Hi everyone,
Thanks very much for all of the advice. I've made a significant step
forward in figuring out what the heck is going on, but I still don't
know why.
Despite the fact that I'm using identical versions of ISC dhcpd (down
to the md5 checksum of the binary) and identical configurations, the
difference is that the misbehaving server is NOT setting the
"next-server" and "boot file name" flags in the DHCP OFFER packet.
Fortunately, this narrows down the possibilities quite a bit. It is
absolutely a problem with that particular machine and/or the software
on it, not in the network or on the client machine.
I am currently trying to narrow down what the differences are between
those machines. Here's what they have in common:
Identically configured and installed CentOS 5.5 virtual machines being
hosted on identically configured ESXi hosts (version 4.1.0, 260247).
Fully updated with the CentOS repositories
Identical configuration files, with only the network and MAC addresses
changed to reflect the different sites
I have already removed and reinstalled the dhcp package, however I am
in the middle of building another VM to perform the same services. If
this works, I will assume that the original problem was due to solar
flares reflecting from the swamp gas on Venus. Assuming it doesn't
work, I'm going to be copying the VM image from the site that works
and trying it with the other netblocks. If that works, I may cry. If
it doesn't, I suppose the only thing left is to dive into the source
RPMs for dhcpd and figure out where the bug lies. I sincerely hope
that I don't have to get anywhere near that far in.
Thanks again, everyone. I really appreciate all of the help and
suggestions. It's always great to get new ways to look at a problem.
--Matt
On Mon, Nov 29, 2010 at 4:44 PM, Matt Simmons
<standalone.sysad...@gmail.com> wrote:
> Hi everyone...I've got a problem with dhcpd, and I'm tearing my hair out.
>
> I'm building a machine that can be reinstalled automagically using a
> combination of PXEboot, kickstart, and magic. I've already done this
> once, and it worked great. I copied the exact configuration files,
> installed the same services, and basically tried my best to port the
> process to another network, and I'm failing miserably.
>
> I've got 2 VMware ESXi hosts on the same vSwitch, one of which is the
> server, running CentOS 5.5, ISC dhcpd 3.0.5-RedHat, and has tftpd
> started in xinetd. The client has no OS installed, and is configured
> to boot with PXE.
>
> My dhcpd config file is as follows:
>
> ---
> ddns-update-style interim;
>
> subnet 10.x.1.0 netmask 255.255.255.0 {
>
> option routers 10.x.1.1;
> option subnet-mask 255.255.255.0;
> option domain-name "mydomain";
> option domain-name-servers 10.x.1.43;
> option time-offset -18000;
> range dynamic-bootp 10.x.1.95 10.x.1.96;
> default-lease-time 21600;
> max-lease-time 43200;
>
> group {
> next-server 10.x.1.91;
> filename "pxelinux.0";
>
> host ops1tp {
> hardware ethernet 00:0c:29:2d:ea:5a;
> #hardware ethernet 00:0c:29:05:6a:82;
> fixed-address 10.x.1.94;
> }
> }
> }
> ---EOF---
>
>
> When the client boots, I immediately get:
>
> ---
> Network boot from Intel E1000
> Copyright (C) 2003-2008 VMware, Inc.
> Copyright (C) 1997-2000 Intel Corporation
>
> CLIENT MAC ADDR: 00 0C 29 2D EA 5A GUID: 564D48EF-5B1F-A4A3-C0A6-2493F02DEA5A
> DHCP...|
> ---
>
> The pipe at the end of the DHCP line is a spinner, and the dots slowly
> increase in number while the spinner goes.
>
> At the same time, on the server, I get the following log entries in
> /var/log/messages:
>
> Nov 29 16:29:55 kickstart-host dhcpd: DHCPDISCOVER from
> 00:0c:29:2d:ea:5a via eth0
> Nov 29 16:29:55 kickstart-host dhcpd: DHCPOFFER on 10.x.1.94 to
> 00:0c:29:2d:ea:5a via eth0
>
> Then 2 seconds later, I get these entries:
> Nov 29 16:29:57 kickstart-host dhcpd: DHCPREQUEST for 10.x.1.94
> (10.x.1.91) from 00:0c:29:2d:ea:5a via eth0
> Nov 29 16:29:57 kickstart-host dhcpd: DHCPACK on 10.x.1.94 to
> 00:0c:29:2d:ea:5a via eth0
>
> Those 4 lines cycle a total of 4 times, after which, the client
> console replaces the last "DHCP..." line with:
>
> CLIENT IP: 10.x.1.94 MASK: 255.255.255.0 DHCP IP: 10.x.1.91
> PXE-E55: ProxyDHCP service did not reply to request on port 4011.
>
> PXE-M0F: Exiting Intel PXE ROM.
> Operating System not found
> --
>
> Obviously, the server is seeing the request. Since the client
> eventually knows which IP it's supposed to have, it's receiving the
> DHCPOFFER. The problem appears to be that something in my DHCP
> configuration is making it expect a PXE server (listening on UDP port
> 4011) on the server (presumably 10.x.1.91, which is indeed the
> kickstart server).
>
> The oddity is that the configuration is identical to the configuration
> that I had at the other site.
>
> I'm pretty stuck at this point. Any advice you'd be willing to offer
> would be welcome.
>
> Thanks,
>
> --Matt
>
> --
> LITTLE GIRL: But which cookie will you eat FIRST?
> COOKIE MONSTER: Me think you have misconception of cookie-eating process.
>
--
LITTLE GIRL: But which cookie will you eat FIRST?
COOKIE MONSTER: Me think you have misconception of cookie-eating process.
_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
