Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

New and Changed Features

 

This section describes the new features for the QFX Series switches in Junos OS Release 17.4R2.

Note

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

Release 17.4R2 New and Changed Features

Restoration Procedures and Failure Handling

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

    [See Saving a Rescue Configuration File.]

Release 17.4R1 New and Changed Features

Hardware

  • QFX10000-30C-M line card (QFX10008 and QFX100016 switches)–-Starting with Junos OS Release 17.4R-S2, the QFXF10000-30C-M line cards provides 30 ports of either 100-gigabit or 40-gigabit QSFP28 with MACsec features.

Class of Service (CoS)

  • Priority-based flow control (PFC) using Differentiated Services code points (DSCP) at Layer 3 for untagged traffic (QFX5110 and QFX5200 switches)—Starting in Junos OS Release 17.4R1, to support lossless traffic across Layer 3 connections to Layer 2 subnetworks on QFX5110 and QFX5200 switches, you can configure priority-based flow control (PFC) to operate using 6-bit DSCP values from Layer 3 headers of untagged VLAN traffic, rather than IEEE 802.1P priority values in Layer 2 VLAN-tagged packet headers. DSCP-based PFC is required to support Remote Direct Memory Access (RDMA) over converged Ethernet version 2 (RoCEv2).

    To enable DSCP-based PFC, map a forwarding class to a PFC priority using the pfc-priority statement, define a congestion notification profile to enable PFC on traffic specified by a 6-bit DSCP value, and set up a classifier for the DSCP value and the PFC-mapped forwarding class.

    [See Understanding PFC Using DSCP at Layer 3 for Untagged Traffic.]

EVPNs

  • Support for LACP in EVPN active-active multihoming (QFX5100, QFX5100 Virtual Chassis, QFX5110, and QFX5200 switches)——Starting with Junos OS Release 17.4R1, 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.]

  • EVPN pure type-5 route support (QFX5110 switches)—Starting with Junos OS Release 17.4R1, you can configure pure type-5 routing in an Ethernet VPN (EVPN) Virtual Extensible LAN (VXLAN) environment. Pure type-5 routing is used when the Layer 2 domain does not exist at the remote data centers. A pure type-5 route advertises the summary IP prefix and includes a BGP extended community called a router MAC, which is used to carry the MAC address of the sending switch and to provide next-hop reachability for the prefix. To configure pure type-5 routing include the ip-prefix-routes advertise direct-nexthop statement at the [edit routing-instances routing-instance-name protocols evpn] hierarchy level. To enable two-level equal-cost multipath (ECMP) next hops in an EVPN-VXLAN overlay network, you must also include the overlay-ecmp statement at the [edit forwarding-options vxlan-routing] hierarchy level.

    [See ip-prefix-routes.]

  • SPRING support for EVPN (QFX10000 switches)—-Starting in Junos OS Release 17.4R1, Junos OS supports using Source Packet Routing in Networking (SPRING) as the underlay transport in EVPN. SPRING tunnels enable routers to steer a packet through a specific set of nodes and links in the network.

    To configure SPRING, use the source-packet-routing statement at the [edit protocols isis] hierarchy level.

    [See Understanding Source Packet Routing in Networking (SPRING).]

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

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

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

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

    [See Overview of MAC Mobility. ]

General Routing

  • Enhancement to show chassis forwarding-options command (QFX5200 Virtual Chassis)—Starting in Junos OS Release 17.4R1, the show chassis forwarding-options command displays information about memory banks for QFX5200 Virtual Chassis only for the master. This information is not displayed for all the other members Memory banks can be partitioned among different types of forwarding table entries through the Unified Forwarding Table feature. Values remain the same across all members. All configuration changes for the Unified Forwarding Table are made through the Master.

    [See show chassis forwarding-options.]

Interfaces and Chassis

  • Support for resilient hashing for LAGs and ECMP (QFX10000)—Starting with Junos OS Release 17.4R1 on QFX10000 switches, you can prevent the reordering of flows to active paths in link aggregation groups (LAGs) or ECMP when one or more paths fail. Only flows that are on inactive paths are redirected. It overrides the default behavior of disrupting all existing, including active, TCP connections when an active path fails. You can optionally set a specific value for the resilient-hash seed that differs from the hash-seed value that will be used by the other hash functions on the switch. A resilient hashing configuration on ECMP is applied through use of a route policy.

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

  • Enterprise profile for Precision Time Protocol (PTP) (QFX10002 switches)—Starting with Junos OS Release 17.41, the enterprise profile, which is based on PTPv2, provides the ability for enterprise and financial markets to timestamp on different systems and to handle a range of latency and delays.

    The enterprise profile supports the following options:

    • IPv4 multicast transport

    • Ordinary and boundary clocks

    • 1-Gigabit SFP grandmaster port

    • 512 downstream slave clocks

    You can configure the enterprise profile at the [edit protocols ptp profile-type] hierarchy.

    [See Understanding Transparent Clocks in Precision Time Protocol.]

  • Support for Precision Time Protocol (PTP) transparent clock (QFX5200 switches)—Starting with Junos OS Release 17.4R1, 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, UDP over IPv4 and IPv6 and unicast and multicast transparent clock are supported.

    [See Understanding Transparent Clocks in Precision Time Protocol.]

Junos OS XML API and Scripting

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

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

Management

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

    [See Guidelines for gRPC Sensors.]

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

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

    [See Guidelines for gRPC Sensors.]

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

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

Multicast

  • Support for static multicast route leaking for VRF and virtual-router instances (QFX5110 and QFX5200 switches)—Starting with Junos OS Release 17.4R1, 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.

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

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

    [See Understanding MLD Snooping on Switches.]

  • Multicast-only fast reroute (MoFRR) (QFX5100, QFX5110, and QFX5200 switches)—Starting in Junos OS Release 17.4R1, QFX5100, QFX5110, and QFX5200 switches support MoFRR, which minimizes multicast packet loss in PIM domains when there are link failures. With MoFRR enabled, the switch maintains both a primary and a backup multicast packet stream toward the multicast source, accepting traffic received on the primary path and dropping traffic received on the backup path. Upon primary path failure, the backup path becomes the primary path and quickly takes over forwarding the multicast traffic. If alternative paths are available, a new backup path is created. When enabling MoFRR, you can optionally configure a policy for the (S,G) entries to which MoFRR should apply; otherwise MoFRR applies to all multicast (S,G) streams.

    [See Understanding Multicast-Only Fast Reroute on Switches.]

  • Support for rpf-selection statement for PIM protocol at global instance level (QFX Series)—Starting in Junos OS 17.4R1, the rpf-selection statement for the PIM protocol is available at global instance level. You can configure group and source statements at the [edit protocols pim rpf-selection] hierarchy level.

