Wireless Access

Currently I have a pair of 7240's that were in a Master/Standby state.

We're moving forward with an 8.x migration with Mobility Masters.

I have a couple of questions about how the various parts should play together.

The 7240's are centrally located, we have multiple sites with leased fiber (that's running a 10GB backbone between sites).

We currently have a captive portal setup that's simply used to present and accept an enduser's acceptance of our policy to use the guest environment... Under Mobility Master, I think we will end up with each node being a MD or MC (I'm still not clear on this)... We have a 3rd party certificate that we've loaded on the current controllers, I'm guessing this will get loaded on the MM's under the managed devices section? or somewhere else?

The question is where does the Captive Portal get setup for the above?  Is it still on the controller? or on the Mobility Master?

I see where we have a fairly large number of vlan's.  Most of the vlan's do not have anything actually assigned except for tagged membership on one of our network interfaces.  A couple vlan's have IP addresses assigned, but also have "no IP Routing" configured.  I know the expectation is to pass the traffic onto our core routing switch.  I'm wondering if the IP addressing for those vlan interfaces are actually needed.  Note that one of these vlan's is the one used for the "guest" network with the captive portal configured to preset the AUP.

On the current controller configuration, we leverage ap-groups to allow for one of the wlan/ssid's egress vlan's to be altered on a per site basis.  it seems like the easiest solution is to continue with this model moving forward.

In our current configuration, it appears that CPSec is disabled, what sort of pain is incurred if I enable this with the new system?  Is this something that has to be enabled prior to AP's being attached to the 8.x controllers?  or is this something that can be enabled at a future date?  I know that I need to update the DHCP option 43 settings to point the ap's to the new controller address.

I can see that there is a hardware certificate loaded on the MM's.

I've already read that I need to add the new IP addresses for the controllers to Clearpass.

Can I "update" Airwave to point to the new controllers? or is it more complicated than that?

Before we answer your questions, have you read the ArubaOS 8 Fundamentals Guide here:  http://community.arubanetworks.com/t5/Controller-Based-WLANs/ArubaOS-8-Fundamentals-Guide/ta-p/428914 ?

I've been reading a fair amount, but I can't say that I have everything down.  I did have that document downloaded already.

So MC/MD are essentially different intials/names for the same thing.  We have redundant 5K HMM's for the Mobility Masters, and the 7240's will be running in a clustered Mobility Controller/Managed Device configuration.  Though initially only one controller will be migrated to the new environment while the configuration is being tested and verified.

On the captive portal side, the User Guide wasn't terribly clear on this since we're running 7200 series controller's the water was a bit muddied - from Page 283.

"In 7200 Series master controller mode deployment model, Captive Portal configuration is allowed on the managed devices and device nodes (device nodes are located within managed devices). However, server-based policy configuration is allowed only on device nodes."

vs

"In Mobility Master-Managed Device deployment model, all Captive Portal configuration is allowed only on the Mobility Master."

Reading the section above, in the fundamental's guide, I see that the configuration we're going to run will be in Mobility Controller mode vs Master Controller mode.

So the captive portal will be handled on the Mobility Master.

When looking at the CPSEC section of the user manual, It doesn't really say if I can turn this up later, or not. CPsec appears to be disabled in my 6.5 environment, however, I suspect this is something that we'll desire to have enabled going forward.  But I wasn't certain if this breaks other things, is this something I can enable after the second controller is converted to 8.x and added into the HMM environment?

I suspect I have a bit of AP whitelist scripting in my future... So Ap's are "named" by their mac address going forward? or does 8.x still support "friendly names"?

On the Vlan question about IP assignments, I really think the IP assignments at the vlan is meaningless becuse the vlan's are being passed through to another device to route/NAT these connections. The IP addresses assigned to the 7240's is not the gateway address.  

I could quickly verify if the IP's are meaningful Monday by simply removing one of these addresses on the Master controller that currently has our AP's attached. 

---

@sfarrand

So MC/MD are essentially different intials/names for the same thing.  We have redundant 5K HMM's for the Mobility Masters, and the 7240's will be running in a clustered Mobility Controller/Managed Device configuration.  Though initially only one controller will be migrated to the new environment while the configuration is being tested and verified.

^^^YES and good strategy.

 

 "In 7200 Series master controller mode deployment model, Captive Portal configuration is allowed on the managed devices and device nodes (device nodes are located within managed devices). However, server-based policy configuration is allowed only on device nodes."

 

vs

 

"In Mobility Master-Managed Device deployment model, all Captive Portal configuration is allowed only on the Mobility Master."

 

Reading the section above, in the fundamental's guide, I see that the configuration we're going to run will be in Mobility Controller mode vs Master Controller mode.

 

So the captive portal will be handled on the Mobility Master.

 

Master-Controller-Mode or MCM is where an actual controller is used to configure your environment.  It is not desired, because there are many features that are not supported on that environment:

 You want to choose an MM to configure your enviroment, period.  In the MM environment, the Captive Portal is configured on the MM, but clients and access points do not connect to the MM, at all.   The MM functions as a device to push configurations to MDs, calculate RF parameters, aggregate Airmatch Information, etc.  The "local" controllers or MDs send their information to the MM via Openflow and the MM sends information back to them.  

 

But I wasn't certain if this breaks other things, is this something I can enable after the second controller is converted to 8.x and added into the HMM environment? You should enable CPSEC day one.  It will take a little longer for your access points to come up initially, but it secures traffic between your access points and the mobility controller.  You will also be able to do local bridging (bridged SSIDs and interfaces), without having to enable CPSEC later. 

 

I suspect I have a bit of AP whitelist scripting in my future... So Ap's are "named" by their mac address going forward? or does 8.x still support "friendly names"?  Yes it does.  You can also name access points and their ap-groups ahead of time if you would like by editing the CPSEC whitelist (another reason to have CPSEC enabled day one).

 

On the Vlan question about IP assignments, I really think the IP assignments at the vlan is meaningless becuse the vlan's are being passed through to another device to route/NAT these connections. The IP addresses assigned to the 7240's is not the gateway address.  Just like ArubaOS 6.x, an ip address is not necessary on an controller for a VLAN interface in 8.x unless you are serving Captive Portal on that VLAN.

 

I could quickly verify if the IP's are meaningful Monday by simply removing one of these addresses on the Master controller that currently has our AP's attached.  At minimum the management ip address of your controller is important, because that is what your access points need to contact the controller.  If you have a VLAN with guest traffic, you will need an ip address on each controller for that VLAN, because your clients will need to contact your controllers on an ip address to bring up the captive portal, and you don't want that ip address to be the management address.  You would use the ip cp-redirect-address parameter  to determine what ip address that is.  https://www.arubanetworks.com/techdocs/ArubaOS_83_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/1CommandList/ip_cp_redirect_address.htm?Highlight=ip%20cp-redirect-address

---

To answer your question in the previous post, a single https server certificate can be imported on the MM using Configuration> System > Certificates.  That certificate will be applied to all of your controllers under MD in the hierarchy.

Thank you for your speedy responses - 

I'd love to claim I came up with the staged migration strategy, but it was suggested to me. :)

It wasn't as clear as it should have been initially about the difference with Mobility Controllers under 8.x.  

Your answers about the Mobility Master vs Mobility Controller really clears up and reinforces where the configuration will go.

I had some confusion about the hierarchy.

I've been told to segregate things out by site name, and then I've also been told to keep it simple. 

If I only have two controllers that are centrally located, is there any sense in creating a hierarchy like this?

Managed Devices
-> org folder name
-> site name
-> site name
-> site name

I've been using ap-groups in my current configuration to allow for ssid configurations per site. I think that's probably the way this will end up working best in 8.x as well just where it's listed onder the "org folder name" as a whole. 

Also, at this point, I have specific ap-name configurations in my current 6.5.x config - this is for specific profile changes like Radio profiles. I think this also allowed for SSID's to be added or removed, though we've been using AP-Groups for that functionality thus far. Is this type of functionality retained in the 8.x environment?

>> You should enable CPSEC day one. It will take a little longer for your access points to come up initially, but it secures traffic between your access points and the mobility controller. You will also be able to do local bridging (bridged SSIDs and interfaces), without having to enable CPSEC later.

Sounds like I should have this enabled period.  However, I have one more question about this then - how does CPSEC affect the ability to roll back to my old controller if things go horribly wrong. If I migrate one site's AP's to the 8.x environment with CPSEC, and then if I need to roll back to the old 6.5.x controller, does CPSEC cause additional pain for a possible rollback? While I'm not looking to flop back and forth, I don't like one-way paths either.

Excellent about the ap whitelisting - While this will be a little bit of work (~ 1,250 ap's), I'd rather do this ahead of time before migrating the AP's over. This shouldn't be too painful if I use the AP Database from the old controller for this... (kind of like the excel scripting I used while looking for the interfaces that were running at 100MB vs gig).

In and amongst the different reading I've done in the past day or two, I also think I'll be working on enabling jumbo frames across the organization for AP connectivity. One adventure at a time...

AH!!! ok, so the "guest" wireless vlan DOES need to have IP addresses associated because a captive portal is used for that AUP acceptance. I'll have to review the document you linked. When contemplating this, it felt like I'd need to setup another VRRP address for the guest wireless vlan?  It doesn't sound like this is necessarily needed, but if I can only assign one IP for the captive portal redirect, does this then get configured on each MD directly?

I think ACL's are used in the 6.5.x environment for redirecting the captive portal traffic.  This command appears to work with an IPv4 address only - is there an IPv6 version as well?

We've actually been using the same certificate on each of our controllers.  It sounds like this this will make that process easier to work with.

And a new question that's arisen for me is if I should revise the configuration for the uplinks to the controller/Managed Device. Currently the MD's have a 10GB up-link on 0/0/2 that's untagged with the "Management" IP that all of the AP's link to for their communications, and a second 10GB up-link on 0/0/4 tagged with all of the egress vlan's. While this works, I tend to wonder if it wouldn't be better for redundancy to create an LACP/LAG connection combining both interfaces - possibly spanning two physical cards on the up-link switch and tag all traffic inbound to the Controller/MD's for redundancy? I don't remember if this will load balance well in a routed environment.

I had some confusion about the hierarchy.

I've been told to segregate things out by site name, and then I've also been told to keep it simple. 

How many sites do you have?  Do all of the sites tunnel back to the controller anyways?  Do you generally have all the same SSIDs at sites? If you only have two controllers that are centrally located, you would need a single container under MD where you would configure all of your SSIDs.

I've been using ap-groups in my current configuration to allow for ssid configurations per site.

Yes, continue to create ap-groups with different Virtual APs under that single container/folder under MD (do not configure anything in MD).

Also, at this point, I have specific ap-name configurations in my current 6.5.x config - this is for specific profile changes like Radio profiles. I think this also allowed for SSID's to be added or removed, though we've been using AP-Groups for that functionality thus far. Is this type of functionality retained in the 8.x environment? You can do things that are ap-specific, but only on the commandline.  It is encouraged to do ap-groups for anything that is different.

You can roll back your APs from one controller to another with CPSEC, it would just take longer to come up.

Excellent about the ap whitelisting - While this will be a little bit of work (~ 1,250 ap's), I'd rather do this ahead of time before migrating the AP's over. This shouldn't be too painful if I use the AP Database from the old controller for this... (kind of like the excel scripting I used while looking for the interfaces that were running at 100MB vs gig).

You do not HAVE to do ap whitelisting in CPSEC.  You COULD do it for new access points.  The access points you migrate from 6.x will retain their ap-name and ap-group.  You just need to have something defined for the ap-group in 8.x that your access points are in.

In and amongst the different reading I've done in the past day or two, I also think I'll be working on enabling jumbo frames across the organization for AP connectivity. One adventure at a time...

You can enable jumbo frames in your infrastructure or make the forwarding mode of your virtual APs "decrypt tunnel" to have the same effect.  CPSEC is required to enable "decrypt tunnel" Virtual APS.

You do not need a VRRP for a guest VLAN.  The ip cp-redirect is configured on each MD under that controller's folder on the MM.  Nothing is configured directly on the actual controller in 8.x.

There are ipv6 redirects (captive portal ACLs) in 6.x and 8.x.

Leave your uplinks the way they are currently.  That is fine.  Get everything working and then you can consider LACP in the future.  Enabling more and more physical redundancy could cause more troubleshooting issues so save that for last.  The back of the napkin rule is to have 1 gigabit ethernet link for each 100 access points that are connecting to a controller.

Thank you again for responding, this helps greatly.

As for sites, I have 21 school's (High, Middle, and Elementary) and ~ 4 other district buildings.  Sounds like Ap-Groups are the way to go anyway.

The reasoning for using direct ap-name configuration was to manage a couple of unique situions where we've raised RF power to compensate for access point location(s), or to switch the 2.4ghz radio to air-monitor mode for some of the cafeteria area's where we need to have the SSID for our food services folks operational. It might be better to simply add that virtual-ap rather than have the ap-group for that. For one of the situations, I really need to add another AP to address an area with difficult RF issues.

I'm perfectly fine with this being a CLI only environment - just as long as I can see those configurations in a show run.

Good deal on the being able to roll the AP's back - I don't care if it takes longer as long as it will work.

On the CPSEC whitelisting... are you talking about if I run the migration tool for adding my existing controller into the Mobility Master environment?

Ok, so VRRP isn't needed, but each MD needs to be configured with that IP cp-redirect. Is that a CLI only config? or something configured in the GUI?

Based on the napkin rule, it sounds like we need more 10GB links anyway to match the number of access points we have deployed since we have 2 x 10GB links with ~ 1,250 ap's.  I don't know if it matters or not, but the majority of our AP's are AP-225's and couple of AP-277's in one of our football stadium's.  I'm looking at AP-335's for a few area's and some AP-345's in a couple of higher density area's.

Also, at some point, I need to get some advise for how to better consolidate our Clearpass rules. I see regular expressions in my future on that - but one major change at a time.

On the CPSEC whitelisting... are you talking about if I run the migration tool for adding my existing controller into the Mobility Master environment?

CPSEC whitelisting is an option for new access points to be named automatically based on a whitelist you create.  Migrating with or without the migration tool will carry over the ap-name and ap-group, because those are stored in flash on the access point.

Ok, so VRRP isn't needed, but each MD needs to be configured with that IP cp-redirect. Is that a CLI only config? or something configured in the GUI? Commandline only.   If you did not configure it before, most likely your users were simply connecting to the management ip address of the controller to open up the Captive Portal.  If you are okay with that, you do not need to define an ip cp-redirect-address.

Based on the napkin rule, it sounds like we need more 10GB links anyway to match the number of access points we have deployed since we have 2 x 10GB links with ~ 1,250 ap's.  I don't know if it matters or not, but the majority of our AP's are AP-225's and couple of AP-277's in one of our football stadium's.  I'm looking at AP-335's for a few area's and some AP-345's in a couple of higher density area's. 2 10-gig connections would accomodate 2000 access points.  You are fine.  Not to mention how many bottlenecks in your network would prevent the controller 10gig interfaces from being a chokepoint.

Actually, generating this script was easier than I thought... Since all of the aspects of the command could be on one command line.  If the AP's will provide this information directly, then perhaps this isn't necessary.  If I were to set it up anyway, would it cause problems? It sounds like I should re-enable CPSec. Should I enable the automatic certificate generation?

I know that show whitelist-db cpsec doesn't show anything on my current master controller (which has cpsec turned off actually)

We actually have 10GB up-links between most IDF's and the MDF at each site, with a 10GB up-link though there's a couple of situations where there's an elementary and middle school tied to a high school that then up-links to the district office.  While we have dual 10GB up-links, one's dedicated to inbound traffic, and the other's dedicated to outbound traffic.  While there is other traffic on our backbone connections, we seem to be migrating away from wired/desktop computers and more towards wireless based equipment (over 300 new laptop or chromebook devices are going to one high school alone this summer). I can see where jumbo frames are likely a problem in our network, but I've got some work to do before that can be enabled how I'd want it enabled (e.g. only for the AP ports).  Some of our network equipment will not support jumbo frames and our desktop clients aren't configured for that.  The network devices that will support it will need to be converted to a different version of software so specific ports can be switched to jumbo frames.

I'm now wondering if the missing "ip cp-redirect" command-line setup could be affecting clients who only run an IPv6 stack from getting the captive portal - this is an issue that I've had a TAC case open for, but they couldn't come up with a good solution, and my interest dropped after it became apparent we were rather rapidly moving towards an 8.x migration.

You do not need the script, period, because access points already have names and ap-groups.  New access points will not need the script and you can just rename them.  Again, you do not need a script.

If you have cpsec off, there should be nothing in the whitelist.

Your 10 gigabit connections should be fine.  You can just type "show interface <interface name>" to see if there have been any throttles or any other errors.

TAC would know best based on your infrastructure if you need ip cp-redirect enabled.  Quite frankly, if it works, it is not required.