Global Mint

[Phil_storey]

Hi all and Happy New Year

I have been trying to figure out why 2 AP's that service clients in a remote building are not showing up in the RFS view, I came across some information about Mint. So from the controller I did the ping

ping 172.xxx.xxx.xxx dont-fragment size 1500

PING 172.xxx.xxx.xxx (172.xxx.xxx.xxx) 1500(1528) bytes of data.
From 172.xxx.xxx.xxx ( contoller ) icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 172.xxx.xxx.xxx ( contoller ) icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 172.xxx.xxx.xxx ( contoller ) icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 172.xxx.xxx.xxx ( contoller ) icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 172.xxx.xxx.xxx ( contoller ) icmp_seq=1 Frag needed and DF set (mtu = 1500)
0 packets transmitted, 0 received, +5 errors

so as per the guide I dropped it by 8 each time until I got a response

ping 172.xxx.xxx.xxx dont-fragment size 1472
PING 172.xxx.xxx.xxx (172.xxx.xxx.xxx) 1472(1500) bytes of data.
1480 bytes from 172.xxx.xxx.xxx: icmp_seq=1 ttl=64 time=2.10 ms
1480 bytes from 172.xxx.xxx.xxx: icmp_seq=2 ttl=64 time=6.91 ms
1480 bytes from 172.xxx.xxx.xxx: icmp_seq=3 ttl=64 time=4.26 ms
1480 bytes from 172.xxx.xxx.xxx: icmp_seq=4 ttl=64 time=3.18 ms
1480 bytes from 172.xxx.xxx.xxx: icmp_seq=5 ttl=64 time=3.51 ms
--- 172.xxx.xxx.xxx ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 2.103/3.996/6.919/1.619 ms

The Client AP is at the end of a wireless Bridge that utilises 2 AP 7532, The bridge shows up in the mesh point view under stats.

I connected to one of the AP's in the remote building and had a play around with the MTU settings the AP briefly appeared in the GUI view on the RFS.

So Should I change the Global Mint MTU size ? the Guide I was looking at is this one
https://extremeportal.force.com/ExtrArticleDetail?an=000089595

but the command to alter the Mint MTU does not see to work for wing 5.8

Also the mint ping does not seem to work in wing 5.8

I'm not sure if the VLANS ( Informations ) are carried in the MINT protocol across the wireless bridge as VLAN 1 is working fine and clients are getting IP addresses but VLAN 10 which has and ADSL router on it to give out IP addresses fail to connect, this is why I was looking at the MINT protocol.

But If I give a device a static IP in the range of the ADSL router DHCP server they work. The Network Switches that the AP's connect to are AVAYA ERS500xx and I did read that there was a bug in the firmware that was malforming the DHCP request from the DHCP servers/devices. So to ensure this was not the root cause the IP DHCP-Snooping was disabled.as per another guide from AVAYA

I may be looking in completely the wrong place but any advise is gratefully received

[ckelly]

On the AP, (for a locally bridged WLAN setup) to create a 'trunk' port, you will need to at least add the VLAN entries in the Virtual Interfaces listing (no addressing is needed though for that VLAN unless using a service/feature that actually requires that the VLAN have an IP address)...and then in the ge1 setup, configure it as Trunk, set the Native VLAN, and then specify any VLANs in the Allowed VLANs list.

Understand though that with your current Tunneled WLAN setup - The VLAN traffic at the far end of the mesh is being encapsulated within the Mesh protocol as it traverses the Mesh connection. Once it reaches an AP on the other end of the mesh (with a wired network connection) it's decapsulated but then that VLAN traffic is still encapsulated within MINT itself. That VLAN traffic is then carried back to the controller inside of MiNT....which means that no VLANs have to be defined on the AP/switches in order for that encapsulated traffic to get back to the controller - If a successful MiNT connection already exist between the controller and AP, then you would be good to go. That's all it takes. You'll also need to define the VLANs (and setup trunk port) on the controller though because once those encapsulated VLANs within MiNT are unpacked inside the controller, they need to get off of the controller and back onto the LAN...so the controller's interface needs to be setup to allow for that.

Once you go with a locally bridged WLAN setup though, you have to take into account having trunk ports setup everywhere (APs and switches. Not the controller unless for some reason you wanted to also bring that traffic back to the controller).

To set the MiNT MTU in the CLI: (Set this on the controller)
# config
# mint-policy global-default
# mtu
# commit write

In the GUI:
Configuration -> Devices -> MiNT Policy -> (mtu😃

As for the MTU value, it's hard for me to say. But if you think that the network path won't ever change (between the APs and the controller) then you could just leave it at 1472. My suggestion to maybe lower it was just to act as a small buffer in case what appears to be the current 1472 MTU setting ever changed (lower).

[Phil_storey]

Hi Chris
thankyou for the reply

currently the setup for the AP's is tunnelled, The plan is to move it to locally bridged. On the bridge the allowed VLAN is set to 1,4096 ( so all VLANs ) The network switch ports either end of the bridge are set to allow VLAN 1,10. so it should be passed.
the network ports the Bridge AP's connect to are set as Trunk ports

On the Bridge AP's under ethernet ports ge1 is set to allow all VLANS & under virtual interface I have only VLAN 1 would I need to add VLAN 10 as well ? at both ends ?
I'm not sure if it will cause a problem as the current setup is tunnelled for the client AP's


What is the command for setting the Global Mint MTU ? the one in the guide does not seem to work with wing 5,8

Do you think the MTU size should be set to 1462 instead of 1472 ?

[ckelly]

You're on the right course with the MiNT MTU testing. Based on your testing, set the Global MiNT MTU to 1472...or maybe even one notch lower just in case.
As for what you are seeing with things not working correctly in 5.8, I can't answer that. That's not an issue I'm aware of. It *should* work.

VLANs won't be carried through MiNT unless you are tunneling using MiNT. If your WLANs are all locally bridged, then MiNT carries no user-data VLANs. Across the mesh (MCX) connection is no different. (you do/can carry user VLAN data across the mesh connection)

As for VLAN-10 issue, check to make sure that VLAN-10 is in the allowed VLAN listing for your Meshpoint setup. If not, then VLAN-10 traffic won't be carried across the mesh connection.