Application Hosting

Docker Application Management using IPv6 Address

In this release, you gain the ability to manage Docker applications within containers using IPv6 addresses via the router's management interface. Leveraging IPv6 addresses provides expanded addressing options, enhances network scalability, and enables better segmentation and isolation of applications within the network.

Prior to this update, only IPv4 addresses could be used to manage docker applications.

Programmability

Automatic Resynchronization of OpenConfig Configuration

OpenConfig infrastructure can now reapply all the OpenConfig configurations automatically if there are any discrepancies in the running configuration.

With this feature, there is no need for manual replacement of the OpenConfig configuration using Netconf or gNMI.

The re-sync operation is triggered if the running configurations and the OpenConfig configuration go out of sync after any system event that removes some running configurations from the system. A corresponding system log gets generated to indicate the re-sync status.

gRPC Network Security Interface

This release implements authorization mechanisms to restrict access to gRPC applications and services based on client permissions. This is made possible by introducing an authorization protocol buffer service for gRPC Network Security Interface (gNSI).

This feature introduces the following change:

CLI:

• gnsi load service authorization policy

• show gnsi service authorization policy

BGP

BGP Labeled Unicast over RSVP-TE

You can now steer the MPLS traffic as per your requirement instead of relying on what the IGP directs.

This feature extends the BGP Labeled Unicast (LU) functionality over RSVP-TE protocol. BGP LU advertises label bindings while RSVP-TE establishes the traffic engineering paths that you specify. This feature allows the provider Edge (PE) routers to forward incoming traffic using the label bindings along the specific path reserved using RSVP-TE. This ability to provide explicit routing ensures optimal use of your network resources.

The feature introduces these changes:

CLI:

• hw-module profile cef bgplu-over-rsvpte enable

YANG Data Models:

• Cisco-IOS-XR-npu-hw-profile-cfg.yang (see GitHub, YANG Data Models Navigator)

Peering Between BGP Routers Within the Same Confederation

You can now enable BGP peering between routers in the sub-autonomous system (AS) within a confederation to advertise specific router updates using iBGP. This capability ensures that the mesh of routers between sub-ASes in a confederation maintains consistent routing tables, ensuring proper network reachability. Enabling this feature helps improve preventing performance reduction and traffic management challenges.

The feature introduces these changes:

CLI:

New Command:

• allowconfedas-in

YANG Data Models

• New XPaths for

  • Cisco-IOS-XR-ipv4-bgp-cfg.yang

  • Cisco-IOS-XR-um-router-bgp-cfg

(see GitHub, YANG Data Models Navigator)

Virtual Routing Forwarding Next Hop Routing Policy

You can now enable a route policy at the BGP next-hop attach point to limit notifications delivered to BGP for specific prefixes, which equips you with better control over routing decisions, and allows for precise traffic engineering and security compliance for each VRF instance, and helps establish redundant paths specific to each VRF.

The feature introduces these changes:

CLI:

Modified Command:

• The nexthop route-policy command is extended to VRF address-family configuration mode.

YANG Data Model

• New XPaths for

  • Cisco-IOS-XR-ipv4-bgp-cfg.yang

  • Cisco-IOS-XR-um-router-bgp-cfg

(see GitHub, YANG Data Models Navigator)

Interface and Hardware Component

Diagnostic Parameters for Optical Transceivers

You can analyze the diagnostic parameters for optical transceivers installed on a network device and detect potential issues with the optical transceivers, such as excessive power levels, abnormal temperature readings, or degradation of the optical signal. Such analysis is possible because the show controllers optics command now displays the following diagnostic parameters:

• Effective Signal to Noise Ratio (eSNR)

• Pulse Amplitude Modulation with Four Levels (PAM4) Level Transition Parameter (LTP)

• Pre-Forward Error Correction (FEC) and Post-FEC Bit Error Rate (BER)

• Frame Error Count (FERC)

• Laser age

• Thermoelectric Cooler (TEC) current

• Laser frequency

• Laser temperature

For additional information on VDM (Versatile Diagnostics Monitoring), see the Common Management Interface Specification.

The feature introduces these changes:

CLI:

• The observable-info keyword is added to the show controller optics command.

YANG Data Model:

• New XPath for Cisco-IOS-XR-controller-optics-oper.yang

(see GitHub, YANG Data Models Navigator)

Disable Auto-Squelching

This release introduces support to disable Auto squelching. This helps to detect weak signals that are hidden within the laser source noise. By disabling Auto squelch, you can reduce the processing overhead in systems that have stable laser sources and minimal noise, helping you optimize the performance of your system. When the Auto squelch function is enabled, the optical module will generate a local fault signal on the host side if it detects a fault on the media side. By default, Auto squelch is enabled.

The feature introduces these changes:

CLI:

• host auto-squelch disable

YANG DATA models:

• New XPaths for Cisco-IOS-XR-controller-optics-cfg (see Github, YANG Data Models Navigator)

Loopback on Optical Transceivers

