Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

What's New

 

This section describes the new features and enhancements to existing features in Junos OS Release 20.3R1 for the MX Series routers.

Hardware

  • We've added the following features to the MX Series routers in Junos OS Release 20.3R1.

    Table 1: Features Supported by MPC10E and MPC11E Line Cards on MX Series Routers

    Feature

    Description

    Interfaces and chassis

    • Support for MS-MPC on the MX2000-SFB3 Switch Fabric Board (SFB). The MS-MPC interoperates with MX2K-MPC11E, MPC9E, MPC8E, and MPC6E Modular Port Concentrators on MX2020 and MX2010 routers.

    • On MX2K-MPC11E line cards, you can configure Port 0 of every PIC as 400GbE ports or 200GbE ports using either QSFP56-DD optics or QSFP28-DD optics. You can channelize each of the 400GbE-capable ports either as four 100GbE interfaces or as two 100GbE interfaces. [See Port Speed on MX2K-MPC11E Overview.]

    General routing

    • Support for IP reassembly on GRE tunnel interfaces on:

      • MPC10E-15C-MRATE and MPC10E-10C-MRATE on MX240, MX480, and MX960 routers.

      • MX2K-MPC11E on MX2010 and MX2020 routers.

      [See Configuring Unicast Tunnels.]

    • Support for Mapping of Address and Port with Encapsulation (MAP-E) and IPv6 rapid deployment (inline 6rd) on:

      • MPC10E-15C-MRATE and MPC10E-10C-MRATE on MX240, MX480, and MX960 routers.

      • MX2K-MPC11E on MX2010 and MX2020 routers.

    [See Configuring Mapping of Address and Port with Encapsulation (MAP-E) and Configuring Inline 6rd.]

    Juniper telemetry interface

    Layer 3 features

    • Support for Layer 3 features. The MX2K-MPC11E interoperates with MS-MPC and MS-MIC-16G on MX2020 and MX2010 routers to support the following Layer 3 features: stateful firewall, NAT, IPsec, real-time performance monitoring (RPM), and MS MPC/MS-MIC-based inline flow monitoring services. [See Adaptive Services Overview.]

    Multicast

    • Support for bidirectional Protocol Independent Multicast (PIM) on MPC10E and MX2K-MPC11E line cards running on MX240, MX480, MX960, MX2010 and MX2020 routers. These routers support GRES with NSR. [See Understanding Bidirectional PIM.]

      Note: Junos OS Release 20.3R1 does not support anycast rendezvous point (RP) functionality and bidirectional PIM over next-generation multicast VPN (MVPN).

    • Support for Automatic Multicast Tunneling (AMT) relay on MPC10E and MX2K-MPC11E line cards running on MX240, MX480, MX960, MX2010, and MX2020 routers for IPv4 traffic. To identify a gateway, AMT relay uses a combination of the device IP address and port. [See Understanding AMT.]

      Note: Junos OS Release 20.3R1 does not support AMT gateway.

    Network management and monitoring

    • Support for monitoring link degradation. You can monitor link degradation of the 10GbE, 40GbE, 100GbE, and 400GbE interfaces on the MX2K-MPC11E line cards. [See Link Degrade Monitoring Overview.]

    • Support for inline continuity check messages (CCM) on MPC10E-10C-MRATE and MPC10E-15C-MRATE line cards. You can configure inline CCM for up MEPs, down MEPs, and MIPs for all current supported topologies. [See Inline Transmission Mode.]

    Security

    • Support for Media Access Control Security (MACsec) on logical interfaces (MPC10E only). VLAN tags are transmitted in cleartext, which allows intermediate switches that are MACsec-unaware to switch the packets based on the VLAN tags. [See Media Access Control Security (MACsec) over WAN.]

    Services applications

    SNMP

    • Support for Junos OS SNMP on MPC10E-15C-MRATE, MPC10E-10C-MRATE, and MX2K-MPC11E line cards for the following multicast LDP MIB tables and objects:

      • mplsMldpInterfaceStatsTable

      • mplsMldpFecUpstreamSessPackets

      • mplsMldpFecUpstreamSessBytes

      • mplsMldpFecUpstreamSessDiscontinuityTime

      [See Standard SNMP MIBs Supported by Junos OS and SNMP MIB Explorer.]

    Subscriber management and services

  • Support for the JNP-SFP-10G-BX10D and JNP-SFP-10G-BX10U bidirectional transceivers (MX240, MX480, MX960, MX2008, MX2010 and MX2020)—Starting in Junos OS Release 20.3R1, the MPC3E-3D-NG (with the MIC3-3D-10XGE-SFPP) and MPC5EQ-100G10G line cards on the MX240, MX480, MX960, MX2008, MX2010 and MX2020 routers support the JNP-SFP-10G-BX10D and JNP-SFP-10G-BX10U bidirectional transceivers.

    [See the Hardware Compatibility Tool (HCT) for details.]

  • Support for the JNP-SFP-10G-BX40D and JNP-SFP-10G-BX40U bidirectional transceivers (MX240, MX480, MX960, MX2008, MX2010 and MX2020)—Starting in Junos OS Release 20.3R1, the MPC3E-3D-NG (with the MIC3-3D-10XGE-SFPP) and MPC5EQ-100G10G line cards on the MX240, MX480, MX960, MX2008, MX2010 and MX2020 routers support the JNP-SFP-10G-BX40D and JNP-SFP-10G-BX40U bidirectional transceivers.

    [See the Hardware Compatibility Tool (HCT) for details.]

