DHCP: multi-interfase dhcp service?

[Parrat0]

I need help with troubleshooting my homelab dhcp issue; which is working on one interface (ens18) but not the other (ens19); while webgui and dns is working on both.

edit restarting the container hints at the issue indeed, but how do I change this?

INF ts=1733816158.2315943 logger=role.dhcp msg=starting DHCP Server instance=network-ha-1 version=0.18.0+f925061b port=67 interface=ens18

Edit2: in the meantime the way I solved this is by having dhcp-relay from vlan30 to vlan22.

---

Rest of the original post:

My current setup is:

• server network across vlan 22
• client network across vlan 30
  Gravity initial configuration & setup was on vlan 22. There it's working. I'm using "network_mode: host" and I set "INSTANCE_LISTEN: 0.0.0.0"

I've added a second nic to also add dns & dhcp to my client network via gravity. Dns is working fine, DHCP on the other hand is not. The host where gravity is hosted has its: 172.22.2.1 on ens18/vlan22 and 172.30.1.2 on ens19/vlan30.
The webgui is available on both, dns-resolution is available on both. But DHCP doesn't respond on the ens19-nic.

My dhcp config for 172.22 is:

And for 172.30 is:

if I run discovery on the 172.30 subnet I find myself but also the default gateway (my unifi router) and any static ip clients configured.

The network config from the server where gravity is on:

I have a VM previously used for syncthings that I'm testing with. If I add it's nic to the vlan 30 group and assign a static IP I can ping as well as dns request, which the gravity instance answers. Proof is screenshot 1 - 3.

However when I try set the nic to dhcp and try to get an ip, no response from gravity. see screenshot 4.
The switch is vlan aware and routing is disabled between them, so vlan 30 can only communicate with vlan 30.

My gut feeling is that; much like dns with the instance_listen config I need to tell the dhcp-daemon that it needs to listen on all interfaces. But with my google fu I don't know how to do that with etcd & dhcp. I can't seem to find any config or run any command that might be related to etcd dhcp.

But is this really the problem and if not do you have guidance on how to troubleshoot this?

1

2

3

4

[francoisdrolet]

I encounter what I believe is the same issue.

I am on 0.28.7. I have 3 LXC configured in the same way, with 2 network interfaces each, all using host networking through docker.

Discovery works fine on both subnets -- I am seeing all the hosts and their IPs, but when I add a DHCP scope to serve the subnet on the second interface, it doesn't reply to any DHCP request.

It probably can't, because gravity doesn't listen on the proper interface on port 67.

# ss -lnp | grep 67
udp   UNCONN 0      0        0.0.0.0%eth0:67         0.0.0.0:*    users:(("gravity",pid=549,fd=25))            

The interface on the network subnet I configured the DHCP scope for is not eth0.

I execd into the container and both interfaces exist in /proc/net/dev.

I'll try to figure out where in the code is the mechanism that configures the listening interfaces for gravity DHCP server.

[francoisdrolet]

It seems like the interface the DHCP server might listen on is auto-detected based on the instance IP for the web interface?

Setting the INSTANCE_INTERFACE environment variable to the interface I scoped for, now does listen on its port 67, but it still doesn't answer DHCP requests.

[francoisdrolet]

I get a lease if I make that scope the default one! I was under the impression that the scope would be inferred from the interface subnet the DHCP server is listening on, which is how I interpret the second point in the documentation:

The scope for any particular request is found in the following way:

• Checking if the DHCP Peer address is within any of the scopes CIDR, or
• Checking if the Address of the interface the request was received on is within any of the scopes CIDR, or
• Checking if the Scope has the default flag set to true.

Afterwards, all matching scopes are sorted by the length of the Scope’s CIDR Prefix, and the longest prefix match is chosen.

# ip a | grep -B2 10.8.70
3: net70@if168: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:df:ae:2c brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.8.70.27/24 brd 10.8.70.255 scope global net70

# ss -lnp | grep 67
udp   UNCONN 0      0       0.0.0.0%net70:67       0.0.0.0:*    users:(("gravity",pid=1464,fd=34))           

[francoisdrolet]

Since this is basic functionality, that is probably a misconfiguration on my side, but so far it looks like there's 2 different issues:

• DHCP server does not listen on all interfaces I expect it to
• DHCP server does not answer requests for scopes it's configured for (I'm using INSTANCE_INTERFACE here)

I haven't figured out what might be wrong in my config yet. It might even be the same misconfig causing those 2 issues. Otherwise, I'll try to hack and deploy in my lab to see if I can fix what I think needs fixing.

I really hope to get Gravity deployed in my lab because I've been wanting an HA DHCP / DNS solution for a while and this really looks promising.