[FlowAggregator] IPFIX UDP traffic is fragmented when sent to external collector

[antoninbas]

Describe the bug
I have observed that the IPFIX UDP traffic was not respecting the max message size set by the FlowAggregator (calculated based on the configured MTU for the FlowAggregator's eth0 interface). This lead to fragmentation of the UDP messages, and as far as I can tell, the additional fragments were dropped at the source Pod in my testbed (this part I don't know why exactly).

tcpdump: listening on flow-agg-068e4d, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:04:02.067416 52:40:1f:e7:af:ff > ea:8c:29:a6:52:90, ethertype IPv4 (0x0800), length 667: (tos 0x0, ttl 64, id 3666, offset 0, flags [DF], proto UDP (17), length 653)
    10.10.1.7.44864 > 10.96.174.118.4739: [bad udp cksum 0xc671 -> 0xf572!] UDP, length 625
21:04:02.640018 52:40:1f:e7:af:ff > ea:8c:29:a6:52:90, ethertype IPv4 (0x0800), length 1458: (tos 0x0, ttl 64, id 3667, offset 0, flags [+], proto UDP (17), length 1444)
    10.10.1.7.44864 > 10.96.174.118.4739: UDP, length 1447
21:04:03.068010 52:40:1f:e7:af:ff > ea:8c:29:a6:52:90, ethertype IPv4 (0x0800), length 922: (tos 0x0, ttl 64, id 3668, offset 0, flags [DF], proto UDP (17), length 908)
    10.10.1.7.44864 > 10.96.174.118.4739: [bad udp cksum 0xc770 -> 0xfd39!] UDP, length 880
21:04:04.067393 52:40:1f:e7:af:ff > ea:8c:29:a6:52:90, ethertype IPv4 (0x0800), length 1265: (tos 0x0, ttl 64, id 3669, offset 0, flags [DF], proto UDP (17), length 1251)
    10.10.1.7.44864 > 10.96.174.118.4739: [bad udp cksum 0xc8c7 -> 0xafb7!] UDP, length 1223
21:04:07.067504 52:40:1f:e7:af:ff > ea:8c:29:a6:52:90, ethertype IPv4 (0x0800), length 349: (tos 0x0, ttl 64, id 3670, offset 0, flags [DF], proto UDP (17), length 335)
    10.10.1.7.44864 > 10.96.174.118.4739: [bad udp cksum 0xc533 -> 0x19a1!] UDP, length 307
21:04:07.641127 52:40:1f:e7:af:ff > ea:8c:29:a6:52:90, ethertype IPv4 (0x0800), length 1458: (tos 0x0, ttl 64, id 3671, offset 0, flags [+], proto UDP (17), length 1444)
    10.10.1.7.44864 > 10.96.174.118.4739: UDP, length 1477
21:04:08.073854 52:40:1f:e7:af:ff > ea:8c:29:a6:52:90, ethertype IPv4 (0x0800), length 978: (tos 0x0, ttl 64, id 3672, offset 0, flags [DF], proto UDP (17), length 964)
    10.10.1.7.44864 > 10.96.174.118.4739: [bad udp cksum 0xc7a8 -> 0x5fe5!] UDP, length 936
21:04:09.065687 52:40:1f:e7:af:ff > ea:8c:29:a6:52:90, ethertype IPv4 (0x0800), length 1458: (tos 0x0, ttl 64, id 3673, offset 0, flags [+], proto UDP (17), length 1444)
    10.10.1.7.44864 > 10.96.174.118.4739: UDP, length 1516

Note that according to the IPFIX RFC, the UDP messages must not exceed the (P)MTU, and there must not be IP fragmentation:

The maximum size of exported messages MUST be configured such that
the total packet size does not exceed the PMTU. If the PMTU is
unknown, a maximum packet size of 512 octets SHOULD be used.

The UDP messages should be sized correctly.

This is actually caused by a bug in go-ipfix, which has been addressed in vmware/go-ipfix#417.

Versions:
Antrea v2.3.0