topic RE: MINT MTU in ExtremeWireless (WiNG)

MINT MTU

Aviv_Kedem — Wed, 26 Jul 2017 10:42:00 GMT

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 ?

RE: MINT MTU

Timo1 — Wed, 26 Jul 2017 10:46:00 GMT

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.

RE: MINT MTU

Aviv_Kedem — Wed, 26 Jul 2017 10:46:00 GMT

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

RE: MINT MTU

Timo1 — Wed, 26 Jul 2017 10:46:00 GMT

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.

RE: MINT MTU

Aviv_Kedem — Wed, 26 Jul 2017 11:00:00 GMT

I need the official answer for the question.
Thanks

RE: MINT MTU

Ondrej_Lepa — Wed, 26 Jul 2017 11:00:00 GMT

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

RE: MINT MTU

Aviv_Kedem — Wed, 26 Jul 2017 11:00:00 GMT

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.

RE: MINT MTU

Ondrej_Lepa — Wed, 26 Jul 2017 11:00:00 GMT

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

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 805MTU 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 MTURegards,
Ondrej

RE: MINT MTU

Aviv_Kedem — Wed, 26 Jul 2017 11:00:00 GMT

Thanks