nanog mailing list archives

Re: TCP Window Scaling issue


From: Matthew Petach <mpetach () netflight com>
Date: Thu, 24 Jul 2014 10:23:33 -0700

On Thu, Jul 24, 2014 at 9:51 AM, Zach Hill <zach.reborn () gmail com> wrote:

Also just to reiterate I would lean more heavily on something fishy in
the WAN cloud if all traffic from Site 1 to Site 2 were not seeing tcp
window scaling properly, however it's only for Server A that is seeing
this. Server A is able to properly TCP window scale for any local traffic.


Remember, the WAN cloud is just that, a cloud;
it's not likely to be a single link underneath it all;
so one bad link/bad port/bad device in the cloud
can affect just a sub-portion of the traffic, depending
on the 5-tuple hashing that takes place.

An interesting test would be to be give server A
a different address (secondary address should be
fine, all you need to do is source packets from a
different source address) and see if your scaling
suddenly reappears.  If it does, it's definitely down
to the 5-tuple hashing happening within The Cloud(tm).

Matt



On Thu, Jul 24, 2014 at 12:47 PM, Zach Hill <zach.reborn () gmail com> wrote:

Hi Machael,

Let me setup another packet capture at each side to see if the initial
packets are being modified at all.

Thanks,


On Thu, Jul 24, 2014 at 12:39 PM, Michael Brown <michael () supermathie net

wrote:

On 14-07-24 12:30 PM, Zach Hill wrote:
Hi Tony. No firewall in the way.

Physical flow is as below.

Server A -> Nexus 7k -> 3845 router -> Sprint MPLS -> 3845 router ->
Cisco
3750x stack -> Server B

I blame the cloud.

Dump the actual packets as they leave Server A and arrive at Server B
(and vice-versa!). Does it get modified en route?

M.

--
Michael Brown            | The true sysadmin does not adjust his
behaviour
Systems Administrator    | to fit the machine.  He adjusts the machine
michael () supermathie net  | until it behaves properly.  With a hammer,
                         | if necessary.  - Brian







Current thread: