# ZTP Event Tracker

The **ZTP Event Tracker** provides a centralized view for monitoring and tracking **ZTP-related syslogs received from DHCP servers**. It helps administrators follow the complete lifecycle of a Zero Touch Provisioning (ZTP) event—from the moment a syslog is received through discovery, configuration download, and the creation of an upload job.

This module acts as a **traceability and troubleshooting layer** for ZTP, enabling users to identify where a syslog currently resides in the processing pipeline and quickly detect failures or duplicate events.

The ZTP Event Tracker is available only when:

* The **ZERO\_TOUCH\_PROVISIONING** license is enabled, and
* The **Infraon\_NCCM** feature flag is active.

## **How It Works**

1. A DHCP server sends a **ZTP-related syslog** to the Infraon Data Collector.
2. Syslog messages are ingested into **Kafka** and assigned a unique **Track ID**.
3. The syslog progresses through multiple internal processing stages:

* Event ingestion
* Trigger processing
* Discovery creation
* Download job handling
* Upload job creation

4. Each stage updates the **Status** of the syslog in real time.
5. If a failure occurs at any stage, the error is captured and displayed in the tracker.
6. On successful completion, the tracker confirms whether:

* A discovery job was completed, and
* A download/upload job was created or already existed.

This visibility allows administrators to **validate ZTP behavior**, **diagnose failures**, and **confirm automation outcomes** without switching across modules.

### **ZTP Processing Status**

As a syslog moves through the ZTP pipeline, the **Status** field is updated sequentially to reflect its current processing stage. Common statuses include:

ZTP Event **| State | Status**

<table><thead><tr><th width="183.4000244140625">Status</th><th width="133.20001220703125">State</th><th>Description</th></tr></thead><tbody><tr><td><strong>Received in Kafka</strong></td><td>Not Started</td><td>The ZTP syslog message is received from the DHCP server and successfully ingested into Kafka via the data collector. This is the initial state of ZTP event tracking.</td></tr><tr><td><strong>Sent To Event</strong></td><td>Not Started</td><td>The syslog event is forwarded from Kafka to the event consumer for further ZTP processing.</td></tr><tr><td><strong>Received In Trigger</strong></td><td>Not Started</td><td>The event consumer passes the syslog to the trigger service, where ZTP workflow validation begins.</td></tr><tr><td><strong>Sent To Discovery Celery</strong></td><td>Not Started</td><td>The trigger service sends the ZTP event to the discovery celery worker for device discovery processing.</td></tr><tr><td><strong>Processing Discovery Request</strong></td><td>In Progress</td><td>The discovery celery worker is actively processing the ZTP request to identify the device and validate discovery prerequisites.</td></tr><tr><td><strong>Discovery Configuration Added</strong></td><td>In Progress</td><td>The discovery configuration for the identified device is created or mapped during the ZTP workflow.</td></tr><tr><td><strong>Discovery Job Added</strong></td><td>In Progress</td><td>A discovery job is created and queued for execution on the agent for the detected device.</td></tr><tr><td><strong>Discovery Completed</strong></td><td>Completed</td><td>The discovery job execution is completed successfully, and the device is discovered as part of the ZTP process.</td></tr><tr><td><strong>Download Job Already Exist</strong></td><td>In Progress</td><td>A configuration or image download job already exists for the detected device, so no new job is created.</td></tr><tr><td><strong>Download Job Created</strong></td><td>In Progress</td><td>A new download job is created for the device during ZTP onboarding.</td></tr><tr><td><strong>Added Download Job To Agent</strong></td><td>In Progress</td><td>The download job is successfully assigned to the agent for execution on the device.</td></tr><tr><td><strong>Adding Upload Job</strong></td><td>In Progress</td><td>The system is creating an upload job to collect configuration or operational data from the device after discovery.</td></tr><tr><td><strong>Upload Job Created</strong></td><td>Completed</td><td>The upload job is successfully created and linked to the ZTP workflow.</td></tr><tr><td><strong>Upload Job Created</strong></td><td>Completed</td><td>The ZTP workflow completes after a successful upload job is created.</td></tr><tr><td><strong>Error (Hover Details)</strong></td><td>Error</td><td>If an error occurs at any stage of the ZTP workflow, an error icon is displayed. Hovering over the icon shows the available error details.</td></tr></tbody></table>

## **What You See on the Screen**

