Hello Gene,
You have asked very valid questions. Sorry, I have not clarified these aspects
in my initial email.
>How do you know that host A will be assigned a given IP?
we use something like this
host glab-56-25 {
hardware ethernet 00:0C:29:04:2F:28;
fixed-address glab-56-25;
}
In the DNS we have A record glab-56-25 -> 172.28.56.25
So, there is no way to stil IP address.
> Does it drop just a few pings (even for something as extreme as 30
> seconds) or does it never respond again?
Never
> I'd assume you've tried them individually with identical results?
> Stop DHCP server C, run test, start DHCP server C, stop DHCP server D
> and run the test again.
Frankly speaking NO, due to the fact that servers are idential. The same Linux,
the same dhcpcd, different host with same HW.
Nothing suspiciuos in the dhcpd logs.
Thanks, Oleg.
PS: I've attached screenshot with gPXE in the previous response in the
mailthread.
11.11.10, 14:43, "Gene Cumm" <gene.c...@gmail.com>:
> On Thu, Nov 11, 2010 at 02:53, Andrew Bobulsky wrote:
> > Hello Oleg,
> >
> > I can't say with any certainty what your problem is, but I have
> > personally had to deal with DHCP problems that were impossible to
> > solve without doing some packet capture.
> >
> > For the benefit of those who will likely read your email in the
> > morning, my only suggestion is that you load up Wireshark and capture
> > the traffic occurring during the test scenario you're describing.
> >
> > I've found that the cause of funny DHCP client behavior is usually
> > easy to pinpoint, even if it's not easy to fix.
> >
> > Cheers,
> > Andrew Bobulsky
>
> This is definitely a good idea. Capture all packets going to/from the
> machine that is using gPXE.
>
> > On Nov 11, 2010, at 2:32 AM, oleg-gumenyuk wrote:
> >
> >> Hello ALL!
> >>
> >> Historically our customer has got network where 2 DHCP servers are up and
> running for redundancy purpose. DHCPD config file is common for both servers.
> No issues if we boot down the wire WinPE, any Linux. We observe issue when
> gPXE is booted.
>
> I find it understandable that there are two as I have a similar
> situation at my work. As long as they don't try to assign the same IP
> to two different hosts, this is generally good. One way to prevent
> this issue is to configure them to hand out a different pool of IP
> addresses in the same subnet. Another is that the two must some how
> coordinate to prevent this issue (this coordination can be more
> complex and is DHCPD-specific).
>
> >> When gPXE requests IP address both DHCP servers send responces. The
> concequence of such behaviour is that gPXE lost network settings. We have
> localized problem to the following small scenario:
>
> This is a very nice small scenario.
>
> >> 1. boot to gPXE 1.0.1 on host A and enter to the interactive mode
> (Ctrl-B).
> >> 2. from another host B start pinging IP address which will be assigned to
> the host A
>
> How do you know that host A will be assigned a given IP? Is this a
> lease reservation configured in both servers? Is it a pre-existing
> unexpired lease that both servers are trying to use?
>
> >> 3. execute on Host A gPXE command: dhcp net0
> >> 4. ping from host B are successful.
> >> ...waiting a little bit about 5-7 secs ....
> >> Host A is not pingable.
>
> Does it drop just a few pings (even for something as extreme as 30
> seconds) or does it never respond again? Have you ensured that there
> are no new hosts that are attempting to obtain a new DHCP lease that
> might steal that IP?
>
> Have you tried running "route" (with no parameters) from gPXE just
> after running "dhcp net0" and after host A stops responding to pings?
> Make sure it says the same info both times. It should show something
> like:
>
> "net0: 10.0.0.6/255.255.255/0 gw 10.0.0.1"
>
> >> If we stop one of DHCP server such issue is eliminated.
>
> I'd assume you've tried them individually with identical results?
> Stop DHCP server C, run test, start DHCP server C, stop DHCP server D
> and run the test again.
>
> >> Question: is it a bug of gPXE? _or_ Is it a feature and our customer
> breaks some RFCs?
> >>
> >> Thanks, Oleg.
>
> Another idea is to also examine the logs of the DHCP servers. This
> may be easier to start doing than performing the packet capture as the
> packet capture may require some setup to get it to capture the
> relevant packets however analyzing the packet capture will probably
> reveal the issue quickly and more reliably.
>
>
_______________________________________________
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
