Chapter 1 DHCP Overview
When configuring
ARP, go to these sections for information you are interested in:
l
Introduction to DHCP
l
DHCP Address Allocation
l
DHCP Message Format
l
DHCP Options
l
Protocols and Standards
The fast expansion and growing complexity
of networks result in scarce IP addresses assignable to hosts. Meanwhile, with
the wide application of wireless networks, the frequent movement of laptops across
networks requires that the IP addresses be changed accordingly. Therefore,
related configurations on hosts become more complex. Dynamic Host Configuration
Protocol (DHCP) was introduced to solve these problems.
DHCP is built on a client-server model, in
which the client sends a configuration request and then the server returns a
reply to send configuration parameters such as an IP address to the client.
A typical DHCP application, as shown in Figure 1-1, includes
a DHCP server and multiple clients (PCs and laptops).
Figure 1-1 A typical DHCP application
When residing in a different subnet from the DHCP server, the DHCP
client can get the IP address and other configuration parameters from the
server via a DHCP relay agent. For information about the DHCP relay agent,
refer to Introduction to DHCP
Relay Agent.
DHCP supports three mechanisms for IP
address allocation.
l
Manual allocation: The network administrator
assigns an IP address to a client like a WWW server, and DHCP conveys the
assigned address to the client.
l
Automatic allocation: DHCP assigns a permanent
IP address to a client.
l
Dynamic allocation: DHCP assigns an IP address
to a client for a limited period of time, which is called a lease. Most clients
obtain their addresses in this way.
1.2.2 Dynamic IP Address Allocation Process
Figure
1-2 Dynamic IP address allocation process
As shown in the figure above, a DHCP client
obtains an IP address from a DHCP server via four steps:
1)
The client broadcasts a DHCP-DISCOVER message to
locate a DHCP server.
2)
A DHCP server offers configuration parameters
such as an IP address to the client in a DHCP-OFFER message. The sending mode
of the DHCP-OFFER is determined by the flag field in the DHCP-DISCOVER message.
Refer to DHCP Message
Format for related information.
3)
If several DHCP servers send offers to the
client, the client accepts the first received offer, and broadcasts it in a
DHCP-REQUEST message to formally request the IP address.
4)
All DHCP servers receive the DHCP-REQUEST
message, but only the server to which the client sent a formal request for the
offered IP address returns a DHCP-ACK message to the client, confirming that
the IP address has been allocated to the client, or returns a DHCP-NAK unicast
message, denying the IP address allocation.
l
After the client receives the DHCP-ACK message,
it will probe whether the IP address assigned by the server is in use by
broadcasting a gratuitous ARP packet. If the client receives no response within
specified time, the client can use this IP address. Otherwise, the client sends
a DHCP-DECLINE message to the server to request an IP address again.
l
If there are multiple DHCP servers, IP addresses
offered by other DHCP servers are assignable to other clients.
The IP address dynamically allocated by a
DHCP server to a client has a lease. After the lease duration elapses, the IP
address will be reclaimed by the DHCP server. If the client wants to use the IP
address again, it has to extend the lease duration.
After the half lease duration elapses, the
DHCP client will send the DHCP server a DHCP-REQUEST unicast message to extend
the lease duration. Upon availability of the IP address, the DHCP server
returns a DHCP-ACK unicast confirming that the client’s lease duration
has been extended, or a DHCP-NAK unicast denying the request.
If the client receives the DHCP-NAK
message, it will broadcast another DHCP-REQUEST message for lease extension
after 7/8 lease duration elapses. The DHCP server will handle the request as
above mentioned.
Figure 1-3 gives the DHCP
message format, which is based on the BOOTP message format and involves eight
types. These types of messages have the same format except that some fields
have different values. The numbers in parentheses indicate the size of each
field in bytes.
Figure 1-3 DHCP message format
l
op: Message type defined in option field. 1 =
REQUEST, 2 = REPLY
l
htype,hlen: Hardware address type and length of
a DHCP client.
l
hops: Number of relay agents a request message
traveled.
l
xid: Transaction ID, a random number chosen by
the client to identify an IP address allocation.
l
secs: Filled in by the client, the number of
seconds elapsed since the client began address acquisition or renewal process.
Currently this field is reserved and set to 0.
l
flags: The leftmost bit is defined as the
BROADCAST (B) flag. If this flag is set to 0, the DHCP server sent a reply back
by unicast; if this flag is set to 1, the DHCP server sent a reply back by
broadcast. The remaining bits of the flags field are reserved for future use.
l
ciaddr: Client IP address.
l
yiaddr: 'your' (client) IP address, assigned by
the server.
l
siaddr: Server IP address, from which the
clients obtained configuration parameters.
l
giaddr: The first relay agent IP address a
request message traveled.
l
chaddr: Client hardware address.
l
sname: The server host name, from which the
client obtained configuration parameters.
l
file: Bootfile name and routing information,
defined by the server to the client.
l
options: Optional parameters field that is
variable in length, which includes the message type, lease, DNS IP address,
WINS IP address and so forth.
The DHCP message adopts the same format as
the Bootstrap Protocol (BOOTP) message for compatibility, but differs from it
in the option field, which identifies new features for DHCP.
DHCP uses the option field in DHCP messages
to carry control information and network configuration parameters, implementing
dynamic address allocation and providing more network configuration information
for clients.
Figure 1-4 shows the DHCP option format.
Figure 1-4 DHCP option format
The common DHCP options are:
l
Option 6: DNS server option. It specifies the
DNS server IP address to be assigned to the client.
l
Option 51: IP address lease option.
l
Option 53: DHCP message type option. It identifies the type of the DHCP message.
l
Option 55: Parameter request list option. It is
used by a DHCP client to request specified configuration parameters. The option
contains values that correspond to the parameters requested by the client.
l
Option 66: TFTP server name option. It specifies
a TFTP server to be assigned to the client.
l
Option 67: Bootfile name option. It specifies the
bootfile name to be assigned to the client.
l
Option 150: TFTP server IP address option. It
specifies the TFTP server IP address to be assigned to the client.
For more information about DHCP options,
refer to RFC 2132.
Some options have no unified definitions in
RFC 2132. The formats of some self-defined options are introduced as follows.
Option 82 is the relay agent option in the
option field of the DHCP message. It records the location information of the
DHCP client. When a DHCP relay agent receives a client’s request, it adds
Option 82 to the request message and sends it to the server.
The administrator can locate the DHCP
client to further implement security control and accounting. The Option 82 supporting
server can also use such information to define individual assignment policies
of IP address and other parameters for the clients.
Option 82 involves at most 255 sub-options.
At least one sub-option must be defined. Now the DHCP relay agent supports two
sub-options: sub-option 1 (Circuit ID) and sub-option 2 (Remote ID).
Option 82 has no unified definition. Its
padding formats vary with vendors. Currently the device supports two padding
formats: normal and verbose.
1)
Normal padding format
The padding contents for sub-options in the
normal padding format are:
l
sub-option 1: Padded with the VLAN ID and number
of the port that received the client’s request. The following figure
gives its format. The value of the sub-option type is 1, and that of the
circuit ID type is 0.
Figure
1-5 Sub-option 1 in normal padding format
l
sub-option 2: Padded with the MAC address of the
interface that received the client’s request. The following figure gives
its format. The value of the sub-option type is 2, and that of the remote ID
type is 0.
Figure 1-6 Sub-option 2 in normal
padding format
2)
Verbose padding format:
The padding contents for sub-options in the
verbose padding format are:
l
sub-option 1: Padded with the user-specified
access node identifier (ID of the device that adds Option 82 in DHCP messages),
and type, number, and VLAN ID of the port that received the client’s
request. Its format is shown in the following figure.
Figure
1-7 Sub-option 1 in verbose padding format
In the above
figure, except that the VLAN ID field has a fixed length of 2 bytes, all the
other padding contents of sub-option 1 are length variable.
l
sub-option 2: Padded with the MAC address of the
interface that received the client’s request. It has the same format as
that in normal padding format, as shown in Figure 1-6.
Option 184 is a reserved option, and
parameters in the option can be defined as needed. The device supports Option
184 carrying the voice related parameters, so a DHCP client with voice
functions can get an IP address along with specified voice parameters from the
DHCP server.
Option 184 involves the following
sub-options:
l
Sub-option 1: IP address of the primary network
calling processor, which is a server serving as the network calling control
source and providing program downloads.
l
Sub-option 2: IP address of the backup network
calling processor that DHCP clients will contact when the primary one is
unreachable.
l
Sub-option 3: Voice VLAN ID and the result
whether DHCP clients take this ID as the voice VLAN or not.
l
Sub-option 4: Failover route that specifies the
destination IP address and the called number (SIP users use such IP addresses
and numbers to communicate with each other) that a SIP user uses to reach
another SIP user when both the primary and backup calling processors are
unreachable.
You must define the
sub-option 1 to make other sub-options take effect.
l
RFC2131: Dynamic Host Configuration Protocol
l
RFC2132: DHCP Options and BOOTP Vendor
Extensions
l
RFC1542: Clarifications and Extensions for the
Bootstrap Protocol
l
RFC 3046: DHCP Relay Agent Information Option
Chapter 2 DHCP Relay Agent Configuration
When configuring the DHCP relay agent, go
to these sections for information you are interested in:
l
Introduction
to DHCP Relay Agent
l
Configuration
Task List
l
Configuring
the DHCP Relay Agent
l
Displaying
and Maintaining DHCP Relay Agent Configuration
l
DHCP
Relay Agent Configuration Example
l
Troubleshooting
DHCP Relay Agent Configuration
l
The DHCP relay agent configuration is supported
only VLAN interfaces.
l
DHCP Snooping must be disabled on the DHCP relay
agent.
2.1 Introduction to DHCP Relay Agent
Since DHCP clients request IP addresses via
broadcast messages, the DHCP server and clients must be on the same subnet.
Therefore, a DHCP server must be available on each subnet. It is not practical.
DHCP relay agent solves the problem. Via a
relay agent, DHCP clients communicate with a DHCP server on another subnet to
obtain configuration parameters. Thus, DHCP clients on different subnets can
contact the same DHCP server for ease of centralized management and cost
reduction.
Figure 2-1 shows a typical application of the DHCP relay agent.
Figure 2-1 DHCP relay agent application
No matter whether a relay agent exists or
not, the DHCP server and client interact with each other in a similar way (see
section Dynamic IP Address
Allocation Process). The following describes the
forwarding process on the DHCP relay agent.
Figure
2-2 DHCP relay agent work process
As shown in the figure above, the DHCP
relay agent works as follows:
1)
After receiving a DHCP-DISCOVER or DHCP-REQUEST
broadcast message from a DHCP client, the DHCP relay agent fills the giaddr
field of the message with its IP address and forwards the message to the
designated DHCP server in unicast mode.
2)
Based on the giaddr field, the DHCP server
returns an IP address and other configuration parameters to the relay agent,
which conveys them to the client.
Option 82 records the location information
of the DHCP client. The administrator can locate the DHCP client to further
implement security control and accounting. For more information, refer to Relay agent option (Option 82).
If the DHCP relay agent supports Option 82,
it will handle a client’s request according to the contents defined in
Option 82, if any. The handling strategies are described in the table below.
If a reply returned by the DHCP server
contains Option 82, the DHCP relay agent will remove the Option 82 before
forwarding the reply to the client.
|
If a client’s requesting
message has…
|
Handling strategy
|
Padding format
|
The DHCP relay agent will…
|
|
Option 82
|
Drop
|
Random
|
Drop the message.
|
|
Keep
|
Random
|
Forward the message without changing
Option 82.
|
|
Replace
|
normal
|
Forward the message after replacing the
original Option 82 with the Option 82 padded in normal format.
|
|
verbose
|
Forward the message after replacing the
original Option 82 with the Option 82 padded in verbose format.
|
|
no Option
82
|
—
|
normal
|
Forward
the message after adding the Option 82 padded in normal format.
|
|
—
|
verbose
|
Forward
the message after adding the Option 82 padded in verbose format.
|
2.2 Configuration Task List
Complete the following tasks to configure
the DHCP relay agent:
2.3.1 Enabling DHCP
Enable DHCP before performing other
DHCP-related configurations.
Follow these steps to enable DHCP:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enable DHCP
|
dhcp enable
|
Required
Disabled by default.
|
With this task completed, upon receiving a
DHCP request from the enabled interface, the relay agent will forward the
request to a DHCP server for address allocation.
Follow these steps to enable the DHCP relay
agent on an interface:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter interface view
|
Interface interface-type interface-number
|
—
|
|
Enable the DHCP relay agent on the
current interface
|
dhcp select relay
|
Required
With DHCP enabled, interfaces work in the
DHCP server mode.
|
If the DHCP client
obtains an IP address via the DHCP relay agent, the address pool of the subnet
which the IP address of the DHCP relay agent belongs to must be configured on
the DHCP server. Otherwise, the DHCP client cannot obtain a correct IP address.
2.3.3 Correlating a DHCP Server Group with
a Relay Agent Interface
To improve reliability, you can specify
several DHCP servers as a group on the DHCP relay agent and correlate a relay
agent interface with the server group. When the interface receives requesting
messages from clients, the relay agent will forward them to all the DHCP
servers of the group.
Follow these steps to correlate a DHCP
server group with a relay agent interface:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Create a
DHCP server group and add a server into the group
|
dhcp
relay server-group group-id ip ip-address
|
Required
Not
created by default.
|
|
Enter
interface view
|
interface interface-type interface-number
|
—
|
|
Correlate
the DHCP server group with the current interface
|
dhcp
relay server-select group-id
|
Required
By
default, no interface is correlated with any DHCP server group.
|
l
You can specify at most twenty DHCP server
groups on the relay agent and at most eight DHCP server addresses for each DHCP
server group.
l
The IP addresses of DHCP servers and those of
relay agent’s interfaces cannot be on the same subnet. Otherwise, the
client cannot obtain an IP address.
l
A DHCP server group can correlate with one or
multiple DHCP relay agent interfaces, while a relay agent interface can only
correlate with one DHCP server group. Using the dhcp relay server-select
command repeatedly overwrites the previous configuration. However, if the
specified DHCP server group does not exist, the interface still uses the
previous correlation.
l
The group-id in the dhcp relay
server-select command was specified by the dhcp relay server-group
command.
2.3.4 Configuring the DHCP Relay Agent to
Send a DHCP-Release Request
Sometimes, you need to release a
client’s IP address manually on the DHCP relay agent. With this task
completed, the DHCP relay agent can actively send a DHCP-RELEASE request that
contains the client’s IP address to be released. Upon receiving the DHCP-RELEASE
request, the DHCP server then releases the IP address for the client.
Follow these steps to configure the DHCP
relay agent in system view to send a DHCP-RELEASE request:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Configure
the DHCP relay agent to send a DHCP-RELEASE request
|
dhcp
relay release ip client-ip
|
Required
|
2.3.5 Configuring the DHCP Relay Agent
Security Functions
I. Creating static bindings and
enabling IP address check
The DHCP relay agent can dynamically record
clients’ IP-to-MAC bindings after clients get IP addresses. It also
supports static bindings, which means you can manually configure IP-to-MAC
bindings on the DHCP relay agent, so that users can access external network
using fixed IP addresses.
For avoidance of invalid IP address
configuration, you can configure the DHCP relay agent to check whether a
requesting client’s IP and MAC addresses match a binding on it (both
dynamic and static bindings). If not, the client cannot access outside networks
via the DHCP relay agent.
Follow these steps to create a static
binding and enable IP address check:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Create a static binding
|
dhcp relay security static ip-address mac-address [ interface
interface-type interface-number ]
|
Optional
No static binding is created by default.
|
|
Enter interface view
|
interface interface-type
interface-number
|
—
|
|
Enable invalid IP address check
|
dhcp relay address-check { disable | enable }
|
Required
Disabled by default.
|
l
The dhcp relay address-check enable command
is independent of other commands of the DHCP relay agent. That is, the invalid
address check takes effect when this command is executed, regardless of whether
other commands are used.
l
You are recommended to configure IP address
check on the interface enabled with the DHCP relay agent; otherwise, the valid
DHCP clients may not be capable of accessing networks.
l
When using the dhcp relay security static
command to bind a VLAN interface to a static binding entry, make sure that the
VLAN interface is configured as a DHCP relay agent; otherwise, address entry
conflicts may occur.
II. Configuring dynamic binding
update interval
Via the DHCP relay agent, a DHCP client
sends a DHCP-RELEASE unicast message to the DHCP server to relinquish its IP
address. In this case the DHCP relay agent simply conveys the message to the
DHCP server, thus it does not remove the IP address from its bindings. To solve
this, the DHCP relay agent can update dynamic bindings at a specified interval.
The DHCP relay agent uses the IP address of
a client and the MAC address of the DHCP relay interface to regularly send a
DHCP-REQUEST message to the DHCP server.
l
If the server returns a DHCP-ACK message or does
not return any message within a specified interval, which means the IP address
is assignable now, the DHCP relay agent will update its bindings by aging out
the binding entry of the IP address.
l
If the server returns a DHCP-NAK message, which
means the IP address is still in use, the relay agent will not age it out.
Follow these steps to configure dynamic
binding update interval:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Configure binding update interval
|
dhcp relay security tracker { interval | auto }
|
Optional
auto by
default. (auto interval is calculated by the relay agent according to
the number of bindings.)
|
III. Enabling unauthorized DHCP
servers detection
There are unauthorized DHCP servers on
networks, which reply DHCP clients with wrong IP addresses.
With this feature enabled, upon receiving a
DHCP request, the DHCP relay agent will record the IP address of the DHCP
server which assigned an IP address to the DHCP client and the receiving
interface. The administrator can use this information to check out any DHCP
unauthorized servers.
Follow these steps to enable unauthorized
DHCP server detection:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enable unauthorized DHCP server detection
|
dhcp relay server-detect
|
Required
Disabled by default.
|
With the
unauthorized DHCP server detection enabled, the device puts a record once for
each DHCP server. The administrator needs to find unauthorized DHCP servers
from the log information. After the recorded information of a DHCP server is
cleared, a new record will be put for the DHCP server.
I.
Prerequisites
You need to complete the following tasks
before configuring the DHCP relay agent to support Option 82.
l
Enabling DHCP
l
Enabling the DHCP relay agent on the specified
interface
l
Correlating a DHCP server group with relay agent
interfaces
II. Configuring the DHCP relay
agent to support Option 82
Follow these steps to configure the DHCP
relay agent to support Option 82:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter interface
view
|
interface interface-type
interface-number
|
—
|
|
Enable the relay agent to support Option
82
|
dhcp relay information enable
|
Required
Disabled by default.
|
|
Configure the handling strategy for
requesting messages containing Option 82
|
dhcp relay information strategy { drop | keep | replace }
|
Optional
replace by
default.
|
|
Configure the padding format for Option
82
|
dhcp relay information format { normal | verbose [ node-identifier { mac
| sysname | user-defined node-identifier } ] }
|
Optional
normal by
default.
|
l
To support Option 82, it is required to perform
related configuration on both the DHCP server and relay agent. Since the DHCP
server configuration varies with devices, it is not mentioned here.
l
If the handling strategy of the DHCP relay agent
is configured as replace, you need to configure a padding format for
Option 82. If the handling strategy is keep or drop, you need not
configure any padding format.
l
If sub-option 1 (node identifier) of Option 82
is padded with the device name (sysname) of a node, the device name must
contain no spaces. Otherwise, the DHCP relay agent will drop the message.
2.4 </
