AAA Profile Configuration

The following command and options allow you to configure an AAA profile.

This following example demonstrates a typical AAA (Authentication, Authorization, and Accounting) profile configuration for RADIUS authentication and accounting. The profile name is 'aaa-radius.

The session-timeout value is set to '0', meaning there is no session timeout and the session can remain active indefinitely. The idle timeout value is also '0', indicating no idle timeout, so the session will not be terminated due to inactivity.

The parameter aaa-radius-profile is set to 'radius-default', which maps the AAA profile to the specific RADIUS profile named 'radius-default'. The RADIUS profile contains the necessary configuration details for communicating with the RADIUS server. In this profile, RADIUS is the selected method for handling all authentication requests. The order parameter indicates that RADIUS is the primary and only method of authentication configured.

For accounting, the order is specified as RADIUS, indicating that all accounting data is sent to the RADIUS server. The parameter session-id-format is set to "DEFAULT".

The ingress accounting-source is "POLICER", and the egress accounting source is "CLASS". "POLICER" indicates that the accounting data is based on a traffic policer, while "CLASS" indicates that the accounting data is based on traffic classes.

The class-byte-adjustment-value parameter is set to 16, adjusting the byte count for outgoing traffic by a specific value (16).

RBFS supports the authentication methods: NONE, LOCAL, and RADIUS.

Certain authentication methods can be combined together such as the following:

LOCAL_RADIUS: In this method, the system attempts to authenticate the subscriber at first locally. If no matching local user is found, the system attempts authentication via RADIUS. If a local user is found but the password does not match, the subscriber is immediately rejected, and no RADIUS request is made.

RADIUS_LOCAL: In this method, the system attempts to authenticate the subscriber at first through RADIUS. If the RADIUS server rejects the request, the subscriber is immediately disconnected. However, if no response (timeout) is received from any configured RADIUS server, the system falls back to local authentication.

The following command and options allow you to define the order of authentication methods.

Subscriber accounting involves tracking and recording a subscriber’s session duration and data usage. This process includes two main components:

Volume accounting operates in both directions (ingress and egress), and these can be configured independently.

Note: Currently, RBFS supports RADIUS as the only accounting method.

The following command and options are used to configure accounting for the default AAA profile named aaa-default. The 'egress' option allows you configure accounting for outgoing traffic, and the 'ingress' option allows to set accounting for incoming traffic. The 'interim-interval' option sets the interval, in seconds, for sending interim accounting updates. The 'order' option determines the sequence in which accounting records are processed or sent. This is helpful when multiple accounting methods are used. The 'session-id-format' option allows you to define the format of the accounting session ID attribute, which uniquely identifies each accounting session.

The accounting adjustment feature enables basic counter modifications for the configured accounting method, such as RADIUS accounting. This configuration is necessary to normalize counters across different platforms in each direction. On Broadcom Q2C and Q2A based platforms, packets are counted in the size they enter the switch. Without adjustment, egress accounting would count downstream traffic as received from the core, complete with MPLS labels, while ingress accounting typically includes VLAN headers and/or PPPoE headers.

This counter adjustment aims to normalize counters with diverse encapsulations (double-tagged, untagged, and so on), potentially aligning to L3 counters (IP header and payload) as an example, or exclusively adapting egress traffic to match the outgoing packet encapsulation. The possibility for separate adjustment configurations per direction allows parity in the counters for both ingress and egress.

Example Scenario:

In a scenario where packets enter a device with various encapsulations like PPPoE headers, MPLS labels, or VLAN tags, the system may count these additional headers in the packet size if the adjustment feature is not enabled. This can cause discrepancies in accounting reports.

For instance, an egress interface where traffic exits the device and goes to subscribers. If this traffic originally came from the core network with MPLS labels attached, the system counts the bytes of those labels in its accounting, inflating the byte count. Similarly, on the ingress side, the device counts VLAN tags or PPPoE headers, further impacting accurate accounting reports. To address this issue, you can configure a byte adjustment on both the ingress and egress sides to normalize these counters.

In RBFS, two configuration options are available for to achieve this: the byte adjustment value and the byte adjustment factor. The option byte adjustment value, which can be positive or negative (for example, -20 or 20), adjusts the byte count by a specific amount. Any decimal digits in the adjustment value are rounded to the nearest whole number (for example, 20.2 becomes 20). The option byte adjustment factor, which is less commonly used, adjusts the byte count by a percentage. It accepts positive values and considers up to two decimal places, such as 0.98 for a 2% reduction or 1.02 for a 2% increase.