SD-Access Catalyst 9200L

[AirBorn]

Hi All,

I have the following question regarding Catalyst 9200L in an SD-Access deployment

1/ How many VNs the Catalyst 9200L edge node does supports ? 

2/ Does sd-access wireless is supported on Catalyst 9200L edge nodes  ?

    - If sd-access wireless is not supported, does it mean that i can't connect fabric enabled APs

      On catalyst 9200L edge nodes

Regards

[Benjamin-A]

Hi AirBorn,

To 1. Only one VN is Supported as described in the Datasheet: C9200L Data Sheet Features and Benefits

To 2. Please have a look at the  SD-Access Compatibility Matrix

Further more there is a Breakout Session (Page 43)  and a similar question already asked

As you can see, there is no SD-Access Wireless Support for C9200L. So I think only OTT Wirless is supported with C9200L.

[AirBorn]

Hi,

So, i have to deploy a Wired & Wireless SD-Access fabric withe the following

 - Wireless deployed as OTT

 - Separate edge switch for wired and wireless

 - 9200L switch as wireless only edge nodes

 - One VN for Wired 

As  in Wireless OTT, AP wil reside in INFRA_VN, my fabric will hosts 2 VNs (Wired VN and INFRA_VN). Will this setup causes issue regarding the VN limtation on 9200L, Even if 9200L will be exclusively reserved for wireless only ?

Regards

[Benjamin-A]

Hi,

lets say you have one Building. Then in most cases you will just have one Fabric Site. If you will have C9300 and C900L Switches the whole Fabric Site will go down to just 1 VN (1 Overlay VN + Infra VN) - so thats an limitation.

If you have a Fabric Site with 9200L or 9200L only then your only option is OTT Wireless Deployment.

That means that your APs will reside in the Overlay (as you said Wired VN) as all your other clients will be. The APs won't be in the Infra_VN (Underlay) as with SD-Access Wireless Deployment (as they wont use VXLAN there will be no need). 

So the Access Points will just be a "normal Client". You will have to Authenticate them with ISE and then provide your VN in the Authorization Profile. The SD-Access then just will be your Transport and the AP Control + Data Plane will terminate at your WLC. 

 That means you're gonna lose some advantages you would have with  SD-Access Wireless:

• Automation & Assurance 
• Optimized Distributed Data Plane
• Micro Segmentation through the whole Fabric Wired + Wireless

[AirBorn]

Hi,

But on page 91 of the "wireless design and deployment guide" they says the following

"Since the WLC sits outside the fabric, the border node is responsible for providing reachability between the management interface subnet (192.168.1.0/24 in this example) and the APs’ IP pool (10.1.0.0/16 in this example), so that the CAPWAP tunnel can form and the AP can register to the WLC. In Cisco DNA Center 1.3, the APs reside in INFRA_VRF, which is mapped to the global routing table, so route leaking is not needed."

So the APs are in their own VN different from the wired VN

Regards

[Benjamin-A]

Oh yeah, you are right. In the topology I had in mind as I wrote the post the WLC was also in a VRF out side the fabric, sorry about that.
But if the WLC is in GRT you want to stick to the design guide.

[AirBorn]

Hi Benjamin

so, in  the wireless OTT setup

   1/ APs will reside in the same VN as wired clients VN 

   2/ APs IP Addresses will get registered in the HTDB  LISP instance

   3/ Wireless clients IP Addresses will not get registered in the HTDB LISP instance

Is that correct

Regards

[Benjamin-A]

Hi AirBorn,

 the Design and Deployment Guide can be a bit of confusing because in the WLC section there is the statement: "In Cisco DNA Center 1.3, the APs reside in INFRA_VRF, which is mapped to the global routing table, so route leaking is not needed." And in the Access Points section they write: "Access points are simply wired hosts to the fabric infrastructure, and hence are connected to the overlay space on fabric edge switches". 

So basically you have two options:

1. If your WLC is in GRT you don't want any route leaking happening and simply onboard the APs in the underlay (INFRA_VN) - I think that would be your preffered variant
2. depending on your Topology you are also able to put the APs in the Overlay as described by my previous post. 

Considering that:

   1/ APs will reside in the same VN as wired clients VN 

• as mentioned above it depents on your topology. APs can reside in Underlay (INFRA_VN) or Overlay in OTT deployment. Important is that the WLC is reachable for the APs so they can build up their CAPWAP Tunnel.
• If the APs are in the Underlay they won't reside in the same VN as wired Clients 
• If the APs are in the Overlay they will reside in the same VN as wired Clients

   2/ APs IP Addresses will get registered in the HTDB  LISP instance

• If the AP will reside in the Overlay then LISP is used so the APs IP Addresses will get registered in the VN's LISP HTDB
• If APs reside in the Underlay GRT will be used and it also registers to the Default LISP HTDB (see BRKEWN-2020 Page 105).

   3/ Wireless clients IP Addresses will not get registered in the HTDB LISP instance

• thats correct as the APs Data Plane will terminate on the WLC
• These clients will only being registered in the HTDB if they talk back to wired clients residing in the SD-Access Fabric

[AirBorn]

Hi Benjamin

So if the APs are in the INFRA_VN  ( wich is maped to the GRT)

 - The configuration process for the APs in the DNAC will be the same as in Wireless SD-Access deployment

    i mean that:

           - The Fabric Edge nodes are discovered, provisioned and added to the fabric as edge nodes

           - The APs are assigned to INFRA_VN

           - APs are onboarded the same way

           - APs IP Addresses will be registered in the LISP HTDB

   - The APs VLAN and the corresponding Layer 3 interface are provisioned by DNAC on the FE nodes

   - When the AP is pligged, the FE discovers it is an AP via CDP and assign the switch port to the right VLAN

The difference between the sd-access Wireless and non sd-access Wireless rely on how the fabric handles the wireless clients 

     - In  sd-access Wireless,  clients are part of the fabric

     - In  non sd-access Wireless,clients are not part of the fabric

Is all this correct

Regards

[jedolphi]

Hello,
Reviewing the whole discussion:
*A fabric domain contains fabric sites. A fabric site with a 9200L will be limited to one user defined VN. Other fabric sites will not be limited to one user defined VN if they do not have 9200L. In other words, presence of 9200L in a given fabric site limits only that fabric site, not other fabric sites, and not the fabric domain.
*If you've found language on cisco.com that says "INFRA_VRF" then it's incorrect. It's "INFRA_VN" as per the latest SDA CVD, https://cs.co/sda-sdg . The LISP INFRA_VN maps to the global routing table as of today (24/August, 2020).
*FE ports with an AP connected will be auto-configured to connect to INFRA_VN if there is no authentication on the ports. Otherwise you can configure them in the DNAC host onboarding GUI or create some ISE policy to assign APs to VLANs.
*Everything in your previous post is correct.
Best regards, Jerome

[jedolphi]

Hello community. One more important detail for those planning a future SDA design. The rule of 9200L = one user defined VN in a fabric site applies when the 9200L is provisioned to the FE (fabric edge) role. As of this exact moment 9200L must be provisioned as an FE. In future we should be adding support for 9200/9200L (and some other models too) as a policy extended node (PEN), which should not invoke the one user defined VN limitation. Please do note that this functionality  is roadmap for  later in 2020. Please consult with your Cisco presales team to get further details and timelines. Best regards, Jerome