SDA and wireless Part II - AP onboarding

This post will continue to build on the topology that was used for Part I of this series (which can be found here - https://www.theasciiconstruct.com/post/sda-and-wireless-part-i-integrating-a-9800-cl-into-sda):




The IP addressing scope for APs falls within the pre-created INFRA_VN in fabric. This VN is not an overlay – it runs within the global routing table itself. Once the IP addressing is designed, define this within the INFRA_VN in your fabric:



This does several things (which is commonly done whenever you add an IP pool for any of your VNs):


It creates an instance ID in LISP for this (for both IPv4 and Ethernet) and creates a dynamic EID database-mapping for the IP range within the IPv4 service and the L2 VLAN (along with a database-mapping for any mac address) within the Ethernet service:



It also creates a L2 VLAN and a corresponding SVI, assigning it an IP address that is specified as the default gateway for this IP pool in your DNAC design settings. LISP mobility is configured under this to allow for dynamic EIDs to be learnt.



Additionally, on the control-plane nodes, it creates corresponding instance IDs in LISP as well adding this IP range to be accepted as an EID within the site cache:



It also creates a /32 loopback on the borders with the same anycast IP address as the edges for this SVI (to understand why, please see https://www.theasciiconstruct.com/post/cisco-sda-part-ix-need-for-duplicate-ips-on-fabric-borders).


Lastly, this is advertised and aggregated in BGP to propagate this prefix to upstream neighbors:



If you look at the ‘show wireless fabric summary’ again now, you will see a new mapping in there for this IP pool that was just added to the INFRA_VN. This will also tell you what the corresponding L3 and L2 VNIDs are for this pool.


Everything is now in place for APs to be onboarded. The AP boots up as any other client and acquires an IP address via DHCP. The DHCP scope has option 43 configured, which defines the WLC IP address the AP should reach out to.


A DHCP offer (in the packet capture below) from the DHCP server shows the IP address that the AP is being allocated and option43 within the offer:



Once the AP is up and starts sending some traffic, the edge will register the APs hardware mac address and IP address as EIDs to the control-plane(s):



This can also be seen from the below packet captures. The first image shows the hardware mac registration while the second image shows the IP address registration:



At the same time, the AP (now with an IP address of 192.2.12.18) sends a discover to the WLC and gets a discover response. Post this, it builds a DTLS session with the controller and sends a join once the session is up. It expects to receive a join response back and once the process completes the AP is considered registered to the WLC.


This AP join process can be seen in the below capture (joins will not be seen since that is post DTLS bring-up and is encrypted):


So, originally, when the AP is coming up, your CPs will see the edge as the RLOC for both the L2 and L3 instances, since the edge will register this with the CPs (as seen earlier via the packet captures). On the CPs, you can confirm this with the below commands:


However, there needs to be some way to inform the fabric infrastructure that what is connected to the edge is not just another client but an AP. LISP is leveraged for this.


Once the AP registers with the WLC, the WLC sends a LISP map request to the control-plane nodes for this APs IP address. This is sent because at this point in time, the WLC has no idea what edge the AP is connected to (specifically, in LISP terms, what RLOC the AP is connected to). It can glean this information by sending a map request for the AP.


This can also be visualized like below:




The following packet capture shows the map reply packet:


When the WLC receives this LISP map reply, it gathers the RLOC information from it and immediately sends another LISP message to the control-plane(s) with a LISP packet type of 31.


This includes the radio mac of the AP and necessary encoding that allows this to be further propagated to the edge where the AP is connected. Wireshark cannot decode these packets since there are no dissectors available.


A packet capture for this:


This can also be visualized as below:



The CPs then send a LISP message (again, a LISP packet type of 31) to the RLOC (Edge1, in this case), along with the required meta-data to build a VXLAN tunnel to the AP. The following debug from the edge confirms this:



The edge can now use this meta data to form the VXLAN tunnel to the AP:



This concludes part II of this series. In the next part, we'll take a look at how APs are provisioned in the fabric (via DNAC), what is pushed during this provisioning and why this is a very important part of wireless integration in SDA.

For any queries, concerns or conversations, please email contact@theasciiconstruct.com