Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

New and Changed Features

 

This section describes the new features and enhancements to existing features in Junos OS Release 17.4R2 for the EX Series.

Note

The following EX Series switches are supported in Release 17.4R2: EX4300, EX4600, and EX9200.

Note

In Junos OS Release 17.4R2, J-Web is supported on the EX4300 and EX4600 switches in both standalone and Virtual Chassis setup.

The J-Web distribution model being used provides two packages:

  • Platform package—Installed as part of Junos OS; provides basic functionalities of J-Web.

  • Application package—Optionally installable package; provides complete functionalities of J-Web.

For details about the J-Web distribution model, see Release Notes: J-Web Application Package Release 17.4A1 for EX4300 and EX4600 Switches.

Release 17.4R2 New and Changed Features

EVPNs

  • EVPN proxy ARP and ARP suppression without IRB interfaces (MX Series routers with MPCs, EX9200 switches)—MX Series routers and EX9200 switches that function as provider edge (PE) devices in an Ethernet VPN-MPLS (EVPN-MPLS) or EVPN-Virtual Extensible LAN (EVPN-VXLAN) environment support the proxy Address Resolution Protocol (ARP) and ARP suppression. Both ARP capabilities are enabled by default.

    Starting with Junos OS Release 17.4R2, these features no longer require the configuration of an IRB interface on the PE device. Any interface configured on a PE device can now deliver ARP requests from both local customer edge (CE) devices only. Proxy ARP and ARP suppression are not supported on remote CE devices.

    Also, you can now control the following aspects of the MAC-IP address bindings database on a PE device:

    • The maximum number of MAC-IP address entries in the database.

    • The amount of time a locally learned MAC-IP address binding remains in the database.

    [See EVPN Proxy ARP and ARP Suppression.]

Restoration Procedures and Failure Handling

  • Device recovery mode support introduced in Junos OS with upgraded FreeBSD (EX Series)—Starting in Junos OS Release 17.4R2, devices running Junos OS with an upgraded FreeBSD and a saved rescue configuration have an automatic device recovery mode should the system go into amnesiac mode. The new process has the system automatically reboot with the saved rescue configuration. Then the system displays "Device is in recovery mode” in the CLI (in both operational and configuration modes). Previously, there was no automatic process to recover from amnesiac mode. A user with load and commit permission had to log in using the console and fix the issue in the configuration before the system would reboot.

    [See Saving a Rescue Configuration File.]

Release 17.4R1 New and Changed Features

Hardware

  • Aggregation device support on EX9200 with EX9200-RE2 routing engine (Junos Fusion Enterprise)—Starting with Junos OS Release 17.4, EX9200 switches with the EX9200-RE2 Routing Engine module are supported as aggregation devices in a Junos Fusion Enterprise. The EX9200-RE2 module supports virtual machine (VM) architecture in an EX9200 switch.

    [See Understanding Junos Fusion Enterprise Software and Hardware Requirements.]

Authentication, Authorization and Accounting (AAA)

  • Periodic refresh of authorization profile on TACACS server (EX Series)—Starting with Junos OS Release 17.4R1, periodic refresh of the authorization profile that is received from the TACACS server is supported. The authorization profile that is configured for the user on the TACACS server is sent to the Junos OS device after the user is successfully authenticated. The authorization profile is stored locally on the Junos OS device. With the periodic refresh feature, the authorization profile is periodically fetched from the TACACS server to refresh the authorization profile that is stored locally. User authorization is reevaluated using the refreshed authorization profile.

    [See Configuring Periodic Refresh of the TACACS+ Authorization Profile.]

