Manually Creating 802.1Q VLAN Links for Docker Networks

valid_lft forever preferred_lft forever inet6 2001:db8:abc4::250:56ff:fe2b:2940/64 scope link valid_lft forever preferred_lft forever inet6 2001:db8:abc6::10/64 scope link nodad valid_lft forever preferred_lft forever # Note the default route is the eth device because ARPs are filtered. $$ ip route default dev eth0 scope link 192.168.112.0/24 dev eth0 proto kernel scope link src 192.168.112.2 $$ ip -6 route 2001:db8:abc4::/64 dev eth0 proto kernel metric 256 2001:db8:abc6::/64 dev eth0 proto kernel metric 256 default dev eth0 metric 1024 ``` > [!NOTE] > > There may be a bug when specifying `--ip6=` addresses when you delete a > container with a specified v6 address and then start a new container with the > same v6 address it throws the following like the address isn't properly being > released to the v6 pool. It will fail to unmount the container and be left dead. ```console docker: Error response from daemon: Address already in use. ``` ### Manually create 802.1Q links #### VLAN ID 40 If a user does not want the driver to create the VLAN sub-interface, it needs to exist before running `docker network create`. If you have sub-interface naming that is not `interface.vlan_id` it is honored in the `-o parent=` option again as long as the interface exists and is up. Links, when manually created, can be named anything as long as they exist when the network is created. Manually created links do not get deleted regardless of the name when the network is deleted with `docker network rm`. ```console # create a new sub-interface tied to dot1q vlan 40 $ ip link add link eth0 name eth0.40 type vlan id 40 # enable the new sub-interface $ ip link set eth0.40 up # now add networks and hosts as you would normally by attaching to the master (sub)interface that is tagged $ docker network create -d ipvlan \ --subnet=192.168.40.0/24 \ --gateway=192.168.40.1 \ -o parent=eth0.40 ipvlan40 # in two separate terminals, start a Docker container and the containers can now ping one another. $ docker run --net=ipvlan40 -it --name ivlan_test5 --rm alpine /bin/sh $ docker run --net=ipvlan40 -it --name ivlan_test6 --rm alpine /bin/sh ``` Example: VLAN sub-interface manually created with any name: ```console # create a new sub interface tied to dot1q vlan 40 $ ip link add link eth0 name foo type vlan id 40 # enable the new sub-interface $ ip link set foo up # now add networks and hosts as you would normally by attaching to the master (sub)interface that is tagged $ docker network create -d ipvlan \ --subnet=192.168.40.0/24 --gateway=192.168.40.1 \ -o parent=foo ipvlan40 # in two separate terminals, start a Docker container and the containers can now ping one another. $ docker run --net=ipvlan40 -it --name ivlan_test5 --rm alpine /bin/sh $ docker run --net=ipvlan40 -it --name ivlan_test6 --rm alpine /bin/sh ``` Manually created links can be cleaned up with: ```console $ ip link del foo ``` As with all of the Libnetwork drivers, they can be mixed and matched, even as far as running 3rd party ecosystem drivers in parallel for maximum flexibility to the Docker user.

This section explains how to manually create 802.1Q VLAN sub-interfaces before creating Docker networks. It describes how to create and enable a VLAN sub-interface using `ip link`, and then create an IPvlan network that utilizes this manually created interface. The section also demonstrates that custom names for the VLAN sub-interfaces are honored as long as the interface exists and is up before creating the Docker network. It further details how to remove manually created links. Finally, it mentions that Libnetwork drivers can be mixed and matched, even running alongside third-party ecosystem drivers.