The Path Computation Element (PCE) Support for MPLS Traffic Engineering Label Switched Paths (MPLS-TE LSPs) feature allows Cisco's SR-PCE to act as a PCE for MPLS-TE LSPs.

For more information, see PCE Support for MPLS-TE LSPs.

The Segment Routing TI-LFA (Topology independent Loop-free alternate) Support for GRE Tunnels feature extends the TI-LFA logic to span different instances or different IGP domains by using a Generic Routing Encapsulation (GRE) tunnel that runs between two ABRs as a backup path for TI-LFA protection in an SR Core. GRE is a tunneling protocol that provides a simple generic approach to transport packets of one protocol over another protocol by means of encapsulation.

For more information, see SR-MPLS over GRE as TI-LFA Backup Path.

With multicast distribution trees, a Bud node is a node that acts as a Leaf (egress) node as well as a midpoint (transit) node toward the downstream subtree.

In this release, the tree computation algorithm on the SR-PCE has been enhanced to detect a Bud node based on knowledge of the Leaf set and to handle Leaf/Transit node transitions to the Bud node.

For information, see Bud Node Support.

This release introduces delay metric as an optimization objective on the SR-PCE in its Tree-SID path computation to minimize a link delay.

For information, see Segment Routing Tree Segment Identifier.

This feature introduces support for SRv6 IS-IS Flexible Algorithm Summarization. SRv6 leverages longest-prefix-match IP forwarding. Massive-scale reachability can be achieved by summarizing locators at ABRs and ASBRs. This feature allows summarizing SRv6 Flexible Algorithm locators at the IS-IS level boundary by the level-1-2 routers.

For more information, see Configuring SRv6 IS-IS Flexible Algorithm.

TCP Message Digest 5 (MD5) authentication is used for authenticating PCEP (TCP) sessions by using clear text or encrypted password. This feature introduces TCP Authentication Option (TCP-AO), which replaces the TCP MD5 option. TCP-AO is compatible with Master Key Tuple (MKT) configuration. TCP-AO also protects connections when using the same MKT across repeated instances of a connection. TCP-AO protects the connections by using traffic key that are derived from the MKT, and then coordinates changes between the endpoints.

For more information, see TCP Authentication Option.

This feature introduces support SRv6 IS-IS Microloop Avoidance with Flexible Algorithm.

Microloop Avoidance paths for a Flexible Algorithm are computed using the same constraints as the calculation of the primary paths for such Flexible Algorithm. These paths use Prefix-SIDs advertised specifically for such Flexible Algorithm in order to enforce a microloop avoidance path.

For more information, see Configuring SRv6 IS-IS Microloop Avoidance.

Performance measurement (PM) measures various link characteristics like packet loss and delay. IS-IS can use such characteristics as a metric for Flexible Algorithm computation. Delay is measured in microseconds. If delay values are taken as measured and used as link metrics during the IS-IS topology computation, some valid ECMP paths might be unused because of the negligible difference in the link delay.

The SR-TE IS-IS Delay Normalization feature takes the delay values of different low-latency links and computes a normalized delay value. The normalized value is advertised and used as a metric during the Flexible Algorithm computation.

For more information, see Delay Normalization.

This release introduces support for manually configured BGP Egress Peer Engineering (EPE) Peer SIDs. The ability to manually configure BGP-EPE peer SIDs allows for persistent EPE label values. Manual BGP-EPE SIDs are advertised through BGP-LS and are allocated from the Segment Routing Local Block (SRLB).

For more information, see Configuring Manual BGP-EPE Peering SIDs.

Currently, DHCPv4 clients do not get an IP address when there is pure IPv6 configured on the core-facing interfaces and a session is established over Segment Routing over IPv6 (SRv6). For IPv6-only environments, DHCPv4 relay agent and proxy are now supported to handle and process new clients and sessions on SRv6 IPv4 L3VPN scenarios.

For more information, see DHCPv4 Relay Agent and Proxy Support for SRv6 IPv4 L3VPN.

