RADIUS Servers and Parameters for Subscriber Access
Configuring parameters and options for RADIUS servers is a major part of your subscriber management configuration. After defining the authentication and accounting servers, you configure options for all RADIUS servers. You also configure access profiles that enable you to specify subscriber access authentication, authorization and accounting configuration parameters for subscribers or groups of subscribers. The profile settings override global settings. Although some options are available at both the global level and the access profile level, many options are available only in access profiles.
After you have created an access profile, you must specify where
the profile is used with an access-profile
statement; this
is known as attaching the profile. Access profiles can be assigned
at various levels. For example, some of places you can attach access
profiles
Globally for a routing instance.
In dynamic profiles.
In a domain map, which maps access options and session parameters for subscriber sessions.
On the interfaces for dynamic VLANs and dynamic stacked VLANs.
On the interface or in a subscriber group for subscribers with statically configured interfaces for dynamic service provisioning.
On DHCP relay agents and DHCP local servers for DHCP clients or subscribers.
Because you can attach access profiles at many levels, the most specific access profile takes precedence over any other profile assignments to avoid conflict. Authentication and accounting do not run unless you attach the profile.
RADIUS Authentication and Accounting Server Definition
When you use RADIUS for subscriber management, you must define one or more external RADIUS servers that the router communicates with for subscriber authentication and accounting. Besides specifying the IPv4 or IPv6 address of the server, you can configure options and attributes that determine how the router interacts with the specified servers.
You can define RADIUS servers and connectivity options at the [edit access radius-server]
hierarchy level, at the [edit
access profile name radius-server]
hierarchy
level, or at both levels.
The AAA process (authd) determines which server definitions to use as follows:
When RADIUS server definitions are present only in
[edit access radius-server]
, authd uses those definitions.When RADIUS server definitions are present only in the access profile, authd uses those definitions.
When RADIUS server definitions are present in both
[edit access radius-server]
and in the access profile, authd uses only the access profile definitions.
To use a RADIUS server, you must designate it as an authentication
server, an accounting server, or both, in an access profile. You must
do so for servers regardless of whether they are defined in an access
profile or at the [edit access radius-server]
hierarchy
level.
To define RADIUS servers and to specify how the router interacts with the server:
This procedure shows only the [edit access radius-server]
hierarchy level. You can optionally configure any of these parameters
at the [edit access profile profile-name] radius-server]
hierarchy level. You can do so either in addition
to the global setting or instead of the global setting. When you apply
a profile, the profile settings override the global configuration.
Configuring Options that Apply to All RADIUS Servers
You can configure RADIUS options that apply to all RADIUS servers globally.
To configure RADIUS options globally:
Configuring a Timeout Grace Period to Specify When RADIUS Servers Are Considered Down or Unreachable
When a RADIUS authentication server fails to respond to any of the attempts for a given authentication request and times out, authd notes the time for reference, but it does not immediately mark the server as down (if other servers are available) or unreachable (if it is the only configured server). Instead, a configurable grace period timer starts at the reference time. The grace period is cleared if the server responds to a subsequent request before the period expires.
During the grace period, the server is not marked as down or unreachable. Each time the server times out for subsequent requests to that server, authd checks whether the grace period has expired. When the check determines that the grace period has expired and the server has still not responded to a request, the server is marked as unreachable or down.
Using a short grace period enables you to more quickly abandon an unresponsive server and direct authentication requests to other available servers. A long grace period gives a server more opportunities to respond and may avoid needlessly abandoning a resource. You might specify a longer grace period when you have only one or a small number of configured servers.
To configure the grace period during which an unresponsive RADIUS server is not marked as unreachable or down:
Specify the duration of the grace period.
[edit access radius-options] user@host# set timeout-grace seconds
Configuring Access Profile Options for Interactions with RADIUS Servers
You can use an access profile to specify options that the router uses when communicating with RADIUS authentication and accounting servers for subscriber access. This procedure describes options that are available only in access profiles. For options that are available at both the access profile and global level, see RADIUS Servers and Parameters for Subscriber Access.
To configure RADIUS authentication and accounting server options:
Configuring a Calling-Station-ID with Additional Options
Use this section to configure an alternative value for the Calling-Station-ID (RADIUS IETF attribute 31) in an access profile on the MX Series router.
You can configure the Calling-Station-ID to include one or more of the following options, in any
combination, at the [edit access profile profile-name radius
options
calling-station-id-format
]
hierarchy:
Agent circuit identifier (
agent-circuit-id
)—Identifier of the subscriber’s access node and the digital subscriber line (DSL) on the access node. The agent circuit identifier (ACI) string is stored in either the DHCP option 82 field of DHCP messages for DHCP traffic, or in the DSL Forum Agent-Circuit-ID VSA [26-1] of PPPoE Active Discovery Initiation (PADI) and PPPoE Active Discovery Request (PADR) control packets for PPPoE traffic.Agent remote identifier (
agent-remote-id
)—Identifier of the subscriber on the digital subscriber line access multiplexer (DSLAM) interface that initiated the service request. The agent remote identifier (ARI) string is stored in either the DHCP option 82 field for DHCP traffic, or in the DSL Forum Agent-Remote-ID VSA [26-2] for PPPoE traffic.Interface description (
interface-description
)—Value of the interface.Interface text description (
interface-text-description
)—Text description of the interface. The interface text description is configured separately, using either theset interfaces interface-name description description
statement or theset interfaces interface-name unit unit-number description description
statementMAC address (
mac-address
)—MAC address of the source device for the subscriber.NAS identifier (
nas-identifier
)—Name of the NAS that originated the authentication or accounting request. NAS-Identifier is RADIUS IETF attribute 32.Stacked VLAN
(stacked-vlan)
—Stacked VLAN ID.VLAN
(vlan)
—VLAN ID.
If you configure the format of the Calling-Station-ID with more than one optional value, a hash character (#) is the default delimiter that the router uses as a separator between the concatenated values in the resulting Calling-Station-ID string. Optionally, you can configure an alternative delimiter character for the Calling-Station-ID to use. The following example shows the order of output when you configure multiple optional values:
nas-identifier#interface description#interface text description#agent-circuit-id#agent-remote-id#mac address#stacked vlan#vlan
To configure an access profile to provide optional information in the Calling-Station-ID:
Example: Calling-Station-ID with Additional Options in an Access Profile
The following example creates an access profile named retailer01
that configures a Calling-Station-ID string that includes the NAS-Identifier
(fox
), interface description, agent circuit identifier,
and agent remote identifier options.
[edit access profile retailer01 radius options] nas-identifier "fox"; calling-station-id-delimiter "*"; calling-station-id format { nas-identifier; interface-description; agent-circuit-id; agent-remote-id; }
The resulting Calling-Station-ID string is formatted as follows:
fox*ge-1/2/0.100:100*as007*ar921
where:
The NAS-Identifier value is
fox
.The Calling-Station-ID delimiter character is
*
(asterisk).The interface description value is
ge-1/2/0.100:100
.The agent circuit identifier value is
as007
.The agent remote identifier value is
ar921
.
Consider an example where all options are configured, but no values are available for the Agent-Circuit-ID, the Agent-Remote-Id, or the stacked VLAN identifier. The other values are as follows:
NAS identifier—solarium
interface description—ge-1/0/0.1073741824:101
interface text description—example-interface
MAC address—00:00:5E:00:53:00
VLAN identifier—101
These values result in the following Calling-Station-ID:
solarium#ge-1/0/0.1073741824:101#example-interface###00-00-5E-00-53-00##101
Filtering RADIUS Attributes and VSAs from RADIUS Messages
Standard attributes and vendor-specific attributes (VSAs) received in RADIUS messages take precedence over internally provisioned attribute values. Filtering attributes consists of choosing to ignore certain attributes when they are received in Access Accept packets and to exclude certain attributes from being sent to the RADIUS server. Ignoring attributes received from the RADIUS server enables your locally provisioned values to be used instead. Excluding attributes from being sent is useful, for example, for attributes that do not change for the lifetime of a subscriber. It enables you to reduce the packet size without loss of information.
You can specify standard RADIUS attributes and VSAs that the router or switch subsequently ignores when they are received in RADIUS Access-Accept messages. You can also specify attributes and VSAs that the router or switch excludes from specified RADIUS message types. Exclusion means that the router or switch does not include the attribute in specified messages that it sends to the RADIUS server.
Starting in Junos OS Release 18.1R1, you can configure the router or switch to ignore or exclude RADIUS standard attributes and VSAs by specifying the standard attribute number or the IANA-assigned vendor ID and the VSA number, respectively. With this flexible configuration method, you can configure any standard attribute and VSA supported by your platform to be ignored or excluded. The configuration has no effect if you configure unsupported attributes, vendors, and VSAs.
The legacy method allows you to configure only those attributes and VSAs for which the statement syntax includes a specific option. Consequently, you can use the legacy method to ignore only a subset of all attributes that can be received in Access-Accept messages.
To configure the attributes ignored or excluded by your router or switch:
The following example compares the legacy and flexible configuration methods to ignore the standard RADIUS attribute, Framed-IP-Netmask (9), and the Juniper Networks VSAs, Ingress-Policy-Name (26-10) and Egress-Policy-Name (26-11).
Legacy method:
[edit access profile prof-ign radius attributes] user@host# set ignore framed-ip-netmask input-filter output-filter
Flexible method:
[edit access profile prof-ign radius attributes] user@host# set ignore standard-attribute 9 user@host# set ignore vendor-id 4874 vendor-attribute [ 10 11 ]
The following example compares the legacy and flexible configuration methods to exclude the standard RADIUS attribute, Framed-IP-Netmask (9), and the Juniper Networks VSAs, Ingress-Policy-Name (26-10) and Egress-Policy-Name (26-11).
Legacy method:
[edit access profile prof-exc radius attributes] user@host# set exclude framed-ip-netmask accounting-stop user@host# set exclude input-filter [ accounting-start accounting-stop ] user@host# set exclude output-filter [ accounting-start accounting-stop ]
Flexible method: Specify standard attribute number or the IANA-assigned vendor ID, the VSA number, and the message type:
[edit access profile prof-exc radius attributes] user@host# set exclude standard-attribute 9 packet-type accounting-stop user@host# set exclude vendor-id 4874 vendor-attribute 10 packet-type [ accounting-start accounting-stop ] user@host# set exclude vendor-id 4874 vendor-attribute 11 packet-type [ accounting-start accounting-stop ]
What happens if you specify an attribute with both methods in the same profile? The effective configuration is the logical OR of the two methods. Consider the following example for the standard attribute, accounting-delay-time (41):
[edit access profile prof-3 radius attributes] user@host# set exclude accounting-delay-time [ accounting-off accounting-on ] user@host# set exclude standard-attribute 41 packet-type [ accounting-start accounting-stop ]
The result is that the attribute is excluded from all four message types: Accounting-Off, Accounting-On, Accounting-Start, and Accounting-Stop. The effect is the same as if either of the following configurations is used:
[edit access profile prof-3 radius attributes] user@host# set exclude accounting-delay-time [ accounting-off accounting-on accounting-start accounting-stop ]
[edit access profile prof-3 radius attributes] user@host# set exclude standard-attribute 41 packet-type [ accounting-off accounting-on accounting-start accounting-stop ]
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.