SD-Access Wireless

This blog is part of a series covering various SD-Access topics.

Previous blogs in this series:

Migration to SD-Access

This blog covers Wireless with SD-Access. It summarizes what I’ve learned and configured for SD-Access. For details, I’ll refer you to 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 “FEW”).

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 APs will be on fabric switch ports assigned to the INFRA_VN. The Wireless Controllers (WLCs) 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 refer to this as “Over The Top” or OTT wireless. It runs over the top of the fabric. It 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 has to 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? Two possible reasons:

You want to migrate a site to SDA, but leave the WLAN side alone (more or less – the APs could be addressed from a separate pool). Then you can migrate the WLAN later. (As to why you’d do that, see below.)
You have old APs that don’t support FEW.

With wireless OTT, all your APs will get addressed out of an SDA IP Pool, one subnet for the entire fabric site.

Wireless OTT means your traffic gets concentrated at the WLC, which could become a bottleneck. FEW potentially distributes the workload better. Wireless OTT may also incur greater latency, back-hauling all wireless traffic to the WLC.

Wireless OTT also means that you might be associating SSIDs with VLANs from the WLC into the infrastructure (the classic way we did this). Or with recent code and hardware, you might be assigning SGTs 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 is a non-starter: mobility won’t work.

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 DNAC. 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: less overhead. No hairpinning.
The traffic is distributed, just like wired traffic. It does funnel through the BN switches (or routers). But so does all site traffic. The switch ASICs do the VXLAN de-encapsulation in hardware at wire speed.
SD–Access does require that the WLC be onsite. You can do that with hardware WLCs 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 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 pretty large, in terms of number of APs. (I’ll defer to the 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 DNAC, so management overhead is reasonable.
- Note: The second reference below doesn’t mention virtual WLCs, despite a recent date stamp. It may be a revised version of an earlier document pre-dating virtual WLCs where a couple of paragraphs on that topic did not get added. Otherwise, the document is quite good with lots of good diagrams.

WLAN roaming within the site is effectively pure L2: 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 require you to go into DNAC and set the switch ports the APs 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 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 DNAC, you can then finish provisioning it in DNAC.

For details and lots of helpful diagrams and screen captures, see the 2nd reference below, the DNAC 1.3.3 Wireless Design and Deploy Guide.

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 monitor directly on the port in question since bouncing the port disables any monitor-based packet capture. Instead, doing monitoring on an upstream switch port can help.

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.

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 ENs.

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 DNAC

The Deployment Guide reference below has many pages of screen captures to walk you through deployment. Recommended reading!

Conclusion

As I 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 the next year’s budget.