Exploring Docker Networking – Host, None, and MACVLAN

None

The none driver is pretty straightforward with one little twist.  You might imagine with a name like None that you’d get something like this:

nonenetworkwrong

Let’s spin up a container and check things out.

[root@dockernet2 ~]# docker run -dit --network=none centos

Now I’ve got a CentOS container with the name “loving_hodgkin” on the None network.

If we inspect the None network:

[root@dockernet2 ~]# docker network inspect none
[
 {
 "Name": "none",
 "Id": "b0cf5ba8b44d67f936ce40ee48e8b36ca2026f9d8c934a875c3f4ed65f6ade63" ,
 "Created": "2017-08-01T16:20:18.738820212-04:00",
 "Scope": "local",
 "Driver": "null",
 "EnableIPv6": false,
 "IPAM": {
 "Driver": "default",
 "Options": null,
 "Config": []
 },
 "Internal": false,
 "Attachable": false,
 "Ingress": false,
 "ConfigFrom": {
 "Network": ""
 },
 "ConfigOnly": false,
 "Containers": {
 "bf263fe11819d273dfefdcce1a370d360b7a3be6f3e05c6ef1c64febc9b2410a": {
 "Name": "loving_hodgkin",
 "EndpointID": "720f3d83bc799c3a4569cadb1e4db2fc67079b119c758ddec 1c6e1f45306c81b",
 "MacAddress": "",
 "IPv4Address": "",
 "IPv6Address": ""
 }
 },
 "Options": {},
 "Labels": {}
 }
]

See again that the IPAM section is empty as we’d expect. We see the container attached to the network but no MAC, IP, etc.  Again this is probably expected.

We see the twist in this docker inspect portion:

"NetworkSettings": {
 "Bridge": "",
 "SandboxID": "eedcddb9e5e20750c6fab5c88b200b3494959744304f361124efaf5eed17730a",
 "HairpinMode": false,
 "LinkLocalIPv6Address": "",
 "LinkLocalIPv6PrefixLen": 0,
 "Ports": {},
 "SandboxKey": "/var/run/docker/netns/eedcddb9e5e2",

This actually uses a created network namespace, not the default.  Because I’ve already softlinked things properly I can list this network namespace:

[root@dockernet2 ~]# ip netns list
eedcddb9e5e2
default

And I can exec against this namespace to see the interfaces inside the container.

[root@dockernet2 ~]# ip netns exec eedcddb9e5e2 ip addr show
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

If you continue to spin up new containers on the None network, they will all have distinct, isolated namespaces.

So the configuration actually looks like this:

nonenetworkright

Each container has a network namespace and a local loopback interface, but nothing else.  Important distinction from bridge is that there is no veth pairing for these namespaces so they are fully isolated from each other and from the host.  Remember that without the pairing mechanism you can’t bridge namespaces.

Not a ton of use cases for this.  Maybe you want to build something out disconnected and then attach it later.  Maybe you need to disconnect a container from the main network.  Maybe you have a container that isn’t intended to ever be connected to a network.  Or maybe even you don’t need or want Docker managing your network and you want to do it yourself.  Again I don’t see this being used a lot but it is there if you need it.

Finally up next and the meatiest portion of this post, MACVLAN.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s