This article assumes you have the basic knowledge and experience with Cisco DNA Center and Identity Services Engine (ISE). Note when reading this doc the "Authentication Policy" referred to is part of Cisco DNA Center Onboarding section and has no correlation with ISE Authentication Policy.
When choosing a VN and binding an IP Pool to it Cisco DNA Center automatically assigns a name in the "Authentication Policy" field. For example if we have a VN name "Employees" and assign the IP Pool 172.16.16.0 then the "Authentication Policy" will receive the following name "172_16_16_0-EMPLOYEES" as seen below.
This will work just fine but what happens when using Identity Services Engine (ISE) to securely and dynamically onboard your endpoints? You can find out more on How to Onboard Endpoints using ISE at the following link How to SDA Host Onboarding with ISE When referring to the "How to SDA Host Onboarding with ISE" you will understand that ISE Interprets the "Authentication Policy" in Cisco DNA Center to a VLAN ID. In order to dynamically assign the endpoint to that VLAN ID we need to do 2 things in ISE.
Create an "Authorization Profile" with a VLAN ID of the same naming as the "Authentication Policy" in Cisco DNA Center.In this case my VLAN ID name will be "172_16_16_0-EMPLOYEES"
Create an "Authorization Policy" in which if the Condition/s are met the "Result" applied will be the "Authorization Profile" we created in step 1 and endpoints will be onboarded to VLAN "172_16_16_0-EMPLOYEES"
Up until this point, this is exactly how the process is explained in the "How to SDA Host Onboarding with ISE".
Lets now take the following scenario to understand what kind of "issues" we could run into when using the automatic name assigning of "Authentication Policy" when binding IP Pool to VN in Cisco DNA Center.
Use Case The above VN (Employees) and IP pool (172.16.16.0/24) bind to it, is named "172_16_16_0-EMPLOYEES" in the Authentication Policy field relates to a single fabric site , and we are using an Authorization Policy in ISE to onboard the endpoints to VLAN "172_16_16_0-EMPLOYEES"
You have just acquired a company and have migrated them to a new Fabric site within your existing Fabric domain and would like to onboard them using ISE but keep Authorization Profiles and Authorization Policies to a minimum. You could create a new VN (e.g Employees2) and bind an IP Pool to it (e.g 172.16.20.0/24) , the automatic "Authentication Policy" name Cisco DNA Center would create is "172_16_20_0-EMPLOYEES2". Recall this name will be your VLAN ID in ISE , meaning to dynamically onboard the endpoints you would need another Authentication Profile in ISE with VLAN ID "172_16_20_0-EMPLOYEES2" , as well as another "Authorization Policy".
Problem If you have multiple fabric sites this starts to become a management issue as well as resources used in ISE Just think if you had 5 or 10 fabric sites ... Resolution In earlier versions of Cisco DNA Center we did not have the option to modify the "Authentication Policy" name. But now given this option lets say instead of naming the Authentication Policy "172_16_16_0-EMPLOYEES" in VN "Employees" we name it "Employees" (In this case both the VN name and Authentication policy are using the same name , this is in no means a requirement). ISE will recognize this as VLAN ID "EMPLOYEES"
And in the second Fabric site, instead of using the automatically generated Authentication Policy name of "172_16_20_0-EMPLOYEES2" in VN "Employees2" use the same name as used in the first fabric site i.e. "Employees". ISE here will also recognize this as VLAN ID "EMPLOYEES" The outcome is that we now have 2 separate fabric sites with 2 separate IP Pools which ISE defines as VLANID "EMPLOYEES". This means that in ISE we can use one Authorization Profile and one Authorization Policy to dynamically onboard endpoints to the same VLAN ID while each VLAN ID provides its own unique IP Pool .
The above diagram depicts how we can use one Authorization Profile and one Authorization Policy in ISE for 2 different IP Pools within 2 different fabric sites.
If you have any questions regarding this particular Document or would like to see other walk throughs that extend beyond this topic please let us know on our community page SD-Access Community
I need help figuring out what is going wrong. I am only worried about the Honolulu network. I have 5 vlans setup. I also have 2 of them being given addresses via DHCP on the router. For some reason I cannot reach my servers or my printers though.
Using the above topology, I have ebgp running between edge1 and edge2 with isp1 and isp2, and ibgp running between the two edge routers and core routers. I had this up and working before but I'm studying for the CCNP so I decided to tear it do...
I am experiencing an issue with multicast feeds over a VTI. We have two VPN gateways at both source and receiver sites. From the receiver side, a static default route has been put in place towards the tunnel. On the source side, we have configured IGMP st...
Folks,We are working on some OSPF design where 2 routers need to talk OSPF with an internal network. The catch, we want to pass the traffic via a Palo Alto firewall. I have attached the diagram on the design on how we are going to implement this...
Hi Freinds am i right as per below: SSO: sup aware feature to prevent the interruption of L2 Traffic NSF : it prevents the interruption of L3 traffic during Sup failover NSR: acts as graceful restart prevents peer to experiencing flapp...