Link to home
Start Free TrialLog in
Avatar of AccessYourBiz_Com
AccessYourBiz_ComFlag for United States of America

asked on

MTU Packet size, VPN with Active Directory

I have a windows 2003 network, with a mix of 2003 and 2000 domain controllers, there are branch offices connected to the lan via a VPN, recently this vpn was upgraded from Pick boxes to Cisco 1720, since then, active directory relication has been troublesome at best. I tested the max packet size with ping, 1472 gets fragmented, 1380 is the max size which can go through without fragmentation.

The currect packet size is the default of 1472. There are about 15 DCs in the domain, I spoke to the Router Vendor, who reports that he can not increase the packet size because of the tunnel and the ecription he is using.

Just a few questions:

1)  If I make no changes, what is the actions AD will take, will it try the 1472, then scale down to the largest non fragmented packet size, or will it fragment the packet and what would the effect of this be.

2) Do I need to edit the registry on each DC to the 1380 packet size.

3) Are there any tools which can help determine if the AD replication packets are being fragmented as currently configures, I know I can use ping to determin the max no fragmented size, but can a see what AD is doing.

4) what would be the recommended solution to what is going on here.

Thanks
Steve
SOLUTION
Avatar of Shift-3
Shift-3
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Rob Williams
>>"the Router Vendor, who reports that he can not increase the packet size "
Correct 1472 is the maximum, but you want to lower, they should be able to do that.

Doing the fragmentation test is not truly accurate as you are doing so over a VPN. The VPN takes up some "overhead" so the acceptable packet size would be larger than your tested 1380, but still likely not 1472 base on your tests.

You can easily change the MTU on a given system using the common DrTCP tool
http://www.dslreports.com/drtcp
Avatar of AccessYourBiz_Com

ASKER

If I make no changes, what is the actions AD will take, will it try the 1472, then scale down to the largest non fragmented packet size, or will it fragment the packet or drop the packet  and what would the effect of this be.

Right now the AD appears to be replicating, if the max size is 1380 and the MTU on the DCs are set to the default how is this being replicated?
AD will not "scale down to the largest non fragmented packet size"
The only time Windows will change the default packet size if it sees the presence of a specified Internet service. For example if you configure a network adapter to connect directly to the Internet using a PPPoE connection, it will set it to 1492, an L2TP/IPSec 1472, etc.

The reason it is likely currently working is that the device/server creating the packet is doing so at an acceptable size. usually it is recommended all generating sources and routers at the same site be changed, but I have found as a rule that if the device generating the packet is reduced the packet size will be passed along unchanged, except of course with addition header information being added such as VPN encapsulation.
If I wanted to adjust the MTU in the registry to 1380, where is that key located?

Thanks
Steve
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
See Method 3 from my link.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks AccessYourBiz_Com,
Cheers !
--Rob
http://support.microsoft.com/kb/244474 is how to force Kerberos to use TCP not UDP. It would appear over a VPN, UDP packets were black holeing forcing TCP resolved our issue straight away. I have previously set MTU sizes etc without any joy. We can now get to network shares very quickly

Cheers

Martin