Programmability

Replace Router Configuration at Sub-tree Level Using gNMI

Using the gNMI SetRequest message, you can replace the router's existing configuration with a new set of configurations at the subtree level within the same model. Earlier you could replace router configurations at the data tree root level.

To view the specification of gNMI replace, see Github repository.

gNMI Bundling Size Enhancement

With gRPC Network Management Interface (gNMI) bundling, the router internally bundles multiple gNMI Update messages meant for the same client into a single gNMI Notification message and sends it to the client over the interface.

You can now optimize the interface bandwidth utilization by accommodating more gNMI updates in a single notification message to the client. We have now increased the gNMI bundling size from 32768 to 65536 bytes, and enabled gNMI bundling size configuration through Cisco native data model.

Prior releases allowed only a maximum bundling size of 32768 bytes, and you could configure only through CLI.

The feature introduces new XPaths to the Cisco-IOS-XR-telemetry-model-driven-cfg.yang Cisco native data model to configure gNMI bundling size.

To view the specification of gNMI bundling, see Github repository.

gNOI System Service Revision 1.0.0

With the gRPC Network Operations Interface (gNOI) Revision 1.0.0, you can:

• Cancel a pending reboot request using the CancelReboot RPC

• Terminate a process using the KillProcess RPC

You can access the gNOI system RPC messages from the Github repository.

IP Addresses and Services

Filter Ingress IPv6 ACL Traffic based on ACL Hop Limit

We ensure that IPv6 packets have a limited lifetime on your networks, thus reducing the impact of any routing loops and preventing networking failures. To that end, we have added the option to set hop limit rules in the ACLs based on the following hop limit match criteria:

• eq - equal to

• lt - less than

• gt - greater than

• range - ranges from 1 to 255

To set the hop limit, use the ttl keyword in the following commands:

• deny (IPv6)

• permit (IPv6)

Enable Ingress Interface Logging on IPv4 and IPv6 ACLs

Using the log-input keyword, you can now enable Access Control Lists (ACLs) to generate log messages that help you identify the interface through which a particular traffic stream ingresses the routers. This information aids in optimizing traffic flow across the network. There was no option to enablelogging of ingress interfaces with an ACL in earlier releases. This feature introduces an optional keyword log-input for the following commands:

• deny (IPv4)

• deny (IPv6)

• permit (IPv4)

• permit (IPv6)

L2VPN

Ethernet VPN Virtual Private Wire Service

The Ethernet VPN Virtual Private Wire Service (EVPN-VPWS) is a BGP control plane solution for point-to-point services. It implements the signaling and encapsulation techniques for establishing an EVPN instance between a pair of PEs. It provides the service of forwarding L2 Ethernet traffic between network devices without inspecting the MAC header in the Ethernet frame.

The use of EVPN for VPWS eliminates the need for signaling single-segment and multi-segment pseudowire (PW) for point-to-point Ethernet services.

EVPN Seamless Integration with Legacy VPWS

When expanding an existing L2VPN network, users may want to deploy EVPN-VPWS to provide additional Layer 2 point-to-point Ethernet services, and at the same time some of their customer traffic may still need to be terminated on the existing L2VPN PEs on their network.

Users can migrate the PE nodes from L2VPN VPWS to EVPN-VPWS, without disruption in traffic. The seamless migration offers users the option to use either VPWS or EVPN-VPWS services on PE nodes. This allows the coexistence of legacy VPWS and EVPN-VPWS dual-stack in the core for a given L2 Attachment Circuit (AC) over the same MPLS network.

This feature introduces the vpws-seamless-integration  command.

Segment Routing

Circuit-Style SR-TE Policies

This solution allows Segment Routing to meet the requirements of a connection-oriented transport network, which was historically delivered over circuit-switched SONET/SDH networks.

Circuit-style SR-TE policies allow a common network infrastructure to be used for both connection-oriented services and classic IP-based transport. This eliminates the need for multiple parallel networks, which greatly reduces both capital expenditures (CapEx) and operating expenditures (OpEx).

Dual-Stack L3VPN Services (IPv4, IPv6) (SRv6 Micro-SID)

This feature introduces support for Dual-stack (VPNv4/VPNv6) VRFs.

VPNv4/VPNv6 Dual-stack supports both IPv4 (uDT4) and IPv6 (uDT6) based SRv6 L3VPN service on the same interface, sub-interface, or VRF.

Dual stacking allows operators to access both IPv4 and IPv6 simultaneously and independent of each other. It avoids the need to translate between two protocol stacks. This results in high processing efficiency and zero information loss.

IS-IS Enhancements: max-metric and data plane updates

The new anomaly optional keyword is introduced to affinity flex-algo command. This keyword helps to advertise the flex-algo affinity when the performance measurement signals a link anomaly, such as an excessive delay on a link. You could use the anomaly option to exclude the link from flex-algo path computations.

affinity flex-algo

Multicast VPN: Tree-SID MVPN

With this feature, you can use SR and MVPN for optimally transporting IP VPN multicast traffic over the SP network, using SR-PCE as a controller.

With SR’s minimal source router configuration requirement, its ability to implement policies with specific optimization objectives and constraints and use SR-PCE to dynamically generate optimal multicast trees (including when topology changes occur in the multicast tree), the SR-enabled SP network can transport IP multicast traffic efficiently.

Path Tracing Midpoint Node

Path Tracing (PT) provides a log or record of the packet path as a sequence of interface IDs along with its time stamp. In Path Tracing, a node can behave as a source, midpoint, or sink node.

The Path Tracing Midpoint feature is implemented in this release which measures the hop-by-hop delay, traces the path in the network and collects egress interface load information and interface Id, and stores them in the Midpoint Compressed Data (MCD) section of Hop-by-Hop Path Tracing (HbH-PT) header.

This feature provides visibility to the Path Tracing Midpoint node that handles IPv6 transit in Path Tracing and full characterization of the packet delivery path. It provides real time information and the current status of the network.

This feature introduces the following command:

• performance-measurement interface

Per-Prefix SRv6 Locator Assignment

This feature allows you to assign a specific SRv6 locator for a given prefix or a set of prefixes (IPv4/IPv6 GRT, IPv4/IPv6 VPN).

The egress PE advertises the prefix with the specified locator. This allows for per-prefix steering into desired transport behaviors, such as Flex Algo.

SRv6 Services: BGP Global IPv6

With this feature, the egress PE can signal an SRv6 Service SID with the BGP global route. The ingress PE encapsulates the IPv4/IPv6 payload in an outer IPv6 header where the destination address is the SRv6 Service SID provided by the egress PE. BGP messages between PEs carry SRv6 Service SIDs to interconnect PEs.

SRv6 Services: IPv6 L3VPN

With this feature, the egress PE can signal an SRv6 Service SID with the BGP overlay service route. The ingress PE encapsulates the IPv4/IPv6 payload in an outer IPv6 header where the destination address is the SRv6 Service SID provided by the egress PE. BGP messages between PEs carry SRv6 Service SIDs to interconnect PEs and form VPNs.

SRv6 VPN BGP Route Leaking

This feature supports SRv6 VPN Route-leaking between Global Routing Table (GRT) and Virtual Routing and Forwarding (VRF). This enables Enterprise IPv4 internet connectivity.

SRv6/MPLS Dual-Connected PE (SRv6 Micro SID)

This feature allows a PE router to support IPv4 L3VPN services for a given VRF with both MPLS and SRv6. This is MPLS and SRv6 L3VPNv4 co-existence scenario and is sometimes referred to as dual-connected PE.

SRv6/MPLS L3 Service Interworking Gateway (SRv6 Micro-SID)

This feature enables you to extend L3 services between MPLS and SRv6 domains by providing service continuity on the control plane and data plane.

This feature allows for SRv6 L3VPN domains to interwork with existing MPLS L3VPN domains. The feature also allows migration from MPLS L3VPN to SRv6 L3VPN.

Support for iBGP as PE-CE protocol

This feature introduces support for iBGP as PE-CE protocol.

System Management

Smart Licensing on 8111-32EH and 8201-24H8FH

Cisco Smart Licensing is a cloud-based, flexible, automated software licensing model that enables you to activate and manage Cisco software licenses across your organization. Smart Licensing solution allows you to easily track the status of your license and software usage trends.

Smart Licensing is now supported on the following chassis:

• 8111-32EH

• 8201-24H8FH

Smart Licensing Per Port for Segment Routing-Traffic Engineering

Cisco Smart Licensing is a cloud-based, flexible software licensing model that enables you to activate and manage Cisco software licenses across your organization. Under the flexible, automated software licensing model, we have Advantage licenses which are required on top of Essential Licenses for ports that use advanced features like L3VPN.

