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.
The following QFX Series platforms are supported in Release 17.1R2: QFX5100, QFX10002, QFX10008, and QFX10016.
Release 17.1R2 New and Changed Features
There are no new features or enhancements to existing features for QFX Series in Junos OS Release 17.1R2.
Release 17.1R1 New and Changed Features
Hardware
QFX10008 switch—Starting with Junos OS Release 17.1R1, the Juniper Networks QFX10000 line of Ethernet switches provides cloud builders and data center operators scalable solutions for both core and spine data center deployments. The QFX10008 switch is an 8-slot, 13 U chassis that supports up to eight line cards. This switch was previously supported in an “X” release of Junos OS.
QFX10016 switch—Starting with Junos OS Release 17.1R1, the Juniper Networks QFX10016 modular data center spine and core Ethernet switch provides cloud and data center operators with high-level scale and throughput. The largest of the QFX10000 line of switches, the QFX10016 can provide 96 Tbps of throughput and 32 Bpps of forwarding capacity in a 21 rack unit (21 U) chassis. The QFX10016 has 16 slots for line cards that allow for a smooth transition from 10-Gigabit Ethernet and 40-Gigabit Ethernet networks to 100-Gigabit Ethernet high-performance networks. This switch was previously supported in an “X” release of Junos OS.
QFX10000-60S-6Q line card (QFX10008 and QFX10016 switches)—Starting with Junos OS Release 17.1R1, the QFX10000-60S-6Q line card provides 60 SFP+ ports and six flexible configuration ports for 100Gbps and 40Gbps. Note that as of Release 17.1R1, the SFP+ ports do not support 1-Gbps.
Of the six flexible configuration ports, two ports have QSFP28 sockets that support either 100-Gbps or 40-Gbps speeds. The remaining four ports have QSFP+ sockets that can be configured as either a native 40-Gbps port or four 10-Gbps ports using a breakout cable. With breakout cables, the line card supports a maximum of 84 logical 10-GbE ports.
[See QFX10000-60S-6Q Line Card.]
Class of Service (CoS)
Support for class-of-service-based forwarding (QFX 10000 Series)—CoS-based forwarding (CBF) enables the control of next-hop selection based on a packet's class-of-service field. Starting with Junos OS Release 17.1R1, QFX 10000 Series switches support CBF. You can implement CBF by creating a next-hop-map at the [edit class-of-service forwarding-policy] hierarchy level and then applying the next-hop-map to a policy-statement at the [edit policy-options] hierarchy level. CBF can only be configured on a device with eight or fewer forwarding classes plus a default forwarding class.
Support for data center bridging quantized congestion notification (QFX 10000 Series)—Starting with Junos OS Release 17.1R1, QFX 10000 Series switches support data center bridging quantized congestion notification, which is a congestion management mechanism that sends a congestion notification message through the network to the ultimate source of the congestion, stopping congestion at its source.
New show interfaces command for virtual output queues (QFX 10000 Series)—Starting with Junos OS Release 17.1R1, QFX 10008 Series switches support the show interfaces voq interface-name command, which enables you to view statistics for virtual output queues.
[See show interfaces voq].
Support for data center bridging standards (QFX 10000 Series)—Starting with Junos OS Release 17.1R1, QFX 10008 Series switches support three data center bridging standards:
Priority-based flow control (PFC) allows you to select traffic flows within a link and pause them, so that the output queues associated with the flows do not overflow and drop packets.
Enhanced transmission selection (ETS), also called CoS hierarchical port scheduling, is a two-tier process that provides better port bandwidth utilization and greater flexibility to allocate resources to queues (forwarding classes) and to groups of queues (forwarding class sets).
Explicit congestion notification (ECN) enables end-to-end congestion notification between two endpoints on TCP/IP based networks.
Support for data center bridging standards (QFX 5100 Series)—Starting with Junos OS Release 17.1R1, class of service (CoS) features can be configured on OVSDB-managed VXLAN interfaces on QFX5100 switches. An OVSDB-managed VXLAN interface uses an OVSDB controller to create and manage the VXLAN interfaces and tunnels.
Dynamic Host Configuration Protocol
Virtual-router aware DHCP server/DHCP relay agent (QFX10008 )—Starting with Junos OS Release 17.1R1, QFX10000 switches can be configured to act as a DHCP server or DHCP relay agent for IPv4 and IPv6. If you have virtual router instances on the switch, the DHCP implementation can work with them. This feature was previously supported in an “X” release of Junos OS.
High Availability (HA) and Resilency
Support for high availability features (QFX10000 switches)—Starting with Junos OS Release 17.1R1, the following features are supported:
Graceful Routing Engine switchover (GRES)—Enables a switch with redundant Routing Engines to continue forwarding packets, even if one Routing Engine fails.
To configure GRES, include the graceful-switchover statement at the [edit chassis redundancy] hierarchy level and the synchronize statement at the [edit system commit] hierarchy level.
Nonstop active routing (NSR)—Uses the same infrastructure as GRES to preserve interface and kernel information. NSR also saves routing protocol information by running the routing protocol process (rpd) on the backup Routing Engine.
To configure NSR, include the nonstop-routing statement at the [edit routing-options] hierarchy level.
Nonstop bridging (NSB)—Uses the same infrastructure as GRES to preserve interface and kernel information. NSB also saves Layer 2 Control Protocol (L2CP) information by running the Layer 2 Control Protocol process (l2cpd) on the backup Routing Engine.
To configure NSB, include the nonstop-bridging statement at the [edit protocols layer2-control] hierarchy level.
These features were previously supported in an “X” release of Junos OS.
Infrastructure
Support for Secure Boot (QFX10008 and QFX10016 switches)—Starting with Junos OS Release 17.1R1, 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
LACP hold-up timer configuration support on LAG interfaces (QFX10000 switches)—Starting with Junos OS Release 17.1R1, you can configure a Link Aggregation Control Protocol (LACP) hold-up timer value for link aggregation group (LAG) interfaces. You configure the hold-up timer to prevent excessive flapping of a child (member) link of a LAG interface due to transport layer issues. With transport layer issues, it is possible for a link to be physically up and still cause LACP state-machine flapping. LACP state-machine flapping can adversely affect traffic on the LAG interface. LACP monitors the PDUs received on the child link for the configured time value, but does not allow the member link to transition from the expired or defaulted state to current state. This configuration prevents excessive flapping of the member link. To configure the LACP hold-up timer for LAG interfaces, use the hold-time up timer-value statement at the [edit interfaces ae interface-name aggregated-ether-options lacp] hierarchy level.
This feature was previously supported in an “X” release of Junos OS.
[See Configuring LACP Hold-UP Timer to Prevent Link Flapping on LAG Interfaces.]
Initialization delay timer feature support on LAG interfaces (QFX10000 switches)—Starting with Junos OS Release 17.1R1, you can configure an initialization delay timer value on link aggregation group (LAG) interfaces. When a standby multichassis aggregated Ethernet (MC-AE) interface reboots to come up in active-active MC-AE mode, the Link Aggregation Control Protocol(LACP) protocol comes up faster than the Layer 3 protocols. As soon as LACP comes up, the interface is UP and starts receiving traffic from the neighboring interfaces. In absence of the routing information, the traffic received on the interface is dropped, causing traffic loss. The initialization delay timer, when configured, delays the MC-AE node from coming UP for a specified amount of time. This gives the Layer 3 protocols time to converge on the interface and prevent traffic loss. To configure the initialization delay timer on an MC-AE interface, use the init-delay-timer statement at the [edit interfaces ae interface-name aggregated-ether-options mc-ae] hierarchy level.
This feature was previously supported in an “X” release of Junos OS.
[See mc-ae.]
Support for 10-Gigabit Ethernet on QFX10000-30C line card (QFX10008 and QFX10016)—Starting with Junos OS Release 17.1R1, QFX10008 and QFX10016 switches support 10-Gigabit Ethernet interfaces in addition to 40-Gigabit Ethernet and 100-Gigabit Ethernet interfaces on the QFX10000-30C line card.
When a particular provider edge (PE) is working in mode A to support 10-Gigabit Ethernet, ports 6, 7, 16, 17, 26 , and 27 at the PE0 to PE5 level are non-operational. However, once the PE goes into mode A, these ports can operate at 10-Gigabit Ethernet, 40-Gigabit Ethernet, and 100-Gigabit Ethernet as well.
Depending on the optics that are plugged in, the interface works in 40-Gigabit Ethernet or 100-Gigabit Ethernet speed. For 10-Gigabit Ethernet, you must configure the port using the channelization command. Because there is no port-groups option for the 100-Gigabit Ethernet line card, you must use individual port channelization commands.
In 30C line card, by default FPC comes up in Mode D. when you channelize first port in any PE, whole FPC restarts and corresponding PE comes up in Mode A. Further channelization in that PE does not restart the FPC. But if you channelize some other ports in other PE, then the whole FPC restarts again. If you undo the channelization of all ports in any PE, then FPC gets restarted and corresponding PE comes up in Mode D which is the default mode. [See QFX10000-30C Line Card.]
Note If any mode changes (A to D or D to A) occur at the PE, you must perform a cold reboot on the Packet Forwarding Engine.
Support for multichassis link aggregation groups (MC-LAG) (QFX10000 switches)—Starting with Junos OS Release 17.1R1, you can use MC-LAG to enable 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 MC-LAG 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.]
Support for link aggregation (QFX10000 switches)—Starting with Junos OS Release 17.1R1, you can use multiple network cables and ports in parallel to increase link speed and redundancy.
This feature was previously supported in an “X” release of Junos OS.
[See Understanding Aggregated Ethernet Interfaces and LACP.]
LAG local minimum links per Virtual Chassis or VCF member (QFX5100 switches)—Starting with Junos OS Release 17.1R1, you can use the local minimum links feature to help avoid traffic loss due to asymmetric bandwidth on link aggregation group (LAG) forwarding paths through a Virtual Chassis or Virtual Chassis Fabric (VCF) member switch when one or more LAG member links local to that chassis have failed.
When this feature is enabled, if a user-configured percentage of local LAG member links has failed on a chassis, all remaining local LAG member links on the chassis are forced down, and LAG traffic is redistributed only through LAG member links on other chassis.
To enable local minimum links for an aggregated Ethernet interface (aex), set the local-minimum-links-threshold configuration statement with a threshold value that represents the percentage of local member links that must be up on a chassis for any local LAG member links on that chassis to continue to be active in the aggregated Ethernet bundle. Otherwise, all remaining LAG member links on that chassis are also forced down. The feature responds dynamically to bring local LAG member links up or down if you change the configured threshold, or when the status or configuration of LAG member links changes. Note that forced-down links also influence the minimum links count for the LAG as a whole, which can bring down the LAG, so enable this feature only in configurations where LAG traffic is carefully monitored and controlled.
This feature was previously supported in an “X” release of Junos OS.
Support for Micro BFD over child links of AE or LAG bundle (cross-functional Packet Forwarding Engine/kernel/rpd) (QFX10000 switches)—Starting with Junos OS Release 17.1R1, this feature provides a Layer 3 BFD liveness detection mechanism for child links of the Ethernet LAG interface. In scenarios in which you do not have a point-to-point link, and a Layer 1 device fails at one end of the link, Micro BFD detects failures faster than traditional LACP. Micro BFD sessions are independent of each other despite having a single client that manages the LAG interface. Micro BFD is not supported on pure Layer 2 interfaces.
To enable failure detection for aggregated Ethernet interfaces, include the bfd-liveness-detection statement at the [edit interfaces aex aggregated-ether-options bfd-liveness-detection] hierarchy level.
This feature was previously supported in an “X” release of Junos OS.
PVLAN and Q-in-Q on the same interface (QFX5100 Switches) —Starting with Junos OS Release 17.1R1, you can configure a private VLAN and Q-in-Q tunneling on the same Ethernet port. To configure both PVLAN and Q-in-Q on the same physical interface, you must configure flexible Ethernet services to support dual methods of configuring logical interfaces. Q-in-Q requires a service provider configuration method, and PVLAN requires an enterprise configuration method.
This feature was previously supported in an “X” release of Junos OS.
[See Understanding Flexible Ethernet Services Encapsulation on Switches.]
Support for configuration synchronization for MC-LAG (QFX10000 switches)—Starting with Junos OS Release 17.1R1, Multichassis Link Aggregation group (MC-LAG) configuration synchronization enables you to easily propagate, synchronize, and commit configurations from one MC-LAG peer to another. You can log into any one of the MC-LAG peers to manage both MC-LAG peers, thus having a single point of management. You can also use configuration groups to simplify the configuration process. You can create one configuration group for the local MC-LAG peer, one for the remote MC-LAG peer, and one for the global configuration, which is essentially a configuration that is common to both MC-LAG peers.
In addition, you can create conditional groups to specify when a configuration is synchronized with another MC-LAG peer. You can enable the peers-synchronize statement at the [edit system commit] hierarchy to synchronize the configurations and commits across the MC-LAG peers by default. NETCONF over SSH provides a secure connection between the MC-LAG peers, and Secure Copy Protocol (SCP) copies the configurations securely between them.
This feature was previously supported in an “X” release of Junos OS.
Support for configuration consistency check for MC-LAG (QFX10000 switches)—Starting with Junos OS Release 17.1R1, Multichassis Link Aggregation group (MC-LAG) configuration consistency check alerts you of both severe and moderate configuration inconsistencies across MC-LAG peers. The configuration consistency check feature checks MC-LAG configuration parameters, such as chassis ID, session establishment time, and so on, on each peer and notifies you of any errors, so you can fix the inconsistencies. Configuration inconsistencies are categorized as severe or moderate. If there is a severe inconsistency, the MC-LAG interface is prevented from coming up. Once you have corrected the inconsistency, the system will bring up the interface. If there is a moderate inconsistency, you are notified of the error and can then fix the inconsistency. After you fix any inconsistency, you must commit the changes to take effect.
This feature was previously supported in an “X” release of Junos OS.
[See Understanding Multichassis Link Aggregation Group Configuration Consistency Check.]
Configuration support to improve MC-LAG Layer 2 and Layer 3 convergence (QFX10000 switches)—Starting with Junos OS Release 17.1R1, you can configure multichassis link aggregation (MC-LAG) interfaces to improve Layer 2 and Layer 3 convergence time when a multichassis aggregated Ethernet link goes down or comes up in a bridge domain. To use this feature, ensure that the Inter-Chassis Link (ICL) is configured on an aggregated Ethernet interface. For Layer 2 convergence, configure the enhanced-convergence statement at the [edit interfaces aex aggregated-ether-options mc-ae] hierarchy level. For Layer 3 convergence, configure the enhanced-convergence statement on an integrated routing and bridging (IRB) interface at the [edit interfaces irb unit unit-number] hierarchy level.
This feature was previously supported in an “X” release of Junos OS.
[See enhanced-convergence.]
Channelizing 40-Gigabit Ethernet QSFP+ ports (QFX10008 switch)—This feature enables you to channelize four 10-Gigabit Ethernet interfaces from the 40-Gigabit Ethernet QSFP+ interfaces. Channelization is supported on fiber break-out cable using standard structured cabling techniques.
Note This feature is not supported on the QFX10000-30C line card.
By default, the 40-Gigabit Ethernet QSFP+ interfaces are named et-fpc/pic/port. The resulting 10-Gigabit Ethernet interfaces appear in the following format: xe-fpc/pic/port:channel, where channel can be a value of 0 through 3. To channelize a 40-Gigabit Ethernet QSFP+ interface into four 10-Gigabit Ethernet interfaces, include the 10g statement at the [edit chassis fpc fpc-slot pic pic-slot ( port port-number | port-range port-range-low port-range-high) channel-speed] hierarchy level. To revert the 10-Gigabit Ethernet channels to a full 40-Gigabit Ethernet interface, remove the 10g statement from the same hierarchy level.
There are 100-Gigabit Ethernet ports that work either as 100-Gigabit Ethernet or as 40-Gigabit Ethernet but are recognized as 40-Gigabit Ethernet by default. You cannot channelize the 100-Gigabit Ethernet ports when they are operating as 100-Gigabit Ethernet interfaces. The 40-Gigabit Ethernet ports can operate independently or be channelized into four 10-Gigabit Ethernet ports as part of a port range. Ports cannot be channelized individually. Only the first and fourth port in each 6XQSFP cage is available to channelize as part of a port range. In a port range, the ports are bundled with the next two consecutive ports. For example, if you want to channelize ports 0 through 2, you channelize port 0 only. If you try to channelize a port that is not supported, you receive an error message when you commit the configuration. Auto-channelization is not supported on any ports.
When a 40-Gigabit Ethernet transceiver is inserted into a 100-Gigabit Ethernet port, the port recognizes the 40-Gigabit Ethernet port speed. When a 100-Gigabit Ethernet transceiver is inserted into the port and enabled in the CLI, the port recognizes the 100-Gigabit Ethernet speed and disables two adjacent 40-Gigabit Ethernet ports.
This feature was previously supported in an “X” release of Junos OS.
[See Channelizing Interfaces.]
IP Tunneling
Generic Routing Encapsulation support (QFX10008 and QFX10016 switches)—Starting with Junos OS Release 17.1R1, you can configure GRE tunnels. GRE provides a private, secure path for transporting packets through a public network by encapsulating (or tunneling) the packets. GRE tunneling is accomplished through tunnel endpoints that encapsulate or de-encapsulate traffic. To configure a GRE tunnel interface, include the gre-fpc/pic/port set of statements at the [edit interfaces] hierarchy level.
This feature was previously supported only on the QFX10002 switch.
IPv4
IPv4 address conservation method for hosting providers (QFX10000 switches)—Starting with Junos OS Release 17.1R1, you can configure a static route on an IRB interface with or without pinning to a specific underlying interface, thereby conserving the usage of IP address space.
Configure the interface on the router with an address from the reserved IPv4 prefix for shared address space (RFC 6598) and by using static routes pointed at the interface. IANA has recorded the allocation of an IPv4 /10 for use as shared address space. The shared address space address range is 100.64.0.0/10.
This way, the interface in the router is allocated an IP address from the shared address space, so it is not consuming publicly routable address space, and connectivity is handled with static routes on an interface. The interface in the server is configured with a publicly routable address, but the router interfaces are not. Network and broadcast addresses are consumed out of the shared address space rather than the publicly routable address space.
[See IPv4 Address Conservation Method for Hosting Providers.]
Layer 2 Features
Support for Layer 2 Features (QFX10000 switches)—Starting with Junos OS Release 17.1R1, 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 )—Provide Layer 2 loop prevention.
These features were previously supported in an “X” release of Junos OS.
NNI and UNI on same interface (QFX5100 switches)—Starting with Junos OS Release 17.1R1, this feature allows you to configure the same interface as a network-to-network interface (NNI) and a user-network interface (UNI) when you use Q-in-Q tunneling. This feature was previously supported in an “X” release of Junos OS.
Q-in-Q tunneling support (QFX10008 and QFX10016 switches)—Starting with Junos OS Release 17.1R1, this feature 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. This feature was previously supported in an “X” release of Junos OS.
Support for IRB interfaces on Q-in-Q VLANs (QFX5100 switches and QFX5100 Virtual Chassis)—Starting with Junos OS Release 17.1R1, integrated routing and bridging (IRB) interfaces are supported on Q-in-Q VLANs—you can configure the IRB interface on the same interface as one used by an S-VLAN, and you can use the same VLAN ID for both the VLAN used by the IRB interface and for the VLAN used as an S-VLAN. This feature was previously supported in an “X” release of Junos OS.
Dual VLAN tag translation (QFX5100 switches and QFX5100 Virtual Chassis)—Starting with Junos OS Release 17.1R1, you can use the dual VLAN tag translation (also known as dual VLAN tag rewrite) feature to deploy switches in service-provider domains, allowing dual-tagged, single-tagged, and untagged VLAN packets to come into or exit from the switch. Operations added for dual VLAN tag translation are swap-push, swap-swap, and pop-push. This feature was previously supported in an “X” release of Junos OS.
Layer 3 Features
Support for Layer 3 unicast features (QFX10000 switches)—Starting with Junos OS Release 17.1R1, the following layer 3 features for unicast IPv4 and IPv6 traffic are supported on QFX10000 switches:
Neighbor Discovery Protocol (IPv6 only)
Virtual Routers
OSPF
IS-IS
BGP
VRRP
This feature set was previously supported in an “X” release of Junos OS.
Management
Support for adding non-native YANG modules to the Junos OS schema (QFX Series)—Starting in Junos OS Release 17.1R1, you can load custom YANG models on devices running Junos OS to add data models that are not natively supported by Junos OS but can be supported by translation. Doing this enables you to extend the configuration hierarchies and operational commands with data models that are customized for your operations. The ability to add data models to a device is also beneficial when you want to create device-agnostic and vendor-neutral data models that enable the same configuration or RPC to be used on different devices from one or more vendors. You can load custom YANG modules by using the request system yang add operational command.
[See Understanding the Management of Non-Native YANG Modules on Devices Running Junos OS.]
Multicast
Layer 2 and layer 3 multicast support (QFX10000 switches)—Starting with Junos OS Release 17.1R1, IGMP, including versions 1, 2, and 3, IGMP snooping, PIM-SM and PIM-SSM are supported. You can also configure IGMP, IGMP snooping and PIM in virtual-router instances. MSDP is also supported. Configure IGMP at the [edit protocols igmp] hierarchy level. Configure IGMP snooping at [edit protocols igmp-snooping] hierarchy level. Configure PIM at the [edit protocols pim] hierarchy level. Configure MSDP at the [edit protocols msdp] hierarchy level.
This feature set was previously supported in an “X” release of Junos OS.
[See Multicast Overview.]
MPLS
Path Computation Element Protocol (QFX10000 switch)—Starting in Junos OS Release 17.1R1, QFX10000 switch supports the Path Computation Element Protocol (PCEP). A Path Computation Element (PCE) is an entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. A Path Computation Client (PCC) is any client application requesting a path computation to be performed by a PCE. PCEP enables communications between a PCC and a PCE, or between two PCEs (defined in RFC 5440).
[See PCEP Overview.]
Static label-switched path with resolve next hop (QFX5100 switches)—Starting in Junos OS Release 17.1R1, you can configure a static label-switched path (LSP) to be resolved to a next hop that is not directly connected. This feature provides simplicity and scalability to your configuration, because you are no longer required to configure multiple, directly connected next hops if you have multiple links.
This feature was previously supported in an “X” release of Junos OS.
MPLS support (QFX5100 switches)—Starting in Junos OS Release 17.1R1, Multiprotocol Label Switching (MPLS) is supported on the QFX10008 and QFX10016 switches. MPLS provides both label edge router (LER) and label switch router (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), a component of MPLS local protection (both one-to-one local protection and many-to-one local protection are supported).
Loop-free alternate (LFA)
SixPE 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 IRB interfaces over MPLS (QFX5100 switches)—Starting in Junos OS Release 17.1R1, you can configure integrated routing and bridging (IRB) interfaces over an MPLS network. An IRB is a logical Layer 3 VLAN interface used to route traffic between VLANs. An IRB interface functions as a logical switch on which you can configure a Layer 3 logical interface for each VLAN. The switch relies on its Layer 3 capabilities to provide this basic routing between VLANs.
This feature was previously supported in an “X” release of Junos OS.
[See Example: Configuring IRB Interfaces on QFX5100 Switches over an MPLS Core Network.]
Support for MPLS automatic bandwidth allocation and dynamic label switched path (LSP) count sizing (QFX10000 switches)—Starting with Junos OS Release 17.1R1, automatic bandwidth allocation allows an MPLS tunnel to automatically adjust its bandwidth allocation based on the volume of traffic flowing through the tunnel. You can configure an LSP with minimal bandwidth, and rely on this feature to dynamically adjust the bandwidth allocation based on current traffic patterns. Dynamic LSP count sizing provides an ingress router with the capability of acquiring as much network bandwidth as possible by creating parallel LSPs dynamically. The bandwidth adjustments do not interrupt traffic flow through the tunnel.
This feature was previously supported in an “X” release of Junos OS.
Support for MPLS filters (QFX10000 switches)—Starting in Junos OS Release 17.1R1, you can configure firewall filters to filter MPLS traffic. To use an MPLS firewall filter, you must first configure the filter and then apply it to an interface that you have configured for forwarding MPLS traffic. You can also configure a policer for the MPLS filter to police (that is, rate-limit) the traffic on the interface to which the filter is attached.
This feature was previously supported in an “X” release of Junos OS.
BGP link state distribution (QFX Series and QFX10000)—Starting with Junos OS Release 17.1R1, you can deploy a mechanism to distribute topology information across multiple areas and autonomous systems (ASs) by extending the BGP protocols to carry link state information. Previously, this information was acquired using an IGP. Using BGP provides a policy-controlled and scalable means of distributing the multi-area and multi-AS topology information. This information is used for computing paths for MPLS LSPs spanning multiple domains, such as inter-area TE LSP. This information also enables external path computing entities.
Ethernet-over-MPLS L2 circuit (QFX10000 switches)—Starting in Junos OS Release 17.1R1, you can configure a Layer 2 circuit to create a point-to-point Layer 2 connection using MPLS on the service provider's network. Ethernet-over-MPLS allows sending Layer 2 (L2) Ethernet frames transparently over MPLS. Ethernet-over-MPLS uses a tunneling mechanism for Ethernet traffic through an MPLS-enabled Layer 3 core. It encapsulates Ethernet protocol data units (PDUs) inside MPLS packets and forwards the packets, using label stacking, across the MPLS network. To enable a Layer 2 circuit, include the l2circuitstatement at the [edit protocols mpls labeled-switched-path lsp-name] hierarchy level.
This feature was previously supported in an “X” release of Junos OS.
Network Management and Monitoring
Support for hrProcessorTable object (QFX Series)—Starting in Junos OS Release 17.1R1, support is provided for the hrProcessorTable object (object id: 1.3.6.1.2.1.25.3.3) described in the RFC2790, Host Resources MIB. The hrProcessorTable object provides the load statistics information per CPU for multi-core devices.
[See SNMP MIB Explorer.]
IEEE 802.3ah (QFX10002, QFX10008, QFX10016)—QFX Series switches support the IEEE 802.3ah standard for the Operation, Administration, and Maintenance (OAM) of Ethernet in networks. The standard defines OAM link fault management (LFM). You can configure IEEE 802.3ah OAM LFM on point-to-point Ethernet links that are connected either directly or through Ethernet repeaters. Ethernet OAM provides the tools that network management software and network managers can use to determine how a network of Ethernet links is functioning.
Port mirroring support (QFX10008 and QFX10016 switches)—Starting with Junos OS Release 17.1R1, port mirroring copies packets entering or exiting a port or entering a VLAN and sends the copies to a local interface for local monitoring. You can 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.]
sFlow technology support (QFX10008/QFX10016 switches)—Starting in Junos OS Release 17.1R1, the QFX10008 and QFX10016 switches support monitoring technology for high-speed switched or routed networks. You can configure sFlow technology to monitor traffic continuously at wire speed on all interfaces simultaneously. sFlow technology 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 Security
Support for MAC limiting and MAC move limiting on OVSDB-managed interfaces (QFX5100 switches)—Starting in Junos OS Release 17.1R1, you can you can configure MAC limiting and MAC move limiting on interfaces managed by a Contrail controller through the Open vSwitch Database (OVSDB) management protocol. MAC limiting protects against flooding of the Ethernet switching table. MAC move limiting detects MAC movement and MAC spoofing on access interfaces.
This feature was previously supported in an “X” release of Junos OS.
[See Understanding MAC Limiting and MAC Move Limiting for Port Security.]
Routing Policy and Firewall Filters
IPv4 filter-based GRE tunneling (QFX10000 switches)—Starting in Junos OS Release 17.1R1, QFX10000 switches support filter-based generic routing encapsulation (GRE) tunneling across IPv4 networks. GRE tunneling is performed by tunnel endpoints that encapsulate or de-encapsulate traffic. With filter-based GRE tunneling, you can use a firewall filter to de-encapsulate traffic over an Ipv4 network. For example, you can terminate many tunnels from multiple source IP addresses with one firewall term. This provides significant benefits in terms of scalability, performance, and flexibility because you don't need to create a tunnel interface to perform the de-encapsulation.
[See Configuring a Firewall Filter to De-Encapsulate GRE Traffic on a QFX5100, QFX10000, or OCX Switch.]
Routing Protocols
Support for BGP flow routes for traffic filtering (QFX10000 switches)—Starting with Junos OS Release 17.1R1, you can propagate flow routes as part of BGP through flow-specification network-layer reachability information (NLRI) messages. Flow routes provide traffic filtering and rate-limiting capabilities much like firewall filters. Propagating flow routes as part of BGP enables you to propagate filters against denial-of-service (DOS) attacks dynamically across autonomous systems. Include the flow route name set of statements at the [edit routing-options] hierarchy level.
See [Example: Enabling BGP to Carry Flow-Specification Routes.]
Support for advertising multiple paths in BGP (QFX5100 switches and QFX10000 switches)—Starting with Junos OS Release 17.1R1, you can configure BGP to advertise multiple paths to the same destination, instead of advertising only the active path. The potential benefits of advertising multiple paths for BGP include fault tolerance, load balancing, and maintenance. Include the add-path set of statements at the [edit protocols bgp group group-name family family-type] hierarchy level.
[See add-path.]
Enhancement to ECMP next-hop groups (QFX5100 switches)—Starting with Junos OS Release 17.1R1, equal-cost multipath (ECMP) next hops are allocated dynamically. A dynamic, rather than fixed, allocation of ECMP next hops, or paths, effectively increases the number of ECMP groups available for route resolution. For example, if the maximum number of ECMP next hops is set to 16, a dynamic allocation means that as many 1,000 ECMP groups are supported. To configure the maximum limit for ECMP next hops, include the maximum-ecmp next-hops statement at the [edit chassis] hierarchy level.
This feature was previously introduced in an "X" release of Junos OS.
[See Configuring ECMP Next Hops for RSVP and LDP LSPs for Load Balancing.]
Support for BGP Monitoring Protocol (BMP) Version 3 (QFX10000 switches)—Starting with Junos OS Release 17.1R1, 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.
This feature was previously introduced in an "X" release of Junos OS.
Security
Firewall filter support (QFX10008/QFX10016 switches)--Starting in Junos OS Release 17.1R1, you can define firewall filters on the switch that defines 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.]
Policing support (QFX10008/QFX10016 switches)--Starting in Junos OS Release 17.1R1, you can use policing to apply limits to traffic flow and to set consequences for packets that exceed those limits. A switch polices traffic by limiting the input or output transmission rate of a class of traffic according to user-defined criteria. Policing (or rate-limiting) 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.]
Support for policers on OVSDB-managed interfaces (QFX5100 switches)--Starting in Junos OS Release 17.1R1, you can configure two-rate three-color markers (policers) on interfaces managed by a Contrail controller through the Open vSwitch Database (OVSDB) management protocol.
This feature was previously supported in an “X” release of Junos OS.
Support for firewall filters on OVSDB-managed interfaces (QFX5100 switches)--Starting in Junos OS Release 17.1R1, you can configure firewall filters on interfaces managed by a Contrail controller through the Open vSwitch Database (OVSDB) management protocol. Firewall filters enable you to control packets transiting a device to a network destination as well as packets destined for and sent by a device.
This feature was previously supported in an “X” release of Junos OS.
[See Understanding Firewall Filters on OVSDB-Managed Interface.]
Software Defined Networking
Support for EVPN-VXLAN (QFX5100 and QFX10000 switches)—Traditionally, data centers use Layer 2 technologies such as STP and multi-chassis link aggregation groups (MC-LAGs) for compute and storage connectivity. As the design of data centers shifts to scale-out, service-oriented multi-tenant networks, a new data center architecture emerges that allows decoupling of an underlay network from the tenant overlay network with VXLAN. Starting with Junos OS Release 17.1R1, you can use a Layer 3 IP-based underlay coupled with an EVPN-VXLAN overlay to deploy larger networks than those possible with traditional Layer 2 Ethernet-based architectures. With an EVPN-VXLAN overlay, endpoints (servers or virtual machines) can be placed anywhere in the network and remain connected to the same logical Layer 2 network.
This feature was previously supported in an “X” release of Junos OS.
Support for LACP in EVPN active-active multihoming (QFX10000 switches)—Starting with Junos OS Release 17.1R1, an extra level of redundancy can be achieved in an Ethernet VPN (EVPN) active-active multihoming network by configuring the Link Aggregation Control Protocol (LACP) on both the endpoints of the link between the multihomed customer edge (CE) and provider edge (PE) devices. The link aggregation group (LAG) interface of the multihomed CE-PE link can either be in the active or in the standby state. The interface state is monitored and operated by LACP to ensure fast convergence on isolation of a multihomed PE device from the core. When there is a core failure, a traffic black hole can occur at the isolated PE device. With the support for LACP on the CE-PE link, at the time of core isolation, the CE-facing interface of the multihomed PE device is set to the standby state, thereby blocking data traffic transmission from and toward the multihomed CE device. After the core recovers from the failure, the interface state is switched back from standby to active.
To configure LACP in EVPN active-active multihoming network:
On the multihomed CE device include the lacp active statement at the [edit interfaces aex aggregated-ether-options] hierarchy.
On the multihomed PE device include the lacp active statement at the [edit interfaces aex aggregated-ether-options] hierarchy, and include the service-id number statement at the [edit switch-options] hierarchy.
[See Understanding LACP for EVPN Active-Active Multihoming.]
OVSDB schema updates (QFX5100, QFX5100VC)—Starting with Junos OS Release 17.1R1, the Open vSwitch Database (OVSDB) schema (for physical devices) implemented on QFX5100 switches is version 1.3.0. In addition, this schema now supports the multicast MACs local table.
This feature was previously supported in an “X” release of Junos OS.
Class-of-service support for OVSDB-managed VXLAN interfaces (QFX5100 switches)—Starting with Junos OS Release 17.1R1, class-of-service (CoS) features can be configured on OVSDB-managed VXLAN interfaces on QFX5100 switches. An OVSDB-managed VXLAN interface uses an OVSDB controller to create and manage the VXLAN interfaces and tunnel. T
his feature was previously supported in an “X” release of Junos OS.
Support for ping and traceroute with VXLANs (QFX5100 switches)—Starting with Junos OS Release 17.1R1, you can use ping and traceroute to troubleshoot the physical underlay that supports a VXLAN overlay.
This feature was previously supported in an “X” release of Junos OS.
[See Understanding Overlay ping and traceroute Packet Support.]
PIM NSR support for VXLAN (QFX5100 Virtual Chassis)—Starting in Junos OS Release 17.1R1, the QFX5100 Virtual Chassis supports Protocol Independent Multicast (PIM) nonstop active routing (NSR) for Virtual Extensible LANs (VXLANs).
The Layer 2 address learning daemon (l2ald) passes VXLAN parameters (VXLAN multicast group addresses and the source interface for a VXLAN tunnel vtep-source-interface to the routing protocol process on the master Routing Engine. The routing protocol process forms PIM joins with the multicast routes through the pseudo-VXLAN interface based on these configuration details.
Because the l2ald daemon does not run on the backup Routing Engine, the configured parameters are not available to the routing protocol process in the backup Routing Engine when NSR is enabled. The PIM NSR mirroring mechanism provides the VXLAN configuration details to the backup Routing Engine, which enables creation of the required states. The routing protocol process matches the multicast routes on the backup Routing Engine with PIM states, which maintains the multicast routes in the Forwarding state.
Software Installation and Upgrade
Support for FreeBSD 10 kernel for Junos OS (QFX10000 switches)—Starting with Junos OS Release 17.1R1, FreeBSD is the underlying OS that enables SMP for Junos OS, rather than the FreeBSD 6.1 version that is used is some older Juniper Networks devices. If you compare the switch to devices that run the older kernel, you will notice that some system commands display different output and a few other commands are deprecated.
This feature was previously supported in an “X” release of Junos OS.
System Management
Support for Precision Time Protocol (PTP) transparent clock (QFX10000 switches)—Starting with Junos OS Release 17.1R1, 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.
This feature was previously supported in an “X” release of Junos OS.
[See Understanding Transparent Clocks in Precision Time Protocol.]
Support for reporting FATAL and MAJOR FAULT information (QFX10000 switches)—Starting in Junos OS Release 17.1R1, FATAL and MAJOR errors are reported in the output of the show chassis fpc errors command.
This feature was previously supported in an “X” release of Junos OS.
VPNs
Support for carrier-of-carriers Layer 3 VPNs (QFX10000 switches)—Staring in Junos OS 17.1R1, this feature is supported for customers who want to provide VPN service. Layer 3 VPNs based on BGP MPLS are used by service providers to provide VPN services to end-user customers, enabling these customers to use the MPLS backbone network to connect their multiple sites seamlessly. Include the labeled-unicast statement in the configuration for the IBGP session to the carrier-of-carriers customer’s CE device and include the family-inet-vpn statement in the configuration for the IBGP session to the carrier-of-carriers PE device on the other side of the network.
[See Configuring Carrier-of-Carriers VPNs for Customers That Provide VPN Service.]
IPv6 Layer 3 VPNs (QFX5100 and QFX10000 switches)—You can now configure switch interfaces in a Layer 3 VPN to carry IPv6 traffic. This feature, commonly referred to as 6VPE, allows for the transport of IPv6 traffic across an MPLS-enabled IPv4 backbone to provide VPN service for IPv6 customers.
This feature was previously supported in an “X” release of Junos OS.
[See Example: Tunneling IPv6 Traffic over MPLS IPv4 Networks.]