Chapter 9: Cisco Catalyst Center — Architecture and Day 0 Provisioning

9.1.1 From DNA Center to Catalyst Center: Intent-Based Networking

Cisco Catalyst Center — formerly DNA Center — is Cisco's flagship Intent-Based Networking (IBN) controller. The exam treats "DNA Center" and "Catalyst Center" as synonymous. Traditional management works bottom-up: engineers configure each device with CLI. IBN inverts the relationship — you declare the outcome and the controller derives the per-device configuration.

Catalyst Center delivers IBN through three capabilities: Design (sites, IP pools, network settings), Policy (SD-Access segmentation, group-based policy), and Assurance (telemetry, AI/ML analytics, root-cause analysis).

9.1.2 Platform Architecture and Communication Planes

Catalyst Center exposes four communication planes. The southbound interface is hidden from automation engineers — you call the Northbound Intent API, and Catalyst Center translates that intent into NETCONF, SSH, SNMP, or OpenConfig as needed per device type.

9.1.3 The Intent API: Structure and Authentication

The Intent API exposes over 1,000 operations organized into functional domains. All calls use the base path /dna/intent/api/v1/ (v2 for some newer endpoints) and require an X-Auth-Token header.

Authentication uses a POST to /dna/system/api/v1/auth/token with Basic credentials encoded in Base64. The response contains a JWT-like token valid for 1 hour. The catalystcentersdk handles refresh automatically.

9.1.4 The Asynchronous Task Pattern

All mutating operations (POST, PUT, DELETE) are asynchronous. The response returns immediately with a taskId. You must poll GET /dna/intent/api/v1/task/{taskId} until endTime is set, then check isError and failureReason. Think of it like a delivery tracking number — you check the portal periodically rather than standing at the loading dock.

9.2.1 Plug and Play Zero-Touch Provisioning

PnP allows a technician to unbox a device, connect cables, and walk away. Catalyst Center handles the rest. Every Cisco IOS-XE device ships with a PnP IOS Agent in its bootstrap startup config. When the device boots with no persistent configuration, the agent activates and discovers the controller via one of three methods:

9.2.2 PnP Device States

9.2.3 The Five-Step Day 0 Provisioning Workflow

The claim step (Step 5) is the trigger. Its payload bundles site ID, device ID, template ID, and per-device variable values (hostname, management IP, gateway, etc.). Catalyst Center executes image upgrade (if needed), renders the template, pushes the config, and adds the device to managed inventory — all asynchronously via a taskId.

Pre-staging (Step 4 done before the device ships) is a best practice: register the serial number in the PnP inventory so the device transitions directly from Unclaimed to Onboarding when it makes first contact, with zero human intervention required on-site.

9.3.1 Site Hierarchy: The Organizing Principle

The site hierarchy is the primary key linking devices to configuration policies, IP pools, templates, and network settings. Every provisioning workflow requires resolving the correct siteId UUID first. The hierarchy follows four levels:

Global
└── Area          (geographic region, country, or logical grouping)
    └── Building  (physical facility)
        └── Floor (specific floor within a building)

Example: Global / US / San-Jose / HQ-Building-1 / Floor-2

The catalystcentersdk makes hierarchy creation straightforward. Call catalyst.sites.create_site(type="area" | "building" | "floor", site={...}) for each level, using parentName to position the node correctly.

9.3.2 Network Settings and IP Pools

Each site can have per-site DNS, NTP, DHCP, and AAA settings configured via POST /dna/intent/api/v1/network, plus IP address sub-pools reserved via POST /dna/intent/api/v1/reserve-ip-subpool. These settings propagate to all devices provisioned at that site, ensuring branch-wide consistency without per-device manual configuration.

9.3.3 Software Image Management (SWIM)

SWIM manages the full software image lifecycle: import approved images, tag a "golden" image per device platform, distribute to device flash, and activate. All SWIM operations are asynchronous.

The distribute → activate split is key: distribute during business hours (device keeps running the old image), then activate (reload) during the maintenance window. This cuts the risk window from hours to the reload time only.

9.4.1 The catalystcentersdk Python Library

The SDK (pip install catalystcentersdk or legacy pip install dnacentersdk) is the primary automation interface for ENAUTO 300-435. Both packages are functionally equivalent; the legacy name persists due to broad adoption.

9.4.2 SDK Instantiation and Version Compatibility

Always instantiate using environment variables to avoid hard-coded credentials. Pin the SDK version in requirements.txt to match the controller deployment version — mismatches cause silent method signature failures.

from catalystcentersdk import api

# Zero hard-coded credentials (reads CATALYST_CENTER_* env vars)
catalyst = api.CatalystCenterAPI()

# Explicit instantiation for multi-controller scripts
catalyst = api.CatalystCenterAPI(
    username="devnetuser",
    password="Cisco123!",
    base_url="https://sandboxdnac.cisco.com:443",
    version="3.1.3.0",
    verify=False   # use True in production
)

9.4.3 Core Automation Patterns

Every Catalyst Center automation workflow follows the same pattern:

1. Resolve UUIDs (site, template, device) by querying existing resources
2. Execute the mutating operation (claim, distribute, discover, etc.)
3. Extract the returned taskId
4. Poll until endTime is set
5. Check isError — raise/log if true, continue if false

The custom_caller pattern handles endpoints not yet wrapped in named SDK methods:

catalyst.custom_caller.add_api(
    "get_global_credentials",
    lambda cred_type: catalyst.custom_caller.call_api(
        "GET",
        "/dna/intent/api/v1/global-credential",
        params={"credentialSubType": cred_type}
    ).response
)

netconf_creds = catalyst.custom_caller.get_global_credentials("NETCONF")

9.4.4 Production Error Handling Principles