Segment Routing On-Demand Next Hop (SR-ODN) allows a service head-end router to automatically instantiate an SR policy to a BGP next-hop when required (on-demand). SR-ODN provides per-destination steering behaviors where a prefix, a set of prefixes, or all prefixes from a service can be associated with a desired underlay SLA. The functionality applies equally to single-domain and multidomain networks.

An on-demand SR policy is created dynamically for BGP global or VPN (service) routes. This release introduces SR-ODN support for EVPN services with either single-homing or multi-homing configurations.

For more information, see On-Demand SR Policy – SR On-Demand Next-Hop.

Segment Routing On-Demand Next Hop (SR-ODN) allows a service head-end router to automatically instantiate an SR policy to a BGP next-hop when required (on-demand). SR-ODN provides per-destination steering behaviors where a prefix, a set of prefixes, or all prefixes from a service can be associated with a desired underlay SLA. The functionality applies equally to single-domain and multi-domain networks.

An on-demand SR policy is created dynamically for BGP global or VPN (service) routes. This release introduces SR-ODN support for EVPN-VPWS services with multi-homing configurations.

For more information, see On-Demand SR Policy – SR On-Demand Next-Hop.

Currently, the steering of traffic through a Segment Routing (SR) policy is based on the candidate paths of that policy. For a given policy, a candidate path specifies the path to be used to steer traffic to the policy’s destination. The policy determines which candidate path to use based on the candidate path’s preference and state. The candidate path that is valid and has the highest preference is used to steer all traffic using the given policy. This type of policy is called a Per-Destination Policy (PDP).

Per-Flow Automated Traffic Steering introduces a way to steer traffic on an SR policy based on the attributes of the incoming packets, called a Per-Flow Policy (PFP). A PFP provides up to 8 "ways" or options to the endpoint. With a PFP, packets are classified by a classification policy and marked using internal tags called forward classes (FCs). The FC setting of the packet selects the “way”. For example, this “way” can be a traffic-engineered SR path, using a low-delay path to the endpoint. The FC is represented as a numeral with a value of 0 to 7.

For more information, see Per-Flow Automated Steering.

Segment routing egress peer engineering (EPE) uses a controller to instruct an ingress provider edge, or a content source (node) within the segment routing domain, to use a specific egress provider edge (node) and a specific external interface to reach a destination. BGP peer SIDs are used to express source-routed interdomain paths. BGP peer SID types include Peer Node SIDs and Peer Adjacency SIDs.

This release adds support for a new type of BGP peering SID, called BGP Peer Set SID. A BGP Peer Set SID is a group or set of BGP peer SIDs, and can be associated with any combination of Peer Node SIDs or Peer Adjacency SIDs. Peer Set SIDs provide load balancing over BGP neighbors (nodes) or links (adjacencies).

For more information, see Segment Routing Egress Peer Engineering.

This feature introduces support for Global Weighted Shared Risk Link Group (SRLG) Protection for OSPF. An SRLG is a set of links sharing a common resource and hence shares the same risk of failure. The current implementation of SRLG protection considers only the directly connected links. Hence, if the router that computes the backup path includes a link that is not directly connected but shares the same SRLG, the SRLG protection fails. The global weighted SRLG protection feature provides better path selection for the SRLG by associating a weight with the SRLG value and using the weights of the SRLG values while computing the backup path.

For more information, see Configuring Global Weighted SRLG Protection.

This feature introduces support for SRv6 Anycast Locator. An SRv6 Anycast locator is a type of locator that identifies a set of nodes (END SIDs). SRv6 Anycast Locators and their associated END SIDs may be provisioned at multiple places in a topology. Anycast routing enables the steering of traffic toward multiple advertising nodes. Packets addressed to an Anycast address are forwarded to the topologically nearest nodes.

One use case is to advertise Anycast END SIDs at exit points from an SRv6 network. Any of the nodes that advertise the common END SID could be used to forward traffic out of the SRv6 portion of the network to the topologically nearest node.

For more information, see Segment Routing over IPv6 Overview.

