Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Dynamic Service Management with RADIUS

Using RADIUS Dynamic Requests for Subscriber Access Management

RADIUS dynamic requests provide an efficient way to centrally manage subscriber sessions. The AAA Service Framework’s RADIUS dynamic request support allows RADIUS servers to initiate user-related operations, such as a termination operation, by sending unsolicited request messages to the router. Without the RADIUS dynamic request feature, the only way to disconnect a RADIUS user is from the router, which can be cumbersome and time-consuming in large networks.

In a typical client-server RADIUS environment, the router functions as the client and initiates requests sent to the remote RADIUS server. However, when using RADIUS dynamic requests, the roles are reversed. For example, during a disconnect operation, the remote RADIUS server performs as the client and initiates the request (the disconnect action) — the router functions as the server in the relationship.

You create an access profile to configure the router to support RADIUS dynamic requests. This configuration enables the router to receive and act on the following types of messages from remote RADIUS servers:

  • Access-Accept messages—Dynamically activate services based on attributes in RADIUS Access-Accept messages received when a subscriber logs in.

  • Change-of-Authorization (CoA) messages—Dynamically modify active sessions based on attributes in CoA messages. CoA messages can include service creation requests, deletion requests, RADIUS attributes, and Juniper Networks VSAs.

  • Disconnect messages—Immediately terminate specific subscriber sessions.

By default, the router monitors UDP port 3799 for CoA requests from RADIUS servers. You can also configure a nondefault port for RADIUS servers. You must either use the default port for all RADIUS servers or configure the same nondefault port for all RADIUS servers. This rule applies at both the global access and access profile levels.

Note:

Any other configuration results in a commit check failure. Multiple port numbers—that is, different port numbers for different servers—are not supported.

Benefits of Radius Dynamic Requests

Enables simplified central management of subscriber sessions by sending unsolicited changes to subscriber sessions, including changes in attributes, service activation, service deactivation, and session termination.

See Also

Configuring RADIUS-Initiated Dynamic Request Support

The router uses the list of specified RADIUS authentication servers for both authentication and dynamic request operations. By default, the router monitors UDP port 3799 for dynamic requests, also known as Change of Authorization (CoA) requests.

To configure RADIUS dynamic request support:

  • Specify the IP address of the RADIUS server.

To configure the router to support dynamic requests from more than one RADIUS server:

  • Specify the IP addresses of multiple RADIUS servers.

When you configure dynamic request ports, you must do one of the following:

  • Use the default port for all RADIUS servers at both the global access level and in all access profiles.

  • Configure the same nondefault port for all servers at both the global access level and in all access profiles.

Note:

Any other configuration results in a commit check failure. Multiple port numbers—that is, different port numbers for different servers—are not supported.

To specify a global dynamic request port:

To specify the dynamic request port for a specific access profile:

Consider the following scenarios:

  • The following configuration uses the default port for both a server globally and a different server in the access profile. This is a valid configuration.

  • The following configuration specifies nondefault port 50201 for both a server globally and a different server in the access profile. This is a valid configuration.

  • The following configuration specifies port 50201 globally for a server and port 51133 for the same server in the ap1 access profile. This is an invalid configuration and commit check fails, because multiple nondefault ports are not supported.

  • The following configuration uses the default port 3799 for one server globally and port 51133 for another server globally. This is an invalid configuration and the commit check fails, because for all servers you must configure either the default port or the same nondefault port.

See Also

RADIUS-Initiated Change of Authorization (CoA) Overview

The AAA Service Framework uses CoA messages to dynamically modify active subscriber sessions. For example, RADIUS attributes in CoA messages might instruct the framework to create, modify, or terminate a subscriber service. You can also use CoA messages to set or modify usage thresholds for current subscriber services.

CoA Messages

Dynamic request support enables the router to receive and process unsolicited CoA messages from external RADIUS servers. RADIUS-initiated CoA messages use the following codes in request and response messages:

  • CoA-Request (43)

  • CoA-ACK (44)

  • CoA-NAK (45)

Qualifications for Change of Authorization