MPLS

  • Support for BGP MPLS-based Ethernet VPN (QFX10000 Series switches)—Starting with Junos OS Release 17.4R1, you can use MPLS-based Ethernet VPN (EVPN) to route MAC addresses using BGP over an MPLS core network. An EVPN enables you to connect dispersed customer sites by using a Layer 2 virtual bridge. As with other types of VPNs, an EVPN consists of a customer edge (CE) device (host, router, or switch) connected to a provider edge (PE) switch. The QFX10000 acts as a PE switch at the edge of the MPLS infrastructure. The switch can be connected by an MPLS Label Switched Path (LSP) which provides the benefits of MPLS technology, such as fast reroute and resiliency. You can deploy multiple EVPNs within a service provider network, each providing network connectivity to a customer while ensuring that the traffic sharing on that network remains private.

    [See EVPN Overview.]

  • Support for static adjacency segment identifier for ISIS (QFX Series)—Starting with Junos OS Release 17.4R1, you can configure static adjacency segment ID (SID) labels for an interface. You can configure two IPv4 adjacency SIDs (protected and unprotected), IPv6 adjacency SIDs (protected and unprotected) per level per interface. You can use the same adjacent SID for multiple interfaces by grouping a set of interfaces under an interface-group and configuring the adjacency-segment for that interface-group. For static adjacency SIDs, the labels are picked from either a static reserved label pool or from segment routing global block (SRGB).

    [See Static Adjacency Segment Identifier for ISIS.]

  • Support for static adjacency segment identifier for aggregate Ethernet member links (QFX Series)—Starting with Junos OS Release 17.4R1, you can configure a transit single-hop static label switched path (LSP) for a specific member link of an aggregate Ethernet (AE) interface. A static labeled route is added with next-hop pointing to the AE member link of an aggregate interface. Label for these routes is picked from the segment routing local block (SRLB) pool of the configured static label range. This feature is supported for AE interfaces only.

    A new member-interface CLI command is added under [edit protocols mpls static-label-switched-path lsp-name transit] hierarchy to configure the AE member interface name. The static LSP label is configured from a defined static label range.

    [See Configuring Static Adjacency Segment Identifier for Aggregate Ethernet Member Links Using Single-Hop Static LSP.]

  • Support for PCEP (QFX5100, QFX5110, QFX5200 switches)—Starting with Junos OS Release 17.4R1, MPLS RSVP-TE functionality was extended to provide a partial client-side implementation of the stateful Path Computation Element (PCE) architecture (draft-ietf-pce-stateful-pce). The PCE computes path for the traffic engineered LSPs (TE LSPs) of ingress routers that are configured for external control. The ingress router that connects to a PCE is called a Path Computation Client (PCC). The PCC is configured with the Path Computation Client Protocol (PCEP) (defined in RFC 5440, but limited to the functionality supported on a stateful PCE only) to facilitate external path computing by a PCE. In this new functionality, the active stateful PCE sets parameters for the PCC's TE LSPs, such as bandwidth, path (ERO), and priority.

    [See PCEP Overview.]

  • Support for Flap and MBB counter for LSP (QFX Series)—Starting in Junos OS Release 17.4R1, the show mpls lsp extensive command introduces the following two counters for LSP on master routing engine (RE) only:

    • Flap counter–- Counts the number of times a LSP flaps down or up.

    • MBB counter— Counts the number of times a LSP incurs MBB.

    The clear mpls lsp counters command resets the flap and the MBB counter to zero.

  • Display of labels in received record route for unprotected LSPs by show mpls lsp extensive command (QFX Series)—The show mpls lsp extensive command displays the labels in received record route (RRO) for protected LSPs. Starting in Junos OS Release 17.4R1, the command also displays the labels associated with the hops in RRO for unprotected LSPs as well. The label recording in RRO is enabled by default.

  • Support for default timeout duration for self-ping on an LSP instance (QFX Series)—Starting in Junos OS 17.4R1, the default timeout duration for which the self-ping runs on an LSP instance is reduced from 65,535 (runs until success) to 1800 seconds. You can also manually configure the self-ping duration value between 1 to 65,535 (runs until success) seconds using the self-ping-duration value command at the [edit protocols mpls label-switched-path label-switched-path] hierarchy level. By default, self-ping is enabled. The LSP types such as CCC, P2MP, VLAN-based , and non-default instances do not support self-ping . You can configure the no-self-ping command at the [edit protocols mpls label-switched-path label-switched-path] hierarchy level to override the behavior of self-ping running by default.

  • Support for label history for MPLS protocol (QFX Series)—Starting in Junos OS Release 17.4R1, configure max-entries number option at [edit protocols mpls label-history] hierarchy level to display label allocation, release history, and associated information such as RSVP session that helps debug label related error such as stale label route and deleted label route. You can configure the limit for the maximum number of MPLS history entry per label . By default, label history is off and there is no maximum limit for the number of entries for each label. The show mpls label history label-value command displays the label history for a given label value and the show mpls label history label-range start-label end-label command displays the history of labels between the given label range.

    The clear mpls label history command clears the label history details.

  • Support for adjusting the threshold of autobandwidth based on the absolute value for LSP (QFX Series)—Current autobandwidth threshold adjustment is done based on the configured percentage that is hard to tune to work well for both small and large bandwidth reservations. For a given threshold percentage, when the bandwidth reservation is small there can be multiple LSP resignalling events. This is because the LSP is responsive to even minor increase or decrease in the utilization when current reservation is small. For example, a small threshold adjustment of 5 percent allows large LSPs of say 1G to respond to changes in bandwidth of the order of 50M. However, that same threshold adjustment results in too many LSP resignalling events for small LSPs of say 10M reservation. Increasing the adjust threshold percentage by for example 40 percent minimizes LSP resignalling for small LSPs. However, large LSPs do not react to bandwidth usage changes unless it is huge, for example 400M. Starting in Junos OS Release 17.4R1, you can configure an absolute value based threshold along with the percentage based threshold that helps avoid the bandwidth getting triggered for LSPs of both small and large bandwidth reservations. Configure adjust-threshold-absolute value option at [edit protocols mpls label-switched-path lsp-name auto-bandwidth] hierarchy level.

