Fw: MTU Path Discovery Problem

[Jim Flowers]

I ran into something like this back in the days of SKIP VPNs and fbsd 3.5 to 
4.5 and although I am not currently doing that, I can remember a couple of 
the issues.

One was that I was also using natd via ipfw bypassing the tunnel and natd 
would copy the MTU (1500) before SKIP reduced it to 1346 for encapsulation 
and refused to listen to messages generated by ifconfig when changing the mtu 
(not in the code).  Then when the response to mtu discovery probing began, 
the reduction was from 1500 instead of 1346 and the Windows NT machine just 
kept sending too-large packets with the DF flag set and the interface 
rejected them.  The solution was to delay startup of natd until after the 
SKIP reduction completed.  

The second issue had to do with the response from Windows NTs which was not 
quite right and which I can't quite remember.  This was at the time of NT4.0 
with SP6 or so and there was a knowledge-base article on turning blackhole 
discovery off in certain instances to accomodate it.

Hope that's some help.  Good luck.

--
Jim Flowers<jflowers at ezo.net>

---------- Original Message -----------
From: Koroush Saraf <koroush.saraf at lmco.com>
To: freebsd-hackers at freebsd.org
Sent: Thu, 19 Jun 2003 14:22:05 -0700
Subject: Fw: MTU Path Discovery Problem

> PMTUD Black Hole ProblemPlease take a look at this possible code 
> Problem?  If not, please read the message below to find out the 
> original problem!
> 
> Is this a code problem in ip_input.c, This code is from FreeBSD 4.8 
> that I just installed on my computers. ip_forward ?  It looks to me 
> like case EMSGSIZE can never be reached.  Is this breaking mtu path 
> discovery responses ? 
> 
> ip_forward(struct mbuf *m, int srcrt, struct sockaddr_in *next_hop)
>         switch (error) {
> 
>         case 0:                         /* forwarded, but need 
> redirect */                /* type, code set above */                
> break;
> 
>         case ENETUNREACH:               /* shouldn't happen, checked 
> above */        case EHOSTUNREACH:        case ENETDOWN:        case 
> EHOSTDOWN:        default:                type = ICMP_UNREACH;       
>          code = ICMP_UNREACH_HOST;                break;
> 
>         case EMSGSIZE:
>                 type = ICMP_UNREACH;
>                 code = ICMP_UNREACH_NEEDFRAG;
>   ----- Original Message ----- 
>   From: Saraf, Koroush (N-Norman SubSystems) 
>   To: freebsd-questions at freebsd.org 
>   Sent: Thursday, June 19, 2003 9:32 AM
>   Subject: PMTUD Black Hole Problem
> 
>   Hi All, 
> 
>   I have the following network in the lab
> 
>   WINXP <---mtu1500--->FREEBSD4.4<---mtu1280(gif tunnel)---
> >FREEBSD4.4<---mtu1500--->WINXP 
> 
>   The BSD computers are setup as gateway routers.  As you might see 
> from diagram above, the MTU of the link between the two BSD 
> computers is 1280Bytes because of a tunnel.  When I try to transfer 
> a file between the XP endpoints, the PMTUD goes off by sending a 
> 1514B packet to the other end with the Don't fragment bit set. 
>  However this packet never generates the ICMP unreachable message 
> back to the XP box during Path MTU discovery.  So that's why I have 
> concluded that the BSD router is the black hole.  
> 
>   Now I would like to know how to make my BSD router to participate 
> in the MTU discovery.  Changing the MTU of the windows computers is 
> not an option for me.  Also please note that the BSD computers only 
> have one NIC interface, and the network is logically sperate but 
> physically all connected to a switch, so playing with the MTU of the 
> interface connecting the BSD computers is not an option either.
> 
>   I hope that this is a known problem and easy to fix and thanks for 
> taking the time to respond.   ~koroush   
> _______________________________________________   freebsd-
> questions at freebsd.org mailing list   
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions   To 
> unsubscribe, send any mail to "freebsd-questions-
> unsubscribe at freebsd.org" _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
------- End of Original Message -------