close

keyboard_arrow_left

Table of Contents Expand all

play_arrow Overview
- play_arrow NETCONF XML Management Protocol Overview
  - NETCONF XML Management Protocol and Junos XML API Overview
  - Advantages of Using the NETCONF XML Management Protocol and Junos XML API
- play_arrow NETCONF and Junos XML Tags Overview
play_arrow Manage NETCONF Sessions
- play_arrow NETCONF Session Overview
- play_arrow Manage NETCONF Sessions
- play_arrow NETCONF Tracing Operations
  - NETCONF and Junos XML Protocol Tracing Operations Overview
  - Example: Trace NETCONF and Junos XML Protocol Session Operations
- play_arrow NETCONF Protocol Operations and Attributes
- play_arrow NETCONF Request and Response Tags
- play_arrow Junos XML Protocol Elements Supported in NETCONF Sessions
- play_arrow Junos XML Protocol Element Attributes Supported in NETCONF Sessions
play_arrow Manage Configurations Using NETCONF
play_arrow Request Operational and Configuration Information Using NETCONF
- play_arrow Request Operational Information Using NETCONF
  - Request Operational Information Using NETCONF
  - Specify the Output Format for Operational Information Requests in a NETCONF Session
- play_arrow Request Configuration Information Using NETCONF
play_arrow NETCONF Utilities
- play_arrow NETCONF Perl Client
  - Understanding the NETCONF Perl Client and Sample Scripts
  - Install the NETCONF Perl Client
- play_arrow Develop NETCONF Perl Client Applications
play_arrow YANG
- play_arrow YANG Overview
- play_arrow Create and Use Non-Native YANG Modules
play_arrow OpenDaylight Integration
- play_arrow Configure OpenDaylight Integration
  - Configure Interoperability Between MX Series Routers and OpenDaylight
play_arrow Configuration Statements and Operational Commands
- Junos CLI Reference Overview

list Table of Contents

English

Configure a NETCONF Proxy Telemetry Sensor in Junos

date_range 11-Dec-24

arrow_backward

arrow_forward

Using Junos telemetry streaming, you can turn any available state information into a telemetry sensor by means of the XML Proxy functionality. The NETCONF XML management protocol and Junos XML API fully document all options for every supported Junos OS operational request. After you configure XML proxy sensors, you can access data over NETCONF “get” remote procedure calls (RPCs).

This task shows you how to stream the output of a Junos OS operational mode command.

Best Practice:

We recommend not to use YANG files that map to a Junos OS operational command with extensive or verbose output or one that is slow in producing output. Commands with a noticeable delay should be avoided in YANG files. Including such commands can affect other xmlproxyd sensors as well as the performance of xmlproxyd.

The output from some operational mode commands is dynamic and the level of their verbosity depends on factors such as the configuration and hardware. Examples of such commands include any variation of show interfaces, show route, show arp, show bfd, show bgp, and show ddos-protection.

To check the verbosity level of a command, issue the command-name| display xml | count command. If the line count exceeds a value of 4000 lines, then the command is not recommended for XML proxy streaming. This value is more of an approximation based on internal base-lining. It can be less depending upon various factors such as device type, processing power of the device, and the existing CPU load. Consequently, this feature needs to be used judiciously based on how the device is performing.

You can issue the command command-name| display xml before using a YANG file that maps to a Junos OS or Junos OS Evolved operational mode command to verify that the command produces valid XML output and does not contain invalid tags, data, or formatting.

Using a YANG file that maps to a verbose command results in one or more of following:

The xmlproxyd process CPU utilization remains high. If xmlproxyd has tracing enabled, the CPU utilization is even higher.
An increase in the xmlproxyd process memory utilization.
The xmlproxyd process state may show sbwait, indicating that the command output is verbose and that xmlproxyd is spending significant time reading the command's remote procedure call’s (RPC’s) output.
The xmlproxyd sensor data does not complete the wrap.
The xmlproxyd streams partial or no data for the sensors.
The xmlproxyd misses reporting-interval cycles. The intervals start to overlap because of a command’s verbose output, resulting in the xmlproxyd's sensor streaming data that is slow or delayed.
The process or application that serves the verbose command's RPC may show high CPU numbers or delays in performing main tasks. This behavior is caused when the process or application is busy serving the RPC that has verbose output.

