close

keyboard_arrow_left

Table of Contents Expand all

play_arrow Subscriber Service Activation and Management
- play_arrow Subscriber Service Activation and Management
play_arrow Configuring Dynamic Class of Service
- play_arrow CoS for Subscriber Access and Interfaces Overview
- play_arrow Configuring Scheduling and Shaping for Subscriber Access
- play_arrow Allocating Dedicated Queues for Each Logical Interface Using Per-Unit Scheduling
- play_arrow Configuring Hierarchical CoS Scheduling on MPLS Ethernet Pseudowire Subscriber Interfaces
- play_arrow Configuring Dedicated Queue Scaling with Hierarchical CoS or Per-Unit Scheduling
- play_arrow Shaping Downstream Traffic Based on Frames or Cells
- play_arrow Applying CoS to Households or Individual Subscribers Using ACI-Based Dynamic VLANs
- play_arrow Applying CoS to Households or Individual Subscribers Using Access Line Identifier Dynamic VLANs
- play_arrow Managing Excess Bandwidth Distribution and Traffic Bursts
- play_arrow Applying CoS Using Parameters Received from RADIUS
- play_arrow Modifying a Subscriber’ s Shaping Characteristics After a Subscriber is Instantiated
- play_arrow Applying CoS to Groups of Subscriber Interfaces
- play_arrow Applying CoS to Subscriber Interfaces
play_arrow Configuring Dynamic Filters and Policers
- play_arrow Dynamic Firewall Filters Overview
  - Understanding Dynamic Firewall Filters
  - Defining Dynamic Filter Processing Order
- play_arrow Configuring Static Firewall Filters That Are Dynamically Applied
- play_arrow Streamlining Processing of Chains of Static Filters
  - Configuring Firewall Filter Bypass
  - Example: Bypassing Firewall Filters
- play_arrow Dynamically Attaching Static or Fast Update Filters to an Interface
  - Dynamically Attaching Statically Created Filters for a Specific Interface Family Type
  - Dynamically Attaching Statically Created Filters for Any Interface Type
- play_arrow Configuring Filters That Are Created Dynamically
- play_arrow Using Ascend Data Filters to Implement Firewalls Based on RADIUS Attributes
- play_arrow Configuring Fast Update Filters to Provide More Efficient Processing Over Classic Static Filters
- play_arrow Defending Against DoS and DDoS Attacks Using Unicast RPF and Fail Filters
  - Unicast RPF in Dynamic Profiles for Subscriber Interfaces
- play_arrow Improving Scaling and Performance of Filters on Static Subscriber Interfaces
  - Firewall Filters and Enhanced Network Services Mode Overview
  - Configuring a Filter for Use with Enhanced Network Services Mode
- play_arrow Configuring Dynamic Service Sets
- play_arrow Configuring Rate-Limiting Premium and Non-Premium Traffic on an Interface Using Hierarchical Policers
- play_arrow Monitoring and Managing Firewalls for Subscriber Access
  - Verifying and Managing Firewall Filter Configuration
  - Enhanced Policer Statistics Overview
play_arrow Configuring Dynamic Multicast
- play_arrow Configuring Dynamic IGMP to Support IP Multicasting for Subscribers
- play_arrow Configuring Dynamic MLD to Enable Subscribers to Access Multicast Networks
  - Dynamic MLD Configuration Overview
play_arrow Configuring Application-Aware Policy Control and Reporting
play_arrow Configuring HTTP Redirect Services
- play_arrow Configuring Captive Portal Content Delivery Services for Redirected Subscribers
play_arrow Configuring Subscriber Secure Policy
- play_arrow Configuring Subscriber Secure Policy Traffic Mirroring Overview
  - Subscriber Secure Policy Overview
- play_arrow Configuring RADIUS-Initiated Subscriber Secure Policy Traffic Mirroring
- play_arrow Configuring DTCP-Initiated Subscriber Secure Policy Traffic Mirroring
- play_arrow Configuring DTCP Messages Used for DTCP-Initiated Subscriber Secure Policy Mirroring
- play_arrow Configuring Subscriber Secure Policy Support for IPv4 Multicast Traffic
  - Subscriber Secure Policy Support for IPv4 Multicast Traffic
  - Enabling Subscriber Secure Policy Mirroring for IPv4 Multicast Traffic
- play_arrow Configuring Intercept-Related Information for Subscriber Secure Policy
play_arrow Configuring Stateless, Rule-Based Services Using Application-Aware Access Lists
- play_arrow AACL Overview
  - AACL Overview
- play_arrow Configuring AACL Rules
  - Configuring AACL Rules
- play_arrow Example: Configuring AACL Rules
  - Example: Configuring AACL Rules
- play_arrow Example: Configuring AACL Rule Sets
  - Configuring AACL Rule Sets
- play_arrow Configuring Logging of AACL Flows
  - Configuring Logging of AACL Flows
play_arrow Remote Device and Service Management
- play_arrow Configuring Remote Device Services Management
- play_arrow Configuring TCP Port Forwarding for Remote Subscriber Services
- play_arrow Configuring IPFIX Mediation for Remote Device Monitoring
  - IPFIX Mediation on the BNG
  - Configuring the BNG as an IPFIX Mediator to Collect and Export IPFIX Data
- play_arrow Collection and Export of Local Telemetry Data on the IPFIX Mediator
  - Telemetry Data Collection on the IPFIX Mediator for Export to an IPFIX Collector
  - Configuring the Collection and Export of Local Telemetry Data on the IPFIX Mediator
play_arrow Troubleshooting
- play_arrow Contacting Juniper Networks Technical Support
  - Collecting Subscriber Access Logs Before Contacting Juniper Networks Technical Support
