One of the major changes to the CCNA examination is the introduction of IP Services into the examination. If you plan to take the exam after 30 September, 2013, then you must take the new exam. In this series of posts, we will explore the IP Services topics that you require for the new CCNA exam. Some of the topics that we will discuss include:
First Hop Redundancy Protocols (HSRP, VRRP and GLBP)
As usual, we will employ a hands-on approach so I encourage you to load your simulators/emulators and try to practice the concepts that we will discuss throughout the series.
Dynamic Host Configuration Protocol (DHCP)
DHCP is the protocol that is responsible for the first level of magic that happens when a user connects to the network. We have already learned that a device to communicate on an IP network, the device needs an IP address. So how do we assign these IP addresses to devices? We can do it manually. But that would mean that for every user that joins the network, you have to configure a unique IP address that is part of your network. This can easily become a nightmare for any administrator. The other option would be to automatically assign IP addresses to devices. And that is where DHCP comes in.
DHCP was developed as an extension to the bootstrap protocol (BootP) which was the original protocol developed to assign IP addresses to devices while they were booting up. You can say that DHCP is BootP on steroids. DHCP automatically assigns configuration information to devices, based on a client server model. The DHCP process is a four-step process:
DHCP Discover—When a device is connected to a network, it sends broadcast packets to “discover” the DHCP servers on the network. Remember that a broadcast is sent to all the servers on the subnet. For DHCP to work properly, the DHCP server should be on the same network as the DHCP client.
DHCP Offer—When DHCP servers receive a “discover” packet, they respond with an offer message. The message is a unicast message that contains the IP address offer of the client. It is possible for a subnet to have more than one DHCP Server. In that case, the client accepts the first offer that it gets.
DHCP Request—After a client receives a DHCP offer, the client sends a broadcast requesti for that particular offer. This broadcast tells all other servers that may have offered it an address that the client already has an offer and is no longer interested.
DHCP ACK: When the client makes a request for the IP address, the server responds with an acknowledgement. At this point, the DHCP transaction is complete and the client can use the IP address for as long as the lease time is valid.
The DHCP server is usually set up on a Windows server or a Linux server in large network environments. However, in some cases you might need to configure the Cisco router as a DHCP server. You can easily set this up from the command line. Let us look at an example:
In this example, we will configure the router as a DHCP server and observe the DHCP process. Assuming we have the following details:
IP Address Pool—192.168.2.11 – 192.168.2.254
IP address range restricted for servers—192.168.2.2 to 192.168.2.10
The configuration on the router would look like:
The “ip dhcp excluded-address” command excludes some addresses in the pool from being assigned. In this example, the router would begin assigning addresses from 192.168.2.11
The “network” command indicates the addresses that the can be used in the pool. Notice that the /24 format of the subnet mask can be used, instead of the dotted decimal format of 255.255.255.0.
Similarly, the “domain-name” and “dns-server” commands are used to specify the domain name and dns-server that would be sent to clients requesting addresses from that pool. If you have more than one dns-server, you can list them in order of preference.
The lease time (set in days) is the amount of time that the address is valid for. In this case, we have set the lease time to 30 days. This means that once the router hands out an address, the user does not need to renew the address for 30 days. Long lease times can cause problems in dynamic environments if the address pool is not long enough. An example is an hotel with different guests; if the lease time is set to 30 days and guests only spend an average of three days, then the IP addresses they are issued cannot be reissued to other guests for another 27 days after they have left the hotel.
Now let’s see what happens when a user tries to connect to the network. We can use the debug commands to see what is going on in the background
“debug ip dhcp server packets”
“debug ip dhcp server events”
Caution: Be CAREFUL with debugs on a live network! If heavy traffic is sent across the router, debugs can overload the console and the CPU. Debugs are very useful in lab environments but can be extremely dangerous in production!
First we receive a discover message from the client:
Once the router confirms that there is an available address in the pool, it sends an offer to the client:
This is followed by a DHCP request from the client:
And then the acknowledgement is sent back to the client, completing the four-step process:
Notice the parameters of the DHCP configuration that we applied in the debugs. The fully qualified domain name (FQDN) of the device is also generated as part of the DHCP exchanges. Now let’s check on the client to see if we received the IP address.
On a Windows machine, you can use the ipconfig command to check the TCP/IP parameters. On a MAC or Linux, you can use ifconfig -a from the terminal.
Notice that the client has downloaded the correct configuration from the server. Just like magic. And it happens so fast that most users do not even know that there’s something going on in the background. You see, that is the beauty of networking.
One extra tip for the day. What happens when you just connect the client to the switch for the first time and the switch port comes on? If it a Cisco switch, it has to go through the listening and learning modes before it goes to forwarding mode. This means that you can wait for up to 30 seconds before the switch starts forwarding the DHCP packets. Sometimes, the device will give up after a couple of retries and this breaks the DHCP process. In order to fix this, it is advisable to configure portfast on ports that are facing hosts on a Cisco switch. To do this, just issue the interface command:
As part of the DHCP configuration, you might need to configure DHCP options that do not have well-defined names. In order to do this, you can use the “option command.” A typical example of when you need to do this is when you set up IP phones. IP phones usually download their initial configuration files from a TFTP server (which is usually the call manager too). In order for the phones to identify the TFTP server, the option 66 feature needs to be configured under the DHCP pool, as shown below:
Router as a DHCP Client
In some circumstances, a router can be configured as a DHCP Client. An example is when you have an ISP that automatically assigns IP addresses to its customers. To configure a router as a DHCP client on an Ethernet interface is quite easy. Assuming another router (R2) is connected to our DHCP server, as shown below:
You can configure it as a DHCP client using the configuration below:
The “ip address dhcp” command configures the router interface to act as a dhcp client. As you can see in the syslog message above, the router is assigned 192.168.2.12 as its IP address.
You can verify connectivity by using the show commands, as shown below:
Note that the method of IP assignment shows DHCP. Also, a default route pointing to 192.168.2.1 has automatically been installed in the routing table because the default router was set to 192.168.2.1
You can verify the addresses that have been given out by a DHCP using the show command “show ip dhcp binding” The output of the command is shown below:
P.S The lease expiration dates are wrong because the clock of the router has not been set correctly. Always remember to set your date correctly in production.
We have come to the end of the first post in this series. I hope you enjoyed it as much as I did. As usual, if you have any thoughts or comments, please feel free to use the comments section. In the next post we will take a look at first hop redundancy protocols. See you soon!