Matteo Malvica
As a first post, I would like to explain the behaviour of RIP on top of a DMVPN hub and spoke failover topology. Fore more information about DMVPN check Jeremy Stretch’s brilliant post** here**
R5 is our DMVPN hub and R2 and R3 are our two spokes.
R5#<strong>show dmvpn</strong> Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete N - NATed, L - Local, X - No Socket # Ent --> Number of NHRP entries with same NBMA peer NHS Status: E --> Expecting Replies, R --> Responding UpDn Time --> Up or Down Time for a Tunnel ========================================================================== Interface: Tunnel0, IPv4 NHRP Details Type:Hub, NHRP Peers:2, # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb ----- --------------- --------------- ----- -------- ----- 1 10.1.21.2 192.168.1.2 UP 02:44:39 D 1 10.1.13.3 192.168.1.3 UP 08:05:47 D
R2 acts as primary link for the common subnet shared with R3, which is 9.9.9.9/32 (for sake simplicity I’ve used the same Loopback0/address on both R2 and R3) To avoid load balancing of the 9.9.9.9 route on R5, the cost of that network has been increased through an offset-list on R3.
From hub router (R5) we can check 9.9.9.9 coming from our primary link 192.168.1.2 (R2)
R5#<strong>show ip route</strong> Gateway of last resort is 10.1.15.1 to network 0.0.0.0 S* 0.0.0.0/0 [1/0] via 10.1.15.1 9.0.0.0/32 is subnetted, 1 subnets R 9.9.9.9 [120/1] via 192.168.1.2, 00:00:20, Tunnel0 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.1.15.0/24 is directly connected, Serial1/0 L 10.1.15.5/32 is directly connected, Serial1/0 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.1.0/24 is directly connected, Tunnel0 L 192.168.1.5/32 is directly connected, Tunnel0 R5#<strong>show ip rip database</strong> 9.0.0.0/8 auto-summary 9.9.9.9/32 [1] via 192.168.1.2, 00:00:09, Tunnel0 192.168.1.0/24 auto-summary 192.168.1.0/24 directly connected, Tunnel0 We activate some debugs to check what's going on. R5#<strong>debug ip routing</strong> R5#<strong>debug ip rip</strong> events R5#<strong>debug ip rip database</strong>
And then after turning off the tunnel on the primary spoke - R2 - we can see from R5
R5#<strong>show ip rip database 9.9.9.9 255.255.255.255</strong> 9.9.9.9/32 [1] via 192.168.1.2, 00:01:01, Tunnel0
R5 still thinking that best route is from primary CPE
07:16:03: RIP: received v2 update from 192.168.1.3 on Tunnel0 07:16:03: RT: updating rip 9.9.9.9/32 (0x0) via 192.168.1.3 Tu0 07:16:03: RT: rib update return code: 19 07:16:03: RIP: Update contains 1 routes <strong>[the error code #19 on RT debug means that it will not be installed]</strong>
Until INVALID TIMER expires and then enters HOLD-DOWN
07:16:22: RIP-DB: invalidated route of 9.9.9.9/32 via 192.168.1.2 07:16:22: RT: delete route to 9.9.9.9 via 192.168.1.2, rip metric [120/1] 07:16:22: RT: no routes to 9.9.9.9, entering holddown 07:16:22: RIP-DB: Remove 9.9.9.9/32, (metric 4294967295) via 192.168.1.2, Tunnel0
Waiting for HOLD DOWN expires, that will take normally 180” but now will be anticipated by FLUSH TIMER after 60”
R5#show ip rip database 9.9.9.9 255.255.255.255
9.9.9.9/32 is possibly down 07:17:22: RIP: Update contains 1 routes 07:17:22: RIP: Update queued 07:17:22: RIP: Update sent via Tunnel0 07:17:22: RIP-DB: garbage collect 9.0.0.0/8 07:17:22: RIP-DB: garbage collect 9.9.9.9/32 07:17:22: RT: delete subnet route to 9.9.9.9/32 07:17:24: RIP: received v2 update from 192.168.1.3 on Tunnel0 07:17:24: RT: updating rip 9.9.9.9/32 (0x0) via 192.168.1.3 Tu0 07:17:24: RT: add 9.9.9.9/32 via 192.168.1.3, rip metric [120/6] 07:17:24: RIP-DB: network_update with 9.9.9.9/32 succeeds 07:17:24: RIP-DB: adding 9.9.9.9/32 (metric 6) via 192.168.1.3 on Tunnel0 to RIP database 07:17:24: RIP-DB: add 9.9.9.9/32 (metric 6) via 192.168.1.3 on Tunnel0 07:17:24: RIP-DB: Adding new rndb entry 9.9.9.9/32 07:17:24: RIP-DB: Created rip ndb summary entry for 9.0.0.0/8 07:17:24: RIP-DB: Adding new rndb entry 9.0.0.0/8 R5#<strong>show ip route</strong> Gateway of last resort is 10.1.15.1 to network 0.0.0.0 S* 0.0.0.0/0 [1/0] via 10.1.15.1 9.0.0.0/32 is subnetted, 1 subnets R 9.9.9.9 [120/6] via 192.168.1.3, 00:00:23, Tunnel0 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.1.15.0/24 is directly connected, Serial1/0 L 10.1.15.5/32 is directly connected, Serial1/0 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.1.0/24 is directly connected, Tunnel0 L 192.168.1.5/32 is directly connected, Tunnel0
Just to recap RIP timers: in order to install a backup route we shall wait since last update: INVALID TIMER (180”) + HOLD DOWN TIMER (180”). Please note that since the FLUSH TIMER starts at the same time as INVALID TIMER and least 240”, it will force HOLD DOWN TIMER to stop after 60”. If we now bring up the primary link the hub then install the best route due to lower hop-count.
07:33:02: RIP: received v2 update from 192.168.1.2 on Tunnel0 07:33:02: 9.9.9.9/32 via 0.0.0.0 in 1 hops 07:33:02: RT: updating rip 9.9.9.9/32 (0x0) via 192.168.1.2 Tu0 R5#show ip route Gateway of last resort is 10.1.15.1 to network 0.0.0.0 S* 0.0.0.0/0 [1/0] via 10.1.15.1 9.0.0.0/32 is subnetted, 1 subnets R 9.9.9.9 [120/1] via 192.168.1.2, 00:00:12, Tunnel0 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.1.15.0/24 is directly connected, Serial1/0 L 10.1.15.5/32 is directly connected, Serial1/0 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.1.0/24 is directly connected, Tunnel0 L 192.168.1.5/32 is directly connected, Tunnel0 <span style="font-family: sans-serif; font-size: 1.1em; font-weight: bold; line-height: 1.4;"> Conclusions:</span>
This fallback DMPVN design takes 240” seconds to converge and that is really too much for a production environment. It is therefore recommended to tune RIP timers within_** router rip**_ configuration mode:
R5(config-router)#<b>timers basic</b> <i>update invalid holddown flush</i>