ExtremeWireless (WiNG)

  • 1.  MINT MTU

    Posted 07-26-2017 03:42
    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 ?



  • 2.  RE: MINT MTU

    Posted 07-26-2017 03:46
    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.


  • 3.  RE: MINT MTU

    Posted 07-26-2017 03:46
    As far as I know in most LAN networks is about 1456-1472 but not 1500. PPPOE 1392. VPN's about 1460.


  • 4.  RE: MINT MTU

    Posted 07-26-2017 03:46
    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.


  • 5.  RE: MINT MTU

    Posted 07-26-2017 04:00
    I need the official answer for the question.
    Thanks


  • 6.  RE: MINT MTU

    Posted 07-26-2017 04:00
    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 [/code] 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)[/code]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 [/code]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[/code]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


  • 7.  RE: MINT MTU

    Posted 07-26-2017 04:00
    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.


  • 8.  RE: MINT MTU

    Posted 07-26-2017 04:00
    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


  • 9.  RE: MINT MTU

    Posted 07-26-2017 04:00
    Thanks