Cisco Crosswork Network Controller 7.2.x Administration Guide

PDF

Cisco Crosswork Network Controller 7.2.x Administration Guide

Collection jobs in Crosswork Data Gateway

Updated: August 14, 2026

Want to summarize with AI?

Log in

Introduces collection jobs in Crosswork Data Gateway, including their role in application-driven data gathering, supported protocols, internal and external data collection requests, and how bulk and parameterized jobs are displayed in the Crosswork Network Controller UI.

A collection job is a data collection operation that Crosswork Data Gateway executes in response to application requests. A collection job:

  • enables applications to initiate data gathering from network devices

  • is assigned and managed by Cisco Crosswork to a Data Gateway, and

  • supports transmission using protocols such as CLI, MDT, SNMP, gNMI, and syslog.

The Data Gateway can collect any type of data as long as it is compatible with the supported protocols.

Types of collection jobs handled by Crosswork

Cisco Crosswork handles two types of data collection requests:

  • Internal processes: These requests forward data for internal operations within Cisco Crosswork. Cisco Crosswork creates system jobs for this purpose.

    • If you want the Data Gateway to gather specific information from non-Cisco devices, you must use custom device packages.

    • For more information on custom device packages, see Types of custom packages.

    • To learn how to build a model for Cisco Crosswork to communicate with non-Cisco devices, see Cisco DevNet.

  • External data destinations: These requests forward collected data to external endpoints, such as Kafka, gRPC, or Cisco Crosswork Health Insights.

Collection jobs in Crosswork Network Controller UI

On the Collection Jobs page in the Crosswork Network Controller UI, you can view active collection jobs and operational context.

The left pane on the Collection Jobs page includes two tabs:

  • Bulk jobs: Lists collection jobs created by the system, UI, or API.

  • Parameterized jobs: Displays active collection jobs dynamically initiated by the Crosswork Network Controller and tied to specific monitoring use cases:

    • Default jobs: Created automatically for reachability checks.

    • Policy-driven jobs: Generated when Performance Policies are applied.

    • Service-based jobs: Created as a result of enabling basic or advanced service health monitoring.

Deprecation of MDT-based data collection

Crosswork Network Controller is deprecating support for Model-Driven Telemetry (MDT) based data collection. While the MDT configuration options remain visible in the GUI for backward compatibility during the transition period, MDT collection is no longer actively supported and should not be used for new deployments.

You should migrate to gNMI for all telemetry data collection needs. The gNMI protocol provides enhanced capabilities, a richer feature set, simplified architecture, improved integration with modern network automation workflows, and ongoing support from Cisco.

Create, delete, and monitor collection jobs

In Cisco Crosswork, collection jobs describe data collection tasks that the Data Gateway performs. Use cases for creating, deleting, and monitoring collection jobs involve the following:

  • Gathering device configuration, interface traffic counters, and operational metrics for network monitoring and analytics. See Create a collection job from Crosswork UI.

  • When collection jobs are no longer needed, such as outdated data requirements or device decommissioning, or when you want to clean up unused or redundant jobs after a data collection cycle is complete or after testing. See Delete collection job.

  • Verify the status of collection jobs and ensure that data is collected successfully from target devices.

Create a collection job from Crosswork UI

Configure a new collection job to gather data from network devices via the Cisco Crosswork UI.

Use this task to automate data collection from targeted network devices. You can use CLI or SNMP protocols, and the results are deposited in a specified data destination.

Before you begin

  • Ensure that a data destination is created and active to deposit the collected data.

  • Gather details of the sensor path and MIB that you plan to collect data from.

  • Collection jobs created through the Data Gateway UI page can only be published once.

  • For CLI data collection, ensure that devices do not have a banner configuration. See the device documentation on how to turn this off.

Procedure

1.

Go to Administration > Collection Jobs > Bulk jobs.
2.

In the left pane, click Add icon.
3.

On the New Collection Job page, enter the details:

Figure 1. New collection
Job Details Window

  1. Application Id: Enter a unique identifier for the application.

  2. Context Id: Enter a unique identifier for your application subscription across all collection jobs.

  3. Collector type: Select the type of collection (CLI or SNMP).

  4. Click Next.
4.

Select the devices from which data is to be collected.

Figure 2. Select devices
Select Devices Window

  1. Select devices based on device tag or manually.

  2. Click Next.
5.

Enter the sensor details. The parameters differ for CLI path, SNMP, and device package. See Parameters for configuring sensor path.

Figure 3. Sensor details for CLI path
Sensor Details Window
Figure 4. Add CLI path
Add CLI Path Dialog Box
Figure 5. Add device package sensor
Add Device Package Sensor Dialog Box
Figure 6. Sensor details for SNMP path
Sensor Details Window
Figure 7. Add SNMP MIB
Add SNMP MIB Dialog Box
6.

Click Create Collection Job.

Note

If you submit a collection job to an external Kafka destination using unsecured Kafka, the dispatch to Kafka will fail to connect. Collector logs will show a timeout exception, and Kafka logs will display an SSL authentication error. This issue occurs because the port on the external Kafka VM is blocked. The error seen in collector logs is org.apache.kafka.common.errors.TimeoutException: Topic cli-job-kafka-unsecure not present in metadata after 60000 ms. In Kafka logs, the error is seen is SSL authentication error "[2021-01-08 22:17:03,049] INFO [SocketServer brokerId=0] Failed authentication with /80.80.80.108 (SSL handshake failed) (org.apache.kafka.common.network.Selector).

This happens because the port is blocked on an external Kafka VM. To check if the port is listening on Kafka docker/server port, use netstat -tulpn.

Fix the problem on the Kafka server and restart the Kafka server process.

Recommendations for data collection

Best practice for setting data collection cadence

When configuring data collection cadence:

  • Set the cadence to a minimum of 60 milliseconds.The valid range for configuring cadence is between 10 milliseconds and 604,800,000 milliseconds.

  • Consider both the frequency with which device data changes and the operational significance of that data.

  • Use a longer intervals (higher cadence) for relatively stable information, such as memory consumption or CPU utilization.

  • Use a shorter cadence for more volatile or dynamic data points.

  • If a Data Gateway is set to collect large volumes of telemetry or extensive datasets with a short cadence, this will increase the load on both the devices and the Crosswork Network Controller. Because it is challenging to model these loads precisely, experiment to identify settings that provide the best operational insight and, most importantly, actionable information.

Handling skipped collection attempts

If a collection attempt is skipped because the previous execution is ongoing, Crosswork Data Gateway logs a warning without an alert. This avoids overlapping collection jobs while maintaining operational efficiency.

Parameters for configuring sensor path

This section describes the parameters that you must provide for configuring the sensor paths.
Table 1. Sensor details required for adding the CLI and SNMP collection

Parameter

Description

Collection cadence

Push or poll cadence in seconds.

Device package name

Custom device package ID used while creating the device package.

Function name

Function name within a custom XDE device package.

Operation

Select the operation from the list.

OID

Specifies the SNMP Object Identifier used in sensor paths for polling specific metrics from network devices.

Command

CLI command

Topic

Topic associated with the output destination. Topic can be any string if using an external gRPC server.

Delete collection job

System jobs (default jobs created by various Crosswork Applications) should not be deleted as it causes collection issues. Jobs created by Health Insights should only be deleted by disabling the KPI profile which will remove the collection jobs it deployed. When you delete a collection job, it deletes the associated collection tasks.

Use this procedure to delete external collection jobs from the Collection Jobs page. Follow the steps to delete a collection job:

Procedure

1.

From the main menu, go to Administration > Collection Jobs.
2.

Select either the Bulk Jobs tab or Parametrized Jobs tab.
3.

In the Collection Jobs pane on the left-hand side, select the collection job that you want to delete.
4.

In the corresponding row, click More icon and select Delete. The Delete Collection Job window is displayed.
5.

Click Delete when prompted for confirmation.

Monitor the collection jobs

Monitor the status of active collection jobs on Crosswork Data Gateway instances enrolled with Crosswork Network Controller by using the Collection Jobs page.

Before you begin

When monitoring collection jobs, be aware of these important status behaviors and conditions that affect task visibility and job health:

  • The status of a collection task is initially reported as Unknown after a device attaches to a Crosswork Data Gateway due to pending data collection or reporting delays.

  • Reasons for Unknown status include

    • unreported status by the Data Gateway

    • loss of connection between Data Gateway and Crosswork,

    • pending telemetry collection, such as traps not being sent to the Data Gateway southbound interface or the device not sending telemetry updates.

    • lack of triggered SNMP trap conditions. For example, if you are looking for Link Up or Link down transitions and the link state has not changed since the collector was established, then the state will report as Unknown. To validate that trap-based collections are working it is therefore necessary to actually trigger the trap.

  • Collection jobs change to Successful when data is processed without errors, or Failed otherwise.

  • A degraded collection job may indicate missing static routes to the device or misconfigured KPI job mappings to standard instead of extended Data Gateway instances.

  • Data collections continue even if a destination is in an Error state, but error counts increment and require log review and troubleshooting.

  • Address NSO-related job creation failures by resolving NSO errors and resetting device administrative states to restart collection properly.

Use these steps to view and understand the collection job details.

Procedure

1.

From the main menu, choose Administration > Collection Jobs.

This left pane lists all active collection jobs along with their Status, App ID, Context ID, and Actions. The Actions drop-down lets you remove collection jobs. You can also refresh the status of a collection job and its associated tasks.
2.

Select a job in the Collection Jobs pane.

