Before any addresses can be assigned, you must decide what address space to use for the devices in your network and how to allocate that address space. This decision is important ”the way in which you assign addresses now may have a serious impact on your network in the future. Answering the following questions helps you determine what address space to use:
If your network will connect to the Internet or to another company's network, it is important for it to have a unique network address space. If you choose network addresses that are the same as those used in another network, routers within the Internet cannot properly distinguish the duplicate addresses. If your network connects to the Internet via a single ISP or NSP, that provider normally provides you with unique address space from a large pool that has been allocated to it by one of a number of network address registries. These registries include the American Registry for Internet Numbers (ARIN), R seaux IP Europ ens (RIPE), and Asia Pacific Network Information Center (APNIC). The ISP allocates your network address space based on factors such as the number of hosts in your network, the number of physical LAN and WAN segments, and the expected growth of your network.
In cases in which your network is connected to multiple service providers, there are two options for obtaining address space. With the first option, your network has IP addresses assigned by one ISP. Because these addresses are assigned out of the ISP's address space, traffic coming to your network follows a path through that service provider's network. However, your network is connected to multiple service providers, so traffic leaving your network can take a different path from inbound traffic, a situation known as asymmetric routing. This scenario may be fine for your network if the predominant traffic flow is outbound and the desire is to load-share. This scenario might also be okay if the additional ISP connection is simply for redundancy (in case of failure). But this scenario may be less than optimal if your predominant traffic flow is inbound to your network and the desire is to load-share across the multiple ISPs.
The second scenario for obtaining address space when the network is connected to multiple ISPs is to request it directly from the registry for your region. Generally speaking, the registries discourage this practice and have set up stringent guidelines for IP address assignments directly to end user networks. The explosive growth in the number of unique networks on the Internet has resulted in a lack of available address space and an exponential growth in the size of the routing tables for the complete Internet. These challenges have prompted the registries to adopt their stringent policies for distributing IP addresses.
Requesting addresses directly from a registry is appropriate in situations in which the predominant traffic flow to your network is inbound and there is a desire to share that load across multiple service providers. The disadvantage of requesting address space directly from a registry is that the issuing body may grant your network only a very small address allocation. As a result of this limited allocation, not all service providers on the Internet will propagate information about your network globally. If information about your network is not available globally, there will be networks that cannot reach your network, and vice versa.
Guidelines for requesting IP address space from the registries can be found on each of the respective registries' web sites:
If your network has no plans to connect to the Internet, or if you intend to use advanced firewall and Network Address Translation (NAT) techniques found in products such as the Cisco Systems Private Internet Exchange (PIX) product, it is highly desirable to use IP addresses from a class of addresses that have been designated as private addresses by the IETF. The addresses in this set are considered private because information about these networks is not propagated on the Internet by any ISP or NSP. Because information about these addresses is not propagated, they can be used repeatedly by multiple companies, thereby conserving the amount of public addresses available. The set of private IP addresses is defined in RFC 1918, "Address Allocation for Private Internets," as follows:
10.0.0.0-10.255.255.255 172.16.0.0-172.31.255.255 192.168.0.0-192.168.255.255
After IP addresses have been assigned by your ISP or registry, or after private address space has been selected, that address space must be allocated across the whole of your network. The way that address space is allocated depends primarily on how many hosts will be connected to a given LAN segment, how many LAN/WAN segments are in your network, and how much address space is available for your network. If the network is using private IP addresses, the amount of address space available is not as big of a concern. Private IP network 10.0.0.0 can support as many as four million hosts or LAN/WAN segments, depending on the subnet allocation scheme. Here, a network administrator may choose to assign 24-bit subnets from network 10.0.0.0 to all LAN and WAN segments. This allows for 255 hosts on a given segment, which is more than suitable for most LAN segments and is overkill for point-to-point WAN segments with only two devices.
In situations in which IP address space has been assigned by an ISP or registry and may be at a premium, the network administrator may choose to assign subnets of varying length to LAN and WAN segments. For example, on point-to-point WAN segments, assign a network address with a 30-bit mask instead of assigning a network address that can support more than two devices. A single Class C address space that can support 255 devices can then be configured to support 64 point-to-point WAN segments when subnetting to a 30-bit mask. Likewise, with LAN segments, choose a subnetting scheme and network masks that support only the number of devices that will actually reside on that segment. For example, a small remote office with only 10 people does not need a network address that can support 128.
If you use multiple network masks to create subnets that support varying numbers of hosts, the address space allocated to your network is probably more effectively utilized and less quickly exhausted.
We recommend that an efficient subnetting scheme be used that does not overallocate addresses to segments such as WAN point-to-point interfaces, regardless of the address space that is allocated to your network. As of this writing, the Cisco Systems Technical Assistance Center has created an IP Subnet Design Calculator that is available to registered CCO users at http://www.cisco.com/techtools/ip_addr. html to aid in the selection and design of IP numbering schemes.
LAN Interface Configuration
Devices such as routers have a unique IP address on each of the LAN segments attached to them. Thus, the router knows which networks are connected to each interface and where packets for those networks should be sent. In contrast, devices such as bridges and switches have only a single IP address for the entire system. Typically, this IP address is used solely for the purposes of remote administration and network management.
Each of the five LAN types described in Chapter 3, "The Basics of Device Interfaces" (Ethernet, Token Ring, Fast Ethernet, Gigabit Ethernet, and FDDI), supports the concept of dynamically mapping the data link address (commonly referred to as the MAC address) found on the LAN adapter to the IP address assigned to the interface. This process, which is called address resolution, is supported by a protocol called the Address Resolution Protocol (ARP).
When an IP station needs to contact another IP station on the same logical network and doesn't know that station's data link address, it sends a broadcast requesting that a data link address be supplied for the desired IP address. This process is illustrated in Figure 4-3. Each station in that logical network examines the request and, if the requested IP address matches that station, responds with its MAC address. Therefore, a station does not need to know which specific MAC addresses reside on its logical network to communicate with them. In contrast, many of the WAN protocols do not support a dynamic mapping of the data link address to the IP address and require additional IP address configuration to communicate with other stations across a WAN interface.
Figure 4-3. An IP Router Sends an ARP Request for the Unknown MAC Address of an IP Destination
To examine LAN interface configuration, we utilize the IP network addresses that were selected for the ZIP network, which are summarized in Table 4-1.
Table 4-1. ZIP Network IP Network Address Allocation
Figure 4-4 shows the logical IP address topology for the complete ZIP network.
Figure 4-4. ZIP Network's IP Address Topology
In addition to the assignment of IP network addresses, the following IP addresses have been assigned to workstations that perform the indicated function for the ZIP network:
Assigning IP addresses to both LAN and WAN interfaces is accomplished with the Cisco IOS interface configuration subcommand ip address . This command requires that you supply both the IP address and the network mask for that IP address.
In the following example, we configure the SF-2 router with IP addresses on each of its three LAN interfaces. In each case, we preface the ip address subcommand with the major configuration command interface to reference the LAN interface to which the ip address command should be applied:
SF-2# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-2(config)# interface ethernet 0 SF-2(config-if)# ip address 22.214.171.124 255.255.255.0 SF-2(config-if)# interface ethernet 1 SF-2(config-if)# ip address 126.96.36.199 255.255.255.0 SF-2(config-if)# interface fastethernet 0 SF-2(config-if)# ip address 188.8.131.52 255.255.252.0 SF-2(config-if)# ^Z
We recommend that you reserve some IP addresses at either the start or the end of each LAN network address space for routers and other network infrastructure devices. Having a consistent group of addresses for various network devices across all LAN segments aids in the troubleshooting process by providing quicker recognition of specific IP addresses.
In some instances, the amount of IP address space allocated to your network may require the use of a subnetwork that is the first subnet in an address range. This first subnet is generally referred to as subnet zero because all the bits of the subnet portion of the network mask are 0. Older routing protocols have trouble distinguishing between a major network such as 184.108.40.206 and the subnet 220.127.116.11; therefore, routers typically do not allow the use of the first subnet. The following is an example of a user trying to use subnet zero on the SF-1 router:
SF-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-1(config)# interface ethernet 1 SF-1(config-if)# ip address 18.104.22.168 255.255.255.128 Bad mask 255.255.255.128 for address 22.214.171.124 SF-1(config-if)# ^Z
In this example, the router warns the user that the network mask is bad because the user tried to use subnet zero. In the ZIP network, sufficient IP address space is available, so the first subnet of the assigned address space, 126.96.36.199/25, was not used.
Newer routing protocols are more adept at recognizing the differences between a major network and subnet zero; therefore, the router has configuration commands to allow the user to make use of subnet zero. If in the future it is necessary to use subnet zero on the SF-1 router, the IOS global configuration command ip subnet-zero would be required before entering the ip address command:
SF-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-1(config)# ip subnet-zero SF-1(config)# interface ethernet 1 SF-1(config-if)# ip address 188.8.131.52 255.255.255.128 SF-1(config-if)# ^Z
WAN Interface Configuration
IP addressing of WAN interfaces is similar in many ways to LAN interfaces, with the following exceptions:
Point-to-Point WAN Interface Addressing
A point-to-point WAN interface is simply an interface in which exactly two devices are connected ”one at each end of the line. These types of interfaces are usually found when using dedicated leased data circuits or when two routers are connected back to back via cables or modem-eliminators. Point-to-point connections can also be emulated on a multipoint medium such as Frame Relay or ATM through the use of subinterfaces. There is exactly one device at the opposite end of the line, so there is no question as to what address or which station a packet is sent when it is placed on the point-to-point interface. Given this property, this type of interface (or subinterface) does not require IP addresses as LAN or multipoint WAN interfaces do. In most cases, network administrators prefer to address their point-to-point WAN interfaces for the purposes of network management and ease of troubleshooting. However, if network address space is in short supply, unnumbered interfaces are a definite plus.
If a point-to-point WAN interface, such as a PPP, HDLC, ATM, or Frame Relay subinterface, is assigned an IP address, the ip address command is used (which is similar to the addressing of LAN interfaces). As with the LAN interfaces, the ip address command requires you to supply the network mask and the actual IP address. You must assign each separate point-to-point WAN connection (or point-to-point subinterface) a separate IP network address. Again, note that the IOS major configuration command interface precedes the use of the ip address command to denote which WAN interface is being addressed. The following is an example of IP addressing for an HDLC point-to-point interface and for two Frame Relay point-to-point subinterfaces on the ZIP Seoul-1 router:
Seoul-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Seoul-1(config)# interface serial 0.16 point-to-point Seoul-1(config-if)# ip address 184.108.40.206 255.255.255.252 Seoul-1(config-if)# interface serial 0.17 point-to-point Seoul-1(config-if)# ip address 220.127.116.11 255.255.255.252 Seoul-1(config-if)# interface serial 1 Seoul-1(config-if)# ip address 18.104.22.168 255.255.255.252 Seoul-1(config-if)# ^Z
Although no unnumbered interfaces are currently used in the ZIP network, let's examine the configuration if a WAN interface were added to the Seoul-2 router in the future. An unnumbered IP point-to-point WAN interface is configured using the IOS interface subcommand ip unnumbered . The command requires that a reference interface parameter is supplied so that IP routing protocols have an actual IP address to use when running over the unnumbered interface. This reference interface can be a physical interface, such as an Ethernet or Token Ring, or a virtual interface, such as the loopback interface. Each end of the WAN link must be unnumbered ”that is, one end cannot be assigned an address and the other be unnumbered. The following is an example of adding the future unnumbered interface to the ZIP Seoul-2 router:
Seoul-2# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Seoul-2(config)# interface serial 1 Seoul-2(config-if)# ip unnumbered loopback 0 Seoul-2(config-if)# ^Z
IP unnumbered interfaces have two drawbacks. First, you cannot form a virtual terminal connection (via the Telnet protocol, for instance) directly to the serial interface or use SNMP to query the router via the serial interface. (SNMP is a network management protocol; it is discussed in more detail in Chapter 7, "Basic Administrative and Management Issues." ) You can make a connection to the IP address of the LAN or virtual interface on the device and query that address for network management. Second, if the unnumbered interface is referenced to a LAN interface and that interface is placed in shutdown or has a fault, you may be unable to reach the device. For this reason, we recommend that unnumbered interfaces be referenced to virtual interfaces, such as the loopback interface.
Multipoint WAN Interface Addressing
A multipoint WAN interface is an interface on which multiple devices can be reached via a single connection to the WAN medium. A packet sent out to a multipoint WAN interface does not know which station it is destined for, so multipoint WAN interfaces must be addressed for IP communications. Furthermore, multipoint WAN technologies, such as X.25, ISDN, ATM, and Frame Relay, have data-link addressing methodologies to distinguish between stations on the WAN, so there must be a mapping of the IP address to the data-link address ”in much the same way that IP addresses are mapped to MAC addresses on LAN interfaces. Most of the multipoint WAN technologies have no dynamic method by which to map the IP address to the data-link address. Thus, additional commands are required to provide proper addressing on this type of interface. The exception to this is that Frame Relay does have a dynamic mapping method called Inverse ARP.
Although there are multipoint Frame Relay interfaces in the ZIP network, they are configured to operate as point-to-point connections using subinterfaces. No X.25, ISDN, or ATM is in the ZIP network. Let's examine how multipoint WAN interfaces might be addressed if they were added to the ZIP network device SF-Core-1.
As described in Chapter 3, Frame Relay makes use of the DLCI to distinguish between different virtual circuits on the Frame Relay network. Multiple virtual circuits terminate on a multipoint Frame Relay interface, so multiple DLCIs are associated with it as well. For the IP devices at the ends of those virtual circuits to communicate, their IP addresses must be mapped to the DLCIs. This mapping allows the multipoint device to identify to the Frame Relay network the proper destination virtual circuit for each packet sent out the single physical interface. The packets can then traverse the Frame Relay network. On a multipoint Frame Relay interface, you can perform the mapping manually via the IOS interface configuration frame relay map subcommand or rely on the Inverse ARP function. When you are addressing multipoint WAN interfaces, you should assign all devices in the same multipoint network addresses from the same logical IP network number. The following is an example of configuring a multipoint Frame Relay interface using the frame-relay map command on the SF-Core-1 router:
SF-Core-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-Core-1(config)# interface serial 1/1 SF-Core-1(config-if)# encapsulation frame-relay ietf SF-Core-1(config-if)# no inverse-arp SF-Core-1(config-if)# ip address 22.214.171.124 255.255.255.0 SF-Core-1(config-if)# frame-relay map ip 126.96.36.199 30 cisco broadcast SF-Core-1(config-if)# frame-relay map ip 188.8.131.52 50 broadcast SF-Core-1(config-if)# frame-relay map ip 184.108.40.206 62 broadcast SF-Core-1(config-if)# ^Z
In the preceding example, the dynamic mapping function Inverse ARP is disabled by the IOS interface configuration subcommand no inverse-arp . Three IP addresses are mapped to three virtual circuits and their corresponding DLCI numbers. Additionally, the virtual circuit on DLCI 30 with IP address 220.127.116.11 uses the Cisco "gang of four" encapsulation method rather than the default for the interface. (The default encapsulation is defined as IETF by using the IOS interface configuration subcommand encapsulation frame-relay ietf .) The broadcast keyword at the end of the frame-relay map command instructs the router to forward broadcasts for this interface to this specific virtual circuit.
Optional Keywords and Commands
Like most IOS soft ware commands, all of the IP-to-data link-mapping commands have optional keywords that change the behavior of a virtual circuit or enable/disable special features on that virtual circuit, such as compression. We highlight only the most widely used of those keywords. For a complete explanation of all optional keywords and IOS software commands, refer to the Cisco Connection Documentation CD-ROM or online version at http://www.cisco.com/univercd/home/home. htm.
If we allowed the Inverse ARP function to perform a dynamic mapping of the IP addresses to DLCI numbers in the preceding example, there would be no need for the frame-relay map commands. Instead, the interface would send Inverse ARP queries to each of the virtual circuits identified as active by the Frame Relay network on this interface. Those queries would result in the far-end devices responding with their IP addresses for the particular virtual circuit and DLCI queried. Using Inverse ARP would reduce the example to the following:
SF-Core-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-Core-1(config)# interface serial 1/1 SF-Core-1(config-if)# encapsulation frame-relay ietf SF-Core-1(config-if)# ip address 18.104.22.168 255.255.255.0 SF-Core-1(config-if)# ^Z
Frame Relay configuration requires some care. When you rely on Inverse ARP to provide mapping of IP addresses to DLCIs, configuration errors can result in unexpected virtual circuits being dynamically mapped to unknown devices. Also, mixing the IETF and Cisco "gang of four" encapsulations on the same Frame Relay interface requires the use of the frame-relay map command.
Static addressing of X.25 WAN interfaces is performed in much the same manner as static addressing of Frame Relay interfaces ”that is, with the static map command. X.25 interfaces' IP addresses must be mapped to the X.121 addresses that are used to set up the virtual circuits between systems on the X.25 network. Each virtual circuit is identified by the X.121 address used to set up the connection. The following is an example of configuring a new X.25 interface on the ZIP SF-Core-1 router using the IOS interface configuration subcommand x25 map :
SF-Core-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-Core-1(config)# interface serial 1/2 SF-Core-1(config-if)# encapsulation x25 SF-Core-1(config-if)# x25 address 44598631 SF-Core-1(config-if)# ip address 22.214.171.124 255.255.255.0 SF-Core-1(config-if)# x25 map ip 126.96.36.199 44593389 broadcast SF-Core-1(config-if)# x25 map ip 188.8.131.52 44591165 broadcast SF-Core-1(config-if)# x25 map ip 184.108.40.206 44590712 broadcast SF-Core-1(config-if)# ^Z
Addressing ISDN interfaces requires mapping commands similar to those of Frame Relay and X.25. However, the mapping commands are required only when a device wants to establish a call to another device. If a device receives only inbound calls, IP addresses can be dynamically mapped to the incoming device and phone number. The IOS interface configuration subcommand dialer map is used to provide the mapping between IP addresses and the system names and phone numbers that are used to set up calls over ISDN. The name keyword for the dialer map command must be supplied to properly relate the IP address and telephone number to the remote system. Additionally, the name keyword is used as part of the authentication process when a connection is established with the remote system. The following is an example of configuring a new ISDN BRI interface on the ZIP Seoul-1 router:
Seoul-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Seoul-1(config)# interface bri 0 Seoul-1(config-if)# ip address 220.127.116.11 255.255.255.0 Seoul-1(config-if)# dialer map ip 18.104.22.168 name SF-Core-1 broadcast 14085551212 Seoul-1(config-if)# dialer map ip 22.214.171.124 name SF-Core-2 broadcast 14085551313 Seoul-1(config-if)# ^Z
Addressing ATM interfaces requires the basic ip address command, just like the other types of interfaces that we have explored so far. With ATM interfaces, however, the type of commands used to map IP addresses to the data link layer depends on the type of ATM protocols used, as well as on the type of virtual circuits used. The three possible protocol variations are as follows:
LLC/SNAP encapsulation with PVCs makes use of the IOS interface configuration subcommand map-group and the IOS global configuration command map-list to map IP addresses to specific PVCs. The following is a configuration example for addressing a new ATM interface with LLC/SNAP and PVCs on the SF-Core-1 router:
SF-Core-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-Core-1(config)# interface atm 1/0 SF-Core-1(config-if)# atm pvc 3 0 21 aal5snap SF-Core-1(config-if)# atm pvc 5 0 22 aal5snap SF-Core-1(config-if)# ip address 126.96.36.199 255.255.255.0 SF-Core-1(config-if)# map-group zip1 SF-Core-1(config-if)# map-list zip1 SF-Core-1(config-map-list)# ip 188.8.131.52 atm-vc 3 broadcast SF-Core-1(config-map-list)# ip 184.108.40.206 atm-vc 5 broadcast SF-Core-1(config-map-list)# ^Z
LLC/SNAP encapsulation with SVCs makes use of the IOS interface configuration subcommand map-group and the IOS global configuration command map-list to map IP addresses to the network service access point (NSAP) addresses used to identify the remote devices on the ATM network. The following is a configuration example for addressing a new ATM interface with LLC/SNAP and SVCs on the SF-Core-1 router:
SF-Core-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-Core-1(config)# interface atm 1/0 SF-Core-1(config-if)# atm nsap FE.DCBA.01.987654.3210.ABCD.EF12.3456.7890. 1234.12 SF-Core-1(config-if)# ip address 220.127.116.11 255.255.255.0 SF-Core-1(config-if)# map-group zip1 SF-Core-1(config-if)# map-list zip1 SF-Core-1(config-map-list)# ip 18.104.22.168 atm-nsap A1.9876.AB.123456.7890. FEDC.BA.1234.5678.ABCD.12 SF-Core-1(config-map-list)# ip 22.214.171.124 atm-nsap B2.9876.AB.123456.7890. FEDC.BA.1234.5678.AB12.12 SF-Core-1(config-map-list)# ^Z
Classical IP with ARP requires the ip address subcommand to configure IP addresses for the interface. The ATM interface configuration subcommand atm arp-server identifies the ATM ARP server address that can resolve IP addresses to ATM NSAP addresses, which is required to establish the virtual circuits. The following is a configuration example for addressing a new ATM interface with Classical IP and ARP on the SF-Core-1 router:
SF-Core-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-Core-1(config)# interface atm 1/0 SF-Core-1(config-if)# atm nsap FE.DCBA.01.987654.3210.ABCD.EF12.3456.7890. 1234.12 SF-Core-1(config-if)# ip address 126.96.36.199 255.255.255.0 SF-Core-1(config-if)# atm arp-server nsap 01.ABCD.22.030000.0000.0000.0000. 0000.0000.0000.00 SF-Core-1(config-if)# ^Z
Verifying IP Address Configuration
Verifying the IP addresses and other IP attributes that have been assigned to your interfaces can be accomplished via one of three EXEC commands. The IOS EXEC show interface command provides general information about an interface, including the IP address and network mask assigned to it. When a specific interface is supplied as a command parameter, only that interface is displayed. When no interface is specified, all interfaces are shown. The following is output from the show interface ethernet 0 command executed on the ZIP SF-2 router:
SF-2# show interface ethernet 0 Ethernet0 is up, line protocol is up Hardware is Lance, address is 0000.0c07.b627 (bia 0000.0c07.b627) Internet address is 188.8.131.52 255.255.255.0 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Queuing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 1000 bits/sec, 1 packets/sec 716895 packets input, 69741733 bytes, 0 no buffer Received 76561 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 input packets with dribble condition detected 5148972 packets output, 750393298 bytes, 0 underruns 0 output errors, 68 collisions, 5 interface resets 0 babbles, 0 late collision, 286 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out
The IOS EXEC show ip interface command provides a complete look at all the parameters associated with the IP configuration of an interface. If a specific interface is supplied as a parameter to the command, only the information about that interface is displayed. When no specific interface is supplied, information about all interfaces is supplied. The following is the output of the show ip interface ethernet 0 command executed on the ZIP SF-2 router:
SF-2# show ip interface ethernet 0 Ethernet0 is up, line protocol is up Internet address is 184.108.40.206 255.255.255.0 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is enabled Multicast reserved groups joined: 220.127.116.11 18.104.22.168 22.214.171.124 Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is enabled IP fast switching on the same interface is disabled IP multicast fast switching is enabled Router Discovery is disabled IP output packet accounting is disabled IP access violation accounting is disabled TCP/IP header compression is disabled Probe proxy name replies are disabled Gateway Discovery is disabled Policy routing is disabled Network address translation is disabled
The IOS EXEC show ip interface command has an optional form that enables you to see a brief summary of IP address information and interface status for all available interfaces on the device. This summarized version is obtained using the show ip interface brief command.
The following is the output of the show ip interface brief command executed on the ZIP SF-2 router:
SF-2# show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0 126.96.36.199 YES NVRAM up up Ethernet1 188.8.131.52 YES NVRAM up up FastEthernet 0184.108.40.206 YES NVRAM up up
In addition to verifying the IP configuration on the interface itself, you can view both the static and the dynamic mappings of IP addresses to data-link addresses on the various WAN multipoint media. To do so, use the IOS EXEC commands show frame-relay map, show atm map, show x25 map , and show dialer maps . The following is an example of the output from the show frame-relay map command from the ZIP router Seoul-1:
Seoul-1# show frame-relay map Serial0.16 (up): point-to-point dlci, dlci 16(0x10,0x400), broadcast, status defined, active Serial0.17 (up): point-to-point dlci, dlci 17(0x11,0x410), broadcast, status defined, active Seoul-1#
The other WAN protocol mapping commands have output similar to that of the show frame-relay map command.
As discussed in the section "TCP/IP Addressing," network masks can be represented in both dotted-decimal and bit-count, or slash, format. The router defaults to use the bit-count format. If you are more comfortable with the dotted -decimal format for verifying network masks, the IOS EXEC command terminal ip netmask -format decimal can be used to switch formats. This command is in effect only for the current virtual terminal or console session. The following is an example of using the command on the ZIP Seoul-1 router:
Seoul-1# terminal ip netmask-format decimal Seoul-1#
To preserve this format for all virtual terminal or console sessions, you must apply the IOS line configuration subcommand ip netmask-format decimal to the desired lines in configuration mode. The following is an example of changing the network mask format for all virtual terminal sessions on the ZIP router Seoul-1:
Seoul-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Seoul-1(config)# line vty 0 4 Seoul-1(config-line)# ip netmask-format decimal Seoul-1(config-line)# ^Z