Lab setup to experiment split horizon operation
In this lab, we create a RIP loop and show how split horizon could help fix it
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…