The Job Details pane displays the application name and context associated with the collection job, status of the collection job, and other job-related details.

Job details pane

Selecting a job displays detailed information on all collection tasks associated with that job. The details are:

  • The Application name and context associated with the collection job.

  • The collection job status.

  • The device hostname and unique device ID.

  • The sensor data paths and destination information are displayed.

  • Job configuration of the collection job that you pass in the REST API request. To view the job configuration, Click icon next to Config Details. Data Gateway lets you view configuration in two modes:

    • View Mode

    • Text Mode

  • The collection type is displayed.

  • The time and date when the collection job was last modified.

  • Collections (x): x refers to requested input collections that span device by sensor paths. The corresponding (y) Issues is the count of input collections that are in UNKNOWN or FAILED state.

  • Distributions (x): x refers to requested output collections that span device by sensor paths. (y) Issues is the count of output collections in UNKNOWN or FAILED state.

Data Gateway also displays these details for collections and distributions:

Field

Description

Collection/Distribution Status

Split into multiple cells if describing a process and providing an instruction, otherwise clarify the instructions and context. Click next to the collection/distribution status for details.

Hostname

Device hostname with which the collection job is associated.

Device Id

A unique identifier for the device from which data is collected.

Sensor Data

Sensor path

Click to see collection/distribution summary. From the sensor data summary pop up you can copy the sensor data by clicking Copy to Clipboard.

Click to see collection/distribution metrics summary. The metrics are reported on cadence-basis i.e., once every 10 minutes by default. The metrics available for a collection are:

  • last_collection_time_msec

  • total_collection_message_count

  • last_device_latency_msec

  • last_collection_cadence_msec

It shows the following metrics for a collection:

  • total_output_message_count

  • last_destination_latency_msec

  • last_output_cadence_msec

  • last_output_time_msec

  • total_output_bytes_count

Destination

Data destination for the job.

Last Status Change Reported Time

Time and date on which last status change was reported for that device sensor pair from Data Gateway.

Collection job status explanations and error handling

Event-based collection jobs

The status of event-based collection jobs in Crosswork Data Gateway reflects the current data collection state and device connectivity with the system.

  • When data collection completes successfully, the collection job status changes from Unknown to Success in the Collection Jobs pane.

  • When a device is detached from the Crosswork Data Gateway, all associated collection jobs are automatically deleted. The job status displays as Success in the Collection Jobs pane, but no devices or collection tasks appear in the Job Details pane.

  • When a device is newly attached to a Crosswork Data Gateway, a new collection job is created with the initial status Unknown. The status automatically updates to Success once event data is received from the device.

  • If a device configuration is modified incorrectly after it has already been attached and the Crosswork Data Gateway has received both the job and event data, the collection task status remains unchanged in the Job Details pane.

  • If the device inventory is updated with an incorrect device IP address, the collection task status is displayed as Unknown in the Job Details pane.

Handling errors and failures

A Create Failed error indicates that one or more devices failed to complete the setup process out of the total number of devices (N). Data collection continues for the devices that were successfully set up.

You can identify the devices causing the setup failure using the Control Status API.

  • Resolving NSO errors: If job creation fails on a device due to NSO (Network Services Orchestrator) errors, follow these steps after fixing the NSO configuration:

    1. Manually change the device’s administrative state to Down.

    2. Change it back to Up.

      Note

      This action resets the data collection process on the device.

  • Viewing and resolving other job errors

    • Errors that occur during job creation or deletion are displayed in a separate pop-up window.

      To view the details, click the information icon next to the job status.

    • If necessary, recreate the job by sending a PUT Collection Job API request with the identical payload.

CLI collection jobs

CLI Collection Jobs are a method supported by Crosswork Data Gateway to collect CLI-based data from network devices. These jobs use specific commands to retrieve operational data. They diagnose network issues and gather directory information from the device. The commands supported include:

  • show (and its short version sh)

  • traceroute

  • dir

CLI collection API payload example

This section provides a sample payload for the CLI Collection API, illustrating its structure and key elements.

In this example, Crosswork sends device data to an external Kafka destination. The Device Lifecycle Manager assigns a UUID for identification. This UUID uniquely identifies each device. The device is identified with a UUID rather than an IP address. The destination is also referenced by a UUID. Cisco Crosswork looks up the UUIDs for collection jobs built using the UI. If you create your own collection jobs, you must look up these values yourself.

{
  "collection_job": {
    "application_context": {
      "context_id": "collection-job1",
      "application_id": "APP1"
    },
    "collection_mode": {
      "lifetime_type": "APPLICATION_MANAGED",
      "collector_type": "CLI_COLLECTOR"
    },
    "job_device_set": {
      "device_set": {
        "devices": {
          "device_ids": [
            "658adb03-cc61-448d-972f-4fcec32cbfe8"
          ]
        }
      }
    },
    "sensor_input_configs": [
      {
        "sensor_data": {
          "cli_sensor": {
            "command": "show platform"
          }
        },
        "cadence_in_millisec": "60000"
      }
    ],
    "sensor_output_configs": [
     {
        "sensor_data": {
          "cli_sensor": {
            "command": "show platform"
          }
        },
        "destination": {
          "destination_id": "1e71f2fb-ea65-4242-8efa-e33cec71b369",
          "context_id": "topic1"
        }
      }
    ]
  }
}

Steps to create a CLI collection job

You can create a CLI collection job using the Cisco Crosswork UI or APIs.. For information on creating a job from the UI, see Create a Collection Job from Cisco Crosswork UI and from the API, see Cisco Devnet.

SNMP collection jobs

An SNMP collection job is a task configured on the Cisco Crosswork Data Gateway that directs the system to collect device data using SNMP protocol. It is a type of collection job that:

  • Polls devices based on their supported MIB and associated Object Identifiers (OIDs) to retrieve specific data

  • Can be configured to collect multiple types of SNMP data, such as scalar values or tables, across multiple devices, and

  • Executes the collection requests and stores or forwards the retrieved data to designated external data destinations for further processing or analysis.

SNMP collection methods

You can configure SNMP data collection in two primary ways:

  • MIB-based polling: Data is collected based on MIB and OID definitions supported by the device through polling operations.

  • Trap-based listening: The collector listens for incoming SNMP traps to collect event-driven data.

SNMP polling and trap-based listening

Many common device attributes can be collected using standard MIBs, which are included with Cisco Crosswork. However, if a device uses custom or vendor-specific MIBs, you may need to upload a custom MIB package tailored for that device. For information about the packages, see Types of custom packages.

Crosswork Data Gateway supports these SNMP versions for polling and traps:

Table 2. Supported SNMP versions

Purpose

Supported versions

Polling data

  • SNMPv2

  • SNMPv3 (no auth nopriv, auth no priv, authpriv)

  • Supported auth protocols: HMAC_MD5, HMAC_SHA, HMAC_SHA2-512, HMAC_SHA2_384, HMAC_SHA2_256, and HMAC_SHA2_224

  • Supported priv protocols: AES-128, AES-192, AES-256, CiscoAES192, CiscoAES256, DES, and 3-DES

Traps

  • SNMPv2

  • SNMPv3 (no auth nopriv, auth no priv, authpriv)

Device configuration sample commands

The table lists sample commands to enable various SNMP functions. For more information, refer to the platform-specific documentation.

Table 3. Sample configuration to enable SNMP on a device

Version

Command

To...

V2c

snmp-server group <group_name> v2c

snmp-server user <user_name> <group_name> v2c

Define the SNMP version, user/user group details.

snmp-server host <host_ip> traps SNMP version <community_string> udp-port 1062

snmp-server host a.b.c.d traps version 2c v2test udp-port 1062

Define the destination to which trap data must be forwarded.

Note

The IP address mentioned here must be the virtual IP address of the Crosswork Data Gateway.

snmp-server traps snmp linkup

snmp-server traps snmp linkdown

Enable traps to notify link status.

V3

Note

Password for a SNMPv3 user must be at least 8 bytes.

snmp-server host <host_IP> traps version 3 priv <user_name> udp-port 1062

Define the destination to which trap data must be forwarded.

Note

The IP address mentioned here must be the virtual IP address of the Crosswork Data Gateway.

snmp-server user <user_name> <group_name> v3 auth md5 <password> priv aes 128 <password>

Configures the SNMP server group to enable authentication for members of a specified named access list.

snmp-server view <user_name> < MIB > included

Define what must be reported.

snmp-server group <group_name> v3 auth notify <user_name> read <user_name> write <user_name>

Define the SNMP version, user/user group details.

snmp-server enable traps snmp [authentication ] [linkup ] [linkdown ] [warmstart ] [coldstart ]

  • When used without any of the optional keywords, enables authenticationFailure, linkUp, linkDown, warmStart, and coldStart traps.

  • When used with keywords, enables only the trap types specified. For example, to globally enable only linkUp and linkDown SNMP traps for all interfaces, use the snmp-server enable traps snmp linkup linkdown form of this command.
Note

  • SNMPv3 user passwords must be at least 8 bytes.

  • The IP address in trap commands should be the virtual IP address of the Crosswork Data Gateway.

SNMP collection job operations

The SNMP Collector supports several SNMP operations defined in the sensor configuration:

  • SCALAR: Retrieves single data points. Multiple scalar OIDs can be retrieved efficiently using a single GETBULK (getbulkrequestquery) request.

  • TABLE, WALK, COLUMN: Retrieve tabular and structured data as specified. For TABLE operation, either provide a Table OID or a Column OID.

