> For the complete documentation index, see [llms.txt](https://docs.infraon.io/infraon-help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.infraon.io/infraon-help/infinity-user-guide/infraon-configuration/it-operations/network-configuration/ztp-configuration/ztp-process-flow.md).

# 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.

{% hint style="info" %}
This ensures audit control for changes made to live environments.
{% endhint %}

**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)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.infraon.io/infraon-help/infinity-user-guide/infraon-configuration/it-operations/network-configuration/ztp-configuration/ztp-process-flow.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.