This release allows you to allocate the Advantage licenses to the Segment Routing Traffic Engineering (SR-TE) based on the active ports under MPLS or SRV6. Before this release, when you configured SR-TE, all the ports used to consume Advantage licenses. This allows you to manage advantage licenses for SR-TE.

System Security

Secure Boot Status

You can now verify whether the router is securely booted up with an authentic Cisco software image. We have introduced a show command to verify the secure boot status of the router. If the software image was tampered with, then the secure boot fails, and the router does not boot up. Before this release, there was no provision on the router to verify the secure boot status.

The feature introduces these:

• CLI: show platform security integrity log secure-boot status command.

• YANG Data Model: Cisco-IOS-XR-attestation-agent-oper.yang Cisco native model (see GitHub)

Selective Authentication Methods for SSH Server

You now have the flexibility to choose the preferred SSH server authentication methods on the router. These methods include password authentication, keyboard-interactive authentication, and public-key authentication. This feature allows you to selectively disable these authentication methods. By allowing the SSH clients to connect to the server only through these permitted authentication methods, this functionality brings in additional security for router access through SSH. Before this release, by default, the SSH server allowed all these authentication methods for establishing SSH connections.

The feature introduces these changes:

• CLI: New disable auth-methods command

• YANG Data Model: New XPaths for Cisco-IOS-XR-crypto-ssh-cfg.yang Cisco native model (see GitHub)

Cisco MASA Service for IOS XR

Cisco’s Manufacturer Authorized Signing Authority (MASA) service is used to create ownership vouchers and owner certificates (OVs and OCs) for a Cisco IOS XR router. These OVs and OCs certify that the device belongs to a given customer.

Use cases where OVs and OCs are required include secure ZTP workflows, and to securely boot up your device on a 5G cell site over a third party ethernet service.

You can use the MASA service to download, view logs, and audit ownership vouchers for the routers you own.

This service also enables Cisco’s Account teams to assign serial number of a device to customers and view details of the logging, verification, and audit of OVs.

Multicast

LSM mLDP based MVPN support on edge routers

Label Switch Multicast (LSM) is MPLS technology extensions to support multicast using label encapsulation. Next-generation MVPN is based on Multicast Label Distribution Protocol (mLDP), which can be used to build P2MP and MP2MP LSPs through a MPLS network. These LSPs can be used for transporting both IPv4 and IPv6 multicast packets, either in the global table or VPN context.

From this release, mLDP is supported on edge routers on profiles 1,2,4,5,6,7,9,12,13,14,17,19,21,23, and 25.

Software Installation

Error messages with clear actions

The following command descriptions and outputs have been updated for clarity and better user responses:

• show install request

• show install history last package

• show install history id 2.1.2 errors

Setup and Upgrade

Optimized PSU FPD Upgrade

We have optimized the upgrade process of Field-Programmable Devices (FPDs) associated with the Power Supply Unit (PSUs) on the router. During the installation and PSU insertion process on the router, the FPDs associated with the PSUs are automatically upgraded. Starting this release, the PSU FPDs are grouped in the form of a parent FPD and its related child FPDs, and the upgrade image is downloaded only once. The upgrade is then triggered on the parent FPD PSU and replicated to the child FPD PSUs.

In earlier releases, you downloaded the FPD image for each FPD associated with that PSU, and the upgrade process was then triggered sequentially. This process was time-consuming.

The feature is supported on the following PSUs:

• PSU2KW-ACPI

• PSU2KW-HVPI

• PSU3KW-HVPI

• PSU4.8KW-DC100

Cisco IOS XRv 9000 Router Installation and Configuration Guide

gNMI Bundling of Telemetry Updates

gNMI (gRPC Network Management Interface) bundles multiple messages of a same client into a single message and sends to the client over the interface to optimize the interface bandwidth utilization.

You can configure gNMI bundle size up to 65,535 bytes using Cisco IOS XR native model Cisco-IOS-XR-telemetry-model-driven-cfg.yang to optimize the interface bandwidth utilization.

You can view the telemetry updates of gNMI bundling from the Github repository.

Programmability

Cisco-IOS-XR-attestation-agent-oper.yang

We have introduced this Cisco native data model to verify whether the router is securely booted up with an authentic Cisco software image.

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

We have introduced the following Xpaths to this Cisco native data model for you to selectively disable the SSH server authentication methods on the router:

• /ssh/server/disable/AuthMethods/Password

• /ssh/server/disable/AuthMethods/KeyboardInteractive

• /ssh/server/disable/AuthMethods/PublicKey

openconfig-network-instance.yang Revision 0.15.0

The OpenConfig data model is revised from version 0.6.0 to 0.15.0 and supports the following XPaths to configure and retrieve the Layer 3 forwarding constructs, Layer 2 instances, static routes, forwarding instances, Border Gateway Protocol (BGP) parameters and so on:

openconfig-network-instance/network-instances/network-instance[name]/

• config

• state

• tables

• protocols

You can stream Event-driven and Model-driven telemetry data for the operational state of the network instance.

openconfig-routing-policy.yang Revision 3.2.2

The OpenConfig data model, which is part of the openconfig-network-instance.yang data model is revised from version 1.0.1 to 1.2.0. This revision introduces support to configure and retrieve the operational state data for static routes using the following XPaths:

openconfig-network-instance/network-instances/network-instance[name]/

• config/enabled

• protocols/[identifier-name]/static-routes/static/config/description

• protocols/[identifier-name]/static-routes/static/state/description

You can stream Event-driven and Model-driven telemetry data for the operational state of the static routes.

Openconfig-alarms.yang Revision 0.3.2

The OpenConfig data model, part of the openconfig-system.yang data model. The model is revised from 0.3.0 to 0.3.2 to enhance the time the system raises the alarm. This value is expressed relative to the UNIX epoch time.

Using this XPath, you can stream Event-driven and Model-driven telemetry data.

openconfig-if-ethernet.yang Revision 2.12.1

The OpenConfig data model is revised from version 2.8.1 to 2.12.1 to support the following sensor paths to manage the Forward Error Correction (FEC) configuration and state of Ethernet interfaces:

Configuration Xpath:

openconfig-interfaces:interfaces/interface[name="interface-name"]/ openconfig-if-ethernet:ethernet/config/fec-mode

State XPaths supported on half-duplex interfaces:

openconfig-interfaces:interfaces/interface[name="interface-name"]/ openconfig-if-ethernet:ethernet/state/

• in-carrier-errors

• in-interrupted-tx

• in-late-collision

• in-single-collision

State XPaths supported on half-duplex and full-duplex interfaces:

openconfig-interfaces:interfaces/interface[name="interface-name"]/ openconfig-if-ethernet:ethernet/state/

• in-mac-errors-rx

• in-symbol-error

• out-mac-errors-tx

• in-maxsize-exceeded

You can stream Model-driven telemetry data for the operational state of the Ethernet interfaces.

openconfig-interfaces.yang Revision 2.5.0

The OpenConfig data model is revised from version 2.4.3 to 2.5.0. This version introduces support to configure the interface to connect the system to an out-of-band management network and enable the system CPU to handle traffic using the following XPaths:

openconfig-interfaces/interfaces/interface[name]/state/

• state/management

• State/cpu

• subinterfaces/subinterface[index]/state/management

• subinterfaces/subinterface[index]/state/cpu

You can stream Event-driven and Model-driven telemetry data for the operational state of the interface.

openconfig-system-terminal.yang Revision 0.3.1

The OpenConfig data model is revised from version 0.3.0 to 0.3.1. This version introduces the following config XPaths to configure the IPv4 or IPv6 telnet server and the number of telnet sessions that are active simultaneously, and state sensor paths to view that the configuration is enabled:

IPv4: openconfig-system/system/telnet-server/

oc-term-ext:ipv4/oc-term-ext:vrf[vrf-name]/

oc-term-ext:state/oc-term-ext:enable

oc-term-ext:config/oc-term-ext:session-limit

oc-term-ext:state/oc-term-ext:session-limit

IPv6: openconfig-system/system/telnet-server/

oc-term-ext:ipv6/oc-term-ext:vrf[vrf-name]/

oc-term-ext:state/oc-term-ext:enable

oc-term-ext:config/oc-term-ext:session-limit

oc-term-ext:state/oc-term-ext:session-limit

With this release, an extended model Cisco-IOS-XR-openconfig-system-terminal-ext.yang is introduced to manage the telnet server configuration.

You can stream Event-driven and Model-driven telemetry data for the operational state of the system.

openconfig-system.yang Revision 0.7.0