Note
The optional device parameter snmpRequestTimeoutMillis should be set if the device’s response time exceeds 1500 milliseconds. Use it only when you are sure the device responds slowly. Specify the value in milliseconds, with a default and minimum of 1500 ms. There is no maximum limit for this value.

SNMP collection job example

{
  "collection_job": {
    "application_context": {
      "context_id": "collection-job1",
      "application_id": "APP1"
    },
    "collection_mode": {
      "lifetime_type": "APPLICATION_MANAGED",
      "collector_type": "SNMP_COLLECTOR"
    },
    "job_device_set": {
      "device_set": {
        "devices": {
          "device_ids": [
            "c70fc034-0cbd-443f-ad3d-a30d4319f937",
            "8627c130-9127-4ed7-ace5-93d3b4321d5e",
            "c0067069-c8f6-4183-9e67-1f2e9bf56f58"
          ]
        }
      }
    },
    "sensor_input_configs": [
      {
        "sensor_data": {
          "snmp_sensor": {
            "snmp_mib": {
              "oid": "1.3.6.1.2.1.1.3.0",
              "snmp_operation": "SCALAR"
            }
          }
        },
        "cadence_in_millisec": "60000"
      },
      {
        "sensor_data": {
          "snmp_sensor": {
            "snmp_mib": {
              "oid": "1.3.6.1.2.1.31.1.1",
              "snmp_operation": "TABLE"
            }
          }
        },
        "cadence_in_millisec": "60000"
      }
    ],
    "sensor_output_configs": [
      {
        "sensor_data": {
          "snmp_sensor": {
            "snmp_mib": {
              "oid": "1.3.6.1.2.1.1.3.0",
              "snmp_operation": "SCALAR"
            }
          }
        },
        "destination": {
          "destination_id": "4c2ab662-2670-4b3c-b7d3-b94acba98c56",
          "context_id": "topic1_461cb8aa-a16a-44b8-b79f-c3daf3ea925f"
        }
      },
      {
        "sensor_data": {
          "snmp_sensor": {
            "snmp_mib": {
              "oid": "1.3.6.1.2.1.31.1.1",
              "snmp_operation": "TABLE"
            }
          }
        },
        "destination": {
          "destination_id": "4c2ab662-2670-4b3c-b7d3-b94acba98c56",
          "context_id": "topic2_e7ed6300-fc8c-47ee-8445-70e543057f8a"
        }
      }
    ]
  }
}

Steps to create a SNMP collection job

You can create a SNMP collection job using the Cisco Crosswork UI or APIs. For information on creating a job from the UI, see Create a collection job from Crosswork UI and from the API, see Cisco Devnet.

SNMP traps collection job

SNMP trap collection jobs can only be created through the API.

Prerequisites for trap collections

  • Install the Common EMS Services application.

  • Configure host information for SNMP on the Data Gateway.

  • Ensure SNMP traps are properly configured on devices to send traps to the Crosswork Data Gateway’s virtual IP address.

To understand how SNMP trap collection operates, see How SNMP trap collection jobs work.

Supported trap types

Crosswork supports three types of non-YANG or OID-based traps:

Table 4. Non-YANG and OID traps
Sensor path Description
* Gets all the traps pushed from the device without any filter.
MIB level traps

OID of one MIB notification

(Ex: 1.3.6.1.2.1.138.0 to get all the isis-mib level traps)
Specific trap

OID of the specific trap

(Ex: 1.3.6.1.6.3.1.1.5.4 to get the linkUp trap)

Enabling SNMP traps to forward to external applications

We recommend enabling only the necessary traps on the device. You can identify trap types in the received data by matching OIDs (OBJECT_IDENTIFIER), for example oid 1.3.6.1.6.3.1.1.4.1.0 and strValue associated to the oid in the OidRecords. The application matches the OID of interest to determine the trap type.

These are sample values and a sample payload to forward traps to external applications:

Table 5. Non-YANG and OID traps
Trap type OID value

Link Up

 1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.6.3.1.1.5.4

Link Down

 1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.6.3.1.1.5.3

Syslog

 1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.4.1.9.9.41.2.0.1

Cold start

 1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.6.3.1.1.5.1 
{
  "nodeIdStr": "BF5-XRV9K1.tr3.es",
  "nodeIdUuid": "C9tZ5lJoSJKf5OZ67+U5JQ==",
  "collectionId": "133",
  "collectionStartTime": "1580931985267",
  "msgTimestamp": "1580931985267",
  "dataGpbkv": [
    {
      "timestamp": "1580931985267",
      "name": "trapsensor.path",
      "snmpTrap": {
        "version": "V2c",
        "pduType": "TRAP",
        "v2v3Data": {
          "agentAddress": "172.70.39.227",
          "oidRecords": [
            {
              "oid": "1.3.6.1.2.1.1.3.0",
              "strValue": "7 days, 2:15:17.02"
            },
            {
              "oid": "1.3.6.1.6.3.1.1.4.1.0",  // This oid is the Object Identifier.
              "strValue": "1.3.6.1.6.3.1.1.5.3" // This is the value that determines the kind of trap.
            },
            {
              "oid": "1.3.6.1.2.1.2.2.1.1.8",
              "strValue": "8"
            },
            {
              "oid": "1.3.6.1.2.1.2.2.1.2.8",
              "strValue": "GigabitEthernet0/0/0/2"
            },
            {
              "oid": "1.3.6.1.2.1.2.2.1.3.8",
              "strValue": "6"
            },
            {
              "oid": "1.3.6.1.4.1.9.9.276.1.1.2.1.3.8",
              "strValue": "down"
            }
          ]
        }
      }
    }
  ],
  "collectionEndTime": "1580931985267",
  "collectorUuid": "YmNjZjEzMTktZjFlOS00NTE5LWI4OTgtY2Y1ZmQxZDFjNWExOlRSQVBfQ09MTEVDVE9S",
  "status": {
    "status": "SUCCESS"
  },
  "modelData": {},
  "sensorData": {
    "trapSensor": {
      "path": "1.3.6.1.6.3.1.1.5.4"
    }
  },
  "applicationContexts": [
    {
      "applicationId": "APP1",
      "contextId": "collection-job-snmp-traps"
    }
  ]
}

A sample payload illustrates trap forwarding with relevant OID records and their corresponding string values.

{
  "collection_job": {
    "application_context": {
      "context_id": "collection-job1",
      "application_id": "APP1"
    },
    "collection_mode": {
      "lifetime_type": "APPLICATION_MANAGED",
      "collector_type": "SNMP_COLLECTOR"
    },
    "job_device_set": {
      "device_set": {
        "devices": {
          "device_ids": [
            "c70fc034-0cbd-443f-ad3d-a30d4319f937",
            "8627c130-9127-4ed7-ace5-93d3b4321d5e",
            "c0067069-c8f6-4183-9e67-1f2e9bf56f58"
          ]
        }
      }
    },
    "sensor_input_configs": [
      {
        "sensor_data": {
          "snmp_sensor": {
            "snmp_mib": {
              "oid": "1.3.6.1.2.1.1.3.0",
              "snmp_operation": "SCALAR"
            }
          }
        },
        "cadence_in_millisec": "60000"
      },
      {
        "sensor_data": {
          "snmp_sensor": {
            "snmp_mib": {
              "oid": "1.3.6.1.2.1.31.1.1",
              "snmp_operation": "TABLE"
            }
          }
        },
        "cadence_in_millisec": "60000"
      }
    ],
    "sensor_output_configs": [
      {
        "sensor_data": {
          "snmp_sensor": {
            "snmp_mib": {
              "oid": "1.3.6.1.2.1.1.3.0",
              "snmp_operation": "SCALAR"
            }
          }
        },
        "destination": {
          "destination_id": "4c2ab662-2670-4b3c-b7d3-b94acba98c56",
          "context_id": "topic1_461cb8aa-a16a-44b8-b79f-c3daf3ea925f"
        }
      },
      {
        "sensor_data": {
          "snmp_sensor": {
            "snmp_mib": {
              "oid": "1.3.6.1.2.1.31.1.1",
              "snmp_operation": "TABLE"
            }
          }
        },
        "destination": {
          "destination_id": "4c2ab662-2670-4b3c-b7d3-b94acba98c56",
          "context_id": "topic2_e7ed6300-fc8c-47ee-8445-70e543057f8a"
        }
      }
    ]
  }
}

How SNMP trap collection jobs work

SNMP trap collection jobs can only be created through the API. Trap listeners in the Data Gateway listen on UDP port 1062 for trap data. They forward the data based on configured recipient topics.

Summary

Key components involved in the SNMP trap collection job process:

  • Data Gateway: The component that receives SNMP trap messages and forwards relevant data based on active collection jobs and configured recipient topics.

  • Trap listener: The sub-component within the Data Gateway that listens for incoming SNMP traps on UDP port 1062.

  • Recipient topic: The configuration element that determines where the Data Gateway forwards validated SNMP trap data.

  • Device or router: The network element that generates and sends SNMP traps to the Data Gateway.

Workflow

