Remote Authentication Dial-In User Service (RADIUS) attributes are used to define specific authentication, authorization, and accounting (AAA) elements in a user profile, which are stored on the RADIUS program.

Enable the RADIUS endpoint to dynamically create pods on a designated node or host. This feature is necessary to ensure nodes meet specific security and regulatory parameters are geographically closer to the datacenter. Node affinity determines the node where cnAAA creates the RADIUS endpoint pods, based on affinity towards a node or group of nodes. Node affinity is a set of rules that defines custom labels on nodes and specifies label selectors within the pods. Based on these rules, the scheduler determines the pod's placement location.

Note	If you do not specify a node, then the Kubernetes scheduler determines the node where the RADIUS endpoint creates a pod.

cnAAA supports both IPv4 and IPv6 connectivity on its external interfaces/endpoints (inbound and outbound).

The CPC supports RADIUS for managing Authentication, Authorization, and Accounting (AAA) for users connecting to a network service. It ensures secure network access and precise session tracking for accurate billing and resource management. The feature also supports interim updates and Change of Authorization (CoA) requests, allowing real-time adjustments to user services. The Broadband Network Gateway (BNG) acts as the RADIUS client, sending requests to CPC based on user information.

The following are the core functionalities of the CPC in handling RADIUS requests:

• Access-Request

• Accounting-Request

This section describes how to specify the node or host where the RADIUS endpoint must spawn the pod.

Note	Configuration changes to the RADIUS endpoint cause the endpoint to restart automatically. Cisco recommends making such changes only within the maintenance window.

Mandatory RADIUS configuration

To configure the RADIUS server with essential parameters for optimal network performance and security, use the following configuration:

radius bind-ip <bind IP address>
radius replicas 2
radius settings request-timeout-ms 5000
radius settings max-tries  1
radius async-threading-configuration default-processing-threads 100
radius async-threading-configuration default-action-priority 5
radius async-threading-configuration default-action-threads 100
radius async-threading-configuration default-action-queue-size 400000
radius async-threading-configuration default-action-drop-oldest-when-full true
radius device-group ASR9K
 	default-shared-secret     <secret value>
 	default-coa-shared-secret <secret value>
 	coa-port                  3799
 coa-timeout-seconds       3
 	device <BNG Device Name>
 	 ip                 <BNG IP Address>
  	shared-secret      <secret value>
  	coa-shared-secret  <secret value>
  	loopback-addresses [ <loopback addresses> ]
 exit
radius server-group <Server Group Name>
 servers <server name>
  	primary              <primary OCS IP Address>
 	 secondary            <secondary OCS IP Address>
 	 nas-ip               <nas p address>
 	 accounting-port      1803
  	authorization-port   1802
 	 auth-protocol        PAP
 	 radius-password      <radius password>
  	shared-secret        <secret value>
 	 timeout-seconds      3
  	test-message         false
  	test-userid          test
 	 test-password        test123
 	 thread-pool-size     330
 	 max-proxy-queue-size 50000
       server-type   online (or) offline
 	 retries              0
 exit
radius properties grpc.executors
 	value 5
exit
radius properties grpc.timeoutMs.processing
 value 5000
exit
radius properties io.netty.eventLoopThreads
 	value 16
exit
radius properties parallelChannelCount
 	value 5
exit
radius properties prometheusPort
 	value 9099
exit
radius properties radiusCorePoolSize
 	value 20
exit
radius properties radiusMaxQueue
 	value 4000
exit
radius properties traps.tps
 	value 4000
exit
radius properties udpMaxQueue
 	value 4000
exit
radius properties udpPoolSize
 value 20
exit

IPv6 support for cnAAA manages both IPv4 and IPv6 sessions, ensuring network connectivity.It operates in environments requiring either IPv4 or IPv6, supporting the transition to IPv6 while maintaining compatibility with existing IPv4 infrastructure without disrupting current operations.

To configure IPv6 support, configure the following components:

• Radius Endpoint

• Mongo Replica Sets

