cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Cisco SD-Access (SDA) Integration with Cisco Application Centric Infrastructure (ACI)

440
Views
0
Helpful
0
Comments

 

 

 

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:

Screen Shot 2019-08-11 at 1.08.30 PM.png

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.

Screen Shot 2019-08-11 at 9.06.20 PM.png

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.

Screen Shot 2019-08-11 at 9.13.39 PM.png

 

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.

    Screen Shot 2019-08-11 at 2.41.58 PM.pngScreen Shot 2019-08-11 at 2.38.38 PM.png

 

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

Screen Shot 2019-08-11 at 3.11.05 PM.png

SGTs are sent to APIC when the integration happens but we can choose whether to propagate newly created SGTs to APIC-DC or not

Screen Shot 2019-08-11 at 9.14.42 PM.png

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.

Screen Shot 2019-08-11 at 9.21.46 PM.png

Establish BGP/IGP connectivity from ACI to Fusion device and here Is an example of bgp peering

Screen Shot 2019-08-14 at 2.19.41 PM.png

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.

Screen Shot 2019-08-11 at 8.24.29 PM.png

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

Screen Shot 2019-08-11 at 8.30.01 PM.png

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.

Screen Shot 2019-08-11 at 8.39.20 PM.png

Similarly, you can see EPGs in Cisco SD-Access (SDA) via ISE under Work Centers > Trustsec > Components

Screen Shot 2019-08-11 at 8.38.09 PM.png

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.

Screen Shot 2019-08-15 at 9.28.07 AM.png

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

Screen Shot 2019-08-11 at 8.56.36 PM.png

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:

Screen Shot 2019-08-11 at 8.59.02 PM.png

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.

Screen Shot 2019-08-11 at 11.07.57 PM.png

We can see that Employee is successfully authenticated in Cisco SD-Access (SDA) environment.

Screen Shot 2019-08-11 at 11.10.27 PM.png

By default, in ACI traffic is denied, and we need to create a policy to allow the traffic between the groups

Screen Shot 2019-08-14 at 2.09.15 PM.png

Traffic is denied as we do not have any contracts

Screen Shot 2019-08-11 at 11.15.56 PM.png

Here, we create a contract between Employee SGT and Server EPG1

Screen Shot 2019-08-14 at 2.08.53 PM.png

Once we created the contract, we see traffic allowed between the clients

Screen Shot 2019-08-14 at 2.08.23 PM.png

Policy Enforcement in Cisco SD-Access Domain:

Screen Shot 2019-08-11 at 11.07.57 PM.png

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.

Screen Shot 2019-08-11 at 11.08.07 PM.png

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.

Screen Shot 2019-08-11 at 11.10.27 PM.png

We can see below that Employee is able to reach the server:

Screen Shot 2019-08-11 at 11.12.06 PM.png

We can see that there are no policies configured on the Edge device.

Screen Shot 2019-08-11 at 11.12.30 PM.png

Now, we are going to create a group-based access-list denying the traffic between employee and Server

Screen Shot 2019-08-11 at 11.13.41 PM.png

Once the policy is created, we have to deploy the policy by clicking deploy so that this is pushed to devices in the fabric.

Screen Shot 2019-08-11 at 11.14.21 PM.png

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:

Screen Shot 2019-08-11 at 11.15.56 PM.png

 

Now, we can see that the counters are incrementing:

 

Screen Shot 2019-08-11 at 11.16.05 PM.png

 

 

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

 

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards