Basically what I was saying is that the programmer would have to be extremely dumb in order to make software that would create a conflict. In which ever possible scenario, once an algorithm fills its variable with a value which seems good enough it stops, or should stop at this point. Even if it continued searching for a different DHCP server ( fail over ), due to the nature of the protocol, the new value retrieved from the second DHCP server would replace the the contents of the variable ( which was possibly undefined ). I doubt that anyone would set up a program using two variables to obtain an IP address( maybe microsoft with the purpose of bloating XP ). If for some weird reason two addresses would be retrieved from the DHCP servers, the first DCHP server would be short one IP address from its pool of IPs which should not be a problem.
This is purely theoretical, I do even setup DHCP usually becuase I like to do things the hard way. I do realize the importance of DHCP for large networks. :-) please be gentle when you flame this posting, I can already feel it Alvaro Zuniga On Friday 07 March 2003 08:06 am, Scott Harney wrote: > Alvaro Zuniga <[EMAIL PROTECTED]> writes: > > I do not know to much about this but if your are using different address > > pools like you have stated this is how is see it: > > > > In order to have a conflict the DHCP discovery algorithm would have to > > find a second instance of the DHCP server after finding the first one :-) > > Sounds like a Microsoftian Alnorythm. > > It's not as uncommon as you might think. I set up failover DHCP > servers when I was employed at Charter using Cisco's CNR. It's also > possible to do this with ISC dhcpd. You can also have two machines > handing out different pools. The main thing is each machine needs to > be aware of the other's pools and leases. As long as the dhcp client > gets a valid lease, it doesn't know or care about the multiple DHCP > servers on the subnet. > > Regarding the original poster's issues, I would turn off one of the > DHCP servers in his subnet. There's really no reason to have two > running in a small office environment and it will make problem > resolution really hard for him to diagnose.