When an SNMP trap is received, the Data Gateway:

  1. Checks for an active collection job for the device.
  2. Validates the trap version and community string.
    Note

    To prevent Data Gateway from checking the community string for SNMP traps, select the SNMP Disable Trap Check check box when adding a device through the Crosswork UI. For more information about this option, see Add devices individually through the UI in Cisco Crosswork Network Controller 7.2.x Device Lifecycle Management.

  3. For SNMP v3, the process validates user authentication, privacy protocols, and credentials.
    Note
    SNMPV3 auth-priv traps depend on the engineId of the device or router to maintain local USM user tables. If the engineId of the device or router changes, receiving traps will be interrupted. Therefore, there will be an interruption in receiving traps whenever the engineId of the device or router changes. To resume receiving traps, detach and reattach the respective device.
  4. Filters the traps based on the trap OID mentioned in the sensor path and sends only those requested. If the collection job is invalid, configuration on the device is missing, or no trap is received, the job status remains Unknown. For list of supported Traps and MIBs, see List of Pre-loaded Traps and MIBs for SNMP Collection.

MDT collection job

Model-Driven Telemetry Collection in Crosswork Data Gateway is a network data collection method that

  • enables direct consumption of telemetry streams from IOS-XR devices using MDT TCP Dial-out mode

  • leverages Cisco NSO to automate telemetry configuration and collection job deployment, and

  • requires backup or restore operations to be coordinated with NSO for device configuration consistency.

Starting with Crosswork Network Controller Release 7.2, Model-Driven Telemetry (MDT) based data collection is deprecated. While MDT options remain visible in the GUI during this transition period, use gNMI for all new and existing telemetry collection configurations. See Deprecation of MDT-based data collection.

Notes on backup and restore

  • If MDT collection jobs are changed between backup and restore operations, Crosswork Network Controller only restores jobs in the database and does not replay configuration updates on the devices. NSO or device configuration restoration is required separately.

  • Before using any YANG modules for MDT collection, verify their support status. See List of Pre-loaded YANG Modules for MDT Collection.

Example MDT collection payload

{
	"collection_job": {
		"job_device_set": {
			"device_set": {
				"device_group": "mdt"
			}
		},
		"sensor_output_configs": [{
				"sensor_data": {
					"mdt_sensor": {
						"path": "Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters"
					}
				},
				"destination": {
					"context_id": "cw.mdt_sensor.cisco-ios-xr-infra-statsd-oper.gpb",
					"destination_id": "c2a8fba8-8363-3d22-b0c2-a9e449693fae"
				}
			},
			{
				"sensor_data": {
					"mdt_sensor": {
						"path": "Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/data-rate"
					}
				},
				"destination": {
					"context_id": "cw.mdt_sensor.cisco-ios-xr-infra-statsd-oper.gpb",
					"destination_id": "c2a8fba8-8363-3d22-b0c2-a9e449693fae"
				}
			}
		],
		"sensor_input_configs": [{
				"sensor_data": {
					"mdt_sensor": {
						"path": "Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/data-rate"
					}
				},
				"cadence_in_millisec": "70000"
			}, {
				"sensor_data": {
					"mdt_sensor": {
						"path": "Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters"
					}
				},
				"cadence_in_millisec": "70000"
			}
		],
		"application_context": {
			"context_id": "c4",
			"application_id": "a4-mdt"
		},
		"collection_mode": {
			"lifetime_type": "APPLICATION_MANAGED",
			"collector_type": "MDT_COLLECTOR"
		}
	}
}

How does MDT collection work

Summary

The MDT collection job workflow orchestrates automated telemetry data collection from network devices, ensuring that key performance indicators (KPIs) are monitored efficiently. It coordinates interactions between Cisco Crosswork, NSO, and Crosswork Data Gateway to push device configurations, create collection jobs, and distribute collected data to designated destinations.

Workflow

The MDT collection job workflow proceeds through these stages:

  1. When an MDT-based KPI is activated on a device, Cisco Crosswork sends a configuration request to NSO to enable data collection on the target devices.
  2. A collection job create request is sent to the Crosswork Data Gateway.
  3. Crosswork Data Gateway creates a distribution to send the collected data to the specified destination.

Syslog collection jobs

A syslog collection job is a task configured on the Cisco Crosswork Data Gateway that

  • collects syslog messages from devices formatted according to supported standards (RFC 5424 and RFC 3164),

  • supports multiple syslog transport methods, enabling collection of real-time event logs across diverse devices, and

  • processes and forwards the collected syslog data to specified external destinations for monitoring, analysis, and troubleshooting.

Filtering the syslog events

You can manage and control the volume of syslog data collected from devices by configuring filtering rules using SyslogSensors. SyslogSensors support PRI-based and filter-based rules that allow you to selectively capture only the syslog events relevant to your network monitoring and analysis needs. When you apply filters based on severity, facility, or regular expressions, only required events are forwarded to the configured destination. This reduces noise, optimizes storage, and streamlines downstream processing of syslog data. Logical operators such as AND and OR enable you to define up to three filter combinations, providing flexibility in how filters are evaluated.

Configure syslog data collection from Crosswork Data Gateway

Use the Data Gateways in your network to enable syslog data collection. This process allows you to gather and manage system logs from connected devices efficiently

Procedure

1.

Install the Element Management Functions application. Then, configure the host information for syslog. Refer to the Cisco Crosswork Network Controller 7.2.x Installation Guide for reference.
2.

Add the device and select the YANG_CLI capability.
3.

Configure the required parameters to enable syslog data collection from the Data Gateways.

Note
The order of these steps does not affect the outcome, but steps 2 and 3 are mandatory. If either step is skipped, no syslog data will be collected.

What to do next

For example configurations, refer to:

Syslog collection job output

When you onboard a device from Crosswork Network Controller UI (Device Management > Network Devices > Device Details), the value you choose in the Syslog Format field configures the format in which syslog events received from the device should be parsed by the syslog collector. You can choose either UNKNOWN, RFC5424 or RFC3164.

  1. Output for UNKNOWN syslog format: Syslog collection Job output contains syslog events as received from device.

    Note

    If the device is configured to generate syslog events in RFC5424/RFC3164 format but no format is specified in the Syslog Format field, this is considered as UNKNOWN by default.

    Sample output: 
    node_id_str: "xrv9k-VM8"
node_id_uuid: ":i\300\216>\366BM\262\270@\337\225\2723&"
collection_id: 1056
collection_start_time: 1616711596200
msg_timestamp: 1616711596201
data_gpbkv {
  timestamp: 1616711596201
  name: "syslogsensor.path"
  fields {
    name: "RAW"
    string_value: "<6>1 Mar 25 15:34:41.321 PDT - SSHD_ 69570 - - 98949: RP/0/RP0/CPU0:SSHD_[69570]: %SECURITY-SSHD-6-INFO_SUCCESS : Successfully authenticated user \'admin\' from \'40.40.40.116\' on \'vty0\'(cipher \'aes128-ctr\', mac \'hmac-sha1\') \n"
  }
  fields {
    name: "DEVICE_IP"
    string_value: "40.40.40.30"
  }
}
collection_end_time: 1616711596200
collector_uuid: "17328736-b726-4fe3-b922-231a4a30a54f:SYSLOG_COLLECTOR"
status {
  status: SUCCESS
}
model_data {
}
sensor_data {
  syslog_sensor {
    pris {
      facilities: 0
      facilities: 3
      facilities: 4
      facilities: 23
      severities: 0
      severities: 5
      severities: 6
      severities: 7
    }
  }
}
application_contexts {
  application_id: "SyslogApp-xr-8-job1"
  context_id: "xr-8-job1"
}
version: "1"

  2. Output for RFC5424 syslog format: If the device is configured to generate syslog events in RFC5424 format and the RFC5424 format is selected in the Syslog Format field, the Syslog Job Collection output contains syslog events as received from the device (RAW) and the RFC5424 best-effort parsed syslog events from the device.

    Note

    The syslog collector will parse the syslog event on best effort as per the following Java RegEx pattern:

    Sample output:

    ....
....
 
 
collection_start_time: 1596307542398
msg_timestamp: 1596307542405
data_gpbkv {
  timestamp: 1596307542405
  name: "syslogsensor.path"
  fields {
    name: "RAW"
    string_value: "<13>1 2020 Aug  1 12:03:32.461 UTC:  iosxr254node config 65910 - - 2782: RP/0/RSP0/CPU0:2020 Aug  1 12:03:32.461 UTC: config[65910]: %MGBL-SYS-5-CONFIG_I : Configured from console by admin on vty0 (10.24.88.215) \n"
  }
  fields {
    name: "RFC5424"
    string_value: "pri=13,  severity=5,  facility=1,  version=1,  date=2020-08-01T12:03:32.461,  remoteAddress=/172.28.122.254,  host=\'iosxr254node\',  message=\'2782: RP/0/RSP0/CPU0:2020 Aug  1 12:03:32.461 UTC: config[65910]: %MGBL-SYS-5-CONFIG_I : Configured from console by admin on vty0 (10.24.88.215) \', messageId=null, processName=config, structuredDataList=null"
  }
  fields {
    name: "DEVICE_IP"
    string_value: "172.28.122.254"
  }
}
collection_end_time: 1596307542404
collector_uuid: "ac961b09-8f67-4c93-a99a-31eef50f7fa9:SYSLOG_COLLECTOR"
status {
  status: SUCCESS
}
...
...

  3. Output for RFC3164 syslog format: If the device is configured to generate syslog events in RFC3164 format and the RFC3164 format is selected in the Syslog Format field, the Syslog Job Collection output contains both RAW (as received from the device) syslog events and the RFC3164 best-effort parsed syslog events from the device.

    Note

    The syslog collector will parse the syslog event on best efforts as per this Java RegEx pattern.

    Sample output: 
    ....
