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 the Junos OS main release and the maintenance releases for QFX Series.

Note

The following QFX Series platforms are supported in Release 17.2R2: QFX5100, QFX5110, QFX5200, QFX10002, QFX10008, and QFX10016.

Release 17.2R2 New and Changed Features

  • There are no new features or enhancements to existing features for QFX Series in Junos OS Release 17.2R2.

Release 17.2R1 New and Changed Features

Hardware

  • QFX5110-32Q–The QFX5110 line of switches is Juniper Network’s versatile fixed-configuration solution for hybrid cloud deployments. The model QFX5110-32Q is a flexible configuration switch allowing either 32 ports of 40-Gigabit Ethernet quad small form-factor pluggable plus (QSFP+) or 20 ports of QSFP+ and 4 ports of high-density 100-Gigabit Ethernet quad small form-factor pluggable solution (QSFP28). Each QSFP+ port can operate as a native 40-Gigabit Ethernet port, or as four independent 10-Gigabit ports when using breakout cables. The four QSFP28 ports are available either as access ports or as uplinks. The QFX5110-32Q provides full duplex throughput of 960 Gbps. The QFX5110-32Q has a 1 U form factor and comes standard with redundant fans and redundant power supplies. The switch can be ordered with either ports-to-FRUs or FRUs-to-ports airflow. The model is available with either AC or DC power supplies.

  • QFX10000-60S-6Q Line Card (QFX10008 and QFX10016 switches)–Starting with Junos OS Release 17.2R1, QFX10000-60S-6Q line cards support 1 Gbps speeds on the 10 Gigabit Ethernet SFP+ ports.

    [See QFX10000-60S-6Q Line Card.]

  • QFX10K-12C-DWDM Coherent Line Card (QFX10008 and QFX10016 switches)—Starting with Junos OS Release 17.2R1, QFX10008 and QFX10016 modular switch chassis support the QFX10K-12C-DWDM Coherent Line Card. The QFX10K-12C-DWDM Coherent Line Card provides up to 1.2 Tbps packet forwarding for cloud providers, service providers, and enterprises that need coherent dense wavelength-division multiplexing (DWDM) with MACsec security features. The six-port line card, with built-in optics, supports flexible rate modulation at 100 Gbps, 150 Gbps, and 200 Gbps speeds. A maximum of four QFX10K-12C-DWDM Coherent Line Cards are supported in either the QFX10008 switch chassis or the QFX10016 switch chassis.

    [See QFX10K-12C-DWDM Coherent Line Card.]

Authentication, Authorization, and Accounting (AAA) (RADIUS)

  • Access control and authentication (QFX5100 switches)—Starting in Junos OS Release 17.2R1, QFX5100 switches support controlling access to your network using 802.1X authentication and MAC RADIUS authentication. 802.1X authentication provides port-based network access control (PNAC) as defined in the IEEE 802.1X standard. QFX5100 switches support 802.1X features including guest VLAN, private VLAN, server fail fallback, dynamic changes to a user session, RADIUS accounting, and configuration of port-filtering attributes on the RADIUS server using vendor-specific attributes (VSAs). MAC RADIUS authentication is used to authenticate end devices independently of whether they are enabled for 802.1X authentication. You can permit end devices that are not 802.1X-enabled to access the LAN by configuring MAC RADIUS authentication on the switch interfaces to which the end devices are connected. You configure access control and authentication features at the the [edit protocols dot1x] hierarchy level. This feature was previously supported in an “X” release of Junos OS.

    [See Understanding Authentication on Switches.]

Class of Service (CoS)

  • Support for class of service on QFX5200 switches—Starting in Junos OS Release 17.2R1, the QFX5200 supports class-of-service (CoS). When a packet traverses a switch, the switch provides the appropriate level of service to the packet using either default CoS settings or CoS settings that you configure. On ingress ports, the switch classifies packets into appropriate forwarding classes and assigns a loss priority to the packets. On egress ports, the switch applies packet scheduling and any rewrite rules to re-mark packets.

    [See Traffic Management Feature Guide for the QFX Series.]

  • Support for FIP snooping and DCBX on QFX5200 switches—Starting in Junos OS Release 17.2R1, the QFX5200 supports both FIP snooping and DCBX. FIP snooping filters prevent an FCoE device from gaining unauthorized access to a Fibre Channel (FC) storage device or to another FCoE device. Data Center Bridging Capability Exchange Protocol (DCBX) discovers the data center bridging (DCB) capabilities of connected peers. DCBX advertises the capabilities of applications on interfaces by exchanging application protocol information through application type, length, and values (TLVs).

    [See Traffic Management Feature Guide for the QFX Series.]

Dynamic Host Configuration Protocol (DHCP)

  • User-defined interface description for DHCP relay (QFX5100, QFX5110, and QFX5200 switches)--Starting in Junos OS Release 17.2R1, you can define an interface description to be included in DHCP relay option 82 that is independent of the textual interface description configured at the [edit interfaces interface-name] hierarchy level.

    [See user-defined.]

