To filter routes in RIPv2 protocol I have these options:
1. Filtering with Passive Interface
2. Filtering with Prefix-Lists
3. Filtering with Standard Access-Lists
4. Filtering with Extended Access-Lists
5. Filtering with Offset Lists
6. Filtering with Administrative Distance
7. Filtering with Per Neighbor AD
To do some tests I will use this topology already used in other topic:
1. PASSIVE INTERFACE
I can consider passive-interface an indirect form of filtering. For example, link connecting R4 and R5 via their Fa1/1 it’s an OSPF enabled link
R4#show run | s r o
router ospf 1000
router-id 4.4.4.4
log-adjacency-changes
area 1 authentication message-digest
network 10.0.10.0 0.0.0.255 area 1 –> Fa1/1
network 10.0.11.0 0.0.0.255 area 1
network 10.0.12.0 0.0.0.255 area 1
but due to RIP configuration (command network 10.0.0.0)
R4#show run | s r r
router rip
version 2
network 10.0.0.0
no auto-summary
The link is exchanging RIP packet too:
R4#
*Mar 1 00:57:32.699: RIP: sending v2 update to 224.0.0.9 via FastEthernet1/1 (10.0.10.4)
*Mar 1 00:57:32.699: RIP: build update entries
*Mar 1 00:57:32.699: 1.0.0.254/32 via 0.0.0.0, metric 3, tag 0
*Mar 1 00:57:32.703: 2.0.0.254/32 via 0.0.0.0, metric 3, tag 0
*Mar 1 00:57:32.703: 10.0.0.0/24 via 0.0.0.0, metric 2, tag 0
*Mar 1 00:57:32.703: 10.0.1.0/24 via 0.0.0.0, metric 2, tag 0
*Mar 1 00:57:32.703: 10.0.2.0/24 via 0.0.0.0, metric 2, tag 0
*Mar 1 00:57:32.707: 10.0.3.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:57:32.707: 10.0.5.0/24 via 0.0.0.0, metric 2, tag 0
*Mar 1 00:57:32.707: 10.0.6.0/24 via 0.0.0.0, metric 2, tag 0
*Mar 1 00:57:32.707: 10.0.8.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:57:32.711: 10.0.9.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:57:32.711: 10.0.11.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:57:32.711: 10.0.12.0/24 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:57:33.419: RIP: received v2 update from 10.0.10.5 on FastEthernet1/1
*Mar 1 00:57:33.423: 1.0.0.254/32 via 0.0.0.0 in 3 hops
*Mar 1 00:57:33.423: 2.0.0.254/32 via 0.0.0.0 in 3 hops
*Mar 1 00:57:33.423: 10.0.0.0/24 via 0.0.0.0 in 2 hops
*Mar 1 00:57:33.423: 10.0.1.0/24 via 0.0.0.0 in 2 hops
*Mar 1 00:57:33.427: 10.0.2.0/24 via 0.0.0.0 in 2 hops
*Mar 1 00:57:33.427: 10.0.4.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:57:33.427: 10.0.5.0/24 via 0.0.0.0 in 2 hops
*Mar 1 00:57:33.431: 10.0.6.0/24 via 0.0.0.0 in 2 hops
*Mar 1 00:57:33.431: 10.0.7.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:57:33.431: 10.0.13.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:57:33.431: 10.0.14.0/24 via 0.0.0.0 in 1 hops
*Mar 1 00:57:33.435: 10.0.15.0/24 via 0.0.0.0 in 1 hops
R4#show ip rip database 10.0.10.0 255.255.255.0
10.0.10.0/24 directly connected, FastEthernet1/1
R4#show ip route 10.0.10.0
Routing entry for 10.0.10.0/24
Known via “connected”, distance 0, metric 0 (connected, via interface)
Redistributing via rip
Advertised by rip –> this tells me that network command is putting route into rip database
Routing Descriptor Blocks:
* directly connected, via FastEthernet1/1
Route metric is 0, traffic share count is 1
R4(config)#router rip
R4(config-router)#passive-interface Fa1/1
“Static” info about the route on R4 don’t change (network is still injected in database). Let’s check again with a debug if something changed:
R4#debug condition interface fa1/1
Condition 1 set
R4#debug ip rip
RIP protocol debugging is on
R4#show debug
IP routing:
RIP protocol debugging is on
Condition 1: interface Fa1/1 (1 flags triggered)
Flags: Fa1/1
First effect of making passive fa1/1 on R4 is that R4 stops sending RIP packet on this interface but it keep receiving and processing those one received:
R4#show log | i RIP
Aug 14 22:05:30.067: RIP: received v2 update from 10.0.10.5 on FastEthernet1/1
Aug 14 22:05:38.795: RIP: received v2 update from 10.0.10.5 on FastEthernet1/1
Aug 14 22:05:58.455: RIP: received v2 update from 10.0.10.5 on FastEthernet1/1
Aug 14 22:06:26.315: RIP: received v2 update from 10.0.10.5 on FastEthernet1/1
Aug 14 22:06:52.303: RIP: received v2 update from 10.0.10.5 on FastEthernet1/1
Aug 14 22:07:21.159: RIP: received v2 update from 10.0.10.5 on FastEthernet1/1
Aug 14 22:07:48.499: RIP: received v2 update from 10.0.10.5 on FastEthernet1/1
Aug 14 22:08:16.883: RIP: received v2 update from 10.0.10.5 on FastEthernet1/1
Aug 14 22:08:44.687: RIP: received v2 update from 10.0.10.5 on FastEthernet1/1
R4#show ip route rip | i FastEthernet1/1$
R 10.0.13.0 [120/1] via 10.0.10.5, 00:00:27, FastEthernet1/1
R 10.0.7.0 [120/1] via 10.0.10.5, 00:00:27, FastEthernet1/1
R 10.0.4.0 [120/1] via 10.0.10.5, 00:00:27, FastEthernet1/1
R5 not seeing rip packets coming into Fa1/1 reconverge in this way about network 10.0.9.0/24
R5#show ip route 10.0.9.0
Routing entry for 10.0.9.0/24
Known via “rip”, distance 120, metric 2
Redistributing via rip
Last update from 10.0.4.3 on FastEthernet1/13, 00:00:00 ago
Routing Descriptor Blocks:
* 10.0.7.2, from 10.0.7.2, 00:00:00 ago, via FastEthernet1/12
Route metric is 2, traffic share count is 1
10.0.4.3, from 10.0.4.3, 00:00:00 ago, via FastEthernet1/13
Route metric is 2, traffic share count is 1
So R5 goes R2 or R3 to reach a network of R4.
Even if Fa1/1 is passive R4 keeps sending update about this network in outgoing update on different interfaces:
RIP protocol debugging is on
R4#
Aug 14 22:34:28.747: RIP: sending v2 update to 224.0.0.9 via FastEthernet1/13 (10.0.8.4)
Aug 14 22:34:28.747: RIP: build update entries
………………………………………………………..
Aug 14 22:34:28.755: 10.0.10.0/24 via 0.0.0.0, metric 1, tag 0
Nothing more to add about passive interface with RIP, to recap: – passive-interface fa1/1:
– router stops sending rip update packets out of interface fa1/1
– rip peer connected on other side of this interface will flush old routes entries learned on this link
– router keeps receiving and processing rip update packet received on fa1/1 populating routing table as necessary – gateway for routes can be still out of fa1/1.
– router keeps advertising the network connected to its fa1/1 in update it sends to peer connected on interfaces different from fa1/1- If I want to exclude all rip traffic (incoming/outgoing) on a link I must set passive both the interfaces connected by that link.
2. PREFIX-LIST
More useful filtering tool are prefix-list. You can find more general and detailed explanation about route-filtering using distribute-list, ACLs (standard/extended), prefix-list and route-map at this LINK. Here I would do some little test as a reminder.
With a prefix-list I can filter a set of routes specifying a range of mask-length. RIP can use a prefix-list calling it in these ways:
Option 1) gives me a very granular approach for filtering routes, for example I can filter a set of routes matched by a first prefix-list and filter them only for gateway matched by a second prefix-list also for a single interface. Let’s do an example:
R5’s rip learned routes are:
R5#show ip route rip
10.0.0.0/24 is subnetted, 16 subnets
R 10.0.8.0 [120/1] via 10.0.10.4, 00:00:17, FastEthernet1/1
[120/1] via 10.0.7.2, 00:00:05, FastEthernet1/12
R 10.0.9.0 [120/1] via 10.0.10.4, 00:00:17, FastEthernet1/1
R 10.0.2.0 [120/1] via 10.0.7.2, 00:00:05, FastEthernet1/12
[120/1] via 10.0.4.3, 00:00:04, FastEthernet1/13
R 10.0.3.0 [120/1] via 10.0.10.4, 00:00:17, FastEthernet1/1
[120/1] via 10.0.4.3, 00:00:04, FastEthernet1/13
R 10.0.0.0 [120/1] via 10.0.4.3, 00:00:04, FastEthernet1/13
R 10.0.1.0 [120/1] via 10.0.4.3, 00:00:04, FastEthernet1/13
R 10.0.6.0 [120/1] via 10.0.7.2, 00:00:05, FastEthernet1/12
R 10.0.5.0 [120/1] via 10.0.7.2, 00:00:05, FastEthernet1/12
Suppose we want that R5 learns about network 10.0.2.0/24 and 10.0.3.0/24 only from R3 (10.0.4.3) one solution could be:
– match routes 10.0.2.0/24 and 10.0.3.0/24 in one prefix-list and deny them –> call it NET-23
– match gateway R4 (10.0.10.4) and R2 (10.0.7.2) with two other prefix-list –> call them GATEWAY-R4 and GATEWAY-R2
R5(config)#ip prefix-list NET-23 deny 10.0.2.0/23 ge 24
R5(config)#ip prefix-list NET-23 permit 0.0.0.0/0 le 32
R5(config)#ip prefix-list GATEWAY-R4 permit 10.0.10.4/32
R5(config)#ip prefix-list GATEWAY-R2 permit 10.0.7.2/32
R5(config)#router rip
R5(config-router)#distribute-list prefix NET-23 gateway GATEWAY-R4 in FastEthernet1/1
R5(config-router)#distribute-list prefix NET-23 gateway GATEWAY-R2 in FastEthernet1/12
R5#show run | s r r
router rip
version 2
network 10.0.0.0
distribute-list prefix NET-23 gateway GATEWAY-R4 in FastEthernet1/1
distribute-list prefix NET-23 gateway GATEWAY-R2 in FastEthernet1/12
no auto-summary
R5#show ip route rip
10.0.0.0/24 is subnetted, 16 subnets
R 10.0.8.0 [120/1] via 10.0.10.4, 00:00:02, FastEthernet1/1
[120/1] via 10.0.7.2, 00:00:00, FastEthernet1/12
R 10.0.9.0 [120/1] via 10.0.10.4, 00:00:02, FastEthernet1/1
R 10.0.2.0 [120/1] via 10.0.7.2, 00:02:01, FastEthernet1/12 –> going HolDown
[120/1] via 10.0.4.3, 00:00:11, FastEthernet1/13
R 10.0.3.0 [120/1] via 10.0.10.4, 00:02:18, FastEthernet1/1 –> going HolDown
[120/1] via 10.0.4.3, 00:00:11, FastEthernet1/13
R 10.0.0.0 [120/1] via 10.0.4.3, 00:00:11, FastEthernet1/13
R 10.0.1.0 [120/1] via 10.0.4.3, 00:00:11, FastEthernet1/13
R 10.0.6.0 [120/1] via 10.0.7.2, 00:00:00, FastEthernet1/12
R 10.0.5.0 [120/1] via 10.0.7.2, 00:00:00, FastEthernet1/12
We can see that 10.0.2.0/24 learned via 10.0.7.2 (R2) is going to expire, the same for 10.0.3.0/24 learned via 10.0.10.4 (R4)
R5#show ip route rip
10.0.0.0/24 is subnetted, 16 subnets
R 10.0.8.0 [120/1] via 10.0.10.4, 00:00:08, FastEthernet1/1
[120/1] via 10.0.7.2, 00:00:28, FastEthernet1/12
R 10.0.9.0 [120/1] via 10.0.10.4, 00:00:09, FastEthernet1/1
R 10.0.2.0 [120/1] via 10.0.4.3, 00:00:09, FastEthernet1/13
R 10.0.3.0 [120/1] via 10.0.4.3, 00:00:09, FastEthernet1/13
R 10.0.0.0 [120/1] via 10.0.4.3, 00:00:09, FastEthernet1/13
R 10.0.1.0 [120/1] via 10.0.4.3, 00:00:09, FastEthernet1/13
R 10.0.6.0 [120/1] via 10.0.7.2, 00:00:28, FastEthernet1/12
R 10.0.5.0 [120/1] via 10.0.7.2, 00:00:28, FastEthernet1/12
As an example of 2) On R5 I filter all incoming updates from R4
R5(config)#ip prefix-list DENY-R4 deny 10.0.10.4/32
R5(config)#router rip
R5(config-router)#distribute-list gateway DENY-R4 in fa1/1
R5#show ip route rip | i FastEthernet1/1$
R 10.0.8.0 [120/1] via 10.0.10.4, 00:00:38, FastEthernet1/1 –> Expiring
R 10.0.9.0 [120/1] via 10.0.10.4, 00:00:38, FastEthernet1/1 –> Expiring
R 10.0.3.0 [120/1] via 10.0.10.4, 00:00:38, FastEthernet1/1 –> Expiring
R5#show ip route rip | i FastEthernet1/1$
R 10.0.8.0 [120/1] via 10.0.10.4, 00:02:56, FastEthernet1/1
R 10.0.9.0 [120/1] via 10.0.10.4, 00:02:56, FastEthernet1/1
R 10.0.3.0 [120/1] via 10.0.10.4, 00:02:56, FastEthernet1/1
R5#show ip route rip | i FastEthernet1/1$
R 10.0.8.0 [120/1] via 10.0.10.4, 00:03:00, FastEthernet1/1
R 10.0.9.0 [120/1] via 10.0.10.4, 00:03:00, FastEthernet1/1
R 10.0.3.0 [120/1] via 10.0.10.4, 00:03:00, FastEthernet1/1
R5#show ip route rip
10.0.0.0/24 is subnetted, 15 subnets
R 10.0.8.0 [120/1] via 10.0.7.2, 00:00:26, FastEthernet1/12
R 10.0.2.0 [120/1] via 10.0.7.2, 00:00:26, FastEthernet1/12
[120/1] via 10.0.4.3, 00:00:57, FastEthernet1/13
R 10.0.3.0 [120/1] via 10.0.4.3, 00:00:57, FastEthernet1/13
R 10.0.0.0 [120/1] via 10.0.4.3, 00:00:57, FastEthernet1/13
R 10.0.1.0 [120/1] via 10.0.4.3, 00:00:57, FastEthernet1/13
R 10.0.6.0 [120/1] via 10.0.7.2, 00:00:26, FastEthernet1/12
R 10.0.5.0 [120/1] via 10.0.7.2, 00:00:26, FastEthernet1/12
Ok, R4 filtered.
———————————– NOTE ———————————————-
With the option “gateway” IOS (tested 12.4(25d) and 15.4.1T) seems to give me the possibility to filter in out direction too:
R5(config-router)#distribute-list gateway GATEWAY-R4 ?
in Filter incoming routing updates
out Filter outgoing routing updates
but
R5(config-router)#distribute-list gateway GATEWAY-R4 out fa1/1
% Gateway not allowed with OUT in distribute-list cmd
the same if use “gateway” as the second option after the keyword “prefix”:
R5(config-router)#distribute-list prefix NET-23 gateway GATEWAY-R4 out fa1/1
% Gateway not allowed with OUT in distribute-list cmd
It seems reasonable since gateway is something related to an incoming route – anyway I’ll check this with other IGP
——————————– END NOTE ———————————————
———————————– NOTE ————————————————
R5(config)#ip prefix-list NET-23 deny 10.0.2.0/23 ge 24
R5(config)#ip prefix-list NET-23 permit 0.0.0.0/0 le 32
R5(config)#ip prefix-list GATEWAY-R4 permit 10.0.10.4/32
R5(config-router)#distribute-list prefix NET-23 gateway GATEWAY-R4 in FastEthernet1/1
R5(config)#ip prefix-list DENY-R4 deny 10.0.10.4/32
R5(config-router)#distribute-list gateway DENY-R4 in fa1/1
In first set of commands the prefix-list GATEWAY-R4 is permitting(matching) the gateway I wanted set of routes (permitted/denied by prefix-list NET-23) would come/not-com from
In second set of commands the prefix-list DENY-R4 is denying the gateway ip address meaning that all routes should be filtered.
——————————– END NOTE ———————————————
Option 3) gives me a tool to filter routes during a redistribution, for example on Route-Server I want redistribute a subset of the connected routes into rip:
Route-Server(config)#ip prefix-list INJECTOR permit 128.0.0.0/1 ge 24
Route-Server(config)#route-map SELECTOR permit 10
Route-Server(config-route-map)#match ip address prefix-list INJECTOR
Route-Server(config)#router rip
Route-Server(config-router)#redistribute connected route-map SELECTOR
Matching prefix-list INJECTOR I’m telling router to consider against the route-map statement the higher half part of the ip address space (128.x.x.x) with mask length >= 24, then since route-map action is permit, router will redistribute this set of routes into RIP.
Route-Server#show ip rip database | i redistributed
135.136.43.180/31 redistributed
146.60.5.182/31 redistributed
156.23.244.64/26 redistributed
160.44.165.192/26 redistributed
167.51.48.252/31 redistributed
172.124.97.176/28 redistributed
176.67.161.20/31 redistributed
179.225.88.0/24 redistributed
192.253.51.0/28 redistributed
203.156.156.148/30 redistributed
204.84.65.224/27 redistributed
204.231.109.0/24 redistributed
210.164.50.0/26 redistributed
NOTE: You can find more details about interaction between permit/deny rules of an ACL and permit/deny action of a route-map at this LINK
3. STANDARD ACCESS-LIST
In rip a standard access-list can be invoked by RIP for filtering-routes purpose in two ways:
1) distribute-list [std-ACL-number] in/out [interface] –> direct routes filtering
2) route-map [route-map-name] permit/deny <seq-num> –> routes filtering during redistribution
match ip address [std-ACL-number]
Standard ACL are very limited when used as routes filter because we cannot match mask length of the route.
R2#show ip route 10.0.0.0 255.255.255.0
Routing entry for 10.0.0.0/24
Known via “rip”, distance 120, metric 1
Redistributing via rip
Last update from 10.0.2.3 on FastEthernet1/1, 00:00:05 ago
Routing Descriptor Blocks:
* 10.0.6.254, from 10.0.6.254, 00:00:24 ago, via FastEthernet0/1
Route metric is 1, traffic share count is 1
10.0.2.3, from 10.0.2.3, 00:00:05 ago, via FastEthernet1/1
Route metric is 1, traffic share count is 1
For example if on R2 I wanted to filter 10.0.0.0/24, I couldn’t filter distinguishing the gateway or even the mask, with a standard ACL I could do:
R2(config)#access-list 10 deny 10.0.0.0 0.0.0.255
R2(config)#access-list 10 permit any
R2#show run | s r r
router rip
version 2
network 10.0.0.0
distribute-list 10 in
no auto-summary
R2#show ip route 10.0.0.0 255.255.255.0
Routing entry for 10.0.0.0/24
Known via “rip”, distance 120, metric 1
Redistributing via rip
Last update from 10.0.6.254 on FastEthernet0/1, 00:02:11 ago –> Expiring
Routing Descriptor Blocks:
* 10.0.6.254, from 10.0.6.254, 00:02:11 ago, via FastEthernet0/1
Route metric is 1, traffic share count is 1
10.0.2.3, from 10.0.2.3, 00:02:19 ago, via FastEthernet1/1
Route metric is 1, traffic share count is 1
R2#show ip route 10.0.0.0 255.255.255.0
Routing entry for 10.0.0.0/24
Known via “rip”, distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 10.0.6.254 on FastEthernet0/1, 00:03:11 ago
Hold down timer expires in 175 secs
R2#show ip route 10.0.0.0 255.255.255.0
Routing entry for 10.0.0.0/24
Known via “rip”, distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 10.0.6.254 on FastEthernet0/1, 00:03:48 ago
Hold down timer expires in 138 secs
R2#show ip route 10.0.0.0 255.255.255.0
% Subnet not in table
So with a std-ACL I have not too much flexibility, matching a portion of the network address is only thing we can do.
The same concept is true when using std-ACL called by a route-map for redistributing purpose. Here an example of std-ACL called by a route-map permitting connected networks starting with 104 in first octet:
Route-Server#show ip route connected | i ^C 104.
C 104.54.143.0/24 is directly connected, Loopback10100
C 104.219.202.48/29 is directly connected, Loopback10053
Route-Server#show access-list 10
Standard IP access list 10
10 permit 104.0.0.0, wildcard bits 0.255.255.255 (2 matches)
Route-Server#
!
route-map SELECTOR permit 10
match ip address 10
Route-Server#show run | s r r
router rip
version 2
redistribute connected route-map SELECTOR
network 10.0.0.0
no auto-summary
Route-Server#show ip rip database | i redistributed
104.54.143.0/24 redistributed
104.219.202.48/29 redistributed
4. EXTENDED ACCESS-LIST
In rip a extended access-list can be invoked by RIP for filtering-routes purpose in two ways:
1) distribute-list [ext-ACL-number] in/out [interface]
–> direct routes filtering
2) route-map [route-map-name] permit/deny
match ip address [ext-ACL-number]
–> routes filtering during redistribution
Here we must pay attention to the logic used (more details can be read at this LINK).
With option 1) since RIP is belonging to the family of IGP protocols ext-ACL fields are interpreted by IOS in this way:
[source ip address][wildcard mask] = [ROUTE’S GATEWAY IP ADDRESS][wildcard mask] => match the ip address of the device to exit toward the route.
[destination ip address][wildcard mask] = [NETWORK ADDRESS][wildcard mask] => match the network portion of the ip prefix.
With option 2) fields of the ext-ACL are interpreted by IOS in this different ways:
[source ip address][wildcard mask] = [NETWORK ADDRESS][wildcard mask] => match a specific portion of the configured ADDRESS based on wildcard
[destination ip address][wildcard mask] = [NETWORK MASK][wildcard mask] => match a specific portion of the configured MASK based on wildcard => Mask Length
In other words when using distribute-list + ext-ACl I can match gateway of the route and a portion of the network address based on a wildcard but I cannot match specific mask length. With route-map + ext-ACL I can match a portion of a network address and I can specifiy different mask length ranges.
Example 1) – distribute-list + ext-ACl
NOTE: remember distribute-list can invoke only numbered extended ACL (not-named-ext-ACL, at least with IGP, BGP can do it per neighbor)
on R3 I want filter routes 104.x.x.x coming from gateway = Route-Server (10.0.0.254 connected to R3’s fa0/0)
R3#show ip route 104.0.0.0
Routing entry for 104.0.0.0/8, 2 known subnets
Variably subnetted with 2 masks
Redistributing via rip
R 104.219.202.48/29 [120/1] via 10.0.0.254, 00:00:09, FastEthernet0/0
R 104.54.143.0/24 [120/1] via 10.0.0.254, 00:00:09, FastEthernet0/0
R3(config)#access-list 100 deny ip 10.0.0.254 0.0.0.0 104.0.0.0 0.255.255.255
R3(config)#access-list 100 permit ip any any
R3(config)#router rip
R3(config-router)#distribute-list 100 in
R3#show access-lists
Extended IP access list 100
10 deny ip host 10.0.0.254 104.0.0.0 0.255.255.255 (2 matches) –> matching(denying) the 2 rip routes 104.x.x.x from gateway 10.0.0.254
20 permit ip any any (34 matches)
R3#show ip route 104.0.0.0
Routing entry for 104.0.0.0/8, 2 known subnets
Variably subnetted with 2 masks
Redistributing via rip
R 104.219.202.48/29 [120/1] via 10.0.0.254, 00:02:31, FastEthernet0/0 –> Expiring
R 104.54.143.0/24 [120/1] via 10.0.0.254, 00:02:31, FastEthernet0/0 –> Expiring
After a while, R3 receives the route from R2 and no more from Route-Server
R3#show ip route 104.0.0.0
Routing entry for 104.0.0.0/8, 2 known subnets
Variably subnetted with 2 masks
Redistributing via rip
R 104.219.202.48/29 [120/2] via 10.0.2.2, 00:00:10, FastEthernet1/1
R 104.54.143.0/24 [120/2] via 10.0.2.2, 00:00:10, FastEthernet1/1
Example 2) route-map + ext-ACL
Let’s try to get the same result I got when using route-map+prefix-list. I want redistribute into rip the higher half part of the ip address space (128.x.x.x) with mask length >= 24, using an ip prefix-list I configured something like:
Route-Server(config)#ip prefix-list INJECTOR permit 128.0.0.0/1 ge 24
Let’s use an ext-ACl instead – I start from a clean condition on Route-Server (no connected Loopback are redistributed/injectednetwork command) into rip database):
Route-Server#show ip rip database | i redistributed
Route-Server#show ip rip database | i directly
10.0.0.0/24 directly connected, Ethernet0/0
10.0.6.0/24 directly connected, Ethernet0/1
Creating an ext-ACl with name INJECTOR – NOTE: (route-map can always call ext-numbered/named-ACL)
Route-Server(config)#ip access-list extended INJECTOR
Route-Server(config-ext-nacl)#5 permit ip 128.0.0.0 127.255.255.255 255.255.255.0 0.0.0.255
The logic here is –>
10000000.0.0.0 011111111.255.255.255 check if the first bit is = 1
255.255.255.0 0.0.0.255 –> check if the first 24 bits are 255.255.255 last 8 bits can be any bits –> /24 <= mask-length <= 32
Route-Server(config)#route-map SELECTOR permit 10
Route-Server(config-route-map)#match ip address INJECTOR
Route-Server(config)#router rip
Route-Server(config-router)#redistribute connected route-map SELECTOR
Route-Server#show ip rip database | i redistributed
135.136.43.180/31 redistributed
146.60.5.182/31 redistributed
156.23.244.64/26 redistributed
160.44.165.192/26 redistributed
167.51.48.252/31 redistributed
172.124.97.176/28 redistributed
176.67.161.20/31 redistributed
179.225.88.0/24 redistributed
192.253.51.0/28 redistributed
203.156.156.148/30 redistributed
204.84.65.224/27 redistributed
204.231.109.0/24 redistributed
210.164.50.0/26 redistributed
We can compare this output with the one I got in prefix-list case, we can verify they are perfectly matching, well done!
5. OFFSET LISTS
An offset-list is a filtering tool when used as an extrema ratio. By default an offset-list is a tool used to INCREASE the metric of a route. Of course, if we increase the metric so it reaches 16 hops or more the route will become inaccessible and then discarded/filtered. Let’s see the syntax:
offset-list keyword can invoke Standard-ACL (numbered or named)
R3(config)#router rip
R3(config-router)#offset-list ?
<0-99> Access list of networks to apply offset (0 selects all networks)
<1300-1999> Access list of networks to apply offset (expanded range)
WORD Access-list name
A special case exists when setting 0 as ACL number meaning –> all networks match.
We can increase metric for incoming or outgoing routes independently by the interface receiving/transmitting the routes
R3(config-router)#offset-list 1 ?
in Perform offset on incoming updates
out Perform offset on outgoing updates
Then we must set the OFFSET for the route:
R3(config-router)#offset-list 1 in ?
<0-16> Offset
Then we can specify the interface too:
R3(config-router)#offset-list 1 in 10 ?
[list of configurable interfaces]
Example – R3 is receiving these two 204.x.x.x networks from Route-Server with metric 1
R3#show ip route | i 204
204.84.65.0/27 is subnetted, 1 subnets
R 204.84.65.224 [120/1] via 10.0.0.254, 00:00:15, FastEthernet0/0
R 204.231.109.0/24 [120/1] via 10.0.0.254, 00:00:15, FastEthernet0/0
Suppose I want add an Ooffset of 10 the metric of these 2 routes, I can do:
R3(config)#ip access-list standard NET-204
R3(config-std-nacl)#5 permit 204.0.0.0 0.255.255.255
R3(config)#router rip
R3(config-router)#offset-list NET-204 in 10
Routes have now metric of 1+10=11
R3#show ip route | i 204
204.84.65.0/27 is subnetted, 1 subnets
R 204.84.65.224 [120/11] via 10.0.0.254, 00:00:05, FastEthernet0/0
R 204.231.109.0/24 [120/11] via 10.0.0.254, 00:00:05, FastEthernet0/0
If now I want to filter the same two routes, I can adjust the offset to at least 15:
R3(config)#router rip
R3(config-router)#offset-list NET-204 in 15
R3#show ip route | i 204
[EMPTY OUTPUT] –> routes are gone
I can configure an offset-list for the same ACL with different offset in the two directions in/out, for example:
R3(config)#router rip
R3(config-router)#offset-list NET-204 in 10
R3(config-router)#offset-list NET-204 out 3
Here I’m increasing of 10 incoming update and I’m further adding an offset of 3 for outgoing update, so I have in out:
R3#
Aug 15 16:30:15.339: RIP: sending v2 update to 224.0.0.9 via FastEthernet1/13 (10.0.4.3)
Aug 15 16:30:15.339: RIP: build update entries
Aug 15 16:30:42.335: 204.84.65.224/27 via 0.0.0.0, metric 15, tag 0
Aug 15 16:30:42.339: 204.231.109.0/24 via 0.0.0.0, metric 15, tag 0
I see an outgoing metric of 15 hops because 1 hop is what R3 has normally in its database, with an incoming offset of 10 I have in database:
R3#show ip rip database
…………………..
204.84.65.0/24 auto-summary
204.84.65.224/27
[11] via 10.0.0.254, 00:00:20, FastEthernet0/0
204.231.109.0/24 auto-summary
204.231.109.0/24
[11] via 10.0.0.254, 00:00:20, FastEthernet0/0
When R3 sends out its update adds normally 1, then adds an offset of 3 totalling 11+1+3 = 15.
6. ADMINISTRATIVE DISTANCE (AD)
A simple method for filtering routing updates coming from a specific ip source is increasing the Administrative Distance up to 255.
R3(config)#router rip
R3(config-router)#distance ?
<1-255> Administrative distance
R3(config-router)#distance 255 ?
A.B.C.D IP Source address
R3(config-router)#distance 255 10.0.0.254 ?
A.B.C.D Wildcard bits
R3(config-router)#distance 255 10.0.0.254 0.0.0.0 ?
<1-99> IP Standard access list number
<1300-1999> IP Standard expanded access list number
WORD Standard access-list name
I can match a specific source or a group of sources (IP Source address/Wildcards bits) then match a set of routes calling a standard ACL.
For example, suppose we want increase up to 255 the AD of routes 204.x.x.x sent by Route-Server (10.0.0.254) to R3:
R3#show ip route | i 204
204.84.65.0/27 is subnetted, 1 subnets
R 204.84.65.224 [120/1] via 10.0.0.254, 00:00:12, FastEthernet0/0
R 204.231.109.0/24 [120/1] via 10.0.0.254, 00:00:12, FastEthernet0/0
I can do:
R3#show access-lists
Standard IP access list NET-204
5 permit 204.0.0.0, wildcard bits 0.255.255.255
R3(config)#router rip
R3(config-router)#distance 255 10.0.0.254 0.0.0.0 NET-204
R3#show ip route | i 204|Time
Time source is user configuration, 17:05:16.875 UTC Fri Aug 15 2014
204.84.65.0/27 is subnetted, 1 subnets
R 204.84.65.224 [120/1] via 10.0.0.254, 00:01:47, FastEthernet0/0
R 204.231.109.0/24 [120/1] via 10.0.0.254, 00:01:47, FastEthernet0/0
R3#show ip route | i 204|Time
Time source is user configuration, 17:05:24.143 UTC Fri Aug 15 2014
204.84.65.0/27 is subnetted, 1 subnets
R 204.84.65.224 [120/1] via 10.0.0.254, 00:01:54, FastEthernet0/0 –> Expiring
R 204.231.109.0/24 [120/1] via 10.0.0.254, 00:01:55, FastEthernet0/0 –> Expiring
R3#show ip route | i 204|Time
Time source is user configuration, 17:06:40.395 UTC Fri Aug 15 2014
204.84.65.0/27 is subnetted, 1 subnets
R 204.84.65.224/27 is possibly down,
R 204.231.109.0/24 is possibly down, routing via 10.0.0.254, FastEthernet0/0
R3#show ip route | i 204|Time
Time source is user configuration, 17:08:07.255 UTC Fri Aug 15 2014
204.84.65.0/27 is subnetted, 1 subnets
R 204.84.65.224 [120/2] via 10.0.2.2, 00:00:13, FastEthernet1/1 –> Now in 2 hops from R2
R 204.231.109.0/24 [120/2] via 10.0.2.2, 00:00:14, FastEthernet1/1 –> Now in 2 hops from R2
7. Per Neighbor AD –> we can consider it a special case of 6. –> match exact neighbor ip address setting 0.0.0.0 in wildcard