MINT MTU

  • 0
  • 1
  • Question
  • Updated 1 year ago
  • Answered
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 ?
Photo of Aviv Kedem

Aviv Kedem

  • 1,714 Points 1k badge 2x thumb

Posted 1 year ago

  • 0
  • 1
Photo of Timo

Timo

  • 3,210 Points 3k badge 2x thumb
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.
Photo of Aviv Kedem

Aviv Kedem

  • 1,714 Points 1k badge 2x thumb
As far as I know in most LAN networks is about 1456-1472 but not 1500. PPPOE 1392. VPN's about 1460.
Photo of Timo

Timo

  • 3,210 Points 3k badge 2x thumb
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.
Photo of Aviv Kedem

Aviv Kedem

  • 1,714 Points 1k badge 2x thumb
I need the official answer for the question.
Thanks
Photo of Ondrej Lepa

Ondrej Lepa, Employee

  • 5,638 Points 5k badge 2x thumb
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 ping
So 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
(Edited)
Photo of Aviv Kedem

Aviv Kedem

  • 1,714 Points 1k badge 2x thumb
Thanks for your reply.
Just yesterday I saw some AP failed to adopt to VC because of maximum MTU of 504.
But allowed MTU size can be configured only between 900-1500, and in this condition is caused adoption to fail at all. So this is some extreme situation but it caused Me to think about MTU size.
Photo of Ondrej Lepa

Ondrej Lepa, Employee

  • 5,638 Points 5k badge 2x thumb
Hi Aviv,

you might be right - testing that in Lab I see that adoption / configuration push could be quite higher
ROUTER#service pktcap on bridge filter mint and host 88.88.88.88
<omitted>
7 9:21:18.149772 UDP: 88.88.88.88 > 192.168.7.205 ports 24576 > 24576, data length 72, DSCP 0| RDP/STREAM 4D.87.1A.F0/58143 > 12.34.04.07/11 adoption/config, AF, seq 55626, ack 8144, win 10, data 0
6 9:21:18.149758 UDP: 88.88.88.88 > 192.168.7.205 ports 24576 > 24576, data length 877, DSCP 0| RDP/STREAM 4D.87.1A.F0/58143 > 12.34.04.07/11 adoption/config, AP, seq 55625, ack 8144, win 10, data 805
MTU of 504 is very low value - this could cause general problems to MINT communication. I'd stay with formula
 Highest DF PING MTU - 100 bytes = WAN crossing MINT MTU
Regards,
Ondrej
(Edited)
Photo of Aviv Kedem

Aviv Kedem

  • 1,714 Points 1k badge 2x thumb
Thanks