I guess it is because ipvlan assigns the hostâs mac address to the containers while macvlan assigns new mac addresses. I donât have experience with Unifi, but if it recognizes the hosts by mac address and you donât have DNS records assigned to the IP addresses directly, it wonât work. When I assign an IP manually to a machine on my LAN, I have to choose the mac address and type the IP. This is how the router knows about the machine. I can map hostnames to IP addresses, but for that I have to use static IPs. It is probably similar to what happens when I just add a new IP address to an interface on the host.
From where? From another container on the same macvlan?
I would say even if you use macvlan, it is better if you use static IPs and set DNS records or just edit a hosts file on the router.
If your containers on the same host, you can also use a bridge network as a second network so your containers could be on macvlan, but could use the bridge network to communicate with eachother on the same host and refer to a container using the container name or compose service name.
This explains another observation. On the list of clients in my Unifi Network Application, the macvlan containers are all there - I thought because they are on different Unifi-VLANs. The containers on the 192.168.70.x-range are missing. (Or more correct: the IP-address changes every couple of secondsâŠ) Obviously, because they have all the same mac-address.
The Ubuntu server is on 192.168.70.2. Would it work, if I create a mac-vlan, that distributes IPs from the 192.168.70.x-range? (I thought I tried this, but I ran into trouble, as the Ubuntu server and the docker containers would be in the same Unifi-VLAN and on the same Switch PortâŠ)
Either your macvlan uses a different vlan or at least a dedicated iprange. So for example you can use the existing vlan if you can configure the router to assign IP addresses from a smaller ip range like 192.168.70.0/25 which is between 192.168.70.0 and 192.168.70.127 and I think you could set your macvlan subnet to 192.168.70.128/25 to use only half of the entire IP range or set the ip range of the hosts in the aux-address if it is possible. I donât use macvlan, so I donât know, but the documentation shows a single IP not an ip range in aux-address.
Is this correct? Should the parent be eno1.70, as the containers in that network should end up on that VLAN? (well, according to the Unifi Network Application, they are on VLAN 70âŠ)
Yes, but how it affects DNS with macvlan, I canât tell.
I really donât use macvlan and ipvlan and network configuration is not my favourite topic, but the best if you test accessing containers using the macvlan addresses from other machines. If it works, then the configuration must be correct. I donât know your network, so I canât tell you what the correct configuration is. If I had to configure it, I would test it too
I would guess if eno1.70 is the vlan interface, that should be the parent, but I would not like to speculate more.
My HomeAssistant Container, where the domain name is working, is probably alpine based. Do you know, where I can find the defined domain name within the container? I had a look into /etc/hostname and /etc/hosts, but the domain name is not there. Where else to look?
I just had a look into the json of an ipvlan-container. There is no mac-address at all.
Within Docker documentation:
IPvlan is similar to Macvlan, but doesnât assign unique MAC addresses to containers. Consider using IPvlan when thereâs a restriction on the number of MAC addresses that can be assigned to a network interface or port.
I think I have lost the thread. What domain name are you looking for? I try to summarize what I tried to suggest so far. Maybe I was not clear enough and thatâs why I donât understand your last posts:
You need DNS resolution to map an IP address to a domain name.
DNS resolution works between containers on user-defined bridge networks (the kind that Docker Compose creates too) so you can use compose service names or container names as hostnames
on MACVLAN you there is no such DNS resolution provided by Docker automatically
You can have MACVLAN (or IPVLAN) and user-defined bridge network attached to one container as long as both containers are attached to the same bridge network.
On MACVLAN (and this is a guess based on how it works on a usual LAN) the router can automatically recognize the hostname of a machine or in this case a container and make it available for DNS resolution, but for that you need unique MAC addresses, as this is how the router identifies the machine.
As you quoted from the documentation as well, IPVLAN doesnât provide unique MAC addresses.Thatâs why it is âIPâ vlan and not âMACâ vlan. So the router will see the MAC of the host.
In case of IPVLAN, you most likely need to set DNS records on a DNS server. That could be a router too.
So if you want to use the hostname and domainname parameters of a compose service to set DNS records, that will probably work only on MACVLAN. If you want a specific container to access another container with a known IP on IPVLAN using a hostname, you can use the extra_hosts parameter in compose, which will indeed edit the hosts file in the container (actually created on the host and bind mounted into it) Unfortunately I 'm not sure what domain name you were looking for.
What did you test? Network connection or DNS resolution?
thank you very much for your summary.
I guess, I understood now the difference of ipvlan and macvlan and its implications on domain name resolution.
I have spent last night further looking into my issue. Domain name resolution still not working. It took me a while to realize that Adguard Home is gathering a list of clients, including their domain names. This list is not properly updating and I donât (yet) understand why.
To summarize:
Those domains on that client list are instantly resolved, as I expect them to. All other containers are only reachable via IP. So, this is not a Docker issue.
I had a look into the /etc/hosts file and there is esphome.esphome.internal. The configuration in the compose.yaml should be the following to get the wished URL esphome.internal.
Again: thank you very much for your time and help. I will open up discussions on the Adguard Community and eventually in the Unifi Community to get this solved.
I did some more digging. Here is, what I have found out.
My Unifi Gateway writes every device, that ever connected to my network, into the /etc/hosts-File. Over the last 5 years, this has become a very long list. For some IP-addresses, there have been several entries with different domain names.
Well, almost all devices. This seems to be true for all physical clients, which receive their IP-address via DHCP-reservations.
After having deleted all entries from the hosts-file, my gateway is gathering all the data again. This time, the entries have the correct domain names and access via domain name is possible.
All my docker containers have not (yet) been discovered by my Gateway. I donât know, why some of them had been added before.
There seem to be three ways to solve the dns-resolution problem:
manual entries in the hosts-file of the Unifi Gateway
Within the Unifi Network Application, I could manually create DNS-entries. (The Application doesnât allow me, if the mac-address is already knownâŠ)
I could use AdGuard Home as a DNS-Server and manually add the DNS-entries there. (I decided to give pi-hole a try as wellâŠ)
summary:
I have learned how to define the hostname and domain name for docker containers.
I have learned the difference between ipvlan and macvlan. I will change everything to macvlan, as I would like to see all my containers in the Unifi Client Overview.
The issue was not the reverse-DNS from AdGuard Home, but a messy hosts-file on my Unifi Gateway.
Hope, this will help some other lost hobby-network-specialists, such as my self