To complete the change of authorization for a user, you specify identification attributes and session attributes. The identification attributes identify the subscriber. Session attributes specify the operation (activation or deactivation) to perform on the subscriber’s session and also include any client attributes for the session (for example, QoS attributes). The AAA Service Framework handles the actual request.

Table 1 shows the identification attributes for CoA operations.

Table 1: Identification Attributes

Attribute

Description

User-Name [RADIUS attribute 1]

Subscriber username.

Acct-Session-ID [RADIUS attribute 44]

Specific subscriber session.
Note:

Using the Acct-Session-ID attribute to identify the subscriber session is more explicit than using the User-Name attribute. When you use the User-Name as the identifier, the CoA operation is applied to the first session that was logged in with the specified username. However, because a subscriber might have multiple sessions associated with the same username, the first session might not be the correct session for the CoA operation.

When you use the Acct-Session-ID attribute, it identifies the specific subscriber session, avoiding that potential error. Although the Acct-Session-ID attribute can include an interface specifier in addition to the session ID—when the attribute is in the description format—only the session ID is used for subscriber matching. For example, if the subscriber has a subscriber session ID of 54785, then the subscriber is matched when the Acct-Session-ID attribute is 54785 (decimal format), or jnpr demux0.1073759682:54785 (description format), or indeed any value:54785 (description format).

Table 2 shows the session attributes for CoA operations. Any additional client attributes that you include depend on your particular session requirements.

Table 2: Session Attributes

Attribute

Description

Activate-Service [Juniper Networks VSA 26-65]

Service to activate for the subscriber.

Deactivate-Service [Juniper Networks VSA 26-66]

Service to deactivate for the subscriber.

Service-Volume [Juniper Networks VSA 26-67]

Amount of traffic, in MB, that can use the service; service is deactivated when the volume is exceeded.

Service-Timeout [Juniper Networks VSA 26-68]

Number of seconds that the service can be active; service is deactivated when the timeout expires.

Service-Volume-Gigawords [Juniper Networks VSA 26-179]

Amount of traffic, in 4GB units, that can use the service; service is deactivated when the volume is exceeded.

Update-Service [Juniper Networks VSA 26-180]

New values of service and time quotas for existing service.

Message Exchange

The RADIUS server and the AAA Service Framework on the router exchange messages using UDP. The CoA-Request message sent by the RADIUS server has the same format as the Disconnect-Request packet that is sent for a disconnect operation.

The response is either a CoA-ACK or a CoA-NAK message:

  • If the AAA Service Framework successfully changes the authorization, the response is a RADIUS-formatted packet with a CoA-ACK message, and the data filter is applied to the session.

  • If AAA Service Framework is unsuccessful, the request is malformed, or attributes are missing, the response is a RADIUS-formatted packet with a CoA-NAK message.

Note:

The AAA Service Framework processes one dynamic request at a time per subscriber. If the framework receives a second dynamic request (either another CoA or a Disconnect-Request) while processing a previous request for the same subscriber, the framework responds with a CoA-NAK message. Starting in Junos OS Release 15.1R5, CoA-Request retry messages are ignored and no CoA-NAK is sent in response to them.

Bulk CoA Transactions

Starting in Junos OS Release 17.2R1, bulk CoA requests are supported to improve the processing efficiency of RADIUS-based subscriber services on the BNG. The bulk CoA functionality enables the accumulation of a series of CoA requests and commits all of them together, in bulk, automatically.

All the services in a bulk CoA request must be for the same subscriber session.

Bulk CoA transactions are particularly valuable for business services. RADIUS-based subscriber services use the Juniper Networks VSAs, Activate-Service (26-65) and Deactivate-Service (26-66). The VSAs are provided in RADIUS-Accept messages during login or in CoA requests after login.

For conventional, dynamic service profile-based services, up to 12 service activations can easily fit within either RADIUS message. However, the op-script based services used by businesses typically have scaling requirements that exceed the capacity of either message. This means that specifying and activating all the services needed in a given subscriber session may require using an Accept-Access message and multiple CoA requests.