.....
collection_id: 20
collection_start_time: 1596306752737
msg_timestamp: 1596306752743
data_gpbkv {
  timestamp: 1596306752743
  name: "syslogsensor.path"
  fields {
    name: "RAW"
    string_value: "<14>2020 Aug  1 11:50:22.799 UTC:  iosxr254node 2756: RP/0/RSP0/CPU0:2020 Aug  1 11:50:22.799 UTC: config[65910]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user \'admin\'. Use \'show configuration commit changes 1000000580\' to view the changes. \n"
  }
  fields {
    name: "RFC3164"
    string_value: "pri=14,  severity=6,  facility=1,  version=null,  date=2020-08-01T11:50:22.799,  remoteAddress=/172.28.122.254,  host=\'iosxr254node\',  message=\'RP/0/RSP0/CPU0:2020 Aug  1 11:50:22.799 UTC: config[65910]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user \'admin\'. Use \'show configuration commit changes 1000000580\' to view the changes. \', tag=2756"
  }
  fields {
    name: "DEVICE_IP"
    string_value: "172.28.122.254"
  }
}
collection_end_time: 1596306752742
collector_uuid: "ac961b09-8f67-4c93-a99a-31eef50f7fa9:SYSLOG_COLLECTOR"
status {
  status: SUCCESS
}
....
....

Sample syslog collection payload

{
  "collection_job": {
      "job_device_set": {
      "device_set": {
        "devices": {
          "device_ids": [
            "c6f25a33-92e6-468a-ba0d-15490f1ce787"
          ]
        }
      }
    },
    "sensor_output_configs": [
      {
        "sensor_data": {
          "syslog_sensor": {
            "pris": {
                "facilities": [0, 1, 3, 23,4],
                "severities": [0, 4, 5, 6, 7]
            }
        }
        },
        "destination": {
          "context_id": "syslogtopic",
          "destination_id": "c2a8fba8-8363-3d22-b0c2-a9e449693fae"
        }
      }
    ],
    "sensor_input_configs": [
      {
        "sensor_data": {
          "syslog_sensor": {
            "pris": {
                "facilities": [0,1, 3, 23,4],
                "severities": [0,4, 5, 6, 7]
            }
        }
        },
        "cadence_in_millisec": "60000"
      }
    ],
    "application_context": {
      "context_id": "demomilesstone2syslog",
      "application_id": "SyslogDemo2"
    },
    "collection_mode": {
      "lifetime_type": "APPLICATION_MANAGED",
      "collector_type": "SYSLOG_COLLECTOR"
    }
  }
}

Configuring syslog on devices

Enable network devices to send event logs and messages to Crosswork Data Gateway for centralized monitoring and analysis by configuring non-secure or secure syslog options.

Syslog in Crosswork Data Gateway enables network devices to send logs and event messages to the Data Gateway. This allows centralized monitoring and analysis. There are two primary configurations:

Configure secure syslog on device

In a dual-stack Crosswork deployment, the device must use the same IP stack (either IPv4 or IPv6) as configured in the device inventory to ensure syslog events are logged without interruption. If the Data Gateway host address resolves to both IPv4 and IPv6, configure the device so that the source IP in events matches the configuration in the device inventory.

Before you begin

Confirm device inventory and Data Gateway configurations use the correct IP stack.

Use the steps to establish a secured syslog communication with the device.

Procedure

1.

Download the Cisco Crosswork trust chain.

  1. Access the Cisco Crosswork UI.

  2. Go to Administration > Certificate Management.

  3. Locate Crosswork-Device-Syslog and click the info icon.

  4. Click Export All to download the certificate files to your system.

    Similar files are downloaded to your system.

Figure 8. Certificates that are downloaded
2.

Configure your device with the Cisco Crosswork trustchain. Refer to sample configurations for device OS.

Refer to the sample configurations to enable Cisco Crosswork Trustpoint on device.

  1. For Cisco IOS XR.

    Enable TLS and create syslog-root trustpoint:

    RP/0/RSP0/CPU0:ASR9k(config)#crypto ca trustpoint syslog-root
RP/0/RSP0/CPU0:ASR9k(config-trustp)#enrollment terminal
RP/0/RSP0/CPU0:ASR9k(config-trustp)#crl optional
RP/0/RSP0/CPU0:ASR9k(config-trustp)#commit
RP/0/RSP0/CPU0:ASR9k(config-trustp)#end
RP/0/RSP0/CPU0:ASR9k#
RP/0/RSP0/CPU0:ASR9k#crypto ca authenticate syslog-root
Fri Jan 22 11:07:41.880 GMT
  
  
Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself
  
-----BEGIN CERTIFICATE-----
MIIGKzCCBBOgAwIBAgIRAKfyU89yjmrXVDRKBWuSGPgwDQYJKoZIhvcNAQELBQAw
bDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMREwDwYDVQQHEwhTYW4gSm9zZTEa
................................................................
................................................................
jPQ/UrO8N3sC1gGJX7CIIh5cE+KIJ51ep8i1eKSJ5wHWRTmv342MnG2StgOTtaFF
vrkWHD02o6jRuYXDWEUptDOg8oEritZb+SNPXWUc/2mbYog6ks6EeMC69VjkZPo=
-----END CERTIFICATE-----
  
Read 1583 bytes as CA certificate
  Serial Number  : A7:F2:53:CF:72:8E:6A:D7:54:34:4A:05:6B:92:18:F8
  Subject:
                CN=Crosswork Device Root CA,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Issued By      :
                CN=Crosswork Device Root CA,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Validity Start : 02:37:09 UTC Sat Jan 16 2021
  Validity End   : 02:37:09 UTC Thu Jan 15 2026
  SHA1 Fingerprint:
                209B3815271C22ADF78CB906F6A32DD9D97BBDBA
  
Fingerprint: 2FF85849EBAAB9B059ACB9F5363D5C9CDo you accept this certificate? [yes/no]: yes
RP/0/RSP0/CPU0:ASR9k#config
RP/0/RSP0/CPU0:ASR9k(config)#crypto ca trustpoint syslog-inter
RP/0/RSP0/CPU0:ASR9k(config-trustp)#enrollment terminal
RP/0/RSP0/CPU0:ASR9k(config-trustp)#crl optional
RP/0/RSP0/CPU0:ASR9k(config-trustp)#commit
RP/0/RSP0/CPU0:ASR9k#crypto ca authenticate syslog-inter
Fri Jan 22 11:10:30.090 GMT
  
  
Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself
  
-----BEGIN CERTIFICATE-----
MIIGFDCCA/ygAwIBAgIRAkhqHQXcJzQzeQK6U2wn8PIwDQYJKoZIhvcNAQELBQAw
bDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMREwDwYDVQQHEwhTYW4gSm9zZTEa
................................................................
................................................................
5lBk617z6cxFER5c+/PmJFhcreisTxXg1aJbFdnB5C8f+0uUIdLghykQ/zaZGuBn
AAB70c9r9OeKGJWzvv1e2U8HH1pdQ/nd
-----END CERTIFICATE-----
  
Read 1560 bytes as CA certificate
  Serial Number  : 02:48:6A:1D:05:DC:27:34:33:79:02:BA:53:6C:27:F0:F2
  Subject:
                CN=device-syslog,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Issued By      :
                CN=Crosswork Device Root CA,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Validity Start : 02:37:11 UTC Sat Jan 16 2021
  Validity End   : 02:37:11 UTC Mon Jan 16 2023
  SHA1 Fingerprint:
                B06F2BFDE95413A8D08A01EE3511BC3D42F01E59
  
CA Certificate validated using issuer certificate.
RP/0/RSP0/CPU0:ASR9k#show crypto ca certificates
Fri Jan 22 15:45:17.196 GMT
 
 
Trustpoint       : syslog-root
==================================================
CA certificate
  Serial Number  : A7:F2:53:CF:72:8E:6A:D7:54:34:4A:05:6B:92:18:F8
  Subject:
        CN=Crosswork Device Root CA,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Issued By      :
        CN=Crosswork Device Root CA,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Validity Start : 02:37:09 UTC Sat Jan 16 2021
  Validity End   : 02:37:09 UTC Thu Jan 15 2026
  SHA1 Fingerprint:
         209B3815271C22ADF78CB906F6A32DD9D97BBDBA
 
 
Trustpoint       : syslog-inter
==================================================
CA certificate
  Serial Number  : 02:48:6A:1D:05:DC:27:34:33:79:02:BA:53:6C:27:F0:F2
  Subject:
        CN=device-syslog,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Issued By      :
        CN=Crosswork Device Root CA,O=CISCO SYSTEMS INC,L=San Jose,ST=CA,C=US
  Validity Start : 02:37:11 UTC Sat Jan 16 2021
  Validity End   : 02:37:11 UTC Mon Jan 16 2023
  SHA1 Fingerprint:
         B06F2BFDE95413A8D08A01EE3511BC3D42F01E59
RP/0/RSP0/CPU0:ASR9k(config)#logging tls-server syslog-tb131
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#tls-hostname <CDG Southbound IP>
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#trustpoint syslog-inter
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#severity debugging
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#vrf default
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#commit
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#exit
RP/0/RSP0/CPU0:ASR9k(config)#exit
RP/0/RSP0/CPU0:ASR9k#exit
RP/0/RSP0/CPU0:ASR9k#show running-config logging
Fri Jan 22 11:17:19.385 GMT
logging tls-server syslog-tb131
vrf default
severity debugging
trustpoint syslog-inter 
tls-hostname <CDG Southbound IP>
!
logging trap debugging
logging format rfc5424
logging facility user
logging hostnameprefix ASR9k
logging suppress duplicates
  
