Per the split-horizon rule, don’t send an update back on the interface it was received on
What is the challenge here? In addition to bandwidth usage and system resources consumption, Split horizon helps prevent routing loops…
In this kind of loop the routing information is lost, incoherent between the domain routers
In this lab, we create a RIP loop and show how split horizon could help fix it
We limit RIP updated to only fa0/0 of both routers in the previous 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
Now R1 sends even the R2 updates back to R2
How R2 processes 2.2.2.2/32 route it receives from R1
The R2 “debug ip rip” does not show the update being sent by R1
On the wire R1 sends 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 (connected)
What happens first? Next hop check or rip routing database entry arbitration?
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 bette administrative distance 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 were deleted
Next the static route is being updated and added to the routing table
The route is sent to R1
And received back as a better admin distance
And the same scenario repeats again and again
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 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
And the cycle repeats after the reception of the new update
RIP will loop indefinately…
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