Each CoA request message is independent of previous and future CoA requests in the same subscriber session. All service-activations and deactivations in a message are processed before a CoA response is offered. The CoA request provides a way to incrementally modify a subscriber session without affecting existing services that are already present.

For op-script based services, the service sessions are collaboratively created by the authd and essmd processes such that the last operation initiates a commit to apply all resultant static business logical interfaces from the CoA request. Because the commit time is generally the largest part of applying a static business service, there is an advantage to packing as many service-activations or deactivations as will fit within a RADIUS message to efficiently use the commit window. Until the commit operation completes, the BNG cannot accept a subsequent CoA request to apply additional business services for the same subscriber session.

Bulk CoA improves the efficiency of commit processing by using a single commit action for all services in the bulk transaction. The bulk transaction has the effect of managing a series of requests as a single meta-request. It defers the commit processing until the final CoA request in the bulk transaction is received.

Bulk CoA requires each individual request to contain a single instance of the Juniper Networks Bulk-CoA-Transaction-Id VSA (26–194). This VSA identifies requests as belonging to the same bulk transaction; 26–194 must have the same value in all CoA requests in the bulk series. Each successive bulk transaction in the session must have a different identifier; for example, three successive bulk transactions can have IDs of 1, 2, and 1, but cannot have successive IDs of 1, 1, and 2. In practice, the Bulk-CoA-Transaction-Id value typically is incremented for multiple bulk transactions, but this is not required. An ID value used in a given subscriber session can also be used in different subscriber sessions.

Each CoA request within a bulk transaction has its own unique identifier, provided by a single instance of the Bulk-CoA-Identifier VSA (26–195) in each CoA. An increasing series of values for the ID is typical but not enforced. Values can be reused within a given session and between sessions. The final CoA request in the series is identified by having a value of 0xFFFFFFFF for the Bulk-CoA-Identifier.

Benefits of Radius-Initiated Change of Authorization

Enables changes in attribute values to be dynamically pushed to subscriber sessions, as well as dynamic activation and deactivation of subscriber services.

See Also

RADIUS-Initiated Disconnect Overview

This section describes the AAA Service Framework’s support for RADIUS-initiated disconnect dynamic requests. The AAA Service Framework uses disconnect messages to dynamically terminate active subscriber sessions.

Disconnect Messages

To centrally control the disconnection of remote access subscribers, the RADIUS dynamic request feature on the router receives and processes unsolicited messages from RADIUS servers.

The dynamic request feature uses the existing format of RADIUS disconnect request and response messages. RADIUS-initiated disconnect uses the following codes in its RADIUS request and response messages:

  • Disconnect-Request (40)

  • Disconnect-ACK (41)

  • Disconnect-NAK (42)

Qualifications for Disconnect

For the AAA Service Framework to disconnect a user, the Disconnect-Request message must contain an attribute with an accounting session ID. The Disconnect-Request message can contain an Acct-Session-Id (44) attribute or an Acct-Multi-Session-Id (50) attribute for the session ID or both. If both the Acct-Session-Id and Acct-Multi-Session-Id attributes are present in the request, the router uses both attributes. If the User-Name (1) attribute is also present in the request, the username and accounting session ID are used to perform the disconnection. The AAA Service Framework handles the actual request.

Message Exchange

The RADIUS server and the AAA Service Framework exchange messages using UDP. The Disconnect-Request message sent by the RADIUS server has the same format as the CoA-Request packet that is sent for a change of authorization operation.

The disconnect response is either a Disconnect-ACK or a Disconnect-NAK message:

  • If the AAA Service Framework successfully disconnects the user, the response is a RADIUS-formatted packet with a Disconnect-ACK message.

  • If the AAA Service Framework cannot disconnect the user, the request is malformed, or attributes are missing from the request, the response is a RADIUS-formatted packet with a Disconnect-NAK message.

Note:

The AAA Service Framework processes one dynamic request at a time per subscriber. If the framework receives a second dynamic request while processing a previous request (either a CoA or another Disconnect-Request) for the same subscriber, the framework responds with a Disconnect-NAK message.

