cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2543
Views
0
Helpful
7
Replies

DMVPN fast convergence with ebgp and capacity planning

Carlos T
Level 1
Level 1

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.

7 Replies 7

Marcin Latosiewicz
Cisco Employee
Cisco Employee

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.

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.

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.

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.

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.

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.

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: