AltocumulusVPN 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?
NimbostratusThe error message you’re encountering indicates that fragmented IP packets are being dropped due to the specified minimum fragment size constraint. By default, the minimum fragment size is set to 552 bytes. You can create an iRule that selectively handles fragmented packets based on specific conditions. In your case, you want to disregard the ‘tm.minipfragsize’ constraint for certain Virtual Servers.
when IP_FRAGMENT {
# Check if the fragment size exceeds the default threshold (552 bytes)
if {[IP::frag_size] > 552} {
# Allow the fragmented packet to pass through
IP::forward
}
}
AltocumulusThank 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.
AltocumulusUnfortunately, 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?
Cumulonimbusas 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
AltocumulusThere'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.
Cumulonimbusdefault 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.
EmployeeOne 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.
AltocumulusThanks 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.