A Path Computation Element (PCE) computes SR-TE that is paths based on the SR-topology database that stores the connectivity, state, and TE attributes of SR network nodes and links. BGP Labeled Unicast (BGP-LU) provides MPLS transport across IGP boundaries by advertising the loopbacks and label binding of edge and border routers across IGP boundaries.

The SR-PCE Inter-Domain Path Computation Using SID Redistribution feature adds new functionality to the SR-PCE that enables it to compute a path for remote non-SR end-point devices that are distributed by BGP-LU.

For more information, see Inter-Domain Path Computation Using Redistributed SID.

Currently, a Flexible Algorithm definition is unknown to the Segment Routing Path Computation Element (SR-PCE). In order to select a Flexible Algorithm across domains, Flexible Algorithm definition can now be distributed to a PCE topology database from the gateway ABR/ASBR. The SR-PCE Flexible Algorithm Multi-Domain Path Computation feature incorporates the following changes:

• BGP-LS has been augmented to carry a Flexible Algorithm definition (FAD)

• PCEP vendor-specific objects have been added to indicate SR policy Flexible Algorithm constraints to the PCE and to request a path computation based on the Flexible Algorithm number

• PCE algorithms have been augmented to compute paths based on a Flexible Algorithm constraint

For more information, see SR-PCE Flexible Algorithm Multi-Domain Path Computation.

File mirroring feature enables the router to copy files or directories automatically from /harddisk:/mirror location in active RP to /harddisk:/mirror location in standby RP or RSP without user intervention or EEM scripts.

For more information, see Introduction to File Mirroring.

The command, mirror enable is introduced.

WAN-PHY is now supported on 10G MPA cards. WAN-PHY support in Cisco IOS XR software is based on the IEEE 802.3ae standard.

In this release WAN-PHY is only supported on NC55-MPA-12T-S cards and on SFP-10G-LR-X optics.

The purpose of WAN-PHY is to render 10 Gigabit Ethernet compatible with the SONET STS-192c format and data rate, as defined by ANSI, as well as the SDH VC-4-64c container specified by ITU.

For more information, see Configuring WAN-PHY Controllers .

Commands introduced or modified:

• port-mode sonet framing WIS

• show controller OC192

• show controller STS192c

• show controllers

BFD over Bundle with IPv4 Unnumbered Interface feature enables BFD to run on IP unnumbered interfaces, which take the IP address from the loopback address. This feature saves IP addresses space or range. The same loopback address is used on multiple interfaces.

For more information, see BFD over Bundle with IPv4 Unnumbered Interface.

With the introduction of the BFD support on HSRP/VRRP, HSRP/VRRP will use BFD to detect a link failure and facilitate fast failover times without excessive control packet overhead.

With this feature, you can:

• Identify failure detection in less than one second.

• Support all types of encapsulation.

• Have support for almost all routing protocols.

For more information, see:

• Implementing HSRP

• Implementing VRRP

From Release 7.2.1 onwards, you can configure peak burst size for egress shaping. This configuration gives your router interface the ability to manage the traffic burst for a particular traffic class such that the peer node can accommodate the burst and does not drop packets either due to lower burst policing or due to shorter queue depth.

For more information, see Configure Traffic Shaping.

The command, shape average is modified.

Traditional Hierarchical QoS (H-QoS), while allowing for granular and multi-level management of traffic, does not allow for conforming traffic from a child-level policy to a parent-level policy to get priority. This inability means that in case of excess traffic, the parent policer drops conforming traffic packets as well.

With the conform-aware hierarchical policy feature, the parent policer is prevented from dropping any conforming traffic from child policers, thus increasing traffic throughput and efficiency.

For more information, see Conform Aware Hierarchical Policy Overview.

The command, hw-module profile qos conform-aware-policer is introduced.

With the ability to configure an ACL with a fragment match, you now have more granular control over non-initial IP fragments of a packet. You specify the fragments keyword in an ACL and then attach that ACL to specific class maps. When you run this configuration, the ACL applies only to non-initial IP fragments of packets, and enables rate-limiting these packets.

For more information, see Configuring an ACL with Fragment Match.

The command, hw-module profile qos ipv6 short-l2qos-enable is introduced.

