FEATUREDApplication Development & Modernization
PETER WELCHER | Solutions Architect
This blog is part of a series covering various SD-Access topics.
Previous blogs in this series include:
This blog covers Wireless with SD-Access, summarizing pertinent topics and configurations for SD-Access. For further details, see the second reference listed below.
SD-Access Wireless Design Options
SD-Access supports two modes of operation: traditional wireless or “fabric-enabled wireless” (which some people abbreviate as “FEW”, but that acronym might be confusing).
Traditional Wireless (OTT)
Traditional wireless leverages the SD-Access INFRA_VN, which is a VN (VRF) that is tied to the global routing table and connects to the outside global routing via the border nodes.
Typically, your AP’s will be on fabric switch ports assigned to the INFRA_VN. The (perhaps call them traditional) Wireless Controllers (WLC’s) will be in a datacenter or site services location, perhaps in a closet connected to the core switches of a large site. That’s just the way we deployed them prior to SD-Access.
One difference is that we will now refer to this as “Over The Top,” or OTT wireless.
Why? Because the wireless traffic runs over the top of the fabric, and the APs are not part of the fabric, they are handled as end systems, just like user PCs.
The traffic does so by using CAPWAP to the WLC, just as it did pre-SD-Access. However, to cross the fabric from edge node (EN) to border node (BN), the traffic must be VXLAN tunneled as well: CAPWAP over VXLAN. Once the CAPWAP reaches the BN, it is just routed into the global routing table (GRT).
Why would you do OTT WLAN? There are two possible reasons:
- You want to migrate a site to SDA but leave the WLAN side alone (more or less – the AP’s could be addressed from a separate pool). Then, you can migrate the WLAN later. (As to why you might want to do that, see below. Short answer: migration is already complex enough, and leaving WLAN as is reduces risk.)
- You have old APs that don’t support “FEW”.
With wireless OTT, all your AP’s will likely get addressed out of an SDA IP Pool, one subnet for the entire fabric site. Just like other end systems.
Wireless OTT means your traffic gets concentrated at the WLC, which could become a bottleneck. FEW potentially distributes the workload better, namely directly from the AP to destination. No special tunneling needed. Wireless OTT may also incur greater latency by backhauling all wireless traffic to the WLC. Usually, the additional latency is within the same site or location, so it is not significant.
Concerning segmentation: Wireless OTT also means that you might be associating SSID’s with VLANs from the WLC into the infrastructure, the classic way we did this. Or with recent code and hardware, you might be assigning SGT’s at the WLC instead.
Fabric Enabled Wireless (FEW)
You probably will want to migrate to FEW once you have time and your hardware supports it. If your old APs did not support FEW, you might migrate at the time of AP replacement. Probably on a per-site basis. Mixing non-FEW and FEW APs at a site is not great: mobility won’t work properly.
There are several good reasons to do FEW:
- WLAN users and client devices will get assigned an SG just like wired users, via ISE and CCC. That means you get standardized user management and security across wired and wireless. Yes, the APs do get managed a little differently than the switches.
- That also means you’ll be using the same SG-based enforcement mechanisms – it’s just users and SGT’s, whether their access was wired or wireless.
- CAPWAP is used only to manage the AP. Normal user traffic is VXLAN tunneled by the AP just as wired user traffic is VXLAN tunneled by the switch. So less overhead, and no hair pinning.
- The traffic is distributed, just like wired traffic, so the WLC is not a potential bottleneck (and may exist only in distributed form anyway). Egress traffic does funnel through the BN switches (or routers). But so does all site traffic. The switch or AP ASIC’s do the VXLAN de-encapsulation in hardware at wire speed.
- SD-Access FEW does require that the WLC be onsite at each site. You can do that with hardware WLC’s for a larger scale if you like spending money or need to handle large sites. Or you can also use the virtual WLC, typically on a BN (or two) or even on an AP for smaller sites, if you really insist on doing so. Doing it on the BN makes more sense to me. And “small” here is rather large, in terms of number of AP’s these virtual WLC’s can handle. (I’ll defer to the Cisco scaling documents on how many.)
- The virtual WLC licensing is included in the switch license. So, while you may need more virtual WLCs than your old physical WLCs, especially for HA per site, doing so is already paid for.
- They’re managed via CCC (Cisco Catalyst Center), so overhead management is reasonable.
- Note: The second reference below doesn’t specifically mention virtual WLC’s for some reason. Perhaps because nothing differs? Otherwise, the document is quite good with lots of good diagrams.
- WLAN roaming within the site is effectively pure Layer 2: the same IP is retained across the site.
- Note that OTT and FEW don’t inter-operate, so migration should be, say, one floor at a time so as to not create roaming problems within a floor.
By the way, FEW is enabled per-SSID. So, you can have some SSID’s doing FEW and some not.
If you like guest anchor, you can do that. I personally like the idea of wired guest = wireless guest and handling all that at the fusion firewall. The Wireless Design Guide reference below suggests a couple of other creative alternatives for guest access.
One item that might slightly surprise you: the AP does VXLAN tunneling of user traffic to the EN it is attached to. The SGT is included in that VXLAN header. The switch de-encapsulates and re-tunnels the traffic to where it needs to do (typically, another EN or a BN).
How the AP Joins the Fabric
There’s one deployment detail you’ll have to pay a little attention to – getting the AP connected (onboarded) as part of the fabric. Once that’s done, client access is via 802.1x and pretty much the same as for wired ports, from the client’s perspective.
The earlier SD-Access releases required you to go into CCC and set the switch ports the AP’s are connected to, to Access Point and No Authentication. That is so the AP can send DHCP within the INFRA_VN VLAN and get an IP address assigned to the AP. The edge switch will be programmed with the appropriate configuration template to recognize the AP via CDP.
Remember that one great advantage to PoE is that shutting down the switch port power-cycles the AP. This is handy when testing or troubleshooting.
The 1.3.3x alternative is to set the port to closed authentication and MAB or 802.1x. The AP doesn’t initially have the 802.1x supplicant enabled, so for onboarding, you will need to use MAB authentication. By default, the 802.1x is the higher priority, so MAB won’t kick in until ISE has tried 802.1x and timed out. MAB gets the AP profiled for subsequent connections.
The AP then re-authenticates, hits MAB again, establishes connectivity to the WLC, and the WLC can enable 802.1x on the AP. The AP can then re-authenticate via 802.1x.
You should care about this because:
- You may need to troubleshoot onboarding the AP onto the SDA fabric
- You may want to check or alter the authorization rules
Once the AP is set up like this, onboarded into CCC, you can then finish provisioning it in CCC.
For details, helpful diagrams, and screen captures, see the 2nd reference below: the CCC 1.3.3 Wireless Design and Deploy Guide (or any newer version, of course).
If you are troubleshooting, enabling DHCP snooping on the switch can help. Then, check via “show device-tracking d <interface name>.” The interface name could be VLAN and number.
You cannot do switch monitoring directly on the AP’s connecting port since bouncing the port disables any monitor-based packet capture. Instead, do monitoring on an upstream switch port.
You’ll want to configure something like:
mon cap MYCAP interface ten 1/1/3 both
mon cap MYCAP match ipv4 protocol UDP any any range 67 68
mon cap MYCAP buffer size 100
mon cap MYCAP limit pps 1000
then in EXEC mode:
mon cap MYCAP start
mon cap MYCAP stop
I prefer to capture to a file:
mon cap MYCAP file location flash:PJW.pcap
I personally usually use my initials for the capture name, possibly with a number like 01 after: PJW01. Doing so flags my work and differentiates it from a capture someone else configures. Of course, after a while, you might accumulate a lot of such “junk” to clean up…
I typically also configure SCP on the switch. Then, I can quickly SCP download the small capture file and open it in WireShark on my Mac and use the up arrow to repeat the download in my terminal window!
For reference, here’s what The Fine Manual says about configuring SCP, edited some for brevity and focus:
configure terminal
! If not using TACACS+, omit the aaa commands that follow.
aaa new-model
aaa authentication login default group tacacs+
aaa authorization exec default group tacacs+
! If you are using TACACS+, omit the following local login
username name [privilege level] password encryption-type encrypted-password
IP scp server enable
Doing packet capture on the switch or on the next hop towards the DHCP server can also help. Bear in mind that after doing “no shutdown” on the switch port, it will take some time for a phone or AP to boot up, so you will not see a DHCP request immediately. (Lesson learned the hard way: hurrying to troubleshoot, brain not really engaged, with ensuing “What The Heck” moment, later forehead slapping.)
Note: Every SDA Cisco document notes that the default route is not useful for reaching a central WLC. You need a more specific route, such as 10.0.0.0/8. The issue is that the WLC is considered a LISP RLOC in SDA, and the RLOC reachability check against the routing table excludes default routes.
High Availability
Stateful failover with SSO and two WLCs is supported with physical WLCs.
You can do stateless redundancy as well (primary, secondary).
Control plane redundancy: set up the WLC with two control plane nodes and do the same for the EN’s.
See the reference below for lots of diagrams!
Wireless Multicast
This topic doesn’t summarize well, so I’ll just refer you to the reference below.
Deploying with CCC
The Deployment Guide reference below has many pages of screen captures to walk you through deployment. Recommended reading!
Conclusion
As previously mentioned, migration to SD-Access is best done incrementally.
Wireless OTT lets you migrate wired and wireless separately (mostly). This can be very handy if you are rushing to replace wired switches that are near end-of-support. You can go back later and migrate the wireless, perhaps buying new AP’s out of next year’s budget.
References