This task requires the following:

An MX Series, vMX Series, or PTX Series router operating Junos OS Release 17.3R2 or later.
Installation of the required Network Agent package ( network-agent-x86–32–17.4R1.16-C1.tgz or later).
A telemetry data receiver, such as OpenNTI, to verify proper operation of your telemetry sensor.

In this task, you will stream the contents of the Junos OS command show system users.

show system users (vMX Series)

content_copy zoom_out_map
user@switch> show system users
USER     TTY      FROM                              LOGIN@  IDLE WHAT
user1   pts/0       172.31.12.36                    12:40PM     39 -cli (cli)    
user2   pts/1       172,16.03.25                     3:01AM      - -cli (cli)    

In addition to the expected list of currently logged-in users, the show system users output also provides the average system load as 1, 5 and 15 minutes. You can find the load averages by using the show system users | display xml command to view the XML tagging for the output fields. See <load-average-1>, <load-average-5>, and <load-average-15> in the XML tagging output below.

content_copy zoom_out_map
user@switch> show system users | display xml

<rpc-reply xmlns:junos="http://xml.juniper.net/junos/17.4R1/junos">
    <system-users-information xmlns="http://xml.juniper.net/junos/17.4R1/junos">
        <uptime-information>
            <date-time junos:seconds="1520170982">1:43PM</date-time>
            <up-time junos:seconds="86460">1 day, 40 mins</up-time>
            <active-user-count junos:format="2 users">2</active-user-count>
            <load-average-1>0.70</load-average-1>
            <load-average-5>0.58</load-average-5>
            <load-average-15>0.55</load-average-15>
            <user-table>
                <user-entry>
                    <user>root</user>
                    <tty>pts/0</tty>
                    <from>172.21.0.1</from>
                    <login-time junos:seconds="1520167202">12:40PM</login-time>
                    <idle-time junos:seconds="0">-</idle-time>
                    <command>cli</command>
                </user-entry>
                <user-entry>
                    <user>mwiget</user>
                    <tty>pts/1</tty>
                    <from>66.129.241.10</from>
                    <login-time junos:seconds="1520170862">1:41PM</login-time>
                    <idle-time junos:seconds="60">1</idle-time>
                    <command>cli</command>
                </user-entry>
            </user-table>
        </uptime-information>
    </system-users-information>
    <cli>
        <banner></banner>
    </cli>
</rpc-reply>

Tip:

The uptime-information tag shown in the preceding output is a container that contains leafs, such as date-time, up-time, active-user-count. and load-average-1. Below is a sample YANG file for this container:

content_copy zoom_out_map
container uptime-information { 
      dr:source "uptime-information"; // Exact name of the XML tag
      leaf date-time { // YANG model leaf
        type string; // Type of value
        dr:source date-time; // Exact name of the XML tag
      }
      leaf up-time { // YANG model leaf
        type string; // Type of value
        dr:source up-time; // Exact name of the XML tag
      }
      leaf active-user-count { // YANG model leaf
        type int32; // Type of value
        dr:source active-user-count; // Exact name of the XML tag
      }
      leaf load-average-1 { // YANG model leaf
        type string; // Type of value
        dr:source load-average-1; // Exact name of the XML tag
      }
      ...

Tip:

The uptime-information tag also has another container named user-table that contains a list of user entries.

Below is a sample YANG file for this container:

content_copy zoom_out_map
container user-table { // "user-table" container which contains list of user-entry
        dr:source "user-table"; // Exact name of the XML tag
        list user-entry { // "user-entry" list which contains the users' details in form of leafs
          key "user"; // Key for the list "user-entry" which is a leaf in the list "user-entry"
          dr:source "user-entry"; // Source of the list "user-entry" which is the exact name of the XML tag
          leaf user { // YANG model leaf
            dr:source user; // A leaf in the list "user-entry", exact name of the XML tag
            type string; // Type of value
          }
          leaf tty { // YANG model leaf
            dr:source tty; // A leaf in the list "user-entry", exact name of the XML tag
            type string; // Type of value
          }
          leaf from { // YANG model leaf
            dr:source from; // A leaf in the list "user-entry", exact name of the XML tag
            type string; // Type of value
          }
          leaf login-time { // YANG model leaf
            dr:source login-time; // A leaf in the list "user-entry", exact name of the XML tag
            type string; // Type of value
          }
          leaf idle-time { // YANG model leaf
            dr:source idle-time; // A leaf in the list "user-entry", exact name of the XML tag
            type string; // Type of value
          }
          leaf command { // YANG model leaf
            dr:source command; // A leaf in the list "user-entry", exact name of the XML tag
            type string; // Type of value
          }
        }
      }
      
      

Create a User-Defined YANG File

The YANG file defines the Junos CLI command to be executed, the resource path the sensors are placed under, and the key value pairs taken from the matching XML tags.

Custom YANG files for Junos OS conform to the YANG language syntax defined in RFC 6020 YANG 1.0 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) and RFC 7950 The YANG 1.1 Data Modeling Language. Certain directives need to be present in the file that configure XML proxy.

