What's Changed

OISM SBD bit in EVPN Type 3 route multicast flags extended community—In EVPN Type 3 Inclusive Multicast Ethernet Tag (IMET) route advertisements for interfaces associated with the supplemental bridge domain (SBD) in an EVPN optimized intersubnet multicast (OISM) network, we now set the SBD bit in the multicast flags extended community. We set this bit for interoperability with other vendors, and to comply with the IETF draft standard for OISM, draft-ietf-bess-evpn-irb-mcast.You can see this setting in the output from the show route table bgp.evpn.0 ? extensive command.

[See CLI Commands to Verify the OISM Configuration.]

Group-based Policy (GBP) tag displayed with show bridge mac-table command—On platforms that support VXLAN-GBP, the show bridge mac-table command now displays a GBP TAG output column that lists the GBP tag associated with the MAC address for a bridge domain or VLAN in a routing instance. Even if the device doesn?t support or isn?t using GBP itself, the output includes this information for GBP tags in packets received from remote EVPN-VXLAN peers.

[See Example: Micro and Macro Segmentation using Group Based Policy in a VXLAN.]

This feature now includes a few new options so you have more flexibility to customize the generated configuration:

• no-underlay-config at the [edit services evpn] hierarchy level—To provide your own underlay peering configuration.

• mtu overlay-mtu and mtu underlay-mtu options at the [edit services evpn global-parameters] hierarchy level—To change the default assigned MTU size for underlay or overlay packets.

[See Easy EVPN LAG Configuration.]

Limit on number of IP address associations per MAC address per bridge domain in EVPN MAC-IP database—By default, devices can associate a maximum of 200 IP addresses with a single MAC address per bridge domain. We provide a new CLI statement to customize this limit, mac-ip-limit statement at the [edit protocols evpn] hierarchy level. In most use cases, you don?t need to change the default limit. If you want to change the default limit, we recommend that you don?t set this limit to more than 300 IP addresses per MAC address per bridge domain. Otherwise, you might see very high CPU usage on the device, which can degrade system performance.

[See mac-ip-limit.]

The subscription path for the flow sensor is changed from /junos/security/spu/flow/usage to /junos/security/spu/flow/statistics. This change maintains a uniform path in request and response data.

Change in the XML tags displayed for the show virtual-network-functions command in JDM (Junos node slicing) — To align the XML tags displayed for the show virtual-network-functions gnf-name | display xml with the new XML validation logic, we have replaced the underscores (_) in the output with hyphens (-) as shown below:

Old output:

user@host> show virtual-network-functions mgb-gnf-d | display xml (vnf-instance) 1mgb-gnf-dRunningdown <ip_addr>192.168.2.1</ip_addr> <<< The tag includes _. 2 <max_mem>16GiB</max_mem> <<< The tag includes _. <resource_template>2core-16g</resource_template> <<< The tag includes _. <qemu_process_id>614702</qemu_process_id> <<< The tag includes _. <smbios_version>v2</smbios_version> <<< The tag includes _. New output: user@jdm> show virtual-network-functions mgb-gnf-d | display xml 1mgb-gnf-dRunningdown192.168.2.1 <<< The tag changes to ip-addr. 216GiB <<< The tag changes to max-mem. 2core-16g <<< The tag changes to resource-template. 614702 <<< The tag changes to qemu-process-id. v2 <<< The tag changes to smbios-version. This change is applicable to any RPC that previously had underscores in the XML tag name.

When you run the run show lldp local-information interface interface-name | display xml command, the output is displayed under the lldp-local-info root tag and in the lldp-local-interface-info container tag. When you run the run show lldp local-information interface | display xml command, the lldp-tlv-filter and lldp-tlv-select information are displayed under the lldp-local-interface-info container tag in the output.

Change in use of RSA signatures with SHA-1 hash algorithm?Starting in Junos OS Release 24.2R1, there is a behavioural change by OpenSSH 8.8/8.8p1. OpenSSH 8.8/8.8p1 disables the use of RSA signatures with SHA-1 hash algorithm by default. You can use RSA signatures with SHA-256 or SHA-512 hash algorithm.

Starting from Junos OS 21.4R1 platforms with the following Routing Engines which have Intel CPUs with microcode version 0x35 observe the error warning, "000: Firmware Bug: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x3a (or later)" on the console. RE-S-X6-64G RE-S-X6-128G REMX2K-X8-64G RE-PTX-X8-64G RE-MX2008-X8-64G RE-MX2008-X8-128G

