Is there a better way by not assigning 2 ip address

[ghost]

Hello,

I have tried your solution, thanks for great work. It works fine.
I have question regarding each macvlan container will use 2 ip address from router when creating network link between container and synology(Host)
1st is for actual container and 2nd is to network traffic between host(synology) and container app.

Is there other way so we can have only 1 ip address on actually DHCP server(Router). as when i will have many macvlan containers then i need to maintain 2 ip address for each one.

Thank you for your help.

[markdumay]

hi @krswin, good to hear the script is working for you. If I understand your question correctly, you'd like to know if you can reduce the amount of required IP addresses for each macvlan network. The short answer is, no, you can't. I'm still working on a more elaborate tutorial, but below an attempt to answer your question.

The macvlan network is a virtual network within your existing network. Imagine your DHCP server uses the private IPv4 range 192.168.1.0 - 192.168.1.255. By design, the network address is 192.168.1.0 and the broadcast address is 192.168.1.255, leaving 254 IP addresses for hosts. The macvlan network reserves a subrange of this network as a virtual network. The minimum range of such a network is 4 consecutive addresses, as the first and last are the network address and the broadcast address, leaving two addresses available to hosts. This IP calculator is a helpful tool to calculate the available addresses for a given address range in CIDR notation. For more background information, this article gives an in-depth overview of IP addresses, subnet masks, and CIDR notation.

To come back to your question, you could consider to assign the containers to the same macvlan network, instead of creating a separate macvlan network for each container. Below excerpt of the docker-compose.yml file instructs Docker to assign the container to a specific IP address on the macvlan network. You would have to increase the range of your macvlan network to the amount of hosts + 2, and lookup the valid range with the IP calculator.

services:
    pihole:
        [...]
        networks:
            macvlan:
                ipv4_address: ${PIHOLE_IP}

Another alternative is to setup multiple VLANs that are able to communicate with each other. However, setting this up correctly requires quite some network experience and is dependent on your specific network setup.

[ghost]

@markdumay Thanks for quick reply. and nice explanation.

I was trying to figure out to reduce number of IP use for each container and currently found that it works with 2 ips.

ip link add pihole_VLAN1 link eth0 type macvlan mode bridge
ip addr add 192.168.1.10/32 dev pihole_VLAN1
ip link set pihole_VLAN1 up
ip route add 192.168.1.11/32 dev pihole_VLAN1

Where:
eth0 - Name of your physical adapter
192.168.1.10/32 - Genuine new IP on your network
192.168.1.11/32 - IP of the container using macvlan

And this way pihole gets ip : 192.168.1.11 and synology can talk to pihole on 192.168.1.10.

What do you think about this solution? I have tested this and works perfectly fine, also other device in network can talk to pihole

[markdumay]

Nice- thumbs up for the experimentation! :-) I did some additional research, and found this post that might be interesting. Below some of the observations mentioned when using the broadcast address as a host address. Then again, if it works for you without any issues, I see no harm in using your configuration in a home setup. It might be a different story in a production environment. I'm by no means a networking expert, so there might be other nuances here that I overlook.

Some switches can rate limit broadcast traffic. If your switch does that, the host to which you assigned the broadcast IP address may never be able to receive data from the network at full speed.

Moreover some of the other hosts which receive packets destined for the broadcast IP might send error responses (ICMP errors or TCP RST packets) when receiving unexpected traffic. If any host does so, it can cause broken connectivity for the one host attempting to use the broadcast IP.

Alternatively, you could still consider extending your macvlan IP range and assigning the containers to the same macvlan network. In this scenario, the overhead is limited to two addresses only (and any rounding of 2^n). The downside is that these containers are then no longer isolated from each other, which might not be what you are looking for.

[ghost]

Thanks for info. I am also not networking expert, but when i have free time during Christmas I will read more about this networking stuff seems interesting how this works. Have a good time.

[markdumay]

Cool, looking forward to your findings!

…

On 8 Dec 2020, at 20:40, krswin ***@***.***> wrote:  Thanks for info. I am also not networking expert, but when i have time during Christmas I will read more about this networking stuff seems interesting how this works. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Kieren]

Thanks Mark for putting this script together, it seems to be a comprehensive script which makes managing a Pi-hole Docker container easier, and not something I could have put together on my own.

I forked your repository to make some changes. These were much in line with comments from @krswin. I've done some testing on my changes and everything appears to work as I would expect them.

I created a pull request should you wish to consider merging the updates into your own repository.

Thanks for your work.

[ghost]

Thanks Kieren for help. I will also check it.

[markdumay]

Hi all, the latest two PRs should now have solved this issue. Let me know if I need to reopen this issue.

[markdumay]

One additional note, upgrading to the latest Pi-hole (FTL version 5.7) raised an issue on my NAS. The reported error was [ERROR] File not found: /etc/pihole/setupVars.conf (or something similar). Removing the current data directory solved this issue. It seems the Pi-hole image made some changes to the file structure. I couldn't be bothered too much about loosing my old log data. You might want to reconsider this if you do.

[wizlee]

Thank you @markdumay, @Kieren and @krswin for this discussion. I am not very familiar with network and shell script. Reading all these helps me to get a better understanding on what are the intends of the script. =)