This chapter provides information about configuring authentication, authorization, and accounting (AAA) functions on the BNG router. BNG interacts with the RADIUS server to perform AAA functions. A group of RADIUS servers form a server group that is assigned specific AAA tasks. A method list defined on a server or server group lists methods by which authorization is performed. Some of the RADIUS features include creating specific AAA attribute formats, load balancing of RADIUS servers, throttling of RADIUS records, Change of Authorization (CoA), and Service Accounting for QoS.

This chapter covers these topics:

AAA acts as a framework for effective network management and security. It helps in managing network resources, enforcing policies, auditing network usage, and providing bill-related information. BNG connects to an external RADIUS server that provides the AAA functions.

The RADIUS server performs the three independent security functions (authentication, authorization, and accounting) to secure networks against unauthorized access. The RADIUS server runs the Remote Authentication Dial-In User Service (RADIUS) protocol. (For details about RADIUS protocol, refer to RFC 2865). The RADIUS server manages the AAA process by interacting with BNG, and databases and directories containing user information.

The RADIUS protocol runs on a distributed client-server system. The RADIUS client runs on BNG (Cisco ASR 9000 Series Router) that sends authentication requests to a central RADIUS server. The RADIUS server contains all user authentication and network service access information.

The AAA processes, the role of RADIUS server during these processes, and some BNG restrictions, are explained in these sections:

Accounting

The accounting keeps track of resources used by the subscriber during network access. Accounting is used for billing, trend analysis, tracking resource utilization, and capacity planning activities. During the accounting process, a log is maintained for network usage statistics. The information monitored include, but are not limited to - subscriber identities, applied configurations on the subscriber, the start and stop times of network connections, and the number of packets and bytes transferred to, and from, the network.

BNG reports subscriber activity to the RADIUS server in the form of accounting records. Each accounting record comprises of an accounting attribute value. This value is analyzed and used by the RADIUS server for network management, client billing, auditing, etc.

The accounting records of the subscriber sessions may timeout if the BNG does not receive acknowledgments from the RADIUS server. This timeout can be due to RADIUS server being unreachable or due to network connectivity issues leading to slow performance of the RADIUS server. If the sessions on the BNG are not acknowledged for their Account-Start request, loss of sessions on route processor fail over (RPFO) and other critical failures are reported. It is therefore recommended that a RADIUS server deadtime be configured on the BNG, to avoid loss of sessions. Once this value is configured, and if a particular session is not receiving an accounting response even after retries, then that particular RADIUS server is considered to be non-working and further requests are not sent to that server.

The radius-server deadtime limit command can be used to configure the deadtime for RADIUS server. For details, see Configuring RADIUS Server Settings.

Note

On session disconnect, transmission of the Accounting-Stop request to RADIUS may be delayed for a few seconds while the system waits for the "final" session statistics to be collected from the hardware. The Event-Timestamp attribute in that Accounting-Stop request should, however, reflect the time the client disconnects, and not the transmission time.

A RADIUS server group is a named group of one or more RADIUS servers. Each server group is used for a particular service. For example, in an AAA network configuration having two RADIUS server groups, the first server group can be assigned the authentication and authorization task, while the second group can be assigned the accounting task.

Server groups can include multiple host entries for the same server. Each entry, however, must have a unique identifier. This unique identifier is created by combining an IP address and a UDP port number. Different ports of the server, therefore, can be separately defined as individual RADIUS hosts providing a specific AAA service. In other words, this unique identifier enables RADIUS requests to be sent to different UDP ports on the same server. Further, if two different host entries on the same RADIUS server are configured for the same service (like the authentication process), then the second host entry acts as a fail-over backup for the first one. That is, if the first host entry fails to provide authentication services, BNG tries with the second host entry. (The RADIUS host entries are tried in the order in which they are created.)

For assigning specific actions to the server group, see Configuring RADIUS Server Group.

Method lists for AAA define the methods using which authorization is performed, and the sequence in which these methods are executed. Before any defined authentication method is performed, the method list must be applied to the configuration mechanism responsible for validating user-access credentials. The only exception to this requirement is the default method list (named "default"). The default method list is automatically applied if no other method list is defined. A defined method list overrides the default method list.

On BNG, you have to specify the method list and the server group that will be used for AAA services. For specifying method lists, see Configuring Method Lists for AAA.

The AAA attribute is an element of RADIUS packet. A RADIUS packet transfers data between a RADIUS server and a RADIUS client. The AAA attribute parameter, and its value - form a Attribute Value Pair (AVP). The AVP carries data for both requests and responses for the AAA transaction.

