3

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 10.6.246.1
dhcpd: DHCPOFFER on 10.6.246.9 to 00:11:22:33:44:55 via 10.6.246.1
dhcpd: DHCPREQUEST for 10.6.246.9 (10.6.247.236) from 00:11:22:33:44:55 via 10.6.246.1
dhcpd: DHCPACK on 10.6.246.9 to 00:11:22:33:44:55 via 10.6.246.1
xinetd[3010]: START: tftp pid=26359 from=10.6.246.9
in.tftpd[26360]: RRQ from 10.6.246.9 filename /pxelinux.0
in.tftpd[26360]: tftp: client does not accept options
in.tftpd[26361]: RRQ from 10.6.246.9 filename /pxelinux.0
in.tftpd[26362]: RRQ from 10.6.246.9 filename /pxelinux.cfg/44454c4c-5800-104e-8057-b9c04f4b4e31
in.tftpd[26363]: RRQ from 10.6.246.9 filename /pxelinux.cfg/01-00-11-22-33-44-55
in.tftpd[26364]: RRQ from 10.6.246.9 filename //images/RHEL-6.4-x86_64/vmlinuz
in.tftpd[26365]: RRQ from 10.6.246.9 filename //images/RHEL-6.4-x86_64/initrd.img
dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 via 10.6.246.1
dhcpd: DHCPOFFER on 10.6.246.9 to 00:11:22:33:44:55 via 10.6.246.1
dhcpd: DHCPREQUEST for 10.88.254.102 (10.88.254.22) from 00:11:22:33:44:55 via 10.6.246.1: 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 10.6.246.0 is set as authoratative
  3. In the DHCP server, the option routers section is set to 10.6.246.1, 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 10.88.254.102 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.

2
  • Have you already checked the ks and ksdevice parameters in your append line?
    – dawud
    Jul 5, 2013 at 17:45
  • Yes - found the issue though - I'll post the issue. Jul 5, 2013 at 21:59

1 Answer 1

1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .