On Thu, Jul 24, 2014 at 9:51 AM, Zach Hill <zach.reb...@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.reb...@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 <mich...@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 > >> mich...@supermathie.net | until it behaves properly. With a hammer, > >> | if necessary. - Brian > >> > >> > > > >