Alcatel DHCP server Technology White Paper
- Type
- Technology White Paper
Alcatel DHCP server is a powerful and versatile device that can be used to provide dynamic IP address assignment and configuration to devices on a network. It supports a wide range of features, including:
- DHCP failover: This feature ensures that clients can still obtain IP addresses even if the primary DHCP server fails.
- Split-scope: This feature allows you to divide your IP address pool into multiple scopes, each of which can be managed by a different DHCP server.
- Option 82: This feature allows you to pass additional information, such as the client's MAC address, to the DHCP server.
Alcatel DHCP server is a powerful and versatile device that can be used to provide dynamic IP address assignment and configuration to devices on a network. It supports a wide range of features, including:
- DHCP failover: This feature ensures that clients can still obtain IP addresses even if the primary DHCP server fails.
- Split-scope: This feature allows you to divide your IP address pool into multiple scopes, each of which can be managed by a different DHCP server.
- Option 82: This feature allows you to pass additional information, such as the client's MAC address, to the DHCP server.
IP network administrators are understandably concerned with providing
redundancy in the event of the failure or inaccessibility of their frontline
Dynamic Host Configuration Protocol (DHCP) servers. Using a single
DHCP server to manage access to an IP network runs the risk that end
users will be denied access to the network when the DHCP server is
down or unreachable.
Customers who use Alcatel-Lucent DHCP servers and the VitalQIP
software to implement a redundant DHCP server configuration can
improve their service availability and increase end user satisfaction.
Implementing DHCP Redundancy to Sustain
Critical Operations
DHCP Redundancy: Choosing between the Split-Scopes and Alcatel-Lucent
Failover DHCP configurations
T E C H N O L O G Y W H I T E P A P E R
2 Alcatel-Lucent | Implementing DHCP Redundancy to Sustain Critical Operations
Table of Contents
1 Introduction
1 Understanding Split-Scopes
1 The Split-Scopes configuration provides proven redundancy protection
2 Split-Scopes and Alcatel-Lucent DHCP servers
3 Understanding the Alcatel-Lucent Failover DHCP configuration
3 The Alcatel-Lucent Failover DHCP configuration: A More Sophisticated Approach
to DHCP Server Redundancy
4 Considerations when implementing the Alcatel-Lucent Failover DHCP configuration
4 Summary
3Alcatel-Lucent | Implementing DHCP Redundancy to Sustain Critical Operations 1Alcatel-Lucent | Implementing DHCP Redundancy to Sustain Critical Operations
Introduction
IP network administrators are understandably concerned with providing redundancy in the event
of the failure or inaccessibility of their frontline Dynamic Host Configuration Protocol (DHCP)
servers. Using a single DHCP server to manage access to an IP network runs the risk that end users
will be denied access to the network when the DHCP server is down or unreachable. When denied
access, end users will be quick to report their dissatisfaction and lost productivity to those
concerned. Consequently, IP administrators must implement some form of redundant DHCP
server configuration. This paper compares two approaches to providing redundancy—the Split-Scopes
and the Alcatel-Lucent Failover DHCP methods.
Understanding Split-Scopes
The Split-Scopes configuration generally uses two DHCP servers. Each server maintains one segment
of the entire scope of IP addresses for each managed subnet. The segment on the first DHCP server
must be separate, distinct and may not overlap the segment maintained on the other DHCP server.
Both servers receive Discover packets from clients, and both will offer those clients IP addresses
if available. In a Split-Scopes configuration, each server responding to a client’s Discover packet
competes to reach the client with an Offer. Generally, the client will accept the first Offer it receives
that contains all of its desired options. When it receives a viable Offer, the client issues a Request
to the appropriate server as a broadcast, thereby notifying each server of its choice. The appropriate
server then sends an Acknowledge packet back to the client, allowing the client to initialize TCP/IP
and access the network. Consequently, network proximity generally determines which server will
be the frontline DHCP server and which the redundant server.
The Split-Scopes configuration provides proven redundancy protection
The benefits of Split-Scopes redundancy are straightforward. First, it is a proven approach that
has been successfully implemented in many client-server environments. Second, it provides
redundancy in the event of hardware, software and partial network outages. Since the DHCP
servers in a Split-Scopes configuration operate completely independently of one another, there
is no replication or communication needed between them.
Wasted IP addresses, uncertainty about primary and redundant server assignments, and additional
network traffic all complicate DHCP management in the Split-Scopes configuration
The redundancy protection in the Split-Scopes configuration comes at a price. The configuration:
• Systematically wastes IP addresses by requiring IP network administrators to assign a
separate and distinct set of IP addresses to the redundant DHCP server that may never be
used to support services
• Prevents administrators from guaranteeing which DHCP server acts as the frontline server,
and which is the backup system
• Increases network traffic by allowing both servers to compete to offer IP addresses to clients
First, the Split-Scopes configuration requires customers to waste a portion of their scope of IP
addresses. Because the IP address segments on each server cannot overlap, IP network administrators
must assign the redundant server a segment of addresses that will only be used if and when the
frontline DHCP server fails. The intended frontline server cannot offer clients IP addresses from
the segment on the redundant server. IP network administrators will not always have to provide
a 50-50 split of addresses between the intended frontline and redundant servers. Instead, IP
network administrators can determine the appropriate split based on estimates involving the
4 Alcatel-Lucent | Implementing DHCP Redundancy to Sustain Critical Operations2
l
ease duration and maximum downtime for the frontline DHCP server and a variety of network
c
omponents. Still, any split used will involve setting aside IP addresses for the redundant DHCP
server that will hopefully never be used to provide services.
Second, despite the estimated IP address split or the science behind that split, the Split-Scopes
configuration gives IP network administrators no way to guarantee which server will be the
frontline and which will be the redundant server at any given time. As mentioned earlier, both
servers operate independently. Both respond to client Discover requests with Offers for which it
has an address available. Any number of variables on a network can cause the redundant server’s
Offer to arrive before the intended frontline server’s Offer. Once the client obtains an address
from either server, it will issue a unicast Request to obtain a Renewal from the server that provided
the original lease, assuming that the server is available at the time. While not a major concern,
the inability to guarantee the identity of the frontline and redundant servers creates a degree of
uncertainty that complicates the troubleshooting process for any DHCP problems that may occur.
In some cases, IP network administrators will have to visit the client site to determine where
the client obtained its lease.
Finally, although a minor issue, one should also consider the additional network traffic in a Split-Scopes
configuration generated by the duplicate Offers flowing to the client from both DHCP servers.
The problems created by the wasted IP addresses, uncertainty, and network traffic issues are
compounded when one considers how an IP administrator handles manual DHCP and automatic
DHCP objects in a Split-Scopes configuration. A manual DHCP object is similar to a Lease
Reservation or Reserved Address in Microsoft terms, since the IP network administrator must
know and manually enter a given client’s MAC address into the DHCP database beforehand in
order for that client to obtain a lease. Automatic DHCP objects are similar to manual DHCP objects
in that clients will be granted an infinite lease without prior knowledge of the MAC address. In
this approach, the DHCP server obtains the MAC address from the Discover packet and then
forever associates that MAC address with a given client.
Implementing automatic DHCP objects in a Split-Scopes configuration requires IP network
administrators to consider several additional issues. First, do administrators create reservations
for automatic DHCP objects on both servers? And if not, what would prevent automatic DHCP
objects from obtaining a non-reserved address from the redundant server? Finally, with what
degree of certainty could IP network administrators prevent automatic DHCP objects from obtaining
a non-reserved IP address?
Administering Split-Scopes is clearly a duplicate effort scenario in an environment without a
centralized IP management tool such as the Alcatel-Lucent VitalQIP software. When implementing
changes to the IP address segment on one DHCP server, IP network administrators will have to
duplicate those changes in the IP address segment on the other DHCP server.
Split-Scopes and Alcatel-Lucent DHCP servers
Because the Alcatel-Lucent DHCP server offers the option to use either a Split-Scopes or Alcatel-Lucent
Failover DHCP redundancy configuration, IP network administrators who implement a Split-Scopes
configuration using Alcatel-Lucent DHCP servers need to be aware of a minor configuration detail.
By default, the server policy setting NakUnknownClients on the Alcatel-Lucent DHCP server will
be set to True or turned on. In other words, by default the Alcatel-Lucent server will send a NAK
to a client to request an address from the split of the scope for which the server is not configured.
In comparison, a Microsoft DHCP server would not send a NAK to the client in this situation.
5Alcatel-Lucent | Implementing DHCP Redundancy to Sustain Critical Operations 3
I
P administrators who implement Split-Scopes using Alcatel-Lucent DHCP servers should check their
N
akUnknownClients policy configuration
When implementing the Split-Scopes configuration on Alcatel-Lucent DHCP servers, IP network
administrators must set this policy to False or turned off. Otherwise, the server not configured
for the address in question will NAK Renewal Requests or Init Reboot Requests—causing the client
to issue a Discover packet and start the DHCP process all over again.
Understanding the Alcatel-Lucent Failover DHCP configuration
Unlike the Split-Scopes configuration, which cannot guarantee the relationship between the
intended frontline and redundant servers, the Alcatel-Lucent Failover DHCP configuration clearly
designates a Primary and a backup Failover server. Both the Primary and Failover servers manage
an identical set of IP addresses and receive all Discover traffic. In this configuration, the Primary
server is responsible for sending Offers and granting leases to clients. Although the Failover server
will prepare an Offer in response to a client Discover request, it will not send it out as long as
the Primary server is operational. After the Primary server successfully sends an ACK to complete
the DHCP process, it will send an update to the Failover server to synchronize the active lease
files on both servers.
In the Alcatel-Lucent Failover DHCP configuration, the Failover server polls the Primary server
periodically to insure that it is up and running. As long as the Primary server responds to the
Failover server’s polls, the Failover server will not provide an Offer to the client. However, if the
Primary server fails to answer a number of its polls, the Failover server will assume the Primary
server is down and will take responsibility for sending Offers and granting leases.
The Alcatel-Lucent Failover DHCP configuration: A More Sophisticated Approach
to DHCP Server Redundancy
The Alcatel-Lucent Failover DHCP configuration corrects many of the weaknesses of the
Split-Scopes configuration.
First, the Failover server is a true hot backup of the Primary server. Unlike the Split-Scopes
configuration, there is no need to maintain distinct IP address reserves on the two servers—
minimizing wasted IP addresses while providing true redundancy.
Second, the Alcatel-Lucent Failover DHCP configuration eliminates the considerations referenced
earlier regarding manual DHCP and automatic DHCP clients.
Third, although the polling between the Primary and Failover servers in this configuration generates
some network traffic, eliminating the duplicate Offer packets for each client Discover request
substantially reduces overall traffic levels.
Finally, implementing the Alcatel-Lucent Failover DHCP configuration using Alcatel-Lucent DHCP
servers and VitalQIP enables IP network administrators to virtually eliminate the duplicate
administrative efforts of a Split-Scopes configuration. Once the IP administrator creates the
Primary/Failover relationship in the VitalQIP GUI, he or she assigns all other configurable
items—from scope assignment to server policies and DHCP options—only to the Primary server.
After generating the file to the Primary server, Alcatel-Lucent VitalQIP software automatically
passes the configuration for these items to the Failover server. In an ideal situation, IP network
administrators will establish a one-to-one relationship between the Primary and Failover servers.
However, a distinct advantage of the Alcatel-Lucent Failover DHCP configuration is the ability to
www.alcatel-lucent.com
Alcatel, Lucent, Alcatel-Lucent and Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other
trademarks are the property of their respective owners. The information presented is subject to
change without notice. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein.
© 2007 Alcatel-Lucent. All rights reserved. 031960-00 Rev A 11/07
c
reate one-to-many configurations in which a single server is defined as the Failover server for
u
p to five Primary DHCP servers. Although they are theoretically possible, Alcatel-Lucent does not
recommend that IP administrators establish greater than one-to-five relationships.
Considerations when implementing the Alcatel-Lucent Failover DHCP configuration
When implementing a Alcatel-Lucent Failover DHCP configuration, IP network administrators
should keep two things in mind.
First, DHCP File Generation generally takes longer in a Alcatel-Lucent Failover DHCP configuration
than it does in a Split-Scopes configuration. As referenced earlier, the Failover server receives its
configuration files when a DHCP push is performed to the Primary server. In fact, the Failover
server is not available for pushes the DHCP file to the Primary server, it also pushes the file to
the Failover server. This configuration nuance primarily affects one-to-many configurations, because
the Failover server must receive updated configuration information for each Primary server every
time VitalQIP performs a DHCP File Generation to any of its Primary servers. By design, a DHCP
File Generation will fail if both the Primary and Failover servers are not available or reachable at
the time, as it is critical for their configurations to be identical.
Second, the Alcatel-Lucent Failover DHCP configuration requires reliable network communication
between the Primary and Failover servers. Obviously, this communication is required to synchronize
active lease information and to support the flow of updates from the Primary to the Failover server.
More importantly though, if network issues prevent the Primary server from receiving or responding
to the Failover server’s polls, the Failover server may assume that the Primary server has failed,
when in fact the Primary server is still operating. In that case, both the Failover and Primary
servers will hand out Offers to clients and grant leases. Should this occur, the two servers could
potentially hand out the same IP address to different clients until communication is resumed.
Once communication is resumed, the Primary and Failover servers will synchronize their active
lease files. In the event that a duplicate IP address assignment is found at that time, the Primary
server will assume that the Failover server is correct and will overwrite its own lease information.
When the duplicate client attempts a Renew or Init Reboot, the Primary server will NAK the duplicate
address—forcing the client to send a Discover request to obtain a new address.
Summary
Although Alcatel-Lucent DHCP servers support both the Split-Scopes and Alcatel-Lucent
Failover DHCP configurations, Alcatel-Lucent recommends that IP network administrators use
the Alcatel-Lucent Failover DHCP configuration to provide DHCP redundancy. All things considered,
the Alcatel-Lucent Failover DHCP configuration provides a more sophisticated solution to the
redundancy problem—correcting the IP address waste and the uncertainty about the primary
and backup role assignments that limit the utility of the Split-Scopes configuration. In the end,
it limits the risk of DHCP failure, maintains a key to access to an IP network, and helps maintain
end user satisfaction.
-
1
-
2
-
3
-
4
-
5
-
6
Alcatel DHCP server Technology White Paper
- Type
- Technology White Paper
Alcatel DHCP server is a powerful and versatile device that can be used to provide dynamic IP address assignment and configuration to devices on a network. It supports a wide range of features, including:
- DHCP failover: This feature ensures that clients can still obtain IP addresses even if the primary DHCP server fails.
- Split-scope: This feature allows you to divide your IP address pool into multiple scopes, each of which can be managed by a different DHCP server.
- Option 82: This feature allows you to pass additional information, such as the client's MAC address, to the DHCP server.
Ask a question and I''ll find the answer in the document
Finding information in a document is now easier with AI
Related papers
Other documents
-
Alcatel-Lucent VitalQIP 7.2 Product Description
-
-
-
-
-
-
Alcatel-Lucent IAP93 User guide
-
-
-