The **ZTP Event Tracker** page provides a single consolidated view to monitor, track, and control the lifecycle of ZTP syslog events received from DHCP servers.\*\*Syslog Events |\*\*Basic Details

<table><thead><tr><th width="149">Label</th><th width="86.20001220703125">Action</th><th>Description / Example</th></tr></thead><tbody><tr><td><strong>Search</strong></td><td>Filter</td><td>Allows users to filter ZTP events based on selected columns and conditions (in, not in, equal, not equal, contains).<strong>Fields:</strong> Track ID, Syslog, DHCP Server ID, Status, Device IP Address, Reference Key, and State.</td></tr><tr><td><strong>Track ID</strong></td><td>View</td><td>Unique identifier generated for each ZTP syslog event. Used to trace the full ZTP workflow across stages.<br><br><strong>Example:</strong> 257ea3f5b77c49b...</td></tr><tr><td><strong>Syslog</strong></td><td>View</td><td>Displays the raw syslog message received from the DHCP server, including DHCPACK details.<br><br><strong>Example:</strong> DHCPACK on 192.168.50.14 to bd:f8:f2:0d:c5:cf via 10.0.4.1</td></tr><tr><td><strong>Received Time</strong></td><td>View</td><td>Timestamp indicating when the syslog was received by the data collector.<br><br><strong>Example:</strong> Oct 30, 2025 03:42 PM</td></tr><tr><td><strong>DHCP Server IP</strong></td><td>View</td><td>IP address of the DHCP server from which the syslog was received.<br><br><strong>Example:</strong> 10.0.4.88</td></tr><tr><td><strong>Data Collector</strong></td><td>View</td><td>Shows the data collector (agent) that ingested the syslog event.<br><br><strong>Example:</strong> Test – 10.0.4.88</td></tr><tr><td><strong>State</strong></td><td>View</td><td>Represents the high-level execution state of the ZTP process.<br><br><strong>Example:</strong> Not Started, Completed</td></tr><tr><td><strong>Status</strong></td><td>View</td><td>Indicates the current processing stage of the ZTP workflow.<br><br><strong>Example:</strong> Sent To Event, Upload Job Created, Discovery Completed</td></tr><tr><td><strong>Device IP Address</strong></td><td>View</td><td>IP address assigned to the device through ZTP DHCP process.<br><br><strong>Example:</strong> 192.168.50.14</td></tr><tr><td>Reference Key</td><td>View</td><td>Device identifier (typically MAC address) used to correlate the ZTP event.<br><br><strong>Example:</strong> bd:f8:f2:0d:c5:cf</td></tr><tr><td>Last Update Time</td><td>View</td><td>Timestamp of the most recent status update for the ZTP event.<br><br><strong>Example:</strong> Oct 30, 2025 03:42 PM</td></tr><tr><td>Export</td><td>Action</td><td>Exports the ZTP Event Tracker data to an XLSX file for analysis or audit purposes.</td></tr><tr><td>Re-Initiate</td><td>Action</td><td>Re-triggers the ZTP process from the beginning for the selected event, subject to permissions and status conditions.<br><br><strong>Example:</strong> Restart ZTP when the process stops due to an error or exceeds the configured delta time.</td></tr></tbody></table>

### **ZTP Syslog Re-Trigger**

The **Re-Initiate** action allows authorized users to manually restart the ZTP workflow for a selected syslog event when reprocessing is required.

**Availability**

* Visible only to users with **Edit permission** for the ZTP license.
* Not available when the status is **Upload Job Created** or **Download Job Already Exist**.

**When It Is Enabled**

* The ZTP process stopped due to an error.
* The **Last Update Time** exceeds the configured delta interval (ZTP\_RE\_TRIGGER\_DELTA\_INTERVAL).
* The event is in an intermediate or failed state.

**Execution**

* Clicking **Re-Initiate** opens a confirmation dialog.
* On confirmation, the ZTP process restarts from the beginning.
* Each action is captured in the audit log.

#### **How It Works**

When a ZTP-related syslog is received, the system tracks its progress through each processing stage. If the workflow fails or becomes inactive beyond the configured threshold, the **Re-Initiate** option becomes available.

Triggering this action re-queues the event and restarts the ZTP process from the initial stage, enabling recovery without waiting for a new syslog.


---

# Agent Instructions: 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:

```
GET https://docs.infraon.io/infraon-help/infinity-user-guide/infraon-configuration/it-operations/network-configuration/ztp-event-tracker.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.