Device

Location in GUI: Provision » Inventory

Diagram

Classes

inventory (catalyst_center)

Name	Type	Constraint	Mandatory	Default Value
devices	List	`[devices]`	No

devices (catalyst_center.inventory)

Name	Type	Constraint	Mandatory
name	String		Yes
fqdn_name	String		No
type	Choice	`AccessPoint`	No
rf_profile	String		No
device_ip	IP		No
pid	Any	String or Null	No
serial_number	Any	String or Null	No
state	Choice	`INIT`, `PNP`, `PROVISION`, `REPROVISION`, `ASSIGN`, `MARK_FOR_REPLACEMENT`	Yes
device_role	Choice	`ACCESS`, `CORE`, `DISTRIBUTION`, `BORDER ROUTER`	Yes
site	String		Yes
fabric_site	String		No
fabric_zone	String		No
fabric_roles	List	Choice[`BORDER_NODE`, `CONTROL_PLANE_NODE`, `EDGE_NODE`, `WIRELESS_CONTROLLER_NODE`, `EMBEDDED_WIRELESS_CONTROLLER_NODE`]	No
enable_wireless	Boolean	`true`, `false`	No
clean_up_config	Boolean	`true`, `false`	No
enable_rolling_ap_upgrade	Boolean	`true`, `false`	No
image_name	String		No
image_id	String		No
image_skip	Boolean	`true`, `false`	No
stack	Class	`[stack]`	No
ap_reboot_percentage	Choice	`5`, `15`, `25`	No
onboarding_template	Class	`[onboarding_template]`	No
dayn_templates	Class	`[dayn_templates]`	No
primary_managed_ap_locations	List	String	No
secondary_managed_ap_locations	List	String	No
port_assignments	List	`[port_assignments]`	No
port_channels	List	`[port_channels]`	No
tags	List	String	No

