Is it sufficient split-horizon rule to prevent RIP loops?

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

atlink'admin

Learn More →

Leave a Reply

Translate »