Commit 22bcb060 authored by Marcin Siodelski's avatar Marcin Siodelski

[master] Merge branch 'trac3740'

parents 70be0aad 080e5f3c
......@@ -570,6 +570,58 @@ temporarily override a list of interface names and listen on all interfaces.
</note>
</section>
<section id="dhcpinform-unicast-issues">
<title>Issues with unicast responses to DHCPINFORM</title>
<para>The use of UDP sockets has certain benefits in deployments
where the server receives only relayed traffic. These benefits are
mentioned in the <xref linkend="dhcp4-interface-configuration"/>. From
the administrator's perspective it is often desired to be able to
configure the system's firewall to filter out the unwanted traffic, and
the use of UDP sockets faciliates it. However, the administrator must
also be aware of the implications related to filtering certain types
of traffic as it may impair the DHCP server's operation.
</para>
<para>In this section we are focusing on the case when the server
receives the DHCPINFORM message from the client via a relay. According
to the <ulink url="http://tools.ietf.org/html/rfc2131">RFC 2131</ulink>,
the server should unicast the DHCPACK response to the address carried in
the 'ciaddr' field. When the UDP socket is in use, the DHCP server
relies on the low level functions of an operating system to build the
data link, IP and UDP layers of the outgoing message. Typically, the
OS will first use ARP to obtain the client's link layer address to be
inserted into the frame's header, if the address is not cached from
a previous transaction that the client had with the server.
When the ARP exchange is successful, the DHCP message can be unicast
to the client, using the obtained address.
</para>
<para>Some system administrators block ARP messages in their network,
which causes issues for the server when it responds to the
DHCPINFORM messages, because the server is unable to send the
DHCPACK if the preceding ARP communication fails. Since the OS is
entirely responsible for the ARP communication and then sending
the DHCP packet over the wire, the DHCP server has no means to
determine that the ARP exchange failed and the DHCP response message
was dropped. Thus, the server does not log any error messages when
the outgoing DHCP response is dropped. At the same time, all hooks
pertaining to the packet sending operation will be called, even
though the message never reaches its destination.
</para>
<para>Note that the issue described in this section is not observed
when the raw sockets are in use, because, in this case, the DHCP server
builds all the layers of the outgoing message on its own and does not
use ARP. Instead, it inserts the value carried in the 'chaddr' field
of the DHCPINFORM message into the link layer.
</para>
<para>Server administrators willing to support DHCPINFORM
messages via relays should not block ARP traffic in their
networks or should use raw sockets instead of UDP sockets.
</para>
</section>
<section id="ipv4-subnet-id">
<title>IPv4 Subnet Identifier</title>
<para>
......
......@@ -427,13 +427,26 @@ respectively. The remaining arguments specify the source IPv4 address,
destination IPv4 address and the name of the interface on which the
message has been received.
% DHCP4_PACKET_SEND %1: sending packet %2 (type %3) from %4:%5 to %6:%7 on interface %8
This debug message is issued when the server is sending the response to
the client. The arguments specify the client identification information
(HW address and client identifier), DHCP message name and type, source
IPv4 address and port, destination IPv4 address and port and the
% DHCP4_PACKET_SEND %1: trying to send packet %2 (type %3) from %4:%5 to %6:%7 on interface %8
The arguments specify the client identification information (HW address
and client identifier), DHCP message name and type, source IPv4
address and port, destination IPv4 address and port and the
interface name.
This debug message is issued when the server is trying to send the
response to the client. When the server is using an UDP socket
to send the packet there are cases when this operation may be
unsuccessful and no error message will be displayed. One such situation
occurs when the server is unicasting the response to the 'ciaddr' of
a DHCPINFORM message. This often requires broadcasting an ARP
message to obtain the link layer address of the unicast destination.
If broadcast ARP messages are blocked in the network, according to
the firewall policy, the ARP message will not cause a response.
Consequently, the response to the DHCPINFORM will not be sent.
Since the ARP communication is under the OS control, Kea is not
notified about the drop of the packet which it is trying to send
and it has no means to display an error message.
% DHCP4_PACKET_SEND_FAIL %1: failed to send DHCPv4 packet: %2
This error is output if the DHCPv4 server fails to send an assembled
DHCP message to a client. The first argument includes the client and
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment