Some hosts are unable to get an address through DHCP

[mageta52]

The setup is five hosts hooked up to a switch, and the FOG server hooked up to this switch as well. No other devices, this is on an isolated network.

All hosts are powered off, and I’m powering them on one at a time for registration. First host was able to connect and register with the server. Second host stalled out receiving a DHCP address. I thought it might be a physical connection issue, so I took the cable from the first host, who had connected successfully, and tried with that, still failed. These are all identical systems, I’m not sure why some of them fail to connect while others have no issues?

[Wayne Workman]

What OS are you running FOG on? What version of FOG?

[mageta52]

Fedora workstation 23, FOG trunk rev 7272

[Wayne Workman]

@mageta52 Please check your cables first. Both the host cables and server cables. A misshapen, malformed, kinked, loose, or otherwise used and abused cable can cause your issue.

Second, check DHCP.
systemctl status dhcpd

if it’s failed, try to restart it. systemctl restart dhcpd
If it fails to restart, please provide us with the output from these two commands:
ip addr show
cat /etc/dhcp/dhcpd.conf

Third, check firewall.
systemctl status firewalld

Fourth, check selinux
getenforce

[mageta52]

Checked cables, found a mix of crossover and straight through. Should all be straight through, so I took out the ones that were crossover and verified that their replacements were indeed straight through.

Dhcpd is active and running

firewalld is inactive

selinux is disabled

[Wayne Workman]

@mageta52 So… is it fixed?

[mageta52]

I’m sorry, I forgot to post the results! No it still is not working.

If I let the hosts boot into their old OS, I am able to ping the FOG server, so I don’t believe there is a physical communication issue happening.

[Wayne Workman]

@mageta52 Then we will need to see the output of ip addr show and cat /etc/dhcp/dhcpd.conf, maybe it’s something simple.

[mageta52]

[root@localhost ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:13:20:04:2f:3d brd ff:ff:ff:ff:ff:ff
    inet 192.168.235.52/24 brd 192.168.235.255 scope global enp2s0
       valid_lft forever preferred_lft forever
    inet6 fe80::213:20ff:fe04:2f3d/64 scope link 
       valid_lft forever preferred_lft forever
3: enp4s2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:03:47:ad:c3:61 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:62:65:da brd ff:ff:ff:ff:ff:ff
    inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue master virbr0 state DOWN group default qlen 500
    link/ether 52:54:00:62:65:da brd ff:ff:ff:ff:ff:ff

[root@localhost ~]# cat /etc/dhcp/dhcpd.conf 
# DHCP Server Configuration file\n#see /usr/share/doc/dhcp*/dhcpd.conf.sample
# This file was created by FOG
#Definition of PXE-specific options
# Code 1: Multicast IP Address of bootfile
# Code 2: UDP Port that client should monitor for MTFTP Responses
# Code 3: UDP Port that MTFTP servers are using to listen for MTFTP requests
# Code 4: Number of seconds a client must listen for activity before trying
#         to start a new MTFTP transfer
# Code 5: Number of seconds a client must listen before trying to restart
#         a MTFTP transfer
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16;
use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
# Specify subnet of ether device you do NOT want service.
# For systems with two or more ethernet devices.
# subnet 136.165.0.0 netmask 255.255.0.0 {}
subnet 192.168.235.0 netmask 255.255.255.0{
    option subnet-mask 255.255.255.0;
    range dynamic-bootp 192.168.235.10 192.168.235.254;
    default-lease-time 21600;
    max-lease-time 43200;
    #option routers 0.0.0.0
    #option routers 0.0.0.0
    next-server 192.168.235.52;
    class "Legacy" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
        filename "undionly.kkpxe";
    }
    class "UEFI-32-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
        filename "i386-efi/ipxe.efi";
    }
    class "UEFI-32-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
        filename "i386-efi/ipxe.efi";
    }
    class "UEFI-64-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
        filename "ipxe.efi";
    }
    class "UEFI-64-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
        filename "ipxe.efi";
    }
    class "UEFI-64-3" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
        filename "ipxe.efi";
    }
}

[Wayne Workman]

@mageta52 The configuration looks fine. Can you attach a laptop or something to this network and see if you can get DHCP using the laptop’s OS?

[mageta52]

The hosts to be imaged all have a previous OS on them, so I can just boot them up and switch them to obtain an address automatically since they’re already hooked up to the server via the switch.

I tried /release /renew a couple of times on the machines that failed to get an address during PXE and they could both get an address when booted into windows. DHCP seems to be working fine.

So I went back to PXE booting, one of the hosts registered fine, I moved onto the next; failed at DHCP, same for the second host.

[Wayne Workman]

@mageta52 Ok then. This is a switch or hardware issue. What model of computers are you using? and what model of switch? Is it a mini switch or like an enterprise grade Cisco Catalyst ? If it’s a managed switch, what is your configuration? Do you have portfast enabled? Spanning tree? 802.11x power saving options?

[mageta52]

These are custom build 1RU’s with an Asrock Z97E motherboard.

The switch is a D-link DGS 1024D switch. I looked it up to confirm that it is indeed unmanaged

[Wayne Workman]

@mageta52 Can you try a different boot file? It might help. Right now, for legacy, you have undionly.kkpxe configured.

This is in your /etc/dhcp/dhcpd.conf file. They are labeled pretty well in there, it’s the one named “Legacy”.

If your NIC on the motherboard is realtek, use realtek.kpxe and if it’s intel, use intel.kpxe

You might also try out ipxe.kpxe as well.

The computers need fully turned off and back on for the settings to take right. On the fog server, after making a change, restart dhcp with systemctl restart dhcpd

Also, do you know if the motherboard is operating in BIOS mode or UEFI mode? The above instructions are for BIOS.

[Sebastian Roth]

@mageta52 said:

I tried /release /renew a couple of times on the machines that failed to get an address during PXE and they could both get an address when booted into windows. DHCP seems to be working fine.

Sounds very much like a spanning tree issue to me. Can you please try connecting an unmanaged mini switch in between the client and your D-link DGS 1024D switch. Does PXE boot work then? Search the wiki for spanning tree and port fast!

[mageta52]

Looks like they’re running BIOS, not UEFI. The nic is an Intel NIC.

By modifying the boot file I get the same error for both of your suggestions.
“Waiting for link up on net0… Down (http://ipxe.org/38086101)
DHCP failed, hit S for pxe shell, rebooting in 10 seconds”

[mageta52]

@Sebastian-Roth I checked the manual for this switch and the only mention of spanning tree is in the glossary. It gives no mention of the feature anywhere else, and I don’t think that a flat switch like this even supports it.

[Wayne Workman]

@Sebastian-Roth

@mageta52 said in Some hosts are unable to get an address through DHCP:

The switch is a D-link DGS 1024D switch. I looked it up to confirm that it is indeed unmanaged

[mageta52]

@Wayne-Workman So, I took the switch out of there and put in a different one; Trendnet TE100-S16, which is another unmanaged switch.

The pattern I’m seeing is that one host will make it through and get registered, then I move up to the next PC, and it fails to get through DHCP.

I’m not sure what the deciding factor is on whether or not they get through, but I’ve never had more than one get through consecutively

[Sebastian Roth]

@mageta52 Are you familiar with capturing a packet dump (network packets) from the wire using wireshark or tcpdump? This might be really helpful!