Re: Frame-Relay, RIP & Split-Horizon

Just for reference....split-horizon disabled on the hub, R1. R1 learns
2.2.2.2/32 from the spoke R2 and sends it directly back out the interface it
came in as we would expect with split-horizon disabled. However, that
particular route never makes it back down to R2, or at least is never shown
in the debug.

HUB -- R1 learns 2.2.2.2/32 from R2 and sends it directly back to R2 out the
same interface it was received on as expected
-------

R1#

*Jul 14 00:06:54.863: RIP: received v2 update from 100.100.100.2 on
Serial0/1/0
*Jul 14 00:06:54.863: 2.2.2.2/32 via 0.0.0.0 in 1 hops
*Jul 14 00:06:54.863: 100.100.100.0/24 via 0.0.0.0 in 1 hops

*Jul 14 00:06:59.643: RIP: sending v2 update to 224.0.0.9 via Serial0/1/0
(100.100.100.1)
*Jul 14 00:06:59.643: RIP: build update entries
*Jul 14 00:06:59.643: 2.2.2.2/32 via 100.100.100.2, metric 2, tag 0
*Jul 14 00:06:59.643: 100.100.100.0/24 via 0.0.0.0, metric 1, tag 0

Spoke -- However, on R2 the 2.2.2.2/32 route "disappeared" ...it does not
show in the incoming RIP update
---------

R2
*Jul 10 05:27:51.135: RIP: received v2 update from 100.100.100.1 on
Serial0/0
*Jul 10 05:27:51.139: 100.100.100.0/24 via 0.0.0.0 in 1 hops
*Jul 10 05:27:51.139: RIP: Update contains 1 routes

What gives? Does R1 in reality NOT send 2.2.2.2/32 back out because it is
smart enough to see it is the same PVC or does R2 magically drop it for some
reason and not make any reference to that in the debugs? What am I missing?

-- 
Regards,
Joe Astorino
CCIE #24347
Blog: http://astorinonetworks.com
"He not busy being born is busy dying" - Dylan
Blogs and organic groups at http://www.ccie.net