EVPNs

  • EVPN-MPLS interworking with Junos Fusion Enterprise and MC-LAG (EX9200 switches)—Starting with Junos OS Release 17.4R1, you can use Ethernet VPN (EVPN) to extend your Junos Fusion Enterprise or MC-LAG network over an MPLS network. Typically, Junos Fusion Enterprise is extended to a geographically distributed campus or enterprise network, while an MC-LAG network is extended to a data center network or geographically distributed campus or enterprise network.

    The EVPN-MPLS interworking feature offers the following benefits:

    • Ability to use separate virtual routing and forwarding (VRF) instances to control inter-VLAN routing.

    • VLAN translation.

    • Default Layer 3 virtual gateway support, which eliminates the need to run such protocols as Virtual Router Redundancy Protocol (VRRP).

    • Load balancing to better utilize both links when using EVPN multihoming.

    • The use of EVPN type 2 advertisement routes (MAC+IP) reduces the need for flooding domains with ARP packets.

    [See Understanding EVPN-MPLS Interworking with Junos Fusion Enterprise and MC-LAG.]

  • Support for duplicate MAC address detection and suppression (EX9200 switches)— When a MAC address relocates, PE devices can converge on the latest location by using sequence numbers in the extended community field. Misconfigurations in the network can lead to duplicate MAC addresses. Starting in Junos OS Release 17.4R1, Juniper supports duplicate MAC address detection and suppression.

    You can modify the duplicate MAC address detection settings on the switch by configuring the detection window for identifying duplicate MAC address and the number of MAC address moves detected within the detection window before duplicate MAC detection is triggered and the MAC address is suppressed. In addition, you can also configure an optional recovery time that the switch waits before the duplicate MAC address is automatically unsuppressed.

    To configure duplicate MAC detection parameters, use the detection-window, detection-threshold, and auto-recovery-time statements at the [edit routing instance routing-instance-name protocols evpn duplicate-mac-detection] hierarchy level.

    To clear duplicate MAC suppression manually, use the clear evpn duplicate-mac-suppression command.

    [See Overview of MAC Mobility. ]

Junos OS XML API and Scripting

  • Automation script library additions and upgrades (EX Series)—Starting in Junos OS Release 17.4R1, devices running Junos OS include new and upgraded Python modules as well as upgraded versions of Junos PyEZ and libslax. On-box Python automation scripts can use features supported in Junos PyEZ Release 2.1.4 and earlier releases to perform operational and configuration tasks on devices running Junos OS. Python automation scripts can also leverage new on-box Python modules including ipaddress, jxmlease, pyang, serial, and six, as well as upgraded versions of existing modules. In addition, SLAX automation scripts can include features supported in libslax release 0.22.0 and earlier releases.

    [See Overview of Python Modules Available on Devices Running Junos OS and libslax Distribution Overview.]

Layer 2 Features

  • Layer 2 protocol tunneling support (EX4600 switches and Virtual Chassis)—Starting with Junos OS Release 17.4R1, Layer 2 protocol tunneling (L2PT) is supported on EX4600 switches and EX4600 Virtual Chassis. You can configure the switch to tunnel any of the following Layer 2 protocols: CDP, E-LMI, GVRP, IEEE 802.1X, IEEE 802.3AH, LACP, LLDP, MMRP, MVRP, STP (including RSTP and MSTP), UDLD, VSTP, and VTP.

    [See Understanding Layer 2 Protocol Tunneling on EX Series Switches.]

  • Q-in-Q support on redundant trunk links using LAGs with link protection (EX4300 switches and Virtual Chassis)—Starting in Junos OS Release 17.4R1, Q-in-Q is supported on redundant trunk links (also called “RTGs”) using LAGs with link protection. Redundant trunk links provide a simple solution for network recovery when a trunk port on a switch goes down. In that case, traffic is routed to another trunk port, keeping network convergence time to a minimum.

    Q-in-Q support on redundant trunk links on a LAG with link protection also includes support for the following items:

    • Configuration of flexible VLAN tagging on the same LAG that supports the redundant links configurations

    • Multiple redundant-link configurations on one physical interface

    • Multicast convergence

    [See Q-in-Q Support on Redundant Trunk Links Using LAGs with Link Protection.]

