Article

Imagen de dshruthy
article
Reads:

%count lecturas

Score:
3.25
3.3
4
 
Comments:

2

Solution for Duplicate Address Assignment Problem in PXE Boot Workstations

Author Info

17 April 2009 - 1:33pm
Submitted by: dshruthy

(View Disclaimer)

Authors:
Shruthy Devendra
Sulabh Sharma

Usage of dhcpClass to overcome the duplicate address assignment problem in PXE boot workstations

The Preboot execution environment is an environment to boot computers using a network interface independently using the available data storage devices (like hard disks) or installed operating systems.

If the workstation is PXE boot, then it gets an address from the dhcp server. During the PXE boot, the client-identifier is not sent to the dhcp server. So the server creates a lease entry without the client-identifier value.

After the client loads up the operating system, the dhcp server again gives away the IP to the client. Thus for every single workstation, two IP addresses are offered. Hence, sometimes all the IP's get exhausted although effectively only half are being used.

To over come this, a solution is proposed as below:

  1. Create a class using iManager or Java console. For Example: PXE
  2. Click modify class option and type the following in the conditional expression field:
    match if option dhcp-client-identifier = null

    iManager

    Java Console

  3. Create 2 pools. Example: Pool1 and Pool2.
  4. Select any pool. Example: Pool1.
  5. Set the default lease time to double the time taken by the client to boot.
  6. (Server renews the leases after half the default-lease-time).

  7. Select the other Pool. Example: Pool2.
  8. Add the class PXE in the denied classes section of this pool.

This achieves the following functionality:

  1. During PXE boot, Pool2 never leases any IP. So this pool remains intact to serve the normal (non pxe boot) clients.
  2. Only Pool1 leases IPs during PXE boot and the lease expires soon after the client boots up. Hence these IPs are available soon.

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.




User Comments

Imagen de di6parn

Very useful, but

Submitted by di6parn on 20 January 2010 - 3:29am.

This was very useful for us. We did it a slightly different way though: created the class, but instead of creating or editing any pools, we edited the class itself to have the desired default-lease-time and max-lease-time. That way it applies to all of the pools.

Imagen de mrosen

Serious logic flaw.

Submitted by mrosen on 23 May 2011 - 7:58am.

Hi.

This solution unfortunately comes with a serious logic flaw, in that while it forces PXE clients to use the pool with the very short leasetime, at the same time it does nothing to stop windows client to *also* use this pool. E.G, it denies the PXE clients the usage of Pool2 here in this example, but it does *not* deny the other machines to use pool1, regardless if they have a client identifier or not.

The end result is that Windows workstations will also end up in the Pool1, with a very short leasetime, and almsot continously renew their IP address, which will end sooner or later in a serious mess in the net.

So in addition to the deny rule in pool2 for the class PXE, it also needs an exclusive allow rule for the class PXE in pool1 to stop regular windows clients to grab an IP from there.

© 2013 Novell