- play_arrow Knowledge Base
  - Juniper Knowledge Base
play_arrow Configuration Statements and Operational Commands

list Table of Contents

English

Using RADIUS Dynamic Requests for Subscriber Access Management
Configuring RADIUS-Initiated Dynamic Request Support
RADIUS-Initiated Change of Authorization (CoA) Overview
RADIUS-Initiated Disconnect Overview
Usage Thresholds for Subscriber Services
Subscriber Session Logins and Service Activation Failures Overview
Configuring How Service Activation Failures Affect Subscriber Login
Error-Cause Codes (RADIUS Attribute 101) for Dynamic Requests
Verifying RADIUS Dynamic-Request Statistics
Change History Table

keyboard_arrow_right

Dynamic Service Management with RADIUS

date_range 05-Sep-24

arrow_backward

arrow_forward

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.

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.

content_copy zoom_out_map
[edit access profile isp-bos-metro-fiber-basic radius] 
user@host# set authentication-server 192.168.1.3

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

Specify the IP addresses of multiple RADIUS servers.

content_copy zoom_out_map
[edit access profile isp-bos-metro-fiber-basic radius] 
user@host# set authentication-server 192.168.1.3 192.168.10.15

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:

content_copy zoom_out_map
[edit access]
user@host# set radius-server server-address dynamic-request-port port-number

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

content_copy zoom_out_map
[edit access]
user@host# set profile profile-name radius-server server-address dynamic-request-port port-number

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.
```
[edit access]
user@host# set radius-server 192.0.2.1
user@host# set profile ap1 radius-server 192.0.2.3
```
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.
```
[edit access]
user@host# set radius-server 192.0.2.1 dynamic-request-port 50201
user@host# set profile ap1 radius-server 192.0.2.3 dynamic-request-port 50201
```
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.
```
[edit access]
user@host# set radius-server 192.0.2.1 dynamic-request-port 50201
user@host# set profile ap1 radius-server 192.0.2.1 dynamic-request-port 51133 
```
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.
```
[edit access]
user@host# set radius-server 192.0.2.1
user@host# set radius-server 192.0.2.3 dynamic-request-port 51133
```

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
Qualifications for Change of Authorization
Message Exchange
Bulk CoA Transactions
Benefits of Radius-Initiated Change of Authorization

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.

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
Qualifications for Disconnect
Message Exchange
Benefits of Radius-Initiated Disconnects

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.

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`

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:

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.
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.
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.
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.
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.
authd reviews the cached service activation attributes and requests activation for the services associated with the requested address family.
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.

content_copy zoom_out_map
[edit access profile profile-name radius options service-activation]
user@host# set dynamic-profile optional-at-login

Specify that service activation is required (the default).

content_copy zoom_out_map
[edit access profile profile-name radius options service-activation]
user@host# set dynamic-profile required-at-login

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

Specify that service activation is required.

content_copy zoom_out_map
[edit access profile profile-name radius options service-activation]
user@host# set extensible-service required-at-login

Specify that service activation is optional (the default).

content_copy zoom_out_map
[edit access profile profile-name radius options service-activation]
user@host# set extensible-service optional-at-login

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).

Verifying RADIUS Dynamic-Request Statistics

Purpose
Action

Purpose

Display RADIUS dynamic request statistics and information.

Action

To display RADIUS dynamic request statistics:
```
user@host>show network-access aaa statistics dynamic-requests
```

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

arrow_backward PREVIOUS Broadband Subscriber Services User Guide

NEXT arrow_forward Service Activation and Deactivation Using the CLI Instead of RADIUS

Broadband Subscriber Services User Guide

ON THIS PAGE

Dynamic Service Management with RADIUS

Using RADIUS Dynamic Requests for Subscriber Access Management

Benefits of Radius Dynamic Requests

Configuring RADIUS-Initiated Dynamic Request Support

RADIUS-Initiated Change of Authorization (CoA) Overview

CoA Messages

Qualifications for Change of Authorization

Message Exchange

Bulk CoA Transactions

Benefits of Radius-Initiated Change of Authorization

RADIUS-Initiated Disconnect Overview

Disconnect Messages

Qualifications for Disconnect

Message Exchange

Benefits of Radius-Initiated Disconnects

Usage Thresholds for Subscriber Services

Subscriber Session Logins and Service Activation Failures Overview

Service and Network Family Activation Process

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

Verifying RADIUS Dynamic-Request Statistics

Purpose

Action

Change History Table

Stay in touch

Helped me install or use the product
Accelerated my deployment

Discuss the product with a co-worker
Make a purchase inquiry

Broadband Subscriber Services User Guide

ON THIS PAGE

Dynamic Service Management with RADIUS

Using RADIUS Dynamic Requests for Subscriber Access Management

Benefits of Radius Dynamic Requests

See Also

Configuring RADIUS-Initiated Dynamic Request Support

See Also

RADIUS-Initiated Change of Authorization (CoA) Overview

CoA Messages

Qualifications for Change of Authorization

Message Exchange

Bulk CoA Transactions

Benefits of Radius-Initiated Change of Authorization

See Also

RADIUS-Initiated Disconnect Overview

Disconnect Messages

Qualifications for Disconnect

Message Exchange

Benefits of Radius-Initiated Disconnects

See Also

Usage Thresholds for Subscriber Services

See Also

Subscriber Session Logins and Service Activation Failures Overview

Service and Network Family Activation Process

Configuring How Service Activation Failures Affect Subscriber Login

See Also

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

See Also

Verifying RADIUS Dynamic-Request Statistics

Purpose

Action

See Also

Change History Table

Stay in touch