[K12OSN] 2 DHCP Servers

[Robert Arkiletian]

Terrell, I also was concerned about this issue. However, I read this 

==========================================
The first part is Etherboot contains code that when it sends out a 
DHCPDISCOVER request, a tag containing a Vendor Class Identifier of 
"Etherboot" is sent out.  This allows the server to identify Etherboot 
clients and ignore all others.
...........
If you have a DHCP server already running for the subnet, you probably should 
specify that your additional ISC DHCPD server is not authoritative for the 
the subnet, or it will veto (NAK) existing client IP address allocations, 
upsetting the status quo. 
==========================================

here

http://www.etherboot.org/doc/html/userman/x126.html

According to this, the k12ltsp server should ignore OTHER ip requests. So 
today at work I tried this approach. 

1) I downloaded and copied new .zdsk image for my floppies from rom-o-matic 
but I enabled REQUIRE_VCI_ETHERBOOT in the options. 

2) I include the line 

not authoritative;

and 

option vendor-encapsulated-options 3c:09:45:74:68:65:72:62:6f:6f:74:ff;
#which stands for 9 bytes and hex code for "Etherboot"

in my dhcpd.conf file 

3) restarted dhcp service and all my clients got ip's from my k12ltsp server. 
None got ip's from the school. Hurray!!! However, all got stuck at 

Running dhclient
mounting root filesystem: /opt/ltsp/i386 from: 192.168.0.254
 
and would NOT boot. 

So I disabled eth1 (ifdown eth1) and suddenly ALL clients booted perfectly. 
Hurray!!!!!!!!!!!!!!!!!!!!!!

Both eth1 and eth0 are plugged into the same hub (I too wish it was a switch, 
chuck). I'm not sure why eth1 makes such a difference. In any case once all 
the clients are booted up I (ifup eth1) and internet is back and all is well.

Just to make sure that the other windows boxes in the school (connected to the 
same hub) were not affected. I tracked them down and rebooted them (cold 
boot) while my dhcp was up and NONE of them got an ip from my server. Another 
Hurray!!! Seems like the "Etherboot" check worked for both server and client.

Wondering if anyone knows what's up with eth1 issue?

Robert Arkiletian
Eric Hamber Secondary
 

On Monday 17 May 2004 4:34 am, Terrell Prude', Jr. wrote:
> But then we've got to make sure that the standalone workstations
> (Windows, Mac, whatever) don't respond to the K12LTSP server's DHCP
> server. That's the bigger problem. The K12LTSP clients may not respond
> to the pre-existing (Windows-based) DHCP server, but the existing LAN
> workstations will happily respond to the K12LTSP server's DHCP server,
> and that can cause major problems without involving the IT staff of the
> school.
>