I just posted this over on the IPexpert OSL form in response to a student question. It actually threw me for a second, and I thought it would be a good thing to post out there for everybody!

This post is in regards to the way RIPv2 operates using auto-summary and discontiguous networks. We have a very simple topology here:

R1 —–150.100.12.0/24—–R2

R1 has Loopback100: 10.1.1.1/32

R2 has Loopback100:10.2.2.2/32

First thing is first let’s look at our relevant configurations (I have labbed this up):

R1

R1#sh ip int brie | i 0/0|Loopback100

FastEthernet0/0Â Â Â Â Â Â Â Â Â Â Â 150.100.12.1Â Â Â YES manual up

up

Loopback100Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 10.1.1.1Â Â Â Â Â Â Â YES manual up

up

R1#sh run | beg router rip

router rip

version 2

passive-interface default

no passive-interface FastEthernet0/0

network 10.0.0.0

network 150.100.0.0

R2

R2#sh ip int brie | i net1/0|Loopback100

FastEthernet1/0Â Â Â Â Â Â Â Â Â Â Â 150.100.12.2Â Â Â YES manual up

up

Loopback100Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 10.2.2.2Â Â Â Â Â Â Â YES manual up

up

R2#sh run | beg router rip

router rip

version 2

passive-interface default

no passive-interface FastEthernet1/0

network 10.0.0.0

network 150.100.0.0

Let’s check out the routing table of R1 and R2 as it relates to the routes we are concerned with here:

R1#sh ip route | i 10.[01]

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

RÂ Â Â Â Â Â 10.0.0.0/8 [120/1] via 150.100.12.2, 00:00:07, FastEthernet0/0

CÂ Â Â Â Â Â 10.1.1.1/32 is directly connected, Loopback100

R2#sh ip route | i 10.[02]

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

CÂ Â Â Â Â Â 10.2.2.2/32 is directly connected, Loopback100

RÂ Â Â Â Â Â 10.0.0.0/8 [120/1] via 150.100.12.1, 00:00:05, FastEthernet1/0

What we see on R1 is that it has a directly connected route, 10.1.1.1/32.

What R1 does is it summarizes this /32 route to 10.0.0.0/8 and sends it to

R2 with a metric of 1. When R2 receives the route, R2 has now learned about the route 10.0.0.0/8 via its Fa1/0 interface with a metric of 1. Similarly,

R2 has a directly connected route of 10.2.2.2/32. R2 summarizes this /32 route as well to 10.0.0.0/8 and sends it to R1 with a metric of 1. When R1 receives the route, it has now learned about the route 10.0.0.0/8 via its fa0/0 interface with a metric of 1.

Here is the trick — I know it looks insane at first — R2 gets 10.0.0.0/8 and then sends out 10.0.0.0/8 out the same interface appearing to violate the split horizon rule as you said. BUT what you have to see here is that when R2 sends out 10.0.0.0/8 it is NOT sending out the 10.0.0.0/8 route it learned from R1 — instead it is sending its own summary of its own /32 loopback 10.2.2.2/32.

If we had a true split horizon violation here, we would see the hop count increase until it hit 16 and then expire, but if you notice we do not see that…we always see the metric as 1 in the debugs. Why? Every 30 seconds each router sends out its own “interpretation” of its own /32 loopback address — 10.1.1.1/32 on R1 summarizes to 10.0.0.0/8 on R1 and gets send out. 10.2.2.2/32 on R2 gets summarized to 10.0.0.0/8 and sent out — THAT IS IT! Neither router then takes the route it has just learned and sends it BACK OUT. Check out the debug on R1. Lets look at 2 full “cycles”

*** Here R1 summarizes its own /32 route 10.1.1.1/32 to 10.0.0.0/8 and sends it out with a metric of 1 ***

*Jun 26 09:56:00.501: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (150.100.12.1) *Jun 26 09:56:00.501: RIP: build update entries

*Jun 26 09:56:00.501:Â Â 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0

*** Just over 1 second later it receives 10.0.0.0/8 from R2. Keep in mind this is just R2 summarizing its own 10.2.2.2/32 to 10.0.0.0/8 and sending it out the same way as above! ***

*Jun 26 09:56:12.205: RIP: received v2 update from 150.100.12.2 on FastEthernet0/0

*Jun 26 09:56:12.205:Â Â Â Â Â 10.0.0.0/8 via 0.0.0.0 in 1 hops

*Jun 26 09:56:12.205:Â Â Â Â Â 150.100.24.0/24 via 0.0.0.0 in 1 hops

*Jun 26 09:56:12.209:Â Â Â Â Â 150.100.25.0/24 via 0.0.0.0 in 1 hops

*Jun 26 09:56:12.209:Â Â Â Â Â 150.100.100.0/24 via 0.0.0.0 in 1 hops

*** 30 seconds later (default RIP timer, right : ) ) R1 does the EXACT same thing. Here is where the confusion can set in. It would appear it is sending out the same route it just learned, but it is not. IF that was the case, the metric would be increased to 2, right? It is simply sending out its summary of its own 10.1.1.1/32 route again ***

*Jun 26 09:56:29.537: RIP: sending v2 update to 224.0.0.9 via FastEthernet0/0 (150.100.12.1) *Jun 26 09:56:29.537: RIP: build update entries

*Jun 26 09:56:29.537:Â Â 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0

*** 30 seconds after the first update R1 received from R2 the same thing happens from the other side… R2 is not sending out what it just received from R1, but it’s own interpretation of its own /32 route, which happens to be the same thing***

*Jun 26 09:56:39.305: RIP: received v2 update from 150.100.12.2 on FastEthernet0/0

*Jun 26 09:56:39.305:Â Â Â Â Â 10.0.0.0/8 via 0.0.0.0 in 1 hops

*Jun 26 09:56:39.305:Â Â Â Â Â 150.100.24.0/24 via 0.0.0.0 in 1 hops

*Jun 26 09:56:39.305:Â Â Â Â Â 150.100.25.0/24 via 0.0.0.0 in 1 hops

*Jun 26 09:56:39.305:Â Â Â Â Â 150.100.100.0/24 via 0.0.0.0 in 1 hops

I hope that helps!