|
|
This chapter describes the basic tasks that you can perform to manage the general system features of the Cisco IOS software--those features that are generally not specific to a particular protocol. Cisco's system management features are supported through the Simple Network Management Protocol (SNMP). Cisco supports the SNMP Version 1 protocol, referred to as SNMPv1, and the SNMP Version 2 protocol, referred to as SNMPv2. This chapter describes the tasks needed to configure SNMP support on Cisco routers. A part of SNMP is the Management Information Base (MIB). MIBs provide variables that can be set or read to change parameters or provide information on network devices and interfaces. Cisco supports several MIBs, including the Internet standard MIB II, and also provides its own Cisco MIB. For information on the Cisco MIB, see the Cisco Management Information Base (MIB) User Quick Reference.
Cisco Systems also provides CiscoWorks, a feature-rich network management application suite that is integrated with Sun Microsystems' SunNet Manager product running on a Sun SPARCstation platform. CiscoWorks provides a menu-driven graphical user interface and supports all five areas of network management. (See the next section, "Understanding System Management," for details.) With CiscoWorks, you can create network maps and set up automated network performance monitors and fault tests, such as pinpointing connectivity problems. Test results can be displayed in several graph formats. Refer to CiscoWorks online help for information on how to use CiscoWorks on a Sun SPARCstation. See the CiscoWorks Installation and Reference Guide for installation and reference information.
In addition to CiscoWorks for the Sun SPARCstation platform, Cisco Systems provides CiscoWorks for Windows. CiscoWorks for Windows incorporates the features of the Cisco Configuration Builder, which was based on an MS-Windows graphical user interface. CiscoWorks for Windows replaces the Cisco Configuration Builder, previously provided for configuring Cisco routers. For information on how to use CiscoWorks for Windows, refer to the online help provided with the product and the CiscoWorks for Windows Getting Started Guide.
For a list of recommended books on network management, refer to the appendix "References and Recommended Reading" in the Configuration Fundamentals Command Reference.
For a complete description of the commands mentioned in this chapter, refer to the "System Management Commands" chapter of the Configuration Fundamentals Command Reference.
This chapter describes the tasks you can perform to manage the router and its performance on the network. In general, system or network management falls into the categories described in the following sections:
You can complete any of the tasks in the following sections to perform configuration management functions:
Other configuration management tasks are described in the chapter entitled "Loading System Images, Microcode Images, and Configuration Files" in the Configuration Fundamentals Configuration Guide.
Identification support allows you to query a TCP port for identification. This feature enables RFC 1413, an unsecure protocol for reporting the identity of a client that is initiating a TCP connection and a host responding to the connection. With identification support, you can connect a TCP port on a host, issue a simple text string to request information, and get back a simple text-string reply.
To configure identification support, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable identification support. | ip identd |
By default, the prompt consists of the router name followed by an angle bracket (>) for EXEC mode or a pound sign (#) for privileged EXEC mode. To customize your prompt, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Customize the prompt. | promt string |
| Remove the configuration prompt (config). | no service prompt config |
One of the first basic tasks is to name your router. The name is considered the host name and is the name that is displayed by the system prompt. If no name is configured, the system default name is Router. You can name the router in global configuration mode as follows:
| Task | Command |
|---|---|
| Set the host name. | hostname name |
For an example of configuring a router name, see the section "System Configuration File Example" at the end of this chapter.
You can create aliases for commonly used or complex commands. Use word substitutions or abbreviations to tailor command syntax for you and your user community.
To create and display command aliases, perform the tasks in the following sections:
To create a command alias, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Configure a command alias. | alias mode alias-name alias-command-line |
To display alias names and the original command syntax, perform the following task in EXEC mode:
| Task | Command |
|---|---|
| Show all command aliases and original command syntax, or specify the aliases in a particular command mode. | show aliases [mode] |
You can change the period of time over which a set of data is used for computing load statistics. By decreasing the load interval, dial backup and other decisions are based on an average that is computed over a shorter period of time and is more responsive to bursts of traffic.
To change the length of time for which a set of data is used to compute load statistics, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Set the length of time for which data is used for load calculations. | load-interval seconds |
All Cisco routers provide an array of time-of-day services. These services allow the products to accurately keep track of the current time and date, to synchronize multiple products to the same time, and to provide time services to other systems.
The heart of the time service is the system clock. This clock runs from the moment the system starts up and keeps track of the current date and time. The system clock can be set from a number of sources, and in turn can be used to distribute the current time through various mechanisms to other systems. When the system is initialized, the system clock is set based on the time in the Cisco 7000 hardware; on other models, the system clock it is set to midnight on March 1, 1993. The system clock can then be set from the following sources:
The system clock can provide time to the following services:
The system clock keeps track of time internally based on Coordinated Universal Time (UTC), also known as Greenwich Mean Time (GMT). You can configure information about the local time zone and summer time (daylight savings time) so that the time is displayed correctly relative to the local time zone.
The system clock keeps track of whether the time is "authoritative" or not (that is, whether it has been set by a time source considered to be authoritative). If it is not authoritative, the time will be available only for display purposes and will not be redistributed.
The Network Time Protocol (NTP) is a protocol designed to time-synchronize a network of machines. NTP runs over UDP, which in turn runs over IP. NTP is documented in RFC 1305.
An NTP network usually gets its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server. NTP then distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two machines to within a millisecond of one another.
NTP uses the concept of a "stratum" to describe how many NTP "hops" away a machine is from an authoritative time source. A "stratum 1" time server has a radio or atomic clock directly attached, a "stratum 2" time server receives its time via NTP from a "stratum 1" time server, and so on. A machine running NTP will automatically choose as its time source the machine with the lowest stratum number that it is configured to communicate with via NTP. This strategy effectively builds a self-organizing tree of NTP speakers.
NTP is careful to avoid synchronizing to a machine whose time may not be accurate. It avoids doing so in two ways. First of all, NTP will never synchronize to a machine that is not in turn synchronized itself. Secondly, NTP will compare the time reported by several machines, and will not synchronize to a machine whose time is significantly different than the others, even if its stratum is lower.
The communications between machines running NTP (known as "associations") are usually statically configured; each machine is given the IP address of all machines with which it should form associations. Accurate timekeeping is made possible by exchanging NTP messages between each pair of machines with an association. However, in a local-area network (LAN) environment, NTP can be configured to use IP broadcast messages instead. This alternative reduces configuration complexity because each machine can simply be configured to send or receive broadcast messages. However, the accuracy of timekeeping is marginally reduced because the information flow is one-way only.
The time kept on a machine is a critical resource, so we strongly recommend that you use the security features of NTP to avoid the accidental or malicious setting of incorrect time. Two mechanisms are available: an access list-based restriction scheme and an encrypted authentication mechanism.
Cisco's implementation of NTP does not support stratum 1 service; in other words, it is not possible to connect to a radio or atomic clock. It is recommended that time service for your network be derived from the public NTP servers available in the IP Internet. If the network is isolated from the Internet, Cisco's implementation of NTP allows a machine to be configured so that it acts as though it is synchronized via NTP, when in fact it has determined the time using other means. Other machines then synchronize to that machine via NTP.
When multiple sources of time (VINES, Cisco 7000 calendar, manual configuration) are available, NTP is always considered to be more authoritative. NTP time overrides the time set by any other method.
A number of manufacturers include NTP software for their host systems, and a publicly available version for systems running UNIX and its various derivatives is also available. This software allows host systems to be time-synchronized as well.
Time service is also available when Banyan VINES is configured. This protocol is a standard part of VINES. Cisco's implementation allows the VINES time service to be used in two ways. First, if the system has learned the time from some other source, it can act as a VINES time server and provide time to other machines running VINES. It also can use the VINES time service to set the system clock if no other form of time service is available.
The Cisco 7000 contains a battery-powered calendar system that tracks the date and time across system restarts and power outages. This calendar system is always used to initialize the system clock when the system is restarted. It can also be considered to be an authoritative source of time and be redistributed via NTP or VINES time service if no other source is available. Furthermore, if NTP is running, the Cisco 7000 calendar can be periodically updated from NTP, compensating for the inherent drift in the calendar time.
You can configure the system to synchronize unsolicited messages and debug output with solicited device output and prompts for a specific line. You can identify the types of messages to be output asynchronously based on the level of severity. You can also determine the maximum number of buffers for storing asynchronous messages for the terminal after which messages are dropped.
When synchronous logging of unsolicited messages and debug output is turned on, unsolicited device output is displayed on the console or printed after solicited device output is displayed or printed. Unsolicited messages and debug output is displayed on the console after the prompt for user input is returned. This is to keep unsolicited messages and debug output from being interspersed with solicited device output and prompts. After the unsolicited messages are displayed, the console displays the user prompt again.
To configure for synchronous logging of unsolicited messages and debug output with solicited device output and prompts, perform the following tasks:
| Task | Command |
|---|---|
| Step 1 Specify the line to be configured for synchronous logging of messages. | line [aux | console | VTY] line-number [ending-line-number]1 |
| Step 2 Enable synchronous logging of messages. | logging synchronous [level severity-level | all] [limit number-of-buffers] |
NTP services are enabled on all interfaces by default. The optional tasks you can perform are documented in the following sections:
If you want to authenticate the associations with other systems for security purposes, perform the tasks that follow. The first task enables the NTP authentication feature. The second task defines each of the authentication keys. Each key has a key number, a type, and a value. Currently the only key type supported is md5. Third, a list of "trusted" authentication keys is defined. If a key is trusted, this system will be ready to synchronize to a system that uses this key in its NTP packets.
To configure NTP authentication, perform the following tasks in global configuration mode:
An NTP association can be a peer association (meaning that this system is willing to either synchronize to the other system or to allow the other system to synchronize to it), or it can be a server association (meaning that only this system will synchronize to the other system, and not the other way around). If you want to form an NTP association with another system, perform one of the following tasks in global configuration mode:
Note that only one end of an association needs to be configured; the other system will automatically establish the association.
See the example entitled "Clock, Calendar, and NTP Configuration Examples" at the end of this chapter.
The system can either send broadcast packets or listen to them on an interface-by-interface basis. The estimated round-trip delay for broadcast packets can also be configured. Perform one or more of the following tasks in global configuration mode if you want to use NTP's broadcast feature:
| Task | Command |
|---|---|
| Send NTP broadcast packets. | ntp broadcast [version number] |
| Receive NTP broadcast packets. | ntp broadcast client |
| Adjust estimated delay. | ntp broadcastdelay microseconds |
See the example entitled "Clock, Calendar, and NTP Configuration Examples" at the end of this chapter.
You can control NTP access on two levels by completing the following tasks:
To control access to NTP services, you can create an NTP access group and apply a basic IP access list to it. To do so, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create an access group and apply a basic IP access list to it. | ntp access-group {query-only | serve-only | serve | peer} access-list-number |
The access group options are scanned in the following order from least restrictive to most restrictive:
If the source IP address matches the access lists for more than one access type, the first type is granted. If no access groups are specified, all access types are granted to all systems. If any access groups are specified, only the specified access types will be granted.
For details on NTP control queries, see RFC 1305 (NTP version 3).
NTP services are enabled on all interfaces by default. You can disable NTP packets from being received through an interface by performing the following task in interface configuration mode:
| Task | Command |
|---|---|
| Disable NTP services on a specific interface. | ntp disable |
When the system sends an NTP packet, the source IP address is normally set to the address of the interface through which the NTP packet is sent. Perform the following task in global configuration mode if you want to configure a specific interface from which the IP source address will be taken:
| Task | Command |
|---|---|
| Configure an interface from which the IP source address will be taken. | ntp source interface |
This interface will be used for the source address for all packets sent to all destinations. If a source address is to be used for a specific association, use the source parameter on the ntp peer or ntp server command shown earlier in this chapter.
Perform the following task in global configuration mode if you want the system to be an authoritative NTP server, even if the system is not synchronized to an outside time source:
| Task | Command |
|---|---|
| Make the system an authoritative NTP server. | ntp master [stratum] |
For an example of configuring an authoritative NTP server, see the section "Clock, Calendar, and NTP Configuration Examples" at the end of this chapter.
Perform the following task in global configuration mode if the system is synchronized to an outside time source via NTP and you want the Cisco 7000 calendar to be synchronized periodically to NTP time:
| Task | Command |
|---|---|
| Configure NTP to update the Cisco 7000 calendar. | ntp update-calendar |
For an example of configuring NTP to update the Cisco 7000 calendar, see the section "Clock, Calendar, and NTP Configuration Examples" at the end of this chapter.
Perform the following task in global configuration mode if you want to distribute the system clock to other VINES systems:
| Task | Command |
|---|---|
| Distribute the system clock to other VINES systems. | vines time use-system1 |
To receive VINES time service to control the system clock, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Receive VINES time service. | vines time set-system1 |
If no other source of time is available, you can manually configure the current time and date after the system is restarted. The time will remain accurate until the next system restart. We recommend that you use manual configuration only as a last resort.
To set up time services, complete the following tasks as needed. If you have an outside source to which the router can synchronize, you do not need to manually set the system clock.
Complete the following task in global configuration mode to manually configure the time zone used by the Cisco IOS software:
| Task | Command |
|---|---|
| Set the time zone. | clock timezone zone hours [minutes] |
For an example of configuring the time zone, see the section "Clock, Calendar, and NTP Configuration Examples" at the end of this chapter.
To configure summer time (daylight savings time) in areas where it starts and ends on a particular day of the week each year, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Configure summer time. | clock summer-time zone recurring [week day month hh:mm week day month hh:mm [offset]] |
If summer time in your area does not follow this pattern, you can configure the exact date and time of the next summer time events by performing one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Configure summer time. | clock summer-time zone date month date year hh:mm month date year hh:mm [offset]
or clock summer-time zone date date month year hh:mm date month year hh:mm [offset] |
For an example of configuring summer time, see the section "Clock, Calendar, and NTP Configuration Examples" at the end of this chapter.
If you have an outside source on the network that provides time services (such as an NTP server or VINES time service), you do not need to manually set the system clock.
However, if you have do not have any time service source, complete one of the following tasks in EXEC mode to set the system clock:
| Task | Command |
|---|---|
| Set the system clock. | clock set hh:mm:ss day month year
or clock set hh:mm:ss month day year |
In addition to a system clock, the Cisco 4500 and Cisco 7000 hardware provides a system calendar that can set the system time and control the system clock, as well as enable the router to act as a time service for the network.
You can complete the following tasks to enable the Cisco 4500 and Cisco 7000 calendar capabilities:
The calendar maintains time separately from the system clock. It continues to run when the system is restarted or power is turned off. Typically, it only needs to be manually set once, when the system is first installed. If time is available from an external source using NTP, the calendar can be updated from the system clock instead.
If you do not have an external time source, perform the following task in EXEC mode to set the system calendar:
| Task | Command |
|---|---|
| Set the calendar. | calendar set hh:mm:ss day month year
or calendar set hh:mm:ss month day year |
Although the system clock is always initialized from the calendar when the system is restarted, by default it is not considered to be authoritative and so will not be redistributed with NTP or VINES Time Service. To make the calendar be authoritative, complete the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable the router to act as a valid time source to which network peers can synchronize. | clock calendar-valid |
For an example of making the calendar authoritative, see the section "Clock, Calendar, and NTP Configuration Examples" at the end of this chapter.
To set the system clock to the new calendar setting, perform the following task in EXEC mode:
| Task | Command |
|---|---|
| Set the system clock from the calendar. | clock read-calendar |
To update the calendar with the new clock setting, perform the following task in EXEC mode:
| Task | Command |
|---|---|
| Set the calendar from the system clock. | clock update-calendar |
To monitor clock, calendar, and NTP EXEC services, complete the following tasks in EXEC mode:
You can access minor TCP, UDP, and BOOTP services available from hosts on the network. These services are enabled by default.
To enable these services, perform the following tasks in global configuration mode:
You can enable the Finger protocol so that people throughout the network can get a list of the users currently using the router. The information displayed includes the processes running on the system, the line number, connection name, idle time, and terminal location. To enable the Finger protocol, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable the Finger protocol requests. | service finger |
You can hide addresses while attempting to establish a Telnet session. To configure the router to suppress Telnet addresses, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Hide addresses while establishing a Telnet session. | service hide-telnet-address |
The hide feature suppresses the display of the address and continues to display all other messages that would normally display during a connection attempt, such as detailed error messages if the connection was not successful.
Use the busy-message command with the service hide-telnet-address command to customize the information displayed during Telnet connection attempts. If the connection attempt is not successful, the router suppresses the address and displays the message specified with the busy-message command.
The Simple Network Management Protocol (SNMP) system consists of three parts: an SNMP manager, an SNMP agent, and a Management Information Base (MIB). SNMP is an application-layer protocol that allows SNMP manager and agent stations to communicate. SNMP provides a message format for sending information between an SNMP manager and an SNMP agent. The SNMP manager can be part of a Network Management System (NMS), such as CiscoWorks.
The agent and MIB reside on the router. To configure SNMP on the router, you define the relationship between the manager and the agent.
The SNMP agent contains MIB variables whose values the SNMP manager can request or change. A manager can get a value from an agent or store a value into that agent.The agent gathers data from the MIB, the repository for information about device parameters and network data. The agent can also respond to a manager's requests to get or set data.
An agent can send unsolicited traps to the manager. Traps are messages alerting the SNMP manager to a condition on the network. Traps can indicate improper user authentication, restarts, link status (up or down), closing of a TCP connection, or loss of connection to a neighbor router.
Figure 29 illustrates the communications relationship between the SNMP manager and agent. It shows that a manager can send the agent requests to get and set MIB values. The agent can respond to these requests. Independent of this interaction, the agent can send unsolicited traps to the manager notifying the manager of network conditions.
Cisco supports the SNMP Version 1 protocol, referred to as SNMPv1, and the SNMP Version 2 protocol, referred to as SNMPv2. Cisco's implementation of SNMP supports all MIB II variables (as described in RFC 1213) and SNMP traps (as described in RFC 1215). See the Cisco Management Information Base (MIB) User Quick Reference for a list and detailed description of each Cisco MIB variable and SNMP trap.
RFC 1447, "SNMPv2 Party MIB" (April 1993), describes the managed objects that correspond to the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies, as defined by the SNMPv2 Administrative Model. RFC 1450, "SNMPv2 MIB," (April 1993) describes the managed objects that instrument the behavior of an SNMPv2 implementation. Cisco supports the MIB variables as required by the conformance clauses specified in these MIBs.
Cisco also provides its own MIB with every system. One of the set of MIB objects provided is the Cisco Chassis MIB that enables the SNMP manager to gather data on system card descriptions, serial numbers, hardware and software revision levels, and slot locations.
Although SNMPv2 offers more robust support than SNMPv1, Cisco continues to support SNMPv1. This is because not all management stations have migrated to SNMPv2 and you must configure the relationship between the agent and the manager to use the version of SNMP supported by the management station.
SNMPv1 offers a community-based form of security defined through an IP address access control list and password. SNMPv2 offers richer security configured through an access policy that defines the relationship between a single manager and agent. SNMPv2 security includes message authentication support using the Message Digest (MD5) algorithm, but because of the Data Encryption Standard (DES) export restrictions, it does not include encryption support through DES. SNMPv2 security provides data origin authentication, ensures data integrity, and protects against message stream modification.
In addition to enhanced security, SNMPv2 support includes a bulk retrieval mechanism and more detailed error message reporting to management stations. The bulk retrieval mechanism supports the retrieval of tables and large quantities of information, minimizing the number of round-trips required.
The SNMPv2 improved error handling support includes expanded error codes that distinguish different kinds of error conditions; these conditions are reported through a single error code in SNMPv1. Error return codes now report the error type. Three kinds of exceptions are also reported: no such object exceptions, no such instance exceptions, and end of MIB view exceptions.
There is no specific command that you use to enable SNMP. The first snmp-server command that you enter enables both versions of SNMP.
To configure SNMP support, perform the tasks in one of the following sections:
To configure relationship between the agent and the manager on the router, you need to know the version of the SNMP protocol that the management station supports. An agent can communicate with multiple managers; for this reason, you can configure the Cisco IOS software to support communications with one management station using the SNMPv1 protocol and another using the SNMPv2 protocol.
You can perform tasks in the following sections to configure support for both SNMPv1 and SNMPv2:
Using SNMP packets, a network management tool can send messages to users on virtual terminals and the console. This facility operates in a similar fashion to the EXEC send command; however, the SNMP request that causes the message to be issued to the users also specifies the action to be taken after the message is delivered. One possible action is a shutdown request. After a system is shut down, typically it is reloaded. Because the ability to cause a reload from the network is a powerful feature, it is protected by the snmp-server system-shutdown global configuration command. If you do not issue this command, the shutdown mechanism is not enabled. To enable the SNMP agent shutdown mechanism, perform the following task:
| Task | Command |
|---|---|
| Use the SNMP message reload feature and request a system shutdown message. | snmp-server system-shutdown |
To understand how to use this feature with SNMP requests, read the document mib.txt available by anonymous FTP from ftp.cisco.com.
You can set the system contact, location, and serial number of the SNMP agent so that these descriptions can be accessed through the configuration file. To do so, perform one or more of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Set the system contact string. | snmp-server contact text |
| Set the system location string. | snmp-server location text |
| Set the system serial number. | snmp-server chassis-id text |
You can set the maximum packet size permitted when the SNMP agent is receiving a request or generating a reply. To do so, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Establish the maximum packet size. | snmp-server packetsize byte-count |
You can limit the TFTP servers used for saving and loading configuration files via SNMP to the servers specified in an access list. To do so, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Limit TFTP servers used for configuration file copies via SNMP to the servers in an access list. | snmp-server tftp-server-list number |
To monitor SNMP input and output statistics, including the number of illegal community string entries, errors, and requested variables, complete the following task in EXEC mode:
| Task | Command |
|---|---|
| Monitor SNMP status. | show snmp |
To disable both versions of SNMP (SNMPv1 and SNMPv2) concurrently, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Disable SNMP agent operation. | no snmp-server |
SNMPv2 security requires that you create an access policy that defines the relationship between a manager and the agent. For each management station that the agent communicates with, you must create a separate access policy. Creating an access policy is a multiple-task process:
Step 1 Define a view to identify the objects that can be seen, if you do not want to use one of the standard predefined views.
Step 2 Define a context to identify the object resources that can be acted on.
Step 3 Define a party for both the manager and the agent to identify them.
Step 4 Using the definitions created in the previous tasks, configure the access policy that characterizes the communications that can occur between the manager and the agent. The privileges that you define for the access policy depend on whether the agent is defined as the source or the destination. For example:
Figure 30 shows the information exchanged between the manager and the agent. The top arrow, leading from the manager to the agent, shows the types of requests the manager can send to the agent. The bottom arrow, leading from the agent to the manager, shows the kind of information that the agent can send to the manager. Note that the agent sends trap messages to the manager in response to certain network conditions; trap messages are unsolicited and are not related to the request/response communication exchange between the manager and the agent that occurs in relation to MIB variables. For any given manager and agent relationship, the privileges defined in the access policy constrain communications to a specific set of operations.
You must create access policies for each new agent that is installed. You also must create access policies on an agent when new management stations with which the agent will communicate are installed. Moreover, every time a network address changes on a management station, you must reconfigure the access policy to reflect the new information for the management station.
This section describes each task that you must perform to configure an access policy. Then it addresses the alternative method and describes the task of configuring the user ID for the simplified security conventions method.
To configure support for SNMv2, perform the following tasks:
After you create a record, you can modify the record contents by changing one or more of the record values. To do this, issue the command again, naming the record that you created originally. You must fully specify the record values, including the argument values to remain unchanged.
To create or modify an SNMP view record, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create or modify a view record. | snmp-server view view-name oid-tree {included | excluded} [volatile] |
To remove a view record, use the no snmp-server view command.
To create or modify an SNMP context record, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create or modify a context record. | snmp-server context context-name context-oid view-name [volatile] |
To remove a context entry, use the no snmp-server context command. Specify only the name of the context. The name identifies the context to be deleted.
To create or modify an SNMPv2 party record, perform the following task in global configuration mode:
To remove a party record, use the no snmp-server party command.
To create or modify an SNMPv2 access policy, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create or modify an access policy. | snmp-server access-policy destination-party source-party context privileges [volatile] |
To remove an SNMPv2 access-policy, use the no snmp-server access-policy command. Specify all three arguments to correctly identify the access policy to be deleted. A difference of one value constitutes a unique access policy entry.
The SNMP trap operations allow a system administrator to configure the agent router to send information to an SNMP manager when a particular event occurs.
To define the recipient of the trap message, you configure a party record for the manager, including the protocol address, and specify the party record as the destination party for the snmp-server access policy command. To configure the router to send traps to a host, perform the following tasks in global configuration mode:
Optionally, you can specify a value other than the default for the source interface, message (packet) queue length for each trap host, or retransmission interval.
To change trap operation values, perform any of the following optional tasks in global configuration mode:
By default, SNMP link traps are sent when an interface goes up or down. For interfaces expected to go up and down during normal usage, such as ISDN interfaces, the output generated by these traps may not be useful. Use the no snmp trap link-status command to disable these traps.
If the manager supports only the SNMPv1 protocol, you must configure the relationship between the manager and the agent using SNMPv1 support. You can use either of two methods to configure access to the agent. There are trade-offs involved in choosing one method over the other. The methods differ in the following ways:
For both of the methods, perform the tasks in the "Define SNMP Trap Operations for SNMPv1" section to configure the router to send SNMP traps.
You can configure a community string, which acts like a password, to permit access to the agent on the router. Optionally, you can associate a list of IP addresses with that community string to permit only managers with these IP addresses to use the string. You can also associate a MIB view with the community string to restrict access to a particular subset of MIB objects.
To configure a community string, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Define the community access string. | snmp-server community string [view view-name] [ro | rw] [access-list number] |
You can configure one or more community strings. To remove a specific community string, use the no snmp-server community command.
For an example of configuring a community string, see the section "System Configuration File Example" at the end of this chapter.
To create or modify an SNMP view record, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create or modify a view record to be used for a context record. | snmp-server view view-name oid-tree {included | excluded} [volatile] |
To remove a view record, use the no snmp-server view command.
To create or modify an SNMP context record, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create or modify a context record to be used for a party record. | snmp-server context context-name context-oid view-name [volatile] |
To remove a context entry, use the no snmp-server context command. Specify only the name of the context. The name identifies the context to be deleted.
To create or modify an SNMPv1 party record to be used in an access policy and associate that party with a community string, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create or modify a party record. | snmp-server party party-name party-oid [protocol-address] [packetsize size] [local | remote] authentication snmpv1 string [volatile] |
To remove a party record, use the no snmp-server party command.
To configure an access policy, you specify the SNMPv1 proxy for which you configured the party record as both the destination party and the source party. To configure an access policy, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create an access policy. | snmp-server access-policy destination-party source-party context privileges [volatile] |
To remove an SNMP access policy, use the no snmp-server access-policy command. Specify all three arguments to correctly identify the access policy to be deleted. A difference of one value constitutes a unique access policy entry.
The SNMP trap operations allow a system administrator to configure the agent router to send information to an SNMP manager when a particular event occurs.
To configure the router to send traps to a host, perform the following tasks in global configuration mode:
Optionally, you can specify a value other than the default for the source interface, message (packet) queue length for each trap host, or retransmission interval.
To change trap operation values, perform any of the following optional tasks in global configuration mode:
By default, SNMP link traps are sent when an interface goes up or down. For interfaces expected to go up and down during normal usage, such as ISDN interfaces, the output generated by these traps may not be useful. Use the no snmp trap link-status command to disable these traps.
For an example of configuring trap authentication, see the section "System Configuration File Example" at the end of this chapter.
The Remote Monitoring (RMON) option provides visibility of individual nodal activity and allows you to monitor all nodes and their interaction on a LAN segment. RMON, used in conjunction with the SNMP agent in the router, allows you to view both traffic that flows through the router and segment traffic not necessarily destined for the router. Combining RMON alarms and events with existing MIBs allows you to choose where proactive monitoring will occur.
Full RMON packet analysis as described in RFC 1757 is available only on an Ethernet interface of a Cisco 2500 series router. RMON requires that SNMP be configured. A generic RMON console application such as Frontier NETscout Manager or Traffic Director is required in order to take advantage of RMON's network management capabilities.
RMON can be very data and processor intensive. Users should measure usage effects to ensure that router performance is not degraded and to minimize excessive management traffic overhead. Native mode is less intensive than promiscuous mode.
All Cisco IOS software images ordered without the explicit RMON option include limited RMON support (RMON alarms and event groups only). Images ordered with the RMON option include support for all nine groups (statistics, history, alarms, hosts, hostTopN, matrix, filter, capture, and event). As a security precaution, support for the packet capture group allows capture of packet header information only; data payloads are not captured.
To enable RMON on an Ethernet interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable RMON. | rmon {native | promiscuous} |
The default size of the queue that holds packets for analysis by the RMON process is 64 packets. To change the size of the queue, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Change the size of the RMON queue. | rmon queuesize size |
To set an RMON alarm or event, perform one of the following tasks in global configuration mode:
You can set an alarm on any MIB object in the access server. To disable an alarm, you must enable the no form of this command on each alarm you configure. You cannot disable all the alarms you configure at once. Refer to RFC 1757 to learn more about alarms and events and how they interact with each other.
To display the current RMON status, perform the following task in EXEC mode:
For an example of configuring RMON alarms and events, see the section "RMON Alarm and Event Examples" at the end of this chapter.
In Cisco IOS Release 10.3, IP access lists changed format. If you decide to downgrade from Release 11.0 to Release 10.2, you can configure the software to regenerate a configuration in the format of Release 10.2, thereby saving time and making your IP access lists compatible with the software.
To have the software regenerate a configuration in the format prior to Release 10.3, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Generate a backward-compatible configuration. | downward-compatible-config version |
The Cisco Discovery Protocol (CDP) is a media- and protocol-independent protocol that runs on all Cisco-manufactured equipment including routers, bridges, access servers, and switches. With CDP, network management applications can learn the device type and the SNMP agent address of neighboring devices. This enables applications to send SNMP queries to neighboring devices.
CDP runs on all media that support Subnetwork Access Protocol (SNAP), including local-area network (LAN), Frame Relay, and Asynchronous Transfer Mode (ATM) media. CDP runs over the data link layer only. Therefore, two systems that support different network-layer protocols can learn about each other.
Each device configured for CDP sends periodic messages to a multicast address. Each device advertises at least one address at which it can receive SNMP messages. The advertisements also contain time-to-live, or holdtime, information, which indicates the length of time a receiving device should hold CDP information before discarding it.
There is a CDP MIB for the management of CDP on Cisco devices.
To configure CDP, perform the tasks in the following sections:
To set the frequency of CDP transmissions and the hold time for CDP packets, perform the following tasks in global configuration mode:
CDP is enabled by default. To disable CDP and later reenable it, perform the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Disable CDP. | no cdp run |
| Enable CDP. | cdp run |
CDP is enabled by default on the router and is also enabled by default on all supported interfaces to send and receive CDP information. To disable and later reenable CDP on an interface, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Disable CDP on an interface. | no cdp enable |
| Enable CDP on an interface. | cdp enable |
To monitor and maintain CDP on your device, perform the following tasks in privileged EXEC mode:
To set up security features, you need to identify sensitive information, find the network access points to that information, secure these access points, and maintain the secure access points.
The following sections describe the optional tasks used to control access to the system:
Other chapters in the Cisco IOS Software Configuration Guides and Command References provide information on protocol-specific security features. The "Configuring Interfaces" chapter in the Configuration Fundamentals Configuration Guide provides information on CHAP, an additional authentication feature. Another example is the IP Security Option (IPSO) feature described in the "Configuring IP" chapter in the Network Protocols Configuration Guide, Part 1. Finally, see the separate protocol chapters for information about how to create access lists.
You can use the RADIUS protocol within AAA sessions. To do so, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable the Cisco access server to act as a client for the RADIUS authentication protocol. | aaa authentication {feature | list-name method] [...[method4]]} radius |
| Set parameters that restrict a user's network access based on RADIUS authorization. | aaa authorization {feature} radius |
| Set AAA accounting of requested services for billing or security purposes. | aaa accounting {feature} {when} radius |
| Specify a RADIUS server host and assign an accounting and authentication destination port. | radius-server host {hostname | ip-address} [authen-port port-number] [acct-port port-number] |
| Set the authentication/encryption key used for all RADIUS communications between the access server and the RADIUS daemon. | radius-server key {string} |
| Specify the number of times the router software will search the list of RADIUS server hosts before giving up. | radius-server retransmit n |
| Set the interval that the server waits for a server host to reply. | radius-server timeout {seconds} |
| Specify the number of minutes a RADIUS server, which is not responding to authentication requests, is passed over by requests for RADIUS authentication. | radius-server dead-time minutes
|
Table 7 lists the supported RADIUS (IETF) attributes. In cases where the attribute has a security server-specific format, the format is specified.
| Number | Attribute | Description | Cisco IOS Release 11.1 | Cisco IOS Release 11.2 |
|---|---|---|---|---|
| 1 | User-Name | Indicates the name of the user being authenticated. | yes | yes |
| 2 | User-Password | Indicates the user's password or the user's input following an Access-Challenge. Passwords longer than 16 characters are encrypted using the IETF Draft #2 (or later) specifications. | yes | yes |
| 3 | CHAP-Password | Indicates the response value provided by a PPP Challenge-Handshake Authentication Protocol (CHAP) user in response to an Access-Challenge. | yes | yes |
| 4 | NAS-IP Address | Specifies the IP address of the network access server that is requesting authentication. | yes | yes |
| 5 | NAS-Port | Indicates the physical port number of the network access server that is authenticating the user. The NAS-Port value (32 bits) consists of one or two 16-bit values(depending on the setting of the "radius-server extended-portnames"command.) Each 16-bit number should be viewed as a 5 digit decimal integer for interpretation as follows:
For asynchronous terminal lines, async network interfaces, and virtual async interfaces, the value is 00ttt, where ttt is the line number or async interface unit number. For ordinary synchronous network interface, the value is 10xxx. For channels on a primary rate ISDN interface, the value is 2ppcc. For channels on a basic rate ISDN interface, the value is 3bb0c. For other types of interfaces, the value is 6nnss. | yes | yes |
| 6 | Service-Type | Indicates the type of service requested or the type of service to be provided.
Exec User--Start an EXEC session. | yes | yes |
| 7 | Framed-Protocol | Indicates the framing to be used for framed access. | yes | yes |
| 8 | Framed-IP-Address | Indicates the address to be configured for the user. | yes | yes |
| 9 | Framed-IP-Netmask | Indicates the IP netmask to be configured for the user when the user is a router to a network. This attribute value results in a static route being added for Framed-IP-Address with the mask specified. | yes | yes |
| 10 | Framed-Routing | Indicates the routing method for the user when the user is a router to a network. Only "None" and "Send and Listen" values are supported for this attribute. | yes | yes |
| 11 | Filter-Id | Indicates the name of the filter list for the user and is formatted as follows: %d, %d.in, or %d.out. This attribute is associated with the most recent service-type command. For login and EXEC, use %d or %d.out as the line access list value from 0 to 199. For Framed service, use %d or %d.out as interface output access list, and %d.in for input access list. The numbers are self-encoding to the protocol to which they refer. | yes | yes |
| 13 | Framed-Compression | Indicates a compression protocol used for the link. This attribute results in a "/compress" being added to the PPP or SLIP autocommand generated during EXEC authorization. Not currently implemented for non-EXEC authorization. | yes | yes |
| 14 | Login-IP-Host | Indicates the host to which the user will connect when the Login-Service attribute is included. | yes | yes |
| 15 | Login-Service | Indicates the service that should be used to connect the user to the login host. | yes | yes |
| 16 | Login-Port | Defines the TCP port with which the user is to be connected when the Login-Service attribute is also present. | yes | yes |
| 17 | Change-Password | Specifies a request to change a user's password. | no | 11.2(5)F |
| 18 | Reply-Message | Indicates text that might be displayed to the user. | yes | yes |
| 21 | Password-Expiration | Specifies an expiration date for a user's password in the user's file entry. | no | 11.2(5)F |
| 22 | Framed-Route | Provides routing information to be configured for the user on this network access server. The RADIUS RFC format (net/bits [router [metric]]) and the old style dotted mask (net mask [router [metric]]) are supported. If the router field is omitted or 0, the peer IP address is used. Metrics are currently ignored. | yes | yes |
| 24 | State | Allows State information to be maintained between the network access server and the RADIUS server. This attribute is applicable only to CHAP challenges. | yes | yes |
| 26 | Vendor-Specific | Allows vendors to support their own extended attributes not suitable for general use. The Cisco RADIUS implementation supports one vendor-specific option using the format recommended in the specification. Cisco's vendor-ID is 9, and the supported option has vendor-type 1, which is named "cisco-avpair." The value is a string of the format:
protocol : attribute sep value
"Protocol" is a value of the Cisco "protocol" attribute for a particular type of authorization. "Attribute" and "value" are an appropriate AVpair defined in the Cisco TACACS+ specification, and "sep" is "=" for mandatory attributes and "*" for optional attributes. This allows the full set of features available for TACACS+ authorization to also be used for RADIUS. For example: cisco-avpair= "ip:addr-pool=first" cisco-avpair= "shell:priv-lvl=15"The first example causes Cisco's "multiple named ip address pools" feature to be activated during IP authorization (during PPP's IPCP address assignment). The second example causes a "NAS Prompt" user to have immediate access to EXEC commands. | yes | yes |
| 27 | Session-Timeout | Sets the maximum number of seconds of service to be provided to the user before the session terminates. This attribute value becomes the per-user "absolute timeout." This attribute is not valid for PPP sessions. | yes | yes |
| 28 | Idle-Timeout | Sets the maximum number of consecutive seconds of idle connection allowed to the user before the session terminates. This attribute value becomes the per-user "session-timeout." This attribute is not valid for PPP sessions. | yes | yes |
| 34 | Login-LAT-Service | Indicates the system with which the user is to be connected by LAT. This attribute is only available in the EXEC mode. | yes | yes |
| 35 | Login-LAT-Node | Indicates the node with which the user is to be automatically connected by LAT. | no | no |
| 36 | Login-LAT-Group | Identifies the LAT group codes that this user is authorized to use. | no | no |
Table 8 lists the supported RADIUS (IETF) accounting attributes. In cases where the attribute has a security server-specific format, the format is specified.
| Number | Attribute | Description | Cisco IOS Release 11.1 | Cisco IOS Release 11.2 |
|---|---|---|---|---|
| 25 | Class | Arbitrary value that the network access server includes in all accounting packets for this user if supplied by the RADIUS server. | yes | yes |
| 30 | Called-Station-Id | Allows the network access server to send the telephone number the user called as part of the Access-Request packet (using Dialed Number Identification [DNIS] or similar technology). This attribute is only supported on ISDN, and modem calls on the Cisco AS5200 if used with PRI. | yes | yes |
| 31 | Calling-Station-Id | Allows the network access server to send the telephone number the call came from as part of the Access-Request packet (using Automatic Number Identification or similar technology). This attribute has the same value as "remote-addr" from TACACS+. This attribute is only supported on ISDN, and modem calls on the Cisco AS5200 if used with PRI. | yes | yes |
| 40 | Acct-Status-Type | Indicates whether this Accounting-Request marks the beginning of the user service (start) or the end (stop). | yes | yes |
| 41 | Acct-Delay-Time | Indicates how many seconds the client has been trying to send a particular record. | yes | yes |
| 42 | Acct-Input-Octets | Indicates how many octets have been received from the port over the course of this service being provided. | yes | yes |
| 43 | Acct-Output-Octets | Indicates how many octets have been sent to the port in the course of delivering this service. | yes | yes |
| 44 | Acct-Session-Id | A unique accounting identifier that makes it easy to match start and stop records in a log file. Acct-Session Ids restart at 1 each time the router is power cycled or the software is reloaded. Contact Cisco Support if this is unsuitable. | yes | yes |
| 45 | Acct-Authentic | Indicates how the user was authenticated, whether by RADIUS, the network access server itself, or another remote authentication protocol. This attribute is set to "radius" for users authenticated by RADIUS; "remote" for TACACS+ and Kerberos; or "local" for local, enable, line, and if-needed methods. For all other methods, the attribute is omitted. | yes | yes |
| 46 | Acct-Session-Time | Indicates how long (in seconds) the user has received service. | yes | yes |
| 47 | Acct-Input-Packets | Indicates how many packets have been received from the port over the course of this service being provided to a framed user. | yes | yes |
| 48 | Acct-Output-Packets | Indicates how many packets have been sent to the port in the course of delivering this service to a framed user. | yes | yes |
| 61 | NAS-Port-Type | Indicates the type of physical port the network access server is using to authenticate the user. | yes | yes |
This section describes the Kerberos security system and includes the following topics:
Kerberos is a secret-key network authentication protocol, developed at Massachusetts Institute of Technology (MIT), that uses the Data Encryption Standard (DES) cryptographic algorithm for encryption and authentication. Kerberos was designed to authenticate requests for network resources. Kerberos, like other secret-key systems, is based on the concept of a trusted third party that performs secure verification of users and services. In the Kerberos protocol, this trusted third party is called the key distribution center (KDC).
The primary use of Kerberos is to verify that users and the network services they use are really who and what they claim to be. To accomplish this, a trusted Kerberos server issues tickets to users. These tickets, which have a limited lifespan, are stored in a user's credential cache and can be used in place of the standard username-and-password authentication mechanism.
The Kerberos credential scheme embodies a concept called "single logon." This process requires authenticating a user once, and then allows secure authentication (without encrypting another password) wherever that user's credential is accepted.
Cisco IOS Release 11.1 includes Kerberos 5 support, which allows organizations already deploying Kerberos 5 to use the same Kerberos authentication database on their routers that they are already using on their other network hosts (such as UNIX servers and PCs).
Table 9 lists common Kerberos-related terms and their definitions.
| Term | Definition |
|---|---|
| Authentication | A process by which a user or service identifies itself to another service. For example, a client can authenticate to a router, or a router can authenticate to another router. |
| Credential | A general term that refers to authentication tickets, such as ticket granting tickets and service credentials. Kerberos credentials verify the identity of a user or service. If a network service decides to trust the Kerberos server that issued this ticket, it can be used in place of a username and password. Credentials have a default limited lifespan of 8 hours. |
| Kerberos realm | A domain consisting of users, hosts, and network services that are registered to a Kerberos server. The Kerberos server is trusted to verify the identity of a user or network service to another user or network service. Kerberos realms must always be in uppercase characters. |
| Kerberos server | A daemon running on a network host. Users and network services register their identity with the Kerberos server. Network services query the Kerberos server to authenticate to other network services. |
| Key distribution center (KDC) | A Kerberos server and database program running on a network host. |
| Principal
| Also known as a Kerberos identity, this is who you are or what a service is according to the Kerberos server. |
| Ticket granting ticket (TGT) | A credential that the key distribution center (KDC) issues to authenticated users. When users receive a TGT, they can authenticate to network services within the Kerberos realm represented by the KDC. |
This section describes the first layer of security remote users must pass through when they attempt to access a network. The first step in the Kerberos authentication process is for users to authenticate themselves to the boundary router. The following procedure describes how users authenticate to a boundary router:
A remote user who successfully initiates a PPP session and authenticates to the boundary router is inside the firewall but still must authenticate to the KDC directly before being allowed to access network services. This is because the TGT issued by the KDC is stored on the router and is not useful for additional authentication unless the user physically logs on to the router.
In order for hosts and the key distribution center (KDC) in your Kerberos realm to communicate and mutually authenticate, you must identify them to one another. To do this, you add entries for the hosts to the Kerberos database on the KDC and add SRVTAB files generated by the KDC to all hosts in the Kerberos realm. You also make entries for users in the KDC database.
This section describes how to set up a Kerberos-authenticated server-client system and contains the following topics:
This section assumes that you have installed the Kerberos administrative programs on a UNIX host, known as the Key Distribution Center (KDC), initialized the database, and selected a Kerberos realm name and password. For instructions about completing these tasks, refer to the documentation that came with your Kerberos software.
After you set up a host to function as the key distribution center (KDC) in your Kerberos realm, you must make entries to the KDC database for all principles in the realm. Principles can be network services on hosts, or users.
This section describes how to use Kerberos commands to add services to the KDC database (and to modify existing database information).
To add users to the KDC and create privileged instances of those users, use the su command to become root on the host running the KDC and use the kdb5_edit program to perform the following tasks:
For example, to add user loki of Kerberos realm CISCO.COM, enter the following Kerberos command:
ank loki@CISCO.COM
You might want to create privileged instances to allow network administrators to connect to the router at the enable level, for example, so that they need not enter a cleartext password (and compromise security) to enter enable mode.
To add an instance of loki with additional privileges (in this case, enable, although it could be anything) enter the following Kerberos command:
ank loki/enable@CISCO.COM
In each of these examples, you are prompted to enter a password, which you must give to user loki to use at login.
This section describes how to configure a Cisco router to function as a network security server and authenticate users using the Kerberos protocol.
For a router to authenticate a user defined in the Kerberos database, it must know the host name or IP address of the host running the KDC, the name of the Kerberos realm and, optionally, be able to map the host name or Domain Naming System (DNS) domain to the Kerberos realm.
To configure the router to authenticate to a specified KDC in a specified Kerberos realm, perform the following tasks in global configuration mode (DNS domain names must begin with a leading dot (.)):
The Kerberos local realm, Kerberos realm, and Kerberos server commands are equivalent to the UNIX krb.conf file. Table 10 identifies mappings from the Cisco IOS configuration commands to a Kerberos 5 configuration file (krb5.conf).
| krb5.conf file | Cisco IOS Configuration Command |
|---|---|
| [libdefaults]
default_realm = MURUGA.COM | (in config mode)
kerberos local-realm MURUGA.COM |
| [domain_realm]
.muruga.com = MURUGA.COM muruga.com = MURUGA.COM | (in config mode)
kerberos realm .muruga.com MURUGA.COM kerberos realm muruga.com MURUGA.COM |
| [realms]
kdc = MURUGA.PIL.COM:750 admin_server = MURUGA.PIL.COM default_domain = MURUGA.COM | (in config mode)
kerberos server MURUGA.COM 172.65.44.2 (172.65.44.2 is the example IP address for MURUGA.PIL.COM) |
For an example of defining a Kerberos realm, see the "Define a Kerberos Realm Examples" section.
You have now configured Kerberos on your router. This makes it possible for the router to authenticate using Kerberos. But you have not yet told it to do so. To specify to the router to use Kerberos as the authentication method, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Set AAA authentication at login using Kerberos. | aaa authentication login {default | list-name} method1 [...[method4]] |
Remote users logging in to the network are now prompted for a username. If the KDC has an entry for that user, it creates an encrypted ticket granting ticket (TGT) with the password for that user and sends it back to the router. The user is then prompted for a password, and the router attempts to decrypt the TGT with that password. If it succeeds, the user is authenticated and the TGT is stored in the user's credential cache on the router.
A user does not need to run the KINIT program to get a TGT to authenticate to the router. This is because KINIT has been integrated into the login procedure in the Cisco IOS implementation of Kerberos. However, you might want to configure some remote users to authenticate via Kerberos when they log in using PPP. In that case, they would never actually be on the router but use it only as a gateway to their workstations.
You can use Kerberos to authenticate PPP sessions using the Password Authentication Protocol (PAP). After configuring PPP for PAP authentication, perform the following task in global configuration mode to specify Kerberos as the method of PAP authentication:
| Task | Command |
|---|---|
| Specify Kerberos as the method of authentication. | aaa authentication ppp [default | list-name] method1 [...[method4]] |
For an example of specifying Kerberos authentication, see the "Specify Kerberos Authentication Examples" section.
To display or remove a current user's credentials, perform the following tasks in EXEC mode:
| Task | Command |
|---|---|
| List the credentials in a current user's credentials cache. | show kerberos creds |
| Destroy all credentials in a current user's credentials cache. | clear kerberos creds |
Complete the following tasks to establish password protection:
You can provide access control on a terminal line by entering the password and establishing password checking. To do so, perform the following tasks in line configuration mode:
| Task | Command |
|---|---|
| Step 1 Assign a password to a terminal or other device on a line. | password password1 |
| Step 2 Enable password checking at login. | login1 |
The password checker is case sensitive and can include spaces. The password Secret is different than the password secret, for example, and the password two words is an acceptable password.
For an example of configuring a password and enabling password checking at login, see the section "System Configuration File Example" at the end of this chapter.
You can increase access security by configuring the Cisco IOS software to encrypt passwords because protocol analyzers can examine packets. Encryption prevents the password from being visible in the configuration file.
Configure the software to encrypt passwords by performing the following task in global configuration mode:
| Task | Command |
|---|---|
| Encrypt a password. | service password-encryption |
The actual encryption process occurs when the current configuration is written or when a password is configured. Password encryption is applied to all passwords, including authentication key passwords, the privileged command password, console and virtual terminal line access passwords, and BGP neighbor passwords. The service password-encryption command is primarily useful for keeping unauthorized individuals from viewing your password in your configuration file.
| **before**The service password-encryption command does not provide a high level of network security. If you use this command, you should also take additional network security measures.@@before@@ | Caution **after**The service password-encryption command does not provide a high level of network security. If you use this command, you should also take additional network security measures.@@after@@ |
While you cannot recover a lost encrypted password, you can recover from a lost encrypted password. That is, you cannot get the original password back. Before attempting to reload the router, issue the command configure memory to execute the configuration commands stored in NVRAM. If you lose your enable secret password, you must clear the contents of NVRAM and set a new password.
To provide an additional layer of security, particularly for passwords that cross the network or are stored on a TFTP server, you can use either the enable password or enable secret commands. Both commands accomplish the same thing; that is, they let you establish an encrypted password that users must enter to access enable mode (the default), or any privilege level you specify.
Cisco recommends that you use the enable secret command because it is the newer command and uses an improved encryption algorithm. You would use the enable password command only if you boot an older image of the Cisco IOS, or if you boot older boot roms that don't recognize the enable secret command.
If you configurethe enable secret command, it is used instead of the enable password command, not in addition to it.
To configure the router to require an enable password, perform one of the following tasks in global configuration mode:
Use either of these commands with the level option to define a password for a specific privilege level. After you specify the level and set a password, give the password to users you want to have access at this level. Use the privilege level configuration command to specify commands accessible at various levels.
If you have service password-encryption set, the password you enter is encrypted. When you display it with the show startup-config command, it is displayed in encrypted form.
If you specify an ecncyption type, you must provide an encrypted password--an encrypted password you copy from another router configuration.
You cannot recover a lost encrypted password. You must clear NVRAM and set a new password. See the sections "Recover a Lost Enable Password" or "Recover a Lost Line Password" in this chapter if you have lost or forgotten your password.
By default, the Cisco IOS software has two levels of password security, user level and privileged, or enabled, level. You can configure up to sixteen hierarchical levels of security. By configuring multiple passwords, you can allow different sets of users to have access to specified commands.
For example, if you want the configure command to be available to a more restricted set of users than the clear line command, you can assign level 2 security to the clear line command and distribute the level 2 password fairly widely, and assign level 3 security to the configure command and distribute the password to level 3 commands to fewer users.
To configure additional levels of security, perform the tasks in the following sections:
To set the privilege level for a command, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Set the privilege level for a command. | privilege mode level level command |
To change the default privilege level for a given line or a group of lines, perform the following task in line configuration mode:
| Task | Command |
|---|---|
| Specify a default privilege level for a line. | privilege level level |
To display your current level of privilege based on the password you used, perform the following task in EXEC mode:
| Task | Command |
|---|---|
| Display your current privilege level. | show privilege |
To log onto a router at a specified privilege level, perform the following task in EXEC mode:
| Task | Command |
|---|---|
| Log in to a specified privilege level. | enable level 1 |
To exit to a specified privilege level, perform the following task in EXEC mode:
| Task | Command |
|---|---|
| Exit to a specified privilege level. | disable level 1 |
You can disable line password verification by disabling password checking. To do so, perform the following task in line configuration mode:
| Task | Command |
|---|---|
| Disable password checking or allow access to a line without password verification. | no login1 |
To recover a lost enable password, follow these steps:
Step 1 Power cycle the router.
Step 2 Press the Break key within the first 60 seconds after power cycle. This puts the router in the ROM monitor mode indicated by the angle bracket (>) prompt.
Step 3 Examine and note the value in the configuration register:
Step 4 From the ROM monitor prompt (>), type o/r.
This puts the value 0x141 into the configuration register.
Step 5 Initialize and boot the router:
Step 6 Answer no to all the Setup questions. You should end with the following prompt:
Step 7 Enter privileged mode by entering the enable command. No password is required, and the prompt changes to Router(boot)#.
enable
Step 8 Use the show startup-config command to see the enable password.
show startup-config
Step 9 Restore the configuration register to its original value (as recorded earlier) using the configuration command:
config-register 0xoriginal values
Step 10 Reload and boot the router using the reload command:
reload
If your server has the nonvolatile memory option, you can accidentally lock yourself out if you enable password checking on the console terminal line and then forget the line password. To recover a lost line password, force the server into factory diagnostic mode and then follow these steps:
Step 1 Force the server into factory diagnostic mode.
See the hardware installation and maintenance publication for your product for specific information about configuring the processor configuration register for factory diagnostic mode. Table 11 summarizes the hardware or software settings required by various products to set factory diagnostic mode.
Step 2 Enter Yes when asked if you want to set the manufacturers' addresses. You will then see the following prompt:
TEST-SYSTEM>
Step 3 Enter the enable command to get the privileged prompt:
TEST-SYSTEM> enable
Step 4 Enter the show startup-config command to review the system configuration and find the password. Do not change anything in the factory diagnostic mode.
TEST-SYSTEM# show startup-config
Step 5 To resume normal operation, restart the server or reset the configuration register.
Step 6 Log into the server with the password that was shown in the configuration file.
See the hardware installation and maintenance publication for your product for specific information about configuring the processor configuration register for factory diagnostic mode. Table 11 summarizes the hardware or software settings required by the various products to set factory diagnostic mode.
| Platform | Setting |
|---|---|
| Modular products | Set jumper in bit 15 of the processor configuration register, then restart; remove jumper when finished. |
| Cisco 2500, Cisco 3000, Cisco 4000, Cisco AS5100, Cisco 7000 series | Use the config register command to set the processor configuration register to 0x8000, then initialize and boot the system. Use the reload command to restart and set the processor configuration register to 0x2102 when finished. |
This section summarizes the protocols that use access lists. The general guidelines for access lists vary from protocol to protocol. See the appropriate protocol-specific chapters in the Cisco IOS Configuration Guides and Command References for detailed task information on each protocol-specific access list.
To control SNMP access, see the "Configure SNMP Support" section in this chapter.
Table 12 provides the protocols that have access lists specified by names.
| Protocol |
|---|
| Apollo Domain |
| ISO CLNS |
| Source-route bridging NetBIOS |
| NetBIOS IPX |
Table 13 provides the protocols that have access lists specified by numbers and provides the corresponding numerical ranges.
To authorize remote access to local services, a common security solution has been to create access lists. Standard and static extended access lists have the following implications:
An improved security solution is the lock-and-key access feature, which is available for IP only. In particular, it works only with IP extended access lists. Lock-and-key access allows you to set up dynamic access lists that grant access per user to a specific source/destination host through a user authentication process. In essence, you can allow user access through a firewall dynamically, without compromising security restrictions.
 | Caution Enhancements to the access-list command are backward compatible; migrating from releases prior to Release 11.1 will convert your access lists automatically. However, releases prior to Release 11.1 are not upwardly compatible with these enhancements. Therefore, if you save an access list with these images and then use software prior to Release 11.1, the resulting access list will not be interpreted correctly. This could cause you severe security problems. Save your old configuration files before booting these images. |
| Caution Lock-and-key access allows an external event to place an opening in the firewall. Once this opening exists, the router is susceptible to source address spoofing. To prevent this, you need to provide encryption support using IP authentication or encryption. This issue is discussed further in this section. Spoofing is a problem with all existing access-lists. Lock-and-key access does not address this problem. |
Because lock-and-key access introduces a potential pathway through your network firewall, you need to evaluate the following serious considerations:
Two examples of when you might use lock-and-key access are as follows:
The following process describes the lock-and-key access operation:
To configure lock-and-key access, perform the following tasks beginning in global configuration mode:
| Task | Command |
|---|---|
| Step 1 Configure a dynamic access list, which serves as a template and place holder for temporary access list entries. | access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [established] [log] 1 |
| Step 2 Configure an interface. | interface type number 2 |
| Step 3 In interface configuration mode, apply the access list to the interface. | ip access-group access-list-number 3 |
| Step 4 In global configuration mode, define one or more virtual terminal (VTY) ports. If you specify multiple VTY ports, they must all be configured identically because the software hunts for available VTY ports on a round-robin basis. If you do not want to configure all your VTY ports for lock-and-key access, you can specify a group of VTY ports for lock-and-key support only. | line VTY line-number [ending-line-number] 4 |
| Step 5 Configure user authentication. | login tacacs 4
or username name password secret or password password 4 |
| Step 6 Enable the creation of temporary access list entries. If the host argument is not specified, all hosts on the entire network are allowed to set up a temporary access list entry. The dynamic access list contains the network mask to enable the new network connection. | autocommand access-enable [host] [timeout minutes] |
There are three possible methods to configure an authentication query process (see Step 5 in the previous task list):
Router# login tacacs
Router# username name password password
Router# password password
Router# login local
For an example of lock-and-key access, see the section "Lock-and-Key Access Example" later in this chapter.
Follow these guidelines when you configure dynamic access lists:
When you create dynamic access lists, remember the following:
To manually clear or to display dynamic access lists, refer to the section "Monitor and Maintain Dynamic Access Lists" in this chapter.
User authentication is successful when the following router events occur:
You can verify that this operation is successful on the router by:
The following sample display illustrates what the end-user might see after successfully completing the authentication process. Notice that the connection was closed immediately after the password was entered and authenticated. The temporary access list entry has already been created, and the host that initiated the Telnet session has access inside the firewall.
Router% telnet corporate
Trying 172.21.52.1 ...
Connected to corporate.abc.com.
Escape character is '^]'.
User Access Verification
Password:Connection closed by foreign host.
For an example of lock-and-key access, see the "Lock-and-Key Access Example" at the end of this chapter.
To manually delete a temporary access list entry, perform the following task in privileged EXEC mode:
| Task | Command |
|---|---|
| Delete a dynamic access list. | clear access-template access-list-number dynamic-name source destination |
You can display temporary access list entries when they are in use. Once a temporary access list entry is cleared by you or by the absolute or idle timeout parameter, it can no longer be displayed. The number of matches displayed indicates the number of times the access list entry was hit.
To view dynamic access lists and any temporary access list entries that are currently established, perform the following task in privileged EXEC mode:
| Task | Command |
|---|---|
| Display dynamic access lists and temporary access list entries. | show access-lists [access-list-number] 1 |
You can configure the Cisco IOS software to use one of three special TCP/IP protocols related to Terminal Access Controller Access Control System (TACACS): regular TACACS, extended TACACS, or AAA/TACACS+. TACACS services are provided by and maintained in a database on a TACACS server running on a workstation. You must have access to and configure a TACACS server before configuring the TACACS features described in this chapter on your Cisco router. Cisco's basic TACACS support is modeled after the original Defense Data Network (DDN) application.
A comparative description of the supported versions follows. Table 14 compares the versions by commands.
You can establish TACACS-style password protection on both user and privileged levels of the system EXEC.
| Command | TACACS | Extended TACACS | TACACS+ |
|---|---|---|---|
| aaa accounting | X | ||
| aaa authentication arap | X | ||
| aaa authentication enable default | X | ||
| aaa authentication login | X | ||
| aaa authentication local override | X | ||
| aaa authentication ppp | X | ||
| aaa authorization | X | ||
| aaa new-model | X | ||
| arap authentication | X | ||
| arap use-tacacs | X | X | |
| enable last-resort | X | X | |
| enable use-tacacs | X | X | |
| ip tacacs source-interface | X | X | X |
| login authentication | X | ||
| login tacacs | X | X | |
| ppp authentication | X | X | X |
| ppp use-tacacs | X | X | X |
| tacacs-server attempts | X | X | X |
| tacacs-server authenticate | X | X | |
| tacacs-server extended | X | ||
| tacacs-server host | X | X | X |
| tacacs-server key | X | ||
| tacacs-server last-resort | X | X | |
| tacacs-server notify | X | X | |
| tacacs-server optional-passwords | X | X | |
| tacacs-server retransmit | X | X | X |
| tacacs-server timeout | X | X | X |
The following sections describe the features available with TACACS and Extended TACACS. The Extended TACACS software is available using FTP (see the README file in the ftp.cisco.com directory).
You can enable password checking at login by performing the following task in line configuration mode:
| Task | Command |
|---|---|
| Set the TACACS-style user ID and password-checking mechanism. | login tacacs1 |
If a TACACS server does not respond to a login request, the Cisco IOS software will deny the request by default. However, you can prevent that login failure in one of two ways. You can allow a user to access privileged EXEC mode if that user enters the password set by the enable command.
Alternatively, you can ensure a successful login by allowing the user to access the privileged EXEC mode without further question.
To specify one of these features, perform either of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Allow a user to access privileged EXEC mode. | tacacs-server last-resort password |
| Set "last resort" options for logins. | tacacs-server last-resort succeed |
You can specify that the first TACACS request to a TACACS server is made without password verification. To do so, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Set TACACS password as optional. | tacacs-server optional-passwords |
When the user types in the login name, the login request is transmitted with the name and a zero-length password. If accepted, the login procedure is completed. If the TACACS server refuses this request, the terminal server prompts for a password and tries again when the user supplies a password. The TACACS server must support authentication for users without passwords to make use of this feature. This feature supports all TACACS requests such as login, SLIP, and enable.
You can set the TACACS protocol to determine whether a user can access the privileged EXEC level. To do so, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Set the TACACS-style user ID and password-checking mechanism at the privileged EXEC level. | enable use-tacacs |
When you set TACACS password protection at the privileged EXEC level, the EXEC enable command will ask for both a new username and a password. This information is then passed to the TACACS server for authentication. If you are using the extended TACACS, it will also pass any existing UNIX user identification code to the server.
| Caution If you use the enable use-tacacs command, you must also specify tacacs-server authenticate enable; otherwise, you will be locked out. |
You can specify what happens if the TACACS servers used by the enable command do not respond. To invoke this "last resort" login feature, perform either of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Allow user to enable by asking for the privileged EXEC-level password. | enable last-resort password |
| Allow user to enable without further questions. | enable last-resort succeed |
You can cause a message to be transmitted to the TACACS server when a user makes a TCP connection, enters the enable command, or logs out. To do so, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Set server notification of user actions. | tacacs-server notify {connection [always] | enable | logout [always] | slip [always]} |
The retransmission of the message is performed by a background process for up to five minutes. The terminal user, however, receives an immediate response allowing access to the terminal.
The tacacs-server notify command is only available when you have set up an extended TACACS server using the latest Cisco extended TACACS server software, available using FTP (see the README file in the ftp.cisco.com directory).
For a TCP connection, you can specify that if a user tries to make a connection, the Cisco IOS software requires a response, either from the network or the router, indicating whether the user can make the connection. You can also specify that the software performs authentication even when a user is not logged in.
For a SLIP or PPP session, you can specify that if a user tries to start a session, the software requires a response, either from the network or the router, indicating whether the user can start the session. You can specify that the software performs authentication even when a user is not logged in. You can also request that the software install access lists.
For use of the enable command, you can specify that if a user issues the enable command, the software must respond indicating whether the user can give the command.
To configure any of these scenarios, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Set server authentication of user actions. | tacacs-server authenticate {connection [always] | enable | slip [always] [access-lists]} |
The tacacs-server authenticate command is available only when you have set up an extended TACACS server using the latest Cisco extended TACACS server software, available using FTP (see the README file in the ftp.cisco.com directory).
You can specify the names of the IP host or hosts maintaining a TACACS server. The software searches for the hosts in the order specified, so this feature can be useful for setting up a list of preferred servers.
You can also modify the number of times the system software searches the list of TACACS servers (from the default of two times) and the interval it waits for a reply (from the default of 5 seconds).
Perform the following tasks as needed for your system configuration in global configuration mode:
You can set controls on the number of login attempts that can be made on a line set up for TACACS by performing the following task in global configuration mode:
| Task | Command |
|---|---|
| Control the number of login attempts that can be made on a line set for TACACS verification. | tacacs-server attempts count |
The tacacs-server login-timeout command allows you to specify how long the system will wait for login input (such as username and password) before timing out. The default login value is 30 seconds; with the tacacs-server login-timeout command, you can specify a timeout value from 1 to 300 seconds. Perform the following task in global configuration mode to change the login timeout value from the default of 30 seconds:
| Task | Command |
|---|---|
| Specify how long the system will wait for login information before timing out. | tacacs-server login-timeout seconds |
Extended TACACS mode provides information about the terminal requests to help set up UNIX auditing trails and accounting files for tracking use of protocol translators, access servers, and routers. The information includes responses from these network devices and validation of user requests.
An unsupported, extended TACACS server is available via FTP for UNIX users who want to create the auditing programs (see the README file in the ftp.cisco.com directory). Extended TACACS differs from standard TACACS, which provides only username and password information.
To enable extended TACACS mode, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable an extended TACACS mode. | tacacs-server extended |
You can use the Extended TACACS protocol for authentication within PPP sessions. To do so, perform the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Step 1 Enable CHAP or PAP. | ppp authentication {chap | pap} [if-needed] |
| Step 2 Enable TACACS under PPP. | ppp use-tacacs [single-line] |
For more information on PPP, refer to the "Configuring Interfaces" chapter in the Configuration Fundamentals Configuration Guide. For examples of enabling TACACS for PPP protocol authentication, see the section "System Management Examples" at the end of this chapter.
You can use the Standard TACACS protocol for authentication within AppleTalk Remote Access (ARA) protocol sessions. To do so, perform the following task starting in line configuration mode:
| Task | Command |
|---|---|
| Enable standard TACACS under the ARA protocol. | arap use-tacacs single-line1 |
| Enable autoselection of ARA. | autoselect arap2 |
| (Optional) Have the ARA session start automatically at user login. | autoselect during-login2 |
By using the optional during-login argument with the autoselect command, you can display the username or password prompt without pressing the Return key. While the Username or Password name is being presented, you can choose to answer these prompts or to start sending packets from an autoselected protocol.
The remote user logs in through ARA as follows:
Step 1 When prompted for username by the ARA application, the remote user enters username*password and presses Return.
Step 2 When prompted for password by the ARA application, the remote user enters arap and presses Return.
For more information on the ARA protocol, refer to the "Configuring an AppleTalk Remote Access Server" chapter in the Access Services Configuration Guide. For examples of enabling TACACS for ARA protocol authentication, see the section "System Management Examples" later in this chapter.
You can use the Extended TACACS protocol for authentication within AppleTalk Remote Access (ARA) protocol sessions. The Extended TACACS server software is available using FTP (see the README file in the ftp.cisco.com directory).
After installing an Extended TACACS server with ARA support, perform the following task in line configuration mode on each line:
| Task | Command |
|---|---|
| Enable extended TACACS under the ARA protocol on each line. | arap use-tacacs1 |
| (Optional) Enable autoselection of ARA. | autoselect arap2 |
| (Optional) Have the ARA session start automatically at user login. | autoselect during-login2 |
By using the optional during-login argument with the autoselect command, you can display the username or password prompt without pressing the Return key. While the Username or Password name is being presented, you can choose to answer these prompts or to start sending packets from an autoselected protocol.
For more information on the ARA protocol, refer to the "Configuring an AppleTalk Remote Access Server" chapter in the Access Services Configuration Guide. For examples of enabling TACACS for ARA protocol authentication, see the section "System Management Examples" later in this chapter.
By using a new configuration command in IOS 11.1, you can designate a fixed source IP address for all TACACS packets. The command makes TACACS use the IP address of a specified interface for all outgoing TACACS packets. This is especially useful in cases where the router has many interfaces and you want to make sure that all TACACS packets from a particular router have the same IP address.
To enable TACACS to use the address of a specified interface for all outgoing TACACS packets, perform the following task in configuration mode:
| Task | Command |
|---|---|
| Enable TACACS to use the ip address of a specified interface for all outgoing TACACS packets. | ip tacacs source-interface sub-interface-name |
AAA/TACACS+ combines original and enhanced functionality from previous versions of TACACS as well incorporating a new model of control access called Authentication, Authorization, and Accounting (AAA). The resulting benefits are more accurate accounting information and improved remote access functionality.
AAA's subset of services are broken down into the following functional groups:
TACACS+ also provides an API (Application Programming Interface) that allows the protocol to be integrated into existing standard databases.
You will need a server running TACACS software to use the AAA/TACACS+ functionality on your router. You can obtain this software free of charge from Cisco or purchase software from a third-party vendor.
The following sections describe the features available in AAA/TACACS+:
Additionally, the following features from the previous versions of TACACS are also available in TACACS+. Refer to the section "Enable TACACS and Extended TACACS."
To enable AAA/TACACS+, perform the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Enable AAA/TACACS+. | aaa new-model |
| Set the authentication and encryption key to the same key used on the TACACS+ daemon. | tacacs-server key key |
With the aaa authentication arap command, you create one or more lists of authentication methods that will be tried when ARA users log into the router. These lists are used with the arap authentication line command.
The list-name is any character string used to name the list you are creating. The method refers to the actual list of methods the authentication algorithm will try, in the sequence entered. You can enter up to four methods that this list should try in sequence.
To create a default list that is used if no list is specified in the arap authentication command, use the default argument followed by the methods you wish to be used in default situations.
The additional methods of authentication will only be used if the previous method returns an error, not if it fails. To specify that the authentication should succeed even if all methods return an error, specify none as the final method in the command line.
Perform at least the first of the following tasks starting in global configuration mode:
| Task | Command |
|---|---|
| Enable authentication for ARA users. | aaa authentication arap {default | list-name} method1 [...[method4]] |
| (Optional) Change to line configuration mode. | line x |
| (Optional) Enable autoselection of ARA. | autoselect arap1 |
| (Optional) Start the ARA session automatically at user login. | autoselect during-login1 |
| (Optional--not needed if default is used in the aaa authentication arap command) Enable TACACS+ authentication for ARA on a line. | arap authentication list-name 1 |
By using the optional during-login argument with the autoselect command, you can display the username or password prompt without pressing the Return key. While the Username or Password name is being presented, you can choose to answer these prompts or to start sending packets from an autoselected protocol.
Use the aaa authentication enable default command to create a series of authentication methods that are used to determine if a user can access privileged EXEC command level. You can specify up to four authentication methods. The additional methods of authentication are only used if the previous method returns an error, not if it fails. To specify that the authentication should succeed even if all methods return an error, specify none as the final method in the command line.
Perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable TACACS+ user ID and password checking for users requesting privileged EXEC level. | aaa authentication enable default method1 [...[method4]] |
With the aaa authentication login command, you create one or more lists of authentication methods that are tried at login. These lists are used with the login authentication line command.
The keyword list-name is any character string used to name the list you are creating. The method keyword refers to the actual list of methods the authentication algorithm tries, in the sequence entered. You can enter up to four methods that this list should try in sequence.
To create a default list that is used if no list is specified in the login authentication command, use the default argument followed by the methods you want used in default situations.
The additional methods of authentication are only used if the previous method returns an error, not if it fails. To specify that the authentication should succeed even if all methods return an error, specify none as the final method in the command line.
Perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable AAA authentication at login. | aaa authentication login {default | list-name} method1 [...[method4]] |
To have the Cisco IOS software check the local user database for authentication before attempting another form of authentication, use the aaa authentication local-override command. This command is useful when you want to configure an override to the normal authentication process for certain personnel such as system administrators.
Perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Create an override for authentication. | aaa authentication local-override |
With the aaa authentication ppp command, you create one or more lists of authentication methods that are tried during PPP sessions. These lists are used with the ppp authentication line command.
The keyword list-name is any character string used to name the list you are creating. The method keyword refers to the actual list of methods the authentication algorithm tries, in the sequence entered. You can enter up to four methods that this list tries in sequence.
To create a default list that is used if no list is specified in the ppp authentication command, use the default argument followed by the methods you want used in default situations.
The additional methods of authentication are only used if the previous method returns an error, not if it fails. To specify that the authentication should succeed even if all methods return an error, specify none as the final method in the command line.
Perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable AAA authentication for PPP. | aaa authentication ppp {default | list-name} method1 [...[method4]] |
Using the aaa authorization command you create a list of one and up to four authorization methods that are used when a user accesses the specified function.
The additional methods of authorization are only used if the previous method returns an error, not if it fails. To specify that the authorization should succeed even if all methods return an error, specify none as the final method in the command line.
Perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Restrict network access using AAA. | aaa authorization {network | connection | exec command level} methods |
Refer to "Restrict Network Access Examples" for an example of the aaa authorization command, and for an example of how to use address pooling with this command.
You use the aaa authorization command with the tacacs+ keyword to set parameters that restrict a user's network access.
To specify TACACS+ authorization for EXEC access and network services, perform the following tasks in global configuration mode:
| Task | Command |
|---|---|
| User TACACS+ authorization for all network-related service requests, including SLIP, PPP NCPs, and ARA protocol. | aaa authorization exec tacacs+ |
| User TACACS+ authorization to determine if the user is allowed to run an EXEC shell. This keyword might return user profile information (such as autocommand information). | aaa authorization network tacacs+ |
The aaa authorization exec tacacs+ local command sets the following authorization parameters:
You use the aaa accounting command with the tacacs+ keyword to turn on TACACS+ accounting for each Cisco IOS privilege level, and network services.
To use TACACS+ accounting to send a start record accounting notice at the beginning of an EXEC process and a stop record at the end, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Turn on TACACS+ accounting for the EXEC session. | aaa accounting exec start-stop tacacs+ |
To use TACACS+ to account for all network-related service requests, including SLIP, PPP, and PPP NCPs, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Use TACACS+ accounting for network-related service requests. | aaa accounting network start-stop tacacs+1 |
Table 15 lists the supported TACACS+ AV pairs.
| Attribute | Description | Cisco IOS Release 11.0 | Cisco IOS Release11.1 | Cisco IOS Release11.2 |
|---|---|---|---|---|
| service=x | The primary service. Specifying a service attribute indicates that this is a request for authorization or accounting of that service. Current values are slip, ppp, arap, shell, tty-daemon, connection, and system. This attribute must always be included. | yes | yes | yes |
| protocol=x | A protocol that is a subset of a service. An example would be any PPP NCP. Currently known values are lcp, ip, ipx, atalk, vines, lat, xremote, tn3270, telnet, rlogin, pad, vpdn, http, and unknown. | yes | yes | yes |
| cmd=x | A shell (EXEC) command. This indicates the command name for a shell command that is to be run. This attribute must be specified if service equals "shell." A NULL value indicates that the shell itself is being referred to. | yes | yes | yes |
| cmd-arg=x | An argument to a shell (EXEC) command. This indicates an argument for the shell command that is to be run. Multiple cmd-arg attributes may be specified, and they are order dependent. | yes | yes | yes |
| acl=x | ASCII number representing a connection access list. Used only when service=shell. | yes | yes | yes |
| inacl=x | ASCII identifier for an interface input access list. Used with service=ppp and protocol=ip. | yes | yes | yes |
| inacl#<n> | ASCII access list identifier for an input access list to be installed and applied to an interface for the duration of the current connect ion. Used with service=ppp and protocol=ip, and service service=ppp and protocol =ipx. | no | no | 11.2(4)F |
| outacl=x | ASCII identifier for an interface output access list. Used with service=ppp and protocol=ip, and service service=ppp and protocol=ipx. Contains an IP output access list for SLIP or PPP/IP (for example, outacl=4). The access list itself must be preconfigured on the router. Per-user access lists do not currently work with ISDN interfaces. | yes (PPP/IP only) | yes | yes |
| outacl#<n> | ACSII access list identifier for an interface output access list to be installed and applied to an interface for the duration of the current condition. Used with service=ppp and protocol=ip, and service service=ppp and protocol=ipx. | no | no | 11.2(4)F |
| zonelist=x | A numeric zonelist value. Used with service=arap. Specifies an AppleTalk zonelist for ARA (for example, zonelist=5). | yes | yes | yes |
| addr=x | A network address. Used with service=slip, service=ppp, and protocol=ip. Contains the IP address that the remote host should use when connecting via SLIP or PPP/IP. For example, addr=1.2.3.4. | yes | yes | yes |
| addr-pool=x | Specifies the name of a local pool from which to get the address of the remote host. Used with service=ppp and protocol=ip.
Note that addr-pool works in conjunction with local pooling. It specifies the name of a local pool (which must be preconfigured on the network access server). Use the ip-local pool command to declare local pools. For example: You can then use TACACS+ to return addr-pool=boo or addr-pool=moo to indicate the address pool from which you want to get this remote node's address. | yes | yes | yes |
| routing=x | Specifies whether routing information is to be propagated to, and accepted from this interface. Used with service=slip, service=ppp, and protocol=ip. Equivalent in function to the /routing flag in SLIP and PPP commands. Can either be true or false (for example, routing=true). | yes | yes | yes |
| route | Specifies a route to be applied to an interface. Used with service=slip, service=ppp, and protocol=ip.
During network authorization, the route attribute can be used to specify a per-user static route, to be installed by TACACS+ as follows: This indicates a temporary static route that is to be applied. dst_address, mask, and gateway are expected to be in the usual dotted-decimal notation, with the same meanings as in the familiar ip route configuration command on a network access server. If gateway is omitted, the peer's address is the gateway. The route is expunged when the connection terminates. | no | yes | yes |
| route#<n> | Like the route AV pair, this specifies a route to be applied to an interface, but these routes are numbered, allowing multiple routes to be applied. Used with service=ppp and protocol=ip, and service=ppp and protocol=ipx. | no | no | 11.2(4)F |
| timeout=x | The number of minutes before an ARA session disconnects (for example, timeout=60). A value of zero indicates no timeout. Used with service=arap. | yes | yes | yes |
| idletime=x | Sets a value, in minutes, after which an idle session is terminated. Does not work for PPP. A value of zero indicates no timeout. | no | yes | yes |
| autocmd=x | Specifies an autocommand to be executed at EXEC startup (for example, autocmd=telnet muruga.com). Used only with service=shell. | yes | yes | yes |
| noescape=x | Prevents user from using an escape character. Used with service=shell. Can be either true or false (for example, noescape=true). | yes | yes | yes |
| nohangup=x | Used with service=shell. Specifies the nohangup option. Can be either true or false (for example, nohangup=false). | yes | yes | yes |
| priv-lvl=x | Privilege level to be assigned for the EXEC. Used with service=shell. Privilege levels range from 0 to 15, with 15 being the highest. | yes | yes | yes |
| callback-dialstring | Sets the telephone number for a callback (for example: callback-dialstring=408-555-1212). Value is NULL, or a dial-string. A NULL value indicates that the service may choose to get the dialstring through other means. Used with service=arap, service=slip, service=ppp, service=shell. Not valid for ISDN. | no | yes | yes |
| callback-line | The number of a TTY line to use for callback (for example: callback-line=4). Used with service=arap, service=slip, service=ppp, service=shell. Not valid for ISDN. | no | yes | yes |
| callback-rotary | The number of a rotary group (between 0 and 100 inclusive) to use for callback (for example: callback-rotary=34). Used with service=arap, service=slip, service=ppp, service=shell. Not valid for ISDN. | no | yes | yes |
| nocallback-verify | Indicates that no callback verification is required. The only valid value for this parameter is 1 (for example, nocallback-verify=1). Used with service=arap, service=slip, service=ppp, service=shell. There is no authentication on callback. Not valid for ISDN. | no | yes | yes |
| tunnel-id | Specifies the username that will be used to authenticate the tunnel over which the individual user MID will be projected. This is analogous to the remote name in the vpdn outgoing command. Used with service=ppp and protocol=vpdn. | no | no | yes |
| ip-addresses | Space-separated list of possible IP addresses that can be used for the end-point of a tunnel. Used with service=ppp and protocol=vpdn. | no | no | yes |
| nas-password | Specifies the password for the network access server during the L2F tunnel authentication. Used with service=ppp and protocol=vpdn. | no | no | yes |
| gw-password | Specifies the password for the home gateway during the L2F tunnel authentication. Used with service=ppp and protocol=vpdn. | no | no | yes |
| rte-ftr-in#<n> | Specifies an input access list definition to be installed and applied to routing updates on the current interface for the duration of the current connection. Used with service=ppp and protocol=ip, and with service=ppp and protocol=ipx. | no | no | 11.2(4)F |
| rte-ftr-out#<n> | Specifies an output access list definition to be installed and applied to routing updates on the current interface for the duration of the current connection. Used with service=ppp and protocol=ip, and with service=ppp and protocol=ipx. | no | no | yes 11.2(4)F |
| sap#<n> | Specifies static Service Advertising Protocol (SAP) entries to be installed for the duration of a connection. Used with service=ppp and protocol=ipx. | no | no | yes 11.2(4)F |
| sap-fltr-in#<n> | Specifies an input SAP filter access list definition to be installed and applied on the current interface for the duration of the current connection. Used with service=ppp and protocol=ipx. | no | no | yes 11.2(4)F |
| sap-fltr-out#<n> | Specifies an output SAP filter access list definition to be installed and applied on the current interface for the duration of the current connection. Used with service=ppp and protocol=ipx. | no | no | 11.2(4)F |
| pool-def#<n> | Used to define IP address pools on the network access server. Used with service=ppp and protocol=ip. | no | no | 11.2(4)F |
Table 16 lists the supported TACACS+ accounting AV pairs.
| Attribute | Description | Cisco IOS Release11.0 | Cisco IOS Release 11.1 | Cisco IOS Release 11.2 |
|---|---|---|---|---|
| service | The service the user used. | yes | yes | yes |
| port | The port the user was logged in to. | yes | yes | yes |
| task_id | Start and stop records for the same event must have matching (unique) task_id's. | yes | yes | yes |
| start_time | The time the action started (in seconds since the epoch, 12:00 a.m. Jan 1 1970). The clock must be configured to receive this information. | yes | yes | yes |
| stop_time | The time the action stopped (in seconds since the epoch.) The clock must be configured to receive this information. | yes | yes | yes |
| elapsed_time | The elapsed time in seconds for the action. Useful when the device does not keep real time. | yes | yes | yes |
| timezone | The timezone abbreviation for all timestamps included in this packet. | yes | yes | yes |
| priv_level | The privilege level associated with the action. | yes | yes | yes |
| cmd | The command the user executed. | yes | yes | yes |
| protocol | The protocol associated with the action. | yes | yes | yes |
| bytes_in | The number of input bytes transferred during this connection. | yes | yes | yes |
| bytes_out | The number of output bytes transferred during this connection. | yes | yes | yes |
| paks_in | The number of input packets transferred during this connection. | yes | yes | yes |
| paks_out | The number of output packets transferred during this connection. | yes | yes | yes |
| event | Information included in the acounting packet that describes a state change in the router. Events described are accounting starting and accounting stopping. | yes | yes | yes |
| reason | Information included in the accounting packet that describes the event that caused a system change. Events described are system reload, system shutdown, or when accounting is reconfigured (turned on or off). | yes | yes | yes |
You can create a username-based authentication system, which is useful for the following reasons:
Perform the following tasks in global configuration mode, as needed for your system configuration:
The keyword noescape prevents users from using escape characters on the hosts to which they are connected.
For examples of configuring username authentication, see the section "Username Examples" at the end of this chapter.
Access control using Challenge Handshake Authentication Protocol (CHAP) is available on all serial interfaces that use PPP encapsulation. The authentication feature reduces the risk of security violations on your router.
When CHAP is enabled, a remote device (a PC, workstation, router, access server, or communication server) attempting to connect to the local router is requested, or "challenged," to respond.
The challenge consists of an ID, a random number, and either the host name of the local device or the name of the user on the remote device. This challenge is transmitted to the remote device.
The required response consists of two parts:
When the local device receives the challenge response, it verifies the secret by looking up the name given in the response and performing the same encryption operation. The secret passwords must be identical on the remote device and the local device.
Because the secret is never transmitted, other devices are prevented from stealing it and gaining illegal access to the system. Without the proper response, the remote device cannot connect to the local device.
CHAP transactions occur only when a link is established. The local device does not request a password during the rest of the call. (The local device can, however, respond to such requests from other devices during a call.)
To use CHAP, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable CHAP on the interface. | ppp authentication chap [if-needed] or ppp authentication chap [list-name] |
The optional keyword if-needed can be used only with TACACS or extended TACACS. The optional argument list-name can be used only with AAA/TACACS+. CHAP is specified in RFC 1334. It is an additional authentication phase of the PPP Link Control Protocol.
Once you have enabled CHAP, the local device requires a response from the remote devices. If the remote device does not support CHAP, no traffic is passed to that device.
Access control using the Password Authentication Protocol (PAP) is available on all serial interfaces that use PPP encapsulation. The authentication feature reduces the risk of security violations on your router.
The optional keyword if-needed can be used only with TACACS or Extended TACACS. The optional argument list-name can be used only with AAA/TACACS+. To use PAP, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
| Enable PAP on the interface. | ppp authentication pap [if-needed] or ppp authentication pap [list-name] |
To perform general fault management, complete the tasks in the following sections:
Most chapters in the Cisco IOS Software Configuration Guides include fault management tasks in a monitoring and maintaining section. For example, the "Configuring Interfaces" chapter in the Configuration Fundamentals Configuration Guide provides a section on interface loopback testing. Another example is the information on Internet Control Messages Protocol (ICMP) support described in the "Configuring IP" chapter in the Network Protocols Configuration Guide, Part 1.
To provide information about system processes, the Cisco IOS software includes an extensive list of EXEC commands that begin with the word show, which, when executed, display detailed tables of system information. Following is a list of the more common system management show commands. Perform these tasks in EXEC mode to display the information described:
Look for specific show commands in the tables of configuration tasks found throughout the chapters in Cisco IOS software configuration guides. See the Cisco IOS software command references for detailed descriptions of the commands.
On the Cisco 7000 only, the environmental monitor is built into the route processor (RP). If a measurement exceeds acceptable margins, a warning message is printed to the system console. The system software queries the RP for measurements once every 60 seconds, but warnings for a given test point are printed at most once every four hours. If the temperature measurements are out of specification more than the shutdown margin, the software shuts the router down but the fan will stay on. The router has to be manually turned off and on after such a shutdown. You can query the RP using the show environment command at any time to determine whether a measurement is out of tolerance. Refer to the System Error Messages publication for a description of environmental monitor warning messages.
On the Cisco 7000 only, if the RP detects that any of its temperature test points have exceeded maximum margins, it performs the following steps in this order:
The following is the message the system displays if temperatures exceed maximum margins, along with a message indicating the reason for the shutdown:
Router# %ENVM-1-SHUTDOWN: Environmental Monitor initiated shutdown %ENVM-2-TEMP: Inlet temperature has reached SHUTDOWN level at 64(C)
Refer to the hardware installation and maintenance publication for your router for more information about environmental specifications.
Complete the tasks in the following sections to test basic network connectivity:
The TCP keepalive capability allows a router to detect when the host with which it is communicating experiences a system failure, even if data stops being transmitted (in either direction). This is most useful on incoming connections. For example, if a host failure occurs while talking to a printer, the router might never notice, because the printer does not generate any traffic in the opposite direction. If keepalives are enabled, they are sent once every minute on otherwise idle connections. If five minutes pass and no keepalives are detected, the connection is closed. The connection is also closed if the host replies to a keepalive packet with a reset packet. This will happen if the host crashes and comes back up again.
To set up the TCP keepalive packet service, perform the following task in global configuration mode:
As an aid to diagnosing basic network connectivity, many network protocols support an echo protocol. The protocol involves sending a special datagram to the destination host, then waiting for a reply datagram from that host. Results from this echo protocol can help in evaluating the path-to-host reliability, delays over the path, and whether the host can be reached or is functioning.
To use the echo protocol, perform the following task in either user or privileged EXEC mode:
| Task | Command |
|---|---|
| Invoke a diagnostic tool for testing connectivity. | ping [protocol] {host | address} |
Look for specific ping commands in the tables of configuration tasks found throughout the chapters in Cisco IOS Software configuration guides. See the Cisco IOS Software command references for detailed descriptions of the command.
You can discover the routes that packets will actually take when traveling to their destinations. To do so, perform the following task in either user or privileged EXEC mode:
| Task | Command |
|---|---|
| Trace packet routes through the network (privileged level). | trace [protocol] [destination] |
When using a standard TCP implementation to send keystrokes between machines, TCP tends to send one packet for each keystroke typed. On larger networks, many small packets use up bandwidth and contribute to congestion.
John Nagle's algorithm (RFC 896) helps alleviate the small-packet problem in TCP. In general, it works this way: The first character typed after connection establishment is sent in a single packet, but TCP holds any additional characters typed until the receiver acknowledges the previous packet. Then the second, larger packet is sent, and additional typed characters are saved until the acknowledgment comes back. The effect is to accumulate characters into larger chunks, and pace them out to the network at a rate matching the round-trip time of the given connection. This method is usually a good for all TCP-based traffic. However, do not enable the Nagle slow packet avoidance algorithm if you have XRemote users on X Window sessions.
By default, the Nagle algorithm is not enabled. To invoke the Nagle algorithm and thereby reduce TCP transactions, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable the Nagle slow packet avoidance algorithm. | service nagle |
You can test the status of the following items:
To test the status of Flash memory, perform the following task in privileged EXEC mode:
| Task | Command |
|---|---|
| Test Flash memory on MCI and envm Flash EPROM interfaces. | test flash |
To test the status of system memory, perform the following task in privileged EXEC mode:
| Task | Command |
|---|---|
| Diagnose Multibus memory, including nonvolatile memory. | test memory |
| Caution Do not use this test to diagnose problems with an operational server. |
To test the status of the interfaces, perform the following task on a nonoperational server in privileged EXEC mode:
| Task | Command |
|---|---|
| Check network interfaces. | test interfaces |
By default, the network servers send the output from the debug EXEC command and system error messages to the console terminal. You can redirect these messages, as well as output from asynchronous events such as interface transition, to other destinations. These destinations include virtual terminals, internal buffers, and UNIX hosts running a syslog server; the syslog format is compatible with 4.3 BSD UNIX.
Additionally, you can set the severity level of the messages to control the type of messages displayed. You can also have log messages timestamped to enhance real-time debugging and management.
There are three syslog messages at LOG_NOTICE syslog level that make it easier to check the status of how the system provides address resolution. An example follows:
%LINK-5-BOOTP: Ethernet0 address 131.108.160.24, resolved by 131.108.1.111 %LINK-5-RARP: Ethernet0 address 131.108.160.24, resolved by 131.108.1.111 %LINK-5-SLARP: Ethernet0 address 131.108.160.24, resolved by 131.108.1.111
There are also startup messages that help you identify NVRAM problems:
Warning: NVRAM device not found Warning: NVRAM invalid, possibly due to erase startup-config
The following level 4 LOG_WARNING message provides FDDI status information:
%FDDISTAT-4-STATUS: FDDI state indication detected on interface variable
The possible values for indication are listed in the next paragraph. The variable will be replaced with something like fddi0, for example.
Changes in status reflect interface connectivity or cabling problems (or fixes). The possible status reports include the following indications:
isolated wrap A wrap B wrap a-B thru A thru B thru A-B
To set up the syslog daemon on a 4.3 BSD UNIX system, include a line such as the following in the file /etc/syslog.conf:
local7.debugging /usr/adm/logs/cisco.log
The local7 keyword specifies the logging facility to be used; see Table 18 for a general description of other keywords. The debugging keyword specifies the syslog level; see Table 17 for a general description of other keywords.
The syslog daemon sends messages at this level or a more severe level to the file specified in the next field. The file must already exist, and the syslog daemon must have permission to write to it.
To enable message logging, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable message logging. | logging on |
To enable slave Versatile Interface Processor (VIP) cards to log important messages to the console, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable slave message logging. | service slave-log |
By default, error messages are directed to the system console. To direct messages to other devices, perform one of the following tasks in global configuration mode:
| Task | Command |
|---|---|
| Log messages to an internal buffer. | logging buffered [size] |
| Log messages to a UNIX syslog server host. | logging host |
| Redirect messages to the system console. | no logging on |
The logging buffered command copies logging messages to an internal buffer instead of writing them to the console terminal. The buffer is circular, so newer messages overwrite older messages after the buffer is full. To display the messages that are logged in the buffer, use the show logging EXEC command. The first message displayed is the oldest message in the buffer.
The EXEC command terminal monitor locally accomplishes the task of displaying the system error messages to a nonconsole terminal.
The logging command identifies a syslog server host to receive logging messages. The argument host is the name or Internet address of the host. By issuing this command more than once, you build a list of syslog servers that receive logging messages. The no logging command deletes the syslog server with the specified address from the list of syslogs.
You can limit messages displayed to the selected device by specifying the severity level of the error message. To do so, perform one of the following tasks in global configuration mode:
The logging console command limits the logging messages displayed on the console terminal to messages with a level number at or below the specified severity level, which is specified by the level argument. Table 17 lists the error message level keywords and corresponding UNIX syslog definitions in order from the most severe level to the least severe level.
| Level Keyword | Level | Description | Syslog Definition |
|---|---|---|---|
| emergencies | 0 | System unusable | LOG_EMERG |
| alerts | 1 | Immediate action needed | LOG_ALERT |
| critical | 2 | Critical conditions | LOG_CRIT |
| errors | 3 | Error conditions | LOG_ERR |
| warnings | 4 | Warning conditions | LOG_WARNING |
| notifications | 5 | Normal but significant condition | LOG_NOTICE |
| informational | 6 | Informational messages only | LOG_INFO |
| debugging | 7 | Debugging messages | LOG_DEBUG |
The no logging console command disables logging to the console terminal.
The default is to log messages to the console at the debugging level and those level numbers that are lower, which means all levels. The logging monitor command defaults to debugging also. The logging trap command defaults to informational.
To display logging messages on a terminal, use the terminal monitor EXEC command.
Current software generates four categories of error messages:
You can also configure the syslog facility in which error messages are sent by performing the following task in global configuration mode:
| Task | Command |
|---|---|
| Configure system log facilities. | logging facility facility-type |
Table 18 lists the logging facility type keywords and their descriptions.
| Facility Type Keyword | Description |
| auth | Indicates the authorization system. |
| cron | Indicates the cron facility. |
| daemon | Indicates the system daemon. |
| kern | Indicates the Kernel. |
| local0-7 | Reserved for locally defined messages. |
| lpr | Indicates line printer system. |
| Indicates mail system. | |
| news | Indicates USENET news. |
| sys9 | Indicates system use. |
| Facility Type Keyword | Description |
| sys10 | Indicates system use. |
| sys11 | Indicates system use. |
| sys12 | Indicates system use. |
| sys13 | Indicates system use. |
| sys14 | Indicates system use. |
| Facility Type Keyword | Description |
| syslog | Indicates the system log. |
| user | Indicates user process. |
| uucp | Indicates UNIX-to-UNIX copy system. |
Refer also to your syslog manual pages.
To display the addresses and levels associated with the current logging setup, as well as any other logging statistics, perform the following task in EXEC mode:
| Task | Command |
| Display the state of syslog error and event logging, including host addresses and whether console logging is enabled. | show logging |
By default, log messages are not timestamped. You can enable timestamping of log messages by performing the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable log timestamps. | service timestamps log uptime or service timestamps log datetime [msec] [localtime] [show-timezone] |
Your router includes hardware and software to aid in tracking down internal problems and problems with other hosts on the network. The privileged debug EXEC commands start the console display of several classes of network events. The following tasks describe in general the system debug message feature. Refer to the Debug Command Reference for all information regarding debug commands. Also refer to the Troubleshooting Internetworking Systems publication.
| Caution The system gives high priority to debugging output. For this reason, debugging commands should be turned on only for troubleshooting specific problems or during troubleshooting sessions with technical support personnel. Excessive debugging output can render the system inoperable. |
You can configure timestamping of system debug messages. Timestamping enhances real-time debugging by providing the relative timing of logged events. This information is especially useful when customers send debugging output to your technical support personnel for assistance. To enable timestamping of system debug messages, perform the following task in global configuration mode:
| Task | Command |
| Enable timestamping of system debug messages. | service timestamps debug uptime or service timestamps debug datetime [msec] [localtime] [show-timezone] |
Normally, the messages are displayed only on the console terminal. See the section "Set the Error Message Display Device" earlier in this chapter to change the output device.
The following sections describe how to manage general system performance:
In addition, most chapters in this guide include performance tasks specific to the chapter content, and the Internetworking Design Guide includes detailed information on performance issues that arise when designing a network.
The normal operation of the network server allows the switching operations to use as much of the central processor as is required. If the network is running unusually heavy loads that do not allow the processor the time to handle the routing protocols, you might need to give priority to the system process scheduler. To do so, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Define the maximum amount of time that can elapse without running the lowest-priority system processes. | scheduler interval milliseconds |
To change the amount of time that the CPU spends on fast switching and process level operations on the Cisco 7200 series and Cisco 7500 series, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| For the Cisco 7200 series and Cisco 7500 series, change the default time the CPU spends on process tasks and fast switching. | scheduler allocate network-microseconds process-microseconds |
| Caution Cisco recommends that you do not change the default values of the scheduler allocate command. |
There are four possible queuing algorithms used: first-come-first-serve (FCFS), weighted fair queuing, priority queuing, and custom queuing. For serial interfaces at E1 (2.048 MBPS) and below, weighted fair queuing is used by default. When no other queuing strategies are configured, all other interfaces use FCFS by default.
You can configure the Cisco IOS software to support the following three types of queuing strategies for prioritizing network traffic:
You can configure weighted fair queuing, priority queuing, and custom queuing, but you can assign only one queue type--a fair queue, a priority group, or a custom queue--to an interface.
When enabled for an interface, weighted fair queuing provides traffic priority management that automatically sorts among individual traffic streams without requiring that you first define access lists.
Weighted fair queuing can manage duplex data streams, such as those between pairs of applications, and simplex data streams such as voice or video. From the perspective of weighted fair queuing, there are two categories of data streams: high-bandwidth sessions and low-bandwidth sessions. Low-bandwidth traffic has effective priority over high-bandwidth traffic, and high-bandwidth traffic shares the transmission service proportionally according to assigned weights.
When you enable weighted fair queuing for an interface, new messages for high-bandwidth conversations are discarded after the congestive-messages threshold you set or the default one has been met. However, low-bandwidth conversations, which include control-message conversations, continue to enqueue data. As a result, the fair queue may occasionally contain more messages than are specified by the threshold number.
Priority output queuing is a mechanism that allows the administrator to set priorities on the type of traffic passing through the network. Packets are classified according to various criteria, including protocol and subprotocol type, and then queued on one of four output queues (high, medium, normal, and low).
When the server is ready to transmit a packet, it scans the priority queues in order, from highest to lowest, to find the highest-priority packet. After that packet is completely transmitted, the server scans the priority queues again. If a priority output queue fills up, packets are dropped and, for IP, quench indications are sent to the original transmitter.
Although you can enable priority output queuing for any interface, the intended application was for low-bandwidth, congested serial interfaces. Cisco's priority output queuing mechanism allows traffic control based on protocol or interface type. You can also set the size of the queue and defaults for what happens to packets that are not defined by priority output queue rules.
The priority output queuing mechanism can be used to manage traffic from all networking protocols. Additional fine-tuning is available for IP and for setting boundaries on the packet size.
The four priority queues--high, medium, normal, and low--are listed in order from highest to lowest priority. Keepalives sourced by the network server are always assigned to the high-priority queue; all other management traffic (such as IGRP updates) must be configured. Packets that are not classified by the priority list mechanism are assigned to the normal queue.
A priority list is a set of rules that describes how packets should be assigned to priority queues. A priority list might also describe a default priority or the queue size limits of the various priority queues.
Priority queuing introduces a fairness problem in that packets classified to lower-priority queues might not get serviced in a timely manner or at all, depending upon the bandwidth used by packets sent from the higher-priority output queues.
With custom output queuing, a "weighted fair" queuing strategy is implemented for the processing of interface output queues. You can control the percentage of an interface's available bandwidth that is used by a particular kind of traffic. When custom queuing is enabled on an interface, the system maintains 17 output queues for that interface that can be used to modify queuing behavior. You can specify queues 1 through 16.
For queue numbers 1 through 16, the system cycles through the queues sequentially, delivering packets in the current queue before moving on to the next. Associated with each output queue is a configurable byte count, which specifies how many bytes of data the system should deliver from the current queue before it moves on to the next queue. When a particular queue is being processed, packets are sent until the number of bytes sent exceed the queue byte count or the queue is empty. Bandwidth used by a particular queue can only be indirectly specified in terms of byte count and queue length.
Queue number 0 is a system queue; it is emptied before any of the queues numbered 1 through 16 are processed. The system enqueues high-priority packets, such as keepalive packets, to this queue. Other traffic cannot be configured to use this queue.
Note that IP traffic is classified by the fast-switching logic. All other traffic is classified by the process logic. This holds true for priority, custom, and weighted fair queuing.
You can set up weighted fair queuing, priority queuing, and custom queuing on your network, but you can assign only one of the three to an interface.
The following sections describe the tasks that you can choose from, depending upon the needs of your network:
To enable weighted fair queuing for an interface and set the congestion threshold after which messages for high-bandwidth conversations are dropped, perform the following task in interface configuration mode after specifying the interface:
| Task | Command |
|---|---|
| Configure an interface to use weighted fair queuing. | fair-queue congestive-discard-threshold-number |
To disable weighted fair queuing for an interface, use the no fair-queue command. Fair queuing is automatically disabled if either autonomous or SSE switching is enabled. Fair queueing is disabled automatically on interfaces configured with the ppp multilink command. If the no ppp multilink command is configured, you must enable fair queuing manually on the interface.
Fair queueing is enabled by default for physical interfaces whose bandwidth is less than or equal to 2.048 megabits per second (Mbps) and that do not use Link Access Procedure, Balanced (LAPB), X.25, or Synchronous Data Link Control (SDLC) encapsulations. (Fair queuing is not an option for these protocols.) However, if custom queuing or priority queuing is enabled for a qualifying link, it overrides fair queueing, effectively disabling it. Additionally, fair queuing is automatically disabled if you enable autonomous or SSE switching.
You can establish queuing priorities based upon the protocol type by using one of the following commands in global configuration mode. All Cisco-supported protocols are allowed.
Queue keywords provide additional options including byte-count, TCP service and port number assignments, and AppleTalk, IP, IPX, VINES, or XNS access list assignments. See the priority-list and queue-list command syntax descriptions in the "System Management Commands" chapter in the Configuration Fundamentals Command Reference.
You can assign a queue for those packets that did not match any other rule in the list. To do so, perform one of the following tasks in global configuration mode:
You can establish queuing priorities on packets entering from a specific interface by performing one of the following tasks in global configuration mode:
You can specify the maximum number of packets that might be waiting in each of the priority queues. To do so, perform one of the following tasks in global configuration mode:
Both limit and byte-count keywords can appear as arguments to the queue-list list queue command.
You can assign a priority list number to an interface. Only one list can be assigned per interface. To assign an priority group or custom queue to an interface, perform one of the following tasks in interface configuration mode:
| Task | Command |
|---|---|
| Assign a priority list number to the interface. | priority-group list |
| Assign a custom queue list number to the interface. | custom-queue-list list |
You can display information about the input and output queues when priority queuing is enabled on an interface. To do so, perform one of the following tasks in EXEC mode:
| Task | Command |
|---|---|
| Show the status of the priority queuing lists. | show queueing priority1 |
| Show the status of the custom queuing lists. | show queueing custom1 |
If you enter the show queueing command without any keywords, the terminal displays status on both custom and priority queue lists.
You can adjust initial buffer pool settings and the limits at which temporary buffers are created and destroyed. To do so, perform the following tasks in global configuration mode:
| Caution Normally you need not adjust these parameters; do so only after consulting with technical support personnel. Improper settings can adversely impact system performance. |
During normal system operation, there are two sets of buffer pools: public and interface.
See the section "Buffer Modification Examples" at the end of this chapter.
The server has one pool of queuing elements and six public pools of packet buffers of different sizes. For each pool, the server keeps count of the number of buffers outstanding, the number of buffers in the free list, and the maximum number of buffers allowed in the free list. To display statistics about the buffer pool on the system, perform the following tasks in EXEC mode:
You can delay the startup of the EXEC on noisy lines until the line has been idle for 3 seconds. To do so, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Delay startup of the EXEC. | service exec-wait |
This command is useful on noisy modem lines or when a modem attached to the line is configured to ignore MNP or V.42 negotiations, and MNP or V.42 modems may be dialing in. In these cases, noise or MNP/V.42 packets might be interpreted as usernames and passwords, causing authentication failure before the user can type a username/password. The command is not useful on nonmodem lines or lines without some kind of login configured.
You can configure the Cisco IOS software to set the TCP window to zero (0) when the Telnet connection is idle. To do so, perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Set the TCP window to zero when the Telnet connection is idle. | service telnet-zero-idle |
Normally, data sent to noncurrent Telnet connections is accepted and discarded. When service telnet-zero-idle is enabled, if a session is suspended (that is, some other connection is made active or the EXEC is sitting in command mode), the TCP window is set to zero. This action prevents the remote host from sending any more data until the connection is resumed. Use this command when it is important that all messages sent by the host be seen by the users and the users are likely to use multiple sessions. Do not use this command if your host will eventually time out and log out a TCP user whose window is zero.
Accounting management allows you to track individual and group usage of network resources. You can then reallocate resources as needed. The following sections describe accounting management tasks:
Additional tasks for measuring system resources are covered in other chapters in the Cisco IOS Software configuration guides. For example, IP accounting tasks are described in the "Configuring IP" chapter in the Network Protocols Configuration Guide, Part 1.
You can use the TACACS protocol for enhanced accounting functionality. To do so, perform the following tasks in global configuration mode.
| Task | Command |
|---|---|
| Display information about the types of AAA Accounting that are enabled for your access server or router. | debug aaa accounting |
| Step through all active sessions to print all the accounting records for the actively accounted functions. | show accounting |
The aaa accounting command allows you to set start-stop accounting for any or all of the listed functions for this command. For minimal accounting control, use the stop-only keyword, which instructs TACACS+ to send a stop record accounting notice at the end of the requested user process. For additional accounting control, you can use the start-stop keyword, which instructs TACACS+ to send a start accounting notice at the beginning of the requested process and a stop accounting notice at the end of the process. You can further control access and accounting by use the wait-start keyword, which ensures that the TACACS+ server receives the start notice before granting the user's process request. Accounting is done only to the TACACS+ server.
Before using the aaa accounting command, you must initialize AAA/TACACS+ as described in the "Enable AAA/TACACS+ and Set Authentication Key" section earlier in this chapter.
Perform the following task in global configuration mode:
| Task | Command |
|---|---|
| Enable accounting. | aaa accounting {system | network | connection | exec | command level} {start-stop | wait-start | stop-only} tacacs+ |
You can display stack utilization of processes and interrupt routines, including the reason for the last system reboot. This feature is useful to Cisco engineers for analyzing system crashes. It is included here in case you need to read the displayed statistics to an engineer over the phone. To display stack utilization, perform the following task in EXEC mode:
| Task | Command |
| Display stack utilization of processes and interrupt routines. | show stacks |
To display memory usage information, perform the following tasks in EXEC mode:
In addition to providing basic IP accounting functions, Cisco's IP accounting support provides information identifying IP traffic that fails IP access lists. Identifying IP source addresses that violate IP access lists alerts you to possible attempts to breach security. The data also indicates that you should verify IP access list configurations.
To make this feature available to users, you must first enable IP accounting. Users can then display the number of bytes and packets from a single source that attempted to breach security against the access list for the source destination pair.
The IP accounting access violations output displays the number of the access list failed by the last packet for the source and destination pair. The number of packets reveals how aggressive the attack is upon a specific destination.
By default, IP accounting displays the number of packets that have passed access lists and were routed. To enable IP accounting, perform the following task for each interface in interface configuration mode:
| Task | Command |
|---|---|
| Enable IP accounting. | ip accounting1 |
To display IP access violations for a specific IP accounting database, perform the following task in EXEC mode:
| Task | Command |
|---|---|
| Display IP access-violation information. | show ip accounting access-violations |
The following sections provide system management examples:
The following is an example of a typical system configuration file:
! Define line password line 0 4 password secret login ! ! Define privileged-level password enable-password Secret Word ! ! Define a system hostname hostname TIP ! Define host filenames boot host host1-confg 131.108.1.111 boot host host2-confg 131.108.1.111 ! Define system filenames boot system sys1-system 131.108.13.111 boot system sys2-system 131.108.1.111 ! ! Enable SNMP snmp-server community snmp-server trap-authentication snmp-server host 131.108.1.27 public snmp-server host 131.108.1.111 public snmp-server host 131.108.2.63 public ! ! Define TACACS server hosts tacacs-server host 131.108.1.27 tacacs-server host 131.108.13.33 tacacs-server host 131.108.1.33 ! ! Define a message-of-the-day banner banner motd ^C The Information Place welcomes you Please call 1-800-555-2222 for a login account, or enter your password at the prompt. ^C
In the following example, a Cisco 7000 has server associations with two other systems, transmits broadcast NTP packets, periodically updates the Cisco 7000 calendar, and redistributes time into VINES:
clock timezone PST -8 clock summer-time PDT recurring ntp update-calendar ntp server 131.108.13.57 ntp server 131.108.11.58 interface Ethernet 0/0 ntp broadcast vines time use-system
In the following example, a Cisco 7000 has no outside time source, so it uses the calendar as an authoritative time source and distributes the time via NTP broadcast packets.
clock timezone MET 2 clock calendar-valid ntp master interface fddi 0/0 ntp broadcast
To define CISCO.COM as the default Kerberos realm, use the following command:
kerberos local-realm CISCO.COM
To tell the router that the CISCO.COM KDC is running on host 1.2.3.4 at port number 170, use the following Kerberos command:
kerberos server CISCO.COM 1.2.3.4 170
To map the DNS domain cisco.com to the Kerberos realm CISCO.COM, use the following command:
kerberos realm .cisco.com CISCO.COM
To specify Kerberos as the authentication method, use the following command:
aaa authentication login default krb5
Use the following command to specify Kerberos authentication for PPP:
aaa authentication ppp default krb5
This section provides examples of using multiple privilege levels to specify who can access different sets of commands.
If you want to allow users to clear lines, you can do either of the following:
privilege exec level 1 clear line
enable password level 2 pswd2
privilege exec level 2 clear line
In the following example, you define an enable password for privilege level 10 for system operators and make clear and debug commands available to anyone with that privilege level enabled.
enable password level 10 pswd10 privilege exec level 10 clear line privilege exec level 10 debug ppp chap privilege exec level 10 debug ppp error privilege exec level 10 debug ppp negotiation
The following example lowers the privilege level of show running-config and most configuration commands to operator level so that the configuration can be viewed by an operator, but leaves the privilege level of the configure command at 15 so an operator cannot change the configuration. Unless the privilege level for the individual configuration commands has been lowered to level 10, they will not be displayed in the show running-config output. The user is only allowed to see commands that have a privilege level less than or equal to the user's current privilege level.
enable password level 15 pswd15 privilege exec level 15 configure enable password level 10 pswd10 privilege exec level 10 show running-config
In the following example, the show ip route command is set to privilege level 15. In order to keep all show ip and show commands from also being set to privilege level 15, these commands are specified to be privilege level 1.
privilege exec level 15 show ip route privilege exec level 1 show ip privilege exec level 1 show
The following example instructs the system to keep at least 50 small buffers free:
buffers small min-free 50
The following example instructs the system to keep no more than 200 medium buffers free:
buffers middle max-free 200
The following example instructs the system to create one large temporary extra buffer, just after a reload:
buffers large initial 1
The following example instructs the system to create one permanent huge buffer:
buffers huge permanent 1
The following example enables the rmon event command:
rmon event 1 log trap eventtrap description "High ifEntry" owner sdurham
This example creates RMON event number 1, which is defined as High ifEntry, and generates a log entry when the event is triggered by an alarm. The user sdurham owns the row that is created in the event table by this command. This example also generates a Simple Network Management Protocol (SNMP) trap when the event is triggered.
The following example configures an RMON alarm using the rmon alarm command:
rmon alarm 10 ifEntry.20.1 20 delta rising-threshold 15 1 falling-threshold 0 owner jjohnson
This example configures RMON alarm number 10. The alarm monitors the MIB variable ifEntry.20.1 once every 20 seconds until the alarm is disabled, and checks the change in the variable's rise or fall. If the ifEntry.20.1 value shows a MIB counter increase of 15 or more, such as from 100000 to 100015, the alarm is triggered. The alarm in turn triggers event number 1, which is configured with the rmon event command. Possible events include a log entry or an SNMP trap. If the ifEntry.20.1 value changes by 0, the alarm is reset and can be triggered again.
The following example shows TACACS enabled for PPP authentication:
int async 1 ppp authentication chap ppp use-tacacs
The following example shows TACACS enabled for ARAP authentication:
line 3 arap use-tacacs
The following example creates a default AAA authentication algorithm used with the ARA protocol:
aaa authentication arap default if-needed none
The following example creates the same authentication algorithm for the ARA protocol but calls the list MIS-access:
aaa authentication arap MIS-access if-needed none
The following example allows network authorization using TACACS+:
aaa authorization network tacacs+
The following example provides the same authorization, but also creates address pools called mci and att.
aaa authorization network tacacs+ ip address-pool local ip local-pool mci 172.16.0.1 172.16.0.255 ip local-pool att 172.17.0.1 172.17.0.255
These address pools can then be selected by the TACACS daemon. A sample configuration of the daemon follows:
user = mci_customer1 {
login = cleartext "some password"
service = ppp protocol = ip {
addr-pool=mci
}
}
user = att_customer1 {
login = cleartext "some other password"
service = ppp protocol = ip {
addr-pool=att
}
}
The following sample configuration sets up secret passwords on Routers A, B, and C, thus enabling the three routers to connect to each other.
To authenticate connections between Routers A and B, enter the following commands:
On Router A:
username B password a-b_secret
On Router B:
username A password a-b_secret
To authenticate connections between Routers A and C, enter the following commands:
On Router A:
username C password a-c_secret
On Router C:
username A password a-c_secret
To authenticate connections between Routers B and C, enter the following commands:
On Router B:
username C password b-c_secret
On Router C:
username B password b-c_secret
When you specify an encryption type of 0 to enter an unencrypted password, the system displays the encrypted version of the password. For example, suppose you enter the following command:
username bill password westward
The system displays this command like this:
username bill password 7 21398211
The encrypted version of the password is 21398211. The password was encrypted by the Cisco-defined encryption algorithm, as indicated by the "7."
However, if you enter the following command, the system determines that the password is already encrypted and performs no encryption. Instead, it displays the command exactly as you typed it:
username bill password 7 21398211username bill password 7 21398211
The following example shows how to configure lock-and-key access. In this example, login is on TACACS+ server, so no autocommand command appears in this configuration. Lock-and-key access is configured on the BRI0 interface. Four VTY ports are defined with the password "cisco."
aaa authentication login default tacacs+ enable aaa accounting exec stop-only tacacs+ aaa accounting network stop-only tacacs+ enable password ciscotac ! isdn switch-type basic-dms100 ! interface ethernet0 ip address 185.302.23.9 255.255.255.0 !! interface BRI0 ip address 185.302.21.1 255.255.255.0 encapsulation ppp dialer idle-timeout 3600 dialer wait-for-carrier-time 100 dialer map ip 185.302.21.2 name diana dialer-group 1 isdn spid1 2036333715291 isdn spid2 2036339371566 ppp authentication chap ip access-group 102 in ! access-list 102 dynamic testlist timeout 5 permit ip any any access-list 102 permit tcp any host 185.302.21.2 eq 23 ! ! ip route 185.302.250.0 255.255.255.0 185.302.21.2 priority-list 1 interface BRI0 high tacacs-server host 185.302.23.21 tacacs-server host 185.302.23.14 tacacs-server key test1 tftp-server rom alias all ! dialer-list 1 protocol ip permit ! line con 0 password cisco line aux 0 line VTY 0 4 password cisco !
|
|