You can now easily detect link failures between the optical transceiver and an external device such as a router by creating a loopback within the transceiver itself. Enabling loopback detects the fault in the physical or network connections, such as, traffic loss or a faulty optical transceiver.

The loopback configuration allows incoming traffic within the transceiver to be redirected back to its source. By analyzing the loopback signals received at the source, it becomes possible to detect physical connectivity failures or network issues, such as packet loss or a malfunctioning transceiver.

The feature introduces these changes:

CLI:

Modified the controller optics command by adding the following keywords:

• host loopback internal

• host loopback line

• loopback internal

• loopback line

The information loopback keyword is added to the show controller optics command.

YANG Data Model:

• New XPaths for Cisco-IOS-XR-controller-optics-cfg.yang

(see GitHub, YANG Data Models Navigator)

Outer IP Header-Driven Hash Computation for Incoming GUE Packets

We now offer you the flexibility of using only the outer IP header to calculate the hashing for incoming Generic UDP Encapsulation (GUE) packets. On enabling this feature, only the outer IP source and destination addresses are used for hashing calculations. The inner IP addresses are not considered, providing a simpler method of distribution. Previously, both inner IP and outer IP headers were used for ECMP hashing the incoming GUE packets.

The feature introduces these changes: 

CLI:

• hw-module profile gue underlay-hash

YANG Data Models:

• New XPaths for Cisco-IOS-XR-npu-hw-profile-cfg.yang (see GitHub, YANG Data Models Navigator)

The command is supported on Q200-based ASICs.

IP Addresses and Services

Unicast VRRP

We have now enabled Layer 3 unicast transport mode in VRRP, allowing it to enhance its capacity to send data to other networks, including cloud networks. Pairwise router redundancy enables high availability in cloud network scenarios. However, a virtual IP (VIP) address is required by the default route of the cloud native function because there is no pre-designated active member in paired routers. HSRP can provide a VIP, but cloud networks do not support Layer 2 multicast or broadcast transports. You can configure VRRP to support Layer 3 unicast transport to overcome the limitation of Layer 2 multicast and broadcast transports.

The feature introduces these changes:

New Command:

CLI:

• unicast-peer

Modified Commands:

• show vrrp command is modified to support new fields: Mcast packet in Ucast mode , IPv4 Unicast Peer , and IPv4 Unicast Peer .

YANG Data Model:

• Cisco-IOS-XR-ipv4-vrrp-cfg.yang

• Cisco-IOS-XR-ipv4-vrrp-oper.yang

  (see GitHub, YANG Data Models Navigator)

MPLS

Auto-enable LDP on all TE Tunnel Interfaces

You can now automatically enable all the configured LDP tunnels over IPv4 traffic-engineering (TE) with upto 2000 unique destinations to achieve time efficiency and consistency of LDP tunnel configurations in routers within an MPLS network.

Earlier, you could enable the LDP tunnels over TE manually.

This feature introduces the following changes:

CLI: mpls ldp address-family ipv4 traffic-eng tunnels command.

YANG Data Model: Cisco-IOS-XR-mpls-ldp-cfg

(see GitHub, YANG Data Models Navigator)

GMPLS User Network Interface (UNI) to Manage Optical Networks

We have improved the dynamic optical transport connection provisioning between IP routers and optical network elements to reduce operational time and administrative overhead needed for new connectivity setup by enabling support for Generalized Multiprotocol Label Switching (GMPLS) User Network Interface (UNI), which enables advanced traffic engineering capabilities.

This feature introduces the following changes:

• CLI

  • New gmpls optical-uni command.

• YANG Data Model

  • New XPaths for Cisco-IOS-XR-um-mpls-te-cfg.yang (see GitHub, YANG Data Models Navigator).

Teardown and Reestablishment of RSVP-TE Tunnels

You can now teardown and reestablish the existing tunnels of headend, midend, or tailend router tunnels of an MPLS network for optimized distribution of the traffic across MPLS and RSVP-TE to improve network performance and enhance resource utilization.

Previously, you could reestablish tunnels only at the headend router using the mpls traffic-eng resetup command.

The feature introduces these changes:

CLI: mpls traffic-eng teardown

YANG Data Model: Cisco-IOS-XR-mpls-te-act.yang

(see GitHub, YANG Data Models Navigator)

EVPN

BUM Ingress Replication for EVPN Single-Homing

You can optimize Broadcast, Unknown Unicast, and Multicast (BUM) traffic by ensuring that traffic that a single-homed device receives is replicated and forwarded to only those CE devices in an EVPN network, if and when they require it. This reduction in the unnecessary forwarding of BUM traffic prevents the flooding of BUM traffic to all devices on the EVPN network.

This feature is supported only on Q200-based line cards.

This feature is enabled by default.

Core Isolation by Interface Tracking for EVPN Single-Homing

You can now monitor the connectivity of the customer-facing interface on the PE router using object tracking (OT). If the interface fails or becomes unavailable, the router isolates the customer site from the rest of the EVPN network. Isolating the core from the network prevents the customer site from advertising its routes to other sites on the EVPN single-home network, ensuring that traffic isn't sent to the failed PE router.

Object tracking involves continuous monitoring of network interfaces, including links or ports on routers. By actively observing the status of these interfaces, administrators can dynamically adjust the network configuration based on their availability and health.

This feature is supported only on Q200-based line cards.

Use Object Tracking commands to track and monitor the connected interfaces.

Detect and Block Duplicate MAC Addresses

You can now effectively mitigate traffic disruptions, packet loss, and potential network outages in your network operations by detecting and freezing duplicate MAC addresses and blocking all associated routes.

This feature is supported only on Q200-based line cards.

The feature introduces the host mac-address duplicate-detection command.

EVPN Core Isolation through Peer Failure Detection

You can now isolate the provider edge (PE) device from the network when there is a core link failure, preventing traffic disruptions and data leakage that could result from a compromised or malfunctioning peer. Upon detecting a link failure, the affected PE device is isolated from the core network, and the EVPN brings down the PE's Ethernet Segment (ES), which is associated with the access interface attached to the customer edge (CE) device.

This feature is supported only on Q200-based line cards.

The feature introduces the core-isolation-group command.

EVPN E-Tree

We now enable efficient forwarding of ethernet traffic in a tree-like topology where a root PE router broadcasts or multicasts traffic to all the leaf PE routers while the leaf PE routers only forward traffic destined for the respective customer sites connected to them.

This feature is supported only on Q200-based line cards.

The feature introduces the etree rt-leaf command.

MAC Mobility for EVPN Single-Homing

Now, it is now possible to seamlessly move MAC addresses between various network devices or locations while preserving their connectivity and associated network services. This ensures uninterrupted communication for devices or virtual machines frequently changing their physical or virtual location within the network. The L2 gateway dynamically updates its forwarding table when a MAC address moves from one device to another within the EVPN E-LAN network, guaranteeing that packets destined for that MAC address are correctly forwarded to its new location.

This feature is supported only on Q200-based line cards.

Seamless Migration of VPLS Network to EVPN Network

You can now provision EVPN service on existing VPLS-enabled PEs individually, thus ensuring a seamless VPLS-to-EVPN migration without traffic disruption.

This feature is supported only on Q200-based line cards.

Split-Horizon Groups for EVPN Single-Homing

You can prevent unnecessary BUM traffic flooding and conserve bandwidth for single-homed EVPN scenarios by ensuring that the traffic isn’t sent back to the CE device from which it originated. Depending on the type of traffic you need to be forwarded or distributed, you can configure split-horizon group 0 (SG 0), SG 1, or SG 2.

This feature is supported only on Q200-based line cards.

The feature introduces the split-horizon group command.

VRF Leaking for EVPN Single-Homing

We now allow for seamless intercommunication between different VRF instances in an EVPN domain, thus enabling controlled inter-VRF communication and resource-sharing, which is helpful in multi-tenancy environments, data center deployments, and hybrid cloud scenarios.

This feature is supported only on Q200-based line cards.

EVPN E-LAN L2 Gateway Single-Homing

We now offer a cost-effective and simplified solution for seamless communication between various customer sites connected to the same service provider network using Ethernet Virtual Private Network (EVPN) single-homing mode. EVPN LAN (E-LAN) is a service to bridge Ethernet data traffic among different sites across the MPLS network connecting a Layer 2 gateway device to a single access network.

In the single-homing mode, a device is connected to one router in the MPLS core through physical ports or bundle ports, and in the event of a failure on those links, the traffic over the links is not protected by links to another router on the core.

This feature is supported only on Q200-based line cards.

The feature introduces the evpn commands.

Segment Routing

Configure Flow Labels in SRv6 Header for PM Liveness

You can now monitor the activeness of multiple paths for a given segment list using flow labels in the SRv6 header.

In earlier releases, the SRv6 header didn't include flow labels.

The feature introduces these changes:

CLI:

• The flow-label keyword is introduced in the performance-measurement liveness-profile command.

YANG Data Models:

• Cisco-IOS-XR-um-performance-measurement-cfg.yang

• Cisco-IOS-XR-perf-meas-oper.yang

See (GitHub, Yang Data Models Navigator)

Configure Segment Lists to Activate Candidate Paths in SRv6 for PM Liveness

You can now enable a candidate path to be up by configuring the minimum number of active segment lists associated with the candidate path. The head-end router determines that a candidate path is up based on the minimum number of active segment lists configured.

In earlier releases, the head-end router identified a candidate path as up only when all the segment lists associated with the path were active.

The feature introduces these changes:

CLI:

• The validation-cp minimum-active segment-lists option is introduced in the performance-measurement liveness-detection command.

YANG Data Models:

• Cisco-IOS-XR-infra-xtc-agent-cfg.yang

See (GitHub, Yang Data Models Navigator)

IS-IS Flexible Algorithm with Exclude Maximum Delay Constraint

This feature enables you to configure topologies that exclude links that have delays over a specific threshold. This is especially critical for high-frequency trading applications, in satellite networks, or wherever there are fluctuations in link delays.

This feature introduces these changes:

CLI:

• The router isis instance flex-algo algo command is modified with the new maximum-delay value option.

YANG Data Model:

• This feature extends the native Cisco-IOS-XR-clns-isis-cfg.yang model (see GitHub, YANG Data Models Navigator)

IS-IS Flexible Algorithm with Exclude Minimum Bandwidth Constraint

Traffic engineering in networks can be optimized by avoiding low-bandwidth links that may not be capable of handling high volumes of traffic.

This feature allows you to use Flexible Algorithm to create topologies in your network that explicitly exclude high bandwidth traffic from utilizing links below a specified capacity. This constraint is achieved by introducing a new bandwidth-based metric type within the Flexible Algorithm framework. Links that do not satisfy the constraint are ignored when computing the associated Flexible Algorithm topology.

This feature introduces these changes:

CLI:

• The router isis instance flex-algo algo command is modified with the new minimum-bandwidth value option.

YANG Data Model:

• This feature extends the native Cisco-IOS-XR-clns-isis-cfg.yang model (see GitHub, YANG Data Models Navigator)

Maximum Paths Per IS-IS Flexible Algorithm Per Prefix

Previously, you could configure a maximum number of Equal-Cost Multi-path (ECMP) to be set for individual Flex Algorithms.

This feature provides additional granularity to the IS-IS Maximum Paths Per-Algorithm feature by allowing you to specify a set of prefixes for Flexible Algorithm.

Now you can achieve a balance between path diversity and computational and memory requirements by controlling the number of paths for each specific algorithm and destination prefix combination.

This feature introduces these changes:

CLI:

• maximum-paths route-policy name

YANG Data Models:

• This feature extends the native Cisco-IOS-XR-clns-isis-cfg.yang model

  See GitHub, Yang Data Models Navigator

Microloop Avoidance for IS-IS with Per-Prefix Filtering

Currently, when SR Microloop Avoidance for IS-IS is enabled, it applies to all prefixes.

This feature allows you to selectively allow or deny specific IPv4 or IPv6 prefixes or routes that may cause microloops, which allows for efficient use of hardware resources and ensures overall network stability.

This feature introduces these changes:

CLI:

• The microloop avoidance segment-routing command is modified with the new route-policy name option for IS-IS.

YANG Data Model:

• This feature extends the native Cisco-IOS-XR-um-router-isis-cfg.yang model (see GitHub, YANG Data Models Navigator)

SR Policy Liveness Monitoring on Segment Routing over IPv6 (SRv6)

In segment routing over IPv6 (SRv6), you can now verify end-to-end traffic forwarding over an SR policy candidate path by periodically sending probe messages. Performance monitoring on an SRv6 network enables you to track and monitor traffic flows at a granular level.

Earlier releases supported SR policy liveness monitoring over an SR policy candidate path on MPLS.

SR-TE Application Programming Interface (API)

This feature introduces an API solution that simplifies the task of building SR-TE controllers and managing SRTE policies. It does so by defining gRPC API services that allow applications to request SR policy operations.

The solution leverages the gRPC Service API and GPB Data models, providing a unified, scalable, and secure method for network programming.

This feature introduces these changes:

New CLI

• grpc segment-routing traffic-eng policy-service

YANG Data Models:

EMSD Yang model is updated to have this config under "segment-routing" container.

• Native model: Cisco-IOS-XR-man-ems-cfg.yang

• UM model: Cisco-IOS-XR-um-grpc-cfg.yang

(see GitHub, YANG Data Models Navigator)

SR-TE: Per Flow Automated Steering

This feature extends the SR-TE automated steering capabilities with per-flow granularity.

Before this feature, per-destination automated steering (AS) dynamically steered all traffic flows destined to a BGP service prefix over a single path of an SR policy.

With this feature, Per-Flow AS dynamically steers traffic flows destined to a BGP service prefix over different paths across the network. Traffic flows are determined based on the attributes of incoming packets (for example, source/destination IP address or QoS markings). Per-flow AS is realized using a Per-Flow SR policy (PFP).

PFPs offer the user the flexibility to deliver the desired transport paths for different traffic flows.

SRv6-Services: L3 Services with Local SIDs from W-LIB

This feature enables an SRv6 headend node to allocate and advertise local SIDs with Wide (32-bit) functions (Local W-LIB).

The headend router utilizes the local W-LIB functionality to define and implement SR policies using SRv6 SIDs.

The Local W-LIB is supported for Layer 3 (VPNv4/VPNv6/BGPv4/BGPv6 global) services.

Support for mixed SR-TE Policy Autoroute paths, unprotected native paths, and protected (LFA/TI-LFA) native paths

When an SR-TE policy is autoroute announced, an IGP route can use it as one of its nexthops, as well as other native paths for load balancing. If protection is configured under IGP, some of these native paths may have LFA or TI-LFA backup paths.

In earlier releases, this mix of SR-TE policy paths and protected native paths wasn't supported. This feature adds support for protected (LFA/TI-LFA) native paths.

This functionality is enabled by default.

Support for uDT46 SRv6 Endpoint Behavior

This feature adds support for the “Endpoint with decapsulation and specific IP table lookup” SRv6 end-point behavior (uDT46).

The End.DT46 behavior is used for dual-stack L3VPNs. This behavior is equivalent to the single per-VRF VPN label (for IPv4 and IPv6) in MPLS.

Two-Way Active Measurement Protocol Light Source Address Filtering

You can now restrict unauthorized users from sending packets to the network and prevent compromising the network security and reliability. For a destination UDP port, you can configure the list of IP addresses that can send Two-Way Active Measurement Protocol (TWAMP)-light packets to responder or querier nodes.

In earlier releases, the responder or querier node accepted TWAMP-light packets from all IP addresses.

The feature introduces these changes:

CLI:

• The querier and responder keywords are introduced in the performance-measurement protocol twamp-light measurement delay command.

YANG Data Models:

• Cisco-IOS-XR-um-performance-measurement-cfg.yang

• Cisco-IOS-XR-perf-meas-oper.yang

See (GitHub, Yang Data Models Navigator)

VRF Allocation Mode for uDT46 Endpoint Behavior

This feature introduces a new VRF allocation mode for uDT46 SIDs for the following BGP-based services:

• IPv4 Layer-3 VPNs

• IPv6 Layer-3 VPNs

• IPv4 BGP global

• IPv6 BGP global

• L3 EVPN

When this allocation mode is configured under an address family, CE-learned routes, redistributed routes, aggregated routes, local routes, and imported routes will use uDT46 SID when advertised to remote peers.

System Management

Ability to Set Maximum Power Limit for the Router

We are introducing functionality to set the maximum power limit for a router to improve power management and distribution in the PSUs. It prevents a router from using more than the configured power and also gives the ability to limit the reservation pool regardless of how many power supplies are present. In the previous releases, the ability to prevent a router from using more than a configured amount of power was unavailable.

This feature introduces the following change:

CLI

• power-mgmt configured-power-capacity

NTP-PTP Interworking

We have improved NTP synchronization and reliability to achieve nanosecond-level accuracy for applications that require high-precision timing. This is achieved by enabling NTP-PTP interworking which allows the use of PTP as the reference clock.

As in previous releases, the NTP client continues to support polling NTP protocol-based external time servers to synchronize the local system clock and achieve accuracy within the millisecond range.

On-demand transfer of Redundant Power Modules to Power Reservation Pool

The Cisco 8800 Series Modular Routers now have a functionality that allows them to transfer their redundant Power Supply Units (PSUs) to the power reservation pool when there is inadequate power supply. This capability helps prevent the router from shutting down hardware components due to a lack of power in the reservation pool, which used to occur due to the router prioritizing redundancy over power availability in the power reservation pool. Consequently, the router now raises an alarm indicating redundancy loss when it transfers PSUs to the power reservation pool. This feature ensures that the router components reserve the necessary power, even when redundancy is enabled.

PTP on 8000-RP2 Route Processor

Based on the IEEE 1588-2008 standard, Precision Time Protocol (PTP) is a protocol that defines a method to synchronize clocks in a network for networked measurement and control system

With this release, support for 1G, 10G PTP ports and BITs are extended to the route processor 8000-RP2

PTP and SyncE on 88-LC0-36FH-M and 8800-LC-36FH

Based on the IEEE 1588-2008 standard, Precision Time Protocol (PTP) is a protocol that defines a method to synchronize clocks in a network for networked measurement and control systems. And, SyncE provides synchronization signals transmitted over the Ethernet physical layer to downstream devices, while the Synchronization Status Message (SSM) indicates the quality level of the transmitting clock to the neighboring nodes, informing the nodes about the level of the network's reliability. Ethernet Synchronization Message Channel (ESMC) is the logical channel that uses an Ethernet PDU (protocol data unit) to exchange SSM information over the SyncE link.

Support for PTP telecom profiles G8273.2 and G8275.1, SyncE and BITs are extended to the following line cards:

• 88-LC0-36FH-M

• 8800-LC-36FH

System Monitoring

System Logging Message Count

Instead of calculating the bytes consumed by Syslog as you did previously, you can now easily and effectively manage the buffer size of the system log messages by specifying the number of entries the system log displays.

The feature introduces these changes:

CLI:

• The entries-count keyword is added to the logging buffered command.

YANG Data Model:

• New Xpaths for Cisco-IOS-XR-infra-syslog-cfg

• New Xpaths for Cisco-IOS-XR-um-logging-cfg

System Security

MACsec Encryption on Layer 3 Subinterfaces

You can now configure MACsec policy on Layer 3 subinterfaces, which gives you the flexibility to apply MACsec policies to different L3 subinterfaces that belong to the same main physical interface. This capability is possible because we've enabled the router to keep the VLAN tags unencrypted, enabling the L3 subinterfaces to be the MACsec endpoints. When you apply MACsec policies on these subinterfaces, you can enhance the overall security of your network by adding an extra layer of security to the communication between different subnets.

