Network Management and Monitoring

Support for the gRPC Network Operations Interface (gNOI) CertificateManagement service (PTX10008 and PTX10016)—Starting in Release 22.2R1, Junos OS Evolved devices support gRPC Network Operations Interface services. You can execute supported CertificateManagement service remote procedure calls (RPCs) to manage certificates on the network device. Using gNOI operations enables you to use the same suite of microservices to efficiently manage large-scale multivendor networks.

[See gNOI Certificate Management Service.]

Support for the gRPC Network Operations Interface (gNOI) diag service (PTX1004, PTX10008, and PTX10016)—Starting in Release 22.2R1, Junos OS Evolved devices support gRPC Network Operations Interface services. You can execute supported Diag service remote procedure calls (RPCs) to perform diagnostic operations such as bit error rate tests (BERTs) on the network device. Using gNOI operations enables you to use the same suite of microservices to efficiently manage large-scale multivendor networks.

[See gNOI Diagnostic (Diag) Service.]

Support for the gRPC Network Operations Interface (gNOI) file, os, and system services (PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016)—Starting in Release 22.2R1, Junos OS Evolved devices support gRPC Network Operations Interface services. You can execute supported File, OS, and System service remote procedure calls (RPCs) to perform common file and system operations on the network device. Using gNOI operations enables you to use the same suite of microservices to efficiently manage large-scale multivendor networks.

[See gNOI File Service, gNOI Operating System (OS) Service, and gNOI System Service.]

Support for YANG metadata annotations for configuration operations (PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.2R1, we provide the junos-configuration-metadata YANG module. This module defines metadata annotations that you can use to perform specific configuration operations in YANG-compliant NETCONF sessions. Supported operations include adding comments to the configuration, deactivating and activating configuration statements, and protecting and unprotecting configuration statements.

[See YANG Metadata Annotations for Junos Devices .]

Support for additional family in port mirroring (PTX10001-36MR; LC1201 and LC1202 line cards in PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.2R1, you can configure family any (as well as the earlier family options, inet and inet6) for local port mirroring and remote port mirroring:

• Family any (for family any, ccc, ethernet-switching, or mpls)

The following configuration statements are no longer part of the port mirroring configuration on PTX: next-hop for family any; family vpls; no-filter-check; hosted-service; server-profile.

[See Example: Configure Port Mirroring with Family any and a Firewall Filter.]

gRIBI Flush() remote procedure call (RPC) support (PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.2R1, these devices support the gRPC Routing Information Base Interface (gRIBI) Flush() RPC. The Flush() RPC removes all the server's gRIBI programmed routes that match what is described in the FlushRequest message. Sending a Flush() request is a quick and easy way to delete gRIBI programmed routes from the server.

[See gRIBI.]

gRIBI API enhancements (PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.2R1, we offer enhanced support for the gRPC Routing Information Base Interface (gRIBI) API including:

• The gRIBI client only programs an IPv4Entry AFT entry on the server after it receives acknowledgments from the server that the server received the associated NextHopGroup and NextHop messages. If the client programs an IPv4Entry AFT entry on the server without the NextHopGroup message, it adds the route to the server as a hidden route.

• You can now perform hierarchical lookups by using the IPv4Entry AFT entry to program IP-IP tunnel endpoints and site group virtual IP address routes.
• We now support arbitration when multiple clients are connected to the gRIBI server.

[See gRIBI.]

gRIBI RIB-FIB acknowledgment (PTX10008)—Starting in Junos OS Evolved Release 22.2R1, the Packet Forwarding Engine sends an acknowledgment when you successfully program a route in the Packet Forwarding Engine using the gRPC Routing Information Base Interface (gRIBI) API. When the gRIBI API fails to program a route in the Packet Forwarding Engine after a timeout period passes, the Packet Forwarding Engine sends an error message. You can configure the length of this timeout. The acknowledgment is only valid for the most recent route. If an older route sends an acknowledgment but the new route does not, the Packet Forwarding Engine records the acknowledgment as an error.

Use the show route extensive command to display the acknowledgment status. The acknowledgment status is persistent across rpd process restarts.

[See gRIBI.]

gRIBI API route reconciliation and recovery after client reconnection (PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.2R1, we have enhanced the gRPC Routing Information Base Interface (gRIBI) API to better recover routes after the gRIBI server or rpd process goes down. When the client reconnects to the server, the client automatically sends a gRIBI Get() RPC request to the server. If GRES is configured, the client reconciles the routes on the server. If the client sends another Get() RPC request, the answering GetResponse response stream includes the active reconciled routes on the server.

If you configure GRES but do not configure non-stop routing, the gRIBI API also recovers routes after a Routing Engine switchover.

[See gRIBI.]

gRIBI support for fallback to default route in VRF instance (PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.2R1, you can use the gRPC Routing Information Base Interface (gRIBI) API to program a default route in a traffic engineering virtual routing and forwarding (VRF) instance as the backup route. Traffic falls back to this backup route when all other routes are unavailable, which prevents traffic loss. This default route has a next hop with decapsulation and looks up routes in the default VRF. Add the default route to the VRF first so the future routes you configure in the VRF will use it as a fallback route.

[See gRIBI.]

gRIBI enhancements for IP-in-IP tunneling (PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.2R1, the gRPC Routing Information Base Interface (gRIBI) API supports IP-in-IP encapsulation. Set the backup_next_hop_group field in the NextHopGroup message to perform decapsulation and look up routes in other routing instances. You can program a service route using multiple IP-IP tunnel endpoints.

[See gRIBI.]

gRIBI support for automatic tunnel fallback (PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.2R1, you can use the gRPC Routing Information Base Interface (gRIBI) API to program backup tunnels for automatic fallback. Use the gRIBI Modify() remote procedure call (RPC) to program a backup next-hop group. If the primary tunnel goes down, the device automatically switches the traffic to this backup tunnel. Automatic fallback quickly reroutes traffic to reduce traffic loss. This feature supports IPv4 transport for dynamic IP-IP tunnels with an IPv4 or IPv6 payload.

Use the PolicyForwardingEntry message to program policy-based forwarding on the gRIBI server. Policy-based forwarding ensures that traffic moved to the backup tunnel remains in the tunnel regardless of what the routing table says.

[See gRIBI.]