EVPNs

  • Support for IGMP snooping for EVPN-VXLAN in a multihomed environment (QFX10000 switches)—Starting in Junos OS Release 17.2R1, QFX10000 switches support IGMP snooping with Ethernet EVPN (EVPN) . This feature is useful in an EVPN-VXLAN environment with significant multicast traffic. IGMP snooping enables PE devices to send multicast traffic to CE devices only as needed. To configure IGMP snooping, Include the igmp-snooping (all | vlan-number) set of statements at the [edit protocols] hierarchy level. You must also include the proxy statement in the IGMP snooping configuration. All multihomed interfaces must have the same configuration. The following new operational commands are also supported: show evpn igmp snooping database extensive, show igmp snooping evpn database, show igmp snooping evpn membership, and show evpn multicast-snooping next-hops.

    [See Overview of IGMP Snooping in an EVPN-VXLAN Environment.]

  • Tunneling Q-in-Q traffic through an EVPN-VXLAN overlay network (QFX5100 switches)—Starting in Junos OS Release 17.2R1, QFX5100 switches that function as Layer 2 VXLAN tunnel endpoints (VTEPs) can tunnel single- and double-tagged Q-in-Q packets through an Ethernet VPN-Virtual Extensible LAN (EVPN-VXLAN) overlay network. In addition to tunneling Q-in-Q packets, the ingress and egress VTEPs can perform the following Q-in-Q actions:

    • Delete, or pop, an outer service provider VLAN (S-VLAN) tag from an incoming packet.

    • Add, or push, an outer S-VLAN tag onto an outgoing packet.

    • Map a configured range of customer VLAN (C-VLAN) IDs to an S-VLAN.

      Note

      The QFX5100 switch does not support the pop and push actions with a configured range of VLANs.

    The ingress and egress VTEPs support the tunneling of Q-in-Q packets and the Q-in-Q actions in the context of specific traffic patterns.

    To enable the tunneling of the Q-in-Q packets on the VTEPs, you must configure a flexible VLAN tagging interface, which can transmit 802.1Q VLAN single- and double-tagged packets, on ingress and egress VTEPs. It is also important to configure the interface to retain the inner C-VLAN tag while a packet is tunneled.

    [See Examples: Configuring QFX5100 Switches to Tunnel Q-in-Q Traffic Through an EVPN-VXLAN Overlay Network.]

  • EVPN-VXLAN support of Virtual Chassis and Virtual Chassis Fabric (QFX5100, QFX5100 Virtual Chassis, and Virtual Chassis Fabric)—Ethernet VPN (EVPN) supports multihoming active-active mode, which enables a host to be connected to two leaf devices through a Layer 2 link aggregation group (LAG) interface. In previous Junos OS releases, the two leaf devices had to be QFX5100 standalone switches. Starting in Junos OS Release 17.2R1, the two leaf devices can be QFX5100 standalone switches, QFX5100 switches configured as a Virtual Chassis (VC), QFX5100 switches configured as a Virtual Chassis Fabric (VCF), or a mix of these options.

    This feature was previously introduced in an "X" release of Junos OS.

    [See EVPN-VXLAN Support of Virtual Chassis and Virtual Chassis Fabric.]

  • EVPN pure type-5 route support (QFX10000 switches)—Starting in Junos OS Release 17.2R1, you can configure pure type-5 routing in an Ethernet VPN (EVPN) Virtual Extensible LAN (VXLAN) environment. Pure type-5 routing is used when the Layer 2 domain does not exist at the remote data centers. A pure type-5 route advertises the summary IP prefix and includes a BGP extended community called a router MAC, which is used to carry the MAC address of the sending switch and to provide next hop reachability for the prefix. This router MAC extended community provides next-hop reachability without requiring an overlay next hop or supporting type-2 route. To configure pure type-5 routing, include the ip-prefix-routes advertise direct-nexthop statement at the [edit routing-instances routing-instance-name protocols evpn] hierarchy level. Pure type-5 routing was previously introduced in Junos OS Release 15.1x53-D60.

    [See ip-prefix-routes.]

Infrastructure

  • Secure Boot (QFX5110 switches)—Starting in Junos OS Release 17.2R1, a significant system security enhancement, Secure Boot, has been introduced. The Secure Boot implementation is based on the UEFI 2.4 standard. The BIOS has been hardened and serves as a core root of trust. The BIOS updates, the bootloader, and the kernel are cryptographically protected. No action is required to implement Secure Boot.

    This feature was previously supported in an "X" release of Junos OS.

