Frame Relay and Split Horizon question

[Craddockc]

Community,

I am currently studying for the CCNP ROUTE exam and am labbing up Frame Relay and RIPv2 in GNS3. I am noticing something interesting in my lab. I have 3 routers connected to a FR switch in the middle. The hub router is using a physical multipoint interface, so Split Horizon is disabled. The spoke routers are using multipoint subinterfaces, so split horizon is enabled. The spoke routers do not have any DLCI mapping to eachother on the FR switch so all communications have to go thru the Hub router.

The issue I am noticing is that when the spoke routers send RIPv2 updates to the Hub, the hub is accepting the updates and entering the subnets into its RT.

*Sep 5 21:16:06.238: RIP: received v2 update from 199.0.0.2 on Serial1/0
*Sep 5 21:16:06.238: 192.168.1.0/24 via 0.0.0.0 in 1 hops

*Sep 5 21:16:19.880: RIP: received v2 update from 199.0.0.3 on Serial1/0
*Sep 5 21:16:19.880: 172.16.1.0/24 via 0.0.0.0 in 1 hops

With SH disabled on this interface, the Hub router is attempting to advertise the routes it learned back to the routers from which it learned them (this is expected with SH being disabled).

Sep 5 21:27:05.940: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (199.0.0.1)
*Sep 5 21:27:05.940: RIP: build update entries
*Sep 5 21:27:05.940: 10.10.10.0/24 via 0.0.0.0, metric 1, tag 0
*Sep 5 21:27:05.940: 172.16.1.0/24 via 199.0.0.3, metric 2, tag 0
*Sep 5 21:27:05.940: 192.168.1.0/24 via 199.0.0.2, metric 2, tag 0
*Sep 5 21:27:05.940: 199.0.0.0/29 via 0.0.0.0, metric 1, tag 0

However, when the hub routers who do have SH enabled receive the RIPv2 update from the hub, they are NOT seeing or otherwise acknowledging their own subnets advertised back to them from the Hub:

This router is not seeing or processing 192.168.1.0/24 from the advertisement from the Hub:

Sep 5 21:27:05.965: RIP: received v2 update from 199.0.0.1 on Serial1/0.1
*Sep 5 21:27:05.965: 10.10.10.0/24 via 0.0.0.0 in 1 hops
*Sep 5 21:27:05.965: 172.16.1.0/24 via 199.0.0.3 in 2 hops
*Sep 5 21:27:05.965: 199.0.0.0/29 via 0.0.0.0 in 1 hops

This router is not seeing or acknowledging 172.16.1.0/24 from the advertisement from the Hub:

*Sep 5 21:27:05.964: RIP: received v2 update from 199.0.0.1 on Serial1/0.1
*Sep 5 21:27:05.964: 10.10.10.0/24 via 0.0.0.0 in 1 hops
*Sep 5 21:27:05.964: 192.168.1.0/24 via 199.0.0.2 in 2 hops
*Sep 5 21:27:05.964: 199.0.0.0/29 via 0.0.0.0 in 1 hops

Is Split Horizon responsible for this phenomenon? In reading about Split horizon, I am only reading about how SH prevents a route from being advertised on the interface from which it was learned, but I have never seen any literature state the SH would PREVENT the router from processing or acknowledging route entries that the router itself owns. 

Any help on this would be greatly appreciated! Thanks. 

[Giuseppe Larosa · Accepted solution]

Hello Craddockc,

the split horizon needs to be disabled on the hub to allow it to propagate routes learned from Spoke1 to Spoke2 and viceversa.

However, Frame Relay is not capable of multicast so actually the Hub prepares a different copy of the update for each DLCI and in this way can send to each spoke only the routes not learned over that DLCI.

The debug tells you only the L3 info but it is not the whole story

Sep 5 21:27:05.940: RIP: sending v2 update to 224.0.0.9 via Serial1/0 (199.0.0.1)
*Sep 5 21:27:05.940: RIP: build update entries
*Sep 5 21:27:05.940: 10.10.10.0/24 via 0.0.0.0, metric 1, tag 0
*Sep 5 21:27:05.940: 172.16.1.0/24 via 199.0.0.3, metric 2, tag 0
*Sep 5 21:27:05.940: 192.168.1.0/24 via 199.0.0.2, metric 2, tag 0
*Sep 5 21:27:05.940: 199.0.0.0/29 via 0.0.0.0, metric 1, tag 0

with

*Sep 5 21:16:06.238: RIP: received v2 update from 199.0.0.2 on Serial1/0
*Sep 5 21:16:06.238: 192.168.1.0/24 via 0.0.0.0 in 1 hops

*Sep 5 21:16:19.880: RIP: received v2 update from 199.0.0.3 on Serial1/0
*Sep 5 21:16:19.880: 172.16.1.0/24 via 0.0.0.0 in 1 hops

Another possible explanation is that device with IP address 199.0.0.3 does not accept a route with next-hop 199.0.0.3 so it is silently discarded.

The via above when not 0.0.0.0 are third party next-hop in RIP terms.

This is caused by the NBMA nature of Frame Relay.

note:

if you want to enable spoke to spoke ping on the FR you need an additional frame-relay map statement pointing to the DLCI to the hub without the broadcast keyword.

Example:

frame-relay map ip 199.0.0.1 100 broadcast

frame-relay map ip 199.0.0.2 100

The broadcast keyword allows to map broadcast and multicast to a DLCI, but this requires replication of the packet over each DLCI.

The end result is that each spoke does not receive its own routes back either because the third party next-hop is the same as the receiving interface or because the hub router in preparing the copy for Spoke1 can remove the routes learned on the same DLCI.

Hope to help

Giuseppe

[Craddockc]

Giuseppe,

Thanks so much for your detailed response: I was considering the following and I think youre right:

"Another possible explanation is that device with IP address 199.0.0.3 does not accept a route with next-hop 199.0.0.3 so it is silently discarded."

Since this route is in fact owned by the same router, even though the Hub router is sending it back to it (due to SH being disabled), the router refuses to accept it because its already a directly connected route. It makes little sense for a router to accept a route it already owns or is directly connected to. It appears the debug is the result of the router already making this decision behind the scenes. Interesting stuff!

Thanks!