Doug,
R4 did not install the new route to 10.0.3.0/24 that it learned from R5 until the previous route from R3 was deleted. See the debugs below. R4# *Mar 2 02:51:55.453: RT: delete subnet route to 10.0.3.0/24 <=== this is the old route from R3 that is being deleted *Mar 2 02:51:55.453: RT: NET-RED 10.0.3.0/24 *Mar 2 02:51:55.853: RIP: received v2 update from 192.168.45.5 on Ethernet1/0 <=== new route received from R5 *Mar 2 02:51:55.853: RT: SET_LAST_RDB for 10.0.3.0/24 NEW rdb: via 192.168.45.5 *Mar 2 02:51:55.857: RT: add 10.0.3.0/24 via 192.168.45.5, rip metric [120/2] <==== metric of 2 Remember, when we are comparing the route learned from R3 with that learned from R5, the R3 metric (4294967295) is the absolute worst compared to that of R5 (2 hops). That R3 metric means the route is not reachable via R3. Once the hold down timer expires, the route is deleted from the routing table, and then the new prefix learned from R5 can be installed. Chuck On 8/30/13 4:24 PM, "Doug Koobs" <[email protected]> wrote: >Chuck, > >Lo2 on R6 was enabled while the route was still in hold down, so it >should not have been used, right? Isn't that the purpose of hold down, to >not allow routes with worse metrics to be installed, thus preventing >loops? > >Does the hold down time apply if the route is coming in from another >source? > >"Chuck Ryan (chryan)" <[email protected]> wrote: > >>Doug, >> >>R4 installed the route to 10.0.3.0/24 via R5 because this network is not >>reachable via R3 anymore. It is reachable via R5 in 2 hops, not 1. See >>the >>advertisement here: >> >>R4# >>*Mar 2 02:51:55.453: RT: delete subnet route to 10.0.3.0/24 >>*Mar 2 02:51:55.453: RT: NET-RED 10.0.3.0/24 >>*Mar 2 02:51:55.853: RIP: received v2 update from 192.168.45.5 on >>Ethernet1/0 >>*Mar 2 02:51:55.853: RT: SET_LAST_RDB for 10.0.3.0/24 >> NEW rdb: via 192.168.45.5 >>*Mar 2 02:51:55.857: RT: add 10.0.3.0/24 via 192.168.45.5, rip metric >>[120/2] <==== metric 120, 2 hops >> >>This is why when both R3 and R6 (Lo2) are up, R4 installs the route known >>via R3 only, and not via R5. The path via R3 is reachable in 1 hop, the >>path via R5 is reachable in 2 hops. R3 has the better path based on lower >>metric (fewer hops). >> >>The holddown timer worked exactly as expected. The extremely high metric >>given by R3 is because the route is no longer reachable, so it doesn't >>want you to forward traffic to that router anymore. That's by design. The >>route will continue to show up with the "show ip route" command until the >>hold down timer expires, at which time, it will be removed completely >>from >>the routing table. The "inaccessible" keyword tells the router that this >>network is no longer reachable via R3, so don't send me any traffic for >>this network. >> >>R4#sh ip route 10.0.3.0 >>Routing entry for 10.0.3.0/24 >> Known via "rip", distance 120, metric 4294967295 (inaccessible) >> Redistributing via rip >> Last update from 192.168.34.3 on Ethernet0/0, 00:03:59 ago >> Hold down timer expires in 124 secs >> >> >> >>When you enabled Lo2 on R6, that's when R4 received an advertisement from >>R5 saying that he could reach the 10.0.3.0/24 network in 1 hop, which is >>much shorter than 4294967295. R4 then installs the route to 10.0.3.0/24 >>with a hop count of 2 (R5, R6), and life is good. >> >> >>Does that help? >> >>Chuck >> >> >>On 8/29/13 5:07 AM, "[email protected]" <[email protected]> wrote: >> >>>I did some experimenting to make sure my understanding of the holddown >>>timer is correct, and evidently it isn't... I thought it's purpose was >>>to >>>prevent a loop from forming when a route isn't updated for 180 seconds >>>(by default) by not accepting updates about the route that have a worse >>>metric. >>> >>>However, I found that when a route goes into holddown, its metric goes >>>to >>>4294967295, so how could there be a worse route? >>> >>>So I set up a small topology to test: >>> >>>Lo1 10.0.3.3 >>> Lo2 10.0.3.6 >>> >>>R3-------------------------R4-----------------------------R5------------ >>>-- >>>-------------R6 >>> 192.168.34.0 192.268.45.0 >>>192.168.56.0 >>> >>>All router are running RIPv2 in all interfaces, timers are default, >>>autosummary disabled, but on R6, Lo2 is shut down. R4 installs a route >>>to >>>10.0.3.0/24 with metric 1 and next-hop of R3: >>> >>>R4#sh ip route >>>... >>>C 192.168.45.0/24 is directly connected, Ethernet1/0 >>>R 192.168.56.0/24 [120/1] via 192.168.45.5, 00:00:02, Ethernet1/0 >>> 10.0.0.0/24 is subnetted, 4 subnets >>>R 10.0.3.0 [120/1] via 192.168.34.3, 00:00:00, Ethernet0/0 >>>R 10.0.6.0 [120/2] via 192.168.45.5, 00:00:02, Ethernet1/0 >>>C 10.0.4.0 is directly connected, Loopback1 >>>R 10.0.5.0 [120/1] via 192.168.45.5, 00:00:02, Ethernet1/0 >>>C 192.168.34.0/24 is directly connected, Ethernet0/0 >>> >>>Now, I enable "passive-interface default" on R3, and wait for the route >>>to go into holddown on R4, which it does in 180 seconds: >>> >>>*Mar 2 02:50:55.437: RT: delete route to 10.0.3.0 via 192.168.34.3, rip >>>metric [120/1] >>>*Mar 2 02:50:55.441: RT: SET_LAST_RDB for 10.0.3.0/24 >>> OLD rdb: via 11.13.11.13 >>>*Mar 2 02:50:55.441: RT: no routes to 10.0.3.0, entering holddown >>>*Mar 2 02:50:55.441: RT: NET-RED 10.0.3.0/24 >>> >>>R4#sh ip route 10.0.3.0 >>>Routing entry for 10.0.3.0/24 >>> Known via "rip", distance 120, metric 4294967295 (inaccessible) >>> Redistributing via rip >>> Last update from 192.168.34.3 on Ethernet0/0, 00:03:13 ago >>> Hold down timer expires in 169 secs >>> >>>Now I bring up Lo2 (10.0.3.6) on R6, which advertises 10.0.3.0.24 to R5. >>>When R5 advertises this route to R4, it does so with a metric of 1, >>>which >>>is worse than the original metric that R3 was advertising.. However, R4 >>>still installs the route, even though it is in holddown: >>> >>>*Mar 2 02:51:45.449: RIP: Update sent via Ethernet1/0 >>>R4#sh ip route 10.0.3.0 >>>Routing entry for 10.0.3.0/24 >>> Known via "rip", distance 120, metric 4294967295 (inaccessible) >>> Redistributing via rip >>> Last update from 192.168.34.3 on Ethernet0/0, 00:03:59 ago >>> Hold down timer expires in 124 secs >>> >>>R4# >>>*Mar 2 02:51:55.453: RT: delete subnet route to 10.0.3.0/24 >>>*Mar 2 02:51:55.453: RT: NET-RED 10.0.3.0/24 >>>*Mar 2 02:51:55.853: RIP: received v2 update from 192.168.45.5 on >>>Ethernet1/0 >>>*Mar 2 02:51:55.853: RT: SET_LAST_RDB for 10.0.3.0/24 >>> NEW rdb: via 192.168.45.5 >>>*Mar 2 02:51:55.857: RT: add 10.0.3.0/24 via 192.168.45.5, rip metric >>>[120/2] >>>*Mar 2 02:51:55.857: RT: NET-RED 10.0.3.0/24 >>>Routing entry for 10.0.3.0/24 >>> Known via "rip", distance 120, metric 2 >>> Redistributing via rip >>> Last update from 192.168.45.5 on Ethernet1/0, 00:00:08 ago >>> Routing Descriptor Blocks: >>> * 192.168.45.5, from 192.168.45.5, 00:00:08 ago, via Ethernet1/0 >>> Route metric is 2, traffic share count is 1 >>> >>> >>>What am I missing here? It seems the holddown didn't do anything... >>> >>>Doug >>>_______________________________________________ >>>For more information regarding industry leading CCIE Lab training, >>>please >>>visit www.ipexpert.com >>> >>>Are you a CCNP or CCIE and looking for a job? Check out >>>www.PlatinumPlacement.com >>> >>>http://onlinestudylist.com/mailman/listinfo/ccie_rs >> _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs
