0

I'm trying to setup a foreman service in my homelab to replace my current manually managed KVM solution. As part of this, I'm trying to get deployment working and the DHCP and DNS proxies working. I'm starting with DHCP.

The problem that I'm seeing is that my primary DHCP server is handing out leases to new hosts, and that the addresses do not match the expected foreman address, so the PXE deployment fails.

I was hoping that because I had the MAC address of my host setup in Foreman (under the Interfaces section of my host definition), and do not have that MAC address present in my standard isc-dhcp-server, that foreman would answer the request via the smart proxy, instead of my primary DHCP server answering it.

Is this possible, and if so, how ?

I'm using Foreman 1.11.3 on Ubuntu 14.04.4 LTS and I have the following packages installed: 

ii  foreman                            1.11.3-1                         amd64        Systems management web interface
ii  foreman-cli                        1.11.3-1                         all          metapackage providing hammer CLI for Foreman
ii  foreman-debug                      1.11.3-1                         all          provides support utility foreman-debug.
ii  foreman-installer                  1.11.3-1                         all          Automated puppet-based installer for The Foreman
ii  foreman-libvirt                    1.11.3-1                         all          metapackage providing libvirt dependencies for Foreman
ii  foreman-postgresql                 1.11.3-1                         all          metapackage providing PostgreSQL dependencies for Foreman
ii  foreman-proxy                      1.11.3-1                         all          RESTful proxies for DNS, DHCP, TFTP, and Puppet
ii  ruby-foreman-setup                 3.1.0-1                          all          Foreman Setup Plugin
ii  ruby-hammer-cli-foreman            0.6.2-1                          all          Foreman commands for Hammer

tcpdump shows that my foreman server is receiving the DHCP request:

16:10:34.160764 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:cd:03:63 (oui Unknown), length 402
16:10:34.161015 IP foreman.penguinpowered.org.bootps > 192.168.10.147.bootpc: BOOTP/DHCP, Reply, length 326
16:10:35.143593 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:cd:03:63 (oui Unknown), length 402
16:10:35.143752 IP foreman.penguinpowered.org.bootps > 192.168.10.147.bootpc: BOOTP/DHCP, Reply, length 326
16:10:37.120935 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:cd:03:63 (oui Unknown), length 414
16:10:37.121087 IP foreman.penguinpowered.org.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300

But on my main DHCP server, I can see it being answered in the logs: 

Aug 27 16:10:33 networkservices dhcpd[3678]: DHCPDISCOVER from 52:54:00:cd:03:63 via ens3
Aug 27 16:10:34 networkservices dhcpd[3678]: DHCPOFFER on 192.168.10.70 to 52:54:00:cd:03:63 via ens3
Aug 27 16:10:36 networkservices dhcpd[3678]: DHCPREQUEST for 192.168.10.70 (192.168.10.3) from 52:54:00:cd:03:63 via ens3
Aug 27 16:10:36 networkservices dhcpd[3678]: DHCPACK on 192.168.10.70 to 52:54:00:cd:03:63 via ens3
Anonymouslemming
  • 801
  • 2
  • 14
  • 25

1 Answers1

1

Duelling DHCP servers are possible, though will require configuration to prevent the wrong one from answering the wrong thing, ranging from a kluge ping-check / ping-timeout to slow one down to marking one or the other as not authoritative or to deny unknown-clients (possibly the one that only has a few static entries in it) or in this case perhaps on the main DHCP server to match some feature of the PXE clients and deny them leases from the main pool. See dhcpd(8) and dhcp-options(5) for pointers, as you could match by MAC address prefix, or something in the PXE client request...

class "your-pxe-booters" {
    match ...;
}

subnet ... {
    pool {
        deny members of "your-pxe-booters";
        ...
thrig
  • 1,626
  • 9
  • 9
  • Thanks. I was kinda hoping that the foreman proxy would create a reservation in my main DHCP server, but that doesn't seem to be happening. I'll give some of these options a try. – Anonymouslemming Aug 27 '16 at 19:09
  • DHCP is a broadcast, so two servers on the same subnet will both see the packets (unless you use VLANs, or at the network level filter DHCP requests somehow...) – thrig Aug 27 '16 at 19:18