cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1263
Views
0
Helpful
5
Replies

DMVPN connection problems

wdgolden1
Level 1
Level 1

I am having a very strange DMVPN connection problem.

I'm in the initial stages of moving from an IPSEC Site-to-Site vpn to a full DMVPN cloud. I currently have only one spoke converted from Site-to-Site to DMVPN.

Site to Hub connection looks like this

1841 -> Internet -> 2821 -> Core switch

From the spoke I can reach most resources off the core switch. However I'm unable to open internet browser connections to internal resources. Previously this site had been a Site-to-Site vpn using the same addressing and connecting through the same equipment. As a Site-to-Site vpn I can connect to all the proper internal network resources, as I can at all the other Site-to-Site vpn locations.

AS soon as I moved to DMVPN I started having connection problems to certain resources.

Once packets from the spoke reach the internal network is their any difference in their content between a DMVPN and a Site-to-Site vpn?

5 Replies 5

mlitka
Level 2
Level 2

How are things like mail and RDP performing? This sounds like it could be an MTU issue.

I can ping across normally, RDP will often disconnect. In general the connection across the GRE tunnel seems much slower than across the old IPSEC connection.

Right now I'm using MTU 1400 as found in this document, http://www.cisco.com/en/US/tech/tk583/tk372/technologies_white_paper09186a008018983e.shtml

How would I go about finding the optimal MTU?

Increase your ping packet size until it begins to timeout.

I have had good luck with setting my MTU at 1500 on my tunnels and then use ip tcp-adjust mss 1300.

For us RDP is sluggish and disconnects often it is usually a good sign that there is an MTU issue. Although this usually goes hand in hand with mail queues backing up or Outlook clients having trouble connecting over the VPN.

As soon as I put "ip tcp adjust-mss 1300" into the Tunnel interface on the spoke side I was able to connect to intranet sites.

Can you provide a summary of what would cause that one command to allow clients proper connectivity? I'd like to better understand the problem and resulting solution.

Also, I haven't yet changed IPSEC to transport mode and a previous admin had entered the command "crypto ipsec df-bit clear". In troubleshooting this problem I had removed the df-bit clear command.

Should the df-bit clear command exist or not and would moving to tunnel mode produce noticeable performance improvements?

Thank you very much for the help.

You can read more about it here:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00804247fc.html

I realize the settings I gave you aren't what is recommended in the document. I got those settings from TAC and they work for me. I haven't had a chance to play around with them to try different combinations as it typically breaks things.

The df-bit clear would remove the 'do not fragement' flag from the packet, enabling the router to fragment these packets into smaller sizes so they can get under the max MTU size. You shouldn't need the df-bit clear with the ip tcp adjust-mss command in place.

Transport mode may also help you here. It will reduce header overhead on the packets that are traversing your tunnel.

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: