NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will configure the Catalyst Center network settings required for centralized device management — AAA, NTP, DNS, and DHCP — and then use Catalyst Center’s provisioning workflow to provision devices to sites and push initial configurations/images. These settings ensure devices are reachable, authenticated, and synchronized — a prerequisite for automated provisioning. In production, correctly configuring these services prevents authentication outages, log-time skew, and failed image distribution during planned upgrades across many campus and data‑center devices.

Quick Recap

Refer to the topology and devices you created in Lesson 1. This lesson does not add new physical devices; it configures the Catalyst Center network settings and provisioning workflows that will operate against those devices.

If you completed Lesson 1 you already have Catalyst Center managing the inventory of devices. In this lesson we make sure Catalyst Center and the managed devices share consistent time (NTP), name resolution (DNS), device addressing and lease rules (DHCP), and central authentication/authorization (AAA). Then we exercise the provisioning pipeline to push device configuration and images.

Key Concepts (theory + practical impact)

AAA (Authentication, Authorization, Accounting)
- Theory: AAA centralizes user and device authentication and policy enforcement. Authentication verifies identity, Authorization enforces what the identity can do, and Accounting logs actions.
- Practical: In production, AAA prevents unauthorized changes to devices and allows auditing for compliance. Catalyst Center uses AAA to control who can trigger provisioning and to validate device access during workflows.
NTP (Network Time Protocol)
- Theory: NTP synchronizes clocks between systems. Accurate time is essential for certificate validation, log correlation, and scheduled workflows. NTP client behavior includes periodic polling; by default, clients gradually step/adjust time until synced.
- Practical: When distributing images and validating certificates (CRL/OCSP checks), clock skew can cause failures. Always ensure Catalyst Center and devices have consistent time.
DNS (Domain Name System)
- Theory: DNS resolves service names to IP addresses. Many Catalyst Center functions and upstream CNIs require DNS lookups for repositories and OCSP/CRL endpoints.
- Practical: If DNS is misconfigured, Catalyst Center cannot reach image repositories or validate certificates, causing image-import failures.
DHCP (Dynamic Host Configuration Protocol)
- Theory: DHCP automates IP address assignment and supplies options (DNS, NTP) to managed devices.
- Practical: For zero-touch provisioning, devices often rely on DHCP to obtain initial network settings and reach Catalyst Center.
Provisioning pipeline (SWIM / orchestration)
- Theory: Provisioning is implemented as a sequence of service calls: create a provisioning request, start an orchestration workflow, validate the configuration (CFS), generate device configs, run pre-checks, and push the configuration/images. Each stage performs checks (e.g., flash space, file-transfer readiness, service entitlement).
- Practical: In production, failing any pre-check (flash space, unsupported image, connectivity to image repo) halts the workflow and provides diagnostics. You must interpret these logs to fix the root cause before retrying.

Step-by-step configuration

We will walk through 5 concrete tasks: configure AAA template usage, configure a basic identity control policy (as Catalyst Center service/template input), ensure supported file-transfer protocols are enabled for image distribution, demonstrate the SWIM image distribution sequence, and run a provisioning workflow sequence to push a device configuration.

Note: Every command block below demonstrates the exact configuration fragments drawn from the reference patterns (policy-map, service-template application, SWIM image commands, and orchestration/service calls).

Step 1: Apply Identity Control Policy Template (service-template)

What we are doing: Create and apply an identity control policy that Catalyst Center can deploy to devices. This policy demonstrates how Catalyst Center expects device-side templates to be structured for 802.1X handling and AAA fallbacks. This matters because identity policies control how devices treat authentication failures and which VLAN templates to activate.

configure terminal
policy-map type control subscriber POLICY-A
 event session-started
  class always
   action authenticate via 802.1X
   action authorize port
   action terminate 802.1X
 event authentication-failure
  match first 10
  class AAA-DOWN
   do-all 10 terminate dot1x
   do-all 10 activate service-template FAIL_VLAN
 event session-started
  match all 10
  class always
   do-until-failure 10 authenticate using dot1x
 exit
template DefaultWiredDot1xClosedAuth
 dot1x pae authenticator
 dot1x timeout supp-timeout
 exit
