Offensive Security Researcher & Quantum Cryptography Analyst

How to Set Up Cisco DNA Center for Network Automation and Intent-Based Networking

Abdul Wahab Junaid
How to Set Up Cisco DNA Center for Network Automation

How to Set Up Cisco DNA Center for Network Automation

Anyone who has spent a career configuring switches one CLI session at a time knows the pain of scaling that process across hundreds of devices. Manual configuration doesn’t just slow you down — it introduces inconsistency, human error, and configuration drift that becomes a nightmare during audits or troubleshooting. Cisco DNA Center changes that equation entirely by shifting network management from device-by-device configuration to intent-based networking, where you describe what you want the network to do and the controller figures out how to make it happen across every device. Here’s how I approach setting it up in a real enterprise environment.

Understanding Intent-Based Networking

Before diving into setup steps, it’s worth understanding the paradigm shift. Traditional networking is imperative — you log into each device and type the exact commands needed. Intent-based networking is declarative — you define a policy (“this VLAN needs this QoS treatment across the whole campus”) and DNA Center translates that into the appropriate configuration for every switch, router, and wireless controller in scope, then continuously verifies the network matches that intent.

DNA Center’s architecture rests on a few pillars:

Networking Fundamentals You Need First

DNA Center leans heavily on a few underlying technologies you should understand before deployment:

Pre-Deployment Planning

Before racking anything, map out:

  1. Physical appliance sizing — DNA Center ships as a physical appliance (DN2-HW-APL series) or scalable cluster; sizing depends on device count (small: <1,000 devices, medium: up to 5,000, large: up to 25,000+)
  2. Network hierarchy — Areas, Buildings, and Floors need to mirror your actual physical topology for accurate assurance and location-based analytics
  3. IP address pool planning — SD-Access fabric requires dedicated pools for underlay and overlay networks
  4. Device readiness — minimum IOS-XE versions required for full DNA Center management (generally 16.x or later; verify per platform)

Step-by-Step Implementation

Step 1: Initial Appliance Configuration

Connect to the appliance console and run the initial configuration wizard:

Welcome to Cisco DNA Center Configuration Wizard

Enter Enterprise DHCP server: 10.1.1.10
Enter Enterprise DNS server(s): 10.1.1.10, 10.1.1.11
Enter Cluster Virtual IP: 10.1.1.50
Enter Network Adapter for Enterprise: eth0
Enter Network Adapter for Management: eth1
Configure NTP server: 10.1.1.5

After the wizard completes and services initialize (this can take 30–60 minutes on first boot), access the GUI at https://<cluster-VIP>.

Step 2: Define Your Network Hierarchy

Under Design > Network Hierarchy, build out your site structure:

Global
 └─ Area: North-America
     └─ Building: HQ-Campus
         ├─ Floor: Floor-1
         ├─ Floor: Floor-2
         └─ Floor: Floor-3
     └─ Building: Branch-Chicago

This isn’t cosmetic — assurance analytics, wireless heatmaps, and fabric provisioning are all scoped to this hierarchy.

Step 3: Configure Network Settings and Credentials

Under Design > Network Settings, define:

AAA Server: ISE (10.1.1.20)
Shared Secret: <configured>
NTP Server: 10.1.1.5
DHCP Server: 10.1.1.10
DNS Server: 10.1.1.10
Syslog Server: 10.1.1.30
SNMP Credentials: Read/Write community strings
CLI Credentials: netadmin / <encrypted>

Devices must be reachable via SSH and SNMP with these credentials for discovery to succeed.

Step 4: Discover Devices

Navigate to Provision > Inventory > Discovery, and configure an IP range or CDP-based discovery seed:

Discovery Name: Campus-Discovery-01
Discovery Type: CDP
Seed IP: 10.1.1.1
CDP Level: 16
Preferred Management IP: Use Loopback

Run discovery and verify devices land in inventory:

show network-device count
Total Devices Discovered: 142
Reachable: 140
Unreachable: 2

On the actual device CLI, confirm SNMP and SSH are correctly enabled to support this:

switch(config)# snmp-server community DNACread RO
switch(config)# ip ssh version 2
switch(config)# username netadmin privilege 15 secret <password>

Step 5: Assign Devices to Sites

Once discovered, assign each device under Provision > Inventory to its corresponding site in the hierarchy. This step is mandatory before any provisioning or SD-Access fabric work can proceed.

Step 6: Build the SD-Access Fabric

Under Provision > Fabric Sites, create a fabric domain:

Fabric Name: Campus-Fabric-01
Associated Site: HQ-Campus

Designate fabric roles for your devices:

Device: Core-SW-01 → Role: Control Plane + Border
Device: Access-SW-01 → Role: Edge Node
Device: Access-SW-02 → Role: Edge Node

