37 replies to this topic

[Sami Lehtinen]

DHCP server works so badly, that I had to revert to old solution. Running two DHCP servers on same network, to get acceptable reliablity. Then everything works pretty well.

[patpat]

mmhh
which DHCP server is not working? Serva? or tftpd32?
have you used the combination of your regular infrastructure DHCP + Serva's proxyDHCP mode? that's my favorite setup for PXE.

[Sami Lehtinen]

Problem with serva32 is that now it assigns leases with 2 days duration. I tried to use option 51 to shorten lease, but it wasn't possible in this case.

I would really love to have an option in configuration screen to set lease duration.

We're using serva32 in pre-installation network, where 8-30 work stations are connected for short duration, when images are loaded.

Currently we do batch, and then restart serva32 to reset dhcp pool. I would prefer setting shorter lease-time.

Again, this is one of the things that's pretty easy to work around, but it's still pretty annoying, if all pre-installation batches aren't installed in synchronized way. Therefore I also added one network which allows to install non batch computers. I'm also running on main network alternate dhcp server, which assignes short duration leases for most of computers. Long duration leases are ony configured for computers which use TFTPD boot.

Trick to get alternate DHCP server as preferred server, was really to configure invalid gateway and dhcp (0.0.0.0) when using Serva. In this case tftp boot uses serva dhcp pool, to load ftpd boot stuff. When OS is running and does regular dhcp query, then we'll get regular short duration IP from another pool which also allows internet trraffic to flow, so installing updates etc is easier.

Now problem is that even if we have largest possible /24 pool for booting, it's not enough. Maybe I'll just configure /16 pool for booting. It would be pretty easy work-a-round too.

It's just wonderful when extremely simple stuff gets annoyingly challenging and complex.

Another super annoying issue is that if serva32 is restarted when some of images are still being done, IP collisions nicely aborts cloning process and systems need to be restarted. That's why it's very important to do complete batch at once and then restart serva32. If serva is being restarted during cloning, it will most propably lead to failure of cloning for systems still running.

So in this case, main issue is too long lease + dhcp collisions. (And this is naturally with your test version, which is work-a-round to that previously reported issue.)

Edited by Sami Lehtinen, 19 March 2012 - 07:44 AM.

[patpat]

dhcp duration can be adjusted by hand editing Serva.ini, not GUI.
the default is:
DHCP_Lease(minutes)=2880


"Another super annoying issue is that if serva32 is res...."
Serva can't know if a PXE session has finished or not...

"IP collisions nicely aborts.."
what ip collisions?

"test version"
enjoy it ;-) I think I won't include that mod into next versions.
did clonezilla people say anithing about this?

Edited by patpat, 19 March 2012 - 12:39 PM.

[Sami Lehtinen]

dhcp duration can be adjusted by hand editing Serva.ini, not GUI.
the default is:
DHCP_Lease(minutes)=2880

Excellent, it wasn't mentioned in documentation. Changed and working.

"Another super annoying issue is that if serva32 is res...."
Serva can't know if a PXE session has finished or not...

"IP collisions nicely aborts.."
what ip collisions?

Yes, this failure is caused by pool getting full. When server is reset, it reassigns IP addresses already being used by existing systems to new systems. Causing IP collision and therefore aborting existing clone processes. But as I said, this isn't problem if resets are done in carefully planned manner. All systems must be ready and then serva is reset and new systems attached to network. When I assign short enough lease time, I can get unused IP's to get released much quicker.

"test version"
enjoy it ;-) I think I won't include that mod into next versions.
did clonezilla people say anithing about this?

Nope, they claim that then it must be debian or ubuntu which is broken. But as I said, it might be best to use traditional dhcp server instead of serva or tftpd and prefer USB boot instead of network boot. Of course it isn't optimal solution. But with current production system and hardware there is also secondary problem with that. Because network card isn't fully supported and therefore network boot would hang with this model which we're currently delivering anyway.

Maybe we'll just waith 6 to 12 months, and try again if everything is working and issues got fixed somehow. It's quite common that when issue is found, someone has already reported it and it just takes a while to get fixed and fix delivered with new version. If that's not the case, it's quite probable, that issue is such that nobody cares to fix it anyway. I'll have a small talk with guys, if we decide to ditch troublesome PXE boot completely. I personally would prefer it working, but it sure isn't worth of all this trouble.

This turned out to be just like the case with Torrent client vs Torrent tracker which I told you about earlier. There's nothing wrong, it just isn't working. To be honest, this is quite common situation.

P.S. Thank you patpat, you have been great help.

[patpat]

- On an scenario that already has DCHP infrastructure you should always use proxyDHCP.

- your card not supporting PXE sure has some update that makes it work.

- Debian/Ubuntu PXE is not broken at least since 8.10, I've made Jeoss Linux (Ubuntu based) that is strongly
PXE oriented and the Debian/Ubuntu PXE client works perfectly. Then I do not understand what clonezilla people say...

[Sami Lehtinen]

- On an scenario that already has DCHP infrastructure you should always use proxyDHCP.

Of course I would prefer using only one dhcp server, in case it would be reliable enough. But reasons for this are also complex, as stated previously. When using firewalls DHCP we don't have problems what so ever. Except it won't deliver required PXE parameters.

- your card not supporting PXE sure has some update that makes it work.

