Hey Kim,
This is a bit tricky to explain, so bear with me. It is actually working as
it should:
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!
Regards,
Joe Astorino
CCIE #24347 (R&S)
Sr. Support Engineer - IPexpert, Inc.
URL: http://www.IPexpert.com
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Kim Pedersen
Sent: Friday, June 26, 2009 4:39 AM
To: [email protected]
Subject: [OSL | CCIE_RS] Summary routes and split horizon.
Hi All,
I have two routers, R1 and R2. Each of them has a loopback interface
with R1 (10.1.1.1/24) and R2 (10.2.2.2). I am running a serial link
between them in the 172.16.0.0 net. They are running RIP version 2 with
auto-summary ON.
Since it crosses a major-network boundary, I expect them to summarize
to the 10.0.0.0/8 network. What puzzles me, is that each of them sends
out the summary route, even though it also learns the same summary route
from the other router. I thought split horizon would kick in, and
basically state: "You have learned route 10.0.0.0/8 through interface
s0/0, so dont send out the same net out the interface in which you
learned it"?
R1:
R 10.0.0.0/8 [120/1] via 172.16.0.2, 00:00:01, Serial0/0
R1 debug ip rip:
Mar 1 00:13:12.691: RIP: build update entries
*Mar 1 00:13:12.691: 10.0.0.0/8 via 0.0.0.0, metric 2, tag 0
*Mar 1 00:13:39.867: RIP: received v2 update from 172.16.0.2 on Serial0/0
*Mar 1 00:13:39.867: 10.0.0.0/8 via 0.0.0.0 in 1 hops
R2:
R 10.0.0.0/8 [120/1] via 172.16.0.1, 00:00:17, Serial0/0
R2 debug ip rip:
*Mar 1 00:13:56.535: RIP: build update entries
*Mar 1 00:13:56.535: 10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
*Mar 1 00:14:05.491: RIP: received v2 update from 172.16.0.1 on Serial0/0
*Mar 1 00:14:05.491: 10.0.0.0/8 via 0.0.0.0 in 1 hops
Any ideas?
Sincerely,
Kim Pedersen
--
// Freedom Matters
// Follow my progress on: http://kpjungle.wordpress.com
Checked by AVG - www.avg.com
Version: 8.5.374 / Virus Database: 270.12.91/2201 - Release Date: 06/25/09
06:22:00