The OpenConfig data model is revised from version 0.6.0 to 0.7.0. This version introduces support to view the statistics of CPU utilization of a component, create a customized banner that is displayed before the username and password login prompt and view the operational state of the system memory using the following XPaths:

openconfig-system:system/

• cpus

• memory/state

• current-datetime

  • boot-time

  • config/login-banner

  • config/motd-banner

Event-driven telemetry is not supported for openconfig-system:/system/cpusXPath. For the other sensor paths, you can stream Event-driven and Model-driven telemetry data for the operational state of the system.

openconfig-lacp.yang Revision 1.2.0

The OpenConfig data model is revised from version 1.1.0 to 1.2.0 and introduces the following XPaths to monitor the Link Aggregation Control Protocol (LACP) aggregate interface timeouts and the time since the last timeout:

lacp/interfaces/interface[name]/members/member[interface]/state/:

• last-change

• counters/lacp-timeout-transitions

You can stream Event-driven telemetry data for the time since the last change of a timeout and Model-driven telemetry data for the number of times the state has transitioned with a timeout. The state change is monitored since the device restarted or the interface was brought up, whichever is most recent.

openconfig-sampling-sflow Revision 0.1.0

The OpenConfig data model revision 0.1.0 supports the following XPaths to configure the parameters such as sampling rate, sampling size, the source address of the router, collector port number, IPv4 or IPv6 addresses, and network-instance (VRF) to monitor real-time traffic in data networks using a sampling mechanism in the sFlow agent.

openconfig-sampling-sflow:sampling/sflow

• config/enabled

• config/source-address

• config/sampling-size

• config/sampling-rate

• state/enabled

• state/source-address

• state/sampling-size

• state/sampling-rate

• collectors/collector[address,port]/address

• collectors/collector[address,port]/port

• collectors/collector[address,port]/config/address

• collectors/collector[address,port]/config/port

• collectors/collector[address,port]/config/network-instance

• collectors/collector[address,port]/state/address

• collectors/collector[address,port]/state/port

• collectors/collector[address,port]/state/network-instance

• interfaces/interface[name]/name

• interfaces/interface[name]/config/name

• interfaces/interface[name]/config/enabled

• interfaces/interface[name]/config/sampling-rate

• interfaces/interface[name]/state/name

• interfaces/interface[name]/state/enabled

• interfaces/interface[name]/state/sampling-rate

This release introduces source-address command.

openconfig-aft.yang Revision 0.6.0

The OpenConfig data model is revised from version 0.3.0 to 0.6.0. The revised version introduces the support for NMS to receive essential interface characteristics, such as next-hop and next-hop group using the following XPaths to simplify the forwarding process:

openconfig-network-instance/network-instances/network-instance/afts/

• next-hop-groups/next-hop-group/

• next-hops/next-hop

To view the operational data of the system, you can stream Event-driven and Model-driven telemetry data.

openconfig-qos.yang

Revision 0.5.0

The OpenConfig data model version 0.5.0 supports the following XPaths to avoid network congestion using queuing mechanism in the router.

openconfig-qos/qos

• config

• state

• interfaces/interface/interface-id

• interfaces/interface/config/interface-id

• interfaces/input/config

• interfaces/input/state

• interfaces/input/classifiers/classifier [type]/type

• interfaces/input/classifiers/classifier [type]/config/name

• interfaces/input/classifiers/classifier [type]/config/type

• interfaces/input/classifiers/classifier [type]/state/name

• interfaces/input/classifiers/classifier [type]/state/type

• interfaces/input/classifiers/classifier [type]/terms/term/id

• interfaces/input/classifiers/classifier [type]/terms/term[id]/state/id

• Interfaces/input/classifiers/classifier [type]/terms/term[id]/state/matched-packets

• Interfaces/input/classifiers/classifier [type]/terms/term[id]/state/matched-octets

• interfaces/output/config

• interfaces/output/state

• interfaces/output/ interface-ref/config/interface

• interfaces/output/ interface-ref/config/subinterface

• interfaces/output/ interface-ref/classifiers/classifier[type]/type

• interfaces/output/

• interface-ref/classifiers/classifier[type]/config/name

• interfaces/output/ interface-ref/classifiers/classifier[type]/config/type

• interfaces/output/queues/queue[name]/name

• interfaces/output/queues/queue[name]/config/name

• interfaces/output/queues/queue[name]/state/name

• interfaces/output/queues/queue[name]/state/ transmit-pkts

