No dhcp and dns registration within LXC containers

Help Community Help
1

The issue I am facing:
The LXC containers receive IP and DNS details for all vlans.
However only the last vlan is actually registered within pihole/dnsmasq.

For VM's this is working as expected - meaning all vlans are registered.

See also dhcp.leases in the files with the debug token for the systems registered as ctf, cypher, upsmon, icarus and logos. The first 3 are LXC containers and have only one entry - should be multiple. The last 2 are VM's and have multipe entries with MAC adresses (and client-id's?)

Tested with eth0 and vmbr0 interfaces:
Interfaces are eth0, eth0.100, eth0.110, etc
Or with bridge interfaces vbmr0, vmbr0.100, vmbr0.110, etc.

Tested with and wthout dhcp-ignore-clid.

The config with the debug token is without vmbr-interfaces and dhcp-ignore-clid.

Details about my system:
Latest Debian version, pihole v6 version.
Also tried with bridge interfaces.
https://tricorder.pi-hole.net/YuqJxRh5/

What I have changed since installing Pi-hole:
Don't know - just noticed this behavior after starting a new LXC container with 3 vlan interfaces.

=====

Any suggestions?

2

You have configured multiple dhcp-host lines for the same MAC address, e.g. I count 7 entries for your osiris MAC.

Multiple dhcp-host are legit, but dnsmasq will only issue one lease per MAC, so "which one is used (and therefore which address is allocated by DHCP and appears in the DNS) depends on the subnet on which the host last obtained a DHCP lease" (quoting dnsmasq documentation).

With dhcp-ignore-clid, if you want a container to connect to a number of different VLANs/subnets simultaneously, you should have to attach as many different MACs to that container, and adjust your dhcp-host entries accordingly.

3

Ok - I'm not sure I understand what you are saying.

Where do you see these dhcp-host entries?
I'm not aware of creating any of these entries. Unless you are referring to the mac-based dhcp reservations.

If I look inside the VM's and LXC's (see also below for logos and osiris), then they all have the same MAC-address for all vlan interfaces. Meaning there is one MAC-address per vlan-tag.

Why does it work different for the VM's (like logos) then it does for the LXC's (like osiris)?

root@logos:/home/will# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether fe:09:86:65:3c:6b brd ff:ff:ff:ff:ff:ff permaddr 00:14:fd:19:3c:dd
3: enp5s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether fe:09:86:65:3c:6b brd ff:ff:ff:ff:ff:ff permaddr 00:14:fd:19:3c:de
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether fe:09:86:65:3c:6b brd ff:ff:ff:ff:ff:ff
5: bond0.100@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether fe:09:86:65:3c:6b brd ff:ff:ff:ff:ff:ff
6: bond0.110@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether fe:09:86:65:3c:6b brd ff:ff:ff:ff:ff:ff
7: bond0.200@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether fe:09:86:65:3c:6b brd ff:ff:ff:ff:ff:ff
8: bond0.210@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether fe:09:86:65:3c:6b brd ff:ff:ff:ff:ff:ff
9: bond0.220@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether fe:09:86:65:3c:6b brd ff:ff:ff:ff:ff:ff
10: bond0.230@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether fe:09:86:65:3c:6b brd ff:ff:ff:ff:ff:ff

root@osiris:/home/will# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether bc:24:11:87:be:e5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
3: eth0.100@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether bc:24:11:87:be:e5 brd ff:ff:ff:ff:ff:ff
4: eth0.110@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether bc:24:11:87:be:e5 brd ff:ff:ff:ff:ff:ff
5: eth0.200@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether bc:24:11:87:be:e5 brd ff:ff:ff:ff:ff:ff
6: eth0.210@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether bc:24:11:87:be:e5 brd ff:ff:ff:ff:ff:ff
7: eth0.220@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether bc:24:11:87:be:e5 brd ff:ff:ff:ff:ff:ff
8: eth0.230@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether bc:24:11:87:be:e5 brd ff:ff:ff:ff:ff:ff
4

