1.2.6 Verifying DHCP operation / 1.2.7 Troubleshooting DHCP

1.2.6 Verifying DHCP operation
To verify the operation of DHCP, the command show ip dhcp binding can be used. This displays a list of all bindings created by the DHCP service.
To verify that messages are being received or sent by the router, use the command show ip dhcp server statistics. This will display count information regarding the number of DHCP messages that have been sent and received. 
1.2.7Troubleshooting DHCP
To troubleshoot the operation of the DHCP server, the command debug ip dhcp server events can be used. This command will show that the server periodically checks to see if any leases have expired. Also displayed are the processes of addresses being returned and addresses being allocated.

1.2.5 Configuring DHCP / 1.2.6 Verifying DHCP operation

1.2.5 Configuring DHCP

Like NAT, a DHCP server requires that the administrator define a pool of addresses. The ip dhcp pool command defines which addresses will be assigned to hosts.
The first command, ip dhcp pool, creates a pool with the specified name and puts the router in a specialized DHCP configuration mode. In this mode, use the network statement to define the range of addresses to be leased. If specific addresses on the network are to be excluded, return to global configuration mode.
The ip dhcp excluded-address command configures the router to exclude an individual address or range of addresses when assigning addresses to clients. The ip dhcp excluded-address command may be used to reserve addresses that are statically assigned to key hosts, for instance, the interface address on the router.
Typically, a DHCP server will be configured to assign much more than an IP address. Other IP configuration values such as the default gateway can be set from the DHCP configuration mode. Using the default-router command sets the default gateway. The address of the DNS server, dns-server, and WINS server, netbios-name-server, can also be configured here. The IOS DHCP server can configure clients with virtually any TCP/IP information.
A list of the key IOS DHCP server commands entered in the DHCP pool configuration mode are shown in Figure .
The DHCP service is enabled by default on versions of Cisco IOS that support it. To disable the service, use the no service dhcp command. Use the service dhcp global configuration command to re-enable the DHCP server process.

1.2.6 Verifying DHCP operation
To verify the operation of DHCP, the command show ip dhcp binding can be used. This displays a list of all bindings created by the DHCP service.
To verify that messages are being received or sent by the router, use the command show ip dhcp server statistics. This will display count information regarding the number of DHCP messages that have been sent and received. 

1.2.4 DHCP operation

1.2.4 DHCP operation

The DHCP client configuration process uses the following steps:

1. A client must have DHCP configured when starting the network membership process. The client sends a request to a server requesting an IP configuration. Sometimes the client may suggest the IP address it wants, such as when requesting an extension to a DHCP lease. The client locates a DHCP server by sending a broadcast called a DHCPDISCOVER.
2. When the server receives the broadcast, it determines whether it can service the request from its own database. If it cannot, the server may forward the request on to another DHCP server. If it can, the DHCP server offers the client IP configuration information in the form of a unicast DHCPOFFER. The DHCPOFFER is a proposed configuration that may include IP address, DNS server address, and lease time.
3. If the client finds the offer agreeable, it will send another broadcast, a DHCPREQUEST, specifically requesting those particular IP parameters. Why does the client broadcast the request instead of unicasting it to the server? A broadcast is used because the first message, the DHCPDISCOVER, may have reached more than one DHCP server. If more than one server makes an offer, the broadcasted DHCPREQUEST allows the other servers to know which offer was accepted. The offer accepted is usually the first offer received.
4. The server that receives the DHCPREQUEST makes the configuration official by sending a unicast acknowledgment, the DHCPACK. It is possible, but highly unlikely, that the server will not send the DHCPACK. This may happen because the server may have leased that information to another client in the interim. Receipt of the DHCPACK message enables the client to begin using the assigned address immediately.
5. If the client detects that the address is already in use on the local segment it will send a DHCPDECLINE message and the process starts again. If the client received a DHCPNACK from the server after sending the DHCPREQUEST, then it will restart the process again.
6. If the client no longer needs the IP address, the client sends a DHCPRELEASE message to the server.

Depending on an organization's policies, it may be possible for an end user or an administrator to statically assign a host an IP address that belongs in the DHCP servers address pool. Just in case, the Cisco IOS DHCP server always checks to make sure that an address is not in use before the server offers it to a client. The server will issue an ICMP echo request, or will ping, to a pool address before sending the DHCPOFFER to a client. Although configurable, the default number of pings used to check for a potential IP address conflict is two.

