- Overview of Dial Interfaces, Controllers, and Lines
- Configuring Asynchronous Lines and Interfaces
- Asynchronous Call Queueing by Role
- Configuring Asynchronous Serial Traffic Over UDP
- Configuring and Managing Integrated Modems
- 1- and 2-Port V.90 Modem WICs for Cisco 2600 and Cisco 3600 Series Multiservice Platforms
- Call Tracker show Commands Extensions
- Cisco NM-8AM-V2 and NM-16AM-V2 Analog Modem Network Modules with V.92
- MICA and NextPort Modem Tech-Support Command Additions
- PIAFS Wireless Data Protocol Version 2.1 for Cisco MICA Modems
- V.92 and V.44 Support for Digital Modems
- V.92 Modem on Hold for Cisco AS5300 and Cisco AS5800 Universal Access Servers
- V.92 Modem on Hold for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways and Cisco AS5800 Universal Access Servers
- V.92 Quick Connect for Cisco AS5300 and Cisco AS5800 Universal Access Servers
- V.92 Quick Connect for Cisco AS5350, Cisco AS5400, and Cisco AS5850 Universal Gateways and Cisco AS5800 Universal Access Servers
- V.92 Reporting Using RADIUS Attribute v.92-info
- Configuring and Managing Cisco Access Servers and Dial Shelves
- Configuring and Managing External Modems
- Modem Signal and Line States
- Creating and Using Modem Chat Scripts
- Cisco Modem User Interface
- Modem Script and System Script Support in Large-Scale Dial-Out
- Leased and Switched BRI Interface for ETSI NET3
- ISDN BCAC and Round-Robin Channel Selection Enhancements
- Configuring Virtual Asynchronous Traffic over ISDN
- Configuring Modem Use over ISDN BRI
- Configuring X.25 on ISDN
- Configuring X.25 on ISDN Using AO/DI
- Configuring ISDN on Cisco 800 Series Routers
- Cisco IOS Software Feature Removal
- Configuring ISDN PRI
- Dialing Number Enhancement
- ISDN BCAC and Round-Robin Channel Selection Enhancements
- Configuring ISDN Special Signaling
- Configuring Network Side ISDN PRI Signaling, Trunking, and Switching
- Preparing to Configure DDR
- Configuring Legacy DDR Spokes
- Configuring Legacy DDR Hubs
- Configuring Peer-to-Peer DDR with Dialer Profiles
- Dialer Map VRF-Aware for an MPLS VPN
- Dialer Persistent
- PPPoE Client DDR Idle-Timer
- Redial Enhancements
- Rotating Through Dial Strings
- Configuring Dialer CEF
- CEF Support for Dialer Profiles on Cisco 7500 Routers
- Configuring Snapshot Routing
- Reliable Static Routing Backup Using Object Tracking
- Configuring Dial Backup for Serial Lines
- Configuring Dial Backup Using Dialer Watch
- Dialer Watch Connect Delay
- VRF Aware Dialer Watch
- Configuring Dial Backup with Dialer Profiles
- ISDN Backup in MPLS Core
- Configuring Cisco Easy IP ..
- Configuring Virtual Template Interfaces
- Multiclass Multilink PPP
- Configuring Asynchronous Callback
- Configuring PPP Callback
- Configuring ISDN Caller ID Callback
- Configuring BACP
- Configuring an IP Local Pools Holdback Timer
- Configuring per-User Configuration
- Configuring Resource Pool Management
- Configuring Wholesale Dial Performance Optimization
- Large-Scale Dial-Out
- Dial-Out DS0 Level Trunk Group
- L2TP Large-Scale Dial-Out
- L2TP Large-Scale Dial-Out per-User Attribute via AAA
- Modem Script and System Script Support in Large-Scale Dial-Out
- Large-Scale Dial-Out (LSDO) VRF Aware
- Peer Pool Backup
- Dial Networking Business Applications
- Enterprise Dial Scenarios and Configurations
- Telco and ISP Typical Dial Scenarios and Configurations
- Modem Initialization Strings
Configuring per-User Configuration
This chapter describes per-user configuration, a large-scale dial solution. It includes the following main sections:
- Per-User Configuration Overview
- How to Configure a AAA Server for Per-User Configuration
- Monitoring and Debugging Per-User Configuration Settings
- Configuration Examples for Per-User Configuration
This set of features is supported on all platforms that support Multilink PPP (MLP).
A virtual access interface created dynamically for any user dial-in session is deleted when the session ends. The resources used during the session are returned for other dial-in uses.
When a specific user dials in to a router, the use of a per-user configuration from an authentication, authorization, and accounting (AAA) server requires that AAA is configured on the router and that a configuration for that user exists on the AAA server.
To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the “Identifying Supported Platforms” section in the “Using Cisco IOS Software” chapter.
For a complete description of the commands mentioned in this chapter, refer to the Cisco IOS Dial Technologies Command Reference, Release 12.2 and the Cisco IOS Security Command Reference, Release 12.2. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
Per-User Configuration Overview
Per-user configuration provides a flexible, scalable, easily maintained solution for customers with a large number of dial-in users. This solution can tie together the following dial-in features:
- Virtual template interfaces, generic interface configuration and router-specific configuration information stored in the form of a virtual template interface that can be applied ( cloned ) to a virtual access interface each time any user dials in. This configuration is described in the chapter “Configuring Virtual Template Interfaces” in this publication.
- AAA per-user security and interface configuration information stored on a separate AAA server and sent by the AAA server to the access server or router in response to authorization requests during the PPP authentication phase. The per-user configuration information can add to or override the generic configuration on a virtual interface.
- Virtual profiles, which can use either or both of the two sources of information listed in the previous bullets for virtual interface configuration. When a user dials in, virtual profiles can apply the generic interface configuration and then apply the per-user configuration to create a unique virtual access interface for that user. This configuration is described in the chapter “Configuring Virtual Profiles” in this publication.
The per-user configuration feature provides these benefits:
- Maintenance ease for service providers with a large number of access servers and a very large number of dial-in users. Service providers need not update all their routers and access servers when user-specific information changes; instead, they can update one AAA server.
- Scalability. By separating generic virtual interface configuration on the router from the configuration for each individual, Internet service providers and other enterprises with large numbers of dial-in users can provide a uniquely configured interface for each individual user. In addition, by separating the generic virtual interface configuration from the physical interfaces on the router, the number and types of physical interfaces on the router or access server are not intrinsic barriers to growth.
General Operational Processes
In general, the per-user configuration process on the Cisco router or network access server proceeds as follows:
2. The authentication and authorization phases occur.
a. If AAA is configured, the router sends an authorization request to the AAA server.
b. If the AAA server has information (attribute-value or AV pairs, or other configuration parameters) that defines a configuration for the specific user, the server includes it in the information in the approval response packet.
Figure 1 illustrates the request and response part of the process that happens when a user dials in, given that AAA is configured and that the AAA server has per-user configuration information for the dial-in user.
c. The router looks for AV pairs in the AAA approval response.
d. The router caches the configuration parameters.

Note TACACS servers treat authentication and authorization as two phases; RADIUS servers combine authentication and authorization into a single step. For more detailed information, refer to your server documentation.
Figure 1 Per-User Configuration Authentication and Authorization

3. A virtual access interface is created for this user.
a. The router finds the virtual template that is set up for virtual profiles, if any, and applies the commands to the virtual access interface.
b. The router looks for the AV pairs to apply to this virtual access interface to configure it for the dial-in user.
c. The AV pairs are sent to the Cisco IOS command-line parser, which interprets them as configuration commands and applies them to configure this virtual access interface.
The result of this process is a virtual access interface configured uniquely for the dial-in user.
When the user ends the call, the virtual access interface is deleted and its resources are returned for other dial-in uses.

Note The use of virtual profiles can modify the process that occurs between the user dial-in and the use of AAA configuration information. For more information, see the chapter “Configuring Virtual Profiles” in this publication.
Operational Processes with IP Address Pooling
During IP Control Protocol (IPCP) address negotiation, if an IP pool name is specified for a user, the network access server checks whether the named pool is defined locally. If it is, no special action is required and the pool is consulted for an IP address.
If the required pool is not present (either in the local configuration or as a result of a previous download operation), an authorization call to obtain it is made using the special username:
where nas-name is the configured name of the network access server. In response, the AAA server downloads the configuration of the required pool.
This pool username can be changed using Cisco IOS configuration, for example:
This command has the effect of changing the username that is used to download the pool definitions from the default name “pools- nas-name” to “nas1-pools-definition.cisco.com.”
On a TACACS+ server, the entries for an IP address pool and a user of the pool might be as follows:
On a RADIUS server, the entries for the same IP address pool and user would be as follows:

Note This entry specifies a User-Service-Type of Outbound-User. This attribute is supplied by the network access server to prevent ordinary logins from using the well-known username and password combination of nas1-pools/cisco.
Pools downloaded to a Cisco network access server are not retained in nonvolatile memory and automatically disappear whenever the access server or router restarts. Downloaded pools can also be made to time out automatically by adding a suitable AV pair. For more information, see the section “Supported Attrubutes for AV Pairs” and the pool-timeout attribute in Table 1 . Downloaded pools are marked as dynamic in the output of the show ip local pool command.
Deleting Downloaded Pools
To delete downloaded pools, you can do either of the following:
- Manually delete the definition from the network access server. For example, if “bbb” is the name of a downloaded pool, you can enter the Cisco IOS no ip local pool bbb command.
Deleting a pool definition does not interrupt service for current users. If a pool is deleted and then redefined to include a pool address that is currently allocated, the new pool understands and tracks the address as expected.
The pool-timeout AV pair starts a timer when the pool is downloaded. Once the timer expires, the pools are deleted. The next reference to the pools again causes an authorization call to be made, and the pool definition is downloaded again. This method allows definitions to be made and changed on the AAA server and propagated to network access servers.
Supported Attributes for AV Pairs
Table 1 provides a partial list of the Cisco-specific supported attributes for AV pairs that can be used for per-user virtual interface configuration. For complete lists of Cisco-specific, vendor-specific, and TACACS+ supported attributes, see the Cisco IOS Security Configuration Guide and Cisco IOS Security Command Reference.
|
|
---|---|
An input access list definition. For IP, standard or extended access list syntax can be used, although you cannot mix them within a single list. For Internet Protocol Exchange (IPX), only extended syntax is recognized. The value of this attribute is the text that comprises the body of a named access list definition. |
|
outacl#1 |
An output access list definition. For IP, standard or extended access list syntax can be used. For IPX, only extended syntax is recognized. The value of this attribute is the text that comprises the body of a named access list definition. |
An input route filter. For IP, standard or extended access list syntax can be used, although you cannot mix them within a single list. For IPX, only extended syntax is recognized. The first line of this filter must specify a routing process. Subsequent lines comprise the body of a named access list. |
|
An output route filter. For IP, standard or extended access list syntax can be used, although you cannot mix them within a single list. For IPX, only extended syntax is recognized. The first line of this filter must specify a routing process. Subsequent lines comprise the body of a named access list. |
|
route#2 |
Static routes, for IP and IPX. The value is text of the form destination-address mask [ gateway ]. |
IPX static Service Advertising Protocol (SAP). The value is text from the body of an ipx sap configuration command. |
|
IPX input SAP filter. Only extended access list syntax is recognized. The value is text from the body of an extended IPX access-list configuration command. (The Novell socket number for SAP filtering is 452.) |
|
IPX output SAP filter. Only extended access-list command syntax is recognized. The value is text from the body of an extended IPX access-list configuration command. |
|
An IP pool definition. The value is text from the body of an ip local pool configuration command. |
|
An IP pool definition. The body is an integer representing a timeout, in minutes. |
Table 2 provides examples for each attribute on an AAA TACACS+ server.
Table 3 provides examples for each attribute on an AAA RADIUS server.
|
|
---|---|
lcp:interface-config3 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.This attribute is specific to RADIUS servers. It can be used to add Cisco IOS interface configuration commands to specific user configuration information. |
How to Configure a AAA Server for Per-User Configuration
The configuration requirements and the structure of per-user configuration information is set by the specifications of each type of AAA server. Refer to your server documentation for more detailed information. The following sections about TACACS and RADIUS servers are specific to per-user configuration:
- Configuring a Freeware TACACS Server for Per-User Configuration (As required)
- Configuring a CiscoSecure TACACS Server for Per-User Configuration (As required)
- Configuring a RADIUS Server for Per-User Configuration (As required)
See the section “Monitoring and Debugging Per-User Configuration Settings” later in this chapter for tips on troubleshooting per-user configuration settings. See the section “Configuration Examples for Per-User Configuration” at the end of this chapter for examples of configuring RADIUS and TACACS servers.
Configuring a Freeware TACACS Server for Per-User Configuration
On a TACACS server, the entry in the user file takes a standard form. In the freeware version of TACACS+, the following lines appear in order:
- “User =” followed by the username, a space, and an open brace
- Authentication parameters
- Authorization parameters
- One or more AV pairs
- End brace on a line by itself
The general form of a freeware TACACS user entry is shown in the following example:
The freeware TACACS user entry form is also shown by the following examples for specific users:
For more requirements and detailed information, refer to your AAA server documentation.
Configuring a CiscoSecure TACACS Server for Per-User Configuration
The format of an entry in the user file in the AAA database is generally name = value. Some values allow additional subparameters to be specified and, in these cases, the subparameters are enclosed in braces ({}). The following simple example depicts an AAA database showing the default user, one group, two users that belong to the group, and one user that does not:
For more information about the requirements and details of configuring the CiscoSecure server, see the CiscoSecure UNIX Server User Guide.
Configuring a RADIUS Server for Per-User Configuration
On a RADIUS server, the format of an entry in the users file includes the following lines in order:

Note All these AV pairs are vendor specific. To use them, RADIUS servers must support the use of vendor-specific AV pairs. Patches for some servers are available from the Cisco Consulting Engineering (CE) customer-support organization.
The structure of an AV pair for Cisco platforms starts with cisco-avpair followed by a space, an equal sign, and another space. The rest of the line is within double quotation marks and, for all lines but the last, ends with a comma. Inside the double quotation marks is a phrase indicating the supported attribute, another equal sign, and a Cisco IOS command. The following examples show two different partial user configurations on a RADIUS server.
Monitoring and Debugging Per-User Configuration Settings
Per-user configuration information exists on AAA servers only and is configured there, as described in the “How to Configure a AAA Server for Per-User Configuration” section.
For more information about configuring an application that can tie AAA per-user configuration information to generic interface and router configuration, see the chapter “Configuring Virtual Profiles” in this publication. Virtual profiles are required for combining per-user configuration information and generic interface and router configuration information to create virtual access interfaces for individual ISDN B channels.
However, you can monitor and debug the per-user configuration settings on the router or access server that are set from an AAA server. Table 4 indicates some of the commands to use for each attribute.
|
|
|
---|---|---|
show ip access-list |
||
Configuration Examples for Per-User Configuration
The following sections provide two comprehensive examples:
These examples show router or access server configuration and AV pair configuration on an AAA server.
TACACS+ Freeware Examples
This section provides the TACACS+ freeware versions of the following examples:
IP Access Lists and Static Routes Using Virtual Profiles over ISDN BRI
The following example provides configurations for the TACACS+ freeware daemon, the network access server, and the peer router named Router1. On the TACACS+ AAA server, peer router Router1 has a configuration that includes static routes and IP access lists.
TACACS+ Freeware Daemon Configuration File
Current Network Access Server Configuration
Current Peer Configuration for Router1
IPX Per-User SAP Filters Using IPXWAN and Virtual Profiles by a Synchronous Interface
The following example provides configurations for the TACACS+ daemon and the peer router named Router1. On the TACACS+ AAA server, user ny has a configuration that includes inbound and outbound SAP filters.
TACACS+ Freeware Daemon Configuration File for User
Router1
{
Current Remote Peer (Router1) Configuration
Router1
Router1
172.21.114.131
Router1
Router1
password 7 044C0E0A0C2E414B
RADIUS Examples
This section provides the RADIUS versions of the following examples:
IP Access Lists and Static Routes Using Virtual Profiles over ISDN BRI
The following example shows a remote peer (Router1) configured to dial in to a BRI on a Cisco network access server (Router2), which requests user configuration information from an AAA server (radiusd):
Current Network Access Server Configuration
Current Peer Configuration for Router1
Output of ping Command from Router1
Network Access Server (Router2) show and debug Command Output
IPX Per-User SAP Filters Using IPXWAN and Virtual Profiles by a Synchronous Interface
The following examples show a remote peer (Router1) configured to dial in to a synchronous interface on a Cisco network access server (Router2), which requests user configuration information from an AAA server (radiusd):
Current Remote Peer (Router 1) Configuration
Network Access Server show Command Output

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: www.cisco.com/go/trademarks. 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)
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.
© 2001-2009 Cisco Systems, Inc. All rights reserved.