-
CSS Administration Guide (Software Version 7.10)
-
Index
-
About This Guide
-
Logging In and Getting Started
-
Configuring Interfaces and Circuits
-
Configuring CSS Network Protocols
-
Configuring OSPF
-
Using the CSS Logging Features
-
Configuring User Profiles and CSS Parameters
-
Configuring Simple Network Management Protocol (SNMP)
-
Configuring Remote Monitoring (RMON)
-
Upgrading Your CSS Software
-
Using the Offline Diagnostic Monitor Menu
-
Table Of Contents
Configuring User Profiles and CSS Parameters
Configuring User Terminal Parameters
Configuring Terminal Netmask-Format
Copying and Saving User Profiles
Copying the Running Profile to the Default-Profile
Copying the Running Profile to a User Profile
Copying the Running Profile to an FTP Server
Copying the Running Profile to a TFTP Server
Configuring the CSS as a Client of a RADIUS Server
Configuring the CSS as a RADIUS Client
Specifying a Primary RADIUS Server
Specifying a Secondary RADIUS Server
Configuring the RADIUS Server Timeouts
Configuring the RADIUS Server Retransmits
Configuring the RADIUS Server Dead-Time
Configuring a RADIUS Server for Use With the CSS
Showing RADIUS Server Configuration Information
Configuring the CSS as a Client of a TACACS+ Server
Configuring TACACS+ Server User Accounts for Use with the CSS
Configuring Authentication Settings
Configuring Authorization Settings
Defining a Global Encryption Key
Setting the Global CSS TACACS+ Timeout Period
Showing TACACS+ Server Configuration Information
Controlling Remote Access to the CSS
Configuring Virtual Authentication
Configuring Console Authentication
Configuring Permanent Connections for TCP/UDP Ports
Resetting Fast Ethernet and Gigabit Ethernet Ports
Configuring TCP Maximum Segment Size
Reclaiming Reserved Telnet and FTP Control Ports
Configuring Flow Resource Reclamation
Displaying Flow Timeout Statistics
Displaying Content Rule and Source Group Information
Configuring Global Portmapping
Displaying Global Portmapping Statistics
Configuring Noflow Portmapping
Displaying Noflow Portmapping Statistics
Enabling and Disabling Core Dumps
Controlling Access to the CSS HTTP Server
Publishing the XML Code to the CSS
Testing the Output of the XML Code
Configuring the Command Scheduler
Showing Configured Command Scheduler Records
Configuring User Profiles and CSS Parameters
This chapter describes how to configure user profiles and CSS parameters. This chapter also contains information on using the Content API and Command Scheduler features. Information in this chapter applies to all models of the CSS, except where noted.
This chapter contains the following sections:
•
Configuring the CSS as a Client of a RADIUS Server
•
•
•
•
•
•
Configuring User Profiles
The CSS contains a default-profile that resides in the scripts directory on the CSS disk (hard disk or flash disk). This file contains settings that are user-specific; that is, they apply uniquely to each user when the user logs in.
You can customize the following settings for each user:
•
•
•
•
•
Though the settings are user-specific, each default setting applies to all users until the user saves the default-profile to a username-profile (where username is the current login username). You can continue using the default-profile so that all users logging into a CSS use the same settings. See "Copying and Saving User Profiles" in this chapter for information on saving the default-profile.
If you change a user setting and want to save it in the scripts directory of the current ADI, use the copy profile command. If you do not, the CSS stores the setting temporarily in a running-profile. If you attempt to log out of the CSS without saving profile changes, the CSS prompts you that profile changes have been made and allows you to save or discard the changes.
When you upgrade the ADI, user profiles, which are saved in the current ADI directory, are deleted. If you wish to save user profiles permanently, use the save_profile command. This command saves the profiles in both the scripts and archive directories in the current ADI. The archive directory is not overwritten during a software upgrade.
To access the CSS disk, FTP to the CSS. Use the appropriate commands to access the scripts directory and list the contents of the default-profile. When logged into the CSS, use the show profile command to display either the default-profile or your username-profile.
For example:
# show profile@prompt CSS11503@no expertalias all reboot "@configure;boot;rebo"alias all shutdown "@configure;boot;shutd"alias all logon "@configure;logging line \${LINE};exit"alias all logoff "@configure;no logging line \${LINE};exit"alias all aca-load "@script play service-load"alias all dnslookup "@script play dnslookup"alias super save_config "copy running-config startup-config;archive startup-config"alias super setup "script play setup"alias super upgrade "script play upgrade"alias super monitor "script play monitor"alias super save_profile "copy profile user-profile;archive script admin-profile"set CHECK_STARTUP_ERRORS "1" sessionThis section contains information on:
•
•
Configuring User Terminal Parameters
To configure terminal parameters, use the terminal command. These parameters control output to the system terminal screen. Terminal parameters are user-specific, that is, they apply uniquely to each CSS user.
Use the copy profile user-profile command to add terminal command parameters to your user profile so that the parameters are used each time you log in. Otherwise you must reenter the commands for the parameters to take effect each time you log in.
The options for this command are:
•
•
•
•
•
Configuring Terminal Idle
To set the time a session can be idle before the CSS terminates a console or Telnet session, use the terminal idle command. This command is available at the User and SuperUser prompts. Enter an idle time between 0 and 65535 minutes. The default value is 0 (disabled).
To set a terminal idle time, enter:
# terminal idle 15To restore the terminal idle time to its default of disabled, enter:
# no terminal idleConfiguring Terminal Length
To set the number of output lines the CLI displays on the terminal screen, use the terminal length command. This command is available at the User and SuperUser prompts. Enter the number of lines you want the CLI to display from 2 to 65535. The default is 25 lines.
To set the line number to 35, enter:
# terminal length 35To reset the number of lines to the default of 25 lines, enter:
# no terminal lengthConfiguring Terminal More
To enable support for more terminal functions, use the terminal more command. This command is available at the User and SuperUser prompts. You can also toggle the more function on and off within a session by using the ESC-M key sequence. The default is enabled.
To enable more terminal functions, enter:
# terminal moreTo disable support for more terminal functions, enter:
# no terminal moreConfiguring Terminal Netmask-Format
To determine how the CSS displays subnet masks in show screens, use the terminal netmask-format command. This command is available at the User and SuperUser prompts. The options for this command are:
•
•
•
To display subnet masks in bitcount format, enter:
# terminal netmask-format bitcountTo restore the default display format (decimal), enter:
# no terminal netmask formatConfiguring Terminal Timeout
To set the total amount of time a session can be logged in before the CSS terminates a console or Telnet session, use the terminal timeout command. This command is available at the User and SuperUser prompts. Enter a timeout value between 0 and 65535 minutes. The default value is 0 (disabled).
To set a terminal timeout value, enter:
# terminal timeout 30To restore the terminal timeout value to its default (disabled), enter:
# no terminal timeoutUsing Expert Mode
Expert mode allows you to turn the CSS confirmation capability on or off. Expert mode is available at the SuperUser prompt and is off by default. When expert mode is off, the CSS prompts you for confirmation when you:
•
•
•
Caution
To enable expert mode, enter:
# expertTo allow the CSS to prompt you for confirmation before executing configuration commands, enter:
# no expertFor example, when you enter the command to create an owner and expert mode is off, the CSS prompts you to verify the command, enter:
(config)# owner arrowpoint.comCreate owner <arrowpoint.com>, [y/n]:y(config-owner[arrowpoint.com])#Changing the CLI Prompt
The CLI default prompt displays as the product model number followed by the # symbol. The CSS adds a # sign to the prompt automatically to indicate SuperUser mode. To change the default prompt, enter the prompt command as shown in the following example:
CSS11506# prompt CSS1-labCSS1-lab#You can enter a maximum of 15 characters.
To save the new prompt, add it to your user- or default-profile. To restore the prompt to its default, use the no prompt command.
Modifying the History Buffer
Use the history command to modify the history buffer length. The command line history buffer stores the most recent CLI commands that you enter. Enter the number of lines you want in the history buffer as an integer from 0 to 256. The default is 20. This command is available in SuperUser mode.
To set the history buffer to 80 lines, enter:
# history length 80To disable the history function (setting of 0), enter:
# history length 0To restore the history buffer to the default of 20 lines, enter:
# no history lengthDisplaying the History Buffer
Use the show history command to display the history buffer. The history buffer is cleared automatically upon reboot.
For example:
# show historyhistoryshow historyshow ip routesshow ip summaryshow ip statclockclock dateclock timeshow historyCopying and Saving User Profiles
Use the copy profile command to copy the running profile from the CSS to the default-profile, an FTP server, a TFTP server, or your user-profile. This command is available in SuperUser mode. The options are:
•
•
•
•
Note
See the following sections for information on these options.
Copying the Running Profile to the Default-Profile
Use the copy profile default-profile command to copy the running profile to the default profile. This command is available in SuperUser mode.
For example:
# copy profile default-profileCopying the Running Profile to a User Profile
Use the copy profile user-profile command to copy the changes made to the running profile to the user profile. This command is available in SuperUser mode. This command creates a file username-profile if one does not exist (where username is the current username).
For example:
# copy profile user-profileCopying the Running Profile to an FTP Server
Use the copy profile ftp command to copy the running profile to an FTP server. This command is available in SuperUser mode. The syntax is:
copy profile ftp ftp_record filename
The variables are:
•
•
For example:
# copy profile ftp arrowrecord \records\arrowftprecordCopying the Running Profile to a TFTP Server
Use the copy profile tftp command to copy the running profile to a TFTP server. This command is available in SuperUser mode. The syntax is:
copy profile tftp ip_or_host filenameThe variables are:
•
•
For example:
# copy profile tftp 192.168.3.6 \home\bobo\bobo-profileConfiguring a Login Banner
You can create and display a custom banner that appears after you log in to a CSS. The banner is an ASCII text file that you provide, and it resides in the CSS /script directory. Because this feature is part of your user profile, you can have your own custom banner associated with your login name.
To configure a login banner, use the set BANNER command as follows.
1.
2.
# set BANNER "mybanner" sessionThe keyword session causes the CSS to create the environment variable every time you log in.
3.
# copy profile user-profileThe next time you log in to the CSS, your custom banner will appear.
To provide the same banner for all users, replace the command in Step 3 with:
# copy profile default-profileConfiguring Host Name
Use the host command to manage entries in the Host table. The Host table is the static mapping of mnemonic host names to IP address, analogous to the ARP table. The syntax for this global configuration mode command is:
host host_name ip_address
The variables are:
•
•
For example:
(config)# host CSS11150-LML 192.168.3.6
Note
To remove an existing host from the Host table, enter:
(config)# no host CSS11150-LMLTo display a list of host names, enter:
(config)# show running-config globalConfiguring Idle Timeout
To globally set the total amount of time all sessions can be active before the CSS terminates a console or Telnet session, use the idle timeout command. Enter a timeout value between 0 and 65535 minutes. The default value is enabled for 5 minutes.
Note
Cisco recommends that you configure the idle timeout for at least 30 minutes. Setting this value to 30 minutes:
•
•
To set an idle timeout value, enter:
(config)# idle timeout 15To restore the terminal timeout value to its default of enabled for 5 minutes, enter:
(config)# no idle timeoutConfiguring the CSS as a Client of a RADIUS Server
The Remote Authentication Dial-In User Server (RADIUS) protocol is a distributed client/server protocol that protects networks against unauthorized access. It uses the User Datagram Protocol (UDP) to exchange authentication and configuration information between the CSS authentication client and the active authentication server that contains all user authentication and network service access information. The RADIUS host is normally a multiuser system running RADIUS server software.
Use the radius-server command to configure the CSS as a client of a RADIUS server for authentication requests by remote or local users who require authorization to access network resources.
When a user remotely logs into a CSS operating as a RADIUS client, the CSS sends an authentication request (including user name, encrypted password, client IP address, and port ID) to the central RADIUS server. The RADIUS server is responsible for receiving user connection requests, authenticating users, and returning all configuration information necessary for the client to deliver services to the users. Transactions between the RADIUS client and the RADIUS server are authenticated through the use of a shared secret.
Once the RADIUS server receives the authentication request, it validates the sending client and consults a database of users to match the login request. After the RADIUS server performs user authentication, it transmits one of the following authentication responses back to the RADIUS client:
•
•
If no response is returned by the RADIUS server within a period of time, the authentication request is retransmitted a predefined number of times (both options are specified in the radius-server command). The RADIUS client can forward requests to an alternate secondary RADIUS server in the event that the primary server is down or is unreachable.
In a configuration where both a primary RADIUS server and a secondary RADIUS server are specified, and one or both of the RADIUS servers become unreachable, the CSS automatically transmits a keepalive authentication request to query the server(s). The CSS transmits the username "query" and the password "areyouup" to the RADIUS server (encrypted with the RADIUS server's key) to determine its state. The CSS continues to send this keepalive authentication request until the RADIUS server indicates that it is available.
Configuring the CSS as a RADIUS Client
Note
Use the radius-server command and its options to specify the RADIUS server host (primary RADIUS server, and, optionally, a secondary RADIUS Server), communication time interval settings, and a shared secret text string. This command is available in global configuration mode. The options for this command are:
•
•
•
•
•
Note
Specifying a Primary RADIUS Server
Use the radius-server primary command to specify a primary RADIUS server to authenticate user information from the CSS RADIUS client (console or virtual authentication). The syntax for this global configuration mode command is:
radius-server primary ip_address secret string {auth-port port_number}
Options and variables include:
•
•
•
To specify a primary RADIUS server, enter:
(config)# radius-server primary 172.27.56.76 secret Hello auth-port 30658To remove a primary RADIUS server, enter:
(config)# no radius-server primarySpecifying a Secondary RADIUS Server
Use the radius-server secondary command to specify a secondary RADIUS server to authenticate user information from the CSS RADIUS client (console or virtual authentication). The CSS directs authentication requests to the secondary RADIUS server when the specified RADIUS primary server is unavailable. The syntax for this global configuration mode command is:
radius-server secondary ip_address secret string {auth-port port_number}
Note
Options and variables include:
•
•
•
To specify a secondary RADIUS server, enter:
(config)# radius-server secondary 172.27.56.79 secret Hello auth-port 30658To remove a secondary RADIUS server, enter:
(config)# no radius-server secondaryConfiguring the RADIUS Server Timeouts
Use the radius-server timeout command to specify the time interval that the CSS waits for the RADIUS server (primary or secondary) to reply to an authentication request before retransmitting requests to the RADIUS server. You configure the number of retransmitted requests to the server through the radius-server retransmit command. Valid entries are 1 to 255 seconds. The default is 10 seconds.
To configure the configure the RADIUS server timeout interval to 1 minute (60 seconds), enter:
(config)# radius-server timeout 60To reset the RADIUS server retransmit request to the default of 10 seconds, enter:
(config)# no radius-server timeoutConfiguring the RADIUS Server Retransmits
Use the radius-server retransmit command to specify the number of times the CSS retransmits an authentication request to a timed-out RADIUS server before considering the server dead and stopping transmission. If a secondary RADIUS server has been identified, that server is selected as the active server. Valid entries are 1 to 30 retries. The default is 3 retransmits.
If the RADIUS server does not respond to the CSS retransmitted requests, the CSS considers the server as dead, stops transmitting to the server, and starts the dead timer as defined through the radius-server dead-time command. If a secondary server is configured, the CSS transmits the requests to the secondary server. If the secondary server does not respond to the request, the CSS considers it dead and starts the dead timer. If there is no active server, the CSS stops transmitting requests until the primary RADIUS server becomes alive.
To configure the number of RADIUS server retransmits to 5, enter:
(config)# radius-server retransmit 5To reset the RADIUS server retransmit request to the default of 3 retransmits, enter:
(config)# no radius-server retransmitConfiguring the RADIUS Server Dead-Time
Use the radius-server dead-time command to set the time interval in which the CSS verifies whether a non-responsive server is operational. During the set time interval, the CSS sends probe access-request packets to verify that the RADIUS server (primary or secondary) is available and can receive authentication requests. The dead-time interval starts when the server does not respond to the number of authentication request transmissions configured through the radius-server retransmit command. When the server responds to a probe access-request packet, the CSS transmits the authentication request to the server. Valid entries are 1 to 255 seconds. The default is 5 seconds.
To configure the RADIUS server dead-time to 15 seconds, with probe access-requests enabled, enter:
(config)# radius-server dead-time 15To reset the RADIUS server dead-time request to the default of 5 seconds, enter:
(config)# no radius-server dead-timeConfiguring a RADIUS Server for Use With the CSS
This section provides background information on the setup of a RADIUS server. It is intended as a guide to help ensure proper communication with a RADIUS server and a CSS operating as a RADIUS client.
The following example summarizes the recommended settings for the Cisco Secure Access Control Server (ACS) when used as a centralized RADIUS server with the CSS:
•
–
–
–
Note
–
•
–
–
•
–
–
•
•
•
Showing RADIUS Server Configuration Information
Use the show radius command to display information and statistics about the RADIUS server configuration. The syntax and options are:
•
•
To view the configuration for a RADIUS primary server, enter:
(config)# show radius config primaryTo view the authentication statistics for a RADIUS secondary server, enter:
(config)# show radius stats secondaryTable 6-1 describes the fields in the show radius config output.
Table 6-2 describes the fields in the show radius stat output.
Configuring the CSS as a Client of a TACACS+ Server
The Terminal Access Controller Access Control System (TACACS+) protocol provides access control for routers, network access servers (NAS) or other devices through one or more daemon servers. It encrypts all traffic between the NAS and daemon using TCP communications for reliable delivery.
You can configure the CSS as a client of a TACACS+ server, providing a method for authentication of users, and authorization and accounting of configuration and non-configuration commands. The following sections provide information on:
•
•
•
•
•
After you configure the TACACS+ server on the CSS, configure TACACS+ authentication for virtual or console authentication. See "Controlling Remote Access to the CSS".
Configuring TACACS+ Server User Accounts for Use with the CSS
This section provides background information on the setup of a TACACS+ server. It is intended as a guide to help ensure proper communication with a TACACS+ server and a CSS operating as a TACACS+ client.
The following sections summarizes the following recommended Cisco Secure Access Control Server (ACS) TACACS+ user authentication and authorization settings.
Configuring Authentication Settings
To configure the authentication settings on Cisco Secure ACS, go to the Network Configuration section of the Cisco Secure ACS HTML interface, the Add AAA Client page, and complete the following fields:
•
•
•
•
Configuring Authorization Settings
To determine the privilege level of users accessing the CSS, you must configure the user accounts on the TACACS+ server to permit or deny execution of the privilege command. The CSS queries the TACACS+ server for authorization to execute the privilege command. If the server allows the privilege command, the user is granted privileged (SuperUser and configuration mode) access to the CSS. If the server denies the privilege command, the user is granted non-privileged (User mode) access to the CSS.
To configure the group authorization settings:
1.
2.
3.
•
•
An alternative way to configure the group authorization settings is as follows:
1.
2.
3.
4.
•
•
5.
6.
7.
To add a user to a group, go to the User Setup section of the Cisco Secure ACS HTML interface:
•
•
–
–
–
Defining a TACACS+ Server
The TACACS+ server contains the TACACS+ authentication, authorization, and accounting databases. You can designate a maximum of three servers on the CSS. However, the CSS uses only one server at a time. The CSS selects the server based upon availability, giving preference to the configured primary server. The CSS sends periodic TCP keepalive probes at a frequency of every five seconds to the TACACS+ server to determine its operational state: Alive, Dying, or Dead. The TCP keepalive frequency is not user-configurable in the CSS.
Note
To apply a TACACS+ global attribute, such as the timeout period or shared secret, to a TACACS+ server, you must configure the global attribute before you configure the server. To apply a modified global attribute to a configured CSS TACACS+ server, remove the server and reconfigure it.
To define a server, use the tacacs-server command. You must provide the IP address and port number for the server. You can optionally define the timeout period and encryption key, and designate the server as the primary server.
The syntax for this global configuration command is:
tacacs-server ip_address port {timeout ["cleartext_key"|des_key]} {primary}
The variables and options are:
•
•
•
Note
•
The shared secret value is identical to the one on the TACACS+ server. The shared secret key can be either clear text entered in quotes or the DES-encrypted secret entered without quotes. The clear text key is DES-encrypted before it is placed in the running configuration. Either key type can have a maximum of 100 characters.
Defining this option overrides the tacacs-server key command. For more information on defining a global encryption key, see "Defining a Global Encryption Key" in this chapter.
•
For example, to define a primary TACACS+ server at IP address 192.168.11.1 with a default port of 49, a timeout period of 12 seconds, and a clear text shared secret of summary, enter:
#(config) tacacs-server 192.168.11.1 12 "summary" primary
Note
To delete a TACACS+ server at IP address 23.43.23.12 with a default port of 49, enter:
#(config) no tacacs-server 192.168.11.1 49
Note
After configuring the TACACS+ server, enable TACACS+ authentication for console and virtual logins (if the user and password pair is not in the local user database) through the virtual authentication and console authentication commands. See "Controlling Remote Access to the CSS".
Defining a Global Encryption Key
The CSS allows you to define a global encryption key for communications with all configured TACACS+ servers. To encrypt TACACS+ packet transactions between the CSS and the TACACS+ server, you must define an encryption key. If you do not define an encryption key, packets are not encrypted. The key is a shared secret value that is identical to the one on the TACACS+ server. To specify a shared secret between the CSS and the server, use the tacacs-server key command.
Note
The shared secret key can be either clear text entered in quotes or the DES-encrypted secret. The clear text key is DES encrypted before it is placed in the running configuration. Either key types can have a maximum of 100 characters.
For example, to define the clear text key, enter:
#(config) tacacs-server key "market"To define a DES encrypted key, enter:
#(config) tacacs-server key acskefterefesdtxTo remove the key, enter:
#(config) no tacacs-server keySetting the Global CSS TACACS+ Timeout Period
The CSS allows you to define a global TACACS+ timeout period for use with all configured TACACS+ servers. To determine the availability of the TACACS+ servers, the CSS sends periodic TCP keepalive probes to them. If the server does not respond to the probe within the timeout period, the CSS considers the server unavailable.
If the CSS attempts to contact the server and does not receive a response within the defined timeout value, it will use another server. The next configured server is contacted and the process repeated. If a second (or third) TACACS+ server has been identified, that server is selected as the active server.
If the CSS cannot reach all three TACACS+ servers, users will not be authenticated and cannot log into the CSS unless TACACS+ is used in combination with a RADIUS or local server, as defined through the virtual command or the console command. See the "Controlling Remote Access to the CSS" in this chapter.
By default, the global timeout period is 5 seconds. To change the timeout period, use the tacacs-server timeout command. Enter a number from 1 to 255.
Note
For example, to set the timeout period to 60 seconds, enter:
#(config) tacacs-server timeout 60To reset the timeout period to its default of 5 seconds, enter:
#(config) no tacacs-server timeoutSetting TACACS+ Authorization
TACACS+ authorization allows the TACACS+ server to control specific CSS commands that the user can execute. CSS authorization divides the command set into two categories:
•
•
By default, authorization is disabled. When authorization is enabled, the TACACS+ server is responsible for granting permission or denying all attempts to issue commands.
Note
Failure of the TACACS+ server results in the failure of all authorization requests and the suspension of user activity unless another server is reachable. To enable users to execute commands in this case, configure a failover authentication method to a local user database. Users will need to log back into the CSS.To enable authorization of all commands that change the running configuration, use the tacacs-server authorize config command. For example:
#(config) tacacs-server authorize configTo enable authorization of all commands that do not change the running configuration, use the tacacs-server authorize non-config command. For example:
#(config) tacacs-server authorize non-configTo disable authorization, use the no form of these commands. For example, to disable authorization for commands that affect the running configuration, enter:
#(config) no tacacs-server authorize configTo disable authorization for commands that do not affect the running configuration, enter:
#(config) no tacacs-server authorize non-configSetting TACACS+ Accounting
TACACS+ accounting allows the TACACS+ server to receive an accounting report for commands that the user can execute. CSS accounting divides the command set into two categories:
•
•
By default, the CSS disables accounting. When you enable accounting, you can account for configuration commands, non-configuration commands, or both.
Note
To enable the TACACS+ server to receive accounting reports for all commands that change the running configuration, use the tacacs-server account config command. For example:
#(config) tacacs-server account configTo enable the TACACS+ server to receive accounting reports for all commands that do not change the running configuration, use the tacacs-server account non-config command. For example:
#(config) tacacs-server account non-configTo disable accounting, use the no form of these commands. For example, to disable accounting for commands that affect the running configuration, enter:
#(config) no tacacs-server account configTo disable accounting for commands that do not affect the running configuration, enter:
#(config) no tacacs-server account non-configShowing TACACS+ Server Configuration Information
Use the show tacacs-server command to display the TACACS+ server configuration information. To view this information, enter:
(config)# show tacacs-serverTable 6-3 describes the fields in the show tacacs-server output.
Controlling Remote Access to the CSS
To control access to the CSS, you can configure the CSS to authenticate remote (virtual) or console users. The CSS can authenticate users by using the local user database, RADIUS server, or TACACS+ server. You can also allow user access without authenticating or disallowing all remote user access to the CSS.
You can set a maximum of three authentication methods: a primary, secondary, or tertiary authentication method. The primary method is the first authentication method that the CSS tries. If the primary authentication method fails, the CSS tries the secondary method. And if the secondary method fails, then the CSS tries the tertiary method. In the event that the tertiary method also fails, the CSS displays a message that authentication has failed.
The following sections provide information on:
•
•
Note
To display virtual and console authentication settings, use the show user-database command (refer to Chapter 1, Logging In and Getting Started, "Showing User Information").
Configuring Virtual Authentication
Virtual authentication allows remote users to log in to the CSS when they are using FTP, Telnet, SSHD, or the Device Management user interface with or without requiring a username and password. The CSS can also deny access to all remote users.
You can configure the CSS to authenticate users by using the local database, RADIUS server, or TACACS+ server. By default, the CSS uses the local database as the primary method to authenticate users, and disallows user access for the secondary and tertiary method.
To configure the primary, secondary, or tertiary virtual authentication method, use the virtual authentication command. The syntax for this global configuration command is:
virtual authentication [primary|secondary|tertiary [local|radius|tacacs|disallowed]]
The options are:
•
•
Note
•
•
•
•
•
Note
To define the TACACS+ server as the primary virtual authentication method, enter:
#(config) virtual authentication primary tacacsTo define local user database as the secondary virtual authentication method, enter:
#(config) virtual authentication secondary localConfiguring Console Authentication
Console authentication allows users to log into the CSS through a terminal connected to the console port with or without requiring a username and password. The CSS cannot disallow user access as a primary authentication method, however, it can disallow user access as a secondary or tertiary authentication method.
You can configure the CSS to authenticate users by using the local database, RADIUS server, or TACACS+ server. By default, the CSS uses the local database as the primary method to authenticate users, and disallows user access for the secondary and tertiary method.
To configure the primary, secondary, or tertiary console authentication method, use the console authentication command. The syntax for this global configuration command is:
console authentication [primary [local|radius|tacacs|none]
|secondary|tertiary [local|radius|tacacs|none|disallowed]]The options are:
•
•
Note
•
•
•
•
•
•
Note
To define the TACACS+ server as the primary console authentication method, enter:
#(config) console authentication primary tacacsTo define local user database as the secondary console authentication method, enter:
#(config) console authentication secondary localTo disable authentication on the console port allowing users to access the CSS without a username and password, enter:
#(config) no console authenticationRestricting Access to the CSS
Use the restrict command to enable or disable console, FTP, SNMP, SSH, Telnet, user database, XML, and Web management data transfer to the CSS. CSS access through a console, FTP, SSHD, SNMP, and Telnet is enabled by default.
Entering the restrict command does not prevent the CSS from listening for connection attempts on the restricted port. For TCP connections, the CSS completes the TCP 3-way handshake, then terminates the connection with an error to prevent any data transfer from occurring. For UDP SNMP connections, the CSS simply discards the packets.
To secure restricted ports from unauthorized access, configure ACL clauses to deny packets destined to these ports, while permitting normal traffic to flow through the CSS. You can also use ACLs to secure the CSS itself. For more information, refer to the Cisco Content Services Switch Basic Configuration Guide.
Note
The syntax and options for this global configuration mode command are:
•
•
•
•
•
•
•
•
To enable access to the CSS:
•
•
•
•
•
•
•
•
For example:
(config)# restrict telnetFinding an IP Address
Use the find ip address command to search the CSS configuration for the specified IP address. You can include a netmask for subnet (wildcard) searches. This search can help you avoid IP address conflicts when you configure the CSS.
When you use this command, it checks services, source groups, content rules, ACLs, the management port, syslog, APP sessions, and local interfaces for the specified IP address. If the address is found, the locations of its use are displayed. If no addresses are found, the CSS returns you to the command prompt.
This command is available in all modes. The syntax is:
find ip address ip_or_host {subnet_mask|range number}
The options and variables for this command are:
•
•
–
–
If you enter a mask of 0.0.0.0, the CSS finds all addresses.
•
For example, if you enter an IP address of 203.1.1.1 with a range of 10, the CSS tries to find the addresses from 203.1.1.1 through 203.1.1.10.
For example:
(config)# find ip address 192.168.0.0Users of IP address 192.168.0.0Content Rule - 192.168.12.1, layer 3, owner: lml, state:ActiveContent Rule - 192.168.12.1, layer 5, owner: lml, state:ActiveService - 192.168.3.6, serv1, state:ActiveService - 192.168.3.7, serv3, state:ActiveInterface - 192.168.1.117. VLAN1Interface - 192.168.2.117. VLAN1Configuring Flow Parameters
The CSS enables you to configure the following flow parameters for the CSS using the flow command:
•
•
•
•
•
Note
Configuring Permanent Connections for TCP/UDP Ports
The CSS allows you to configure a maximum of 10 TCP/UDP ports that will have permanent connections and will not be reclaimed by the CSS when the flows are inactive. To configure a TCP/UDP port as a permanent connection, use the flow permanent command. This command is typically used when you are load-balancing long-lived connections or you observe the CSS dropping long-lived idle TCP connections.
Enter a port number from 0 to 65535. The default is 0.
Note
The options for this command are:
•
•
•
•
•
•
•
•
•
•
To configure port 1520 as a permanent connection, enter:
(config) flow permanent port1 1520To reset a permanent connection to its default port number of 0, use the no flow permanent command. To reset the port number for port1 to 0, enter:
(config) no flow permanent port1Resetting Fast Ethernet and Gigabit Ethernet Ports
You can configure a CSS to reset its Fast Ethernet and Gigabit Ethernet ports automatically when it detects that they are not responding during operation. Use the flow port-resets command to enable this function. By default, port resetting is enabled on a CSS.
Caution
For example:
(config)# flow port-resetsTo disable port resets on the CSS, enter:
(config)# no flow port-resetsConfiguring TCP Maximum Segment Size
Use the flow tcp-mss command to configure the TCP maximum segment size (MSS) that the CSS expects to receive from the transmitting device. The MSS is the largest amount of TCP data that can be transmitted in one segment. The flow tcp-mss command changes the MSS value in the TCP header OPTIONS field of a SYN segment. You can use the flow tcp-mss command to reduce the MSS from the default value of 1460 bytes. The need for a smaller MSS between devices may be necessary in rare instances due to network restrictions between devices.
Note
Enter a maximum segment size (in bytes) from 1 to 1460. The default is 1460 bytes. Use the no form of the command to reset the TCP maximum segment size back to the default value of 1460 bytes.
Caution
To configure a TCP maximum segment size of 1400 bytes, enter:
(config)# flow tcp-mss 1400To reset the TCP maximum segment size to the default value of 1460 bytes, enter:
(config)# no flow tcp-mssReclaiming Reserved Telnet and FTP Control Ports
Use the flow reserve-clean command in global configuration mode to define how often the CSS scans flows from reserved Telnet and FTP control ports to reclaim them. Control ports have port numbers less than or equal to 23. When the CSS determines that one of these ports has a flow with asymmetrical routing, it reclaims the port.
Enter the flow reserve-clean time in seconds as the interval the CSS uses to scan flows. Enter an integer from 0 to 100. The default is 10. To disable the flow reclaiming process, enter a flow reserve-clean value of 0.
For example:
(config)# flow reserve-clean 36To disable flow cleanup on Telnet and FTP control ports, enter:
(config)# no flow reserve-cleanShowing Flow Statistics
Use the flow statistics command to display statistics on currently allocated flows.
For example:
(config)# flow statisticsFlow Manager Statistics:Current High AvgUDP Flows per second 0 0 0TCP Flows per second 0 4 0Total Flows per second 0 4 0Hits per second 0 0 0-------------------------------------------------------------Port Active Total TCP UDP-------------------------------------------------------------1 13 43339169 13 02 16 43337519 16 05 18 3167362 18 06 9 33483528 9 0Configuring Flow Resource Reclamation
Use this feature to configure flow inactivity timeout values for TCP and UDP flows on a per rule and per source group basis. Note that this timeout value is not the frequency with which a CSS reclaims flow resources, but the time period that must elapse for an idle flow before the CSS marks the flow for cleanup.
To set up and keep track of flows, a CSS uses data structures called flow control blocks (FCBs). For optimal performance, the CSS reuses FCBs that are no longer needed by flows. Flow resource reclamation involves removing FCBs from the TCP and UDP lists.
Normally, flow cleanup occurs at a rate that is directly related to the overall number of flows that are currently active on a CSS. A CSS always cleans up UDP flows. For TCP flows, a CSS reclaims resources when the number of used FCBs reaches a certain percentage of the total FCBs. A CSS also cleans up long-lived TCP flows that have received a FIN or a RST, or whose timeout values have been met.
Timeout Value Precedence
The CSS uses the following guidelines in the order presented when reclaiming flow resources:
1.
2.
3.
4.
Configuring Flow Timeouts
To specify the number of seconds for which an idle flow can exist before the CSS tears it down, use the flow-timeout-multiplier command in owner-content or group configuration mode.
The syntax for this command is:
flow-timeout-multiplier number
Enter an integer for the number variable from 0 to 65533. The CSS multiplies the value you specify by 16 to calculate the flow timeout in seconds. The default value depends on the TCP or UDP port number (see the show flow-timeout default command description later in this chapter). This default value applies only to flows that are created under a content rule or source group.
A value of zero (no timeout) instructs the CSS to never tear down the flow, resulting in a permanent flow and lost resources. This is equivalent to entering the flow permanent port command (see "Configuring Permanent Connections for TCP/UDP Ports" in this chapter).
These examples show flow timeout periods of 80 seconds:
(config-owner-content[cisco-rule1])# flow-timeout-multiplier 5(config-group[group1])# flow-timeout-multiplier 5To disable the configured flow-timeout-multiplier value and restore the default timeout for the port type, enter:
(config-owner-content[cisco-rule1])# no flow-timeout(config-group[group1])# no flow-timeoutDisplaying Flow Timeout Statistics
Use the show flow-timeout default command to display the default timeout values for TCP and UDP ports and applications. The default values are not user configurable.
Table 6-4 shows the fields in the show flow-timeout default output.
Use the show flow-timeout configured command to display the configured flow timeout values. The command output includes the content rule or source group for which you configured the flow timeout value.
Table 6-5 describes the fields in the show flow-timeout configured output.
Displaying Content Rule and Source Group Information
If you configure a flow timeout value in a content rule or a source group, the show rule or show group command output will have an additional field called Flow Timeout Multiplier. This field contains the configured timeout value assigned to flows that match on the rule or group.
For details on the show rule command, refer to the Cisco Content Services Switch Basic Configuration Guide, Chapter 3, Configuring Content Rules. For details on the show group command, refer to the Cisco Content Services Switch Basic Configuration Guide, Chapter 5, Configuring Source Groups, ACLs, EQLs, URQLs, NQLs, and DQLs.
Configuring CSS Portmapping
The following sections describe how to globally control the range of port numbers a CSS uses when it translates (portmaps) TCP and UDP source port numbers specified in packets sent from clients. A CSS assigns unique port numbers within a configurable range for the source port numbers specified in the packets, then sends the packets to the appropriate server port. When a server initiates a return flow, the packets flow through the CSS. The CSS matches the translated port number with the client who initiated the request and sends the server packets to the appropriate client.
Each CSS maintains a database of used and available portmap numbers. When a CSS needs to portmap a source port, it uses the next unused port number in its database.
For information on portmapping with source groups, refer to Cisco Content Services Switch Basic Configuration Guide, Chapter 5, Configuring Source Groups, ACLs, EQLs, URQLs, NQLs, and DQLs.
Configuring Global Portmapping
The global portmapper in a CSS is called the megaportmapper. The megaportmapper database comprises 16 banks of portmap numbers (megamap banks) in each session processor (SP) with unique ranges. A CSS uses a source port hash algorithm to select a megamap bank.
Use the global-portmap command to control the global source-port translation (portmapping) for TCP flows on a CSS. This command is always enabled. You can use this command to specify the source-port mapping range on:
•
•
•
Note
The syntax for this global configuration mode command is:
global-portmap base-port number1 range number2
The options and variables for this command are:
•
•
Note
For example:
(config)# global-portmap base-port 3096 range 42308To return the global-portmap command parameters to their default values, enter:
(config)# no global-portmapDisplaying Global Portmapping Statistics
Use the show global-portmap command to display statistics for global portmapping on a CSS. This command is available in all modes except RMON, URQL, and VLAN configuration modes.
The syntax for this command is:
show global-portmap [all-banks [all-sps|slot number1]|number2 [all-sps|slot number1]]
The options and variables for this command are:
•
•
•
To display the available active slots in the CSS, enter the show global-portmap all-banks slot ? command. If you enter an invalid slot number, the CLI displays values for only the first two parameters listed in Table 6-6.
•
To display portmapping statistics for all megamap banks (up to 16) on every active SP in the CSS, enter:
(config)# show global-portmap all-banks all-spsTo display global portmapping statistics for megamap bank 12 in the SP that resides in slot 3, enter:
(config)# show global-portmap 12 slot 3Table 6-6 describes the fields in the show global-portmap output.
Configuring Noflow Portmapping
Use the noflow-portmap command to control the port translation (portmapping) range of DNS UDP source-port numbers greater than 1023 on a CSS. This command is always enabled. However, before a CSS can use this command, you must enter the dnsflow disable command to disable DNS flows on the CSS. For details on the dnsflow command, refer to Chapter 3, Configuring CSS Network Protocols, "Specifying UDP Traffic on the DNS Server Port".
Note
The syntax for this global configuration mode command is:
noflow-portmap base-port number1 range number2
The options and variables for this command are:
•
•
Note
For example:
(config)# noflow-portmap base-port 4317 range 35421To reset the starting port number and portmap range to their default values, enter:
(config)# no noflow-portmapDisplaying Noflow Portmapping Statistics
Use the show noflow-portmap command to display statistics for noflow portmapping on a CSS. This command is available in all modes except RMON, URQL, and VLAN configuration modes.
The syntax for this command is:
show noflow-portmap [all-sps|slot number]
The options and variables for this command are:
•
•
Note
For example:
(config)# show noflow-portmap slot 3Table 6-7 describes the fields in the show noflow-portmap output.
Enabling and Disabling Core Dumps
A core dump occurs when the CSS experiences a fatal error. The CSS allows you to enable or disable core dumps. Core dumps are enabled by default.
When the CSS experiences a fatal error and core dumps are enabled, the CSS:
•
–
–
•
Note
When the CSS experiences a fatal error and core dumps are disabled, the CSS reboots automatically. The CSS does not write information to the hard disk or the flash disk.
Note
To disable core dumps, enter:
(config)# dump disableTo reenable core dumps (the default setting), enter:
(config)# dump enableDisplaying Core Dumps
Use the show core command to display the core dump files stored in the Core directory of the volume root (for example, c:\core) on the hard disk or flash disk. This command is available in all mode except for User mode.
Use the show core disk_slot command to display the core dump files stored in the Core directory of the volume root of a specific disk in the CSS 11501, CSS 11503, or CSS 11506. Valid selections are 0 (for the disk in slot 0) or 1 (for the disk in slot 1).
For example:
# show coreSCP0101_4.80_115... OCT 31 15:06:26 16708412SCP0101_4.80_109... OCT 29 16:56:16 37806459SCP0101_4.80_116... NOV 1 15:54:28 38403870Configuring Content API
The CSS Content Application Program Interface (API) feature allows you to use a network management workstation to make Web-based configuration changes to the CSS using Extensible Markup Language (XML) documents. XML is a powerful tool that can be used to automatically configure a CSS using all of the CLI commands included in the CSS software, such as to specify server weight and load, to configure load balancing across a group of servers, or to configure content rules to restrict access to a group of directories or files on the servers.
XML code loads a series of CLI commands into the CSS without the need to respond to the prompts, similar to operating in expert mode. As the CSS administrator, plan which type of changes you want to implement and the consequences of these changes as they are performed.
After you create the XML document, you publish (upload) the XML file to the Hypertext Transfer Protocol (HTTP) server embedded in the CSS using an HTTP PUT method.
Creating XML Code
When developing XML code for the Content API to issue CLI commands, adhere to the following guidelines. You can use any text editor for creating the XML code.
1.
<?xml version="1.0" standalone="yes"?>2.
<action>add service MyServiceName</action><action>vip address 10.2.3.4</action>
Note
3.
–
–
–
4.
As an example, the following commands configure an access control list (ACL):
<?xml version="1.0" standalone="yes" ?><config><action>acl 98</action><action>clause 10 permit any any dest any</action><action>apply circuit-(VLAN3)</action></config>In another example, the following commands configure a CSS Ethernet interface:
<?xml version="1.0" standalone="yes" ?><config><action>interface ethernet-6</action><action>bridge vlan 3</action><action>circuit VLAN3</action><action>ip address 10.10.104.1/16</action></config>5.
Note
XML Document Example
The following example is a complete XML document. The XML document creates three services, an owner, and a content rule, and assigns one of the newly created services to the content rule.
<?xml version="1.0" standalone="yes"?><config><service name="router"><ip_address>10.0.3.1</ip_address><action>active</action></service><service name="sname2"><ip_address>10.0.3.2</ip_address><weight>4</weight><action>active</action></service><service name="sname3"><ip_address>10.0.3.3</ip_address><weight>5</weight><protocol>udp</protocol><action>suspend</action></service><service name="nick"><ip_address>10.0.3.93</ip_address><action>active</action></service><owner name="test"><content name="rule"><vip_address>10.0.3.100</vip_address><protocol>udp</protocol><port>8080</port><add_service>nick</add_service><action>active</action></content></owner></config>Controlling Access to the CSS HTTP Server
To control access to the HTTP server running on the CSS, use the restrict xml and no restrict xml commands. Clients can send XML documents to this server to configure the CSS. The options for this global configuration mode command are:
•
•
Parsing the XML Code
After you complete the XML file, parse the code to ensure that it is syntactically correct. The easiest way to parse XML code is to open the XML file directly from Microsoft® Internet Explorer. Syntax errors are flagged automatically when the file is loaded. If an error occurs, review your XML code and correct all syntax errors.
Publishing the XML Code to the CSS
The completed XML file is remotely published (uploaded) to the HTTP server in the CSS from the external network management workstation by using a HTTP PUT method. The HTTP PUT method uses the IP address of the CSS as the destination URL where you want to publish the XML file.
Note
When you publish XML files to the HTTP server in the CSS, the CSS requires a valid username and password as part of the user authentication process. The username must have SuperUser privileges to be able to add XML files to the CSS.
Note
Software is available to simplify the process of publishing XML files to the CSS HTTP server. These software packages offer a simple method to publish files to a Web server. This software uses the HTTP protocol to publish files and require no special software on the Web server side of the connection.
Note
Testing the Output of the XML Code
Test the output of the XML code by reviewing the running configuration of the CSS. After the XML has been successfully published to the CSS, Telnet to the switch and enter the show running-config command to verify that the XML changes have properly occurred. If the XML changes are incorrect or missing, republish the XML code to the CSS as described in the "Publishing the XML Code to the CSS" section.
Configuring the Command Scheduler
Use the cmd-sched command to configure the scheduled execution of any CLI commands, including playing scripts. The commands that will be executed are referred to as the command string. To schedule commands, you must create a configuration record, which includes a provision about when to execute the commands, and the command string.
For example, you can use this command to schedule periodic content replication, the gathering of statistics, and scheduled configuration changes. At the specified time, the command scheduler executes a command string by creating a pseudo-login shell where each string is executed. A cmd-sched record is scheduled for execution only upon completion of its shell. Use the show lines command to display information about active pseudo shells (refer to Chapter 1, Logging In and Getting Started, "Showing Current Logins").
Note
The syntax and options for this global configuration mode command are:
•
•
The variables are listed below. When entering minute, hour, day, month, and weekday variables, you may enter a single integer, a wildcard (*), a list separated by commas, or a range separated by a dash (-).
•
•
•
•
•
•
•
•
Any of the time variables can contain one or some combination of the following values:
•
•
•
•
For example:
(config)# cmd-sched record periodic_shows 30 21 3 6 1 "show history;show service;show rule;show system-resources"To enable command scheduler, enter:
(config)# cmd-schedTo disable command scheduling, enter:
(config)# no cmd-schedTo delete a configuration record, enter:
(config)# no cmd-sched periodic_showsShowing Configured Command Scheduler Records
Use the show cmd-sched command to display the state of the command scheduler and information about the records for the scheduled CLI commands. The syntax and options are:
•
•
To view the command scheduler state and all scheduled CLI command records, enter:
(config)# show cmd-schedCmd Scheduler: Enabled 1 record currently configured.Sched Rec: suspendRule id: 8265b980 Next exec: APR 14 10:46:00 executions:1145minList: 0hourList: 12dayList: *monthList: *weekdayList: 2,3,4,5,6cmd: config;owner owner1;content content1;suspendTable 6-8 describes the fields in the show cmd-sched output.
Where to Go Next
Chapter 7, Configuring Simple Network Management Protocol (SNMP), describes how to configure SNMP on the CSS.
