DMVPN question

Brent Rockburn · ‎10-09-2008

I'm not really sure if this is the right place to ask but here goes.

I'v setup a small 1 hub 2 spoke DMVPN network.

on the spokes however I'm not seeing the routing table populate with the other spokes internal network. When they ping the others internal network there is no "tunnel" created between the two spokes, that is I do a "sh cry isa sa" and the only peer is the hub. Is this what I should be seeing?

Giuseppe Larosa · ‎10-09-2008

Hello Brent,

if you are using EIGRP over the mGRE tunnel you need to configure on hub

int tuxx

no ip eigrp ASN next-hop-self

so that a spoke can see the LAn of other spoke with the original next-hop and this allows to create dynamic spoke to spoke tunnel for lan to lan traffic

Hope to help

Giuseppe

Brent Rockburn · ‎10-09-2008

Yes I've done that. Here is the hub t10 config

interface Tunnel10

ip address 172.30.0.1 255.255.255.0

no ip redirects

ip mtu 1400

no ip next-hop-self eigrp 100

ip nhrp authentication abc123

ip nhrp map multicast dynamic

ip nhrp network-id 200

ip virtual-reassembly

ip tcp adjust-mss 1360

no ip split-horizon eigrp 100

delay 1000

tunnel source FastEthernet4

tunnel mode gre multipoint

tunnel key 7712

tunnel protection ipsec profile NMMHUBDMVPN

Giuseppe Larosa · ‎10-09-2008

Hello Brent,

on spoke1 you should see LAN of spoke2 with nexthop different from 172.30.0.1

Is it so ?

To trigger the dynamic spoke to spoke you need to do an extended ping with source the local lan ip address of spoke1 and destination the local lan ip address of spoke2

Hope to help

Giuseppe

Brent Rockburn · ‎10-09-2008

ok .. so here is the deal

If I put in static routes from spoke1 to spoke2(and vice versa) going out the tunel10 then this seems to work. So it must be a EIGRP thing. I've put in the "no ip next-hop-self eigrp (as)" command and I still need the static routes.

Has anyone seen this before?

Giuseppe Larosa · ‎10-09-2008

Hello Brent,

you may need to use a different IOS image on hub router it looks like something is wrong with EIGRP

Hope to help

Giuseppe

Brent Rockburn · ‎10-09-2008

I removed both static routes on the spokes and now the EIGRP portion seems to be working fine. I've added a 3rd spoke and it has the same problem. Seems that static routes somehow reset the EIGRP? Is there a way to stop and restart eigrp?

Giuseppe Larosa · ‎10-09-2008

Hello Brent,

verify also the state of nhrp because to resolve the private ip address in the MGRE IP subnet the spokes need to ask to the nhrp server (the hub router)

Only after nhrp server answers they can build the dynamic spoke to spoke tunnel.

this is part of config for a spoke

ip nhrp authentication cisco123

ip nhrp map multicast dynamic

ip nhrp map 192.168.1.1 209.168.202.225

ip nhrp map multicast 209.168.202.225

ip nhrp network-id 1

ip nhrp nhs 192.168.1.1

the key commands are

ip nhrp map multicast dynamic

ip nhrp nhs 192.168.1.1

+

ip nhrp map 192.168.1.1 209.168.202.225

to give the spoke the capability to query the nhrp server

To verify NHRP activity do:

r3725#sh ip nhrp traffic

Tunnel91

Sent: Total 1373

1 Resolution Request 0 Resolution Reply 1371 Registration Request

0 Registration Reply 1 Purge Request 0 Purge Reply

0 Error Indication

Rcvd: Total 4

0 Resolution Request 1 Resolution Reply 0 Registration Request

2 Registration Reply 0 Purge Request 1 Purge Reply

0 Error Indication

Tunnel100

Sent: Total 94

0 Resolution Request 12 Resolution Reply 0 Registration Request

82 Registration Reply 0 Purge Request 0 Purge Reply

0 Error Indication

Rcvd: Total 94

12 Resolution Request 0 Resolution Reply 82 Registration Request

0 Registration Reply 0 Purge Request 0 Purge Reply

0 Error Indication

r3725#

Hope to help

Giuseppe

Brent Rockburn · ‎10-09-2008

it was working beautifully for a while so I decided to simulate a spoke with going down. I chose spoke 2

Now I get this

*Oct 9 21:30:49.971: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=66.38.235.1, prot=50, spi=0x965D5160(2522698080), srcaddr=192.168.0.1

*Oct 9 21:31:19.675: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.30.0.20 (Tunnel10) is down: holding time expired

*Oct 9 21:31:47.095: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 172.30.0.20 (Tunnel10) is up: new adjacency

*Oct 9 21:31:50.915: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=66.38.235.1, prot=50, spi=0x965D5160(2522698080), srcaddr=192.168.0.1

*Oct 9 21:32:51.367: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=66.38.235.1, prot=50, spi=0x965D5160(2522698080), srcaddr=192.168.0.1

*Oct 9 21:33:52.115: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=66.38.235.1, prot=50, spi=0xBB68DF69(3144212329), srcaddr=60.0.0.1

*Oct 9 21:34:30.995: %CRYPTO-4-IKMP_NO_SA: IKE message from 60.0.0.1 has no SA and is not an initialization offer

and spoke2 is no longer participating in the DMVPN

Giuseppe Larosa · ‎10-09-2008

Hello Brent,

this becomes an IPSec trouble :

try to clear the spoke2 SA on the hub router

Hope to help

Giuseppe

Brent Rockburn · ‎10-10-2008

Seems to me that EIGRP is being really flaky here ... can someone suggest a better routing protocol for a DMVPN network. This will be distributed to about 400 spoke sites so a flaky routing protocol makes me nervous.

Thanks

Giuseppe Larosa · ‎10-10-2008

Hello Brent,

OSPF is another possible choice that doesn't need tricks about split-horizon and next-hop-self.

I would try with OSPF, or better using iBGP with the hub(s) as BGP route-reflector it should scale to 400 spokes

Hope to help

Giuseppe

Brent Rockburn · ‎10-10-2008

Is there also a command to set so that if spoke1 goes down then spoke2 two will detect that no traffic is passing and will immediately clear its crypto session?

Brent Rockburn · ‎10-10-2008

Fixed this!!

So I just had to add the

Crypto isakmp keepalive seconds 40(i used 40) on-demand

option and now by the time the router creating the traffic comes up the listening spoke has killed the tunnel at his end.

Thanks for all your help!

Giuseppe Larosa · ‎10-10-2008

Hello Brent,

I was missing this part of the problem I had thought a keealive mechanism was needed but I thought only of GRE keepalive but not sure it can be used with multipoint GRE and GRE is carried inside IPSec so cannot be the solution here.

well done !

Best Regards

Giuseppe