[6bone] problem with ftp.netbsd.org
Stephen Stuart
stuart@tech.org
Fri, 14 Jun 2002 12:17:13 -0700
> On Thu, Jun 13, 2002 at 08:51:12PM -0700, Stephen Stuart wrote:
> | If anyone is still having problems with TCP sessions to/from
> | ftp.netbsd.org, please send me traceroutes.
>
> The MTU and tunnel setttings are unrelated. A TCP handshake uses
> Syn/SynAck/Ack packets without payload so these should be around 50
> bytes.
I understand that.
ISC receives routes from two sources: peers on the PAIX Palo Alto
switch fabric, and a tunnel to ISI. I would like to determine if the
people having problems share some property relating to that, like
"people who still report problems all show the ISI tunnel in their
traceroute."
> Stephen, I still cannot reach the site, from various Dutch ISPs, such as
> SURFnet (AS1103), Intouch (AS8954), BIT (AS12859) and Concepts
> (AS12871).
[traceroutes]
The traceroutes you sent were helpful, as they all show the ISI tunnel
in the traceroute.
The problem showed up as the result of two variables in our network
changing: our Palo Alto router changed from Cisco to Juniper, and our
Redwood City router changed from Cisco to FreeBSD/zebra (this is not
to be taken as a reflection on Cisco, the change was necessary for
other reasons).
To further comment on your observation regarding TCP - yes, the
handshake is small, and in an environment where MTU mismatch would
cause problems with larger packet sizes, a TCP session would tend to
start and then hang, as the window size ramps up and datagram sizes
approach interface MTU size. As was correctly noted by itojun, when
the *interior* tunnel MTU sizes did not match, everyone suffered
(including the iBGP session between the routers); when the MTUs were
aligned in the manner that itojun noted (the Juniper was brought down
to FreeBSD's setting) connectivity for some improved.
Remaining problems *seem* to have the ISI tunnel in common. Interface
MTU size on the tunnel interface toward the ISI router has now been
matched, just as with the interior tunnel interface.
> As Ronald has also witnessed, I see Syn, then SynAck, then I send Ack
> and the line goes dead (does this Ack ever reach the ftp6 server?).
That is an excellent question. I am not a member of the NetBSD
development team, and I do not have access to their box to determine
conclusively whether the ack really gets there. I can run tcpdump on
the router immediately upstream to see if it is attempting to deliver
it. If someone still having issues would like to coordinate a
debugging session to look at that, please contact me privately.
Stephen