Benefits of Radius-Initiated Disconnects

Enables a RADIUS server to dynamically terminate subscriber sessions. This centralized subscriber management feature simplifies handling large numbers of subscribers because operator termination would otherwise require action on the router.

See Also

Usage Thresholds for Subscriber Services

Starting in Junos OS Release 14.1, subscriber management enables you to manage subscriber services by establishing usage thresholds when a service is dynamically activated or when an existing service is modified by a RADIUS CoA action. The service is deactivated when the specified threshold is reached.

Subscriber management supports two types of usage thresholds—traffic volume and time. You use Juniper Networks VSAs to set the usage thresholds. The VSAs are transmitted in RADIUS Access-Accept messages for dynamically activated services, or in RADIUS-initiated CoA-Request messages for existing services. The volume threshold sets the maximum amount of the total input and output traffic that can use the service before the service is deactivated. A time threshold sets the maximum length of time that the service can be active. Table 3 shows the VSAs used for volume and time thresholds.

Table 3: Juniper Network VSAs Used for Service Thresholds

Attribute Number

Attribute Name

Description

Value

26-67

Service-Volume

Amount of input and output traffic, in MB, that can use the service; service is deactivated when the volume is exceeded. Tagged VSA, which supports 8 tags (1-8). The router polls the traffic in 10 minute intervals.

  • range = 0 through 16777215 MB

  • 0 = no limit

26-68

Service-Timeout

Number of seconds that the service can be active; service is deactivated when the timeout expires. Tagged VSA, which supports 8 tags (1-8).

  • range = 0 through 16777215 seconds

  • 0 = no timeout

26-179

Service-Volume-Gigawords

Amount of input and output traffic, in 4GB units, that can use the service; service is deactivated when the volume is exceeded. Tagged VSA, which supports 8 tags (1-8). The router polls the traffic in 10 minute intervals.

  • range = 0 through 16777215 4GB units

  • 0 = no limit

26-180

Update-Service

New values of service and time quotas for an existing service. Tagged VSA, which supports 8 tags (1-8).

string: service-name

See Also

Subscriber Session Logins and Service Activation Failures Overview

When a subscriber attempts to log in and is authenticated by RADIUS, the Access-Accept message may include services in the RADIUS Activate-Service VSA (26-65) to be activated for a particular network family. Depending on the configuration and service type, failure to activate a service can result in denial of the subscriber login.

You can use the service activation statement at the [edit access profile profile-name radius options] hierarchy level to configure the behavior subsequent to an activation failure.

Use the following options to configure this behavior separately for two types of services:

  • dynamic-profile—This service type is configured in the dynamic profile that is applied by the subscriber access profile.

  • extensible-service—This service type is configured in an Extensible Subscriber Services Manager (ESSM) operation script. These services often configure new interfaces for business subscribers.

Use the following options to specify whether successful activation of these services is required or optional for subscriber login access:

  • required-at-login—Activation is required. Failure for any reason causes the Network-Family-Activate-Request for that network family to fail. If no other network family is already active for the subscriber, then the client application logs out the subscriber. This is the default behavior for the dynamic-profile service type.

  • optional-at-login—Activation is optional. Failure due to configuration errors does not prevent activation of the address family; it allows subscriber access. Failure for any other reason causes network family activation to fail. If no other network family is already active for the subscriber, then the client application logs out the subscriber. This is the default behavior for the extensible-service service type.

Note:

Failures associated with the activation of subscriber secure policies (for mirroring traffic to a mediation device) have no effect on access by subscribers subject to the policy.

This configuration does not apply to services activated by means of RADIUS CoA requests, JSRC Push-Profile-Request (PPR) messages, or subscriber secure policies.

For the dynamic-profile service type, configuration errors include the following:

  • Parsing errors of the dynamic profile and its attributes.

  • Missing mandatory user variables.

  • References to dynamic profiles that do not exist.

  • Semantic check failures in the dynamic profile.

For the extensible-service service type, configuration errors include the following:

  • Parsing errors of the operation script.

  • Commit failures.

