Problem setting up DMVPN in Dynamips

Unanswered Question
Sep 25th, 2008

Hi, I'm trying to set up single cloud DMVPN in Dynamips but having some really frustrating issues. I could set up dual cloud without any problems. Here's some background info:

Head End Routers:

- Dual head end, connected on LAN segment

- Running EIGRP on the LAN segment

- WAN connected to MPLS PE

- mGRE tunnel source is the PE-CE link

- BGP with MPLS PE (only advertising PE-CE link, to allow tunnels to be established)

- Tunnel protection enabled for the mGRE

Spoke:

- Two spokes, no direct connection

- WAN connected to MPLS PE

- Tunnel source is the PE-CE link

- BGP with MPLS PE (only advertising PE-CE link, to allow tunnels to be established)

- Tunnel protection enabled

Now, I tried both p2p GRE and mGRE on the spokes, both results are the same: connectivity to Head End router 1 OK, to Head End router 2 OK. But Head End 1 to Head End 2... Not OK. Is this normal?

Here're snippets of the tunnel interface configs:

Common crypto config on both Head End routers:

crypto isakmp policy 10

encr 3des

authentication pre-share

crypto isakmp key bigsecret address 192.168.200.10

crypto isakmp key bigsecret2 address 192.168.200.14

crypto ipsec transform-set vpn-test esp-3des esp-sha-hmac

crypto ipsec profile DMVPN1

set transform-set vpn-test

Head End 1:

interface Tunnel10

ip address 10.1.1.1 255.255.255.240

ip mtu 1400

ip nhrp authentication password

ip nhrp network-id 12345

ip nhrp holdtime 60

ip nhrp nhs 10.1.1.2

tunnel source 192.168.200.2

tunnel mode gre multipoint

tunnel key 12345

tunnel protection ipsec profile DMVPN1

Head End 2:

interface Tunnel10

ip address 10.1.1.2 255.255.255.240

ip mtu 1400

ip nhrp authentication password

ip nhrp network-id 12345

ip nhrp holdtime 60

ip nhrp nhs 10.1.1.1

tunnel source 192.168.200.6

tunnel mode gre multipoint

tunnel key 12345

tunnel protection ipsec profile DMVPN1

Spoke 1:

crypto isakmp policy 10

encr 3des

authentication pre-share

crypto isakmp key bigsecret address 192.168.200.2

crypto isakmp key bigsecret address 192.168.200.6

interface Tunnel10

ip address 10.1.1.3 255.255.255.240

ip mtu 1400

ip nhrp authentication password

ip nhrp network-id 12345

ip nhrp holdtime 60

ip nhrp nhs 10.1.1.1

ip nhrp nhs 10.1.1.2

tunnel source 192.168.200.10

tunnel mode gre multipoint

tunnel key 12345

tunnel protection ipsec profile DMVPN1

Spoke 2:

crypto isakmp.... same as above

crypto isakmp key bigsecret2 address 192.168.200.2

crypto isakmp key bigsecret2 address 192.168.200.6

interface Tunnel10

ip address 10.1.1.4 255.255.255.240

ip mtu 1400

ip nhrp authentication password

ip nhrp network-id 12345

ip nhrp holdtime 60

ip nhrp nhs 10.1.1.1

ip nhrp nhs 10.1.1.2

tunnel source 192.168.200.14

tunnel mode gre multipoint

tunnel key 12345

tunnel protection ipsec profile DMVPN1

Thanks muchly in advance for any advice.

Cheers

Michael

Edit: forgot to mention that I also added two "ip nhrp map" commands on the Spoke routers. One for each Head End.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
smahbub Wed, 10/01/2008 - 14:28

In a single DMVPN cloud topology, there are two headend routers on the same DMVPN subnet. Therefore, the branch router requires an mGRE interface. Because of this mGRE interface, branch routers attempt inter-branch communications if so directed by the routing table. As a result, this model should be considered a spoke-to-spoke topology. The hub-and-spoke deployment model can be configured in a single DMVPN cloud topology with only one headend router. This scenario is not tested or recommended because there is no failover mechanism for the headend router.

michaelchoo Wed, 10/01/2008 - 15:28

Thanks for your reply. I'm quite aware of what the SRND said, which you have quoted very nicely above. :P

Having said that, the set up that I need to do is multiple spoke-to-spoke clouds.

Anyway, I have actually solved my own issue. As it turns out, an NHRP Map command on each hub router is all I need to get the two hubs "talking" to each other. It's all good now. :)

Actions

This Discussion