Dual DMVPN Layout - Routing and tunnel issue

[gauthier]

Good day,

We have setup a single dmvpn layout. This did work well at the time. Since we didn't have any flexibility in managing priority routing (using bandwidth for eigrp) we decided to migrate to a DUAL DMPVN LAYOUT.

This, we have issue. It either doesn't bring both tunnel (see below for the configuration) only the first one gets connected correctly.

After research I tried using the tunnel destination configuration instead of the dynamic maping at the spoke locations.

This do eliminate the confusion of tunnel. Tunnels do comes up and routing becomes up to speed. The problem with this, we loose the dynamic feature between spoke locations. No tunnels are done directly between spoke to spoke when required...which is why we needed DMVPN in the begining.

By the way we use version 12.3.6 (2600XM and 7200)

Does anyone have some input on how I could get a dual DMVPN layout working correctly and keep the spoke to spoke tunneling feature ???

Take note that we need to be able to priorities routing (eigrp) at the spokes locations going to the HUBs.

I did look everywhere I could in the Cisco site, but I cannot find anything that solves my issues.

See attachement for the configs

[sergej.gurenko]

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_white_paper09186a008018983e.shtml

Dual Hub - Dual DMVPN Layout

You can use either p-pGRE or mGRE tunnel interfaces on the spoke routers. Multiple p-pGRE interfaces on a spoke router can use the same tunnel source ... IP address, but !!!!> multiple mGRE interfaces on a spoke router must have a unique tunnel source ... IP address. first mGRE tunnel interface is always matched Cisco is currently looking into methods of removing the unique tunnel source ... IP address restriction when using multiple mGRE tunnel interfaces on the same router. !

[sergej.gurenko]

The last information is that in 12.3(6) and 12.3(7)T dual hub/dual DMVPN problem solved. Do not know how.

[wong.jason]

Do anybody has confirmation that this is solved ? I'm unable to locate the information and my client would be very pissed with me if I mess around with it and still don't solve it.

For for curiousity, what settings do you guys use for the

ISAKMP Keepalive ?

Tunnel Keepalive ?

IPSec Keepalive ?

[sergej.gurenko]

My Sevice Reqest to cisco F291722 "DOES DMVPN SUPPORT HSRP?"

There was to qestions:

1Q. DOES DMVPN SUPPORT HSRP?

1A. No. HSRP is only supported on traditional crypto maps. HSRP do not supported on "tunnel protection ipsec profile"

2Q. Document http://www.cisco.com/en/US/tech/tk583/tk372/technologies_white_paper09186a008018 983e.shtml

States that:

You can use either p-pGRE or mGRE tunnel interfaces on the spoke routers. Multiple p-pGRE interfaces on a spoke router can use the same tunnel source ... IP address, but multiple mGRE interfaces on a spoke router must have a unique tunnel source ... IP address. This is because when IPsec is initiating, the first packet is an ISAKMP packet which needs to be associated with one of the mGRE tunnels. The ISAKMP packet only has the destination IP address (remote IPsec peer address) with which to make this association. This address is matched against the tunnel source ... address, but since both tunnels have the same tunnel source ... address, the first mGRE tunnel interface is always matched. This means that incoming multicast data packets may be associated with the wrong mGRE interface, breaking any dynamic routing protocol.

GRE packets themselves do not have this problem since they have the tunnel key ... value to differentiate between the two mGRE interfaces. Cisco is currently looking into methods of removing the unique tunnel source ... IP address restriction when using multiple mGRE tunnel interfaces on the same router. In the meantime, p-pGRE tunnels will be used in this dual hub with dual DMVPN layout. In the p-pGRE tunnel case, both the tunnel source ... and the tunnel destination ... IP addresses can be used for matching.

That mean migration to mGre on the spokes with one external interface will be possible in future. May be this issue resolved now? Which IOS version? Thanks!

2A. I had contacted my senior most engineer who was working on this & also had wrote that article.He told me that this now has being fixed in code 12.3(6) and 12.3(7)T. The whitepaper will also be updated. The workaround will be provided.

[wong.jason]

Thanks. I assume the 12.3(6) refers to the T train. This will be a problem for me because my customer is using a mixed of 1720 and 1721 for the spoke. From the IOS downloads, the 12.3(6)T trains doesn't support 1720. So upgrading would be a problem.

[sergej.gurenko]

When the cisco says 12.3(6) - I thing that mean NO T train. When says 12.3(7)T - That mean T train. What the purpose to say supported from 12.3(6)T and from 12.3(7)T - there is no logical sence. 12.3(7)T would surely support 12.3(6)T features!

[wong.jason]

Notice that the first guy that has this problem is already using 12.3(6). I've tried to upgrade the IOS to 12.3(6) on 1721 and I revert back in a hurry. The tunnels all crash on me, *MM_State* after a couple of hrs even before I make any changes to the config. (Dual Hub DMVPN using mGRE at the hub and p-p GRE at the branch).

[gauthier]

Just as an update on the dmvpn stuff.

I am using the 12.3.6 version on 2600 and 2600xm 3600 and 7200 routers. All is fine, but I still have issue with prioritizing routes from the spokes going to the hubs. One hub as a primary and a second one as a backup. At the moment, it is load balancing which is not an option for me, I need the second hub only as backup.

A case at tac is open for the routing and the cisco engineers are still working on this, it's been a few days. If any of you are interested on the results, let me know.

[wong.jason]

Are you saying that 12.3.6 solve the problem with the Dual DMVPN Dual hub. Or are you using a single hub situation. Any chance of you posting a clean (no password, etc) config for the hub and spoke ? THANKS ..

[gauthier]

Hi Jason,

I'm using 12.3.6, I did try older version, but that one seems to work fine with my devices.

Here are examples of the configurations of Single and Dual layout that I use and are working for long time.

Take note that ::::

Single layout:

Dynamic tunnel between spokes works fine. Downside, you cannot chose to which hub traffic should pass as primary, it load balance between the two hubs. (this is the case that I have open with Cisco).

Dual layout:

No dynamic tunnel between spokes. But each spoke is still able to talk to other spokes, they go through the hubs. The good thing about the dual is you can chose correctly to which hub traffic should be going as primary. You tweakk it with the bandwidth and delay at each locations.

Hope this will help. Feel free to give me feedback on how it works on your side.

[wong.jason]

Hi,

Thanks. I've look through and see if we have any differences in how I did it. I'm using Dual Hub, Dual tunnel and I was under the impression that the 12.3.6 IOS could possibly solve the problem of the tunnels but my experinces with just installing 12.3.6 on the routers (w/o changes in config) was that tunnels keep dropping and reconnecting w/o reasons. So I falled back to 12.2(15)T

What Cisco has said was that dual mGRE tunnels don't work but what I've found was that even single mGRE with another p-p GRE tunnels on the same router is pretty unstable.

The current issue with not being able to have more than 1 mGRE tunnels on the same router sort of defeats the purpose of going towards DMVPN anyway.

Hope we will get some good news on this soon. If you managed to get some feedback on the problem you log with TAC. Drop me a note here or through email. Thanks.

[gauthier]

Hi,

Ok, I got the solution for the dual hub single layout. First, the dual hub single layout works with dynamic tunnels between spokes. The only issu that was missing for me was how to send traffic to only one hub and the other hub as a backup. The tric is to simply put a delay on the inside interface of the backup hub. Eigrp will do all the proper calculation and traffic will go according to the priority.

Hope this helps, for me it solved all my issues.

[daniel-ma]

I read the document, it seems that we could configure higher distance under EIGRP for HUB 2. Anyone configured that way?

[wong.jason]

I think you will end up with Asymentric routing.