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