IOS XE and XR via gNMI dial in - API method only

Provisioning A Telemetry Collector For gNMI Dial In Data Collection

Provider Connectivity Assurance does not currently provide UI level support for provisioning a Telemetry Collector for gNMI Dial In data collection. It is therefore necessary to set this up via direct API calls. This section will walk through the process of doing this.

Initial Provisioning of the Telemetry Collector

Every telemetry collector must have its runtime configuration pre-provisioned in PCA before it can successfully be brought online.

At startup, the telemetry collector will establish its administrative connection with PCA and request its runtime configuration. Until it is able to successfully receive this, it cannot start doing useful work.

Provisioning a Telemetry Collector instance to receive telemetry via gNMI Dial In involves the following steps:

• Generate The Agent/Collector Configuration JSON For Your Collector

  To make life a little easier, a helper API has been created to do the heavy lifting of generating the JSON structure required to provision the runtime configuration for the collector.

  You will need to collect the following information to supply to the API call:

The actual API call should look similar to the following:

POST /api/v3/telemetry-collector-templates/build-agent-configuration

Body:
{
"DataGateway": {
"DataBrokerPort": 55888,
"DataBrokerServer": "1.2.3.4"
},
"AgentName": "my-cisco-xr-collector"
"InputType": "DialIN",
"DataTypes": "XR"
}

This will return a structured JSON response similar to the example below, which represents the actual configuration for your collector.
{
"data": {
"attributes": {
"type": "agentConfigs",
"dataGateway": {
"dataBrokerSslAllowExpiredCerts": false,
"dataBrokerSslAllowInsecureCerts": false,
"dataBrokerSslAllowSelfsigned": false,
"dataBrokerSslSkipHostnameCheck": false,
"dataBrokerUseSsl": false,
"port": 55888,
"server": "1.2.3.4"
},
"identification": {
"agentName": "telem-collector-dial-in"
},
"metadata": {
"name": "telem-collector-dial-in"
},
"telemetry": {
"dataCollection": "",
"templateName": "",
"templateVersion": 0,
"dataInput": "",
"dataInputTemplateName": "",
"dataInputTemplateVersion": 0,
"dataTransformation": "REDACTED - BASE64 BLOB"
"dataTransformationTemplateName": "data-transformation-cisco-ios-xe",
"dataTransformationTemplateVersion": 1
}
}
}
}

We will use this in the next step.

• Provision The Agent/Collector

  Now that you have generated the actual run time configuration for your collector, you need to provision it. This is accomplished via a call to:

  POST api/orchestrate/v3/agents/configuration

  cutting and pasting the result from the previous step into the body of your request.

  This will return a result similar to the following:

  {
  "data": {
  "attributes": {
  "_rev": "1-a7eb1648979efac37e276136494d8516",
  "agentId": "ca8614c1-8ce0-4f40-b5ee-2253852fc92f",
  "createdTimestamp": 1747236829611,
  "dataGateway": {
  "dataBrokerSslAllowExpiredCerts": true,
  "dataBrokerSslAllowInsecureCerts": true,
  "dataBrokerSslAllowSelfsigned": true,
  "dataBrokerSslSkipHostnameCheck": true,
  "dataBrokerUseSsl": false,
  "port": 55888,
  "server": "1.2.3.4"
  },
  "identification": {
  "agentName": "my-cisco-xr-collector"
  },
  "lastModifiedTimestamp": 1747236829611,
  "metadata": {
  "name": "my-cisco-xr-collector"
  },
  "telemetry": {
  "dataTransformation": "REDACTED - BASE64 BLOB"
  "dataTransformationTemplateName": "data-transformation-cisco-ios-xe",
  "dataTransformationTemplateVersion": 1
  }
  },
  "id": "ca8614c1-8ce0-4f40-b5ee-2253852fc92f",
  "type": "agentConfigs"
  }
  }

Note the agentId field. This contains a dynamically generated identifier for your collector. Take note of it as it will be needed later.

At this point you have provisioned your collector in PCA.

At this point you may follow the instructions detailed in Deploying The Agent to deploy your collector instance. It should connect successfully to PCA, although it will not yet be able to produce data (that’s what the next set of steps is for).

Provisioning Targets from which to Collect Telemetry

If you have followed the instructions in the previous section, you now have a Telemetry Collector provisioned for gNMI Dial In data collection, and will have deployed your collector instance.

At this point your collector should be running and connected to PCA, but will not be producing any data. This is because, with gNMI Dial In collection (as opposed to the other supported mode, gNMI Dial Out), the collector must be told what data sources it is expected to subscribe to receive telemetry from and which sensor paths it is expected to subscribe to.

This is accomplished by provisioning ‘sessions’ against your collector, where in this context, a ‘session’ defines an individual telemetry stream for the collector to subscribe to (or to put this another way, each session represents a device we want to receive telemetry from)

Each collector may be provisioned with multiple ‘sessions’ (or data sources) in order to receive telemetry from multiple devices, and may subscribe to a different set of sensor paths for each device.

As with the global collector provisioning, a helper API has been provided to perform the heavy lifting of producing the JSON payload for each session to be added to your collector.

The following set of steps should be executed for each data source that you want your collector to stream telemetry from:

• Generating A Session JSON Payload

  You will need to collect the following information to provide to the API call for creating your session configuration: