06-25-2013 08:17 PM - edited 02-21-2020 06:59 PM
Hi.
In a dual hub/dual dmvpn design, EBGP is running over the GRE DMVPN tunnel (without ipsec/NO encryption). Once the main hub is down, it takes so long for the spokes to detect the primary hub is down (bgp hold down timer) and then converge to the secondary hub.
Apart from the bgp timers tunning, is there any other way to achieve fast convergence? and without overutilizing resources? (memory/cpu).
The hub routers are ASR1001 and there will be ~70 dmvpns, with ~100 spokes per DMVPN.
Thanks,
Carlos.
06-26-2013 05:09 AM
Carlos,
What's the configuration and deployment type on spoke?
In some cases you can use "if-state nhrp" (disabled by default) and "fast-external-fallover" (should be on by default).
However NHRP is also pretty slow to detect a failure (registration messages going every 1/3 of holdtime).
For the rest chnaging timers is the easiest way to detect a failure.
M.
06-26-2013 09:13 PM
Marcin,
I paste the config of one of the spokes. It has only one physical wan interface (attached to a vrf dmvpn, which is the "front vrf", and the global routing table acts as the "inside vrf"
Both tunnels (one to hub1 and the other to hub2) use the same source interface fast 1/0. In the config I added the
"if-state nhrp" command at each tunnel.
R21#show run int tun 178
Building configuration...
Current configuration : 408 bytes
!
interface Tunnel178
ip address 178.178.178.21 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication XXX
ip nhrp map multicast 200.0.0.178
ip nhrp map 178.178.178.1 200.0.0.178
ip nhrp network-id 178
ip nhrp holdtime 10
ip nhrp nhs 178.178.178.1
ip nhrp shortcut
ip tcp adjust-mss 1360
if-state nhrp
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel vrf dmvpn
end
R21#show run int tun 179
Building configuration...
Current configuration : 408 bytes
!
interface Tunnel179
ip address 179.179.179.21 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication XXX
ip nhrp map multicast 201.0.0.178
ip nhrp map 179.179.179.1 201.0.0.178
ip nhrp network-id 179
ip nhrp holdtime 10
ip nhrp nhs 179.179.179.1
ip nhrp shortcut
ip tcp adjust-mss 1360
if-state nhrp
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel vrf dmvpn
end
After I added the command "if-state nhrp" at both tunnels, I saw one of the tunnels changed state from up/up to the up/down state, even when both hub routers (nhs´s) are reachable by the spoke.
the interface change after adding the command is this the correct behavior? I want both tunnels to stay in up/up state when both hubs are reachable by the spoke.
R21#show ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM administratively down down
FastEthernet1/0 172.16.254.3 YES DHCP up up
FastEthernet1/1 unassigned YES NVRAM administratively down down
Loopback0 21.21.21.21 YES manual up up
Tunnel178 178.178.178.21 YES NVRAM up down
Tunnel179 179.179.179.21 YES manual up up
R21#show ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding, W=Waiting
Tunnel178:
178.178.178.1 E priority = 0 cluster = 0 req-sent 600 req-failed 0 repl-recv 0 (01:06:28 ago)
Tunnel179:
179.179.179.1 RE priority = 0 cluster = 0 req-sent 911 req-failed 0 repl-recv 413 (00:00:00 ago)
Thanks,
Carlos.
06-26-2013 09:26 PM
Marcin,
After deleting the command "if-state nhrp" from both tunnels, I see that one of the tunel changes it state to up/up and I can recover reachability to the remote hub.
R21#show ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM administratively down down
FastEthernet1/0 172.16.254.3 YES DHCP up up
FastEthernet1/1 unassigned YES NVRAM administratively down down
Loopback0 21.21.21.21 YES manual up up
Tunnel178 178.178.178.21 YES NVRAM up down
Tunnel179 179.179.179.21 YES manual up up
R21#config t
Enter configuration commands, one per line. End with CNTL/Z.
R21(config)#int tun 178
R21(config-if)#no if
R21(config-if)#no if-state nh
R21(config-if)#no if-state nhrp
R21(config-if)#int tun 179
R21(config-if)#no if-state nhrp
R21(config-if)#
*Jun 27 00:18:06.511: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel178, changed state to up
R21(config-if)#^Z
R21#show ip
*Jun 27 00:18:16.103: %SYS-5-CONFIG_I: Configured from console by console
R21#show ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM administratively down down
FastEthernet1/0 172.16.254.3 YES DHCP up up
FastEthernet1/1 unassigned YES NVRAM administratively down down
Loopback0 21.21.21.21 YES manual up up
Tunnel178 178.178.178.21 YES NVRAM up up
Tunnel179 179.179.179.21 YES manual up up
R21#show ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding, W=Waiting
Tunnel178:
178.178.178.1 E priority = 0 cluster = 0 req-sent 6 req-failed 0 repl-recv 0 (01:11:41 ago)
Tunnel179:
179.179.179.1 RE priority = 0 cluster = 0 req-sent 1020 req-failed 0 repl-recv 522 (00:00:01 ago)
R21#
From the last output of "show ip nhrp nhs detail" I see only peer from tunel 179 is marked as RE: Responding, Expecting replies. Want to know why the peer from tunel 178 is not also in that state?
I can ping both nbma (physical) and virtual (tunnel) ip address of both hubs.
########## Ping to hub 1 nbma (physical) address:
R21#ping vrf dmvpn 200.0.0.178
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.178, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 200/303/436 ms
########## Ping to hub 2 nbma (physical) address:
R21#ping vrf dmvpn 201.0.0.178
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 201.0.0.178, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 144/220/268 ms
########## Ping to hub 1 virtual (tunnel) address:
R21#ping 178.178.178.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 178.178.178.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 164/186/228 ms
########## Ping to hub 2 virtual (tunnel) address:
R21#ping 179.179.179.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 179.179.179.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 228/395/560 ms
R21#
R21#show ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding, W=Waiting
Tunnel178:
178.178.178.1 E priority = 0 cluster = 0 req-sent 74 req-failed 0 repl-recv 0 (01:15:08 ago)
Tunnel179:
179.179.179.1 RE priority = 0 cluster = 0 req-sent 1088 req-failed 0 repl-recv 590 (00:00:02 ago)
R21#
Thanks,
Carlos Trujillo.
06-27-2013 12:15 AM
Carlos,
You'd need to have a look at the NHRP registration process and see if it's being started if not what's going on.
debug nhrp condition interface tunnel 178
debug nhrp pack
debug nhrp ext
debug nhrp err
BTW I'm assuming you're running a decently recent version of IOS. 15.x
M.
06-27-2013 09:17 AM
Hi Marcin,
I made the following test using the debugs you suggested and I obtained the following results:
1. Initially both interfaces tunel 178 and tunel 179 are shutdown. Both are configured with if-state nhrp.
2. I enable (no shut) only the interface tunel 178. from the debug I see that for each nhrp registration request for int tun 178. there is a nhrp registration reply.
*Jun 27 11:45:05.891: NHRP: Send Registration Request via Tunnel178 vrf 0, packet size: 105
*Jun 27 11:45:06.151: NHRP: Receive Registration Reply via Tunnel178 vrf 0, packet size: 125
3. I enable (no shut) interface tunel 179. from the debug I see that nhrp registrarion requests are still sent for int tunel 178, but I stop receiving nhrp registration replies for int tun 178. As there are no replies, the int tunel 178 changes state to up/down.
*Jun 27 11:53:06.139: NHRP: Send Registration Request via Tunnel178 vrf 0, packet size: 105
*Jun 27 11:53:07.107: NHRP: Send Registration Request via Tunnel178 vrf 0, packet size: 105
*Jun 27 11:53:09.031: NHRP: Send Registration Request via Tunnel178 vrf 0, packet size: 105
*Jun 27 11:53:12.895: NHRP: Send Registration Request via Tunnel178 vrf 0, packet size: 105
*Jun 27 11:53:12.903: src: 178.178.178.21, dst: 178.178.178.1
*Jun 27 11:53:12.911: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Jun 27 11:53:12.911: shtl: 4(NSAP), sstl: 0(NSAP)
*Jun 27 11:53:12.915: pktsz: 105 extoff: 52
*Jun 27 11:53:12.919: (M) flags: "unique nat ", reqid: 65552
*Jun 27 11:53:12.919: src NBMA: 172.16.254.2
*Jun 27 11:53:12.923: src protocol: 178.178.178.21, dst protocol: 178.178.178.1
*Jun 27 11:53:12.931: (C-1) code: no error(0)
*Jun 27 11:53:12.931: prefix: 32, mtu: 17916, hd_time: 360
*Jun 27 11:53:12.935: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Jun 27 11:53:12.935: Responder Address Extension(3):
*Jun 27 11:53:12.935: Forward Transit NHS Record Extension(4):
*Jun 27 11:53:12.935: Reverse Transit NHS Record Extension(5):
*Jun 27 11:53:12.935: Authentication Extension(7):
*Jun 27 11:53:
R21#12.935: type:Cleartext(1), data:claro
*Jun 27 11:53:12.935: NAT address Extension(9):
*Jun 27 11:53:12.935: (C-1) code: no error(0)
*Jun 27 11:53:12.935: prefix: 32, mtu: 17916, hd_time: 0
*Jun 27 11:53:12.935: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0
*Jun 27 11:53:12.935: client NBMA: 200.0.0.178
*Jun 27 11:53:12.935: client protocol: 178.178.178.1
R21#
*Jun 27 11:53:16.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel178, changed state to down
R21#
R21#show ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM administratively down down
FastEthernet1/0 172.16.254.2 YES DHCP up up
FastEthernet1/1 unassigned YES NVRAM administratively down down
Tunnel178 178.178.178.21 YES NVRAM up down
Tunnel179 179.179.179.21 YES NVRAM up up
R21#show ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding, W=Waiting
Tunnel178:
178.178.178.1 E priority = 0 cluster = 0 req-sent 12 req-failed 0 repl-recv 7 (00:02:27 ago)
Tunnel179:
179.179.179.1 RE priority = 0 cluster = 0 req-sent 1 req-failed 0 repl-recv 1 (00:00:56 ago)
My question is, using my config, should I expect to receive reply for both tunnels?
After live deployment, Im first testing using dynamips using the following version:
R21#show ver
Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 15.2(4)M3, RELEASE SOFTWARE (fc2)
Thanks,
Carlos.
06-27-2013 09:35 AM
Also,
At the hub router of tunel 178, I see it is receiving nhrp regist request and sending back replyes. Seems that in transit this reply is lost... Any idea why? how to continue troubleshoot?
R1#
*Jun 27 12:32:02.415: NHRP: Receive Registration Request via Tunnel178 vrf 1, packet size: 105
*Jun 27 12:32:02.419: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Jun 27 12:32:02.423: shtl: 4(NSAP), sstl: 0(NSAP)
*Jun 27 12:32:02.427: pktsz: 105 extoff: 52
*Jun 27 12:32:02.427: (M) flags: "unique nat ", reqid: 65552
*Jun 27 12:32:02.431: src NBMA: 172.16.254.2
*Jun 27 12:32:02.435: src protocol: 178.178.178.21, dst protocol: 178.178.178.1
*Jun 27 12:32:02.443: (C-1) code: no error(0)
*Jun 27 12:32:02.443: prefix: 32, mtu: 17916, hd_time: 360
*Jun 27 12:32:02.447: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Jun 27 12:32:02.451: Responder Address Extension(3):
*Jun 27 12:32:02.451: Forward Transit NHS Record Extension(4):
*Jun 27 12:32:02.455: Reverse Transit NHS Record Extension(5):
*Jun 27 12:32:02.455: Authentication Extension(7):
*Jun 27 12:32:02.459: type:Cleartext(1), data:claro
*Jun 27 12:32:02
R1#
R1#
R1#.463: NAT address Extension(9):
*Jun 27 12:32:02.463: (C-1) code: no error(0)
*Jun 27 12:32:02.467: prefix: 32, mtu: 17916, hd_time: 0
*Jun 27 12:32:02.467: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0
*Jun 27 12:32:02.471: client NBMA: 200.0.0.178
*Jun 27 12:32:02.475: client protocol: 178.178.178.1
*Jun 27 12:32:02.487: NHRP: Send Registration Reply via Tunnel178 vrf 1, packet size: 125
*Jun 27 12:32:02.491: src: 178.178.178.1, dst: 178.178.178.21
*Jun 27 12:32:02.499: (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
*Jun 27 12:32:02.503: shtl: 4(NSAP), sstl: 0(NSAP)
*Jun 27 12:32:02.503: pktsz: 125 extoff: 52
*Jun 27 12:32:02.507: (M) flags: "unique nat ", reqid: 65552
*Jun 27 12:32:02.507: src NBMA: 172.16.254.2
*Jun 27 12:32:02.511: src protocol: 178.178.178.21, dst protocol: 178.178.178.1
*Jun 27 12:32:02.519: (C-1) code: no error(0)
*Jun 27 12:32:02.523: prefix: 32, mtu: 17916, hd_ti
R1#me: 360
*Jun 27 12:32:02.523: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Jun 27 12:32:02.523: Responder Address Extension(3):
Thanks,
Carlos.
06-29-2013 02:58 AM
Carlos,
Hub is sending reply while spoke is not reciving it.
You'd need to check what's going on there. Since you're not using encryption, you can use EPM to check if those packets are being sent out the right interface.
I don't remember whether it's going to be CEF path or not.
M.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide