|
|
This chapter describes the basic tasks that you can do to manage the general system (or nonprotocol-specific) features. Our 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 the router. 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 graphical user interface that is menu driven and provides support for 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. For more information, see the CiscoWorks User Guide.
The Cisco Configuration Builder application, based on an MS-Windows graphical user interface, also streamlines the process of configuring Cisco routers. The Cisco Configuration Builder offers a guided configuration capability, so that as you complete the first configuration step, you are automatically led through the correct order of remaining steps needed to complete configuration of each feature or protocol. In addition, the Cisco Configuration Builder provides an online help system for easy access to information. See the Cisco Configuration Builder Getting Started Guide for more information.
For a list of recommended books on network management, refer to the appendix "References and Recommended Reading" in the Router Products Command Reference publication.
For a complete description of the commands mentioned in this chapter, refer to the "System Management Commands" chapter of the Router Products Command Reference publication.
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."
By default, the router 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 router prompt, perform the following task in global configuration mode:
| Task | Command |
|---|---|
Customize the router prompt. | prompt string |
One of the first basic tasks is to name your router. The name of the router is considered the host name and is the name that is displayed by the system prompt. If no name is configured, the system default router name is Router. You can name the router while in global configuration mode as follows:
| Task | Command |
|---|---|
Set the host name. | hostname name |
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 of our router products 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 router 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 internally keeps track of time 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.
Our implementation of NTP does not support stratum 1 service; in other words, it is not possible to connect a radio or atomic clock to this router. 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, our 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 will 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 will override 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. Our 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 router 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 router output is displayed on the console or printed after solicited router 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 router 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 router 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] |
| 1This command is documented in the "Terminal Line and Modem Support Commands" chapter of the Router Products Command Reference publication. |
NTP services are enabled on all interfaces by default. The ptional subtasks 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, then this system will be willing 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:
| Task | Command |
|---|---|
Step 1. Enable the NTP authentication feature. | |
Step 2. Define the authentication keys. | ntp authentication-key number md5 value |
Step 3. Define trusted authentication keys. | ntp trusted-key key-number |
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 this system will only 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:
| Task | Command |
|---|---|
Form a peer association with another system. or Form a server association with another system. | ntp peer ip-address [version number] [key keyid] [source interface] [prefer]
ntp server ip-address [version number] [key keyid] [source interface] [prefer] |
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. | |
Adjust estimated delay. |
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:
1. Peer—Allows time requests and NTP control queries and allows the system to synchronize itself to a system whose address passes the access list criteria.
2. Serve—Allows time requests and NTP control queries, but does not allow the system to synchronize itself to a system whose address passes the access list criteria.
3. Serve-only—Allows only time requests from a system whose address passes the access list criteria.
4. Query-only—Allows only NTP control queries from a system whose address passes the access list criteria.
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. |
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] |
 | Caution Use this command with extreme caution. It is very easy to override valid time sources using this command, especially if a low stratum number is configured. Configuring multiple machines in the same network with the ntp master command can cause instability in timekeeping if the machines do not agree on the time. |
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. |
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. |
| 1This command is documented in the "Banyan VINES Commands" chapter of the Router Products Command Reference publication. |
To receive VINES time service to control the system clock, perform the following task in global configuration mode:
| Task | Command |
|---|---|
Receive VINES time service. |
| 1This command is documented in the "Banyan VINES Commands" chapter of the Router Products Command Reference publication. |
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. 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 router:
| Task | Command |
|---|---|
Set the router 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:
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 router 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 router 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 router's 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. |
For an example of making the router's 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. |
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. |
To monitor clock, calendar, and NTP EXEC services, complete the following tasks in EXEC mode:
| Task | Command |
|---|---|
Display the current calendar time (for the Cisco 4500 and Cisco 7000 only). | |
Display the current system clock time. | show clock [detail] |
Show the status of NTP associations. | show ntp associations [detail] |
Show the status of NTP. |
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:
| Task | Command |
|---|---|
Access minor TCP services such as echo, chargen, discard, and daytime. | |
Access minor UDP services such as echo, chargen, and discard. | |
Access the BOOTP service. |
| Task | Command |
|---|---|
Enable the Finger protocol requests. |
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. |
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. In configuring SNMP on the router, you define the relationship between the manager and the agent.
An agent can also 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 5-1 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. Our implementation of SNMP supports all MIB II variables (as described in RFC 1213) and SNMP traps (as described in RFC 1215). Cisco also supports the definition of management information described in RFCs 1155, 1157, and 1213, and supports some or all variables in the MIBs described in the following RFCs: 1156, 1212, 1231, 1243, 1285, 1286, 1315, 1381, 1382, 1398, 1447, 1450, and 1285 (FDDI).
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. The Cisco MIB provides a new chassis MIB variable that enables the SNMP manager to gather data on system card descriptions, serial numbers, hardware and software revision levels, and slot locations.
See the Cisco Management Information Base (MIB) User Quick Reference for a detailed description of each Cisco MIB variable and SNMP trap.
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 router to support communications with one management station using the SNMPv1 protocol and another using the SNMPv2 protocol.
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. |
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. |
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. |
| 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 5-2 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 on the router, you perform the following tasks:
After you create a record, you can modify the record's contents, changing one or more of the record values. To do this, you 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. |
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 create or modify an SNMPv2 party record, perform the following task in global configuration mode
| Task | Command |
|---|---|
Create or modify a party record. | snmp-server party party-name party-oid |
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 |
A trap is an unsolicited message sent by an SNMP agent to an SNMP manager indicating that some event has occurred. The SNMP trap operations allow you to configure the router to send information to a network management application when a particular event occurs. You can specify the following features for SNMPv2 agent trap operations:
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 define traps for the agent to send to the manager, perform one or more of the following tasks in global configuration mode:
| Task | Command |
|---|---|
Specify the source interface (and hence IP address) of the trap message. | snmp-server trap-source interface |
Specify the access policy that defines the traps that the agent can send to the manager. | snmp-server access-policy destination-party source-party context privileges |
Specify the recipient of the trap message. | snmp-server host address community-string [trap-type] |
Establish trap message authentication. | snmp-server trap-authentication [snmpv1 | snmpv2] |
Specify the types of traps sent. | |
Define how often to resend trap messages on the retransmission queue. | snmp-server trap-timeout seconds |
snmp-server queue-length length |
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 SNMPv" section to configure the router to send SNMP traps.
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] |
You can configure one or more community strings. To remove a specific community string, use the no snmp-server community command.
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. |
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. |
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 |
To remove a party record, use the no snmp-server party command.
| Task | Command |
|---|---|
Create an access policy. | snmp-server access-policy destination-party source-party context privileges |
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 a manager when a particular event occurs. You can specify the following features for SNMP server trap operations:
Perform the following tasks in global configuration mode to define traps for the agent to send to the specified manager:
| Task | Command |
|---|---|
Specify the source interface (and hence IP address) of the trap message. | snmp-server trap-source interface |
Specify the recipient of the trap message. | snmp-server host address community-string [trap-type] |
Establish trap message authentication. | |
Specify the types of traps sent. | |
Define how often to resend trap messages on the retransmission queue. | snmp-server trap-timeout seconds |
Establish the message queue length for each trap host. | snmp-server queue-length length |
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.
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 try 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 try to 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:
| Task | Command |
|---|---|
Specify frequency of transmission of CDP updates. | cdp timer seconds |
Specify the amount of time a receiving device should hold the information sent by your device before discarding it. | cdp holdtime seconds |
CDP is enabled by default. To disable CDP and later reenable it, perform the following tasks in global configuration mode:
| Task | Command |
|---|---|
Disable CDP. | |
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 CDP on an interface, perform the following task in interface configuration mode:
| Task | Command |
|---|---|
Disable CDP on an interface. | |
Enable CDP on an interface. |
To monitor and maintain CDP on your device, perform the following tasks in privileged EXEC mode:
| Task | Command |
|---|---|
Reset the traffic counters to zero. | |
Delete the CDP table of information about neighbors. | |
Display global information such as frequency of transissions and the holdtime for packets being transmitted. | |
Display information about a specific neighbor. Display can be limited to protocol or version information. | |
Display informaton about interfaces on which CDP is enabled. | |
Display information about neighbors. The display can be limited to neighbors on a sepcific interface, and expanded to provide more detailed information. | show cdp neighbors [type number] [detail] |
Display CDP counters, including the number of packets sent and received and checksum errors. | |
Display information about the types of debugging that are enabled for your router. See the Debug Command Reference publication for more information about CDP debug commands. |
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 this guide provide information on protocol-specific security features. The Configuring Interfaces" chapter provides information on CHAP, an additional authentication feature. Another example is the IP Security Option (IPSO) feature described in the chapter entitled "Configuring IP." Finally, see the separate protocol chapters for information about how to create access lists.
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 | Command1 |
|---|---|
Step 1. Assign a password to a terminal or other device on a line. | password password |
Step 2. Enable password checking at login. |
| 1These commands are documented in the "Terminal Line and Modem Support Commands" chapter of the Router Products Command Reference publication. |
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.
You can control access to the system by setting a password that must be entered to gain access to the privileged-level prompt, and therefore to the system configuration. Perform the following task in global configuration mode:
| Task | Command |
|---|---|
Establish a password for the privileged command level. | enable password password |
You can increase access security to your router by configuring it to encrypt passwords because protocol analyzers can examine packets. Encryption prevents the password from being visible in the configuration file.
Configure the router to encrypt passwords by performing the following task in global configuration mode:
| Task | Command |
|---|---|
Encrypt a password. |
It is not possible to recover a lost encrypted password.
By default, the router has two levels of password security, user level and privileged, or enabled, level. You can configure up to sixteen hierarchical levels of security on a router. 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 restriced 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 tasks in global configuration mode:
| Task | Command |
|---|---|
Set the privilege level for a command. | privilege mode level level command |
Specify the enable password for a privilege level. | enable password level level [encryption-type] password |
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. |
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. |
| 1This command is documented in the "User Interface Commands" chapter of the Router Products Command Reference. |
To exit to a specified privilege level, perform the following task in EXEC mode:
| Task | Command |
|---|---|
Exit to a specfied privilege level. |
| 1This command is documented in the "User Interface Commands" chapter of the Router Products Command Reference. |
To provide an additional level of password security, especially useful when a password crosses a network or is stored on a TFTP server, perform the following tasks in global configuration mode:
| Task | Command |
|---|---|
Establish a password for the privileged command level. | enable password password |
Specify a secret password, saved using a non-reversible encryption method. When both the enable password and enable secrets are set, this is the password the user will be enter. | enable secret password |
You cannot recover a lost encrypted password.
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 |
| 1This command is documented in the "Terminal Line and Modem Support Commands" chapter of the Router Products Command Reference publication. |
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 will put the router in the ROM monitor mode indicated by the prompt ">".
Step 3 Examine and note the value in the configuration register:
> o
Step 4 From the ROM monitor prompt, >, type o/r.
This will put the value 0x141 into the configuration register.
Step 5 Initialize and boot the router:
> i
Step 6 Answer NO to all the SETUP questions. Then you should end up with the following prompt:
Router(boot)>
Step 7 Enter privileged mode by entering the enable command. No password is required and the prompt will change to Router(boot)#.
Router(boot)> enable Router(boot)#
Step 8 Use the show configuration command to see the enable password.
Router(boot)# show configuration
Step 9 Restore the configuration register to its original value (as recorded earlier) using the configuration command:
Router(boot)# config-register 0xoriginal values
Step 10 Reload and boot the router using the reload command:
Router(boot)# 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 You will be asked if you want to set the manufacturers' addresses. Respond by typing Yes. You will then see the following prompt:
TEST-SYSTEM>
Step 2 Type the enable command to get the privileged prompt:
TEST-SYSTEM> enable
Step 3 Type the show configuration command to review the system configuration and find the password. Do not change anything in the factory diagnostic mode.
TEST-SYSTEM> show configuration
Step 4 To resume normal operation, restart the server and/or reset the configuration register.
Step 5 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 5-1 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 3000, Cisco 4000, 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 chapter in this guide for detailed task information on each protocol-specific access list. To control SNMP access, see "Configure SNMPv2 Support" earlier in this chapter. Also refer to the appropriate protocol-specific chapters of the Router Products Command Reference publication.
Table 5-2 provides the protocols that have access lists specified by names.
| Protocol |
|---|
Apollo Domain |
ISO CLNS |
Source-route bridging NetBIOS |
NetBIOS IPX |
Table 5-3 provides the protocols that have access lists specified by numbers and provides the corresponding numerical ranges.
| Protocol | Range |
|---|---|
IP | 1-99 |
Extended IP | 100-199 |
Transparent bridging (protocol type) | 200-299 |
Transparent bridging (vendor code) | 700-799 |
Extended transparent bridging | 1100-1199 |
DECnet and extended DECnet | 300-399 |
XNS | 400-499 |
Extended XNS | 500-599 |
AppleTalk | 600-699 |
Source-route bridging (protocol type) | 200-299 |
Source-route bridging (vendor code) | 700-799 |
IPX | 800-899 |
Extended IPX | 900-999 |
IPX SAP | 1000-1099 |
Standard VINES | 1-100 |
Extended VINES | 101-200 |
Simple VINES | 201-300 |
You can configure the router 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+. All three versions provide additional control over servers that run on a timesharing system. TACACS services are provided by and maintained in a database on the TACACS server. Our basic TACACS support is modeled after the original Defense Data Network (DDN) application.
A comparative description of the supported versions follows. Table 5-4 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 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 |
|
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 |