Monday, October 22, 2012

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  ->  R2 Fa0/0
R2: Fa0/1        ->  R2 Fa0/1

interface FastEthernet0/0
 ip address

interface FastEthernet0/1
 ip address
interface FastEthernet0/0
 ip address

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

interface Loopback0
 ip address

interface Loopback1
 ip address

interface Loopback2
 ip address

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

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

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

interface FastEthernet0/1
 ip summary-address rip

And watch the route oscillation begin! 

R1 & R2:
debug ip routing

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

R1's Fa0/1 receives the summary for  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 is variably subnetted, 5 subnets, 2 masks
R [120/1] via, 00:00:15, FastEthernet0/0
R [120/1] via, 00:00:03, FastEthernet0/1
R [120/1] via, 00:00:15, FastEthernet0/0
R [120/1] via, 00:00:15, FastEthernet0/0
R [120/1] via, 00:00:15, FastEthernet0/0
R1 then changes the next-hop to R1's Fa0/0 IP address 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 is subnetted, 4 subnets
C is directly connected, Loopback0
C is directly connected, Loopback1
C is directly connected, Loopback2
C is directly connected, Loopback3 is subnetted, 1 subnets
C is directly connected, FastEthernet0/1
C is directly connected, FastEthernet0/0
No route to!

Consequently, if you have quick fingers, you can watch it install its own summary back in the RIB for a split-second:
R [120/2] via, 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 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:

ip route 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.

ip prefix-list block_components seq 5 deny le 24
ip prefix-list block_components seq 10 permit 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 [120/1] via, 00:00:25, FastEthernet0/1
Now let's pull out that null0 route on R2:
no ip route null0
ping from R1:
Sending 5, 100-byte ICMP Echos to, 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

No comments:

Post a Comment