Ask the Expert: Cisco Wireless LAN Controllers (WLCs)

[ciscomoderator]

with Cisco Expert Nicolas Darchis

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about how to trobuleshoot, configure and deploy any Cisco Wireless LAN controller with Cisco subject matter expert Nicolas Darchis.

Nicolas Darchis is a wireless and authentication, authorization, and accounting expert for the Technical Assistance Center at Cisco Europe. He has been troubleshooting wireless networks, wireless management tools, and security products, including Cisco Secure Access Control Server since 2007. He also focuses on filing technical and documentation bugs. Nicolas Darchis holds a bachelor's degree in computer networking from the Haute Ecole Rennequin Sualem and a master's degree in computer science from the University of Liege. He also holds CCIE Wireless certification number 25344.

Remember to use the rating system to let Nicolas know if you have received an adequate response.

Nicolas might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Wireless sub-community, Getting Started with Wireless discussion forum shortly after the event.

This event last through Friday June 28, 2013. Visit the community often to view responses to youe questions of other community members.

[Nicolas Darchis]

It is usually said that 128kbps is required per AP.

The AP in Flexconnect mode will tolerate some packet loss (it knows it's behind a WAN). But an AP in local mode may "freak out" pretty quick if some packets are lost randomly.

So the absence of QoS on your WAN is not the factor but more likely the reliability of the link itself

[Craig Le-Butt]

Hi

Problem with mobility, we have 9 * WISM over 3 sites running 7.0.24 , all configured the same expect for IPs running, each site is in its own local mobility group as clients are far to roam.

We have a couple of mobility groups set up to for external agencies and which one of them is broadcasting our corporate wlan.

We had a problem with devise connecting to different floors like brettcodey above.

The settings on our corporate wlan to mobility anchor either, “local”, all the controllers for that site or no setting at all.

Once I took all the settings out, no one externally could connect to our wlan, now by adding “local” back in, this will work?

The problem we have, some of the APs we use on the COWs are flaky when it comes to roaming, need to keep the same IP.

I want to be able to roam from one side of the building all the way to the other side, up and down lifts still keeping the IP, but now by adding “local” back in to the mobility anchor on the wlan does this effect it?

Any help appreciated

[Nicolas Darchis]

I'm not sure to fully understand your situation.

However :

-When you go on a particular WLC (let's say WLC A for this example) for a particular SSID/WLAN and define "local" as mobility anchor. It means that this particular WLC for this particular SSID will act as mobility anchor.

-Typically this means that other WLCs will have WLC A ip address mentioned as mobility anchor for that SSID/WLAN.

in summary, all other WLCs have WLC A management ip as mobility anchor and WLC A has "local" since he IS the anchor.

If you delete "local" from WLC A, it will not act as anchor anymore.

What is mobility anchor in brief ? (Very brief)

It means that other WLCs will transfer all their clients to the anchor (WLC A here) for that SSID. The result is that if you connect to an AP on WLC D, then you are tunneled automatically and get an ip address as defined on the SSID interface on WLC A.

It is typically used in a scenario where you put WLC A in the DMZ and all other WLCs are in the internal network. You would mobility-anchor the guest SSID only so that guest take their ips in the DMZ. Corporate SSIDs are not anchored because there is no need to, employees will then get an internal ip address.

Going back to your original symptoms of keeping your ip while changing floors :

-This will always happen if the WLCs controlling APs of those 2 floors are in the same mobility group and mobility is up/up.

-It also happens if you have mobility anchor configured because anyway your ip is given by the anchor. So you can change WLC, they will reconfigured their relations so that you still keep your ip from the anchor WLC in the DMZ.

[vigleik]

Hi Nicholas

I have a customer with two sites.

Site A - WLC5508

Site B - 2602 APs in Flexconnect mode with dot1q trunks

SSID SiteBGuest mapped to vlan 255 with local DHCP server at site B

The WLC at site A has no connectivity at all to vlan 255 at site B.

I want to do

- DHCP request and offer switched locally at the site B AP

- web authentication with WLC virtual interface at site A for SSID SiteBGuest

- AP Local switching of traffic after web authentication

Will this work?

To configure the SSID, I guess I need to define an interface for vlan 255 at the WLC with a dummy ip address belonging to this vlan.

Is it important to define the correct DHCP server at the WLC interface ?

[Nicolas Darchis]

Not much needs to be done for this work actually, it's "Flexconnect local switch" default behavior.

Recap :

-Have your 2600 AP on site B be in Flexconnect mode. Enable vlan support on it, define what is the native vlan.

-On the WLC, enable SSID "SiteBGuest" for Flex Local switching operations (checkbox in the advanced tab).

-Go to the 2600AP (in the AP list of the WLC) and go to the Flex options again, you can now define vlan mappings.

Define SSID SiteBGuest to be locallyswitched on vlan255.

-MAke sure the AP is plugged on a trunk port with the native vlan configured to be what you set as native on the AP (through WLC gui) and that 255 is allowed as vlan.

You'e good to go !

Authentications will still be tunneled to the WLC but as soon as client is authorized, he will be locally switched.

You do not need to create an interface at all on the WLC for vlan 255.

[Nicolas Darchis]

I recommend trying first an open SSID, and when working, set up the webauth security afterwards. It de-complexifies troubleshooting if things are not working.

[vigleik]

That's good.

I am, however, afraid to map the SiteBGuest SSID to an existing internal WLC interface. If the customer introduces new APs at a later time, and forgets to change the default AP group and AP mode, we have a guest SSID with access to a corporate vlan.

Do you agree ?

Maybe I could create a dummy interface on the WLC, to be used as default mapping for Flexconnect SSIDs ?

[Nicolas Darchis]

That is the right reflex to have yes. The dummy interface will prevent new APs or AP losing their mapping to give access to unwanted ressource.

[vigleik]

Another question for you, Nicolas.

WLC-5508 version 7.4 with two interfaces.

management - with access to corporate servers.

ifBYOD - gives only internet access.

Central switching at the WLC.

default mapping for SSID BYOD is interface ifBYOD

AAA override with radius attribute 81 for vlan number.

For Active Directory members doing computer authentication, the radius server will return the management vlan.

The radius server is behind the default router connected to the management interface.

Problem: WLC sends radius request packets out the ifBYOD interface, which is wrong. (I sniffed the packets at the firewall)

After mapping the SSID to the management interface, radius requests are sent the right way, and it works.

Is this a bug or is there a way to configure the default source interface for aaa requests ?

I do not like to have the management vlan as default mapping for any SSID.

[Nicolas Darchis]

So the WLC is sourcing the radius traffic from the dynamic interface of the SSID ?

This is the expected behavior if you configured "Radius interface overwrite" in the SSID config, which does exactly that.

Otherwise by default, it's always the management that is used to reach out to radius.

So i suggest removing that option in the SSID AAA config

[vigleik]

That option may have been checked at the time. Thanks, I will try to reproduce and verify.

[jino_jacob]

Hi Nicholas,

I faced a very wierd  DHCP issue today and would like to know your thoughts on it.

I have my wired clients on vlan 1 and wireless cleints(eap-peap) on VLAN 2.

Today there was an issue where multiple wired clients who were on access port vlan 1 were receiving IP address from wireless subnet(vlan2) with their DHCP server was the WLC virtual gateway IP address(2.2.2.2) causing an outage to few wired clients.

The WLC trunk does not have vlan 1 allowed on its ports and all APs are in local mode and all on access vlan.

Do you think its possible that 'A Client' laptop had his laptop in bridge connection mode - his wired nic on VLAN 1 and wireless NIC on vlan 2, which caused new wired clients(vlan1) DHCP request forwared to the WLC on VLAN 2?

Is there any way i could deny this on the WLC?

Thanks

Jino

[Nicolas Darchis]

This is very weird.

The Virtual ip of WLC as DHCP server is normal as when the WLC proxies the DHCP for its wireless clients, it pretends it is the DHCP server, therefore hiding the real DHCP server.

But since vlan 1 is blocked on your WLC trunk, it would mean that  your wired clients got their ip address through access points. So either someone was bridging like you said, or the affected laptops turned on wireless on top of their wired connections maybe ?

In any case, I'm not sure how you could prevent this. I guess DHCP snooping on the switch ? but it's more a switching security question I think.

[Amjad Abdullah]

Hi Nicolas again,

I have one more question regarding the data rates status of "Disabled'.

I understand that when I set a data rate as disabled in the radio config on the WLC then the clients can no more use that data rate to communicate.

Cisco Docs explains the "Disabled" status as:

    Disabled—The clients specify the data rates used for communication.

Can you please shed some light on that? Is this correct?
Or it is correct only if ALL data rates in some specific radio are all put to "Diasbled" state?

AFAIK each sides of wireless communication (the client and the AP) must determine that appropriate data rate to send with and that data rate is selected from a group of data rates that the AP supports. If an AP does not support a specific data rate it will not then mention that data rate in its beacons. How will the client - as per cisco explanation - specify the data rates that is used for communication if the AP itself doesn ot support that data rate?

Thanks.

Amjad

Rating useful replies is more useful than saying "Thank you"

[Nicolas Darchis]

In the beacons and probe responses, the AP will advertise all data rates marked as supported/mandatory and will not mention the disabled ones.

When the client sends the association request, it also specifies the data rates it is capable of. If the AP does not see in that list the rates that you marked as "mandatory" it will deny the client association. If they are present, the AP will take note of the common data rates between client and AP and will use only this common ground to talk to that client.