To use the xmlproxyd (daemon) process to translate telemetry data, create a render.yang file. In this file, the dr:command-app is set to xmlproxyd.

The XML proxy YANG filename and module name must start with xmlproxyd_:

For the XML proxy YANG filename, add the extension .yang, for example, xmlproxyd_sysusers.yang
For the module name, use the filename without the extension .yang, for example, xmlproxyd_sysusers

To simplify creating a YANG file, it’s easiest to start by modifying a working example.

Provide a name for the module. The module name must start with xmlproxyd_ and be the same name as the XML proxy YANG file name.
For example, for an XML proxy YANG file called sysusers.yang, drop the .yang extension and name the module xmlproxyd_sysusers:

module xmlproxyd_sysusers {
For the Junos telemetry interface, include the process (daemon) name xmlproxyd:
dr:command-app "xmlproxyd";
Include the following RPC for the NETCONF get request:
rpc juniper-netconf-get {
Specify the location of the output of the RPC, where company-name is the name you give to the location:
dr:command-top-of-output "/company-name";
Include the following command to execute the RPC:
dr:command-full-name "drend juniper-netconf-get";
Specify the CLI command from which to retrieve data. The Junos OS CLI command that gets executed at the requested sample frequency is defined under dr:cli-command and executed by the xmlproxyd daemon.
To retrieve command output for the Junos OS command show system users:

dr:cli-command "show system users";
Escalate privileges, logon as “root”, connect to the internal management socket via Telnet, and specify help for an RPC:
dr: command-help “default <get> rpc”;

When this is included in the YANG file, output that is helpful for debugging is displayed in the help drend output on the internal management socket:
```
telnet /var/run/xmlproxyd_mgmt
Trying /var/run/xmlproxyd_mgmt...
Connected to /var/run/xmlproxyd_mgmt.
Escape character is '^]'.
220 XMLPROXYD release 18.2I20180412_0904_bijchand built by bijchand on 2018-04-12 14:48:48 UTC
help drend
```
200-juniper-netconf-get-0 system users <get> RPC
Specify the hierarchy and use the dr:source command to map to a container, a list, or a specific leaf. The absolute path under which the sensors will be reported is built from the output group junos plus system-users-information, concatenated by /’. The path /junos/system-users-information/ is the path to query for information about this custom sensor.
Warning:
You should not create a custom YANG model that conflicts or overlaps with predefined native paths (Juniper defined paths) and OpenConfig paths (resources). Doing so can result in undefined behavior.

For example, do not create a model that defines new leafs at or augments nodes for resource paths such as /junos/system/linecard/firewallor /interfaces.
A one-to-one mapping between container, leafs and the XML tag or value from the CLI command output is defined in the grouping referenced by uses within the output container. A grouping can be referred to multiple times in different container outputs. The container system-users-information below uses the grouping system-users-information. However, it is defined without the aforementioned one-to-one mapping for every container, list and leaf to an output XML tag from the CLI command XML output.
```
output {
    container junos {
        container system-users-information {
            dr:source "/system-users-information“;
            uses system-users-information-grouping;
        }
    }
}
```

The following YANG file shows how to include these commands to enable the xmlproxyd process to retrieve the full operational state and map it to the leafs in Juniper’s own data model:

content_copy zoom_out_map
*/


/*
 * Example yang for generating OpenConfig equivalent of show system users
 */

module xmlproxyd_sysusers {
  yang-version 1;

  namespace "http://juniper.net/yang/software";

  import drend {
    prefix dr;
  }

  grouping system-users-information-grouping {
    container uptime-information {
      dr:source "uptime-information";
      leaf date-time {
        type string;
        dr:source date-time;
      }
      leaf up-time {
        type string;
        dr:source up-time;
      }
      leaf active-user-count {
        type int32;
        dr:source active-user-count;
      }
      leaf load-average-1 {
        type string;
        dr:source load-average-1;
      }
      leaf load-average-5 {
        type string;
        dr:source load-average-5;
      }
      leaf load-average-15 {
        type string;
        dr:source load-average-15;
      }
      container user-table {
        dr:source "user-table";
        list user-entry {
          key "user";
          dr:source "user-entry";
          leaf user {
            dr:source user;
            type string;
          }
          leaf tty {
            dr:source tty;
            type string;
          }
          leaf from {
            dr:source from;
            type string;
          }
          leaf login-time {
            dr:source login-time;
            type string;
          }
          leaf idle-time {
            dr:source idle-time;
            type string;
          }
          leaf command {
            dr:source command;
            type string;
          }
        }
      }
    }
  }

  dr:command-app "xmlproxyd";
  rpc juniper-netconf-get {
    dr:command-top-of-output "/company-name";
    dr:command-full-name "drend juniper-netconf-get";
    dr:cli-command "show system users";
    dr:command-help "default <get> rpc”;
output {
      container company-name {
        container system-users-information {
          dr:source "/system-users-information";
          uses system-users-information-grouping;
        }
      }
    }
  }
}

Load the Yang File in Junos

After the YANG file is complete, upload the YANG file and verify that the module is created.

Upload the YANG file to the router.

request system yang
add package

command.

content_copy zoom_out_map
user@switch> request system yang add package sysusers proxy-xml module xmlproxyd_sysusers.yang
XML proxy YANG module validation for xmlproxyd_sysusers.yang : START
XML proxy YANG module validation for xmlproxyd_sysusers.yang : SUCCESS
JSON generation for xmlproxyd_sysusers.yang : START
JSON generation for xmlproxyd_sysusers.yang: SUCCESS
      

Note:

Starting in Junos OS Release 18.3R1, adding, deleting, or updating YANG packages in configuration mode with the run command is not supported.

Verify that the module (sensor) is registered using the show system yang package sysusers command, where sysusers is the name of the package:
```
user@switch> show system yang package sysusers
Package ID               :sysusers
XML Proxy YANG Module(s) :xmlproxyd_sysusers.yang      
```

Enable gRPC in the Junos OS configuration:

content_copy zoom_out_map
user@switch> set system services extension-service request-response grpc port 32767

Collect Sensor Data

Use your favorite collector to pull the newly created telemetry sensor data from the device.

Consider resource constraints before initiating sensors:

Avoid specifying the same reporting interval for multiple XML proxy sensors.

For PTX10008 routers operating Junos OS Evolved, do not connect more than 10 collectors per router for telemetry RPCs.

Because xmlproxyd performs XML and text processing, a device should only contain XML proxy sensors that execute within the CPU utilization range.

The following instructions use the collector jtimon. For information about jtimon setup, see Junos Telemetry Interface client.

Note:

If a subscription already exists for a sensor and a duplicate subscription is configured, the connection between the collector and the device will close with the error message AlreadyExists.

Create a simple configuration file, here named vmx1.json. Adjust the host IP address and the port, as needed. The path /junos/system-users-information is specified. The freq field is defined in MicroSoft, streaming a new set of key value pairs every 5 seconds. Optionally, you can add multiple paths.

content_copy zoom_out_map
$ cat vmx1.json
{
  "host": "172.16.122.182
  "port": 32767
  "cid": "my-client-id",
  "grpc" : {
    "ws" : 524289
  },
  "paths": {
     {
       "path": "/junos/system-users-information/",
       "freq": 5000
     },
     {
       "path": "/junos/additional-path/",  <-OPTIONAL
       "freq": 5000 
     }
   }
}      

Launch the collector, using either your own compiled file or an automatically built image from Docker Hub. The sample query output below shows the sensor report by path. Every key is sent in human-readable form as an absolute path. In case of lists, the absolute path contains an index in the form of XPATH which is ideal to group values from a (time series) database, such as InfluxDB. For example, the output below shows the path /junos/system-users-information/uptime-information/user-table/user-entry[user='ab']/.

You can terminate the stream of sensor data using Ctrl-C.

content_copy zoom_out_map
$ docker run -tu --rm -v $(PWD):/u mw/jtimon --config vmx1.json --print
gRPC headers from Junos:
  init-response: [response { subscription_id 1} path_list {path: "junos/system-users-information/" sample-frequency: 5000 } ]
  content-type: [application/grpc]
  grpc-accept-encoding: [identity,deflate,gzip]
2018/03/04 17:13:19 system-id vmxdockerlight_vmx1_1
2018/03/04 17:13:19 component_id 65535
2018/03/04 17:13:19 sub_component_id: 0
2018/03/04 17:13:19 path: sensor_1000:/junos/system-users-information/:/junos/system-users-information/
2018/03/04 17:13:19 sequence_number: 16689
2018/03/04 17:13:19 timestamp: 1520183589391
2018/03/04 17:13:19 sync_response: %!d(bool=false) 
2018/03/04 17:13:19 key: __timestamp__
2018/03/04 17:13:19 uint_value: 1520183589391
2018/03/04 17:13:19 key: __junos_re_stream_creation_timestamp--
2018/03/04 17:13:19 uint value: 1520183589372
2018/03/04 17:13:19 key: __junos_re_payload-get_timestamp__
2018/03/04 17:13:19 uint_value: 1520183589390
2018/03/04 17:13:19 key: /junos/system-users-information/uptime-information/date-time
2018/03/04 17:13:19 str-value: 5:13PM
2018/03/04 17:13:19 key: /junos/system-users-inforamtion/uptime-information/up-time
2018/03/04 17:13:19 str-value: 1 day, 4:10
2018/03/04 17:13:19 key: /junos/system-users-information/uptime-information/active-user-count
2018/03/04 17:13:19 int_value: 2
2018/03/04 17:13:19 key: /junos/system-users-inforamtion/uptime-information/load-average-1
2018/03/04 17:13:19 str_value: 0.62
2018/03/04 17:13:19 key: /junos/system-users-information/uptime-information/load-average-5
2018/03/04 17:13:19 str_value: 0.56
2018/03/04 17:13:19 key: /junos/system-users-inforamtion/uptime-information/load-average-15
2018/03/04 17:13:19 str_value: 0.53
2018/03/04 17:13:19 key: __prefix__
2018/03/04 17:13:19 str_value: /junos/system-users-information/uptime-information/user-table/user-entry[user='ab']/
2018/03/04 17:13:19 key: tty
2018/03/04 17:13:19 str_value: pts/1
2018/03/04 17:13:19 key: from
2018/03/04 17:13:19 str-value: 172,16.04.25
2018/03/04 17:13:19 key: login-time
2018/03/04 17:13:19 str_value: 5:12PM
2018/03/04 17:13:19 key: idle-time
2018/03/04 17:13:19 str-value: -
2018/03/04 17:13:19 key: command 
2018/03/04 17:13:19 str_value: -cl
2018/03/04 17:13:19 system_id: vmxdockerlight_vmx1_1
2018/03/04 17:13:19 component_id: 65535   
2018/03/04 17:13:19 sub_component_id: 0
2018/03/04 17:13:19 <output truncated>

The sample query shown below shows two sensor reports per path, then I terminated it with Ctrl-C. Every key is sent in human readable form as an absolute path and in case of lists, contains an index in form of XPATH, ideal to group values from a (time series) database like InfluxDB e.g. /junos/system-users-information/uptime-information/user-table/user-entry[user='ab']/

Verify that the module (sensor) is loaded using the show system yang package sysusers command, where sysusers is the name of the package:
```
user@switch> show system yang package sysusers
Package ID               :sysusers
XML Proxy YANG Module(s) :xmlproxyd_sysusers.yang      
```

Enable gRPC in the Junos OS configuration:

content_copy zoom_out_map
user@switch> set system services extension-service request-response grpc port 32767

Installing a User-Defined YANG File

To add, validate, modify, or delete a user-defined YANG file for XML proxy for the Junos telemetry interface, use the request system yang set of commands from the operational mode:

Specify the name of the XML proxy YANG file and the file path to install it. This command creates a .json file in the /opt/lib/render directory.
```
user@switch> request system yang add package package-name proxy-xml module file-path-name
```
Note:
This command can be performed only on the current routing engine.

To add multiple YANG modules with the request system yang add package package-name proxy-xml module command, enclose the file-path-name in brackets: [ file-path-name 1 file-path-name 2 ]
(Optional) Validate an module before adding it to the router using the request system yang validate proxy-xml module module-name command. .
```
user@switch> request system yang validate proxy-xml module module-name
```
The output XML proxy YANG module validation for xmlproxyd_<module-name> : SUCCESS indicates successful module validation.

Mismatch error sometimes occur. If the command returns the error below, you can eliminate the error by using Junos OS Release 17.3R2 or later:
```
user@switch> request system yang validate proxy-xml module xmlproxyd_sysusers.yang
error: illegal identifier <identifier> , must not start with [xX][mM][lL]
```
(Optional) Update an existing XML proxy YANG file that was previously added.
```
user@switch> request system yang update package-name proxy-xml module file-path-name 
```
Delete an existing XML proxy YANG file.
```
user@switch> request system yang delete package-name
```
Verify that the YANG file has been installed by entering the show system yang package command.
```
user@switch> show system yang package package-name
```

Troubleshoot Telemetry Sensors

Problem

Description

Use the following methods to troubleshoot user-define telemetry sensors:

Execute a tcpdump for the interface your gRPC requests came from (for this task, interface fxp0 was used).
```
user@switch>monitor traffic interface fxp0 no-resolve matching "tcp port 32767"
```
Enable traceoptions using the set services analytics traceoptions flag xmlproxy command. Check the xmlproxyd log file for confirmation of whether the CLI command’s RPC was sent and if a response was received:

Issue the show log xmlproxyd command to show the xmlproxyd log. The value for the field xmlproxy_execute_cli_command: indicates if the RPC was sent or not. The value for the field xmlproxy_build_context indicates the command.

content_copy zoom_out_map
user@switch>show log xmlproxyd 
Mar 4 18:52:46 vmxdockerlight_vmx1_1 clear-log[52495]: logfile cleared
Mar  4 18:52:51 xmlproxy_telemetry_start_streaming: sensor /junos/system-users-information/
Mar  4 18:52:51 xmlproxy_build_context: command show system users merge-tag:
Mar  4 18:52:51 <command format="xml">show system users</command>
Mar  4 18:52:51 xmlproxy_execute_cli_command: Sent RPC..
Mar  4 18:52:51 <system-users-information xmlns="http://xml.juniper.net/junos/17.4R1/junos" xmlns:junos="http://xml.juniper.net/junos/*/junos">
<uptime-information>
<date-time junos:seconds="1520189571">
6:52PM
</date-time>
<up-time junos:seconds="107400">
1 day,  5:50
</up-time>
<active-user-count junos:format="1 users">
1
</active-user-count>
<load-average-1>
0.94
</load-average-1>
<load-average-5>
0.73
</load-average-5>
<load-average-15>
0.65

arrow_backward PREVIOUS Display Valid Command Option and Configuration Statement Values in the CLI for Custom YANG Modules

NEXT arrow_forward Configure Interoperability Between MX Series Routers and OpenDaylight

NETCONF XML Management Protocol Developer Guide

ON THIS PAGE

Configure a NETCONF Proxy Telemetry Sensor in Junos

Create a User-Defined YANG File

Load the Yang File in Junos

Collect Sensor Data

Installing a User-Defined YANG File

Troubleshoot Telemetry Sensors

Problem

Description

Stay in touch

Helped me install or use the product
Accelerated my deployment

Discuss the product with a co-worker
Make a purchase inquiry

NETCONF XML Management Protocol Developer Guide

ON THIS PAGE

Configure a NETCONF Proxy Telemetry Sensor in Junos

Create a User-Defined YANG File

Load the Yang File in Junos

Collect Sensor Data

Installing a User-Defined YANG File

Troubleshoot Telemetry Sensors

Problem

Description

Related Documentation

Stay in touch