Thumbnail: logo

RIP convergence within DMVPN

by on under blog

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>


© 2018 Matteo Malvica. Illustrations by Sergio Kalisiak.