When dhcp-ignore-clid is present, I'd expect all of them to acquire but one IP.

If in absence of dhcp-ignore-clid it works for some virtualisation environments, but not for others, then I'd suspect those other environments to provide their client identifier inconsistently, e.g. it may be missing or using a single identifier for all subnets, or perhaps even mixing up identifiers for different subnets.

By chance, your debug log hints that may happen, e.g. see these exchanges for the same MAC on eth0.100 and eth0.110:

Mar 21 10:32:29 dnsmasq-dhcp[50]: DHCPREQUEST(eth0.100) 192.168.100.41 bc:24:11:<redacted> 
Mar 21 10:32:29 dnsmasq-dhcp[50]: DHCPNAK(eth0.100) 192.168.100.41 bc:24:11:<redacted> wrong address
(…)
Mar 21 10:32:33 dnsmasq-dhcp[50]: DHCPREQUEST(eth0.110) 192.168.110.41 bc:24:11:<redacted> 
Mar 21 10:32:33 dnsmasq-dhcp[50]: DHCPNAK(eth0.110) 192.168.110.41 bc:24:11:<redacted> wrong address

Indications are that your observation should be addressed by the DHCP client.
Perhaps you can configure DHCP client identifier behaviour for those LXC containers?

1 Like
5

You are right - the client identifier is unique for the VM's.
And non-existing for the LXC containers.

I found the parameter inside /etc/dhcp/dhclient.conf.
But the default value doesn't help - it is still the same.
So I have to figure out a VM-type of way to make it unique across all interfaces

6

I have reviewed the config and made some changes - the biggest one is using dnsmasq-tags.
With a tag for each vlan - see also: https://tricorder.pi-hole.net/yG11N0A4/
For now I also enabled dhcp logging.

The dhcp logging shows that the dhcp requests are coming in via configured vlan interfaces and tagged as expected. The logging also shows that dhcp requests are processed as expected.

However, the dhcp dashboard only shows the last request that came in - not the previous ones.
The same applies for the content of the files called dhcp.leases.
In addition, dns resolution is only available for this last request.

Based on the docs I would expect that the current config sees each fqdn as a unique node - even if the MAC-address is the same. Meaning ctf.tech.lan is different from ctf.ota.lan and ctf.staging.lan. And all 3 should now be registered in DNS - even if there is no unique client-ID.

Would this indeed be the expected behaviour? And if so, why is it still not working as expected - what am I overlooking?

7

DNS is secondary here, as it only happens for active DHCP leases, i.e. your FQDN can only come into play once a DHCP lease has been assigned.

Your primary concern is DHCP registration, and pihole-FTL/dnsmasq will only register one lease per unique DHCP client, where such a client is identified either by its MAC or its client id.

I've explained that in my first reply:

8

Agree - therefor the log has multiple "wrong address" messages because the returned lease is validated against the subnet of the respective vlan. Which leads to a few "retries" along the way.

Despite these warnings and retries the process continues and ends with a "valid" lease for all vlan interfaces - just not a dns registration.

=====

Would a relay agent be of any help here?
I'm using a L3 switch as default gateway. Which can also be a dhcp relay agent for each vlan.

9

I very much doubt that, as that would only relay broadcasts from one link to another, adding an additional twist in client identification.

Could you share your respective lease file?

cat /etc/pihole/dhcp.leases | pihole tricorder

Of course, you have to run that from within your Pi-hole container.

10

Assuming dhcp-ignore-clid is not set and the clid is unique across all interfaces:
Which one is leading for getting the IP address? The mac address or the clid?

11

RFC 2131 defines:

If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client.

I've never been in the predicament of having to verify this particular aspect, but I trust dnsmasq to stick to RFCs tightly.

