[157583] in North American Network Operators' Group
Re: the little ssh that (sometimes) couldn't
daemon@ATHENA.MIT.EDU (Mike O'Connor)
Mon Oct 29 22:21:54 2012
Date: Mon, 29 Oct 2012 20:44:01 -0400
From: "Mike O'Connor" <mjo@dojo.mi.org>
To: nanog@nanog.org
In-Reply-To: <20121029170743.GB2527@vacation.karoshi.com.>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--cvVnyQ+4j833TQvp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
:
:corruption!
:
:
:http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldn=
t.html
I ran into a similar issue with a customer just a few days ago! The
customer's theory was that there was something badly wrong with their
dorky gateway/switch (which we sold and support <sigh>). ssh was
timing out, with a SSH2_MSG_KEX_DH_GEX_GROUP hang/failure during the
ssh protocol exchange. Based on that, some wireshark captures, and
and stray Google droppings, I advised them to ratchet down the MTU to
make things work. Through bisectional MTU settings and pinging, we
arrived at an MTU of 850. And I initially started cursing at the
switch (because that helps move packets, really :) ).
Turns out -- the ssh server in question was running RHEL 5.x Linux,
and that was the key. Even though "ip route show cache" looked sane,
"ip route flush cache" (which I had them run, just on a lark) made=20
the problem go away. So it probably wasn't my switch (unless it had
done something untoward in the distant past that induced some weird
Linux stack bug).
I'm mostly posting this because I was wondering if anyone else had
run into an MTU of 850 before. Is that a "magic number" that rings
any bells (or perhaps has seen the Linux route cache behavior I did).
-Mike
--=20
Michael J. O'Connor mjo@dojo.mi.o=
rg
=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=
=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D--=3D=3D=
--=3D
"It is now the age of now." -Non Campus Ment=
is
--cvVnyQ+4j833TQvp
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
iQBVAwUBUI8i0ZEu6kwgW799AQI2fwIAoICcYLaxDJLgT2b141OeWz0S+Zp/2nT9
6aa3IFSY1Xqefn2saSfE32Z9LF7AALhjvrSqhTVPli0F1LUFRX3kdg==
=Gnd0
-----END PGP SIGNATURE-----
--cvVnyQ+4j833TQvp--
