Chris Jaecker cjaecker "at"
Fri, 25 Jan 2002 01:48:46 +0000

At 10:20  24/01/02 +0000, you wrote:
>Date: Thu, 24 Jan 2002 13:00:28 +0000
>From: Mark.Reeder "at"
>Subject: Re:  MTU
>can you clarify your reply  please.

No problem. Bear in mind that this may not be the cause of your problems.....

>On 24/01/2002 11:35:20 Chris Jaecker wrote:
> > To test for this try sending out pings with 1500 mtu and df set (client 
> to server or vice versa).

> that would be
>                                             ping -l 1500 -f  remote_host
>       -  correct ?

Yes. You need to sweep a range of sizes to see what MTU works. Try 1400, 
1420, 1450 etc. I'd also send a lot of pings in the test, by using the -t 
option (which means the ping goes till you press CNTRL-C) as the 
intervening devices may benevolently ignore the df bit, and also to 
simulate the congestion overhead.

> >If it is the problem, try this:
> >
> > The solution was to reduce the MTU of the VNC host. This can be done in 
> the registry permanently with:
> >
> > 
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\<adapter>\Tcpip\Param 
> eters\MTU
> >
> > which should be set to 1400
>[Under NT4 system] I couldn't find any Tcpip\Parameter names under 
>Services and couldn't really match <adapter> to my actual adapter
>can you advise how to create an appropriate "<adapter>" name please.

You don't create the adaptor name, it's created as part of the NIC install 
process. On my Compaq ML370 running ipconfig in a DOS window revealed I had 
the Ethernet adaptor N1001, and in the Registry, it was there as

I had to create the Tcpip parameters myself. Actually I prefer the option 
below, because it worked better.

> > The NT server can also be forced to discover the MTU of a path by setting:
> >
> > 
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Enab 
> lePMTUBHDetect
> >
>On my system, this did not exist, so presumably requires creation.

Yes, you need to create it.

>a) what is the behaviour when entry does not exist?

The system will default to 1500 MTU

>b) can you confirm that "discover" means "discover and use"

Yes. It means that the connection begins a little more slowly as the server 
will actually check for the path MTU by setting DF and waiting for "should 
have fragmented, but couldn't"  messages from intervening routers. Even if 
the router doesn't send the "Could not Fragment" message (as it may well do 
because it is in "black hole" mode), the NT box will wait for the 
acknowledgement of the packet and if it is not received it will drop the 
MTU and try again until it gets an ack and therefore knows the "true" MTU 
of the path.

>c) As a normal "end-user", when would you NOT want "discover and use" ?
>  I assume it is useful when investigating performance and setting up a 
> network.

It does slow down session connect time, so you wouldn't use it if the path 
between hosts was homogenous and transparent. For me, because all 
connections are through VPN, it's compulsory. I suppose I could force the 
MTU and avoid the session negotiation overhead, but I wasn't too happy 
setting up the interface registry either, and in any event, any local 
connections under the detection scheme will go at 1500.

I hope this is helpful. I'm really a router guy, and strictly empirical 
with MS.

Best wishes

To unsubscribe, mail majordomo "at" with the line:
'unsubscribe vnc-list' in the message BODY
See also: