Hi all, I'm having a hard time wrapping my head around some peculiar traffic, and I'm hoping that the big brains here may be able to offer some insight. In short ... this looks plain wrong: 42737 2014-12-02 17:06:04.822626 0.000004 2.057276000 0.001216000 10.10.10.10 20.20.20.20 118 27081 80 TCP 66 63960 63960 1921089026 1921091786 1306854153 4011022929 [TCP Dup ACK 42718#1] 27081→80 [ACK] Seq=1306854153 Ack=4011022929 Win=63960 Len=0 SLE=1921089026 SRE=1921091786 Src: 10.10.10.10 (third party ISP network) Dst: 20.20.20.20 (FE server) Seq=1306854153 Ack=4011022929 SLE=1921089026 SRE=1921091786 I'm having a hard time wrapping my head around this behavior. Could this be caused by a transit device (firewall/NAT) mucking about with the SACK option data? Thanks, Kevin asked 02 Dec '14, 10:10  Qwert |
2 Answers:
Thanks to another thread for putting me on the right track. This is looking like a /?/cosmetic/?/ anomaly due to TSO in use by the NIC. There seems to be a set value that the NIC/TCPstack/(wireshark) is applying to the SLE/SRE values on a per session basis. answered 02 Dec '14, 15:00 Qwert |
Wow .. been a while since I've been on this site. This had nothing to do with TSO, and in hindsight, I recognize that my assumption to that effect was based in ignorance. This behavior was, indeed, due to a load balancing appliance operating in inline mode that was not supporting SACK rewrites. live-and-learnanswered 24 Sep '15, 15:03 Qwert edited 24 Sep '15, 15:06 |
