Mtuissues
This tutorial aims to shed some light on how Vermont deals with Path MTU (PMTU) issues. Please note that this is only relevant if you use UDP or DTLS over UDP as the transport protocol. In contrast, if SCTP is used, the operating system deals with PMTU issues and you, as the user, do not have to worry about it.
As a general principal, we always want to avoid IP fragmentation for various reasons including suboptimal performance which is due to the increased workload caused by fragment reassembly. When UDP is used, an IP packet that caries IPFIX data consists of the IP header, the UDP header and exactly one IPFIX message. Since the IP und UDP headers are of constant length in most situations, the length of the IP packet results from the length of the IPFIX message plus a constant value which is the overhead caused by IP and UDP.
Now, if we want to avoid IP fragmentation, we have to make sure that the IP packets fit inside the PMTU. To achieve this goal, we have to ensure that our IPFIX messages are not longer than a certain threshold. This threshold can be easily calculated from the PMTU. However, the situation becomes more tricky if DTLS over UDP is used because DTLS adds another intermediate header. The nasty detail is that the size of the DTLS record header depends on the negotiated cipher suite. What Vermont ends up doing is that it assumes the longest DTLS record header possible.
Determining the correct PMTU is not trivial. There are basically two ways in which Vermont can learn about the PMTU:
- configuration by the administrator
- through a process called PMTU discovery
The latter is certainly the one that is more user friendly because the administrator can just lay back and do nothing. That said, it should be noted, though, that PMTU discovery is not available on all operating system platforms. Some operating systems do not provide PMTU discovery at all. Others carry out PMTU discovery but do not provide the application with the result. In an ideal situation, the OS performs PMTU discovery and provides the application with the result.
If you are lucky enough so that your OS is cooperative in terms of PMTU discovery and no router or firewall on the path blocks the ICMP packets which are necessary for PMTU discovery, then you can lay back. If this is not the case, you can still configure the PMTU manually.
The MTU that should be assumed by the Exporter can be configured via the element which is part of the element. See ModuleConfiguration#ipfixexporter for more information.
A value of 0 (the default) indicates that PMTU discovery should be turned on. If the platform does not support PMTU discovery, a conservative default value (1400 at the time or writing) is used instead.
###Linux Linux has superior support for PMTU discovery. If all routers and firewalls on the path behave correctly, you can use PMTU discovery by setting mtu to 0.
FreeBSD has PMTU discovery but does not provide the result to the application. It is therefore advisable to configure the MTU manually.