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 in Junos OS Release 17.4R2 for the PTX Series.
Class of Service (CoS)
Changes in configuration of hardware-based queue priority (PTX Series)—Starting in Junos OS Release 17.4R1, the mapping of output queue priority values in the Junos OS to the output queue priorities supported by physical interfaces on PTX Series routers has changed. For shared scheduling, when strict-high is not configured, setting the priority to high maps to the hardware priority high. And for strict-priority scheduling, setting the priority to high maps to the hardware priority high. For the full mapping of output queue priorities, see Understanding Scheduling on PTX Series Routers.
Interfaces and Chassis
Secondary interface (em2) raises an alarm when the link is down (PTX1000)—Starting in Junos OS Release 17.4R1, secondary interface (em2) raises alarm when the link goes down. Earlier, no alarm was raised when an em2 (secondary interface) went down. Currently, the behavior is changed and an alarm will be raised when the interface link goes down as shown below:
user@host# run show chassis alarms 3 alarms currently active Alarm time Class Description 2017-09-12 23:41:20 PDT Major FPC Management2 Ethernet Link Down 2017-09-12 23:38:45 PDT Major FPC0: PEM 2 Not Powered 2017-09-12 23:38:45 PDT Major FPC0: PEM 0 Not Powered
Modified output of the request vmhost zeroize command—Starting with Junos OS Release 17.2, the command request vmhost zeroize, upon execution, prompts the user for confirmation to proceed. The following line is displayed:
user@host request vmhost zeroize VMHost Zeroization : Erase all data, including configuration and log files ? [yes,no] (no) yes
Power supply alarm is not raised when the input switch status is OFF or power not connected (PTX10008, PTX10016)—Starting in Junos OS Release 17.4R2, the power supply alarm A power supply input has failed will not be raised if the INP1/INP2 switch status if off and the power is not connected. Earlier, an alarm was raised for the power entry module (PEM) that it was not powered on as Not Powered irrespective of the switch state. For the power supply status, execute the show chassis power or show chassis power detail CLI command. The DC input is the new output parameter that provides information about the status of the input feed.
user@host> show chassis power
PEM 0: State: Online Capacity: 2500 W (maximum 2500 W) DC output: 864 W (zone 0, 72 A at 12 V, 34% of capacity) PEM 1: State: Online Capacity: 2500 W (maximum 2500 W) DC output: 864 W (zone 0, 72 A at 12 V, 34% of capacity) System: Zone 0: Capacity: 7500 W (maximum 7500 W) Allocated power: 6525 W (975 W remaining) Actual usage: 2616 W Total system capacity: 7500 W (maximum 7500 W) Total remaining power: 975 W ...
user@host> show chassis power
PEM 0: State: Online Capacity: 2500 W (maximum 2500 W) DC input: OK (No feed expected, Both feed connected) DC output: 576 W (zone 0, 48 A at 12 V, 23% of capacity) PEM 1: State: Online Capacity: 2500 W (maximum 2500 W) DC input: OK (No feed expected, Both feed connected) DC output: 576 W (zone 0, 48 A at 12 V, 23% of capacity) ...
[See show chassis power.]
Changes to Junos OS YANG module naming conventions (PTX 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 for adjusting the threshold of autobandwidth based on the absolute value for LSP (PTX 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.
Support for label history for MPLS protocol (PTX 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 default time out duration for self-ping on an LSP instance (PTX Series)—Starting in Junos OS 17.4R1, the default time out 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 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 like CCC, P2MP, VLAN-based, and non-default instances do not support self-ping . You can configure 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.
Display of labels in received record route for unprotected LSPs by show mpls lsp extensive command (PTX 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 flap and MBB counter for LSP (PTX 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 only:
Flap counter–- Counts the number of times an LSP flaps down or up.
MBB counter— Counts the number of times an LSP incurs MBB.
The clear mpls lsp counters command resets the flap and the MBB counter to zero.
Support for rpf-selection statement for PIM protocol at global instance level (PTX 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.
Network Management and Monitoring
Change in default log level setting (PTX 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 (PTX 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.]
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 (PTX 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.
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 the log-key-changes 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.
Key generator adds one day to make the duration of license show as 365 days (PTX 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 duration 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 (PTX 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:
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.