The AAA attributes either can be predefined as in Internet Engineering Task Force (IETF) attributes or vendor defined as in vendor-specific attributes (VSAs). For more information about the list of BNG supported attributes, see RADIUS Attributes.

The RADIUS server provides configuration updates to BNG in the form of attributes in RADIUS messages. The configuration updates can be applied on a subscriber during session setup through two typical methods— per-user attributes, which applies configuration on a subscriber as part of the subscriber's authentication Access Accept, or through explicit domain, port, or service authorization Access Accepts. This is all controlled by the Policy Rule Engine's configuration on the subscriber.

When BNG sends an authentication or an authorization request to an external RADIUS server as an Access Request, the server sends back configuration updates to BNG as part of the Access Accept. In addition to RADIUS configuring a subscriber during setup, the server can send a change of authorization (CoA) message autonomously to the BNG during the subscriber's active session life cycle, even when the BNG did not send a request. These RADIUS CoA updates act as dynamic updates, referencing configured elements in the BNG and instructing the BNG to update a particular control policy or service policy.

BNG supports the concept of a "service", which is a group of configured features acting together to represent that service. Services can be represented as either features configured on dynamic-templates through CLI, or as features configured as RADIUS attributes inside Radius Servers. Services are activated either directly from CLI or RADIUS through configured "activate" actions on the Policy Rule Engine, or through CoA "activate-service" requests. Services can also be deactivated directly (removing all the involved features within the named service) through configured "deactivate" action on the Policy Rule Engine or through CoA "deactivate-service" requests.

aaa attribute format <format-name> format-string [length] <string> *[<Identity-Attribute>]

In order to make BNG interact with the RADIUS server, certain server specific settings must be made on the BNG router. This table lists some of the key settings:

For more making RADIUS server settings, see Configuring RADIUS Server Settings.

For more making specific automated testing settings, see Configuring Automated Testing.

For more making specific IP DSCP settings, see Setting IP DSCP for RADIUS Server.

Note

The service profile push or asynchronously pushing a profile to the system is not supported. To download a profile from Radius, the profile must be requested initially as part of the subscriber request. Only service-update is supported and can be used to change a service that was previously downloaded.

The RADIUS load-balancing feature is a mechanism to share the load of RADIUS access and accounting transactions, across a set of RADIUS servers. Each AAA request processing is considered to be a transaction. BNG distributes batches of transactions to servers within a server group.

When the first transaction for a new is received, BNG determines the server with the lowest number of outstanding transactions in its queue. This server is assigned that batch of transactions. BNG keeps repeating this determination process to ensure that the server with the least-outstanding transactions always gets a new batch. This method is known as the least-outstanding method of load balancing.

You can configure the load balancing feature either globally, or for RADIUS servers that are part of a server group. In the server group, if a preferred server is defined, you need to include the keyword "ignore-preferred-server" in the load-balancing configuration, to disable the preference.

For configuring the load balancing feature globally, see Configuring Load Balancing for Global RADIUS Server Group.

For configuring the load balancing feature on RADIUS servers that are part of a named server group, see Configuring Load Balancing for a Named RADIUS Server Group.

The Throttling of AAA (RADIUS) records is a mechanism to avoid RADIUS congestion and instability. This function is useful in situations when there is insufficient bandwidth to accommodate a sudden burst of AAA requests generated by the BNG for the RADIUS server.

While configuring throttling, a threshold rate, which corresponds to the maximum number of outstanding requests, is defined. It is possible to configure independent throttling rates for access (authentication and authorization) and accounting requests. After a threshold value is reached for a server, no further requests of that type are sent to the server. However, for the pending requests, a retransmit timer is started, and if the outstanding request count (which is checked after every timer expiry), is less than the threshold, then the request is sent out.

As a session may timeout due to throttle on the access requests, a limit is set for the number of retransmit attempts. After this limit is reached, further access requests are dropped. Throttled accounting requests, however, are processed through the server-group failover process.

The throttling feature can be configured globally, or for a server-group. However, the general rule of configuration preference is that the server-group configuration overrides global configuration, if any.

radius-server throttle {[accounting THRESHOLD] [access THRESHOLD [access-timeout NUMBER_OF-TIMEOUTS]]}

Note	By default, the throttling feature is disabled on BNG.

For activating throttling globally, see Configuring RADIUS Throttling Globally.

For activating throttling on a server group, see Configuring RADIUS Throttling on a Server Group.

