So lets just cover off one of the great things about distance vector routing protocols like RIP and EIGRP. To prevent loops in routing tables they use something called ‘split horizon’. The basic rule is this, “never pass on a route learned from one interface back through that same interface”. Scott Morris states this in this way “never tell a joke back to the person you just heard it from, it never has the same effect”. Split horizon works great for broadcast networks, but the behavior is not quite so useful in non-broadcast networks like frame relay, lets have a look at a few examples.

Broadcast network

Here is our broadcast network with three routers we’ll have say R1, R2 and R3 (see diagram below). Each router is connected to a switch using interface Fa0/0 sharing subnet Each router is also configured with a loopback interface (Lo0) with an IP address significant to their hostname e.g. R1 is, R2 is and R3 is

Screen shot 2011-06-15 at 00.06.37

Now, each of the routers advertise their connected networks using RIP.

Here is the configuration for R1’s RIP process. You can see we’ve enabled version 2 and disabled auto-summary but it doesn’t matter for the purpose of this demonstration. TIP: the sh run | s rip’ command is us asking the IOS parser to look for the RIP section (s rip) in the configuration.

Screen shot 2011-06-15 at 00.06.07

R1, R2 and R3 each have a copy of the RIP database containing all of the routers. Crucially however none of the routers advertise learnt networks back out of their networks connected to the switch , they only send their directly connected networks. This is because, as the split horizon rule dictates, we are learning the other networks via a broadcast interface so it is un-necessary to send that same learned route back out. If we did that then we would be advertising routers to neighbors which we didn’t have connectivity to.

For example, what if we disabled split horizon on R2. It would advertise connectivity to R3 and R1’s loopback interfaces. Of course those RIP adverts would have a metric (hop count) of one more than the best route but what if the best route was lost? In this case the route advertised from R2 would be the new ‘best route’ and since R2 doesn’t actually have any connectivity to the R1 or R3 loopback interfaces the traffic would get to R2 and be dropped. All of this is possible because of the painfully slow convergence timers in distance vector protocols like RIP. Indeed the dead interval is 3 minutes and the flush timer 4 minutes! Now then, it’s not all bad news. RIP does also have another very clever way of telling all connected RIP hosts on the same broadcast network that something bad has happened and you must flush your RIP tabels immediately (usually because an interface has gone down). This type of ‘triggered update’ is called ‘Poison Reverse’. This ‘poisoning’ of a lost route basically advertises an immediate route update for the lost network with a metric (hop count) of 16 which means ‘inaccessible’ - job done.

Lets see the poison reverse in action here We’ll shut down the loopback0 interface on R1. Our debugs are running on R2. Watch as R1 sends out the update for the lost route to

First;y here is a normal update from R1 - notice it learned it from which is R1’s interface closest to R2.

Screen shot 2011-06-15 at 00.28.56

Now we’ve just shutdown the lo0 interface on R1. It immediately sends out an update telling us that route is dead (hop count 16).

Screen shot 2011-06-15 at 00.29.38

Now we (R2) send an update ourselves, basically passing on the bad news to all other RIPv2 (we send it to which is the multicast address used by RIPv2)

Screen shot 2011-06-15 at 00.29.54

We also ‘hear’ the bad news from R3 who also, like us, passed it on...hey bad news does travel fast even in RIP.

Screen shot 2011-06-15 at 00.30.13

Right, this is all good fun, but what about split-horizon? Well, you know, the best place to see split horizon NOT working well for us is on a frame relay lets do that instead.

Split Horizon on Frame Relay multipoint networks.

Here is the topology. In this example, R1 is the frame relay hub with R2 and R3 as spokes.


The network has been configured using between the two spokes and the hub. We’ve configured RIP on each of the routers and split horizon is enabled on each interface. Lets take a look at the routing table on R1.

Screen shot 2011-06-15 at 00.42.40

OK, this is perfect. We see learned routes for the loopback interfaces of both R2 and R3. Right so now we’ve enabled a routing protocol and we’re injecting the loopback interfaces into RIP then R2 should have routes to R1’s lo0 and R3’s lo0 and R3 should have routes to R1’s lo0 and R2’s lo0 right?

Well lets see. First on R2.

Screen shot 2011-06-15 at 00.46.17

Hmm - well I see R1’s lo0 network but I don’t see R3’s lo0.

What about R3?

Screen shot 2011-06-15 at 00.46.51

OK, so just like R2 I only see R1’s lo0 interface.

Well unless I fix this I won’t be able to ping all of the loopback interfaces. The answer to the problem is easy though. In our example R1 is the hub of a frame relay network. The RIP routes are being learned from R2 and R3 via one interface on R1 (S2/0.123). So, go back to what we know about split horizon. The fact that is that routes are being learned from R2 and R3 and then those routes are not sent back out of that same interface!

This behaviour is not ideal right, luckily however we can override split horizon. We need to disable split-horizon on that serial interface for the hub on R1. Lets do that now.

Screen shot 2011-06-15 at 00.50.10

Now lets take a look at the RIP database on R2 (show ip rip database)

Screen shot 2011-06-15 at 00.50.42

Cool, now I see the lo0 network from R3. Notice that it was learned from R1 though. R1 has passed it on? Of course we’re on a non-broadcast network and R3 and R2 and not directly connected with their own DLCI so R1 is the man in the middle here.

Lets take a look at R3’s routing table

Screen shot 2011-06-15 at 00.52.36

Nice one, we have a network for R2’s lo0 interface.

Thats it for this article on split horizon

Thanks for reading

View Comments
© 2011

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.