Interfaces and Chassis

  • Resilient hashing support for link aggregation groups and equal cost multipath routes (QFX5110 and QFX5200 switches)—Starting with Junos OS Release 17.2R1, resilient hashing is now supported by link aggregation groups (LAGs) and equal cost multipath (ECMP) sets.

    Resilient hashing enhances LAGs by minimizing destination remapping when a new member is added to or deleted from the LAG.

    Resilient hashing works in conjunction with the default static hashing algorithm. It distributes traffic across all members of a LAG by tracking the flow's LAG member utilization. When a flow is affected by a LAG member change, the packet forwarding engine (PFE) rebalances the flow by reprogramming the flow set table. Destination paths are remapped when a new member is added to or existing members are deleted from a LAG.

    This feature was previously supported in an "X" release of Junos OS.

    [See Understanding the Use of Resilient Hashing to Minimize Flow Remapping in Trunk/ECMP Groups.]

  • Multichassis link aggregation groups (MC-LAG) (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.2R1, MC-LAG enables a client device to form a logical LAG interface using two switches. MC-LAG provides redundancy and load balancing between the two switches, multihoming support, and a loop-free Layer 2 network without running STP.

    On one end of an MC-LAG is an MC-LAG client that has one or more physical links in a LAG. This client does not need to detect the MC-LAG. On the other side of the MC-LAG are two switches. Each of these switches has one or more physical links connected to a single client. The switches coordinate with each other to ensure that data traffic is forwarded properly.

    This feature was previously supported in an "X" release of Junos OS.

    [See Multichassis Link Aggregation Features, Terms, and Best Practices.]

  • Channelizing 100-Gigabit Ethernet QSFP28 interfaces (QFX5200 switches)—This feature enables you to channelize the 100-Gigabit Ethernet interfaces to two independent 50-Gigabit Ethernet or to four independent 25-Gigabit Ethernet interfaces. The default 100-Gigabit Ethernet interfaces can also be configured as 40-Gigabit Ethernet interfaces, and in this configuration can either operate as dedicated 40-Gigabit Ethernet interfaces or can be channelized to four independent 10-Gigabit Ethernet interfaces using breakout cables.

    To channelize the ports, manually configure the port speed using the set chassis fpc slot-number port port-number channel-speed speed command, where the speed can be set to 10G, 25G, or 50G. The ports do not support autochannelization.

    Note

    If a 100G transceiver is connected to the switch, channelize the port only to 25G or 50G. If a 40G transceiver is connected, channelize the port only to 10G. Note that there is no commit check for these options.

    This feature was previously supported in an "X" release of Junos OS.

    [See Channelizing Interfaces on QFX5200 Switches.]

  • IRB interface in a PVLAN (QFX5110 switches)—Starting with Junos OS Release 17.2R1, you can configure an integrated routing and bridging (IRB) interface in a private VLAN (PVLAN) on QFX5110 switches so that devices within community VLANs and isolated VLANs can communicate with each other and with devices outside the PVLAN at Layer 3 without requiring you to install a router. This feature was previously supported in an "X" release of Junos OS.

    [See Example: Configuring a Private VLAN Spanning Multiple Switches with an IRB Interface.]

IPv4

  • Generic routing encapsulation (GRE) support (QFX5110 switches)—Starting in Junos OS Release 17.2R1, you can use GRE tunneling services on QFX5110 switches to encapsulate any network layer protocol over an IP network. Acting as a tunnel source router, the switch encapsulates a payload packet that is to be transported through a tunnel to a destination network. The switch first adds a GRE header and then adds an outer IP header that is used to route the packet. When it receives the packet, a switch performing the role of a tunnel remote router extracts the tunneled packet and forwards the packet to the destination network. GRE tunnels can be used to connect noncontiguous networks and to provide options for networks that contain protocols with limited hop counts.

IPv6

  • IPv6 feature support (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.2R1, you can configure the Neighbor Discovery Protocol, the Virtual Router Redundancy Protocol (VRRP) for IPv6, and Protocol Independent Multicast (PIM) for IPv6. You can also configure BGP and IS-IS for IPv6 as well as OSPFv3. Additionally, unicast IPv6 is supported for virtual router instances. DHCPv6 is also supported. IPv6 feature support for QFX5110 and QFX5200 switches was previously introduced in "X" releases of Junos OS.

    [See Example: Configuring IPv6 Interfaces and Enabling Neighbor Discovery and Verifying and Managing DHCPv6 Local Server Configuration.]

Layer 2 Features

  • Layer 2 features (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.2R1, the following features are supported:

    • VLAN support—Enables you to divide one physical broadcast domain into multiple virtual domains.

    • LLDP—Enables a switch to advertise its identity and capabilities on a LAN as well as receive information about other network devices.

    • Q-in-Q tunneling support—Allows service providers on Ethernet access networks to extend a Layer 2 Ethernet connection between two customer sites. Using Q-in-Q tunneling, providers can also segregate or bundle customer traffic into fewer VLANs or different VLANs by adding another layer of 802.1Q tags. Q-in-Q tunneling is useful when customers have overlapping VLAN IDs, because the customer’s 802.1Q (dot1Q) VLAN tags are prepended by the service VLAN (S-VLAN) tag.

    • Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP),and VLAN Spanning Tree Protocol (VSTP ) support – Provides Layer 2 loop prevention.

    These features were previously supported in an "X" release of Junos OS.

  • Q-in-Q tunneling support (QFX5200 switches)—Starting in Junos OS Release 17.2R1, QFX5200 switches support Q-in-Q tunneling, which enables service providers on Ethernet access networks to extend a Layer 2 Ethernet connection between two customer sites. Using Q-in-Q tunneling, providers can also segregate or bundle customer traffic into fewer VLANs or different VLANs by adding another layer of 802.1Q tags. Q-in-Q tunneling is useful when customers have overlapping VLAN IDs, because the customer’s 802.1Q (dot1Q) VLAN tags are prepended by the service VLAN (S-VLAN) tag. This feature was previously supported in an "X" release of Junos OS.

    [See Understanding Q-in-Q Tunneling.]

Layer 3 Features

  • Support for hierarchical ECMP groups (QFX5200 switches)—Starting in Junos OS Release 17.2R1, hierarchical equal-cost multipath (ECMP) groups are enabled by default at system start. Hierarchical ECMP provides for two-level route resolution automatically through the Packet Forwarding Engine. Two-level route resolution through ECMP groups enhances load balancing of traffic. This feature was previously introduced in Junos OS Release 15.1X53-D30.

    [See Overview of Hierarchical ECMP Groups.]

  • Support for 64 next-hop gateways for ECMP (QFX5110 switches)—Starting in Junos OS Release 17.2R1, you can configure as many as 64 equal-cost-multipath (ECMP) next hops for RSVP and LDP LSPs or external BGP peers. The following Layer 3 protocols are supported as ECMP gateways for both IPv4 and IPv6 traffic: OSPF, ISIS, EBGP, and IBGP (resolving over IGP routes). Include the maximum-ecmp next-hops statement at the [edit chassis] hierarchy level. This feature was previously introduced on QFX5110 switches in Junos OS Release 15.1X53-D210.

    [See maximum-ecmp]

  • Support to disable hierarchical ECMP (QFX5200 switches)—Starting with Junos OS Release 17.2R1, you can disable hierarchical equal-cost multipath (ECMP) groups at system start time. Hierarchical ECMP is enabled by default. Disabling this feature effectively increases the number of ECMP groups. Include the no-hierarchical-ecmp statement at the [edit forwarding-options] hierarchical level. Disabling hierarchical ECMP causes the Packet Forwarding Engine to restart. To reenable hierarchical ECMP, issue the following command: delete forwarding-options no-hierarchical-ecmp. This feature was previously introduced in Junos OS Release 15.1X53-D210.

    [See no-hierarchical-ecmp.]

Management

  • Support for device family and release in Junos OS YANG modules (QFX Series)—Starting in Junos OS Release 17.2, Junos OS YANG modules are specific to a device family, and each module’s namespace includes the module name, device family, and Junos OS release string. Furthermore, each juniper-command module uses its own unique module name as the module’s prefix. Device families include junos, junos-es, junos-ex, and junos-qfx.

    [See Understanding Junos OS YANG Modules.]

  • Support for the Junos Telemetry Interface (QFX10000 switches)—Starting with Junos OS Release 17.2R1, the Junos Telemetry Interface is supported on QFX10000 switches. Both UDP and gRPC streaming of statistics are supported. Junos Telemetry Interface enables you to provision sensors to export telemetry data for various network elements without involving polling.

    The following sensors are supported on QFX10000 switches:

    • Logical interfaces (UDP and gRPC streaming)

    • Physical interfaces (UDP and gRPC streaming)

    • Firewall filters, including traffc-class counters (UDP and gRPC streaming)

    • LSP statistics (UDP and gRPC streaming)

    • LSP events and properties (gRPC streaming)

    • Optical interfaces (UDP and gRPC streaming)

    • Network processing unit (NPU) memory (UDP and gRPC streaming)

    • NPU memory utilization (UDP and gRPC streaming)

    • CPU memory (UDP and gRPC streaming)

    • Chassis components (gRPC streaming only)

    • RSVP interface events (gRPC streaming only)

    • BGP peers (gRPC streaming only)

    • Memory utilization for routing protocol tasks (gRPC streaming only)

    • Aggregated Ethernet interfaces configured with the Link Aggregation Control Protocol (gRPC streaming only)

    • Ethernet interfaces enabled configured with the Link Layer Discovery Protocol (gRPC streaming only)

    • Network Discovery Protocol table state (gRPC streaming only)

    • Address Resolution Protocol table state (gRPC streaming only)

    To provision sensors to stream data through UDP, all parameters are configured at the [edit services analytics] hierarchy level. To provision sensors to stream data through gRPC, use the telemetrySubscribe RPC to specify telemetry parameters for a specified list of OpenConfig command paths. Because QFX10000 switches run a version Junos OS with an upgraded FreeBSD kernel, you must download the Junos Network Agent software package, which provides the interfaces to manage gRPC subscriptions. Streaming telemetry data through gRPC also requires you to download the OpenConfig for Junos OS module and YANG models.

    The LSP events and properties sensor is supported in Junos OS Release 17.2R1 for the first time. You can export statistics for ingress point-to-point LSPs, point-to-multipoint LSPs, bypass LSPs, and dynamically created LSPs. To export data through gRPC, use the /mpls/lsps/ or /mpls/signal-protocols/ set of OpenConfig subscription paths.

    [See Overview of the Junos Telemetry Interface.]

  • Support for the Junos Telemetry Interface (QFX5200 switches)—Starting with Junos OS Release 17.2R1, you can provision sensors through the Junos Telemetry Interface to export telemetry data for various network elements without involving polling. On QFX5200 switches, only gRPC streaming of statistics is supported. UDP streaming is not supported.

    The following sensors are supported:

    • Chassis components

    • Aggregated Ethernet interfaces configured with the Link Aggregation Control Protocol

    • Ethernet interfaces enabled configured with the Link Layer Discovery Protocol

    • BGP peers

    • RSVP interface events

    • Memory utilization for routing protocol tasks

    • Address Resolution Protocol table state

    • Network Discovery Protocol table state

    To provision sensors to stream data through gRPC, use the telemetrySubscribe RPC to specify telemetry parameters for a specified list of OpenConfig commands paths. You must download the Junos Network Agent software package, which provides the interfaces to manage gRPC subscriptions. Streaming telemetry data through gRPC also requires you to download the OpenConfig for Junos OS module and YANG models.

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

MPLS

  • TE++ dynamic bandwidth management using container LSPs (QFX5100)—Starting with Junos OS Release 17.2R1, a new type of label-switched path (LSP), called a container LSP, is introduced to enable load balancing across multiple point-to-point member LSPs between the same ingress and egress routers. Each member LSP takes a different path to the same destination and can be routed along a different interior gateway protocol (IGP) cost path. Based on the configuration and aggregate traffic, a container LSP provides support for dynamic bandwidth management by enabling the ingress router to dynamically add and remove member LSPs through a process called LSP splitting and LSP merging, respectively. Member LSPs can also be re-optimized with different bandwidth values in a make-before-break way. The feature was previous supported in a "X" release of Junos OS.

    [See Dynamic Bandwidth Management Using Container LSP Overview.]

  • Entropy labels for LSPs (QFX10000 switches)—Starting with Junos OS Release 17.2R1, you can configure entropy labels for label-switched paths (LSPs). An entropy label is a special load-balancing label that 0 enhances the ability of the switch to load-balance traffic across equal-cost multipath (ECMP) paths or link aggregation groups (LAGs). The entropy label allows the switch to efficiently load-balance traffic using just the label stack rather than deep packet inspection (DPI). To configure entropy labels, include the entropy-label statement at the [edit protocols mpls labeled-switched-path labeled-switched-path-name] hierarchy level.

    [See Understanding Entropy Label for BGP Labeled Unicast LSPs and Automatic Bandwidth Allocation for LSPs.]

  • Support for a label stack for BGP label unicast for MPLS advertisements (QFX10000 switches)—Starting with Junos OS 17.2R1, QFX10000 switches implement RFC 3701, which supports a stack of labels in BGP label unicast for both IPv4 and IPv6 traffic. Previously, only one label per prefix was supported in the BGP unicast label. You can now specify to include of up to five labels per prefix in the BGP labeled unicast updates. This feature enables the use of the BGP label unicast stack to program a stack of labels to control packet forwarding in a network configured with hierarchical MPLS label-switched paths. To configure as many as five labels to advertise through MPLS, include the maximum-labels number statement at the [edit interfaces interface-name unit logical-unit-number family mpls] hierarchy level. The show route receive-protocol bgp neighbor-address detail and show route advertising-protocol neighbor-address detail operational commands are enhanced to display multiple labels for one prefix in the Labels field.

    [See Configuring the Maximum Number of MPLS Labels.]

  • MPLS support (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.2R1, MPLS is supported on the QFX5110 and QFX5200 switches. MPLS supports both label edge routers (LER) and label switch routers (LSR) and provides the following capabilities:

    • Support for both MPLS major protocols, LDP and RSVP

    • IS-IS interior gateway protocol (IGP) traffic engineering

    • Class of service (CoS)

    • Object access method, including ping, traceroute, and Bidirectional Forwarding Detection (BFD)

    • Fast reroute (FRR) support, a component of MPLS local protection for both one-to-one and many-to-one local protection.

    • Loop-free alternate (LFA)

    • 6PE devices

    • Layer 3 VPNs for both IPv4 and IPv6

    • LDP tunneling over RSVP

    This feature was previously supported in an “X” release of Junos OS.

    [See MPLS Overview for Switches.]

  • Support for equal cost multipath (ECMP) routing on label-switching routers (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.2R1, you can configure ECMP on MPLS label-switched routers (LSRs). ECMP is a layer 3 mechanism for load–balancing traffic to a destination over multiple equal-cost next hops. When a link goes down, ECMP uses fast reroute protection to shift packet forwarding to use operational links, thereby decreasing packet loss. This feature was previously supported in an "X" release of Junos OS.

    [See Configuring ECMP Next Hops for RSVP and LDP LSPs for Load Balancing.]

  • Ethernet over MPLS (Layer 2 circuit) support (QFX5100 Virtual Chassis and Virtual Chassis Fabric)—Starting in Junos OS Release 17.2R1, a QFX5100 Virtual Chassis or Virtual Chassis Fabric (VCF) supports Ethernet over MPLS (Layer 2 circuit). The Virtual Chassis or VCF can act as a provider edge switch on which you configure MPLS and LDP for the interfaces that will carry the Layer 2 circuit traffic. The Layer 2 circuit can be port-based (pseudo-wire) or VLAN-based. These features were previously supported for a QFX5100 Virtual Chassis or VCF in an “X” release of Junos OS.

    [See Understanding Ethernet-over-MPLS (L2 Circuit) and Configuring Ethernet over MPLS (L2 Circuit).]

Multicast

  • Layer 3 multicast support (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.2R1, IGMP, including versions 1,2, and 3, IGMP snooping, PIM sparse mode, and PIM source-specific multicast are supported. You can also configure IGMP, IGMP snooping, and PIM in virtual router instances. Multicast Source Discovery Protocol (MSDP) is also supported. Configure IGMP at the [edit protocols igmp] hierarchy level. Configure IGMP snooping at the [edit protocols igmp-snooping] hierarchy level. Configure PIM at the [edit protocols pim] hierarchy level. Configure MSDP at the [edit protocols msdp] hierarchy level. Layer 3 multicast support was previously introduced in "X" releases of Junos OS.

    [See Multicast Overview.]

  • Support for static multicast route leaking for VRF and virtual-router instances (QFX5100 and EX4300 switches)—Starting in Junos OS Release 17.2R1, you can configure your switch to share IPv4 multicast routes among different virtual routing and forwarding (VRF) instances or different virtual-router instances. On EX4300 switches, multicast route leaking is supported only when the switch functions as a line card in a Virtual Chassis, not as a standalone switch. Only multicast static routes with a destination-prefix length of /32 are supported for multicast route leaking. Only Internet Group Management Protocol version 3 is supported. To configure multicast route leaking for VRF or virtual-router instances , include the next-table routing-instance-name.inet.0 statement at the [edit routing-instances routing-instance-name routing-options static route destination-prefix/32] hierarchy level. For routing–instance-name, include the name of a VRF or virtual-router instance. This feature was previously introduced in Junos OS Release 14.X53-D40.

    [See Understanding Multicast Route Leaking for VRF and Virtual-Router Instances.]

Network Management and Monitoring

  • sFlow enhancements (QFX10008 and QFX10016 switches)—Starting in Junos OS Release 17.2R1, sFlow IPv4 and IPv6 packets support extended router information, including the IP address of the next-hop router, the outgoing VLAN ID, the source IP address prefix length, and the destination IP address prefix length. This information is collected only if BGP is configured on the switch.

    In addition, a configuration statement was introduced that allows the sFlow sampling rate to stay within the maximum sampling rate of 1 out of 64,000 packets. Packet-based sampling is implemented in the hardware, so all of the interfaces can be monitored with very little overhead. However, if traffic levels are unusually high, the hardware generates more samples than it can handle. The extra samples are dropped by the software rate-limiting algorithm and can cause inaccurate results. You can include the disable-sw-rate-limiter statement at the [edit protocols sFlow] hierarchy to disable the software, allowing the hardware sampling rate to stay within the maximum sampling rate for sFlow.

    [See Understanding How to Use sFlow Technology for Network Monitoring on a Switch.]

  • sFlow technology support (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.2R1, the QFX5110 and QFX5200 switches support sFlow technology. sFlow technology is a monitoring technology for high-speed switched or routed networks. sFlow monitoring randomly samples network packets and sends the samples to a monitoring station called a collector. You can configure sFlow monitoring on the switch to continuously monitor traffic at wire speed on all interfaces simultaneously. sFlow monitoring also collects samples of network packets, providing you with visibility into network traffic information. You configure sFlow monitoring at the [edit protocols sflow] hierarchy level. sFlow operational commands include show sflow and clear sflow collector statistics. This feature was previously supported in an "X" release of Junos OS

    [See Understanding How to Use sFlow Technology for Network Monitoring on a Switch.]

  • Port mirroring (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.2R1, you can use port mirroring on QFX5110 and QFX5200 switches to copy packets entering or exiting a port or entering a VLAN and send the copies to a local interface for local monitoring or to a VLAN for remote monitoring. Use port mirroring to send traffic to applications that analyze traffic for purposes such as monitoring compliance, enforcing policies, detecting intrusions, monitoring and predicting traffic patterns, correlating events, and so on. This feature was previously supported in an "X" release of Junos OS.

    [See Understanding Port Mirroring.]

  • SNMP support for monitoring tunnel statistics (QFX Series)—Starting in Junos OS Release 17.2R1 , SNMP MIB jnxTunnelStat supports monitoring of tunnel statistics for IPv4 over IPv6 tunnels. This is a new enterprise-specific MIB, Tunnel Stats MIB, that currently displays three counters: tunnel count in rpd, tunnel count in Kernel, and tunnel count in the Packet Forwarding Engine. This MIB can be extended to support other tunnel statistics. The MIB is defined in jnx-tunnel-stats.txt. This MIB is attached to jnxMibs.

    [See SNMP MIB Explorer.]

Port Security

  • Media Access Control Security (MACsec) support (QFX10008 and QFX10016 switches)—Starting in Junos OS Release 17.2R1, MACsec is supported on all six interfaces of the QFX10K-12C-DWDM line card when it is installed in a QFX10008 or QFX10016 switch. MACsec is an 802.1AE IEEE industry-standard security technology that provides secure communication for all traffic on point-to-point Ethernet links. MACsec is capable of identifying and preventing most security threats, and can be used in combination with other security protocols to provide end-to-end network security. MACsec can be enabled only on domestic versions of Junos OS software.

    [See Understanding Media Access Control Security (MACsec)]

  • Access security support (QFX5110 switches)—Starting in Junos OS Release 17.2R1, the following access security features are supported on QFX5110 switches:

    • DHCP snooping—DHCP snooping allows the switch to monitor and control DHCP messages received from untrusted devices connected to the switch. When DHCP snooping is enabled, the system snoops the DHCP messages to view DHCP lease information, which it uses to build and maintain a database of valid IP-address-to-MAC-address (IP-MAC) bindings called the DHCP snooping database. Clients on untrusted ports are only allowed to access the network if they can be validated against the database.

    • DHCPv6 snooping—DHCP snooping for DHCPv6.

    • DHCP option 82—You can use DHCP option 82, also known as the DHCP relay agent information option, to help protect the switch against attacks such as spoofing (forging) of IP addresses and MAC addresses, and DHCP IP address starvation. Option 82 provides information about the network location of a DHCP client, and the DHCP server uses this information to implement IP addresses or other parameters for the client.

    • DHCPv6 option 37—Option 37 is the DHCPv6 equivalent of the remote ID suboption of DHCP option 82. It is used to insert information about the network location of the remote host into DHCPv6 packets.

    • Dynamic ARP inspection (DAI)—DAI inspects Address Resolution Protocol (ARP) packets on the LAN and uses the information in the DHCP snooping database on the switch to validate ARP packets and to protect against ARP spoofing (also known as ARP poisoning or ARP cache poisoning). ARP requests and replies are compared against entries in the DHCP snooping database, and filtering decisions are made based on the results of those comparisons.

    • IPv6 neighbor discovery (ND) inspection—IPv6 ND inspection mitigates attacks based on the Neighbor Discovery Protocol by inspecting neighbor discovery messages and verifying them against the DHCPv6 snooping table.

    • MAC limiting—You can configure a MAC limit per interface and per VLAN, and set an action to take on the next packet the interface or VLAN receives after the limit is reached.

    • MAC move limiting—You can configure MAC move limiting to track MAC address movements on the switch, so that if a MAC address changes more than the configured number of times within one second, the changes to MAC addresses are dropped, logged, or ignored, or the interface is shut down.

    • Persistent MAC learning—Persistent (also called sticky) MAC addresses help restrict access to an access port by identifying the MAC addresses of workstations that are allowed access to a given port. Secure access to these workstations is retained even if the switch is restarted.

    [See Understanding Port Security Features to Protect the Access Ports on Your Device Against the Loss of Information and Productivity.]

Routing Protocols

  • Support for BGP Monitoring Protocol (BMP) Version 3 (QFX5110 and QFX5200 switches)—Starting with Junos OS Release 17.2R1, you can configure BMP, which sends BGP route information from the switch to a monitoring application, or station, on a separate device. To deploy BMP in your network, you need to configure BMP on each switch and at least one BMP monitoring station. Only version 3 is supported. To configure BMP, include the bmp set of statements at the [edit routing-options] hierarchy level. To configure a BMP monitoring station, include the station-address ip-address and the station-port number statements at the [edit routing-options bmp] hierarchy level.

    [See Configuring BGP Monitoring Protocol Version 3.]

  • Support for segment routing for IS-IS (QFX5100 switches and QFX10000 switches)—Starting with Junos OS Release 17.2R1, you can advertise MPLS labels through IS-IS to support segment routing. IS-IS advertises a set of segments, which enables an ingress device to steer a packet through a specific set of nodes and links in the network without relying on the intermediate nodes in the network to determine the path to take. Two types of segments are supported: node and adjacency. A node segment represents a shortest-path link to a node. An adjacency segment represents a specific adjacency to a node. To enable segment routing, include the source-packet-routing statement at the [edit protocols isis] hierarchy level. By default, segment routing is enabled on all IS-IS levels. To disable advertising of the adjacency segment for a specified interface, include the no-advertise-adjacency-segment statement. You can also specify an interval for maintaining adjacency segments by including the adjacency-segment hold-time milliseconds statement.

    To enable node segments, include the node-segment statement at the [edit protocols isis source-packet-routing] hierarchy level. You have two options for advertising a range of indices for IPv4 or IPv6 addresses. Use the index-range statement to specify a dynamic label range managed by MPLS. To specify a specific block of indices, also known as a segment routing global block, include the start-label <number> index-range <number> statements at the [edit protocols isis source-packet-routing srgb] hierarchy level. This configuration enables MPLS to reserve the specified label range.

    Segment routing in IS-IS also supports provisioning prefix segment indices (SIDs) and anycast SIDs for both IPv4 and IPv6 prefixes. These SIDs are provisioned through a routing policy for each prefix. Include the then prefix-segment index number statement at the [edit policy options policy-statement policy-name] hierarchy level. You can also enable IPG shortcuts for prefix segment routes. Include the shortcuts statement at the [edit protocols isis traffic-engineering family (inet-mpls | inet6-mpls)] hierarchy level.

    [See source-packet-routing.]

  • Support for segment routing for OSPF (QFX5100 switches and QFX10000 switches)—Starting with Junos OS Release 17.2R1, you can advertise MPLS labels through OSPF to support segment routing. Only IPv4 is supported. OSPFv3 is not supported. OSPF advertises a set of segments, which enables an ingress device to steer a packet through a specific set of nodes and links in the network without relying on the intermediate nodes in the network to determine the path to take. Two types of segments are supported: node and adjacency. A node segment represents a shortest-path link to a node. An adjacency segment represents a specific adjacency to a node. To enable segment routing, include the source-packet-routing statement at the [edit protocols ospf] hierarchy level. By default, segment routing is enabled for all OSPF areas. To disable for a specific area, include theno-source-packet-routing statement at the [edit protocols ospf area area-id] hierarchy level. To enable node segments, include the node-segment statement. You can specify a range for IPv4 addresses to advertise, which MPLS manages dynamically. To disable advertising of the adjacency segment for a specified interface, include the no-advertise-adjacency-segment statement.

    [See source-packet-routing.]

  • Support for unique AS path count (QFX Series)—Starting with Junos OS Release 17.2R1, you can configure a routing policy to determine the number of unique autonomous systems (ASs) present in the AS path. The unique AS path count helps determine whether a given AS is present in the AS path multiple times, typically as prepended ASs. In earlier Junos releases it was not possible to implement this counting behavior using the as-path regular expression policy. This feature permits the user to configure a policy based on the number of AS hops between the route originator and receiver. This feature ignores ASs in the as-path that are confederation ASs, such as confed_seq and confed_set.

    To configure AS path count, include the as-path-unique-count count (equal | orhigher | orlower) configuration statement at the [edit policy-options policy-statement policy_name from] hierarchy level.

Security

  • Support for filter-based decapsulation over an IP-IP interface (QFX10000 switches)—Starting in Junos OS Release 17.2R1, you can use a firewall filter over an IP-IP interface to de-encapsulate traffic on the switch, without the need to create any tunnel interfaces. IP-in-IP packets are special IP tunneling packets with no GRE header. With this feature, you can define a filter with filtering terms to classify packets based on packet fields such as destination IP address and protocol type. This provides significant benefits in terms of scalability, performance, and flexibility.

    [See Configuring a Firewall Filter to De-Encapsulate IP-in-IP Traffic.]

  • Policing support (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.2R1, you can use policing (or rate-limiting) to apply limits to traffic flow and to set consequences for packets that exceed those limits. The device polices traffic by limiting the input or output transmission rate of a class of traffic according to user-defined criteria. Policing traffic allows you to control the maximum rate of traffic sent or received on an interface and to provide multiple priority levels or classes of service. This feature was previously supported in an “X” release of Junos OS.

    [See Overview of Policers.]

  • Storm control support (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.2R1, you can monitor traffic levels and take a specified action when a defined traffic level (called the storm control level) is exceeded, preventing packets from proliferating and degrading service. You can configure the switch to drop broadcast and unknown unicast packets, shut down interfaces, or temporarily disable interfaces when a traffic storm occurs. This feature was previously supported in an “X” release of Junos OS.

    [See Understanding Storm Control.]

  • Firewall filters support (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.2R1, you can provide rules that define whether to accept or discard packets. You can use firewall filters on interfaces, VLANs, routed VLAN interfaces (RVIs), link aggregation groups (LAGs), and loopback interfaces. This feature was previously supported in an “X” release of Junos OS.

    [See Overview of Firewall Filters.]

  • Generic routing encapsulation (GRE) support (QFX5100 and QFX5200 switches)—You can use GRE tunneling services to encapsulate any network layer protocol over an IP network. Acting as a tunnel source router, the switch encapsulates a payload packet that is to be transported through a tunnel to a destination network. The switch first adds a GRE header and then adds an outer IP header that is used to route the packet. When it receives the packet, a switch performing the role of a tunnel remote router extracts the tunneled packet and forwards the packet to the destination network. GRE tunnels can be used to connect noncontiguous networks and to provide options for networks that contain protocols with limited hop counts. This feature was previously supported in an “X” release of Junos OS.

    [See Configuring a Firewall Filter to De-Encapsulate GRE Trafficl.]

Services Applications

  • Support for IPFIX templates for flow aggregation (QFX10002 switches)—Starting with Junos OS Release 17.2R1, you can define a flow record template for unicast IPv4 and IPv6 traffic in IP Flow Information Export (IPFIX) format. Templates are transmitted to the collector periodically. To define an IPFIX template, include the version-ipfix template template-name set of statements at the [edit services flow-monitoring] hierarchy level.

    You must also perform the following configuration:

    • Sampling instance at the [edit forwarding-options] hierarchy level.

    • Associate the sampling instance with the FPC at the [edit chassis] hierarchy level and with a template configured at the [edit services flow-monitoring] hierarchy level.

    • Firewall filter for the family of traffic to be sampled at the [edit firewall] hierarchy level.

    [See Configuring Flow Aggregation to Use IPFIX Flow Templates.]

Software Defined Networking (SDN)

  • OVSDB-VXLAN support with Contrail (QFX5110 and QFX5200 switches)—Starting with Junos OS Release 17.2R1, the Open vSwitch Database (OVSDB) management protocol provides a means through which a Contrail controller can communicate with QFX5110 and QFX5200 switches to provision them as Layer 2 VXLAN gateways. In an environment in which Contrail Release 2.22 or later is deployed, a Contrail controller and these switches can exchange control and statistical information, thereby enabling virtual machine (VM) traffic from entities in a virtualized network to be forwarded to entities in a physical network and vice versa.

    This feature was previously supported in an “X” release of Junos OS.

    [See Understanding the OVSDB Protocol Running on Juniper Networks Devices.]

  • Layer 2 VXLAN gateway (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.2R1, you can implement a QFX5110 or QFX5200 switch as a Layer 2 Virtual Extensible LAN (VXLAN) gateway. VXLAN is an overlay technology that allows you to stretch Layer 2 connections over an intervening Layer 3 network by encapsulating (tunneling) Ethernet frames in a VXLAN packet that includes IP addresses. You can use VXLAN tunnels to enable migration of virtual machines (VMs) between servers that exist in separate Layer 2 domains by tunneling the traffic through Layer 3 networks. This functionality allows you to dynamically allocate resources within or between data centers without being constrained by Layer 2 boundaries or being forced to create large or geographically stretched Layer 2 domains. Using VXLANs to connect Layer 2 domains over a Layer 3 network means that you do not need to use the Spanning Tree Protocol (STP) to converge the topology (so no links are blocked) but can use more robust routing protocols in the Layer 3 network instead.

    This feature was previously supported in an “X” release of Junos OS.

    [See Understanding VXLANs.]

  • BFD in a VMware NSX environment with OVSDB and VXLAN (QFX5100 switches, QFX5100 Virtual Chassis)

    Within a Virtual Extensible LAN (VXLAN) managed by the Open vSwitch Database (OVSDB) protocol, by default, Layer 2 broadcast, unknown unicast, and multicast (BUM) traffic is replicated and forwarded by one or more software virtual tunnel endpoints (VTEPs) or service nodes in the same VXLAN. (The software VTEPs and service nodes are collectively referred to as replicators.)

    Starting in Junos OS Release 17.2R1, a Juniper Networks switch or Virtual Chassis that functions as a hardware VTEP in a VMware NSX environment uses the Bidirectional Forwarding Detection (BFD) protocol to prevent the forwarding of BUM packets to a non-functional replicator.

    By exchanging BFD control messages with replicators at regular intervals, the hardware VTEP can monitor the replicators to ensure that they are functioning and reachable.

Software Installation and Upgrade

  • Support for FreeBSD 10 kernel for Junos OS (QFX5200 and QFX5110 switches)—Starting with Junos OS Release 17.2R1, FreeBSD 10 is the underlying OS for Junos OS instead of FreeBSD 6.1. This feature includes a simplified package naming system that drops the domestic and world-wide naming convention. Because installation restructures the file system, logs and configurations are lost unless precautions are taken. Now there are Junos OS and OAM volumes, that provide the ability to boot from the OAM volume upon failures. Some system commands display different output and a few others are deprecated.

    This feature was previously supported in an "X" release of Junos OS.

    [See Understanding Junos OS with Upgraded FreeBSD.]

Software Licensing

  • Integrated software feature licenses (QFX5110 and QFX5200 switches)—Starting with Junos OS Release 17.2R1, the standard QFX Series premium feature license for BGP, Intermediate System-to-Intermediate System (IS-IS), and Virtual Extensible Local Area Network (VXLAN), and Open vSwitch Database (OVSDB) software license and the standard QFX Series advanced feature license for BGP, Intermediate System-to-Intermediate System (IS-IS), MPLS, and Virtual Extensible Local Area Network (VXLAN), and Open vSwitch Database (OVSDB) license are supported.

    This feature was previously supported in an “X” release of Junos OS.

    [See Software Features That Require Licenses on the QFX Series.]

System Management

  • Support for Precision Time Protocol (PTP) transparent clock (QFX5100 and QFX5110 switches)—Starting in Junos OS Release 17.2R1, PTP synchronizes clocks throughout a packet-switched network. With a transparent clock, the PTP packets are updated with residence time as the packets pass through the switch. There is no master/slave designation. End-to-end transparent clocks are supported. With an end-to-end transparent clock, only the residence time is included. The residence time can be sent in a one-step process, which means that the timestamps are sent in one packet. In a two-step process, estimated timestamps are sent in one packet, and additional packets contain updated timestamps. In addition, User UDP over IPv4 and IPv6 and unicast and multicast transparent clock are supported.

    You can configure the transparent clock at the [edit protocols ptp] hierarchy.

    [See Understanding Transparent Clocks in Precision Time Protocol.]

  • Zero Touch Provisioning (QFX5100, QFX5110, and QFX5200 switches)Starting with Junos OS Release 17.2R1, Zero Touch Provisioning allows you to provision new Juniper Networks switches in your network automatically without manual intervention. When you physically connect a switch to the network and boot it with a default configuration, it attempts to upgrade the Junos OS software automatically and autoinstall a configuration file from the network. The switch uses information that you configure on a Dynamic Host Configuration Protocol (DHCP) server to locate the necessary software image and configuration files on the network. If you do not configure the DHCP server to provide this information, the switch boots with the preinstalled software and default configuration. The Zero Touch Provisioning process either upgrades or downgrades the Junos OS version.

    This feature was previously supported in an "X" release of Junos OS.

    [See Understanding Zero Touch Provisioning.]

VLAN Infrastructure

  • Double VLAN tags on Layer 3 subinterfaces (QFX10000 switches)—Starting in Junos OS Release 17.2R1, you can configure double VLAN tags on Layer 3 subinterfaces (also called “Layer 3 logical interfaces) on QFX10000 switches. Layer 3 double-tagged logical interfaces support inet, inet6, and mpls families.

    Support for double-tagging VLANs on Layer 3 logical interfaces includes:

    • Configuration of an IPv4, an IPv6, or an mpls family on the logical interface

    • Configuration over an aggregated Ethernet interface

    • Configuration of multiple logical interfaces on a single physical interface

    [See Configuring Double-Tagged VLANs on Layer 3 Logical Interfaces.]