3850 as a WLC and other controllers co-existence

[jmcburnett2]

situation is a 3850 and a 2504 on the same LAN.

The 2504 is connected to the 3850.

there are 30 APS in the network and 9 of them cable directly to the 3850.

The 2504 AP management VLAN is 253 and the 3850 is configured as 254

whenever wireless management vlan 254 is entered ALL APs drop from the 2504.

BOTH are configured as MC, and have been rebooted.

The 2504 is running 8.3 code to support some older APs.

TAC case is open, but after explaining the above 4 times in an hour and drawing a visio diagram of it in the webex, I am unsure if he even understands.

As I understood it here-

When the management vlan was different from the management vlan used by the 2504 the capwap traffic should not have been intercepted by the 3850.  but that is not what I am seeing.

anyone have ideas?

[Flavio Miranda]

Hi

Maybe I am more confuse then the TAC guys but what you mean by management vlan on switch ?

If switch port where the AP is connected is in the same vlan as the switch port where the 2504 is connected, there's no way the AP doesn't join. They would be on the same broadcast domain.

 If doesn't take a look on AP licensing, time and date, AP model and country, etc.

-If I helped you somehow, please, rate it as useful.-

[jmcburnett2]

The 3850 can serve as a WLC with the licensing enabled.

With the command "wireless management interface vlan #" that enables the 3850 to serve as a WLC.

When this command is enabled the CAPWAP packets are intercepted by the 3850 BEFORE they get to the 2504 so the AP's can never join the 2504.

the documentation leads me to believe that if the 2504 AP management enabled IP address/interface is vlan 253 and the 3850 is set to wireless management interface vlan 254 then the interception is not supposed to happen.

When the APs have to cross into the 3850 on ANY port and the 2504 is an egress out of the 3850 the CAPWAP packets are intercepted hence the problem. This appears to be contradictory of the documentation for the command "wireless management interface vlan #".

Does that make sense?

Jim

[Rasika Nayanajith]

what code you running on your 3850 ? Which vlan you put your APs ? Unless AP configured on vlan 254, it should not behave like that.

On AP registered to 2504, did they have Primary Controller Name/IP (pointing toward 2504) configured ?

HTH

Rasika

[jmcburnett2 · Accepted solution]

Ok-- The problem has been solved..

So let's cover all the details here for someone else just in case TAC does NOT raise the bug as requested and get the documentation edited to reflect these findings.


1. WLC2504 is running 8.3.143

2. 3850 is running 16.3.6


APs are all in VLAN 253

Switch is configured to use Wireless management interface vlan 254


In this configuration it made no sense why the APs would attempt to register to the 3850 as it was not using VLAN 253 for wireless management.

The Key is hidden here:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/16-1/configuration_guide/b_161_consolidated_3850_cg/b_161_consolidated_3650_cg_chapter_011010.pdf

Under the section AP Pass Through it said to make sure the APs were on a different VLAN than the VLAN configured as the management wireless.  This highlighted the fact that the switch is intercepting the CAPWAP traffic.  Therefore if the AP is intercepting the traffic on the ACCESS VLAN, and ALL AP's are in a different ACCESS VLAN, then it MUST be intercepting the CAPWAP somewhere else.  The only option left are trunk ports.

That led me to check ALL TRUNK ports and see if ANY are not pruning the 254 VLAN. And yes, against best practice some ports are not filtering/pruning ANY VLANs.  Changed ALL ports to prune VLAN 254 and then set the management vlan to 254.

And then the problem was solved.

This leads me to the details I sent TAC.

The documentation leaves out a VERY important element.
If the 3850/3650 is part of a network where there are multiple switches OR the other WLC is trunked from the 3850, the 3850 will see the capwap packets on trunk port and then intercept them.

To that end, the documentation should be edited to reflect something like the following notes:

When AP Pass through is in use, the 3850/3650 configured as an MC or MA must be configured to strip the supported AP VLAN on ALL TRUNK PORTS leaving the switch.
This can be done by removing the VLAN to be used for the 3850/3650 management VLAN from ALL trunk ports.
Assuming the VLAN for the access points being used for AP Pass Through is vlan 10 this command would look like:
Interface gigabitethernet1/0/1
switchport trunk allowed vlan remove 10

This also needs to include the trunk for the Wireless LAN Controller supporting APs not supported or desired to be controlled by the 3850/3650 .
Best Practice of limiting the VLANS included on a Trunk port would work to solve this issue, but it should be pointed out in the documentation that inclusion of the wireless management vlan on a trunk breaks AP Pass Through.

[Rasika Nayanajith]

thanks for the explanation, It will be useful to many others. 

[jmcburnett2]

You're welcome-- I just hope no one else has to suffer through the issue like I did..

I asked TAC to involve the BU/SME/TME to get the documentation to reflect these findings or have the developer look and see if this is the desired behavior.  If anyone knows who should get this and weigh in from the BU level, please push this to them.  If they contact me, I will gladly provide the TAC Case #.

The information about trunk ports should be included on the AP Pass Through documentation.  If I had a count of how many switch configs I've seen where trunks are NOT properly pruned, it would be massive.....