WLC connection lost when switches trunk

Hi,

I think this is a related question.
I have this set up that stops working at some point and I can’t figure out why.

Sw1 connects to the DHCP server, to the WLC and to Sw2 and Sw3. WLC has management IP address of 10.0.0.11 and server is 10.0.0.10.

Sw2 connects to Lightweight APs and to the end-user laptop.
The APs and the laptop use DHCP and the laptop can log in to the WLC through its GUI - https://10.0.0.11.

Everything works fine, wireless users authenticate to APs, APs have CAPWAP tunnels to the WLC.

When I create VLANs for management and sales etc. I assign the laptop’s interface on Sw2 to the management vlan, create other VLANs and set up a trunk between Sw2 and Sw1, and from Sw1 to the WLC, I cannot access the WLC’s GUI anymore. The native vlans on trunks are the same and other VLAN’s settings are fine, the interfaces trunk, but the connection between the laptop and the WLC’s GUI is lost.

Can anyone explain the problem with this set up, please?
Does each vlan need a dhcp pool?

Thank you in advance
Marcin

Hello Marcin

There could be several things that are going on here. Initially, you are able to access the DHCP server (since the laptop obtains an IP address) and the WLC from the laptop since they are on the same subnet and same VLAN.

Now when you introduce new VLANs, you must ensure that each VLAN has its own IP addressing space, that is, a defined subnet, and that the DHCP server is providing IP addressing information for all of these subnets. You must also ensure that the devices you want on the management VLAN (laptop and WLC) are indeed on the same VLAN, and those using DHCP (the laptop) are able to reach the DHCP server. Additionally, you have to make sure that these new VLANs are reaching the access points and that you have configured the appropriate SSIDs that correspond to these VLANs (if you are applying multiple VLANs to the APs). Finally, if you want communication between hosts that exist on different VLANs and different subnets, you must ensure that routing is configured.

Let us know how you get along in your troubleshooting efforts!

I hope this has been helpful!

Laz

Thank you Lazaros for getting back to me, first of all!

My configuration was pretty much as you suggested - I use L3 switch and it served as a DHCP server with assigned pools to particular vlans.

The solution to my problem was that on the WLC my management interface was left untagged and thus I needed to set the management vlan 10 on trunks as: switchport trunk native vlan 10.
Now everything is working fine, but another question comes up: should the management vlan be left untagged - that is what I thought - or should it be tagged with the management vlan number and then the native vlan set to a different number? What is the standard and the recommended approach?

Best regards
Marcin

Hello Marcin

Remember that tags are placed on frames that exit a trunk interface. Tags have no meaning when we’re talking about traffic that enters and exits access ports. Should you tag your management frames on the trunks you have configured? I would say yes. Untagged frames always use the native VLAN, and the native VLAN can be leveraged for malicious attacks. Also, tagging will allow you to implement QoS parameters for your management traffic to ensure that it gets through even if you have a lot of congestion on your network.

This is not to say that untagged management traffic will not work, it will work just fine. However, the best practice in my opinion would be to tag it for the reasons described above.

I hope this has been helpful!

Laz

Thank you very much for your explanation. From now on I will tag my management interface at the WLC.

1 Like