The Change of Authorization (CoA) function allows the RADIUS server to change the authorization settings for a subscriber who is already authorized. CoA is an extension to the RADIUS standard that allows sending asynchronous messages from RADIUS servers to a RADIUS client, like BNG.

Note	A CoA server can be a different from the RADIUS server.

To identify the subscriber whose configuration needs to be changed, a RADIUS CoA server supports and uses a variety of keys (RADIUS attributes) such as Accounting-Session-ID, Username, IP-Address, and ipv4:vrf-id.

For a list of supported Vendor-Specific Attributes for account operations, see Vendor-Specific Attributes for Account Operations.

Note	In order for BNG to enable interim accounting, it is mandatory for the CoA request to have both accounting method list from the dynamic-template and Acct-Interim-Interval attribute from the user profile. This behavior is applicable for accounting enabled through dynamic-template.

The user authentication and authorization in the local network feature in BNG provides the option to perform subscriber authorization locally (in a subscriber's network), instead of both remote authentication and authorization that occurs in RADIUS servers. With the User Authentication and Authorization in the Local Network feature, you can run the RADIUS server locally in your network, manage, and configure the RADIUS server locally in your network to the profile that is required for the environment. In the case of a remote RADIUS server, the RADIUS server is maintained by an external regulatory body (not within the subscriber's network) and subscriber will not be able to manage or configure the server.

User Authentication and Authorization in the Local Network feature is used in a case when a user wants to perform a two-level authentication or authorization, first, a remote authentication (or authorization) followed by a local authorization (or authentication).

Note	All the debug commands applicable to AAA server are applicable on User Authentication and Authorization in the Local Network feature.

For IPoE subscribers, User Authentication and Authorization in the Local Network is a two-level authorization process as a part of the session-start event. For PTA subscribers, User Authentication and Authorization in the Local Network is a remote server authentication process, followed by a local server authorization process.

Accounting records for each service enabled on a subscriber can be sent to the configured RADIUS server. These records can include service-start, service-stop, and service-interim records containing the current state of the service and any associated counters. This feature is the Service Accounting feature. Service accounting records are consolidated accounting records that represent the collection of features that make up a service as part of a subscriber session.

Service accounting starts when a subscriber session comes up with a service enabled on it. This can happen through a dynamic template applied through a control policy, through access-accept (AA) messages when the session is authorized, or through a change of authorization (CoA), when a new service is applied on a subscriber session. Service accounting stops either when the session is terminated, or a service is removed from the session through CoA, or some other event that deactivates the service. Start records have no counters; interim and stop records with QoS counters are generated when service accounting is enabled for QoS. Interim accounting records can be generated, in between start and stop accounting, as an option with a pre-defined periodic interval. When the interim period is zero, interim accounting records are not created. Different interim intervals are based on every service for each session. Service accounting is enabled on each template, based on the configuration.

Service Accounting is supported on bundle subscriber interfaces as well as line card subscriber interfaces.

Note

The policy-map associated to a dynamic template can be edited to change the service parameters. However, this does not update the accounting records. Therefore, to generate all the accounting records accurately, it is recommended that a new service with all the required service parameters be created and associated to the new service, through a CoA.

For service accounting, statistics for ingress and egress QoS policies, which are applied under each service for a given subscriber, may need to be reported as part of the accounting interim and stop records. For each service, these QoS counters can be reported as part of the accounting records:

• BytesIn — Aggregate of bytes matching all classes of the ingress QoS policy for the service minus the policer drops.

• PacketsIn — Aggregate of packets matching all classes of the ingress QoS policy for the service minus the policer drops.

• BytesOut — Aggregate of bytes matching all classes of the egress QoS policy for the service minus the queuing drops.

• PacketsOut — Aggregate of packets matching all classes of the egress QoS policy for the service minus the queuing drops

Dynamic template features that support accounting statistic collection and require that their statistics be reported in the AAA service accounting records can enable accounting statistics on their features using the newly-introduced optional acct-stats configuration option. This option is not available for the features that do not support statistic collection. By default, QoS accounting statistics are disabled to optimize performance.

Note	The QoS counters for each direction is reported only if a QoS policy is applied for that service in the given direction. For example, if a service does not have an ingress policy applied, BytesIn and PacketsIn counters are reported as being 0.

Note	IPv4 and IPv6 subscriber sessions has a single set of service accounting records. They are merged into one set of bytes_in, bytes_out, packets_in, packets_out counters. Service accounting is not supported for static sessions.

