introduction
Dynamic routing protocols exchange routing information before populating routing tables and forwarding packets. For this task, RIP (routing information protocol) put into play many machanisms and rules to guarantee that this routing information exchange is consistent: not contradictory among routers. An example of such inconsistency is to receive the same routing information on two different router interface… the router is unable to resolve the next hop for traffic matching this route to only one interface!
split-horizon to prevent routing loops
One of those mechanism that RIP put into play is Split-Horizon rule. Per the split-horizon rule, RIP routers don’t send an update back on the interface it was received on. We’re talking about routing information and not the data packet itself.
What is the challenge here? In addition to enhancing bandwidth usage and system resources consumption, Split horizon helps prevent routing loops… let’s focus on how split-horizon helps prevent routing loops;
In this kind of loop the routing information is lost, incoherent between the domain routers. The routers are unable to encode the next hop for received packets (matching this route) due to routing table information frequent changes, lack or errors. The problem is even more impacting if other features depend on route lookup… because of the lack of this information, CPU is engaged to handle packets in an exception mode which may complicate things even more.
lab setup to experiment split horizon operation
In this lab, we create a RIP loop and show how split horizon could help fix it
Our network is a two routers network: R1 and R2. R1 is configured with 2 static routes and 2 loopback connected routes.
We limit RIP updates to only fa0/0 of both routers in the lab topology
R1 receives 2.2.2.2/32 network information from R2
And sends information it has in its rip table to R2
The split horizon rule prevents R1 from sending back the 2.2.2.2/32 (R2 lo0’s attached subnet) to R2
Let’s deactivate this rule at the interface level
We check that now R1 sends even the R2 updates back to R2
How R2 processes 2.2.2.2/32 route it receives from R1?
An “debug ip rip” on R2 does not show the update (R2 loopback routing information) being sent by R1
On the wire (using wireshark or any utility capable of capturing packets on the wire) R1 sends effectively 2.2.2.2/32 udpate with a metric of 2 and a next hop of 12.0.0.2
The other fact is that 2.2.2.2/32 at R2, is already present in the rip routing database and marked as connected
What happens first? Next hop check (R2 drops the routing information because it sees its IP address in it) or rip routing database entry arbitration (the route received by R2 is less preferred due to administrative distance of cost than the one already connected)?
A validation check by R2 on this update would reveal that the next hop is itself and may reject it…
Let’s try to change the rip route next hop at R1
Using summarization, we change the update next hop information
Now R2 receives a new version of this route without the nexthop itself
The metric is set to 2 hops
The debug shows now that the route is not being accepted in the table because of code 17
“Rib udpate return code 17” stands of better administrative distance route being processed
Connected routes are of better administrative distance (lowest) and thus more preferred than rip routes
Instead of a connected loopback to represent the 2.2.2.2/32 lets use an attached route to fa0/0
Similarlily to R1, let’s disable split horizon on R2 fa0/0 for this update to be included in the R2 udpate sending
AT R2, we first delete the static route
In addition we change this static route administrative distance to whatever value that is greather than 120
In our case 121
The route is added with the new admin distance to the routing table
Then R2 receives the same route from R1 with a better administrative distance
It installs the new route and flushes the other one (the local static route)
Next R2 update the route that is poisoned now
The route enter the holdown state because all path was deleted
Next the static route is being updated and added to the routing table
The route is sent to R1
And received back with better admin distance
And the same scenario repeats again and again causing a loop: route enters and get flushed from routing table repeatedly in a loop.
But why the metric get poisoned?
R2 seeing the better route admin distance deletes the udpate ( from its local static routing ) in its routing table and poison it
R1 receives (back) this better admin distance update that was poisoned
It poisons also its local update which lead R1 advertised route, to be flushed at R2
From R1 perspective
R1 receives 2.2.2.2/32 route from R2 and sends back its summary
Short time after, it receives a flash update with the route marked as inaccessible (more than 16 hops away)
And the cycle repeats after the reception of the new update
RIP will loop indefinately…
As conclusion,
To achieve this loop we’ve deactivated the split horizon rule, changed the update next hop so that R2 accept it, and the admin distance of the static route. In another condition, in a more complex network there would be no need to change the next hop of admin distance because routes are also learnt dynamically (not static or connected). The idea was to show that split horizon rule is working using CLI commands (show and debug) and on-wire packets capture.
