Site-site VPN - MTU problem?
Get this same problem with any Cisco router site-site VPN. Have various customers with 857, 877, 1841, 2811 routers, same problem every time. I'm setting up a VPN with the SDM, link goes up ok, but traffic seems oddly sluggish.
Installing the Cisco VPN client on all PCs seems to resolve the problem - I'm guessing because it sets the MTU size to 1300 - but you always get this error message when testing the VPN from the SDM:
Failure Reason(s)
A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not fragment' packets.
Recommended Action(s)
1)Contact your ISP/Administrator to resolve this issue. 2)Issue the command 'crypto ipsec df-bit clear' under the VPN interface to avoid packets drop due to fragmentation.
The crypto command doesn't make any difference.
Any ideas gratefully received.
Installing the Cisco VPN client on all PCs seems to resolve the problem - I'm guessing because it sets the MTU size to 1300 - but you always get this error message when testing the VPN from the SDM:
Failure Reason(s)
A ping with data size of this VPN interface MTU size and 'Do not Fragment' bit set to the other end VPN device is failing. This may happen if there is a lesser MTU network which drops the 'Do not fragment' packets.
Recommended Action(s)
1)Contact your ISP/Administrator to resolve this issue. 2)Issue the command 'crypto ipsec df-bit clear' under the VPN interface to avoid packets drop due to fragmentation.
The crypto command doesn't make any difference.
Any ideas gratefully received.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
And there's no reason to go in increments of one. Divide and conqour :) I'd do it about 100 at a time, then 50, then 20, etc.. Will save lots of time.
ASKER
Sounds like good advice - but I'm missing something somewhere. The ping tool you're using - this can't be from the router, or a Windows host, because the ping commands don't support those switches. Is it a third party tool I need to get hold of?
Thanks
Thanks
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Actually, on windows it'll be "ping -f -l 1472 x.x.x.x" the f will set the do not fragment flag, and the l will specify the packet length.
Opps, I was concentrating on the -s vs the -l, yep need the -f.
ASKER
Finally found the time to try this out, discovered a path MTU of 1472, so, to both routers globally:
ip tcp mss 1372
for int atm0 and int dialer0: (not sure which one so did both - it's an 877 ADSL model)
ip mtu 1472
ip tcp-adjust mss 1372
crypto ipsec df-bit clear
But the VPN "test tunnel" from the SDM still comes up with the same message as before.
What am I missing?
Thanks
ip tcp mss 1372
for int atm0 and int dialer0: (not sure which one so did both - it's an 877 ADSL model)
ip mtu 1472
ip tcp-adjust mss 1372
crypto ipsec df-bit clear
But the VPN "test tunnel" from the SDM still comes up with the same message as before.
What am I missing?
Thanks
ASKER
Still haven't quite got to the bottom of it, but I'm sure we're on the right lines, so I'll split the points.
I know this is old.. but giltjr you are completely wrong
When doing a ping from windows, windows does NOT count the 28 byte ip header as part of the payload. So when doing a ping of ping -l 1472 -f x.x.x.x the packet size is actually 1500 bytes. Not 1472. This behavior is different to *nix and to Cisco IOS
When doing a ping from windows, windows does NOT count the 28 byte ip header as part of the payload. So when doing a ping of ping -l 1472 -f x.x.x.x the packet size is actually 1500 bytes. Not 1472. This behavior is different to *nix and to Cisco IOS
Sorry, and to give a solution for the OP
You will need to change the MTu on the client machines.
Start at 1436 (1500-64 bytes from ipsec vpn overhead)
Xp/2000/2003
http://www.pctools.com/guides/registry/detail/280/
Vista from the cli
netsh interface ipv4 set subinterface "Local Area Connection" mtu=xxxx store=persistent
You will need to change the MTu on the client machines.
Start at 1436 (1500-64 bytes from ipsec vpn overhead)
Xp/2000/2003
http://www.pctools.com/guides/registry/detail/280/
Vista from the cli
netsh interface ipv4 set subinterface "Local Area Connection" mtu=xxxx store=persistent
Obviously you read my post out of context. If you read the prior post, it instructed the user to start ping'ing the remote side using the do not fragment bit set. It instructed them to start at 1500 bytes. Which will fail if you do this under windows, in fact it will fail under Linux also, because both Linux ( on the -s option) and Windows (the -l option) use this as the amount of data to use as the payload to the ping command.
You then need to add the 20 byte IP header and the 8 byte ICMP header (28 bytes) to get you to the Ethernet max payload (typically called MTU) to 1500 bytes.
I instructed the user to start ping'ing with a payload (payload to the ping command) value of 1472, because anyting and everything between 1500 and 1473 will fail on any 10/100 Mbps Ethernet network no matter what.
You then need to add the 20 byte IP header and the 8 byte ICMP header (28 bytes) to get you to the Ethernet max payload (typically called MTU) to 1500 bytes.
I instructed the user to start ping'ing with a payload (payload to the ping command) value of 1472, because anyting and everything between 1500 and 1473 will fail on any 10/100 Mbps Ethernet network no matter what.
With a 1500 byte MTU the largest unfragmented ping is 1472 because you have a 28 byte IP header and a 8 byte ICMP header.