Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Maybe someone that knows more about DHCP and network that can help me out with this one. I've been thrown for a look with this for awhile now, so I'm reaching out to the ServerFault community.

We migrated a server out of our production datacenter as we are repurposing the system. In our local lab, I PXE booted the server into our environment and it PXE booted fine and loaded the image just fine. However, after loading the image, it couldn't download the kickstart. I noticed from the DHCP logs, it was trying to get a new IP address and couldn't. What it seems to look like is, it PXE boots using a local PXE/DHCP server and then once it loads up and then tries to DHCP again, it reaches out to a random server outside our lab environment. Here are the DHCP logs:

dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 via
dhcpd: DHCPOFFER on to 00:11:22:33:44:55 via
dhcpd: DHCPREQUEST for ( from 00:11:22:33:44:55 via
dhcpd: DHCPACK on to 00:11:22:33:44:55 via
xinetd[3010]: START: tftp pid=26359 from=
in.tftpd[26360]: RRQ from filename /pxelinux.0
in.tftpd[26360]: tftp: client does not accept options
in.tftpd[26361]: RRQ from filename /pxelinux.0
in.tftpd[26362]: RRQ from filename /pxelinux.cfg/44454c4c-5800-104e-8057-b9c04f4b4e31
in.tftpd[26363]: RRQ from filename /pxelinux.cfg/01-00-11-22-33-44-55
in.tftpd[26364]: RRQ from filename //images/RHEL-6.4-x86_64/vmlinuz
in.tftpd[26365]: RRQ from filename //images/RHEL-6.4-x86_64/initrd.img
dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 via
dhcpd: DHCPOFFER on to 00:11:22:33:44:55 via
dhcpd: DHCPREQUEST for ( from 00:11:22:33:44:55 via ignored (not authoritative).

Things to note are:

  1. 00:11:22:33:44:55 is the MAC address I am referring to
  2. In the DHCP server, the subnet is set as authoratative
  3. In the DHCP server, the option routers section is set to, which is the default gateway - which in our network, can get to anything on the network

Does this seem weird or is it just me? I feel like it's reaching out to something that it shouldn't be.

Also - that and .22 servers - those are not pingable from anywhere, however, when I run an nmap on them they show a squid-http servers (which would be proxy servers), however, my network team tells mem those don't have an ARP entry so they are "down".

I'm at a loss here.

share|improve this question
Have you already checked the ks and ksdevice parameters in your append line? – dawud Jul 5 '13 at 17:45
Yes - found the issue though - I'll post the issue. – drewrockshard Jul 5 '13 at 21:59

Was able to resolve the issue myself. There was a rogue DHCP server on the same switch (and thus, the same network/VLAN) as the server I was provisioning.

This was an weird mistake, due to the fact that both servers were plugged in at the same time, and apparently the second server actually booted up, and the server used to be an old DHCP server, therefore, it started issuing out DHCP offers without me even knowing that it used to be used for that purpose. I had our network team trace down the offers and that's when we realized that it was the second server causing the issues. So weird though.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.