Unable to Deploy Docker container with static IP using IPVLAN


At my home lab I have a router setup with VLAN’s, I created a specific VLAN VLAN ID 15 just for Docker containers. I have Docker’s NIC running on my managed switch port with VLAN ID 15.

I’m interested in having each Docker container have it’s own IP address.

I read about Docker IPVLAN 802.1q trunk L2 mode and it caught my interest.
Article: Use IPvlan networks | Docker Documentation

I created docker network successfully:

docker network create -d ipvlan
-o ipvlan_mode=l2
-o parent=eth0.15 ipvlan15

I created a test nginx container with a static IP with no problems:
docker run --net ipvlan15 --ip --name mynginx3 -p 80:80 -d nginx

however I don’t see the port shown under docker ps:

CONTAINER ID   IMAGE                            COMMAND                  CREATED          STATUS                  PORTS                                                           NAMES
008800fb6bd8   nginx                            "/docker-entrypoint.…"   24 seconds ago   Up 21 seconds                                                                           mynginx3

30c8cc809188   nginx                            "/docker-entrypoint.…"   3 hours ago      Up 3 hours    >80/tcp, :::80->80/tcp 

In addition I cannot ping nor access nginx via

If I do a regular docker run --name mynginx2 -p 80:80 -d nginx the port shows up in docker ps (as shown above) and accessible via browser

Am I doing something wrong when deploying a docker container with static IP?

Any help appreciated.

I assume you are using docker-ce, as macvlan/ipvlan will not work on Docker Desktop.
There is no need to publish ports on a container attached to a macvlan/ipvlan.

The Linux kernel prevents macvlan child interfaces to directly communicate with their parent interfaces and vice versa. I couldn’t find any reference if the same applies to ipvlan, but I would be surprised if it didn’t.

Did you consider both in your test scenario?

Yes I forgot to mention I am running docker-ce on ProxMox LXC container that is running Debian 11 core.

Hmmm interesting so if ports don’t need to be published then the container publishes ports automatically in IPVLAN mode? Wonder how it works when some people want to specify a different port for their container.

I tried another container without publishing ports:
docker run --net ipvlan15 --ip --name mynginx4 -d nginx

and the command ran fine, however same thing no ports shown in docker ps for “mynginx4” and I’m not able to ping nor access via browser

I haven’t tried MACVLAN yet. I wasn’t sure that I have to set my managed network switch port to “promiscuous mode” so it can accept multiple MAC addresses from single host OS NIC.

The application inside the container binds ports directly on the ipvlan ip, there is no port mapping (=published port) between host and container port.

If you are lucky, the image supports port change by environment variable, or mapping configurations into the container as volume. if both do not apply, look for another image for the same service or build your own.

Like I wrote: there is no port publishing involved with ipvlan/macvlan.

If your host is on a different machine than the container, and network wise the ipvlan ip can be reached from the host, e.g. is routed to on vlan15, it should work. Docker does not block the traffic in any way.

My container and host are on the same machine, I ssh’d into the docker host and from cli tried to ping the container ipvlan ip and got no response. In addition on the same network ( I hooked up a Macbook Pro and tried to ping the container ipvlan ip and got no response.

Even though the docker run ipvlan command ran successfully for nginx deployment, I think something is still wrong. I think Docker PS command should’ve shown what port nginx is listening to.

*Don’t know what other trouble shooting steps I can do :frowning_face:, *
*Hopefully someone in the docker community with similar interest and same setup as me tried IPvlan 802.1q trunk L2 mode and can provide feedback if it worked for them. *
As the docker article mentioned this ipvlan “is a new twist” not mature yet, likely the reason why there isn’t much trouble shooting, feedback and deployment documentation available.