RIP summarization

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:

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.

RIPv2 broadcast

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 23.1.1.2, 00:00:07, GigabitEthernet0/2
R     192.168.1.0/24 [120/1] via 13.1.1.1, 00:00:01, GigabitEthernet0/1
R     192.168.2.0/24 [120/1] via 23.1.1.2, 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 23.1.1.2, 00:00:06, GigabitEthernet0/2
R     192.168.1.0/24 [120/1] via 13.1.1.1, 00:00:11, GigabitEthernet0/1
R     192.168.2.0/24 [120/2] via 13.1.1.1, 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 13.1.1.1 3 msec 2 msec 3 msec
  2 12.1.1.2 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 2.2.2.2/32
!
route-map RELIABLE_RIP permit 10
 match ip address prefix-list LO_R2

As long as the route to 2.2.2.2/32 exists R1 will originate a default route. When we remove the route to 2.2.2.2/32 the default route will be withdrawn:

R3 (before withdrawal):
Gateway of last resort is 13.1.1.1 to network 0.0.0.0

R*    0.0.0.0/0 [120/1] via 13.1.1.1, 00:00:02, GigabitEthernet0/1

[shutdown of 2.2.2.2 interface on R2]

R1:
*Jul 30 18:20:14.563: RIP: received v2 update from 12.1.1.2 on GigabitEthernet0/1
*Jul 30 18:20:14.564:      2.2.2.2/32 via 0.0.0.0 in 16 hops  (inaccessible)
*Jul 30 18:20:14.573: RIP: sending v2 flash update to 224.0.0.9 via GigabitEthernet0/1 (12.1.1.1)
*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:   2.2.2.2/32 via 0.0.0.0, metric 16, tag 0
*Jul 30 18:20:14.574: RIP: sending v2 flash update to 224.0.0.9 via GigabitEthernet0/2 (13.1.1.1)
*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:   2.2.2.2/32 via 0.0.0.0, metric 16, tag 0

R3:
*Jul 30 18:20:12.502: RIP: received v2 update from 13.1.1.1 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:      2.2.2.2/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 2.2.2.2
 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 2.2.2.2. 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 13.1.1.1 to network 0.0.0.0

R*    0.0.0.0/0 [120/1] via 13.1.1.1, 00:00:06, GigabitEthernet0/1


R2:
access-list 100 deny   icmp any host 2.2.2.2
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 2.2.2.2
Routing entry for 2.2.2.2/32
  Known via "rip", distance 120, metric 1
  Redistributing via rip
  Last update from 12.1.1.2 on GigabitEthernet0/1, 00:00:20 ago
  Routing Descriptor Blocks:
  * 12.1.1.2, from 12.1.1.2, 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 2.2.2.2 is still available at R1, the default route has been withdrawn because the IP address is not reachable.