RP/0/RSP0/CPU0:ASR9k#

  2. Enable TLS on IOS XE device configuration.

    csr8kv(config)#crypto pki trustpoint syslog-root
csr8kv(ca-trustpoint)#enrollment terminal
csr8kv(ca-trustpoint)#revocation-check none
csr8kv(ca-trustpoint)#chain-validation stop
csr8kv(ca-trustpoint)#end
csr8kv(config)#crypto pki authenticate syslog-root
 
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
 
-----BEGIN CERTIFICATE-----
MIIFPjCCAyYCCQCO6pK5AOGYdjANBgkqhkiG9w0BAQsFADBhMQswCQYDVQQGEwJV
UzELMAkGA1UECAwCQ0ExETAPBgNVBAcMCE1pbHBpdGFzMQ4wDAYDVQQKDAVDaXNj
................................................................
................................................................
JbimOpXAncoBLo14DXOJLvMVRjn1EULE9AXXCNfnrnBx7jL4CV+qHgEtF6oqclFW
JEA=
-----END CERTIFICATE-----
 
Certificate has the following attributes:
       Fingerprint MD5: D88D6D8F E53750D4 B36EB498 0A435DA1
      Fingerprint SHA1: 649DE822 1C222C1F 5101BEB8 B29CDF12 5CEE463B
 
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported
 
 
csr8kv(config)#crypto pki trustpoint syslog-intermediate
csr8kv(ca-trustpoint)#enrollment terminal
csr8kv(ca-trustpoint)#revocation-check none
csr8kv(ca-trustpoint)#chain-validation continue syslog-root
csr8kv(ca-trustpoint)#end
csr8kv(config)#crypto pki authenticate syslog-intermediate
 
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
 
-----BEGIN CERTIFICATE-----
MIIFfTCCA2WgAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwXDELMAkGA1UEBhMCVVMx
EzARBgNVBAgMCkNhbGlmb3JuaWExDjAMBgNVBAoMBUNpc2NvMQ4wDAYDVQQLDAVT
................................................................
................................................................
Nmz6NQynD7bxdQa9Xq9kyPuY3ZVKXkf312IRH0MEy2yFX/tAen9JqOeZ1g8canmw
TxsWA5TLzy1RmxqQh88f0CM=
-----END CERTIFICATE-----
Trustpoint 'syslog-intermediate' is a subordinate CA.
but certificate is not a CA certificate.
Manual verification required
Certificate has the following attributes:
       Fingerprint MD5: FE27BDBE 9265208A 681670AC F59A2BF1
      Fingerprint SHA1: 03F513BD 4BEB689F A4F4E001 57EC210E 88C7BD19
 
csr8kv(config)#logging host <CDG Southbound IP> transport tls port 6514
csr8kv(config)#logging trap informational syslog-format rfc5424
csr8kv(config)#logging facility user
csr8kv(config)#service timestamps log datetime msec year show-timezone

csr8kv(config)#logging tls-profile tlsv12

  3. Syslog configuration to support FQDN. Use the following commands in addition to the sample device configuration to enable TLS to support FQDN.

    1. Configure the domain name and DNS IP on the device.

      For IOS XR: 
      RP/0/RSP0/CPU0:ASR9k#config
RP/0/RSP0/CPU0:ASR9k(config)#domain name <DNS domain name>
RP/0/RSP0/CPU0:ASR9k(config)#domain name-server <DNS server IP>

      For IOS XE:

      Device(config)# ip name-server <IP of DNS>
Device(config)# ip domain name <domain name>

    2. Configure Crosswork Data Gateway VIP FQDN for tls-hostname.

      For IOS XR:

      RP/0/RSP0/CPU0:ASR9k(config)#logging tls-server syslog-tb131
RP/0/RSP0/CPU0:ASR9k(config-logging-tls-peer)#tls-hostname <CDG VIP FQDN>

      For IOS XE:

      Device(config)# logging host fqdn ipv4 <CDG VIP FQDN> transport tls port 6514
Your device is configured for secure syslog communications using TLS, with trusted certificate enrollment. Syslog events will log without interruption according to inventory IP stack and FQDN configuration.

What to do next

Monitor syslog event flow on Cisco Crosswork to validate successful and secure logging from your device.

Configure non-secure syslog on a device

Configure the device to send non-secure syslog messages in RFC3164 or RFC5424 format to the Data Gateway host.

In dual-stack Crosswork deployments, ensure devices use the same IP stack (IPv4 or IPv6) for sending syslog events as configured in device inventory. Set the Data Gateway host as an IP address rather than an FQDN to ensure source IP consistency.

Before you begin

  • Verify syslog configuration supports RFC3164 or RFC5424 formats.

  • Ensure the device's syslog format matches the format specified during onboarding in the Crosswork UI.

  • In dual-stack deployments, configure the device to send syslog over the same IP stack (IPv4 or IPv6) as in device inventory.

  • Use an IP address for the Data Gateway host instead of an FQDN to ensure source IP consistency.

Procedure

1.

Configure syslog for RFC3164 format.

  • On IOS XR, apply:

    logging <CDG IP> port 9514 OR logging <CDG IP> vrf <vrfname> port 9514 
logging trap [severity]
logging facility [facility value]
logging suppress duplicates
service timestamps log datetime msec show-timezone year
logging hostnameprefix <some host related prefix e.g.iosxrhost2>

  • On IOS XE, apply:

    no logging message-counter syslog 
logging trap <severity>
logging facility <facility>
logging host <CDG IP> transport tcp port 9898 session-id string <sessionidstring> --> To use TCP channel
OR
logging host <CDG IP> transport udp port 9514 session-id string <sessionidstring> ---> To use UDP channel
OR
logging host <CDG IP> vrf Mgmt-intf transport udp port 9514 session-id string <sessionidstring> --> To use UDP via vrf 
service timestamps log datetime msec year show-timezone
2.

Configure syslog for RFC5424 format.

Note
The configuration highlighted in the code below is required to avoid formatting issues in the parsed output.

  • On IOS XR, apply:

    logging <CDG IP> port 9514 OR logging <server 1> vrf <vrfname> port 9514 
logging trap [severity]
logging facility [facility value]
logging suppress duplicates
service timestamps log datetime msec show-timezone year
logging hostnameprefix <some host related prefix e.g.iosxrhost2>
logging format rfc5424

  • On IOS XE, apply:

    no logging message-counter syslog
logging trap <severity>
logging facility <facility>
logging host <CDG IP> transport tcp port 9898 session-id string <sessionidstring> --> To use TCP channel
OR
logging host <CDG IP> transport udp port 9514 session-id string <sessionidstring> ---> To use UDP channel
OR
logging host <CDG IP> vrf Mgmt-intf transport udp port 9514 session-id string <sessionidstring> --> To use UDP via vrf 
service timestamps log datetime msec year show-timezone
logging trap syslog-format 5424 --> if applicable

The device sends non-secure syslog messages to the Data Gateway host using the designated format and protocol.

What to do next

Verify that syslog events are being successfully received by the Data Gateway.

gNMI collection jobs

A gNMI collection job is a telemetry data collection process that

  • uses the gRPC Network Management Interface (gNMI) Dial-In protocol to stream telemetry data based on defined subscriptions

  • relays subscription responses (notifications) to configured destinations with preference for secure connections, and

  • automatically re-subscribes existing subscriptions after device reloads while operating within the protocol’s limitations (no destination or dispatch cadence support).

Modes supported in secure and insecure GNMI collection

In gNMI, a device can operate in both secure and insecure modes simultaneously. The Crosswork Network Controller preferentially uses secure mode, depending on inventory information. After a device reloads, the gNMI collector re-subscribes the existing subscriptions to the device.

When secure mode is enabled, gNMI uses server authentication only. The Data Gateway validates the device's certificate to establish a trusted connection, but does not present a client certificate for device validation. Mutual TLS authentication, where both parties authenticate each other, is not supported for gNMI device configuration.

Crosswork Data Gateway supports these subscribe options for gNMI:

Table 6. gNMI subscription options

Type

Subtype

Description

Once

None

Collects and sends the current snapshot of the system configuration only once for all specified paths.

Stream

SAMPLE

Cadence-based collection.

ON_CHANGE

First response includes the state of all the elements for the subscribed path, followed by subsequent updates to the changes leaf values.

TARGET_DEFINED

The router or device chooses the mode of subscription on a per-leaf basis depending on the subscribed path, such as SAMPLE or ON_CHANGE.
Note

  • Crosswork Data Gateway relies on the device to declare the support of one or more modes.

  • gNMI sensor path with default values does not appear in the payload. This is a known Protocol Buffers (protobuf) behavior. For boolean the default value is false. For enum, it is gnmi.proto specified.

    Example 1: 
    message GNMIDeviceSetting {
bool suppress_redundant = 1;
bool allow_aggregation = 4;
bool updates_only = 6;
}
    Example 2: 
    enum SubscriptionMode {
TARGET_DEFINED = 0; //default value will not be printed
ON_CHANGE = 1;
SAMPLE = 2;
}

Example of gNMI collection payload

In this sample you see two collections for the device group "milpitas". The first collection job gathers interface statistics every 60 seconds using the "SAMPLE" mode. The second job detects any changes to the interface state (up or down) and sends them to the collector using the "STREAM" mode. 