Non-revertive switchover for sender based MoFRR— In earlier Junos releases, source-based MoFRR ensured that the traffic reverted to the primary path from the backup path, when the primary path or session was restored. This reversion could result in traffic loss. Starting in Junos OS 22.4R3-S1, source-based MoFRR will not revert to the primary path, i.e. traffic will continue to flow through the backup path as long as the traffic flow rate on the backup path does not go below the configured threshold set under protocols mvpn hot-root-standby min-rate.

[See min-rate]

Show active forwarding session for sender based MoFRR— The show multicast route extensive command will show the active forwarding session in the case of source-based MoFRR. The field Session Status: Up and Forwarding will indicate that the particular session is currently forwarding traffic.

[See show multicast route.]

For MPC5E line card with flexible-queuing-mode enabled, queue resources are shared between scheduler block 0 and 1. Resource monitor CLI output displays an equal distribution of the total available and used queues between scheduler blocks. This correctly represents the queue availability to the routing engine.

Change to the commit process—In prior Junos OS and Junos OS Evolved releases, if you use the commit prepare command and modify the configuration before activating the configuration using the commit activate command, the prepared commit cache becomes invalid due to the interim configuration change. As a result, you cannot perform a regular commit operation using the commit command. The CLI shows an error message: 'error: Commit activation is pending, either activate or clear commit prepare'. If you now try running the commit activate command, the CLI shows an error message: 'error: Prepared commit cache invalid, failed to activate'. You then must clear the prepared configuration using the clear system commit prepared command before performing a regular commit operation. From this Junos and Junos OS Evolved release, when you modify a device configuration after 'commit prepare' and then issue a 'commit', the OS detects that the prepared cache is invalid and automatically clears the prepared cache before proceeding with regular 'commit' operation.

[See Commit Preparation and Activation Overview.]

In a firewall filter configured with a port-mirror-instance or port-mirror action, if l2-mirror action is also configured, then port-mirroring instance family should be any. In the absence of the l2-mirror action, port-mirroring instance family should be the firewall filter family.

Changes to the XML output for ping RPCs (MX480)—We've updated the junos-rpc-ping YANG module and the corresponding Junos XML RPCs to ensure that the RPC XML output conforms to the YANG schema. As a result, we changed the XML output for the following ping RPCs:

• <ping>—The XML output emits <ping-error-message> and <ping-warning-message> tags instead of <xnm:error> and <xnm:warning> tags.

• <request-ping-ce-ip>—The XML output is enclosed in an <lsping-results> root element.

• <request-ping-ethernet>—

  • The <ethping-results> root tag includes a <cfm-loopback-reply-entry> or <cfm-loopback-reply-entry-rapid> tag for each received response. In earlier releases, a single tag enclosed all responses.

  • The XML output includes only application specific error tags and omits <xnm:error> tags.

  • The <cfm-loopback-reply-entry-rapid> tag is now reflected in the YANG schema.

• <request-ping-overlay>—The <ping-overlay-results> element includes a new child tag <hash-udp-src-port>.

Starting Junos Evolved Release 24.1R1, support for Network Time Protocol (NTP) over TLS (RFC 8915 compliant) for the ACX-series, QFX-series, and PTX-series includes: - Support to configure local-certificate for server and certificate verification option for client. - Verification of x.509 certificates to establish a TLS channel between client and server. - TLS NTS-KE protocol support - Support for NTS secured client-server NTP communication at server and client. - Support for new NTS options in commands "system ntp nts", "system ntp server (server_name) nts remote-identity", and "show ntp associations no-resolve" commands.

Viewing files with the file compare files command requires users to have maintenance permission—The file compare files command in Junos OS and Junos OS Evolved requires a user to have a login class with maintenance permission.

[See Login Classes Overview.

Increase in revert-delay timer range— The revert-delay timer range is increased to 600 seconds from 20 seconds.

[See min-rate.]

Configure min-rate for IPMSI traffic explicitly— In a source-based MoFRR scenario, you can set a min-rate threshold for IPMSI traffic explicitly by configuring ipmsi-min-rate under set routing-instances protocols mvpn hot-root-standby min-rate. If not configured, the existing min-rate will be applicable to both IPMSI and SPMSI traffic.

[See min-rate.]