Underlying LISP configuration pushed automatically resembles:

router lisp
 locator-set RLOC-Campus
  10.1.1.1 priority 1 weight 100
 !
 instance-id 4099
  service ipv4
   eid-table vlan 10
   map-server
   map-resolver

You don’t type this manually — DNA Center generates and pushes it — but understanding what’s happening under the hood is critical for troubleshooting.

Step 7: Define Virtual Networks and Segmentation

Under Policy > Virtual Network, create VNs mapped to business intent, such as separating IoT devices, guest traffic, and corporate endpoints:

Virtual Network: VN-Corporate
Virtual Network: VN-IoT
Virtual Network: VN-Guest

Then define group-based access control policies under Policy > Group-Based Access Control:

Source SGT: Employees (SGT 10)
Destination SGT: Servers (SGT 20)
Access Contract: Permit-HTTPS-Only

This pushes SGACL policy to devices via TrustSec, enforcing segmentation without needing per-device ACLs.

Step 8: Provision and Verify

Push the fabric configuration:

Provision > Fabric Sites > Campus-Fabric-01 > Provision Devices

Verify fabric status on the actual switch:

switch# show fabric edge summary
Fabric Role: Edge Node
Fabric Status: Enabled
Control Plane Reachability: Reachable
VNI Count: 3

Check LISP registration:

switch# show lisp session
Sessions for VRF default, total: 1, established: 1
Peer                          State    Up/Down     In/Out
10.1.1.1                      Up       02:14:33    142/138

Real-World Enterprise Scenario

Consider a healthcare campus with 30 buildings, thousands of medical IoT devices, guest Wi-Fi for patients, and strict compliance requirements around segmenting clinical devices from general corporate traffic. Manually maintaining VLAN-based segmentation across that many access switches would require constant, error-prone updates every time a device moves or a new building comes online.

With DNA Center and SD-Access, the organization defines a “Clinical-IoT” virtual network once. As infusion pumps and monitoring equipment connect anywhere across the campus — even as biomedical staff physically relocate equipment between floors — the fabric automatically applies consistent segmentation and policy based on the device’s group membership rather than its physical port. Assurance dashboards flag any device experiencing packet loss or onboarding failures in real time, letting the network team fix issues before clinical staff even notice a problem.

Best Practices

Common Configuration Mistakes

  1. Skipping site hierarchy planning, leading to a flat, unusable structure that has to be rebuilt later.
  2. Mismatched SSH/SNMP credentials across the fleet, causing partial discovery failures that are tedious to debug device-by-device.
  3. Assigning fabric roles without underlay connectivity verified first — the underlay (basic IP reachability) must work before the LISP/VXLAN overlay can succeed.
  4. Not isolating a test fabric site, pushing fabric-wide changes directly into production and causing outages.
  5. Ignoring certificate warnings during appliance setup, leading to broken trust between DNA Center and ISE for pxGrid integration.

Performance Tuning

Troubleshooting

Devices stuck in “Unreachable” during discovery: Verify SNMP community strings and SSH credentials match exactly what’s configured on the device; also check ACLs blocking DNA Center’s management IP.

Fabric provisioning fails at LISP registration: Confirm underlay routing (typically ISIS or OSPF) is fully converged between control plane and edge nodes before fabric provisioning.

Assurance shows “Health Score: Poor” with no obvious cause: Check for interface errors, high CPU, or an outdated IOS-XE version — Assurance heavily weights these in its scoring algorithm.

FAQs

Does DNA Center support non-Cisco devices? Discovery and basic inventory work for some third-party SNMP-capable devices, but full intent-based provisioning and SD-Access fabric features are Cisco-device specific.

Can I run DNA Center virtually instead of on physical appliances? Cisco offers a virtual appliance option for smaller deployments and lab/PoC environments, though production-scale deployments typically use the physical DN2-HW-APL cluster.

How is DNA Center licensed? Through Cisco DNA subscription tiers (Essentials, Advantage, Premier), which also gate feature availability like SD-Access and advanced Assurance analytics.

What happens if the DNA Center cluster goes down — does the network stop working? No. Already-provisioned configuration remains on devices and continues functioning; you lose centralized management and new provisioning capability until the controller is restored.

Summary

Cisco DNA Center represents a genuine shift in how enterprise networks get built and maintained — from manually typing configuration into hundreds of individual devices to defining intent once and letting the controller handle consistent, policy-driven provisioning across the fabric. The learning curve involves understanding SD-Access, LISP, VXLAN, and TrustSec concepts underneath the GUI, but the operational payoff — consistent segmentation, faster troubleshooting through Assurance, and dramatically reduced configuration drift — is substantial for any network beyond a handful of devices.

References

Exit mobile version