{
    "collection_job": {
        "job_device_set": {
            "device_set": {
                "device_group": "milpitas"
            }
        },
        "sensor_output_configs": [{
            "sensor_data": {
                "gnmi_standard_sensor": {
                    "Subscribe_request": {
                        "subscribe": {
                            "subscription": [{
                                "path": {
                                    "origin": "openconfig-interfaces",
                                    "elem": [{
                                        "name": "interfaces/interface/state/ifindex"
                                    }]
                                },
                                "mode": "SAMPLE",
                                "sample_interval": 10000000000
                            }, {
                                "path": {
                                    "origin": "openconfig-interfaces",
                                    "elem": [{
                                        "name": "interfaces/interfaces/state/counters/out-octets"
                                    }]
                                },
                                "mode": "ON_CHANGE",
                                "sample_interval": 10000000000
                            }],
                            "mode": "STREAM",
                            "encoding": "JSON"
                        }
                    }
                }
            },
            "destination": {
                "context_id": "hukarz",
                "destination_id": "c2a8fba8-8363-3d22-b0c2-a9e449693fae"
            }
        }],
        "sensor_input_configs": [{
            "sensor_data": {
                "gnmi_standard_sensor": {
                    "Subscribe_request": {
                        "subscribe": {
                            "subscription": [{
                                "path": {
                                    "origin": "openconfig-interfaces",
                                    "elem": [{
                                        "name": "interfaces/interface/state/ifindex"
                                    }]
                                },
                                "mode": "SAMPLE",
                                "sample_interval": 10000000000
                            }, {
                                "path": {
                                    "origin": "openconfig-interfaces",
                                    "elem": [{
                                        "name": "interfaces/interfaces/state/counters/out-octets"
                                    }]
                                },
                                "mode": "ON_CHANGE",
                                "sample_interval": 10000000000
                            }],
                            "mode": "STREAM",
                            "encoding": "JSON"
                        }
                    }
                }
            },
            "cadence_in_millisec": "60000"
        }],
        "application_context": {
            "context_id": "testing.group.gnmi.subscription.onchange",
            "application_id": "testing.postman.gnmi.standard.persistent"
        },
        "collection_mode": {
            "lifetime_type": "APPLICATION_MANAGED",
            "collector_type": "GNMI_COLLECTOR"
        }
    }
}

Enable secure gNMI communication between device and Data Gateway

Enable secure gNMI communication between network devices and Cisco Crosswork Data Gateway by configuring trusted certificate authority settings and required device protocols. This ensures all gNMI connections are authenticated and encrypted, allowing Crosswork to safely collect and manage telemetry data from supported devices.

Cisco Crosswork supports only one root CA certificate (either self-signed or signed by a trusted root CA), which means all device certificates must be signed by the same CA. If your device certificates are signed by a different trusted root CA, you can skip the first step and start by importing the root CA certificate into Cisco Crosswork.

Procedure

1.

Generate certificates: Create certificates using OpenSSL or a compatible utility. For device certificates, you can include multiple device IPs in the certificate's subject alternative name (SAN). The certificate validity period should be set appropriately (recommendation: 365 days). See Generate device certificates.
2.

Upload the Root CA Certificate to Crosswork: Use the Cisco Crosswork UI under Administration > Certificate Management to upload the root CA certificate. Multiple device trust chains can be combined into a single .pem file for upload. See Add the gNMI certificate.

Note
If the gNMI certificate is already configured, update the existing .pem file to include any new trust chain information.
3.

Import and install certificates on devices.

  • Cisco IOS XR Devices: Copy rootCA.pem, device.key, and device.crt to the device (usually to /tmp), then place them under /misc/config/grpc as ca.cert, ems.key, and ems.pem respectively. Restart the emsd process on device using process restart emsd.

  • Cisco IOS XE Devices: Use the CLI crypto pki import commands to import CA certificates, device keys, and device certificates under a trustpoint. Disable revocation check if needed.
4.

Update device protocol configuration from Crosswork: After uploading certificates, update device settings by selecting the gNMI protocol and enable the secure connection. See Update device protocol.
5.

Configure device for gNMI.

  • Cisco IOS XR: Enable gRPC over HTTP/2, configure the gRPC port (range 57344–57999), and set session parameters such as TLS, trustpoints, and stream limits.

  • Cisco IOS XE: Enable gNMI in insecure or secure mode with trustpoints and secure ports via CLI commands.

See Configure device for gNMI.
Note
Crosswork Data Gateway supports server authentication only for gNMI device configuration. The device validates the Data Gateway's certificate, but the Data Gateway does not require a client certificate from the device. Mutual TLS authentication is not supported for gNMI collectors.
6.

Enable gNMI bundling on IOS XR devices: gNMI bundling stitches multiple update messages into a single notification to optimize telemetry data. This feature is supported on IOS XR release 7.81 and later. See Configure gNMI bundling for IOS XR.

Generate device certificates

Use this task to generate device certificates using OpenSSL or Microsoft utilities. These certificates are required for secure device communication and authentication.

This procedure describes the steps to create device certificates with OpenSSL. If you want to use a utility other than OpenSSL or Microsoft, contact the Cisco Support Team for guidance.

Before you begin

Use these steps to generate certificates validated with Open SSL and Microsoft utilities.

Procedure

1.

Create the rootCA certificate.

# openssl genrsa -out rootCA.key
# openssl req -subj /C=/ST=/L=/O=/CN=CrossworkCA -x509 -new -nodes -key rootCA.key -sha256 -out rootCA.pem -days 1024

In this command, the days attribute determines the how long the certificate is valid. The minimum value is 30 days, so you must update the certificates every 30 days.

2.

Create device key and certificate.

# openssl genrsa -out device.key
# openssl req -subj /C=/ST=/L=/O=/CN=Crosswork -new -key device.key -out device.csr
# openssl x509 -req -extfile <(printf "subjectAltName=IP.0: 10.58.56.18") -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -sha256 -out device.crt -days 1024

If you have multiple devices, you can specify several device IP addresses separated by commas in subjectAltName instead of creating multiple device certificates.

# openssl x509 -req -extfile <(printf "subjectAltName=IP.0: <IP address>, IP.1: <IP address>, IP.2: <IP address>.....
3.

Verify if the certificate is created and contains the expected SAN details.

# openssl x509 -in device.crt -text -noout

Sample certificate output

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            66:38:0c:59:36:59:da:8c:5f:82:3b:b8:a7:47:8f:b6:17:1f:6a:0f
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = rootCA
        Validity
            Not Before: Oct 28 17:44:28 2021 GMT
            Not After : Aug 17 17:44:28 2024 GMT
        Subject: CN = Crosswork
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:c6:25:8a:e8:37:7f:8d:1a:7f:fa:e2:d6:10:0d:
                    b8:e6:2b:b0:b0:7e:ab:c9:f9:14:a3:4f:2e:e6:30:
                    97:f4:cd:d6:11:7d:c0:a6:9b:43:83:3e:26:0f:73:
                    42:89:3c:d7:62:7b:04:af:0b:16:67:4c:8e:60:05:
                    cc:dd:99:37:3f:a4:17:ed:ff:28:21:20:50:6f:d9:
                    be:23:78:07:dc:1e:31:5e:5f:ca:54:27:e0:64:80:
                    03:33:f1:cd:09:52:07:6f:13:81:1b:e1:77:e2:08:
                    9f:b4:c5:97:a3:71:e8:c4:c8:60:18:fc:f3:be:5f:
                    d5:37:c6:05:6e:9e:1f:65:5b:67:46:a6:d3:94:1f:
                    38:36:54:be:23:28:cc:7b:a1:86:ae:bd:0d:19:1e:
                    77:b7:bd:db:5a:43:1f:8b:06:4e:cd:89:88:e6:45:
                    0e:e3:17:b3:0d:ba:c8:25:9f:fc:40:08:87:32:26:
                    69:62:c9:57:72:8a:c2:a1:37:3f:9d:37:e9:69:33:
                    a5:68:0f:8f:f4:31:a8:bc:34:93:a3:81:b9:38:87:
                    2a:87:a3:4c:e0:d6:aa:ad:a7:5c:fb:98:a2:71:15:
                    68:e7:8d:0f:71:9a:a1:ca:10:81:f8:f6:85:86:c1:
                    06:cc:a2:47:16:89:ee:d1:90:c9:51:e1:0d:a3:2f:
                    9f:0b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                IP Address:10.58.56.18
    Signature Algorithm: sha256WithRSAEncryption
         01:41:2c:91:0b:a1:10:8a:11:1a:95:36:99:2c:27:31:d3:7d:
         e9:4b:29:56:c3:b7:00:8c:f4:39:d2:8c:50:a4:da:d4:96:93:
         eb:bb:71:e3:70:d3:fe:1f:97:b2:bc:5c:f8:f4:65:ed:83:f7:
         67:56:db:0f:67:c2:3d:0c:e7:f8:37:65:1d:11:09:9a:e3:42:
         bc:c6:a0:31:7c:1f:d7:5e:c6:86:72:43:a8:c1:0c:70:33:60:
         dc:14:5b:9d:f3:ab:3d:d5:d2:94:90:1c:ba:fd:80:4d:22:e3:
         31:93:c7:16:5f:85:20:38:ad:36:b9:1a:e0:89:8e:06:8c:f8:
         cd:55:cc:a1:89:d3:91:7f:66:61:a3:40:71:c2:1e:ee:3b:80:
         37:af:73:5e:8e:0d:db:4b:49:da:a6:bd:7d:0a:aa:9e:9a:9e:
         fa:ed:05:25:08:f2:4d:cd:2f:63:55:cf:be:b1:5d:03:c2:b3:
         32:bf:f4:7b:1a:10:b9:5e:69:ac:77:5e:4a:4f:85:e3:7f:fe:
         04:df:ce:3e:bb:28:8f:e3:bf:1a:f9:0f:94:18:08:86:7d:59:
         57:71:0a:97:0d:86:9c:63:e7:0e:48:7d:f0:0e:1d:67:ff:9b:
         1d:1b:05:25:c8:c3:1f:f4:52:0f:e1:bf:86:d7:ec:47:10:bd:
         94:cf:ca:e2