• interfaces/output/queues/queue[name]/state/ transmit-octets

• interfaces/output/queues/queue[name]/state/dropped-pkts

• classifiers/classifier[name]/name

• classifiers/classifier[name]/config/name

• classifiers/classifier[name]/config/type

• classifiers/classifier[name]/state/name

• classifiers/classifier[name]/state/type

• classifiers/classifier[name]/terms/term/id

• classifiers/classifier[name]/terms/term/config/id

• classifiers/classifier[name]/terms/term/state//id

• classifiers/classifier[name]/terms/term/conditions/l2

• classifiers/classifier[name]/terms/term/conditions/ipv4

• classifiers/classifier[name]/terms/term/conditions/ipv6

• classifiers/classifier[name]/terms/term/conditions/transport

• classifiers/classifier[name]/terms/term/conditions/mpls

• classifiers/classifier[name]/terms/term/actions/config/target-group

• classifiers/classifier[name]/terms/term/actions/remark

• forwarding-groups/forwarding-group[name]/name

• forwarding-groups/forwarding-group[name]/config/name

• forwarding-groups/forwarding-group[name]/config/output-queue

• queues/queue[name]/name

• queues/queue[name]/config/name

You can stream Model-driven telemetry data of state containers of classifiers and queues.

In this release, the following guidelines and limitations apply to this QoS data model:

• The data model supports:

  • IPv4, IPv6, and MPLS policy types

  • Classifier policy for ingress traffic and scheduler policy for egress traffic

  • Statistics per classifier policy type

  • Priority scheduler. Priority value ranges 1–8. Value 1 corresponds to priority 7 and traffic-class 1, Value 2 corresponds to priority 6 and traffic class 2, and so on.

  • Configuration of identical scheduler policy queue name as that of scheduler Input-Id name

  • Configuration of identical service-policy name for each policy-type on an interface. When a configured policy is removed from an interface, all policy-map types must be deleted from that interface.

• The data model does not support:

  • Egress remark policy

  • Source and destination address match for IPv4 and IPv6

  • Modification of policy-map. If you try to modify the policy-map, the router does not reject the modifications, but it might result in an unpredicted behavior.

openconfig-policy-forwarding.yang Version 0.4.0

The OpenConfig data model configures the actions to be performed on inbound traffic when a packet matches the conditions defined in the policy-map. The match criteria are based on IPv4 or IPv6 Differentiated Services Code Point (DSCP) and IP-in-IP (IPnIP) protocol for IPv4 address family.

The following

openconfig-network-instance/network-instances/network-instance[name]/policy-forwarding

XPaths are supported:

• /policies/policy[policy-id]

• /policies/policy[policy-id]/config/type

• /policies/policy[policy-id]/rules/rule[sequence-id]

• /policies/policy[policy-id]/rules/rule[sequence-id]/sequence-id

• /policies/policy[policy-id]/rules/rule[sequence-id]/l2/config/ethertype

• /policies/policy[policy-id]/rules/rule[sequence-id]/ipv4/config/dscp-set

• /policies/policy[policy-id]/rules/rule[sequence-id]/ipv4/config/protocol

• /policies/policy[policy-id]/rules/rule[sequence-id]/ipv6/config/dscp-set

• /interfaces/interface[interface-id]

• /interfaces/interface[interface-id]/config/apply-vrf-selection-policy

• /policies/policy[policy-id]/rules/rule[sequence-id]/action/config/network-instance

The following limitations apply when configuring the routing policy using the data model:

• The data model supports only the default VRF for policy configuration.

• A class map and Ether type match in the OC data model is supported on IPv4 or IPv6 address family. Whereas the protocol match in OC data model for the IPv4 address family is supported only on IP-in-IP protocol.

• One policy type of policy-based routing (PBR) is supported per interface. VRF, global policy and PBR interface policies are not supported on the same interface.

• A policy map configured through the data model cannot be modified using the CLI command. Although the modification is accepted, it may lead to an unpredictable outcome.

• Configuration changes made using the OpenConfig model can be retrieved only through the NETCONF get-config operation. Retrieving the configuration using specific show command is not supported.

• OpenConfig statistics for policy-forwarding is not supported.

• Configuring the PBR ACL with existing DSCP values on the L3 port results in a momentary traffic outage upon interface switch-over.

• Configuring PBR ACL is supported only on Cisco Silicon One Q200-based cards.