CCIE blueprint: 3.4.a Implement and troubleshoot RIPv2
This post is part of a multipost series about RIP. Other posts in this series are:
- RIP configuration part 1
- RIP configuration part 2
- RIP authentication
- Miscelanious RIP commands
Because RIP is a distance vector routing protocol summarization can be applied everywhere in the topology. This makes it easy to apply policy using summarization.
For this post I’m using a very simple network shown in the diagram below.
For example, you have two routes to a destination. Let’s say 10.16.1.0/24. However, you want traffic to follow a specific path. Maybe because the bandwidth is higher on that path (since RIP uses a hop count and not a metric based on bandwidth this could be a plausible case). Since routers prefer a more specific path that path will be chosen over the summary. In this case you could apply a summary route like 10.16.0.0/23, but you need to be aware that this might cause traffic blackholing in some cases.
A summary in RIP will be applied on the interface level. The command to perform summarization is very simple:
interface GigabitEthernet 0/1 ip summary-address rip 10.16.0.0 255.255.254.0
Important to know is that RIP will only summarize to classful boundaries. So it will not be possible to summarize 192.168.1.0/24 to 192.168.0.0/16 or even to 192.168.0.0/23. This can be seen when attempting to summarize beyond the classful boundary.
R1(config-if)#ip summary-address rip 192.168.0.0 255.255.0.0 Summary mask must be greater or equal to major net
There is a way around this limitation. It can be done by creating a static route (to null0) and redistributing the static route into RIP. However, this will not prevent the more specific route from being advertised as well. So to prevent that you will need a route filter.
R2#sh run | s route router rip version 2 redistribute static network 0.0.0.0 no auto-summary ip route 192.168.0.0 255.255.252.0 Null0
This will result in R1 and R3 learning about the 192.168.0.0/22 network. So we’ve created a summary. However, as can be seen in the output of show ip route below it did not result in the removal of the more specifics.
R3#show ip route rip [...] R 192.168.0.0/22 [120/1] via 126.96.36.199, 00:00:07, GigabitEthernet0/2 R 192.168.1.0/24 [120/1] via 188.8.131.52, 00:00:01, GigabitEthernet0/1 R 192.168.2.0/24 [120/1] via 184.108.40.206, 00:00:07, GigabitEthernet0/2
I want all traffic from R3 to the 192.168.2.0/24 network to pass through R1. The connection to R2 should only be used when the link between R1 and R3 is down. Let’s create a filter to do so. In this case I will filter all routes that are /24 or longer that point to a network somewhere in the 192.168.x.x range. To do this I created a prefix list and applied that prefix list as a distribute list on G0/2. On R3 we can see the effect of this change:
R2: R2#sh run | i RIP_FILTER distribute-list prefix RIP_FILTER out GigabitEthernet0/2 ip prefix-list RIP_FILTER seq 5 deny 192.168.0.0/16 ge 24 ip prefix-list RIP_FILTER seq 10 permit 0.0.0.0/0 le 32 R3: R3#show ip route rip [...] R 192.168.0.0/22 [120/1] via 220.127.116.11, 00:00:06, GigabitEthernet0/2 R 192.168.1.0/24 [120/1] via 18.104.22.168, 00:00:11, GigabitEthernet0/1 R 192.168.2.0/24 [120/2] via 22.214.171.124, 00:00:11, GigabitEthernet0/1
As you can see we still have the summary as advertised by R2, but traffic sent to 192.168.2.0/24 is sent to R1 and has a metric of 2. When performing a traceroute we can see this behaviour:
R3#trace 192.168.2.2 num Type escape sequence to abort. Tracing the route to 192.168.2.2 VRF info: (vrf in name/id, vrf out name/id) 1 126.96.36.199 3 msec 2 msec 3 msec 2 188.8.131.52 3 msec * 3 msec
The most generic summarization of all will be a summarization to 0.0.0.0/0. This type of summary can be inserted in several ways. Easiest of which is to use the command default-information originate under the RIP process. Another way is to create a static default route to null0 and redistributing the static, or, when a different routing protocol provides you with a default, redistribute that. The third option is to use a summary route to provide the default route. In my topology this does not work however, since the summary loops around, so be careful when using this option. In other routing protocols a null route will be automatically installed in the routing table to prevent the feedback of the summary into the routing table. EIGRP for instance uses a null route with an Administrative Distance of 5, which is much lower than the default AD of 90.
Aside from the basic default route options it’s also possible to only originate a default route when a specific other route is available. This makes the default route more reliable. All these reliable options rely on route-maps. Some are more reliable than others.
The first option is to verify whether a route exists on the local router. This ensures that the router knows of a route further on. To configure this the default origination uses a route-map and prefix list to specify which route must be monitored. Look at the example configuration below:
R1: router rip version 2 network 0.0.0.0 default-information originate route-map RELIABLE_RIP no auto-summary ! ip prefix-list LO_R2 seq 5 permit 184.108.40.206/32 ! route-map RELIABLE_RIP permit 10 match ip address prefix-list LO_R2
As long as the route to 220.127.116.11/32 exists R1 will originate a default route. When we remove the route to 18.104.22.168/32 the default route will be withdrawn:
R3 (before withdrawal): Gateway of last resort is 22.214.171.124 to network 0.0.0.0 R* 0.0.0.0/0 [120/1] via 126.96.36.199, 00:00:02, GigabitEthernet0/1 [shutdown of 188.8.131.52 interface on R2] R1: *Jul 30 18:20:14.563: RIP: received v2 update from 184.108.40.206 on GigabitEthernet0/1 *Jul 30 18:20:14.564: 220.127.116.11/32 via 0.0.0.0 in 16 hops (inaccessible) *Jul 30 18:20:14.573: RIP: sending v2 flash update to 18.104.22.168 via GigabitEthernet0/1 (22.214.171.124) *Jul 30 18:20:14.573: RIP: build flash update entries *Jul 30 18:20:14.573: 0.0.0.0/0 via 0.0.0.0, metric 16, tag 0 *Jul 30 18:20:14.573: 126.96.36.199/32 via 0.0.0.0, metric 16, tag 0 *Jul 30 18:20:14.574: RIP: sending v2 flash update to 188.8.131.52 via GigabitEthernet0/2 (184.108.40.206) *Jul 30 18:20:14.574: RIP: build flash update entries *Jul 30 18:20:14.574: 0.0.0.0/0 via 0.0.0.0, metric 16, tag 0 *Jul 30 18:20:14.575: 220.127.116.11/32 via 0.0.0.0, metric 16, tag 0 R3: *Jul 30 18:20:12.502: RIP: received v2 update from 18.104.22.168 on GigabitEthernet0/1 *Jul 30 18:20:12.502: 0.0.0.0/0 via 0.0.0.0 in 16 hops (inaccessible) *Jul 30 18:20:12.502: 22.214.171.124/32 via 0.0.0.0 in 16 hops (inaccessible) Gateway of last resort is not set
This shows that the default route will only be originated while the route is available. But there is an even more reliable option. Say for example that the route does not go down, but the ip address is not reachable anymore. This could be due to the fact that the route is originated via a static or maybe because due to a misconfiguration a filter is applied somewhere. This could possibly cause the router to keep originating a default while it can’t reach the network anymore. This concept works more or less the same way, but a bit more complex.
For this to work we need to use an ip sla, tracking and a dummy route. The rest of the configuration is comparable. This might sound a lot more complex, but it is actually not that hard as shown in the configuration below.
R1: router rip version 2 network 0.0.0.0 default-information originate route-map RELIABLE_RIP no auto-summary ! ip sla 1 icmp-echo 126.96.36.199 frequency 5 ip sla schedule 1 life forever start-time now ! track 1 ip sla 1 ! ip route 169.254.100.1 255.255.255.255 Null0 track 1 ! ip prefix-list LO_R2 seq 5 permit 169.254.100.1/32 ! route-map RELIABLE_RIP permit 10 match ip address prefix-list LO_R2
First of, the ip sla and track features keep track of the reachability of 188.8.131.52. Unfortunately you need both the ip sla and the track command, because you can’t use the ip sla within the ip route command. The ip route command enters a static dummy route into the table. This dummy route points a non-existing ip address to null0 (use private or apipa addressing for this to avoid issues). That dummy route is tracked using the prefix-list and route map like we did in the previous example.
The result can be seen below:
R3: Gateway of last resort is 184.108.40.206 to network 0.0.0.0 R* 0.0.0.0/0 [120/1] via 220.127.116.11, 00:00:06, GigabitEthernet0/1 R2: access-list 100 deny icmp any host 18.104.22.168 access-list 100 permit ip any any ! interface g 0/1 ip access-group 100 in R1: *Jul 30 18:39:04.963: %TRACK-6-STATE: 1 ip sla 1 state Up -> Down R1# R1#show ip route 169.254.100.1 % Network not in table R1#sh ip route 22.214.171.124 Routing entry for 126.96.36.199/32 Known via "rip", distance 120, metric 1 Redistributing via rip Last update from 188.8.131.52 on GigabitEthernet0/1, 00:00:20 ago Routing Descriptor Blocks: * 184.108.40.206, from 220.127.116.11, 00:00:20 ago, via GigabitEthernet0/1 Route metric is 1, traffic share count is 1 R3: Gateway of last resort is not set
So, even though the routing entry for 18.104.22.168 is still available at R1, the default route has been withdrawn because the IP address is not reachable.