Add the gNMI certificate

Crosswork Data Gateway is the gNMI client, and the device is the gNMI server. To validate the device, Crosswork Data Gateway uses a trust chain.

Note
You can upload only one gNMI certificate to Crosswork.

To add the gNMI certificate.

Before you begin

You should have a global trust chain for all devices.

Procedure

1.

From the Cisco Crosswork UI, go to Administration > Certificate Management.
2.

Click the + icon to add the certificate.
3.

In Add certificate window, enter the following details:

  • Certificate name: Enter a name for the certificate.

  • Certificate role: Select "Device gNMI/gRPC communication" from the drop-down list.

  • Device trust chain: Browse your local file system to the location of the rootCA file and upload it. If you have multiple trust chains, add all the device trust chains (single or multiple vendors) in a single .pem file and upload this .pem file.

Figure 9. Add gNMI certificate
Note

If gNMI certificate is already configured and you wish to onboard a device with a different trust chain, update the existing .pem file to include details of the new CA. Select the existing gNMI certificate from the list, click the edit icon and upload the new .pem file.
4.

Click Save.

After you add the gNMI certificate, it appears in the configured certificates list.

Figure 10. Certificates management
Certificates Window

Import and install certificates on devices

Import and install certificates on the IOS XR and XE devices. Certificates and trustpoints are required only for secure gNMI servers.

Procedure

1.

Copy rootCA.pem, device.key, and device.crt to the device under /tmp folder.
2.

Log in to the IOS XR device and enter the VM shell.

RP/0/RP0/CPU0:xrvr-7.2.1#run
3.

Navigate to the directory.

cd /misc/config/grpc
4.

Create or replace the content of these files.

Note

If TLS was previously enabled on your device, these files will already be present. In this case, replace the content of these files as explained in this section. If this is the first time, you are enabling TLS on the device, copy the files from the /tmp folder to this folder.

  • ems.pem with device.crt

  • ems.key with device.key

  • ca.cert with rootCA.pem
5.

Restart TLS on the device to apply the changes. To do this, disable TLS by using the "no-tls" command and then re-enable it by entering the "no no-tls" configuration command.

Example to install a certificate on a Cisco IOS XE device

# Send:
Device# configure terminal
Device(config)# crypto pki import trustpoint1 pem terminal password password1 
 
# Receive:
% Enter PEM-formatted CA certificate.
% End with a blank line or "quit" on a line by itself.
 
# Send:
# Contents of rootCA.pem, followed by newline + 'quit' + newline:
-----BEGIN CERTIFICATE-----
<snip>
-----END CERTIFICATE-----
quit
 
# Receive:
% Enter PEM-formatted encrypted private General Purpose key.
% End with "quit" on a line by itself.
 
# Send:
# Contents of device.des3.key, followed by newline + 'quit' + newline:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,D954FF9E43F1BA20
<snip>
-----END RSA PRIVATE KEY-----
quit
 
# Receive:
% Enter PEM-formatted General Purpose certificate.
% End with a blank line or "quit" on a line by itself.
 
# Send:
# Contents of device.crt, followed by newline + 'quit' + newline:
-----BEGIN CERTIFICATE-----
<snip>
-----END CERTIFICATE-----
quit
 
# Receive:
% PEM files import succeeded.
Device(config)#
 
# Send:
Device(config)# crypto pki trustpoint trustpoint1
Device(ca-trustpoint)# revocation-check none
Device(ca-trustpoint)# end
Device#

Update protocol on device from Crosswork

Perform the update of protocol details for a specified device using the Crosswork Network Controller.

Use this task to establish or update device communication security, particularly after certificate configuration or when maintaining compliance with network security protocols.

Before you begin

  • Ensure you have configured the gNMI certificate in Crosswork Network Controller.

  • Prepare the CSV file containing device details, including the required protocol information.

Procedure

1.

After configuring the gNMI certificate in Crosswork Network Controller, ensure your device is listed in the network inventory.

2.

Update the device with secure protocol details:

  1. Use the Cisco Crosswork UI at Device Management > Network Devices.

  2. Specify protocol details as GNMI_SECURE Port in the CSV file corresponding to the device.

  3. Import the device entry or edit it if necessary.

  4. View the Edit Device page for confirmation.

    Figure 11. Edit device window
    The Edit Device details page shows the updated secure protocol details for a device.

The device is updated with the specified secure protocol settings, and the Crosswork inventory should reflect the new configurations.

What to do next

  • Validate device communication and ensure connectivity using updated protocols.

  • Monitor alerts and error messages related to protocol changes.

Configure device for gNMI

Configure your device for gNMI support to enable remote management and programmability using standardized network management protocols.

The gNMI protocol enables centralized and automated management of network devices.

Procedure

1.

Enable gRPC over an HTTP/2 connection.

Router#configure
Router(config)#grpc
Router(config-grpc)#port <port-number>

Port numbers range from 57344 to 57999. If the specified port number is unavailable, the system displays an error message.
2.

Configure the session parameters.

Router(config)#grpc{ address-family | dscp | max-request-per-user | max-request-total | 
max-streams | max-streams-per-user | no-tls | service-layer | tls-cipher | tls-trustpoint
| vrf }
Note

For gNMI device configuration, Crosswork Data Gateway supports server-side authentication only. The device validates the Data Gateway certificate, but the Data Gateway does not validate a client certificate from the device. Therefore, mutual TLS authentication is not supported for gNMI collectors.

Table 7. Parameters for gNMI session configuration

Parameters

Description

address-family

Configure the address family identifier type.

dscp

Configure the QoS marking DSCP on transmitted gRPC.

max-request-per-user

Configure the maximum concurrent requests per user.

max-request-total

Configure the maximum concurrent requests in total.

max-streams

Configure the maximum number of concurrent gRPC requests. The maximum subscription limit is 128 requests. The default is 32 requests.

max-streams-per-user

Configure the maximum concurrent gRPC requests for each user. The maximum subscription limit is 128 requests. The default is 32 requests.

no-tls

Disable transport layer security (TLS). The TLS is enabled by default.

service-layer

Enable the gRPC service layer configuration.

tls-cipher

Enable the gRPC TLS cipher suites.

tls-trustpoint

Configure a trustpoint.

server-vrf

Enable the server VRF.
3.

Enable Traffic Protection for Third-Party Applications (TPA).

tpa
vrf default
address-family ipv4
default-route mgmt
update-source dataports MgmtEth0/RP0/CPU0/0

Configurations for Cisco IOS XE devices

This example shows how to enable the gNMI server in insecure mode.

Device# configure terminal
Device(config)# gnmi-yang
Device(config)# gnmi-yang server
Device(config)# gnmi-yang port 50000 <The default port is 50052.>
Device(config)# end
Device

The example shows how to enable the gNMI server in secure mode.

Device# configure terminal
Device(config)# gnmi-yang server
Device(config)# gnmi-yang secure-server
Device(config)# gnmi-yang secure-trustpoint trustpoint1
Device(config)# gnmi-yang secure-client-auth
Device(config)# gnmi-yang secure-port 50001 <The default port is 50051.>
Device(config)# end
Device

Configure gNMI bundling for IOS XR

In IOS XR, gNMI bundling collects multiple Update messages within the Notification message of a SubscribeResponse. These messages are delivered to the IOS XR device. To use gNMI bundling, you must enable it and set the message size.

Before you begin

Be aware of these points:

  • IOS XR release versions 7.81 and later support the gNMI bundling capability. For more information about how the bundling feature works, see Programmability Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.8.x.

  • The gNMI bundling capability can only be configured from the device. This option is not available in the Crosswork Interface.

  • Crosswork Data Gateway supports server-side authentication for gNMI device configuration. The mutual TLS authentication is not supported for gNMI collectors.

Procedure

1.

Enable the bundling feature using the following command:

telemetry model-driven
 gnmi
  bundling
The gNMI bundling capability is disabled by default.
2.

Specify the gNMI bundling size using the following command:


 telemetry model-driven gnmi bundling size <1024-65536>
The default bundling size is 32768 bytes.
Note

After processing the (N - 1) instance, if the message size is smaller than the bundling size, the system may add another instance. This can cause the total size to exceed the bundling limit.

What to do next

Verify that the bundling capability is configured using the configuration.

RP/0/RP0/CPU0:R0(config)#telemetry model-driven
RP/0/RP0/CPU0:R0(config-model-driven)#gnmi ?
  bundling   gNMI bundling of telemetry updates
  heartbeat  gNMI heartbeat
  <cr>
RP/0/RP0/CPU0:R0(config-model-driven)#gnmi bundling ?
  size  gNMI bundling size (default: 32768)
  <cr>
RP/0/RP0/CPU0:R0(config-model-driven)#gnmi bundling
RP/0/RP0/CPU0:R0(config-gnmi-bdl)#size ?
  <1024-65536>  gNMI bundling size (bytes)