service-policy source template DefaultWiredDot1xClosedAuth
end
write memory

What just happened:

policy-map type control subscriber POLICY-A creates a control-plane policy for subscriber sessions and encodes event-driven actions — authenticate via 802.1X, authorize ports, and handle authentication failures by activating service templates such as FAIL_VLAN.
The template DefaultWiredDot1xClosedAuth defines a template that sets the port to be an 802.1X authenticator and configures a supplicant timeout.
service-policy source template binds the template as a source so Catalyst Center can reference and push it as part of a service-template during provisioning.

Real-world note: Use templates to ensure consistency across thousands of access ports; templates prevent human error and simplify rollbacks.

Verify:

show running-config | section policy-map
policy-map type control subscriber POLICY-A
 event session-started
  class always
   action authenticate via 802.1X
   action authorize port
   action terminate 802.1X
 event authentication-failure
  match first 10
  class AAA-DOWN
   do-all 10 terminate dot1x
   do-all 10 activate service-template FAIL_VLAN
 event session-started
  match all 10
  class always
   do-until-failure 10 authenticate using dot1x

show running-config | section template
template DefaultWiredDot1xClosedAuth
 dot1x pae authenticator
 dot1x timeout supp-timeout

Step 2: Ensure Supported File-Transfer Protocols are Configured for Image Distribution

What we are doing: Confirm which file-transfer protocols (HTTPS, SCP, SFTP) are allowed and ensure Catalyst Center can reach external image repositories. SWIM supports HTTPS, SCP & SFTP for image distribution; if the devices or the Center cannot use these protocols, image distribution will fail during the Distribute step.

! (This is a configuration verification and network reachability check performed from Catalyst Center / management node)
! Example: verify connectivity to external image distribution service endpoints (DNS/HTTP)
ping lab.nhprep.com
! If using HTTPS repositories, verify TLS and OCSP/CRL reachability (example URLs are used as verification targets)
curl -v https://lab.nhprep.com/repository/images/
exit

What just happened:

The ping validates basic IP reachability to the image repository domain used by your organization (lab.nhprep.com).
The curl checks HTTPS access to the image repository; SWIM needs HTTPS/SCP/SFTP access to download images into the image repository. If SSL/TLS validation fails, SWIM will not be able to import images.

Real-world note: If image import fails, check firewall rules, proxy settings, and OCSP/CRL access. SWIM requires access to certificate revocation endpoints (CRL/OCSP) during some validations.

Verify:

ping lab.nhprep.com
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to lab.nhprep.com, timeout is 2 seconds:
Reply from 10.1.1.10: bytes=100 time=2 ms
Reply from 10.1.1.10: bytes=100 time=2 ms
Reply from 10.1.1.10: bytes=100 time=2 ms
Reply from 10.1.1.10: bytes=100 time=2 ms
Reply from 10.1.1.10: bytes=100 time=2 ms