1.2.2 BOOTP and DHCP differences / 1.2.3 Major DHCP features

1.2.2 BOOTP and DHCP differences

The Internet community first developed the BOOTP protocol to enable configuration of diskless workstations. BOOTP was originally defined in RFC 951 in 1985. As the predecessor of DHCP, BOOTP shares some operational characteristics. Both protocols are client/server based and use UDP ports 67 and 68. Those ports are still known as BOOTP ports.
The four basic IP parameters include:

• IP address
• Gateway address
• Subnet mask
• DNS server address

BOOTP does not dynamically allocate IP addresses to a host. When a client requests an IP address, the BOOTP server searches a predefined table for an entry that matches the MAC address for the client. If an entry exists, then the corresponding IP address for that entry is returned to the client. This means that the binding between the MAC address and the IP address must have already been configured in the BOOTP server.
There are two primary differences between DHCP and BOOTP:

• DHCP defines mechanisms through which clients can be assigned an IP address for a finite lease period. This lease period allows for reassignment of the IP address to another client later, or for the client to get another assignment, if the client moves to another subnet. Clients may also renew leases and keep the same IP address.

DHCP provides the mechanism for a client to gather other IP configuration parameters, such as WINS and domain name. 

1.2.3 Major DHCP features
There are three mechanisms used to assign an IP address to the client:

• Automatic allocation – DHCP assigns a permanent IP address to a client.
• Manual allocation – The IP address for the client is assigned by the administrator. DHCP conveys the address to the client.
• Dynamic allocation – DHCP assigns, or leases, an IP address to the client for a limited period of time.

The focus of this section is the dynamic allocation mechanism. Some of the configuration parameters available are listed in IETF RFC 1533:

• Subnet mask
• Router
• Domain Name
• Domain Name Server(s)
• WINS Server(s)

The DHCP server creates pools of IP addresses and associated parameters. Pools are dedicated to an individual logical IP subnet. This allows multiple DHCP servers to respond and IP clients to be mobile. If multiple servers respond, a client can choose only one of the offers.

1.2.1 DHCP / Introducing DHCP

1.2.1 DHCP / Introducing DHCP

Dynamic Host Configuration Protocol (DHCP) works in a client/server mode. DHCP enables DHCP clients on an IP network to obtain their configurations from a DHCP server. Less work is involved in managing an IP network when DHCP is used. The most significant configuration option the client receives from the server is its IP address. The DHCP protocol is described in RFC 2131.
A DHCP client is included in most modern operating systems including the various Windows operating systems, Novell Netware, Sun Solaris, Linux, and MAC OS. The client requests addressing values from the network DHCP server . This server manages the allocation of the IP addresses and will answer configuration requests from clients. The DHCP server can answer requests for many subnets. DHCP is not intended for configuring routers, switches, and servers. These type of hosts need to have static IP addresses.
DHCP works by providing a process for a server to allocate IP information to clients. Clients lease the information from the server for an administratively defined period. When the lease expires the client must ask for another address, although the client is typically reassigned the same address.
Administrators typically prefer a network server to offer DHCP services because these solutions are scalable and relatively easy to manage. Cisco routers can use a Cisco IOS feature set, Easy IP, to offer an optional, full-featured DHCP server. Easy IP leases configurations for 24 hours by default. This is useful in small offices and home offices where the home user can take advantage of DHCP and NAT without having an NT or UNIX server.
Administrators set up DHCP servers to assign addresses from predefined pools. DHCP servers can also offer other information, such as DNS server addresses, WINS server addresses, and domain names. Most DHCP servers also allow the administrator to define specifically what client MAC addresses can be serviced and automatically assign them the same IP address each time.
DHCP uses User Datagram Protocol (UDP) as its transport protocol. The client sends messages to the server on port 67. The server sends messages to the client on port 68.

1.1.7 Issues with NAT

1.1.7 Issues with NAT

NAT has several advantages, including:

• Conserves the legally registered addressing scheme by allowing the privatization of intranets.
• Increases the flexibility of connections to the public network. Multiple pools, backup pools, and load balancing pools can be implemented to assure reliable public network connections.
• Consistency of the internal network addressing scheme. On a network without private IP addresses and NAT, changing public IP addresses requires the renumbering of all hosts on the existing network. The costs of renumbering hosts can be significant. NAT allows the existing scheme to remain while supporting a new public addressing scheme.

