What exactly is the difference between TCP packet length in bytes and MTU size?? Is it OK to have to have TCP packet length in bytes higher (for example: 1845) than MTU size (1500) when we see it in Wireshark trace? asked 10 Apr '17, 15:04 armodes |
2 Answers:
TCP length must stay equal or below MTU minus the IP and TCP header size. E.g. if the MTU is 1500, the TCP length should be less or equal to 1460, (MTU 1500 - 20 Bytes IP header - 20 Bytes TCP header). If you see packets with higher length (e.g. 1845) it could be a problem, but most likely it's measurement error. See https://blog.packet-foo.com/2014/05/the-drawbacks-of-local-packet-captures/ answered 10 Apr '17, 15:09 Jasper ♦♦ |
The most common situation where I see TCP length larger than the MTU is when Wireshark is being run on the sending system, TCP Segmentation Offloading is being used, and Wireshark captures the outgoing packets before the NIC card has actually packetized them. If this interferes with the analysis you can either disable the Segmentation Offloading (often not possible), or capture from the network via a SPAN port or a tap. answered 10 Apr '17, 15:25 djdawson |
Jasper, but to keep the TCP packet lengths equal or below MTU size, we have to turn the TCP segmentation feature OFF. However, the problem when we do that is that we can not utilize the maximum bandwidth. For example: the performance for a 1gbps - we get around 370mbps - which i think is so poor. This got me confused.
No, that's not true. The segmentation feature puts the task of segmenting packets on the card, not the CPU, so if you do a local capture it shows incorrect values. On the wire it's always correct. Which is why you need to start capturing with a SPAN port or a TAP. That's the only way to see the real packets.
OK. I am doing all this on a virtual environment and capturing the traffic on the monitor (between the sender and the receiver). I don't have that physical switch in place now, is there any way to do it on a virtual environment?
I'm not sure, maybe if the monitor device is in bridge mode. But speed tests in that kind of environment are generally not very reliable, so if you're trying to prove you can get maximum bandwidth it's usually much better to do it on a physical link.