Close this search box.


Cross Domain Automation: Cisco SD-Access and ACI Integration using ATOM

Getting into the Elements

In today’s rapidly evolving digital landscape, the demand for a more integrated and secure network infrastructure has never been greater. As businesses adapt to dynamic and distributed work environments, the need to seamlessly connect campus and branch networks with data center networks is paramount. Modern networks must cater to the complex web of devices, users, and applications while upholding stringent security and policy standards. 

This blog explores the integration of Cisco DNA center SDA, ACI and nexus dashboard orchestrator (NDO), which aims to connect campus/branch networks to data center networks securely, simplifying policy management for users across various network domains.

Cisco SD-Access: Cisco SD-Access is an intent-based solution to streamline policy-driven automation across networks, enabling functions such as secure segmentation, IoT integration, and guest access management for efficient network orchestration.

Cisco ACI: Cisco Application Centric Infrastructure (ACI) is a datacenter software-defined solution. With Cisco ACI, an application deployment lifecycle can be simplified, optimized, and accelerated by defining network infrastructure based on network policies.

The Cisco Nexus Dashboard Orchestrator (NDO) allows macro-segmentation of network elements between the SD-Access domain and the ACI domain by mapping policies from VNs (SDA) to VRFs

Bridging the Gap – Cisco SDA and ACI Integration for Efficient Policy Management

The benefits of integrating Cisco SDA and ACI can be categorized into the following key points:

  • Policy Consistency and Simplification: Manage both campus/branch networks (SDA) and data center networks (ACI) under a single policy framework.
  • Effortless Policy Management: Map policies from SDA’s Virtual Networks (VNs) to ACI’s Virtual Routing and Forwarding (VRF) instances for unified policy enforcement.
  • Enhanced Security and Compliance: Extend policies from campus/branch to the data center, ensuring a consistent security posture and reducing the attack surface.
  • Application-Centric Infrastructure: Define network infrastructure based on network policies in ACI, optimizing the deployment of network resources to support application requirements.
  • Rapid Adaptation: Easily accommodate changing network and application needs, ensuring agility in responding to evolving business requirements.
  • Better Visibility and Control: Gain improved visibility into network traffic and application behavior across both SDA and ACI domains, facilitating troubleshooting and network optimization.

Obstacles on the Horizon

The steps to manually deploy the above usecase are as follows:

  1. Setting up the underlay/overlay in SDA and DC domains in the case of new campus/DC deployment.
  2. Opening a Change Request in an ITSM system like ServiceNow and seeking approvals from stakeholders for campus/branch to DC connectivity for a particular line of business.
  3. Reserving VLAN and IP Addresses for the campus/branch/DC.
  4. Provisioning the VNs in the SD-Access domain using DNAC.
  5. Provisioning the VRFs in ACI
  6. Configure the IP transit connectivity in the fusion router for border connectivity between the domains.
  7. Provisioning the SDA connectivity VN-VRF policy mapping in NDO.
  8. Executing Reachability tests
  9. Notifying various teams and closing the Change Request in ServiceNow

Integrating these components presents complexities beyond initial perception, with challenges including:

  • Accessing Multiple Controllers and IT Systems: Network Operations are expected to know about these various controllers and systems to accomplish the various provisioning tasks. The usecase covers accessing Cisco NDO, DNAC, ACI, Fusion router, ITSM systems, IPAM, etc..
  • ClickOps heavy processes: Some of these controllers can be ClickOps heavy. An Operator might have to navigate through multiple screens and a lot of clicks to complete provisioning tasks
  • Manual exchange of information between the systems: Information from one system might be required in another system.

For example – IP Addresses reserved in IPAM are required in the Cisco DNAC to provision campus VN and ACI to provision the VRF. Also, an IP subnet block is required for the SDA border node to fusion router connectivity and the ACI border leaf to fusion router connectivity. This process is error-prone

  • Multiple team co-ordination

There can be multiple teams managing these controllers/systems, and the entire provisioning process coordination can be very time-consuming.


In response to these challenges, ATOM offers a robust solution, delivering network operators a unified user interface that incorporates:

  • Pre-build Workflows: Several out-of-the-box process automation workflows can be invoked from an OSS/BSS portal or an ITSM system like ServiceNow. These workflows take care of all the integration with the various domain controllers and systems.
  • Consolidated user forms: The network operator is presented with a single user form to capture all of the controller inputs and required information to complete the provisioning process.

The diagram below illustrates the solution with ATOM integrating with multiple controllers/systems routers to deploy the end-to-end solution.

 ATOM solution – Cisco SDA & ACI integration

ATOM Workflow for Usecase deployment

Below is the ATOM workflow solution for the SD-Access to DC integration with NDO. 

ATOM – Workflow

Upon initiating the workflow, the user can fill in the necessary details.

Example: ATOM Out of Box Workflow Catalog

User inputs form

After the workflow gets initiated by providing user input details, ATOM will create the change request in the ITSM tool (service now) and seek approval.

Service Now – Change request

Once the admin approves the change request, ATOM will create the campus/branch site in DNAC.

DNAC – Site Creation

The screenshot below illustrates the Chicago site created in DNAC with the border and transit routers onboarded, and the necessary configs are pushed by DNAC to the devices.

Campus  Site Details

The below screenshot illustrates the campus VN created with L3 hand-off enabled in DNAC by ATOM workflow for the campus to DC extension.

Campus – VN creation

The screenshots below illustrate the DC sites created in NDO by ATOM workflow DNAC site configuration for SD access Campus to DC connectivity.

NDO – DC site onboarding

NDO – DNAC Site connectivity configuration

NDO – DNAC connectivity overview

NDO – VN-VRF mapping

The below screenshot shows the ACI fabric configuration.

ACI – DC Fabric VRF configuration

ATOM wraps up the process by updating and closing the Change Request in ServiceNow and sending an email notification.

 Email notification for successful deployment

ChatOps tools like Cisco Webex Spaces are updated at major milestones. Similarly, the notes section in the Change Request is also updated.

Webex notifications of the major milestone events

At high-level ATOM performs the following operations in different domains/controllers as part of the SD-Access to DC integration usecase-


In conclusion, the integration of Cisco Software-Defined Access and ACI offers significant advantages, but its complexity can be daunting. Fortunately, ATOM caters to all needs and empowers network operators to navigate these challenges effortlessly, enhancing efficiency, reducing errors, and ultimately delivering a more seamless experience for both operators and end-users.

It’s evident that  ATOM workflow automation simplifies the deployment of intricate cross-domain end-to-end scenarios, encompassing numerous controllers, tools, and processes. Through its endeavors, ATOM aims to reduce human error and deployment time frame, improving the customer experience and time to market.

Additional Contributors: Manisha Dhan

About Author

You will also like...