Authentication, Authorization, and Accounting

  • Support for TCP authentication option (TCP-AO) for BGP and LDP connections (MX Series and PTX Series)—Starting in Junos OS Release 20.3R1, you can use TCP-AO to authenticate TCP segments exchanged during BGP and LDP sessions. It supports both IPv4 and IPv6 traffic. TCP-AO provides a framework to support multiple stronger algorithms, such as HMAC-SHA1 and AES-128, to create its message digest. TCP-AO supports up to 64 keys that can be used for a BGP or an LDP session. You can configure a new key for a BGP or LDP session during its lifetime without causing any session flap. Each key becomes active based on its configured start time.

    In earlier releases, you could use only the TCP MD5 authentication method. It supports only MD5 algorithm to create its message digest.

    [See TCP Authentication Option (TCP-AO) for BGP and LDP Sessions and authentication-key-chains (TCP-AO).]

Class of Service (CoS)

  • Support for MPLS EXP bits rewrite to all segment labels in segment routing stack (MX Series)—Starting in Junos OS 20.3R1, on segment routing LSPs, creating an EXP rewrite rule for the egress interface on the ingress (provider edge) router imposes the rewrite rule to all transport labels in the stack. As a result, you don't need to configure rewrite rules on every segment in the LSP.

    [See exp.]

EVPN

  • Color-based mapping of EVPN-MPLS and EVPN services over SR-TE (ACX5448, EX9200, MX Series, and vMX)—Starting in Junos OS Release 20.3R1, you can specify a color attribute along with an IP protocol next hop. The color attribute adds another dimension to the resolution of transport tunnels over static colored and BGP segment routing traffic-engineered (SR-TE) label-switched paths (LSPs). This type of resolution is known as the color-IP protocol next-hop resolution. With the color-IP protocol next-hop resolution, you must configure a resolution map and apply it to EVPN-MPLS and EVPN services, which includes E-Line, E-LAN and E-Tree. With this feature, you can enable color-based traffic steering of EVPN-MPLS and EVPN services.

    [See Segment Routing LSP Configuration.]

  • Tunnel endpoint in the PMSI tunnel attribute field for EVPN Type 3 routes (MX Series)—Starting in Junos OS Release 20.3R1, you can set the tunnel endpoint in the Provider Multicast Service Interface (PMSI) tunnel attribute field to use the ingress router’s secondary loopback address. When you configure multiple loopback IP addresses on the local provider edge (PE) router and the primary router ID is not part of the MPLS network, the remote PE router cannot set up a PMSI tunnel route back to the ingress router. To configure the router to use a secondary IP address that is part of the MPLS network, include the pmsi-tunnel-endpoint pmsi-tunnel-endpoint statement at the [edit routing-instances routing-instance-name protocols evpn] hierarchy level for both EVPN and virtual-switch instance types.

    [See evpn. ]

High Availability (HA) and Resiliency

  • Higher scale and performance in RIFT (QFX2000, QFX5100, QFX5110, QFX10000, MX960, and vMX)— Starting in Junos OS Release 20.3R1, we’ve made the following improvements to increase the scalability and performance in Routing in Fat Tree (RIFT):

    • Prefixes in RIFT

    • Peers in RIFT

    • Convergence improvement with RIFT

    • BFD sessions with RIFT

    [See RIFT Overview.]

