Copyright Page

Chapter 1. Configuring RADIUS

Finding Feature Information

Prerequisites for RADIUS

Information About RADIUS

RADIUS Network Environments

RADIUS Operation

RADIUS Attributes

Vendor-Proprietary RADIUS Attributes

RADIUS Tunnel Attributes

Preauthentication on a RADIUS Server

RADIUS Profile for DNIS or CLID Preauthentication

RADIUS Profile for Call Type Preauthentication

RADIUS Profile for Preauthentication Enhancements for Callback

RADIUS Profile for a Remote Hostname Used for Large-Scale Dial-Out

RADIUS Profile for Modem Management

RADIUS Profile for Subsequent Authentication

RADIUS Profile for Subsequent Authentication Types

RADIUS Profile to Include the Username

RADIUS Profile for Two-Way Authentication

RADIUS Profile to Support Authorization

RADIUS Authentication

RADIUS Authorization

RADIUS Accounting

RADIUS Login-IP-Host

RADIUS Prompt

Vendor-Specific RADIUS Attributes

Static Routes and IP Addresses on the RADIUS Server

How to Configure RADIUS

Configuring a Device for Vendor-Proprietary RADIUS Server Communication

Configuring a Device to Expand Network Access Server Port Information

Replacing the NAS-Port Attribute with the RADIUS Attribute

Monitoring and Maintaining RADIUS

Configuration Examples for RADIUS

Example: RADIUS Authentication and Authorization

Example: RADIUS Authentication, Authorization, and Accounting

Example: Vendor-Proprietary RADIUS Configuration

Example: Multiple RADIUS Server Entries for the Same Server IP Address

Additional References

Feature Information for Configuring RADIUS

Chapter 2. AAA Server Groups

Finding Feature Information

Information About AAA Server Groups

AAA Server Groups

AAA Server Groups with a Deadtimer

How to Configure AAA Server Groups

Configuring AAA Server Groups

Configuring AAA Server Groups with a Deadtimer

Configuration Examples for AAA Server Groups

Examples: AAA Server Groups

Example: Multiple RADIUS Server Entries Using AAA Server Groups

Additional References

Feature Information for AAA Server Groups

Chapter 3. RADIUS for Multiple UDP Ports

Finding Feature Information

Prerequisites for RADIUS for Multiple UDP Ports

Information About RADIUS for Multiple UDP Ports

Device-to-RADIUS Server Communication

How to Configure RADIUS for Multiple UDP Ports

Configuring Device-to-RADIUS Server Communication

Configuration Examples for RADIUS for Multiple UDP Ports

Example: Device-to-RADIUS Server Communication

Example: RADIUS Server with Server-Specific Values

Additional References

Feature Information for RADIUS for Multiple UDP Ports

Chapter 4. RADIUS Server Load Balancing

Finding Feature Information

Prerequisites for RADIUS Server Load Balancing

Restrictions for RADIUS Server Load Balancing

Information About RADIUS Server Load Balancing

RADIUS Server Load Balancing Overview

Transaction Load Balancing Across RADIUS Server Groups

RADIUS Server Status and Automated Testing

How to Configure RADIUS Server Load Balancing

Enabling Load Balancing for a Named RADIUS Server Group

Troubleshooting RADIUS Server Load Balancing

Configuration Examples for RADIUS Server Load Balancing

Example: Enabling Load Balancing for a Named RADIUS Server Group

Example: Monitoring Idle Timer

Example: Configuring the Preferred Server with the Same Authentication and Authorization Server

Example: Configuring the Preferred Server with Different Authentication and Authorization Servers

Example: Configuring the Preferred Server with Overlapping Authentication and Authorization Servers

Example: Configuring the Preferred Server with Authentication Servers As a Subset of Authorization Servers

Example: Configuring the Preferred Server with Authentication Servers As a Superset of Authorization Servers

Additional References for RADIUS Server Load Balancing

Feature Information for RADIUS Server Load Balancing

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: Click Here . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Chapter 1. Configuring RADIUS

The RADIUS security system is a distributed client/server system that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco devices and send authentication requests to a central RADIUS server that contains all user authentication and network service access information.

- Finding Feature Information

- Prerequisites for RADIUS

- Information About RADIUS

- How to Configure RADIUS

- Configuration Examples for RADIUS

- Additional References

- Feature Information for Configuring RADIUS

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for RADIUS

To configure RADIUS on your Cisco device or access server, you must perform these tasks:

- Use the aaa new-model global configuration command to enable Authentication, Authorization, and Accounting (AAA). AAA must be configured if you plan to use RADIUS.

- Use the aaa authentication global configuration command to define method lists for RADIUS authentication.

- Use line and interface commands to enable the defined method lists to be used.

Information About RADIUS

- RADIUS Network Environments

- RADIUS Operation

- RADIUS Attributes

- Preauthentication on a RADIUS Server

- RADIUS Authentication

- RADIUS Authorization

- RADIUS Accounting

- RADIUS Login-IP-Host

- RADIUS Prompt

- Vendor-Specific RADIUS Attributes

- Static Routes and IP Addresses on the RADIUS Server

RADIUS Network Environments

Cisco supports RADIUS under its authentication, authorization, and accounting (AAA) security paradigm. RADIUS can be used with other AAA security protocols such as TACACS+, Kerberos, and local username lookup. RADIUS is supported on all Cisco platforms, but some RADIUS-supported features run only on specified platforms.

RADIUS has been implemented in a variety of network environments that require high levels of security while maintaining network access for remote users.

Use RADIUS in the following network environments that require access security:

- Networks with multiple-vendor access servers, each supporting RADIUS. For example, access servers from several vendors use a single RADIUS server-based security database. In an IP-based network with multiple vendors’ access servers, dial-in users are authenticated through a RADIUS server that has been customized to work with the Kerberos security system.

- Turnkey network security environments in which applications support the RADIUS protocol, such as in an access environment that uses a smart card access control system. In one case, RADIUS has been used with Enigma’s security cards to validate users and grant access to network resources.

- Networks already using RADIUS. You can add a Cisco device with RADIUS to the network. This might be the first step when you make a transition to a TACACS+ server.

- Networks in which a user must only access a single service. Using RADIUS, you can control user access to a single host, to a single utility such as Telnet, or to a single protocol such as PPP. For example, when a user logs in, RADIUS identifies this user as having authorization to run PPP using the IP address 10.2.3.4 and the defined access list is started.

- Networks that require resource accounting. You can use RADIUS accounting independent of RADIUS authentication or authorization. The RADIUS accounting functions allow data to be sent at the start and end of services, indicating the amount of resources (such as time, packets, and bytes) used during the session. An ISP might use a freeware-based version of RADIUS access control and accounting software to meet special security and billing needs.

- Networks that support preauthentication. Using the RADIUS server in your network, you can configure AAA preauthentication and set up the preauthentication profiles. Preauthentication enables service providers to better manage ports using their existing RADIUS solutions, and to efficiently manage the use of shared resources to offer differing service-level agreements.

RADIUS is not suitable in these network security situations:

- Multiprotocol access environments. RADIUS does not support the following protocols:

- AppleTalk Remote Access (ARA)

- NetBIOS Frame Control Protocol (NBFCP)

- NetWare Asynchronous Services Interface (NASI)

- X.25 Packet Assemblers/Disassemblers (PAD) connections

- Device-to-device situations. RADIUS does not provide two-way authentication. RADIUS can be used to authenticate from one device to a non-Cisco device if the non-Cisco device requires RADIUS authentication.

- Networks using a variety of services. RADIUS generally binds a user to one service model.

RADIUS Operation

When a user attempts to log in and authenticate to an access server using RADIUS, the following steps occur:

1. The user is prompted to enter the username and password.

2. The username and encrypted password are sent over the network to the RADIUS server.

3. The user receives one of the following responses from the RADIUS server:

1. ACCEPT—The user is authenticated.

2. CHALLENGE—A challenge is issued by the RADIUS server. The challenge collects additional data from the user.

3. CHANGE PASSWORD—A request is issued by the RADIUS server, asking the user to select a new password.

4. REJECT—The user is not authenticated and is prompted to reenter the username and password, or access is denied.

The ACCEPT or REJECT response is bundled with additional data that is used for EXEC or network authorization. You must first complete RADIUS authentication before using RADIUS authorization. The additional data included with the ACCEPT or REJECT packets consists of the following:

- Services that the user can access, including connections such as Telnet, rlogin, or local-area transport (LAT), and services such as PPP, Serial Line Protocol (SLIP), or EXEC services.

- Connection parameters, including the host or client IP address, access list, and user timeouts.

RADIUS Attributes

The network access server monitors the RADIUS authorization and accounting functions defined by RADIUS attributes in each user profile:

- Vendor-Proprietary RADIUS Attributes

- RADIUS Tunnel Attributes

Vendor-Proprietary RADIUS Attributes

An Internet Engineering Task Force (IETF) standard for RADIUS specifies a method for communicating vendor-proprietary information between the network access server and the RADIUS server. Some vendors, nevertheless, have extended the RADIUS attribute set in a unique way. Cisco software supports a subset of vendor-proprietary RADIUS attributes.

RADIUS Tunnel Attributes

RADIUS is a security server AAA protocol originally developed by Livingston, Inc. RADIUS uses attribute value (AV) pairs to communicate information between the security server and the network access server.

RFC 2138 and RFC 2139 describe the basic functionality of RADIUS and the original set of IETF-standard AV pairs used to send AAA information. Two IETF standards, “RADIUS Attributes for Tunnel Protocol Support” and “RADIUS Accounting Modifications for Tunnel Protocol Support,” extend the IETF-defined set of AV pairs to include attributes specific to VPNs. These attributes are used to carry the tunneling information between the RADIUS server and the tunnel initiator.

RFC 2865 and RFC 2868 extend the IETF-defined set of AV pairs to include attributes specific to compulsory tunneling in VPNs by allowing the user to specify authentication names for the network access server and the RADIUS server.

Cisco devices and access servers support new RADIUS IETF-standard virtual private dialup network (VPDN) tunnel attributes.

