Forum Discussion
Nimbostratustcp Protocol Profile with short client MSS
We have an office that is connected via PPPoE over DSL. PPPoE has an 8-byte overhead, so client connections coming from this office present an MSS of 1452.
When a client in this office connects to one of our Virtual Servers which is configured with a Protocol Profile (Client) of "tcp", I see an odd behavior. The F5 consistently delivers a packet with 1452 octets, and then one with 8 octets. This happens repeatedly, long after multiple packets have been buffered in the F5 from the server. (The server is on a normal Ethernet and uses an MSS of 1460.) I see what seems to be an endless sequence of these.
We have one LTM pair at 11.2 and one at 11.3. This happens with both instances.
When the same client accesses a different Virtual Server that is configured with "tcp-wan-optimized", I do not see this behavior. I see it do one 1452/8 pair, and then a steady stream of 1452 segments, like I expect.
I've reviewed the differences between "tcp" and "tcp-wan-optimized" on our 11.2 machine, and it seems like the only one that might matter is "Nagle's algorithm". I can conceive of this one mattering at the beginning, but not after a large number of packets have been buffered. (The client is in Australia and we are in the eastern US, so the server is able to fill the buffer on the F5 before the first ack comes from the client side.)
Has anyone else seen this behavior?
4 Replies
mimlo_61970Cumulonimbus
Are these HTTP apps, and if so are any of them using fast http profile? There is an mss override option in fasthttp profiles, just curious if that is the difference between the two. Also, is the 8 byte packet a fragment of the 1452 packet?
- Craig_Jackson_2
These are all HTTP apps. These are Standard Virtual Servers.
Both have OneConnect enabled.
- Craig_Jackson_2
As for the 8 byte packet, it comes in sequence such that it would be the last 8 bytes of a 1460-byte packet which arrived from the server.
- mimlo_61970
I haven't seen this exact issue, but have had problems running VPNs over PPPoE connections. Path MTU discovery completely breaks down in that situation, and 1460 packets just get lost. The solution to this has been to adjust the tcp mss on the PPPoE router to be 1452.
In this case, I would expect path MTU discovery to work, and adjust accordingly.
