CEM

Frame Relay Port Mode

Frame Relay (FR) port mode provides transport between two Provider Edge (PE) devices, where the complete FR frame is transported using the same encapsulation configured for the HDLC or FR pseudowire. On the PE device, the multiple FR Virtual Circuits (VCs) are carried over a single interface and the traffic is passed into a single transparent HDLC or FR pseudowire in an MPLS network. Thus with port mode, there are many-to-one mappings between multiple FR VCs and a pseudowire in a secure manner.

You can configure HDLC or FR port mode on the following interface modules:

• 1 port OC-48/STM-16 or 4 port OC-12/OC-3 / STM-1/STM-4 + 12 port T1/E1 + 4 port T3/E3 CEM Interface Module

Support for 3-in-24 BERT Patterns

• 48-port T1 or E1 interface module

• 1-Port OC-48 or 4-Port OC-12/OC-3 interface module

System CESoP NxDS0 BERT

You can configure BERT patterns at the DS0 level on the following interface modules for both the system and line directions.

• 48-Port T1 or E1 CEM interface module

• 48-Port T3 or E3 CEM interface module

• 1-port OC-48/STM-16 or 4-port OC-12/OC-3 / STM-1/STM-4 + 12-port T1/E1 + 4-port T3/E3 CEM interface module

You can configure speed with bandwidth of 56 kbps or 64 kbps along with the BERT pattern.

With DS0 level BERT configuration, you can verify the end-to-end connectivity.

Layer 3 Termination for Frame Relay

You can configure layer 3 termination on the Frame Relay (FR) and Multilink Frame Relay (MFR) sub interfaces for the following interface modules:

• NCS4202-SA equipped with NCS4200-3GMS

You can assign IP address on the FR or MFR sub interface and terminate the Layer 3 traffic where ever required in the network.

Timing and Synchronization

NTP Support for IPv6 Networks

Network Time Protocol (NTP) synchronizes device clocks across networks to maintain system accuracy. In this release, NTP supports IPv6 multicast networks. The NTP server sends clock updates as multicast messages to the clients across IPv6 networks. As NTP packets are sent only to the intended clients, it reduces timing traffic in the network.

Software Activation

No License Snapshot Support

License snapshot won’t be generated starting from this release and the software relies only on the existing snapshot for any PAK license information.

Strong Crypto Algorithms

Strong Crypto Algorithms

We strongly recommend stronger cryptographic algorithms instead of weak cryptographic algorithms, such as RSA keys of less than 2048 bits, MD5 for authentication, DES, and 3DES for encryption. Soon, such weak algorithms will no longer be allowed by default. An explicit configuration is required to continue using such weak algorithms.

For SNMP v3 users with weak cryptographic properties, the SNMP operations to the device will fail, resulting in loss of management access to device through SNMP. Similarly, if the RSA key pair is not updated to be at least 2048 bits for SSH, the SSH server will be disabled, resulting in loss of remote access to the device through SSH.

For more information on how to migrate to stronger cryptographic algorithms for SNMP, see the Field Notice Number: FN72509.

For more information on how to migrate to stronger cryptographic algorithms for SSH, see Field Notice Number: FN72511.

IP SLAs

QoS for Y.1564 SADT External Sessions

Y.1564 Ethernet service activation test methodology now supports Ingress and Egress QoS policy configuration on interfaces. You can now measure QoS traffic throughput and loss using SADT external sessions on the ingress traffic.

In earlier releases, Y.1564 supports egress QoS policy. With this enhancement, both SADT ingress and egress traffic can coexist on an interface.

Programmability

gNMI Dial-Out Using gRPC Tunnel Service

This feature allows you to configure a network device (tunnel client) to register certain targets (preapproved services) with a gRPC tunnel server through the CLI. These targets are defined as ports on the network device.

You can use the gRPC tunnel server to forward connections from external clients, such as gRPC Network Management Interface (gNMI)/gRPC Network Operations Interface (gNOI), to connect to the network device without establishing a direct connection.

The following commands are introduced for the tunnel and target configurations respectively:

• gnxi grpctunnel destination server name

• gnxi grpctunnel target

YANG

YANG Support for show l2vpn atom vc detail Command

The Cisco-IOS-XE-l2vpn-oper native model is a collection of YANG definitions for L2VPN services operational data. Additional leaves and lists are now supported in the following sensor path:

Cisco-IOS-XE-l2vpn-oper\l2vpn-oper-data\l2vpn-services\l2vpn-atom-vc-info

With this model, you can get detailed information, such as the L2VPN service name, service type, interface name, peer address, status, encapsulation type, virtual circuit ID, and packet information by using a NETCONF RPC.

In earlier releases, you could perform this action by using the following CLI:

show l2vpn atom vc detail

• show l2vpn service xconnect peer peer_id vcid vcid

• show l2vpn atom commands

YANG Data Models—For the list of Cisco IOS XE YANG models available with this release, navigate to https://github.com/YangModels/yang/tree/main/vendor/cisco/xe. Revision statements embedded in the YANG files indicate if there has been a model revision. The README.md file in the same GitHub location highlights changes that have been made in the release.