TCPIP MTU settings

Dave Klein davek at interdyn.com
Mon Jul 19 21:24:05 EDT 1999


> From: guy.raymakers at europe.eds.com 
> ...
> We have discovered following problem
> 
> The remote network (offices) have a NT server and an IPsec 
> enabled router. The
> router encapsulates the TCP/IP packets into IPsec packets.  
> When using the
> default tcpip MTU ( = 1500), on the NT server,  we get 
> problems when doing file
> transfers. When we lower the tcpip MTU to 1444 we don't have 
> these problems.
> The remote office ISP is a different one then our ISP.
> 
> Does anyone had similar experiences ?


Yes, we call it the black hole router encounter.  

Basically, An IP datagram can be up to 65,535 bytes long while layer 2
frames are typically 1500 bytes long. Whenever the packet is larger than
what the frame allows, IP must fragment the packet into many frames.
Fragmenting can occur at any host or router when the size of the incoming
packet is greater than the maximum transmission unit (MTU) of the outgoing
interface. The MTU is the maximum layer 2 payload (which is the maximum size
that the IP header + IP payload can be).  If the host sets the "don't
fragment" bit in an outgoing packet and a downstream router needs to
fragment the packet, the router should send an ICMP message back to the
source saying "destination unreachable, fragmentation needed and DF set." 

Routers that don't do this and just drop the packet we call "black hole"
routers. This could be the source of your problems.  Another is that some
routers, firewalls, and VPN gateways won't forward the ICMP "destination
unreachable" packet that was generated by another router.

Most hosts discover the MTU size (RFC1191) by sending every packet with the
don't fragment bit set. The connection is established, the server sends a
greeting, the client sends a command or two, and it isn't until the server
starts to transfer large amounts of data that one of the packets is now
bigger than the MTU of an interface along the route. When this happens the
router with that interface should send back the ICMP "destination
unreachable" message. The server then reduces the MTU, keeps the don't
fragment bit set and tries again. The problem arises when a [black hole]
router won't send the ICMP message back or another box blocks it.

Now add IPSEC-based tunneling and you've added more headers in the datagram
somewhere between the client and the server typically causing the MTU to be
exceeding.  

We sell an IPSEC-based VPN product and this problem seems to pop-up quit a
bit.  We had to put a "workaround" in our VPN router to detect the situation
and automatically force the MSS (maximum segment size) lower.

Dave Klein
davek at interdyn.com
www.conclave.com

****************************************************************
TO POST A MESSAGE on this list, send it to vpn at listserv.secnetgroup.com

The VPN FAQ (under construction) is available at
http://kubarb.phsx.ukans.edu/~tbird/FAQ.html

We are currently experiencing "unsubscribe" difficulties.  If you
wish to unsubscribe, please send a message containing the single line
"unsubscribe vpn your-e-mail-address" to owner-vpn at listserv.secnetgroup.com

****************************************************************




More information about the VPN mailing list