Configuring Other IP Options
| The IOS software found on Cisco routers and other devices has dozens of features to aid in the operation of the network and of the router itself. In this section, we examine four features commonly implemented on the router that enhance network operation and ease the use of the router itself. Configuring Domain Name ServicesIn TCP/IP networks today, most people refer to servers, printers, workstations, and other IP devices by their names rather than by their IP addresses. Remembering IP addresses may be easy for the network administrator who is intimately familiar with the network, but for the average user , it is easier to remember the name of a system. To that end, servers that resolve names into IP addresses, called domain name service (DNS) servers, usually reside somewhere within an entity's intranet. Routers can make use of the DNS system to convert names into IP addresses and to help reduce the number of IP addresses that the network administrator must remember. DNS normally comes enabled in the Cisco IOS software. However, if it has been disabled, it can be restored via the IOS global configuration command ip domain-lookup . After DNS is enabled, an IOS device should be configured with the domain name in which it resides and with the IP address of the DNS nameservers that it can use for name resolution. The domain name can be configured via the IOS global configuration command ip domain-name . The DNS nameserver(s) can be configured via the IOS global configuration command ip name-server . The ip name-server command takes one or more IP addresses of nameservers as parameters. If the IOS device resides within multiple DNS domains, the IOS global configuration command ip domain-list can be used to specify a list of domain names that should be postpended to unqualified names. The following is an example of configuring DNS on the ZIP SF-Core-1 router. In this example, the domain name is zipnet.com and the nameserver IP addresses are 131.108.110.34 and 131.108.110.35: 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)# ip domain-lookup SF-Core-1(config)# ip domain-name zipnet.com SF-Core-1(config)# ip domain-list zipnet.com SF-Core-1(config)# ip domain-list zipnet.net SF-Core-1(config)# ip name-server 131.108.110.34 131.108.110.35 SF-Core-1(config)#^ Z Verifying the setup of the DNS on the router can be accomplished via the IOS EXEC command show host . Additionally, the show host command displays a list of hosts that have had their names resolved to IP addresses and also displays the age of each entry. The following is an example of the output of the show host command from the ZIP SF-Core-1 router: SF-Core-1# show host Default domain is zipnet.com Domain list: zipnet.com, zipnet.net Name/address lookup uses domain service Name servers are 131.108.110.34, 131.108.110.35 Host Flags Age Type Address(es) testy.zipnet.com (temp, OK) 1 IP 131.108.3.5 s1-Seoul1-kr.zipnet.com (temp, OK) 1 IP 131.108.241.2 s0/0-SanJose-sj.zipnet.com (temp, OK) 1 IP 131.108.240.2 SF-Core-1# The host name-to-IP address mappings can also be configured statically on the router in situations in which DNS servers are not available, you prefer to create special names different from those in DNS, or you want to map individual terminal server ports to IP addresses. Static name-to-IP address mapping is configured with the IOS global configuration command ip host . The ip host command takes as parameters a host name, an optional Telnet protocol port, and one or more IP addresses to which the host name may resolve. The following is an example of statically mapping several different host names to IP addresses on the ZIP 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)# ip host grouchy 131.108.3.5 SF-Core-1(config)# ip host grouchy-console 2001 131.108.3.50 SF-Core-1(config)# ip host farout 131.108.3.88 131.108.3.150 SF-Core-1(config)#^ Z The static host name-to-IP address mappings can also be verified via the show host command. The following is an example, again from the ZIP SF-Core-1 router, after the mappings of the static host names to IP addresses have been entered: SF-Core-1# show host Default domain is zipnet.com Domain list: zipnet.com, zipnet.net Name/address lookup uses domain service Name servers are 131.108.110.34, 131.108.110.35 Host Flags Age Type Address(es) testy.zipnet.com (temp, OK) 1 IP 131.108.3.5 s1-Seoul1-kr.zipnet.com (temp, OK) 1 IP 131.108.241.2 s0/0-SanJose-sj.zipnet.com (temp, OK) 1 IP 131.108.240.2 grouchy (perm, OK) 2 IP 131.108.3.5 grouchy-console (perm, OK) 2 IP 131.108.3.50 farout (perm, OK) 2 IP 131.108.3.88 131.108.3.150 SF-Core-1# The static entries in the host name table can be distinguished from those learned via DNS by the Flags field for the host name entry. A flag type of temp indicates that the name was learned dynamically via DNS and is aged out of the table after a period of time. A flag type of perm indicates that the name was statically configured and is never aged from the table. Temporary entries in the IP host table can be cleared via the IOS EXEC command clear host . Individual host name mapping can be cleared by supplying a host name as the parameter to the command. All temporary host entries can be cleared by supplying an asterisk as the parameter. The following is an example of clearing the host name to IP mapping for the host name testy.zipnet.com on the ZIP SF-Core-1 router: SF-Core-1#clear host testy.zipnet.com SF-Core-1# IP Broadcast ForwardingOne of the benefits that routers provide on a network is restricting IP and MAC broadcast packets to the local LAN segment. Most broadcasts are used for requesting information such as an unknown MAC address for an IP address (ARP) on a local segment, so isolating broadcasts to the local LAN segment presents no inherent problems and is highly beneficial to network performance. In some situations, IP stations use UDP broadcasts to locate services that may not be on the local LAN segment. Applications that rely on NetBIOS over IP, for example, use UDP broadcasts to locate the particular type of service that the user needs. If that service resides on a LAN segment other than the one to which the user's station is attached, the router blocks the broadcast, making that service unavailable. Other services, such as DHCP and the Bootstrap Protocol (BOOTP), send UDP broadcasts to help IP stations determine their IP addresses during the boot process; the broadcasts are received by servers that assign addresses. If those servers reside off the local LAN segment, an IP station cannot receive a server-assigned IP address. To compensate for the broadcast isolation features of the router, the IOS software has the capability to forward UDP broadcasts to a specific host or subnet. This feature, which is called IP broadcast forwarding, is enabled by using the IOS interface configuration subcommand ip helper-address and the IOS global configuration command ip forward-protocol . A common application of these commands is to forward DHCP address requests from a local LAN segment to the LAN segment where the DHCP server resides, as shown in Figure 4-11. Let's examine the use of the broadcast forwarding feature at the San Francisco ZIP site on the router SF-2. Figure 4-11. A DHCP Request Broadcast Is Forwarded by the Use of a Helper Address In the ZIP network in San Francisco, off of the SF-2 router, Microsoft Windows 95/98, NT, and Windows 2000 workstations use DHCP to obtain their IP addresses dynamically. Those workstations reside on the SF-2 routers Ethernet 0 and Ethernet 1 LAN segments. The DHCP server resides on the Fast Ethernet 0 LAN segment. Broadcasts from the Ethernet segments do not traverse the router, and thus the DHCP broadcasts do not reach the Fast Ethernet segment and the DHCP server. To enable the forwarding of broadcasts, the ip helper-address command can be applied to the Ethernet segments where the router receives the broadcasts. The ip helper-address command takes as a parameter an IP host address or an IP broadcast address. The address supplied is either the host address of the specific DHCP server or the broadcast address of the LAN segment where the DHCP server resides. The following is an example of the ip helper-address command on the Ethernet 0 interface of the ZIP SF-2 router, which results in broadcasts being forwarded directly to the DHCP server at 131.108.21.70: 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 helper-address 131.108.21.70 SF-2(config)#^ Z Instead of being forwarded directly to the DHCP server, the broadcast could be forwarded to the LAN segment where the DHCP server resides. This alternative is useful when more than one DHCP server could answer the request. The following is an example of using the IP broadcast address of the LAN segment on which the DHCP server resides as the forwarding destination: 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 1 SF-2(config-if)# ip helper-address 131.108.23.255 SF-2(config-if)#^ Z The ip helper-address is used to specify where the broadcasts should be forwarded. The ip forward-protocol command is used to control which UDP broadcasts get forwarded. By default, several types of UDP broadcasts get forwarded whenever the ip helper-address command is applied to an interface:
If there is an application that broadcasts on a port other than the ones listed and its broadcasts need to be forwarded, the ip forward-protocol command is used to specify that the particular broadcast type should be included among those that are forwarded. With the addition of the keyword no , this command also can be used to restrict any of the default protocols from being forwarded. The ip forward-protocol command takes as parameters the type of forwarding to be performed (such as UDP) and the specific port number of the protocol to be forwarded. The following is an example of using the command to allow broadcasts on UDP port 1965 to be forwarded and to restrict the forwarding of NetBIOS Name Server and Datagram Server on the ZIP SF-2 router: SF-2# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. SF-2(config)# ip forward-protocol udp 1965 SF-2(config)# no ip forward-protocol udp 137 SF-2(config)# no ip forward-protocol udp 138 SF-2(config)#^ Z You can verify ip helper-address configurations with the show ip interface command, as discussed in previous sections. Further Reference: Other Broadcast Applications The broadcast forwarding technique discussed in this section is designed to meet the needs of a limited broadcast forwarding environment. It is well-suited to such tasks as forwarding IP address requests via DHCP or BOOTP to a server or group of servers that reside at a central location on the network. Other applications exist for which more substantial broadcast forwarding may be required. These applications ”for example, stock ticker data ”typically use broadcasts to share information among a large group of workstation users over a large part of the network. Such applications are not well-suited to the helper address model. Instead, they require advanced techniques, such as UDP flooding and broadcast-to-multicast replication, to prevent the router's CPU from being overwhelmed by broadcast packet traffic and replication. Cisco Systems currently has a case study that discusses the implications of the helper address and flooding models. It can be found on CCO athttp://www.cisco. com/univercd/cc/td/doc/cisintwk/ics/cs006.htm. Dynamic Address Assignment with IOS DHCP ServerIn the preceding section, we discussed forwarding DHCP address assignment requests as one of the applications for IP broadcast forwarding. When a router forwards these address assignment requests, it is said to be acting as a DHCP relay agent. The role of the DHCP relay agent is to receive local LAN broadcasts for address assignments and to forward them to a previously identified DHCP server. The DHCP server is typically a workstation or server such as a UNIX or Windows NT system running a DHCP server software package or service. Alternatively, an IOS-based router or access server may serve as the source for dynamic address assignments. The IOS software DHCP server operates similarly to workstation-based DHCP servers, accepting address assignment requests/renewals and assigning the addresses from predefined groups of addresses called pools. The address pools may also be configured to supply additional information to the requesting client such as the IP address(es) of DNS server(s), the default router, and other useful information. The IOS DHCP server may accept broadcasts from locally attached LAN segments or from DHCP requests that have been forwarded by other DHCP relay agents within the network. Note In addition to the IOS software-based DHCP server, Cisco Systems makes a workstation-based DNS and DHCP server called Cisco Network Registrar that runs under such operating systems as Solaris, HP-UX, and Microsoft Windows operating systems. The decision of whether to use the IOS-based DHCP server or a workstation-based DHCP server involves many factors, including the size of your network, the number of nodes requiring dynamic addresses, the frequency of address requests and renewals, the need for redundancy, and cost. In general, the IOS-based DHCP server is most practical in small to medium- sized networks or for use in a decentralized model such as multiple remote offices. Workstation-based DHCP servers are more appropriate for large organizations with a need for redundancy and a highly centralized management scheme. The IOS DHCP server will typically participate in two steps of the address assignment process, the DHCPOFFER and the DHCPACK. Figure 4-12 depicts the basic steps involved when a DHCP client requests an address from the DHCP server. The DHCP client sends a DHCPDISCOVER broadcast message to locate a DHCP Server. A DHCP server offers address assignment parameters to the client in a DHCPOFFER unicast response. The DHCP client then sends a formal DHCPREQUEST broadcast message for the offered address assignment back to the DHCP server. The DHCP server sends a DHCPACK unicast response indicating that the requested addresses have been assigned to the client. The four steps shown in Figure 4-12 depict the normal address negotiation process with no errors or conflicts. The complete address assignment process, including the handling of DHCPDECLINE messages, is described in RFC 2131, "Dynamic Host Configuration Protocol." Figure 4-12. DHCP Address Assignment by a DHCP Server Enabling the IOS-based router or access server to perform as a DHCP server is accomplished with four major configuration steps:
We'll examine the configuration of the IOS DHCP server using the ZIP Kuala Lumpur router. The first step to enabling the IOS DHCP server is configuring a location on the network to log and store the DHCP address assignments (also called bindings). This location is typically a workstation or server that supports TFTP, FTP, or the RCP file transfer protocol. Specifying this location allows the router or access server to be restarted without losing information about which addresses are allocated to which DHCP client systems. Additionally, it provides a location to log address assignment conflicts that may arise during the DHCP negotiation process. The IOS global configuration command ip dhcp database is used to specify the location. The command takes as a parameter a URL that specifies the server address and filename to use for the logging. The configuration command may be repeated multiple times to allow for storing the bindings on multiple servers. The following is an example of configuring the DHCP database location on the ZIP Kuala Lumpur router to log to a server with IP address 131.108.2.77 and a file called kl-dhcp- info using the TFTP protocol: Kuala-Lumpur# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Kuala-Lumpur(config)# ip dhcp database tftp://131.108.2.77/kl-dhcp-info Kuala-Lumpur(config)#^ Z During the address assignment process, the IOS DHCP server attempts to ensure that the IP address being offered is not in use. It does this by sending a series of ping packets to the address being offered before responding to the DHCP client. If the address is in use, it is logged as a conflict and is not offered until the network administrator resolves the conflict. If no server is available for the logging of DHCP address bindings and the ip dhcp database command is not configured, the logging of DHCP conflicts must also be disabled. Disabling conflict logging is accomplished with the IOS global configuration command no ip dhcp conflict logging . In the ZIP network Kuala Lumpur location, a tftp server is available, but the following is an example of how DHCP conflict logging would be disabled if none were available: Kuala-Lumpur# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Kuala-Lumpur(config)# no ip dhcp conflict logging Kuala-Lumpur(config)#^ Z When a location is established for logging the bindings, a list of addresses that should be excluded as dynamically offered assignments is built. This list includes the address of the router(s) in a given address range, any statically assigned addresses, or an address that should be reserved and not offered to a DHCP client. The IOS global configuration command ip dhcp excluded-address is used to build these lists. The command takes as parameters either a single IP address to be excluded or a pair of addresses that represent the starting and ending addresses of an IP address range. The command may be repeated several times in the configuration to exclude multiple IP addresses that are not contiguous or that span multiple IP address assignment pools. The following is an example of excluding the IP address range 131.108.2.1 through 131.108.2.10 and the single IP address 131.108.2.57 on the ZIP Kuala Lumpur router: Kuala-Lumpur# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Kuala-Lumpur(config)# ip dhcp excluded-address 131.108.2.1 131.108.2.10 Kuala-Lumpur(config)# ip dhcp excluded-address 131.108.2.57 Kuala-Lumpur(config)#^ Z The final step in enabling the IOS DHCP server is the definition of the IP address assignment pools that will be used to supply the dynamic addresses. At a minimum, the DHCP address pool specifies the range of addresses that will be offered to DHCP clients requesting addresses (not including the excluded addresses). More than one pool may be defined on the IOS DHCP server if there are multiple LAN segments attached to the router or access server acting as a DHCP server, or if it serves addresses for multiple LAN segments elsewhere within the network. The IOS global configuration command ip dhcp pool establishes an address assignment pool. The command takes as a parameter either an arbitrary string to describe the pool or a numeric integer. Once defined, additional address pool commands are entered from the DHCP configuration subcommand mode, denoted by the (config-dhcp)# prompt. The following example configures a DHCP address pool called kl-users on the Kuala Lumpur router and places the network administrator in DHCP configuration subcommand mode to continue the address pool configuration: Kuala-Lumpur# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Kuala-Lumpur(config)# ip dhcp pool kl-users Kuala-Lumpur(config-dhcp)#^ Z The IOS DHCP configuration subcommand network is used to define the range of addresses that a given address pool will offer to DHCP clients. The network subcommand requires two parameters, an IP network address and a network mask or bit-count mask. The network address and mask specified for a given pool should correspond to the network address and mask on the LAN segment for which this pool will offer addresses. When the DHCP server will supply addresses for multiple LAN segments, separate DHCP pools should be defined, each with a network subcommand with the appropriate address and mask, for that LAN segment. The following is an example of establishing the DHCP address pool kl-users again on the Kuala Lumpur router, using the network subcommand to specify the range of addresses to be assigned to DHCP clients (note the use of the /25 bit-count mask in lieu of the 255.255.255.128 network mask): Kuala-Lumpur# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Kuala-Lumpur(config)# ip dhcp pool kl-users Kuala-Lumpur(config-dhcp)# network 131.108.2.0 /25 Kuala-Lumpur(config-dhcp)#^ Z In this example, specifying network 131.108.2.0 with a /25 bit-count mask means that addresses in the range of 131.108.2.1 to 131.108.2.127 will be offered to DHCP clients (not including the previously excluded addresses). When viewing the running or startup configuration file, the /25 bit-count mask will be converted to a network mask of 255.255.255.128. Additional DHCP configuration subcommands enable the network administrator to configure the IOS DHCP server to supply supplementary information to the DHCP client using the address negotiation process. The additional information is typically the address(es) of the client's default router on the LAN segment, addresses of the DNS servers, addresses of the NetBIOS/WINS servers, and other information that would otherwise have to be configured manually on each client either by the user or by the network administrator. The following is the list of the most commonly configured DHCP configuration subcommands:
The dns-server , netbios-name-server , and default-router subcommands each take as parameters from one to eight IP addresses that the client may contact for each of those functions. The domain-name subcommand takes as a parameter an arbitrary string that represents the name of the DNS domain for the client. The lease subcommand takes as parameters up to three integers to specify the number of days, hours, and minutes that an assigned address is valid. The keyword infinite may also be used to specify that a lease is valid for an unlimited period of time. The netbios-node-type subcommand takes as a parameter the character values of b, p, m, or h, which represent a NetBIOS broadcast node, peer-to-peer node, a mixed node, or a hybrid node, respectively, to denote the operating mode of the client. If you are unfamiliar with these operating modes, selecting the hybrid mode is recommended. The following is an example of configuring the Kuala Lumpur router with additional DHCP configuration subcommands to supply to DHCP clients with information about servers in the ZIP network: Kuala-Lumpur# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Kuala-Lumpur(config)# ip dhcp pool kl-users Kuala-Lumpur(config-dhcp)# dns-server 131.108.101.34 131.108.101.35 Kuala-Lumpur(config-dhcp)# domain-name zipnet.com Kuala-Lumpur(config-dhcp)# netbios-name-server 131.108.21.70 Kuala-Lumpur(config-dhcp)# netbios-node-type h Kuala-Lumpur(config-dhcp)# default-router 131.108.2.1 Kuala-Lumpur(config-dhcp)# lease 0 1 Kuala-Lumpur(config-dhcp)#^ Z As mentioned previously, multiple DHCP address pools may be configured on the same IOS DHCP server. The collection of DHCP address pools on that server is referred to as the DHCP database. The DHCP database is arranged in a hierarchical or tree structure so that one address pool may be a subnetwork of the network address of a different DHCP address pool. This hierarchical structure allows for properties to be inherited by the address pool, which is a subnetwork of the other. Properties that are common to multiple pools should be defined at the highest network or subnetwork level that is appropriate for the DHCP server or network being configured. Properties defined at a higher level can be overridden at a lower subnetwork level. Let's take a look at this on the ZIP Kuala Lumpur router. In the previous example, an address pool called kl-users was defined for a network of 131.108.2.0/25. In the example, additional properties were specifically defined for DNS servers, the default router, and so on. If in the future a second address pool were created for the network address 131.108.2.128/25, the additional properties would again need to be specifically defined in a new address pool because it is not a subnetwork of the previously defined pool. Thus, the configuration on the Kuala Lumpur router for this new address pool would be as follows : Kuala-Lumpur# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Kuala-Lumpur(config)# ip dhcp excluded-address 131.108.2.129 131.108.2.135 Kuala-Lumpur(config)# ip dhcp pool kl-users-2 Kuala-Lumpur(config-dhcp)# network 131.108.2.128/25 Kuala-Lumpur(config-dhcp)# dns-server 131.108.101.34 131.108.101.35 Kuala-Lumpur(config-dhcp)# domain-name zipnet.com Kuala-Lumpur(config-dhcp)# netbios-name-server 131.108.21.70 Kuala-Lumpur(config-dhcp)# netbios-node-type h Kuala-Lumpur(config-dhcp)# default-router 131.108.2.129 Kuala-Lumpur(config-dhcp)# lease 0 1 Kuala-Lumpur(config-dhcp)#^ Z In the configuration of the kl-users-2 address pool, there are a number of subcommands whose parameters are the same as the parameters of the kl-users pool, making the properties assigned to the clients identical for those subcommands. To avoid the subcommand repetition in both kl-users and kl-users-2, those address pools can be reconfigured to be subnetworks of another network address pool. When this is completed, only the subcommands that define properties that are unique to that address pool will be needed. For the ZIP Kuala Lumpur router, an address pool will be defined for the network address 131.108.2.0/24, and the properties that will be inherited by the subnetwork address pools will be defined. The rewritten kl-users and kl-users-2 address pool will be reduced from seven subcommands to only two subcommands. Here is an example of the rewritten DHCP address pools on the Kuala Lumpur router in which the kl-users and kl-users-2 address pools will inherit properties from an address pool called kl-common: Kuala-Lumpur# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Kuala-Lumpur(config)# ip dhcp pool kl-common Kuala-Lumpur(config-dhcp)# network 131.108.2.0/24 Kuala-Lumpur(config-dhcp)# dns-server 131.108.101.34 131.108.101.35 Kuala-Lumpur(config-dhcp)# domain-name zipnet.com Kuala-Lumpur(config-dhcp)# netbios-name-server 131.108.21.70 Kuala-Lumpur(config-dhcp)# netbios-node-type h Kuala-Lumpur(config-dhcp)# lease 0 1 Kuala-Lumpur(config-dhcp)# ip dhcp pool kl-users Kuala-Lumpur(config-dhcp)# network 131.108.2.0/25 Kuala-Lumpur(config-dhcp)# default-router 131.108.2.1 Kuala-Lumpur(config-dhcp)# ip dhcp pool kl-users-2 Kuala-Lumpur(config-dhcp)# network 131.108.2.128/25 Kuala-Lumpur(config-dhcp)# default-router 131.108.2.129 Kuala-Lumpur(config-dhcp)#^ Z In this example, because 131.108.2.0/25 and 131.108.2.128/25 are subnetworks of 131.108.2.0/24, the corresponding address pools will inherit the common properties from the higher-level network address pool. Only the default-router subcommand is used to define the specific IP address that is appropriate for each subnetwork address pool. When the address pools and their properties are defined and the IOS DHCP server has begun assigning IP addresses, the operation of the DHCP server can be verified using several different IOS EXEC commands. Verifying that the IOS DHCP server is logging binding and conflict information to the configured workstation or server is accomplished via the IOS EXEC command show ip dhcp database . The command takes as a parameter the URL to display information about a specific database logging location. If none is supplied, information about all locations is displayed. The following is an example of the show ip dhcp database command on the ZIP Kuala Lumpur router: Kuala-Lumpur> show ip dhcp database URL : tftp://131.108.2.77/kl-dhcp-info Read : Never Written : Jun 30 2000 12:01 AM Status : Last Write Successful. Delay : 300 seconds Timeout : 300 seconds Failures : 0 Successes: 72 Kuala-Lumpur> The output of show ip dhcp database indicates the location to which binding information is being written, the date and time of the last read or write to the binding database, the status of the last read or write, and the number of successes and failures in attempting to write to the bindings database. Specific address assignment information can be viewed using the IOS EXEC command show ip dhcp binding . When an IP address is supplied as an optional parameter to the command, only the binding information for that address is shown; otherwise, all binding information is displayed. The following is an example of the show ip dhcp binding command on the ZIP Kuala Lumpur router, which displays the currently allocated address assignments, the associated MAC address of the DHCP client, and the lease expiration time: Kuala-Lumpur> show ip dhcp binding IP address Hardware address Lease expiration Type 131.108.2.89 00a0.9802.32de Jul 01 2000 12:00 AM Automatic 131.108.2.156 00a0.9478.43ae Jul 01 2000 1:00 AM Automatic Kuala-Lumpur> Information for address conflicts that occurred when the IOS DHCP server was attempting to assign an address to a DHCP client can be viewed with the show ip dhcp conflict command. When an IP address is supplied as an optional parameter to the command, only the conflict information for that address is shown (if any); otherwise, all conflict information is displayed. The following is an example of the show ip dhcp conflict command on the ZIP Kuala Lumpur router, which indicates the IP address in conflict, the detection time, and the method of detection: Kuala-Lumpur> show ip dhcp conflict IP address Detection Method Detection time 131.108.2.126 Ping Jul 02 2000 12:28 AM 131.108.2.254 Gratuitous ARP Jul 02 2000 01:12 AM Kuala-Lumpur> The Detection Method column indicates what method was used by the IOS DHCP server to determine that the address was in conflict. The ping detection method indicates that before address assignment, the IOS DHCP server attempted to ping the address and received a successful response. The Gratuitous ARP detection method indicates that before address assignment, the IOS DHCP server detected a current and valid ARP entry for the address in its ARP table. Either of these detection methods indicates that the address is likely in use (perhaps because of an unauthorized use or because someone forgot to add to the excluded addresses list). Verifying that the IOS DHCP server is receiving and responding to DHCP requests can be accomplished with the IOS EXEC command show ip dhcp server statistics . The com-mand provides useful information such as the number of configured address pools, the amount of memory being consumed by the DHCP bindings database, and counters that indicate the number of different types of DHCP messages that have been both sent and received. The following is an example of the show ip dhcp server statistics command on the ZIP Kuala Lumpur router: Kuala-Lumpur> show ip dhcp server statistics Memory usage 40392 Address pools 3 Database agents 1 Automatic bindings 48 Manual bindings 0 Expired bindings 7 Malformed messages 0 Message Received BOOTREQUEST 22 DHCPDISCOVER 175 DHCPREQUEST 168 DHCPDECLINE 0 DHCPRELEASE 0 DHCPINFORM 0 Message Sent BOOTREPLY 17 DHCPOFFER 166 DHCPACK 155 DHCPNAK 3 Kuala-Lumpur> IP Redundancy with the Hot Standby Router ProtocolMany network administrators worry about having single points of failure in the network. They want to provide both redundant paths and redundant equipment in key locations of the network to prevent any single device from causing vital network resources to become unavailable. Routers (and some servers) handle multiple IP paths very well by exchanging dynamic routing information about the various paths through the network, selecting the best path(s) at any given time, and rerouting when there are path changes because of equipment or circuit failure. However, many workstation, server, and printer implementations are not capable of exchanging dynamic routing information. These devices typically are configured with a single default gateway IP address that serves as their conduit to the rest of the network. If the router that is the default gateway fails, the device is limited to communicating only on the local IP network segment and is effectively cut off from the rest of the network. Even if a redundant router exists that could serve as a default gateway, there is no dynamic method for the workstations to use to switch to a new default gateway IP address, and manual reconfiguration is often beyond the user's technical ability. To assist network administrators with this troublesome situation, Cisco Systems developed the Hot Standby Router Protocol (HSRP). HSRP was designed for the LAN segment, where multiple routers are present and where there are devices that use only a static default gateway IP address. The concept of HSRP is quite simple. The administrator creates a virtual default gateway address and assigns it to the redundant routers that participate in HSRP on the given LAN segment. The IP devices are configured to use the virtual gateway address as the default gateway. The routers manage this virtual gateway address, communicating among themselves to determine which router is responsible for forwarding traffic sent to the virtual IP address. At regular intervals, they exchange information to determine which routers are still present and capable of forwarding traffic. If the primary or lead router of a group of HSRP routers fails, a standby router in the same group begins to forward traffic for the HSRP group. Because the routers decide among themselves which one forwards traffic for the virtual address, and because the workstations on a segment are aware of only the virtual IP address as their default gateway, a failure of the primary forwarding router is barely detectable by the workstation users and requires no intervention on the part of the user or the network administrator. HSRP is very flexible. The network administrator can control all behavior of the routers in an HSRP group ”including which router is the primary forwarding router, which router (or routers) is the standby router, whether the standby router retains the forwarding role when the primary is again available, and the capability of another interface on the router to force traffic onto the standby router. Let's examine the configuration of HSRP on the ZIP routers located in Seoul, Korea. In Seoul, two routers, Seoul-1 and Seoul-2, are attached to the same logical IP network, 131.108.3.0. The presence of two or more routers that can act as default gateways on the LAN segment is the first part of the criteria for configuring HSRP. The other part of the criteria is having IP devices on the network that can support only a single IP address as the default gateway. In this case, printers, servers, and PC workstations fit the criteria. The basic configuration of HSRP requires only the IOS interface configuration subcommand standby ip . This command takes as a parameter the IP address that is used as the virtual default gateway IP address. The command is applied to all routers on the same logical IP network that participate in the same HSRP group. The following is an example of configuring HSRP on the ZIP routers Seoul-1 and Seoul-2 with a standby virtual IP address of 131.108.3.3: Seoul-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Seoul-1(config)# interface ethernet 0 Seoul-1(config-if)# standby ip 131.108.3.3 Seoul-1(config-if)#^ Z Seoul-2# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Seoul-2(config)# interface ethernet 0 Seoul-2(config-if)# standby ip 131.108.3.3 Seoul-2(config-if)#^ Z After the HSRP standby address is configured, the routers negotiate which one will be the primary forwarding router and which will be the standby. Additionally, both routers enter the IP address and the MAC address for the virtual IP address in the ARP table. The primary forwarding router begins forwarding traffic sent to the standby virtual IP address as well as answering ping s and accepting virtual terminal sessions to that address. Note that the MAC address for the virtual IP address on Ethernet, Fast Ethernet, Gigabit Ethernet, and FDDI interfaces is of the form 0000.0c07.acXX, where XX is an HSRP group identifier. The MAC address of the virtual IP address on the Token Ring is a functional address of the form 1000.xxxx.xxxx. The following is an example of the show ip arp 131.108.3.3 command on the ZIP Seoul-1 router, which is configured with HSRP: Seoul-1# show ip arp 131.108.3.3 Protocol Address Age (min) Hardware Addr Type Interface Internet 131.108.3.3 - 0000.0c07.ac00 ARPA Ethernet0 Seoul-1# Tip Some devices on Token Ring do not accept the MAC address of an IP device as a group functional address. In this case, use the IOS interface configuration subcommand standby use-bia to force the HSRP virtual IP address to use the hardware burned-in address of the interface, which limits the number of HSRP groups on the interface to one. As mentioned previously, the network administrator has several configuration options that control the behavior of HSRP. To control which router is the primary forwarding router, use the IOS interface configuration subcommand standby priority . The command takes as a parameter a value between 0 and 255. The router in an HSRP group with the highest priority becomes the forwarding router. In this example, we configure the ZIP Seoul-1 router with an HSRP priority of 100 and the Seoul-2 router with a priority of 95, causing Seoul-1 to become the active forwarding 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 ethernet 0 Seoul-1(config-if)# standby priority 100 Seoul-1(config-if)#^ Z Seoul-2# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Seoul-2(config)# interface ethernet 0 Seoul-2(config-if)# standby priority 95 Seoul-2(config-if)#^ Z If the standby router is required to become the active router, it automatically assumes that role. You can control whether the former primary router resumes its active forwarding role when it is available again. The IOS interface configuration subcommand standby preempt causes the router to resume the active forwarding role from a router with a lower priority. In the case of our ZIP Seoul example, Seoul-2 has a lower priority than Seoul-1. If Seoul-1 fails, Seoul-2 assumes the active forwarding role. Without the standby preempt command on Seoul-1, Seoul-2 retains the active forwarding role. The following example of the standby preempt command causes the ZIP Seoul-1 router to resume the active forwarding role upon restoration because it has the higher HSRP priority: Seoul-1# configure Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. Seoul-1(config)# interface ethernet 0 Seoul-1(config-if)# standby preempt Seoul-1(config-if)#^Z In some situations, the operational status of an interface directly affects which router you want to be the active forwarding router. This is particularly true when each of the routers in an HSRP group has a different path to other parts of the network. In the case of the ZIP network, Seoul-1 has a connection to San Jose, which in turn has connectivity to San Francisco. The Seoul-2 router has direct connectivity to San Francisco and then on to San Jose. If the WAN connection on Seoul-1 is degraded or fails, packets sent to Seoul-1, the active forwarding router, cannot reach San Francisco or San Jose. Eventually, the dynamic routing protocols result in the Seoul-1 router sending packets to Seoul-2 for forwarding over its functional WAN, but reconvergence may take several minutes and disrupt the normal flow of network traffic. However, if Seoul-2 could assume the active forwarding role, it could immediately forward packets to San Francisco and San Jose via its functional WAN connection. The IOS software provides an HSRP feature so that Seoul-1 can be made to adjust the HSRP priority of the HSRP group on Ethernet 0 in such a way that Seoul-2 becomes the active forwarding router. This functionality, which is called interface tracking, is enabled with the IOS interface configuration subcommand standby track . This command takes as a parameter the interface to be tracked and, optionally , the amount to decrement from the HSRP priority for the configured interface. If no priority decrement value is specified, the router deducts the standard amount of ten from the HSRP priority. The following is an example of configuring the standby track command on the ZIP Seoul-1 router so that if the WAN interface Serial 1 becomes unoperational, Seoul-2 becomes the active forwarding 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 ethernet 0 Seoul-1(config-if)# standby track serial 1 Seoul-1(config-if)#^ Z You can verify the operation of HSRP with the IOS EXEC command show standby . The command takes as an optional parameter the specific interface for which to display HSRP information. Without the optional interface parameter, HSRP information is displayed for all interfaces. The following is an example of the output of the show standby command on the ZIP Seoul-1 and Seoul-2 routers: Seoul-1# show standby Ethernet0 - Group 0 Local state is Active, priority 100, may preempt Hellotime 3 holdtime 10 Next hello sent in 00:00:01.880 Hot standby IP address is 131.108.3.3 configured Active router is local Standby router is 131.108.3.2 expires in 00:00:07 Tracking interface states for 1 interface, 1 up: Up Serial0 Seoul-1# Seoul-2# show standby Ethernet0 - Group 0 Local state is Standby, priority 95, may preempt Hellotime 3 holdtime 10 Next hello sent in 00:00:01.380 Hot standby IP address is 131.108.3.3 configured Active router is 131.108.3.1 expires in 00:00:06 Standby router is local Seoul-2# The show standby command displays HSRP information, which includes the forwarding state, the HSRP priority, and the interfaces being tracked for the router being queried. It also displays information about the configured standby IP address and the IP address(es) of possible standby routers within each HSRP group. One of the drawbacks of the original HSRP was that it did not allow the network administrator to load-share the traffic across both the routers in the standby group. Basically, the standby router would just sit idle unless the active forwarding router failed. To address this concern, the capability to support multiple HSRP groups on the same interface was added to the IOS software. On the same interface, you can create multiple HSRP groups ”each with a different virtual IP address ”to back up one another. For example, on the ZIP routers Seoul-1 and Seoul-2, the first HSRP group has a virtual IP address of 131.108.3.3, and Seoul-1 has been designated the primary forwarding router by virtue of its higher HSRP priority. A second HSRP group can be configured for which the virtual IP address is 131.108.3.4, but Seoul-2 is designated as the primary forwarding router by means of setting its HSRP priority higher than Seoul-1 in the second HSRP group. Seoul-1 would then be the active forwarding router, and Seoul-2 would be the standby router for the first HSRP group, while Seoul-2 would be the active forwarding router and Seoul-1 would be the standby router for the second HSRP group. With two HSRP groups and two virtual IP addresses defined, the network administrator can configure the default gateway on some of the hosts with one of the HSRP virtual addresses and some of the hosts with the other. Although it does not achieve exactly equal load bal-ancing, this configuration shares the load between the two routers instead of substantially overloading one while the other is completely unused. Multiple HSRP groups are created by specifying an optional group number in all the standby commands. For example, standby 1 ip address 131.108.3.3 and standby 1 priority 100 specify that these HSRP commands apply to standby group 1. The commands standby 2 ip address 131.108.3.4 and standby 2 priority 100 specify that these HSRP commands apply to standby group 2. |
EAN: 2147483647
Pages: 116