MINT MTU

[Aviv_Kedem]

Generic question about MINT MTU.
Default MTU is 1500 and in most cases is not meet the netwotk's MTU.
Is always recommended in L2/L3 adoption to set the MTU suitable for the network?
Or just only adjust it when there is some issues ?

[Ondrej_Lepa]

Hello Aviv,

I cannot give you official answer, but maybe some ideas...

So this is the default configuration:
VX(config-mint-policy-global-default)# show context include-factory mint-policy global-default udp port 24576 mtu 1500
no level 2 area-id
router packet priority 0
no lsp checksum no lsp disable-suspect-lsp-checks When you do any kind of tunneling, MPLS or WAN crossing, you have to make sure this MTU size will be processed correctly, right? That is obvious. .

To verify the MTU size will pass I'd recommend to check with don't fragment option when pinging the remote site
VX#ping 88.88.88.88 dont-fragment size 1472
PING 88.88.88.88 (88.88.88.88) 1472(1500) bytes of data.
1480 bytes from 88.88.88.88: icmp_seq=1 ttl=63 time=0.782 ms
VX#ping 88.88.88.88 dont-fragment size 1473
PING 88.88.88.88 (88.88.88.88) 1473(1501) bytes of data.
From 192.168.7.205 icmp_seq=1 Frag needed and DF set (mtu = 1500)Then, using over-sized MTU for MINT will cause fragmentation also.
UDP will handle that, but it is better not to bring another potential issue to over-WAN communication:
VX#mint ping 4D.87.1A.F0 size 1472 MiNT ping 4D.87.1A.F0 with 1472 bytes of data. Response from 4D.87.1A.F0: id=16777216 time=0.751 ms ROOT#service pktcap on bridge filter mint Capturing up to 50 packets. Use Ctrl-C to abort. 1 9:15:50.894618 UDP: 192.168.7.205 > 88.88.88.88 ports 24576 > 24576, data length 1534, IPv4 fragment id 53959, offset 0, DSCP 0| DGRAM 12.34.04.07/63569 > 4D.87.1A.F0/15 ping 2 9:15:50.894618 UDP: 192.168.7.205 > 88.88.88.88 IPv4 fragment, IPv4 fragment id 53959, offset 1448, IPv4 length 106, DSCP 0 3 9:15:50.894755 UDP: 88.88.88.88 > 192.168.7.205 ports 24576 > 24576, data length 1534, IPv4 fragment id 23669, offset 0, DSCP 0| DGRAM 4D.87.1A.F0/15 > 12.34.04.07/63569 ping 4 9:15:50.894755 UDP: 88.88.88.88 > 192.168.7.205 IPv4 fragment, IPv4 fragment id 23669, offset 1448, IPv4 length 106, DSCP 0 So you might notice that MINT adds something (proprietary header) to UDP packet and this is not the smallest addition.
Eventually you have to go as low as 1386 bytes MTU to pass without fragmentation
VX#mint ping 4D.87.1A.F0 size 1386
MiNT ping 4D.87.1A.F0 with 1386 bytes of data.
Response from 4D.87.1A.F0: id=16777216 time=0.699 ms
ROOT#service pktcap on bridge filter mint
Capturing up to 50 packets. Use Ctrl-C to abort.
1 9:24:02.688107 UDP: 192.168.7.205 > 88.88.88.88 ports 24576 > 24576, data length 1448, DSCP 0| DGRAM 12.34.04.07/62395 > 4D.87.1A.F0/15 ping
2 9:24:02.688238 UDP: 88.88.88.88 > 192.168.7.205 ports 24576 > 24576, data length 1448, DSCP 0| DGRAM 4D.87.1A.F0/15 > 12.34.04.07/62395 pingSo now the question is - does MINT must not be fragmented?

The answer is not as simple. If you are not using Level2 MINT tunneling you won't experience any differences setting low MTU (usual MINT control packet size is between 70 - 200 bytes), but if you do use tunneling, you might see improvement in matter of throughput - the smaller packet to be lost, the better.

If you are asking me - check MINT tunneling and if used, go to 1386. If not - forget about MTU size when it comes to MINT global policy.

Regards,
Ondrej

[Timo1]

I think to adjust the MTU it's always a good idea. But in most networks with L2/L3 1.500 should be possible?
I change it just in global configuration with L3 over WAN, because it's a global setting for all sites.

[Timo1]

Ok, let's change my answer, we need get problem with 1.500 within a LAN site. Just with WAN connections we get problems and fix the size. Sometimes we need to use settings lower than 1.400 bytes.

[Aviv_Kedem]

As far as I know in most LAN networks is about 1456-1472 but not 1500. PPPOE 1392. VPN's about 1460.