This feature is supported on Cisco 8202-32FH-M fixed port routers and 88-LC0-36FH-M line cards.

The feature introduces these changes:

CLI:

• vlan-tags-in-clear

YANG Data Models:

• Cisco-IOS-XR-um-macsec-cfg

• Cisco-IOS-XR-crypto-macsec-mka-cfg

See GitHub, YANG Data Models Navigator

MACsec Policy Exception for Link Layer Discovery Protocol Packets

We have added a MACsec policy exception that ensures improved router identification when MACsec is enabled for Link Layer Discovery Protocol (LLDP) packets. This exception allows you to configure MACsec policies to accommodate Link Layer Discovery Protocol (LLDP) packets to bypass encryption. When LLDP packets are unencrypted, they effectively convey router identification, configuration details, and capabilities to peer devices expediting the router discovery by peer devices in the Local Area Network (LAN). Using this also helps in troubleshooting configuration issues in the network.

Previously, MACsec automatically encrypted LLDP packets, regardless of whether the peer devices applied encryption, resulting in delays when identifying new devices within the LAN.

The feature introduces these changes:

CLI:

• The lldp-in-clear keyword is introduced in the allow command.

• The lldp-in-clear status is displayed in the show macsec policy detail command.

• The lldp-in-clear status is displayed in the show macsec mka interface detail command.

YANG Data Models:

• Cisco-IOS-XR-crypto-macsec-mka-cfg.yang

• Cisco-IOS-XR-crypto-macsec-mka-oper.yang

• Cisco-IOS-XR-um-macsec-cfg.yang

(See GitHub, YANG Data Models Navigator)

Multiple Public Keys per User for Public Key-based Authentication

We provide greater flexibility to access secure routers by allowing four public keys to be used for authentication. With the ability to associate multiple public keys with your user account on the router, we've also simplified the authentication process by eliminating the need to create unique users for each SSH client device.

The feature introduces these changes:

CLI:

• The second , third , and fourth keywords are introduced in the crypto key import authentication rsa command.

• The second , third , and fourth keywords are introduced in the crypto key zeroize authentication rsa command.

• The second , third , and fourth keywords are introduced in the keystring command.

YANG Data Models:

• Cisco-IOS-XR-crypto-act

• Cisco-IOS-XR-um-ssh-cfg

(See GitHub, YANG Data Models Navigator)

Programmability

openconfig-system.yang Version 0.13.1

This OpenConfig data model is revised from version 0.6.0 to 0.13.1. There are no functional changes between these two versions.

openconfig-vlan.yang Version 3.2.2

This OpenConfig data model is revised from version 3.2.0 to 3.2.2. There are no functional changes between these two versions.

openconfig-mpls-static.yang Version 3.3.0

The OpenConfig data model is revised from version 3.2.2 to 3.3.0. There are no functional changes between these two versions.

openconfig-network-instance.yang Version 1.3.0

This OpenConfig data model introduces the following changes to the BGP container:

• Enable the parameters related to the use of multiple paths for the same Network Layer Reachability Information (NLRI) using use-multiple-paths leaf. The router uses this information in Address Family Indicator (AFI) and Subsequent Address Family Indicator (SAFI) in multi-protocol extensions during exchange of neighbor capabilities when loading the peers.

• Enable the route dampening to minimize the propagation of flapping routes across an internetwork and learn the dampened routes from neighbor or peers using route-flap-damping leaf.

• Configure the default metric within the RIB for entries that are installed by the protocol instance using default-metric leaf. The lower the metric specified the more preferable the RIB entry is to be selected for use within the network instance.

• Specify the type of extended community to be sent to the neighbor group or address family group using send-community leaf.

• Specify the number of occurrences to allow the BGP speaker to accept the BGP updates even if its own BGP autonomous system (AS) number is in the AS-Path attribute using allow-own-as leaf.

• Replace occurrences of the peer's AS in the AS_Path with the local AS number using replace-peer-as leaf.

• Use disable-peer-as-filter for filtering the routes. When set to true, the system advertises routes to a peer even if the peer's AS was in the AS-Path. The default behavior (false) suppresses advertisements to peers if their AS number is in the AS-Path of the route.

• Ignore the Interior Gateway Protocol (IGP) metric to the next-hop when calculating the best-path using ignore-next-hop-igp-metric leaf. The default is to select the route for which the metric to the next-hop is lowest.

openconfig-lldp.yang

This OpenConfig data model supports streaming model-driven telemetry (MDT) data for the leaves deviated in the previous releases.

You can stream cadence-driven telemetry data for the following nodes:

• Retrieve the counters cleared and the number number of valid TLVs received using last-clear and tlv-accepted leaves

• Gather data about LLDP interface counters using frame-in, frame-out, frame-error-in, frame-discard, tlv-discard, tlv-unknown, last-clear, and frame-error-out leaves

• Stream operational state data for LLDP neighbors using age and last-update leaves

You can stream event-driven telemetry (EDT) data for system-name, system-description, chassis-id, and chassis-id-type leaves.

