Share and learn in the Docker community.
Hi all,
I’ve created this macvlan via CLI:
docker network create -d macvlan \
--subnet=192.168.10.0/24 --gateway=192.168.10.1 \
--ip-range 192.168.10.100/30 \
-o parent=enp0s31f6 \
--aux-address="myserver=192.168.10.102" \
macvlan0
This has an IP Range of 192.168.10.100 to 192.168.10.103.
How can I modify this so the range is 192.168.10.100 to 192.168.10.109? If modify is not possible then delete and recreate.
TIA
Looks like the challenge may be your CIDR. The range you’ve added (192.168.10.100/30) will only allow 4 IP addresses, and you’d normally only be able to use two of those. If you are looking to have more than 2 usable addresses, you’d want to try to use /28 instead, which should support your range.
Another option is to explicitly set your range if you’d rather not use a CIDR notation, like so:
docker network create -d macvlan \
--subnet=192.168.10.0/24 --gateway=192.168.10.1 \
--ip-range=192.168.10.100,192.168.10.109 \
-o parent=enp0s31f6 \
--aux-address="myserver=192.168.10.102" \
macvlan0
Thanks for your reply.
I thought you had to use CIDR for the IP Range and I don’t recall seeing anything in the documentation saying you can enter the range in other ways.
With due respect, are you sure of your statement?
Many thanks again.
No worries. I’ve done it both ways. You don’t have to use a CIDR directly for IP ranges if you explicitly set the range in your command, which was the alternative approach that I provided. Maybe try it out on your end to see if you get the desired results?
Again, either option would work, but using /30 will not work with the target range you’re looking for. The best option is to simply use /28 in your original command if you’re not comfortable with explicitly setting the range directly.
But that will give me an IP Range of 96 - 111 meaning, unless I manually set the IP, docker could assign IP’s 96, 97, 98, 99, 110 and 111. Which I don’t want.
Or, do I have it all wrong?
It would give you IPs in the range of 192.168.10.100 to 192.168.10.109, which is what you are looking for, correct? Docker will give you 10 usable addresses, starting at 192.168.10.100. It will not start at 192.168.10.96 since that is below your range
Thanks once again for all you input, I really appreciate it.
I’m obviously not understanding how this all works. Why would docker not start at 192.168.10.96, as that is the starting address for this CIDR?. Also why would docker only use 10 addresses and not 16, also as defined by the CIDR, and use 192.168.10.110 and 192.168.10.111.
Once again, very sorry for being a noob about this, as I’m just trying to understand.
Greg
Networking and subnetting can be challenging to understand, especially fi you’re just starting out.
192.168.10.100/28 covers 16 total addresses (192.168.10.96 - 192.168.10.111).
These are your Usable IPs: 192.168.10.97 to 192.168.10.110. The first and last addresses in the range are reserved by default. /28 provides 16 total addresses, but you can only use 10 of those addresses, not all 16.
However, since 192.168.10.97 - 192.168.10.99 are below your required range, Docker will start at 192.168.10.100, ensuring the correct 10 usable addresses (192.168.10.100 - 192.168.10.109), which is what you are wanting.
Docker will ONLY cover the CIDRs that you explicitly call out for your subnet, nothing more.
Are you sure about that?! After all an ip is a representation of 32 bits. The bits of the cidr range, declare the leading bits that make up the range, In the case of /28, it would be the first 28 bits. So why would the bits not apply to the ip’s between 192.168.10.96 to 192.168.10.99?
The cleanest solution would be to declare a /28 range and declare the ips you want to exclude as aux-address,
Note: the ip-range is only relevant for the built-in dhcp server of the network, to issue ip addresses to containers attached to the macvlan network… If you assign fixed ip’s to your all containers attached to the macvlan network, nothing would realy use the ip-range. Afaik, it does not prevent to declare static ips outside the declared ip-range for containers attached to a macvlan network.
I understand networking and yes, I’m sure. Using an aux -address with the solution is a good callout as well and definitely possible.
A /28 subnet provides 16 total addresses, meaning the range is 192.168.10.96 to 192.168.10.111. However, within that range:
192.168.10.96 is the network address (reserved).
192.168.10.111 is the broadcast address (reserved).
192.168.10.97 - 192.168.10.99 are technically usable but fall outside the explicit --ip-range 192.168.10.100/28 parameter, which instructs Docker to allocate addresses starting from 192.168.10.100 onward.
Docker’s --ip-range defines which subset of the /28 should be allocated, so while the full subnet includes .96 - .111, the range you specify tells Docker where to start assigning. That’s why .100 - .109 are the active allocated IPs in this case.
And yes, you are correct, the --ip-range is primarily used for Docker’s built-in IP allocation, ensuring that dynamically assigned container IPs fall within the specified range. However, that doesn’t change the fact that a /28 subnet inherently includes .96 - .111, and Docker will allocate from the range you define unless static IPs are manually assigned outside of it. The original point stands: specifying --ip-range 192.168.10.100/28 ensures that dynamic IP assignment starts at .100 and stays within .109, making it a practical way to control container allocation.
If you’re manually assigning static IPs outside of the defined range, then yes, Docker’s DHCP won’t enforce restrictions—but that’s outside the scope of what was being discussed. The key point is that the defined IP range still dictates automatic allocations unless explicitly overridden.
I hear you. I tried it, and these are the results with docker-ce 28.0.1:
me@host~ # docker network create -d macvlan \
--subnet=192.168.200.0/24 \
--gateway=192.168.200.1 \
--ip-range=192.168.200.100,192.168.200.101 \
-o parent=eth0 \
macvlan0
every ip-range or gateway must have a corresponding subnet
result: error → no network created
me@host ~ # docker network create -d macvlan \
--subnet=192.168.200.0/24 \
--gateway=192.168.200.1 \
--ip-range=192.168.200.100/28 \
-o parent=eth0 \
macvlan0
Error response from daemon: invalid network config:
invalid ip-range 192.168.200.100/28: it should be 192.168.200.96/28
result: error → no network created
me@host:~# docker network create -d macvlan \
> --subnet=192.168.200.0/24 \
> --gateway=192.168.200.1 \
> --ip-range=192.168.200.100,192.168.200.101 \
> -o parent=eth0 \
> macvlan0
every ip-range or gateway must have a corresponding subnet
result: error → no network created
me@host:~# docker network create -d macvlan \
--subnet=192.168.200.0/24 \
--gateway=192.168.200.1 \
--ip-range=192.168.200.100/28 \
-o parent=eth0 \
macvlan0
2be397cc54ede6422b436932aa62b116c58389ff44d6af2a2ca14266dd670912
me@host:~# docker run -ti --rm --network macvlan0 alpine ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1
link/sit 0.0.0.0 brd 0.0.0.0
37: eth0@sit0: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 02:42:c0:a8:c8:60 brd ff:ff:ff:ff:ff:ff
inet 192.168.200.96/24 brd 192.168.200.255 scope global eth0
valid_lft forever preferred_lft forever
result: network can be created, container still has ip 192.168.200.96.
I am not able to verify either one of the claims.
Your result is interesting, but it doesn’t invalidate the behavior of --ip-range. As mentioned earlier, --ip-range is used for Docker’s built-in DHCP allocation and does not restrict manually assigned static IPs or the first allocated address in certain cases, especially in macvlan networks where behavior differs slightly from bridge networks.
However, there are a few things to consider:
Docker’s Allocation Strategy Can Differ by Version and Network Driver. On some setups, Docker might still allocate the first available IP in the subnet (.96 in your case) before honoring the --ip-range setting.
Macvlan operates differently than bridge networking, where --ip-range is more strictly followed for dynamic assignments.
The First Assigned Address Can Fall Outside --ip-range depending on implementation. This might be an inconsistency in how Docker CE 24.02 handles macvlan specifically. With bridge networks, Docker tends to follow --ip-range more reliably.
Try Running Multiple Containers. If you spin up multiple containers, do subsequent ones get allocated within 192.168.200.100-109 as expected?
This would confirm whether Docker eventually adheres to the defined range after the initial assignment.
Docker Might Allocate from the First Free Address in the Subnet. In some versions, Docker will assign the first available IP in the subnet if no prior allocations exist, instead of immediately enforcing the --ip-range.
While your example shows .96 being assigned, that doesn’t necessarily mean --ip-range is ignored—it may simply be a quirk of macvlan’s handling of initial IP assignments. Testing with multiple containers should clarify whether Docker eventually follows the defined range for subsequent allocations.
Also, if using Docker’s --ip-range option, you’d need to use a CIDR notation block or a single contiguous block as the comma-separated option is not valid when using the --ip-range option. I may have incorrectly added that in an earlier comment while reviewing. That’s why --ip-range=192.168.200.100,192.168.200.101 fails, while something like --ip-range=192.168.200.100/30 (which includes .100 and .101) would work.
So in a nutshell, understanding how different versions and individual docker setups function with networking would be a deciding factor in the results either of you are trying to achieve. It seems as though this is more of a debate rather than trying to understand how networking works in general. I’m just trying to help. I hope this clarifies things a little more.
Just a reminder:
Based on this rule, the user accounts @021bl00m will be suspended for posting ai generated content based on non-verified hallucinations.
After a private conversation, it looks like there was a misunderstanding, so I restored the last post and unsuspended @021bl00m . Sorry for the mistake.
Thanks for you reply.
As already mentioned I orginally created the macvlan with this command:
docker network create -d macvlan \
--subnet=192.168.10.0/24 --gateway=192.168.10.1 \
--ip-range 192.168.10.100/30 \
-o parent=enp0s31f6 \
--aux-address="myserver=192.168.10.102" \
macvlan0
I then followed up with these commands to connect my container, which is connected to macvlan0, and an IP of 192.168.10.100 to the macvlan.
ip link add macvlan-shim link enp0s31f6 type macvlan mode bridge
ip addr add 192.168.10.102/30 dev macvlan-shim
ip link set macvlan-shim up
This gives my container on 192.168.10.100 access the host.
If I now delete the macvlan with the command docker network rm macvlan0 and create a new macvlan with the required new ip-range using:
docker network create -d macvlan \
--subnet=192.168.10.0/24 --gateway=192.168.10.1 \
--ip-range 192.168.10.100/28 \
-o parent=enp0s31f6 \
--aux-address="myserver=192.168.10.96" \
--aux-address="myserver=192.168.10.97" \
--aux-address="myserver=192.168.10.98" \
--aux-address="myserver=192.168.10.99" \
--aux-address="myserver=192.168.10.102" \
--aux-address="myserver=192.168.10.110" \
--aux-address="myserver=192.168.10.111" \
macvlan0
Do I need to re-run the previous ip link commands? Or, should I somehow delete them before I delete the macvlan.
TIA
The mavcvlan-shim is just is a macvlan child interface on the host. It works around limitation that a macvlan parent interface (enp0s31f6 in your case) is not allowed to communicate with child interfaces. Since your host now has its own child interface, the child interface can communicate with the child interfaces of the containers.
Please be aware that those commands are not persisted and need to be done on every system start. Most people use cronjob entries with @reboot to execute the command on every start.
I am surprised about your response: it ignored my results for the latest docker-ce 28.0.1, and it still lacks commands and outputs that verify the claims.
So please share your personal experience: share your commands and the resulting outputs with a docker-ce version where the implementation matches the claims.
The beauty is: everyone can run those commands and verify the results on their own machines.
Sharing my output as well, which is not AI based, but legitimate local testing instead. Also added in the use of --aux-address. Goes back to the original issue the user was facing. Also, I am using Docker-Desktop with MacOS, with a custom DHCP & NAT Bridge with VPN enabled as well. I’d recommend maybe looking into the iptables and firewalld to ensure Docker is able to route the macvlan traffic correctly, if the issue persists.