Interfaces and Chassis

  • Support for local preference when selecting forwarding next hops for load balancing (MX Series)—Starting in Junos OS Release 20.3R1, we’ve expanded support for traffic to prefer local forwarding next hops rather than remote forwarding next hops for equal-cost multipath (ECMP) traffic flows and on aggregated Ethernet and logical tunnel interfaces for the following devices:

    • MX240, MX480, and MX960 routers with MPC10E (MPC10E-15C-MRATE and MPC10E-10C-MRATE)

    • MX2010 and MX2020 routers with MX2K-MPC11E

    To configure local preference:

    • For ECMP traffic flows, include the ecmp-local-bias statement at the [edit forwarding-options load-balance hierarchy level.

    • For aggregated Ethernet interfaces, include the local-bias statement at the [edit interfaces aex aggregated-ether-options] hierarchy level.

    • For logical tunnel interfaces, include the local-bias statement at the [edit interfaces rlt x logical-tunnel-options load-balance] hierarchy level.

    [See ecmp-local-bias, local-bias (aggregated Ethernet), and local-bias (logical tunnel).]

  • Support for QSFP-100G-FR optical transceivers (MX204 and MX10003)—Starting in Junos OS Release 20.3R1, you can use the QSFP-100G-FR optical transceivers in the MX10003 (installed with the JNP-MIC1 or JNP-MIC1-MACSEC MICs) and MX204 routers. You can use the show chassis pic fpc-slot slot pic-slot slot and show chassis hardware commands to view the details of the transceiver.

    Note

    The MX10003 routers with JNP-MIC1-MACSEC do not support unified in-service software upgrade (ISSU). However, the MX10003 routers with JNP-MIC1 support ISSU.

    [See Hardware Compatibility Tool.]

IP Tunneling

  • Support for IP-over-IP next-hop-based tunneling (MX Series, PTX1000, PTX10000, and QFX10000)—Starting in Junos OS Release 20.3R1, we support an IP-over-IP encapsulation to facilitate IP overlay construction over an IP transport network. An IP network contains edge devices and core devices. To achieve higher scale and reliability among these devices, you need to use an overlay encapsulation to logically isolate the core network from the external network that the edge devices interact with. Among other supported encapsulation methods, only IP-over-IP allows transit devices to parse the inner payload and use inner packet fields for hash computation and customer edge devices to route traffic into and out of the tunnel without any throughput reduction. IP-over-IP relies on a next-hop-based infrastructure to support higher scale.

    On MX Series routers, the routing protocol daemon (rpd) sends the encapsulation header with tunnel composite next hop and the Packet Forwarding Engine finds the tunnel destination address and forwards the packet. On PTX Series routers and QFX10000 switches, rpd sends the fully resolved next-hop-based tunnel to the Packet Forwarding Engine. You can either use static configuration or a BGP protocol configuration to distribute routes and signal dynamic tunnels. You can also configure Interface based firewall filters on any transit or egress device with an action to decapsulate IP-IP packets and forward it to the main instance or to a routing-instance as required.

    [See Next-Hop-Based Dynamic Tunneling Using IP-Over-IP Encapsulation.]

  • Support for filter-based decapsulation of IPv4 and IPv6 unicast traffic encapsulated in IPv4 IP-in-IP tunnels (MX Series, PTX1000, PTX10002, and QFX10002)—Junos OS supports decapsulating IPv4 and IPv6 unicast traffic that has been encapsulated in IPv4 IP-in-IP tunnels using firewall filters. If the outer IPv4 header address matches the firewall configuration and the packet has ipip set as the protocol type, then the outer IPv4 header is removed and the packet is routed based on the inner IPv4 or IPv6 address. If the packet does not have the expected ipip header, the packet is dropped.

    Configure this feature using the following CLI statements at the [edit firewall family inet filter filter-name term term-name] hierarchy:

    • from protocol ipip: Set the protocol type as IP-IP.

    • then decapsulate ipip: Decapsulate the IP-IP packet. The inner IP destination address is routed using the inet.0 routing table by default.

    • then decapsulate ipip routing-instance routing-instance-name: Decapsulate the IP-IP packet and route the inner destination address using the specified routing instance.

    Use show firewall to view the configuration.

    [See filter (Firewall Filters) and Configuring IP Tunnel Interfaces.]

Juniper Extension Toolkit

  • Juniper Extension Toolkit (JET) supports BFD Service APIs for routing protocol process (rpd) programmability (MX Series, PTX Series, QFX Series, and vMX)—Starting in Junos OS Release 20.3R1, you can use programmable rpd (prpd) BFD APIs to add, update, and delete BFD sessions and subscribe to BFD events from outside applications. These APIs enable the integration of rpd with software-defined networking (SDN) controllers and increase the flexibility of your network. The prpd BFD APIs support BFD Echo-Lite sessions in single-hop IPv4 and IPv6 modes.

    The following BFD Service APIs are supported:

    • Initialize

    • SessionAdd

    • SessionUpdate

    • SessionDelete

    • SessionDeleteAll

    • Subscribe

    • Unsubscribe

    Use the show bfd session extensive command to view BFD sessions. BFD sessions added through prpd BFD APIs are labeled with PRPD:<session-id> in the client field. The <session-id> is 1 for the first BFD session that is added, 2 for the second, and so on.

    [See show bfd session extensive and JET APIs on Juniper EngNet.]

Junos OS XML, API, and Scripting

  • Support for REST API over nondefault virtual routing and forwarding (VRF) instance (EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—Starting in Junos OS Release 20.3R1, you can execute Junos OS operational commands using the REST API over a nondefault VRF instance. The nondefault VRF instance can be a user-defined instance or the management instance, mgmt_junos.

    The REST API allows you to execute Junos OS operational commands over HTTP(S). If you don’t specify a routing instance, REST API requests are sent over the default routing instance. Use a nondefault VRF instance to improve security and make it easier to troubleshoot.

    Use the routing-instance routing-instance statement at the [edit system services rest] hierarchy level to specify a nondefault VRF instance for REST API requests.

    [See Management Interface in a Nondefault Instance and rest.]

Junos Telemetry Interface

  • EVPN statistics export using JTI (MX240, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10008, MX10016 and vMX routers, EX4300, EX4600, EX4650, EX9200, EX9204, EX9208, EX9214, EX9251, and EX9253 switches)—Starting in Junos OS Release 20.3R1, you can use Junos telemetry interface (JTI) an remote procedure call (gRPC) services to export EVPN statistics from devices to an outside collector.

    Use the following sensors to export EVPN statistics:

    • Sensor for instance level statistics (resource path /network-instances/network-instance[instance-name='name']/protocols/protocol/evpn/)

    • Sensor for route statistics per peer (resource path /network-instances/network-instance[instance-name='name']/protocols/protocol/evpn/peer/)

    • Sensor for Ethernet segment information (resource path /network-instances/network-instance[instance-name='name']/protocols/protocol/evpn/ethernet-segment/). This includes EVPN designated forwarder ON_CHANGE leafs esi and designated-forwarder.

    • Sensor for local interface information (resource path /network-instances/network-instance[instance-name='name']/protocols/protocol/evpn/interfaces/)

    • Sensor for local IRB interface information (resource path /network-instances/network-instance[instance-name='name']/protocols/protocol/evpn/irb-interfaces/)

    • Sensor for global resource counters and current usage (resource path /junos/evpn/evpn-smet-forwarding/)

    • Sensor for EVPN IP prefix (resource path /junos/evpn/l3-context/)

    • Sensor for EVPN IGMP snooping database (type 6) (resource path /network-instances/network-instance[instance-name='name']/protocols/protocol/evpn/sg-db/)

    • Sensor for EVPN IGMP join sync (type 7) ad leave sync (type 8) (resource path /network-instances/network-instance[instance-name='name']/protocols/protocol/evpn/sg-db/sgdb-esi)

    • Sensor to relate selected replicator on AR leaf on QFX5100, QFX5110, QFX5120, and QFX5200 switches (resource path /network-instances/network-instance[instance-name='name']/protocols/protocol/evpn/assisted-replication/)

    • Sensor for EVPN ON_CHANGE notifications (resource path /network-instances/network-instance[instance-name='name']//protocols/protocol/evpn/ethernet-segment)

    • Sensor for overlay VX-LAN tunnel information (resource path /network-instances/network-instance[instance-name='name']/protocols/protocol/evpn/vxlan-tunnel-end-point/). This includes VTEP information ON_CHANGE leafs source_ip_address, remote_ip_address, status, mode, nexthop-index, event-type and source-interface.

    • EVPN MAC table information (resource path /network-instances/network-instance[instance-name='name']/mac_db/entries/entry/)

    • Sensor for MAC-IP or ARP-ND table (resource path /network-instances/network-instance[instance-name='name']/macip_db/entries/entry/)

    • Sensor for MAC-IP ON_CHANGE table information (resource path /network-instances/network-instance[name='name']/macip-table-info/). Statistics include leafs learning, aging-time, table-size, proxy-macip, and num-local-entries.

    • Sensor for MAC-IP ON_CHANGE entry information (resource path /network-instances/network-instance[name='name']/macip-table/entries/entry/). Statistics include leafs ip-address, mac-address, vlan-id and vni.

    • Sensor for bridge domain or VLAN information (resource path /network-instances/network-instance[instance-name='name']/bd/)

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

  • Chassis management configuration and counters support on JTI (MX Series with MPC11E)—Starting in Junos OS Release 20.3R1, Junos telemetry interface (JTI) supports streaming chassis management error (cmerror) configuration and counters to an outside collector using remote procedure calls (gRPC).

    The following base resource paths are supported:

    • /junos/chassis/cmerror/configuration

    • /junos/chassis/cmerror/counters

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

  • Forwarding information base (FIB) sensor support on JTI (MX Series and PTX Series)—Starting in Junos OS Release 20.3R1, you can use the Junos telemetry interface (JTI) and remote procedure calls (gRPC) services to stream or export ON_CHANGE FIB, also known as forwarding table, statistics to outside collectors. This feature supports the OpenConfig YANG model OC-AFT.

    To enable and manage FIB streaming, include the following statements on the client device:

    • set system fib-streaming and delete system fib-streaming statements at the [edit] hierarchy level to launch or terminate the process.

    • set system fib-streaming traceoptions file file-name statement at the [edit] hierarchy level to configure a logging file.

    • set system fib-streaming traceoptions flag flag-name statement at the [edit] hierarchy level to configure various trace parameters.

    • set system fib-streaming traceoptions level level-name statement at the [edit] hierarchy level to configure log levels.

    Use the restart fib-streaming command to restart the process.

    To show information about FIB streaming, use the following operational mode commands on the client device:

    • show fib-streaming

    • show fib-streaming next-hop-groups

    • show fib-streaming next-hops

    • show fib-streaming routes ipv4-unicast

    • show fib-streaming routes ipv6-unicast

    • show fib-streaming routes mpls

    The following table shows supported sensors:

    Table 2: Supported Sensors

    Supported Sensors

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/id

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/state/id

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/state/dscp[]

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/state/next-hop-group

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface/id

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface/state/id

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface/state/interface

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface/state/subinterface

    /network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/prefix

    /network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/prefix

    /network-instances/network-instance/afts/ipv4-unicast/ipv4-entry/state/next-hop-group

    /network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/prefix

    /network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/prefix

    /network-instances/network-instance/afts/ipv6-unicast/ipv6-entry/state/next-hop-group

    /network-instances/network-instance/afts/mpls/label-entry/label

    /network-instances/network-instance/afts/mpls/label-entry/state/label

    /network-instances/network-instance/afts/mpls/label-entry/state/next-hop-group

    /network-instances/network-instance/afts/mpls/label-entry/state/popped-mpls-label-stack

    This leaf reports the same label value in case of pop or swap.

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/id

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/next-hops/nexthop/index

    /network-instances/network-instance/afts/next-hop-groups/next-hop-group/next-hops/nexthop/state/weight

    /network-instances/network-instance/afts/nexthops/nexthop/index

    /network-instances/network-instance/afts/next-hops/next-hop/juniper/state/lsp-id

    This leaf is a new augmentation.

    /network-instances/network-instance/afts/next-hops/next-hop/state/ip-address

    /network-instances/network-instance/afts/next-hops/next-hop/state/mac-address

    /network-instances/network-instance/afts/next-hops/next-hop/state/pushed-mpls-label-stack

    /network-instances/network-instance/afts/next-hops/next-hop/interface-ref/state/interface

    /network-instances/network-instance/afts/next-hops/next-hop/interface-ref/state/subinterface

    /network-instances/network-instance/afts/next-hops/next-hop/juniper/state/mapped-next-hop-index

    This leaf is a new augmentation.

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

  • Support for policy forwarding table sensor on JTI (MX Series and PTX Series)—Starting in Junos OS Release 20.3R1, you can use Junos telemetry interface (JTI) and remote procedure calls (gRPC) services to stream policy forwarding table statistics on MX Series and PTX Series routers to outside collectors. The following resource paths are supported:

    • /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/

    • /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/id

    • /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/state/id

    • /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/state/dscp[]

    • /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/state/next-hop-group

    • /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface

    • /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface/id

    • /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface/state/id

    • /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface/state/interface

    • /network-instances/network-instance/afts/next-hop-groups/next-hop-group/conditional/condition/input-interfaces/input-interface/state/subinterface

    The Junos OS class-of-service (CoS) classifiers do the code-point (CP) to forwarding-class (FC) and loss-priority (LP) mapping. The classifier used depends on the family configured on the logical interface. Devices running Junos OS support the following classifier types:

    • Differentiated Services code point classifier (DSCP)

    • DSCP IPv6

    • MPLS EXP classifier inet-precedence

    • IPv4 precedence classifier

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

  • Support for aggregated Ethernet interface ON_CHANGE with JTI (MX5, MX10, MX40, MX80, MX104, MX150, MX204, MX240, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10008, MX10016, PTX1000, PTX3000, PTX5000, PTX10001-36MR, PTX10002, PTX10003, PTX10008, PTX10016, QFX3500, QFX3600, QFX5100, QFX5110, QFX5120, QFX5130, QFX5200, QFX5210, QFX5220, QFX10002, QFX10008, and QFX10016)—Starting in Junos OS Release 20.3R1, Junos telemetry interface (JTI) supports ON-CHANGE statistics for aggregated Ethernet interfaces for minimum links and member interfaces.

    To export these statistics to an outside collector using remote procedure call (gRPC) services and JTI, include the following resource paths in a subscription:

    • /interfaces/interface/aggregation/state/min-links/

    • /interfaces/interface/aggregation/state/member/

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

  • Increase the speed of telemetry sensor subscription installation (MX Series routers)—Starting in Junos OS Release 20.3R1, Junos telemetry interface (JTI) supports enhancements to increase the sensor subscription installation speed for collectors. Whether a dynamic sensor subscribe or unsubscribe request from a collector uses remote procedure calls (gRPC) services or gRPC Network Management Interface (gNMI) services to make the request, resource paths (sensors) in the request are individually validated and committed. The following enhancements shorten the subscription installation process and time:

    • Validation is no longer done using the ephemeral database’s configuration load operation.

    • Network Agent instead uses information from sensor YANGs and the Packet Forwarding Engine’s internal sensor table to validate the paths in a subscribe or unsubscribe request. Using these sources, Network Agent responds back to the collector with system-accepted paths and completes basic checks before proceeding to commit the request.

    • Network Agent performs a single commit per subscribe or unsubscribe request instead of doing commits for each resource path in a request.

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

  • Support for fabric, optical, and FPC environment sensor on JTI (MX-2010 and MX-2020 routers with MPC11E)—Starting in Junos OS Release 20.3R1, Junos telemetry interface (JTI) supports streaming fabric, optical, and Flexible PIC Concentrator (FPC) environment statistics to an outside collector using remote procedure calls (gRPC).

    The following base resource paths are supported:

    • /junos/system/linecard/optics/

    • /junos/system/linecard/environment/

    • /junos/system/linecard/fabric/

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

Layer 2 Features

Layer 2 VPN

  • Enable or disable control-word for static pseudowire in LDP VPLS instance and BGP VPLS mesh-group (MX Series)—Starting in Junos OS Release 20.3R1, we’ve introduced the control-word and no-control-word options at the [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name neighbor address static] and [edit routing-instances routing-instance-name protocols vpls neighbor address static] hierarchy levels. The control-word configuration requests the other routers to insert a control word between the label stack and the MPLS payload.

    [See control-word and no-control-word.]

Layer 3 Features

  • Support for BGP Layer 3 VPN over IP-IP Tunnel (MX Series, PTX1000, QFX10002, and QFX10008)—Starting in Junos OS Release 20.3R1, we support BGP Layer 3 VPN over IP over IP (IP-IP) tunnels to create a new transport service. IP-IP tunnels terminate into service-layer VRF, so you do not need to use a service label. This feature allows interoperability between the new VRF and traditional VRF, so both types of overlays can coexist in your network. You can use this feature to transition from an MPLS network to an IP fabric core network and to protect your network from distributed denial-of-service (DDoS) attacks.

    To use VPN over an IP-IP tunnel, configure the tunnel-attribute statement at the [edit policy-options policy-statement policy-name term term-name then] or [edit policy-options policy-statement policy-name then] hierarchy level.

    To configure the receiver to program the dynamic tunnel using the tunnel attribute, use the extended-nexthop-tunnel statement at the [edit routing-instances routing-instance-name protocols bgp group group-name family (inet-vpn | inet6-vpn) unicast] hierarchy level.

    [See BGP Layer 3 VPN over IP-IP Tunnels Overview, family (Protocols BGP), policy-statement, vrf-export, and Configuring IP Tunnel Interfaces.]

MPLS

  • New output fields added in the show path-computation-client lsp extensive command (MX Series, PTX Series, and QFX Series)—Starting in Junos OS Release 20.3R1, you’ll see association details such as Association type, ID, and source in the output of the show path-computation-client lsp command when you use the command with the extensive option.

    [See show path-computation-client lsp.]

Multicast

  • Support for virtual tunnels in MVPN (MX240, MX480, and MX960)—Starting in Release 20.3R1, Junos OS supports redundant virtual tunnels (VTs) and fast re-route (FRR) for both active/backup and active/active redundancy models.

    VT interfaces are used in Layer 3 multicast VPNs (MVPN) to facilitate virtual routing and forwarding (VRF) table lookup based on MPLS labels and to provide resiliency.

    [See Resiliency in Multicast L3 VPNs with Redundant Virtual Tunnels.]

Network Management and Monitoring

  • Probe command to query the status of the probed interfaces (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—Starting in Junos OS Release 20.3R1, you can use the probe command to query the status of the probed interface. The proxy interface resides on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected.

    The Probe command helps to capture the interface details such as system statistics, and interface state (active/inactive), irrespective of whether the network family address configured is IPv4 or IPv6 on the probed interfaces.

    To enable the probe command, configure the extended-echo statement under the [edit system] hierarchy.

    [See Using the Probe command.]

  • SNMP support for RIB sharding (MX Series)—Starting in Junos OS Release 20.3R1, you can enable RIB sharding to get network information from BGP MIB-4 and Layer 3 VPN MIB. To enable this feature, configure rib-sharding at the [edit system processes routing bgp] hierarchy level.

    [See Standard SNMP MIBs Supported by Junos OS.]

  • SNMP MIB support for Traffic Load Balancer (MX240, MX480, and MX960)—Starting in Junos OS Release 20.3R1, a new MIB and a few new MIB traps export the statistics of the Traffic Load Balancer application. The new MIB is jnxTLBMIB and the MIB traps are juniperMIB(2636), jnxTraps (4), and jnxTLBNotifications (32).

    [See Enterprise-Specific SNMP MIBs Supported by Junos OS.]

  • Enhancements to sessions over outbound HTTPS (EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—Starting in Junos OS Release 20.3R1, devices running Junos OS with upgraded FreeBSD support the following enhancements to sessions over outbound HTTPS:

    • Connecting to multiple outbound HTTPS clients by configuring one or more clients at the [edit system services outbound-https] hierarchy level

    • Configuring multiple backup gRPC servers for a given outbound HTTPS client

    • Establishing a csh session

    • Establishing multiple, concurrent NETCONF and csh sessions between the device running Junos OS and an outbound HTTPS client

    • Configuring a shared secret that the outbound HTTPS client uses to authenticate the device running Junos OS

    • Authenticating the client using certificate chains in addition to self-signed certificates

    [See NETCONF and Shell Sessions over Outbound HTTPS.]

Next Gen Services

  • GNFs support subscriber services (MX480 and MX960 with MX-SPC3)—Starting in Junos OS Release 20.3R1, guest network functions (GNFs) running Next Gen Services with the MX-SPC3 card support the following subscriber services:

    • Captive portal content delivery (CPCD)

    • Logging and reporting function (LRF)

    • Deep packet inspection (DPI)

    • Junos Subscriber Aware policy and charging enforcement function (PCEF)

    • HTTP content management (HCM)

    Note

    To support the services traffic over abstracted fabric interfaces, a GNF that has an MX-SPC3 card assigned to it must also have a line card linked to it.

    [See MX-SPC3 Services Card.]

  • Support for flow tracing of service sets for Next Gen Services (MX240, MX480, and MX960)—Starting in Junos OS Release 20.3R1, you can perform flow tracing at the service-set level, which reduces file size and avoids having to sift through large files for information about a single service set.

    [See traceoptions (Next Gen Services Service-Set Flow).]

  • Support for port block allocation for Next Gen Services (MX240, MX480, and MX960)—Starting in Junos OS Release 20.3R1, we support port block allocation (PBA) for Next Gen Services. PBA reduces logging in the system by allocating blocks of ports to a subscriber instead of a single port at a time. Subscribers are tracked based on their private IP address and this information is logged in the system logs. However, ports are reused at a high rate, making tracking of subscribers’ usage and activity difficult. PBA enables you to easily track subscribers’ usage and activity.

    [See block-allocation.]

Port Security

  • MACsec on logical interfaces (MX240, MX480, and MX960)—Starting in Junos OS Release 20.3R1, you can configure Media Access Control Security (MACsec) at the logical interface level on the MPC7E-10G line card. This configuration enables multiple MACsec Key Agreement (MKA) sessions on a single physical port. VLAN tags are transmitted in cleartext, which allows intermediate switches that are MACsec-unaware to switch the packets based on the VLAN tags.

    [See Media Access Control Security (MACsec) over WAN.]

  • Timer-based MACsec SAK refresh (MX10003, PTX10001, PTX10003, PTX10008, and PTX10016)—Starting in Junos OS Release 20.3R1, you can configure a timer-based refresh of the secure association key (SAK) on a Media Access Control Security (MACsec)-secured link. The key server generates the SAK and refreshes it periodically. The key server also sets a refresh interval, by default, based on packet counter movement. If the refresh does not occur frequently, this can leave the SAK vulnerable to attack. You can enhance security of the SAK by configuring a shorter timer-based refresh interval.

    [See Understanding Media Access Control Security (MACsec).]

Routing Protocols

  • Support for Implicit filter for default EBGP route propagation behavior without policies (ACX Series, JRR-Series, MX Series, vRR and PTX Series)—Starting in Junos OS Release 20.3R1, we’ve introduced a new configuration hierarchy, defaults ebgp no-policy at the existing [edit protocols bgp] hierarchy level. The configuration option separates the default policy for receive and advertise, into separate clauses (accept, reject, or reject-always) to allow the route propagation behavior of EBGP speakers to vary independently from its default behavior.

    In earlier releases, the default behavior of BGP was to receive and advertise all routes. With the introduction of this feature, the default behavior still remains to “accept” all routes for both receive and advertise, but you also have an option to reject routes by default.

    With the reject configuration, you can reject routes of type inet unicast and inet6 unicast in instance types master, vrf, virtual-router, and non-forwarding. With the reject-always configuration, you can reject all routes from being received or getting advertised, irrespective of address family or instance type. By using this feature, you can control traffic in leaf autonomous systems (AS) and thereby, prevent them from having to accidentally function as transit autonomous systems.

    Note

    The introduction of this implicit filter does not affect the existing deployments that rely on the default behavior.

    [See Implicit Filter for Default EBGP route propagation behavior without policies. and defaults.]

  • TI-LFA SRLG protection and fate-sharing protection for OSPFv2 (MX Series and PTX Series)—Starting in Junos OS Release 20.3R1, you can configure Shared Risk Link Group (SRLG) protection and fate-sharing protection for segment routing to choose a fast reroute path that does not include SRLG links and fate-sharing groups in the topology-independent loop-free alternate (TI-LFA) backup paths to avoid fate-sharing and SRLG failures. This is in addition to existing fast reroute options such as link-protection and node protection for segment routing.

    To enable TI-LFA SRLG protection and fate-sharing protection with segment routing for OSPFv2, include the srlg-protection statement and the fate-sharing-protection statement respectively at the [edit protocols ospf area area-id interface name post-convergence-lfa] hierarchy level.

    [See Topology-Independent Loop-Free Alternate with Segment Routing for OSPF.]

  • BGP sharding for IPv4 and Ipv6 L3VPN, BGP-LU (MX Series, PTX-Series and vRR)—Starting in Release 20.3R1, Junos OS supports BGP sharding and update IO features for these IPv4 and Ipv6 address families:

    • inet-vpn unicast

    • inet-vpn multicast (vrf.inet.2)

    • inet6-vpn unicast

    • inet6-vpn multicast (vrf.inet.2)

    • inet labeled-unicast

    • inet6 labeled-unicast

    To enable BGP sharding, configure rib-sharding at the [edit system processes routing bgp] hierarchy level. Sharding is dependent on the update I/O thread feature. To enable update I/O, configure update-threading at the [edit system processes routing bgp] hierarchy level.

    BGP Sharding is supported only on 64-bit routing protocol process (rpd) where the Routing Engine has at least 4 CPU cores and 16 GB of memory. To enable your device to always use 64-bit mode, use set force-64-bit at [edit system processes routing] hierarchy level. If you configure rib-sharding on a routing engine, RPD creates sharding threads. By default, the number of sharding threads created is the same as the number of CPU cores on the routing engine. Optionally, you can specify the number-of-shards you want to create. To set the number of sharding threads, use set number-of-shards <number-of-shards> at [edit system processes routing bgp rib-sharding] hierarchy level. To set the number of update threads, use set number-of-threads <number-of-threads> at the [edit system processes routing bgp update-threading] hierarchy level. To enable your device to always use 64-bit mode, use set force-64-bit at [edit system processes routing] hierarchy level.

    [See rib-sharding and update-threading.]

  • ECMP next-hop update rate throttling (MX Series, PTX Series, and QFX Series)—Starting in Junos OS Release 20.3R1, you can choose to defer multipath computation for all families during a BGP peering churn. In very large-scale network deployments, during BGP peering churn there is a temporary spike in multipath computation, which takes a toll on the Packet Forwarding Engine resources. This feature allows you to pause the multipath computation and to resume after the peering churn settles down. Note that if there is no BGP peering churn, then multipath computation is not paused.

    To enable the pause option for BGP multipath computation during BGP peering churn, include the pause computation statement at the [edit protocols BGP multipath] hierarchy level.

    [See pause-computation-during-churn.]

  • Support for Faster PFE Acks (MX Series Virtual Chassis)—Starting in Junos OS Release 20.3R1, we support Faster PFE Acks to release Routing Engine kernel resources quicker. This support ensures that resource exhaustion scenarios are avoided

    [See virtual-chassis (MX Series Virtual Chassis). ]

  • Enabling Ifstate, peer infra, and TCP/IP stack parallelization on Virtual chassis (MX240, MX480, MX960, and MX2020)—Starting in Junos OS Release 20.3R1, Virtual Chassis involving the listed MX Series devices support the following BFD features:

    • Ifstate parallelization

    • Peer infra parallelization

    • TCP and IP stack parallelization

    These features are preserved on failover of any chassis when using Virtual Chassis.

    [See Understanding Bidirectional Forwarding Detection (BFD). ]

Segment Routing

  • SRv6 network programming in IS-IS (MX Series with MPC7E, MPC8E and MPC9E line cards)—Starting in Junos OS Release 20.3R1, you can configure segment routing in a core IPv6 network without an MPLS data plane. This feature is useful for service providers whose networks are predominantly IPv6 and have not deployed MPLS. Such networks depend only on the IPv6 headers and header extensions for transmitting data. This feature also benefits networks that need to deploy segment routing traffic through transit routers that do not have segment routing capability yet. In such networks, the SRv6 network programming feature can provide flexibility to leverage segment routing without deploying MPLS.

    To enable SRv6 network programming in an IPv6 domain, include the srv6 statement at the [edit routing-options source-packet-routing] hierarchy level.

    To advertise the Segment Routing Header (SRH) locator with a mapped flexible algorithm, include the algorithm statement at the [edit protocols isis source-packet-routing srv6 locator] hierarchy level.

    To configure a topology-independent loop-free alternate backup path for SRv6 in an IS-IS network, include the transit-srh-insert statement at the [edit protocols isis source-packet-routing srv6] hierarchy level.

    [See How to Enable SRv6 Network Programming in IS-IS Networks.]

  • Support for LDP Tunneling over Segment Routing Traffic Engineering (MX Series, PTX Series, and ACX5448)—Starting in Junos OS Release 20.3R1, you can tunnel LDP LSPs over Segment Routing Traffic Engineering (SR-TE) in your network. Tunneling LDP over SR-TE provides consistency and co-existence of both LDP LSPs and SR-TE LSPs.

    [See Tunneling LDP over SR-TE.]

Services Applications

  • Enhancements to the RFC 2544-based benchmarking tests (MX Series)—Starting in Junos OS Release 20.3R1, we’ve extended support for these tests onto the following devices:

    • MX240, MX480, and MX960 routers with the MPC7E-MRATE or MPC7E-10G line card

    • MX2008, MX2010, and MX2020 routers with the MX2K-MPC8E or MX2K-MPC9E line card

    • MX204 and MX10003 routers

    You can use the RFC 2544 tests to measure and demonstrate the service-level agreement (SLA) parameters before service activation. The tests measure throughput, latency, frame loss rate, and link bursts. This enhancement supports the Layer 2 reflector (ingress direction) for family types bridge and vpls. To set the ingress direction of a test, configure the family bridge or family vpls statement and the direction ingress statement at the [edit services rpm rfc2544-benchmarking tests test-name name] hierarchy level.

    To run the tests, you must configure the reflector function on the corresponding MPC. To configure the reflector function, include the fpc fpc-slot-number slamon-services rfc2544 statement at the [edit chassis] hierarchy level.

    [See Understanding RFC2544-Based Benchmarking Tests on MX Series Routers.]

  • Support for sampling and tunneling performance improvement (MX204)—Starting in release 20.3R1, Junos OS allows fabric-bound packets to take a new fabric loopback path, freeing up the WAN bandwidth and thus improving the sampling and tunneling performance of the router. You can configure fabric-side loopback by using the fabric loopback wan off statement or switch to WAN side by using the fabric loopback wan on statement at the [edit chassis fpc slot-number] hierarchy level. By default, Junos OS uses fabric loopback for the loopback packets.

    [See Tunnel Services Overview and Understanding Inline Active Flow Monitoring.]

  • Support for hardware timestamping of Two-Way Active Measurement Protocol (TWAMP) and real-time performance monitoring (RPM) probe messages (MX10008, MX10016, PTX10008, and PTX10016)—Starting in Junos OS Release 20.3R1, we’ve extended support for hardware timestamping of TWAMP and RPM probe messages. Hardware timestamping is enabled by default for TWAMP, but you must configure it for RPM. You use TWAMP and RPM to measure IP performance between two devices in a network. By configuring hardware timestamping for RPM, you can account for the latency in the communication of probe messages and generate more accurate timers in the Packet Forwarding Engine. To configure hardware timestamping for RPM, include the hardware-timestamping statement at the [edit services rpm probe probe-owner test test-name] hierarchy level.

    [See Understanding Two-Way Active Measurement Protocol on Routers, Understanding Using Probes for Real-Time Performance Monitoring on M, T, PTX and MX Series Routers, and Configuring RPM Timestamping on MX, M, T, and PTX Series Routers and EX Series Switches.]

  • New configuration option for displaying descriptive information of session logs (MX Series)—Starting in Junos OS Release 20.3R1, you can configure an option to display more descriptive information of session logs. You can configure the enable-descriptive-session-syslog statement at the [edit services service-set service-set-name service-set-options] hierarchy level to enable syslog to display information related to inside and outside packets, byte count, and the session IDs for both open and close sessions.

    [See[service-set-options.]

Software Defined Networking (SDN)

  • Support for static FTI backup paths with IP-in-IP tunnel encapsulation and provisioning APIs (MX Series, PTX Series, and QFX10002)—Starting in Junos OS Release 20.3R1, we've enhanced Juniper Extension Toolkit (JET) APIs to enable a controller to implement underlay network backup paths that use IP-in-IP tunnels with IPv4 encapsulation on flexible tunnel interfaces (FTIs). Use this feature to engineer effective, loop-free backup paths for core transport networks built with only IP protocols for fast restoration after failures.

    We've extended FTIs and existing forwarding constructs to support configuring static IPv4 IP-in-IP tunnels. You can also allow policy matches for routes injected by JET APIs.

    [See policy-statement, tunnel, ipip, show interfaces, show route, Configuring Flexible Tunnel Interfaces, and JET APIs on the Juniper Engineering Network website.]

  • Programmable flexible VXLAN tunnels (MX960 with MPC10E; MX2010 and MX2020 with MPC11E)—Starting in Junos OS Release 20.3R1, we support flexible VXLAN tunnels in a data center environment that includes one or more controllers. In this environment, one or more of the supported MX Series routers can function as data center edge gateways that exchange Layer 2 traffic with hosts in a data center. Through the use of static routes and tunnel encapsulation and de-encapsulation profiles, the Layer 2 traffic is dynamically tunneled over an intervening IPv4 or IPv6 network.

    The controllers enable you to program a large volume of static routes and tunnel profiles on the gateway devices through the Juniper Extension Toolkit (JET) APIs.

    [See Understanding Programmable Flexible VXLAN Tunnels and JET APIs on Juniper EngNet.]

System Management

  • Clock synchronization support (MX240, MX480, MX960, MX2010, and MX2020)—Starting in Junos OS release 20.3R1, we’ve enhanced the clock synchronization (clksync) module. When the CB0 clock failure alarm is raised, automatic Routing Engine switchover occurs. The new primary Routing engine Engine connection is made, the clksync module gets the notification.

    [See Understanding Clock Synchronization. ]