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