RADIUS Endpoint support in IPv6 deploys cnAAA with IPv6/IPv4 dual stack connectivity to various network functions (NFs). In Ops-Center, the RADIUS endpoint configuration supports both IPv4 and IPv6 addresses for external IPs, device groups, and server group configurations. This setup ensures cnAAA operates effectively in different network environments, accommodating different IP address.

Properties to Enable IPv6

These properties enable the IPv6 support in cnAAA:

radius properties com.broadhop.pep.ipv6.enable.feature
value true
exit
engine cpc-green
policy-builder properties com.broadhop.pep.ipv6.enable.feature
value true
exit

Mongo replica set configurations support both IPv4 and IPv6 addresses for replica member hosts. This ensures that the initialization, replication, and initial sync functionalities of the Mongo replica set operate without any impact, regardless of whether IPv4 or IPv6 addresses are used. This dual support allows for flexible network configurations and aids in transitioning to IPv6 while maintaining compatibility with existing IPv4 infrastructure.

Each replica subscriber must be configured with either IPv4 or IPv6 addresses to ensure optimal functionality. It is not recommended to mix both IP versions within a single subscriber configuration.

To enable the IPv6 on the RADIUS Endpoint within CPC, complete the following configurations in Ops-Center.

General RADIUS settings

radius accounting-port 1813
radius authorization-port 1812
radius coa-port    1700
radius bind-ip 2001:ddff::1
radius settings request-timeout-ms 5000
radius settings max-tries  1
radius settings min-processing-time-millis 3000
radius settings backoff-time-millis 1000

BNG device group configurations

BNG Client Configuration
device bng01
  ip                 2002:20:50:53::100/127
  shared-secret      cisco
  coa-shared-secret  cisco
  loopback-addresses [ 12.0.0.1 ]
 exit

RADIUS server group configuration

radius server-group grp1
 servers DEL_OCS
  primary              2002:20:50:52::100
  secondary            2002:20:50:52::101
  accounting-port      1803
  authorization-port   1802
  auth-protocol        PAP
  radius-password      test123
  shared-secret        cisco
  timeout-seconds      5
  test-message         false
  test-userid          test
  test-password        test123
  thread-pool-size     400
  max-proxy-queue-size 40000
  server-type   online (or) offline
  retries              3
 exit
exit

Dual Stack support for cnAAA manages of IPv4 and IPv6 sessions simultaneously, providing connectivity across networks. It also manages subsystem interfaces such as Policy Builder, Unified API, Control Center, and Central UI, and handles internal communications using IPv4 and IPv6.

Validation of both IPv4 and IPv6 forwarding is important for all relevant CPC services. This validation confirms that network traffic flows correctly over both protocols within the deployed environment..

How to validate

The successful execution of these key operations confirms correct network forwarding for both IPv4 and IPv6:

• Cluster Deployment and Management: Core cluster components deploy with dual-stack configurations. This ensures node-to-node communication.

• SNMP Alerts and Communication: SNMP alerts are received and processed through configured IPv6 trappers.

• Geo-Redundancy GR with CDL: Data replicates and synchronizes between different sites using IPv6 for CDL communication.

• Geo-Redundancy GR with Mongo: Data replicates and synchronizes between different sites using IPv6 for SPR or Admin DB communication.

Validate IPv6-enabled URLs

Verify access to Grafana, Policy Builder, Control Centre, and CPS Central through their respective IPv6-enabled URLs after the configurations are applied.

• Grafana: https://grafana.2001-db8-1--87.sslip.io/

• CPS Central: https://pb.<namespace>-pcf-engine-app-production-rjio.2001-db8-1--87.sslip.io/central/#!/central

• Policy Builder (PB): https://pb.<namespace>-pcf-engine-app-production-rjio.2001-db8-1--87.sslip.io/pb

• Control Center: https://pcf.controlcenter.2001-420-2c7f-f6ad--87.sslip.io

The Service Mismatch Handling feature in RADIUS Support for cnAAA ensures delivery of Change of Authorization (CoA) messages to the Broadband Network Gateway (BNG). CoA delivery failures can lead to unauthorized service access. This feature uses a retry mechanism with a backoff strategy, allowing the BNG time to recover and process CoA requests. The stack within the RADIUS Endpoint implements the backoff retry strategy.

The Back Off Retry involves multiple attempts with increasing delay times. Following table outlines the retry schedule:

This process details the retry mechanism for sending Change of Authorization (CoA) requests from cnAAA to BNG when timeouts and NAK error codes occur. Assuming the CoA Retry Timeout is set to 3 seconds and the number of CoA Retries is configured to 3, the system will attempt retries based on these settings.

The following examples illustrate the timing of retries under different circumstances.

CoA Request Timed Out from BNG

This example shows the retry behavior when a CoA request times out due to no response from the BNG.

• Initial CoA Request (Retry attempted in RADIUS stack):

  • T0: CoA#1

  • T0+3: CoA#2 (retry#1)

  • T0+6: CoA#3 (retry#2)

  • T0+9: CoA#4 (retry#3)

  • CoA#4 will timeout at T0+12

• 1st Backoff Retry (retry attempted after 1 second):

  • T0+12+1: CoA#5

  • T0+12+1+3: CoA#6

  • T0+12+1+3+3: CoA#7

  • T0+12+1+3+3+3: CoA#8

  • T0+12+1+3+3+3+3: CoA#8 will timeout

• 2nd Backoff Retry (retry attempted after 3 seconds):

  • T0+25+3: CoA#9

  • T0+25+3+3: CoA#10

  • T0+25+3+3+3: CoA#11

  • T0+25+3+3+3+3: CoA#12

  • T0+25+3+3+3+3+3 (T0+40): CoA#12 will timeout

CoA Nack Error Code Configuration

When a CoA request is negatively acknowledged (NAK) by the BNG, retries are triggered with a backoff mechanism. The behavior is shown in the following example:

Configure NACK error codes in OpsCenter using: backOffRetryCoA.CoANackErrorCause = <Comma Separated Nack Error Cause>

Example: backOffRetryCoA.CoANackErrorCause = "506,405,1001"

CoA NAK Error from BNG to cnAAA

• Initial CoA Request

  • T0 – CoA#1

  • T0+2: CoA NAK (error code: 506) (response received after 2 seconds)

• 1st Backoff Retry (retry attempted after 1 second)

  • T0+2+1: CoA#2

  • T0+2+1+2 (T0+5): NAK (error code: 506) (after 2 seconds)

• 2nd Back off Retry (retry attempted after 3 seconds)

  • T0+5+3: CoA#3

  • T0+5+3+2: NAK (response received after 2 seconds)

CoA BackOff Failure Report

• When the BackOff Retry exceeds the configured maxRetransmission limit, cnAAA updates the coaBackOffFailureReport.csv file located at /data/consolidated-aaa-logging/ in the consolidated-aaa-logging pod with the following information:

  • Session Id

  • BNG IP Address

  • Subscriber Id

  • Service Details

    2025-03-27 20:33:50,533  00012,11.11.90.72,0005.9A3C.7A00,
    [subscriber:sd=A0F0500M050M000030MQ, subscriber:sa=A0F0500M100M000030MQ] 

The flowchart explains the process of CoA retry mechanism, the interaction between the Engine, RADIUS Endpoint (EP), and BNG. The workflow includes handling retries, applying backoff logic, and determining success or failure based on responses.

1. The Engine initiates the CoA request workflow and reads the configured Backoff Retry Threshold to determine the maximum number of retry attempts, then sends the initial CoA request to the RADIUS Endpoint (EP).

2. The RADIUS EP forwards the CoA request to the BNG.

3. The BNG processes the CoA request and responds with one of the following:

   • ACK (acknowledgment): Indicates success.

   • NAK (negative acknowledgment): Indicates failure.

   • No response: Indicates timeout.

