|
|
This document contains important information about the Cisco Access Registrar 1.6 software. Cisco Access Registrar is a RADIUS (Remote Authentication Dial-In User Service) server that allows multiple dial-in Network Access Server (NAS) devices to share a common authentication, authorization, and accounting database.
This document is divided into the following sections:
The following documents are available on the Cisco Documentation CD-ROM and are companion documents to this document:
This section describes the system requirements for installing the 1.6 Cisco Access Registrar software.
Table 1 lists the system requirements for a full installation of Cisco Access Registrar.
| Component | Requirement |
|---|---|
CPU Architecture | SPARC |
OS Version | Solaris 2.6, 2.7, 2.8 |
Minimum RAM | 64 MB |
Recommended RAM | 128 MB |
Recommended Disk Space | 80 MB |
Table 2 lists the system requirements for installing the server-only component of Cisco Access Registrar.
| Component | Requirement |
|---|---|
CPU Architecture | SPARC |
OS Version | Solaris 2.6, 2.7, 2.8 |
Minimum RAM | 64 MB |
Recommended RAM | 128 MB |
Recommended Disk Space | 60 MB |
Table 3 lists the system requirements for installing the configuration-only component of Cisco Access Registrar.
| Component | Requirement |
|---|---|
CPU Architecture | SPARC |
OS Version | Solaris 2.6, 2.7, 2.8 |
Minimum RAM | 32 MB |
Recommended RAM | 64 MB |
Recommended Disk Space | 25 MB |
The recommended disk space does not include the amount of space needed for accounting records which can grow rapidly depending on how frequently you process and remove them from the Cisco Access Registrar disk. If Cisco Access Registrar runs out of disk space, it could cause the loss of accounting information and session management information to become corrupted.
If you are upgrading from a previous Cisco Access Registrar 1.2, 1.3, or 1.5 release, you might want to retain data from your existing database. To do so, you must back up your database, then reimport it after installing Cisco Access Registrar 1.6 software.
To back up your database, login as user root and complete the following steps:
where <filename> is the name of the target file to export the database.
 |
Note The command above assumes that you installed Cisco Access Registrar in its default location (/opt/AICar1). |
Step 2 Remove the existing Cisco Access Registrar software package by entering the following:
Step 3 Install the Cisco Access Registrar 1.6 product. Installing Cisco Access Registrar 1.6 Software provides complete instructions.
|
Note At a minimum, you must install the 1.6 default database. You have the option of installing the 1.6 sample configuration. |
Step 4 Import the Cisco Access Registrar 1.2, 1.3, or 1.5 database file using the overwrite option in the mcdadmin command:
where <filename> is the name of the file copied in Step 1. This command overwrites the Cisco Access Registrar 1.6 default database.
This section provides information to help you prepare to install Cisco Access Registrar 1.6 software.
If you downloaded the Cisco Access Registrar 1.6 software from the Cisco web site, the software package is contained within a compressed tarfile named ar-1.6r0.tar.gz.
|
Note You might also need to download the file gunzip (from the same location as the software package) and use the chmod command to make gunzip executable, as in chmod 555 gunzip. |
Complete the following steps to prepare for software installation.
Step 2 Become root user by entering su and the root password.
Step 3 Change directory to the location where you have stored the uncompressed tarfile.
Step 4 Use gunzip to uncompress the tarfile.
Step 5 Use tar to extract the installation package files.
Before you begin to install the software, check your workstation's group file and make sure that group staff exists. Software installation will fail if group staff does not exist before installing the software.
If you have obtained the product CD, please proceed to Installing Software from Product CD. To begin installing downloaded software, complete the following steps:
Step 2 Enter the following command:
Step 3 Proceed to Common Installation Steps.
To begin installing software from the product CD, complete the following steps:
Step 2 Enter the following command:
Step 3 Proceed to Common Installation Steps.
The following steps are common for both types of Cisco Access Registrar software installation.
Step 2 Select the location where you want to install the package, or accept the default location of /opt/AICar1.
Step 3 If the directory does not exist, you are asked if you want it created. Choose Yes to continue the installation.
Step 4 You are prompted for the type of installation you want: Full (both the server and the configuration utility), Server-only, or Configuration-only. Select the default for a Full installation.
To select Server-only, enter Server. To select configuration-only, enter Config.
|
Note If you choose to install the server over a previous installation, the installation will prompt you with the following questions. |
a. If the installation detects a configuration database from a previous installation of Cisco Access Registrar, it asks you if you want to overwrite the database. If you want to start with a clean configuration and remove your session information answer Yes. If you want to keep your original configuration information, answer No.
b. If you answer No to overwriting the database, the installation asks you if you want to overwrite the session information. If you want to start with an empty session information, answer Yes. If you want to keep your original information, answer No.
Step 5 The installation informs you "Reinitializing your old database will also remove old session information," then prompts you whether to initialize the database at /opt/AICar1/data/db. Reply Yes to continue.
Step 6 You are prompted whether to install the example configuration now. Reply Yes to continue.
|
Note You can delete the example configuration at any time by running the command /opt/AICar1/usrbin/aregcmd -f /opt/AICar1/examples/cli/delete-example-configuration.rc. |
Step 7 The installation informs you that files are being installed with setuid and/or setgid permissions and prompts you whether or not to install these files as setuid/setgid files. Reply Yes to continue.
Step 8 The installation informs you that it will install scripts that will run as the superuser (su). Reply Yes. If you reply No, the installation will abort.
Step 9 The installation copies all of the files and starts the AIC Server Agent which, in turn, starts the Cisco Access Registrar server (if you chose to install the server).
Step 10 The installation displays a message informing you it completed successfully.
Step 11 The installation returns to the opening prompt. Choose q to quit the pkgadd program.
The installation process populates the AICar1 directory with the subdirectories listed in Table 4.
| Subdirectory | Description |
|---|---|
bin | Contains the program executables. |
usrbin | Contains user commands. |
data | Contains the radius directory, which contains session backing files; and the db directory, which contains configuration database files. |
logs | Contains system logs and is the default directory for RADIUS accounting. |
scripts | Contains sample scripts that you can modify to automate configuration, and to customize your RADIUS server. |
examples | Contains documentation, sample configuration scripts, and shared library scripts. |
Use the aregcmd command and specify a license key.
|
Note You have three tries to log in successfully before Cisco Access Registrar logs you out. |
> /opt/AICar1/usrbin/aregcmd
Type your cluster administrator name and password. The installation default is admin for the administrator and aicuser for the password.
Step 2 If you see the message that you have an invalid license key, you must enter a valid key.
Step 3 Cisco Access Registrar displays the license key at the cluster level and displays the number of days left on the license. For example:
[ //RadiusServer ] LicenseKey = WXYZ-WXYZ-WXYZ-WXYZ (expires in 30 days) Radius/ Administrators/
If your license key has expired, and you have received a new license key from Cisco, you can enter the new key by using the set command.
> /opt/AICar1/usrbin/aregcmd
Step 2 Type your cluster administrator name and password. The installation default is admin for the administrator and aicuser for the password.
Step 3 Use the set command and specify the new license key. Note, the license key is not case sensitive.
--> set LicenseKey <ABCD>-<ABCD>-<ABCD>-<ABCD>
After you have installed Cisco Access Registrar, which the AIC Server Agent starts automatically. You can verify that the server is running correctly with the arstatus command. Successfully running this command ensures that you can communicate with the database, communicate with the RADIUS server, and determine whether the server is running or stopped. You can run the aregcmd to log in to the server. You can also run the radclient command to create and send a simple Access-Request.
> /opt/AICar1/usrbin/arstatusRADIUS server running (pid: 649)
MCD server running (pid: 648)
Server Agent running (pid: 647)
MCD Lock Manager running (pid: 651)
Step 2 If the servers are not running, do the following:
a. Become superuser (su).
b. Change to the /etc/init.d directory.
c. Type the arservagt command with the start argument:
> ./arservagt startStarting AIC Server Agent for Access Registrar
> /opt/AICar1/usrbin/aregcmd
Step 2 Cisco Access Registrar prompts you for the cluster. Type the cluster name or press Enter for localhost.
Step 3 Cisco Access Registrar prompts you for the admin login and password. Use admin for the admin name, and aicuser for the password.
Step 4 Cisco Access Registrar prompts you to enter a valid license key. Enter the license key that is located on the back of the Cisco Access Registrar CD case.
For more information about the license key, see the "Using Cisco Access Registrar's License" section.
> /opt/AICar1/usrbin/radclient
Step 2 Enter the cluster name.
Step 3 Enter the administrator's username and password (as defined in Cisco Access Registrar's configuration). Use admin for the admin name, and aicuser for the password.
Step 4 Create a simple Access-Request packet for User-Name bob and User-Password bob. At the prompt, type:
The radclient command displays the ID of the packet p001.
Step 5 Send the request to the default host (localhost), type:
--> p001 sendp002
--> p002Packet: code = Access-Accept, id = 1, length = 62,
attributes =
Service-Type = Framed
Framed-Protocol = PPP
Framed-Routing = None
Framed-MTU = 1500
Framed-Compression = VJ TCP/IP header compression
Ascend-Idle-Limit = 1800
-->
The radclient command displays the response, an Access-Accept, when the server is running properly.
The Cisco Access Registrar 1.6 release includes the following new features:
1. "Cross Server Session and Resource Management" section
2. "Service Grouping Feature" section
3. "Tcl/Tk 8.3 Update" section
4. "Logging Syslog Messages" section
5. "Dynamic Attributes" section
6. "Proxy Accounting Enhancement" section
New features and other improvements to the server replication feature will be part of the Cisco Access Registrar 1.6R1 maintenance release scheduled for mid-September.
Prior to AR 1.6, sessions and resources were managed locally, meaning that in a multi-AR server environment, resources such as IP addresses, user-based session limits, and group-based session limits were divided between all the AR servers. It also meant that, to ensure accurate session tracking, all packets relating to one user session were required to go to the same AR server.
Access Registrar 1.6 can manage sessions and resources across AAA server boundaries. A session can be created by an Access-Request sent to AR1, and it can be managed by an Accounting-Stop request sent to AR2, as shown in Figure 1. This enables accurate tracking of User and Group session limits across AAA servers, and IP addresses allocated to sessions are managed in one place.
All resources that must be shared cross multiple front line ARs are configured in the Central Resource AR. Resources that are not shared can still be configured at each front line AR as done prior to the AR 1.6 release.
When the front line AR receives the access-request, it does the regular AA processing. If the packet is not rejected and a Central Resource AR is also configured, the front line AR will proxy the packet1 to the configured Central Resource AR. If the Central Resource AR returns the requested resources, the process continues to the local session management (if local session manager is configured) for allocating any local resources. If the Central Resource AR cannot allocate the requested resource, the packet is rejected.
When the Accounting-Stop packet arrives at the frontline AR, AR does the regular accounting processing. Then, if the front line AR is configured to use Central Resource AR, a proxy packet will be sent to Central Resource AR for it to release all the allocated resources for this session. After that, any locally allocated resources are released by the local session manager.
A new Service step has been added in the processing of Access-Request and Accounting packets. This is an additional step after the AA processing for Access packet or Accounting processing for Accounting packet, but before the local session management processing. The Session-Service should have a service type of radius-session.
An environmental variable Session-Service is introduced to determine the Session-Service dynamically. You can use a script or the rule engine to set the Session-Service environmental variable.
To use a Central Resource server, the DefaultSessionService property must be set or the Session-Service environmental variable must be set through a script or the rule engine. The value in the Session-Service variable overrides the DefaultSessionService.
The configuration parameters for a radius-session service are the same as those for configuring a radius service for proxy, except the service type is radius-session.
The Remote Server configuration for resource server central-server is the same as configuring a proxy server.
[ //localhost/Radius ]Name = RadiusDescription = Version = 1.6R0IncomingScript = OutgoingScript = DefaultAuthenticationService = local-usersDefaultAuthorizationService = local-usersDefaultAccountingService = local-fileDefaultSessionService = Remote-Session-ServiceDefaultSessionManager = session-mgr-1[ //localhost/Radius/Services ]Remote-Session-Service/ Name = Remote-Session-Service Description = Type = radius-session IncomingScript = OutgoingScript = OutagePolicy = RejectAll OutageScript = MultipleServersPolicy = Failover RemoteServers/ 1. central-server[ //localhost/Radius/RemoteServers ]central-server/ Name = central-server Description = Protocol = RADIUS IPAddress = 209.165.200.224 Port = 1645 ReactivateTimerInterval = 300000 SharedSecret = secret Vendor = IncomingScript = OutgoingScript = MaxTries = 3 InitialTimeout = 2000 AccountingPort = 1646Resources at the Central Resource server are configured the same way as local resources are configured. These resources are local resources from the Central Resource server's point of view.
Service Grouping is a new Cisco Access Registrar 1.6 feature that enables you to specify multiple services (called subservices) to be used with authentication, authorization, or accounting requests. The general purpose is to enable multiple Remote Servers to process requests.
Perhaps the most common usage of this new feature will be to send accounting requests to multiple Remote Servers thus creating multiple accounting logs.
Another common usage may be to authenticate from more than one Remote Server where, perhaps the first attempt is rejected, other Remote Servers may be attempted and an Access-Accept obtained.
Clearly, in the accounting request example, each request must be successfully processed by each subservice in order for the originator of the accounting request to receive a response. This is known as a logical AND of each of the subservice results. In the authenticate example, the first subservice which responds with an accept is returned to the client or if all subservices respond with reject, then a reject is returned to the client. This is known as a logical OR of each of the subservice results.
A Service is specified as a Group Service by setting its type to group, specifying the ResultRule (AND or OR) and specifying one or more subservices in the GroupServices subdirectory. The subservices are called in numbered order and as such are in an indexed list similar to Remote Server specification in a radius Service. Incoming and outgoing scripts for the Group Service may be optionally specified.
A subservice is any configured non-Group Service. When a Group Service is used, each subservice is called in exactly the same manner as when used alone (such as if specified as the DefaultAuthenticationService). Incoming and Outgoing scripts are executed if configured and Outage Policies are honored.
The following example shows how to configure an accounting Group Service to deliver accounting requests to multiple Remote Servers.
1. The first task is to setup the subservices which are to be part of the AccountingGroupService. Since subservices are merely configured Services which have been included in a service group, you need only define two new Services. For this example, we will define two new radius Services called OurAccountingService and TheirAccountingService. A provider might want to maintain duplicate accounting logs in parallel with their bulk customer's accounting logs.
[ //localhost/Radius/Services ] Entries 1 to 2 from 2 total entries Current filter: <all> local-file/ local-users/
2. The configuration of these Services is very similar to stand-alone Radius accounting service. Step-by-step configuration instructions are not provided, but the complete configuration is shown below:
[ //localhost/Radius/Services/OurAccountingService ] Name = OurAccountingService Description = Type = radius IncomingScript = OurAccountingInScript OutgoingScript = OurAccountingOutScript OutagePolicy = RejectAll OutageScript = MultipleServersPolicy = Failover RemoteServers/ 1. OurPrimaryServer 2. OurSecondaryServer[ //localhost/Radius/Services/TheirAccountingService ] Name = TheirAccountingService Description = Type = radius IncomingScript =TheirAccountingInScript OutgoingScript =TheirAccountingOutScript OutagePolicy = RejectAll OutageScript = MultipleServersPolicy = Failover RemoteServers/ 1. TheirPrimaryServer 2. TheirSecondaryServer3. The next step is to create the new AccountingGroupService. The purpose of this Service is to process Accounting requests through both OurAccountingService and TheirAccountingService.
Added AccountingGroupService[ //localhost/Radius/Services/AccountingGroupService ] Name = AccountingGroupService Description = Type = IncomingScript = OutgoingScript =Set Type group4. Set the ResultRule to AND to ensure that both services process the accounting request successfully.
Set ResultRule AND[ //localhost/Radius/Services/AccountingGroupService ] Name = AccountingGroupService Description = Type = group IncomingScript = OutgoingScript = ResultRule = AND GroupServices/5. Now we must add the Services we created "OurAccountingService" and "TheirAccountingService" as subservices of the Group Service.
[ //localhost/Radius/Services/AccountingGroupService/GroupServices ]Set 1 OurAccountingServiceSet 2 TheirAccountingService[ //localhost/Radius/Services/AccountingGroupService ] Name = AccountingGroupService Description = Type = group IncomingScript = AcctGroupSvcInScript OutgoingScript = AcctGroupSvcOutScript ResultRule = AND GroupServices/ 1. OurAccountingService 2. TheirAccountingService6. This completes the setup of the AccountingGroupService. To use this Service simply set it as the DefaultAccountingService and/or configure a policy/rule set which will select this Service. Essentially, this may be used in the same manner as any other stand-alone service.
The following describes the flow of what happens when a client sends an accounting request which is processed by the AccountingGroupService:
1. ActGroupSvcInScript is executed.
2. OurAccountingService is called.
3. OurAccountingService's Incoming Script, OurAccountingInScript is called.
4. The request is sent to the Remote Server OurPrimaryServer and/or OurSecondaryServer, if necessary.
5. If a response is not received, because we used the AND ResultRule, the request failed and no response is sent to the client and the request is dropped. If a response is received, then the process continues.
6. OurAccountingService's Outgoing Script, OurAccountingOutScript is called.
7. TheirAccountingService is called
8. TheirAccountingService's Incoming Script, TheirAccountingInScript is called.
9. The request is sent to the Remote Server TheirPrimaryServer and/or TheirSecondaryServer, if necessary.
10. If a response is not received, because we used the AND ResultRule, the request failed and no response is sent to the client and the request is dropped. If a response is received, then the process continues.
11. TheirAccountingService's Outgoing Script, TheirAccountingOutScript is called.
12. ActGroupSvcOutScript is executed.
13. Standard processing continues.
In this example, we will configure a Group Service for the purposes of providing alternate Remote Servers for a single authentication. Simply put, if Service "A" rejects the request, try Service "B".
1. The first task is to setup the subservices which are to be part of the AuthenticationGroupService. Since subservices are merely configured Services which have been included in a service group, we will simply define two new Services. For simplicity, we will define two new radius Services called "AuthenticationServiceA" and "AuthenticationServiceB".
[ //localhost/Radius/Services ] Entries 1 to 2 from 2 total entries Current filter: <all> local-file/ local-users/2. The configuration of these Services is very similar to stand-alone Radius authentication service. Step-by-step configuration instructions are not provided, but the complete configuration is shown below:
[ //localhost/Radius/Services/AuthenticationServiceA ] Name = AuthentictionServiceA Description = Type = radius IncomingScript = AuthAInScript OutgoingScript = AuthAOutScript OutagePolicy = RejectAll OutageScript = AuthAOutageScript MultipleServersPolicy = Failover RemoteServers/ 1. PrimaryServerA 2. SecondaryServerA[ //localhost/Radius/Services/AuthenticationServiceB ] Name = AuthentictionServiceB Description = Type = radius IncomingScript = AuthBInScript OutgoingScript = AuthBOutScript OutagePolicy = RejectAll OutageScript = AuthBOutageScript MultipleServersPolicy = Failover RemoteServers/ 1. PrimaryServerB 2. SecondaryServerB3. The next step is to create the new "AuthenticationGroupService". The purpose of this Service is to process authentication requests through both AuthenticationServiceA and AuthenticationServiceB if AuthenticationServiceA rejects the request.
Added AuthenticationGroupService[ //localhost/Radius/Services/AuthenticationGroupService ] Name = AuthenticationGroupService Description = Type = IncomingScript = OutgoingScript =Set Type group4. Next set the ResultRule to OR because we want to ensure that if the first subservice rejects the request, we then try the second subservice. If the second subservice rejects the request, then the response to the client is a reject.
Set ResultRule ORSet OutgoingScript AuthGroupSvcOutScriptSet OutgoingScript AuthGroupSvcOutScript[ //localhost/Radius/Services/AuthenticationGroupService ] Name = AuthenticationGroupService Description = Type = group IncomingScript = OutgoingScript = ResultRule = AND GroupServices/5. Now we must add the services we created "AuthenticationServiceA" and "AuthenticationServiceB" as subservices of the Group Service.
[ //localhost/Radius/Services/AuthenticationGroupService/GroupServices ]Set 1 AuthenticationServiceASet 2 AuthenticationServiceB[ //localhost/Radius/Services/AuthenticationGroupService ] Name = AuthenticationGroupService Description = Type = group IncomingScript = AuthGroupSvcInScript OutgoingScript = AuthGroupSvcOutScript ResultRule = OR GroupServices/ 1. AuthenticationServiceA 2. AuthenticationServiceB6. This completes the setup of the AuthenticationGroupService. To use this Service simply set it as the DefaultAuthenticationService and/or configure a policy/rule set which will select this Service. Essentially, this may be used in the same manner as any other stand-alone Service.
The following describes the flow of what happens when a client sends an Authentication request which is processed by the AuthenticationGroupService:
1. AuthGroupSvcInScript is executed.
2. AuthenticationServiceA is called.
3. AuthenticationServiceA's Incoming Script, AuthAInScript is called.
4. If the response is a reject or the request is dropped (due to an Outage Policy):
a. AuthenticationServiceA's Outgoing Script, AuthAOutScript is called
b. Processing continues with the next service
5. If the response is an Accept:
a. AuthenticationServiceA's Outgoing Script, AuthAOutScript is called
b. Skip to step 9
6. AuthenticationServiceB is called.
7. AuthenticationServiceB's Incoming Script, AuthBInScript is called.
8. Since this is the last subservice in our Group Service:
a. AuthenticationServiceB's Outgoing Script, AuthBOutScript is called
b. Regardless of whether the request is Accepted or Rejected, processing will continue at step 9
9. AuthGroupSvcOutScript is executed.
10. Standard processing continues.
The Cisco Access Registrar 1.6 has been updated to Tcl/Tk8.3 from Tcl/Tk7.6. Since the Tcl/Tk8.3 supports a multi-threading application environment, it can achieve much better performance than Tcl/Tk7.6.
|
Note In this EFT release, scripts that use Tcl global variables will not work across AR extension points. A future release will address script compatibility issues. |
Tcl/Tk8.3 also performs byte-compile, so no run-time interpretation is required.
Logging messages via syslog provides centralized error reporting for Cisco Access Registrar 1.6. Local logging and syslog logging can be turned on or off at any time by modifying the control flags in the $INSTALLPATH/conf/aic.conf file.
Logging syslog messages requires a UNIX host running a syslog daemon as a receiver for Cisco Access Registrar messages. Cisco Access Registrar and the syslog daemon can be running on the same host or different hosts.
Messages that are sent to the following logs will be forwarded to syslog server in a slightly different format. The logs are:
The messages are in the following format:
MMM DD hh:mm:ss hostname %CAR-[severity]-[mnemonic]: [#n], [System|Server]: message_description
Where:
May 19 14:28:44 dwlau-ultra2.cisco.com
%CAR-3-name_radius: #1, System: Remote LDAP Server.Unable to bind.
May 19 14:28:45 dwlau-ultra2.cisco.com
%CAR-6-name_radius: #1, Server: Stopping server
In $INSTALLPATH/conf/aic.conf file, the following four lines are required.
LOCAL_LOGGING [ON|OFF]SYSLOG_LOGGING [ON|OFF]SERVER_IP_ADDRESS [ip_address]FACILITY_LOCAL_NUMBER [0..7]Where:
The following is an example
LOCAL_LOGGING OFFSYSLOG_LOGGING ONSERVER_IP_ADDRESS 209.165.200.224FACILITY_LOCAL_NUMBER 7You must specify the facility from which syslogd will receive messages and the file into which the messages will be deposited.
In the syslog server's /etc/syslog.conf file, the following line may be needed.
localn.info <tab> <tab> <tab> /var/log/filename.log |
Note Use at least one <tab> as a field separator. |
Where:
To create a syslog log file, complete the following steps:
Step 2 Enter the following command, where filename.log is a name you choose.
Step 3 Change permissions on the syslog log file by entering the following:
To restart the syslog daemon, log in as user root and enter the following commands:
Left unmanaged, the syslog file will grow in size over time and eventually fill all available disk space in its partition. Cisco recommends that you use the cron program to manage the syslog files.
The following example crontab file performs a weekly archival of the existing syslog file (named ar_syslog.log in this example). This scheme keeps the previous two week's worth of syslog files.
## At 02:01am on Sundays:# Move a weeks worth of 'ar_syslog.log' log messages to 'ar_syslog.log.1'.# If there was a 'ar_syslog.log.1' move it to 'ar_syslog.log.2'.# If there was a 'ar_syslog.log.2' then it is lost.01 02 * * 0 cd /var/log; if [ -f ar_syslog.log ]; then if [ -f ar_syslog.log.1 ]; then /bin/mv ar_syslog.log.1 ar_syslog.log.2;fi; /usr/bin/cp ar_syslog.log ar_syslog.log.1; >ar_syslog.log; fi |
Note Consider using move (mv) or copy (cp) commands to store the previous week's syslog files in a different disk partition to reserve space for the current syslog file. |
To add this crontab segment to the existing cron facility in /usr/spool/cron/crontabs directory, complete the following steps at the syslog server console.
Step 2 Enter the following commands:
The command line crontab -l > ar_cron lists the current root's crontab entries, redirects the output to a file (ar_cron), and allows the entries to be captured and edited.
The command line crontab ar_cron adds the new schedule to the existing cron facility.
Cisco Access Registrar 1.6 supports dynamic values for the configuration object properties listed below. Previous releases of Cisco Access Registrar only handles static values for all the object properties.
Dynamic attributes are similar to UNIX shell variables. With dynamic attributes, the value is evaluated at run time. All of the objects that support dynamic attributes will have validation turned off at aregcmd.
The following object properties support dynamic values:
Radius
|
Note Do not use the following environmental variables: Accounting-Service for the /radius/defaultAccountingService, Authentication-Service for the /radius/defaultAuthenticationService, or Authorization-Service for the /radius/defaultAuthorizationService. |
/Radius/Clients
/Radius/Userlist/Default
/Radius/UserGroup
/Radius/Vendor
/Radius/Service
|
Note To differentiate the properties that support dynamic attributes, we place a tilde (~) after each property, as in IncomingScript~. However, when the AR administrator is required to set values for those properties, continue to use the original property name, such as set IncomingScript ${e|realm}{Test}. The tilde is only for visual effect, and including the tilde will generate an error ("310 command Failed.") |
/Radius/RemoteServers
The format of the dynamic attribute is:
where e stands for environment dictionary, q stands for request dictionary and p stands for response dictionary. You can use e, q and p in any order. The attribute name is the name for the attribute from environment dictionary, request dictionary, or response dictionary.
For example,
/Radius
DefaultAuthenticationService = ${eq|realm}{local-users}
The default Authentication Service is determined at run time. Cisco Access Registrar first checks to see if there is one value of realm in the environment dictionary. If there is, it becomes the value of DefaultAuthenticationService. If there is not, check the value of realm in the request dictionary. If there is one value, it becomes the value of DefaultAuthenticationService. Otherwise, local-users is the DefaultAuthenticationService. If we don't set local-users as the default value, the DefaultAuthenticationSerice is null. The same concept applies to all other attribute properties.
The validation for the dynamic values of the object property will only validate the default value. In the above example, Cisco Access Registrar will do validation to check whether local-users is one of services defined in the service subdirectory.
|
Note When setting specific property values, do not use the tilde (~) in the property name. Doing so generates a 310 Command Failed error. |
This feature adds an option to Remote Servers to for handle accounting proxy servers that do not follow RADIUS standards as defined in RFC2139. This feature allows Cisco Access Registrar to disregard accounting acknowledgement and to continue the packet processing rather than waiting for the accounting acknowledgement from the proxy server.
The following is a sample configuration:
/Radius/RemoteServer/Server1 Name = Server1 Description = Protocol = radius IPaddress = 209.165.200.225 Port = 1645 ReactiveTimerInterval = 300000 Sharedsecret = abc Vendor = IncomingScript = OutgoingScript = MaxTries = 3 InitialTimeout = 2000 AccountingPort = 1646 ACKAccounting = TRUEACKAccounting is set to TRUE by default.
If the you plan to use CHAP authentication with an LDAP backing store, the password in LDAP must be stored as clear text. This is due to the one-way hash used by the CHAP and crypt encryption algorithms.
This feature allows you to use special characters in LDAP usernames. The allowable special characters are *, (,), and \. These special characters can be included in the string passed to LDAP as the LDAP username attribute (usually the RADIUS username attribute).
The default of EscapeSpecialCharInUserNameName is FALSE. To enable this feature, use aregcmd to set the EscapeSpecialCharInUserName attribute in /Radius/RemoteServers/ldap-server to TRUE, as shown in the following example.
--> cd /Radius/RemoteServers/ldap-server
--> set EscapeSpecialCharInUserName TRUE
/Radius/RemoteServers/Ldap-Server
EscapeSpecialCharinUserName = TRUE |
Note This feature supports the LDAP V3 library. |
This section provides information about support for the Ascend binary attribute.
Cisco Access Registrar 1.6 supports Ascend-Data-Filter (Ascend attribute 242) with IP filter and generic filter type. Please refer to Ascend document for details of the data syntax. The value for Ascend-Data-Filter is in binary format. This creates some inconvenience for administrators to configuring values for this attribute.
Cisco Access Registrar 1.6 introduces an implementation-specific attribute 225 (Text-Ascend-Data-Filter). This attribute enables you to define the equivalent Ascend-Data-Filter in text format. AR converts the values of this attribute into binary format and saves them into Ascend-Data-Filter attributes. AR maintains the same order for the multiple values in Text-Ascend-Data-Filter and Ascend-Data-Filter.
The conversion occurs before any Access-Accept packet leaves AR. So the scripts inside AR only deal with Text-Ascend-Data-Filter in place of Ascend-Data-Filter during the whole process. After conversion, the Text-Ascend-Data-Filter is removed, and Ascend-Data-Filter is passed on.
For packets with Ascend-Data-Filter attributes that pass through AR, such as in proxy mode, the original Ascend-Data-Filter is untouched. If any Text-Ascend-Data-Filter attributes are added while processing packets inside AR, they are converted to Ascend-Data-Filter and appended to the original Ascend-Data-Filters right before the packet leaves the server.
Assume you want to add the following filters to a profile and pass the profile as part of the Access-Accept to the client.
Ascend-Data-Filter = ip out forward tcp dstip 10.1.1.3/16Ascend-Data-Filter = ip out dropAscend-Data-Filter = generic in drop 0 ffff 0080Ascend-Data-Filter = generic in drop 0 ffff != 0080 moreAscend-Data-Filter = generic in drop 16 ff aa |
Note Refer to Ascend reference for the filter syntax. |
To configure on local profile:
[ //localhost/Radius/Profiles/default-PPP-users/Attributes ] Ascend-Idle-Limit = 1800 Framed-Compression = "VJ TCP/IP header compression" Framed-MTU = 1500 Framed-Protocol = PPP Framed-Routing = None Service-Type = Framed Text-Ascend-Data-Filter = "ip out forward tcp dstip 10.1.1.3/16" Text-Ascend-Data-Filter = "ip out drop" Text-Ascend-Data-Filter = "generic in drop 0 ffff 0080" Text-Ascend-Data-Filter = "generic in drop 0 ffff != 0080 more" Text-Ascend-Data-Filter = "generic in drop 16 ff aa"To configure for LDAP profile
[ //localhost/Radius/RemoteServers/test/LDAPToRadiusMappings ]
ldap-attribute-that-contains-ascend-data-filter-in-text = Text-Ascend-Data-Filter
06/17/2000 18:12:35: P29: Trace of Access-Accept packet
06/17/2000 18:12:35: P29: identifier = 1
06/17/2000 18:12:35: P29: length = 60
06/17/2000 18:12:35: P29: reqauth = 4f:93:b4:1c:0d:21:cd:4a:88:4d:e0:00:c6:12:dc:3d
06/17/2000 18:12:35: P29: Service-Type = Framed
06/17/2000 18:12:35: P29: Framed-Protocol = PPP
06/17/2000 18:12:35: P29: Framed-IP-Address = 192.168.0.0
06/17/2000 18:12:35: P29: Framed-IP-Netmask = 255.255.255.0
06/17/2000 18:12:35: P29: Framed-Routing = None
06/17/2000 18:12:35: P29: Framed-MTU = 1500
06/17/2000 18:12:35: P29: Framed-Compression = VJ TCP/IP header compression
06/17/2000 18:12:35: P29: Ascend-Idle-Limit = 1800
06/17/2000 18:12:35: P29: Text-Ascend-Data-Filter = ip out forward tcp dstip 10.1.1.3/16
06/17/2000 18:12:35: P29: Text-Ascend-Data-Filter = ip out drop
06/17/2000 18:12:35: P29: Text-Ascend-Data-Filter = generic in drop 0 ffff 0080
06/17/2000 18:12:35: P29: Text-Ascend-Data-Filter = generic in drop 0 ffff != 0080 more
06/17/2000 18:12:35: P29: Text-Ascend-Data-Filter = generic in drop 16 ffaa
06/17/2000 18:12:35: P29: Trace of Access-Accept packet
06/17/2000 18:12:35: P29: identifier = 1
06/17/2000 18:12:35: P29: length = 60
06/17/2000 18:12:35: P29: reqauth = 4f:93:b4:1c:0d:21:cd:4a:88:4d:e0:00:c6:12:dc:3d
06/17/2000 18:12:35: P29: Service-Type = Framed
06/17/2000 18:12:35: P29: Framed-Protocol = PPP
06/17/2000 18:12:35: P29: Framed-IP-Address = 192.168.0.0
06/17/2000 18:12:35: P29: Framed-IP-Netmask = 255.255.255.0
06/17/2000 18:12:35: P29: Framed-Routing = None
06/17/2000 18:12:35: P29: Framed-MTU = 1500
06/17/2000 18:12:35: P29: Framed-Compression = VJ TCP/IP header compression
06/17/2000 18:12:35: P29: Ascend-Idle-Limit = 1800
06/17/2000 18:12:35: P29: Ascend-Data-Filter = 01:01:00:00:00:00:00:00:0a:01:
01:03:00:10:06:00:00:00:00:00:00:00:00:00
06/17/2000 18:12:35: P29: Ascend-Data-Filter = 01:00:00:00:00:00:00:00:00:00:
00:00:00:00:00:00:00:00:00:00:00:00:00:00
06/17/2000 18:12:35: P29: Ascend-Data-Filter = 00:00:01:00:00:00:00:02:00:00:
ff:ff:00:00:00:00:00:80:00:00:00:00:00:00
06/17/2000 18:12:35: P29: Ascend-Data-Filter = 00:00:01:00:00:00:00:02:00:01:
ff:ff:00:00:00:00:00:80:00:00:00:00:01:00
06/17/2000 18:12:35: P29: Ascend-Data-Filter = 00:00:01:00:00:10:00:01:00:00:
ff:00:00:00:00:00:aa:00:00:00:00:00:00:00
This section provides information about bugs that have been fixed and known anomalies in Cisco Access Registrar 1.6.
This section describes bugs from previous releases that were fixed in Cisco Access Registrar, Release 1.6.
| Bug ID | Description |
|---|---|
CSCai03851 | Allow an option to not write error messages in syslog. |
CSCdp23831 | Loss of authentication when log partition full/not writable |
CSCdr18971 | Adding remote server on command line fails. |
CSCdr18977 | Reload ordering problem. |
CSCdr18984 | Erroneous log message about shared secrets. |
CSCdr18990 | Ghost remote server appears in statistics output. |
CSCdr37375 | AR core dumps while idle with SMDBR configured. |
CSCdr14189 | Problem with tunnel attributes with tag0*. The following configuration changes should fail validation. They do fail validation, but the RADIUS server stops. cd /Radius/Profile |
CSCdr84894 | Using add-example-configuration.rc script breaks Access Registrar. |
CSCdr92282 | Core dumps if remote server is down. |
CSCdp64341 | Validation does not fail after deleting referenced remote server. |
CSCdr57594 | New feature for syslog support. |
CSCdr61780 | libRexAcctScript.so cannot be loaded. |
CSCdr80592 | Core dumps occurs after server reload. |
CSCdr80607 | outagepolicy and outagescript cannot be updated. |
CSCdr81104 | Core dumps on startup. |
CSCdr81591 | Core dumps when access-request is sent. |
CSCdr84436 | LDAPToRadiusMappings is broken. |
CSCdr84901 | Setting DefaultSessionManager causes server core dump. ` |
CSCdr91376 | Accounting packet never responds (ACKAccounting does not work). |
CSCdr05617 | Tab attribute. |
CSCdr37396 | Using add-example-configuration.rc script freezes server. |
CSCdr73752 | Unexpected error about Ascend-Data-Filter. |
CSCdr74708 | Support dynamic attribute. |
CSCdr76177 | ACKAccount instead of NOAckAccount in remote server. |
CSCdr84898 | Set configuration with tilde (~) does not work. |
CSCdr87971 | Dictionary validation does not occur when setting defaultsessionmanager. |
CSCdr94530 | ParseTranslationGroupsByRealm removes User-Name's realm badly. |
CSCdp91695 | Misleading aregcmd error reported. |
CSCdp91733 | Example data sources do not match. |
CSCdr35229 | Exit status of aregcmd no longer on screen. |
CSCdr37382 | arbug still refers to aicstatus. |
CSCdr89214 | Cache the dynamic value in the attribute. |
CSCdr94180 | arbug should not user aregcmd -s option. |
CSCdr94187 | arbug assumes gzip is available. |
CSCdm17691 | Support is required for Ascend_Binary_Filter type in AIC Radius. |
CSCdp51509 | AR:Proxy to send acct-response to NAS regardless of ACKs. |
CSCdp51527 | AR:Session management takes place on front side, not in the background. |
CSCdr35655 | Version number requires revision. |
CSCdr76342 | Tcl8.3 upgrade. |
CSCdr77491 | Allow DefaultSessionService to user dynamic expansion. |
This section describes the known bugs in Cisco Access Registrar, Release 1.6.
| Bug ID | Description |
|---|---|
CSCdr97637 | Error messages occur during database import. |
CSCds10455 | CNSAR stops and will not restart. |
CSCai02016 | If Session Manager is deleted, IP address assignments are lost. |
CSCai02480 | Incorrect service type is not logged. |
CSCai02483 | Segmentation fault occurs when trying to create too many Session Managers. |
CSCai03159 | Query sessions and release sessions timeout with large number of Session Managers. Workaround: Keep number of Session Managers below 100 to use these commands. |
CSCai03174 | radclient asserts when you add the same attribute to two packets. |
CSCai03178 | Multiple query commands result in Radius server not responding. |
CSCai03229 | Out of Memory occurs when the range is set too high for IP-dynamic objects. To manage a large number of address, more memory is required. |
CSCai03278 | REX: Error in request - Out of Memory during Server reload. |
CSCai03354 | If a REX script passes in NULL for the key, the server dumps core. |
CSCai03674 | Calling a dictionary API function and providing a null value when a char string is expected might cause a core dump. This bug is similar to CSCai03278. |
CSCdm49977 | When the /tmp directory is full, aregcmd and radclient hang. |
CSCdp23831 | Loss of authentication when log partition is full or not writable. |
CSCdp91753 | Logging does not work for files equal to or greater than 2 GB. |
CSCdr18990 | A ghost remote server appears in statistics output. |
CSCdr37401 | Adding LDAP remote servers may freeze the AR server in batch mode. |
CSCdr39215 | Dynamic updates fail for LDAP remote server. |
CSCdr52588 | Unable to set enumerated VSA above 256. |
CSCdr56891 | Accounting packet is not processed by the rule engine. |
CSCdr80266 | When group staff does not exist, aregcmd does not fail, although it should. |
CSCai02696 | arservagt does not clean up defunct processes. |
CSCai03864 | Erroneous bad password log in Agent Server from aregcmd. |
CSCdk82488 | Adding a VSA with the same name as a standard attribute will not work. |
CSCdm92870 | Validation does not fail for an empty UserList in a service. |
CSCdp21838 | Results from the command ls -R are inconsistent for certain objects. |
CSCdr74809 | Maximum attribute length is not checked. |
This section provides information about the Cisco Access Registrar 1.5 R1 release and describes the new features, bug fixes, and open bugs in Access Registrar (AR) Release 1.5R1 (as they have changed from Release 1.5R0). For more comprehensive information about the AR 1.5x releases, please see the release notes and other documentation for Release 1.5R0, available from CCO (http://www.cisco.com/go/ar) or the product CD-ROM.
This section provides information about the new features in the Cisco Access Registrar 1.5 R1 release.
A new environment variable, Dynamic-Search-Path (see rex.h), can be used to set the dynamic LDAP search base. If this environment variable is defined for an LDAP service, it will override the default LDAP search base defined in the LDAP Remote Server configuration. This allows the LDAP search base to be configured on a per-user basis.
For example, you could match the search base to the organization and domain (in a Tcl script called from /Radius/IncomingScript):
set user [ $request get User-Name ]if { [ regexp {^[^@]+@([^\.]+)\.(.+)$} $user m org domain ] } {$environ put Dynamic-Search-Path "ou=$org,ou=people,o=$domain"}Two new environment variables, Group-Session-Limit and Current-Group-Count (see rex.h), are set if the group session limit resource is allocated for a packet. These variables allow a script to see how close the group is to its session limit; one way to use this information is to implement a script-based soft limit. For example, you could use the Class attribute to mark sessions that have exceeded a soft limit of 80% -- as hard coded in the script (in a Tcl script called from /Radius/OutgoingScript):
set softlimit [ expr 0.8 * [ $environ get Group-Session-Limit ] ]if { [ $environ get Current-Group-Count ] < $softlimit } {$response put Class 0} else {$response put Class 1} |
Note The soft limit itself is hard coded in the script; soft limits are not directly supported in the server. The action to be taken when the soft limit is exceeded (e.g. Class = 1, and then the accounting software branches on the value of Class) is also the responsibility of the script and/or external software. |
The ability to monitor when a NAS is down (really only unreachable from AR) is provided by nasmonitor. This program will repeatedly query a TCP port at the specified IP address until the device (NAS) is reachable. If the NAS is not reachable after a period of time, a warning E-mail is sent; if the NAS is still not reachable after another period of time, a message is sent to AR to release all sessions associated with that NAS. The port to query, the query frequency, the first time interval, the backoff time interval, and the E-mail address to send to are all configurable (with defaults); the only required parameter is the NAS IP address. This program will work for any device that has a TCP port open; it can either be run by hand, when desired, or put in a cron job. See nasmonitor -h for details.
|
Note You must have tclsh installed in /usr/local/bin to use nasmonitor. tclsh is part of the standard Tcl installation that can be downloaded from http://www.scriptics.com. |
The program arbug can be used to collect information about the AR server from a customer. There are several levels of detail that can be specified, from level 1 being the least to level 3 being the most. The results are collected into a tarball that can be E-mailed or ftped to Cisco as requested. See arbug -h for details.
Multiple people can view and interact in a single demonstration by using the screen program, a standard GNU release with a special configuration for use with AR. To run screen, a technical support specialist (CSE/DE) will telnet to your server and log in as cisco. While you run /opt/AICar1/usrbin/screen (assuming /opt/AICar1 is the AR path) as root, the CSE/DE runs /opt/AICar1/usrbin/screen -r root. Now both people (or more) can see what the other types, as well as the results of the commands entered. The special AR configuration only allows root and cisco to run screen.
Users in local userlists can now have multiple profiles.
This section provides information about known anomalies in Access Registrar 1.5 R1.
Table 7 lists and describes bugs that were fixed in the AR 1.5R1 release.
| Bug | Description |
|---|---|
CSCai03659 | Table of acceptable attributes for proxied Access-Accepts. |
CSCai03660 | Hot Backup with synchronized databases. |
CSCdm05821 | Wildcard characters can get passed on to LDAP. |
CSCdp91692 | aregcmd asks to save when no changes made. |
CSCdp91785 | Add trace logging for rules. |
CSCdp92780 | Upgrade configuration option needed. |
CSCdr05605 | Core generated after setting a rule without script or attribute. |
CSCdr05896 | aregcmd fails when run as regular user. |
CSCdr06186 | Multiple rules did not get executed. |
CSCdr09524 | SMDBR member cores. |
CSCdr13795 | Change mcdsvr process name to armcdsvr. |
CSCdr14054 | A policy cannot be referred to in a rule if it is not defined. |
CSCdr14061 | AR goes into infinite loop when two policies are invoked. |
CSCdr14092 | Multiple rules are executed in OR grouping. |
CSCdr14104 | Validation does not fail for policy grouping with keyword. |
CSCdr14133 | Keyword shown in the rule name, which is not valid. |
CSCdr14141 | No validation for attribute under rule. |
CSCdr14192 | No validation for tunnel attribute. |
CSCdr14883 | Client secret not dynamically updated. |
CSCdr16422 | AR fails to install when NR is already installed. |
CSCdr17144 | aregcmd always asks to save on exit. |
CSCdr18965 | Erroneous log message after changing Remote Server secret. |
CSCdr20299 | Default-test-user shows up in the example database. |
CSCdr23082 | aregcmd cores after save. |
CSCdr30146 | rexascend script cores when it has multivalued attributes. |
CSCdr30603 | VPI/VCI authentication doesn't accept CHAP-Password. |
CSCdr37382 | arbug still refers to aicstatus. |
CSCdr41571 | Script screen not removed upon pkgrm. |
Table 8 lists and describes bugs that are known to exist in the AR 1.5R1 release.
| Bug | [Severity] Description |
|---|---|
CSCai02209 | [3] Server asserted while recycling LDAP server. |
CSCai02340 | [3] ap_create_path passes the wrong arguments to ap_parse. |
CSCai02480 | [3] Incorrect service type not logged. |
CSCai02888 | [3] System libraries are using our RPC library with bad results. |
CSCdp64341 | [3] Validate does not fail after deleting Remote Server. |
CSCdr05185 | [3] No validation on the replication attributes. |
CSCdr05617 | [3] Tag attribute. |
CSCdr06627 | [3] Server stops after setting tunnel attribute ending in tag01. |
CSCdr14189 | [3] Tunnel attributes with tag0*. |
CSCdr14199 | [3] Setting tunnel attribute in some profiles cores. |
CSCdr14210 | [3] Core file when ldap server is doing A and is down. |
CSCdr14268 | [3] Multivalued profiles don't work. |
CSCdr18977 | [3] Reload ordering problem. |
CSCdr18990 | [3] Ghost Remote Server appears in statistics output. |
CSCdr37315 | [3] SMDBR core problem. |
CSCdr37375 | [3] AR cores while idle. |
CSCdr39215 | [3] LDAP Remote Server does not hot modify. |
CSCai03864 | [4] Erroneous bad password log in Agent Server from aregcmd. |
CSCdm92870 | [4] Validate does not fail for empty userlist in a service. |
CSCdp91695 | [4] Misleading aregcmd error. |
CSCdp91733 | [4] Example data sources do not match. |
CSCdr18971 | [4] Adding Remote Server on command line fails. |
CSCdr18984 | [4] Erroneous log message about shared secrets. |
CSCdr35111 | [4] Require SMDBR validation. |
CSCdr35229 | [4] Exit status of aregcmd no longer on screen. |
CSCai01291 | [5] Facility for querying a NAS. |
CSCai01990 | [5] Do we query active sessions before locking someone out? |
CSCai03323 | [5] Would be nice to be able to query mcd directly from scripts. |
CSCai03851 | [5] Allow an option to NOT write error messages to syslog. |
CSCai04069 | [5] Read-only access to database. |
CSCdm17691 | [5] Need support for Ascend-Binary-Filter type. |
CSCdp51509 | [5] ACK acct-req to NAS regardless of ACK from Remote Server. |
CSCdp51527 | [5] Session management take place on front side, not background. |
This section provides the information about the Cisco Access Registrar 1.5 release.
The following lists Cisco Access Registrar 1.5 release includes the following new features:
1. "Single Master Database Replication Feature" section.
2. "Tunneling Support Feature" section.
3. "xDSL VPI/VCI Support for Cisco 6400" section.
4. "Apply Profile in Cisco Access Registrar Database to Directory Users" section.
5. "Directory Multi-Value Attributes Support" section.
6. "MultiLink-PPP (ML-PPP)" section.
7. "Dynamic Updates Feature" section.
8. "Rule Engine and Service Enhancements" section.
9. "aregcmd Command Logging" section.
The Single Master Database Replication (SMDBR) feature provides administrators with the ability to maintain databases on several different RADIUS servers without having to actually put into effect the changes on each server individually. In an SMDBR network, a single Master Server (upon which database changes are made) and one or more Member Servers (upon which database changes are made only through the Replication mechanism and not through aregcmd) exist. The database of a Member Server is maintained automatically by the Master Server. Changes are replicated throughout the network by the Master Server when an aregcmd save command is issued. With a few exceptions, all database changes are replicated to all network members and dynamically updated in each server such that a server reload is not required.
The following is a list of the configuration elements that are not replicated:
Replicated changes include additions or modifications. Deletions are not replicated (see the "Known Bugs" section for details).
All replications are based upon transactions. Should a transaction's replication fail, a resynchronization mechanism exists which will automatically resynchronize the database of a Replication Member with that of the Master. During resynchronization, the out-of-sync Member is set to off-line status and all Access Requests received are dropped while off-line (these requests are dropped so as to allow the NAS to redirect them to an on-line Member for processing). Once resynchronized, the Member automatically returns to an on-line status and Access Requests are processed as usual.
While on-line, all Members and the Master of a replication network perform as fully functional RADIUS Servers, regardless of the replication tasks being performed.
Install in the same manner as other RADIUS servers, however, you must set the Replication configuration parameters before the server will start correctly. See the "Master Configuration" section for details on how to configure the server for replication.
After installation is complete, run aregcmd and log into the newly installed server. Type cd radius/replication to change to the radius/replication directory. The following describes the replication configuration setup on a by-setting basis.
1. RepType <SMDBR>
This setting accepts the following values:
a. SMDBR—specifies that this server is part of a Single Master replication network.
b. LDAP—for future implementation. Setting this value has the same effect as using the NONE value.
c. NONE—indicates this server is not part of a replication network.
2. RepTransactionSyncInterval = 60000
3. RepTransactionArchiveLimit = 100
100, a Member may not be off-line for longer than a day without requiring a Full-Resynchronization (accomplished manually in this release). See the "Known Bugs" section for a description of the automatic Full-Resynchronization process.4. RepIPAddress = <nnn.nnn.nnn.nnn>
5. RepPort = <nnn>
6. RepSecret = MySecret
7. RepIsMaster = TRUE
8. RepMasterIPAddress = <nnn.nnn.nnn.nnn>
9. RepMasterPort = <nnnn>
10. Type cd rep to change to the Replication Members directory.
11. Type Add <name>, where <name> is the name of the Replication Network Member you are adding.
12. Type cd <name>, where <name> is the new replication network Member you just added.
13. Specify the IP address for the newly added Member by setting the IP address value to that of the Member server.
14. Specify the network port for the newly added Member by setting the Port value to that of the Member server.
15. Type cd ..
16. Repeat Steps 11 through 15 for each Replication Network Member.
17. Type Save to save your Replication Network Master setup.
Now that you have completed the setup of the Replication Network Master, you must configure each Replication Network Member such that it has the IP address and port of the Master (used to validate received replication data) and the replication secret specified on the Master.
After installation on the Member server is complete, run aregcmd and login to the newly installed Member server. Type cd radius/replication to change to the radius/replication directory. The following describes the replication configuration setup on a by-setting basis.
1. RepType = <SMDBR>
a. SMDBR—specifies that this server is part of a Single Master replication network.
b. LDAP—for future implementation. Setting this value has the same effect as using the NONE value.
c. NONE—indicates this server is not part of a Replication Network.
2. RepTransactionSyncInterval = 60000
3. RepTransactionArchiveLimit = 100
4. RepIPAddress = <nnn.nnn.nnn.nnn>
5. RepPort = < nnn>
6. RepSecret = MySecret
7. RepIsMaster = FALSE
8. RepMasterIPAddress = <nnn.nnn.nnn.nnn>
9. RepMasterPort = <nnnn>
10. Type Save to save your Replication Network Member setup.
11. Repeat these steps on each server that is to be a Replication Network Member. Ensure that all Replication Network Members are defined in the Master, or they will be excluded from the Replication Network.
Start all the Replication Network Members and their Master. The order does not matter; however, if the RepTransactionSyncInterval on a Member expires prior to hearing from the Master, it will report in the server log that the Master may be off-line. Should this happen, and the master is in the process of starting, the member will eventually hear from the master and operation will continue as normal.
When a Replication Network Member starts-up, it is off-line until it can verify it is synchronized with the Master. If it is not synchronized, it will attempt a resynchronization, if it is possible, or the server will require manual resynchronization. When installing, you should ensure that if you are using an existing database, it is properly imported on each Member (from the Master) to ensure proper database synchronization from the start.
All configuration changes (except those which are not replicated) must be made to the Master server. While it is possible on a Replication Network Member to make changes to replicated configuration parameters, it is highly discouraged, as this practice will cause the database to be out-of-sync with the Master and other replication Members. This type of out-of-sync condition cannot be detected by the SMDBR network. Consequently, changes to the same configuration parameters made on the Master will overwrite any changes improperly made on the Member. aregcmd may be used to remotely login to the Master so that changes can always be made and replicated safely.
Changes to the non-replicated configuration parameters require a server reload for them to take effect. For example, if you wish to take a Member out of the Replication Network, set the RepType attribute to NONE, then reload the server. This will exclude the Member from the Replication Network. To put the server back into the Replication Network, set the RepType attribute to SMDBR, then reload it. When reinstating a Member, one of two things will occur:
1. If the Member missed less replication transactions than the RepTransactionArchiveLimit specification in the Master, an automatic resynchronization takes place and the Member will be on-line when it is resynchronized with the Master.
2. If the member missed more replication transactions than the RepTransactionArchiveLimit specification in the Master, a manual resynchronization must be done. To accomplish this, follow the steps under "No Full Synchronization" in the "Known Bugs" section below.
1. Deletions Are Not Replicated.
2. No Full Resynchronization.
a. Ensure there are no aregcmd sessions logged into the Master. On the Master, export the database with the following command:
b. Stop the replication Member server by invoking the arservagt stop command.
c. Copy the file exported from the Master server to the Member server.
d. Manually edit the file. Search for RepIsMaster, change its setting to FALSE, then save the file.
e. Import the file using the overwrite option in the mcdadmin command:
f. Start the replication Member by invoking the arservagt start command.
g. Run aregcmd and set up the replication parameters as specified above in the "Member Configuration" section.
h. Reload the server. The Member will start up and show on-line status in the log once it has verified it is synchronized with the Master.
Session Managers, Resource Managers, and Remote Servers may be added; however, any modifications are not dynamically updated in the server. This requires a reload. This is a preexisting artifact of the Dynamic Update implementation. It is important to note that while the Dynamic Update for these objects only supports additions, all additions and modifications are replicated to member's databases (they just are not dynamically updated in the member).
Tunneling support is strictly based upon the IETF draft: "RADIUS Attributes for Tunnel Protocol Support" (http://www.ietf.org/internet-drafts/draft-ietf-radius-tunnel-auth-09.txt).
Table 9 lists the tunneling attributes supported in this Cisco Access Registrar release.
| Attribute Number | Attribute |
|---|---|
64 | Tunnel-Type |
65 | Tunnel-Medium-Type |
66 | Tunnel-Client-Endpoint |
67 | Tunnel-Server-Endpoint |
69 | Tunnel-Password |
81 | Tunnel-Private-Group-ID |
82 | Tunnel-Assignment-ID |
83 | Tunnel-Preference |
90 | Tunnel-Client-Auth-ID |
91 | Tunnel-Server-Auth-ID |
The tunneling attribute has the following format:
|
|
|
|
|
|
|
|
1. Configure the tag attributes as untagged attributes under the /Radius/Advanced/Attribute Dictionary directory (for example, Tunnel-Type).
2. Attach the "_tag" tag to these attributes when configuring the attributes under all of the other directories as tagged attributes (for example, Tunnel-Type_tag10 under the /Radius/Profiles/test directory). Without the tag number, the default value is _tag0.
/Radius/Advanced/Attribute DictionaryMax = 253 /Radius/Profiles/test
/Tunnel-Client-ID
Name = Tunnel-Client-Endpoint
Description =
Attribute = 66
Type = STRING
Min = 0Name = test
Description =
/Attributes
Tunnel-Client-Endpoint_tag3 = "129.56.123.1"
1. "_tag" is reserved for the tunneling attributes. No other attributes should include it.
2. The tag number value can range from 0 through 31.
1. Cisco Access Registrar checks whether the tag attributes are defined under the /Radius/Advanced/Attribute Dictionary directory.
2. Cisco Access Registrar checks whether the tag number falls within the range (0-31).
To provide this support, a distinction must be made between device authentication packets and regular user authentication packets. To identify device authentication packets, the following changes are proposed for three scenarios.
This approach assumes that all Cisco 6400 devices are using the same User-Name and User-Password attributes for device authentication. The following changes must be made.
In the Cisco Access Registrar configuration, the 6400AAA script is defined as follows:
Name = 6400AAA
Description =
Language = REX
Filename = libAR6400.so
EntryPoint = Auth6400
InitEntryPoint = Init6400AAA
InitEntryPointArgs = cisco::cisco
In the Cisco Access Registrar configuration, for each Network Access Server (NAS), a client incoming script is defined as follows:
Name = test6400-1
Description =
IPAddress = 209.165.200.224
SharedSecret = secret
Type = NAS
Vendor =
IncomingScript = 6400AAA
OutgoingScript =
When the 6400 sends out the device authentication packet, Cisco Access Registrar assumes the User-Name/User-Password attributes are cisco/cisco (defined as the value of InitEntryPointArgs in the script definition). When Cisco Access Registrar verifies that the packet is from a known NAS, it runs the 6400AAA script. This all occurs prior to authentication taking place. The 6400AAA script does the device authentication work. First, it ensures the User-Name/User-Password attributes exist in the packet and that they match the cisco/cisco values configured as parameters in the 6400AAA script. When they do match, Cisco Access Registrar concludes that this is a 6400 device. The next step is to replace the User-Name attribute with the concatenated string of the <module>/<slot>/<port> etc. (see below). From this point, the packet is treated as a regular packet.
|
Note A user record with the name of the concatenated string must exist. |
This approach assumes that for every 6400 NAS, a device-name/device-password is created for each. Following are the required changes:
For each NAS in Cisco Access Registrar:
Name = test6400-1
Description =
IPAddress = 209.165.200.224
SharedSecret = secret
Type = NAS
Vendor =
IncomingScript =
OutgoingScript =
Device-Name = theDevice
Device-Password = thePassword
When the 6400 sends out the device authentication packet, it may have different User-Name/User-Password attributes for each 6400 NAS. When Cisco Access Registrar receives the packet, it tries to obtain the Device-Name/Device-Password attributes from the NAS entry in the Cisco Access Registrar configuration database. When the User-Name/User-Password in the packet match the configured Device-Name/Device-Password attribute values, Cisco Access Registrar assumes that it must get the device. The next step is to replace the User-Name attribute with the concatenated <module>/<slot>/<port> string. From this point, the packet is treated as a regular packet.
|
Note A user record with the name of the concatenated string must be created. |
The individual User-Name/User-Password approach scales better; however, it requires more configuration on both the Cisco Access Registrar and NAS sides. The combined approach tries to use individual NAS User-Name/User-Password values; when defined. Otherwise, the global User-Name/User-Password values are used as default.
|
Note This is the recommended approach. |
Following are the configuration steps. In the Cisco Access Registrar configuration, a script is defined:
6400AAAName = 6400AAA Description = Language = REX Filename = libAR6400.so EntryPoint = Auth6400 InitEntryPoint = Init6400AAA InitEntryPointArgs = cisco::ciscoName = test6400-1(device configured for individual User-Name/User-Password): Description = IPAddress =209.165.200.224SharedSecret = secret Type = NAS Vendor = IncomingScript = OutgoingScript = Device-Name = theDevice Device-Password = thePasswordName = test6400-2(device configured for global User-Name/User-Password): Description = IPAddress =209.165.200.224SharedSecret = secret Type = NAS Vendor = IncomingScript = 6400AAA OutgoingScript =
When Cisco Access Registrar gets a packet from a NAS, it first locates the NAS record. When it obtains Device-Name/Device-Password attributes, it uses them to identify the device. When the Device-Name/Device-Password attributes are not defined, and IncomingScript is defined, it uses the script to identify the device. When nothing is defined, it treats the packet as a regular packet and has it go through regular processing.
After the device is identified, the User-Name attribute is replaced with the new value. This new value is the concatenation of 6400 <module>/<slot>/<port> information and the packet is treated as a regular user authentication from this point on.
The format of the new User-Name attribute is the printf of "%s-%d-%d-%d-%d-%d" for the following values:
NAS-IP—in dot format of the NAS-Ip-Address attribute. For example, 10.10.10.10.
slot—apply mask 0xF0000000 on NAS-Port attribute and shift right 28 bits. For example, NAS-Port is 0x10000000, the slot value is 1.
module—apply mask 0x08000000 on NAS-Port attribute and shift right 27 bits. For example, NAS-Port is 0x08000000, the module value is 1.
port—apply mask 0x07000000 on NAS-Port attribute and shift right 24 bits. For example, NAS-Port is 0x06000000, the port value is 6.
VPI—apply mask 0x00FF0000 on NAS-Port attribute and shift right 16 bits. For example, NAS-Port is 0x00110000, the VPI value is 3.
VCI—apply mask 0x0000FFFF on NAS-Port attribute. For example, NAS-Port is 0x00001001, the VCI value is 9.
You can define the User-Profile and User-Group environment variables in the directory mapping and Cisco Access Registrar will apply the profiles defined in the Cisco Access Registrar database to each directory user having any of these two variables set.
This attribute is of type string with the format:
<Value1>::<Value2>
The User-Profile attribute is intended to hold a list of profile names. <Value1> and <Value2> represent the names of the profiles. They are separated by the "::" character, therefore, the "::" can not be part of the profile name. The order of values in the string has significance, as the profiles are evaluated from left to right. In this example, profile <Value2> is applied after profile <Value1>.
Assume the user record has a field called UserProfile that holds the name of the profile that applies to this user. This field is mapped to the environment attribute User-Profile. Following is how the mapping is done with aregcmd:
QuickExample/
Name = QuickExample
Description =
Protocol = ldap
IPAddress = 209.165.200.224
Port = 389
ReactivateTimerInterval = 300000
Timeout = 15
HostName = QuickExample.company.com
BindName =
BindPassword =
UseSSL = FALSE
SearchPath = "o=Ace Industry, c=US"
Filter = (uid=%s)
UserPasswordAttribute = password
LimitOutstandingRequests = FALSE
MaxOutstandingRequests = 0
MaxReferrals = 0
ReferralAttribute =
ReferralFilter =
PasswordEncryptionStyle = None
LDAPToEnvironmentMappings/
UserProfile = User-Profile
LDAPToRadiusMappings/
After Cisco Access Registrar authenticates the user, it checks whether User-Profile exists in the environment dictionary. If it finds User-Profile, for each value in User-Profile, Cisco Access Registrar looks up the profile object defined in the configuration database and adds all of the attributes in the profile object to the response dictionary. If any attribute is included in more than one profile, the newly applied profile overrides the attribute in the previous profile.
You can use the User-Group environment variable to apply the user profile as well. In Cisco Access Registrar, a user can belong to a user group, and that user group can have a pointer to a user profile. When Cisco Access Registrar finds that a packet has User-Group set, it obtains the value of the User-Profile within the user group, and if the User-Profile exists, it applies the attributes defined in the user profile to that user.
Note that in Cisco Access Registrar, every user can also directly have a pointer to a user profile. Cisco Access Registrar applies profiles is in the following order:
1. If the user profile defined in the user group exists, apply it.
2. If the user profile defined in the user record exists, apply it.
The profile in User-Group is more generic than in User-Profile. Therefore, Cisco Access Registrar applies the profile from generic to more specific.
You can use an existing user attribute in the user record to store profile info. When this is a new attribute, we suggest you create a new auxiliary class AR_UserRecord for whichever user class is used. AR_User_Profile and AR_User_Group are two optional members in this class. They are of type string. The mapping is as follows:
LDAPToEnvironmentMappings/ AR_User_Profile = User-Profile AR_User_Group = User-Group
If any attributes mapped from the LDAP directory to the Cisco Access Registrar response dictionary are multi-valued, the attributes are mapped to multiple RADIUS attributes in the packet.
Cisco Access Registrar supports MultiLink-PPP (ML-PPP). ML-PPP is an IETF standard, specified by RFC 1717. It describes a Layer 2 software implementation that opens multiple, simultaneous channels between systems, providing additional bandwidth-on-demand, for additional cost. The ML-PPP standard describes how to split, recombine, and sequence datagrams across multiple B channels to create a single logical connection. The multiple channels are the ports being used by the Network Access Server (NAS).
During the AA process, Cisco Access Registrar authenticates the user connection for each of its channels, even though they belong to the same logical connection. The Authentication process treats the multilink connection as if it is multiple, single link connections. For each connection, Cisco Access Registrar creates a session dedicated for management purposes. The session stays active until you logout, which subsequently frees up all of the ports in the NAS assigned to each individual session, or until the traffic is lower than a certain threshold so that the secondary B channels are destroyed thereafter. Cisco Access Registrar has the responsibility of maintaining the active session list and discards any session that is no longer valid in the system, by using the accounting stop packet issued from NAS. The multiple sessions that were established for a single logical connection must be destroyed upon the user logging out.
In addition, the accounting information that was gathered for the sessions must be aggregated for the corresponding logical connection by the accounting software. Cisco Access Registrar is only responsible for logging the accounting start and accounting stop times for each session. As those sessions belong to the same bundle, IETF provides two standard RADIUS attributes to identify the related multilink sessions. The attributes are Acct-Multi-Session-Id (attribute 50) and Acct-Link-Count (attribute 51), where Acct-Multi-Session-Id is a unique Accounting identifier used to link multiple related sessions in a log file, and Acct-Link-Count provides the number of links known to have existed in a given multilink session at the time the Accounting record was generated. The Accounting software is responsible for calculating the amount of the secondary B channel's connection time.
The secondary B channel can go up and down frequently, based upon traffic. The Ascend NAS supports the Target-Util attribute, which sets up the threshold for the secondary channel. When the traffic is above that threshold the secondary channel is up, and when the traffic is below that threshold, the secondary B channel is brought down by issuing an Accounting stop packet to Cisco Access Registrar. On the other hand, if you bring down the primary channel (that is, log out), the secondary B channel is also destroyed by issuing another Accounting stop packet to Cisco Access Registrar.
Table 10 lists ML-PPP related attributes.
| Number | Attribute | Cisco NAS (IOS 11.3 Release) | Ascend NAS |
|---|---|---|---|
44 | Acct-Session-Id | Supported | Supported |
50 | Acct-Multi-Session-Id | Supported | Supported |
51 | Acct-Link-Count | Supported | Supported |
62 | Port-Limit | Supported | Supported |
234 | Target-Util | Not Supported | Supported |
235 | Maximum-Channels | Supported | Supported |
Following are sample configurations for ML-PPP:
/Radius /Profile /Default-ISDN-Users Name = Default-ISDN-Users Description = Attributes/ Port-Limit = 2 Target-Util = 70 Session-Timeout = 70 /Radius /UserGroups /ISDN-Users Name = ISDN-Users Description = " Users who always use ISDN" BaseProfile = Default-ISDN-Users Authentication-Script = Authorization-Script =
The Port-Limit attribute controls the number of concurrent sessions a user can have. The Target-Util attribute controls the threshold level at which the second B channel should be brought up.
The Dynamic Updates feature enables changes to server configurations made using aregcmd to take effect in the Cisco Access Registrar server after issuing the save command, eliminating the need for a server reload after making changes.
Table 11 lists the Radius object and its child objects. For each object listed, the Add and Modify or Delete columns indicate whether a dynamic update occurs after adding, modifying, or deleting an object or attribute. Entries in the Add and Modify or Delete columns also apply to child objects and child attributes of the objects listed, unless the child object is explicitly listed below the object, such as /Radius/Advanced/Ports or /Radius/Advanced/Interfaces.
| Object | Add | Modify or Delete |
|---|---|---|
Radius | Yes | Yes |
| Yes | Yes |
| Yes | Yes |
| Yes | Yes |
| Yes | Yes |
| Yes | Yes |
| Yes | Yes |
| Yes | Yes |
| Yes | No |
| Yes | No |
| Yes | Yes |
| Yes | Yes |
| Yes | Yes |
| Yes | Yes |
| Yes | Yes |
| Yes | Yes |
| Yes | Yes |
| No | No |
| No | No |
The Dynamic Updates feature is subject to the following limitations:
The Cisco Access Registrar Rule Engine provides an interface to define and configure a policy and to apply the policy to the corresponding access-request packets. Authentication service is based on Realm, Dialed Number Information String (DNIS), and Calling Line ID (CLID). The following is an example set of policies and rules:
/Policies
/SelectPolicy
Name = SelectPolicy
Description =
Grouping = CiscoRealmRule|CiscoCLIDRule/CiscoSelectPolicy
Name = CiscoSelectPolicy
Description =
Grouping = CiscoGroupRule/CiscoDefaultPolicy
.../CiscoExecPolicy
Name = CiscoExecPolicy
Description =
Grouping =CiscoExecTimeRule1&CiscoExecSecurityRule|CiscoExecTimeRule2..../Rules
/CiscoRealmRule
Name = CiscoRealmRule
Description =
Script = ExecRealmRule
/Attributes
Realm = @cisco.com
AuthenticationService = jen1-ultra
Policy = CiscoSelectPolicy/CiscoCLIDRule
Name = CiscoCLIDRule
Description =
Script = ExecCLIDRule
/Attributes
.../CiscoGroupRule
Name = CiscoGroupRule
Description =
Script = ExecGroupRule
/Attributes
Group = CiscoExec
Policy = CiscoExecPolicy
DefaultPolicy = CiscoDefaultPolicy/CiscoExecTimeRule1
Name = CiscoExecTimeRule1
Description =
Script = ExecTimeRule
/Attributes
TimeRange = "mon-fri,06:00-18:00";
AcceptedProfiles = PPP-USER/CiscoExecTimeRule2
Name = CiscoExecTimeRule2
Description =
Script = ExecTimeRule
/Attributes
TimeRange = "sun,18:00-24:00;sat,18:00-24:00";
AcceptedProfiles = TELNET-USER/CiscoExecSecurityRule
Name = SecurityRule
Description =
Script = ExecSecurityRule
/Attributes
TunnelEnforcement = TRUE
AuthenticationProtocol = CHAP
1. /Radius/Policies/SelectPolicy is the first policy Cisco Access Registrar applies.
2. "|" and "&" are reserved as logical operands in a Grouping definition; they cannot be included in a /Radius/Rules name.
3. A space is not permitted between the logical operands and the rules in a Grouping definition.
4. The scripts included in the rules must be defined under the /Radius/Scripts directory.
5. The attributes included in the rules must be defined under the /Radius/Advanced/Attribute Dictionary directory.
6. The rules included in the policies must be defined under the /Radius/Rules directory.
When policies are configured, the following validations are performed by Cisco Access Registrar:
1. A check is performed to ensure the scripts included in the rules are defined under the /Radius/Scripts directory.
2. A check is performed to ensure the attributes included in the rules are defined under the /Radius/Advanced/Attribute Dictionary directory.
3. A check is performed to ensure the rules included in the policies are defined under the /Radius/Rule directory.
1. Grouping expressions are not checked for validity.
2. The use of parentheses to denote precedence is not supported in a Grouping definition.
3. A check is not performed to determine whether a policy that is included within another policy is defined under the /Radius/Policies directory.
The Cisco Access Registrar 1.5 release provides the following service enhancements:
1. Service determination by DNIS, Realm, or CLID, or a pattern match of these parameters.
2. Attributes Insertion/Substitution/Translation for proxy packets.
This requirement is for service determination by Realm, CLID, DNIS, and pattern matching to these three parameters for providing proxy or local services.
Service determination is set through the Cisco Access Registrar Rule Engine. To make all scripts ready to run, all scripts must be configured and set up through the aregcmd command. The following scripts are used for service determination:
These scripts extract the domain of the username or called-station-id or calling-station-id from the access request packet and compares it with the Realm, DNIS, or CLID set within the rule. Upon finding a match, the scripts will set the services (Authentication-Service, Authorization-Service, or Accounting-Service) into the Environment Dictionary.
In order to invoke this service enhancement, you must add rules and policies. Under the /Radius/Rules directory, you set the script that is going to be executed. Under the /Radius/Policies directory, you set the combination of rules.
Following is an example for adding a new Realm rule:
cd /Radius/Rules
Add RealmRule
cd RealmRule
Set Script ExecRealmRule
cd Attributes
Set Realm @cisco.com
SetAuthentication-Service local-users
SetAuthorization-Service local-users
where Realm is the domain filter for user name. If the user-name contains @cisco.com, the ExecRealmRule script sets Authentication-Service and Authorization-Service to local-users. The current release also supports the #cisco.com format.
Besides setting up the rules, you must also set up one or more policies. Policies can be any combination of rules using the and (&) and or (|) operators. Using the above example, a policy is setup as follows:
cd /Radius/Policies
Add SelectPolicy
cd SelectPolicy
Set Grouping RealmRule
This feature supports the RADIUS proxy with the ability to customize attribute filters so that RADIUS attribute value pairs can be inserted/deleted/substituted.
For example, when roaming a packet from ISP A to ISP B, some attribute value (AV) pairs may be substituted (such as IP address) as they may not be valid on B's network. Additionally, B may return some vendor-specific attributes (VSAs) that are not applicable to A's network. Therefore, A will substitute B's VSA value pairs for A's VSAs.
Two new configuration points have been added under the /Radius directory: Translations and TranslationGroups. Under the /Radius/Translations directory, any translation to insert/substitute/translate attributes can be added. The following is a sample configuration under the /Radius/Translations directory:
cd /Radius/Translations
Add T1
cd T1
Set DeleAttrs Session-Timeout,Called-Station-Id
cd Attributes
Set Calling-Station-Id 18009998888
DeleAttrs is the set of attributes to be deleted from the packet. Each attribute is comma separated and no spaces are allowed between attributes.
Under the /Radius/Translations/T1/Attributes directory, inserted or translated attribute value pairs can be set. These attribute value pairs are either added to the packet or replaced with the new value.
Under the /Radius/TranslationGroups directory, translations can be grouped and applied to certain sets of packets, which are referred to in a rule. The following is a sample configuration under the /Radius/TranslationGroups directory:
cd /Radius/TranslationGroups
Add CiscoIncoming
cd CiscoIncoming
cd Translations
Set 1 T1
The translation group is referenced through the Cisco Access Registrar Rule Engine in the /Radius/Rules/<RuleName>/Attributes directory. Incoming-Translation-Groups are set to a translation group (for example CiscoIncoming) and Outgoing-Translation-Groups to another translation group (for example CiscoOutgoing).
The following is an example of setting up a rule for a translation group.
cd /Radius/Rules
Add CiscoTranslationRule
cd CiscoTranslationRule
cd Attributes
Set Realm @cisco.com
Set Incoming-Translation-Groups CiscoIncoming
Set Outgoing-Translation-Groups CiscoOutgoing
The CiscoTranslationRule rule must be referred to in the /Radius/Policies directory so the Cisco Access Registrar Rule Engine can invoke this rule. If the pattern of Realm, DNIS, or CLID matches the one defined in the rule, the Cisco Access Registrar Rule Engine sets Incoming-Translation-Groups to CiscoIncoming in the Environment Dictionary. By looking up the definition of CiscoIncoming, Cisco Access Registrar applies all of the translations to the incoming packet before it is proxied to the other server. When the proxied packet comes back to the RADIUS server, Cisco Access Registrar does a similar process to the outgoing packet. Note, Realm in the above example is a filter for packets whose user-name contains @cisco.com.
DNIS, CLID, and Realm are supported for filtering packets in the current release.
Cisco Access Registrar supports limited wildcard functionality. Cisco Access Registrar supports the "*" and "?" wildcard characters. "*" matches any number of characters, including the Null character, and "?" matches any single character, not including the Null character. Currently, wildcards apply to Realm, DNIS, and CLID attributes.
|
Note All Realms should start with the "@" character. For example, Realm=@cisco.com. |
The following is an example using the "*" wildcard character:
/Radius /Rules /Rule1 Name=rule1 Description = ScriptName = ExecRealmRule Attributes/ Authentication-Service = Local-Users Authorization-Service = Local-Users Realm = @*cisco.com
In the above example, when the domain of the user name in an access request matches the @*cisco.com pattern (for example, @us.cisco.com, @eng.cisco.com, and @cisco.com are all good matches), the ExecRealmRule script sets Authentication-Service and Authorization-Service to Local-Users in the environment dictionary.
The following is an example using the "?" wildcard character:
/Radius
/Rules
/Rule2
Name = rule2
Description =
ScriptName = ExecDNISRule
Attributes/
Authentication-Service = Translation-Service
Authorization-Service = Translation-Service
DNIS = 1800345987?
In the above example, if the Called-Station-Id attribute in the packet matches 1800345987? (for example, 18003459876 and 18003459870 are good matches, while 1800345987 is not), the ExecDNISRule script sets Authentication-Service and Authorization-Service to Translation-Service in the environment dictionary.
Cisco Access Registrar also supports both wildcard characters in one pattern. For example,CLID = 180098?87* is valid.
The ExecTimeRule script, invoked by the Cisco Access Registrar Rule Engine, applies the TimeOfDay rule to the access request packet during the RADIUS server's incoming packet processing. The ExecTimeRule script either rejects or accepts the access request packets based upon the allowable user's login profiles within a certain time range.
The format of the TimeRange internal attribute is as follows:
TimeRange = dateRange, timeRange [; dateRange, TimeRange] dateRange = mdayRange | weekdayRange mdayRange = number [-number] number = 1 | 2 | 3 | | 31 weekdayRange = weekday [-weekday] weekday = sun | mon | tue | wed | thu | fri | sat timeRange = hh:mm - hh:mm hh = 00 | 01 | | 24 mm = 00 | 01 | | 60
For example:
mon-fri,09:00-17:00 mon,09:00-17:00; tue-sat,12:00-13:00 mon,09:00-24:00;tue,00:00-06:00 1-13,10-17:00; 15,00:00-24:00
The format of the AcceptedProfiles internal attribute is as follows:
AcceptedProfiles = userProfile[; userProfile]
The following is an example:
/Policies...
/MarketingTODPolicy
Name = MarketingTODPolicy
Description =
Grouping = MarketingTODRule/EngineeringTODPolicy
Name = EngineeringTODPolicy
Description =
Grouping = EngineeringTODRule.../Rules.../MarketingTODRule
Name = MarketingTODRule
Description =
Script = ExecTimeRule
/Attributes
TimeRange = "mon-fri,8:00-17:00;sat,20:00-24:00;sun,00:00-7:00"
AcceptedProfile = PPP-users/EngineeringTODRule
Name = EngineeringTODRule
Description =
Script = ExecTimeRule
/Attributes
TimeRange = "sun-sat,00:00-24:00"
AcceptedProfiles = PPP-users;Telnet-users
...
1. Spaces cannot be used in the TimeRange or AcceptedProfiles attributes.
2. The lower limit must be less than the upper limit within any specified range.
Cisco Access Registrar validates the above configuration as follows:
1. Checks whether the ExecTimeRule script is defined under the /Radius/Scripts directory.
2. Checks whether the TimeRange and AcceptedProfiles attributes are defined under the /Radius/Advanced/Attributes Dictionary.
3. Checks whether the profiles included in the AcceptedProfiles attribute are defined under the /Radius/Profiles directory.
1. Cisco Access Registrar does not check the format of the TimeRange attribute.
2. Cisco Access Registrar does not validate the lower limit and the upper limit with the TimeRange attribute.
aregcmd now records the commands that are either entered interactively or executed in batch mode. The recorded commands are saved in the aregcmd_log file, which resides in the logs directory within the Cisco Access Registrar installation directory.
For security reasons, aregcmd blocks out the actual password that is entered as part of the command and replaces it with <passwd>.
In interactive mode, aregcmd logs the actions that are taking place in the exit/logout dialog box. The action can be save or not save if the configuration database has been modified after the last execution of the save command.
In non-interactive (batch) mode, aregcmd replaces the empty field with a NULL string.
aregcmd is now installed as a setgid program where the group is set to staff. This allows a non-root user to run aregcmd while still being able to write to the aregcmd_log log file. During the installation of the Cisco Access Registrar product, you are prompted whether you want to install aregcmd with setuid/setgid permissions. You must reply "yes" unless you only run aregcmd as user root.
The following is the format of an entry in the exit/logout dialog box when not save has been specified:
Mm/dd/yyyy HH:MM:SS aregcmd Info Configuration 0
[<clustername> <username>] ( exit )
Mm/dd/yyyy HH:MM:SS aregcmd Info Configuration 0
[<clustername> <username>] ( *** New config is not saved!
...proceed to logout.)
The following is sample output of an entry in the exit/logout dialog box when not save has been specified:
09/23/1999 16:18:56 aregcmd Info Configuration 0
[localhost admin] --> quit
09/23/1999 16:19:02 aregcmd Info Configuration 0
[localhost admin] --> *** New config is not saved!
...proceed to logout.
The following is the format of an entry in the exit/logout dialog box when save has been specified:
Mm/dd/yyyy HH:MM:SS aregcmd Info Configuration 0
[<clustername> <username>] ( exit )
Mm/dd/yyyy HH:MM:SS aregcmd Info Configuration 0
[<clustername> <username>] ( *** New config saved!
...proceed to logout.)
Commands entered at the aregcmd prompt can be edited with a subset of the standard EMACS style key strokes. A description of the supported key strokes are shown in Table 12.
| Key Stroke | Description |
|---|---|
Ctrl A | Go to the beginning of the line. |
Ctrl B | Move back one character. |
Ctrl D | Delete the character at the cursor. |
Ctrl E | Go to the end of the line. |
Ctrl F | Move forward one character. |
Ctrl N | Retrieve the next line. |
Ctrl P | Retrieve the previous line. |
RADIUS server up/down detection and logging has been added to this release of Cisco Access Registrar. The information messages are saved in the <AR_install_dir>/logs/name_radius_1_log file where <AR_install_dir> is Cisco Access Registrar installation directory.
Each message consists of a header and a message description.
The format of a header entry is:
mm/dd/yyyy HH:MM:SS name/radius/n Error Server 0
Following are the descriptions and types of messages that can be found within the <AR_install_dir>/logs/name_radius_1_log file.
1. Cisco Access Registrar detects a Remote Server when it responds for the first time or after it is reentered into Cisco Access Registrar's server pool for retry. The format of the message is:
09/14/1999 17:56:32 name/radius/1 Error Server 0
Remote Server dave-ultra (171.69.237.99:1645) is UP!
09/14/1999 17:57:12 name/radius/1 Error Server 0 Remote
server dave-ultra (171.69.237.99:1645) is DOWN!
2. Cisco Access Registrar receives no response from the Remote Server after the server is reentered into Cisco Access Registrar's server pool for retry. The format of the message is:
09/14/1999 17:56:32 name/radius/1 Error Server 0 Remote
server dave-ultra (171.69.237.99:1645) remains DOWN!
3. The Remote Server is responding to the first retry but not the initial request. The format of the message is:
09/14/1999 17:56:32 name/radius/1 Error Server 0 Remote
server dave-ultra (171.69.237.99:1645) is UP but slow!
4. The Remote Server is responding to the second retry request but not the initial request or the first retry request. The format of the message is:
09/14/1999 17:56:32 name/radius/1 Error Server 0 Remote
server dave-ultra (171.69.237.99:1645) is UP but very slow!
5. The Remote Server has been marked inactive and is being put back into Cisco Access Registrar's server pool for later use. The format of the message is:
09/14/1999 17:56:32 name/radius/1 Error Server 0 Remote
server dave-ultra (209.165.200.224:1645) is being reactivated for later use.
This section describes the bugs fixed in the 1.5 release of Cisco Access Registrar.
| Bug Number | Description |
|---|---|
CSCai03470 | Process ParseAARealm has regular expression bug. This was fixed in the destiny/servers/radius/src/tclscript.tcl file for the following processes: ParseAAARealm ParseAARealm ParseAAASRealm |
CSCdm82121 | Multistream accounting script core dumps server. We have found that the Solaris localtime() call is not thread safe and so a change has been made to avoid using this function. |
CSCdp24841 | Added new aregcmd logging and RADIUS server up/down detection. |
This section describes the bugs known to exist in this release of Cisco Access Registrar.
| Bug Number | Description |
|---|---|
CSCdm49977 | aregcmd and radclient hang when /temp is full. The second instance will hang on login. CTRL-C will not work. Trying to use kill to remove the process will result in a PPID of 1 to one of the processes. The only way to remove the hung process is to reboot. The second instance does not need to be the same program as the first instance. You will not be able to shut down the RADIUS server due to the running process. |
CSCdm64258 | Cannot run more than six aregcmd sessions to one server. |
CSCdm92870 | Validate does not fail for an empty UserList in a service. If a new service is created without a UserList, it will pass validation and save, but reload will fail with the following error: The server wrote the following errors to the log file: Configuration Internal Error in /Radius/Services/<service name>/: Required property UserList did not exist. Validation should fail in this case. |
CSCdp21838 | ls -R inconsistent in certain objects. If the Resource Manager object is set to type ip-dynamic, running ls -R with more than twenty IP pools results in only the current twenty pools being listed. Other sets of twenty appear when you cd into the pools and do a previous/next before doing another ls -R. |
CSCdp21844 | Inconsistent directory reporting in aregcmd. When you cd into certain objects within aregcmd, the current directory is not updated properly. This behavior is seen in the IP pools for a Resource Manager set to type ip-dynamic. |
CSCdp23831 | Loss of authentication when log partition is full/not writable. It has been suggested in the past that this is a documented "feature" of Cisco Access Registrar. I was unable to find any documentation pointing this out. Additionally, in the kind of mission critical environments that Cisco Access Registrar is placed in, keeping the processing of authentication requests running is necessary regardless of whether (or not) the logs can still be written. |
CSCdp64341 | Validate does not fail after deleting a referenced Remote Server. |
CSCdp91695 | Misleading aregcmd error reported. In aregcmd, when cd /Radius/Translation is invoked, an error message stating the directory could not be found is erroneously displayed. Instead, an error message stating the path is ambiguous should be displayed, as the /Radius/Translation and /Radius/TranslationGroups directories do exist. |
CSCdp91733 | Example data sources do not match. The example data imported while installing Cisco Access Registrar does not match the example data when installed through the ad-example-configuration.rc script. |
CSCdp91753 | Logging does not work for files greater than or equal to 2Gb. No more logging occurs when the log file grows to over 2047Mb. |
CSCdp92780 | Upgrade configuration option needed. The install package should ask if the user would like help upgrading an existing database. If so, all the necessary configuration files should be added into the old configuration. At this point`, the Rule Engine and any translation scripts and attributes fall into this action. |
CSCdr05185 | No validation on the replication attributes. |
CSCdr05605 | Core generated after setting a rule without script and/or attribute. |
CSCdr05617 | When a tag attribute is created such as |
CSCdr06186 | Multiple rules did not get executed. After setting the policy=newPolicy rule, it was not executed. Only the selectpolicy rule was executed. Even though selectpolicy is the entry point, it should execute all policies if it is referenced in the policy. |
CSCdr09456 | Default RADIUS ports are not RFC compliant. Note, you can define multiple ports per your choosing. |
CSCdr13784 | arservagt does not check for root uid. The arservagt script tries to write to a file in $INSTALLPATH/logs which is owned by root. However, the script does not check for the root uid and emits a misleading error when the script is accidentally run by a non-root uid. |
CSCdr14054 | A policy cannot be referred to in a rule if it is not defined. |
CSCdr14061 | Cisco Access Registrar goes into an infinite loop when two policies are invoked. |
CSCdr14092 | Multiple rules are executed in an OR condition. |
CSCdr14104 | Validation does not fail for p[olicy grouping with keyword example: cd /Radius/Policy |
CSCdr14133 | A keyword shown in a rule name is not validated properly. The following is invalid: cd /Radius/Rules |
CSCdr14141 | Validation does not occur fro attributes under a rule. The following configuration passes validation but should not: cd /Radius/Rules |
CSCdr14189 | Problem with tunnel attributes with tag0*. When you do the following configuration changes, they should fail validation. They do fail validation, however, the RADIUS server stops. cd /Radius/Profile |
CSCdr14192 | No validation for tunnel attribute. The following configuration should fail validation, however, it does not: cd /Radius/Profile |
CSCdr14210 | The server cores when you start the LDAP server first, then send a simple packet (for example, |
CSCdr14883 | Client secret not dynamically updated. |
CSCdr18965 | Erroneous log message after changing Remote Server secret. |
CSCdr18971 | Adding a Remote Server from the command line fails. |
CSCdr18977 | Reload ordering problem with scripts may cause server to core. Reproduce this bydoing the following: Add a new script definition. In most cases, an error message stating that the script is invalid is displayed, which occasionally causes the server to core dump. |
CSCdr18984 | Erroneous log message about shared secrets. |
CSCdr18990 | Ghost Remote Server appears in stats output. |
This section provides the following information about the 1.3 Cisco Access Registrar release:
The 1.3 Cisco Access Registrar release includes the following new features:
1. Concurrent local and proxy accounting streams.
2. Multi-valued RADIUS attribute support.
3. Enhanced duplicate request filtering.
4. Server log file roll over.
5. Statistics output redirection.
Table 15 describes the bugs fixed in the 1.3 Cisco Access Registrar release.
| Bug Number | Description |
|---|---|
CSCai02371 | The two new example scripts add-example-configuration.rc and delete-example-configuration.rc do not automatically reload the server. After running either script, you must manually reload the server to update the database with your changes. |
CSCai02626 | Enhancement: aregcmd can now be used to set the maximum size of the Cisco Access Registrar log files, and the number of log files kept. |
CSCai03094 | Can't eject the CD ROM after pkgadd if it is performed within the cdrom directory. |
CSCai03185 | Cisco Access Registrar does not assign an IP address (or allocate any other resources) when the reply from a remote RADIUS server contains a State attribute. |
CSCai03346 | The AddProfile method does not come back with an error code if the Profile is not found. |
CSCai03376 | Enhancement: the SessionManager for an Accounting-Request is automatically determined by the SessionManager chosen for the previous Access-Request for the same NAS and NAS-Port. |
CSCai03389 | Enhancement: The OutagePolicy on a Service now applies to Accounting-Requests, as well as Access-Requests. |
CSCai03392 | The Adaptive Round Trip Time (RTT) algorithm can cause the dynamic timeout value to become too small and cause invalid timeouts on a RemoteServer. |
CSCai03501 | If a NAS fails to return the State Attribute in Accounting-Requests, SessionManagement does not operate properly. |
CSCai03579 | The RemoteServer name should be displayed with an IP address in aregcmd stats output. |
CSCai03580 | Enhancement: aregcmd now supports the $PAGER environment variable. Currently, this is only used when presenting statistics, and it is only used in interactive mode. |
CSCai03584 | Adding attributes in the standard attribute space with the same name as an existing vendor-specific attribute causes aregcmd to fail. |
CSCai03719 | Enhancement: "Static" IP Addresses (from Profiles or Proxies) are now visible in Session data. See "Session Notes" feature for more information. |
CSCai03789 | Incorrect error message displayed when NULL (zero) is passed as a string value to any of the REX API put functions. |
CSCai03800 | Cisco Access Registrar crashes when a Client is configured with type Proxy, and a request either contains a NAS-Identifier attribute that matches that Client's name, or the request contains a NAS-IP-Address attribute with that Client's IP address. |
CSCai03814 | Cisco Access Registrar should identify the name and IP address of a RemoteServer in any failure log message. |
CSCai04088 | Iterating through Vendor-Specific attributes with a REX or TCL script/service may find the wrong attributes in the Request/ Response dictionary. |
CSCai04101 | After initially installing the product, if the examples are installed, aregcmd may ask the admin to save (upon exit) even if no changes were made. |
CSCdk83312 | Trailing NULL characters included at the end of passwords returned from LDAP may cause PAP/CHAP authentication to fail. |
CSCdk86146 | Out of sequence Accounting "Start" requests can create orphaned sessions, possibly leaking dynamic resources. (See "Session Creation" for solution details). |
Table 16 describes the known bugs in the 1.3 Cisco Access Registrar release.
| Bug Number | Description |
|---|---|
CSCai02130 | When accounting files are rolled, they are renamed to a file that includes the date range of the entries inside. Unfortunately, the creation and modification times of the file are in UTC, while the time stamp on each accounting record is in local time. Thus, there is a time skew between the times used for the name of the rolled accounting file and the time stamp for the first and last record in the file. |
CSCai02242 | Cisco Access Registrar displays the message, "Database lock attempt failed" if you stop the server while it is still in the process of starting. If this occurs, you will not lose any data. |
CSCai02273 | Validation succeeds when multiple administrators enter the same user in the UserList. Instead of reporting a conflict, both administrators will be modifying the same user records. |
CSCai02319 | Validation doesn't check whether a deleted RemoteServer or a deleted ResourceManager is referred to by a Service or a SessionManager, respectively. |
CSCai02320 | After a save, the aregcmd command displays the value of a new Networks range in an IPX-dynamic ResourceManager in decimal. To restore the display, log in to the cluster again. |
CSCai02432 | Cisco Access Registrar does not check the Response-Type which may be set by a Script immediately after running the Server, or Vendor Scripts. It is checked after the Client Script point. |
CSCdk82488 | aregcmd will let the administrator add a VSA with the same name as an existing standard attribute, or a VSA for another vendor. |
CSCai02946 | Requests authenticated with a TACACS service do not get reflected in the Cisco Access Registrar server statistics. |
This section provides information that was missing from the 1.3 Cisco Access Registrar documentation.
If you have the situation where a Cisco Access Registrar RADIUS server is acting as a forwarding server and proxying requests to one or more remote RADIUS servers, the Accounting-On and Accounting-Off requests are only proxied to Remote Servers when the request is directly from a NAS.
Note, Cisco Access Registrar only forwards the Accounting-On or Accounting-Off requests when they come directly from a NAS. It does not forward requests when they are from a proxy. Therefore, if you have a chain of forwarding servers, the Accounting-On or Accounting-Off request will not be forwarded for more than one hop.
When Cisco Access Registrar is unable to write accounting records to disk, this information may be lost. Cisco Access Registrar continues to run, however, it does not acknowledge accounting requests. After you have made disk space available, you must reload Cisco Access Registrar to cause the Accounting Services to resume writing to disk.
Note, because Cisco Access Registrar does not buffer the requests it could not write to disk, this information is lost unless the client (NAS or proxy) resends the accounting requests. Fortunately, most NASs retry accounting requests until they are acknowledged.
Some versions of USR NASs do not generate correct signatures for accounting requests. When an accounting request packet has an incorrect signature, Cisco Access Registrar drops the packet. A workaround for this problem is to set the Vendor of the client to be USR-IgnoreAccountingSignatures. This causes Cisco Access Registrar to not attempt to verify that the signature is correct.
1. In Appendix A, page A-7, the method allocMemory should instead be called allocateMemory (like the method declaration).
2. The following items pertain to Appendix D:
a. In the Command Line Utility Section, the /opt/AICar1/bin path should actually be /opt/AICar1/usrbin
b. In the Recovery Section, the /opt/AICar1/ibin/keybuild mcddb command in Step 5 should actually be /opt/AICar1/bin/keybuild mcddb.
This section lists the components of the Cisco Access Registrar 1.5 product:
1. Cisco Access Registrar 1.5 product CD.
2. Release Notes for Cisco Access Registrar, Release 1.5 (part number 78-7189-02 (this document)).
3. Cisco Access Registrar Getting Started Guide (part number 78-6600-01).
4. Cisco Access Registrar User Guide (part number 78-6601-01).
Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.
Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.
CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.
You can access CCO in the following ways:
For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.
If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
You can access the most current Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM is updated monthly. Therefore, it is probably more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.
Registered CCO users can order the Documentation CD-ROM and other Cisco Product documentation through our online Subscription Services at http://www.cisco.com/cgi-bin/subcat/kaojump.cgi.
Nonregistered CCO users can order documentation through a local account representative by calling Cisco's corporate headquarters (California, USA) at 408 526-4000 or, in North America, call 800 553-NETS (6387).
The Cisco Technical Assistance Center (TAC) is available to warranty or maintenance contract customers who need technical assistance with a Cisco product that is under warranty or covered by a maintenance contract.
To display the TAC web site that includes links to technical support information and software upgrades and for requesting TAC support, use www.cisco.com/techsupport.
To contact by e-mail, use one of the following:
Language | E-mail Address |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
In North America, TAC can be reached at 800 553-2447 or 408 526-7209. For other telephone numbers and TAC e-mail addresses worldwide, consult the following web site: http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml.
If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, for your convenience many documents contain a response card behind the front cover. Otherwise, you can mail your comments to the following address:
Cisco Systems, Inc.
Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate and value your comments.
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
Access Registrar, AccessPath, Any to Any, Are You Ready, AtmDirector, Browse with Me, CCDA, CCDE, CCDP, CCIE, CCNA, CCNP, CCSI, CD-PAC, the Cisco logo, Cisco Certified Internetwork Expert logo, CiscoLink, the Cisco Management Connection logo, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Capital, the Cisco Systems Capital logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, the Cisco Technologies logo, Fast Step, FireRunner, Follow Me Browsing, FormShare, GigaStack, IGX, Intelligence in the Optical Core, Internet Quotient, IP/VC, IQ Breakthrough, IQ Expertise, IQ FastTrack, IQ Readiness Scorecard, The IQ Logo, Kernel Proxy, MGX, Natural Network Viewer, NetSonar, Network Registrar, the Networkers logo, Packet, PIX, Point and Click Internetworking, Policy Builder, Precept, RateMUX, ReyMaster, ReyView, ScriptShare, Secure Script, Shop with Me, SlideCast, SMARTnet, SVX, The Cell, TrafficDirector, TransPath, VlanDirector, Voice LAN, Wavelength Router, Workgroup Director, and Workgroup Stack are trademarks; Changing the Way We Work, Live, Play, and Learn, Empowering the Internet Generation, The Internet Economy, and The New Internet Economy are service marks; and Aironet, ASIST, BPX, Catalyst, Cisco, Cisco IOS, the Cisco IOS logo, Cisco Systems, the Cisco Systems logo, the Cisco Systems Cisco Press logo, CollisionFree, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastLink, FastPAD, FastSwitch, GeoTel, IOS, IP/TV, IPX, LightStream, LightSwitch, MICA, NetRanger, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. or its affiliates in the U.S. and certain other countries. All other trademarks mentioned in this document 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. (0005R)
Copyright © 2000, Cisco Systems, Inc.
All rights reserved.
Posted: Wed Aug 23 12:26:34 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.