Note that RFC 2131 also requires the combination of a client id or hardware address plus the leased IP address to be used as a key for that client's DHCP parameters, which implies that there will only ever be one active DHCP lease for your LXC clients, unless you are either able to assign multiple MACs to an LXC container, or to configure a container to provide a unique client identifier for each VLAN it is attached to (which is what I am trying to get across since my awkward first reply :wink: ).

12

Yes - that was my understanding (and was the thing I was looking for). It looks as if systemd-networkd does exactly that: it allows me to use a system wide unique mac address and clid for each interface - including the vlan interfaces.

The test results until now show that the mac address has the final say - even if the clid is unique per vlan. Which is a strong indicator that dnsmasq is not compliant to the rfc - at least not when it comes to these lxc containers.

I have tried with 2 lxc containers. And only if the mac address is unique, pihole/dnsmasq registers the IP in dhcp.lease. And with that in dns.

If I leave the mac address to the system default and only provide a system wide unique clid it doesn't do that.

The system default means the mac address for the vlan interfaces is the same as for the physical interface it is attached to.

13

If that would be true, how does that fit your earlier:

With regards to your dhcp client stack:

Are you referring to your host system's systemd-networkd?

14

I reconfigured the LXC containers to use systemd-networkd.
Which allows me to activate the csid and custom mac-addresses - one unique csid and mac-address for each interface.

Now - systemd-networkd is doing dhcp requests.

The stack is Proxmox => LXC containers => Docker containers (for example pihole).
VM's are rarely used - only when LXC is not supported - like for example HASS and Kubernetes.

The systemd-networkd is not supported on Proxmox-PVE itself.
Here everything is about ifupdownv2 - I use systemd-resolved as stubresolver.
With pihole as forwarding dns server.

15

I try to phrase it differently:
Your VMs did present a unique client identifier right from the start, and you observed your VMs "working as expected - meaning all vlans are registered".

That would suggest that the DHCP clients for your LXC containers (now that you've got them to present a client id) do not present their client identifier in the same way as your VMs, or perhaps not at all.

Would you have reasons to believe otherwise?

You should also consider to bring this up with LXC support.
They should be better versed to tackle issues like yours.

16

It looks like the lcx vendor (i.e. Debian and PVE) have something to do with it - yes!
But dnsmasq could also have something to do with it.

If the mac-address is unique and clid is set via the duid option, all interfaces are registered in DNS.
In addition the pihole dashboard shows the system with all mac-addresses and all clid's.
This showed me that both are unique across all interfaces.

If I then remove the custom mac addresses (leaving the unique clid's in place), only the last one is registered in dns. Which is not what I would expect based on what the dnsmasq-manual says about the way things work with clid's.

The weird thing is that with the VM's things are working as expected - even when all mac-addresses are the same.

17

Just for prosperity, that info is on Currently active DHCP leases under Settings | DHCP, not the dashboard. :wink:

AFAIAAO, LXC and Docker both run their own sets of iptables rules for container isolation, which may or may not have an impact on DHCP.

Given that one type of client succeeds to register a DHCP lease per client id where another type fails, it seems likely that the other type client does something differently. Perhaps its using its client id only during initial broadcasts, but not in subsequent calls, violating RFCs.

I am aware you have also presented your issue at dnsmasq's mailing list.
Maybe they can come up with an explanation why dnsmasq would register your VMs as expected.

I'm afraid I can't help you much further, since I run neither Proxmox nor LXC containers to reproduce your observation. :frowning:

18

Yup - you are right :grinning_face_with_smiling_eyes:

Probably not in my case because the Docker containers are all running with the host adapter.

Yes - will see what that brings (if anything).

That's fine - I now know how the mechanism works and which buttons to push.

In addition I reviewed and improved the pihole install over the past few weeks. Combined with a switch to systemd-networkd which is far more flexible and easier then ifupdown - should have done this a long time ago.

Also a big thank you for your support and patience - you did a great job! :star_struck:
Let me now if there is anything I could do to return the favour!

1 Like
19

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.