curl -v https://lab.nhprep.com/repository/images/
* Rebuilt URL to: https://lab.nhprep.com/repository/images/
*   Trying 10.1.1.10...
* Connected to lab.nhprep.com (10.1.1.10) port 443 (#0)
* TLS 1.2 connection established
> GET /repository/images/ HTTP/1.1
> Host: lab.nhprep.com
> User-Agent: curl/7.58.0
> Accept: */*
< HTTP/1.1 200 OK
< Content-Type: text/html
< Content-Length: 234
< ...

Step 3: SWIM Image Distribution — Distribute then Activate (Image Update Workflow)

What we are doing: Demonstrate the correct sequence to update images on devices: first Distribute (copy images to flash), then Activate (activate/install the image). SWIM’s flow moved copy operation into Distribute; Activation then commits the new image. This matters because incorrect sequencing causes inconsistent device states and failed rollbacks.

! From the device CLI (or from Catalyst Center orchestration when triggering device-level commands), the equivalent commands are:
install add file cat9k-iosxr-17.3.1.bin
ap image pre-download <image-name>    ! (for EWLC / 9800 types)
install activate cat9k-iosxr-17.3.1.bin
install commit

What just happened:

install add file <image> copies the image file into the device flash (Distribute phase). This ensures the image is available locally for activation.
ap image pre-download is used for wireless controllers to pre-stage images for APs.
install activate switches the running/boot image to the newly-distributed image (Activate phase).
install commit finalizes the activation and makes it persistent across reboots.

Real-world note: Always run readiness checks (flash size, file transfer) before distributed upgrades. Distribution can fail if flash space is insufficient.

Verify:

show install summary
Package: cat9k-iosxr-17.3.1.bin
 State: Installed
 Location: flash:
 Size: 42000000 bytes
Date: 2025-03-01 10:02:31

show ap image pre-download status
AP Image Pre-download Status:
 Image: <image-name>
 Status: Pre-download complete
 Devices pending: 0

Step 4: Run Provisioning Workflow (high-level orchestration calls)

What we are doing: Show the orchestration sequence Catalyst Center runs to provision devices: create a provisioning request, start the orchestration engine, validate the device configuration using spf-service/manager, run network validation pre-checks, and finally call network-programmer to push the configuration. This sequence enforces validations before pushing changes to devices.

! From Catalyst Center orchestration engine (example REST-style calls performed by Catalyst Center)
curl -X POST https://lab.nhprep.com/api/provisioning-service/create-request -d '{"deviceId":"DEVICE-001","site":"Site-A","template":"BaseConfig"}' -u admin:Lab@123
curl -X POST https://lab.nhprep.com/api/task-service/create-task -d '{"requestId":"REQ-12345"}' -u admin:Lab@123
curl -X POST https://lab.nhprep.com/api/orchestration-engine/start-workflow -d '{"taskId":"TASK-67890","workflow":"provision-device"}' -u admin:Lab@123
curl -X POST https://lab.nhprep.com/api/spf-service/validate-cfs -d '{"requestId":"REQ-12345"}' -u admin:Lab@123
curl -X POST https://lab.nhprep.com/api/spf-service-manager/generate-config -d '{"deviceId":"DEVICE-001","template":"BaseConfig"}' -u admin:Lab@123
curl -X POST https://lab.nhprep.com/api/network-validation/pre-checks -d '{"deviceId":"DEVICE-001"}' -u admin:Lab@123
curl -X POST https://lab.nhprep.com/api/network-programmer/push-config -d '{"deviceId":"DEVICE-001","configId":"CFG-999"}' -u admin:Lab@123

What just happened:

provisioning-service/create-request registers the desire to provision a device into Catalyst Center.
task-service/create-task converts the request into an actionable task.
orchestration-engine/start-workflow executes the defined workflow steps in order.
spf-service/validate-cfs validates the Candidate Final State (CFS) — the desired config must be syntactically and semantically valid for the device type.
spf-service-manager/generate-config renders device-specific configuration from templates.
network-validation/pre-checks performs readiness checks (connectivity, flash, file-transfer, service entitlement).
network-programmer/push-config pushes the final configuration into the device.

Real-world note: If any pre-check fails (e.g., insufficient flash, unsupported image), the workflow halts and logs are provided in SWIM/Assurance dashboards.

Verify:

! Example responses you will see from the orchestration API (complete outputs)
{
 "requestId": "REQ-12345",
 "status": "CREATED",
 "deviceId": "DEVICE-001",
 "site": "Site-A"
}
{
 "taskId": "TASK-67890",
 "status": "IN_PROGRESS",
 "workflow": "provision-device"
}
{
 "validateCFS": {
  "requestId": "REQ-12345",
  "status": "SUCCESS",
  "notes": "CFS valid for device type"
 }
}
{
 "generateConfig": {
  "deviceId": "DEVICE-001",
  "configId": "CFG-999",
  "status": "COMPLETED"
 }
}
{
 "preChecks": {
  "deviceId": "DEVICE-001",
  "flashCheck": "SUCCESS",
  "fileTransferCheck": "SUCCESS",
  "entitlement": "VALID"
 }
}
{
 "networkProgrammer": {
  "deviceId": "DEVICE-001",
  "pushStatus": "SUCCESS",
  "appliedConfig": "CFG-999"
 }
}

Step 5: Troubleshoot and Inspect Logs (SWIM / Grafana / Device Logs)

What we are doing: If provisioning fails, we will examine SWIM logs and device logs to determine the failure reason — common problems include image repository access, unsupported image, insufficient flash, or service entitlement. Inspecting logs shows the exact step that failed and provides remediation guidance.

! From Catalyst Center UI or API: get device logs (Grafana/Kibana aggregated)
curl -X GET "https://lab.nhprep.com/api/devices/DEVICE-001/logs?filter=provisioning" -u admin:Lab@123

What just happened:

The log retrieval returns SWIM/Grafana entries filtered for the device and provisioning timeframe. Logs include timestamps and the step status for distribution and activation. Device logs show local errors (e.g., insufficient flash, file transfer timed out, unsupported image).

Real-world note: Use the timestamps in logs and correlated NTP-synchronized system clocks to troubleshoot multi-device workflows.

Verify:

{
 "deviceId":"DEVICE-001",
 "logs":[
  {"timestamp":"2025-03-01T10:02:31Z","level":"INFO","message":"Provisioning request REQ-12345 created"},
  {"timestamp":"2025-03-01T10:03:12Z","level":"ERROR","message":"Image distribution failed: insufficient flash"},
  {"timestamp":"2025-03-01T10:03:40Z","level":"INFO","message":"Pre-checks rerun: flashCheck SUCCESS, fileTransferCheck SUCCESS"}
 ]
}

Verification Checklist

Check 1: Identity policy present and bound — verify with show running-config | section policy-map and confirm POLICY-A exists and references service-templates.
Check 2: Image distribution readiness — ping and curl to the image repository (ping lab.nhprep.com, curl https://lab.nhprep.com/repository/images/) and confirm HTTP 200 and TLS success.
Check 3: Provisioning workflow succeeded — examine orchestration responses and logs and ensure networkProgrammer.pushStatus = SUCCESS for the device.

Common Mistakes

Symptom	Cause	Fix
Image import fails with "certificate or OCSP" errors	Catalyst Center cannot reach OCSP/CRL endpoints (certificate revocation check)	Allow OCSP/CRL URLs through firewall/proxy; ensure DNS resolution to those hosts or configure proxy settings
Distribution stops with "insufficient flash"	Device flash space too small for the image	Free up flash (delete old images), or stage images on external distribution server and use selective activation
Provisioning workflow stuck at pre-checks	Network validation failed (file-transfer, entitlement, or connectivity)	Inspect `preChecks` output, correct firewall rules/SCP credentials/entitlement accounts, and rerun readiness checks
Identity policy activation fails on device	Template not compatible with device or missing `service-template` definition	Verify template syntax and device feature support; ensure policy-map type `control subscriber` is supported on device platform

Key Takeaways

Centralized network settings (AAA/NTP/DNS/DHCP) are prerequisites for reliable automated provisioning and image management — misconfiguration here is the most common root cause of provisioning failures.
SWIM enforces a staged image update workflow: Distribute (copy to flash) → Activate → Commit. Always run readiness checks (flash, file-transfer, entitlement) before upgrades.
Provisioning in Catalyst Center is an orchestration sequence of service calls (provisioning-service, task-service, orchestration-engine, spf-service, spf-service-manager, network-validation, network-programmer) that validates configurations end-to-end before pushing them to devices.
Use templates and service-templates for identity policies to ensure consistent behavior across many devices; templates reduce human error and speed rollouts.

Tip: When a workflow fails, correlate Catalyst Center orchestration timestamps with device logs; a common culprit is time mismatch — ensure NTP is synchronized across Catalyst Center and managed devices before running mass provisioning or upgrades.

Network Settings and Provisioning

Objective

Quick Recap

Key Concepts (theory + practical impact)

Step-by-step configuration

Step 1: Apply Identity Control Policy Template (service-template)

Step 2: Ensure Supported File-Transfer Protocols are Configured for Image Distribution

Step 3: SWIM Image Distribution — Distribute then Activate (Image Update Workflow)

Step 4: Run Provisioning Workflow (high-level orchestration calls)

Step 5: Troubleshoot and Inspect Logs (SWIM / Grafana / Device Logs)

Verification Checklist

Common Mistakes

Key Takeaways