Need to understand WebAuth using 3850 MA, 5760 MC and 5508 GA

[igaffine]

All,

I would appreciate if anyone could provide clarification on my current understanding of Converged Access mobility design for WebAuth and guest access. My setup is as follows:

(WAP)---(MA)---(MC)---(Firewall)---(GA)

Wireless Access Point (WAP) - 3500

Mobility Agent (MA) - Cisco 3850 (running IPServices)

Mobility Controller (MC) - WLC 5760

DMZ Firewall

Guest Anchor (GA) - WLC 5508 (running 7.5.110.0 and new mobility feature enabled)

I have my mobility domain configured with an SPG and the 3850 MAs configured into the domain. All status indicators are up for MC to MA and MC to GA. The WAPs are connected to the 3850 MA and appear on the MA using the command 'show ap summary'. There are also a number of WAPs that associate directly to the 5760 MC.

My configuration on the MC has a guest wireless service using WebAuth, which anchors over to the GA. Clients connecting to the WebAuth service on WAPs associated directly to the 5760 MC receive and IP address from the GA DMZ and are redirected to the GA WLC. This is as expected with the usual centralized wireless model.

My initial thoughts with the Mobility Agents (MA) was that it was a simple case of pointing the 3850s to the MC and the wireless service (WLAN) configurations would automatically appear. Through configuration tests and converged access deployment guides, I now believe this to no longer be the case. Therefore, for MAs to advertise wireless services they have to be individually configured. Am I correct with my thoughts?

This was proved with a Secure 802.1x WLAN on the MA and it was a simple case of replicating the 5760 Secure WLAN on the MA.

For the deployment of WebAuth wireless services on the MA 3850 switches, I have not managed to find a guide that explains how an MA anchors wireless clients to the GA. I have found documents that describe combined MC/MA configurations to GA, but not when the 3850 is just an MA. Is it is case that:

1. MA WebAuth wireless service is configured to anchor to the GA using the command 'mobility anchor <GA IP Address>'. This would require the DMZ firewall to allow mobility tunnels between the MA to GA and MC to GA, or;

2. MA WebAuth wireless service is configured to anchor to the MC using the command 'mobility anchor <MC IP Address>'. This would mean the traffic from the MA for WebAuth is tunneled to MC and then onwards to GA.

I suspect option 1 is the correct method, but would appreciate confirmation.

Also, I have not configured a Mobility Oracle (MO) since I only have one MC and the GA. If it is advisable to do, then would it be best to enable the MO on the MC or GA?

Thanks in advance

Ian

[Rasika Nayanajith]

Hi Ian,

It is a long post & many questions 

I will try to answer as much as I can.

"I have not configured a Mobility Oracle (MO) since I only have one MC and the GA. If it is advisable to do, then would it be best to enable the MO on the MC or GA?"

No, you don't want MO unless your set-up is extremely large (it is similar to use of BGP route reflector to reduce complexity of having full mesh)

"My initial thoughts with the Mobility Agents (MA) was that it was a simple case of pointing the 3850s to the MC and the wireless service (WLAN) configurations would automatically appear. Through configuration tests and converged access deployment guides, I now believe this to no longer be the case. Therefore, for MAs to advertise wireless services they have to be individually configured. Am I correct with my thoughts?"

Yes, you have to configure your WLAN configuration in MC & MA, it won't automatically propagate to MA.

"For the deployment of WebAuth wireless services on the MA 3850 switches, I have not managed to find a guide that explains how an MA anchors wireless clients to the GA. I have found documents that describe combined MC/MA configurations to GA, but not when the 3850 is just an MA"

I have not configured this, but this is my understanding.  You would configure MA WLAN  pointing to GA as mobility anchor. Still traffic will transit through MC as it will manage MA & SPG (any thing outside SPG should go through MC)

Here is the some useful reference information I gathered over the timel. (white paper is the one you should read to cover everything)

https://supportforums.cisco.com/discussion/11984726/converged-access-design-information

HTH

Rasika

*** Pls rate all useful responses ****

[igaffine]

Rasika,

Many thanks for your reply. Long post indeed :)

The mai issue I am having is around the Mobility Anchor configuration on the MA. I have looked at your suggested reference before, but I could not find anything specific to MA and Webauth. I will have another look.

I did initially setup the MA to anchor to the GA IP address, but my clients never get an IP address and no reply packets are received. I suspected that this was down to no direct connection to the GA, as the firewall does not allow MA to GA connection. I will attempt further debugging today and let you know how I get on.

Kind regards,

Ian

[igaffine]

Rasika,

Many thanks for your reply. Just to let you know that you were correct with your ideas that the MA should have the mobility anchor configured as the GA IP address. It turned out that we had a problem with our firewall when testing the guest wireless service and once that was resolved our client now receive an IP address from the DMZ and can successfully webauth to the GA.

We have spotted something interesting in our firewall logs and our GA mobility debugs, in that when a guest client connects you see the MA connecting to the GA through the MC, however, we see attempts of the GA controller trying to connect directly to the MA. This at the moment is blocked on the firewall and wondered what this could be for. The clients successfully connect to the wireless environment, so wondered if the GA controller was trying to attempt to perform a 'fast path' tunnel to the MA directly.

Kind regards,

Ian

[Scott Fella]

Guest tunnel in CA is the same as for AireOS, the WLC has to have a tunnel to the GA, like in CA, the MC's have to have a tunnel to the GA.  The device will not communicate directly to the GA.  The MA's tunnel back to the MC and that is where the tunnel is initiated to the GA's.

CA hasn't really been pushed a lot as AireOS isn't going anywhere and there are some limitations to CA vs AireOS.  If you have issues an you know that your setup is right, open a TAC case and verify.  That is what I would do:)

Please rate helpful post and Cisco Support Community will donate to Kiva

Scotty

[Rasika Nayanajith]

HI Ian,

Thanks for the follow up & confirming what you have done to fix it. +5

Rasika