Cisco Catalyst Center Plug and Play Device Onboarding - 夜莺博客

Cisco Catalyst Center Plug and Play Device Onboarding

Catalyst Center (the product formerly called DNA Center) can bring a factory-default
switch into inventory with no console session at all. The mechanism is the PnP Agent built into
IOS-XE: the switch boots, talks DHCP, discovers a controller, and pulls its day-zero
configuration. The failure modes are all in the bootstrap path — the DHCP option is wrong, DNS
does not resolve, or someone interrupted the agent and it gave up. This article covers the
discovery chain end to end and the checks that tell you which stage failed.

How the Discovery Chain Works

The PnP Agent follows a fixed order and stops at the first method that succeeds:

  1. DHCP option 43 — the switch sends a DHCP Discover with option 60
    (vendor class identifier) set to the plain-text value ciscopnp. A
    DHCP server configured to answer returns option 43 containing the controller's URL and port,
    for example 5A1D;B2;K4;I172.16.202.101;J80;.
  2. DNS — look up pnpserver.<domain> or the
    cisco-capwap-controller style names depending on the platform.
  3. Cloud phone-home — the device contacts the Cisco Plug and Play Connect
    portal at devicehelper.cisco.com, matches its serial number and SUDI to a Smart
    Account, and receives the controller URL from a Controller Profile. This works even on networks
    with no PnP configuration, but it needs DNS, NTP and an internet path.

If any startup configuration is saved to NVRAM, the PnP Agent aborts. If someone breaks into
enable mode on the console during boot, the agent stops too. Both behaviours surprise people
using lab devices that were previously configured.

Step 1: Prepare the Management LAN

! On the upstream switch the new device will connect to
pnp startup-vlan 200

That single command is the cleanest way to bootstrap: the upstream device uses CDP to tell
the downstream factory-default switch to move its DHCP client from VLAN 1 to VLAN 200, and the
auto-created dynamic trunk changes its allowed VLANs to match. The new switch obtains its
management address on the correct VLAN without anyone touching it.

If you cannot configure a PnP startup VLAN, some IOS-XE platforms support USB AutoInstall —
a configuration file on a USB stick bootstraps the device far enough to reach the PnP server.

Step 2: DHCP Option 43

! Cisco IOS DHCP server
ip dhcp pool PNP
 network 172.16.202.0 255.255.255.0
 default-router 172.16.202.1
 option 43 hex 012B 
   .  5A1D;B2;K4;I172.16.202.101;J80;      ! ASCII form, hex-encode the payload

What you should see on the device console while this works:

Autoinstall trying DHCPv6 on Vlan1
Autoinstall trying DHCPv4 on Vlan1
Acquired IPv4 address 172.16.2.25 on Interface Vlan1
Received following DHCPv4 options:
vendor          : 5A1D;B2;K4;I172.16.202.101;J80;
OK to enter CLI now...
pnp-discovery can be monitored without entering enable mode
Entering enable mode will stop pnp-discovery

Do not press Return and do not enter enable mode. Let it run.

Step 3: Credentials and Site Hierarchy in Catalyst Center

Catalyst Center needs working credentials before it can onboard anything: a CLI username and
password, an SNMP read community or v3 user, and optionally an enable password. Store them as
Design > Network Settings > Device Credentials, and assign them through the site
hierarchy so different sites can use different credentials.

The site hierarchy must exist before device assignment, because the API expects a site ID,
not a site name path. The declarative shape most teams standardise on looks like this:

# 01_site-hierarchy.yml
site:
  area:
    - name: "DC1"
      parentName: "Global"
  building:
    - name: "DC1-CageA"
      parentName: "Global/DC1"
      latitude: 52.341419
      longitude: 4.888043

# 02_add-devices.yml
site:
  - name: "Global/DC1/DC1-CageA"
    ipAddress: 10.100.80.11

Step 4: Discovery and Assignment via API or Ansible

- name: Add device to Catalyst Center inventory
  cisco.dnac.network_device:
    type: "NETWORK_DEVICE"
    ipAddress: "{{ item.ipAddress }}"
    cliTransport: ssh
    userName: "{{ DEVICE_USER }}"
    password: "{{ DEVICE_PASSWORD }}"
    snmpVersion: v2
    snmpROCommunity: "{{ SNMP_RO }}"
    snmpRetry: 3
    snmpTimeout: 3
    computeDevice: false
  loop: "{{ site }}"

- name: Resolve the site name to an ID, then assign
  cisco.dnac.assign_device_to_site:
    device:
      - ip: "{{ item.ipAddress }}"
    siteId: "{{ site_id }}"
  loop: "{{ site }}"

The two-step pattern matters: resolving the site path to the internal UUID is required, and
the site must already exist. Build the hierarchy first, then devices, then templates.

Troubleshooting the Discovery Chain

  • No DHCP address — VLAN mismatch or the PnP startup VLAN is not allowed on
    the trunk. Check show interfaces status upstream.
  • Address obtained, no controller — option 43 is missing, malformed, or the
    hex encoding is wrong. Compare the console vendor: line against what Catalyst
    Center expects. Check UDP 80/443 reachability from the device subnet.
  • Stuck in "Attempting to contact PnP server" — DNS resolution failing, or
    the device clock is far off. PnP relies on TLS and a wildly wrong clock breaks trust; NTP must
    be reachable.
  • Aborts immediately — a saved startup configuration exists, or someone
    entered enable mode. Wipe the device and let it boot untouched.
  • Onboards then fails template deployment — credential mismatch at the site,
    or the template references variables the device family cannot render.

Making It Repeatable

原文链接:https://github.com/miarond/DNA_Center_Device_Discovery