Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Changes in Behavior and Syntax


This section lists the changes in behavior of Junos OS features and changes in the syntax of Junos OS statements and commands from Junos OS Release 17.4R2 for the QFX Series.

Class of Service (CoS)

  • When you configure a transmit-rate, you must also configure a guaranteed-rate under traffic-control-profiles. If you commit a configuration of a transmit-rate without a guaranteed-rate, a warning message is displayed and the default scheduler map is applied.


  • Change to the show vlans evpn command (QFX5100 switches)—Starting with Junos OS Release 17.4R2, the show vlans evpn command is replaced by the show ethernet-switching evpn command.

General Routing

  • Change in default value for port ID TLV for QFX5200 switches—In Junos OS Release 17.4R1, for QFX5200 switches, the default value used for port ID TLV in LLDP messages is interface name, not SNMP index.


  • Changes to Junos OS YANG module naming conventions (QFX Series)—Starting in Junos OS Release 17.4R1, the native Junos OS YANG modules use a new naming convention for the module's name, filename, and namespace. The module name and filename include the device family and the area of the configuration or command hierarchy to which the schema in the module belongs. In addition, the module filename includes a revision date. The module namespace is simplified to include the device family, the module type, and an identifier that is unique to each module and that differentiates the namespace of the module from that of other modules.

    [See Understanding Junos OS YANG Modules.]


  • 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 the 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 the [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 entries 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 which 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 resignaling events. This is because the LSP is responsive to even minor increases or decreases in the utilization when current reservation is small. For example, a small threshold adjustment of 5 percent allows large LSPs of around 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 around 10M reservation. Increasing the adjust threshold percentage by for example 40 percent minimizes LSP resignaling for small LSPs. However, large LSPs do not react to bandwidth usage changes unless they are 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 the [edit protocols mpls label-switched-path lsp-name auto-bandwidth] hierarchy level.

  • When the no-propagate-ttl statement is configured on a QFX5200 switch in an MPLS network, the TTL value is not is not copied and decremented on the transit devices during a swap operation. When the switch acts as an ingress device for an LSP, it pushes an MPLS header with a TTL value of 255, regardless of the IP packet TTL. When the switch acts as the penultimate provider switch, it pops the MPLS header without writing the MPLS TTL into the IP packet. PR1368417

Network Management and Monitoring

  • Change in default log level setting (QFX Series)—In Junos OS Release, 17.4R1, the following changes were made in default logging levels:

    Before this change:

    • SNMP_TRAP_LINK_UP was LOG_INFO for both the physical (IFD) and logical (IFL) interfaces.

    • SNMP_TRAP_LINK_DOWN was LOG_WARNING for both the physical (IFD) and logical (IFL) interfaces.

    After this change:

    • IFD LinkUp -> LOG_NOTICE (because this is an important message but less frequent)

    • IFL LinkUp -> LOG_INFO (no change)

    • IFD and IFL LinkDown -> LOG_WARNING (no change)

    [See the MIB Explorer.]

  • New context-oid option for trap-options configuration statement to distinguish the traps that come from a non-default routing instance with a non-default logical system (QFX Series)—Starting in Junos OS Release 17.4R2, a new option, context-oid, for the trap-options statement allows you to handle prefixes such as <routing-instance name>@<trap-group> or <logical-system name>/<routing-instance name>@<trap-group> as an additional varbind.

    [See trap-options.]

  • SNMP syslog messages changed (QFX Series)—In Junos OS Release 17.4R1, two misleading SNMP syslog messages have been rewritten to accurately describe the event:

    • OLD --AgentX master agent failed to respond to ping. Attempting to re-register

      NEW –- AgentX master agent failed to respond to ping, triggering cleanup!

    • OLD –- NET-SNMP version %s AgentX subagent connected

      NEW --- NET-SNMP version %s AgentX subagent Open-Sent!

    [See the SNMP MIB Explorer.]

Routing Policy and Firewall Filters

  • Support for configuring the GTP-TEID field for GTP traffic (QFX5000 line of switches)—Starting in Junos OS Release 17.3R3 and 17.4R2, the gtp-tunnel-endpoint-identifier statement is supported to configure the hash calculation of IPv4 or IPv6 packets that are included in the GPRS tunneling protocol–tunnel endpoint identifier (GTP-TEID) field hash calculations. The gtp-tunnel-endpoint-identifier configuration statement is configured at the [edit forwarding-options enhanced-hash-key family inet] hierarchy level.

    In most of the cases, configuring gtp-tunnel-endpoint-identifier statement is sufficient for enabling GTP hashing. After enabling, if GTP hashing does not work, it is recommended to capture the packets using relevant tools and identify the offset value. As per standards, 0x32 is the default header offset value. But, due to some special patterns in the header, offset may vary to say 0x30, 0x28, and so on. In this cases, use gtp-header-offset statement to set a proper offset value. Once the header offset value is resolved, run gtp-tunnel-endpoint-identifier command for enabling GTP hashing successfully.

    [See gtp-tunnel-endpoint-identifier and gtp-header-offset.]


  • Support to log the SSH key changes—Starting with Junos OS 17.4R1, the configuration statement log-key-changes is introduced at the [edit system services ssh ] hierarchy level. When the log-key-changes configuration statement is enabled and committed (with the commit command in configuration mode), Junos OS logs the changes to the set of authorized SSH keys for each user (including the keys that were added or removed). Junos OS logs the differences since the last time the log-key-changes configuration statement was enabled. If the log-key-changes configuration statement was never enabled, then Junos OS logs all the authorized SSH keys.

Software Licensing

  • Key generator adds one day to make the duration of license show as 365 days (QFX Series)—Starting in Junos OS Release 17.4R1, the duration of subscription licenses as generated by the show system license command and shown in the output is correct to the numbers of days. Before this fix, for example, for a 1-year subscription license, the duration was generated as 364 days. After the fix, the duration of the 1-year subscription now shows as 365 days.

    [See show system license.]

Virtual Chassis

  • Adaptive load balancing (ALB) feature (Virtual Chassis Fabric)—Starting in Junos OS Release 17.4R1, the adaptive load balancing (ALB) feature for Virtual Chassis Fabric (VCF) is being deprecated to avoid potential VCF instability. The fabric-load-balance configuration statement in the [edit forwarding-options enhanced-hash-key] hierarchy is no longer available to enable and configure ALB in a VCF. When upgrading a VCF to a Junos OS release where ALB is deprecated, if the configuration has ALB enabled, you should delete the fabric-load-balance configuration item before initiating the upgrade.

    [See Understanding Traffic Flow Through a Virtual Chassis Fabric and fabric-load-balance.]

  • New configuration option to disable automatic Virtual Chassis port conversion (QFX5100 Virtual Chassis)—Starting in Junos OS Release 17.4R2, you can use the no-auto-conversion statement at the [edit virtual-chassis] hierarchy level to disable automatic Virtual Chassis port (VCP) conversion in a QFX5100 Virtual Chassis. Automatic VCP conversion is enabled by default on these switches. When automatic VCP conversion is enabled, if you connect a new member to a Virtual Chassis or add a new link between two existing members in a Virtual Chassis, the ports on both sides of the link are automatically converted into VCPs when all of the following conditions are true:

    • LLDP is enabled on the interfaces for the members on both sides of the link. The two sides exchange LLDP packets to accomplish the port conversion.

    • The Virtual Chassis must be preprovisioned with the switches on both sides of the link already configured in the members list of the Virtual Chassis using the set virtual-chassis member command.

    • The ports on both ends of the link are supported as VCPs and are not already configured as VCPs.

    Automatic VCP conversion is not needed when using default-configured VCPs on both sides of the link to interconnect two members. On both ends of the link, you can also manually configure network or uplink ports that are supported as VCPs, whether or not the automatic VCP conversion feature is enabled.

    Deleting the no-auto-conversion statement from the configuration returns the Virtual Chassis to the default behavior, which reenables automatic VCP conversion.

    [See no-auto-conversion.]