stack (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory	Default Value
top_of_stack_serial_number	String		Yes
cabling_scheme	Choice	`1A`, `1B`	Yes

onboarding_template (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory	Default Value
name	String		Yes
variables	List	`[variables]`	No

dayn_templates (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory
regular	List	`[regular]`	No
composite	List	`[composite]`	No
redeploy_template	Choice	`ALWAYS`, `NEVER`, `ON_CHANGE`	No

port_assignments (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory
interface_name	String		No
interfaces_range	String	Regex: `^[A-Za-z]+\d+(/\d+)+-\d+(/\d+)+$`	No
interface_description	String		No
connected_device_type	Choice	`USER_DEVICE`, `ACCESS_POINT`, `TRUNKING_DEVICE`, `AUTHENTICATOR_SWITCH`, `SUPPLICANT_BASED_EXTENDED_NODE`	Yes
data_vlan_name	String		No
voice_vlan_name	String		No
security_group_name	String		No
authenticate_template_name	Choice	`No Authentication`, `Open Authentication`, `Closed Authentication`, `Low Impact`	No

port_channels (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory
id	Integer		Yes
connected_device_type	Choice	`TRUNK`, `EXTENDED_NODE`	Yes
protocol	Choice	`ON`, `LACP`, `PAGP`	No
description	String		No
interface_names	List	String	Yes
native_vlan_id	Integer	min: `1`, max: `4094`	No
allowed_vlan_ranges	String		No

variables (catalyst_center.inventory.devices.onboarding_template)

Name	Type	Constraint	Mandatory	Default Value
name	String		Yes
value	Any	String or List[String]	Yes

regular (catalyst_center.inventory.devices.dayn_templates)

Name	Type	Constraint	Mandatory
name	String		Yes
variables	List	`[variables]`	No
redeploy_template	Choice	`ALWAYS`, `NEVER`, `ON_CHANGE`	No
copying_config	Boolean	`true`, `false`	No
force_push_template	Boolean	`true`, `false`	No

composite (catalyst_center.inventory.devices.dayn_templates)

Name	Type	Constraint	Mandatory
name	String		Yes
variables	List	`[variables]`	No
redeploy_template	Choice	`ALWAYS`, `NEVER`, `ON_CHANGE`	No
copying_config	Boolean	`true`, `false`	No
force_push_template	Boolean	`true`, `false`	No

variables (catalyst_center.inventory.devices.dayn_templates.composite)

Name	Type	Constraint	Mandatory
name	String		Yes
value	Any	String or List[String]	Yes
template_name	String		Yes

Devices represent the network equipment managed by Catalyst Center. The device data model defines inventory attributes, site assignment, provisioning parameters, and fabric roles. Devices must be discovered (via Discovery or manual add), assigned to a site, and provisioned before they can participate in the network. In SDA fabric deployments, devices are additionally assigned fabric roles (edge, border, control plane) for Fabric Site participation. Applicable to both SDA fabric and non-fabric deployments.

Device Provisioning States and Lifecycle

The device provisioning lifecycle in Catalyst Center follows a well-defined state machine that manages devices from initial discovery through full deployment and ongoing management. Understanding these states and their transitions is crucial for effective network automation and troubleshooting.

Device States

INIT (Initial State)

The starting state for all devices when first added to the inventory. Devices in this state are discovered but not yet assigned to any site or configured for provisioning.

Characteristics:

Device is discovered and added to inventory
No site assignment
No configuration applied
Basic device information collected (IP, serial number, PID)

Possible Transitions:

To ASSIGN: Assign device to a specific site for configuration
To PROVISION: Begin the provisioning process for non-fabric devices, as well as fabric provisioning if fabric attributes are specified

PNP (Plug and Play)

Devices in this state are ready for zero-touch provisioning when they boot up and contact the Catalyst Center. This state is typically used for new devices that will be deployed in remote locations.

Characteristics:

Device prepared for zero-touch deployment
Configuration templates pre-assigned
Waiting for device to contact Catalyst Center
No active management until device boots

Possible Transitions:

To PROVISION: Begin the provisioning process for non-fabric devices, as well as fabric provisioning if fabric attributes are specified
To INIT: Keep device in Inventory “as is” after PNP process
ASSIGN: Assign device to a specific site

ASSIGN

Devices are assigned to a specific site but not yet provisioned with configuration. This state allows for site-specific settings preparation before actual provisioning.

Characteristics:

Device assigned to a site hierarchy
Site-specific credentials and settings applied
Ready for provisioning process
Configuration templates can be assigned

Possible Transitions:

To PROVISION: Begin the provisioning process for non-fabric devices, as well as fabric provisioning if fabric attributes are specified
To INIT: Un-assign device from site

PROVISION

The active provisioning state where devices receive their full configuration and become operational network elements. This is the target state for most production devices.

Characteristics:

Full configuration deployment in progress or completed
Device actively managed by Catalyst Center
Templates applied and configuration synchronized
Monitoring and compliance checking active
Fabric roles assigned (if applicable)

Possible Transitions:

To REPROVISION: When configuration changes require redeployment
To INIT: Unprovision device completely (removes from SDA fabric and/or Inventory with config clearing)

REPROVISION

A specialized state for devices that need Network Settings configuration updates. This state ensures network settings are refreshed while maintaining device operational status.

Characteristics:

Device remains operational during re-provisioning
Configuration templates reapplied
Network settings updated every time
Maintains existing fabric membership and site assignment

Possible Transitions:

To PROVISION: Return to standard provisioned state after updates complete
To INIT: Unprovision device completely (removes from SDA fabric and/or Inventory with config clearing)

State Transition Operations

Provisioning Operations

Provision non-fabric devices: Apply standard network configuration
Provision fabric devices: Apply SDA fabric configuration and assign fabric roles
Both operations move devices from INIT, ASSIGN or PNP states to PROVISION state

Unprovisioning Operations

Standard Unprovisioning: Removes device from Inventory management with configuration clearing
SDA Fabric Removal: Removes from both SDA fabric and Inventory with configuration clearing

Best Practices

State Management

Use ASSIGN state for devices requiring site-specific preparation
Use PNP state for zero-touch deployment scenarios
Monitor devices in REPROVISION state for completion

Operational Considerations

Devices in PROVISION state should be monitored for compliance
REPROVISION operations should be scheduled during maintenance windows
Use proper unprovisioning procedures to avoid configuration conflicts
Maintain device inventory accuracy across all states

Examples

Example-1: SD-Access Border Router Device Configuration

This example demonstrates how to configure a border router device in Catalyst Center inventory with SD-Access fabric capabilities. Border routers serve as critical infrastructure components that connect the SD-Access fabric to external networks and provide advanced routing and policy enforcement functions.

The border router device configuration includes:

Device name (BR01) for identification and inventory management
Management IP address (192.168.10.1) for device communication and monitoring
PROVISION state for active deployment and configuration management
Border router role designation for network function
Site assignment (Global/Canada) for geographic and organizational placement
Fabric site association (Global/Canada) for SD-Access fabric membership
Multiple fabric roles including BORDER_NODE for external connectivity and CONTROL_PLANE_NODE for fabric control plane operations

catalyst_center:
  inventory:
    devices:
      - name: BR01
        fqdn_name: BR01.company.local
        device_ip: 192.168.10.1
        state: PROVISION
        device_role: BORDER ROUTER
        site: Global/Canada
        fabric_site: Global/Canada
        fabric_roles:
          - BORDER_NODE
          - CONTROL_PLANE_NODE

Example-2: Access Switch with Edge Node Functionality

This example shows how to configure an access layer switch with SD-Access edge node capabilities for endpoint connectivity and policy enforcement at the network edge.

catalyst_center:
  inventory:
    devices:
      - name: ACCESS-SW01
        fqdn_name: ACCESS-SW01.company.local
        device_ip: 192.168.20.10
        serial_number: FOC2644021A
        pid: C9300-24P
        state: PROVISION
        device_role: ACCESS
        site: Global/North America/Campus/Building A/Floor 1
        fabric_site: Global/North America/Campus
        fabric_roles:
          - EDGE_NODE
        tags:
          - FLOOR1_DEVICES
          - EMPLOYEE_ACCESS

Example-3: Plug-n-Play Functionality

This example shows how to configure a device to be on-boarded into Catalyst Center inventory using plug and play.

Note : The below assumes that a day zero on-boarding template named PNP_Template has already be provisioned using the data model. The PNP_Template during the PNP process, switches the device’s https source-interface to the device’s desired management interface IP address.

Note : During the PNP claim process, the value of name defined in the data model is used as the device name in the Plug and Play device database of the Catalyst Center GUI.

catalyst_center:
  inventory:
    devices:
      - name: PNP_DEVICE
        fqdn_name: PNP_DEVICE.cisco.eu
        device_ip: 192.158.142.20
        serial_number: FAB12345602
        pid: C9300-48P
        state: PNP
        device_role: BORDER ROUTER
        site: Global/Poland/Krakow/Bld A
        onboarding_template:
          name: PNP_Template
          variables:
            - name: device_host_name
              value: PNP_DEVICE
            - name: infra_vlan
              value: "100"
            - name: infra_vlan_network_add
              value: 181.1.1.90
            - name: infra_vlan_network_mask
              value: 255.255.255.248
            - name: loopback_0_IP
              value: 192.158.142.20
            - name: loopback_0_mask
              value: 255.255.255.255
            - name: Border_AS
              value: "65005"
            - name: peer_BGP_neigbor
              value: 181.1.1.89
            - name: peer_AS
              value: "65002"
            - name: peer_interface
              value: GigabitEthernet1/0/1

After the plug and play process is completed, the device state can be updated to PROVISION to enable full management and configuration capabilities within Catalyst Center.

catalyst_center:
  inventory:
    devices:
      - name: PNP_DEVICE
        fqdn_name: PNP_DEVICE.cisco.eu
        device_ip: 192.158.142.20
        serial_number: FAB12345602
        pid: C9300-48P
        state: PROVISION
        device_role: BORDER ROUTER
        site: Global/Poland/Krakow/Bld A

Example-4: Plug-n-Play with Switch Stack Configuration

This example shows how to configure a switch stack to be on-boarded into Catalyst Center inventory using Plug and Play. The stack block specifies stack-specific parameters that control the physical switch numbering and the StackWise cabling layout.

Note :

serial_number must be a comma-separated list of all member-switch serial numbers in the stack (no spaces between entries).
top_of_stack_serial_number selects the switch that will be assigned stack member number 1. This is purely a numbering convention - it does not imply that switch 1 will be the active (master) switch in the stack. The active role is elected by the stack itself following standard StackWise election rules.
cabling_scheme specifies the StackWise cabling layout. Two values are currently supported: 1A and 1B.
Both top_of_stack_serial_number and cabling_scheme must be provided when the stack block is used.

catalyst_center:
  inventory:
    devices:
      - name: PNP_STACK
        fqdn_name: PNP_STACK.cisco.eu
        device_ip: 192.168.50.2
        serial_number: "FOC2724Y8RE,FOC2724Y8SJ"
        pid: C9300X-48HX
        state: PNP
        stack:
          top_of_stack_serial_number: FOC2724Y8SJ
          cabling_scheme: "1A"
        device_role: BORDER ROUTER
        site: Global/Poland/Krakow/Bld A
        clean_up_config: false

Example-5: Plug-n-Play with Image Upgrade

This example shows how to upgrade a device’s software image as part of the Plug and Play (PnP) onboarding process. When image_skip is set to false, Catalyst Center includes image-upgrade information in the PnP claim payload and upgrades the device to the target image during onboarding, ensuring the device boots with the desired software version on its first day of operation.

Note :

The device platform must be booting in install mode (not bundle mode) for the PnP image upgrade to succeed.
In the Catalyst Center GUI image repository, the image must already exist and be assigned to the device’s platform and site. Tagging the image as Golden is recommended.
image_skip controls the upgrade behavior:
- image_skip: true (default) — PnP devices are not upgraded; the device boots with whatever image it ships with.
- image_skip: false — the PnP claim payload includes imageInfo and Catalyst Center upgrades the device during onboarding.
image_name — when image_skip: false is configured, image_name should be defined at the device level so that Catalyst Center knows which image to push during the PnP claim. It must point to an existing image filename in the SWIM repository (for example, cat9k_iosxe.17.15.05.SPA.bin).

catalyst_center:
  inventory:
    devices:
      - name: Edge-2
        fqdn_name: Edge-2.cisco.eu
        device_ip: 172.16.251.4
        pid: C9300-48P
        state: PNP
        serial_number: FOC2710YM9V
        device_role: "ACCESS"
        site: Global/Poland/Krakow/Bld A
        image_skip: false
        # Image filename in the SWIM repository.
        # When `image_skip: false`, `image_name` must be defined
        image_name: cat9k_iosxe.17.15.05.SPA.bin

Setting `image_skip` globally via `defaults.yaml`

To enable PnP image upgrade for all PnP devices without repeating the flag on each one, set image_skip under the pnp.devices block in defaults.yaml:

defaults:
  catalyst_center:
    pnp:
      devices:
        image_skip: false

When set in defaults.yaml, the flag applies to all PnP devices that do not explicitly override it. Individual devices can still opt out by setting image_skip: true at the device level.

Note: image_name is per-device only. To upgrade every PnP device, keep image_skip: false in defaults.yaml and set the appropriate image_name on each device.

Example-6: Access Point Plug-n-Play

This example shows how to configure an Access Point to be on-boarded into Catalyst Center inventory using plug and play.

Note : It is mandatory to provide the type as AccessPoint, rf_profile, and site in order to add and claim the device in Provision -> Plug and Play

catalyst_center:
  inventory:
    devices:
      - name: AP_PNP
        fqdn_name: AP_PNP.cisco.eu
        pid: C9136I-E
        serial_number: FGL3727MF6Y
        state: PNP
        type: AccessPoint
        rf_profile: TYPICAL
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A/FLOOR_2

After the plug and play process is completed, the Access Point can be updated to PROVISION to provision full management and configuration capabilities within Catalyst Center.

catalyst_center:
  inventory:
    devices:
      - name: AP_PNP
        fqdn_name: AP_PNP.cisco.eu
        pid: C9136I-E
        serial_number: FGL3727MF6Y
        state: PROVISION
        type: AccessPoint
        rf_profile: TYPICAL
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A/FLOOR_2

Example-7: Embedded Wireless Controller provisioning

This example demonstrates how to enable the fabric Embedded Wireless Controller (EWC) role on a fabric device so it manages wireless access points from within the fabric.

Note :

It is mandatory to include EMBEDDED_WIRELESS_CONTROLLER_NODE in the fabric_roles list (in addition to the existing role(s) such as EDGE_NODE, BORDER_NODE, CONTROL_PLANE_NODE).
An Embedded Wireless Controller must always have managed AP locations. It is mandatory to populate primary_managed_ap_locations (and optionally secondary_managed_ap_locations) whenever the EMBEDDED_WIRELESS_CONTROLLER_NODE role is present. A device carrying the EWC role without any managed AP locations is an invalid configuration and is rejected by validation.

Mandatory prerequisite: Embedded WLC image

Before enabling the EMBEDDED_WIRELESS_CONTROLLER_NODE role, the Embedded Wireless Controller image must already be installed, committed, and activated on the switch. This is an out-of-band (OOB) prerequisite performed directly on the device (for example via CLI) and is not part of the data model / Terraform workflow. Terraform does not install or activate the Embedded WLC image; it only enables the fabric EWC role on a switch that already has the image active.

Verify the base image and the Embedded WLC image are in an activated state using show install summary. Both the base IMG and the C9800-SW wireless-controller PKG should show state C (Activated & Committed):

FIAB1> show install summary
[ Switch 1 ] Installed Package(s) Information:
State (St): I - Inactive, U - Activated & Uncommitted,
            C - Activated & Committed, D - Deactivated & Uncommitted
--------------------------------------------------------------------------------
Type  St   Filename/Version
--------------------------------------------------------------------------------
IMG   C    17.15.03.0.5635
PKG   C    flash:C9800-SW-iosxe-wlc.17.15.03.SPA.bin

--------------------------------------------------------------------------------
Auto abort timer: inactive
--------------------------------------------------------------------------------

Supported role combinations

The EWC role can be combined with specific wired fabric role(s). Two supported combinations are shown below.

Option 1 — Border + Control Plane + Edge + Embedded Wireless Controller (a fabric-in-a-box that is also the wireless controller):

catalyst_center:
  inventory:
    devices:
      - name: FIAB1
        fqdn_name: FIAB1
        device_ip: 192.168.142.20
        pid: C9300L-24T-4X
        state: PROVISION
        device_role: ACCESS
        site: Global/Poland/Warsaw/Bld_B
        fabric_site: Global/Poland/Warsaw
        fabric_roles:
          - BORDER_NODE
          - CONTROL_PLANE_NODE
          - EDGE_NODE
          - EMBEDDED_WIRELESS_CONTROLLER_NODE
        primary_managed_ap_locations:
          - Global/Poland/Warsaw/Bld_B/FLOOR_1
        secondary_managed_ap_locations:
          - Global/Poland/Warsaw/Bld_B/FLOOR_2

Option 2 — Edge + Embedded Wireless Controller:

catalyst_center:
  inventory:
    devices:
      - name: FIAB2
        fqdn_name: FIAB2
        device_ip: 192.168.142.30
        pid: C9300L-24T-4X
        state: PROVISION
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A
        fabric_site: Global/Poland/Krakow
        fabric_roles:
          - EDGE_NODE
          - EMBEDDED_WIRELESS_CONTROLLER_NODE
        primary_managed_ap_locations:
          - Global/Poland/Krakow/Bld A
        secondary_managed_ap_locations:
          - Global/Poland/Krakow/Bld B

Adding the EWC role to an Edge-only fabric device requires two Terraform applies

Enabling the Embedded Wireless Controller on an Edge-only fabric device requires two separate terraform apply runs. The device must first be provisioned with its wired fabric Edge role, and the EWC role plus managed AP locations are added on a second apply.

Step 1 — Provision the device with the wired fabric Edge role only (no EWC role, no managed AP locations):

catalyst_center:
  inventory:
    devices:
      - name: FIAB2
        fqdn_name: FIAB2
        device_ip: 192.168.142.30
        pid: C9300L-24T-4X
        state: PROVISION
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A
        fabric_site: Global/Poland/Krakow
        fabric_roles:
          - EDGE_NODE

Run terraform apply.

Step 2 — Add the EMBEDDED_WIRELESS_CONTROLLER_NODE role together with the managed AP locations:

catalyst_center:
  inventory:
    devices:
      - name: FIAB2
        fqdn_name: FIAB2
        device_ip: 192.168.142.30
        pid: C9300L-24T-4X
        state: PROVISION
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A
        fabric_site: Global/Poland/Krakow
        fabric_roles:
          - EDGE_NODE
          - EMBEDDED_WIRELESS_CONTROLLER_NODE
        primary_managed_ap_locations:
          - Global/Poland/Krakow/Bld A
        secondary_managed_ap_locations:
          - Global/Poland/Krakow/Bld B

Run terraform apply again.

Removing the EWC role

When removing the Embedded Wireless Controller from a device, remove the EMBEDDED_WIRELESS_CONTROLLER_NODE role and its primary_managed_ap_locations / secondary_managed_ap_locations in the same terraform apply. The managed AP locations must never be left behind after the EWC role is removed — removing the role while keeping the AP locations is an invalid configuration and is rejected by validation.

Example-8: Management IP Address Update

This example demonstrates how to update the management IP address of an existing device. When the device_ip in the data model differs from the device’s current management IP in Catalyst Center, the module automatically triggers a management address update. The device must be identifiable by its name or fqdn_name (hostname match against Catalyst Center inventory).

Note: This resource uses an ephemeral approach: it only appears in Terraform state when device_ip differs from the current Catalyst Center management IP. After a successful apply, the next apply will detect the IPs match, automatically remove the resource from state, and make no further changes. This means zero state footprint when IPs are in sync. This feature does not apply to Access Points (type: AccessPoint).

catalyst_center:
  inventory:
    devices:
      - name: SW-CORE-01
        fqdn_name: SW-CORE-01.company.local
        device_ip: 10.1.1.100        # new management IP (was 10.1.1.10)
        state: PROVISION
        device_role: CORE
        site: Global/HQ/DataCenter

Example-9: Device Unprovisioning with clean_up_config

When unprovisioning a device (transitioning from PROVISION to INIT), Catalyst Center attempts to connect to the device and remove its configuration. However, if the device is unreachable (e.g. hardware failure, network outage, or the device has already been physically removed), the unprovisioning will fail because Catalyst Center cannot clean the configuration.

The clean_up_config: false flag instructs Catalyst Center to skip the configuration cleanup step, allowing the device to be deleted from inventory even when it is unreachable or error-free cleanup is not possible.

Important: This is a two-step process:

First terraform apply: Set clean_up_config: false on the device while it is still in PROVISION state. This tells Catalyst Center to skip configuration cleanup on the next state change.

Second terraform apply: Change the device state to INIT (unprovision). Because clean_up_config was already set to false, Catalyst Center will remove the device without attempting to reach it.

Step 1 — Set clean_up_config: false on the unreachable device:

catalyst_center:
  inventory:
    devices:
      - name: SW-UNREACHABLE-01
        fqdn_name: SW-UNREACHABLE-01.company.local
        device_ip: 10.1.1.50
        state: PROVISION
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        clean_up_config: false

Run terraform apply to register the flag with Catalyst Center.

Step 2 — Unprovision the device by setting state: INIT:

catalyst_center:
  inventory:
    devices:
      - name: SW-UNREACHABLE-01
        fqdn_name: SW-UNREACHABLE-01.company.local
        device_ip: 10.1.1.50
        state: INIT
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        clean_up_config: false

Run terraform apply again. Catalyst Center will remove the device from inventory without attempting to clean its configuration.

Setting `clean_up_config` globally via `defaults.yaml`

If you have multiple unreachable devices or want to apply this flag to all devices by default, you can set it in the defaults.yaml file instead of on each individual device:

defaults:
  catalyst_center:
    inventory:
      devices:
        clean_up_config: false

When set in defaults.yaml, the flag applies to all devices that do not explicitly override it. Individual devices can still override the default by setting clean_up_config: true at the device level.

Example-10: RMA (Return Material Authorization) Device Replacement

This example demonstrates how to replace a faulty device using the RMA workflow. The process uses the state and serial_number attributes to coordinate with Catalyst Center’s device replacement API. The replacement is a 2-step process requiring two separate terraform apply runs.

Prerequisites:

The faulty device must be unreachable in Catalyst Center
The replacement device must be physically connected and reachable by Catalyst Center
The device must have serial_number defined in the data model

How it works: The module uses a data.catalystcenter_device_replacement data source to query Catalyst Center’s device replacement API for the device. When the device is in MARK_FOR_REPLACEMENT state (Step 1), the module marks it for replacement via the API. When the device transitions back to PROVISION state with a new serial_number (Step 2), the module detects that the YAML serial number differs from the faulty_device_serial_number reported by the replacement API entry (created in Step 1), and triggers the replacement workflow. The faulty device’s serial number is resolved from the replacement API entry. The user only provides the new replacement serial number.

Step 1 — Mark the faulty device for replacement:

Change the device state from PROVISION to MARK_FOR_REPLACEMENT. All existing device resources (provisioning, fabric roles, templates, port assignments) remain untouched during this step.

catalyst_center:
  inventory:
    devices:
      - name: SW-ACCESS-01
        fqdn_name: SW-ACCESS-01.company.local
        device_ip: 10.1.1.20
        pid: C9300-24P
        serial_number: FOC12345678
        state: MARK_FOR_REPLACEMENT
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        fabric_site: Global/HQ
        fabric_roles:
          - EDGE_NODE

Run terraform apply. Catalyst Center marks the device for replacement.

Step 2 — Trigger the replacement with the new device’s serial number:

Update serial_number to the replacement device’s serial number and change state back to PROVISION.

catalyst_center:
  inventory:
    devices:
      - name: SW-ACCESS-01
        fqdn_name: SW-ACCESS-01.company.local
        device_ip: 10.1.1.20
        pid: C9300-24P
        serial_number: FOC87654321
        state: PROVISION
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        fabric_site: Global/HQ
        fabric_roles:
          - EDGE_NODE

Run terraform apply. The module triggers the Catalyst Center RMA workflow, which transfers the configuration from the faulty device to the replacement device. The replacement workflow runs asynchronously in Catalyst Center.

Convergence: After Step 2, run terraform apply periodically. Once Catalyst Center finishes the replacement and updates its inventory to show the new device, the catalystcenter_device_replacement_workflow.rma resource will be removed from the Terraform plan. The catalystcenter_device_replacement.mark resource remains in Terraform state as a record of the completed replacement. The final result is a stable state with the device provisioned under the new serial number.

Note: The RMA process is fully repeatable. After the workflow completes and Terraform reaches a stable state, the same 2-step process can be used again for any future replacement of the same device.

Example-11: Deploying a Built-in or Pre-existing CLI Template

This example shows how to deploy a CLI template that already exists in Catalyst Center (a built-in template, or a custom template created outside of Terraform) without redefining it under Templates. Reference the template from the device using the <project_name>#<template_name> form. The module resolves the template via data sources (project lookup by name → template lookup by (project_id, template_name) → latest committed version) and deploys it to the device exactly like a managed template.

This form is supported in all three places a device consumes a template:

dayn_templates.regular[].name — built-in regular Day-N template.
dayn_templates.composite[].name — built-in composite Day-N template (members and their latest committed versions are discovered automatically; per-member variables are matched on template_name).
onboarding_template.name — built-in onboarding template (consumed by the PnP device-claim flow).

The <project_name>#<template_name> prefix is required — bare names are still treated as references to templates declared under templates.projects[] in the data model. Use this form only when the template is not declared in the data model.

Regular Day-N template:

catalyst_center:
  inventory:
    devices:
      - name: ACCESS-SW02
        fqdn_name: ACCESS-SW02.company.local
        device_ip: 192.168.20.11
        state: PROVISION
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        dayn_templates:
          regular:
            - name: Onboarding Configuration#BUILT_IN_HARDENING
              variables:
                - name: management_vlan
                  value: "100"
                - name: ntp_server
                  value: 10.0.0.1

Composite Day-N template. Reference the composite under dayn_templates.composite[]. The module reads the composite’s member templates from Catalyst Center, so only the composite itself is named here; per-member variables are tagged with template_name set to the member template name (exactly as for managed composites):

catalyst_center:
  inventory:
    devices:
      - name: ACCESS-SW02
        fqdn_name: ACCESS-SW02.company.local
        device_ip: 192.168.20.11
        state: PROVISION
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        dayn_templates:
          composite:
            - name: Project_DayN#ACL_COMPOSITE
              variables:
                - name: acl_ip_address
                  value: 21.21.21.0
                  template_name: ACL_41
                - name: acl_ip_address
                  value: 22.22.22.0
                  template_name: ACL_42

Onboarding template (PnP):

catalyst_center:
  inventory:
    devices:
      - name: ACCESS-SW02
        serial_number: FCW2152XXXX
        pid: C9300-48U
        state: PROVISION
        site: Global/HQ/Building A/Floor 1
        onboarding_template:
          name: Onboarding Configuration#BUILT_IN_PNP
          variables:
            - name: hostname
              value: ACCESS-SW02

Variable values are still supplied per device under variables[] exactly as for templates declared in the data model. The template content (and, for composites, the member list) stays in Catalyst Center — Terraform never reads or modifies the template definition.

Limitations:

The referenced project and template must already exist in Catalyst Center; otherwise terraform plan fails when the data sources cannot resolve the lookup. For composites, the member templates must also be committed (have at least one saved version).

Composite-ness is taken from the device section (dayn_templates.composite[] vs regular[]), so a built-in composite must be referenced under composite[] for its members to be deployed.

Example-12: Reconciling State When a Device is Removed Out-of-Band (Non-Fabric)

When a device provisioned through the data model (state: PROVISION) is later removed from Catalyst Center inventory out-of-band — for example, manually deleted from the Catalyst Center GUI — the data model becomes out of sync with the controller. A state: PROVISION entry asserts that the device must exist in Catalyst Center inventory. On the next terraform plan, apply, or destroy, the run fails because the device can no longer be found in inventory: device-discovery validation reports the device as missing, and the provisioning resource cannot resolve the device’s network_device_id.

Scenario (non-fabric device): The device was provisioned via the data model (Terraform) and then removed from inventory using the Catalyst Center GUI.

Resolution — reconcile the data model with the controller:

Change the device state to INIT in the data model.
Run terraform apply.

Setting the state to INIT unprovisions the device from the data model’s perspective and realigns Terraform with the controller. In the INIT state the device is excluded from the module’s device-discovery validation and from the provisioning workflow, so Terraform no longer requires it to be present in inventory. The provisioning resource for that device is then torn down: because the device is already absent from inventory, the provider detects that the resource no longer exists (its pre-delete verification lookup returns not found / 404) and removes it from Terraform state without raising an error.

Important: The state must be set specifically to INIT.

catalyst_center:
  inventory:
    devices:
      - name: SW-ACCESS-01
        fqdn_name: SW-ACCESS-01.company.local
        device_ip: 10.1.1.20
        state: INIT
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1

Run terraform apply. The device entry is reconciled and removed from Terraform state. If the device is no longer managed at all, its block can then be removed from the data model entirely on a subsequent apply.

Note: This procedure applies to non-fabric devices. Setting state: INIT is the supported way to realign the data model when a device has been removed from Catalyst Center outside of Terraform.

Location in GUI: Provision » Inventory

Diagram

Classes

inventory (catalyst_center)

Name	Type	Constraint	Mandatory	Default Value
devices	List	`[devices]`	No

devices (catalyst_center.inventory)

Name	Type	Constraint	Mandatory
name	String		Yes
fqdn_name	String		No
type	Choice	`AccessPoint`	No
rf_profile	String		No
device_ip	IP		No
pid	Any	String or Null	No
serial_number	Any	String or Null	No
state	Choice	`INIT`, `PNP`, `PROVISION`, `REPROVISION`, `ASSIGN`, `MARK_FOR_REPLACEMENT`	Yes
device_role	Choice	`ACCESS`, `CORE`, `DISTRIBUTION`, `BORDER ROUTER`	Yes
site	String		Yes
fabric_site	String		No
fabric_zone	String		No
fabric_roles	List	Choice[`BORDER_NODE`, `CONTROL_PLANE_NODE`, `EDGE_NODE`, `WIRELESS_CONTROLLER_NODE`, `EMBEDDED_WIRELESS_CONTROLLER_NODE`]	No
enable_wireless	Boolean	`true`, `false`	No
clean_up_config	Boolean	`true`, `false`	No
enable_rolling_ap_upgrade	Boolean	`true`, `false`	No
image_name	String		No
image_id	String		No
image_skip	Boolean	`true`, `false`	No
stack	Class	`[stack]`	No
ap_reboot_percentage	Choice	`5`, `15`, `25`	No
onboarding_template	Class	`[onboarding_template]`	No
dayn_templates	Class	`[dayn_templates]`	No
primary_managed_ap_locations	List	String	No
secondary_managed_ap_locations	List	String	No
port_assignments	List	`[port_assignments]`	No
port_channels	List	`[port_channels]`	No
tags	List	String	No

stack (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory	Default Value
top_of_stack_serial_number	String		Yes
cabling_scheme	Choice	`1A`, `1B`	Yes

onboarding_template (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory	Default Value
name	String		Yes
variables	List	`[variables]`	No

dayn_templates (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory
regular	List	`[regular]`	No
composite	List	`[composite]`	No
redeploy_template	Choice	`ALWAYS`, `NEVER`, `ON_CHANGE`	No

port_assignments (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory
interface_name	String		No
interfaces_range	String	Regex: `^[A-Za-z]+\d+(/\d+)+-\d+(/\d+)+$`	No
interface_description	String		No
connected_device_type	Choice	`USER_DEVICE`, `ACCESS_POINT`, `TRUNKING_DEVICE`, `AUTHENTICATOR_SWITCH`, `SUPPLICANT_BASED_EXTENDED_NODE`	Yes
data_vlan_name	String		No
voice_vlan_name	String		No
security_group_name	String		No
authenticate_template_name	Choice	`No Authentication`, `Open Authentication`, `Closed Authentication`, `Low Impact`	No

port_channels (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory
id	Integer		Yes
connected_device_type	Choice	`TRUNK`, `EXTENDED_NODE`	Yes
protocol	Choice	`ON`, `LACP`, `PAGP`	No
description	String		No
interface_names	List	String	Yes
native_vlan_id	Integer	min: `1`, max: `4094`	No
allowed_vlan_ranges	String		No

variables (catalyst_center.inventory.devices.onboarding_template)

Name	Type	Constraint	Mandatory	Default Value
name	String		Yes
value	Any	String or List[String]	Yes

regular (catalyst_center.inventory.devices.dayn_templates)

Name	Type	Constraint	Mandatory
name	String		Yes
variables	List	`[variables]`	No
redeploy_template	Choice	`ALWAYS`, `NEVER`, `ON_CHANGE`	No
copying_config	Boolean	`true`, `false`	No
force_push_template	Boolean	`true`, `false`	No

composite (catalyst_center.inventory.devices.dayn_templates)

Name	Type	Constraint	Mandatory
name	String		Yes
variables	List	`[variables]`	No
redeploy_template	Choice	`ALWAYS`, `NEVER`, `ON_CHANGE`	No
copying_config	Boolean	`true`, `false`	No
force_push_template	Boolean	`true`, `false`	No

variables (catalyst_center.inventory.devices.dayn_templates.composite)

Name	Type	Constraint	Mandatory
name	String		Yes
value	Any	String or List[String]	Yes
template_name	String		Yes

Device Provisioning States and Lifecycle

Device States

INIT (Initial State)

The starting state for all devices when first added to the inventory. Devices in this state are discovered but not yet assigned to any site or configured for provisioning.

Characteristics:

Device is discovered and added to inventory
No site assignment
No configuration applied
Basic device information collected (IP, serial number, PID)

Possible Transitions:

To ASSIGN: Assign device to a specific site for configuration
To PROVISION: Begin provisioning process for non-fabric devices as well fabric provisioning, if fabric attributes specified

PNP (Plug and Play)

Devices in this state are ready for zero-touch provisioning when they boot up and contact the Catalyst Center. This state is typically used for new devices that will be deployed in remote locations.

Characteristics:

Device prepared for zero-touch deployment
Configuration templates pre-assigned
Waiting for device to contact Catalyst Center
No active management until device boots

Possible Transitions:

To PROVISION: Begin provisioning process for non-fabric devices as well fabric provisioning, if fabric attributes specified
To INIT: Keep device in Inventory “as is” after PNP process
ASSIGN: Assign device to a specific site

ASSIGN

Devices are assigned to a specific site but not yet provisioned with configuration. This state allows for site-specific settings preparation before actual provisioning.

Characteristics:

Device assigned to a site hierarchy
Site-specific credentials and settings applied
Ready for provisioning process
Configuration templates can be assigned

Possible Transitions:

To PROVISION: Begin provisioning process for non-fabric devices as well fabric provisioning, if fabric attributes specified
To INIT: Un-assign device from site

PROVISION

The active provisioning state where devices receive their full configuration and become operational network elements. This is the target state for most production devices.

Characteristics:

Full configuration deployment in progress or completed
Device actively managed by Catalyst Center
Templates applied and configuration synchronized
Monitoring and compliance checking active
Fabric roles assigned (if applicable)

Possible Transitions:

To REPROVISION: When configuration changes require redeployment
To INIT: Unprovision device completely (removes from SDA fabric and/or Inventory with config clearing)

REPROVISION

A specialized state for devices that need Network Settings configuration updates. This state ensures network settings are refreshed while maintaining device operational status.

Characteristics:

Device remains operational during re-provisioning
Configuration templates reapplied
Network settings updated every time
Maintains existing fabric membership and site assignment

Possible Transitions:

To PROVISION: Return to standard provisioned state after updates complete
To INIT: Unprovision device completely (removes from SDA fabric and/or Inventory with config clearing)

State Transition Operations

Provisioning Operations

Provision non-fabric devices: Apply standard network configuration
Provision fabric devices: Apply SDA fabric configuration and assign fabric roles
Both operations move devices from INIT, ASSIGN or PNP states to PROVISION state

Unprovisioning Operations

Standard Unprovisioning: Removes device from Inventory management with configuration clearing
SDA Fabric Removal: Removes from both SDA fabric and Inventory with configuration clearing

Best Practices

State Management

Use ASSIGN state for devices requiring site-specific preparation
Use PNP state for zero-touch deployment scenarios
Monitor devices in REPROVISION state for completion

Operational Considerations

Devices in PROVISION state should be monitored for compliance
REPROVISION operations should be scheduled during maintenance windows
Use proper unprovisioning procedures to avoid configuration conflicts
Maintain device inventory accuracy across all states

Examples

Example-1: SD-Access Border Router Device Configuration

The border router device configuration includes:

Device name (BR01) for identification and inventory management
Management IP address (192.168.10.1) for device communication and monitoring
PROVISION state for active deployment and configuration management
Border router role designation for network function
Site assignment (Global/Canada) for geographic and organizational placement
Fabric site association (Global/Canada) for SD-Access fabric membership
Multiple fabric roles including BORDER_NODE for external connectivity and CONTROL_PLANE_NODE for fabric control plane operations

catalyst_center:
  inventory:
    devices:
      - name: BR01
        fqdn_name: BR01.company.local
        device_ip: 192.168.10.1
        state: PROVISION
        device_role: BORDER ROUTER
        site: Global/Canada
        fabric_site: Global/Canada
        fabric_roles:
          - BORDER_NODE
          - CONTROL_PLANE_NODE

Example-2: Access Switch with Edge Node Functionality

This example shows how to configure an access layer switch with SD-Access edge node capabilities for endpoint connectivity and policy enforcement at the network edge.

catalyst_center:
  inventory:
    devices:
      - name: ACCESS-SW01
        fqdn_name: ACCESS-SW01.company.local
        device_ip: 192.168.20.10
        serial_number: FOC2644021A
        pid: C9300-24P
        state: PROVISION
        device_role: ACCESS
        site: Global/North America/Campus/Building A/Floor 1
        fabric_site: Global/North America/Campus
        fabric_roles:
          - EDGE_NODE
        tags:
          - FLOOR1_DEVICES
          - EMPLOYEE_ACCESS

Example-3: Plug-n-Play Functionality

This example shows how to configure a device to be on-boarded into Catalyst Center inventory using plug and play.

catalyst_center:
  inventory:
    devices:
      - name: PNP_DEVICE
        fqdn_name: PNP_DEVICE.cisco.eu
        device_ip: 192.158.142.20
        serial_number: FAB12345602
        pid: C9300-48P
        state: PNP
        device_role: BORDER ROUTER
        site: Global/Poland/Krakow/Bld A
        onboarding_template:
          name: PNP_Template
          variables:
            - name: device_host_name
              value: PNP_DEVICE
            - name: infra_vlan
              value: "100"
            - name: infra_vlan_network_add
              value: 181.1.1.90
            - name: infra_vlan_network_mask
              value: 255.255.255.248
            - name: loopback_0_IP
              value: 192.158.142.20
            - name: loopback_0_mask
              value: 255.255.255.255
            - name: Border_AS
              value: "65005"
            - name: peer_BGP_neigbor
              value: 181.1.1.89
            - name: peer_AS
              value: "65002"
            - name: peer_interface
              value: GigabitEthernet1/0/1

After the plug and play process is completed, the device state can be updated to PROVISION to enable full management and configuration capabilities within Catalyst Center.

catalyst_center:
  inventory:
    devices:
      - name: PNP_DEVICE
        fqdn_name: PNP_DEVICE.cisco.eu
        device_ip: 192.158.142.20
        serial_number: FAB12345602
        pid: C9300-48P
        state: PROVISION
        device_role: BORDER ROUTER
        site: Global/Poland/Krakow/Bld A

Example-4: Access Point Plug-n-Play

This example shows how to configure an Access Point to be on-boarded into Catalyst Center inventory using plug and play.

Note : It is mandatory to provide the type as AccessPoint, rf_profile, and site in order to add and claim the device in Provision -> Plug and Play

catalyst_center:
  inventory:
    devices:
      - name: AP_PNP
        fqdn_name: AP_PNP.cisco.eu
        pid: C9136I-E
        serial_number: FGL3727MF6Y
        state: PNP
        type: AccessPoint
        rf_profile: TYPICAL
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A/FLOOR_2

After the plug and play process is completed, the Access Point can be updated to PROVISION to provision full management and configuration capabilities within Catalyst Center.

catalyst_center:
  inventory:
    devices:
      - name: AP_PNP
        fqdn_name: AP_PNP.cisco.eu
        pid: C9136I-E
        serial_number: FGL3727MF6Y
        state: PROVISION
        type: AccessPoint
        rf_profile: TYPICAL
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A/FLOOR_2

Example-5: Embedded Wireless Controller provisioning

This example demonstrates how to enable the fabric Embedded Wireless Controller (EWC) role within a fabric site

Note :

It is mandatory to provide the fabric_role as EMBEDDED_WIRELESS_CONTROLLER_NODE (in addition to the existing role(s) - EDGE, BORDER)
It is also required to populate the primary_managed_ap_locations field to specify the primary location(s) for managed access points (APs)

catalyst_center:
  inventory:
    devices:
      - name: P3-EN1
        fqdn_name: P3-EN1.cisco.eu
        device_ip: 192.168.30.24
        pid: C9300-24P
        state: PROVISION
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A
        fabric_site: Global/Poland/Krakow
        fabric_roles:
          - EDGE_NODE
          - EMBEDDED_WIRELESS_CONTROLLER_NODE
        primary_managed_ap_locations:
          - Global/Poland/Krakow/Bld A/FLOOR_2
          - Global/Poland/Krakow/Bld A/FLOOR_1

Example-6: Management IP Address Update

Note: This resource uses an ephemeral approach: it only appears in Terraform state when device_ip differs from the current Catalyst Center management IP. After a successful apply, the next apply will detect the IPs match, automatically remove the resource from state, and make no further changes. This means zero state footprint when IPs are in sync. This feature does not apply to Access Points (type: AccessPoint).

catalyst_center:
  inventory:
    devices:
      - name: SW-CORE-01
        fqdn_name: SW-CORE-01.company.local
        device_ip: 10.1.1.100        # new management IP (was 10.1.1.10)
        state: PROVISION
        device_role: CORE
        site: Global/HQ/DataCenter

Example-7: Device Unprovisioning with clean_up_config

Important: This is a two-step process:

First terraform apply: Set clean_up_config: false on the device while it is still in PROVISION state. This tells Catalyst Center to skip configuration cleanup on the next state change.

Second terraform apply: Change the device state to INIT (unprovision). Because clean_up_config was already set to false, Catalyst Center will remove the device without attempting to reach it.

Step 1 — Set clean_up_config: false on the unreachable device:

catalyst_center:
  inventory:
    devices:
      - name: SW-UNREACHABLE-01
        fqdn_name: SW-UNREACHABLE-01.company.local
        device_ip: 10.1.1.50
        state: PROVISION
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        clean_up_config: false

Run terraform apply to register the flag with Catalyst Center.

Step 2 — Unprovision the device by setting state: INIT:

catalyst_center:
  inventory:
    devices:
      - name: SW-UNREACHABLE-01
        fqdn_name: SW-UNREACHABLE-01.company.local
        device_ip: 10.1.1.50
        state: INIT
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        clean_up_config: false

Run terraform apply again. Catalyst Center will remove the device from inventory without attempting to clean its configuration.

Setting `clean_up_config` globally via `defaults.yaml`

If you have multiple unreachable devices or want to apply this flag to all devices by default, you can set it in the defaults.yaml file instead of on each individual device:

defaults:
  catalyst_center:
    inventory:
      devices:
        clean_up_config: false

Example-8: RMA (Return Material Authorization) Device Replacement

Prerequisites:

The faulty device must be unreachable in Catalyst Center
The replacement device must be physically connected and reachable by Catalyst Center
The device must have serial_number defined in the data model

How it works: The module uses a data.catalystcenter_device_replacement data source to query Catalyst Center’s device replacement API for the device. When the device is in MARK_FOR_REPLACEMENT state (Step 1), the module marks it for replacement via the API. When the device transitions back to PROVISION state with a new serial_number (Step 2), the module detects that the YAML serial number differs from the faulty_device_serial_number reported by the replacement API entry (created in Step 1), and triggers the replacement workflow. The faulty device’s serial number is resolved from the replacement API entry. The user only provides the new replacement serial number.

Step 1 — Mark the faulty device for replacement:

Change the device state from PROVISION to MARK_FOR_REPLACEMENT. All existing device resources (provisioning, fabric roles, templates, port assignments) remain untouched during this step.

catalyst_center:
  inventory:
    devices:
      - name: SW-ACCESS-01
        fqdn_name: SW-ACCESS-01.company.local
        device_ip: 10.1.1.20
        pid: C9300-24P
        serial_number: FOC12345678
        state: MARK_FOR_REPLACEMENT
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        fabric_site: Global/HQ
        fabric_roles:
          - EDGE_NODE

Run terraform apply. Catalyst Center marks the device for replacement.

Step 2 — Trigger the replacement with the new device’s serial number:

Update serial_number to the replacement device’s serial number and change state back to PROVISION.

catalyst_center:
  inventory:
    devices:
      - name: SW-ACCESS-01
        fqdn_name: SW-ACCESS-01.company.local
        device_ip: 10.1.1.20
        pid: C9300-24P
        serial_number: FOC87654321
        state: PROVISION
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        fabric_site: Global/HQ
        fabric_roles:
          - EDGE_NODE

Note: The RMA process is fully repeatable. After the workflow completes and Terraform reaches a stable state, the same 2-step process can be used again for any future replacement of the same device.

Location in GUI: Provision » Inventory

Diagram

Classes

inventory (catalyst_center)

Name	Type	Constraint	Mandatory	Default Value
devices	List	`[devices]`	No

devices (catalyst_center.inventory)

Name	Type	Constraint	Mandatory
name	String		Yes
fqdn_name	String		No
type	Choice	`AccessPoint`	No
rf_profile	String		No
device_ip	IP		No
pid	Any	String or Null	No
serial_number	Any	String or Null	No
state	Choice	`INIT`, `PNP`, `PROVISION`, `REPROVISION`, `ASSIGN`, `MARK_FOR_REPLACEMENT`	Yes
device_role	Choice	`ACCESS`, `CORE`, `DISTRIBUTION`, `BORDER ROUTER`	Yes
site	String		Yes
fabric_site	String		No
fabric_zone	String		No
fabric_roles	List	Choice[`BORDER_NODE`, `CONTROL_PLANE_NODE`, `EDGE_NODE`, `WIRELESS_CONTROLLER_NODE`, `EMBEDDED_WIRELESS_CONTROLLER_NODE`]	No
enable_wireless	Boolean	`true`, `false`	No
clean_up_config	Boolean	`true`, `false`	No
enable_rolling_ap_upgrade	Boolean	`true`, `false`	No
ap_reboot_percentage	Choice	`5`, `15`, `25`	No
onboarding_template	Class	`[onboarding_template]`	No
dayn_templates	Class	`[dayn_templates]`	No
primary_managed_ap_locations	List	String	No
secondary_managed_ap_locations	List	String	No
port_assignments	List	`[port_assignments]`	No
tags	List	String	No

onboarding_template (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory	Default Value
name	String		Yes
variables	List	`[variables]`	No

dayn_templates (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory
regular	List	`[regular]`	No
composite	List	`[composite]`	No
redeploy_template	Choice	`ALWAYS`, `NEVER`, `ON_CHANGE`	No

port_assignments (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory
interface_name	String		No
interfaces_range	String	Regex: `^[A-Za-z]+\d+(/\d+)+-\d+(/\d+)+$`	No
interface_description	String		No
connected_device_type	Choice	`USER_DEVICE`, `ACCESS_POINT`, `TRUNKING_DEVICE`, `AUTHENTICATOR_SWITCH`, `SUPPLICANT_BASED_EXTENDED_NODE`	Yes
data_vlan_name	String		No
voice_vlan_name	String		No
security_group_name	String		No
authenticate_template_name	Choice	`No Authentication`, `Open Authentication`, `Closed Authentication`, `Low Impact`	No

variables (catalyst_center.inventory.devices.onboarding_template)

Name	Type	Constraint	Mandatory	Default Value
name	String		Yes
value	Any	String or List[String]	Yes

regular (catalyst_center.inventory.devices.dayn_templates)

Name	Type	Constraint	Mandatory
name	String		Yes
variables	List	`[variables]`	No
redeploy_template	Choice	`ALWAYS`, `NEVER`, `ON_CHANGE`	No
copying_config	Boolean	`true`, `false`	No
force_push_template	Boolean	`true`, `false`	No

composite (catalyst_center.inventory.devices.dayn_templates)

Name	Type	Constraint	Mandatory
name	String		Yes
variables	List	`[variables]`	No
redeploy_template	Choice	`ALWAYS`, `NEVER`, `ON_CHANGE`	No
copying_config	Boolean	`true`, `false`	No
force_push_template	Boolean	`true`, `false`	No

variables (catalyst_center.inventory.devices.dayn_templates.composite)

Name	Type	Constraint	Mandatory
name	String		Yes
value	Any	String or List[String]	Yes
template_name	String		Yes

Devices represent the network equipment managed by Catalyst Center. The device data model defines inventory attributes, site assignment, provisioning parameters, and fabric roles. Devices must be discovered (via Discovery or manual add), assigned to a site, and provisioned before they can participate in the network. In SDA fabric deployments, devices are additionally assigned fabric roles (edge, border, control plane) for Fabric Site participation. Applicable to both SDA fabric and non-fabric deployments.

Device Provisioning States and Lifecycle

Device States

INIT (Initial State)

The starting state for all devices when first added to the inventory. Devices in this state are discovered but not yet assigned to any site or configured for provisioning.

Characteristics:

Device is discovered and added to inventory
No site assignment
No configuration applied
Basic device information collected (IP, serial number, PID)

Possible Transitions:

To ASSIGN: Assign device to a specific site for configuration
To PROVISION: Begin provisioning process for non-fabric devices as well fabric provisioning, if fabric attributes specified

PNP (Plug and Play)

Devices in this state are ready for zero-touch provisioning when they boot up and contact the Catalyst Center. This state is typically used for new devices that will be deployed in remote locations.

Characteristics:

Device prepared for zero-touch deployment
Configuration templates pre-assigned
Waiting for device to contact Catalyst Center
No active management until device boots

Possible Transitions:

To PROVISION: Begin provisioning process for non-fabric devices as well fabric provisioning, if fabric attributes specified
To INIT: Keep device in Inventory “as is” after PNP process
ASSIGN: Assign device to a specific site

ASSIGN

Devices are assigned to a specific site but not yet provisioned with configuration. This state allows for site-specific settings preparation before actual provisioning.

Characteristics:

Device assigned to a site hierarchy
Site-specific credentials and settings applied
Ready for provisioning process
Configuration templates can be assigned

Possible Transitions:

To PROVISION: Begin provisioning process for non-fabric devices as well fabric provisioning, if fabric attributes specified
To INIT: Un-assign device from site

PROVISION

The active provisioning state where devices receive their full configuration and become operational network elements. This is the target state for most production devices.

Characteristics:

Full configuration deployment in progress or completed
Device actively managed by Catalyst Center
Templates applied and configuration synchronized
Monitoring and compliance checking active
Fabric roles assigned (if applicable)

Possible Transitions:

To REPROVISION: When configuration changes require redeployment
To INIT: Unprovision device completely (removes from SDA fabric and/or Inventory with config clearing)

REPROVISION

A specialized state for devices that need Network Settings configuration updates. This state ensures network settings are refreshed while maintaining device operational status.

Characteristics:

Device remains operational during re-provisioning
Configuration templates reapplied
Network settings updated every time
Maintains existing fabric membership and site assignment

Possible Transitions:

To PROVISION: Return to standard provisioned state after updates complete
To INIT: Unprovision device completely (removes from SDA fabric and/or Inventory with config clearing)

State Transition Operations

Provisioning Operations

Provision non-fabric devices: Apply standard network configuration
Provision fabric devices: Apply SDA fabric configuration and assign fabric roles
Both operations move devices from INIT, ASSIGN or PNP states to PROVISION state

Unprovisioning Operations

Standard Unprovisioning: Removes device from Inventory management with configuration clearing
SDA Fabric Removal: Removes from both SDA fabric and Inventory with configuration clearing

Best Practices

State Management

Use ASSIGN state for devices requiring site-specific preparation
Use PNP state for zero-touch deployment scenarios
Monitor devices in REPROVISION state for completion

Operational Considerations

Devices in PROVISION state should be monitored for compliance
REPROVISION operations should be scheduled during maintenance windows
Use proper unprovisioning procedures to avoid configuration conflicts
Maintain device inventory accuracy across all states

Examples

Example-1: SD-Access Border Router Device Configuration

The border router device configuration includes:

Device name (BR01) for identification and inventory management
Management IP address (192.168.10.1) for device communication and monitoring
PROVISION state for active deployment and configuration management
Border router role designation for network function
Site assignment (Global/Canada) for geographic and organizational placement
Fabric site association (Global/Canada) for SD-Access fabric membership
Multiple fabric roles including BORDER_NODE for external connectivity and CONTROL_PLANE_NODE for fabric control plane operations

catalyst_center:
  inventory:
    devices:
      - name: BR01
        fqdn_name: BR01.company.local
        device_ip: 192.168.10.1
        state: PROVISION
        device_role: BORDER ROUTER
        site: Global/Canada
        fabric_site: Global/Canada
        fabric_roles:
          - BORDER_NODE
          - CONTROL_PLANE_NODE

Example-2: Access Switch with Edge Node Functionality

This example shows how to configure an access layer switch with SD-Access edge node capabilities for endpoint connectivity and policy enforcement at the network edge.

catalyst_center:
  inventory:
    devices:
      - name: ACCESS-SW01
        fqdn_name: ACCESS-SW01.company.local
        device_ip: 192.168.20.10
        serial_number: FOC2644021A
        pid: C9300-24P
        state: PROVISION
        device_role: ACCESS
        site: Global/North America/Campus/Building A/Floor 1
        fabric_site: Global/North America/Campus
        fabric_roles:
          - EDGE_NODE
        tags:
          - FLOOR1_DEVICES
          - EMPLOYEE_ACCESS

Example-3: Plug-n-Play Functionality

This example shows how to configure a device to be on-boarded into Catalyst Center inventory using plug and play.

catalyst_center:
  inventory:
    devices:
      - name: PNP_DEVICE
        fqdn_name: PNP_DEVICE.cisco.eu
        device_ip: 192.158.142.20
        serial_number: FAB12345602
        pid: C9300-48P
        state: PNP
        device_role: BORDER ROUTER
        site: Global/Poland/Krakow/Bld A
        onboarding_template:
          name: PNP_Template
          variables:
            - name: device_host_name
              value: PNP_DEVICE
            - name: infra_vlan
              value: "100"
            - name: infra_vlan_network_add
              value: 181.1.1.90
            - name: infra_vlan_network_mask
              value: 255.255.255.248
            - name: loopback_0_IP
              value: 192.158.142.20
            - name: loopback_0_mask
              value: 255.255.255.255
            - name: Border_AS
              value: "65005"
            - name: peer_BGP_neigbor
              value: 181.1.1.89
            - name: peer_AS
              value: "65002"
            - name: peer_interface
              value: GigabitEthernet1/0/1

After the plug and play process is completed, the device state can be updated to PROVISION to enable full management and configuration capabilities within Catalyst Center.

catalyst_center:
  inventory:
    devices:
      - name: PNP_DEVICE
        fqdn_name: PNP_DEVICE.cisco.eu
        device_ip: 192.158.142.20
        serial_number: FAB12345602
        pid: C9300-48P
        state: PROVISION
        device_role: BORDER ROUTER
        site: Global/Poland/Krakow/Bld A

Example-4: Access Point Plug-n-Play

This example shows how to configure an Access Point to be on-boarded into Catalyst Center inventory using plug and play.

Note : It is mandatory to provide the type as AccessPoint, rf_profile, and site in order to add and claim the device in Provision -> Plug and Play

catalyst_center:
  inventory:
    devices:
      - name: AP_PNP
        fqdn_name: AP_PNP.cisco.eu
        pid: C9136I-E
        serial_number: FGL3727MF6Y
        state: PNP
        type: AccessPoint
        rf_profile: TYPICAL
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A/FLOOR_2

After the plug and play process is completed, the Access Point can be updated to PROVISION to provision full management and configuration capabilities within Catalyst Center.

catalyst_center:
  inventory:
    devices:
      - name: AP_PNP
        fqdn_name: AP_PNP.cisco.eu
        pid: C9136I-E
        serial_number: FGL3727MF6Y
        state: PROVISION
        type: AccessPoint
        rf_profile: TYPICAL
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A/FLOOR_2

Example-5: Embedded Wireless Controller provisioning

This example demonstrates how to enable the fabric Embedded Wireless Controller (EWC) role within a fabric site

Note :

It is mandatory to provide the fabric_role as EMBEDDED_WIRELESS_CONTROLLER_NODE (in addition to the existing role(s) - EDGE, BORDER)
It is also required to populate the primary_managed_ap_locations field to specify the primary location(s) for managed access points (APs)

catalyst_center:
  inventory:
    devices:
      - name: P3-EN1
        fqdn_name: P3-EN1.cisco.eu
        device_ip: 192.168.30.24
        pid: C9300-24P
        state: PROVISION
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A
        fabric_site: Global/Poland/Krakow
        fabric_roles:
          - EDGE_NODE
          - EMBEDDED_WIRELESS_CONTROLLER_NODE
        primary_managed_ap_locations:
          - Global/Poland/Krakow/Bld A/FLOOR_2
          - Global/Poland/Krakow/Bld A/FLOOR_1

Example-6: Management IP Address Update

Note: This resource uses an ephemeral approach: it only appears in Terraform state when device_ip differs from the current Catalyst Center management IP. After a successful apply, the next apply will detect the IPs match, automatically remove the resource from state, and make no further changes. This means zero state footprint when IPs are in sync. This feature does not apply to Access Points (type: AccessPoint).

catalyst_center:
  inventory:
    devices:
      - name: SW-CORE-01
        fqdn_name: SW-CORE-01.company.local
        device_ip: 10.1.1.100        # new management IP (was 10.1.1.10)
        state: PROVISION
        device_role: CORE
        site: Global/HQ/DataCenter

Example-7: Device Unprovisioning with clean_up_config

Important: This is a two-step process:

First terraform apply: Set clean_up_config: false on the device while it is still in PROVISION state. This tells Catalyst Center to skip configuration cleanup on the next state change.

Second terraform apply: Change the device state to INIT (unprovision). Because clean_up_config was already set to false, Catalyst Center will remove the device without attempting to reach it.

Step 1 — Set clean_up_config: false on the unreachable device:

catalyst_center:
  inventory:
    devices:
      - name: SW-UNREACHABLE-01
        fqdn_name: SW-UNREACHABLE-01.company.local
        device_ip: 10.1.1.50
        state: PROVISION
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        clean_up_config: false

Run terraform apply to register the flag with Catalyst Center.

Step 2 — Unprovision the device by setting state: INIT:

catalyst_center:
  inventory:
    devices:
      - name: SW-UNREACHABLE-01
        fqdn_name: SW-UNREACHABLE-01.company.local
        device_ip: 10.1.1.50
        state: INIT
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        clean_up_config: false

Run terraform apply again. Catalyst Center will remove the device from inventory without attempting to clean its configuration.

Setting `clean_up_config` globally via `defaults.yaml`

If you have multiple unreachable devices or want to apply this flag to all devices by default, you can set it in the defaults.yaml file instead of on each individual device:

defaults:
  catalyst_center:
    inventory:
      devices:
        clean_up_config: false

Example-8: RMA (Return Material Authorization) Device Replacement

Prerequisites:

The faulty device must be unreachable in Catalyst Center
The replacement device must be physically connected and reachable by Catalyst Center
The device must have serial_number defined in the data model

How it works: The module uses a data.catalystcenter_device_detail data source to look up the current serial number from Catalyst Center’s live inventory. When the YAML serial_number differs from the inventory serial number and the device is in PROVISION state, the module automatically triggers the replacement workflow. The user only needs to provide the new replacement serial number — the faulty serial number is resolved automatically.

Step 1 — Mark the faulty device for replacement:

Change the device state from PROVISION to MARK_FOR_REPLACEMENT. All existing device resources (provisioning, fabric roles, templates, port assignments) remain untouched during this step.

catalyst_center:
  inventory:
    devices:
      - name: SW-ACCESS-01
        fqdn_name: SW-ACCESS-01.company.local
        device_ip: 10.1.1.20
        pid: C9300-24P
        serial_number: FOC12345678
        state: MARK_FOR_REPLACEMENT
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        fabric_site: Global/HQ
        fabric_roles:
          - EDGE_NODE

Run terraform apply. Catalyst Center marks the device for replacement.

Step 2 — Trigger the replacement with the new device’s serial number:

Update serial_number to the replacement device’s serial number and change state back to PROVISION.

catalyst_center:
  inventory:
    devices:
      - name: SW-ACCESS-01
        fqdn_name: SW-ACCESS-01.company.local
        device_ip: 10.1.1.20
        pid: C9300-24P
        serial_number: FOC87654321
        state: PROVISION
        device_role: ACCESS
        site: Global/HQ/Building A/Floor 1
        fabric_site: Global/HQ
        fabric_roles:
          - EDGE_NODE

Convergence: After Step 2, run terraform apply periodically. Once Catalyst Center finishes the replacement and updates its inventory to show the new device, Terraform automatically cleans up the temporary RMA resources from its state. The final result is a clean state with the device provisioned under the new serial number.

Note: The RMA process is fully repeatable. After the workflow completes and Terraform reaches a clean state, the same 2-step process can be used again for any future replacement of the same device.

Location in GUI: Provision » Inventory

Diagram

Classes

inventory (catalyst_center)

Name	Type	Constraint	Mandatory	Default Value
devices	List	`[devices]`	No

devices (catalyst_center.inventory)

Name	Type	Constraint	Mandatory
name	String		Yes
fqdn_name	String		No
type	Choice	`AccessPoint`	No
rf_profile	String		No
device_ip	IP		No
pid	Any	String or Null	No
serial_number	Any	String or Null	No
state	Choice	`INIT`, `PNP`, `PROVISION`, `REPROVISION`, `ASSIGN`	Yes
device_role	Choice	`ACCESS`, `CORE`, `DISTRIBUTION`, `BORDER ROUTER`	Yes
site	String		Yes
fabric_site	String		No
fabric_zone	String		No
fabric_roles	List	Choice[`BORDER_NODE`, `CONTROL_PLANE_NODE`, `EDGE_NODE`, `WIRELESS_CONTROLLER_NODE`, `EMBEDDED_WIRELESS_CONTROLLER_NODE`]	No
enable_wireless	Boolean	`true`, `false`	No
enable_rolling_ap_upgrade	Boolean	`true`, `false`	No
ap_reboot_percentage	Choice	`5`, `15`, `25`	No
onboarding_template	Class	`[onboarding_template]`	No
dayn_templates	Class	`[dayn_templates]`	No
primary_managed_ap_locations	List	String	No
secondary_managed_ap_locations	List	String	No
port_assignments	List	`[port_assignments]`	No
tags	List	String	No

onboarding_template (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory	Default Value
name	String		Yes
variables	List	`[variables]`	No

dayn_templates (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory
regular	List	`[regular]`	No
composite	List	`[composite]`	No
redeploy_template	Choice	`ALWAYS`, `NEVER`, `ON_CHANGE`	No

port_assignments (catalyst_center.inventory.devices)

Name	Type	Constraint	Mandatory
interface_name	String		No
interfaces_range	String	Regex: `^[A-Za-z]+\d+(/\d+)+-\d+(/\d+)+$`	No
interface_description	String		No
connected_device_type	Choice	`USER_DEVICE`, `ACCESS_POINT`, `TRUNKING_DEVICE`, `AUTHENTICATOR_SWITCH`, `SUPPLICANT_BASED_EXTENDED_NODE`	Yes
data_vlan_name	String		No
voice_vlan_name	String		No
security_group_name	String		No
authenticate_template_name	Choice	`No Authentication`, `Open Authentication`, `Closed Authentication`, `Low Impact`	No

variables (catalyst_center.inventory.devices.onboarding_template)

Name	Type	Constraint	Mandatory	Default Value
name	String		Yes
value	Any	String or List[String]	Yes

regular (catalyst_center.inventory.devices.dayn_templates)

Name	Type	Constraint	Mandatory
name	String		Yes
variables	List	`[variables]`	No
redeploy_template	Choice	`ALWAYS`, `NEVER`, `ON_CHANGE`	No
copying_config	Boolean	`true`, `false`	No
force_push_template	Boolean	`true`, `false`	No

composite (catalyst_center.inventory.devices.dayn_templates)

Name	Type	Constraint	Mandatory
name	String		Yes
variables	List	`[variables]`	No
redeploy_template	Choice	`ALWAYS`, `NEVER`, `ON_CHANGE`	No
copying_config	Boolean	`true`, `false`	No
force_push_template	Boolean	`true`, `false`	No

variables (catalyst_center.inventory.devices.dayn_templates.composite)

Name	Type	Constraint	Mandatory
name	String		Yes
value	Any	String or List[String]	Yes
template_name	String		Yes

Device Provisioning States and Lifecycle

Device States

INIT (Initial State)

The starting state for all devices when first added to the inventory. Devices in this state are discovered but not yet assigned to any site or configured for provisioning.

Characteristics:

Device is discovered and added to inventory
No site assignment
No configuration applied
Basic device information collected (IP, serial number, PID)

Possible Transitions:

To ASSIGN: Assign device to a specific site for configuration
To PROVISION: Begin provisioning process for non-fabric devices as well fabric provisioning, if fabric attributes specified

PNP (Plug and Play)

Devices in this state are ready for zero-touch provisioning when they boot up and contact the Catalyst Center. This state is typically used for new devices that will be deployed in remote locations.

Characteristics:

Device prepared for zero-touch deployment
Configuration templates pre-assigned
Waiting for device to contact Catalyst Center
No active management until device boots

Possible Transitions:

To PROVISION: Begin provisioning process for non-fabric devices as well fabric provisioning, if fabric attributes specified
To INIT: Keep device in Inventory “as is” after PNP process
ASSIGN: Assign device to a specific site

ASSIGN

Devices are assigned to a specific site but not yet provisioned with configuration. This state allows for site-specific settings preparation before actual provisioning.

Characteristics:

Device assigned to a site hierarchy
Site-specific credentials and settings applied
Ready for provisioning process
Configuration templates can be assigned

Possible Transitions:

To PROVISION: Begin provisioning process for non-fabric devices as well fabric provisioning, if fabric attributes specified
To INIT: Un-assign device from site

PROVISION

The active provisioning state where devices receive their full configuration and become operational network elements. This is the target state for most production devices.

Characteristics:

Full configuration deployment in progress or completed
Device actively managed by Catalyst Center
Templates applied and configuration synchronized
Monitoring and compliance checking active
Fabric roles assigned (if applicable)

Possible Transitions:

To REPROVISION: When configuration changes require redeployment
To INIT: Unprovision device completely (removes from SDA fabric and/or Inventory with config clearing)

REPROVISION

A specialized state for devices that need Network Settings configuration updates. This state ensures network settings are refreshed while maintaining device operational status.

Characteristics:

Device remains operational during re-provisioning
Configuration templates reapplied
Network settings updated every time
Maintains existing fabric membership and site assignment

Possible Transitions:

To PROVISION: Return to standard provisioned state after updates complete
To INIT: Unprovision device completely (removes from SDA fabric and/or Inventory with config clearing)

State Transition Operations

Provisioning Operations

Provision non-fabric devices: Apply standard network configuration
Provision fabric devices: Apply SDA fabric configuration and assign fabric roles
Both operations move devices from INIT, ASSIGN or PNP states to PROVISION state

Unprovisioning Operations

Standard Unprovisioning: Removes device from Inventory management with configuration clearing
SDA Fabric Removal: Removes from both SDA fabric and Inventory with configuration clearing

Best Practices

State Management

Use ASSIGN state for devices requiring site-specific preparation
Use PNP state for zero-touch deployment scenarios
Monitor devices in REPROVISION state for completion

Operational Considerations

Devices in PROVISION state should be monitored for compliance
REPROVISION operations should be scheduled during maintenance windows
Use proper unprovisioning procedures to avoid configuration conflicts
Maintain device inventory accuracy across all states

Examples

Example-1: SD-Access Border Router Device Configuration

The border router device configuration includes:

Device name (BR01) for identification and inventory management
Management IP address (192.168.10.1) for device communication and monitoring
PROVISION state for active deployment and configuration management
Border router role designation for network function
Site assignment (Global/Canada) for geographic and organizational placement
Fabric site association (Global/Canada) for SD-Access fabric membership
Multiple fabric roles including BORDER_NODE for external connectivity and CONTROL_PLANE_NODE for fabric control plane operations

catalyst_center:
  inventory:
    devices:
      - name: BR01
        fqdn_name: BR01.company.local
        device_ip: 192.168.10.1
        state: PROVISION
        device_role: BORDER ROUTER
        site: Global/Canada
        fabric_site: Global/Canada
        fabric_roles:
          - BORDER_NODE
          - CONTROL_PLANE_NODE

Example-2: Access Switch with Edge Node Functionality

This example shows how to configure an access layer switch with SD-Access edge node capabilities for endpoint connectivity and policy enforcement at the network edge.

catalyst_center:
  inventory:
    devices:
      - name: ACCESS-SW01
        fqdn_name: ACCESS-SW01.company.local
        device_ip: 192.168.20.10
        serial_number: FOC2644021A
        pid: C9300-24P
        state: PROVISION
        device_role: ACCESS
        site: Global/North America/Campus/Building A/Floor 1
        fabric_site: Global/North America/Campus
        fabric_roles:
          - EDGE_NODE
        tags:
          - FLOOR1_DEVICES
          - EMPLOYEE_ACCESS

Example-3: Plug-n-Play Functionality

This example shows how to configure a device to be on-boarded into Catalyst Center inventory using plug and play.

catalyst_center:
  inventory:
    devices:
      - name: PNP_DEVICE
        fqdn_name: PNP_DEVICE.cisco.eu
        device_ip: 192.158.142.20
        serial_number: FAB12345602
        pid: C9300-48P
        state: PNP
        device_role: BORDER ROUTER
        site: Global/Poland/Krakow/Bld A
        onboarding_template:
          name: PNP_Template
          variables:
            - name: device_host_name
              value: PNP_DEVICE
            - name: infra_vlan
              value: "100"
            - name: infra_vlan_network_add
              value: 181.1.1.90
            - name: infra_vlan_network_mask
              value: 255.255.255.248
            - name: loopback_0_IP
              value: 192.158.142.20
            - name: loopback_0_mask
              value: 255.255.255.255
            - name: Border_AS
              value: "65005"
            - name: peer_BGP_neigbor
              value: 181.1.1.89
            - name: peer_AS
              value: "65002"
            - name: peer_interface
              value: GigabitEthernet1/0/1

After the plug and play process is completed, the device state can be updated to PROVISION to enable full management and configuration capabilities within Catalyst Center.

catalyst_center:
  inventory:
    devices:
      - name: PNP_DEVICE
        fqdn_name: PNP_DEVICE.cisco.eu
        device_ip: 192.158.142.20
        serial_number: FAB12345602
        pid: C9300-48P
        state: PROVISION
        device_role: BORDER ROUTER
        site: Global/Poland/Krakow/Bld A

Example-4: Access Point Plug-n-Play

This example shows how to configure an Access Point to be on-boarded into Catalyst Center inventory using plug and play.

Note : It is mandatory to provide the type as AccessPoint, rf_profile, and site in order to add and claim the device in Provision -> Plug and Play

catalyst_center:
  inventory:
    devices:
      - name: AP_PNP
        fqdn_name: AP_PNP.cisco.eu
        pid: C9136I-E
        serial_number: FGL3727MF6Y
        state: PNP
        type: AccessPoint
        rf_profile: TYPICAL
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A/FLOOR_2

After the plug and play process is completed, the Access Point can be updated to PROVISION to provision full management and configuration capabilities within Catalyst Center.

catalyst_center:
  inventory:
    devices:
      - name: AP_PNP
        fqdn_name: AP_PNP.cisco.eu
        pid: C9136I-E
        serial_number: FGL3727MF6Y
        state: PROVISION
        type: AccessPoint
        rf_profile: TYPICAL
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A/FLOOR_2

Example-5: Embedded Wireless Controller provisioning

This example demonstrates how to enable the fabric Embedded Wireless Controller (EWC) role within a fabric site

Note :

It is mandatory to provide the fabric_role as EMBEDDED_WIRELESS_CONTROLLER_NODE (in addition to the existing role(s) - EDGE, BORDER)
It is also required to populate the primary_managed_ap_locations field to specify the primary location(s) for managed access points (APs)

catalyst_center:
  inventory:
    devices:
      - name: P3-EN1
        fqdn_name: P3-EN1.cisco.eu
        device_ip: 192.168.30.24
        pid: C9300-24P
        state: PROVISION
        device_role: ACCESS
        site: Global/Poland/Krakow/Bld A
        fabric_site: Global/Poland/Krakow
        fabric_roles:
          - EDGE_NODE
          - EMBEDDED_WIRELESS_CONTROLLER_NODE
        primary_managed_ap_locations:
          - Global/Poland/Krakow/Bld A/FLOOR_2
          - Global/Poland/Krakow/Bld A/FLOOR_1

Device

Diagram

Classes

inventory (catalyst_center)

devices (catalyst_center.inventory)

stack (catalyst_center.inventory.devices)

onboarding_template (catalyst_center.inventory.devices)

dayn_templates (catalyst_center.inventory.devices)

port_assignments (catalyst_center.inventory.devices)

port_channels (catalyst_center.inventory.devices)

variables (catalyst_center.inventory.devices.onboarding_template)

regular (catalyst_center.inventory.devices.dayn_templates)

composite (catalyst_center.inventory.devices.dayn_templates)

variables (catalyst_center.inventory.devices.dayn_templates.composite)

Device Provisioning States and Lifecycle

Device States

INIT (Initial State)

PNP (Plug and Play)

ASSIGN

PROVISION

REPROVISION

State Transition Operations

Provisioning Operations

Unprovisioning Operations

Best Practices

State Management

Operational Considerations

Examples

Setting image_skip globally via defaults.yaml

Mandatory prerequisite: Embedded WLC image

Supported role combinations

Adding the EWC role to an Edge-only fabric device requires two Terraform applies

Removing the EWC role

Setting clean_up_config globally via defaults.yaml

Diagram

Classes

inventory (catalyst_center)

devices (catalyst_center.inventory)

stack (catalyst_center.inventory.devices)

onboarding_template (catalyst_center.inventory.devices)

dayn_templates (catalyst_center.inventory.devices)

port_assignments (catalyst_center.inventory.devices)

port_channels (catalyst_center.inventory.devices)

variables (catalyst_center.inventory.devices.onboarding_template)

regular (catalyst_center.inventory.devices.dayn_templates)

composite (catalyst_center.inventory.devices.dayn_templates)

variables (catalyst_center.inventory.devices.dayn_templates.composite)

Device Provisioning States and Lifecycle

Device States

INIT (Initial State)

PNP (Plug and Play)

ASSIGN

PROVISION

REPROVISION

State Transition Operations

Provisioning Operations

Unprovisioning Operations

Best Practices

State Management

Operational Considerations

Examples

Setting clean_up_config globally via defaults.yaml

Diagram

Classes

inventory (catalyst_center)

devices (catalyst_center.inventory)

onboarding_template (catalyst_center.inventory.devices)

dayn_templates (catalyst_center.inventory.devices)

port_assignments (catalyst_center.inventory.devices)

variables (catalyst_center.inventory.devices.onboarding_template)

regular (catalyst_center.inventory.devices.dayn_templates)

composite (catalyst_center.inventory.devices.dayn_templates)

variables (catalyst_center.inventory.devices.dayn_templates.composite)

Device Provisioning States and Lifecycle

Device States

INIT (Initial State)

PNP (Plug and Play)

ASSIGN

PROVISION

REPROVISION

Setting `image_skip` globally via `defaults.yaml`

Setting `clean_up_config` globally via `defaults.yaml`

Setting `clean_up_config` globally via `defaults.yaml`

Setting `clean_up_config` globally via `defaults.yaml`