4. If the BNG responds with an ACK, the RADIUS EP forwards this to the Engine. The Engine considers the process successful, and the workflow ends.

5. If the BNG responds with a NAK or does not respond (timeout), the RADIUS EP forwards this response to the engine.

6. If a NAK or timeout is received, the engine updates the retry counter and, after a one second delay, either retries the CoA request (if within the retry threshold) or generates a failure report.

7. The workflow ends either upon success (ACK) or failure (retries exhausted).

This feature optimizes CoA request handling for BNGs by directing requests from an engine pod to a consistent RADIUS endpoint using a hash derived from the NAS IP address of the BNG. The engine generates a hash number from the NAS IP Address, ensuring consistent endpoint selection for each BNG. This prevents overloads by avoiding inconsistent throttling that can occur with random distribution of CoA requests across endpoints.

BNG IPs is configured through Policy Builder and Ops Center.

BNG Configuration

Configure the BNG-IP and device details using the following setup:

Device Group Setup:

radius device-group ASR9K
device dev1
ip  192.68.41.138
shared-secret cisco
coa-shared-secret cisco
loopback-addresses [ 12.3.1.2 ]
exit
device dev2
ip  192.68.41.139
shared-secret cisco
coa-shared-secret cisco
loopback-addresses [ 12.3.1.2 ]
exit
device dev3
ip 192.68.41.140
shared-secret cisco
coa-shared-secret cisco
loopback-addresses [ 12.3.1.2 ]
exit

Enable the CoA Processing Per BNG

Enable CoA processing per BNG in the Ops Center by setting the property value to true. The default configuration sets this property to false.

engine cpc-green
properties coaThrottlingPerBng
value true
exit

Configure CoA Throttling

Enable the following Ops Center configuration for the throttling feature.

radius advance-tuning throttling-limit 15

radius advance-tuning coa-throttlling-for-asr9k-pep true

Add/Remove the Radius Replicas

Use the following Ops Center configuration to modify the radius replicas.

CoA Request Throttling

When the cnAAA engine receives a plan change request from the OCS, it initiates a process towards the RADIUS endpoint (radius-ep) to send a Change of Authorization (CoA) to the designated BNG. The engine generates a hash number from the NAS IP Address, ranging from 0 to N, representing the number of radius endpoints. This hash maps to the corresponding radius endpoint, allowing the engine to send a CoA Request for further processing to the configured BNG.

Example: If the cnAAA engine processes 20 CoA requests with a throttling value of 15, 15 requests will be successful while 5 are dropped due to throttling. The engine will retry the throttled requests and consistently route them to the radius-ep.

Endpoint Pod Changes

While adding or removing RADIUS endpoint pods, re-hashing is performed. As a result, CoA requests are always redirected to the correct RADIUS endpoint based on the hash value of the configured BNGs. The hashing mechanism minimizes key redistribution when the number of RADIUS Endpoint pods changes, focusing on maintaining consistent routing rather than equal distribution of keys.

These metrics provide an overview into the processing and outcomes of CoA requests and responses:

Throttled CoA Requests:

Description: Indicates the total number of CoA requests that were throttled due to exceeding set limits.

radius_coa_requests_throttled_total{message_type="CoARequestThrottle",
nas_ip_address="192.168.41.138",endpoint_address="192.102.6.99",} 5.0 

Total CoA Requests:

Description: Represents the total CoA requests processed.

radius_coa_requests_total{message_type="CoARequest",
nas_ip_address="192.168.41.138",endpoint_address="192.102.6.99",retry_type="NA",
result="SUCCESS",} 20.0

CoA Acknowledgment Responses:

Description: Captures acknowledgment responses for CoA requests. The metric shows a successful CoA ACK response from NAS IP address to endpoint, with no NAK error cause specified.

radius_coa_responses_total{message_type="CoAACKResponse",
nas_ip_address="192.168.41.138",client_ip_address="192.168.101.70",
endpoint_address="192.102.6.99",nak_error_cause="",}