Yes, that's one of the reasons why we retry this after some time.

- Debian/Ubuntu PXE is not broken at least since 8.10, I've made Jeoss Linux (Ubuntu based) that is strongly
PXE oriented and the Debian/Ubuntu PXE client works perfectly. Then I do not understand what clonezilla people say...

Yes, I didn't claim that Ubuntu / Debian itself would be broken. I tried both versions and those worked out exactly as expected.

At this point, we concluded that it's better to use USB boot. Then we can use reliable DHCP server and everything works smoothly. Only drawback is that you need to plugin USB-stick to boot Clonezilla to RAM. Pro is that you don't need to first boot computer to enable PXE and then reboot it from network. So in terms on time consumed these are in balance.

After summer vacation I'll recheck if situation has changed. If it's ok then, then I'll use tftpd service version.

- Thank you!

[patpat]

I dont quite get if you understand the "proxyDHCP" concept...
Do you know that you can use your firewall DHCP untouched + Serva on proxyDHCP mode just providing PXE info but no IP assignation/administration??

[Sami Lehtinen]

True. I haven't investigated it. I assume proxy does what it sounds like, so it forwards requests to another interface or so. But I'll read documentation about it.

Yet another option would be using two dhcp servers which another providex pxe info and another usable network info. In this case it's then up to clients logic to select reasonable option. It might work out well, or it might not work out at all. In that case DHCP lease from Serva would be used only for initla PXE load. Immediately after that another pool would be used for all the stuff after that. In that case dhcp lease time for pxe pool of 2 minutes should be more than enough. But this is also play, that might work or might not and would require much testing. And even if it works with one dhcp client, then we might have another dhcp client which doesn't work well with it. It could prefer pool with pxe information even if it doesn't have gateway and dns info. In theory this should work if dhcp clients are smart enough to select reasonable offer.

- Thanks

Edit: After checking out, it might solve all the IP related issues:

proxyDHCP Server - It turns the proxyDHCP on and off. During the proxyDHCP operation the service offers PXE information only. IP addresses and other DHCP related info has to be provided by a different DHCP server.

I assume this could solve the problems we have with PXE boot currently. I'll check out if it works as expected today. It doesn't clearly state if it requires separate interfaces, but I assume it's "supplementary" information. So this might be exactly what we need in this case.

I'll repost when I have checked it out.

Edited by Sami Lehtinen, 20 March 2012 - 09:41 AM.

[Sami Lehtinen]

Finally, I can conclude this issue "closed" using work-a-rounds.

1. DHCP issue between tftpd32, serva32 and clonezilla was "solved". Technicall it still remains. But we worked around it by using serva's proxydhcp option.

2. BiostarM BIOS PXE boot wasn't working. Now it's working with latest clonezilla alternate test version and latest pxelinux.0.

So for now, everything is working for me as we expect. Configuration isn't what I would like it to be. But it's working and perfectly acceptable.

Thank you for everyone. I hope that the DHCP issue where this discussion started gets fixed some day.

As said earlier more information about it can be found from this archive is someone is interested enough to take a look.

[patpat]

The term "proxyDHCP" many times leads to confusion; it really has nothing to do with the "HTTP proxy" concept you already have.

A net booting PC needs to gather basic network information as soon as it powers up:
1-IP address
2-Network mask
3-Default gateway
4-IP address of the TFTP server that hosts the bootstrap loader
5-Boostrap loader File Name

The first three items are regular DHCP parameters and the last two are the typical PXE DHCP extensions.
Serva is a DHCP server. But, what if we already have a working DHCP on our net? even worse; what if we have no access/permission to chage its configuration at all?
on that situation we use the already in-place DHCP and we run Serva on proxyDHCP mode just providing 4 & 5 to PXE clients...

[Sami Lehtinen]

Yes, I knew everything else you said. Except method of proxyDHCP technical functionality is still bit open. So does it listen for original dhcp offer, and adds supplementary information to it and resends it to network, or does it send / broadcast some kind of separate supplementary information packet. Of course I could find out this using packet capture. But very short description is better.

Afaik, gateway information isn't mandatory. There can be stand-a-lone network without gateway. Yes, I did confuse proxyDHCP with DHCP relay concept. I actually haven't ever heard proxyDHCP concept earlier, and I havent needed it in last 15 years. But it's always good to learn something new.

Edit: Serva.ini issue has been "solved" using another work-a-round.

I created new user account, and specified serva to be started at server startup using it as separate task. Now serva runs in background and I don't actually know if error message is "shown" or not. Because it isn't visible and because we aren't using serva as dhcp server anymore, I don't care if persistent leases are stored or not. So even that issue has been resolved. Now people using console do not accidentally close serva by clikcing ok, to that error message.

I also tried serva32 on two other machines, in startup. With those it worked without this issue. So I have to say, that it probably isn't worth of checking out what the real reason behind this is.

So wonderful, now everything is working as hoped, just after "little" tuning.

Edited by Sami Lehtinen, 20 March 2012 - 12:07 PM.

[patpat]

the proxyDHCP listen to DHCP dicovery packets and announces its presence aswering to discovery packets only from PXE clients.
When the client got its IP address there's a special transaction between the client and the proxyDHCP where the PXE information is supplied...
That transaction is unicast.