TCP Window Scaling issue
mpetach at netflight.com
Thu Jul 24 17:23:33 UTC 2014
On Thu, Jul 24, 2014 at 9:51 AM, Zach Hill <zach.reborn at 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).
> On Thu, Jul 24, 2014 at 12:47 PM, Zach Hill <zach.reborn at 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 at 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
> >> Systems Administrator | to fit the machine. He adjusts the machine
> >> michael at supermathie.net | until it behaves properly. With a hammer,
> >> | if necessary. - Brian
More information about the NANOG