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 VLAN ID "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
... View more
Currently when changing the Authentication Template under the Onboarding section, there is no choice but to remove SGTs, VNs and IP Pools which clearly disrupt existing services.
Hitless Authentication was introduced in Cisco DNA Center 188.8.131.52 providing the ability to modify the Authentication Template under "Host Onboarding" without the need to remove SGTs, VNs, and IP Pools and therefore avoiding impact of endpoint connectivity and services.
Hitless Authentication also supports Site level based Authentication Templates , meaning you may have a different set of Authentication Templates per fabric site. The changes made to the Site level templates will have no impact on the Global Level Template parameters and take priority over the Global Level Template parameters. Global Authentication Templates parameters apply to all sites if not overwritten at the Site level.
The Authentication Template can be found when navigating to Provision > Fabric > (Your fabric site) > Host Onboarding To modify the template parameters simply click on "Edit" and when finished click "Save" Once you have chosen the relevant template click on "Set as Default" NOTE: Existing endpoints that have already been authenticated will not be impacted or forced to re-authenticated. The Global Template Parameters can be found by navigating to Design > Authentication Template When parameters are modified click on "Submit" to apply changes.
... View more
Host Onboarding is the term used when connecting an endpoint (hosts , IOT , Other devices) to the fabric , and can be accomplished in a couple of ways. One option is the "static" approach as oppose to the dynamic and secure approach using Identity Services Engine (ISE) based on Authentication and Authorization. With this approach we dynamically assign the endpoint to a VN as well as assigning it a Scalable Group Tag (SGT) providing us with Macro and Micro Segmentation. In this document we will provide a step by step example how to Onboard an endpoint to the fabric using ISE.
This document assumes you have a fabric already up and running with VNs, IP Pools, SGTs, and AAA settings in place. This document will not focus on these steps.
When writing this doc the following was used. DNAC 184.108.40.206 ISE 2.6 Patch 1
Cisco DNA Center with ISE integration How To Cisco DNA Center ISE Integration
VNs, SGTs, IP Pools, Authentication Template
Cisco DNA Center Deployment Steps
Create the VN . This will be achieved under Policy > Virtual Network In this example we have we created a VN named "ENG"
Assign SGTs In this example we have added a few SGTs - Engineering, Guests, HR, Students
Navigate to Provision > Fabric and choose the Fabric you created , Then choose "Host Onboarding" You will see the VN that was created in previous steps Assign IP pool to VN We have reserved an IP pool of 172.16.10.0 and assigned it to "ENG" VN
NOTE:When adding the IP Pool to VN it is important to understand the significance of the name created by SDA and why there is an option to actually modify that name. This is out of the scope of this document but you can find the explanation in the following document: SDA-Access Authentication Policy Naming Best Practice
The Authentication Template chosen in this example is "Open Authentication" which is in the upper part of "Host Onboarding".
To check the actual configuration the template applies at the port level we can navigate in Cisco DNA Center to Fabric Infrastructure , and click on the Fabric Edge device at which time a slide in window will appear with information regarding the specific Edge device. Click on "Configuration" to see the device configuration.
The Cisco DNA Center section is complete and in this next section will show the steps needed in ISE to accomplish dynamic Onboarding.
ISE Deployment Steps
The way ISE interprets and views the VN and the IP Pool assigned to it , is by binding it to the SGT that was assigned to the VN, This can be seen in the diagram below under SGT "Engineering".
So lets take a quick look of the steps that were taken ,
We created the VN (ENG)
We assigned the SGTs to the VN (HR, Engineering, Guests, Students)
We assigned an IP pool to VN (172_16_10_0-ENG) So if for example we were to take a look at the SGT "Engineering" in ISE , we would see the VN "ENG" and the address pool that we assigned to it in Cisco DNA Center. Navigate to Work Centers > TrustSec > Components > Security Groups (which is on the left hand side) and click on SGT "Engineering"
The next step is to create the "Authorization Profile" which is the Authorization that is applied once the endpoint is Authenticated and meets that Authorization Conditions.
In ISE Navigate to Policy > Policy Elements > Results > Authorization (left hand side) > Authorization Profiles
Will Name it "Engineers"
Under "Common Tasks" we will check mark "Security Group"
In the first field of "Security Group" we will choose the SGT "Engineering"
Once the SGT is chosen an additional field will appear which is the VN field , We will chose VN "ENG"
As soon as we choose the VN "ENG" the last field will appear , which is the "Subnet/IP Address Pool Name" at this stage we will choose the IP Pool Name "172_16_10_0-ENG" (Note:You may have multiple IP Pools in a single VN)
Your Authorization Profile should look like this.
We can now create the Authorization Policy and apply the Authorization Profile we created above (also known as the Rule) Note: We will not cover the Authentication Policy and we will use default Policy Set
Navigate to Policy > Policy Sets and choose the "Default" just under it by clicking the arrow on the right hand side which will expand the Policy Set
Click on "Authorization Policy" Policy to expand and create a new Authorization Policy Named "Engineering" Your Authorization Policy should look like this:
Notice the "Security Groups" field is empty , this is because we already applied the SGT in the Authorization Profile so there is no reason to add it here.
But what if you did not want to assign an SGT to the endpoint and still have it assigned a VN ? In this case you would use the "VLAN" option under "Common Tasks" in the Authorization Profile we previously created (Engineers) instead of "Security Group"
Which should look like this:
Make sure to enter the VN name correctly otherwise it will not work , best practice is to copy the VN name from the SGT section and paste it in the field.
You can then use that same Authorization Policy we created previously and if later you wish to start assigning an SGT while Onboarding the endpoint you can choose it from the "Security Groups" field in the Authorization Policy:
In this document you have learned how to dynamically assign a VN (Macro Segmentation) and an SGT (Micro Segmentation) while Onboarding an endpoint based on an Authorization Policy.
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
... View more
In a typical network a DHCP flow would look something like this.
If your DHCP server resides on a different subnet (which will most probably be the case) you would use the command “ip helper-address x.x.x.x” to overcome the broadcast barrier that a Layer3 Network device has by taking the DHCP broadcast request and forwarding it in a DHCP unicast request to the DHCP server.
In the Fabric the behavior is slightly different, as our DHCP server will reside outside the fabric , like in Data Center for example.
We also use Anycast GW in the fabric to allow for seamless mobility and this will also have affect on a normal DHCP flow.
Before reading this document, you must have a basic understanding of the following Architectural terms:
Understanding of SDA Virtual Network Identifier (VNI) Virtual Routing and Forwarding (VRF) Switch Virtual Interface (SVI) Dynamic Host Configuration Protocol (DHCP) / Flow
Anycast address is an address allocated to a set of interfaces that typically belong to different routers and in the fabric, this allows for seamless mobility as the endpoint moving from one fabric edge device to another does not need to change their Default GW address. For this reason, you will notice that every Switch Virtual Interface (SVI) that is provisioned by Cisco DNA Center is present on every Fabric Edge device with the same virtual IP and MAC address.
The SVI will have the DHCP Server IP address configured as its ip helper address, just as you would in a typical non-fabric network where the DHCP Server resides on a different subnet than your endpoint.
Now imagine you have 5 Fabric Edge devices and the SVI address is identical across all of them (See Illustration 1 below). The fabric edge device sends a DHCP Request on behalf of the endpoint using its own SVI address. How will the Border Device know to which Edge device it needs to return the DHCP reply to?
DHCP Flow in The Fabric
When creating the fabric, we create VNs for the different services we require.
For example we may create
INFRA_VN – Used for Access Points and Extended Nodes in the GRT
DEFAULT_VN – We can use as our Underlay VN
USERS_VN – Created for user access
Whats important to keep in mind is that VNs in the fabric are the equivalent to VRFs but with added attributes.
The USERS VN for example will need access to a DHCP server which is beyond the fabric meaning it resides in a different routing table (what we refer to as the Global Routing Table in the network), and in order to reach the DHCP server we need to leak the routes between the VRFs routing table and the GRT, and this is done using what we call a “Fusion Router”.
In the illustration above we are using a “GLOBAL” VRF as our Global Routing Table (GRT). On the left-hand side, we will defer to "USERS" VRF as an example for the user access.
We route-leak the routes in the VRFs on the “Fusion Router” which can be seen in this CLI example.
ip vrf USERS rd 1:4099 route-target export 1:4099 route-target import 1:4099 route-target import 1:4097
ip vrf GLOBAL rd 1:4097 route-target export 1:4097 route-target import 1:4097 route-target import 1:4099 The endpoint device will now be able to reach the DHCP server.
In the next section will discuss how exactly the Border GW actually knows to which Fabric Edge device it needs to send the DHCP reply to.
Client from subnet 10.1.18.0/24 sends DHCP request
The DHCP request is sent from the Edge device to the DHCP server adding option 82/Circuit ID.
The “magic” lays in option 82 which provides additional DHCP information regarding the clients point of attachment, in this case it would be the RLOC loopback address 220.127.116.11 as well as the
VN-ID 10 (vrf id 10).
The Border will forward the DHCP request via the Fusion Router so it may reach the DHCP server as explained earlier.
Before proceeding with the flow let’s look at the configurations that are needed to accomplish this.
The following configurations are needed to enable option 82 as well as pointing to the ip helper-address.
This is Automated by Cisco DNA Center.
“ip dhcp relay information option” – enables option 82 and is also automatically enabled by Cisco DNA Center. Without this command DHCP in the Fabric will not work.
In order for the DHCP server (which is outside the fabric) to learn the endpoints subnet we need to advertise it into BGP, and we do this by using the config below in the diagram.
Notice how we use the “Interface Loopback3000” to advertise the subnet. This is common rule in networking - if router does not know of a route to the endpoints subnet it will not advertise the subnet to others. Which makes sense right? so we “fool” the router thinking it knows of subnet 10.1.18.0/24 by adding loopback3000 with an IP from the endpoint’s subnet (in this case the SVI address).
This to is automated by Cisco DNA Center.
The DHCP server will check the GIADDR address and offer an ip address from that subnet. In the process option 82 is also sent back to the Border GW without the DHCP server processing it.
NOTE: Make sure your DHCP server supports option 82, Windows Server 2008 for example does not support Option 82.
Proceeding with the step 4 or the DHCP flow
5. The Border GW will extract the option 82 information and send the DHCP reply.
Fabric Edge device is RLOC=18.104.22.168 VNI=10
The following commands on the Border GW achieve step 5
vrf forwarding User
ip address 10.1.18.1 255.255.255.255
When using an ASR1K or an ISR4K as your Border Device and additional command will be added to the interface loopback which is
This to is automated by Cisco DNA Center but good to keep in mind.
6. At this final step the Border gw will send the reply to the Fabric Edge device in which the request originally came from by using the RLOC address and VNI 10.
... View more
Whether you’re beginning your SD-Access journey or are in the process, it's critical to understand the various components that make up the SD-Access solution: Design, Provision, Policy, and Assurance.
Its important to understand that Identity Services Engine (ISE) is a key component with in Cisco DNA Center providing Intent Services like:
AAA (RADIUS and TACACS+)
Macro and Micro Segmentation
To leverage these services we need to perform Cisco DNA Center ISE Integration to establish trust between the two entities and in the following guide we will provide the steps.
DNAC and ISE compatibility versions:
SD-Access Product Compatibility
There are 3 main services that need to be enabled and running in order to complete a successful Integrations:
Just before you begin check to make sure ISE and Cisco DNA Center can ping each other, This may sound trivial, but many times is overseen and can save some headaches.
SSH enables the exchange of certificates to establish a trust relationship between ISE and Cisco DNA Center.
Verify that SSH is enabled on ISE. The following entry can be seen on the CLI Note: Both CLI and GUI Account must have identical passwords.
Validate by performing SSH from Cisco DNA Center to ISE , as well use the same username and password to access ISE GUI ( http://<ISE-Node> )
Various ERS API calls are used for the following:
- Certification exchange
- Cisco DNA Center requires knowledge of the ISE deployment infrastructure in order to subscribe to the pxGrid Persona
- pxGrid - subscription to ISE publisher to retrieve contextual date and SGTs
- Update ISE with Cisco DNA Center Orchestrated Group Based Policies (SGTs,Contracts)
In ISE, navigate to Administration > System > Settings > ERS Settings and verify the "Enable ERS for Read/Write" check box is marked.
Cisco DNA Center will subscribe to the pxGrid publisher in order to retrieve contextual data as well as the SGTs.When integration is complete the Scalable Groups on the Policy Dashboard in Cisco DNA Center will be updated reflecting the existing list of SGTs on ISE.
Navigate to Administration > System > Deployment and click the node on the right hand side.
Navigate on Cisco DNA Center dashboard to the top right and click on the cog icon and select "System Settings"
Select "Settings" tab and choose "Authentication and Policy Servers"
Click on the plus icon and enter the ISE settings
Once complete click "Apply"
Note: To complete the integration process you may need to log onto your ISE instance and navigate to Administration > pxGrid Services to approve "dnac" Subscriber at which stage the "Pending" Status will change to "Online".
When Integration is completed you will notice on the Cisco DNA Center Policy Dashboard that the "Scalable Groups" value has incremented to the value of the number of SGTs currently on your ISE deployment (the value was null before the integration).What you are witnessing is Cisco DNA Center retrieving the ISE SGTs over API call.
As a sanity check, create an SGT on ISE and see how it increments on the Cisco DNA Center Policy dashboard.
... View more
You can find some useful info in the following resrouces
... View more
The 3615 will only support up to 10k concurrent sessions not matter the deployment model , that being said it doesnt mean it wont work but in terms of Cisco its not supported.
Your best option is what you suggested .
... View more