Management

  • Enhancements to LSP events sensor for Junos Telemetry Interface (EX4600 and EX9200 switches) —Starting with Junos OS Release 17.4R1, telemetry data streamed through gRPC for LSP events and properties is reported separately for each routing instance. To export data for LSP events and properties, you must now include /network-instances/network-instance/[name_'instance-name']/ in front of all supported paths. For example, to export LSP events for RSVP Signaling protocol attributes, use the following path: /network-instances/network-instance[name_'instance-name']/mpls/signaling-protocols/rsvp-te/. Use the telemetrySubscribe RPC to specify telemetry parameters and provision the sensor. If your device is running a version of Junos OS with an upgraded FreeBSD kernel, you must download the Junos Network Agent software package, which provides the interfaces to manage gRPC subscriptions.

    [See Guidelines for gRPC Sensors.]

  • Support for multiple, smaller configuration YANG modules (EX Series)—Starting in Junos OS Release 17.4R1, the YANG module for the Junos OS configuration schema is split into a root configuration module that is augmented by multiple, smaller modules. The root configuration module comprises the top-level configuration node and any nodes that are not emitted as separate modules. Separate, smaller modules augment the root configuration module for the different configuration statement hierarchies. Smaller configuration modules enable YANG tools and utilities to more quickly and efficiently compile and work with the modules, because they only need to import the modules required for the current operation.

    [See Understanding the YANG Modules That Define the Junos OS Configuration.]

  • Enhancement to BGP sensor for Junos Telemetry Interface (EX4600 and E9200 switches)—Starting with Junos OS Release 17.4R1, you can specify to export the number of BGP peers in a BGP group for telemetry data exported through gRPC. To export the number of BGP peers for a group, use the following OpenConfig path: /network-instances/network-instance[name_'instance-name']/protocols/protocol/

    bgp/peer-groups/peer-group[name_'peer-group-name]/state/peer-count/
    . The BGP peer count value exported reflects the number of peering sessions in a group. For example, for a BGP group with two devices, the peer count reported is 1 (one) because each group member has one peer. To provision the sensor to export data through gRPC, use the telemetrySubcribe RPC to specify telemetry parameters.

    [See Guidelines for gRPC Sensors.]

Multicast

  • MLD snooping versions 1 and 2 (EX4600 switches and Virtual Chassis)—Starting with Junos OS Release 17.4R1, EX4600 switches and EX4600 Virtual Chassis support Multicast Listener Discovery (MLD) snooping version 1 (MLDv1) and version 2 (MLDv2). MLD snooping constrains the flooding of IPv6 multicast traffic on VLANs. When MLD snooping is enabled on a VLAN, the switch examines MLD messages encapsulated within ICMPv6 packets transferred between hosts and multicast routers. The switch learns which hosts are interested in receiving traffic for a multicast group and forwards multicast traffic only to those interfaces in the VLAN that are connected to interested receivers instead of flooding the traffic to all interfaces. You configure MLD snooping parameters and enable MLD snooping using configuration statements at the [edit protocols] mld-snooping vlan vlan-name hierarchy.

    [See Understanding MLD Snooping on Switches.]

Routing Protocols

  • Support for EBGP route server (EX Series)—Starting in Junos OS Release 17.4R1, BGP feature is enhanced to support EBGP route server functionality. A BGP route server is the external BGP (EBGP) equivalent of an internal IBGP (IBGP) route reflector that simplifies the number of direct point-to-point EBGP sessions required in a network. EBGP route server propagates unmodified BGP routing information between external BGP peers to facilitate high scale exchange of routes in peering points such as Internet Exchange Points (IXPs). When BGP is configured as a route server, EBGP routes are propagated between peers unmodified, with full attribute transparency (NEXT_HOP, AS_PATH, MULTI_EXIT_DISC, AIGP, and Communities).

    The BGP JET bgp_route_service.proto API has been enhanced to support route server functionality as follows:

    • Program the EBGP route server.

    • Inject routes to the specific route server RIB for selectively advertising it to the client groups in client-specific RIBs.

    The BGP JET bgp_route_service.proto API includes a peer-type object that identifies individual routes as either EBGP or IBGP (default).

    [See BGP Route Server Overview.]

  • Support for importing IGP topologies into BGP-LS (EX Series)—Starting in Junos OS Release 17.4R1, you can import IGP, that is IS-IS and OSPF topologies into BGP-LS. Prior to Junos OS Release 17.4R1, Junos OS BGP-LS implementation exports only Traffic Engineering enabled (RSVP-enabled) links. This feature allows you to export IGP links (that do not have RSVP enabled) and Traffic Engineering enabled links into BGP-LS.

Software Installation and Upgrade

  • Configuration validation for image upgrade or downgrade (EX4300)—Starting in Junos OS Release 17.4R1, when you install a new version of Junos OS on the switch, the system validates that the existing configuration is compatible with the new image. Without the validation feature, configuration incompatibilities or insufficient memory to load the new image might cause the system to lose its current configuration or go offline. With the validation feature, if validation fails, the new image is not loaded, and an error message provides information about the failure.

    Image validation is supported only on the jinstall package.

    If you invoke validation from an image that does not support validation, the new image is loaded but validation does not occur.

    Invoke validation by issuing either request system software add or request system software nonstop-upgrade. You can also issue request system software validate to run just configuration validation.

    Image validation does not work in a downgrade from Release 17.4 to 17.2 or earlier if graceful switchover is enabled and image loading is done without NSSU. Use one of the following options:

    • To downgrade with graceful switchover but without image validation—Issue the request system software add image-name reboot no-validate command.

    • To downgrade with image validation but without graceful switchover—Remove the graceful-switchover configuration and then issue the request system software add image-name reboot command.

    • To downgrade with image validation and graceful switchover—Use NSSU by issuing the request system software nonstop-upgrade image-name command.

    [See Understanding Software Installation on EX Series Switches.]