DHCP Server Interview Questions and Answers
1. What is DHCP?
DHCP stands for "Dynamic Host Configuration Protocol".
2.What is DHCP's purpose?
DHCP's purpose is to enable individual computers on an IP network to extract
their configurations from a server (the 'DHCP server') or servers, in particular,
servers that have no exact information about the individual computers until they
request the information. The overall purpose of this is to reduce the work
necessary to administer a large IP network. The most significant piece of
information distributed in this manner is the IP address.
3. Can DHCP work with AppleTalk or IPX?
No, it is too tied to IP. Furthermore, they don't need it since they have always
had automated mechanisms for assigning their own network addresses.
4. Who Created It? How Was It Created?
DHCP was created by the Dynamic Host Configuration Working Group of the
Internet Engineering Task Force (IETF; a volunteer organization which defines
protocols for use on the Internet). As such, it's definition is recorded in an
Internet RFC and the Internet Activities Board (IAB) is asserting its status as to
Internet Standardization. As of this writing (June 1998), DHCP is an Internet
Draft Standard Protocol and is Elective. BOOTP is an Internet Draft Standard
Protocol and is recommended. For more information on Internet standardization,
see RFC2300 (May 1998)
5. How is it different than BOOTP or RARP?
DHCP is based on BOOTP and maintains some backward compatibility. The main
difference is that BOOTP was designed for manual pre-configuration of the host
information in a server database, while DHCP allows for dynamic allocation of
network addresses and configurations to newly attached hosts. Additionally,
DHCP allows for recovery and reallocation of network addresses through a
leasing mechanism.
RARP is a protocol used by Sun and other vendors that allows a computer to find
out its own IP number, which is one of the protocol parameters typically passed
to the client system by DHCP or BOOTP. RARP doesn't support other parameters
and using it, a server can only serve a single LAN. DHCP and BOOTP are
designed so they can be routed.
6.How is it different than VLANs?
DHCP and VLANs, which are very different in concept, are sometimes cited as
different solutions to the same problem. While they have a goal in common
(easing moves of networked computers), VLANs represent a more revolutionary
change to a LAN than DHCP. A DHCP server and forwarding agents can allow you
to set things up so that you can unplug a client computer from one network or
subnet and plug it into another and have it come alive immediately, it having
been reconfigured automatically. In conjunction to Dynamic DNS, it could
automatically be given its same name in its new place. VLAN-capable LAN
equipment with dynamic VLAN assignment allows you to configure things so a
client computer can be plugged into any port and have the same IP number (as
well as name) and be on the same subnet. The VLAN-capable network either has
its own configuration that lists which MAC addresses are to belong to each VLAN,
or it makes the determination from the source IP address of the IP packets that
the client computer sends. Some differences in the two approaches:
- DHCP handles changes by reconfiguring the client while a VLAN-capable
network handles it by reconfiguring the network port the client is moved to.
- DHCP dynamic reconfiguration requires a DHCP server, forwarding agent
in each router, and DHCP capability in each client's TCP/IP support. The
analogous capability in VLANs requires that all hubs throughout the
network be VLAN-capable, supporting the same VLAN scheme. To this
point VLAN support is proprietary with no vendor interoperability, but
standards are being developed.
- DHCP can configure a new client computer for you while a VLAN-capable
network can't.
- DHCP is generally aimed at giving "easy moves" capability to networks
that are divided into subnets on a geographical basis, or on separate
networks. VLANs are generally aimed at allowing you to set up subnets
on some basis other than geographical, e.g. instead of putting everyone
in one office on the same subnet, putting each person on a subnet that
has access to the servers that that person requires.
There is an issue with trying to use DHCP (or BOOTP) and VLANs at the same
time, in particular, with the scheme by which the VLAN-capable network
determines the client's VLAN based upon the client computer's source IP
address. Doing so assumes the client computer is already configured, which
precludes the use of network to get the configuration information from a DHCP
or BOOTP server.
7. What protocol and port does DHCP use?
DHCP, like BOOTP runs over UDP, utilizing ports 67 and 68.
8. What is an IP address?
An IP address (also called an IP number) is a number (typically written as four
numbers separated by periods, i.e. 107.4.1.3 or 84.2.1.111) which uniquely
identifies a computer that is making use of the Internet. It is analogous to your
telephone number in that the telephone number is used by the telephone
network to direct calls to you. The IP address is used by the Internet to direct
data to your computer, e.g. the data your web browser retrieves and displays
when you surf the net. One task of DHCP is to assist in the problem of getting a
functional and unique IP number into the hands of the computers that make use
of the Internet.
9. What is a MAC address?
A MAC address (also called an Ethernet address or an IEEE MAC address) is a
number (typically written as twelve hexadecimal digits, 0 through 9 and A
through F, or as six hexadecimal numbers separated by periods or colons, i.e.
0080002012ef, 0:80:0:2:20:ef) which uniquely identifes a computer that has an
Ethernet interface. Unlike the IP number, it includes no indication of where your
computer is located. In DHCP's typical use, the server uses a requesting
computer's MAC address to uniquely identify it.
10. What is a DHCP lease?
A DHCP lease is the amount of time that the DHCP server grants to the DHCP
client permission to use a particular IP address. A typical server allows its
administrator to set the lease time.
11. What is a Client ID?
What is termed the Client ID for the purposes of the DHCP protocol is whatever
is used by the protocol to identify the client computer. By default, DHCP
implementations typically employ the client's MAC address for this purpose, but
the DHCP protocol allows other options. Some DHCP implementations have a
setup option to specify the client ID you want. One alternative to the MAC
address is simply a character string of your choice. In any case, in order for
DHCP to function, you must be certain that no other client is using the client ID
you choose, and you must be sure the DHCP server will accept it.
12.Can DHCP support statically defined addresses?
Yes. At least there is nothing in the protocol to preclude this and one expects it
to be a feature of any DHCP server. This is really a server matter and the client
should work either way. The RFC refers to this as manual allocation.
13. How does DHCP and BOOTP handle multiple subnets?
For the situations where there is more than one LAN, each with its own subnet
number, there are two ways. First of all, you can set up a seperate server on
each subnet. Secondly, a feature of some routers known as "BOOTP forwarding"
to forward DHCP or BOOTP requests to a server on another subnet and to
forward the replies back to the client. The part of such a router (or server acting
as a router) that does this is called a "BOOTP forwarding agent". Typically you
have to enable it on the interface to the subnet to be served and have to
configure it with the IP address of the DHCP or BOOTP server. On a Cisco router,
the address is known as the "UDP Helper Address".
14. Can a BOOTP client boot from a DHCP server?
Only if the DHCP server is specifically written to also handle BOOTP queries.
15. Can a DHCP client boot from a BOOTP server?
Only if the DHCP client were specifically written to make use of the answer from
a BOOTP server. It would presumably treat a BOOTP reply as an unending lease
on the IP address.
In particular, the TCP/IP stack included with Windows 95 does not have this
capability.
16. Is a DHCP server "supposed to" be able to support a BOOTP client?
The RFC on such interoperability (1534) is clear: "In summary, a DHCP server:
... MAY support BOOTP clients," (section 2). The word "MAY" indicates such
support, however useful, is left as an option.
A source of confusion on this point is the following statement in section 1.5 of
RFC 1541: "DHCP must provide service to existing BOOTP clients." However, this
statement is one in a list of "general design goals for DHCP", i.e. what the
designers of the DHCP protocol set as their own goals. It is not in a list of
requirements for DHCP servers.
17. Is a DHCP client "supposed to" be able to use a BOOTP server?
The RFC on such interoperability (1534) is clear: "A DHCP client MAY use a reply
from a BOOTP server if the configuration returned from the BOOTP server is
acceptable to the DHCP client." (section 3). The word "MAY" indicates such
support, however useful, is left as an option.
18. Can a DHCP client or server make a DNS server update the client's DNS entry to match the client's dynamically assigned address?
RFCs 2136 and 2137 indicate a way in which DNS entries can be updated
dynamically. Using this requires a DNS server that supports this feature and a
DHCP server that makes use of it. The RFCs are very recent (as of 5/97) and
implementations are few. In the mean time, there are DNS and DHCP servers
that accomplish this through proprietary means.
19. Can a DHCP server back up another DHCP server?
You can have two or more servers handing out leases for different addresses. If
each has a dynamic pool accessible to the same clients, then even if one server
is down, one of those clients can lease an address from the other server.
However, without communication between the two servers to share their
information on current leases, when one server is down, any client with a lease
from it will not be able to renew their lease with the other server. Such
communication is the purpose of the "server to server protocol" (see next
question). It is possible that some server vendors have addressed this issue with
their own proprietary server-to-server communication.
20. When will the server to server protocol be defined?
The DHC WG of the IETF is actively investigating the issues in inter-server
communication. The protocol should be defined "soon".
21.Where is DHCP defined?
In Internet RFCs.
22. Can DHCP support remote access?
PPP has its own non-DHCP way in which communications servers can hand
clients an IP address called IPCP (IP Control Protocol) but doesn't have the same
flexibility as DHCP or BOOTP in handing out other parameters. Such a
communications server may support the use of DHCP to acquire the IP addresses
it gives out. This is sometimes called doing DHCP by proxy for the client. I know
that Windows NT's remote access support does this.
A feature of DHCP under development (DHCPinform) is a method by which a
DHCP server can supply parameters to a client that already has an IP number.
With this, a PPP client could get its IP number using IPCP, then get the rest of its
parameters using this feature of DHCP.
SLIP has no standard way in which a server can hand a client an IP address, but
many communications servers support non-standard ways of doing this that can
be utilized by scripts, etc. Thus, like communications servers supporting PPP,
such communications servers could also support the use of DHCP to acquire the
IP addressees to give out.
The DHCP protocol is capable of allocating an IP address to a device without an
IEEE-style MAC address, such as a computer attached through SLIP or PPP, but
to do so, it makes use of a feature which may or may not be supported by the
DHCP server: the ability of the server to use something other than the MAC
address to identify the client. Communications servers that acquire IP numbers
for their clients via DHCP run into the same roadblock in that they have just one
MAC address, but need to acquire more than one IP address. One way such a
communications server can get around this problem is through the use of a set
of unique pseudo-MAC addresses for the purposes of its communications with
the DHCP server. Another way (used by Shiva) is to use a different "client ID
type" for your hardware address. Client ID type 1 means you're using MAC
addresses. However, client ID type 0 means an ASCII string.
23.How can I relay DHCP if my router does not support it?
A server on a net(subnet) can relay DHCP or BOOTP for that net. Microsoft has
software to make Windows NT do this.
24.What is DHCP Spoofing?
Ascend Pipeline ISDN routers (which attach Ethernets to ISDN lines) incorporate
a feature that Ascend calls "DHCP spoofing" which is essentially a tiny server
implementation that hands an IP address to a connecting Windows 95 computer,
with the intention of giving it an IP number during its connection process.
25. How long should a lease be?
A very relevant factor is that the client starts trying to renew the lease when it is
halfway through: thus, for example, with a 4 day lease, the client which has lost
access to its DHCP server has 2 days from when it first tries to renew the lease
until the lease expires and the client must stop using the network. During a 2-
day outage, new users cannot get new leases, but no lease will expire for any
computer turned on at the time that the outage commences.
Another factor is that the longer the lease the longer time it takes for client
configuration changes controlled by DHCP to propogate.
25. How can I control which clients get leases from my server?
There is no ideal answer: you have to give something up or do some extra work.
- You can put all your clients on a subnet of your own along with your own
DHCP server.
- You can use manual allocation.
- Perhaps you can find DHCP server software that allows you to list which
MAC addresses the server will accept. DHCP servers that support roaming
machines may be adapted to such use.
- You can use the user class option assuming your clients and server
support it: it will require you to configure each of your clients with a user
class name. You still depend upon the other clients to respect your
wishes.
26. How can I prevent unauthorized laptops from using a network that uses DHCP for dynamic addressing?
This would have to be done using a mechanism other than DHCP. DHCP does not
prevent other clients from using the addresses it is set to hand out nor can it
distinguish between a computer's permanent MAC address and one set by the
computer's user. DHCP can impose no restrictions on what IP address can use a
particular port nor control the IP address used by any client.
27. What features or restrictions can a DHCP server have?
While the DHCP server protocol is designed to support dynamic management of
IP addresses, there is nothing to stop someone from implementing a server that
uses the DHCP protocol, but does not provide that kind of support. In particular,
the maintainer of a BOOTP server-implementation might find it helpful to
enhance their BOOTP server to allow DHCP clients that cannot speak "BOOTP" to
retrieve statically defined addresses via DHCP. The following terminology has
become common to describe three kinds of IP address allocation/management.
These are independent "features": a particular server can offer or not offer any
of them:
- Manual allocation: the server's administrator creates a configuration for
the server that includes the MAC address and IP address of each DHCP
client that will be able to get an address: functionally equivalent to
BOOTP though the protocol is incompatible.
- Automatic allocation: the server's administrator creates a configuration
for the server that includes only IP addresses, which it gives out to
clients. An IP address, once associated with a MAC address, is
permanently associated with it until the server's administrator intervenes.
- Dynamic allocation: like automatic allocation except that the server will
track leases and give IP addresses whose lease has expired to other
DHCP clients.
Other features which a DHCP server may or may not have:
- Support for BOOTP clients.
- Support for the broadcast bit.
- Administrator-settable lease times.
- Administrator-settable lease times on manually allocated addresses.
- Ability to limit what MAC addresses will be served with dynamic
addresses.
- Allows administrator to configure additional DHCP option-types.
- Interaction with a DNS server. Note that there are a number of
interactions that one might support and that a standard set & method is
in the works.
- Interaction with some other type of name server, e.g. NIS.
- Allows manual allocation of two or more alternative IP numbers to a
single MAC address, whose use depends upon the gateway address
through which the request is relayed.
- Ability to define the pool/pools of addresses that can be allocated
dynamically. This is pretty obvious, though someone might have a server
that forces the pool to be a whole subnet or network. Ideally, the server
does not force such a pool to consist of contiguous IP addresses.
- Ability to associate two or more dynamic address pools on separate IP
networks (or subnets) with a single gateway address. This is the basic
support for "secondary nets", e.g. a router that is acting as a BOOTP
relay for an interface which has addresses for more than one IP network
or subnet.
- Ability to configure groups of clients based upon client-supplied user
and/or vendor class. Note: this is a feature that might be used to assign
different client-groups on the same physical LAN to different logical
subnets.
- Administrator-settable T1/T2 lengths.
- Interaction with another DHCP server. Note that there are a number of
interactions that one might support and that a standard set & method is
in the works.
- Use of PING (ICMP Echo Request) to check an address prior to
dynamically allocating it.
- Server grace period on lease times.
- Ability to force client(s) to get a new address rather than renew.
DHCP Discovery:
The client broadcasts on the local physical subnet to find available servers. Network
administrators can configure a local router to forward DHCP packets to a DHCP server on a
different subnet. This client-implementation creates a UDP packet with the broadcast
destination of 255.255.255.255 or subnet broadcast address and also requests its last-known
IP address (in the example below, 192.168.1.100) although the server may ignore this optional
parameter....
DHCP Offers:
When a DHCP server receives an IP lease request from a client, it extends an IP lease offer.
This is done by reserving an IP address for the client and broadcasting a DHCPOFFER message
across the network. This message contains the client's MAC address, followed by the IP
address that the server is offering, the subnet mask, the lease duration, and the IP address of
the DHCP server making the offer.
The server determines the configuration, based on the client's hardware address as specified in
the CHADDR field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR field.
DHCP Requests:
Whenever a computer comes on line, it checks to see if it currently has an IP address leased. If
it does not, it requests a lease from a DHCP server. Because the client computer does not know
the address of a DHCP server, it uses 0.0.0.0 as its own IP address and 255.255.255.255 as
the destination address. Doing so allows the client to broadcast a DHCPDISCOVER message
across the network. Such a message consists of the client computer's Media Access Control
(MAC) address (the hardware address built into the network card) and its NetBIOS name.
The client selects a configuration out of the DHCP "Offer" packets it has received and
broadcasts it on the local subnet. Again, this client requests the 192.168.1.100 address that
the server specified. In case the client has received multiple offers it specifies the server from
which it has accepted the offer.
DHCP Acknowledgement:
When the DHCP server receives the DHCPREQUEST message from the client, it initiates the
final phase of the configuration process. This acknowledgement phase involves sending a
DHCPACK packet to the client. This packet includes the lease duration and any other
configuration information that the client might have requested. At this point, the TCP/IP
configuration process is complete.
The server acknowledges the request and sends the acknowledgement to the client. The
system as a whole expects the client to configure its network interface with the supplied
options.
