[ale] SSH Cisco Networking Issue

Omar Chanouha ofosho at gatech.edu
Fri Sep 17 12:14:24 EDT 2010


Thanks for that explanation Keith. The server is actually behind a
NAT. As it turned out the max MTU I could have is 1400, god call. It
hangs at 1408 or higher.

The IT wizard is telling me that he thinks this is due to a driver
issue. Linux, of course, is always to blame. The server is actually a
virtual machine on top of Vmware on top of an intel NIC.

Is there any truth to his theory?
Is the performance hit I am taking significant enough to keep fiddling with it?
Is there a way to fix the NAT/Firewall, or is it just suck like that
til we get a firmware upgrade? The HW is actually very new. Just
purchased within 6mo I think.

Thanks,

-O

On Fri, Sep 17, 2010 at 11:40 AM, Watson, Keith <krwatson at cc.gatech.edu> wrote:
>> -----Original Message-----
>> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of
>> Omar Chanouha
>> Sent: Friday, September 17, 2010 01:02
>> To: Atlanta Linux Enthusiasts - Yes! We run Linux!
>> Subject: Re: [ale] SSH Cisco Networking Issue
>>
>> > Most SSH
>> >packets are much smaller than your MTU, but a large amount of data
>> >could well exceed this.  If the firewall is dropping fragments, you
>> >would get a behavior similar to what you've described.
>>
>> AMAAAAAAAAAAZINGGGGGGGG!!!!!!!!!!!!!
>>
>> David, you sir are nothing shy of the man!!!!!!!!!
>>
>> I throttled the MTU on my server, and now I am able to send/recieve as
>> much data as I want!
>>
>> This brings up another question about MTU size, but I'll make another thread
>> for that.
>>
>> Thanks again!
>>
>
> Omar,
>
> Sorry for arriving at the party late. The symptoms are classic of an MTU mismatch.
>
> Are any of the machines sitting behind a NAT router? The reason I ask is that consumer grade NAT routers are sometimes a bit deficient in properly negotiating MTU for encrypted connections, which results in symptoms like the ones you are seeing. Setting the MTU of your machine to 1438 or less should solve the problem.
>
> When Linksys first came out with their routers we had a rash of bizarre https, vpn, and ssh behavior just like you described. I was sent home for a day with a Linksys to find the problem. I found that MTU was not be negotiated properly.
>
> Most consumer router vendors eventually solved the problem with a firmware upgrade. If you are not using NAT it doesn't mean you still don't have an MTU problem. There is some networking device between you and them that is not negotiating properly.
>
> Here is the conclusion from the report:
>
>   A larger header is required for HTTPS over a VPN.
>   When the MTU is set to 1500 the packets are fragmented
>   whenever the data size to be transmitted is >1K.
>
>      header size + data size > 1500 bytes
>
>
>   Setting MTU to 1438 prevents the packets
>   from fragmenting by limiting the amount of data in
>   the packet.
>
>      header size + data size = 1500 bytes
>
>   Since not all possible scenarios were tested
>   an MTU value of less than 1438 should be used
>   to provide a safety margin. However, as MTU
>   decreases more packets are needed to send the
>   same amount of data. Therefore a safe compromise
>   would be to set MTU to 1400.
>
> Keith
>
> --
>
> Keith R. Watson                        Georgia Institute of Technology
> Systems Support Specialist IV          College of Computing
> keith.watson at cc.gatech.edu             801 Atlantic Drive NW
> (404) 385-7401                         Atlanta, GA 30332-0280
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>



More information about the Ale mailing list