[syslinux] Network Boot IP Configuration Dilemma

[James Courtier-Dutton]

Fred Feirtag wrote:
> Background:  I recently wrote to Peter Anvin regarding IPAPPEND
> functionality, and he suggested I take the issue to this mailing list.
> I see it has been touched upon several times, after reviewing the
> archives.  Let me see if I can add to it with a good level of detail:
> 
> When using PXE to network boot a linux client, PXE must first
> acquire the client's IP address, by dhcp request, then, the downloaded
> linux kernel must get the IP address either from pxelinux, or by a
> "duplicate" dhcp request.
> 
> If the pxelinux.cfg "IPAPPEND 1" entry is used, an "ip=..." string is
> appended to the parameters passed to the kernel.  This is, as I will
> ultimately conclude below, a less problematic approach, however,
> it is in need of being extended to use the currently unused "device"
> parameter.
> 
> If the pxelinux.cfg "ip=::::::dhcp" entry is used, a dhcp request
> will be made by the kernel.
> 
> Discussion of the dilemma:
> 
> Under ideal circumstances, it makes no difference which approach
> is used.  In real world, problematic environments, it may make a very
> significant difference.  The first complicating factor is if more than
> one network interface is present.  When using the Tyan s2880 Opteron
> board, the two on-board interfaces can be turned both on or both off.
> It is impossible to use only one of them.  This discussion of
> potential problems should apply to any multi-homed netbooting system:
> 
> Line 1214 of ipconfig.c (2.4.22 kernel) contains "ic_first_dev->next,"
> which implements the objective of the comment on lines 1203-1206:
>   "If the config information is insufficient (e.g., ...or we have
>    multiple network interfaces and no default was set), use BOOTP
>    or RARP to get the missing values."
> So if there is more than one device found (the linked list contains
> more than a single element), the enumerated "ip=..." values are
> ignored and dynamic reconfiguration is attempted, and if dynamic
> prococals haven't been compiled into ipconfig, the network
> configuration simply fails.  This functionality is understandable,
> though I think its wisdom questionable.
> 
> I have been able to think of three situations where relevant problems
> may occur.
> 
> 1)  The second network interface, rather than the first, has
>     PXE active, and the dhcp issued IP address intended for the
>     second interface's identity is used by the first.
> 
> 2)  The BIOS ordering of the interfaces is different than the
>     kernel ordering, so even if the first BIOS located interface
>     makes the dhcp request, the kernel sees it as the second.
>     I have observed such a similar ordering problem with SCSI
>     interfaces, so the same possibility probably exists for network
>     interfaces.
> 
> 3)  A second DHCP server answers the request differently than
>     the first.  This is from my experience, the much more likely
>     and frequent problem.  Where different servers, possibly
>     unintentionally, are answering on the same network, one may
>     often answer first for the first request, and the other may
>     often answer first for subsequent requests, as the busier, but
>     faster system has dhcpd swapped in.
> 
> Using the two dhcp request approach may reduce problems #1 and #2.
> Using the single dhcp request approach reduces problem #3.
> Problems #1 and #2 are solid configuration errors with limited
> potential for trouble.  If a system is using an IP address on one
> interface that is intended for another of its interfaces, I consider
> this the lesser problem.  If, however, a system is intermittently
> failing to receive its correct IP address at differing stages of the
> boot process, it is a more difficult problem, less likely to be
> reported in a way that a system administrator can correctly diagnose it.
> 
I think my understanding of DHCP is a lot different to yours.
Maybe you should read the DHCP/BOOTP RFCs again.

Here is my understanding of the issue: -
NIC card sends it's own MAC address in the DHCP request.
The DHCP server replies with an IP address, and other info, e.g. default 
gateway, tftp server address for net booting etc.
The DHCP server will then link that IP address with that MAC address, 
until an expiry period set by the DHCP server.
If the NIC card sends out a DHCP request any time before the expiry 
period, it will reset the exiry period on the DHCP server, and the DHCP 
server guarantees to give it the same IP address again.
The NIC card can at any time send a DHCP release, whereby on the next 
DHCP request it might get any IP address in the range.
So, this guartees that the IP address the NIC card got during PXE boot, 
will be exactly the same as the IP address linux kernel dhcp will get.
It is also beneficial that the linux kernel re-does the request, because 
it might understand more of the reply items than PXE did.

This leaves (3), which will cause problems in any network, and should 
never happen, unless both servers lease tables can be perfectly 
syncronised. (3) will cause all sorts of problems when DHCP clients try 
to renew IP address before the expiry timer times out.

Cheers
James