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 EX Series.

EVPNs

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

Management

  • Changes to Junos OS YANG module naming conventions (EX 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.]

Network Management and Monitoring

  • Change in default log level setting (EX 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.]

  • SNMP syslog messages changed (EX Series)—Starting 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.]

  • 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 (EX 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.]

Security

  • Support for logging SSH key changes—Starting with Junos OS Release 17.4R1, the configuration statement log-key-changes is introduced at the [edit system services ssh ] hierarchy level. When 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 log-key-changes was enabled. If log-key-changes 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 (EX 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.]

Subscriber Management and Services

  • DHCPv6 lease renewal for separate IA renew requests (EX Series)—Starting in Junos OS Release 17.4R2, the jdhcpd process handles the second renew request differently if the DHCPv6 client CPE device does both of the following:

    • Initiates negotiation for both the IA_NA and IA_PD address types in a single solicit message.

    • Sends separate lease renew requests for the IA_NA and the IA_PD and the renew requests are received back-to-back.

    The new behavior is as follows:

    1. When the reply is received for the first renew request, if a renew request is pending for the second address type, the client stays in the renewing state, the lease is extended for the first IA, and the client entry is updated.

    2. When the reply is received for the second renew request, the lease is extended for the second IA and the client entry is updated again.

    In earlier releases:

    1. The client transitions to the bound state instead of staying in the renewing state. The lease is extended for the first IA and the client entry is updated.

    2. When the reply is received for the second renew request, the lease is not renewed for the second address type and the reply is forwarded to the client. Consequently, when that lease ages out, the binding for that address type is cleared, the access route is removed, and subsequent traffic is dropped for that address or address prefix.

    [See Using DHCPv6 IA_NA with DHCPv6 Prefix Delegation Overview.]

Virtual Chassis

  • New configuration option to disable automatic Virtual Chassis port conversion (EX4300 and EX4600 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 an EX4300 or EX4600 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].