Article
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:
- Create a class using iManager or Java console. For Example: PXE
- Click modify class option and type the following in the conditional expression field:
match if option dhcp-client-identifier = null
iManager
Java Console
- Create 2 pools. Example: Pool1 and Pool2.
- Select any pool. Example: Pool1.
- Set the default lease time to double the time taken by the client to boot.
- Select the other Pool. Example: Pool2.
- Add the class PXE in the denied classes section of this pool.
(Server renews the leases after half the default-lease-time).
This achieves the following functionality:
- During PXE boot, Pool2 never leases any IP. So this pool remains intact to serve the normal (non pxe boot) clients.
- 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.
Related Articles
User Comments
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.
- Be the first to comment! To leave a comment you need to Login or Register
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.
- Be the first to comment! To leave a comment you need to Login or Register




2