Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

PXE Clients unable to obtain IP address from DHCP server over a Relay


Author: Denis Jedig MVP

View products that this article applies to.

Symptoms

PXE clients are unable to configure�with an�IP address and�Remote Installation Services (RIS) will not work in certain DHCP/BOOTP relay configurations.

↑ Back to the top


Cause

If the "giaddr" (Gateway IP Address) field in the DHCP�REQUEST does not�match to the source IP address of the DHCP�REQUEST packet and the DHCP�REQUEST packet originates from a PXE client, the Microsoft DHCP server implementation issues an invalid DHCP�OFFER response.

↑ Back to the top


Resolution

A patch has been developed to address this problem, however, it is not yet publicly available. It is described in KB article 300034 and will be part of Windows Server 2003 Service Pack 1.
You can work around this problem by using Microsoft DHCP relays provided with the Routing and Remota Access Services (RRAS). The DHCP relays must not cascade in this case.

↑ Back to the top


More information

A DHCP request packet comes with various fields specifying flags, address information, client state and DHCP relays�it passed. BOOTP/DHCP relay operation is defined in RFC 1542. One of these fields, referenced�as "giaddr" (Gateway IP�address) in RFC�1542, indicates which subnet the DHCP request originated from by carrying the IP address of the BOOTP/DHCP relay interface which initially caught the request.

In most configurations, the giaddr field will�match the source IP address of the IP packet carrying the DHCP REQUEST, since this packet is�created�by the DHCP relay. However, some implementations of BOOTP/DHCP relays of third party router vendors are known to use the IP address configured for management in the "source IP address" of this packet, causing the two addresses not to match anymore. Furthermore, cascading BOOTP/DHCP relays (Relay1 forwarding requests to Relay2, which then is forwarding the request to a DHCP server) will result a mismatch in those fields.

If you look closer at such a datagram, it may look like this in your network analyzer with the highlighted fields differing.

Internet Protocol, Src Addr: 192.168.100.193 (192.168.100.193), Dst Addr: 192.168.100.10 (192.168.100.10)
User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67)
Bootstrap Protocol
��� Message type: Boot Request (1)
��� Client IP address: 0.0.0.0 (0.0.0.0)
��� Your (client) IP address: 0.0.0.0 (0.0.0.0)
��� Next server IP address: 0.0.0.0 (0.0.0.0)
��� Relay agent IP address (giaddr): 192.168.0.254 (192.168.0.254)

While this is perfectly in line with the requirements�for the DHCP and BOOTP protocols, Microsoft DHCP server implementation fails to respond to those DHCP REQUESTS correctly when they�originate from a PXE client and carry the "PXEClient" vendor extension field.

References:

RFC 1542 -�Clarifications�and�Extensions�for�the�Bootstrap�Protocol
RFC 2131 -�Dynamic�Host�Configuration�Protocol
MSKB 244036�Description of PXE Interaction Among PXE Client, DHCP, and RIS Server
MSKB 300034�PXE Clients May Discard All DHCP Offers Across Router

↑ Back to the top


Community solutions content disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the suitability, reliability, or accuracy of the information and related graphics contained herein. All such information and related graphics are provided "as is" without warranty of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this information and related graphics, including all implied warranties and conditions of merchantability, fitness for a particular purpose, workmanlike effort, title and non-infringement. You specifically agree that in no event shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental, special, consequential damages or any damages whatsoever including, without limitation, damages for loss of use, data or profits, arising out of or in any way connected with the use of or inability to use the information and related graphics contained herein, whether based on contract, tort, negligence, strict liability or otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of damages.

↑ Back to the top


Keywords: KB555228, kbhowto, kbpubmvp, kbpubtypecca

↑ Back to the top

Article Info
Article ID : 555228
Revision : 1
Created on : 2/22/2005
Published on : 2/22/2005
Exists online : False
Views : 395