Overview This integration will enable customers to use common policies across Cisco SD-Access and Cisco ACI essentially to simplify policy management for customers using Cisco technology in different operational domains. We will be able to maintain common policy management across domains by providing common groups for different domain management applications to leverage. we will have consistent security policy groups in Cisco SD-Access (SDA) and ACI domains. There are many roles which span across multiple domains such as financial, healthcare, manufacturing, where critical applications are located in data center which should only be accessible to authorized campus endpoints. There are multiple use cases which needs to be addressed such as: To be able to maintain separation meaning, giving access to HR applications only to folks in HR and development applications access to only developers. Restricting access to confidential property in data center to certain users only based on their role and authorization. Enabling customers to easily extend policy from one domain to another easily. Cisco SD-Access (SDA) Overview: Cisco SD-Access provides automated end-to-end segmentation to separate user, device and application traffic without redesigning the network. Cisco SD-Access automates user access policy so organizations can make sure the right policies are established for any user or device with any application across the network. This is accomplished with a single network fabric across LAN and WLAN which creates a consistent user experience anywhere without compromising on security. Benefits of Cisco SD-Access include: ● Consistent management of wired and wireless network provisioning and policy. ● Automated network segmentation and group-based policy achieved using SGTs. ● Contextual insights for fast issue resolution and capacity planning. ● Open and programmable interfaces for integration with third-party solutions. Cisco ACI Overview: ACI shares some base characteristics with SD-Access (SDA) in that it provides policy for base security, QOS, path selection and service chaining via a construct called endpoint groups (EPGs). Endpoint groups to customers are synonymous with Scalable Groups used in cisco SD-Access (SDA), hence customers need interoperability between EPGs and SGTs, so that they can apply policy within the data center leveraging groups using context from Cisco SD-Access (SDA). Cisco SD-Access (SDA)-Cisco ACI Integration: This phase of integration enables sharing of policy groups between Cisco SD-Access (SDA) and Cisco ACI environments to benefit customers but here are the caveats: Integration works with single ACI Fabric Scale limits on ip to group mappings handled by ACI border leaf. Single ACI Tenant. Single L3out in ACI tenant. Shared L3out not supported. How the Integration works: Cisco DNAC and ISE are integrated over pxgrid and group information is exchanged between them. Similarly, ISE and APIC-DC exchange groups and member information. ISE and APIC-DC exchange SGT to EPG mappings and ISE and APIC exchange IP endpoint to EPG/SGT mappings. Configuration: Topology: Looking at above topology, Cisco SD-Access (SDA) will have LISP as its control plane protocol and VXLAN as its Data plane protocol inside the fabric and is connected to ACI fabric using BGP/IGP and VRF-LITE and Each of the fabric configuration is automated by their respective controllers but the configuration between the domains is achieved manually and we need a fusion device to achieve this which can be a router/switch/firewall doing the route leaking. Cisco DNAC to ISE Integration: DNA Center uses AAA servers for user authentication and Cisco ISE for both user authentication and access control. Cisco Identity Services Engine (ISE) is a next-generation identity and access control policy platform that enables enterprises to enforce compliance, enhance infrastructure security, and streamline their service operations. Integration between DNAC with ISE allows SGT groups and enforcement policy (SGACLs) to be transferred between the DNAC and ISE platforms using Cisco pxGrid. **Please check Cisco SD-Access (SDA) compatibility matrix for recommended hardware/software versions. Check basic connectivity between ISE and Cisco DNA-C server SSH enabled on ISE. SSH from both DNAC host needs to be successful. ERS needs to be ENABLED on the ISE PAN node. ISE CLI & GUI password must be the same. Pxgrid service is running on ISE Make sure we give right FQDN details on DNAC. After the Integration, all the SGTs are visible in Cisco DNAC and we can manage groups/policies from Cisco DNAC itself. More details on Cisco DNAC to ISE Integration available at this link: https://community.cisco.com/t5/networking-documents/how-to-cisco-dna-center-ise-integration/ta-p/3896410 Cisco ISE to ACI Integration: With this integration, SGTs in enterprise environment. can be converted to EPGs in ACI and vice versa. Cisco ISE helps in sharing of consistent security policy groups between Cisco SD-Access (SDA) and ACI domains. In this integration, ISE PAN communicates with APIC-DC to synchronize SGTs to EPGs. IP-group mappings are managed by ISE PSN running SGT eXchange protocol (SXP) service. To achieve this SXP service needs to be enabled on ISE and also APIC-DC details needs to be entered in ISE ACI settings. After entering the settings, ISE and APIC-DC are going to establish a two-way communication over an API channel.   Import APIC-DC certificate into ISE: We need to first establish a secure communication between Cisco ISE and APIC-DC and in order to do that we import APIC-DC certificate into ISE Trusted certificates store. Enter the APIC-DC ip address in the browser and click the view certificate from browser window and export the certificate. Navigate to Trusted Certificates section in the ISE UI: Administration > System > Certificates > Trusted Certificates. Import the APIC-DC certificate to ISE.   This is how it shows up after successful import of certificate. EPGs that are received from APIC-DC are assigned numeric value of 10,000 and so on and you can change the starting number as well from here: Navigate to General TrustSec Settings in ISE: Work Centers > TrustSec > Settings > General TrustSec Settings SGTs are sent to APIC when the integration happens but we can choose whether to propagate newly created SGTs to APIC-DC or not On APIC-DC, we will have application profiles and end point groups (EPG)s in a tenant and we connect this tenant to outside world such as Cisco SD-Access (SDA) via BGP/IGP using L3 outside and servers inside vrf which are mapped to l3out. Below, you can see we have EPG1 created and associated to an application profile under SDA-Tenant. Establish BGP/IGP connectivity from ACI to Fusion device and here Is an example of bgp peering Once the ACI fabric is configured, then navigate to ACI Settings Screen in ISE: Work Centers > TrustSec > Settings > ACI Settings and enter the ACI details. Make sure checkbox for “Trustsec-ACI Policy Element Exchange” is selected as this is to enable SGT-EPG Integration. Naming convention is suffix appended to learned/shared groups An SXP Domain is a collection of SXP Devices and the administrator can decide which domain to send IP-to-SGT mappings to. This is not mandatory as a Default Domain exists and this is used by default for all SXP Devices and all IP-to-SGT mappings. If using SXP Domains to control the distribution of mappings, add the required Domains from Work Centers > TrustSec > SXP > SXP Devices Each domain is a unique table of IP/SGT bindings which can be peered independently from other domains and you can choose to have each domain pointing to each VN or Site. You can set ISE SXP Domain filters in ISE from Work Centers > TrustSec > SXP > All SXP Mappings > Manage SXP Domain Filters Once the above settings are saved, ISE and APIC-DC will start sharing the policy group information with each other Now, you can see SGTs provisioned from Cisco SD-Access (SDA) to ACI via ISE. In APIC-DC Navigate to Tenants > (Tenant Name) >Networking > External Routed Networks > L3 Outside (L3Out you used to integrate with ISE) > Networks. Similarly, you can see EPGs in Cisco SD-Access (SDA) via ISE under Work Centers > Trustsec > Components Verifying to SGT-IP and EPG-IP Mappings: In order to see the mappings from ACI in ise, there has to be a sxp device configured. Here you can see that after the group translation happened, the end points of EPGs are converted to IP mappings under All SXP mappings under ISE. You can check here: Navigate to SXP Mappings in ISE under Work Centers > TrustSec > SXP > All SXP Mappings We can also verify the IP-SGT mappings from ISE are converted to EPG members. As soon as the SGTs from Cisco DNAC are propagated as EPGs in ACI via ISE, the IP-SGT mappings are also visible in ACI as subnets under the EPGs. In APIC-DC ,navigate to Tenants > (Tenant Name) >Networking > External Routed Networks > L3 Outside (L3Out you used to integrate with ISE) > Networks. Click on the EPG and you’ll see the details as below: Verification: Policy Enforcement in ACI Domain: In the below Demo topology, we can see that we have Cisco SD-Access (SDA) and ACI domains and we have a user who is authenticated via 802.1x and has been assigned an SGT of 4/Employee and we have a server in ACI environment with EPG1. Once the integration happened the group information between the domains has been exchanged and we can create policy aka contracts in ACI environment via APIC-DC to control traffic between environments. We can see that Employee is successfully authenticated in Cisco SD-Access (SDA) environment. By default, in ACI traffic is denied, and we need to create a policy to allow the traffic between the groups Traffic is denied as we do not have any contracts Here, we create a contract between Employee SGT and Server EPG1 Once we created the contract, we see traffic allowed between the clients Policy Enforcement in Cisco SD-Access Domain: In the above Demo topology, we can see that we have SD-Access (SDA) and ACI domains and we have a user who is authenticated via 802.1x and has been assigned an SGT of 4/Employee and we have a server in ACI environment with EPG. Once the integration happened the group information between the domains has been exchanged and if we are creating policy in Cisco SD-Access (SDA) environment and if we want to enforce policy here we need to make sure that destination group information of EPG server is also known to SDA environment or whichever device we are doing policy enforcement. To achieve this, we build an SXP tunnel from ISE to the destination device, here in the topology above, we are building an SXP from ISE to Border so that EPG information is propagated to the Cisco SD-Access (SDA) environment and enforcing at Edge device. Alternatively, we can build SXP from ISE to Fusion device which can be a router/switch/firewall so that we can enforce on those devices before the traffic reaches the Cisco SD-Access (SDA) environment as well like the below topology. For this demo, we are going to see SXP built between ISE and border and enforcing on edge. We can see that Employee is successfully authenticated in Cisco SD-Access (SDA) environment. We can see below that Employee is able to reach the server: We can see that there are no policies configured on the Edge device. Now, we are going to create a group-based access-list denying the traffic between employee and Server Once the policy is created, we have to deploy the policy by clicking deploy so that this is pushed to devices in the fabric. Once the fabric is created, we can see that traffic is denied between Employee and Server and we can see policy being pushed to devices and counters are incrementing:   Now, we can see that the counters are incrementing:       References: BRKCRS - 2821 - Cisco Live Presentation   Policy Enforcement within Cisco SD-Access (SDA) Border https://community.cisco.com/t5/security-documents/policy-enforcement-within-sda-border/ta-p/3646816#toc-hId--1069166528   ... View more

Contents Introduction This Document shows how we can set up 2 Factor authentication using RSA SecurID token with one time token based on a PIN to login to the Cisco DNAC Web interface. Two factor authentication provides two or more authentication factors to gain access into a secured system. This also increases security by requiring a pin and use a device we have such as laptop ,mobile ,hardware .By using One-time password which is only valid for one login session, we overcome organizational security concerns of using only a static password. The 2-factor authentication is supported only for Cisco DNAC configured to authenticate the user against an external authentication server over RADIUS protocol. Cisco ACS supports the RSA SecurID server as external database and RSA SecurID two-factor authentication consists of users PIN and individually registered RSA SecurID token that generates single use token codes. RSA server validates this code and each RSA SecurID token is unique . When the correct token code is supplied together with a PIN, user is authenticated and thus RSA SecurID servers provide reliable authentication mechanism compared to already set passwords   Prerequisite Cisco DNAC Appliance An authentication server such as ACS, ISE, or other RADIUS servers that is able to return cisco-av-pairs to convey the RBAC role authorization of the authenticated Cisco DNAC users A 2-factor token server such as RSA Secure ID that can function as backend of ACS/ISE or support the RADIUS protocol above. Token card or RSA Secur ID application on client PC/Mac that generates the login token   Devices Used Cisco DNAC Cisco Secure Access Control System (ACS) 5.8 RSA SecurID Token Server ( RSA Authentication Manager-7.2 ) RSA SecurID Token Client   Configuration We created two users in RSA SecurID AM as admin_dnac and observer_dnac First Integrate RSA- Authentication manager with Cisco ACS Create a new Authentication Agent pointing to Cisco ACS with its details. This is done under Access > Authentication Agents > Add New: After you added, it shows up like this Now from , RSA Security Console, navigate to Access > Authentication Agents > Generate Configuration File in order to generate the sdconf.rec configuration file: Use the default values for Maximum Retries and Maximum Time Between Each Retry: Download the configuration File The .zip file contains the actual configuration sdconf.rec file, which the ACS administrator needs in order to complete configuration tasks. As a first part of authentication, we have to generate PIN for each username in RSA-AM Log into the RSA-AM Console-self service using Screenshot below , we logged in as admin_dnac and there we will have the option to set/change PIN for each username. Now Go to the Cisco ACS Server In the Cisco Secure ACS Version 5.x console, navigate to Users and Identity Stores > External Identity Stores > RSA SecurID Token Servers, and click Create: Enter the name of the RSA server, and browse to the sdconf.rec file that was downloaded from the RSA server: Which shows up like this Now the Cisco ACS and RSA – AM are successfully integrated Now Make sure you have a Shared Secret for RADIUS Under Network Resources > Default network Device Now, Create a Authorization Profile under Policy Elements > Authorization and Permissions > Network Access > Authorization Profiles Create a Profile Edit this profile in such a way that it returns cisco-av-pair with role NETWORK-ADMIN-ROLE Create similarly for Observer as well Create Access Service Add RSA- AM as Identity On ACS, create authorization policy rule to return the Authorization Profile corresponds to the different users or user group.  In this paper our rule is based on the User-Name as an illustration. The AdminRule match the admin_dnac and returns the admin authorization, and the ObserverRule match the observer_dnac and returns the read only authorization. After Creating, it looks like this Once the profiles are created, make sure you have tokens for each users under RSA Security Console. Then, Integrate ACS into Cisco DNAC under Settings > Authentication and Policy Servers and enable External Authentication under Settings > Users > External Authentication and point to ACS Server. Once the Integration is done, register the RSA Token with RSA token server, this ensures that only user in procession of the token is able to use token Open the RSA SecurID Token client and enter the pre-set PIN in the RSA SecurID Token client as a first factor of authentication Which in turn gives you one time token as below which you enter while authentication with the username Enter the username and one time token on the Cisco DNAC login page.   User passed authentication is allowed access. This is how 2 factor authentication is achieved with a combination of PIN + One time token.   Authentication Workflow User generates PIN using RSA SecurID client to get RSA SecureID token On the Cisco DNAC Login page user enters username and RSA SecureID token Cisco DNAC will send the username/Passcode request to ACS over RADIUS Protocol ACS in turn sends it to the RSA AM RSA AM sends it to acs that authentication is successful ACS matches the authenticated user to the configured authorization profile ACS returns the cisco-av-pair with role=NETWORK-ADMIN-ROLE of the authorization profile Cisco DNAC use the RBAC role to give the user access to relevant features and pages   Verification We can verify the login from the live logs from Cisco ACS and RSA-AM On RSA-AM Authentication Monitor Dashboard, we can see that dnac_admin was able to successfully log in Under ACS Monitoring and Reports > Launch Monitoring and Report Viewer We can also see that we were able to successfully log in to the Cisco DNAC via admin_dnac       ... View more

  Introduction Cisco DNA Center gives us the flexibility to configure multiple fabric sites and connect them using different Transits. In this paper, we are going to talk about how we can connect multiple fabric sites using IP as a transit and how can we carry SGTs over IP Transit.   What is a Fabric Site ? A “Fabric site” is a portion of the fabric which has its own set of Control Plane Nodes, Border Nodes and Edge Nodes. Different levels of redundancy and scale can be designed per Site by including local resources: DHCP, AAA, DNS, Internet, etc. A Fabric Site may cover a single physical location, multiple locations, or just a subset of a location. Single Location Branch, Campus or Metro Campus Multiple Locations Metro Campus + Multiple Branches Subset of a Location Building or Area within a Campus What is a Fabric Domain ? SD-Access fabric domain is hierarchal representation of fabric sites managed by Cisco DNAC SD-Access fabric domain can consist of multiple fabric sites and each site has its own devices which helps us achieve the benefits such as scale, resiliency and survivability. A Fabric domain should be able to scale horizontally by having state specific information within each site. What is a Transit ? Multiple Fabric sites in a single Fabric domain will be interconnected using a Transit. The SD-Access transit consists of Control plane nodes which helps interconnect multiple fabric sites. There are two types of Transits: SD-Access Transit - Enables a native SD-Access (LISP,VXLAN,CTS) fabric, with a domain-wide Control Plane node for inter-site communication. IP- Based Transit - Leverages a traditional IP-based (VRF-LITE, MPLS) network, which requires remapping of VRFs and SGTs between sites. IP Transit : Traffic between sites will use control and data plane of the transit network/WAN. The SD-Access Border will hand off the traffic to the directly connected WAN/External router and the traffic is delivered across the Wan/external domain to other site. No Lisp lookup with the transit control node is performed here as the border will hand off traffic to the WAN/External router using VRF-LITE. If SD-WAN is deployed in the transit network/WAN then performance based routing, Encryption etc. in the WAN is possible. End to end policy can only be maintained by Manual configuration. Why IP Based Transit ? IP Based Transit can be used if customers are already using existing WAN or have adapted SD-WAN. Tends to be many remote branch offices connected via traditional IP WAN/MPLS or SD-WAN. Also when there is a requirement for site-to-site encryption and traffic engineering and policy based routing. Typical use cases Internet Handoff P2P IPSEC encryption Policy Based Routing WAN Accelerators Traffic engineering Mobile Backhaul LTE SD-Access Distributed Campus Fabric IP as Transit IP transits provides IP connectivity without native Cisco SD-Access encapsulation (SD-Access transit provides).Using IP based transits we can connect the SD-Access fabric to external networks using VRF lite for ip connectivity. We need to make sure that SGT information is also carried between sites using below methods in “SGT Propagation between sites” section. Important to note that each fabric site has its own set of control plane nodes, edge nodes, border nodes, WLC. Cisco DNAC automates the BGP configuration for all the VRFs on the border nodes and it can be seen in the UI workflow below. When client gets authenticated and gets assigned an SGT, that packet is traversed to the destination in data plane using VXLAN encapsulation which carries the SGT in its header and when the client is trying to reach to destination outside of the fabric then the packet is de encapsulated at the border from VXLAN header where SGT preservation is also gone. The same applies for returning traffic as well which enters the border switch and as border does not know about SGT for that source or destination. In a SD-Access distributed deployment, you can have ISE PSNs dedicated to each of the fabric sites or for larger deployments where you  have more than 2 PSNs at a site, we can have PSNs centrally located at a data center behind a load balancer and point the VIP of load balancer from DNAC settings Supported Platforms for Border (as of Cisco DNAC 1.2.10) Cisco SD-Access Border Node Cisco SD-Access Transit IP Transit C9K YES YES ASR1K/ISR4K YES YES C6K NO YES N7K NO YES Fusion Device As Cisco SD-Access achieves macro segmentation using vrfs, Users in those vrfs would want to talk to shared services residing out of the fabric which is in global routing table and we use a fusion devices which can be either router/switch/firewall to do route leaking leveraging the L3 handoff on the Border. If the fusion device is a cisco firewall then ASA supports both SXP and inline tagging. Cisco FTD supports pxgrid and inline tagging and it will know about SGTs via pxgrid from ise. Now ,we will look at how we can propagate SGTs. Steps on Configuring Fusion router https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/dna-center/213525-sda-steps-to-configure-fusion-router.html#anc11 SGT Propagation between sites Note: Assuming Cisco ISE is deployed in the network and end users are authenticating to Cisco Ise via 802.1x or any other method. Cisco ISE will assign Security Group Tag (SGT) once they authenticate to your wired/wireless network. There are two ways in which we can make sure that SGTs are propagated across Fabric Sites. Device Inline Tagging. Using SXP or Scalable group tag exchange Protocol Device Inline Tagging Inline tagging is the process where the Security Group Tag is carried within a special field known as CMD (Cisco Meta Data) that can be inserted in an L2 header, whether that be Ethernet, IPsec or Tunnel as in GRE/DMVPN. EtherType:0x8909 16-Bit SGT encapsulated within Cisco Meta Data (CMD) payload. We have to make sure all the devices in the path support Inline tagging. Cisco TrustSec-capable devices have built-in hardware capabilities than can send and receive packets with SGT embedded in the MAC (L2) layer. It allows Ethernet interfaces on the device to be enabled for L2-SGT imposition so that the device can insert an SGT in the packet to be carried to its next hop Ethernet neighbor. SGT-over-Ethernet is a method of hop-by-hop propagation of SGT embedded in Ethernet packets. The inline identity propagation is scalable, provides near line-rate performance and avoids control plane overhead. Configs that need to be enabled on each and every device in the path on both ingress/egress interface is : Border# configure terminal Border(config)# interface gigabitethernet 1/0/1 Border(config-if)# cts manual Border(config-if-cts-manual)# propagate sgt Border(config-if-cts-manual)# policy static sgt 54 trusted Enable this on all the sub interfaces on routers and physical interfaces on switches on the interface facing outside of the fabric from Border. SGT Platform Compatible Matrix https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/trustsec/software-platform-capability-matrix.pdf Using SXP or Scalable group tag exchange Protocol SXP or Scalable group tag exchange Protocol is a TCP-based, control plane protocol used to exchange IP to SGT bindings that have been created on a network device through either dynamic assignment (802.1X, MAB, WebAuth) or statically via CLI with peer networking devices. SXP is supported on most Cisco Routers, Switches, Firewalls, and the Cisco Identity Services Engine or ISE. IP-to-SGT binding exchange over 64999/TCP SXP is typically used in scenarios where a network devices do not support inline tagging. SXP is used to propagate the IP-SGT information over the above mentioned network. Here's how we create SXP sessions between border switches and ISE. The SXP tunnel should be created individually for each VN. By using this you have to build SXP for each vrf onto the border device. Alternatively, we can create sxp domains on ise which allows you to put certain mappings in each domain and only send once you want to each VN using ISE SXP Domain Filters. An SXP Domain is a collection of SXP Devices and the administrator can decide which domain to send IP-to-SGT mappings to. This is not mandatory as a Default Domain exists and this is used by default for all SXP Devices and all IP-to-SGT mappings. If using SXP Domains to control the distribution of mappings, add the required Domains from Work Centers > TrustSec > SXP > SXP Devices: Each domain is a unique table of IP/SGT bindings which can be peered independently from other domains and you can chose to have each domain pointing to each VN or Site. You can set ISE SXP Domain filters from Work Centers > TrustSec > SXP > All SXP Mappings > Manage SXP Domain FIlters SXP isn’t orchestrated from Cisco DNAC today so we can use template editor in DNAC to configure SXP tunnel. Once the destination SGTs are known to Border via SXP and source SGTs are already known, we can do enforcement on the border manually by entering cts role based enforcement for those vlans on the trunk interface egressing towards the WAN. Configuring SXP between Border and ISE: Check to make sure SXP is enabled in ISE. Administration > System > Deployment > (ISE Hostname) Now, configure SXP on the border for respective VNs. cts sxp enable cts sxp default password <password> cts sxp connection peer <> source <> password default mode local listener vrf <> Now go to ISE, to the "Work Center > TrustSec > Settings > SXP Settings" and Make sure the password is matched on ISE as well Now go to "Work Center > Trustsec > SXP > SXP Devices" and add a session each for each VN on each border.  We can check the status of SXP connection using below commands: show cts sxp connections vrf Campus show cts sxp connections brief We can perform Policy enforcement at the Firewall as well by building SXP from ISE to Firewall and sending the mappings to the firewall and sending SGTs from border to firewall via inline tagging as ASA firewall supports both types of SGT propagation.   Which Border to Pick ? Cisco SD-Access Network Requirements Latency Requirements (RTT) In Summary, device latency should be around 100 msec RTT, you can go up to 200 msec RTT but there could be a performance hit. Anything beyond 200 msec is not recommended by Cisco at this time The RTT (round-trip time) between Cisco DNA Center and network devices should be taken into consideration. The optimal RTT should be less than 100 milliseconds to achieve optimal performance for base automation and assurance. When RTT is between 100 milliseconds and 200 milliseconds, longer execution time could be experienced for certain events including Inventory Collection, Fabric Provision and Image Update, ranging from a few minutes to tens of minutes. Cisco does not recommend RTT more than 200 milliseconds.   Resources SDA Platform & Compatible Matrix https://www.cisco.com/c/en/us/solutions/enterprise-networks/software-defined-access/compatibility-matrix.html SDA CVD https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Campus/CVD-Software-Defined-Access-Design-Sol1dot2-2018DEC.pdf SGT Design Guides https://www.cisco.com/c/en/us/solutions/enterprise-networks/trustsec/design-guide-listing.html Segmentation Strategy Document https://community.cisco.com/t5/security-documents/segmentation-strategy/ta-p/3757424 SGT Troubleshooting Guide https://community.cisco.com/t5/security-documents/trustsec-troubleshooting-guide/ta-p/3647576 ... View more

