Question

Global Mint

  • 10 January 2019
  • 7 replies
  • 625 views

Userlevel 2
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://gtacknowledge.extremenetworks.com/articles/Q_A/What-is-recommended-MINT-MTU-size

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

7 replies

Userlevel 2
Spoke too soon one of the AP's the one I swopped out has disappeared from the RFS GUI , On The AP7532's I'm seeing Dot11i handshake timeouts for anything trying to connect to VLAN10
Userlevel 2
Hi Chris
I have Both AP's now checking in to the RFS, I ended up adding the controllers to the AP's under controller adoption. I also created a new profile for these two AP's only in the RFS and under adoption I set it to pool 1 routing level 1 and added the host ( RFS )
This seems to have worked,
Over in the remote building I was able to get an IP on VLAN 1 which has never been an issue, and on VLAN 10 which has been the issue, But this was only on the AP on the first floor, So I connected to the AP's in the remote building as they were getting IP addresses and compared the setting, on the AP I could not get an IP on VLAN 10 under Access Point it was showing no information - i.e Name /location Version etc but the one that was working did. So I have swopped the AP out and then tried to connect to VLAN 10 and I got an IP, So Just waiting on users turning up now and seeing if the MU's will connect to Vlan 10.
Userlevel 5
Regarding the tree view having the appearing/dissapearing issue....this tells me that there's an RF Domain Manager election issue. This is what you'll see happen in the tree.

How are the APs adopted? Level-1MiNT? Level-2 MiNT?
The fact that you are tunneling traffic tells me either your APs are level-1 MiNT adopted or you are tunneling over Level-2 MiNT...so I can't tell.

If the APs are level-1 MiNT adopted, then the controller should be the RF Domain Manger, in which case you shouldn't be seeing the weird issue withe the APs in the tree.

If the APs are level-2 MiNT adopted, then you need to make sure that you have defined the Control-VLAN for that RF Domain (configuration for the Control VLAN is in the RF Domain setup). If you don't, that tree issue will occur.
Userlevel 2
Hi Chris
this gets stranger by the second, So I have changed the MTU value, in the tree view one of the AP's is now showing but not the other , If I connect to the AP and look at the events, I can see devices trying to connect to the VLAN1 & VLAN10, but failing with dot11i handshake timeouts and association denied invalid MDIE
crazy
Userlevel 5
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).
Userlevel 2
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 ?
Userlevel 5
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.

Reply