ZTP Process Flow

There are multiple steps within ZTP. They are:

Pre-Requisites for ZTP

Before using ZTP in Infraon NCCM, ensure the following components are configured:

1. ZTP Configuration Profile

• Defines how NCCM will interpret syslog messages and which assets can initiate ZTP.

• Includes:

  • Regex-based Syslog Matching Patterns

  • IP Address and MAC Reference Key Patterns

  • Device Credential Assignment

  • Data Collector Agent

  • Optional Notifiers and API Integrations

2. Device Credentials

• Pre-created credential profiles with:

  • CLI Access (via SSH or Telnet)

  • SNMP read/write community strings for inventory and configuration tasks.

3. Templates and Runtime Parameters

• Configuration Templates contain reusable command structures with dynamic fields (e.g., ${hostname}, ${ip}).

• Runtime Parameters allow populating these fields dynamically per device via:

  • Manual Input

  • CSV Upload

  • External API Query

4. Role & Privilege Control

• Admins can directly submit jobs.

• Technicians may only “request” jobs, requiring approval.

• These controls are defined under Roles and Privileges in the platform.

5. Change Management & Approval Setup (if enabled)

• ZTP jobs can optionally go through CAB (Change Advisory Board) review.

• Approval logic, approver teams, and workflows must be preconfigured in the Change Management module.

Step-by-Step ZTP Workflow

Step 1: Device Power-On

• A field engineer physically installs the device and powers it on.

• No configuration or IP address exists yet on the device.

• The device must have a DHCP client enabled in its base firmware.

Step 2: DHCP Broadcast and DORA Handshake

What is DORA? A four-step process of IP assignment using DHCP:

1. Discover – Device broadcasts a request to find a DHCP server.

2. Offer – DHCP server offers an IP.

3. Request – Device confirms it wants the offered IP.

4. Acknowledge (ACK) – DHCP confirms the assignment.

• These steps are logged by the DHCP server and forwarded to the NCCM Agent for ZTP initiation.

Step 3: DHCP Syslog Reception & Pattern Matching

• Infraon NCCM Agent listens for logs from DHCP servers.

• Syslog messages are matched against patterns defined in ZTP Configuration:

  • .*DHCPDISCOVER.*, .*DHCPACK.* (to detect IP assignment)

  • MAC address pattern (([0-9A-Fa-f]{2}[:-]){5}([0-9A-Fa-f]{2}))

  • IP address pattern using regex.

• Once matched:

  • A ZTP event is triggered in NCCM.

  • This confirms that a new device has come online and can be provisioned.

Step 4: Event Creation & Device Discovery

• The system creates a structured Event Notification for the new device.

• Based on the ZTP config and privileges:

  • Device discovery is triggered using CLI (SSH/Telnet) or SNMP.

  • If discovery is successful:

    • NCCM retrieves device inventory like hostname, vendor, model, and firmware version.

Step 5: Template Assignment & Runtime Parameter Mapping

• Based on the device info or admin selection:

  • A Configuration Template is chosen.

• Runtime values (such as hostname, loopback IP, VLANs, etc.) are:

  • Entered manually through UI

  • Uploaded via CSV

  • Retrieved from an external system using registered APIs

Runtime Parameters must match the template's dynamic fields for successful substitution.

Step 6: ZTP Upload Job Creation

• A ZTP Upload Job is created to push configurations to the newly discovered device.

• The form displays two action buttons:

  • Submit – Directly sends the job for execution (requires proper privilege).

  • Request – Sends the job for approval via the Change Management process.

Whether Submit is available depends on the toggle: Upload Job Pre-Approval.

• ON → Submit and Request both visible

• OFF → Only Request is visible

Step 7: Change Management Approval Flow (if enabled)

When a job is requested (instead of submitted), it enters the Change Request lifecycle:

Approval Workflow:

1. Change Request Created: Automatically generated in the Change Management module.

2. Assigned to CAB Team: Approvers (defined under Teams) are notified.

3. CAB Members Vote:

   • Each team member gets the option to Approve or Reject.

   • Approval thresholds (e.g., 50% or 100%) are enforced.

4. On Approval:

   • The job status updates to Approved, and execution begins.

5. On Rejection:

   • Job status reflects Rejected, and no execution occurs.

This ensures audit control for changes made to live environments.

Step 8: Job Execution

Once approved (or directly submitted):

• NCCM uses the assigned device credentials to log in.

• Executes the commands as per the configuration template.

• Dynamic values are injected using runtime parameter mapping.

• Job status updates:

  • Success

  • Failed

  • Partially Completed (in case of CLI issues or device mismatch)

Step 9: Post-Execution Notifications

After successful execution:

• A notification is sent to:

  • Registered users (e.g., field engineer, support team)

  • API endpoints (e.g., ticketing system, monitoring tool)

Configured via:

• Notifier Email

• API Integration (using method, endpoint, headers, content type)