• September 19, 2020, 02:50:58 AM
Welcome, Guest. Please login or register. Registration is free.
Did you miss your activation email?

Author Topic: MINT discovery problems after L2 network physical topology change  (Read 3688 times)

0 Members and 1 Guest are viewing this topic.

Offline Wojtek Nawrot

  • Rookie
  • **
  • Posts: 2
Hello,
We have RFS400 (in cluster) + 26 x ap622. All runing the newest software 5.7.
MINT communication is in Vlan 3817 (RFS controllers and APs in the same vlan 3817).

APs are connected to several LAN switches including 3com 4500 series, Cisco (Linksys) SG300/SF300 and Juniper EX.
By Saturday everything worked fine. Problems occurred after LAN reconfiguration. We simplified network topology by removing several switches and some APs stopped seeing neigbours.
Normally the AP should see all other APs and controller sharing the same native vlan.

However an example ap622-C4-3 sees only neighbours residing on the same switch:

ap622-C4-3>show mint neighbors
3 mint neighbors of 19.E3.88.48:
19.DC.D2.FA (rfs4000-DCD2FA) at level 1, best adjacency ip-192.168.1.2:24576
19.E3.D4.D0 (ap622-C4-1) at level 1, best adjacency vlan-3817
19.E4.19.CC (ap622-C4-2) at level 1, best adjacency vlan-3817

RFS is also displayed as a neighbour but it’s IP was configured manualy on the AP.

Moreover. When displaying mint info, addresses of RFS are shown:

ap622-C4-3>show mint info
Mint ID: 19.E3.88.48
3 Level-1 neighbors
Level-1 LSP DB size 27 LSPs (6 KB)
0 Level-2 neighbors
Level-2 LSP DB size 0 LSPs (0 KB)
Level-2 gateway is unreachable
Reachable adopters: 19.DC.D2.FA,19.DC.D3.0E

but MINT ping towards RFS doesn’t work:

ap622-C4-3>mint ping 19.DC.D2.FA
MiNT ping 19.DC.D2.FA with 64 bytes of data.
Ping request 1 timed out. No response from 19.DC.D2.FA
Ping request 2 timed out. No response from 19.DC.D2.FA

Pings to neighbouring APs within the same Ethernet switch work fine:

ap622-C4-3>mint ping 19.E3.D4.D0
MiNT ping 19.E3.D4.D0 with 64 bytes of data.
 Response from 19.E3.D4.D0: id=1 time=0.667 ms
 Response from 19.E3.D4.D0: id=2 time=0.405 ms


Conclusion.
-   Network physical topology change made some APs not see [MINT] their neighbours residing on other switches (despite they can ping [icmp] each other). Access switches were not replaced or removed. We only removed some distribution switches
-   Adoption was enforced by entering RFSs IPs manually on the APs (without this, APs wouldn’t discover the controllers)
-   APs with limited MINT Level1 connectivity are unstable – they adopt and unadopt using IP connection with the controller (there were also timeouts when uploading them with captive portal customized files, etc)
-   We also disabled CDP and LLDP in AP profiles and changed mint MTU size to 1468 (according to hints in best practices document).
-   Controller vlan is configured properly and applied to all trunks in the network as tagged. On ports where APs or RFS reside it is configured as native-untagged.

Any suggestions or similar problems?
Thank you in advance
Wojtek


Offline McNulty

  • Sr. Member
  • ****
  • Posts: 217
Re: MINT discovery problems after L2 network physical topology change
« Reply #1 on: July 21, 2015, 11:31:40 PM »
Just some quick ideas:

Are your switches allowing the MiNT ethertype to pass?
Is the VLAN 3817 trunked to each and every switch and RFS?
Is there a native vlan mismatch?

Offline Wojtek Nawrot

  • Rookie
  • **
  • Posts: 2
Re: MINT discovery problems after L2 network physical topology change
« Reply #2 on: July 22, 2015, 06:02:00 AM »
Hi McNulty,


1) Are your switches allowing the MiNT ethertype to pass?
2) Is the VLAN 3817 trunked to each and every switch and RFS?
3) Is there a native vlan mismatch?

1) No. Switches had never had it set. As I said we have a number of switch vendors/models and there is no command including MINT or MLCP in global config or an interface of any switch.

The bigest change we made was replacement of  Cisco SG300 core switch by Juniper EX switch. The core switch aggregates traffic from all access switches in LAN and I suspect that it may block MINT communications. From the other hand there are some access switches (with APs attached) that are connected to Juniper EX directly and these APs have no problem with discovering neighbours...
Juniper EX is more advanced than Cisco SG300 and it may need aditional configuration.

- is there any WING documentation describing MINT protocol and necessary ethertype filters configuration? I didn't find anything...
- do you have any examples of ethertype filters configuration including Juniper EX switches?
- what is ethertype code for MINT?

2) Vlan 3817 is set as tagged in trunks between the switches, and as untagged (native) between switches and APs/Controllers. L3 (IP) communication works between all WING devices within vlan 3817.

3) There is no native vlan mismatch. Trunk ports of APs/RFSs and access switches are configured in the same way: data vlans as tagged and control (3817) vlan as untagged (native).