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.