To activate a service, authd sends an activation request for the appropriate services to the subscriber management infrastructure (SMI). For example, if the request is for the IPv4 family, then it requests activation of only the IPv4 services. In turn, the SMI sends requests to the server daemons associated with the service, such as cosd or filterd. The results returned by the daemons determine whether the service activation is a success or a failure.

  • When all server daemons report success, then SMI reports success to authd and the service is activated.

  • If any server daemon reports a configuration error and no daemons report a nonconfiguration error, then SMI reports a configuration error to authd. The service is not activated, but depending on the configuration, the network family activation may succeed.

  • If any server daemon reports a nonconfiguration error, then SMI reports failure to authd and the service is not activated.

Service and Network Family Activation Process

When a subscriber logs in, authd has to activate the corresponding address family after the subscriber is authenticated. The client application, such as DHCP or PPP, can request activation of a single network family, IPv4 or IPv6, or it can sequentially request both families to be activated. Successful network family activation is related to the activation of associated services. The following steps describe the process when authd is configured to use RADIUS for authentication:

  1. A subscriber attempts to log in.

    1. The client application requests authentication from authd.

    2. authd sends an Access-Request message to the RADIUS server.

    3. The RADIUS server sends an Access-Accept message to authd that includes the RADIUS Activate-Service VSA (26-65).

    4. authd caches the service activation attributes and sends a grant to the client application.

  2. The client application sends the first Network-Family-Activate request, for either the IPv4 or IPv6 address family. This request is sometimes referred to as the client-activate request.

  3. authd reviews the cached service activation attributes and sends an activation request for the appropriate services to the subscriber management infrastructure (SMI). For example, if the request is for the IPv4 family, then it requests activation of only the IPv4 services. In turn, the SMI sends requests to the server daemons associated with the service, such as cosd or filterd.

  4. What authd does next depends on whether the service activation request fails and whether the service is optional or required.

    • When the service activation fails due to a configuration error and the service is optional:

      1. authd deletes the cached service activation attributes for the service.

        Note:

        This deletion enables you to re-issue the service request by using a RADIUS change of authorization (CoA) request or a CLI command, without interference from the failed service.

      2. authd sends an ACK in response to the family activation request and the family is activated.

      3. The subscriber login proceeds.

    • When the service activation fails due to a configuration error and the service is required:

      1. authd deletes the cached service activation attributes for the service.

        Note:

        This deletion enables you to re-issue the service request by using a RADIUS change of authorization (CoA) request or a CLI command, without interference from the failed service.

      2. authd sends a NACK in response to the family activation, which causes the client application to terminate the subscriber's login.

    • When the service activation fails due to a nonconfiguration error and the service is either optional or required:

      1. authd deletes the cached service activation attributes for the service.

        Note:

        This deletion enables you to re-issue the service request by using a RADIUS change of authorization (CoA) request or a CLI command, without interference from the failed service.

      2. authd sends a NACK in response to the family activation, which causes the client application to terminate the subscriber's login.

    • When the service activation succeeds:

      1. authd activates the service.

      2. authd sends an ACK in response to the family activation request and the family is activated.

      3. The subscriber login proceeds.

  5. Unless service activation was required and failed, causing the family activation to fail in the first request, the client application may send a second request, but only for the family not requested the first time. If the first request was for IPv4, then the second request can only be for IPv6. If the first request was for IPv6, then the second request can only be for IPv4.

  6. authd reviews the cached service activation attributes and requests activation for the services associated with the requested address family.

  7. What authd does next depends on whether the service activation request fails and whether the service is optional or required.

    • When the service activation fails due to a configuration error and the service is optional:

      1. authd deletes the cached service activation attributes for the service.

        Note:

        This deletion enables you to re-issue the service request by using a RADIUS change of authorization (CoA) request or a CLI command, without interference from the failed service.

      2. authd sends an ACK in response to the family activation request and the family is activated.

      3. The subscriber login proceeds.

    • When the service activation fails due to a configuration error and the service is required:

      1. authd deletes the cached service activation attributes for the service.

        Note:

        This deletion enables you to re-issue the service request by using a RADIUS change of authorization (CoA) request or a CLI command, without interference from the failed service.

      2. authd sends a NACK in response to the family activation. Because this is the second family activation request, the result of the first family activation determines what happens next:

        • If the first family activation was successful and that subscriber logged in, failure of the second request does not halt the current subscriber login. This event also does not cause authd to log out the previous (first request) subscriber.

        • If the first family activation was unsuccessful, failure of the second request causes the client application to terminate the current subscriber login.

    • When the service activation fails due to a nonconfiguration error and the service is either optional or required:

      1. authd deletes the cached service activation attributes for the service.

        Note:

        This deletion enables you to re-issue the service request by using a RADIUS change of authorization (CoA) request or a CLI command, without interference from the failed service.

      2. authd sends a NACK in response to the family activation, which causes the client application to terminate the subscriber's login.

    • When the service activation succeeds:

      1. authd activates the service.

      2. authd sends an ACK in response to the family activation request and the family is activated.

      3. The subscriber login proceeds.

