To support scale and performance, cnBNG supports the following configuration commands:

• cnBNG pod layout configuration when the virtual machine is short of CPU and memory resource:

  • cpu { max-process | request }:process_thread_count | request resource_request_number } —Enable the K8s pod CPU configuration.

  • memory { limit max_resource_limit | request resource_request_number } —Enable the K8s pod memory configuration.

• Event tracing configuration to trace session level event history in CDL records:

  • event-trace-disable —Disable event tracing.

  • event-trace-max-count event_trace —Limit the number of entries in event tracing.

For more information, see the Cloud Native BNG Control Plane Configuration Guide > Pods and Services Reference chapter.

The End-to-End Flow Control feature optimizes flow control and rate limit of the traffic toward the control plane ingress.

The End-to-End Flow Control feature supports the following functionalities in this release:

• Configurable rate limits and queue sizes for different UPFs. The rate limits and queue sizes vary for all UPFs depending on the UPF's capability.

  In the endpoint udp-proxy configuration, use the flowctrl-group group_name { capacity inbound_queue_size | outbound-capacity outbound_queue_size | outbound-rate-limit outbound_rate_limit | rate-limit inbound_rate_limit } command to configure the inbound and outbound queue size and rate limit for the specified flow control group.

• Packet priority and differential treatment to packets based on the packet type or DSCP value of the packet.

• FSOL token mechanism—This is a protection method to control the maximum inflight transactions on control plane at each FSOL pod. Token mechanism addresses higher packet rates and works with UDP proxy flow control to protect the control plane. The flow control configuration acts as the first-level check in the control plane to control the incoming GTPU and PFCP message rates.

  Use the subscriber token { dhcp | pppoe } token_count command to set the maximum token available for the FSOL pod.

For more information, see the Cloud Native BNG Control Plane Configuration Guide > End-to-End Flow Control chapter.

cnBNG Control Plane is built on Cisco® Cloud Native Infrastructure, which is a Kubernetes-based platform that provides a common execution environment for container-based applications.

In this release, the Kubernetes (K8s) version is upgraded from 1.21 to 1.22.

High Availability and CP Reconciliation

The high availability (HA) and Reconciliation feature for the control plane supports all cnBNG-specific service pods. This feature is extended to support the LAC and LNS session types.

• CP Reconciliation—This feature supports reconciliation between PPP and L2TP for LAC and LNS sessions. To recover L2TP service after HA events and to avoid service impact, critical information such as L2TP sequence numbers (Ns/Nr), Session Count, and SessionID bitmap must be recovered. The tunnel state for L2TP HA is recovered through recovery from another L2TP service.

• Pod Restart—The HA support for L2TP is provided using a local peer service to synchronize the necessary L2TP tunnel information and recover it after restart. It also supports hitless operation during pod restart, and the restart of pods without impacting the existing sessions and tunnels. This feature helps to recover the L2TP control connection information such as Ns/Nr sequence numbers, Tunnel Context, and Session Bitmap, and also resume the control channel.

For more information, see the Cloud Native BNG Control Plane Configuration Guide > High Availability and CP Reconciliation chapter.

Rolling Software Update

The Rolling Software Update feature enables incremental update of pod instances with minimal downtime. cnBNG supports rolling upgrade for LAC and LNS sessions in addition to PTA and IPoE sessions.

cnBNG supports rolling upgrade for LAC and LNS clusters without impacting the existing tunnels by modifying the L2TP service with an initial readiness delay of 60 seconds. The K8s infrastructure upgrades an instance of L2TP pod only after the active instance is successfully upgraded and resynchronizes all existing tunnel data in the peer L2TP instance. If more than one L2TP instance exists, rolling upgrade updates only one instance at a time. The stateful set pairing must be done accordingly to avoid peer L2TP instance going down at the same time.

For more information, see the Cloud Native BNG Control Plane Configuration Guide > Rolling Software Update chapter.