openconfig-mpls-igp.yang Version 3.3.0

This OpenConfig data model is revised from version 2.3.0 to 3.3.0. There are no functional changes between these two versions.

openconfig-platform.yang

This OpenConfig data model supports the following enhancements:

• Improved cadence of under 30 seconds to stream cadence-driven telemetry data for the operational state of the following components—power supply, fan, software modules, linecards and subcomponents.

Event-driven telemetry is already supported for these components in the previous releases.

• Introduces cadence-driven telemetry support to obtain the Peripheral Component Interconnect Express (PCIe) error statistics about fatal, non-fatal and correctable errors. This container was deviated in the previous releases.

Event-driven telemetry is not supported for the PCIe container.

openconfig-p4rt.yang Version 0.4.0

This OpenConfig data model introduces augments with the following changes:

• For non-channelized interfaces, references the hardware port corresponding to the base interface using hardware-port leaf

• Defines operational state data for the pluggable optics using transceivers leaf

openconfig-qos.yang Version 0.8.0

This OpenConfig data model is revised from version 0.5.0 to 0.8.0 to support the following enhancements:

• Configure the queue limit using dedicated-buffer leaf

• Configure address and protocol matching conditions in the classifier using source-address, destination-address and protocol leaves for IPv4 and IPv6 address families

• Specify the remark actions to be applied for packets matching the specified classification rules using set-dscp, set-dot1p, and set-mpls-tc leaves

• Configure the hardware to map the named queue to a hardware queue using queue-id leaf

• Configure the single rate, two color policer (1R2C) traffic shaping mechanism to manage and control network traffic based on different levels of priority and traffic behavior using cir, cir-pct, queuing-behavior, max-queue-depth-bytes, max-queue-depth-packets, and max-queue-depth-percent leaves

• Configure the dual-rate, three-color policer (2R3C) traffic shaping mechanism using cir, cir-pct, pir, and pir-pct leaves

• Configure Weighted Random Early Detection (WRED) threshold for queue depth using max-drop-probability-percent leaf

• Retrieve the operational state of input interfaces using transmit-pkts, transmit-octets, dropped-pkts leaves, and dropped-octets leaf for both input and output interfaces

• Retrieve the operational state of schedulers within the applied scheduler-policy using conforming-pkts, conforming-octets, exceeding-pkts, exceeding-octets, violating-pkts, and violating-octets leaves

• Retrieve the operational state of the list of match terms in the classifier associated with the interface using matched-packets and matched-octets leaves

Cisco-IOS-XR-controller-optics-oper.yang

This Cisco native data model is enhanced to display the diagnostics parameters of the optical transceiver.

Cisco-IOS-XR-controller-optics-cfg.yang

The following new leaves are added to this Cisco native data model to enable loopback on the optical modules:

• optics-loopback

• optics-host-loopback

openconfig-mpls-te.yang Version 3.3.0

This OpenConfig data model, which is part of the openconfig-network-instance.yang data model is revised from version 3.0.1 to 3.3.0. There are no functional changes between these two versions.

openconfig-mpls-rsvp.yang Version 4.0.0

This OpenConfig data model, which is part of the openconfig-network-instance.yang data model is revised from version 3.0.2 to 4.0.0. There are no functional changes between these two versions.

openconfig-procmon.yang version 0.4.0

This OpenConfig data model is revised from version 0.3.1 to 0.4.0. It is used to retrieve the operational data for processes running on a node. It is introduced to support the openconfig-system.yang data model to configure the following xpaths:

• Fetch the process related information using the the pid leaf.

• View the process name using the name leaf.

• Fetch the current process command line arguments using args leaf.

• View the time at which the process started using start-time leaf.

• Check the CPU time consumed by the process in user mode using the cpu-usage-user leaf.

• Check the CPU time consumed by this process in kernel mode using cpu-usage-system leaf.

• Check the percentage of CPU that is being used by the process using cpu-utilization leaf.

• Check the bytes allocated and still in use by the process using memory-usage leaf.

• View the percentage of RAM that is being used by a process using memory-utilization leaf.

openconfig-mpls.yang Version 3.3.0

This OpenConfig data model is revised from version 3.2.2 to 3.3.0. It is a part of the openconfig-network-instance.yang data model and introduces the following leaves:

• Enable Time To Live (TTL) propagation in the MPLS domain using the ttl-propagation leaf.

• Enable MPLS forwarding capability on an interface using mpls-enabled leaf.

You can stream model-driven telemetry data (MDT) for the operational state of the nodes.

openconfig-mpls-types.yang Version 3.4.0

This OpenConfig data model, which is part of the openconfig-network-instance.yang data model is revised from version 3.2.0 to 3.4.0. There are no functional changes between these two versions.

Cisco-IOS-XR-mpls-te-act.yang

This Cisco native YANG data model enables you to teardown and re-establish LSP tunnels at head-end, mid-end, and tail-end routers of the MPLS network.

Cisco-IOS-XR-mpls-ldp-cfg