Network Management and Monitoring

  • Real-time performance monitoring (RPM) (QFX5100 switches)—Starting in Junos OS Release 17.4R1-S1, real-time performance monitoring (RPM) on QFX5100 switches enables you to configure active probes to track and monitor traffic across the network and to investigate network problems.

    The ways in which you can use RPM include:

    • Monitor time delays between devices.

    • Monitor time delays at the protocol level.

    • Set thresholds to trigger SNMP traps when values are exceeded.

      You can configure thresholds for round-trip time, ingress or egress delay, standard deviation, jitter, successive lost probes, and total lost probes per test.

    • Determine automatically whether a path exists between a host router or switch and its configured BGP neighbors. You can view the results of the discovery using an SNMP client.

    • Use the history of the most recent 50 probes to analyze trends in your network and predict future needs.

    [See Understanding Real-Time Performance Monitoring on Switches .]

Port Security

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

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

Routing Protocols

  • Topology-independent loop-free alternate for IS-IS (QFX Series)—Starting in Junos OS Release 17.4R1, topology-independent loop-free alternate (TI-LFA) with segment routing provides MPLS fast reroute (FRR) backup paths corresponding to the post-convergence path for a given failure. You can enable TI-LFA for IS-IS by configuring the use-post-convergence-lfa statement at the [edit protocols isis backup-spf-options] hierarchy level. TI-LFA provides protection against link failure, node failure, and failures of fate-sharing groups.

    You can enable the creation of post-convergence backup paths for a given interface by configuring the post-convergence-lfa statement at the [edit protocols isis interface interface-name level level] hierarchy level. The post-convergence-lfa statement enables link-protection mode.

    You can enable node-protection and/or fate-sharing-protection mode for a given interface at the [edit protocols isis interface interface-name level level post-convergence-lfa] hierarchy level. To use a particular fate-sharing group as a constraint for the fate-sharing-aware post-convergence path, you need to configure the use-for-post-convergence-lfa statement at the [edit routing-options fate-sharing group group-name] hierarchy level.

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

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

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

    • Program the EBGP route server.

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

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

    [See BGP Route Server Overview.]

  • Support for BGP advertising aggregate bandwidth across external BGP links for load balancing (QFX Series)—Starting in Junos OS Release 17.4R1, BGP uses a new link bandwidth extended community, aggregate-bandwidth, to advertise aggregated bandwidth of multipath routes across external links. BGP calculates the aggregate of multipaths that have unequal bandwidth allocation and advertises the aggregated bandwidth to external BGP peers. A threshold to the aggregate bandwidth can be configured to restrict the bandwidth usage of a BGP group. In earlier Junos OS releases, a BGP speaker receiving multipaths from its internal peers advertised the link bandwidth associated with the active route. To advertise aggregated bandwidth of multipath routes and to set a maximum threshold, configure a policy with aggregate-bandwidth and limit bandwidth actions at the [edit policy-options policy-statement name then] hierarchy level.

    See [Advertising Aggregate Bandwidth Across External BGP Links for Load Balancing Overview].

Services Applications

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

    You must also perform the following configuration:

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

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

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

    This feature was previously introduced on QFX10002 switches in Junos OS Release 17.2R1.

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

Software Installation and Upgrade

  • Support for personality files (QFX5100 switches)—Starting in Junos OS Release 17.4R1, when a switch in a data center network goes down because of a hardware failure, replacing that switch can be time-consuming and error-prone, because you have to ensure that the crucial elements that you had running on the downed switch are exactly replicated on the new switch. To save time and to avoid errors in configuration and state when you replace a switch, create a “personality” file for your current switch while the switch is still up and save that personality file on a remote server. The “personality” of a switch could include (but is not limited to) its running configuration, SNMP indices, and installed scripts and packages. If the current switch goes down, retrieve the personality file from the server, install it on a new switch, and then bring that new switch online in place of the downed switch.

    [See Personality File for Easy Switch Replacement.]