Different ways of passing NICs to containers - and their limitations

02510170{width=”640” height=”425”}

NICs are needed inside containers. By default docker is adding a single linkl to a container. Somtimes tho, you want more links inside the container. There are several ways to do this:

  • Use veths and bridges
  • Use macvlans
  • Use --net=host
  • Move individual NICs into the containers network namespace

There are likely more ways to do this, but the ones above are the ones I looked at up to now.

Considering that --net=host put’s alll host sided NICs into the container, you might wonder why I investigated the other methods. The reason is that --net=host breaks the isolation between the host and container badly, and also has an effect on the network connectivity of other containers on the network.

So I’m looking for a less desruptive way to have more NICs inside the container. veths and macvlans have the advantage that they are virtual, and can be added and handled easily, and provide a clean separation between the physical NICs and the NICs inside the container. The drawbacks are potential performance issues, also the functionality (ethtool …) is limited. ethtool will only see a virtual NIC, and can not configure stuff like offloading - because that is only available on the physical NIC. It is also questionable if fancy network layouts inside the container (bonds, bridges, …) will work as expected.

--het=host and moving individual NICs into the containers network namespace has the advantage that the container can operate on the real NICs. I’d expect less performance and functional issues as we operate on the real physical NIC. The drawback however is that with --net=host we break the hosts connectivity and interfere with other containers. The drawback of moving individual NICs is, that it’s sometimes not easy to decide in an automated way, what NICs to move into a container. I.e. think of the LABEL install … convention to install containers using the atomic command, which would move the NICs between namespaces, would need to decide which NICs to move.

We see there are - as often - many ways to achieve something, but it needs to eb carefully considered what approach suits the individual usecase.

::: {#footer} [ May 7th, 2015 8:31am ]{#timestamp} [fedora]{.tag} [docker]{.tag} [network]{.tag} [macvlan]{.tag} [veth]{.tag} [bridge]{.tag} [bond]{.tag} [atomic]{.tag} [container]{.tag} :::