Accounting is used for billing, trend analysis, tracking resource utilization, and capacity planning activities. During the accounting process, a log is maintained for network usage statistics.

BNG reports subscriber activity to the RADIUS server in the form of accounting records. These reports are analyzed and used by the RADIUS server for network management, client billing, auditing, and so on.

After the subscriber session is established, BNG initiates the Accounting Request packet to report the accounting record. This process is called an Accounting Start. BNG also sends the periodic update to report the status of the subscriber session to the RADIUS server, which is known as the periodic or interim accounting record.

During service deactivation, subscriber deletion, or SRG switchover to a standby role, BNG sends final accounting information to the RADIUS server. This process is called accounting Stop and the information is known as accounting Stop record. RADIUS server acknowledges with a response message.

If the accounting Stop is for a service accounting message then the information contains service data consumption details or if it is for a session accounting then the information contains session data consumption and other corresponding data.

If the link between the RADIUS server and BNG goes down or due to some other reason the RADIUS server did not receive the final accounting message, BNG will not receive the accounting response. This scenario leads to an unaccounted subscriber that causes revenue loss. This feature helps mitigate the issue.

When you enable this feature, if there’s a link failure between BNG and RADIUS server, BNG stores and maintains the accounting Stop record on the local hard disk until the BNG receives the acknowledgment from the RADIUS server or until the storage-time expires, which is configurable from 1 to 24 hours.

BNG stores and maintains the accounting Stop record till it reaches the maximum number of records that can be stored. You can configure the maximum number of records that can be stored from 64000 to 256000 using the subscriber manager accounting stop-storage record command.

The oldest accounting Stop records are deleted after the maximum count of the records is reached. Before deleting the record, BNG tries to verify if the RADIUs server is up.

BNG polls periodically to the RADIUS server and when there is no response from the RADIUS server, and if the configured record period expires then the corresponding record is be deleted. You can specify the record expiry period. The record expiry period ranges from 1 to 24 hours.

BNG resumes forwarding the accounting Stop record only when the connection between the RADIUS server and BNG is restored. If BNG doesn’t receive the acknowledgment message during the specified period, BNG deletes the record.

The RADIUS server accepts the data and sends an acknowledgment to BNG. Only after the acknowledgment is received from the RADIUS server, BNG deletes the accounting record. Thus this feature ensures that the accounting Stop record is transferred without any disruption or data loss.

When BNG sends accounting Stop message with the usage information to RADIUS server and RADIUS server sends the response through an acknowledgement message. For some reason, if the acknowledgement is lost, the message never reaches BNG. In such scenarios, BNG sends the accounting Stop message again and the RADIUS sever should act accordingly.

The Cisco-AV-pair attribute is present in the accounting stop message to indicate the RADIUS server that there is a possibility of getting duplicate final accounting message.

RADIUS server can take care of duplicate records using the following attribute.

The Per VRF AAA function allows authentication, authorization, and accounting (AAA) on the basis of virtual routing and forwarding (VRF) instances. This feature permits the Provider Edge (PE) or Virtual Home Gateway (VHG) to communicate directly with the customer's RADIUS server, (which is associated with the customer's Virtual Private Network (VPN)), without having to go through a RADIUS proxy.

ISPs must be able to define operational parameters such as AAA server groups, method lists, system accounting, and protocol-specific parameters, and associate those parameters to a particular VRF instance.

The Per VRF AAA feature is supported with VRF extensions to server-group, RADIUS, and system accounting commands. The list of servers in server groups is extended to include definitions of private servers, in addition to references to the hosts in the global configuration. This allows simultaneous access to both customer servers and global service provider servers. The syntax for the command used to configure per-vrf AAA globally is:

radius source-interface subinterface-name [vrf vrf-name]

From Cisco IOS XR Software Release 5.3.1 and later, RADIUS over IPv6 is supported in BNG, thereby allowing IPv6 address also for various RADIUS configurations and CoA client configurations.

For details on configuring RADIUS server group and settings, see Configuring RADIUS Server Group and Configuring RADIUS Server Settings.

Starting with Cisco IOS XR Software Release 6.6.3, in BNG with dynamic policy push, a complete service definition is downloaded over the RADIUS interface. When a subscriber accesses a BNG with service, BNG triggers the service download from RADIUS, if that service definition does not exist on the BNG box.

RADIUS sends input policy, output policy, or both, along with service accounting enable information. Merge accounting statistics is a subset of Dynamic Policy Download, and more information about it can be found in Merge and Account Statistics.