Forum Discussion
Neo_Ph
Altocumulus
AltocumulusVPN fragmented IP packets dropped
VPN fragmented IP packets being dropped by the Big-IP, because of 'tm.minipfragsize > default=552' (K52103592) TCPDump showed the ip packets arriving on the client-side and never being forwarded on the server-side.
Any idea if an iRule could disregard 'tm.minipfragsize > default=552' for specific Virtual Servers, without affecting other Virtual Servers?
Neo_PhThank you for your suggesstion. I was looking for commands and events related to fragmentation, but didn't find it in their respective master lists. I'll have it tested in Lab and provide feedbacks.
- Neo_Ph
Unfortunately, IP_FRAGMENT and IP::frag_size aren't valid event or commands on version 15.1.10.
robert1997b do you have references for those command/event that can help me understand?
- zamroni777
Nacreous
as recommended by K52103592 referred by the error log, it is better if you solve the MTU matter.
executing irules for every IP fragment might cause performance problem.enabling jumbo frame (MTU=9000 bytes) might help.
i assume the f5 resides behind router/switch which most of them supports jumbo frame nowadays.https://en.wikipedia.org/wiki/Jumbo_frame
- Neo_Ph
There's a VPN tunnel in the picture, that is forcing the MTU to 1400 -- hence why we get packets with less than 552bytes & with the MF set.
I agree that performance might become an issue. What would be a good option is: to limit performance problems by creating a new VS for all remote VPN sites, with the same pool members. The iRule would only be used on that new dedicated VS for remote VPN sites traffic only.
Thanks for your feedback.- zamroni777
default ethernet mtu is 1500 bytes.
the 100 bytes difference to vpn's 1400 might be cause of the small fragment.enabling jumbo frame 9000 bytes mtu on physical interface means adjacent switch/router will less likely to send fragmented payload to the f5.
- Lucas_Thompson
Employee
One advantage of BIG-IP's full-proxy architecture is that you can have it adjust the TCP MSS on the server-side of the flow so that a connection initiated from outside can have a different effective packet size. You can do this inside the TCP profile using "Proxy Maximum Segment" and "Max Segment Size". If you want to try it, make a new TCP profile with those options and apply it to a new more specific L4 virtual server to catch and forward the VPN traffic.
This would work when the SERVER is sending a lot of data to the client, but not if the CLIENT is sending a lot of data to the server, because the MSS info comes from the client's side of the connection (in our full-proxy case there are 2 "client sides", one is big-ip and one is the client).
Of course this isn't helpful for UDP or other traffic, but for TCP it should prevent these little fragments from the server.
- Neo_Ph
Thanks for the suggestion. In my case it's UDP/1812 being affected when the end-users sends TLS EAP response containing its Certificate, key exchange etc.. TCP-MSS wont help in that case.