With the shared policer feature, you can now share a policer bucket among two or more classes. You can also view the statistics in aggregated mode or per-class mode.

For more information, see Shared Policer.

The command, hw-module profile qos shared-policer-per-class-stats is introduced.

With the introduction of the EVPN convergence improvements for BGP PIC, the following networks are supported, which rides over BGP PIC as transport:

• LxVPN

• EVPN

• 6PE

• 6VPE

For more information, see BGP PIC Implementation Considerations.

With the introduction of the BGP PIC multipath IPv4/IPv6 with interface peering support, BGP control plan installs multiple primary paths and one backup path for all primary paths in the BGP routing table. If one of the primary paths doesn’t work, the system adds a backup into the primary path.

For more information, see BGP PIC Implementation Considerations.

The GPRS Tunneling Protocol (GTP) Load Balancing feature enables efficient distribution of traffic in mobile networks, and provides increased reliability and availability for the network.

GTP load balancing is performed on IPv4 or IPv6 incoming packets with GTP payloads and on MPLS incoming labeled packets. This feature supports GTP hashing only when the GTP UDP port is 2152.

The number of MPLS label stack in the transport layer is limited to three for GTP hashing. GTP hashing is not considered when the MPLS label stack exceeds three.

For more information, see GTP Load Balancing.

The Bridge-group Virtual Interface (BVI) with Double-Tagged AC Support feature allows you to configure the attachment circuit (AC) with double-VLAN tag encapsulation on the BVI. You must specify the rewrite ingress pop 2 symmetric option when you configure the AC on the BVI with double-VLAN tag encapsulation.

For more information, see Configure VLAN Sub-Interfaces.

The Network Convergence using Core Isolation Protection feature allows the router to converge fast when remote links and local interfaces fail. This feature reduces the duration of traffic drop by rapidly rerouting traffic to alternate paths. This feature uses Object Tracking (OT) to detect remote link failure and failure of connected interfaces.

Tracking interfaces can only detect failure of connected interfaces and not failure of a remote router interfaces that provides connectivity to the core. Tracking one or more BGP neighbor sessions along with one or more of the neighbor’s address-families enables you to detect remote link failure.

For more information, see Network Convergence using Core Isolation Protection.

The command, if track is is introduced.

The Support for DHCPv4 and DHCPv6 Client over the BVI feature allows you to configure DHCPv4 and DHCPv6 client on the Bridged Virtual Interface (BVI). You can configure a BVI, and request DHCP IPv4 or IPv6 address on the BVI. This configiration allows your customer’s device to have initial connectivity to your network without any user intervention in the field. After the device is connected to your network, the customer devices can push a node-specific configuration with static IP addresses on a different BVI for a customer deployment.

For more information, see Support for DHCPv4 and DHCPv6 Client over BVI.

This feature allows you to add BUM traffic queueing support for attachment circuits in a bridge domain. BUM traffic is replicated through Ingress Replication, and the replicated packets use the Ingress VOQ. This feature is only supported on single NPU devices, and not on devices with multiple NPUs or line cards.

For more information, see Queueing Support for BUM Traffic on Attachment Circuits.

The command, flood mode ac-ingress-replication is introduced.

You can configure a maximum of 2000 bridge domains. There is an increase in the bridge domain scale from 1500 to 2000. However, there is no change in scale numbers for attachment circuit (AC), pseudowire (PW), and Bridge-group Virtual Interface (BVI).

You can configure BVIs only for 1500 bridge domains out of the 2000 bridge domains. You can configure a maximum of 1500 BVIs with a maximum of one AC per bridge domain. Increasing ACs per bridge reduces BVIs.

The EVPN Automatic Unfreezing of MAC and IP Addresses feature unfreezes the permanently frozen MAC and IP addresses automatically. This feature provides a configurable option to enable a MAC or IP address to undergo infinite duplicate detection and recovery cycles without being frozen permanently. The MAC or IP address is permanently frozen when duplicate detection and recovery events occur three times within a 24-hour window. If any of the duplicate detection events happen outside the 24-hour window, the MAC or IP address undergoes only one duplicate detection event and all previous events are ignored.