Introduction Currently we are relying on solutions such as MPLS/BGP for fabric sites to talk to each other and prefixes are exchanged between fabric sites using the above technologies using Border routers to steer traffic. This document helps us to implement SD-Access Distributed Campus that uses SD-Access Transit to interconnect multiple SD-Access fabric sites. The design follows the Cisco SD-Access of running independent Mapping Systems on each fabric site, so that they are run as independent administrative domains. The architecture has requirement of running independent control plane nodes for each fabric site which helps us achieve resiliency, survivability for each fabric sites. What is a Fabric Site ? A “Fabric site” is a portion of the fabric which has its own set of Control Plane Nodes, Border Nodes and Edge Nodes. Different levels of redundancy and scale can be designed per Site by including local resources: DHCP, AAA, DNS, Internet, etc. A Fabric Site may cover a single physical location, multiple locations, or just a subset of a location. Single Location Branch, Campus or Metro Campus Multiple Locations Metro Campus + Multiple Branches Subset of a Location Building or Area within a Campus What is a Fabric Domain ? SD-Access fabric domain is hierarchal representation of fabric sites managed by Cisco DNAC SD-Access fabric domain can consist of multiple fabric sites and each site has its own devices which helps us achieve the benefits such as scale, resiliency and survivability. A Fabric domain should be able to scale horizontally by having state specific information within each site. What is a Transit ? Multiple Fabric sites in a single Fabric domain will be interconnected using a Transit. The SD-Access transit consists of Control plane nodes which helps interconnect multiple fabric sites. There are two types of Transits: SD-Access Transit - Enables a native SD-Access (LISP,VXLAN,CTS) fabric, with a domain-wide Control Plane node for inter-site communication. IP- Based Transit - Leverages a traditional IP-based (VRF-LITE, MPLS) network, which requires remapping of VRFs and SGTs between sites. SD-Access Transit Traffic between sites will be use VXLAN+SGT encapsulation driven by a LISP The SD-Access Border will do a LISP lookup with the control plane node in the transit network and perform a VXLAN encapsulation to deliver the traffic to the other site. End to end policy is maintained using SGT group tags . No performance based routing is possible in the Transit network/WAN. Fully Automated Turn key solution. Why SD-Access Transit ? SD-Access Transit can be used if customers have multiple sites connected via Dark Fiber links or DWDM Links or sites in same metropolitan area. Typical use cases Consistent policy and end-to-end segmentation using VRFs and SGTs Why Multiple Fabric sites Vs Single Fabric Site ? Advantages: Smaller or isolated Failure Domains Helps scaling number of Endpoints Cisco DNAC provides Automation and Single View of entire system VNs and SGTs gets pushed to all sites (consistent policy) Local breakout at each Site for Direct Internet Access (DIA) Smaller and Isolated fault domains Resiliency and Scalability SD-Access Distributed Campus Fabric with SD-Access as Transit Basically a Distributed Campus is collection of Fabric sites interconnected via a transit Picture below interprets the same   The control plane node in each of the fabric sites will hold prefixes of end points connected to Edge nodes within that fabric site only which means end hosts in each site will be registered to the local control plane node within the site. Any end points which isn’t registered with the local control plane node will have to be reachable via the Border Nodes connected to the Transit Site. The Control Plane node in the transit site will have the summary state information for all Fabric Sites that it is connected to. This information is made available to the Transit control plane node by Border Nodes that connect fabric sites to the Transit Site. Transit control plane needs to be a dedicated node. Which Border to Pick for Transit ?   When using Cisco DNAC to configure SD-Access Distributed campus with SD-Access transit we need to choose Outside world(external border) or Anywhere(internal +external) border when connecting to SD-Access transit. From the picture 1, we see that not every fabric site is connected to the Internet or Data Center. Border which is connected to the internet is the External Border and the Border connecting to the DC is Internal Border. We can have two control plane nodes in the SD-Access Transit and Transit control plane nodes today receive aggregate routes from site borders at each fabric site using LISP. Transit Control Plane nodes can be located Physically at different fabric sites or centralized in a headquarters or Data center basically requiring ip connectivity in the underlay reachability from site borders. MTU Settings for Cisco SD-Access for Distributed Campus with Cisco SD- Access as a Transit. To achieve end to end segmentation in a SD-Access Distributed Campus environment, we need to make sure that extra 50 byte of header is taken care of in the fabric and transit as well by having Jumbo MTU configured on all the devices. Alternatively, we can configure TCP MSS on Edge/Border nodes to achieve this as fragmentation is not supported in cisco SD-Access today. TCP MSS will have to be configured on the overlay SVI prefixes on Edge nodes and egress interfaces on Border facing outside the fabric and this will work for TCP applications in the fabric. We will send the packets with MTU set on the cli and hence no other known MTU setting is needed at the cisco SD-Access transit side and let’s say if your transport supports 1400 MTU then set the TCP MSS value to 1350 so that the 50 bytes is accounted for with VXLAN header. If we need to support UDP traffic over 1500 MTU as well then TCP MSS will not help. If the above caveats cannot be met then we have to use IP Transit instead of SD-Access Transit. Supported Platforms for Border (as of Cisco DNAC 1.2.10) Cisco SD-Access Border Node Cisco SD-Access Transit IP Transit C9K YES YES ASR1K/ISR4K YES YES C6K NO YES N7K NO YES SD-Access for Distributed Campus- Policy The Virtual Networks are preserved end-to-end as traffic traverses the Border Nodes from Fabric-site to Fabric-site via Transit. Policy is defined on a global basis and is relevant to the end-to-end Fabric. The enforcement of the policy is done by default at the Edge Nodes of the multi-fabric network. Policy Enforcement. Scalable Group Tags (SGTs) will be preserved as traffic traverses the Border Nodes between Fabric-sites and the Transit.   In a SD-Access distributed deployment, you can have ISE PSNs dedicated to each of the fabric sites or for larger deployments where you have more than 2 PSNs at a site, we can have PSNs centrally located at a data center behind a load balancer and point the VIP of load balancer from DNAC settings SD-Access for Distributed Campus- Wireless Each site has a WLC associated with its Control Plane Smaller locations in the same metro site may share a WLC Note: Mobility across Fabric Sites is not supported Packet Forwarding in Cisco SD-Access Transit H1 behind E1 in site 1 trying to reach H2 in E1 in site 2 H1 is trying to reach H2 E1 sends a map request to CP requesting for H2 As CP in Fabric Site 1 knows about prefixes in its own site only, it is going to send a negative map reply to E1 Based on the configuration of E1, traffic is sent to Border 1 (E1 is going to pick the border on a flow basis and here we chose Border 1 ) Based on the configuration on Border 1, it is going to send a map request to Transit CP requesting for H2 As Transit CP has information about all prefixes in the fabric domain , Border 1 will receive a map reply from Transit CP with the destination address as Border 3 Traffic is forwarded from border 1 to Border 3 using VXLAN encapsulation with SGT tags. Once Border 3 receives the traffic, based on the configuration on Border 3 it is going to send a map request to the CP node in its fabric and in this case as Border and CP are on the same node. Border 3 will have mapping information of the destination address which is behind E1 Traffic is forwarded to the edge node using VXLAN encapsulation with SGT Tags H2 behind E1 in fabric site 2 trying to reach Internet H1 is trying to reach a prefix in Internet E1 in Fabric site 2 will send a map request to the CP node requesting for the destination prefix Border/CP node in Fabric Site 2 is going to send a negative map reply to E1 as the destination prefix is not registered in the CP node Based on the configuration on E1 , it sends traffic to Border 3 Border 3 upon receiving the traffic , sends a map request to the Transit CP for destination prefix As Transit CP node does not have the prefix registered, it is going to send a Negative map reply to Border 3 Based on the configuration of Border 3 , it sends traffic to either Border 1 or border 2 Border 2 after receiving the traffic, sends a map request to the Transit CP node requesting for destination prefix Transit CP will send a negative map reply as it does not have the destination prefix registered in its database Once Border 2 receives the map reply, it will use native forwarding to send the traffic to the Internet Router H1 behind E1 in Fabric site 1 trying to reach DC prefix behind Internal Border 2 H1 is trying to reach a prefix behind Internal Border 2 in Fabric Site 2 E1 in Site 1 is going to send a map request to the CP node in Site 1 for DC prefix behind Internal Border 2 CP node is going to send a negative map reply as it does not have destination prefix registered in its database Based on the configuration on E1, it sends traffic to either Border 1 or Border 2 Border 1 or Border 2 will send a map request to Transit CP for destination Prefix As Transit CP knows about destination prefix registered in its database, it sends map request back to Border 1 or Border 2 with Border 3 ip address. As Border 3 knows about the destination prefix it is going to send the traffic to Internal Border 2 Once Internal Border 2 receives the traffic, it is going to forward the traffic to the destination in the DC   Example HLDs   Use Case 1     Use Case 2 ... View more

    Two-Factor Authentication for Cisco Digital Network Architecture (DNA) center Using Cisco ISE and RSA SecurID   Introduction This Document shows how we can set up two factor authentication using RSA SecurID token with one time token based on a PIN to login to the Cisco DNAC Web interface. Two factor authentication provides two or more authentication factors to gain access into a secured system. This also increases security by requiring a pin and use a device we have such as laptop ,mobile ,hardware .By using One-time password which is only valid for one login session, we overcome organizational security concerns of using only a static password. The two factor authentication is supported for Cisco DNAC configured to authenticate the user against an external authentication server over RADIUS/TACACS+ protocols. Cisco ISE supports the RSA SecurID server as external database and RSA SecurID two factor authentication consists of users PIN and individually registered RSA SecurID token that generates single use token codes. RSA server validates this code and each RSA SecurID token is unique . When the correct token code is supplied together with a PIN, user is authenticated and thus RSA SecurID servers provide reliable authentication mechanism compared to already set passwords.   Prerequisite Cisco DNAC Appliance 1.2.8 An authentication server such as ISE, or other RADIUS/TACACS+ servers that is able to return cisco-av-pairs to convey the RBAC role authorization of the authenticated Cisco DNAC users. A two factor token server such as RSA Secure ID that can function as backend of ISE or support the RADIUS protocol above. Token card or RSA SecurID application on client PC/Mac that generates the login token.   Devices Used   Cisco DNAC Cisco ISE 2.3 Patch 1 RSA SecurID Token Server ( RSA Authentication Manager-7.2 ) RSA SecurID Token Client Authentication Workflow User generates PIN using RSA SecurID client to get RSA SecurID token On the Cisco DNAC Login page user enters username and RSA SecurID token Cisco DNAC will send the username/Passcode request to Cisco ISE over RADIUS Protocol ISE in turn sends it to the RSA AM RSA AM sends it to ISE that authentication is successful ISE matches the authenticated user to the configured authorization profile ISE returns the cisco-av-pair with role=NETWORK-ADMIN-ROLE of the authorization profile Cisco DNAC use the RBAC role to give the user access to relevant features and pages Configurations We created two users in RSA SecurID AM as dnac_observer and dnac_admin First Integrate RSA- Authentication manager with Cisco ISE: Create a new Authentication Agent pointing to Cisco ISE with its details. This is done under Access > Authentication Agents > Add New: After we added, it shows up like this: Now from, RSA Security Console, navigate to Access > Authentication Agents > Generate Configuration File in order to generate the sdconf.rec configuration file: Use the default values for Maximum Retries and Maximum Time Between Each Retry: Download the configuration File The .zip file contains the actual configuration sdconf.rec file, which the ISE administrator needs in order to complete configuration tasks. As a first part of authentication, we have to generate PIN for each username in RSA-AM. To do that , Log into the RSA-AM Console-self service using Log into the above Link as users we created dnac_admin and dnac_observer and generate a Pin for each user. Now Go to the Cisco ISE In the Cisco ISE, navigate to Administration > Identity Management > External Identity Sources > RSA SecurID, and click Create: Upload the sdconf.rec file that was downloaded from the RSA server: Which shows up like this Now the Cisco ISE and RSA -AM are successfully integrated We can have Cisco DNA Center added as a network device with RADIUS or TACACS+ key set under Administration > Network Devices. For this paper, we have configured a network device called DNAC and assigned a device type “DNAC” for ease of policy creation. Cisco DNA center can be added as a network devices for RADIUS/TACACS+ We will now create two authorization profiles, one for an Admin role and one for a Cisco DNAC Observer role. Create Authorization Profile under Policy > Policy Elements > Results > Authorization > Authorization Profiles. Edit this profile in such a way that it returns cisco-av-pair with role NETWORK-ADMIN-ROLE For dnac_admin and OBSERVER-ROLE for dnac_observer users. NETWORK-ADMIN-ROLE Authorization profile OBSERVER-ROLE Authorization profile Now we Create Authentication Policy for Cisco DNAC pointing to RSA-AM under Policy > Authentication Policy The authentication policy is created to match on Device type DNAC and the identity store that will be checked is RSA SecurID Create a Policy Under Policy > Policy Sets > Authorization Policy. We create two authorization policies, one for admin role and one for observer role. We are matching on the user name here as a condition for authorization policy evaluation. NOTE: In the above screenshot the authorization condition is mapped to username and in a production environment, you can change the authorization condition to use AD Group Membership if the users are present on AD. Once the profiles are created, make sure you have tokens for each users under RSA Security Console. Configuring Cisco DNAC for RBAC using ISE as the External authentication server Two factor authentication using RADIUS Integrate ISE into Cisco DNAC under Settings > Authentication and Policy Servers and enable External Authentication under Settings > Users > External Authentication and point to Cisco ISE. Shared Secret have to match between Cisco DNAC and ISE. Once the Integration is done, register the RSA Token with RSA token server, this ensures that only user in procession of the token is able to use token Open the RSA SecurID Token client and enter the pre-set PIN in the RSA SecurID Token client as a first factor of authentication Which in turn gives you one time token as below which you enter while authentication with the username Enter the username and one time token on the Cisco DNAC login page.   User passed authentication is allowed access. This is how two factor authentication is achieved with a combination of PIN + One time token Verification We can verify the login from the live logs from Cisco ISE and RSA-AM Under Cisco ISE Operations > RADIUS > Live Logs   For Logs in RSA-AM , check under Home > Authentication Activity Monitor We can also see that we were able to successfully log in to the Cisco DNAC via respective users Two Factor Authentication using TACACS+ Under Administration > Network Devices Make sure we have Cisco DNAC and we have shared secret for TACACS+ as well Then, we create a TACACS+ profile for both users dnac_admin and dnac_observer under Work Center > Device Administration > Policy Elements Now, we create Authentication and Authorization Policy for those users under Work Centers > Device Administration > Device Admin Policy Sets   NOTE: In the above screenshot the authorization condition is mapped to username and in a production environment, you can change the authorization condition to use AD Group Membership if the users are present on AD. Once the profiles are created, make sure you have tokens for each users under RSA Security Console. Then, Integrate ISE into Cisco DNAC under Settings > Authentication and Policy Servers and enable External Authentication under Settings > Users > External Authentication and point to Cisco ISE. Shared Secret have to match between Cisco DNAC and ISE.   Once the Integration is done, register the RSA Token with RSA token server, this ensures that only user in procession of the token is able to use token Open the RSA SecurID Token client and enter the pre-set PIN in the RSA SecurID Token client as a first factor of authentication Which in turn gives you one time token as below which you enter while authentication with the username Enter the username and one time token on the Cisco DNAC login page.   User passed authentication is allowed access. This is how two factor authentication is achieved with a combination of PIN + One time token. Verification We can verify the login from the live logs from Cisco ISE and RSA-AM Under Cisco ISE Operations > TACACS > Live Logs For Logs in RSA-AM , check under Home > Authentication Activity Monitor We can also see that we were able to successfully log in to the Cisco DNAC via respective users ... View more