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 ACX Series Universal Metro Routers.
Changes to Junos OS YANG module naming conventions (ACX 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.
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.
Subscriber Management and Services
DHCPv6 lease renewal for separate IA renew requests (ACX Series)—Starting in Junos OS Release 17.4R2, the jdhcpd process handles the second renew request differently in the situation where 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:
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.
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:
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.
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.