Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

DMVPN not the best choice for corp interoffice WAN connectivity - Your thoughts?

Hi everyone, I wanted to start a discussion to get some of your thoughts and ideas in terms of what makes Dynamic Multipoint VPN, the technology of choice and some of the things that do not when it comes to an enterprise level deployment. I have a 7-8 year experience working with this technology at both my past and current work places. My previous company relied on this technology to interconnect hundreds of retails stores all across the country. All their major sites (Data Centers, Offices, Warehouses etc) were connected via MPLS however DMVPN was used as a backup for these as well. We never ran into any major issues with DMVPN since the retail stores hardly ever had any data to send between each other and were really just a hub to spoke link to the data center 90% of the times. DMVPN was deployed for the just-in-case type of scenarios where spoke to spoke might be beneficial and potentially come in handy.

I will list some of the issues I have run into with DMVPN at my current workplace and then perhaps you can let me know your thoughts or suggest any improvements I could perhaps make.

We are a large engineering firm with offices located all across North America. All these offices always have tonne of data (CAD drawings etc) to share among each other so the dynamic nature of DMVPN definitely comes in handy. Primary physical connectivity at majority of the offices is 100Meg internet circuits with some exceptions where primary circuit is a residential grade DSL or Cable connection.

As you know, DMVPN relies on GRE and IPSEC to transport the packets between routers, it adds on a lot of extra overhead. Although they claim otherwise, I have found a lot of internet companies do not allow 1500 byte MTU and fragment the packet as it leaves the customer router. To try and avoid fragmentation in the WAN, I have the MTU set to 1492 bytes on my outbound interfaces. Each tunnel interface has an MTU of 1400 bytes. Extra 92 bytes are allowed for all the extra over-head with ipsec and GRE. I also have a policy in place to set the DF bit to 0 for all incoming packets at the inside interface.

However the issue we run into time to time is with applications such as AD that tends to be sensitive in terms of packet size. I believe AD sends packets of size 1472 bytes with the DF bit set. It almost seems as if AD doesn't like the router playing with the packet sizes it feeds it and causes issues.

I could leave the DF bit settings unchanged at the router and let PMTUD work its magic however that causes problems with too many packet drops if the host, for any reason, does not receive the ICMP packet back from the router.

This scenario would not be a problem if sites were connecting to one another over MPLS that allows 1500 byte MTU. AD could sends its 1472 bytes and the router could simply forward the frame over to the other side.

There are also other issues with DMVPN where IPSEC SAs could go out of sync for a number of reasons causing two peers to completely drop connectivity with each other until both can figure out that the connection went down (invalid spi recovery). However somtimes that could be 5 minutes or longer. In order to speed up the process, I have to manually issue the CLEAR IP NHRP command or simply reboot the routers to restore connectivity.

There are also several other issues that simply don't make DMVPN the optimal choice for a primary technology for inter-office connectivity over the WAN.

What are your thoughts?

Here are some of the links that talk about some of the things I mentioned.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

http://www.cisco.com/image/gif/paws/115801/115801-ipsec-spi-errors-technologies_tech_note-00.pdf

6 REPLIES
New Member

DMVPN not the best choice for corp interoffice WAN connectivity

Nice article and I agree with what you are saying, we use DMVPN as a secondary path in event of MPLS (IPVPN), and it is part of my daily tasks to clear crypto sessions / clear nhrs / reboot the backup routers. I keep meaning to try Get VPN in combination with NHRP:

http://blog.ine.com/2009/09/30/bob-is-back-dmvpnget-vpn-assistance-needed/

Also, though i only use BGP over the DMVPN networks my co-worker has previously configured OSPF. ended up be a disaster.

Although im not looking forward to the IPV6 rollout, it will be interesting to see what the inbuilt ipsec/encryption resolve (/generate)

Regards Neil

Regards Neil http://uk.linkedin.com/pub/neil-grant/20/5b0/267

DMVPN not the best choice for corp interoffice WAN connectivity

New Member

DMVPN not the best choice for corp interoffice WAN connectivity

Looks interesting, not supported on ISR1's though so will need to lab with phyiscal kit,

Regards Neil http://uk.linkedin.com/pub/neil-grant/20/5b0/267
New Member

DMVPN not the best choice for corp interoffice WAN connectivity

Great suggestions. I am very tempted to try both GET and Flex VPNs. Time to do a write erase on the lab gear and reboot

New Member

DMVPN not the best choice for corp interoffice WAN connectivity

Looks like GET only works over private WAN connections? Such as MPLS. It wont work over my DMVPN topology as it traverses the Internet.

New Member

DMVPN not the best choice for corp interoffice WAN connectivity

Hi Ricky

Yes it's original intention was to encrypt traffic traversing mpls networks when security policy dictates, however it can be used to provide encryption across an gre nhrp infrastructure. Have a read of the ine post.

Regards Neil

Ps I say this, but have only read about it and never labbed it up

Regards Neil http://uk.linkedin.com/pub/neil-grant/20/5b0/267
398
Views
19
Helpful
6
Replies
CreatePlease to create content