- Cisco IOS XE Network Management Configuration Guide, Release 2
Table Of Contents
Performing Basic System Management
Basic System Management Task List
Creating and Displaying Command Aliases
Controlling the Finger Protocol
Setting Time and Calendar Services
Configuring Poll-Based NTP Associations
Configuring Broadcast-Based NTP Associations
Configuring an NTP Access Group
Configuring NTP Authentication
Disabling NTP Services on a Specific Interface
Configuring the Source IP Address for NTP Packets
Configuring the System as an Authoritative NTP Server
Configuring Time and Date Manually
Configuring Summer Time (Daylight Savings Time)
Manually Setting the Software Clock
Monitoring Time and Calendar Services
Handling an Idle Telnet Connection
Setting the Interval for Load Data
Limiting the Number of TCP Transactions
Configuring Switching and Scheduling Priorities
Modifying the System Buffer Size
Feature Information for Performing Basic System Management
Performing Basic System Management
Last Updated: February 28, 2009This chapter describes the basic tasks that you can perform to manage the general system features of the Cisco IOS XE software—those features that are generally not specific to a particular protocol.
Finding Feature Information
For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Performing Basic System Management" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS XE software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Basic System Management Task List
•
Basic System Management Task List
To customize the general functionality of your system, perform any of the tasks in the following sections. All tasks in this chapter are optional, though some, such as setting time and calendar services, are highly recommended.
•
•
•
•
•
•
•
•
•
Configuring the System Name
The most basic system management task is to assign a name to your system (router, access server, switch, and so on). The system name, also called the host name, is used to identify the system in your network. The system name is displayed at the CLI prompt. If no name is configured, the system default name is Router. To configure a name for your device, use the following command in global configuration mode:
For more information about Cisco IOS XE commands, see the "Additional References" section.
Customizing the CLI Prompt
By default, the CLI prompt consists of the system name followed by an angle bracket (>) for EXEC mode or a pound sign (#) for privileged EXEC mode. To customize the CLI prompt for your system, use either of the following commands in global configuration mode, as needed:
Router(config)# prompt string
Customizes the CLI prompt.
Router(config)# no service prompt config
Removes the configuration prompt (config).
For more information about Cisco IOS XE commands, see the "Additional References" section.
Creating and Displaying Command Aliases
Command aliases allow you to configure alternative syntax for commands. You may want to create aliases for commonly used or complex commands. For example, you could assign the alias save config to the copy running-config startup-config command to reduce the amount of typing you have to perform, or if your users might find a save config command easier to remember. Use word substitutions or abbreviations to tailor command syntax for you and your user community.
To create a command alias, use the following command in global configuration mode:
Router(config)# alias mode alias-name alias-command-line
Configures a command alias.
To display a list of command aliases currently configured on your system, and the original command syntax for those aliases, use the following command in EXEC mode:
Router# show aliases [mode]
Displays all command aliases and original command syntax, or displays the aliases for only a specified command mode.
Keep in mind that any aliases you configure will only be effective on your system, and that the original command syntax will appear in the configuration file.
For more information about Cisco IOS XE commands, see the "Additional References" section.
Controlling Minor Services
The minor services are "small servers" that run on your routing device and are useful for basic system testing and for providing basic network functions. Minor services are useful for testing connections from another host on the network.
Cisco small servers are conceptually equivalent to daemons.
The TCP small server provides the following minor services:
Echo—Echoes back whatever you type. To test this service, issue the telnet a.b.c.d echo command from a remote host.
Chargen—Generates a stream of ASCII data. To test this service, issue the telnet a.b.c.d chargen command from a remote host.
Discard—Discards whatever you type. To test this service, issue the telnet a.b.c.d discard command from a remote host.
Daytime—Returns system date and time if you have configured NTP or have set the date and time manually. To test this service, issue the telnet a.b.c.d daytime command from a remote host.
The User Datagram Protocol (UDP) small server provides the following minor services:
Echo—Echoes the payload of the datagram you send.
Chargen—Discards the datagram you send and responds with a 72 character string of ASCII characters terminated with a CR+LF (carriage return and line feed).
Discard—Silently discards the datagram you send.
To enable TCP or UDP services, use the following commands in global configuration mode, as needed:
Because the minor services can be misused, these commands are disabled by default.
Caution
Note that the no form of the service tcp-small-servers and service udp-small-servers commands will appear in the configuration file to inform you when these basic services are disabled.
For more information about Cisco IOS XE commands, see the "Additional References" section.
Controlling the BOOTP Server
You can enable or disable an async line Bootstrap Protocol (BOOTP) service on your routing device. This small server is enabled by default. Due to security considerations, this service should be disabled if you are not using it. To disable the BOOTP server on your platform, use the following command in global configuration mode:
Because Dynamic Host Configuration Protocol (DHCP) is based on the Bootstrap Protocol, both of these service share the "well-known" UDP server port of 67 (per the internet standards and RFCs). For more information about BOOTP, see RFC 951. Interoperation between BOOTP and DHCP is defined in RFC 1534. DHCP is defined in RFC 2131. To disable DHCP services (DHCP relay and DHCP server), use the no service dhcp command. To disable BOOTP services, but leave DHCP services enabled, use the ip dhcp bootp ignore command.
Controlling the Finger Protocol
The Finger protocol allows users throughout the network to get a list of the users currently using a particular routing device. The information displayed includes the line number, connection name, idle time, and terminal location. This information is provided through the Cisco IOS XE software show users EXEC command.
To enable a Cisco device to respond to Finger (port 79) requests, use the following command in global configuration mode:
Router(config)# ip finger
Enables the Finger protocol service, which allows the system to respond to finger requests.
To configure the finger protocol to be compliant with RFC 1288, use the following command in global configuration mode:
Router(config)# ip finger rfc-compliant
Configures the device to wait for "Return" or "/W" input when processing Finger requests.
The difference between the two forms of this command is as follows: when the ip finger command is configured, the router will respond to a telnet a.b.c.d finger command from a remote host by immediately displaying the output of the show users command and then closing the connection. When the ip finger rfc-compliant command is configured, the router will wait for input before displaying anything. The remote user can then press the Return key to display the output of the show users command, or enter /W to display the output of the show users wide command. After this information is displayed, the connection is closed.
Hiding Telnet Addresses
You can hide addresses while attempting to establish a Telnet session. To configure the router to suppress Telnet addresses, use the following command in global configuration mode:
Router(config)# ip telnet hidden {addresses | hostnames}
Hides IP address or host name information when a Telnet session is established.
The hide feature suppresses the display of the address and continues to display all other messages that normally would be displayed during a connection attempt, such as detailed error messages if the connection failed.
Use the busy-message line configuration command with the service hide-telnet-address command to customize the information displayed during Telnet connection attempts. If the connection attempt fails, the router suppresses the address and displays the message specified with the busy-message command.
For more information about Cisco IOS XE commands, see the "Additional References" section.
Setting Time and Calendar Services
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 devices to the same time, and to provide time services to other systems. The following sections describe the concepts and task associated with time and calendar services:
•
•
Understanding Time Sources
The primary source for time data on your system is the software clock. This clock runs from the moment the system starts up and keeps track of the current date and time. The software 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 a router with a hardware clock is initialized or rebooted, the software clock is initially set based on the time in the hardware clock. The software clock can then be updated from the following sources:
•
•
Because the software clock can be dynamically updated it has the potential to be more accurate than the hardware clock.
The software clock can provide time to the following services:
•
•
•
•
The software 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 software clock keeps track of whether the time is "authoritative" (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.
Network Time Protocol
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 Version 3 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 the accuracy of 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 typically has an authoritative time source (such as a radio or atomic clock, or a GPS time source) directly attached, a "stratum 2" time server receives its time via NTP from a "stratum 1" time server, and so on.
NTP avoids synchronizing to a machine whose time may not be accurate in two ways. First, NTP will never synchronize to a machine that is not in turn synchronized itself. Second, 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. This strategy effectively builds a self-organizing tree of NTP servers.
The Cisco implementation of NTP does not support stratum 1 service; in other words, it is not possible to connect to a radio or atomic clock (for some specific platforms, however, you can connect a GPS time-source device). We recommend 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, the Cisco 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 can then synchronize to that machine via NTP.
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 also allows UNIX-derivative servers to acquire the time directly from an atomic clock which would subsequently propagate time information along to Cisco routers.
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 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.
When multiple sources of time (VINES, hardware clock, manual configuration) are available, NTP is always considered to be more authoritative. NTP time overrides the time set by any other method.
Configuring NTP
NTP services are disabled on all interfaces by default. The following sections contain optional tasks that you can perform on your networking device:
•
•
•
•
•
•
•
Configuring Poll-Based NTP Associations
Networking devices running NTP can be configured to operate in variety of association modes when synchronizing time with reference time sources. There are two ways that a networking device can obtain time information on a network: by polling host servers and by listening to NTP broadcasts. In this section, we will focus on the poll-based association modes. Broadcast-based NTP associations will be discussed in the next section.
The following are two most commonly used, poll-based association modes:
•
•
The client and the symmetric active modes should be used when NTP is required to provide a high level of time accuracy and reliability.
When a networking device is operating in the client mode, it polls its assigned time serving hosts for the current time. The networking device will then pick a host from all the polled time servers to synchronize with. Since the relationship that is established in this case is a client-host relationship, the host will not capture or use any time information sent by the local client device. This mode is most suited for file-server and workstation clients that are not required to provide any form of time synchronization to other local clients. Use the ntp server command to individually specify the time serving hosts that you want your networking device to consider synchronizing with and to set your networking device to operate in the client mode.
When a networking device is operating in the symmetric active mode, it polls its assigned time serving hosts for the current time and it responds to polls by its hosts. Since this is a peer-to-peer relationship, the host will also retain time-related information about the local networking device that it is communicating with. This mode should be used when there is a number of mutually redundant servers that are interconnected via diverse network paths. Most Stratum 1 and stratum 2 servers on the Internet today adopt this form of network setup. Use the ntp peer command to individually specify the time serving hosts that you want your networking device to consider synchronizing with and to set your networking device to operate in the symmetric active mode.
The specific mode that you should set each of your networking devices to depends primarily on the role that you want it to assume as a timekeeping device (server or client) and its proximity to a stratum 1 timekeeping server.
A networking device engages in polling when it is operating as a client or a host in the client mode or when it is acting as a peer in the symmetric active mode. Although polling does not usually exact a toll on memory and CPU resources such as bandwidth, an exceedingly large number of ongoing and simultaneous polls on a system can seriously impact the performance of a system or slow the performance of a given network. To avoid having an excessive number of ongoing polls on a network, you should limit the number of direct, peer-to-peer or client-to-server associations. Instead, you should consider using NTP broadcasts to propagate time information within a localized network.
Note that only one end of an association needs to be configured; the other system will automatically establish the association.
Caution
Configuring Broadcast-Based NTP Associations
Note
Broadcast-based NTP associations should be used when time accuracy and reliability requirements are modest and if your network is localized and has a large number of clients (more than 20). Broadcast-based NTP associations is also recommended for use on networks that have limited bandwidth, system memory, or CPU resources.
When a networking device is operating in the broadcastclient mode, it does not engage in any polling. Instead, it listens for NTP broadcast packets transmitted by broadcast time servers. Consequently, time accuracy can be marginally reduced since time information flows only one way.
Use the ntp broadcast client command to set your networking device to listen for NTP broadcast packets propagated through a network. In order for broadcastclient mode to work, the broadcast server and its clients must be located on the same subnet. The time server that is transmitting NTP broadcast packets will also have to be enabled on the interface of the given device using the ntp broadcast command.
To configure an interface to send NTP broadcasts, use the following command in interface configuration mode:
Router(config-if)# ntp broadcast [version number]
Configures the specified interface to send NTP broadcast packets.
To configure an interface to receive NTP broadcasts, use the following command in interface configuration mode:
Router(config-if)# ntp broadcast client
Configures the specified interface to receive NTP broadcast packets.
To manually set the estimated round-trip delay between the device and the NTP broadcast server, use the following command in global configuration mode:
Router(config)# ntp broadcastdelay microseconds
Adjusts the estimated round-trip delay for NTP broadcasts.
Caution
Configuring an NTP Access Group
The access list-based restriction scheme allows you to grant or deny certain access privileges to an entire network, a subnet within a network, or a host within a subnet. To define an NTP access group, use the following command in global configuration mode:
Router(config)# ntp access-group {query-only | serve-only | serve | peer} access-list-number
Creates an access group and applies a basic IP access list to it.
The access group options are scanned in the following order, from least restrictive to most restrictive:
1.
2.
3.
4.
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).
Configuring NTP Authentication
The encrypted NTP authentication scheme should be used when a reliable form of access control is required. Unlike the access list-based restriction scheme which is based on IP addresses, the encrypted authentication scheme uses authentication keys and an authentication process to determine if NTP synchronization packets sent by designated peers or servers on a local network are deemed as trusted before the time information that it carries along with it, is accepted.
The authentication process begins from the moment an NTP packet is created. Cryptographic checksum keys are generated using the MD5 Message Digest Algorithm and are embedded into the NTP synchronization packet that is sent to a receiving client. Once a packet is received by a client, its cryptographic checksum key is decrypted and checked against a list of trusted keys. If the packet contains a matching authenticator key, the timestamp information that is contained within it is accepted by the receiving client. NTP synchronization packets that do not contain a matching authenticator key will be ignored.
It is important to note that the encryption and decryption processes used in NTP authentication can be very CPU-intensive and can seriously degrade the accuracy of the time that is propagated within a network. If your network setup permits a more comprehensive model of access control, you should consider the use of the access list-based form of control instead.
After NTP authentication is properly configured, your networking device will only synchronize with and provide synchronization to trusted time sources. To enable your networking device to send and receive encrypted synchronization packets, use the following commands in global configuration mode:
Disabling NTP Services on a Specific Interface
NTP services are disabled on all interfaces by default.
NTP is enabled globally when any NTP commands are entered. you can selectively prevent NTP packets from being received through a specific interface by using the following command in interface configuration mode to turn off NTP on a given interface:
Configuring the Source IP Address for NTP Packets
When a 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. Use the following command in global configuration mode if you want to use a particular source IP address for all NTP packets:
Use this command when you want to use a particular source IP address for all NTP packets:
Router(config)# ntp source type number
Sets the IP address of the specified interface as the source IP address for all NTP packets.
The IP address of the specified interface will be used as the source IP address for all NTP 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.
Configuring the System as an Authoritative NTP Server
Use the following command 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:
Note
Configuring Time and Date Manually
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 tasks in the following sections as needed. If you have an outside source to which the router can synchronize, you do not need to manually set the software clock.
•
•
Configuring the Time Zone
To manually configure the time zone used by the Cisco IOS XE software, use the following command in global configuration mode:
Tip
Configuring Summer Time (Daylight Savings Time)
To configure summer time (daylight savings time) in areas where it starts and ends on a particular day of the week each year, use the following command in global configuration mode:
If summer time in your area does not follow this pattern, you can configure the exact date and time of the next summer time event by using one of the following commands in global configuration mode:
Manually Setting the Software Clock
Generally, if the system is synchronized by a valid outside timing mechanism, such as an NTP or VINES clock source, or if you have a router with a hardware clock, you need not set the software clock. Use this command if no other time sources are available. The time specified in this command is relative to the configured time zone. To set the software clock manually, use the following command in privileged EXEC mode:
Router# clock set hh:mm:ss date month year
or
Router# clock set hh:mm:ss month date year
Sets the software clock.
Monitoring Time and Calendar Services
To monitor clock and NTP EXEC services, use the following commands in EXEC mode, as needed:
Handling an Idle Telnet Connection
To configure the Cisco IOS XE software to set the TCP window to zero (0) when the Telnet connection is idle, use the following command in global configuration mode:
Router(config)# service telnet-zeroidle
Sets the TCP window to zero when the Telnet connection is 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), 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.
For more information about Cisco IOS XE commands, see the "Additional References" section.
Setting the Interval for Load Data
You can change the period of time over which a set of data is used for computing load statistics. Decisions, such as for dial backup, depend on these statistics. If you decrease the load interval, the average statistics are computed over a shorter period of time and are more responsive to bursts of traffic.
To change the length of time for which a set of data is used to compute load statistics, use the following command in interface configuration mode:
Router(config-if)# load-interval seconds
Sets the length of time for which data is used for load calculations.
For more information about Cisco IOS XE commands, see the "Additional References" section.
Limiting the Number of TCP Transactions
When using a standard TCP implementation to send keystrokes between machines, TCP tends to send one packet for each keystroke typed, which can use up bandwidth and contribute to congestion on larger networks.
John Nagle's algorithm (RFC 896) helps alleviate the small-packet problem in TCP. 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 their transmission to the network at a rate matching the round-trip time of the given connection. This method is usually preferable for all TCP-based traffic.
By default, the Nagle algorithm is not enabled. To enable the Nagle algorithm and thereby reduce the number of TCP transactions, use the following command in global configuration mode:
For more information about Cisco IOS XE commands, see the "Additional References" section.
Configuring Switching and Scheduling Priorities
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 may need to give priority to the system process scheduler. To do so, use the following command in global configuration mode:
Router(config)# scheduler interval milliseconds
Defines the maximum amount of time that can elapse without running the lowest-priority system processes.
To configure the characteristics for a looping process, use the following command in global configuration mode:
Router(config)# scheduler process-watchdog {hang | normal | reload | terminate}
Configures an action for a looping process.
For more information about Cisco IOS XE commands, see the "Additional References" section.
Modifying the System Buffer Size
You can adjust initial buffer pool settings and the limits at which temporary buffers are created and destroyed. To do so, use the following commands in global configuration mode, as needed:
Caution
During normal system operation, there are two sets of buffer pools: public and interface. They behave as follows:
•
•
The server has one pool of queueing 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, use the following commands in EXEC mode, as needed:
For more information about Cisco IOS XE commands, see the "Additional References" section.
Additional References
The following sections provide references related to basic system management.
Related Documents
Cisco IOS XE commands
For information about Cisco IOS XE commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or the Cisco IOS Master Command List, All Releases, at http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html.
Standards
No new or modified standards are supported, and support for existing standards has not been modified.
—
MIBs
RFCs
Technical Assistance
Feature Information for Performing Basic System Management
Table 16 lists the features in this module and provides links to specific configuration information
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS XE software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0812R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2007-2009 Cisco Systems, Inc. All rights reserved.
