Welcome to this Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about the Dynamic Host Configuration Protocol (DHCP) and the Domain Name System (DNS), two primary services in today's IPv4 and IPv6 networks. This event will focus on discussing and answering questions concerning the detailed operation of these protocols and services and their implementation, optimization, and troubleshooting.
Cisco Designated VIP Peter Palúch is an assistant professor and a Cisco Networking Academy instructor/instructor trainer at the University of Zilina, Slovakia. His fields of interest include routing, switching, and service provider technologies. He is a seasoned teacher who has cooperated in various educational activities in Slovakia and abroad, focusing particularly on networking and Linux-based network server systems. Peter holds a doctoral degree in the area of VoIP quality degradation factors; he is CCIE no. 23527 certified in routing and switching.
Remember to use the rating system to let Peter know if you have received an adequate response.
Because of the volume expected during this event, Peter might not be able to answer every question. Remember that you can continue the conversation in the Network Infrastructure Community, under the subcommunity IPv6 Integration and Transition, shortly after the event. This event lasts through July 18, 2014. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.
Solved! Go to Solution.
Thank you for sharing your insight.
I believe Ivan was focused on a different issue - he was not asking about maintaining an IP/MAC correspondence gained by gleaning the DHCP communication but rather how to configure the DHCP server itself so that you can manually bind an IP address to a particular host identified by its MAC or Client ID.
The DHCP Snooping is actually a very nice and relevant topic to this thread. The purpose of DHCP Snooping is multifold:
Discussing its details would be a delight - but let's see first if anyone of our readers is interested.
To mitigate this attack - IP Spoof guard is created which actually checks if the IP address is coming from the proper port and is it using the proper mac address.
I am sorry but I do not agree with this statement. DHCP communication is basically a control plane traffic. IP Source Guard protects primarily the data plane traffic by making sure it is sourced only from an IP address (and optionally a corresponding MAC address) that was assigned to a particular station on a particular switchport by the DHCP server. I do not believe that IP Source Guard is able to prevent the DHCP Starvation attack because for a particular IP/MAC combination, it can start doing its job only after DHCP performs the assignment, not before.
The DHCP Starvation attack in particular can be prevented by a combination of countermeasures: configuring DHCP Snooping rate limiting if high intensity attacks are expected, and then by the tools you have suggested yourself: using Port Security to limit the maximum number of MAC addresses on a port, and potentially 802.1X per-host authentication.
Hi, Sir i want to take a part in this discussion. Sir can u please teach me about DHCP? like.. where i can use DHCP configuration? means that in layer 2 always or layer3? or both? and how? i recently enrolled in ccna so i have some problems regarding this.
Thankyou so much...
Thank you so much for joining this thread, and please feel very much welcome to post any specific questions you might have regarding DHCP and DNS!
where i can use DHCP configuration? means that in layer 2 always or layer3? or both?
Just to reiterate on the basics - I am sure you know this already - DHCP is a service that allows a device to acquire all necessary IP settings automatically, instead of requiring you to configure them manually. It is a client/server service, in which the client is the device that seeks to obtain its configuration automatically, and the server is the device that hands out the configuration. So when we talk about using DHCP, we want to be more clear whether we want a device to operate as a client (obtain its configuration from a server) or as a server (provide configuration to clients).
Because DHCP is primarily concerned about IP settings (although it can provide other kinds of settings, too), a pure Layer 2 device such as a basic unmanaged Ethernet switch would not generally participate in DHCP at all. The reason is simple: such a device does not implement or use IP, so there is no configuration the device could possibly ask for. To put this down in different words, if a device does not speak IP protocol then it does not care about DHCP, and is not able to operate as a client or a server.
The situation is different if we talk about routers, firewalls, or end hosts such as workstations, servers, printers, etc. These devices speak IP, so they can - with a proper software - act either as DHCP clients or DHCP servers. It is you as a network administrator who decides if a device is going to get its IP settings via DHCP (becoming a DHCP client), or perhaps if a device is going to provide IP settings to other devices (becoming a DHCP server).
Usually, end hosts like tablets, smartphones, notebooks, workstations, or network printers can be configured as DHCP clients. Devices such as routers and servers can be configured to operate as DHCP servers. It is less usual to have a router operate as a DHCP client - although it is normal when you connect your home gateway router to an internet service provider via some sort of Ethernet connection, and the service provider assigns you an IP address automatically.
So back to your original question - where can you use DHCP configuration? The answer: you can use DHCP on devices that implement the IP protocol (meaning they have at least some functionality on Layer 3 and higher).
If you want to make your router operate as a DHCP server handing out IP addresses to its directly connected clients, the configuration of the router would be, for example:
interface FastEthernet0/0 ip address 192.168.1.1 255.255.255.0 no shutdown ! ip dhcp excluded-address 192.168.1.1 192.168.1.10 ip dhcp pool LAN network 192.168.1.0 /24 default-router 192.168.1.1 dns-server 220.127.116.11 lease 0 0 30
In this example, the Fa0/0 interface is assumed to be the LAN interface of a router where end hosts are connected. The Fa0/0 is configured with an IP address 192.168.1.1/24 which is going to be the default gateway IP address for all hosts connected to that interface. The actual DHCP server configuration is located in the ip dhcp pool LAN section - this is the configuration of a pool of addresses that are going to be handed out to DHCP clients according to the following rules:
The name "LAN" in the ip dhcp pool command is an arbitrary verbose name that should describe the network served by this pool. It is entirely up to you how you name it.
There is also the ip dhcp excluded-address command in the configuration. Without this command, the DHCP server as shown in this example would happily offer all IP addresses from the entire 192.168.1.0/24 network, skipping only the unusable addresses 192.168.1.0, 192.168.1.255, and 192.168.1.1 that is already in use by the router itself. However, all other addresses would be free to use by clients. Usually, in each network, you want to have a range of IP addresses that are reserved for static addressing and are not going to be provided via DHCP to clients, both to have a space for stations configured with static IP addresses, and to avoid address conflicts with addresses that are already used. Therefore, using the ip dhcp excluded-address command, you can define a range of addresses that are not going to be offered to DHCP clients. The configuration shown above excludes the addresses from 192.168.1.1 to 192.168.1.10 inclusive from offering to clients, and will only offer addresses starting at 192.168.1.11 and ending at 192.168.1.254 to the DHCP clients.
If, on the other hand, you want to configure your router to act as a DHCP client, expecting to receive its configuration from a different, already preconfigured DHCP server reachable via a particular interface, this would be the configuration:
interface FastEthernet0/1 ip address dhcp no shutdown
Here, it is assumed that some DHCP server can be reached via Fa0/1 interface, and the interface will use whatever IP address the server assigns it.
I know that this answer is rather lengthy and perhaps complicated - you are welcome to ask further!
You are most welcome.
Regarding me teaching you more information about DHCP, I will be more than happy to answer any particular question you may have about DHCP. If you are interested in a tutorial about DHCP that explains all about DHCP from scratch then please let me know - while I am not going to write such a tutorial here as it would not be appropriate (it would basically be a book), I will be happy to search such materials for you.
These pages and slide decks are, in my opinion, a very nice introduction into the principles of DHCP:
If you are interested in configuring DHCP on Cisco IOS-based devices, then apart from a myriad of articles out there (just googling for "dhcp server ios" gives you hundreds of articles), it is also worth visiting the DHCP Configuration Guide by Cisco at
I hope you'll enjoy reading these resources!
thanku so much sir. i su DHCP configuration in my topology and its work. but sir i didn't use DNS ip and still my DHCP configuration is successfully impemented. why?
i su DHCP configuration in my topology and its work. but sir i didn't use DNS ip and still my DHCP configuration is successfully impemented. why?
I believe that you are asking why does your DHCP assign addresses to clients even though you have not configured any DNS address in the DHCP pool. Do I understand you correctly?
If yes then think about this: DHCP is a service that provides configuration information to clients. However, a DHCP server does not care about the actual contents of the configuration information it sends back to a client. You did specify a DNS server in the DHCP pool configuration? Okay, the DHCP server will advertise it to a client, along with other configuration items (address, netmask, gateway, lease time, domain, ...) you have specified. You did not specify a DNS server? That's still fine, the DHCP server will not advertise a DNS server to a client but it will advertise the remaining specified items. A DHCP server does not personally use any of the configuration items in the pool. Remember: DHCP server is just a remotely accessible database for configuration settings of individual clients. If the settings are intended for clients, a DHCP server in general can assign them but it has no reason to use them itself.
In fact, the minimal DHCP configuration in IOS that would work is this:
ip dhcp pool LAN network 192.168.1.0 /24
This configuration would assign the IP address and netmask to all clients in the network 192.168.1.0/24, and it would work just fine. However, the clients would only be able to communicate in their own network because besides their own address and netmask, they would not be assigned any other configuration, such as default gateway, DNS server address, domain name, etc. But as far as DHCP is concerned, this would already work. By adding other keywords to the pool, such as default-router for the gateway, dns-server for DNS address, domain-name for the domain name, you would make the configuration handed off to clients more complete, more rich.
Would this explain your observation?
yeah sir! thankyou so much,
sir when i assign DHCP configuration on my topology sometimes it was failed to configure. so please tell me what are the causes when DHCP is failed to configure.
i use these commands:
R1# configure terminal
R1(config)# service dhcp
R1(config)# ip dhcp pool NET-POOL
R1(dhcp-config)# network 192.168.1.0 255.255.255.0
R1(dhcp-config)# default-router 192.168.1.1
R1(config)# ip dhcp excluded-address 192.168.1.1 192.168.1.5
when i assign DHCP configuration on my topology sometimes it was failed to configure. so please tell me what are the causes when DHCP is failed to configure.
The configuration you have posted is perfect. As far as the DHCP server configuration is concerned, the configuration is complete and the server will happily assign an IP address, netmask, and the default gateway address to all clients in the 192.168.1.0/24 network. It is missing a DNS server address but that does not make the DHCP pool configuration invalid.
You are saying that sometimes "it was failed to configure". I suppose what you want to say is that sometimes, the clients are not assigned an IP address or report that their IP connectivity is limited. Is that right?
If yes then, well, there is no simple answer. As I said, the DHCP server configuration as shown in your previous post is fine. If that DHCP server receives a request from a client, it will respond unless all assignable IP addresses are already allocated. So the issue boils down to three options: either the server does not receive a client's request, or the server is unable to respond, or it responds but the client does not like the response.
Let's elaborate about these three options. The first one is that the client's DHCP request is not received by the DHCP server. Most often, I have seen this to be caused by clients attached to a switch that runs Spanning Tree Protocol (STP). Each port on such switch needs 30 seconds after being connected to until it becomes capable of forwarding data traffic (it goes over a series of STP states and it must reach the STP Forwarding state before it can start carrying user data). Usually, when an operating system boots, it tends to reinitialize the network card which causes the link to momentarily go down and up, and then the operating system tries to obtain its IP configuration over DHCP. However, the port on the switch has just went down and up, and it will need 30 seconds to become Forwarding again. On many operating systems, DHCP clients use aggressive timers and if they do not obtain an IP address in roughly 30 seconds, they will start complaining.
If the problem is caused by this then the solution is very easy: Simply configure the switch port toward the client using the spanning-tree portfast command. This command will cause the port to behave as a so-called edge port (Cisco calls them PortFast ports). An edge port is immediately put into Forwarding state as soon as it comes up. This will save you 30 seconds of time and will very possibly make your DHCP client happy.
The second option was that the DHCP server got the client's reponse but was unable to respond. Usually, this would be caused by all free IP addresses in the pool to be already allocated and still used, or all IP addresses being marked for conflict (meaning that the DHCP server tried to allocate an IP address that was already used). There is a number of commands you can check to verify your DHCP server operation:
show ip dhcp binding - this command shows you all allocated IP addresses
show ip dhcp conflict - this command shows you all IP addresses that caused a conflict (they're already assigned and the DHCP server did not know about that until it tried to assign the address itself)
show ip dhcp pool - information about your individual configured pools, including the number of leased addresses and total addresses in the pool, and the next IP address that would be leased if a new client requested it
Also, there is the option of debugging the DHCP server to see if it complains about any kind of probem during address allocation:
debug ip dhcp server events
To read the debug output, you either need to be connected to the router over a console, or if your are connected over a Telnet or SSH session, you must enter the terminal monitor command in the command line (not in the config). You would obviously need to read the debugs very carefully, as you do not really know what you are looking for, and you are searching for any kind of abnormal indication in the process of assigning an IP address. It might be useful to have a transcript of this debug when a client received its IP address successfully, and compare it to the output when a client is having trouble getting an IP address. Do not forget to deactivate the debugging after you have finished using the undebug all command - otherwise the debugging will run until you restart the router.
The third option was related to the fact that the server might respond but the client did not like the response. This is a tough thing to debug because especially in Windows, they don't really tell you anything, they just discard the reply and ask for a new IP address again, or they process it but consider it to be incomplete, and complain about this incompleteness. My personal experience with Windows is that they are only satisfied if the DHCP reply contains an IP address, netmask, default gateway, and the DNS server address. Your DHCP server configuration currently does not assign a DNS server address, and that may be the reason your stations appear to have troubles obtaining their IP settings while in reality, they are only missing the DNS server address.
There are open Google DNS servers available, so if you want to test this out, simply add the following line to your DHCP configuration:
and let's see if that makes your operating system to be satisfied.
Running Wireshark on the client and capturing all DHCP traffic may also provide some insight.
Please feel welcome to ask further!
First of all, thank you Peter for your explanations above.
I'd like to expand further this subject by asking you these questions:
1) I don't remember how to supply the DHCP client with the DNS Servers option and the Domain Name option. Could you please refresh my memory?
2) When DHCP Client is configured with those options, supposing it is a Cisco device or a Linux based system, can it do a parent name query like a Microsoft client do? I mean: let's say the DHCP Client host is a Cisco "Box" (any kind of L3 device) or a Linux Box and it got a domain name of "lab.home.com.br" ; and at its CLI we issue a ping command to another host that resides on the same domain name but we use only its hostname
i.e. # ping server01 instead of # ping server01.lab.home.com.br
is it going to append its own domain name on the DNS query just like a Microsoft host would do?
3) Is a Cisco or Linux Box capable of DNS dynamic register? I mean, once the box gets an IP address from its DHCP server and it has other configuration options like the DNS Server's IP address and the Domain Name, is it going to connect to its DNS Server and have it create a resource record type A in the apropriate Zone pointing to the DHCP client itself?
Thank you for joining the discussion! I apologize for my delayed answer - I sincerely hope it still reaches you.
1) I don't remember how to supply the DHCP client with the DNS Servers option and the Domain Name option. Could you please refresh my memory?
With Cisco IOS DHCP servers, the dns-server keyword is used to specify one or more DNS servers to be passed to a client, and the domain-name specifies the domain that the client should use to form Fully Qualified Domain Names (FQDNs). So, reusing my example from the previous post and just expanding it a little, the configuration would look as follows:
ip dhcp pool LAN network 192.168.1.0 /24 default-router 192.168.1.1 dns-server 18.104.22.168 domain-name myzone.com lease 0 0 30
Here in this example, the DNS server passed to clients is 22.214.171.124, and the domain name passed to clients is myzone.com. You can specify multiple DNS servers in the single dns-server command separated by whitespace.
2) When DHCP Client is configured with those options, supposing it is a Cisco device or a Linux based system, can it do a parent name query like a Microsoft client do?
It certainly can. You do not need to configure anything special on the client.
If it is a Cisco router, you simply configure its interface with ip address dhcp as explained in the previous post, and the IOS will automatically obtain its domain name from the DHCP and will use it whenever you specify a non-fully-qualified DNS name in the command line.
The same goes with Linux-based clients: on these clients, the domain list to be searched will be automatically stored in the /etc/resolv.conf file on the line starting with the search keyword, and the domains in this search list will be appended to the name being resolved in DNS.
There is one thing that, according to my experiments, neither Cisco nor Linux will do: automatically appending parent domains of the main DNS domain. In other words, if your domain is lab.home.com.br, and you ping server01, your Windows may go and try resolving
until it gets a proper DNS response. However, neither Linux nor Cisco IOS are going to do this. They will simply try resolving server01.lab.home.com.br.
3) Is a Cisco or Linux Box capable of DNS dynamic register?
Yes, both Linux and Cisco support Dynamic DNS registering. Accomplishing that on a Cisco IOS box is actually very easy. The most simple configuration would be as follows:
ip ddns update method DDNS DDNS ! interface FastEthernet0/1 ip ddns update hostname MyRouter.dynamicdns.com ip ddns update DDNS ip address dhcp no shutdown
This configuration starts with the definition of how to talk to a Dynamic DNS service. Two primary options are available - either the native DNS method called DDNS, or a HTTP-based service. The first two lines in the example simply give a name to the particular method used - currently, it is named DDNS and refers to the DDNS method, not really appearing to be useful. It would be more sensible if we used the HTTP method because in that case, the definition would hold URLs for adding and removing the dynamic DNS record, and you could possible have multiple Dynamic DNS profiles referring to several URLs. For now, this is the simplest configuration that works as long as the Dynamic DNS service provider for your domain allows dynamic updates.
On the Fa0/1 interface, the commands specify the FQDN you want to register in the DNS, and the method to be used to register the name dynamically. Note that the dynamicdns.com is just a domain I've invented for this example, and that domain would need to allow you updating the DNS records dynamically. As the DDNS method lacks proper authentication, I suspect that real Dynamic DNS providers out there like HTTP more as it allows for authenticating the update (otherwise, you could steal someone else's records, and that person could steal yours).
In any case, the configuration as shown here works nicely - tested with 12.4T IOS and BIND 9.9 DNS server.
Regarding Linux clients, Dynamic DNS support is available but you would need to install a software client to perform the updates. There are several clients available; do you use any specific Linux distribution? In Debian, there are ddclient, ddns3-client, dyndns, nsupdate, and ipcheck tools available to say the least.
Once again, thanks for joining and please feel welcome to ask further!
Thank you so much for your wonderful explanations!
If you don't mind, I'd like to go deeper on this subject and ask you what tools could I use on CentOS / Red Hat / Fedora distributions to be able to perform Dynamic DNS?
You are very much welcome!
Regarding your CentOS / Red Hat / Fedora, I supposed you are asking about a Dynamic DNS client (not a server).
For a client, the ddclient is the package that supports many Dynamic DNS services. Do you actually use any of the current dynamic DNS services out there? There's a lot of providers and each of them uses a different way of the client submitting updated information. ddclient supports a set of providers and others may be compatible with one of them - see http://sourceforge.net/p/ddclient/wiki/protocols/ for more information.
If you are using any of the existing Dynamic DNS providers, it would perhaps help if you told us which one it is. That would help us narrowing down the possible options.