NAT is not without drawbacks. Enabling address translation will cause a loss of functionality, particularly with any protocol or application that involves sending IP address information inside the IP payload. This requires additional support by the NAT device.
NAT increases delay. Switching path delays are introduced because of the translation of each IP address within the packet headers. The first packet will always go through the slow path, which means this first packet is process-switched. The remaining packets will go through the fast-switched path if a cache entry exists.
Performance may be a consideration because NAT is currently accomplished by using process switching. The CPU must look at every packet to decide whether it must be translated. The CPU must alter the IP header, and possibly alter the TCP or UDP header.
One significant disadvantage when implementing and using NAT is the loss of end-to-end IP tractability. It becomes much more difficult to trace packets that undergo numerous packet address changes over multiple NAT hops. Hackers who want to determine the source of a packet will find it difficult to trace or obtain the original source or destination address.
NAT also forces some applications that use IP addressing to stop functioning because it hides end-to-end IP addresses. Applications that use physical addresses instead of a qualified domain name will not reach destinations that are translated across the NAT router. Sometimes, this problem can be avoided by implementing static NAT mappings.
Cisco IOS NAT supports the following traffic types:

• ICMP
• File Transfer Protocol (FTP), including PORT and PASV commands
• NetBIOS over TCP/IP, datagram, name, and session services
• RealNetworks' RealAudio
• White Pines' CUSeeMe
• Xing Technologies' StreamWorks
• DNS "A" and "PTR" queries
• H.323/Microsoft NetMeeting, IOS versions 12.0(1)/12.0(1)T and later
• VDOnet's VDOLive, IOS versions 11.3(4)11.3(4)T and later 
• VXtreme's Web Theater, IOS versions 11.3(4)11.3(4)T and later 
• IP Multicast, IOS version 12.0(1)T with source address translation only 

Cisco IOS NAT does not support the following traffic types:

• Routing table updates
• DNS zone transfers
• BOOTP
• talk and ntalk protocols

Simple Network Management Protocol (SNMP) 

1.1.5 Verifying PAT configuration / 1.1.6 Troubleshooting NAT and PAT configuration

1.1.5 Verifying PAT configuration
Once NAT is configured, use the clear and show commands to verify that it is operating as expected.
By default, dynamic address translations will time out from the NAT translation table after a period of non-use. When port translation is not configured, translation entries time out after 24 hours, unless the timers are reconfigured with the ip nat translation timeouttimeout_ seconds command from global configuration mode. Clear the entries before the timeout by using one of the commands in Figure .
Translation information may be displayed by performing one of the tasks in EXEC mode .
Alternatively, use the show run command and look for NAT, access list, interface, or pool commands with the required values.

1.1.6 Troubleshooting NAT and PAT configuration
When IP connectivity problems in a NAT environment exist, it is often difficult to determine the cause of the problem. Many times NAT is mistakenly blamed, when in reality there is an underlying problem.
When trying to determine the cause of an IP connectivity problem, it helps to rule out NAT. Use the following steps to determine whether NAT is operating as expected:

1. Based on the configuration, clearly define what NAT is supposed to achieve.
2. Verify that correct translations exist in the translation table.
3. Verify the translation is occurring by using show and debug commands.
4. Review in detail what is happening to the packet and verify that routers have the correct routing information to move the packet along.

Use the debug ip nat command to verify the operation of the NAT feature by displaying information about every packet that is translated by the router. The debug ip natdetailed command generates a description of each packet considered for translation. This command also outputs information about certain errors or exception conditions, such as the failure to allocate a global address.
Figure shows a sample debug ip nat output. In this example, the first two lines of the debugging output show that a Domain Name System (DNS) request and reply were produced. The remaining lines show the debugging output of a Telnet connection from a host on the inside of the network to a host on the outside of the network.
Decode the debug output by using the following key points:

• The asterisk next to NAT indicates that the translation is occurring in the fast-switched path. The first packet in a conversation will always go through the slow path, which means this first packet is process-switched. The remaining packets will go through the fast-switched path if a cache entry exists.
• s = a.b.c.d is the source address.
• Source address a.b.c.d is translated to w.x.y.z.
• d = e.f.g.h is the destination address.

The value in brackets is the IP identification number. This information may be useful for debugging. This is useful, for example, because it enables correlation with other packet traces from protocol analyzers.