This Cisco native YANG data model lets you to auto-configure all named and numbered tunnels in an MPLS network. It also lets you to provide a regular expression that is auto-enabled if the tunnel name or number matches with the regular expression.

openconfig-network-instance.yang

This OpenConfig data model introduces cadence-driven telemetry support to obtain and monitor the total active route counts on IPv4 or IPv6 default tables in a route processor using installed-routes leaf.

Model-driven telemetry (MDT) sensor subscription can be enabled.

Cisco-IOS-XR-um-performance-measurement-cfg.yang

This unified data model is enhanced as follows:

• New containers allow-querier and allow-responder, to configure the list of IP addresses that can send TWAMP-light packets to responder or querier nodes.

• A new container, flow-label, to monitor the liveness of multiple paths for a given segment list.

Cisco-IOS-XR-perf-meas-oper.yang

This native data model is enhanced as follows:

• New containers, allowed-responder-summary and allowed-querier-summary, to configure the list of IP addresses that can send TWAMP-light packets to responder or querier nodes.

• new container, usid-info, and new leaves such as sid-value, usid-length, sid-format, and sid-behavior in the PM-USID-INFO grouping, to monitor the liveness of a SRv6 candidate path.

Cisco-IOS-XR-infra-xtc-agent-cfg.yang

This native data model is enhanced with a new leaf, minimum-active-segment-lists, to configure the minimum number of active segment lists associated with the candidate path.

Cisco-IOS-XR-npu-hw-profile-cfg

This native data model is enhanced with a new leaf, underlay-hash, to enable GUE underlay hash feature.

Cisco-IOS-XR-crypto-macsec-mka-cfg.yang

This native data model is enhanced with a new node, lldp-in-clear under MACsec policy exceptions xpath Cisco-IOS-XR-crypto-macsec-mka-cfg:/macsec/policy-names/policy-name/allow/, to retain the LLDP packets unencrypted when MACsec encryption is enabled.

Cisco-IOS-XR-um-macsec-cfg.yang

This unified data model is enhanced as follows:

• A new node, lldp-in-clear under MACsec policy exceptions xpath Cisco-IOS-XR-um-macsec-cfg:/macsec-policy/policy-names/policy-name/allow/lldp-in-clear, to retain the LLDP packets unencrypted when MACsec encryption is enabled.

• A new node, vlan-tags-in-clear under xpath Cisco-IOS-XR-um-macsec-cfg:/macsec-policy/policy-names/policy-name/to retain the VLAN tags unencrypted to apply MACsec policies individually to different L3 subinterfaces that belong to the same main physical interface.

Cisco-IOS-XR-crypto-macsec-mka-oper.yang

This unified data model is enhanced as follows:

• A new leaf, lldp-in-clear, to the MKA-EDM-POLICY container to retain the LLDP packets unencrypted when MACsec encryption is enabled.

• A new leaf, vlan-tags-in-clear under xpath Cisco-IOS-XR-crypto-macsec-mka-cfg: /macsec-policy/policy-names/policy-name/ to retain the VLAN tags unencrypted to apply MACsec policies individually to different L3 subinterfaces that belong to the same main physical interface.

Cisco-IOS-XR-crypto-act.yang

This native data model is enhanced with a new leaf, key-num, under the following containers:

key-import-authentication-rsa: To import SSH public keys to the router for the currently logged-in user

key-import-authentication-rsa-username: To import SSH public keys to the router for a specific user

key-zeroize-authentication-rsa: To delete SSH public keys in the router for the currently logged-in user

key-zeroize-authentication-rsa-username: To delete SSH public keys in the router for a specific user

The data model supports the following values for the key-num leaf:

• 2: second key

• 4: third key

• 8: fourth key

Cisco-IOS-XR-um-ssh-cfg.yang

This unified data model is enhanced with the following new leaves under the ssh server username container to add up to 4 multiple public keys per user for public key-based authentication.

keystring-second: Adds a second SSH public key for a user in the router.

keystring-third: Adds a third SSH public key for a user in the router.

keystring-fourth: Adds a fourth SSH public key for a user in the router.

openconfig-aft.yang Revision 0.9.0

The Abstract Forwarding Table (AFT) OpenConfig data model is enhanced to support the following features:

• The gRPC Network Management Interface (gNMI) proto is revised from version 0.7.0 to 0.8.0 to set the atomic flag to send AFT next-hop group notifications in JSON and PROTO encodings using gNMI subscribe RPC. Network events can be represented as multiple updates in the data models. The atomic flag allows NMS to interpret those multiple updates as a single event.

• Stream telemetry data for conditional next-hop groups (CNHG) to provide DSCP information per prefix and list of input interfaces. This model helps to monitor the DSCP-based policy routing configuration at the forwarding layer. It now eliminates multiple lookups to map an IP prefix to an outgoing interface and IP address when internal labels are involved in that route. This is accomplished internally by reducing the hierarchy levels or flattening the nested next-hop telemetry updates.

You can stream Event-driven telemetry (EDT) data.