Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

New and Changed Features

This section describes the new features and enhancements to existing features in Junos OS Release 14.1X53 for the QFX Series.

New Features in Release 14.1X53-D40

Class of Service

  • Support for policy drop counters in CLI and SNMP (QFX Series switches)—Starting in Junos OS Release 14.1X53-D40, the show interfaces interface-name statistics detail command displays the number of packets dropped on an interface because of policers configured for that interface. The number of packet drops is displayed in the command output in the Bucket drops field under Input errors and Output errors. These statistics are also available through SNMP.

    See show interfaces xe.

High Availability (HA) and Resiliency

  • NSSU improvements to optimize total upgrade time and recover from software image copy or reboot failures (QFX5100 Virtual Chassis or Virtual Chassis Fabric [VCF])—Starting in Junos OS Release 14.1X53-D40, nonstop software upgrade (NSSU) on a Virtual Chassis or VCF supports the following optimizations and error recovery measures:
    • To optimize the time needed to complete NSSU, the master member copies the new software in parallel to multiple members at a time rather than waiting for the copy operation to complete to each member before copying the software image to the next member. By default, the number of parallel copy sessions is based on the Virtual Chassis or VCF size, or you can configure a specific number using the rcp-count number configuration statement.
    • As before, the master aborts the NSSU process if copying the new software to any member fails. As a new error recovery measure, the master also removes the new software image from all members to which it was already transferred.
    • During NSSU, when each member is rebooted in turn with the new software, if any member fails to reboot, the master aborts the NSSU process. As a new recovery measure, the master automatically brings down and reboots the entire Virtual Chassis or VCF. This recovery action causes downtime for the Virtual Chassis or VCF, but brings it up in a stable state, cleanly running the new software on all members without requiring you to manually recover members individually.

    [See Understanding Nonstop Software Upgrade on a Virtual Chassis and Mixed Virtual Chassis or Understanding Nonstop Software Upgrade on a Virtual Chassis Fabric.]

Interfaces and Chassis

  • LAG local minimum links per Virtual Chassis or VCF member (QFX5100 switches)—Introduced in Junos OS Release 14.1X53-D40, the local minimum links feature helps 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.

    [See Understanding Local Minimum Links.]

Layer 2 Features

  • Support for IRB interfaces on Q-in-Q VLANs (QFX5100 switches and QFX5100 Virtual Chassis)—Starting with Junos OS Release 14.1X53-D40, 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.

    Packets arriving on an IRB interface that is using Q-in-Q VLANs will get routed regardless of whether the packet is single tagged or double tagged. The outgoing routed packets contain an S-VLAN tag only when exiting a trunk interface; the packets exit the interface untagged when exiting an access interface.

    Note: You can configure the IRB interface only on S-VLAN (NNI) interfaces, not on C-VLAN (UNI) interfaces.

    [See Understanding Q-in-Q Tunneling.]

  • Dual VLAN tag translation (QFX5100 switches and QFX5100 Virtual Chassis)—Starting with Junos OS Release 14.1X53-D40, 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.

    Dual VLAN tag translation supports:

    • Configuration of S-VLANs (NNI) and C-VLANs (UNI) on the same physical interface
    • Control protocols such as VSTP, OSPF, and LACP
    • IGMP snooping
    • Configuration of a private VLAN (PVLAN) and VLAN on a single-tagged interface
    • Use of TPID 0x8100 on both inner and outer VLAN tags

    [See Understanding Q-in-Q Tunneling.]

  • Support to exclude RVIs from state calculations (QFX5100 switches)—Starting with Junos OS Release 14.1X53-D40, you can exclude a trunk or access interface from the state calculation for a routed VLAN interface (RVI) for member VLANs. An RVI typically has multiple ports in a single VLAN. Excluding trunk and access interfaces from state calculations means that as that soon as the port specifically assigned to the VLAN goes down, the RVI for the VLAN is marked as down. Include the autostate-exclude statement at the [edit interfaces ether-options] hierarchy level.

    [See Excluding a Routed VLAN Interface from State Calculations.]

MPLS

  • Support for IRB interfaces over an MPLS core network (QFX5100 switches)—Starting in Junos OS Release 14.1X53-D40, you can configure integrated routing and bridging (IRB) interfaces over an MPLS network on QFX5100 switches. An IRB is a logical Layer 3 VLAN interface used to route traffic between VLANs.

    By definition, VLANs divide a LAN’s broadcast environment into isolated virtual broadcast domains, thereby limiting the amount of traffic flowing across the entire LAN and reducing the possible number of collisions and packet retransmissions within the LAN. To forward packets between different VLANs, you normally need a router that connects the VLANs. Now you can accomplish this forwarding without using a router by simply configuring an IRB interface on the switch. The 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. With IRB, you can configure label-switched paths (LSPs) to enable the switch to recognize which packets are being sent to local addresses, so that they are bridged (switched) whenever possible and are routed only when necessary. Whenever packets can be switched instead of routed, several layers of processing are eliminated.

    [See Example: Configuring IRB Interfaces on QFX5100 Switches over an MPLS Core Network and Understanding Integrated Routing and Bridging .]

Multicast Protocols

  • Support for static multicast route leaking for VRF and virtual-router instances (QFX5100 and EX4300 switches)—Starting with Junos OS Release 14.1X53-D40, you can configure your switch to share IPv4 multicast routes among different virtual routing and forwarding (VRF) instances or different virtual-router instances. 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.

    On the EX4300 switch, multicast route leaking is supported only when the switch functions as a line card in a Virtual Chassis.

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

QFabric Systems

  • Support for displaying the Junos OS software version stored in a USB installer key (QFabric systems)—Starting with Junos OS Release 14.1X53-D40, you can display the version of Junos OS software stored on a standard USB installer key when it is inserted on a Director group device by issuing the show system software usb-software-version command.
  • Support for EX4300 switches in a QFabric System control plane—Starting in Junos OS Release 14.1X53-D40, EX4300 switches can be used as the control plane switches in a QFabric System instead of EX4200 switches.
    • The control plane of a QFX3000-G QFabric System can be comprised of two Virtual Chassis with four EX4300-48T switches each for a copper-based control plane, or four EX4300-48P switches for a fiber-based control plane. Four 10-Gigabit Ethernet uplink ports on each Virtual Chassis connect the two Virtual Chassis configurations together.
    • The control plane of a QFX3000-M QFabric System can be comprised of two EX4300-48T switches with an SFP+ uplink module installed for a copper-based control plane, or two EX4300-48P switches with an SFP+ uplink module installed for a fiber-based control plane.

    You cannot mix EX4300 switches and EX4200 switches in the same QFabric system; the control plane must be comprised of the same type of switch.

    Note: Junos OS Release 15.1R3 is the recommended software version for the EX4300 switches.

    [See Understanding QFX3000-G QFabric System Hardware Configurations, Understanding QFX3000-M QFabric System Hardware Configurations, and Understanding the QFabric System Control Plane.]

  • Support for SNMPv3 (QFabric systems) —Starting in Junos OS Release 14.1X53-D40, QFabric systems support SNMP version 3 (SNMPv3). In contrast to SNMP version 1 (SNMPv1) and SNMP version 2 (SNMPv2), SNMPv3 supports authentication and encryption. With SNMPv3, you can query QFabric systems by using the SNMPv3 request, receive SNMPv3 traps and informs, and query QFabric SNMPv3 MIBs for authentication and encryption. SNMPv3 offers strong authentication to determine whether a message is arriving from a valid source and provides message encryption to prevent the data from being snooped by an unauthorized source.

    [See SNMP v3 Overview]

Security

  • Distributed denial-of-service (DDOS) protection (QFX5100 switches and Virtual Chassis)—A denial-of-service (DoS) attack is any attempt to deny valid users access to network or server resources by using up all the resources of the network element or server. Distributed denial-of-service attacks (DDoS) involve an attack from multiple sources, enabling a much greater amount of traffic to attack the network. The attacks typically use network protocol control packets to trigger a large number of exceptions to the switch control plane. This results in an excessive processing load that disrupts normal network operations. Starting in Junos OS 14.1X53-D40, Junos OS DDoS protection enables QFX5100 switches and Virtual Chassis to continue functioning while under attack. It identifies and suppresses malicious control packets while enabling legitimate control traffic to be processed. A single point of DDoS protection management enables network administrators to customize profiles for their network control traffic.

    [See Understanding Distributed Denial-of-Service Protection on QFX Series Switches].

Software-Defined Networking (SDN)

  • OVSDB-VXLAN support with VMware NSX for vSphere (QFX5100 switches)—Starting with Junos OS Release 14.1X53-D40, the Junos OS implementation of the Open vSwitch Database (OVSDB) management protocol provides a means through which NSX controllers and QFX5100 standalone switches that function as virtual tunnel endpoints (VTEPs) can communicate. In an NSX for vSphere (NSX-v) version 6.2.4 environment, NSX controllers and QFX5100 switches can exchange control and statistical information via the OVSDB schema for physical devices, thereby enabling virtual machine (VM) traffic from entities in a virtual network to be forwarded to bare-metal servers in a physical network and vice versa. You can set up a connection between the QFX5100 management interface (em0 or em1) and an NSX controller.

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

  • BFD in a VMware NSX for vSphere environment with OVSDB and VXLAN (QFX5100 switches)—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 with Junos OS Release 14.1X53-D40, a Juniper Networks switch that functions as a hardware VTEP in a VMware NSX for vSphere (NSX-v) environment uses the Bidirectional Forwarding Detection (BFD) protocol to prevent the forwarding of BUM packets to a nonfunctional 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 are, therefore, reachable. Upon receipt of a BUM packet on an OVSDB-managed interface, the hardware VTEP can choose one of the functioning replicators to handle the packet.

    [See Understanding BFD in a VMware NSX Environment with OVSDB and VXLAN.]

  • EVPN-VXLAN support of Virtual Chassis and Virtual Chassis Fabric (QFX5100, QFX5100 Virtual Chassis, 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 with Release 14.1X53-D40, the two leaf devices can be QFX5100 standalone switches, QFX5100 switches configured as a Virtual Chassis, QFX5100 switches configured as a Virtual Chassis Fabric (VCF), or a mix of these options.

    On each leaf device, the LAG interface is configured with the same Ethernet segment identifier (ESI) for the host. The two leaf devices on which the same ESI is configured are peers to each other.

    If a host, for example, host 1, is connected to two leaf devices through LAG interfaces, Layer 2 broadcast, unknown unicast, and multicast (BUM) traffic is handled as follows:

    • Sending BUM packets—Through the control of the LAG interface, only one copy of a BUM packet is forwarded from host 1 to one of the leaf devices to which host 1 is connected.
    • Receiving BUM packets from another host in the Layer 2 overlay—Per multihoming active-active mode, one of the leaf devices to which host 1 is connected is elected as a designated forwarder (DF). If another host in the Layer 2 overlay—for example, host 2—sends a BUM packet, both leaf devices to which host 1 is connected receive the packet, but only the DF forwards it to host 1. The other leaf device drops the packet.
    • Receiving BUM packets from the host that originated the packets—If host 1 sends a BUM packet, the packet is received by all other leaf devices in the Layer 2 overlay, including the peer leaf device to which host 1 is also connected. In this case, the peer leaf device drops the packet because the packet must not be forwarded to host 1, which originated the packet.
    • Receiving BUM packets from another host connected to the same leaf device—If another host—for example, host 3—that is connected to the same leaf device as host 1 sends a BUM packet, the packet is forwarded to both leaf devices to which host 1 is connected. Per a local bias, the same leaf device to which both host 3 and host 1 are connected forwards the packet to host 1. The other remote leaf device to which only host 1 is connected drops the packet.

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

New Features in Release 14.1X53-D35

Interfaces and Chassis

  • PVLAN and Q-in-Q on the same interface (QFX5100 switches) —Starting with Junos OS Release 14.1X53-D35, 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.

    To configure a physical interface to support both PVLAN and Q-in-Q:

    1. Configure flexible VLAN tagging to enable the interface to transmit packets with two 802.1Q VLAN tags.
      [edit groups group-name ]
      user@switch# set interfaces interface-name flexible-vlan-tagging
    2. Configure flexible Ethernet services to enable the interface to support PVLAN and Q-in-Q on the same interface.
      [edit groups group-name ]
      user@switch# set interface interface-name flexible-ethernet-services
    3. Enable VLAN bridge encapsulation on the logical interface.
      [edit groups group-name]
      user@switch# set interfaces interface-name unit unit-number encapsulation vlan-bridge
    4. Assign the VLAN ID for the logical interface.
      [edit groups group-name]
      user@switch# set interfaces interface-name unit unit-number vlan-id vlan-id

MPLS

  • Support for equal-cost multipath (ECMP) operation on MPLS using firewall filters (QFX5100 switches)—Starting with Junos OS 14.1X53-D35, QFX5100 switches support ECMP operation on MPLS using firewall filters. Use the following commands to enable the feature:
    [edit]
    user@switch# set policy-options policy-statement load-balancing-policy then load-balance per-packet
    user@switch# set routing-options forwarding-table export load-balancing-policy

New Features in Release 14.1X53-D30

Authentication and Access Control

  • Access control and authentication (QFX5100 switches)—Starting with Junos OS Release 14.1X53-D30, 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 (PVLAN), server fail fallback, dynamic changes to a user session, RADIUS accounting, and configuration of port-filtering attributes on the RADIUS server using VSAs. You configure 802.1X authentication at the [edit protocols dot1x] hierarchy level.
    • MAC RADIUS authentication is used to authenticate end devices, whether or not 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 MAC RADIUS authentication at the [edit protocols dot1x authenticator interface interface-name mac-radius] hierarchy level.

    [See Understanding Authentication on Switches.]

Cloud Analytics Engine

  • Data Learning Engine (DLE) component APIs to access Network Traffic Analysis (NTA) statistics (QFX5100 switches)—Starting with Junos OS Release 14.1X53-D30 and Network Director 2.5, you can enable devices to generate NTA flow statistics using Network Director, and configure DLE to collect, process, and store the data. DLE NTA APIs are provided to allow access to the NTA data that DLE maintains.

    [See Data Learning Engine API Overview.]

  • Data Learning Engine (DLE) streaming flow data subscription service and RESTful APIs (QFX5100 switches)—Starting with Junos OS Release 14.1X53-D30, DLE supports a UDP-based network analytics data subscription service that streams analytics data in bulk to subscribed clients as it is collected. The service supports streaming of application flow path analytics data from active flows on network devices that support Cloud Analytics Engine. DLE clients can subscribe to receive this data using DLE data subscription RESTful APIs, avoiding the overhead of having to periodically request this data from DLE and enabling custom real-time client telemetry.

    [See Data Learning Engine API Overview.]

Ethernet Switching

  • IRB in PVLAN (QFX5100 switches)—Starting with Junos OS Release 14.1X53-D30, you can configure an integrated routing and bridging (IRB) interface in a private VLAN (PVLAN) so that devices in the community and isolated VLANs can communicate with each other and with devices outside the PVLAN at Layer 3 without requiring you to install a router.

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

Interfaces and Chassis

  • Short-reach mode (QFX5100-48T switch)—Allows you to use short cable lengths (less than 10 meters) for copper-based 10-Gigabit Ethernet interfaces. Enabling short-reach mode reduces power consumption on these interfaces. You can configure short-reach mode for individual interfaces and for a range of interfaces. Enable short-reach mode for individual interfaces by including the enable statement at the [edit chassis fpc slot-number pic slot-number] hierarchy level. Enable short-reach mode for a range of interfaces by including the enable statement at the [edit chassis fpc slot-number pic port-range port-range-low port-range-high] hierarchy level.

MPLS

  • IPv6 Layer 3 VPNs (QFX5100 switches)—QFX5100 switch interfaces in a Layer 3 VPN can now be configured to carry IP version 6 (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.
  • MPLS over Layer 3 subinterfaces (QFX5100 switches)—Starting with Junos OS Release 14.1X53-D30, MPLS over Layer 3 subinterfaces is supported on a QFX5100 switch when the switch is used as a label switch router (LSR). MPLS over Layer 3 subinterfaces has already been supported when a QFX5100 switch is used as a label edge router (LER).

    [See MPLS Limitations on QFX Series and EX4600 Switches.]

  • MPLS features (QFX5100 Virtual Chassis, Virtual Chassis Fabric)—The following MPLS features are now supported for QFX5100 Virtual Chassis and Virtual Chassis Fabric (VCF):
    • BGP L3 VPN
    • Carrier-over-Carrier and Interprovider
    • Ethernet over MPLS pseudowires based on LDP
    • Static/Dynamic Ethernet pseudowires over LDP/RSVP tunnels
    • Pseudowire over aggregated Ethernet interfaces (core-facing interface)
    • RSVP FRR including link-protection/node-link-protection
    • Junos fast-reroute
    • Ethernet pseudowires over QFX5100 Virtual Chassis and VCF deployments

Software-Defined Networking (SDN)

  • Class-of-service support for OVSDB-managed VXLAN interfaces (QFX5100 switches)—Class-of-service (CoS) features can now 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.
  • Firewall filters on OVSDB-managed interfaces (QFX5100 switches)—Enables you to configure firewall filters on interfaces managed by a Contrail controller through the Open vSwitch Database (OVSDB) management protocol.

    [See Understanding Firewall Filters on OVSDB-Managed Interfaces.]

  • Policers on OVSDB-managed interfaces (QFX5100 switches)—Enables you to configure two-rate three-color markers (policers) on interfaces managed by a Contrail controller through the Open vSwitch Database (OVSDB) management protocol.

    [See Understanding Policers on OVSDB-Managed Interfaces.]

  • MAC limiting on OVSDB-managed interfaces (QFX5100 switches)—Enables you to configure MAC limiting on interfaces managed by a Contrail controller through the Open vSwitch Database (OVSDB) management protocol.
  • NNI and UNI on the same interface (QFX5100 switches)—Enables 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.
  • OVSDB in Junos OS software package, ISSU and NSSU support (QFX5100, QFX5100VC)—Starting with 14.1X53-D30, OVSDB software is included in the Junos OS software package (jinstall). The introduction of this new feature results in the following changes:
    • To upgrade the OVSDB software on your Juniper Networks switch or Virtual Chassis to a later version, you can now use the in-service software upgrade (ISSU) or nonstop software upgrade (NSSU) process. When upgrading the OVSDB software, be aware that this upgrade requires graceful Routing Engine switchover (GRES) only.
    • To install OVSDB on your QFX5100 switch or Virtual Chassis, you no longer need to download and install the jsdn-i386-release software package.

    [See Understanding In-Service Software Upgrade (ISSU) and Understanding Nonstop Software Upgrade on a Virtual Chassis Fabric.]

  • OVSDB support with Contrail (QFX5100, QFX5100 Virtual Chassis, Virtual Chassis Fabric)—Starting with Junos OS Release 14.1X53-D30, the Open vSwitch Database (OVSDB) management protocol provides a means through which a Contrail controller and a QFX5100 switch, QFX5100 Virtual Chassis, or a Virtual Chassis Fabric that includes QFX5100 switches only can communicate. In an environment in which Contrail Release 2.20 or later is deployed, a Contrail controller and a QFX5100 switch, QFX5100 Virtual Chassis, or Virtual Chassis Fabric 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 the reverse.

    [See Understanding the Open vSwitch Database Management Protocol Running on Juniper Networks Devices.]

  • Support for ping and traceroute with VXLANs (QFX5100 switches)—Enables you to use ping and traceroute to debug the underlay that supports a VXLAN overlay.

    [See ping overlay and traceroute overlay.]

VPNs

  • EVPN control plane for VXLAN supported interfaces (QFX5100 switches)—Traditionally, data centers have used Layer 2 technologies such as Spanning Tree Protocol (STP), multichassis link aggregation group (MC-LAG), or TRILL for compute and storage connectivity. As the design of data centers shifts from more traditional to scale-out, service-oriented multitenant networks, a new data center architecture has been provided that allows decoupling of an underlay network from the tenant overlay network with VXLAN. By using a Layer 3 IP-based underlay coupled with a VXLAN-EVPN overlay, you can deploy larger networks than those possible with traditional Layer 2 Ethernet-based architectures. With overlays, endpoints (servers or virtual machines) can be placed anywhere in the network and remain connected to the same logical Layer 2 network. The benefit is that virtual topology, using both MX Series routers and QFX5100 switches, can be decoupled from the physical topology.

New Features in Release 14.1X53-D27

Hardware

  • QFX5100-24Q-AA switch—This low-latency, high-performance, top-of-rack switch provides 2.56 Tbps throughput. Each QSFP+ port supports 40-Gigabit Ethernet but can be configured as four independent 10-Gigabit Ethernet ports using breakout cables (channelization mode). The switch can also be configured to support 96 10-Gigabit Ethernet ports using breakout cables (channelization mode) with 1280-Gbps total throughput.

    The switch can be ordered with either ports-to-FRUs or FRUs-to-ports airflow and with AC or DC power supplies.

    The QFX5100-24Q-AA module bay can accommodate a single double-wide expansion module (QFX-PFA-4Q) and two single-wide optional expansion modules (two or one each of QFX-EM-4Q and EX4600-EM-8F).

  • QFX-PFA-4Q expansion module (QFX5100-24Q-AA switch)—Starting with Junos OS Release 14.1X53-D27, the QFX5100-24Q-AA switch supports the QFX-PFA-4Q expansion module. This double-wide expansion module provides four additional 40-Gigabit Ethernet QSFP+ ports, a dedicated FPGA, and support for the Precision Time Protocol (PTP).

New Features in Release 14.1X53-D26

Network Management and Monitoring

  • DHCP smart relay (QFX5100)—Starting with Junos OS Release 14.1X53-D26, you can configure alternative IP addresses for the gateway interface so that if the server fails to reply to the requests sent from the primary gateway address, the switch can resend the requests using alternative gateway addresses. To use this feature, you must configure an IRB interface or Layer 3 subinterface with multiple IP addresses and configure that interface as a relay agent.

Open vSwitch Database (OVSDB)

  • New OVSDB command summaries (QFX5100, QFX5100 Virtual Chassis)—Starting with Junos OS Release 14.1X53-D26, the show ovsdb commit failures and clear ovsdb commit failures commands are introduced.

    If you suspect a problem has occurred with the configuration of an OVSDB-managed Virtual Extensible LAN (VXLAN) and associated logical interface(s), you can enter the show ovsdb commit failures command. This command describes the OVSDB-managed VXLANs and associated logical interface(s) that the Juniper Networks switch automatically configured but was unable to commit.

    After you resolve the problem, you can remove the configuration from the queue and retry committing the configuration by using the show ovsdb commit failures command.

  • Storm control on OVSDB-managed interfaces (QFX5100)—Starting with Junos OS Release 14.1X53-D26, you can configure storm control on VXLAN interfaces that are managed by an OVSDB controller. By default, Layer 2 BUM traffic that originates in an OVSDB-managed VXLAN is replicated and forwarded by a service node in the same VXLAN. Because service nodes can be overloaded if too much BUM traffic is received, you can manually configure storm control on server-facing VXLAN interfaces to control how much of this traffic is allowed into a VXLAN.

New Features in Release 14.1X53-D25

MPLS

  • MPLS stitching for virtual machine connections (QFX5100, QFX3500)—By using MPLS, the stitching feature provides connectivity between virtual machines on opposite sides of data center routers. An external controller, programmed in the data plane, assigns MPLS labels to both virtual machines and servers. Then, the signaled MPLS labels are used between the data center routers, generating static label-switched paths (LSPs), resolved over RSVP or LDP, to provide the routes dictated by the labels. The new CLI command stitch, located under the LSP transit command, provides this capability.

    [See MPLS Stitching For Virtual Machine Connection.]

Open vSwitch Database (OVSDB)

  • OVSDB schema updates (QFX5100 switch, QFX5100 Virtual Chassis)—Starting with Junos OS Release 14.1X53-D25, the Open vSwitch Database (OVSDB) schema for physical devices version that is implemented on QFX5100 switches is version 1.3.0. In addition, this schema now supports the multicast MACs local table.

    [See Open vSwitch Database Schema for Physical Devices.]

Software Installation and Upgrade

  • Preboot eXecution Environment (PXE) software for Junos Fusion satellite devices (QFX5100 switches)—Enables you to convert a Junos Fusion satellite device back into a standalone QFX5100 switch. For more information on this feature, please see the Junos OS 14.2R3 Release Notes and the Junos Fusion documentation.

System Management

  • DHCP relay with DHCP server and DHCP client in separate routing instances—You can use a stateless DHCP relay agent between a client and server in different virtual routing instances. This feature uses cross-message exchange between the virtual routing instances and supports both DHCPv4 and DHCPv6 packets. This method ensures that:
    • DHCP server network is isolated from the DHCP clients, because there is no direct routing between the client’s and server’s routing instances.
    • Only DHCP packets, not routine traffic, are relayed across the two routing instances.

    [See DHCP Message Exchange Between DHCP Clients and DHCP Server in Different Virtual Routing Instances.]

  • Precision Time Protocol (PTP) transparent clock (QFX5100 switch)—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. 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 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 clocks, are supported. You can configure the transparent clock at the [edit protocols ptp] hierarchy level.

    [See Understanding Transparent Clocks in Precision Time Protocol.]

VXLAN

  • Configurable VXLAN UDP port (QFX5100)—Starting with Junos OS 14.1X53-D25, you can configure the UDP port used as the destination port for VXLAN traffic on a QFX5100 switch. To configure the VXLAN destination port to be something other than the default UDP port of 4789, enter set protocols l2-learning destination-udp-port port-number. The port you configure will be used for all VXLANs configured on the switch.

    Note: If you make this change on one switch in a VXLAN, you must make the same change on all the devices that terminate the VXLANs configured on your switch. If you do not do so, traffic will be disrupted for all the VXLANs configured on your switch. When you change the UDP port, the previously learned remote VTEPs and remote MACs are lost and VXLAN traffic is disrupted until the switch relearns the remote VTEPs and remote MACs.

    [See Understanding VXLANs.]

New Features in Release 14.1X53-D15

Hardware

  • Extended node support (QFX5100-24Q and QFX5100-48T switches)—Enables you to include a QFX5100-24Q switch and a QFX5100-48T switch as a Node device in a QFabric System. To add the device, first install the QFabric “5” family software package (jinstall-qfabric-5-release.tgz) on the switch, and attach two management ports to the QFabric system control plane. For copper-based control plane systems, use the RJ-45 fixed management port and one SFP management port on the QFX5100 Node device with a copper module. For fiber-based control plane systems, use two SFP management ports on the QFX5100 Node device with fiber modules.

    [See Understanding the QFabric System Hardware Architecture.]

  • Improved online insertion and replacement procedures (QFabric systems)—Allows for nondisruptive insertion or replacement of server Node groups, network Node groups, redundant server Node groups, Interconnect devices, and front and rear cards of the Interconnect devices.

    [See Powering Off an Existing QFabric Node Device.]

  • QFX5100 Interconnect device (QFabric systems)—Allows a QFX5100-24Q switch to operate as a QFX3000-M Interconnect device. The interconnect acts like a backplane for data-plane traffic traversing the QFX3000-M QFabric system between Node devices. The QFX5100 Interconnect device has 24 40-Gigabit QSFP+ ports, but only 16 are available as fte ports. The QFX5100 Interconnect device features two RJ-45 management ports and two SFP management ports, which allow connection to either copper-based or fiber-based control-plane networks.

    [See Understanding Interconnect Devices.]

Class of Service

  • Mitigating fate sharing on Interconnect devices by remapping forwarding classes (QFabric systems)—Enables you to remap traffic assigned to a forwarding class into different, separate forwarding classes to mitigate fate sharing as the traffic crosses the Interconnect device. Separating the traffic into multiple forwarding classes spreads the flows across multiple output queues instead of using one output queue for all of the traffic. (Each forwarding class uses a different output queue, and each output queue has its own dedicated bandwidth resources.) Fate sharing occurs when flows in the same forwarding class (flows that have the same IEEE 802.1p priority code point) use the same output queue on an interface, because the flows share the same path and resources. When one flow becomes congested, the congestion can affect the other flows that use the same output queue even if they are not experiencing congestion, because when the congested flow is paused, the other flows that use the same code point are also paused. Because flows from many Node devices cross the Interconnect device, the flows are aggregated at egress interfaces, which increases the chance of fate sharing. Forwarding class remapping mitigates fate sharing on the Interconnect device by separating the traffic into different forwarding classes that use different output queues, so pausing one congested flow does not affect uncongested flows that have been mapped to different forwarding classes and therefore to different output queues.

    [See Understanding How to Mitigate Fate Sharing on a QFabric System Interconnect Device by Remapping Traffic Flows (Forwarding Classes) and Understanding Default CoS Scheduling on QFabric System Interconnect Devices (Junos OS Release 13.1 and Later Releases).]

  • Scheduler configuration on Interconnect device fabric ports (QFabric systems)—Enables you to configure scheduling on the fabric (fte and bfte) ports of the QFabric system Interconnect devices. (This complements the Junos OS Release 13.1 feature that provides scheduler configuration on Node device fabric ports. The combination of access port, Node device fabric port, and Interconnect device fabric port scheduling gives you complete control of scheduling across a QFabric system.) In earlier Junos OS releases, Interconnect device fabric port scheduling was done by default, with no user configuration. In Junos OS Release 14.1X53-D15, the default fabric port scheduler on Interconnect devices is the same as it was in earlier releases.

    Understanding CoS Scheduling Across the QFabric System and Understanding Default CoS Scheduling on QFabric System Interconnect Devices (Junos OS Release 13.1 and Later Releases).]

Multicast Features

  • IGMP querier (QFabric systems)—Enables multicast traffic to be forwarded between connected switches in pure Layer 2 networks. If you enable IGMP snooping in a Layer 2 network without a multicast router, the IGMP snooping reports are not forwarded between connected switches. This means that if hosts connected to different switches in the network join the same multicast group and traffic for that group arrives on one of the switches, the traffic is not forwarded to the other switches that have hosts that should receive the traffic. If you enable IGMP querying for a VLAN, multicast traffic is forwarded between switches that participate in the VLAN if they are connected to hosts that are members of the relevant multicast group.

    [See Using a Switch as an IGMP Querier.]

  • IGMPv3 (QFabric systems)—Introduces support for Internet Group Management Protocol version 3 (IGMPv3). IGMPv3 manages the membership of hosts and routers in multicast groups. IP hosts use IGMP to report their multicast group memberships to any immediately neighboring multicast routing devices. Multicast routing devices use IGMP to learn which groups have members for each of their attached physical networks.

    [See Understanding IGMP.]

  • IGMPv3 snooping (QFabric systems)—With IGMP snooping enabled (the default setting), a switch monitors the IGMP traffic between hosts and multicast routers and uses what it learns to forward multicast traffic to only the downstream interfaces that are connected to interested receivers. This conserves bandwidth by allowing the switch to send multicast traffic to only those interfaces that are connected to devices that want to receive the traffic (instead of flooding the traffic to all the downstream VLAN interfaces).

    [See IGMP Snooping Overview.]

  • Multicast flow groups (QFabric systems)—Node devices usually forward multicast traffic on all available Interconnect devices to distribute the load balancing replication load. As a result, redundant multicast streams can flow through one Interconnect device, making that Interconnect device a potential single point of failure for the redundant flows. Some applications require that the redundant multicast streams flow through different Interconnect devices to prevent a single Interconnect device from potentially dropping both streams of multicast traffic during a failure. You can enforce this use of dual Interconnect devices by using the QFabric flow segregation feature.

    [See Understanding QFabric Multicast Flow Groups.]

  • PIM-SSM (QFabric systems)—Protocol Independent Multicast source-specific multicast (PIM-SSM) uses a subset of PIM sparse mode and IGMP version 3 (IGMPv3) to enable a client to receive multicast traffic directly from the source. PIM SSM uses the PIM sparse-mode functionality to create a shortest-path tree (SPT) between the client and the source, but builds the SPT without the help of a rendezvous point.

    [See PIM SSM.]

Network Management and Monitoring

  • Cloud Analytics Engine (QFX5100 switches)—Uses network data analysis to improve application performance and availability. Cloud Analytics Engine includes data collection, analysis, correlation, and visualization, helping you better understand the behavior of workloads and applications across the physical and virtual infrastructure. Cloud Analytics Engine provides an aggregated and detailed level of visibility, tying applications and the network together, and an application-centric view of network status, improving your ability to quickly roll out new applications and troubleshoot problems.

    [See Cloud Analytics Engine.]

Open vSwitch Database (OVSDB)

  • Automatic configuration of OVSDB-managed VXLANs with trunk interfaces (QFX5100 switches)—In a VMware NSX for Multi-Hypervisor environment for the data center, the QFX5100 switch can automatically configure an OVSDB-managed VXLAN and one or more interfaces associated with the VXLAN, thereby eliminating the need for you to perform these tasks, using the Junos OS CLI. The automatic configuration of the VXLAN and associated interfaces is based on the configuration of a logical switch in NSX Manager or in the NSX API. Starting in Junos OS Release14.1X53-D15, the switch supports the automatic configuration of trunk interfaces and their association with an OVSDB-managed VXLAN. In this situation, trunk interfaces enable the support of multiple software applications running directly on a physical server that generate traffic that must be isolated by OVSDB-managed VXLANs.

    [See Understanding How to Set Up Virtual Extensible LANs in an Open vSwitch Database Environment.]

  • OVSDB support with NSX (QFX5100 Virtual Chassis, Virtual Chassis Fabric)—Starting with Junos OS Release 14.1X53-D15, the Junos OS implementation of the Open vSwitch Database (OVSDB) management protocol provides a means through which VMware NSX controllers and a QFX5100 Virtual Chassis or a Virtual Chassis Fabric that includes QFX5100 switches only can communicate. In an NSX multi-hypervisor environment, NSX version 4.0.3 and later controllers and a QFX5100 Virtual Chassis or Virtual Chassis Fabric can exchange control and statistical information via the OVSDB schema for physical devices, thereby enabling virtual machine (VM) traffic from entities in a virtual network to be forwarded to entities in a physical network and vice versa.

    You can set up a connection between the QFX5100 management interface (em0 or em1) and an NSX controller.

    [See Setting Up Open vSwitch Database Connections Between Junos OS Devices and Controllers.]

QFabric Systems

  • QFabric system software downgrade support (QFabric systems)—Starting with Junos OS 14.1X53-D15, downgrading software provides a quick recovery mechanism to a previous software version and configuration file in cases where a software upgrade or configuration changes have made the QFabric system unstable or inoperable. The recovery mechanism consists of a “restore-point,” which is a snapshot of the software on the QFabric system as well as the configuration that can be rolled back to. Downgrade support does not replace the existing backup and restore functionality.
    • To enable software downgrade:
    • Create a restore-point.

      Note: You can only create one restore-point at a time. Creating a new restore-point deletes the existing restore-point if there is one. Also, all CLI commands are blocked while creating a restore-point.

      To create a restore-point, issue the request system software restore-point command.

    • To roll back to the restore-point, issue the request system software recover-from-restore-point command.
    • To display the status of the Director group after creating a restore-point for the QFabric system, issue the show system software restore-point status command.

Security

  • Error message displayed when TCAM is full (QFX5100 switches)—Firewall filters are stored in ternary content addressable memory (TCAM). With previous versions of Junos OS, if you configure a firewall filter that cannot fit into the available TCAM space, the filter defaults to "permit any," and no error message is displayed in the CLI. With Junos OS Release 14.1X53-D15, an error message is displayed in the CLI if this occurs.

    [See Planning the Number of Firewall Filters to Create.]

  • Media Access Control Security (MACsec) support (QFX5100-24Q switches)—Starting with Junos OS Release 14.1X53-D15, MACsec is supported on all eight SFP+ interfaces on the EX4600-EM-8F expansion module when it is installed in a QFX5100-24Q switch. MACsec is an 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 is standardized in IEEE 802.1AE.

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

Virtual Chassis and Virtual Chassis Fabric

  • Increase vmember limit to 512k support (Virtual Chassis Fabric)—Increases the number of vmembers to 512k. For example, to calculate how many interfaces are required to support 4000 VLANs, divide the maximum number of vmembers (512,000) by the number of configured VLANS (4000). In this case, 128 interfaces are required.

    [See Understanding Bridging and VLANs.]

VLAN Infrastructure

  • Support for private VLANs (QFX5100 switches)—VLANs limit broadcasts to specified users. Private VLANs (PVLANs) take this concept a step further by splitting the broadcast domain into multiple isolated broadcast subdomains and essentially putting secondary VLANs inside a primary VLAN. PVLANs restrict traffic flows through their member switch ports (called “private ports”) so that these ports communicate only with a specified uplink trunk port or with specified ports within the same VLAN. The uplink trunk port is usually connected to a router, firewall, server, or provider network. Each PVLAN typically contains many private ports that communicate only with a single uplink, thereby preventing the ports from communicating with each other.

    Just like regular VLANs, PVLANs are isolated on Layer 2 and require that a Layer 3 device be used to route traffic among them. PVLANs are useful for restricting the flow of broadcast and unknown unicast traffic and for limiting the communication between known hosts. Service providers use PVLANs to keep their customers isolated from one another.

    [See Understanding Private VLANs.]

New Features in Release 14.1X53-D10

Authentication and Access Control

  • IPv6 for RADIUS AAA (QFX5100 switch and Virtual Chassis)—Starting with Junos OS Release 14.1X53-D10, QFX5100 switches and QFX5100 Virtual Chassis support IPv6, along with the existing IPv4 support, for user authentication, authorization, and accounting (AAA) using RADIUS servers.

    RADIUS authentication is a method of authenticating users who attempt to access the router or switch. To use RADIUS authentication on the switch, configure information about one or more RADIUS servers on the network by including one radius-server statement at the [edit system] hierarchy level for each RADIUS server.

    When you configure a source address for each configured RADIUS server, each RADIUS request sent to a RADIUS server uses the specified source address.

    • Authentication—Specify which source address Junos OS uses when accessing your network to contact an external RADIUS server for authentication. You configure the IPv6 source address for RADIUS authentication at the [edit system radius-server server-address source-address] hierarchy level.
    • Accounting—Specify which source address Junos OS uses when contacting a RADIUS server for sending accounting information. You configure the IPv6 source address for RADIUS authentication at the [edit system accounting destination radius server server-address source-address] hierarchy level.

    [See source-address.]

Bridging and Learning

  • MAC notification (QFX5100)—Starting with Junos OS Release 14.1X53-D10, MAC notification is supported on QFX5100 switches. The switches track clients on a network by storing MAC addresses in the Ethernet switching table on the switch. When switches learn or unlearn a MAC address, SNMP notifications can be sent to the network management system at regular intervals to record the addition or removal of the MAC address. This process is known as MAC notification.

    The MAC Notification MIB controls MAC notification for the network management system.

    The MAC notification interval defines how often these SNMP notifications are sent to the network management system. The MAC notification interval works by tracking all MAC address additions or removals on the switch over a period of time and then sending all tracked MAC address additions or removals to the network management server at the end of the interval.

    Enabling MAC notification allows you to monitor the addition and removal of MAC addresses from the Ethernet switching table remotely using a network management system. The advantage of setting a high MAC notification interval is that the amount of network traffic is reduced because updates are sent less frequently. The advantage of setting a low MAC notification interval is that the network management system is better synchronized with the switch.

    Two new MIBs related to MAC notification are provided at Junos OS Release 14.1X53-D10. See Documentation Updates.

    [See Configuring MAC Notification (CLI Procedure).]

  • Default VLAN and multiple VLAN range support (QFX5100)—Starting with Junos OS Release 14.1X53-D10, the default VLAN and multiple VLAN range are supported on QFX5100 switches. They provide the ability for the switch to operate as a plug and play device and connect to various Ethernet-enabled devices in a small, scaled enterprise network. When the switch boots, a VLAN named default is created. The default VLAN is automatically created for every routing instance that belongs to a type of virtual-switch and for the default routing instance named default-switch. All interfaces on the switch are automatically configured as access interfaces and are part of the default VLAN.

    The default VLAN accepts and forwards untagged packets only and is preconfigured with a VLAN ID (vlan-id) of 1. The default VLAN does not support a VLAN ID list (vlan-id-list), vlan-id set to all, or vlan-id set to none. You can configure the VLAN ID to be another value, but the value must be between 1 and 4093.

    Access interfaces that are VoIP-enabled or 802.1X-enabled are internally converted to trunk interfaces, so that the interfaces can belong to multiple VLANs. If the interfaces do not belong to a valid VLAN, the interfaces automatically become part of the default VLAN.

    You can configure more than one VLAN range, and each range can contain unique VLAN properties.

    Note: Virtual Chassis interfaces cannot be preconfigured to belong to the default VLAN or any other VLAN.

    Note: For interfaces to be part of the default VLAN, you must configure the interfaces to be part of the Ethernet switching family. You can configure Ethernet switching at the [edit interfaces interface-name unit family] CLI hierarchy level.

  • Ethernet ring protection switching (QFX5100)—Starting with Junos OS Release 14.1X53-D10, Ethernet ring protection switching (ERPS) is supported on QFX5100 switches. ERPS helps achieve high reliability and network stability. Links in the ring never form loops that fatally affect the network operation and services availability.

    [See Understanding Ethernet Ring Protection Switching Functionality.]

High Availability

  • Resilient hashing support for link aggregation groups and equal cost multipath routes (QFX5100)—Starting with Junos OS Release 14.1X53-D10, resilient hashing is now supported by link aggregation groups (LAGs) and equal cost multipath (ECMP) sets.

    A LAG combines Ethernet interfaces (members) to form a logical point-to-point link that increases bandwidth, provides reliability, and allows load balancing. 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.

    Resilient hashing applies only to unicast traffic and supports a maximum of 1024 LAGs, with each group having a maximum of 256 members.

    An ECMP group for a route contains multiple next-hop equal cost addresses for the same destination in the routing table. (Routes of equal cost have the same preference and metric values.)

    Junos OS uses a hash algorithm to choose one of the next-hop addresses in the ECMP group to install in the forwarding table. Flows to the destination are rebalanced using resilient hashing.

    Resilient hashing enhances ECMPs by minimizing destination remapping when a new member is added to or deleted from the ECMP group.

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

Infrastructure

  • Licensing enhancements (QFX Series)—Starting with Junos OS Release 14.1X53-D10, licensing enhancements on QFX Series switches enable you to configure and delete license keys in a Junos OS CLI configuration file. The license keys are validated and installed after a successful commit of the configuration file. If a license key is invalid, the commit fails and issues an error message. You can configure individual license keys or multiple license keys by issuing Junos OS CLI commands or by loading the license key configuration contained in a file. All installed license keys are stored in the /config/license/ directory.

    To install an individual license key in the Junos OS CLI, issue the set system license keys key name command, and then issue the commit command.

    For example:

    [edit]
    root@switch# set system license keys key "JUNOS_TEST_LIC_FEAT testabc123"
    root@switch# commit
    commit complete

    To verify that the license key was installed, issue the show system license command.

    For example:

    root@switch> show system license
    License usage: 
                                     Licenses     Licenses    Licenses    Expiry
      Feature name                       used    installed      needed 
      sdk-test-feat1                        0            1           0    permanent
    
    Licenses installed: 
      License identifier: JUNOS_TEST_LIC_FEAT
      License version: 2
      Features:
        sdk-test-feat1   - JUNOS SDK Test Feature 1
          permanent
    

    To install multiple license keys in the Junos OS CLI, issue the set system license keys key name command, and then issue the commit command.

    For example:

    [edit]
    root@switch# set system license keys key "key_1"
    set system license keys key "key_2"
    set system license keys key "key_2"
    set system license keys key "key_4"
    root@switch# commit
    commit complete

    To verify that the license key was installed, issue the show system license command.

    To install an individual license key configuration in a file, issue the cat command:

    For example:

    [edit]
    root@switch%cat license.conf
    system {
        license {
            keys {
               key "JUNOS_TEST_LIC_FEAT testabc123";
            }
        }
    }
    

    Load and merge the license configuration file.

    For example:

    [edit]
    root@switch# load merge license.conf
    load complete 

    Issue the show | compare command to see the configuration, and then issue the commit command.

    For example:

    [edit]
    root@switch# show | compare
    [edit system]
    +   license {
    +       keys {
    +           key "JUNOS_TEST_LIC_FEAT testabc123";
    +       }
    +   }
    
    [edit]
    root@switch# commit

    To verify that the license key was installed, issue the show system license command.

    For example:

    root@switch> show system license
    License usage: 
                                     Licenses     Licenses    Licenses    Expiry
      Feature name                       used    installed      needed 
      sdk-test-feat1                        0            1           0    permanent
    
    Licenses installed: 
      License identifier: JUNOS_TEST_LIC_FEAT
      License version: 2
      Features:
        sdk-test-feat1   - JUNOS SDK Test Feature 1
          permanent
    

    To install multiple license keys in a file, issue the cat command:

    For example:

    [edit]
    root@switch%cat license.conf
    system
    {
    license
    {
      keys
      {
       key "key_1"
       key "key_2"
       key "key_3"
       ...
       key "key_n"
      }
    }
    

    Load and merge the license configuration file, and then issue the commit command.

    For example:

    [edit]
    root@switch# load merge license.conf
    load complete 
    [edit]
    root@switch# commit

    To verify that the license key was installed, issue the show system license command.

    You can also delete or deactivate individual and multiple license keys in the Junos OS CLI by issuing the delete system license keys or deactivate system license keys commands. Do not use the request system license delete command to delete the license keys.

    For example, to issue the delete system license keys command:

    [edit]
    root@switch# delete system license keys
    root@switch# commit

Interfaces and Chassis

  • Fast reboot option (QFX5100)—Starting with Junos OS Release 14.1X53-D10, you can enhance the reboot time on a QFX5100 by issuing the new fast-boot option with the request system reboot command (request system reboot fast-boot). The switch reboots in such a way as to minimize downtime of network ports by not bringing the network ports down immediately as in the normal reboot option. There is minimal traffic loss while the forwarding device is reprogrammed.

    [See request system reboot.]

  • Keep a link up on a multichassis link aggregation group (MC-LAG) when LACP is not configured on one of the MC-LAG peers (QFX5100 switch)—Junos OS Release 14.1X53-D10 provides connectivity from provider edge devices to customer edge devices when LACP is not configured on a customer edge device. The customer edge device must have one link connected to the provider edge device, though, and multichassis link aggregation must be configured between the provider edge devices in the MC-LAG. You can configure the force-up feature in Link Aggregation Control Protocol (LACP) on the provider edge device for which you need connectivity. Additionally, only one member interface in the aggregated Ethernet interface can be active, otherwise the provider edge device will receive duplicate packets.

    [See Forcing MC-LAG Links or Interfaces with Limited LACP Capability to Be Up.]

Layer 3 Features

  • Loop-free alternates (QFX5100)—Starting with Junos OS Release 14.1X53-D10, QFX5100 switches support loop-free alternates (LFA) to compute backup next hops for IS-IS routes, providing IP fast-reroute capability for IS-IS routes. These routes, with precomputed backup next hops, are preinstalled in the Packet Forwarding Engine, which performs a local repair and switches to the backup next hop when the link for the primary next hop for a particular route is no longer available. With local repair, the Packet Forwarding Engine can correct a path failure before it receives recomputed paths from the Routing Engine. Local repair reduces the amount of time needed to reroute traffic to less than 50 milliseconds. You can configure loop-free alternates (LFA) for IS-IS at the [edit protocols isis] hierarchy level.
  • IS-IS support (QFX5100)—Starting with Junos OS Release 14.1X53-D10, on QFX5100 switches, the IS-IS protocol has extensions to differentiate between different sets of routing information sent between routers and switches for unicast and multicast. IS-IS routes can be added to the RPF table when special features such as traffic engineering and shortcuts are turned on. You configure the feature under the [edit protocols isis] hierarchy level.

MPLS

  • MPLS-based Layer 3 VPNs (QFX5100)—Starting with Junos OS Release 14.1X53-D10, MPLS-based Layer 3 VPNs are supported on QFX5100 switches.

    Customer networks are private and can use either public addresses or private addresses. When customer networks that use private addresses connect to the public Internet infrastructure, the private addresses might overlap with private addresses being used by other network users. MPLS BGP VPNs solve this problem by adding the route distinguisher prefix to the route.

    You can configure the switch as a CE or PE using Layer 3 MPLS/BGP VPN for interprovider and carrier-of-carrier VPNs. The key difference between interprovider and carrier-of-carriers VPNs is whether the customer sites belong to the same autonomous system (AS) or to a separate AS:

    • Interprovider VPNs—The customer sites belong to different ASs. You need to configure EBGP to exchange the customer’s external routes.
    • Carrier-of-carriers VPNs—The customer sites belong to the same AS. You need to configure IBGP to exchange the customer’s external routes.
  • Ethernet-over-MPLS (L2 circuit) (QFX5100)—Starting with Junos OS Release 14.1X53-D10, Ethernet-over-MPLS is supported on QFX5100 switches. Ethernet-over-MPLS enables you to send Layer 2 Ethernet frames transparently over an MPLS cloud. 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.

    This technology has applications in service provider, enterprise, and data center environments. For disaster recovery purposes, data centers are hosted in multiple sites that are geographically distant and interconnected using a WAN network. These data centers require Layer 2 connectivity between them for the following reasons:

    • To replicate the storage over Fibre Channel over IP (FCIP). FCIP works only on the same broadcast domain.
    • To run a dynamic routing protocol between the sites.
    • To support high availability clusters that interconnect the nodes hosted in the various data centers.
  • MPLS LSP protection (QFX5100)—Starting with Junos OS Release 14.1X53-D10, the following types of MPLS LSP protection are supported on QFX5100 switches:
    • Fast reroute (FRR)
    • Link protection
    • Node link protection

[ See MPLS Overview.]

Network Management and Monitoring

  • Chef for Junos OS (QFX5100)—Starting with Junos OS Release 14.1X53-D10, Chef for Junos OS is supported on all QFX5100 switches, not just QFX5100 switches that are running Junos OS with automated enhancements for QFX5100 switches.
  • Puppet for Junos OS (QFX5100)—Starting with Junos OS Release 14.1X53-D10, Puppet for Junos OS is supported on QFX5100 switches that are not running Junos OS with automated enhancements for QFX5100 switches.
  • IEEE 802.3ah (QFX5100)—Starting with Junos OS Release 14.1X53-D10, QFX5100 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. You configure the feature under the [edit protocols oam ethernet] hierarchy level.

OpenFlow

  • Support for OpenFlow v1.0 and v1.3.1 (QFX5100)—Starting with Junos OS Release 14.1X53-D10, QFX5100 switches support OpenFlow v1.0 and v1.3.1. OpenFlow v1.0 enables you to control traffic in an existing network by adding, deleting, and modifying flows in the switch. You can configure one OpenFlow virtual switch and one active OpenFlow controller under the [edit protocols openflow] hierarchy on each QFX5100 switch in the network.

    In addition to the OpenFlow v1.0 functionality, OpenFlow v1.3.1 allows the action specified in one or more flow entries to direct packets to a base action called a group. The purpose of the group action is to further process these packets and assign a more specific forwarding action to them. You can view groups that were added, modified, or deleted from the group table by way of the OpenFlow controller using the show openflow groups command. You can view group statistics using the show openflow statistics groups command.

    OpenFlow v1.0 and v1.3.1 are not supported on MX Series routers or EX9200 switches in Junos OS Release 14.1X53-D10. OpenFlow v1.0 is supported in Junos OS Release 14.1 on these platforms.

    [See Understanding OpenFlow Operation and Forwarding Actions on Devices Running Junos OS.]

Open vSwitch Database (OVSDB)

  • OVSDB support with NSX (QFX5100)—Starting with Junos OS Release 14.1X53-D10, the Junos OS implementation of the Open vSwitch Database (OVSDB) management protocol provides a means through which VMware NSX controllers and QFX5100 switches that support OVSDB can communicate. In an NSX multi-hypervisor environment, NSX version 4.0.3 controllers and QFX5100 switches can exchange control and statistical information via the OVSDB schema for physical devices, thereby enabling virtual machine (VM) traffic from entities in a virtual network to be forwarded to entities in a physical network and vice versa.

    You can set up a connection between the QFX5100 management interface (em0 or em1) and an NSX controller.

    [See Setting Up Open vSwitch Database Connections Between Junos OS Devices and Controllers.]

Security

  • Port mirroring to IP address (QFX5100)—Starting with Junos OS Release 14.1X53-D10, you can send mirrored packets to an IP address over a Layer 3 network (for example, if there is no Layer 2 connectivity to the analyzer device). This feature also enables you to apply an IEEE-1588 timestamp to the mirrored packets.

Software Installation

  • Open Source Python modules supported in automation enhancement (QFX5100)—Starting with Junos OS Release 14.1X53-D10, these Open Source Python modules are pre-installed in the jinstall-qfx-5-flex-x.tgz software bundle:
    • ncclient—Facilitates client scripting and application development through the NETCONF protocol.
    • lxml—Combines the speed and XML feature completeness of the C libraries libxml2 and libxslt with the simplicity of a native Python API.
    • jinja2—Serves as a fast, secure, designer-friendly templating language.

    [See Overview of Python with QFX5100 Switch Automation Enhancements.]

Virtual Chassis and Virtual Chassis Fabric

  • Alias support for Virtual Chassis and Virtual Chassis Fabric (VCF) nodes—Starting with Junos OS Release 14.1X53-D10, an alias can be used to label nodes in a Virtual Chassis and VCF. An alias allows you to more clearly identify a member switch in your Virtual Chassis or VCF by assigning a text label to it. The text label appears alongside the switch's serial number whenever operational commands, such as show virtual-chassis, are used to monitor Virtual Chassis status.

    [See aliases.]

  • Local link bias support for Virtual Chassis with QFX Series member switches—Starting with Junos OS Release 14.1X53-D10, Virtual Chassis Local Link Bias is available on Link Aggregation Group (LAG) bundles on QFX3500 Virtual Chassis, QFX3600 Virtual Chassis, and mixed QFX3500 and QFX3600 Virtual Chassis. Virtual Chassis local link bias conserves bandwidth on Virtual Chassis ports (VCPs) by using local links to forward unicast traffic exiting a Virtual Chassis that has a LAG bundle composed of member links on different member switches in the same Virtual Chassis. A local link is a member link in the LAG bundle that is on the member switch that received the traffic. Because traffic is received and forwarded on the same member switch when local link bias is enabled, no VCP bandwidth is consumed by traffic traversing the VCPs to exit the Virtual Chassis using a different member link in the LAG bundle.

    [See Understanding Local Link Bias.]

  • Adaptive load balancing support (Virtual Chassis Fabric)—Starting with Junos OS Release 14.1X53-D10, adaptive load balancing (ALB) is supported in Virtual Chassis Fabric (VCF). ALB improves traffic management within a VCF by using dynamic load information to make traffic forwarding decisions. ALB introduces a method to better manage extremely large traffic flows—elephant flows—by splicing them into smaller flows—flowlets—and individually forwarding the flowlets across the VCF to the same destination device over different paths.

    [See Understanding Traffic Flow Through a Virtual Chassis Fabric.]

VXLAN

  • Layer 2 VXLAN gateway (QFX5100)—Starting with Junos OS Release 14.1X53-D10, VXLAN is an overlay technology that enables 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 between servers that exist in separate Layer 2 domains by tunneling the traffic through Layer 3 networks. This functionality enables 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 STP to converge the topology (so no links are blocked) but can use more robust routing protocols in the Layer 3 network instead.

    [See Understanding VXLANs.]

Modified: 2017-11-29