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

DMVPN routing issues

kradjesh13
Level 1
Level 1

Hi,

I have came across some routing issues while testing DMVPN in a test environment. I have used a HUB and two spoke routers and using EIGRP as the routing protocol. Tunnels are farming and can see the IP gets advertised from end to end and can ping without issues.

My problem is, eventhough the spoke routes forms a direct tunnel with other spoke using NHRP, but still the traffic is passing via hub. No EIGRP neighbour relationship is formed between spoke routers. From spoke router, when I checked the routing table it shows the next hop as the hub to reach other spoke.

I look forward to get some further info from you guys and thanks in advance.

Regards

Rajesh

1 Accepted Solution

Accepted Solutions

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Rajesh,

what you see is normal it derives from the distance vector nature of the EIGRP protocol.

You need an additional command on the hub router so that the spoke1 sees the spoke2's remote LAN subnet with a next hop pointing to spoke2.

Under the correct interface on the hub router use the following:

no ip next-hop-self eigrp

see:

http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_eig1.html#wp1013026

Best Regards

hope to help

Giuseppe

View solution in original post

7 Replies 7

stephen.stack
Level 4
Level 4

HI Rajesh,

Can you post a copy of your config. How did you configure the DMVPN, SDM or CLI?

Can you only post the Tunnel interfaces on both the HUB and spokes and perhaps the EIGRP config on each also.

Thanks

Stephen

========================== http://www.rconfig.com A free, open source network device configuration management tool, customizable to your needs! - Always vote on an answer if you found it helpful

Thanks for the reply Stephan. Here is my configs.

Hub Router

~~~~~~~~~~

crypto isakmp policy 1

authentication pre-share

crypto isakmp key cisco47 address 0.0.0.0 0.0.0.0

!

!

crypto ipsec transform-set trans2 esp-des esp-md5-hmac

!

crypto ipsec profile vpnprof

set transform-set trans2

!

interface Tunnel0

bandwidth 1000

ip address 10.10.10.254 255.255.255.0

no ip redirects

ip mtu 1416

ip nhrp authentication cisco123

ip nhrp map multicast dynamic

ip nhrp network-id 99

ip nhrp holdtime 300

no ip split-horizon eigrp 1

delay 1000

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel key 100000

tunnel protection ipsec profile vpnprof

!

interface Loopback0

ip address 192.168.1.1 255.255.255.0

!

interface FastEthernet0/0

ip address 172.17.0.254 255.255.255.0

!

router eigrp 1

network 10.10.10.0 0.0.0.255

network 192.168.1.0

no auto-summary

!

Spoke Router

~~~~~~~~~~~~

crypto isakmp policy 1

authentication pre-share

crypto isakmp key cisco47 address 172.17.0.254

!

!

crypto ipsec transform-set trans2 esp-des esp-md5-hmac

!

crypto ipsec profile vpnprof

set transform-set trans2

!

!

interface Tunnel0

bandwidth 1000

ip address 10.10.10.1 255.255.255.0

no ip redirects

ip mtu 1416

ip nhrp authentication cisco123

ip nhrp map multicast dynamic

ip nhrp map multicast 172.17.0.254

ip nhrp map 10.10.10.254 172.17.0.254

ip nhrp network-id 1

ip nhrp holdtime 300

ip nhrp nhs 10.10.10.254

no ip split-horizon eigrp 1

delay 1000

tunnel source FastEthernet0/0

tunnel mode gre multipoint

tunnel key 100000

tunnel protection ipsec profile vpnprof

!

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0

ip address 172.17.0.1 255.255.255.0

!

router eigrp 1

network 1.1.1.1 0.0.0.0

network 10.10.10.0 0.0.0.255

no auto-summary

!

Hi,

Thanks for those. I will look at the Configs in a little more detail a bit later on. But one thing that strikes me is the subnets behind both routers. They are both 172.17.0.x. This is not for good routing. Or DMVON for that matter. Also i see eigrp is not configured to even advertise the subnets on the fastethernet interface. i.e.

network 172.17.0.0 0.0.0.255

Ok, so let's try this for a start.

1. reconfigure spoke1 so that the subnet on Fa0/0 is 172.18.0.x/24.

2. rebuild the dmvpm using SDM and make sure this subnet is advertised in EIGRP.

3. Build on the second spoke with a different subnet again i.e. 172.19.0.x/24 and build up the DMVPN form SDM again.

Try this. I will look at the NHRP commands later and give a definite answer as to why this config is not working.

Thanks

Stephen

========================== http://www.rconfig.com A free, open source network device configuration management tool, customizable to your needs! - Always vote on an answer if you found it helpful

Thanks Stephen, correct me if I am wrong. My understanding is the 172.17.0.0 is a WAN IP and in the real scenario it will be a public IP. I have difficulty in understanding why you are asking to redistribute a Public IP within EIGRP. All I am doing is redistributing the private IP within EIGRP routing table after forming a tunnel with the head end router.

Thanks

Rajesh

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Rajesh,

what you see is normal it derives from the distance vector nature of the EIGRP protocol.

You need an additional command on the hub router so that the spoke1 sees the spoke2's remote LAN subnet with a next hop pointing to spoke2.

Under the correct interface on the hub router use the following:

no ip next-hop-self eigrp

see:

http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_eig1.html#wp1013026

Best Regards

hope to help

Giuseppe

Thanks Giuseppe,

After using the above said command the routes are pointing directly to the spokes. When i did a trace from a spoke, the next hop is the other spoke which is fine.

One more thing which i want to know, i thought there is a neighbour relationship between spoke to spoke, but its not happening. Can any one tell me why ??

Thanks

Hello,

there isn't a direct communication between spokes because DMVPN emulates an hub and spokes topology.

the spoke to hub tunnel is always up and so the routing protocol follows this path to keep up the neighborship.

Spoke to spoke tunnel is setup dynamically when a traffic flow is present.

The NHRP protocol is used because there isn't a direct communication between spokes there is an emulation of a flat subnet but in reality a spoke asks to the nhrp server (the hub router) how to reach another spoke if necessary.

NHRP was created originally for WAN clouds like ATM, FR where you a NBMA = non broadcast multi access and where you cannot say that two routers in the same subnet are directly connected but they may need to go through some other device.

best regards

Giuseppe

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: