|
|
This chapter describes how to configure the TCP/IP protocol for routing and nonrouting connections. You will find the following information in this chapter:
Making Telnet connections is described in the "User Commands" chapter.
The commands to configure IP and the IP services and features are entered in configuration mode, which is privileged. To enter this mode, type the configure command at the EXEC prompt. For more information about the configuration mode, see the "Startup and Basic Configuration" chapter.
A command summary is included at the end of this chapter.
The Internet Protocol (IP) is a packet-based protocol used to exchange data over computer networks. IP handles addressing, fragmentation, reassembly, and protocol demultiplexing. It is the foundation on which all other Internet protocols, collectively referred to as the Internet Protocol suite, are built. IP is a network-layer protocol that contains addressing information and some control information that allows data packets to be routed. IP is documented in RFC 791
The Transmission Control Protocol (TCP) is built upon the IP layer suite. TCP is a connection-oriented protocol that specifies the format of data and acknowledgments used in the transfer of data. TCP also specifies the procedures the computers use to ensure that the data arrives correctly. TCP allows multiple applications on a system to communicate concurrently, because it handles all demultiplexing of the incoming traffic among the application programs.
The Cisco Systems implementation of TCP generally ensures good communication server performance on slow-speed links as well as high-speed LAN links. Cisco's TCP software includes Telnet, a simple remote terminal protocol that is part of the TCP/IP protocol suite. The software provides commands that allow you to turn on or off TCP services such as stream processing and debugging modes for monitoring the connection. Additionally, the software supports rlogin, the BSD UNIX remote login service.
Cisco supports both TCP and UDP at the transport layer for the maximum services options. Some Cisco global and interface commands require UDP packets. (See the section ""Configuring ICMP and Other IP Services"" later in this chapter.) Cisco supports all standards for IP broadcasts.
IP is a network-layer protocol that contains addressing information and some control information that allows data packets to be routed. IP is documented in RFC 791.
In this chapter, the TCP and Telnet options are described first, followed by an overview of IP, including IP addressing, and then descriptions of the commands available for configuring IP.
The Internet Protocol suite includes the simple remote terminal protocol called Telnet. Telnet allows a user at one site to establish a TCP connection to a login server at another site, then passes the keystrokes from one system to the other. Telnet can accept either an Internet address or a domain name as the remote system address. In short, Telnet offers three main services:
The Cisco Systems implementation of Telnet supports the following Telnet options:
The following sections describe how to configure the lines to support Telnet connections. Making Telnet connections is described in the "User Commands" chapter.
This section describes the line subcommands for configuring Telnet protocol-specific lines. For information about the configure and line configuration commands, see the "System Configuration" chapter.
Use the line subcommand telnet speed to negotiate speeds on reverse Telnet lines. The command has this syntax:
telnet speed default-speed maximum-speedThe argument default-speed is the line speed the communication server will use if the device on the other end of the connection has not specified a speed. The argument maximum-speed is the maximum speed the communication server will use.
Use the telnet speed command to match line speeds on remote systems in reverse Telnet, host machines hooked to a communication server to access the network, or a group of console lines hooked up to the communication server, when disparate line speeds are in use at the local and remote ends of the connection. Line speed negotiation adheres to the Remote Flow Control option, defined in RFC 1080.
This example allows the line to negotiate a bit rate using the Telnet option. If no speed is negotiated, the line will run at 2400 bits per second. If the remote host requests a speed of greater than 9600 baud, then 9600 will be used.
! line 5 telnet speed 2400 9600 !
The line configuration subcommand telnet refuse-negotiations causes Telnet to refuse to negotiate full duplex, remote echo options on incoming connections. The command has this simple syntax:
telnet refuse-negotiationsUse this command on reverse Telnet connections to allow the communication server to refuse these requests from the other end. This command suppresses negotiation of the Telnet Remote Echo and Suppress Go Ahead options.
The line configuration subcommand telnet transparent causes the communication server to send a Return (CR) as a CR followed by a NULL instead of a CR followed by a Line Feed (LF). It has this simple syntax:
telnet transparentThis subcommand is useful for coping with different interpretations of end-of-line handling in the Telnet protocol specification.
The line configuration subcommand telnet sync-on-break causes a reverse Telnet line to send a Telnet Synchronize signal when it receives a Telnet Break signal. The syntax of this command follows:
telnet sync-on-breakThe TCP Synchronize signal clears the data path, but will still interpret incoming commands.
The telnet break-on-ip line configuration subcommand causes the system to generate a hardware Break signal on the RS-232 line that is associated with a reverse Telnet connection, when a Telnet Interrupt-Process (IP) command is received on that connection. This can be used to control the translation of Telnet IP commands into X.25 Break indications. The following is the syntax:
telnet break-on-ipUse this command to work around the following situations:
A hardware Break signal is generated when a Telnet Break command is received.
In the following example, line 5 is configured with the telnet break-on-ip command. The location text notes that this refers to the high-speed modem. The telnet transparent command sets end-of-line handling.
line 5 location high-speed modem telnet transparent telnet break-on-ip
When used with a correctly operating host, communication servers implement the Telnet Synchronize and Abort Output signals, which can stop output within one packet's worth of data from the time the user types the interrupt character. For a faster response to user interrupt characters, use the ip tcp chunk-size global configuration command.
The command has this syntax:
ip tcp chunk-size numberThe argument number is the number of characters output before the interrupt executes. The suggested value of number is 80, which will typically abort output within a line or two of where the user types the interrupt character. Values of less than 50 are not recommended for reasons of efficiency.
Changing the chunk size affects neither the size of the packet used nor the TCP window size, either of which would cause serious efficiency problems for the remote host as well as for the communication server. Instead, the Telnet status is checked after the number of characters specified, causing only a relatively minor performance loss.
This command allows the communication server to react more quickly when an interrupt character or sequence is entered (Ctrl-C, for example).
! ip tcp chunk-size 100 !
The following example represents a typical listing for a modem configured for maximum transparency.
! line 1-20 telnet transparent telnet break-on-ip !
The ip alias global configuration command assigns an Internet address to the service provided on a TCP port.
ip alias internet-address TCP-portThe argument internet-address is the Internet address for the service, and the argument TCP-port is the number of the TCP port. Note that the Internet address must be on the same network or subnet as the communication server's main address, and must not be used by another host on that network or subnet. Connection to the Internet address has the same effect as connecting to the communication server's main address, using TCP-port as the TCP port.
You can use the ip alias command to assign multiple Internet addresses to the communication server. For example, in addition to the primary alias address, you can specify addresses that correspond to lines or rotary groups. Using the ip alias command in this way makes the process of connecting to a specific rotary group transparent to the user.
The no ip alias command removes the specified address for the communication server.
This command configures connections to IP address 131.108.42.42 to act identically to connections made to the server's primary IP address on TCP port 3001. In other words, a user trying to connect is connected to the first free line in rotary group 1 using the Telnet protocol.
ip alias 131.108.42.42 3001
You can configure IP on your communication server to support routing and nonrouting connections.
Follow these steps for each interface you will send IP across.
Step 1: Enable IP routing (if using routing).
Step 2: Assign IP addresses.
Assign and set IP addresses for interfaces on your internetwork. Considerations including address classes, formats, conventions, allowable addresses, and subnetting rules and guidelines are presented.
Step 3: Set address resolution parameters.
Customize Address Resolution Protocol (ARP) static entry and timing functions if necessary (if dynamic resolution is not supported on your host).
Step 4: Set broadcast addresses.
Set up your system to forward broadcasts, limit broadcast storms, perform UDP broadcasts, and so forth.
Each task is described in the following sections.
You must enable IP routing on your communication server to implement routing over SLIP links. The ip routing global configuration command enables IP routing for the communication server. Its full syntax follows.
ip routingThe no ip routing subcommand turns off IP routing. By default, your communication server is set to no ip routing.
The official description of Internet addresses is found in RFC 1020, "Internet Numbers." The Network Information Center (NIC), which maintains and distributes the RFC documents, also assigns Internet addresses and network numbers. Upon application from an organization, the NIC assigns a network number or range of addresses appropriate to the number of hosts on the network.
As described in RFC 1020, Internet addresses are 32-bit quantities, divided into five classes. The classes differ in the number of bits allocated to the network and host portions of the address. For this discussion, consider a network to be a collection of devices (hosts) that have the same network field value in their Internet addresses.
The Class A Internet address format allocates the highest eight bits to the network field and sets the highest-order bit to 0 (zero). The remaining 24 bits form the host field. Only 128 Class A networks can exist, but each Class A network can have almost 17 million hosts. Figure 1-1illustrates the Class A address format.
The Class B Internet address format allocates the highest 16 bits to the network field and sets the two highest-order bits to 1,0. The remaining 16 bits form the host field. Over 16,000 Class B networks can exist, and each Class B network can have over 65,000 hosts.
Figure 1-2 illustrates the Class B address format.
The Class C Internet address format allocates the highest 24 bits to the network field and sets the three highest-order bits to 1,1,0. The remaining eight bits form the host field. Over two million Class C networks can exist, and each Class C network can have up to 254 hosts. Figure 1-3illustrates the Class C address format.
The Class D Internet address format is reserved for multicast groups, as discussed in RFC 988. In Class D addresses, the four highest-order bits are set to 1,1,1,0.
The Class E Internet address format is reserved for future use. In Class E addresses, the four highest-order bits are set to 1,1,1,1. The communication server currently ignores Class D and Class E Internet addresses, except the global broadcast address 255.255.255.255.
The notation for Internet addresses consists of four numbers separated by dots (periods). Each number, written in decimal, represents an 8-bit octet. When strung together, the four octets form the 32-bit Internet address. This notation is called dotted decimal.
These samples show 32-bit values expressed as Internet addresses:
192.31.7.19 10.7.0.11 255.255.255.255 0.0.0.0
Note that 255, which represents an octet of all ones, is the largest possible value of a field in a dotted-decimal number.
Some Internet addresses are reserved for special uses and cannot be used for host, subnet, or network addresses. Table 1-1 lists ranges of Internet addresses and shows which addresses are reserved and which are available for use.
| Class | Address or Range | Status |
|---|---|---|
| A | 0.0.0.0 1.0.0.0 through 126.0.0.0 127.0.0.0 | Reserved Available Reserved |
| B | 128.0.0.0 128.1.0.0 through 191.254.0.0 191.255.0.0 | Reserved Available Reserved |
| C | 192.0.0.0 192.0.1.0 through 223.255.254 223.255.255.0 | Reserved Available Reserved |
| D, E | 224.0.0.0 through 255.255.255.254 255.255.255.255 | Reserved Broadcast |
To create an address that refers to a specific network, the bits in the host portion of the address must all be zero. For example, the Class C address 192.31.7.0 refers to a particular network (no local component).
Conversely, if you want a local address only, without a network portion, all the bits in the network portion of an address must be 0. For example, the Class C address 0.0.0.234 refers to a particular host (local or host address).
If you want to send a packet to all hosts on the network specified in the network portion of the address, the local address must be all ones. For example, the Class B address 128.1.255.255 refers to all hosts on network 128.1.0.0. This is called a broadcast, which is described in the section ""Broadcasting in the Internet"."
You can manually configure the communication server routing table, or you can specify that a high-level routing protocol dynamically build the routing table. In both cases, the routing table is based on the network portion of addresses. Consequently, the addresses of hosts on a single physical network must have the same network number to permit automatic routing. If a network does not meet this requirement, the communication server will be unable to communicate with all of the hosts on that network. (The one exception to this general rule is the use of secondary addresses, which is described in the section "Setting IP Interface Addresses")
Subnetting is a scheme for imposing a simple two-level hierarchy on host addresses, allowing multiple logical networks to exist within a single Class A, B, or C network. The usual practice is to use a few of the contiguous leftmost bits in the host portion of the network addresses for a subnet field. For example, Figure 1-4 shows a Class B address with five bits of the host portion used as the subnet field. The official description of subnetting is contained in RFC 950, "Internet Standard Subnetting Procedure."
The communication server and hosts can use the subnet field for routing. The rules for routing on subnets are identical to the rules for routing on networks; however, correct routing requires all subnets of a network be physically contiguous. In other words, the network must be set up so that traffic between any two subnets does not cross another network. This restriction applies to all IP routing protocols except OSPF. With OSPF you can route traffic between two subnets that are not physically contiguous.
You can create a single network from subnets that are physically separated by another network by using a secondary address.
An example is shown in the section "Setting IP Interface Addresses"
A subnet mask identifies the subnet field of network addresses. All subnets of a given class, A, B, or C, should use the same subnet mask. This mask is a 32-bit Internet address written in dotted-decimal notation with all ones in the network and subnet portions of the address. For the example shown in Figure 1-4, the subnet mask is 255.255.248.0. Table 1-2 shows the subnet masks you can use to divide an octet into subnet and host fields. The subnet field can consist of any number of the host field bits; you do not need to use multiples of eight. However, you should use three or more bits for the subnet field--a subnet field of two bits yields only four subnets, two of which are reserved (the 1,1 and 0,0 values).
| Subnet Bits | Host Bits | Hex Mask | Decimal Mask |
|---|---|---|---|
| 0 | 8 | 0 | 0 |
| 1 | 7 | 0x80 | 128 |
| 2 | 6 | 0xC0 | 192 |
| 3 | 5 | 0xE0 | 224 |
| 4 | 4 | 0xF0 | 240 |
| 5 | 3 | 0xF8 | 248 |
| 6 | 2 | 0xFC | 252 |
| 7 | 1 | 0xFE | 254 |
| 8 | 0 | 0xFF | 255 |
Use the ip address interface subcommand to set an IP address for an interface. The full command syntax follows:
ip address address mask [secondary]The two required arguments are address, which is an IP address, and mask, the network mask for the associated IP network. The subnet mask must be the same for all interfaces connected to subnets of the same network. Hosts can determine subnet masks using the Internet Control Message Protocol (ICMP) Mask Request message. The communication server responds to this request with an ICMP Mask Reply message. (See the section "Configuring ICMP and Other IP Services" later in this chapter for more details.)
Disable IP processing on a particular interface by removing its IP address with the no ip address subcommand. If the communication server detects another host using one of its IP addresses, it will print an error message on the console. The software supports multiple IP addresses per interface.
Specify additional secondary IP addresses by including the keyword secondary after the IP address and subnet mask.
In the sample below, 131.108.1.27 is the primary address and 192.31.7.17 is the secondary address for Ethernet 0.
interface ethernet 0 ip address 131.108.1.27 255.255.255.0 ip address 192.31.7.17 255.255.255.0 secondary
Subnetting with a subnet address of zero is generally not allowed because of the confusion inherent in having a network and a subnet with indistinguishable addresses. For example, if network 131.108.0.0 is subnetted as 255.255.255.0, subnet zero would be written as 131.108.0.0--which is identical to the network address.
To enable or disable the use of subnet zero for interface addresses and routing updates, use the global configuration command ip subnet-zero. Its full command syntax follows:
ip subnet-zeroThe default is for this command to be disabled.
In the example below, subnet zero is enabled for the communication server:
ip subnet-zero
A device in the Internet can have both a local address, which uniquely identifies the device on its local segment or LAN, and a network address, which identifies the network the device belongs to. The local address is more properly known as a data-link address because it is contained in the data link layer (Layer 2 of the OSI Model) part of the packet header and is read by data-link devices (bridges and all device transceivers, for example). Local addresses are also called MAC addresses because the Media Access Control (MAC) sublayer within the data link layer processes addresses for the layer.
To communicate with a device on Ethernet, the communication server must first determine the 48-bit MAC or local data-link address of that device. The process of determining the local data-link address from an Internet address is called address resolution. The process of determining the Internet address from a local data-link address is called reverse address resolution. The communication server uses three address resolution: Address Resolution Protocol (ARP), proxy ARP, and Probe (which is similar to ARP). The communication server also uses the Reverse Address Resolution Protocol (RARP). The ARP, proxy ARP, and RARP protocols, which are used on Ethernets, are defined in RFCs 826, 1027, and 903, respectively. Probe is a protocol developed by the Hewlett-Packard for use on IEEE-802.3 networks.
To send an Internet data packet to a local host with which it has not previously communicated, the communication server first broadcasts an ARP Request packet. The ARP Request packet requests the MAC local data link address corresponding to an Internet address. All hosts on the network receive this request, but only the host with the specified Internet address will respond.
If present and functioning, the host with the specified Internet address responds with an ARP Reply packet containing its local data-link address. The communication server receives the ARP Reply packet, stores the local data-link address in the ARP cache for future use, and begins exchanging packets with the host.
Use the EXEC command show arp to examine the contents of the ARP cache. The show ip arp command will show IP entries.
The function of ARP is to provide a dynamic mapping between 32-bit IP addresses and
48-bit local hardware (Ethernet, Token Ring) addresses. ARP may also be used for protocols other than IP and media that have other than 48-bit addresses.
Because most hosts support dynamic resolution, you generally do not need to specify static ARP cache entries. If you do need to define static ARP cache entries, you can do so globally.
When used as a global configuration command, the arp command installs a permanent entry in the ARP cache. The communication server uses this entry to translate 32-bit Internet Protocol addresses into 48-bit hardware addresses. The full syntax follows:
arp internet-address hardware-address type [alias]The argument internet-address is the Internet address in dotted decimal format corresponding to the local data-link address specified by the argument hardware-address.
The argument type is an encapsulation description. This is typically the arpa keyword for Ethernets and is always snap for Token Ring interfaces. See the discussions of the individual interface types for more information on possible encapsulations.
The optional keyword alias indicates that the communication server should respond to ARP requests as if it were the owner of the specified IP address.
The following is a sample of a static ARP entry for a typical Ethernet host.
arp 192.31.7.19 0800.0900.1834 arpa
The no arp subcommand removes the specified entry from the ARP cache. To remove all nonstatic entries from the ARP cache, use the privileged EXEC command clear arp-cache.
When used as an interface subcommand, the arp command controls the interface-specific handling of IP address resolution into 48-bit Ethernet hardware addresses. The full syntax of the arp interface subcommand follows:
arp {arpa|probe|snap}The keyword arpa, which is the default, specifies standard Ethernet-style ARP (RFC 826), probe specifies the HP Probe protocol for IEEE-802.3 networks, and snap specifies ARP packets conforming to RFC 1042. The show interfaces monitoring command displays the type of ARP being used on a particular interface. Probe is described in more detail in the "Address Resolution Using Probe" section later in this chapter.
To set the number of seconds an ARP cache entry will stay in the cache, use the arp timeout interface subcommand. The full syntax of this command follows:
arp timeout secondsThe value of the argument seconds is used to age an ARP cache entry related to that interface. By default, the seconds argument is set to four hours (14,400 seconds). A value of zero seconds sets no timeout, and the cache entries are never cleared.
Use the no arp timeout command to return to the default value.
This command is ignored when issued on interfaces that do not use ARP. Use the EXEC command show interfaces to display the ARP timeout value. The value follows the Entry Timeout: heading, as seen in this sample display:
ARP type: ARPA, HP-PROBE, Entry Timeout: 14400 sec
The following example illustrates how to set the ARP timeout to 12000 seconds, to allow entries to time out more quickly than the default.
arp timeout 12000
The communication server uses proxy ARP, as defined in RFC 1027, to help hosts with no knowledge of routing determine the hardware addresses of hosts on other networks or subnets. Under proxy ARP, if the communication server receives an ARP Request for a host that is not on the same network as the ARP request sender, and if the communication server has the best route to that host, then the communication server sends an ARP reply packet giving its own local data link address. The host that sent the ARP request then sends its packets to the communication server, which forwards them to the intended host.
The ip proxy-arp interface subcommand enables proxy ARP on the interface. The full command syntax for this command follows.
ip proxy-arpProxy ARP is enabled by default.
The communication server can be made to use the Probe protocol (in addition to ARP) whenever it attempts to resolve an IEEE-802.3 or Ethernet local data link address. The subset of Probe that performs address resolution is called Virtual Address Request and Reply. Using Probe, the communication server can communicate transparently with Hewlett-Packard IEEE-802.3 hosts that use this type of data encapsulation.
The syntax for this command, which enables or disables Probe for IEEE-802.3 and Ethernet networks, is as follows.
arp probeThe other options of the arp command are discussed under "Address Resolution Using ARP" earlier in this chapter. This command is disabled by default.
Reverse ARP (RARP) is defined in RFC 903. If a communication server does not know the IP address of one of its Ethernet interfaces, it will try RARP during startup processing to attempt to determine the Internet address, based on its interface local data link address. Diskless hosts also use RARP at boot time to determine their protocol addresses. RARP works in the same way as ARP, except that the RARP Request packet requests an Internet address instead of a local data link address. Use of RARP requires a RARP server on the same network segment as the communication server interface.
A communication server without nonvolatile memory uses both Reverse ARP (RARP) and Boot Protocol (BootP) messages when trying to obtain its interface address from network servers.
BootP, defined in RFC 951, specifies a method for determining the Internet address of a host from its Ethernet local data-link address. The basic mechanism is similar to that used by Reverse ARP, but it is UDP-based rather than a distinct Ethernet protocol. The main advantage of BootP is that its messages can be routed, whereas RARP messages cannot leave the local Ethernet-based network.
A broadcast is a data packet destined for all hosts on a particular physical network. Network hosts recognize broadcasts by special addresses. This section describes the meaning and use of Internet broadcast addresses. For detailed discussions of broadcast issues in general, see RFC 919, "Broadcasting Internet Datagrams," and RFC 922, "Broadcasting Internet Datagrams in the Presence of Subnets." The communication server support for Internet broadcasts generally complies with RFC 919 and RFC 922; however, the communication server does not support multisubnet broadcasts as defined in RFC 922.
The current standard for an Internet broadcast address requires that the host portion of the address consist of all ones. If the network portion of the broadcast address is also all ones, the broadcast applies to the local network only. If the network portion of the broadcast address is not all ones, the broadcast applies to the network or subnet specified.
The communication server supports two kinds of broadcasting: directed broadcasting and flooding. A directed broadcast is a packet sent to a specific network or series of networks, while a flooded broadcast packet is sent to every network, as shown in Figure 1-5. The packet that is incoming from interface E0 is flooded to interfaces E1, E2 and S0. A directed-broadcast address includes the network or subnet fields.
For example, if the network address is 128.1.0.0, then the address 128.1.255.255 indicates all hosts on network 128.1.0.0. This would be a directed broadcast. If network 128.1.0.0 has a subnet mask of 255.255.255.0 (the third octet is the subnet field), then the address 128.1.5.255 specifies all hosts on subnet 5 of network 128.1.0.0, another directed broadcast.
The ip directed-broadcast interface subcommand is used to enable forwarding of directed broadcasts on the interface. The full syntax of this command follows.
ip directed-broadcastThe default is to forward directed broadcasts. Disable forwarding of directed broadcasts with the no ip directed-broadcast subcommand.
The communication server supports Internet broadcasts on both local and wide area networks. There are at least four popular standard ways of indicating an Internet broadcast address. You can configure a communication server host to generate any form of Internet broadcast address. The communication server can also receive and understand any form of Internet broadcast address. By default, a communication server uses all ones for both the network and host portions of the Internet broadcast address (255.255.255.255). You can change the Internet broadcast address by using the ip broadcast-address interface subcommand. Following is the full command syntax:
ip broadcast-address [address]The argument address is the desired IP broadcast address for a network. If a broadcast address is not specified, the system defaults to a broadcast address of all ones or 255.255.255.255.
Use the no ip broadcast-address command to remove the broadcast address or addresses.
If the communication server does not have nonvolatile memory and you want to specify the broadcast address to use before it has been configured, you can change the Internet broadcast address by setting jumpers in the processor configuration register. Setting bit 10 causes the communication server to use all zeros. Bit 10 interacts with bit 14, which controls the network and subnet portions of the broadcast address. Setting bit 14 causes the communication server to include the network and subnet portions of its address in the broadcast address. Table 1-3 shows the combined effect of setting bits 10 and 14.
| Bit 14 | Bit 10 | Address (<net><host>) |
|---|---|---|
| out | out | <ones><ones> |
| out | in | <zeros><zeros> |
| in | in | <net><zeros> |
| in | out | <net><ones> |
For more information about the configuration register, see the hardware installation and maintenance publication for your system.
Network hosts occasionally employ UDP broadcasts to determine address, configuration, and name information. If such a host is on a network segment that does not include a server host, UDP broadcasts are not forwarded; therefore, no answer or reply is received.
To correct this situation, configure the interface of your communication server to forward certain classes of UDP broadcasts to a helper address. See the descriptions of the ip helper-address and the ip forward-protocol global configuration commands in this chapter for more information.
Sometimes you need to control which broadcast packets and which protocols are forwarded. You do this with helper-address and the forward-protocol commands.
The ip helper-address interface subcommand tells the communication server to forward UDP broadcasts, including BootP, received on this interface. (UDP is the connectionless alternative to TCP at the Transport Layer.) Use the ip helper-address interface subcommand to specify the destination address for forwarding broadcast packets. Full command syntax follows.
ip helper-address addressThe address argument specifies a destination broadcast or host address to be used when forwarding such datagrams. You can have more than one helper address per interface. You remove the list with no ip helper-address.
If you do not specify the IP helper-address command, the communication server will not forward UDP broadcasts.
This example defines an address that acts as a helper address.
ip helper-address 121.24.43.2
The ip forward-protocol interface subcommand allows you to specify which protocols and ports the communication server will forward. Its full syntax is listed next.
ip forward-protocol {udp|nd} [port]The keyword nd is the ND protocol used by older diskless Sun workstations. The keyword udp is the UDP protocol. A UDP destination port can be specified to control which UDP services are forwarded. By default, both UDP and ND forwarding are enabled if a helper address has been defined for an interface. If no ports are specified, these datagrams are forwarded, by default:
Use the no ip forward-protocol command with the appropriate keyword and argument to remove the protocol.
The following example below first defines a helper address, then uses the ip forward-protocol command to specify forwarding of UDP only.
ip forward-protocol udp ! interface ethernet 1 ip helper-address 131.120.1.0
Several early TCP/IP implementations do not use the current broadcast address standard. Instead, they use the old standard, which calls for all zeros instead of all ones to indicate broadcast addresses. Many of these implementations do not recognize an all-ones broadcast address and fail to respond to the broadcast correctly. Others forward all-ones broadcasts, which causes a serious network overload known as a broadcast storm. Implementations that exhibit these problems include UNIX systems based on versions of BSD UNIX before Version 4.3.
The communication server provides some protection from broadcast storms by limiting their extent to the local cable.
The best solution to the broadcast storm problem is to use a single broadcast address scheme on a network. Most modern TCP/IP implementations allow the network manager to set the address to be used as the broadcast address. Many implementations, including that on the communication server, can accept and interpret all possible forms of broadcast addresses.
The Internet Control Message Protocol (ICMP) is a special protocol within the IP protocol suite that focuses exclusively on control and management of IP connections. ICMP messages are generated by the communication server when there is a problem with the IP part of a packet's header; these messages could be alerting another communication server or they could be sent to the source or destination device (host). Characteristics of the ICMP messages follow.
The ip mask-reply interface subcommand tells the communication server to respond to mask requests. The full syntax of this command follows.
ip mask-replyThe default is not to send a Mask Reply, and this default is restored with the no ip mask-reply command.
Each communication server interface has an output hold queue with a limited number of entries that it can store. Upon reaching this limit, the interface sends an ICMP Source Quench message to the source host of any additional packets and discards the packet. When the interface empties the hold queue by one or more packets, the interface can accept new packets again. The communication server limits the rate at which it sends Source Quench and Unreachable messages to one per second.
If the communication server receives a nonbroadcast packet destined for itself that uses an unknown protocol the communication server sends an ICMP Protocol Unreachable message to the source.
If the communication server receives a packet that it is unable to deliver to the ultimate destination because it knows of no route to the destination address, the communication server replies to the originator of that packet with an ICMP Host Unreachable message. Use the ip unreachables interface subcommand to enable the sending of these messages. The full syntax for this command follows.
ip unreachablesThe default is to send unreachable messages. The no ip unreachables subcommand disables sending ICMP Unreachable messages on an interface.
The communication server sends an ICMP Redirect message to the originator of any datagram that it is forced to resend through the same interface on which it was received, since the originating host could presumably have sent that datagram to the ultimate destination without involving the communication server at all. The communication server ignores Redirect messages that have been sent to it by other communication servers or routers. Use the ip redirects interface subcommand to enable or disable the sending of these messages, as follows:
ip redirectsThe default is to send redirects. The no version disables the sending of direct messages.
All interfaces have a default maximum packet size, or maximum transmission unit (MTU). You can set the IP MTU to a smaller unit by using the ip mtu interface subcommand.
If an IP packet exceeds the MTU set for the communication server's interface, the communication server will fragment it. The full command syntax follows:
ip mtu bytesThe default and maximum MTU depends on the interface medium type. The minimum MTU is 128 bytes. The no ip mtu subcommand restores the default MTU for that interface.
In the following example, you are setting the maximum IP packet size for the first serial interface to 300 bytes.
interface serial 0 ip mtu 300
The communication server runs the IP MTU Path Discovery mechanism by default. IP MTU Path Discovery allows a host to dynamically discover and cope with differences in the maximum allowable MTU size of the various links along the path. Sometimes a communication server is unable to forward a datagram because fragmentation of the datagram is required (the packet is larger than the MTU you set for the interface with the ip mtu command), but the "Don't fragment" bit is set. If you have Path Discovery enabled, the communication server sends a message to the sending host, alerting it to the problem. The host will have to replicate packets destined for the receiving interface so that they fit the smallest packet size of all the links along the path. This technique is defined by RFC 1191 and shown in Figure 1-6.
MTU Path Discovery is useful when a link in a network goes down, forcing use of another, different MTU-sized link (and different communication servers). As an example, suppose you were trying to send IP packets over a network where the MTU in the first communication server is set to 1500 bytes, but then reaches a communication server where the MTU is set to 512 bytes. If the datagram's "Don't fragment" bit is set, the datagram would be dropped because the communication server with the MTU set to 512 bytes is unable to forward it. The communication server returns an ICMP Destination Unreachable message to the source of the datagram with its Code field indicating "Fragmentation needed and DF set." To support Path MTU Discovery, it would also include the MTU of the next-hop network link.
MTU Path Discovery is also useful when a connection is first being established and the sender has no information at all about the intervening links. It is always advisable to use the largest MTU that the links will bear; the larger the MTU, the fewer packets the host needs to send.
When you use the privileged EXEC command ping (IP packet internet groper function), the communication server sends ICMP Echo messages to check host reachability and network connectivity. If the communication server receives an ICMP Echo message, it sends an ICMP Echo Reply message to the source of the ICMP Echo message. See the section "The IP Ping Command" later in this chapter for more information about the use of the ping command.
The communication server supports the Internet header options Strict Source Route, Loose Source Route, Record Route, and Time Stamp.
The communication server examines the header options to every packet that passes through it. If it finds a packet with an invalid option, the communication server sends an ICMP Parameter Problem message to the source of the packet and discards the packet.
You can use the extended command mode of the ping command to specify several Internet header options. To see the list of the options you can specify, type a question mark at the extended commands prompt of the ping command. See the "The IP Ping Command" section of this chapter for more information.
The communication server maintains a cache of host-name-to-address mappings for use by the EXEC connect or telnet commands and related Telnet support operations. This cache speeds the process of converting names to addresses.
To define a static host-name-to-address mapping in the host cache, use the ip host global configuration command, as shown below:
ip host name [TCP-port-number] address1 [address2...address8]The argument name is the host name, and the argument address is the associated IP address. Up to eight addresses may be bound to a host name. The no version removes host-name-to-address mapping.
The following example uses the ip host command to define two static mappings.
ip host croff 192.31.7.18 ip host bisso-gw 10.2.0.2 192.31.7.33
You can specify that the Domain Name System (DNS) or IEN-116 Name Server automatically determines host-name-to-address mappings. Use these global configuration commands to establish different forms of dynamic name lookup:
To specify one or more hosts that supply name information, use the ip name-server global configuration command, as follows:
ip name-server server-address1 [server-address2 . . . server-address6]The server-address arguments are the Internet addresses of up to six name servers.
This command specifies host 131.108.1.111 as the primary name server, and host 131.108.1.2 as the secondary server.
ip name-server 131.108.1.111 131.108.1.2
The global configuration command ip domain-name defines a default domain name the communication server uses to complete unqualified host names (names without a dotted domain name appended to them). The full syntax of this command follows:
ip domain-name nameThe argument name is the domain name; do not include the initial period that separates an unqualified name from the domain name. The no ip domain-name command disables use of the Domain Name System.
This command defines cisco.com to be used as the default name.
ip domain-name cisco.com
Any IP host name that does not contain a domain name, that is, any name without a dot (.), will have the dot and cisco.com appended to it before being added to the host table.
By default, the IP Domain Name System (DNS)-based host-name-to-address translation is enabled. To enable or disable this feature, use the ip domain-lookup global configuration command as follows:
ip domain-lookupTo specify the IP IEN-116 Name Server host-name-to-address translation, use the ip ipname-lookup global configuration command as follows:
ip ipname-lookupThe default is for IEN-116 lookup to be disabled.
HP Probe Proxy support allows a communication server to respond to HP Probe Proxy Name requests. These are typically used at sites that have HP equipment and are already using HP Probe.
Use the interface subcommand ip probe proxy to enable or disable HP Probe Proxy, as follows:
ip probe proxyThis command is disabled by default. To use the proxy service, you must first enter the host name of the HP host into the host table through the configuration command ip hp-host. Full syntax follows:
ip hp-host hostname ip-addressThe hostname argument specifies the host's name and the argument ip-address specifies its IP address. Use the no ip hp-host command with the appropriate arguments to remove the host name.
The following example specifies an HP host's name and address and then enables Probe Proxy.
ip hp-host BCWjo 131.108.1.27 interface ethernet 0 ip probe proxy
Commands that will help you to maintain and debug your HP-based network are listed in the sections "Monitoring the IP Network"and "Debugging the IP Network" at the end of this chapter.
To define a list of default domain names to complete unqualified host names, use the ip domain-list global configuration command. The full syntax of this command follows.
ip domain-list nameThe ip domain-list command is similar to the ip domain-name command, except that with ip domain-list you can define a list of domains, each to be tried in turn.
The argument name is the domain name; do not enter an initial period. Specify only one name when you enter the ip domain-list command.
Use the no ip domain-list command with the appropriate argument to delete a name from the list.
In the following example, several domain names are added to a list:
ip domain-list martinez.com ip domain-list stanford.edu
The following example adds a name to, and then deletes a name from the list:
ip domain-list sunya.edu no ip domain-list stanford.edu
The communication server software provides three methods by which the communication server can learn about routes to other networks:
The first and most common method of learning about other routes is by using proxy ARP. The software treats all networks as if they are local, and performs ARPs for every IP address. The appropriate router to that network answers the ARP request, allowing the software to reach any network. This method works so long as the routers support proxy ARP. While this is true of Cisco routers, many other routers, and especially host-based routing software, do not support this feature.
The second method for locating routes is to define a default router (described in the sub-sequent section"Using the Default Gateway"). The software sends all nonlocal packets to this router, which would route them appropriately, and perhaps send an ICMP Redirect message back to the communication server, telling it of a better router. The software would cache these redirect messages, and route each packet thereafter as efficiently as possible. The problem with this method is that there is no means to detect when the default router had crashed or was unavailable, and no method of picking another router is possible in that event.
The Cisco communication server software provides a third method, called Router Discovery, by which the communication server may learn about routes to other networks using the Cisco-defined Gateway Discovery Protocol (GDP) for detecting routers. It is also capable of wiretapping RIP and IGRP routing updates, and inferring from those updates the location of routers. The communication server client implementation of router discovery does not actually examine or store the full routing tables sent by routers, it merely keeps track of which systems are sending such data. Each method is described in the following sections.
Proxy ARP, defined in RFC 1027, enables an Ethernet host with no knowledge of routing to communicate with hosts on other networks or subnets. Such a host assumes that all hosts are on the same local Ethernet, and that it can use ARP to determine their hardware addresses.
Under proxy ARP, if a gateway receives an ARP Request for a host that is not on the same network as the ARP Request sender, the gateway evaluates whether it has the best route to that host. If the gateway does have the best route, the gateway sends an ARP Reply packet giving its own Ethernet hardware address. The host that sent the ARP Request then sends its packets to the gateway, which forwards them to the intended host.
Because the communication server hosts do not wiretap or participate in routing transactions, they are independent of any routing protocol. The communication server can use a default gateway (router) or rely on proxy ARP to send packets to hosts not on the local subnet or network.
You set up a default gateway for the communication server using the ip default-gateway global configuration command. The command has this syntax:
ip default-gateway addressThe ip default-gateway command specifies the router the communication server uses to send packets to hosts not on the local network or subnet. The argument address is the Internet address of the router.
The communication server sends any packets needing the assistance of a gateway to the address you specify. If another gateway has a better route to the requested host, the default gateway sends an ICMP Redirect message to the communication server. The ICMP Redirect message indicates which local router the communication server should use.
To display the address of the default gateway, use the EXEC command show ip redirects. See the section "Monitoring the IP Network" later in this chapter for more information.
This example command defines the router on Internet address 192.31.7.18 as the default router:
ip default-gateway 192.31.7.18
The Cisco Router Discovery mechanism allows the communication server to learn the routes to other networks using routing protocols. The mechanism supports these routing protocols:
You may configure the three protocols together in any combination. When possible, it is
recommended that GDP be used, as it allows each router to specify both a priority and the time after which a router should be assumed down if no further packets are received. Routers
discovered using IGRP are assigned an arbitrary priority of 60. Routers discovered through RIP are assigned a priority of 50. For IGRP and RIP, the software attempts to measure the time between updates, and will assume that the router is down if no updates are received for 2.5 times that interval.
Each router discovered by the communication server becomes a candidate for the default router. The list of candidates is scanned to select a new router with the highest priority for the following reasons:
Use this interface subcommand to configures the Router Discovery feature using the Cisco GDP routing protocol:
ip gdp gdpUse the no ip gdp gdp command to turn the feature off.
This example command configures Router Discovery using GDP on the Ethernet 0 interface:
! interface ethernet 0 ip gdp gdp !
Use this interface subcommand to configure the Router Discovery feature using the UNIX RIP routing protocol:
ip gdp ripUse the no ip gdp rip command to turn the feature off.
This example command configures Router Discovery using RIP on the Ethernet 1 interface:
! interface ethernet 1 ip gdp rip !
Use this interface subcommand to configure the Router Discovery feature using the Cisco IGRP routing protocol:
ip gdp igrpUse the no ip gdp igrp command to turn the feature off.
This example command configures Router Discovery using IGRP on the Ethernet 1 interface:
! interface ethernet 1 ip gdp igrp !
An access list is a sequential collection of permit and deny conditions that apply to Internet addresses. The communication server tests addresses against the conditions in an access list one by one. The first match determines whether the communication server accepts or rejects the address. Because the communication server stops testing conditions after the first match, the order of the conditions is critical. If no conditions match, the communication server rejects the address.
The two steps involved in using access lists are:
Step 1: Create a list.
Step 2: Apply it to implement a policy.
You apply access lists for several reasons:
The Cisco software supports two styles of access lists for IP:
To create an access list, use the access-list global configuration command. Full command syntax follows:
access-list list {permit|deny} source source-maskThe argument list is an integer from 1 through 99 that you assign to identify one or more permit/deny conditions as an access list. Access list 0 (zero) is predefined; it permits any address and is the default access list for all interfaces.
The communication server compares the address being tested to source, ignoring any bits specified in source-mask. If you use the keyword permit, a match causes the address to be accepted. If you use the keyword deny, a match causes the address to be rejected.
The arguments source and source-mask are 32-bit quantities written in dotted-decimal format. Address bits corresponding to wildcard mask bits set to 1 are ignored in comparisons; address bits corresponding to wildcard mask bits set to zero are used in comparisons. See the examples later in this section.
An access list can contain an indefinite number of actual and wildcard addresses. A wildcard address has a nonzero address mask and thus potentially matches more than one actual address. The communication server examines first the actual address, then the wildcard addresses. The order of the wildcard addresses is important because the communication server stops examining access-list entries after it finds a match.
The no access-list subcommand deletes the entire access list. To display the contents of all access lists, use the EXEC command show access-lists.
There are implicit masks in IP access lists. For instance, if you omit the mask from an associated IP host address access-list specification, 0.0.0.0 us assumed to be the mask. Consider the following example configuration:
access-list 1 permit 0.0.0.0 access-list 1 permit 131.108.0.0 access-list 1 deny 0.0.0.0 255.255.255.255
For example, the following masks are implied in the first two lines:
access-list 1 permit 0.0.0.0 0.0.0.0 access-list 1 permit 131.10-8.0 0.0.0.0
The last line in the configuration (using the deny keyword) can be left off since IP access lists implicitly deny all other access; this is equivalent to finishing the access list with the following command statement:
access-list 1 deny 0.0.0.0 255.255.255.255
The following access list allows access for only those hosts on the three specified networks. It assumes that subnetting is not used; the masks apply to the host portions of the network addresses. Any hosts with a source address that does not match the access list statements will be rejected.
access-list 1 permit 192.5.34.0 0.0.0.255 access-list 1 permit 128.88.1.0 0.0.255.255 access-list 1 permit 36.0.0.0 0.255.255.255 ! (Note: all other access implicitly denied)
To specify a large number of individual addresses more easily, you can omit the address mask that is all zeros from the access-list configuration command. Thus, the following two configuration commands are identical in effect:
access-list 2 permit 36.48.0.3 access-list 2 permit 36.48.0.3 0.0.0.0
Extended access lists allow finer granularity of control. They allow you to specify both source and destination addresses and some protocol and port number specifications.
To define an extended access list, use the extended version of the access-list subcommand.
access-list list {permit|deny} protocol source source-mask destination destination-maskThe argument list is an integer from 100 through 199 that you assign to identify one or more extended permit/deny conditions as an extended access list. Note that a list number in the range 100 to 199 distinguishes an extended access list from a standard access list. The condition keywords permit and deny determine whether the communication server allows or disallows a connection when a packet matches an access condition. The communication server stops checking the extended access list after a match occurs.
The argument protocol is one of the following keywords:
Use the keyword ip to match any Internet protocol, including TCP, UDP, and ICMP.
The argument source is an Internet source address in dotted-decimal format. The argument source-mask is a mask, also in dotted-decimal format, of source address bits to be ignored. The communication server uses the source and source-mask arguments to match the source address of a packet. For example, to match any address on a Class C network 192.31.7.0, the argument source-mask would be 0.0.0.255. The arguments destination and destination-mask are dotted-decimal values for matching the destination address of a packet.
To differentiate further among packets, you can specify the optional arguments operator and operand to compare destination ports, service access points, or contact names. Note that the ip and icmp protocol keywords do not allow port distinctions.
For the tcp and udp protocol keywords, the argument operator can be one of these keywords:
The argument operand is the decimal destination port for the specified protocol.
For the TCP protocol there is an additional keyword, established, that does not take an argument. A match occurs if the TCP datagram has the ACK or RST bits set, indicating an established connection. The nonmatching case is that of the initial TCP datagram to form a connection; the software goes on to other rules in the access list to determine if a connection is allowed in the first place.
For an example of using an extended access list, suppose you have an Ethernet-to-Internet routing network, and you want any host on the Ethernet to be able to form TCP connections to any host on the Internet. However, you do not want Internet hosts to be able to form TCP connections into the Ethernet except to the mail (SMTP) port of a dedicated mail host.
To do this, you must ensure that the initial request for an SMTP connection is made on TCP destination port 25 from port X where X is a number greater than 1023. The two port numbers continue to be used throughout the life of the connection, with the originator always using port 25 as the destination, and the acceptor always using port X as the destination. The fact that the secure system behind the communication server will always accept mail connections on port 25, with a foreign port number greater than 1023, is what makes it possible to separately allow/disallow incoming and outgoing services. Also remember that the access list used is that of the interface on which the packet would ordinarily be transmitted.
In the following example, the Ethernet network is a Class B network with the address 128.88.0.0 and the mail host's address is 128.88.1.2.
access-list 101 permit tcp 128.88.0.0 0.0.255.255 0.0.0.0 255.255.255.255
access-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 established
access-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.1.2 0.0.0.0 eq 25
interface serial 0
access-group 101
interface ethernet 0
access-group 102
This is a complex example, designed to show the power of all the options just discussed. The ip access group interface subcommand is described in detail in the section "Controlling Interface Access"
To restrict incoming and outgoing connections between a particular virtual terminal line (into a Cisco device) and the addresses in an access list, use the access-class line configuration subcommand. Full command syntax for this command follows:
access-class list {in|out}The argument list is an integer from 1 through 99 that identifies a specific access list of Internet addresses.
The keyword in applies to incoming connections, such as virtual terminals. The keyword out applies to outgoing Telnet connections.
The no access-class line configuration subcommand removes access restrictions on the line for the specified connections.
The following example defines an access list that permits only hosts on network 192.89.55.0 to connect to the virtual terminal ports on the communication server.
access-list 12 permit 192.89.55.0 0.0.0.255 line 1 5 access-class 12 in
Use the access-class keyword out to define the access checks made on outgoing connections. (A user who types a host name at the communication server prompt to initiate a Telnet connection is making an outgoing connection.)
The following example defines an access list that denies connections to networks other than network 36.0.0.0 on terminal lines 1 through 5.
access-list 10 permit 36.0.0.0 0.255.255.255 line 1 5 access-class 10 out
To display the access lists for a particular terminal line, use the EXEC command show line and specify the line number.
To control access to an interface, use the access-group interface subcommand:
ip access-group listThe argument list is an integer from 1 through 199 that specifies an access list.
After receiving and routing a packet to a controlled interface, the communication server checks the source address of the packet against the access list. If the access list permits the address, the communication server transmits the packet. If the access list rejects the address, the communication server discards the packet and returns an ICMP Destination Unreachable message. Access lists are applied on outbound interfaces to outbound traffic.
The no version removes the access group specified.
The following example applies list 101:
interface ethernet 0 ip access-group 101
All aspects of the IP Security Option (IPSO) are set up using configuration commands. The Cisco IPSO support addresses both the Basic and Extended security options described in a draft of the IPSO circulated by the Defense Communications Agency. This draft document is an early version of RFC 1108. The following list summarizes the differences between Cisco's implementation and RFC 1108:
The following list describes some of the abilities of the IP security option (IPSO).
The following definitions apply to the descriptions of IPSO in this section.
| Level Keyword | Bit Pattern |
|---|---|
| Reserved4 | 0000 0001 |
| TopSecret | 0011 1101 |
| Secret | 0101 1010 |
| Confidential | 1001 0110 |
| Reserved3 | 0110 0110 |
| Reserved2 | 1100 1100 |
| Unclassified | 1010 1011 |
| Reserved1 | 1111 0001 |
| Authority Keyword | Bit Pattern |
|---|---|
| Genser | 1000 0000 |
| Siop-Esi | 0100 0000 |
| SCI | 0010 0000 |
| NSA | 0001 0000 |
The no ip security interface subcommand resets an interface to its default state: dedicated, Unclassified Genser. No extended state is allowed.
no ip securityUse one of the ip security commands described in the following sections, to enable other kinds of security.
The ip security dedicated interface subcommand sets the interface to the requested classification and authorities.
ip security dedicated level authority [authority . . .]All traffic entering the system on this interface must have a security option that exactly matches this label. Any traffic leaving via this interface will have this label attached to it. The levels and authorities were listed in Table 1-4 and Table 1-5.
The following example sets a confidential level with Genser authority:
ip security dedicated confidential Genser
The ip security multilevel interface subcommand sets the interface to the requested range of classifications and authorities. All traffic entering or leaving the system must have a security option that falls within this range. The levels are set with this command:
ip security multilevel level1 [authority ...] to level2 authority2 [authority2...]Being within range requires that the following two conditions be met:
The following example specifies levels Unclassified to Secret and NSA authority.
ip security multilevel unclassified to secret nsa
IPSO allows you to choose from several interface subcommands if you decide you need to modify your security levels.
The ip security ignore-authorities interface subcommand ignores the authorities field of all incoming datagrams. The value used in place of this field is the authority value declared for the given interface. Full syntax for this command follows.
ip security ignore-authoritiesThis action is only allowed for single-level interfaces. Enter the no ip security ignore-authorities command to turn this function off.
The ip security implicit-labelling interface subcommand accepts datagrams on the interface, even if the datagrams do not include a security option. If your interface has multilevel security set, you must use the second form of the command because it specifies the precise level and authority to use when labeling the datagram, just like your original ip security multilevel subcommand. The full syntax of the ip security implicit-labelling command follows.
ip security implicit-labelling level authority [authority ...]Enter the ip security implicit-labelling command (optionally, with the appropriate arguments) to turn these functions off.
In the example below, an interface is set for security and will accept unlabeled datagrams.
ip security dedicated confidential genser ip security implicit-labelling
The ip security extended-allowed interface subcommand accepts datagrams on the interface that have an extended security option present. Full syntax is shown below:
ip security extended-allowedThe default condition rejects the datagram immediately; the no ip security extended-allowed command restores this default.
The ip security add interface subcommand ensures that all datagrams leaving the communication server on this interface contain a basic security option. Its full syntax follows.
ip security addIf an outgoing datagram does not have a security option present, this subcommand adds one as the first IP option. The security label added to the option field is the label that was computed for this datagram when it first entered the communication server. Because this action is performed after all the security tests have been passed, this label will either be the same as or will fall within the range of the interface. This action is always enforced on multilevel interfaces.
The ip security strip interface subcommand removes any basic security option that may be present on a datagram leaving the communication server through this interface. The full syntax of this command follows.
ip security stripThis is performed after all security tests in the communication server have been passed and is not allowed for multilevel interfaces.
The ip security first interface subcommand prioritizes the presence of security options on a datagram. The full syntax of this command is as shown:
ip security firstIf a basic security option is present on an outgoing datagram, but it is not the first IP option, then it is moved to the front of the options field when this subcommand is used.
In order to fully comply with IPSO, the default values for the minor keywords have become complex:
Table 1-6 provides a list of all default values.
| Type | Level | Authority | Implicit | Add |
|---|---|---|---|---|
| none | (none) | (none) | on | off |
| dedicated | Unclassified | Genser | on | off |
| dedicated | any | any | off | on |
| multilevel | any | any | off | on |
The default value for an interface is "dedicated, Unclassified Genser." Note that this implies implicit labeling. This may seem unusual, but it makes the system entirely transparent to datagrams without options. This is the setting generated when the no ip security subcommand is given.
In this first example, three Ethernet interfaces are presented. These interfaces are running at security levels of Confidential Genser, Secret Genser, and Confidential to Secret Genser, as shown in Figure 1-7.
The following commands set up interfaces for the configuration in Figure 1-7.
interface ethernet 0 ip security dedicated confidential genser interface ethernet 1 ip security dedicated secret genser interface ethernet 2 ip security multilevel confidential genser to secret genser end
It is possible for the setup to be much more complex.
In this next example, there are devices on Ethernet 0 that cannot generate a security option, and so must accept datagrams without a security option. These hosts also crash when they receive a security option; therefore, never place one on such interfaces. Furthermore, there are hosts on the other two networks that are using the extended security option to communicate information, so you must allow these to pass through the system. Finally, there is also a host on Ethernet 2 that requires the security option to be the first option present, and this condition must also be specified. The new configuration follows.
interface ethernet 0 ip security dedicated confidential genser ip security implicit-labelling ip security strip interface ethernet 1 ip security dedicated secret genser ip security extended-allowed ! interface ethernet 2 ip security multilevel confidential genser to secret genser ip security extended-allowed ip security first
You can debug security-related problems by using the EXEC command debug ip-packet. Each time a datagram fails any security test in the system, a message is logged describing the exact cause of failure.
Security failure is also reported to the sending host when allowed by the specification. This calculation on whether to send an error message can be somewhat confusing. It depends upon both the security label in the datagram and the label of the incoming interface. First, the label contained in the datagram is examined for anything obviously wrong. If nothing is wrong, it should be assumed to be correct. If there is something wrong, then the datagram should be treated as Unclassified Genser. Then this label is compared to the interface range, and the appropriate action is taken. See Table 1-7.
| Classification | Authorities | Action Taken |
|---|---|---|
| Too low | Too low Good Too high | No Response No Response No Response |
| In range | Too low Good Too high | No Response Accept Send Error |
| Too high | Too Low In range Too high | No Response Send Error Send Error |
The range of ICMP error messages that can be generated by the security code is very small. The only possible error messages are:
IP accounting is enabled on a per-interface basis. The IP accounting support records the number of bytes and packets switched through the system on a source and destination IP address basis. Only transit IP traffic is measured and only on an outbound basis; traffic generated by the communication server, or terminating in the communication server, is not included in the accounting statistics.
The interface subcommand ip accounting enables or disables IP accounting for transit traffic outbound on an interface. Full syntax of this command follows.
ip accountingThe global configuration command ip accounting-threshold enables or disables IP accounting for transit traffic outbound on an interface, as follows.
ip accounting-threshold thresholdThe accounting threshold defines the maximum number of entries (source and destination address pairs) that the communication server accumulates, preventing IP accounting from possibly consuming all available free memory. This level of memory consumption could occur in a communication server that is switching traffic for many hosts. The default threshold value is 512 entries. Overflows will be recorded; see the monitoring commands for display formats.
The following example sets the IP accounting threshold to only 500 entries.
ip accounting-threshold 500
Use the ip accounting-list global configuration command to filter accounting information for hosts. The full syntax for this command follows.
ip accounting-list ip-address maskThe source and destination address of each IP datagram is logically ANDed with the mask and compared with the ip-address. If there is a match, the information about the IP datagram will be entered into the accounting database. If there is no match, then the IP datagram is considered a transit datagram and will be counted according to the setting of the ip accounting-transits command described next.
Use the no ip accounting-list command with the appropriate argument to remove this function.
The ip accounting-transits global configuration command controls the number of transit records that will be stored in the IP accounting database. The full syntax of this command is as follows.
ip accounting-transits countTransit entries are those that do not match any of the filters specified by ip accounting-list commands. If you do not define filters, the communication server will not maintain transit entries. To maintain accurate accounting totals, the communication server software maintains two accounting databases: an active and a checkpointed database.
Use the no ip accounting-transits command to remove this function. The default is zero, which is equivalent to the no version of the command.
The following example specifies that no more than 100 transit records are stored.
ip accounting-transit 100
Use the EXEC command show ip accounting to display the active accounting database. The EXEC command show ip accounting checkpoint displays the checkpointed database. The EXEC command clear ip accounting clears the active database and creates the checkpointed database. See the sections "Maintaining the IP Network" and "Monitoring the IP Network" later in this chapter for more options on monitoring your network's accounting.
This section discusses how to configure static routes, source routing, and how to control IP processing on serial interfaces.
The command no ip source-route causes the system to discard any IP datagram containing a source-route option. The ip source-route global configuration subcommand allows the communication server to handle IP datagrams with source-routing header options.
ip source-routeThe default behavior is to perform the source routing.
The ip unnumbered interface subcommand enables IP processing on a serial interface, but does not assign an explicit IP address to the interface. The full command syntax is shown below:
ip unnumbered interface-nameThe argument interface-name is the name of another interface on which the communication server has an assigned IP address.
Whenever the unnumbered interface generates a packet (for example, for a routing update), it uses the address of the specified interface as the source address of the IP packet. It also uses the address of the specified interface in determining which routing processes are sending updates over the unnumbered interface. Restrictions include the following:
In the example below, the first serial interface is given Ethernet 0's address.
interface ethernet 0
ip address 131.108.6.6 255.255.255.0
interface serial 0
ip unnumbered ethernet 0
You can compress the TCP headers of your Internet packets to reduce the size of your packets. RFC 1144 specifies the compression process. Compressing the TCP header can speed up Telnet connections dramatically. In general, TCP header compression is advantageous when your traffic consists of many small packets, not for traffic that consists of large packets. Transaction processing (using terminals, usually) tends to use small packets while file transfers use large packets. This feature only compresses the TCP header, of course, so it has no effect on UDP packets or other protocol headers.
The ip tcp header-compression interface subcommand enables header compression. Full command syntax for this command follows:
ip tcp header-compression [passive]If you use the optional passive keyword, outgoing packets are only compressed if TCP incoming packets on the same interface are compressed. Without the passive keyword, the communication server will compress all traffic. The no ip tcp header-compression command (the default) disables compression. You must enable compression on both ends of a serial connection.
See the section "Monitoring the IP Network" for more explanation of commands for monitoring your compressed traffic.
The ip tcp compression-connections interface subcommand specifies the total number of header compression connections that can exist on an interface. Each connection sets up a compression cache entry, so you are in effect specifying the maximum number of cache entries and the size of the cache.
ip tcp compression-connections numberThe argument number specifies the number of connections the cache will support. The default is 16; number can vary between 3 and 256, inclusive. Too few cache entries for the specific interface can lead to degraded performance while too many cache entries leads to wasted memory.
In the following example, the first serial interface is set for header compression with a maximum often cache entries.
interface serial 0 ip tcp header-compression ip tcp compression-connections 10
This section shows complete configuration examples for the most common configuration situations.
In the example below, the second asynchronous interface is given Ethernet 0's address. The interface is unnumbered.
interface ethernet 0 ip address 145.22.4.67 255.255.255.0 interface async 1 ip unnumbered ethernet 0
In the example below, networks 192 and 131 are separated by a backbone as shown in
Figure 1-8. The two networks are brought into the same logical network through the use of secondary addresses.
interface ethernet 2 ip address 192.5.10.1 255.255.255.0 ip address 131.108.3.1 255.255.255.0 secondary
interface ethernet 1 ip address 192.5.10.2 255.255.255.0 ip address 131.108.3.2 255.255.255.0 secondary
The following example changes some of the ICMP defaults for the first Ethernet interface. Disabling the sending of redirects could mean you do not think your communication servers on this segment will ever have to send a redirect. Lowering the error processing load on your communication server would increase efficiency. Disabling the unreachables messages will have a secondary effect--it will also disable MTU path discovery because path discovery works by having routers send Unreachables messages. If you have a network segment with a small number of devices and an absolutely reliable traffic pattern--which could easily happen on a segment with a small number of little-used user devices--this would disable options your communication server would be unlikely to need to use anyway.
interface ethernet 0 no ip unreachables no ip redirects
In this example, one server is on network 191.24.1.0 and the other is on network 110.44.0.0, and you want to permit IP broadcasts from all hosts to reach these servers. Figure 1-9 illustrates how to configure the communication server that connects network 110 to network 191.
! ip forward-protocol udp ! interface ethernet 1 ip helper address 110.44.23.7 interface ethernet 2 ip helper address 191.24.1.19
The following example has a network segment with Hewlett-Packard devices on it. The commands listed customize the communication server's first Ethernet port to accommodate the HP devices.
ip hp-host bl4zip 131.24.6.27 interface ethernet 0 arp probe ip probe proxy
The example below establishes a domain list with several alternate domain names.
ip domain-list cisco.com ip domain-list telecomprog.edu ip domain-list merit.edu
In the next example, network 36.0.0.0 is a Class A network whose second octet specifies a subnet; that is, its subnet mask is 255.255.0.0. The third and fourth octets of a network 36.0.0.0 address specify a particular host. Using access list 2, the communication server would accept one address on subnet 48 and reject all others on that subnet. The communication server would accept addresses on all other network 36.0.0.0 subnets; that is the purpose of the last line of the list.
access-list 2 permit 36.48.0.3 0.0.0.0 access-list 2 deny 36.48.0.0 0.0.255.255 access-list 2 permit 36.0.0.0 0.255.255.255 interface ethernet 0 access-group 2
In the example below, the first line permits any incoming TCP connections with a destination port greater than 1023. The second line permits incoming TCP connections to the SMTP port of host 128.88.1.2. The last line permits incoming ICMP messages for error feedback.
access-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 gt 1023 access-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.1.2 0.0.0.0 eq 25 access-list 102 permit icmp 0.0.0.0 255.255.255.255 128.88.0.0 255.255.255.255 interface ethernet 0 access-group 102
Use the EXEC commands described in this section to maintain IP routing caches, tables, and databases.
The clear arp-cache EXEC command removes all dynamic entries from the Address Resolution Protocol (ARP) cache. Enter this command at the EXEC prompt:
clear arp-cacheUse the EXEC command clear host to remove one or all entries from the host-name-and-address cache, depending upon the argument you specify.
clear host {name|*}To remove a particular entry, use the argument name to specify the host. To clear the entire cache, use the asterisk (*) argument. The host-name entries will not be removed from NVRAM but will be cleared in running memory.
Use the clear ip accounting command to clear the active database when IP accounting is enabled. Use the clear ip accounting checkpoint command to clear the checkpointed database when IP accounting is enabled. You can also clear the checkpointed database by issuing the clear ip accounting command twice in succession. Enter one of these commands at the EXEC prompt.
clear ip accounting [checkpoint]Use the clear ip route command to remove a route from the IP routing table. Enter this command at the EXEC prompt:
clear ip route {network|*}The optional argument network is the network or subnet address of the route that you want to remove. Use the asterisk (*) argument to clear the entire routing table.
Use the EXEC commands described in this section to obtain displays of activity on the IP network.
To display a list of all the available EXEC commands for monitoring the IP network use the following command:
show ip ?Following is sample output:
CS> show ip ?
accounting <checkpoint> Accounting statistics
arp IP ARP table
bgp <address> Border Gateway Protocol
egp EGP peers
interface <name> Interface settings
protocols Routing processes
route <network> Routing table
tcp <keyword> TCP information, type "show ip tcp ?" for list
traffic Traffic statistics
A listing is available at both the user and privileged levels. The display will show relevant commands for each level.
To display the ARP cache, use the following EXEC command:
show ip arpThis command displays the contents of the ARP cache. ARP establishes correspondences between network addresses (an IP address, for example) and LAN hardware addresses (Ethernet addresses). A record of each correspondence is kept in a cache for a predetermined amount of time and then discarded. Following is sample output. Table 1-8 describes the fields seen.
CS> show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
AppleTalk 4.57 0 aa00.0400.6408 ARPA Ethernet0
Internet 131.108.1.140 137 aa00.0400.6408 ARPA Ethernet0
Internet 131.108.1.111 156 0800.2007.8866 ARPA Ethernet0
AppleTalk 4.128 0 aa00.0400.6508 ARPA Ethernet0
AppleTalk 4.129 - aa00.0400.0134 ARPA Ethernet0
Internet 131.108.1.115 33 0000.0c01.0509 ARPA Ethernet0
Internet 192.31.7.24 5 0800.0900.46fa ARPA Ethernet2
Internet 192.31.7.26 41 aa00.0400.6508 ARPA Ethernet2
Internet 192.31.7.27 - aa00.0400.0134 ARPA Ethernet2
Internet 192.31.7.28 67 0000.0c00.2c83 ARPA Ethernet2
Internet 192.31.7.17 67 2424.c01f.0711 ARPA Ethernet2
Internet 192.31.7.18 64 0000.0c00.6fbf ARPA Ethernet2
Internet 192.31.7.21 114 2424.c01f.0715 ARPA Ethernet2
Internet 131.108.1.33 15 0800.2008.c52e ARPA Ethernet0
Internet 131.108.1.55 44 0800.200a.bbfe ARPA Ethernet0
Internet 131.108.1.6 89 aa00.0400.6508 ARPA Ethernet0
Internet 131.108.7.1 - 0000.0c00.750f ARPA Ethernet3
Internet 131.108.1.1 - aa00.0400.0134 ARPA Ethernet0
Internet 131.108.1.27 75 0800.200a.8674 ARPA Ethernet0
| Field | Description |
|---|---|
| Protocol | Protocol for network address in the Address field |
| Address | The network address that corresponds to Hardware Addr |
| Age (min) | Age, in minutes, of the cache entry |
| Hardware Addr | LAN hardware address that corresponds to network address |
| Type | Type of encapsulation:
ARPA= Ethernet |
| Interface | Interface for which ARP information is provided |
The show ip accounting command displays the active accounting database. The show ip accounting checkpoint command displays the checkpointed database.
show ip accounting [checkpoint]Following is sample output for the show ip accounting and show ip accounting checkpoint commands:
CS> show ip accounting
Source Destination Packets Bytes
131.108.19.40 192.67.67.20 7 306
131.108.13.55 192.67.67.20 67 2749
131.108.2.50 192.12.33.51 17 1111
131.108.2.50 130.93.2.1 5 319
131.108.2.50 130.93.1.2 463 30991
131.108.19.40 130.93.2.1 4 262
131.108.19.40 130.93.1.2 28 2552
131.108.20.2 128.18.6.100 39 2184
131.108.13.55 130.93.1.2 35 3020
131.108.19.40 192.12.33.51 1986 95091
131.108.2.50 192.67.67.20 233 14908
131.108.13.28 192.67.67.53 390 24817
131.108.13.55 192.12.33.51 214669 9806659
131.108.13.111 128.18.6.23 27739 1126607
131.108.13.44 192.12.33.51 35412 1523980
192.31.7.21 130.93.1.2 11 824
131.108.13.28 192.12.33.2 21 1762
131.108.2.166 192.31.7.130 797 141054
131.108.3.11 192.67.67.53 4 246
192.31.7.21 192.12.33.51 15696 695635
192.31.7.24 192.67.67.20 21 916
131.108.13.111 128.18.10.1 16 1137
The output lists the source and destination addresses, as well as total number of packets and bytes for each address pair.
The show hosts command displays the default domain name, the style of name lookup service, a list of name server hosts, and the cached list of host names and addresses.
show hostsEnter show hosts at the user-level (or privileged-level) prompt.
Following is sample output. Table 1-9 describes the different fields.
CS> show hosts
Default domain is CISCO.COM
Name/address lookup uses domain service
Name servers are 255.255.255.255
Host Flags Age Type Address(es)
SLAG.CISCO.COM (temp, OK) 1 IP 131.108.4.10
CHAR.CISCO.COM (temp, OK) 8 IP 192.31.7.50
CHAOS.CISCO.COM (temp, OK) 8 IP 131.108.1.115
DIRT.CISCO.COM (temp, EX) 8 IP 131.108.1.111
DUSTBIN.CISCO.COM (temp, EX) 0 IP 131.108.1.27
DREGS.CISCO.COM (temp, EX) 24 IP 131.108.1.30
| Field | Description |
|---|---|
| Host | Name of the host for which information is being provided |
| Flag | temp entry in the Flags field is entered by a name server; the communication server removes the entry after 72 hours of inactivity.
perm entry is entered by a configuration command and is not timed out. Entries marked Entries marked |
| Age | The number of hours since the communication server last referred to the cache entry. . |
| Type | The type of address, for example, IP. If you have used the ip hp-host configuration command (see the section "HP Probe Proxy Support"), the show hosts command will display these host names as type HP-IP.
|
| Address(es) | The address of the host. One host may have up to eight addresses. |
If you have used the ip hp-host configuration command (see the section"HP Probe Proxy Support"), the show hosts command will display these host names as type HP-IP.
To display the usability status of interfaces, use the EXEC command show interfaces. If the interface hardware is usable, the interface is marked "up." If the interface can provide two-way communication, the line protocol is marked "up." For an interface to be usable, both the interface hardware and line protocol must be up.
show ip interface [interface unit]If you specify an optional interface type, you will see only information on that specific interface.
If you specify no optional parameters, you will see information on all the interfaces.
The following sample output was obtained by specifying the serial 0 interface. Table 1-10 describes the fields in the output.
cs> show ip interface serial 0
Serial 0 is up, line protocol is up
Internet address is 192.31.7.129, subnet mask is 255.255.255.240
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is 131.108.1.255
Outgoing access list is not set
Proxy ARP is enabled
Security level is default
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
Gateway Discovery is disabled
IP accounting is enabled, system threshold is 512
TCP/IP header compression is disabled
Probe proxy name replies are disabled
| Field | Description |
|---|---|
| Broadcast Address | The broadcast address. |
| Helper Address | A helper address, if one has been set. |
| Outgoing Access | Indicates whether or not the interface has an outgoing access list set. |
| Proxy ARP | Indicates whether Proxy ARP is enabled for the interface. |
| Security Level | Specifies the IPSO security level set for this interface. |
| ICMP redirects | Specifies whether redirects will be sent on this interface. |
| ICMP unreachable | Specifies whether unreachable messages will be sent on this interface. |
| ICMP mask replies | Specifies whether mask replies will be sent on this interface. |
| Gateway Discovery | Specifies whether the discovery process has been enabled for this interface. It is generally disabled on serial interfaces, such as this one. |
| IP accounting | Specifies whether IP accounting is enabled for this interface and what the threshold (maximum number of entries) is. |
| TCP/IP header compression | Indicates whether compression is enabled or disabled. |
| Probe proxy | Indicates whether the function is enabled or disabled. |
The show ip route command displays the IP routing table. Enter this command at the EXEC prompt:
show ip route [network]A specific network in the routing table is displayed when the optional network argument is entered.
Following is sample output with the optional network argument. Table 1-11 describes the fields in the output.
CS> show ip route network
Routing entry for 131.108.1.0
Known via "igrp 109", distance 100, metric 1200
Redistributing via igrp 109
Last update from 131.108.6.7 on Ethernet0, 35 seconds ago
Routing Descriptor Blocks:
* 131.108.6.7, from 131.108.6.7, 35 seconds ago, via Ethernet0
Route metric is 1200, traffic share count is 1
Total delay is 2000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
The following is the result of the show ip route command without the network number:
Codes: I - IGRP derived, R - RIP derived, H - HELLO derived
C - connected, S - static, E - EGP derived, B - BGP derived
* - candidate default route
Gateway of last resort is 131.108.6.7 to network 131.119.0.0
I*Net 128.145.0.0 [100/1020300] via 131.108.6.6, 30 sec, Ethernet0
I Net 192.68.151.0 [100/160550] via 131.108.6.6, 30 sec, Ethernet0
I Net 128.18.0.0 [100/8776] via 131.108.6.7, 58 sec, Ethernet0
via 131.108.6.6, 31 sec, Ethernet0
E Net 128.128.0.0 [140/4] via 131.108.6.64, 130 sec, Ethernet0
C Net 131.108.0.0 is subnetted (mask is 255.255.255.0), 54 subnets
I 131.108.144.0 [100/1310] via 131.108.6.7, 78 sec, Ethernet0
C 131.108.91.0 is directly connected, Ethernet1
| Field | Description |
|---|---|
| First field | Specifies how the route was derived. The options are listed above the routing table. |
| Second field | Specifies a remote network/subnet to which a route exists. The first number in brackets is the administrative distance of the information source; the second number is the metric for the route. |
| Third field | Specifies the IP address of a router or communication server that is the next hop to the remote network. |
| Fourth field | Specifies the number of seconds since this network was last heard. |
| Final field | Specifies the interface through which you can reach the remote network via the specified communication server. |
The show ip traffic command displays IP protocol statistics. Enter this command at the EXEC prompt:
show ip trafficFollowing is sample output. Table 1-12 describes the fields.
CS> show ip traffic
IP statistics:
Rcvd: 98 total, 98 local destination
0 format errors, 0 checksum errors, 0 bad hop count
0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options
Frags: 0 reassembled, 0 timeouts, 0 too big
0 fragmented, 0 couldn't fragment
Bcast: 38 received, 52 sent
Sent: 44 generated, 0 forwarded
0 encapsulation failed, 0 no route
ICMP statistics:
Rcvd: 0 checksum errors, 0 redirects, 0 unreachable, 0 echo
0 echo reply, 0 mask requests, 0 mask replies, 0 quench
0 parameter, 0 timestamp, 0 info request, 0 other
Sent: 0 redirects, 3 unreachable, 0 echo, 0 echo reply
0 mask requests, 0 mask replies, 0 quench, 0 timestamp
0 info reply, 0 time exceeded, 0 parameter problem
UDP statistics:
Rcvd: 56 total, 0 checksum errors, 55 no port
Sent: 18 total, 0 forwarded broadcasts
TCP statistics:
Rcvd: 0 total, 0 checksum errors, 0 no port
Sent: 0 total
EGP statistics:
Rcvd: 0 total, 0 format errors, 0 checksum errors, 0 no listener
Sent: 0 total
IGRP statistics:
Rcvd: 73 total, 0 checksum errors
Sent: 26 total
HELLO statistics:
Rcvd: 0 total, 0 checksum errors
Sent: 0 total
ARP statistics:
Rcvd: 20 requests, 17 replies, 0 reverse, 0 other
Sent: 0 requests, 9 replies (0 proxy), 0 reverse
Probe statistics:
Rcvd: 6 address requests, 0 address replies
0 proxy name requests, 0 other
Sent: 0 address requests, 4 address replies (0 proxy)
0 proxy name replies
| Field | Description |
|---|---|
| format error | Occurs when a packet is discarded because its time-to-live (TTL) field was decremented to zero |
| bad hop count | Occurs when a packet is discarded because its time-to-live (TTL) field was decremented to zero |
| encapsulation failure | Usually indicates that the communication server received no reply to an ARP request and therefore did not send a datagram |
| no route occurrence | Counted when the communication server discards a datagram it did not know how to route |
| proxy reply | Counted when the communication server sends an ARP or Probe Reply on behalf of another host. The display shows the number of probe proxy requests that have been received and the number of responses that have been sent. |
The show ip tcp header-compression command shows statistics on compression. Enter this command at the EXEC prompt:
show ip tcp header-compressionFollowing is sample output. Table 1-13 describes the fields.
cs> show ip tcp header-compression
TCP/IP header compression statistics:
Interface Seria1: (passive, compressing)
Rcvd: 4060 total, 2891 compressed, 0 unknown type, 0 errors
0 dropped, 1 buffer copies, 0 buffer failures
Sent: 4284 total, 3224 compressed,
105295 bytes saved, 661973 bytes sent
1.15 efficiency improvement factor
Connect: 16 slots, 1543 long searches, 2 misses, 99% hit ratio
Five minute miss rate 0 misses/sec, 0 max misses/sec
| Field | Description |
|---|---|
| buffer copies | The number of packets that had to be copied into bigger buffers for decompression. |
| report buffer failures | The number of packets dropped due to a lack of buffers. |
| efficiency improvement factor | The improvement in line efficiency because of TCP header compression. |
| slots | The number of slots is the size of the cache. |
| long searches | The number of times the software had to look to find a match. |
| misses | The number of times a match could not be made. If your output shows a large miss rate, then the number of allowable simultaneous compression connections may be too small. |
| hit ratio | The percentage of times the software found a match and was able to compress the header. |
| Five minute miss rate | The miss rate over the previous five minutes for a longer-term (and more accurate) look at miss-rate trends. |
The privileged-mode EXEC command ping allows the administrator to diagnose network connectivity by sending ICMP Echo Request messages and waiting for ICMP "Echo Reply" messages. The following sample sessions show ping command output for IP.
cs# ping 131.108.62.102
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 131.108.62.102, timeout is 2 seconds:
.....
Success rate is 0 percent
Sandbox# ping
Protocol [ip]:
Target IP address: 131.108.1.27
Repeat count [5]:
Datagram size [100]: 1000
Timeout in seconds [2]:
Extended commands [n]: yes
Source address:
Type of service [0]:
Set DF bit in IP header? [no]: yes
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Sending 5, 1000-byte ICMP Echos to 131.108.2.27, timeout is 2 seconds:
M.M.M
Success rate is 60 percent, round-trip min/avg/max = 4/6/12 ms
The ping command uses the notation shown in Table 1-14 to indicate the responses it sees.
| Character | Meaning |
|---|---|
| ! | Each exclamation point indicates receipt of a reply. |
| . | Each period indicates the network server timed out while waiting for a reply. |
| U | Destination unreachable error PDU received. |
| N | Network unreachable. |
| P | Protocol unreachable. |
| Q | Source quench. |
| M | Could not fragment. |
| ? | Unknown packet type. |
To abort a ping session, type the escape sequence (by default, Ctrl-^, X, which is done by simultaneously pressing the Ctrl, Shift, and 6 keys, letting go, and then pressing the x key).
The IP ping command, in verbose mode, accepts a data pattern. The pattern is specified as a 16-bit hexadecimal number. The default pattern is 0xABCD. Patterns such as all ones or all zeros can be used to debug data sensitivity problems on CSUs (digital devices that connecting end user equipment to the local digital telephone loop and DSUs (devices used in digitial transmission for connecting a CSU to a DTE).
You can also specify the communication server address to use as the source address for ping packets, which here is 131.108.105.62.
Sandbox# ping Protocol [ip]: Target IP address: 131.108.1.111 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: yes Source address: 131.108.105.62 Type of service [0]: Set DF bit in IP header? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.1.111, timeout is 2 seconds: !!!!! Success rate is 100 percent, round-trip min/avg/max = 4/4/4 ms
The EXEC command trace allows you to discover the routing path your communication server's packets are taking through your network.
The trace command offers default and settable parameters for specifying a simple or extended trace mode.
The trace command starts by sending probe datagrams with a TTL value of one. This causes the first communication server to discard the probe datagram and send back an error message. The trace command sends several probes at each TTL level and displays the round trip time for each.
The trace command sends out one probe at a time. Each outgoing packet may result in one or two error messages. A "time exceeded" error message indicates that an intermediate communication server has seen and discarded the probe. A "destination unreachable" error message indicates that the destination node has received the probe and discarded it because it could not deliver the packet. If the timer goes off before a response comes in, trace prints an asterisk (*).
The trace command terminates when the destination responds, when the maximum TTL was exceeded, or when the user interrupts the trace with the escape sequence. By default, to invoke the escape sequence, type Ctrl-^, X--done by simultaneously pressing the Ctrl, Shift, and 6 keys, letting go, and then pressing the x key.
Due to bugs in the IP implementations of various hosts and communication servers, the trace command may behave in odd ways.
Not all destinations will correctly respond to a "probe" message by sending back an "ICMP port unreachable" message. A long sequence of TTL levels with only asterisks, terminating only when the maximum TTL has been reached, may indicate this problem.
There is a known problem with the way some hosts handle an "ICMP TTL exceeded" message. Some hosts generate an "ICMP" message but they re-use the TTL of the incoming packet. Since this is zero, the ICMP packets do not make it back. When you trace the path to such a host, you may see a set of TTL values with asterisks (*). Eventually the TTL gets high enough that the "ICMP" message can get back. For example, if the host is six hops away, trace will time out on responses 6 through 11.
When tracing IP routes, you can set the following trace command parameters:
Table 1-15 describes the output from this test.
| Character | Meaning |
|---|---|
| nn msec | For each node, the round-trip time (in mm milliseconds) for the specified number of probes. |
| * | The probe timed out. |
| ? | Unknown packet type. |
| Q | Source quench. |
| P | Protocol unreachable. |
| N | Network unreachable. |
| U | Host unreachable. |
The following is an example of the simple use of trace.
chaos# trace ABA.NYC.mil Type escape sequence to abort. Tracing the route to ABA.NYC.mil (26.0.0.73) 1 DEBRIS.CISCO.COM (131.108.1.6) 1000 msec 8 msec 4 msec 2 BARRNET-GW.CISCO.COM (131.108.16.2) 8 msec 8 msec 8 msec 3 EXTERNAL-A-GATEWAY.STANFORD.EDU (192.42.110.225) 8 msec 4 msec 4 msec 4 BB2.SU.BARRNET.NET (131.119.254.6) 8 msec 8 msec 8 msec 5 SU.ARC.BARRNET.NET (131.119.3.8) 12 msec 12 msec 8 msec 6 MOFFETT-FLD-MB.in.MIL (192.52.195.1) 216 msec 120 msec 132 msec 7 ABA.NYC.mil (26.0.0.73) 412 msec 628 msec 664 msec
Following is an example of going through the extended dialog of the trace command.
chaos# trace Protocol [ip]: Target IP address: mit.edu Source address: Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to MIT.EDU (18.72.2.1) 1 DEBRIS.CISCO.COM (131.108.1.6) 1000 msec 4 msec 4 msec 2 BARRNET-GW.CISCO.COM (131.108.16.2) 16 msec 4 msec 4 msec 3 EXTERNAL-A-GATEWAY.STANFORD.EDU (192.42.110.225) 16 msec 4 msec 4 msec 4 NSS13.BARRNET.NET (131.119.254.240) 112 msec 8 msec 8 msec 5 SALT_LAKE_CITY.UT.NSS.NSF.NET (129.140.79.13) 72 msec 64 msec 72 msec 6 ANN_ARBOR.MI.NSS.NSF.NET (129.140.81.15) 124 msec 124 msec 140 msec 7 PRINCETON.NJ.NSS.NSF.NET (129.140.72.17) 164 msec 164 msec 172 msec 8 ZAPHOD-GATEWAY.JVNC.NET (128.121.54.72) 172 msec 172 msec 180 msec 9 HOTBLACK-GATEWAY.JVNC.NET (130.94.0.78) 180 msec 192 msec 176 msec 10 CAPITAL1-GATEWAY.JVNC.NET (130.94.1.9) 280 msec 192 msec 176 msec 11 CHEESESTEAK2-GATEWAY.JVNC.NET (130.94.33.250) 284 msec 216 msec 200 msec 12 CHEESESTEAK1-GATEWAY.JVNC.NET (130.94.32.1) 268 msec 180 msec 176 msec 13 BEANTOWN2-GATEWAY.JVNC.NET (130.94.27.250) 300 msec 188 msec 188 msec 14 NEAR-GATEWAY.JVNC.NET (130.94.27.10) 288 msec 188 msec 200 msec 15 IHTFP.MIT.EDU (192.54.222.1) 200 msec 208 msec 196 msec 16 E40-03GW.MIT.EDU (18.68.0.11) 196 msec 200 msec 204 msec 17 MIT.EDU (18.72.2.1) 268 msec 500 msec 200 msec
Use the EXEC commands described in this section to troubleshoot and monitor the IP network transactions and lines in SLIP line mode. For each debug command there is an corresponding undebug command that turns the display off. In general, you need use these commands only during troubleshooting sessions with your technical support personnel, as displaying debugging messages can impact the operation of the communication server.
The debug arp command enables logging of ARP and Probe protocol transactions.
The debug ip-icmp command enables logging of ICMP transactions. Refer to the ICMP section for an in-depth look at the various ICMP messages.
The debug ip-packet command enables logging of general IP debugging information as well as IPSO security transactions. IP debugging information includes packets received, generated, and forwarded. This command can also be used to debug IPSO security-related problems. Each time a datagram fails a security test in the system, a message is logged describing the cause of failure. An optional IP access list can be specified. If the datagram is not permitted by that access list, then the related debugging output is suppressed.
The debug ip-routing command enables logging of routing table events such as network appearances and disappearances.
The debug ip-tcp command enables logging of significant TCP transactions such as state changes, retransmissions, and duplicate packets.
The debug ip-tcp-packet command enables logging of each TCP packet that meets the permit criteria specified in the access list.
The debug ip-udp command enables logging of UDP-based transactions.
debug ip-tcp-header-compression
The debug ip-header-compression command enables logging of TCP header compression statistics.
Debugging information, including information about HP Probe Proxy Requests, is available through debug probe.
This section lists and summarizes commands you can use to configure your IP communication server. Commands are listed in alphabetical order.
[no] access-list list {permit|deny} source source-mask
Creates or removes an access list. The argument list is an IP list number from 1 to 99. The keywords permit and deny specify the security action to take. The argument source is a 32-bit, dotted decimal notation IP address to which the communication server compares the address being tested. The argument source-mask is wildcard mask bits for the address in 32-bit, dotted decimal notation.
[no] access-list list {permit|deny} protocol source source-mask destination destination-mask
[operator operand] [established]
Creates or removes an extended access list. The argument list is an IP list number from 100 to 199. The keywords permit and deny specify the security action to take. The argument protocol is one of the supported protocol keywords--ip, tcp, udp, icmp. The argument source is a 32-bit, dotted decimal notation IP address. The argument source-mask is mask bits for the source address in 32-bit, dotted decimal notation. The arguments destination and destination-mask are the destination address and mask bits for the destination address in 32-bit, dotted decimal notation. Using TCP and UDP, the optional arguments operator and operand can be used to compare destination ports, service access points, or contact names. The optional established keyword is for use in matching certain TCP datagrams (see "Configuring Extended Access Lists").
[no] arp internet-address hardware-address type [alias]
Installs a permanent entry in the ARP cache. The communication server uses this entry to translate 32-bit Internet Protocol addresses into 48-bit hardware addresses. The argument internet-address is the Internet address in dotted decimal format corresponding to the local data link address specified by the argument hardware-address. The argument type is an encapsulation description--arpa for Ethernets. The optional keyword alias indicates that the communication server should respond to ARP requests as if it were the owner of the specified IP address.
[no] async-bootp tag [:hostname] data ...
Specifies extended BootP requests defined in RFC 1084 (used in configuring the communication server for SLIP support). The argument tag is the item being requested, and is one of the following expressed as file name, integer, or IP dotted decimal address:
The optional argument :hostname indicates that this entry applies only to the host specified. The argument :hostname accepts both an IP address and logical host name. The argument data can be a list of IP addresses entered in dotted decimal notation or as logical host names, a number, or a quoted string. Use the no async-bootp command to clear the list.
[no] ip accounting-list ip-address mask
Specifies a set of filters to control the hosts for which IP accounting information is kept. The source and destination address of each IP datagram is logically ANDed with the mask and compared with ip-address. If there is a match, the information about the IP datagram will be entered into the accounting database. If there is no match, then the IP datagram is considered a transit datagram and will be counted according to the setting of the ip accounting-transits command. The no form of this command disables this feature.
[no] ip accounting-threshold threshold
Sets the maximum number of accounting entries to be created. The no form of this command disables this feature.
[no] ip accounting-transits count
Controls the number of transit records that will be stored in the IP accounting database. Transit entries are those that do not match any of the filters specified by ip accounting-list commands. If no filters are defined, no transit entries are possible. The default is zero, which is equivalent to the no version of the command.
[no] ip default-gateway address
Sets up a default gateway for the communication sever. The ip default-gateway command specifies the router the communication server uses to send packets to hosts not on the local network or subnet. The argument address is the Internet address of the router.
[no] ip default-network network
Flags networks as candidates for default routes. The argument network specifies the network number.
[no] ip domain-list name
Defines a list of default domain names to complete unqualified host names. The argument name is the domain name. The no form of this command disables this feature.
[no] ip domain-lookup
Enables or disables IP Domain Name System-based host-name-to-address translation. Enabled by default. The no variation of the command disables the feature.
[no] ip domain-name name
Defines the default domain name, which is specified by the argument name. The
communication server uses the default domain name to complete unqualified domain names--names without a dotted domain name. The no form of this command disables use of the Domain Name System
[no] ip host name [TCP-port-number] address1 [address2...address8]
Defines a static host name-to-address mapping in the host cache. The argument name is the host name. The argument TCP-port-number is the TCP port number. The argument address is an associated IP address. You can specify up to eight Internet address arguments, each separated by a space. The first address argument is required.
[no] ip hp-host name [TCP-port-number] address1 [address2...address8]
Defines a static host-name-to-address mapping in the host cache. The argument name is the host name; the argument TCP-port-number is a TCP port number--Telnet by default (port 23); and the argument address1 [address2...address8] represents associated IP addresses (up to eight can be specified). The no version removes the name-to-address mapping.
[no] ip hp-host hostname ip-address
Enables or disables the use of the proxy service. You enter the hostname of the HP host into the host table, along with its IP address.
[no] ip ipname-lookup
Specifies or removes the IP IEN-116 Name Server host-name-to-address translation. This command is disabled by default; the no variation of the command restores the default.
[no] ip mtu bytes
Sets the maximum transmission unit (MTU) or size of IP packets sent on an interface. The argument bytes is the number of bytes with a minimum of 128 bytes. The no form of the command restores the default.
[no] ip name-server server-address1 [server-address2...server-address6]
Specifies the address of the name server to use for name and address resolution. The arguments server-address are the Internet addresses of up to six name servers. By default, the communication server uses the all-ones broadcast address (255.255.255.255).
[no] ip probe proxy
Enables or disables HP Probe Proxy support, which allows a communication server to respond to HP Probe Proxy Name requests.
[no] ip routing
Controls the system's ability to do IP routing. If the system is running optional. The default setting is to perform IP routing.
[no] ip source-route
Controls the handling of IP datagrams with source routing header options. The default behavior is to perform the source routing. The no keyword causes the system to discard any IP datagram containing a source-route option.
[no] ip subnet-zero
Enables or disables the ability to configure and route to "subnet zero" subnets. The default condition is disabled.
Provides faster response to user interrupt characters. The argument number is the number of characters output before the interrupt executes. The suggested value of number is 80, which will typically abort output within a line or two of where the user types the interrupt character. Values of less than 50 are not recommended for reasons of efficiency.
This section lists and summarizes all the commands in the interface subcommand list for your communication server. Preceding any of these commands with a no keyword undoes their effect or restores the default condition. Commands are listed in alphabetical order.
[no] access-group list
Defines an access group. This subcommand takes a standard or extended IP access list number as an argument.
[no] arp {arpa|probe|snap}
Controls the interface-specific handling of IP address resolution into 48-bit Ethernet and Token Ring hardware addresses. The keyword arpa, which is the default, specifies standard Ethernet-style ARP (RFC 826), probe specifies the Probe protocol for IEEE-802.3 networks, and snap specifies ARP packets conforming to RFC 1042.
[no] arp timeout seconds
Sets the number of seconds an ARP cache entry will stay in the cache. The value of the argument seconds is used to age an ARP cache entry related to that interface, and by default is set to 14,400 seconds. A value of zero seconds sets no timeout. The no form of the command returns the default.
[no] ip accounting
Enables or disables IP accounting on an interface.
[no] ip address address mask [secondary]
Sets an IP address for an interface. The two required arguments are an IP address and the subnet mask for the associated IP network. The subnet mask must be the same for all interfaces connected to subnets of the same network.
[no] ip broadcast-address [address]
Defines a broadcast address. The address argument is the desired IP broadcast address for a network. If a broadcast address is not specified, the system will default to a broadcast address of all ones or 255.255.255.255
[no] ip directed-broadcast
Enables or disables forwarding of directed broadcasts on the interface. The default is to forward directed broadcasts.
[no] ip forward-protocol {udp|nd} [port]
Controls forwarding of physical and directed IP broadcasts. This command controls which protocols and ports are forwarded for an interface on which an ip helper-address command has been specified. The keyword nd is the ND protocol used by older diskless Sun workstations. The keyword udp is the UDP protocol. By default both UDP and ND forwarding are enabled if a helper address has been given for an interface.
Configures the Router Discovery feature using the Cisco GDP routing protocol. The no ip gdp gdp command turns the feature off.
[no] ip gdp igrp
Configures the Router Discovery feature using the Cisco IGRP routing protocol. The no ip gdp igrp command turns the feature off.
[no] ip gdp rip
Configures the Router Discovery feature using the UNIX RIP routing protocol. The no ip gdp rip command turns the feature off.
[no] ip helper-address address
Defines a helper-address for a specified address. The helper-address defines the selective forwarding of UDP broadcasts, including BootP, received on the interface. The address argument specifies a destination broadcast or host address to be used when forwarding such datagrams.
[no] ip mask-reply
Sets the interface to send ICMP Mask Reply messages. The default is not to send Mask Reply messages.
[no] ip proxy-arp
Enables or disables proxy ARP on the interface. The default is to perform proxy ARP.
[no] ip redirects
Disables sending ICMP redirects on the interface. ICMP redirects are normally sent.
[no] ip security add
Adds a basic security option to all datagrams leaving the communication server on the specified interface. The no form of the command disables the function.
ip security dedicated level authority [authority...]
Sets or unsets the requested level of classification and authority on the interface. See Table 1-4 and Table 1-5 for the level and authority arguments.
[no] ip security extended-allowed
Allows or rejects datagrams with an extended security option on the specified interface.
Prioritize the presence of security options on a datagram.
[no] ip security ignore-authorities
Sets or unsets an interface to ignore the authority fields of all incoming datagrams.
[no] ip security implicit-labelling [level authority [authority...]]
In the simplest form, sets or unsets the interface to accept datagrams, even if they do not include a security option. With the arguments level and authority, a more precise condition is set. See Table 1-4 and Table 1-5 for the level and authority arguments.
ip security multilevel level1 [authority...] to level2 authority2 [authority2...]
Sets or unsets the requested range of classification and authority on the interface. Traffic entering or leaving the system must have a security option that falls within the specified range. See Table 1-4 and Table 1-5 for the level and authority arguments.
[no] ip security strip
Removes any basic security option on all datagrams leaving the communication server on the specified interface. The no form of the command disables the function.
[no] ip tcp compression-connections number
Sets the maximum number of connections per interface that the compression cache can support. Default is 16; number can vary from 3 to 256.
[no] ip tcp header-compression [passive]
Enables TCP header compression. The no keyword disables (the default) compression. The optional keyword passive sets the interface to only compress outgoing traffic on the interface for a specific destination if incoming traffic is compressed.
[no] ip unnumbered interface-name
Enables IP processing on a serial interface, but does not assign an explicit IP address to the interface. The argument interface-name is the name of another interface on which the communication server has assigned an IP address. The interface cannot be another unnumbered interface or the interface itself.
[no] ip unreachables
Enables or disables sending ICMP Unreachable messages on an interface. ICMP unreachable messages are normally sent.
transmit-interface interface-name
Assigns a transmit interface to a receive-only interface. When a route is learned on this receive-only interface, the interface designated as the source of the route is converted to interface-name.
Following is an alphabetically arranged summary of the TCP/IP line subcommands.
Restricts incoming and outgoing connections between a particular terminal line or group of lines and the addresses in an access list. The argument list is an integer from 1 through 99 that specifies the defined access list. The keyword in controls which hosts can make Telnet or TCP connections into the communication server. The keyword out defines the access checks made on outgoing connections.
[no] ip alias internet-address TCP-port
Assigns an Internet address to the service provided on a TCP port. The argument internet-address is the Internet address for the service, and the argument TCP-port is the number of the TCP port.
The no keyword with the Internet address removes the specified address for the communication server.
Causes the system to generate a hardware Break signal on the RS-232 line that is associated with a Telnet connection, when a Telnet Interrupt-Process (IP) command is received on that connection. A hardware Break command is generated when a Telnet Break command is received.
Suppresses negotiation of the Telnet Remote Echo and Suppress Go Ahead options. This subcommand causes Telnet to refuse to negotiate the options on incoming connections.
telnet speed default-speed maximum-speed
Negotiates speeds on reverse Telnet lines. The argument default-speed is the line speed the communication server will use in the absence of speed negotiation by the device on the other end of the connection. The argument maximum-speed is the maximum speed the communication server will use.
Causes the communication server to send a Telnet Synchronize signal when it receives a Telnet Break signal. The TCP Synchronize signal clears the data path, but will still interpret incoming commands.
Causes the communication server to send a Return (CR) as a CR followed by a NULL instead of a CR followed by a Line Feed (LF). This subcommand is useful for coping with different interpretations of end-of-line handling in the Telnet protocol specification.
|
|