[clug] Diagnosing SSH performance problems [SEC=UNCLASSIFIED]

[Michael Cohen]

Hi Daniel,

    The problem occurs frequently enough to even be documented on wikipedia

http://en.wikipedia.org/wiki/Path_MTU_discovery

It is not related to noise or saturation and has nothing to do with
window scaling - usually just an incorrectly configured firewall.

Michael.

On Thu, Dec 10, 2009 at 10:59 PM, Daniel Pittman <daniel at rimspace.net> wrote:
> Michael Cohen <scudette at gmail.com> writes:
>
>> What you describes sounds like your machine is configured for too high an
>> MTU for the link.
>
> Are you assuming a noisy link, such as an analog modem without error
> correction, or something like that?
>
> Otherwise incorrect MTU settings should result in either PMTU discovery, or a
> stall as the client sends over-large packets, and those packets are never
> delivered.
>
>> Try to lower your MTU and see if that fixes it. If that is the issue ensure
>> your firewall does not block ICMP MTU discovery type messages so that your
>> system is able to discover the appropriate MTU.
>
> Mmmm.  At the network layer, I would more suspect a firewall that strips the
> window scaling option, and a Linux that sets window_scale to 2 so that the
> connection limps along rather than stalling forever.[1]
>
> Alternately, something else such as high packet loss or latency on the link
> might show these results; it could also be asymmetric load, with one direction
> close to saturation, resulting in high latency in one direction only.[2]
>
>> On Thu, Dec 10, 2009 at 5:18 PM, Roppola, Antti - BRS
>> <Antti.Roppola at daff.gov.au> wrote:
>>> Hi all,
>>>
>>> So I have an SSH problem where pushing data over an SSH connation gets
>>> me less than 9600 baud and numerous halts and timeouts. Pulling from the
>>> same host just rips along as you'd expect.
>>>
>>> Nothing obvious seen using "ssh -v". Nothing relevant leaps out at me in
>>> sshd_config.
>>>
>>> To me this suggests the issue is deeper down in the transport, network,
>>> data link of physical layer. Viz, I can't think of anything in OpenSSH
>>> that could be mis-configured to give asymmetric symptoms.
>>>
>>> Does this seem like a reasonable hypothesis?
>
> Yes, to me.  I can't really envision a scenario that results in asymmetric
> behaviour when *only* OpenSSH is responsible.
>
>        Daniel
>
> Footnotes:
> [1]  When the option was first introduced, this was set to 7, resulting in
>     effectively a zero window when the option was stripped; now it default
>     to 2 by default, and provides bad-but-functional connectivity.
>
> [2]  When you only send acks from your machine to theirs, performance stays
>     good.  When you send bulk data, however, you are exposed to the
>     transmission delays.
>
> --
> ✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
>               ♽ made with 100 percent post-consumer electrons
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux
>