Commands introduced for this feature:

• host ipv4-address duplicate-detection

• host ipv6-address duplicate-detection

• host mac-address duplicate-detection

The EVPN E-Tree using Route Target (RT) constraints feature enables you to configure BGP RT import and export policies for an attachment circuit (AC). This feature allows you to define communication between the leaf and root nodes. The provider edge (PE) nodes can receive L2 traffic either from the attachment circuit (AC) of a bridge domain (BD) or from the remote PE node. For a given BD, L2 communication can only happen from a root to leaf and leaf to root nodes. This feature does not allow any L2 communication between the ACs of two or more leafs.

This feature provides the following benefits:

• Achieve efficiency of the BGP MAC routes scale

• Reduce the consumption of hardware resources

• Utilize the link bandwidth efficiently

The command, etree rt-leaf is introduced.

After you configure the PTP profile on a T-BC or a T-TSC, any change in PTP offset from the T-GM clock triggers an immediate reaction in the servo. With the Slow Tracking feature enabled, the servo corrects any change in the phase offset in steps. The correction is based on the configured value which can be slower than the normal correction rate.

For more information, see Slow Tracking.

This release introduces following updates:

• Support for Smart License feature is now available on NC57 line cards.

• The new license that is introduced in this release is:

  • XR-7.2-TRK

  • NCS-55A1-24Q6-TRK

For more information, see Flexible Consumption Model Licensing Usage Pattern.

Previously, by default, 802.1X allowed only one MAC address on each port at a time. This lead to major constraint in current network deployments where multiple hosts or MAC addresses were connected on a single port. Now, multi-auth and multi-host modes are supported by 802.1X to allow multiple hosts or MAC addresses on a single port. By default, dot1x configured port is in multi-auth mode. However, this behaviour can be altered by changing the host mode under dot1x profile. 802.1X port-control is also supported on pre-configured VLAN sub-interfaces along with multi-auth and multi-host modes. For VLAN sub-interfaces with VLAN IDs to be pre-configured, VLAN tagged traffic is allowed only after successful 802.1X authentication of the port.

For more information, see Protect Network using IEEE 802.1X Port-Based Authentication.

The command, dot1x host-mode is introduced.

The Cisco IOS XR Software extends the existing password policy support for the user authentication to all types of user secret. The types of secret include Type 5 (MD5 ), 8 (SHA256 ), 9 (sCrypt ) and 10 (SHA512 ). Prior to this release, the support for a password policy was only for the Type 7 passwords. The new policy is common to both password and secret of the user. Using irreversible hashed-secrets have the benefit that the other modules in the device cannot retrieve the clear-text form of these secrets. Thus, the enhancement provides more secure secrets for the user names. This policy for user secrets is applicable for local and remote users.

The router streams telemetry data at predefined gather points in the data model even if sensor-path configuration is to an individual leaf. The gather points are collection units; collection always happens at that level for operational data.

Starting from release 7.2.1, the router supports the following sensor-path resolutions:

• Streaming data at the leaf-level or at the container-level under a gather point for cadence-based subscriptions.

• For event-driven subscriptions, streaming is always at the gather point in the model, even if specific leaves or leaf is configured as sensor-path.

See Sensor Path.

gRPC Network Management Interface (gNMI) defines 3 modes for a streaming subscription that indicates how the router must return data in a subscription: SAMPLE, ON_CHANGE, and TARGET_DEFINED.

When a client creates a subscription specifying the TARGET_DEFINED mode, the target, here, the router, determine the best type of subscription to be created on a per-leaf basis. If the path specified within the message refers to some leaves which are event-driven, then an ON_CHANGE subscription is created.

In Cisco IOS XR Release 7.2.1, the TARGET_DEFINED subscription mode is supported only for sensor paths of OpenConfig model; native model is not supported. The supported models are: OC Interfaces, OC Telemetry, OC Shell Util, OC System NTP, and OC Platform.

See gRPC Network Management Interface.

The default parameters of a data node can be retrieved using a NETCONF operation that includes the <with-defaults> capability.