Preauthentication on a RADIUS Server

RADIUS attributes are configured in the RADIUS preauthentication profiles to specify preauthentication behavior. In addition to configuring preauthentication on your Cisco device, you must set up the preauthentication profiles on the RADIUS server.

- RADIUS Profile for DNIS or CLID Preauthentication

- RADIUS Profile for Call Type Preauthentication

- RADIUS Profile for Preauthentication Enhancements for Callback

- RADIUS Profile for a Remote Hostname Used for Large-Scale Dial-Out

- RADIUS Profile for Modem Management

- RADIUS Profile for Subsequent Authentication

- RADIUS Profile for Subsequent Authentication Types

- RADIUS Profile to Include the Username

- RADIUS Profile for Two-Way Authentication

- RADIUS Profile to Support Authorization

RADIUS Profile for DNIS or CLID Preauthentication

To configure the RADIUS preauthentication profile, use the Dialed Number Identification Service (DNIS) or Calling Line Identification (CLID) number as the username, and use the password defined in the dnis or clid command as the password.

Note

The preauthentication profile must have “outbound” as the service type because the password is predefined on the network access server (NAS). Setting up the preauthentication profile in this manner prevents users from trying to log in to the NAS with the username of the DNIS number, CLID number, or call type and an obvious password. The “outbound” service type is also included in the Access-Request packet sent to the RADIUS server.

RADIUS Profile for Call Type Preauthentication

To set up the RADIUS preauthentication profile, use the call type string as the username, and use the password defined in the ctype command as the password. The table below lists the call type strings that can be used in the preauthentication profile.

Call Type Strings Used in Preauthentication

Call Type String

ISDN Bearer Capabilities

digital

Unrestricted digital, restricted digital.

speech

Speech, 3.1 kHz audio, 7 kHz audio.

Note:
This is the only call type available for channel-associated signaling (CAS) .

v.110

Anything with the V.110 user information layer.

v.120

Anything with the V.120 user information layer.

Note

The preauthentication profile must have “outbound” as the service type because the password is predefined on the NAS. Setting up the preauthentication profile in this manner prevents users from trying to log in to the NAS with the username of the DNIS number, CLID number, or call type and an obvious password. The “outbound” service type is also included in the Access-Request packet sent to the RADIUS server and should be a checkin item if the RADIUS server supports checkin items.

RADIUS Profile for Preauthentication Enhancements for Callback

Callback allows remote network users such as telecommuters to dial in to the NAS without being charged. When callback is required, the NAS hangs up the current call and dials the caller back. When the NAS performs the callback, only information for the outgoing connection is applied. The rest of the attributes from the preauthentication access-accept message are discarded.

Note

The destination IP address is not required to be returned from the RADIUS server.

The following example shows a RADIUS profile configuration with a callback number of 555-0101 and the service type set to outbound. The cisco-avpair = “preauth:send-name=<string>” uses the string “user1” and the cisco-avpair = “preauth:send-secret=<string>” uses the password “cisco.”

5550101 password = “cisco”, Service-Type = Outbound
Service-Type = Callback-Framed
Framed-Protocol = PPP,
Dialback-No = “5550119”
Class = “ISP12”
cisco-avpair = “preauth:send-name=user1”
cisco-avpair = “preauth:send-secret=cisco”

RADIUS Profile for a Remote Hostname Used for Large-Scale Dial-Out

The following example protects against accidentally calling a valid telephone number but accessing the wrong device by providing the name of the remote device, for use in large-scale dial-out:

5550101 password = "PASSWORD1", Service-Type = Outbound
Service-Type = Callback-Framed
Framed-Protocol = PPP,
Dialback-No = "5550190"
Class = "ISP12"
cisco-avpair = "preauth:send-name=user1"
cisco-avpair = "preauth:send-secret=PASSWORD1"
cisco-avpair = "preauth:remote-name=Device2"

RADIUS Profile for Modem Management

When DNIS, CLID, or call type preauthentication is used, the affirmative response from the RADIUS server might include a modem string for modem management in the NAS through vendor-specific attribute (VSA) 26. The modem management VSA has this syntax:

cisco-avpair = “preauth:modem-service=modem min-speed <
x
> max-speed <
y
>
modulation <
z
> error-correction <
a
> compression <
b
>”

The table below lists the modem management string elements within the VSA.

Modem Management String

Command

Argument

min-speed

300 to 56000, any

max-speed

300 to 56000, any

modulation

K56Flex, v22bis, v32bis, v34, v90, any

error-correction

lapm, mnp4

compression

mnp5, v42bis

When the modem management string is received from the RADIUS server in the form of a VSA, the information is passed to the Cisco software and applied on a per-call basis. Modem ISDN channel aggregation (MICA) modems provide a control channel through which messages can be sent during the call setup time. Hence, this modem management feature is supported only with MICA modems. This feature is not supported with Microcom modems.

RADIUS Profile for Subsequent Authentication

If preauthentication passes, you can use vendor-proprietary RADIUS attribute 201 (Require-Auth) in the preauthentication profile to determine whether subsequent authentication is performed. If attribute 201, returned in the access-accept message, has a value of 0, subsequent authentication is not performed. If attribute 201 has a value of 1, subsequent authentication is performed as usual.

Attribute 201 has this syntax:

cisco-avpair = “preauth:auth-required=<
n
>”

where <n> has the same value range as attribute 201 (that is, 0 or 1).

If attribute 201 is missing in the preauthentication profile, a value of 1 is assumed, and subsequent authentication is performed.

Note

Before you can perform subsequent authentication, you must set up a regular user profile in addition to a preauthentication profile.

RADIUS Profile for Subsequent Authentication Types

If you specified subsequent authentication in the preauthentication profile, you must also specify the authentication types to be used for subsequent authentication. To specify the authentication types allowed in subsequent authentication, use this VSA:

cisco-avpair = “preauth:auth-type=<
string
>”

The table below lists the allowed values for the <string> element.

<string> Element Values

String

Description

chap

Requires the username and password for the Challenge-Handshake Authentication Protocol (CHAP) for PPP authentication.

ms-chap

Requires the username and password for the MS-CHAP for PPP authentication.

pap

Requires the username and password for the Password Authentication Protocol (PAP) for PPP authentication.

To specify that multiple authentication types are allowed, you can configure more than one instance of this VSA in the preauthentication profile. The sequence of the authentication type VSAs in the preauthentication profile is significant because it specifies the order of authentication types to be used in the PPP negotiation.

This VSA is a per-user attribute and replaces the authentication type list in the ppp authentication interface configuration command.

Note

You should use this VSA only if subsequent authentication is required because it specifies the authentication type for subsequent authentication.

RADIUS Profile to Include the Username

If only preauthentication is used to authenticate a call, the NAS could be missing a username when it brings up the call. RADIUS can provide a username for the NAS to use through RADIUS attribute 1 (User-Name) or through a VSA returned in the Access-Accept packet. The VSA for specifying the username has this syntax:

cisco-avpair = “preauth:username=<
string
>”

If no username is specified, the DNIS number, CLID number, or call type is used, depending on the last preauthentication command configured (for example, if clid was the last preauthentication command configured, the CLID number is used as the username).

If subsequent authentication is used to authenticate a call, there might be two usernames: one provided by RADIUS and one provided by the user. In this case, the username provided by the user overrides the one contained in the RADIUS preauthentication profile. The username provided by the user is used for both authentication and accounting.

RADIUS Profile for Two-Way Authentication

In the case of two-way authentication, the calling networking device must authenticate the NAS. The PAP username and password or CHAP username and password need not be configured locally on the NAS. Instead, the username and password can be included in the Access-Accept messages for preauthentication.

Note

Do not configure the ppp authentication command with the radius command.

To set up PAP, do not configure the ppp pap sent-name password command on the interface. The VSAs “preauth:send-name” and “preauth:send-secret” are used as the PAP username and PAP password for outbound authentication.

For CHAP, “preauth:send-name” is used not only for outbound authentication but also for inbound authentication. For a CHAP inbound case, the NAS uses the name defined in “preauth:send-name” in the challenge packet to the caller networking device. For a CHAP outbound case, both “preauth:send-name” and “preauth:send-secret” are used in the response packet.

The following example shows a configuration that specifies two-way authentication:

5550101 password = "PASSWORD2", Service-Type = Outbound
Service-Type = Framed-User
cisco-avpair = "preauth:auth-required=1"
cisco-avpair = "preauth:auth-type=pap"
cisco-avpair = "preauth:send-name=user1"
cisco-avpair = "preauth:send-secret=PASSWORD2"
class = "<some class>"

Note

Two-way authentication does not work when resource pooling is enabled.

RADIUS Profile to Support Authorization

If only preauthentication is configured, subsequent authentication is bypassed. Note that because the username and password are not available, authorization is also bypassed. However, you can include authorization attributes in the preauthentication profile to apply per-user attributes and avoid having to return subsequently to RADIUS for authorization. To initiate the authorization process, you must also configure the aaa authorization network command on the NAS.

You can configure authorization attributes in the preauthentication profile with one exception: the service-type attribute (attribute 6). The service-type attribute must be converted to a VSA in the preauthentication profile. This VSA has this syntax:

cisco-avpair = “preauth:service-type=<
n
>”

where <n> is one of the standard RFC 2865 values for attribute 6.

Note

If subsequent authentication is required, the authorization attributes in the preauthentication profile are not applied.

RADIUS Authentication

After you have identified the RADIUS server and defined the RADIUS authentication key, you must define method lists for RADIUS authentication. Because RADIUS authentication is facilitated through AAA, you must enter the aaa authentication command, specifying RADIUS as the authentication method.

RADIUS Authorization

AAA authorization lets you set parameters that restrict a user’s access to the network. Authorization using RADIUS provides one method for remote access control, including one-time authorization or authorization for each service, per-user account list and profile, user group support, and support of IP, IPX, AppleTalk Remote Access (ARA), and Telnet. Because RADIUS authorization is facilitated through AAA, you must enter the aaa authorization command, specifying RADIUS as the authorization method.

RADIUS Accounting

The AAA accounting feature enables you to track the services users are accessing and the amount of network resources they are consuming. Because RADIUS accounting is facilitated through AAA, you must enter the aaa accounting command, specifying RADIUS as the accounting method.

RADIUS Login-IP-Host

To enable the network access server (NAS) to attempt more than one login host when trying to connect a dial-in user, you can enter as many as three Login-IP-Host entries in the user’s profile on the RADIUS server. The following example shows that three Login-IP-Host instances are configured for the user user1, and that TCP-Clear is used for the connection:

user1 Password = xyz
Service-Type = Login,
Login-Service = TCP-Clear,
Login-IP-Host = 10.0.0.0,
Login-IP-Host = 10.2.2.2,
Login-IP-Host = 10.255.255.255,
Login-TCP-Port = 23

The order in which the hosts are entered is the order in which they are attempted. Use the ip tcp synwait-time command to set the number of seconds that the NAS waits before trying to connect to the next host on the list; the default is 30 seconds.

Your RADIUS server might permit more than three Login-IP-Host entries; however, the NAS supports only three hosts in Access-Accept packets.

RADIUS Prompt

To control whether user responses to Access-Challenge packets are echoed to the screen, you can configure the Prompt attribute in the user profile on the RADIUS server. This attribute is included only in Access-Challenge packets. The following example shows the Prompt attribute set to No-Echo, which prevents the user’s responses from echoing:

user1 Password = xyz
Service-Type = Login,
Login-Service = Telnet,
Prompt = No-Echo,
Login-IP-Host = 172.31.255.255

To allow user responses to echo, set the attribute to Echo. If the Prompt attribute is not included in the user profile, responses are echoed by default.

This attribute overrides the behavior of the radius-server challenge-noecho command configured on the access server. For example, if the access server is configured to suppress echoing, but the individual user profile allows echoing, the user responses are echoed.

Note

If you want to use the Prompt attribute, your RADIUS server must be configured to support Access-Challenge packets.

Vendor-Specific RADIUS Attributes

The IETF standard specifies a method for communicating vendor-specific information between the network access server and the RADIUS server by using the vendor-specific attribute (attribute 26). Vendor-specific attributes (VSAs) allow vendors to support their own extended attributes not suitable for general use. The Cisco RADIUS implementation supports one vendor-specific option using the format recommended in the specification. Cisco’s vendor ID is 9, and the supported option has vendor type 1, which is named “cisco-avpair.” The value is a string with this format:

protocol : attribute sep value *

“Protocol” is a value of the Cisco “protocol” attribute for a particular type of authorization; protocols that can be used include IP, Internetwork Packet Exchange (IPX), VPDN, VoIP, Secure Shell (SSH), Resource Reservation Protocol (RSVP), Serial Interface Processor (SIP), AirNet, and Outbound. “Attribute” and “value” are an appropriate AV pair defined in the Cisco TACACS+ specification, and “sep” is “=” for mandatory attributes and “*” for optional attributes, allowing the full set of features available for TACACS+ authorization to also be used for RADIUS.

For example, the following AV pair causes Cisco’s “multiple named ip address pools” feature to be activated during IP authorization (during PPP’s Internet Protocol Control Protocol (IPCP) address assignment):

cisco-avpair= ”ip:addr-pool=first“

If you insert an “*”, the AV pair “ip:addr-pool=first” becomes optional. Note that any AV pair can be made optional:

cisco-avpair= ”ip:addr-pool*first“

The following example shows how to cause a user logging in from a network access server to have immediate access to EXEC commands:

cisco-avpair= ”shell:priv-lvl=15“

Other vendors have their own unique vendor IDs, options, and associated VSAs.

Static Routes and IP Addresses on the RADIUS Server

Some vendor-proprietary implementations of RADIUS let the user define static routes and IP pool definitions on the RADIUS server instead of on each individual network access server in the network. Each network access server then queries the RADIUS server for static route and IP pool information.

To have the Cisco device or access server query the RADIUS server for static routes and IP pool definitions when the device starts up, use the radius-server configure-nas command.

Because the radius-server configure-nas command is performed when the Cisco devcie starts up, it does not take effect until you enter a copy system:running-config nvram:startup-config command.

How to Configure RADIUS

- Configuring a Device for Vendor-Proprietary RADIUS Server Communication

- Configuring a Device to Expand Network Access Server Port Information

- Replacing the NAS-Port Attribute with the RADIUS Attribute

- Monitoring and Maintaining RADIUS

Configuring a Device for Vendor-Proprietary RADIUS Server Communication

Although an IETF standard for RADIUS specifies a method for communicating vendor-proprietary information between the network access server and the RADIUS server, some vendors have extended the RADIUS attribute set in a unique way. Cisco software supports a subset of vendor-proprietary RADIUS attributes.

To configure RADIUS (whether vendor-proprietary or IETF compliant), you must use the radius-server commands to specify the host running the RADIUS server daemon and the secret text string it shares with the Cisco device. To identify that the RADIUS server is using a vendor-proprietary implementation of RADIUS, use the radius-server host non-standard command. Vendor-proprietary attributes are not supported unless you use the radius-server host non-standard command.

Note

The radius-server host command is deprecated from Cisco IOS Release 15.4(2)S. To configure an IPv4 or IPv6 RADIUS server, use the radius server name command. For more information about the radius server command, see Cisco IOS Security Command Reference: Commands M to R.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    radius-server vsa send [accounting | authentication]

4.    radius server server-name

5.    address ipv4 ip-address

6.    non-standard

7.    key {0 string | 7 string | string}

8.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

radius-server vsa send [accounting | authentication]

Example:

Device(config)# radius-server vsa send

Enables the network access server to recognize and use VSAs as defined by RADIUS IETF attribute 26.

Step 4

radius server server-name

Example:

Device(config)# radius server rad1

Specifies the name for the RADIUS server.

Note:
The radius-server host command is deprecated from Cisco IOS Release 15.4(2)S. To configure an IPv4 or IPv6 RADIUS server, use the radius server name command. For more information about the radius server command, see Cisco IOS Security Command Reference: Commands M to R.

Step 5

address ipv4 ip-address

Example:

Device(config-radius-server)# address ipv4 10.45.1.2

Assigns an IP address to the RADIUS server.

Step 6

non-standard

Example:

Device(config-radius-server)# non-standard

Identifies that the security server is using a vendor-proprietary implementation of RADIUS.

Step 7

key {0 string | 7 string | string}

Example:

Device(config-radius-server)# key myRaDIUSpassword

Specifies the shared secret text string used between the device and the vendor-proprietary RADIUS server.

- The device and the RADIUS server use this text string to encrypt passwords and exchange responses.

Step 8

exit

Example:

Device(config)# exit

Returns to privileged EXEC mode.

Configuring a Device to Expand Network Access Server Port Information

Sometimes PPP or login authentication occurs on an interface that is different from the interface on which the call itself comes in. For example, in a V.120 ISDN call, login or PPP authentication occurs on a virtual asynchronous interface “ttt”, but the call itself occurs on one of the channels of the ISDN interface.

The radius-server attribute nas-port extended command configures RADIUS to expand the size of the NAS-Port attribute (RADIUS IETF attribute 5) field to 32 bits. The upper 16 bits of the NAS-Port attribute display the type and number of the controlling interface; the lower 16 bits indicate the interface undergoing authentication.

Note

The radius-server attribute nas-port format command replaces the radius-server extended-portnames command and the radius-server attribute nas-port extended command.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    radius-server configure-nas

4.    radius-server attribute nas-port format

5.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

radius-server configure-nas

Example:

Device(config)# radius-server configure-nas

(Optional) Tells the Cisco device or access server to query the RADIUS server for the static routes and IP pool definitions used throughout its domain.

Note:
Because the radius-server configure-nas command is used when the Cisco device starts up, it does not take effect until you issue a copy system:running-config nvram:startup-config command.

Step 4

radius-server attribute nas-port format

Example:

Device(config)# radius-server attribute nas-port format

Expands the size of the NAS-Port attribute from 16 to 32 bits to display extended interface information.

Step 5

exit

Example:

Device(config)# exit

Returns to privileged EXEC mode.

Replacing the NAS-Port Attribute with the RADIUS Attribute

On platforms with multiple interfaces (ports) per slot, the Cisco RADIUS implementation does not provide a unique NAS-Port attribute that permits distinguishing between the interfaces. For example, if a dual PRI is in slot 1, calls on both Serial1/0:1 and Serial1/1:1 appear as NAS-Port = 20101 because of the 16-bit field size limitation associated with the RADIUS IETF NAS-Port attribute. In this case, you can replace the NAS-Port attribute with a VSA (RADIUS IETF attribute 26). Cisco’s vendor ID is 9, and the Cisco-NAS-Port attribute is subtype 2. VSAs can be turned on by entering the radius-server vsa send command. The port information in this attribute is provided and configured using the aaa nas port extended command.

The standard NAS-Port attribute (RADIUS IETF attribute 5) is sent. If you do not want this information to be sent, you can suppress it by using the no radius-server attribute nas-port command. After this command is configured, the standard NAS-Port attribute is no longer sent.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    radius-server vsa send [accounting | authentication]

4.    aaa nas port extended

5.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

radius-server vsa send [accounting | authentication]

Example:

Device(config)# radius-server vsa send

Enables the network access server to recognize and use vendor-specific attributes as defined by RADIUS IETF attribute 26.

Step 4

aaa nas port extended

Example:

Device(config)# aaa nas port extended

Expands the size of the VSA NAS-Port field from 16 to 32 bits to display extended interface information.

Step 5

exit

Example:

Device(config)# exit

Returns to privileged EXEC mode.

Monitoring and Maintaining RADIUS

SUMMARY STEPS

1.    enable

2.    debug radius

3.    show radius statistics

4.    show aaa servers

5.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

debug radius

Example:

Device# debug radius

Displays information associated with RADIUS.

Step 3

show radius statistics

Example:

Device# show radius statistics

Displays the RADIUS statistics for accounting and authentication packets.

Step 4

show aaa servers

Example:

Device# show aaa servers

Displays the status and number of packets that are sent to and received from all public and private AAA RADIUS servers as interpreted by the AAA Server MIB.

Step 5

exit

Example:

Device# exit

Exits the device session.

Configuration Examples for RADIUS

- Example: RADIUS Authentication and Authorization

- Example: RADIUS Authentication, Authorization, and Accounting

- Example: Vendor-Proprietary RADIUS Configuration

- Example: Multiple RADIUS Server Entries for the Same Server IP Address

Example: RADIUS Authentication and Authorization

The following example shows how to configure the device to authenticate and authorize using RADIUS:

aaa authentication login use-radius group radius local
aaa authentication ppp user-radius if-needed group radius
aaa authorization exec default group radius
aaa authorization network default group radius

The lines in this sample RADIUS authentication and authorization configuration are defined as follows:

- The aaa authentication login use-radius group radius local command configures the device to use RADIUS for authentication at the login prompt. If RADIUS returns an error, the user is authenticated using the local database. In this example, use-radius is the name of the method list, which specifies RADIUS and then local authentication.

- The aaa authentication ppp user-radius if-needed group radius command configures the Cisco software to use RADIUS authentication for lines using PPP with CHAP or PAP if the user has not already been authorized. If the EXEC facility has authenticated the user, RADIUS authentication is not performed. In this example, user-radius is the name of the method list defining RADIUS as the if-needed authentication method.

- The aaa authorization exec default group radius command sets the RADIUS information that is used for EXEC authorization, autocommands, and access lists.

- The aaa authorization network default group radius command sets RADIUS for network authorization, address assignment, and access lists.

Example: RADIUS Authentication, Authorization, and Accounting

The following example shows a general configuration using RADIUS with the AAA command set:

radius-server host 10.45.1.2
radius-server key myRaDiUSpassWoRd
username root password ALongPassword
aaa authentication ppp dialins group radius local
aaa authorization network default group radius local
aaa accounting network default start-stop group radius
aaa authentication login admins local
aaa authorization exec default local
line 1 16
autoselect ppp
autoselect during-login
login authentication admins
modem ri-is-cd
interface group-async 1
encaps ppp
ppp authentication pap dialins

The lines in this example RADIUS authentication, authorization, and accounting configuration are defined as follows:

- The radius-server host command defines the IP address of the RADIUS server host.

- The radius-server key command defines the shared secret text string between the network access server and the RADIUS server host.

- The aaa authentication ppp dialins group radius local command defines the authentication method list “dialins,” which specifies that RADIUS authentication and then (if the RADIUS server does not respond) local authentication is used on serial lines using PPP.

- The aaa authorization network default group radius local command is used to assign an address and other network parameters to the RADIUS user.

- The aaa accounting network default start-stop group radius command tracks PPP usage.

- The aaa authentication login admins local command defines another method list, “admins,” for login authentication.

- The login authentication admins command applies the “admins” method list for login authentication.

- The ppp authentication pap dialins command applies the “dialins” method list to the lines specified.

Example: Vendor-Proprietary RADIUS Configuration

The following example shows a general configuration using vendor-proprietary RADIUS with the AAA command set:

Note

The radius-server host command is deprecated from Cisco IOS Release 15.4(2)S. To configure an IPv4 or IPv6 RADIUS server, use the radius server name command. For more information about the radius server command, see Cisco IOS Security Command Reference: Commands M to R.

radius server myserver
radius server address ipv4 192.0.2.2
non-standard
key 7 any key
radius-server configure-nas
username root password ALongPassword
aaa authentication ppp dialins group radius local
aaa authorization network default group radius local
aaa accounting network default start-stop group radius
aaa authentication login admins local
aaa authorization exec default local

The lines in this RADIUS authentication, authorization, and accounting configuration example are defined as follows:

- The non-standard command defines the name of the RADIUS server host and identifies that this RADIUS host uses a vendor-proprietary version of RADIUS.

- The key command defines the shared secret text string between the network access server and the RADIUS server host.

- The configure-nas command defines that the Cisco device or access server queries the RADIUS server for static routes and IP pool definitions when the device first starts up.

- The aaa authentication ppp dialins group radius local command defines the authentication method list “dialins,” which specifies that RADIUS authentication and then (if the RADIUS server does not respond) local authentication is used on serial lines using PPP.

- The aaa authorization network default group radius local command assigns an address and other network parameters to the RADIUS user.

- The aaa accounting network default start-stop group radius command tracks PPP usage.

- The aaa authentication login admins local command defines another method list, “admins,” for login authentication.

Example: Multiple RADIUS Server Entries for the Same Server IP Address

The following example shows how to configure the network access server to recognize several RADIUS host entries with the same IP address. Two different host entries on the same RADIUS server are configured for the same services—authentication and accounting. The second host entry configured acts as failover backup to the first one. (The RADIUS host entries are tried in the order they are configured.)

! This command enables AAA.
aaa new-model
! The next command configures default RADIUS parameters.
aaa authentication ppp default group radius
! The next set of commands configures multiple host entries for the same IP address.
radius-server host 172.20.0.1 auth-port 1000 acct-port 1001
radius-server host 172.20.0.1 auth-port 2000 acct-port 2000

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Command List, All Releases

AAA and RADIUS commands

Cisco IOS Security Command Reference

RADIUS attributes

RADIUS Attributes Configuration Guide (part of the Securing User Services Configuration Library)

AAA

Authentication, Authorization, and Accounting Configuration Guide (part of the Securing User Services Configuration Library)

L2TP, VPN, or VPDN

Dial Technologies Configuration Guide and VPDN Configuration Guide

Modem configuration and management

Dial Technologies Configuration Guide

RADIUS port identification for PPP

Wide-Area Networking Configuration Guide

RFCs

RFC

Title

RFC 2138

Remote Authentication Dial-In User Service (RADIUS)

RFC 2139

RADIUS Accounting

RFC 2865

RADIUS

RFC 2867

RADIUS Accounting Modifications for Tunnel Protocol Support

RFC 2868

RADIUS Attributes for Tunnel Protocol Support

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for Configuring RADIUS

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to . An account on Cisco.com is not required.

Feature Information for Configuring RADIUS

Feature Name

Releases

Feature Information

Configuring RADIUS

Cisco IOS XE 3.2SE

Cisco IOS XE 3.3SE

The RADIUS security system is a distributed client/server system that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco devices and send authentication requests to a central RADIUS server that contains all user authentication and network service access information.

In Cisco IOS XE Release 3.2SE, this feature was supported on the following platforms:

- Catalyst 3850 Series Switches

- Cisco 5760 Wireless LAN Controller

In Cisco IOS XE Release 3.3SE, this feature was supported on the following platforms:

- Catalyst 3650 Series Switches

RADIUS Statistics via SNMP

Cisco IOS XE 3.2SE

Cisco IOS XE 3.3SE

This feature provides statistics related to RADIUS traffic and private RADIUS servers.

In Cisco IOS XE Release 3.2SE, this feature was supported on the following platforms:

- Catalyst 3850 Series Switches

- Cisco 5760 Wireless LAN Controller

In Cisco IOS XE Release 3.3SE, this feature was supported on the following platforms:

- Catalyst 3650 Series Switches

The following commands were introduced or modified: show aaa servers, show radius statistics.

Chapter 2. AAA Server Groups

Configuring a device to use authentication, authorization, and accounting (AAA) server groups provides a way to group existing server hosts. Grouping existing server hosts allows you to select a subset of the configured server hosts and use them for a particular service. Configuring deadtime within a server group allows you to direct AAA traffic to separate groups of servers that have different operational characteristics. This feature module describes how to configure AAA server groups and the deadtimer.

- Finding Feature Information

- Information About AAA Server Groups

- How to Configure AAA Server Groups

- Configuration Examples for AAA Server Groups

- Additional References

- Feature Information for AAA Server Groups

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Information About AAA Server Groups

- AAA Server Groups

- AAA Server Groups with a Deadtimer

AAA Server Groups

Configuring the device to use AAA server groups provides a way to group existing server hosts. Grouping existing server hosts allows you to select a subset of the configured server hosts and use them for a particular service. A server group is used with a global server-host list. The server group lists the IP addresses of the selected server hosts.

Server groups can also include multiple host entries for the same server, as long as each entry has a unique identifier. The combination of an IP address and a UDP port number creates a unique identifier, allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. This unique identifier enables RADIUS requests to be sent to different UDP ports on a server at the same IP address. If two different host entries on the same RADIUS server are configured for the same service—for example, accounting—the second host entry that is configured acts as a failover backup to the first one. If the first host entry fails to provide accounting services, the network access server tries the second host entry configured on the same device for accounting services. (The RADIUS host entries are tried in the order in which they are configured.)

AAA Server Groups with a Deadtimer

After you configure a server host with a server name, you can use the deadtime command to configure each server per server group. Configuring deadtime within a server group allows you to direct AAA traffic to separate groups of servers that have different operational characteristics.

Configuring deadtime is not limited to a global configuration. A separate timer is attached to each server host in every server group. Therefore, when a server is found to be unresponsive after numerous retransmissions and timeouts, the server is assumed to be dead. The timers attached to each server host in all server groups are triggered. In essence, the timers are checked and subsequent requests to a server (once it is assumed to be dead) are directed to alternate timers, if configured. When the network access server receives a reply from the server, it checks and stops all configured timers (if running) for that server in all server groups.

If the timer has expired, the server to which the timer is attached is assumed to be alive. This becomes the only server that can be tried for later AAA requests using the server groups to which the timer belongs.

Note

Because one server has different timers and might have different deadtime values configured in the server groups, the same server might, in the future, have different states (dead and alive) at the same time.

Note

To change the state of a server, you must start and stop all configured timers in all server groups.

The size of the server group will be slightly increased because of the addition of new timers and the deadtime attribute. The overall impact of the structure depends on the number and size of the server groups and how the servers are shared among server groups in a specific configuration.

How to Configure AAA Server Groups

- Configuring AAA Server Groups

- Configuring AAA Server Groups with a Deadtimer

Configuring AAA Server Groups

To define a server host with a server group name, enter the following commands in global configuration mode. The listed server must exist in global configuration mode.

Before You Begin

Each server in the group must be defined previously using the radius-server host command.

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    radius server server-name

4.    aaa group server {radius | tacacs+} group-name

5.    server ip-address [auth-port port-number] [acct-port port-number]

6.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

radius server server-name

Example:

Device(config)# radius server rad1

Specifies the name for the RADIUS server.

Step 4

aaa group server {radius | tacacs+} group-name

Example:

Device(config)# aaa group server radius group1

Defines the AAA server group with a group name.

- All members of a group must be the same type, that is, RADIUS or TACACS+. This command puts the device in server group RADIUS configuration mode.

Step 5

server ip-address [auth-port port-number] [acct-port port-number]

Example:

Device(config-sg-radius)# server 172.16.1.1 acct-port 1616

Associates a particular RADIUS server with the defined server group.

- Each security server is identified by its IP address and UDP port number.

- Repeat this step for each RADIUS server in the AAA server group.

Step 6

end

Example:

Device(config-sg-radius)# end

Exits server group RADIUS configuration mode and returns to privileged EXEC mode.

Configuring AAA Server Groups with a Deadtimer

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    aaa group server radius group

4.    deadtime minutes

5.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa group server radius group

Example:

Device(config)# aaa group server radius group1

Defines a RADIUS type server group and enters server group RADIUS configuration mode.

Step 4

deadtime minutes

Example:

Device(config-sg-radius)# deadtime 1

Configures and defines a deadtime value in minutes.

Note:
Local server group deadtime overrides the global configuration. If the deadtime vlaue is omitted from the local server group configuration, it is inherited from the master list.

Step 5

end

Example:

Device(config-sg-radius)# end

Exits server group RADIUS configuration mode and returns to privileged EXEC mode.

Configuration Examples for AAA Server Groups

- Examples: AAA Server Groups

- Example: Multiple RADIUS Server Entries Using AAA Server Groups

Examples: AAA Server Groups

The following example shows how to create server group radgroup1 with three different RADIUS server members, each using the default authentication port (1645) and accounting port (1646):

aaa group server radius radgroup1
server 172.16.1.11
server 172.17.1.21
server 172.18.1.31

The following example shows how to create server group radgroup2 with three RADIUS server members, each with the same IP address but with unique authentication and accounting ports:

aaa group server radius radgroup2
server 172.16.1.1 auth-port 1000 acct-port 1001
server 172.16.1.1 auth-port 2000 acct-port 2001
server 172.16.1.1 auth-port 3000 acct-port 3001

Example: Multiple RADIUS Server Entries Using AAA Server Groups

The following example shows how to configure the network access server to recognize two different RADIUS server groups. One of these groups, group1, has two different host entries on the same RADIUS server configured for the same services. The second host entry configured acts as failover backup to the first one. Each group is individually configured for the deadtime; the deadtime for group 1 is one minute, and the deadtime for group 2 is two minutes.

Note

In cases where both global commands and server commands are used, the server command takes precedence over the global command.

! This command enables AAA.
aaa new-model
! The next command configures default RADIUS parameters.
aaa authentication ppp default group group1
! The following commands define the group1 RADIUS server group and associate servers
! with it and configures a deadtime of one minute.
aaa group server radius group1
server 10.1.1.1 auth-port 1645 acct-port 1646
server 10.2.2.2 auth-port 2000 acct-port 2001
deadtime 1
! The following commands define the group2 RADIUS server group and associate servers
! with it and configures a deadtime of two minutes.
aaa group server radius group2
server 10.2.2.2 auth-port 2000 acct-port 2001
server 10.3.3.3 auth-port 1645 acct-port 1646
deadtime 2
! The following set of commands configures the RADIUS attributes for each host entry
! associated with one of the defined server groups.
radius-server host 10.1.1.1 auth-port 1645 acct-port 1646
radius-server host 10.2.2.2 auth-port 2000 acct-port 2001
radius-server host 10.3.3.3 auth-port 1645 acct-port 1646

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Command List, All Releases

AAA and RADIUS commands

Cisco IOS Security Command Reference

RADIUS attributes

RADIUS Attributes Configuration Guide (part of the Securing User Services Configuration Library)

AAA

Authentication, Authorization, and Accounting Configuration Guide (part of the Securing User Services Configuration Library)

L2TP, VPN, or VPDN

Dial Technologies Configuration Guide and VPDN Configuration Guide

Modem configuration and management

Dial Technologies Configuration Guide

RADIUS port identification for PPP

Wide-Area Networking Configuration Guide

RFCs

RFC

Title

RFC 2138

Remote Authentication Dial-In User Service (RADIUS)

RFC 2139

RADIUS Accounting

RFC 2865

RADIUS

RFC 2867

RADIUS Accounting Modifications for Tunnel Protocol Support

RFC 2868

RADIUS Attributes for Tunnel Protocol Support

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for AAA Server Groups

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to . An account on Cisco.com is not required.

Feature Information for AAA Server Groups

Feature Name

Releases

Feature Information

AAA Server Group

Cisco IOS XE 3.2SE

Cisco IOS XE 3.3SE

Configuring the device to use AAA server groups provides a way to group existing server hosts. This allows you to select a subset of the configured server hosts and use them for a particular service. A server group is used with a global server-host list. The server group lists the IP addresses of the selected server hosts.

In Cisco IOS XE Release 3.2SE, this feature was supported on the following platforms:

- Catalyst 3850 Series Switches

- Cisco 5760 Wireless LAN Controller

In Cisco IOS XE Release 3.3SE, this feature was supported on the following platforms:

- Catalyst 3650 Series Switches

The following commands were introduced or modified: aaa group server radius, aaa group server tacacs+, and server (RADIUS).

AAA Server Group Enhancements

Cisco IOS XE 3.2SE

Cisco IOS XE 3.3SE

AAA Server Group Enhancements enables the full configuration of a server in a server group.

In Cisco IOS XE Release 3.2SE, this feature was supported on the following platforms:

- Catalyst 3850 Series Switches

- Cisco 5760 Wireless LAN Controller

In Cisco IOS XE Release 3.3SE, this feature was supported on the following platforms:

- Catalyst 3650 Series Switches

AAA Server Group Deadtimer

Cisco IOS XE 3.2SE

Cisco IOS XE 3.3SE

Configuring deadtime within a server group allows you to direct AAA traffic to separate groups of servers that have different operational characteristics.

In Cisco IOS XE Release 3.2SE, this feature was supported on the following platforms:

- Catalyst 3850 Series Switches

- Cisco 5760 Wireless LAN Controller

In Cisco IOS XE Release 3.3SE, this feature was supported on the following platforms:

- Catalyst 3650 Series Switches

The following commands were introduced or modified: deadtime.

Chapter 3. RADIUS for Multiple UDP Ports

RADIUS security servers are identified on the basis of their hostname or IP address, hostname and specific UDP port numbers, or IP address and specific UDP port numbers. The combination of the IP address and UDP port number creates a unique identifier, allowing different ports to be individually defined as RADIUS hosts providing a specific authentication, authorization, and accounting (AAA) service. This unique identifier enables RADIUS requests to be sent to multiple UDP ports on a server at the same IP address. If two different host entries on the same RADIUS server are configured for the same service—for example, accounting—the second host entry configured acts as a failover backup to the first one. If the first host entry fails to provide accounting services, the network access server tries the second host entry configured on the same device for accounting services.

- Finding Feature Information

- Prerequisites for RADIUS for Multiple UDP Ports

- Information About RADIUS for Multiple UDP Ports

- How to Configure RADIUS for Multiple UDP Ports

- Configuration Examples for RADIUS for Multiple UDP Ports

- Additional References

- Feature Information for RADIUS for Multiple UDP Ports

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for RADIUS for Multiple UDP Ports

To configure RADIUS on your Cisco device or access server, you must perform these tasks:

- Use the aaa new-model global configuration command to enable AAA. AAA must be configured if you plan to use RADIUS.

- Use the aaa authentication global configuration command to define method lists for RADIUS authentication.

- Use line and interface commands to enable the defined method lists to be used.

Information About RADIUS for Multiple UDP Ports

- Device-to-RADIUS Server Communication

Device-to-RADIUS Server Communication

The RADIUS host is normally a multiuser system running RADIUS server software from Cisco (CiscoSecure ACS), Livingston, Merit, Microsoft, or another software provider. Configuring device to RADIUS server communication can have several components:

- Hostname or IP address

- Authentication destination port

- Accounting destination port

- Timeout period

- Retransmission value

- Key string

RADIUS security servers are identified on the basis of their hostname or IP address, hostname and specific UDP port numbers, or IP address and specific UDP port numbers. The combination of the IP address and UDP port number creates a unique identifier, allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. This unique identifier enables RADIUS requests to be sent to multiple UDP ports on a server at the same IP address. If two different host entries on the same RADIUS server are configured for the same service—for example, accounting—the second host entry configured acts as a failover backup to the first one. If the first host entry fails to provide accounting services, the network access server tries the second host entry configured on the same device for accounting services. (The RADIUS host entries are tried in the order they are configured.)

A RADIUS server and a Cisco device use a shared secret text string to encrypt passwords and exchange responses. To configure RADIUS to use the AAA security commands, you must specify the host running the RADIUS server daemon and a secret text (key) string that it shares with the device.

The timeout, retransmission, and encryption key values are configurable globally for all RADIUS servers, on a per-server basis or in some combination of global and per-server settings. To apply these settings globally to all RADIUS servers communicating with the device, use the three unique global commands: radius-server timeout, radius-server retransmit, and radius-server key. To apply these values on a specific RADIUS server, use the radius-server host command.

Note

You can configure both global and per-server timeout, retransmission, and key value commands simultaneously on the same Cisco network access server. If both global and per-server functions are configured on a device, the per-server timer, retransmission, and key value commands override global timer, retransmission, and key value commands.

How to Configure RADIUS for Multiple UDP Ports

- Configuring Device-to-RADIUS Server Communication

Configuring Device-to-RADIUS Server Communication

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    radius server server-name

4.    address ipv4 ip-address

5.    key {0 string | 7 string | string}

6.    retransmit retries

7.    timeout seconds

8.    exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

radius server server-name

Example:

Device(config)# radius server rad1

Specifies the name for the RADIUS server.

Step 4

address ipv4 ip-address

Example:

Device(config-radius-server)# address ipv4 10.45.1.2

Assigns an IP address to the RADIUS server.

Step 5

key {0 string | 7 string | string}

Example:

Device(config-radius-server)# key myRaDIUSpassword

Specifies the shared secret text string used between the device and a RADIUS server.

Note:
In this step, the encryption key value is configured globally for all RADIUS servers.

- Use the 0 string option to configure an unencrypted shared secret. Use the 7 string option to configure an encrypted shared secret.

Step 6

retransmit retries

Example:

Device(config-radius-server)# retransmit 25

Specifies how many times the device transmits each RADIUS request to the server before giving up (the default is 3).

Note:
In this step, the retransmission value is configured globally for all RADIUS servers.

Step 7

timeout seconds

Example:

Device(config-radius-server)# timeout 6

Specifies for how many seconds a device waits for a reply to a RADIUS request before retransmitting the request.

Note:
In this step, the timeout value is configured globally for all RADIUS servers.

Step 8

exit

Example:

Device(config)# exit

Returns to privileged EXEC mode.

Configuration Examples for RADIUS for Multiple UDP Ports

- Example: Device-to-RADIUS Server Communication

- Example: RADIUS Server with Server-Specific Values

Example: Device-to-RADIUS Server Communication

The following example shows how to configure two RADIUS servers with specific timeout, retransmit, and key values. In this example, the aaa new-model command enables AAA services on the device, and specific AAA commands define the AAA services. The retransmit command changes the global retransmission value to 4 for all RADIUS servers. The host command configures specific timeout, retransmission, and key values for the RADIUS server hosts with IP addresses 172.16.1.1 and 172.29.39.46.

! Enable AAA services on the device and define those services.
aaa new-model
aaa authentication login default group radius
aaa authentication login console-login none
aaa authentication ppp default group radius
aaa authorization network default group radius
aaa accounting exec default start-stop group radius
aaa accounting network default start-stop group radius
enable password tryit1
!
Device(config)# radius server rad1
Device(config-radius-server)# address ipv4 10.45.1.2
Device(config-radius-server)# key myRaDIUSpassword
Device(config-radius-server)# retransmit 25
Device(config-radius-server)# timeout 6
Device(config)# exit

Example: RADIUS Server with Server-Specific Values

The following example shows how to configure server-specific timeout, retransmit, and key values for the RADIUS server with IP address 172.31.39.46:

radius-server host 172.31.39.46 timeout 6 retransmit 5 key rad123

Additional References

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Command List, All Releases

Security commands

- Cisco IOS Security Command Reference: Commands A to C

- Cisco IOS Security Command Reference: Commands D to L

- Cisco IOS Security Command Reference: Commands M to R

- Cisco IOS Security Command Reference: Commands S to Z

AAA

Authentication, Authorization, and Accounting Configuration Guide (part of the Securing User Services Configuration Library)

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

Click Here

Feature Information for RADIUS for Multiple UDP Ports

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to . An account on Cisco.com is not required.

Feature Information for RADIUS for Multiple UDP Ports

Feature Name

Releases

Feature Information

RADIUS for Multiple UDP Ports

Cisco IOS XE 3.2SE

Cisco IOS XE 3.3SE

RADIUS security servers are identified on the basis of their hostname or IP address, hostname and specific UDP port numbers, or IP address and specific UDP port numbers. The combination of the IP address and UDP port number creates a unique identifier, allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. This unique identifier enables RADIUS requests to be sent to multiple UDP ports on a server at the same IP address.

In Cisco IOS XE Release 3.2SE, this feature was supported on the following platforms:

- Catalyst 3850 Series Switches

In Cisco IOS XE Release 3.3SE, this feature was supported on the following platforms:

- Catalyst 3650 Series Switches

The following command was introduced or modified: radius-server host.

Chapter 4. RADIUS Server Load Balancing

The RADIUS Server Load Balancing feature distributes authentication, authorization, and accounting (AAA) authentication and accounting transactions across RADIUS servers in a server group. These servers can share the AAA transaction load and thereby respond faster to incoming requests.

This module describes the RADIUS Server Load Balancing feature.

- Finding Feature Information

- Prerequisites for RADIUS Server Load Balancing

- Restrictions for RADIUS Server Load Balancing

- Information About RADIUS Server Load Balancing

- How to Configure RADIUS Server Load Balancing

- Configuration Examples for RADIUS Server Load Balancing

- Additional References for RADIUS Server Load Balancing

- Feature Information for RADIUS Server Load Balancing

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to Click Here . An account on Cisco.com is not required.

Prerequisites for RADIUS Server Load Balancing

- Authentication, authorization, and accounting (AAA) must be configured on the RADIUS server.

- AAA RADIUS server groups must be configured.

- RADIUS must be configured for functions such as authentication, accounting, or static route download.

Restrictions for RADIUS Server Load Balancing

- Incoming RADIUS requests, such as Packet of Disconnect (POD) requests, are not supported.

- Load balancing is not supported on proxy RADIUS servers and for private server groups.

Information About RADIUS Server Load Balancing

- RADIUS Server Load Balancing Overview

- Transaction Load Balancing Across RADIUS Server Groups

- RADIUS Server Status and Automated Testing

RADIUS Server Load Balancing Overview

Load balancing distributes batches of transactions to RADIUS servers within a server group. Load balancing assigns each batch of transactions to the server with the lowest number of outstanding transactions in its queue. The process of assigning a batch of transactions is as follows:

1. The first transaction is received for a new batch.

2. All server transaction queues are checked.

3. The server with the lowest number of outstanding transactions is identified.

4. The identified server is assigned the next batch of transactions.

The batch size is a user-configured parameter. Changes in the batch size may impact CPU load and network throughput. As batch size increases, CPU load decreases and network throughput increases. However, if a large batch size is used, all available server resources may not be fully utilized. As batch size decreases, CPU load increases and network throughput decreases.

Note

There is no set number for large or small batch sizes. A batch with more than 50 transactions is considered large and a batch with fewer than 25 transactions is considered small.

Note

If a server group contains ten or more servers, we recommend that you set a high batch size to reduce CPU load.

Transaction Load Balancing Across RADIUS Server Groups

You can configure load balancing either per-named RADIUS server group or for the global RADIUS server group. The load balancing server group must be referred to as “radius” in the authentication, authorization, and accounting (AAA) method lists. All public servers that are part of the RADIUS server group are then load balanced.

You can configure authentication and accounting to use the same RADIUS server or different servers. In some cases, the same server can be used for preauthentication, authentication, or accounting transactions for a session. The preferred server, which is an internal setting and is set as the default, informs AAA to use the same server for the start and stop record for a session regardless of the server cost. When using the preferred server setting, ensure that the server that is used for the initial transaction (for example, authentication), the preferred server, is part of any other server group that is used for a subsequent transaction (for example, accounting).

The preferred server is not used if one of the following criteria is true:

- The load-balance method least-outstanding ignore-preferred-server command is used.

- The preferred server is dead.

- The preferred server is in quarantine.

- The want server flag has been set, overriding the preferred server setting.

The want server flag, an internal setting, is used when the same server must be used for all stages of a multistage transaction regardless of the server cost. If the want server is not available, the transaction fails.

You can use the load-balance method least-outstanding ignore-preferred-server command if you have either of the following configurations:

- Dedicated authentication server and a separate dedicated accounting server

- Network where you can track all call record statistics and call record details, including start and stop records and records that are stored on separate servers

If you have a configuration where authentication servers are a superset of accounting servers, the preferred server is not used.

RADIUS Server Status and Automated Testing

The RADIUS Server Load Balancing feature considers the server status when assigning batches. Transaction batches are sent only to live servers. We recommend that you test the status of all RADIUS load-balanced servers, including low usage servers (for example, backup servers).

Transactions are not sent to a server that is marked dead. A server is marked dead until its timer expires, at which time it moves to quarantine state. A server is in quarantine until it is verified alive by the RADIUS automated tester functionality.

To determine if a server is alive and available to process transactions, the RADIUS automated tester sends a request periodically to the server for a test user ID. If the server returns an Access-Reject message, the server is alive; otherwise the server is either dead or quarantined.

A transaction sent to an unresponsive server is failed over to the next available server before the unresponsive server is marked dead. We recommend that you use the retry reorder mode for failed transactions.

When using the RADIUS automated tester, verify that the authentication, authorization, and accounting (AAA) servers are responding to the test packets that are sent by the network access server (NAS). If the servers are not configured correctly, packets may be dropped and the server erroneously marked dead.

Caution

We recommend that you use a test user that is not defined on the RADIUS server for the RADIUS server automated testing to protect against security issues that may arise if the test user is not correctly configured.

Note

Use the test aaa group command to check load-balancing transactions.

How to Configure RADIUS Server Load Balancing

- Enabling Load Balancing for a Named RADIUS Server Group

- Troubleshooting RADIUS Server Load Balancing

Enabling Load Balancing for a Named RADIUS Server Group

SUMMARY STEPS

1.    enable

2.    configure terminal

3.    aaa group server radius group-name

4.    server ip-address [auth-port port-number] [acct-port port-number]

5.    load-balance method least-outstanding [batch-size number] [ignore-preferred-server]

6.    end

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

- Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

aaa group server radius group-name

Example:

Device(config)# aaa group server radius rad-sg

Enters server group configuration mode.

Step 4

server ip-address [auth-port port-number] [acct-port port-number]

Example:

Device (config-sg-radius)server 192.0.2.238 auth-port 2095 acct-port 2096

Configures the IP address of the RADIUS server for the group server.

Step 5

load-balance method least-outstanding [batch-size number] [ignore-preferred-server]

Example:

Device(config-sg-radius)# load-balance method least-outstanding batch-size 30

Enables the least-outstanding load balancing for a named server group.

Step 6

end

Example:

Device(config-sg)# end

Exits server group configuration mode and enters privileged EXEC mode.

Troubleshooting RADIUS Server Load Balancing

After configuring the RADIUS Server Load Balancing feature, you can monitor the idle timer, dead timer, and load balancing server selection or verify the server status by using a manual test command.

SUMMARY STEPS

1.    Use the debug aaa test command to determine when an idle timer or dead timer has expired, when test packets are sent, the status of the server, or to verify the server state.

2.    Use the debug aaa sg-server selection command to determine the server that is selected for load balancing.

3.    Use the test aaa group command to manually verify the RADIUS load-balanced server status.

DETAILED STEPS

Step 1

Use the debug aaa test command to determine when an idle timer or dead timer has expired, when test packets are sent, the status of the server, or to verify the server state.

The idle timer is used to check the server status and is updated with or without any incoming requests. Monitoring the idle timer helps to determine if there are nonresponsive servers and to keep the RADIUS server status updated to efficiently utilize available resources. For instance, an updated idle timer would help ensure that incoming requests are sent to servers that are alive.

The dead timer is used either to determine that a server is dead or to update a dead server’s status appropriately.

Monitoring server selection helps to determine how often the server selection changes. Server selection is effective in analyzing if there are any bottlenecks, a large number of queued requests, or if only specific servers are processing incoming requests.

The following sample output from the debug aaa test command shows when the idle timer expired:

Example:

Device# debug aaa test

Jul 16 00:07:01: AAA/SG/TEST: Server (192.0.2.245:1700,1701) quarantined.
Jul 16 00:07:01: AAA/SG/TEST: Sending test request(s) to server (192.0.2.245:1700,1701)
Jul 16 00:07:01: AAA/SG/TEST: Sending 1 Access-Requests, 1 Accounting-Requests in current batch.
Jul 16 00:07:01: AAA/SG/TEST(Req#: 1): Sending test AAA Access-Request.
Jul 16 00:07:01: AAA/SG/TEST(Req#: 1): Sending test AAA Accounting-Request.
Jul 16 00:07:01: AAA/SG/TEST: Obtained Test response from server (192.0.2.245:1700,1701)
Jul 16 00:07:01: AAA/SG/TEST: Obtained Test response from server (192.0.2.245:1700,1701)
Jul 16 00:07:01: AAA/SG/TEST: Necessary responses received from server (192.0.2.245:1700,1701)
Jul 16 00:07:01: AAA/SG/TEST: Server (192.0.2.245:1700,1701) marked ALIVE. Idle timer set for 60 sec(s).
Jul 16 00:07:01: AAA/SG/TEST: Server (192.0.2.245:1700,1701) removed from quarantine.

Step 2

Use the debug aaa sg-server selection command to determine the server that is selected for load balancing.

The following sample output from the debug aaa sg-server selection command shows five access requests being sent to a server group with a batch size of three:

Example:

Device# debug aaa sg-server selection

Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Obtaining least loaded server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: [3] transactions remaining in batch. Reusing server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Obtaining least loaded server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: [2] transactions remaining in batch. Reusing server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Obtaining least loaded server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: [1] transactions remaining in batch. Reusing server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Obtaining least loaded server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: No more transactions in batch. Obtaining a new server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Obtaining a new least loaded server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Server[0] load: 3
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Server[1] load: 0
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Server[2] load: 0
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Selected Server[1] with load 0
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: [3] transactions remaining in batch.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: Obtaining least loaded server.
Jul 16 03:15:05: AAA/SG/SERVER_SELECT: [2] transactions remaining in batch. Reusing server.

Step 3

Use the test aaa group command to manually verify the RADIUS load-balanced server status.

The following sample output shows the response from a load-balanced RADIUS server that is alive when the username “test” does not match a user profile. The server is verified alive when it issues an Access-Reject response to an authentication, authorization, and accounting (AAA) packet generated using the test aaa group command.

Example:

Device# test aaa group SG1 test lab new-code

00:06:07: RADIUS/ENCODE(00000000):Orig. component type = INVALID
00:06:07: RADIUS/ENCODE(00000000): dropping service type, "radius-server attribute 6 on-for-login-auth" is off
00:06:07: RADIUS(00000000): Config NAS IP: 192.0.2.4
00:06:07: RADIUS(00000000): sending
00:06:07: RADIUS/ENCODE: Best Local IP-Address 192.0.2.141 for Radius-Server 192.0.2.176
00:06:07: RADIUS(00000000): Send Access-Request to 192.0.2.176:1645 id 1645/1, len 50
00:06:07: RADIUS:  authenticator CA DB F4 9B 7B 66 C8 A9 - D1 99 4E 8E A4 46 99 B4
00:06:07: RADIUS:  User-Password       [2]   18  *
00:06:07: RADIUS:  User-Name           [1]   6   "test"
00:06:07: RADIUS:  NAS-IP-Address      [4]   6   192.0.2.141
00:06:07: RADIUS: Received from id 1645/1 192.0.2.176:1645, Access-Reject, len 44
00:06:07: RADIUS:  authenticator 2F 69 84 3E F0 4E F1 62 - AB B8 75 5B 38 82 49 C3
00:06:07: RADIUS:  Reply-Message       [18]  24
00:06:07: RADIUS:   41 75 74 68 65 6E 74 69 63 61 74 69 6F 6E 20 66  [Authentication f]
00:06:07: RADIUS:   61 69 6C 75 72 65                                [failure]
00:06:07: RADIUS(00000000): Received from id 1645/1
00:06:07: RADIUS/DECODE: Reply-Message fragments, 22, total 22 bytes

Configuration Examples for RADIUS Server Load Balancing

- Example: Enabling Load Balancing for a Named RADIUS Server Group

- Example: Monitoring Idle Timer

- Example: Configuring the Preferred Server with the Same Authentication and Authorization Server

- Example: Configuring the Preferred Server with Different Authentication and Authorization Servers

- Example: Configuring the Preferred Server with Overlapping Authentication and Authorization Servers

- Example: Configuring the Preferred Server with Authentication Servers As a Subset of Authorization Servers

- Example: Configuring the Preferred Server with Authentication Servers As a Superset of Authorization Servers

Example: Enabling Load Balancing for a Named RADIUS Server Group

The following examples show load balancing enabled for a named RADIUS server group. These examples are shown in three parts: the current configuration of the RADIUS command output, debug output, and authentication, authorization, and accounting (AAA) server status information.

The following sample output shows the relevant RADIUS configuration:

Device# show running-config
.
.
.
aaa group server radius server-group1
server 192.0.2.238 auth-port 2095 acct-port 2096
server 192.0.2.238 auth-port 2015 acct-port 2016
load-balance method least-outstanding batch-size 5
!
aaa authentication ppp default group server-group1
aaa accounting network default start-stop group server-group1
.
.
.
Device(config-sg-radius)# load-balance method least-outstanding batch-size 30

The lines in the current configuration of the preceding RADIUS command output are defined as follows:

- The aaa group server radius command shows the configuration of a server group with two member servers.

- The load-balance command enables load balancing for global RADIUS server groups with the batch size specified.

- The aaa authentication ppp command authenticates all PPP users using RADIUS.

- The aaa accounting command enables sending of all accounting requests to the AAA server when the client is authenticated and then disconnected using the start-stop keyword.

The show debug sample output below shows the selection of the preferred server and the processing of requests for the preceding configuration:

Device# show debug

*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT(0000002C):No preferred server available.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:Obtaining least loaded server.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:No more transactions in batch. Obtaining a new server.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:Obtaining a new least loaded server.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:Server[0] load:0
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:Server[1] load:0
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:Selected Server[0] with load 0
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:[5] transactions remaining in batch.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT(0000002C):Server (192.0.2.238:2095,2096) now being used as preferred server
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT(0000002D):No preferred server available.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:Obtaining least loaded server.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:[4] transactions remaining in batch. Reusing server.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT(0000002D):Server (192.0.2.238:2095,2096) now being used as preferred server
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT(0000002E):No preferred server available.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:Obtaining least loaded server.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:[3] transactions remaining in batch. Reusing server.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT(0000002E):Server (192.0.2.238:2095,2096) now being used as preferred server
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT(0000002F):No preferred server available.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:Obtaining least loaded server.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:[2] transactions remaining in batch. Reusing server.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT(0000002F):Server (192.0.2.238:2095,2096) now being used as preferred server
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT(00000030):No preferred server available.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:Obtaining least loaded server.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT:[1] transactions remaining in batch. Reusing server.
*Feb 28 13:51:16.019:AAA/SG/SERVER_SELECT(00000030):Server (192.0.2.238:2095,2096) now being used as preferred server
*Feb 28 13:51:16.023:AAA/SG/SERVER_SELECT(00000031):No preferred server available.
*Feb 28 13:51:16.023:AAA/SG/SERVER_SELECT:Obtaining least loaded server.
*Feb 28 13:51:16.023:AAA/SG/SERVER_SELECT:No more transactions in batch. Obtaining a new server.
*Feb 28 13:51:16.023:AAA/SG/SERVER_SELECT:Obtaining a new least loaded server.
*Feb 28 13:51:16.023:AAA/SG/SERVER_SELECT:Server[1] load:0
*Feb 28 13:51:16.023:AAA/SG/SERVER_SELECT:Server[0] load:5
*Feb 28 13:51:16.023:AAA/SG/SERVER_SELECT:Selected Server[1] with load 0
*Feb 28 13:51:16.023:AAA/SG/SERVER_SELECT:[5] transactions remaining in batch.
*Feb 28 13:51:16.023:AAA/SG/SERVER_SELECT(00000031):Server (192.0.2.238:2015,2016) now being used as preferred server
*Feb 28 13:51:16.023:AAA/SG/SERVER_SELECT(00000032):No preferred server available.
*Feb 28 13:51:16.023:AAA/SG/SERVER_SELECT:Obtaining least loaded server.
*Feb 28 13:51:16.023:AAA/SG/SERVER_SELECT:[4] transactions remaining in batch. Reusing server.
.
.
.

The following sample output from the show aaa servers command shows the AAA server status for the named RADIUS server group configuration:

The sample output shows the status of two RADIUS servers. Both servers are alive, and no requests have been processed since the counters were cleared 0 minutes ago.

Device# show aaa servers

RADIUS:id 8, priority 1, host 192.0.2.238, auth-port 2095, acct-port 2096
State:current UP, duration 3781s, previous duration 0s
Dead:total time 0s, count 0
Quarantined:No
Authen:request 0, timeouts 0
Response:unexpected 0, server error 0, incorrect 0, time 0ms
Transaction:success 0, failure 0
Author:request 0, timeouts 0
Response:unexpected 0, server error 0, incorrect 0, time 0ms
Transaction:success 0, failure 0
Account:request 0, timeouts 0
Response:unexpected 0, server error 0, incorrect 0, time 0ms
Transaction:success 0, failure 0
Elapsed time since counters last cleared:0m
RADIUS:id 9, priority 2, host 192.0.2.238, auth-port 2015, acct-port 2016
State:current UP, duration 3781s, previous duration 0s
Dead:total time 0s, count 0
Quarantined:No
Authen:request 0, timeouts 0
Response:unexpected 0, server error 0, incorrect 0, time 0ms
Transaction:success 0, failure 0
Author:request 0, timeouts 0
Response:unexpected 0, server error 0, incorrect 0, time 0ms
Transaction:success 0, failure 0
Account:request 0, timeouts 0
Response:unexpected 0, server error 0, incorrect 0, time 0ms
Transaction:success 0, failure 0
Elapsed time since counters last cleared:0m

Example: Monitoring Idle Timer

The following example shows idle timer and related server state for load balancing enabled for a named RADIUS server group. The current configuration of the RADIUS command output and debug command output are also displayed.

The following sample output shows the relevant RADIUS configuration:

Device# show running-config | include radius

aaa group server radius server-group1
radius-server host 192.0.2.238 auth-port 2095 acct-port 2096 test username junk1 idle-time 1 key cisco
radius-server host 192.0.2.238 auth-port 2015 acct-port 2016 test username junk1 idle-time 1 key cisco
radius-server load-balance method least-outstanding batch-size 5

The lines in the current configuration of the preceding RADIUS command output are defined as follows:

- The aaa group server radius command shows the configuration of a server group.

- The radius-server host command defines the IP address of the RADIUS server host with authorization and accounting ports specified and the authentication and encryption key identified.

- The radius-server load-balance command enables load balancing for the RADIUS server with the batch size specified.

The show debug sample output below shows test requests being sent to servers. The response to the test request sent to the server is received, the server is removed from quarantine as appropriate, the server is marked alive, and then the idle timer is reset.

Device# show debug

*Feb 28 13:52:20.835:AAA/SG/TEST:Server (192.0.2.238:2015,2016) quarantined.
*Feb 28 13:52:20.835:AAA/SG/TEST:Sending test request(s) to server (192.0.2.238:2015,2016)
*Feb 28 13:52:20.835:AAA/SG/TEST:Sending 1 Access-Requests, 1 Accounting-Requests in current batch.
*Feb 28 13:52:20.835:AAA/SG/TEST(Req#:1):Sending test AAA Access-Request.
*Feb 28 13:52:20.835:AAA/SG/TEST(Req#:1):Sending test AAA Accounting-Request.
*Feb 28 13:52:21.087:AAA/SG/TEST:Obtained Test response from server (192.0.2.238:2015,2016)
*Feb 28 13:52:22.651:AAA/SG/TEST:Obtained Test response from server (192.0.2.238:2015,2016)
*Feb 28 13:52:22.651:AAA/SG/TEST:Necessary responses received from server (192.0.2.238:2015,2016)
*Feb 28 13:52:22.651:AAA/SG/TEST:Server (192.0.2.238:2015,2016) marked ALIVE. Idle timer set for 60 secs(s).
*Feb 28 13:52:22.651:AAA/SG/TEST:Server (192.0.2.238:2015,2016) removed from quarantine.
.
.
.

Example: Configuring the Preferred Server with the Same Authentication and Authorization Server

The following example shows an authentication server group and an authorization server group that use the same servers 209.165.200.225 and 209.165.200.226. Both server groups have the preferred server flag enabled.

aaa group server radius authentication-group
server 209.165.200.225 key radkey1
server 209.165.200.226 key radkey2
aaa group server radius accounting-group
server 209.165.200.225 key radkey1
server 209.165.200.226 key radkey2

When a preferred server is selected for a session, all transactions for that session will continue to use the original preferred server. The servers 209.165.200.225 and 209.165.200.226 are load balanced based on sessions rather than transactions.

Example: Configuring the Preferred Server with Different Authentication and Authorization Servers

The following example shows an authentication server group that uses servers 209.165.200.225 and 209.165.200.226 and an authorization server group that uses servers 209.165.201.1 and 209.165.201.2. Both server groups have the preferred server flag enabled.

aaa group server radius authentication-group
server 209.165.200.225 key radkey1
server 209.165.200.226 key radkey2
aaa group server radius accounting-group
server 209.165.201.1 key radkey3
server 209.165.201.2 key radkey4

The authentication server group and the accounting server group do not share any common servers. A preferred server is never found for accounting transactions; therefore, authentication and accounting servers are load-balanced based on transactions. Start and stop records are sent to the same server for a session.

Example: Configuring the Preferred Server with Overlapping Authentication and Authorization Servers

The following example shows an authentication server group that uses servers 209.165.200.225, 209.165.200.226, and 209.165.201.1 and an accounting server group that uses servers 209.165.201.1 and 209.165.201.2. Both server groups have the preferred server flag enabled.

aaa group server radius authentication-group
server 209.165.200.225 key radkey1
server 209.165.200.226 key radkey2
server 209.165.201.1 key radkey3
aaa group server radius accounting-group
server 209.165.201.1 key radkey3
server 209.165.201.2 key radkey4

If all servers have equal transaction processing capability, one-third of all authentication transactions are directed toward the server 209.165.201.1. Therefore, one-third of all accounting transactions are also directed toward the server 209.165.201.1. The remaining two-third of accounting transactions are load balanced equally between servers 209.165.201.1 and 209.165.201.2. The server 209.165.201.1 receives fewer authentication transactions because the server 209.165.201.1 has outstanding accounting transactions.

Example: Configuring the Preferred Server with Authentication Servers As a Subset of Authorization Servers

The following example shows an authentication server group that uses servers 209.165.200.225 and 209.165.200.226 and an authorization server group that uses servers 209.165.200.225, 209.165.200.226, and 209.165.201.1. Both server groups have the preferred server flag enabled.

aaa group server radius authentication-group
server 209.165.200.225 key radkey1
server 209.165.200.226 key radkey2
aaa group server radius accounting-group
server 209.165.200.225 key radkey1
server 209.165.200.226 key radkey2
server 209.165.201.1 key radkey3

One-half of all authentication transactions are sent to the server 209.165.200.225 and the other half to the server 209.165.200.226. Servers 209.165.200.225 and 209.165.200.226 are preferred servers for authentication and accounting transaction. Therefore, there is an equal distribution of authentication and accounting transactions across servers 209.165.200.225 and 209.165.200.226. The server 209.165.201.1 is relatively unused.

Example: Configuring the Preferred Server with Authentication Servers As a Superset of Authorization Servers

The following example shows an authentication server group that uses servers 209.165.200.225, 209.165.200.226, and 209.165.201.1 and an authorization server group that uses servers 209.165.200.225 and 209.165.200.226. Both server groups have the preferred server flag enabled.

aaa group server radius authentication-group
server 209.165.200.225 key radkey1
server 209.165.200.226 key radkey2
server 209.165.201.1 key radkey3
aaa group server radius accounting-group
server 209.165.200.225 key radkey1
server 209.165.200.226 key radkey2

Initially, one-third of authentication transactions are assigned to each server in the authorization server group. As accounting transactions are generated for more sessions, accounting transactions are sent to servers 209.165.200.225 and 209.165.200.226 because the preferred server flag is on. As servers 209.165.200.225 and 209.165.200.226 begin to process more transactions, authentication transactions will start to be sent to server 209.165.201.1. Transaction requests authenticated by server 209.165.201.1 do not have any preferred server setting and are split between servers 209.165.200.225 and 209.165.200.226, which negates the use of the preferred server flag. This configuration should be used cautiously.

Additional References for RADIUS Server Load Balancing

Related Documents

Related Topic

Document Title

Cisco IOS commands

Cisco IOS Master Command List, All Releases

Security commands

- Security Command Reference: Commands A to C

- Security Command Reference: Commands D to L

- Security Command Reference: Commands M to R

- Security Command Reference: Commands S to Z

AAA and RADIUS

Authentication, Authorization, and Accounting Configuration Guide

AAA server groups and RADIUS configuration

“Configuring RADIUS” module in the RADIUS Configuration Guide

Failover retry reorder mode

“RADIUS Server Reorder on Failure” module in the RADIUS Configuration Guide

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.

To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

Click Here

Feature Information for RADIUS Server Load Balancing

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to . An account on Cisco.com is not required.

Feature Information for RADIUS Server Load Balancing

Feature Name

Releases

Feature Information

RADIUS Server Load Balancing

Cisco IOS XE 3.2SE

Cisco IOS XE 3.3SE

Cisco IOS XE 3.5E

The RADIUS Server Load Balancing feature distributes authentication, authorization, and accounting (AAA) authentication and accounting transactions across servers in a server group. These servers can share the AAA transaction load and thereby respond faster to incoming requests.

In Cisco IOS XE Release 3.2SE, this feature was supported on the following platforms:

- Catalyst 3850 Series Switches

- Cisco 5760 Wireless LAN Controller

In Cisco IOS XE Release 3.3SE, this feature was supported on the following platforms:

- Catalyst 3650 Series Switches

The following commands were introduced or modified: debug aaa sg-server selection, debug aaa test, load-balance (server-group), radius-server host, radius-server load-balance, and test aaa group.