Configuring How Service Activation Failures Affect Subscriber Login

You can configure how an activation failure of optional services during subscriber login affects the outcome of the login. These optional services are those referenced by the RADIUS Activate-Service VSA (26-65) that appears in the RADIUS Access-Accept message during the subscriber’s initial login.

You can configure these two service-activation types to be required or optional.

  • dynamic-profile—These services are configured in the dynamic profile that is applied by the subscriber access profile to provide subscriber access and services for broadband applications. By default, service activation is required for successful login. A configuration error during service activation prevents the network family from being activated and causes the subscriber login to fail.

  • extensible-service—These services are applied by operation scripts handled by the Extensible Subscriber Services Manager (ESSM) daemon (essmd) for business subscribers. By default, service activation is optional for successful subscriber login.

Note:

The service-activation statement configuration affects only activation failures due to configuration errors in the dynamic profile or the ESSM operation script. Failures due to nonconfiguration errors always result in denial of access for the subscriber and termination of the login attempt.

To configure the behavior for dynamic profile services, do one of the following:

  • Specify that service activation is optional.

  • Specify that service activation is required (the default).

To configure the behavior for ESSM services, do one of the following:

  • Specify that service activation is required.

  • Specify that service activation is optional (the default).

See Also

Error-Cause Codes (RADIUS Attribute 101) for Dynamic Requests

When a RADIUS-initiated CoA or disconnect operation is unsuccessful, the router includes an error-cause attribute (RADIUS attribute 101) in the CoA-NAK or Disconnect-NAK message that it sends back to the RADIUS server. If the detected error does not map to one of the supported error-cause attributes, the router sends the message without an error-cause attribute. Table 4 describes the error-cause codes.

Table 4: Error-Cause Codes (RADIUS Attribute 101)

Code

Value

Description

401

Unsupported attribute

The request contains an attribute that is not supported (for example, a third-party attribute).

402

Missing attribute

A critical attribute (for example, the session identification attribute) is missing from a request.

404

Invalid request

Some other aspect of the request is invalid, such as if one or more attributes are not formatted properly.

503

Session context not found

The session context identified in the request does not exist on the router.

504

Session context not removable

The subscriber identified by attributes in the request is owned by a component that is not supported.

506

Resources unavailable

A request could not be honored due to lack of available NAS resources (such as memory).

See Also

Verifying RADIUS Dynamic-Request Statistics

Purpose

Display RADIUS dynamic request statistics and information.

Action

  • To display RADIUS dynamic request statistics:

See Also

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
17.2R1
Starting in Junos OS Release 17.2R1, bulk CoA requests are supported to improve the processing efficiency of RADIUS-based subscriber services on the BNG.
15.1R5
Starting in Junos OS Release 15.1R5, CoA-Request retry messages are ignored and no CoA-NAK is sent in response to them.
14.1
Starting in Junos OS Release 14.1, subscriber management enables you to manage subscriber services by establishing usage thresholds when a service is dynamically activated or when an existing service is modified by a RADIUS CoA action.