This capability indicates which default-handling mode is supported by the server. It also indicates support for additional defaults retrieval modes. These retrieval modes allow a NETCONF client to control whether the server returns the default data.

The <get>, <get-config>, <copy-config> and <edit-config> operations support with-defaults capability. Currently, the <with-defaults> capability is supported only for openconfig-interface.yang data model.

See Retrieve Default Parameters Using with-defaults Capability.

The following enhancements are supported for programmability features:

• New additions to CLI-based data models.

• Export LLDP output via gRPC.

• Support to display the label information about the software version for the oc-platform data model.

• gNOI supports for the following new remote procedure calls (RPCs):

  • Interface

    • SetLoopbackMode

    • GetLoopbackMode

    • ClearInterfaceCounters

  • Layer2

    • ClearLLDPInterface

  • BGP

    • ClearBGPNeighbor

For more information, see New and Changed Feature Information.

With the introduction of egress interface published as part of ingress NetFlow, you can capture traffic flow for IP packets on the egress interface or on the outgoing interface of a router.

For more information, see IPFIX 315 Implementation Considerations.

This feature provides IPv6 protocol support in MPLS LDP. Most of the LDPv4 functions are extended to LDPv6. The LDP control plane can run IPv6 to setup LSPs for IPv6 prefixes.

For more information, see Configuring LDPv6.

With this feature, you can lperform oad-balance for incoming traffic over multiple paths of varying costs. UCMP applies a weight to a path, and adds more forwarding instances to a path that has a higher weight (or larger bandwidth). This feature results in an equal load distribution over paths of varying bandwidths (and costs).

For more information, see UCMP Over MPLS-TE.

You must follow these guidelines while enabling FIPS mode:

• You must configure the session with a FIPS-approved cryptographic algorithm. A session configured with non-approved cryptographic algorithm for FIPS (such as, MD5 and HMAC-MD5) does not work. This is applicable for OSPF, BGP, RSVP, ISIS, or any application using key chain with non-approved cryptographic algorithm, and only for FIPS mode (that is, when crypto fips-mode command is configured).

• If you are using any HMAC-SHA algorithm for a session, then you must ensure that the configured key-string has a minimum length of 14 characters. Otherwise, the session goes down. This is applicable only for FIPS mode.

• If you try to execute the telnet configuration on a system where the FIPS mode is already enabled, then the system rejects the telnet configuration.

• If telnet configuration already exists on the system, and if FIPS mode is enabled later, then the system rejects the telnet connection. But, it does not affect the telnet configuration as such.

• It is recommended to configure the crypto fips-mode command first, followed by the FIPS-related commands in a separate commit. The list of commands related to FIPS with non-approved cryptographic algorithms are:

  • key chain key-chain-name key key-id cryptographic-algorithm MD5

  • key chain key-chain-name key key-id cryptographic-algorithm HMAC-MD5

  • router ospfv3 1 authentication ipsec spi 256 md5 md5-value

  • router ospfv3 1 encryption ipsec spi 256 esp des des-value

  • router ospfv3 1 encryption ipsec spi 256 esp des des-value authentication md5 md5-value

  • snmp-server user username usergroup-name v3 auth md5 priv des56

  • ssh server algorithms key-exchange diffie-hellman-group1-sha1

  • telnet vrf default ipv4 server max-servers server-limit

You must follow this guideline while configuring MACsec:

• The MACsec key IDs (configured through CLI using the macsec key command under the key chain configuration mode) are considered to be case insensitive. These key IDs are stored as uppercase letters. Whereas, prior to this release, the key IDs were treated as case sensitive. These key IDs are now stored as uppercase letters. Whereas, prior to this release, the key IDs were treated as case sensitive. Hence, two key IDs with the same value, but of different case (one in uppercase and other in lowercase) were treated as two separate IDs in previous releases. However, the support for this case insensitive IDs is applicable only for the configurations done through CLI, and not for configurations done through Netconf protocol. Hence it is recommended to have unique strings as key IDs for a MACsec key chain to avoid flapping of MACsec sessions.

  For more information, see Guidelines for Configuring MACsec Keychain.