Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Junos Telemetry Interface

Note:

For Routing Engine telemetry sensors supported by this platform, see Telemetry Sensor Explorer. If any Platform Forwarding Engine sensors have been added for this release, they are listed below

  • End-of-message notification for Routing Engine sensors (EX2300, EX4300, EX4300-MP, EX9200, MX240, MX960, MX10016, MX2010, MX2020, PTX1000, PTX3000, PTX10001, QFX5100, QFX5110, QFX5120, and QFX10002)—Starting in Junos OS Release 21.2R1, we've introduced an end-of-message (EoM) Boolean flag for all Junos telemetry interface (JTI) Routing Engine sensors. The flag notifies the collector that the current wrap has completed for a particular sensor path. A wrap is a complete key-value data dump for all the leaves under a sensor path.

    The EoM flag also enables the collector to detect when the end of wrap occurs without having to compare stream creation timestamp values that the collector receives from the packets. Comparing timestamp values is costly time-wise and delays data aggregation.

    To use this feature with gRPC Network Management Interface (gNMI) transport or Remote Procedure Call (gRPC), retrieve the protobuf files from the relevant branch on the Juniper Networks download site:

    • GnmiJuniperTelemetryHeaderExtension.proto (gNMI)
    • agent.proto (for gRPC)

    For example: https://github.com/Juniper/telemetry/blob/master/20.3/20.3R1/protos/GnmiJuniperTelemetryHeaderExtension.proto.

    After you download and install the new protobuf files on a collector, the EoM field is present in the packets received.

    [See Understanding OpenConfig and gRPC on Junos Telemetry Interface.]

  • CoS sensor support (MX204, MX240, MX960, MX2010, MX2020, MX10003, MX10008, MX10016, MX-ELM and vMX)

    Starting in Junos OS Release 21.2R1, we support the following streaming sensors with Junos telemetry interface (JTI).

    • Interface queue extended statistics Packet Forwarding Engine sensors supported with Remote Procedure Call (gRPC): /interfaces/interface/state/counters/out-queue/lp-red-drop-pkts, /interfaces/interface/state/counters/out-queue/hp-red-drop-pkts, /interfaces/interface/state/counters/out-queue/queued-pkts, and /interfaces/interface/state/counters/out-queue/queued-bytes.
    • CoS interface set description Routing Engine sensor supported with gRPC: /qos/interfaces/interface/state/interface-id.
    • Forwarding class to queue mapping Routing Engine sensors supported with gRPC: /qos/forwarding-groups/forwarding-group/state/name and /qos/forwarding-groups/forwarding-group/state/output-queue.
    • Interface extended statistics sensor with native (UDP) support: /junos/system/linecard/interface/queue/extended-stats/.

    [See sensor (Junos Telemetry Interface) and Guidelines for gRPC and gNMI Sensors (Junos Telemetry Interface)].

  • Monitoring and optimizing Packet Forwarding Engine sensor data export (PTX Series and QFX Series)—Starting in Junos OS Release 21.2R1, you can optimize Packet Forwarding Engine sensor data to dynamically determine how to export data as quickly as possible based on three sensor categories: heavy data (dynamic scale), medium data (predicted scale), and low data (fixed scale). In addition, you can use our new sensor to retrieve export details of all Packet Forwarding Engine sensors. Use the resource path /junos/system/linecard/export/monitor to monitor export details for each subscribed Packet Forwarding Engine sensor including:

    • Number of reaps
    • Number of wraps (a complete data set)
    • Number of packets sent
    • Average number of reaps and wraps
    • Timestamps for reaps and wraps

    [See Understanding OpenConfig and gRPC on Junos Telemetry Interface and Guidelines for gRPC and gNMI Sensors (Junos Telemetry Interface).]

  • Enable VOQ utilization monitoring with JTI (PTX1000, PTX5000, PTX10000, QFX10002, QFX10008, and QFX10016)—Starting in Junos OS Release 21.2R1, you can enable the enable the export utilization data for CoS virtual output queues (VOQs) on aggregated Ethernet or physical Ethernet WAN interfaces. Using this feature, you can export peak buffer utilization data for a given queue with Junos telemetry interface (JTI). Monitoring this data can assist in preventing micro-bursts and high buffer utilization for a given queue because peak buffer utilization is transient and might not be reported by instantaneous queue depth.

    To enable monitoring, include queue-monitoring enable at one of the following hierarchies:

    • [edit class-of-service interfaces if-name]
    • [edit class-of-service traffic-control-profiles tcp-name]
    • [edit class-of-service schedulers scheduler-name]

    To export data to a collector, include the resource path /junos/system/linecard/qmon-sw in a subscription.

    [See queue-monitoring, show class-of-service interface, show class-of-service traffic-control-profile , show class-of-service scheduler-map and show interfaces voq interface-name.]

  • New Packet Forwarding Engine core CPU utilization sensor (SRX1500, SRX4100, SRX4200, SRX4600, and vSRX)—Starting in Junos OS Release 21.2R1, you can stream Packet Forwarding Engine core CPU utilization sensor data using Junos telemetry interface (JTI) and Remote Procedure Calls (gRPC) to an outside collector.

    To access this sensor, use the resource path /junos/security/spu/cpu/usage/ in subscriptions.

    [See Guidelines for gRPC and gNMI Sensors (Junos Telemetry Interface).]

  • JTI: logical interface statistics for IPv4 and IPv6 family input and output counters (MX Series and PTX Series routers using third-generation FPCs)—Starting in Junos OS Release 21.2R1, you can stream per-family logical interface statistics for IPv4 and IPv6 traffic using Junos telemetry interface (JTI) and Remote Procedure Calls (gRPC) to an outside collector.

    To access these sensors, use the resource paths /junos/system/linecard/interface/logical/family/ipv4/usage/ and /junos/system/linecard/interface/logical/family/ipv6/usage/ in a subscription.

    [See Guidelines for gRPC and gNMI Sensors (Junos Telemetry Interface).]

  • Secure packet capture to cloud (EX4400)—Starting in Junos OS Release 21.2R1, we support secure packet capture using Junos telemetry interface (JTI). You can use this feature to capture packets from a device and send them over a secure channel to an external collector (in the cloud) for monitoring and analysis. The maximum size of the packet you can capture is 128 bytes, including the packet header and the data within. Network professionals use real-time packet capture data to troubleshoot complex issues such as network and performance degradation and poor end-user experience.

    To use secure packet capture, include the /junos/system/linecard/packet-capture resource path using a Junos RPC call.

    For ingress packet capture, include the packet-capture option in the existing firewall filter configuration at the [edit firewall family family-name filter filter-name term match-term then packet-capture] hierarchy level. Do this before you send packet capture sensor data to the collector and remove the packet-capture configuration after data is sent to the collector. After the capture is done, ingress packets with the filter match conditions are trapped to the CPU. The trapped packets then go to the collector over a secure channel in JTI-specified format in key-value pairs by means of Remote Procedure Call (gRPC) transport.

    For egress packet capture on physical interfaces (ge-*, xe-*, mge-*, and et-*), include "packet-capture-telemetry," "egress," and "interface <interface-name>" at the [edit forwarding-options] hierarchy level. For example:

    set forwarding-options packet-capture-telemetry egress interface ge-0/0/0

    set forwarding-options packet-capture-telemetry egress interface ge-0/0/10

    You can add multiple interfaces on the device for egress packet capture. When configured, host-bound egress packets are captured from the interface and sent to the collector. As with the ingress configuration, remove the configuration when packet capture is not required.