RIP Summarization & Null0 Routes

Here's oddity I came across today with RIP.

This scenario is simple enough I'm not even going to bother creating a diagram.

Take two routers, connect two Ethernet interfaces from each router to the other router.
In our scenario, we'll use:
R1: Fa0/0 192.168.0.1  ->  R2 Fa0/0 192.168.0.2
R2: Fa0/1 10.0.0.1        ->  R2 Fa0/1 10.0.0.2

R1:
interface FastEthernet0/0
 ip address 192.168.0.1 255.255.255.0

interface FastEthernet0/1
 ip address 10.0.0.1 255.255.255.0
R2:
interface FastEthernet0/0
 ip address 192.168.0.2 255.255.255.0

interface FastEthernet0/1
 ip address 10.0.0.2 255.255.255.0
Create some extra loopbacks on R2 so that we have something to summarize.

R2:
interface Loopback0
 ip address 172.16.0.1 255.255.255.0

interface Loopback1
 ip address 172.16.1.1 255.255.255.0

interface Loopback2
 ip address 172.16.2.1 255.255.255.0

interface Loopback3
 ip address 172.16.3.1 255.255.255.0
Turn up RIP on both routers and advertise everything into RIP.

R1 & R2:
router rip
 version 2
 network 0.0.0.0
 no auto-summary
At this point, R1 has learned about all the loopbacks on R2.

Now, add some summarization to Fa0/1 on R2.

R2:
interface FastEthernet0/1
 ip summary-address rip 172.16.0.0 255.255.0.0

And watch the route oscillation begin! 

R1 & R2:
debug ip routing

R1 output:
*Mar  1 00:28:05.031: RT: network 172.16.0.0 is now variably masked
*Mar  1 00:28:05.031: RT: add 172.16.0.0/16 via 10.0.0.2, rip metric [120/1]
*Mar  1 00:28:05.035: RT: NET-RED 172.16.0.0/16
R1(config-router)#
*Mar  1 00:28:08.859: RT: del 172.16.0.0/16 via 10.0.0.2, rip metric [120/1]
*Mar  1 00:28:08.863: RT: delete subnet route to 172.16.0.0/16
*Mar  1 00:28:08.863: RT: NET-RED 172.16.0.0/16
R2 output:
*Mar  1 00:28:15.527: RT: network 172.16.0.0 is now variably masked
*Mar  1 00:28:15.531: RT: add 172.16.0.0/16 via 192.168.0.1, rip metric [120/2]
*Mar  1 00:28:15.531: RT: NET-RED 172.16.0.0/16
R2(config)#
*Mar  1 00:28:19.595: RT: del 172.16.0.0/16 via 192.168.0.1, rip metric [120/2]
*Mar  1 00:28:19.595: RT: delete subnet route to 172.16.0.0/16
*Mar  1 00:28:19.595: RT: NET-RED 172.16.0.0/16
So what the heck is going on here?

R1's Fa0/1 receives the summary for 172.16.0.0/16.  It installs the route, although you have to have quick fingers to see it, because it won't be there long.

R1(config-router)#do sh ip route rip
     172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
R       172.16.0.0/24 [120/1] via 192.168.0.2, 00:00:15, FastEthernet0/0
R       172.16.0.0/16 [120/1] via 10.0.0.2, 00:00:03, FastEthernet0/1
R       172.16.1.0/24 [120/1] via 192.168.0.2, 00:00:15, FastEthernet0/0
R       172.16.2.0/24 [120/1] via 192.168.0.2, 00:00:15, FastEthernet0/0
R       172.16.3.0/24 [120/1] via 192.168.0.2, 00:00:15, FastEthernet0/0
R1 then changes the next-hop to R1's Fa0/0 IP address 192.168.0.1 and re-advertises it back to R2 on Fa0/0.  Remember there's no split horizon involved here, these are two separate links.

R2 receives it, and it has no other route to that summary.  This is where my brain threw in the towel for a minute.  How can a router that advertises a route not have that route already installed?  Logic would state that it would be a zero count metric or such, and that the 2-hop route it's receiving from R1 would be viewed as inferior. 
Have a look at the routing table:
R2(config)#do sh ip route
<output omitted>
Gateway of last resort is not set
     172.16.0.0/24 is subnetted, 4 subnets
C       172.16.0.0 is directly connected, Loopback0
C       172.16.1.0 is directly connected, Loopback1
C       172.16.2.0 is directly connected, Loopback2
C       172.16.3.0 is directly connected, Loopback3
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet0/1
C    192.168.0.0/24 is directly connected, FastEthernet0/0
No route to 172.16.0.0/16!

Consequently, if you have quick fingers, you can watch it install its own summary back in the RIB for a split-second:
R       172.16.0.0/16 [120/2] via 192.168.0.1, 00:00:02, FastEthernet0/0
Fortunately RIP has a guard against installing routes that it's advertising, and poisons the route about a quarter second after the above output.  The poison hits R1, which pulls its route to 172.16.0.0/16. The problem resolves itself rather quickly, but it also comes back every 30 seconds when RIP re-advertises the summary.  The process loops infinitely.

So why is this the case, and why doesn't it happen with any other protocol? 

Every other major routing protocol installs a route to null0 when it advertises a summary.  RIP, bless it's heart, doesn't.  You have to install this protection manually:

R2:
ip route 172.16.0.0 255.255.0.0 null0

Now when that route comes back around at R2, the process I described above ("I have a 'zero hop' route, go away 2-hop route!") happens, and the route-bouncing stops.  It's of note that this particular scenario doesn't cause actual loss of connectivity, but if you filter the component routes on the other link coming out of R2 towards R1, you can cause chaos.

R1:
ip prefix-list block_components seq 5 deny 172.16.0.0/16 le 24
ip prefix-list block_components seq 10 permit 0.0.0.0/0 le 32
router rip
  distribute-list prefix block_components in FastEthernet0/0
Sequence 10 of the prefix-list is just for clarity; R1 won't install any other routes from R2 anyway.  I suppose a passive interface on R2's Fa0/0 would've also worked...

R1(config)#do sh ip route rip
R    172.16.0.0/16 [120/1] via 10.0.0.2, 00:00:25, FastEthernet0/1
Now let's pull out that null0 route on R2:
no ip route 172.16.0.0 255.255.0.0 null0
ping from R1:
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
You can run a longer ping if you'd like, but the results are always the same:

It takes a little bit of imagination to see how this could be turned into a problem on the CCIE lab, but the "what the heck!" moment I had when I realized R2 was taking it's own summary was worth making note to understand and avoid it in the future.

Jeff Kronlage