According to the Cisco CLI documentation, the rip holddown interval is
Interval (in seconds) during which routing information regarding better paths is suppressed. A route enters into a holddown state when an update packet is received that indicates the route is unreachable. When the holddown expires, routes advertised by other sources are accepted.
However, I see that it accepts the new route immediately after receiving the metric 16 route and starts advertising it. Holddown behaves properly in case a route times out. Then it does not accept any new routes till the holddown interval is over. The
observed and documented behaviour are contradictory. Am I missing something in the configuration that I should set in order to change the behaviour.
When learning about a failed route, the router ignores any new information about that subnet for a period equal to the holddown timer. Once the timer expires new routes are accepted. An update with a hop count higher than the metric recorded in the routing table will also cause the route to go into hold down for 180 seconds.
Since the router is advertising the routes immediately, please check if the flush timer is configured correctly . If not it could lead to routes being accepted before the holddown timer expires.
The flush interval is measured from the last update received for the route. The interval should be longer than the larger of the invalid and holddown values. If the interval is less than the sum of the update and holddown values, the proper holddown interval cannot elapse, which results in a new route being accepted before the holddown interval expires. The default is 240 seconds
It seems to me that you have poison reverse happening. Poison reverse extends the hop count to 16 because the maximum hops rip will take is 15. Making it unusable...until it receives an update with a better metric.
I'm not sure if you are creating a valid route, after creating a bad one, but the router that has thus blocked the route won't update? Don't forget, if split horizon is in effect, the router will not listen from the direction which it sends the updates. You may need to turn the split horizon off by;
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...