veth pairs are a reasonable default for simple single-host connectivity (it's the default for Docker, for example). But for high-throughput production deploymen

veth pairs are a reasonable default for simple single-host connectivity (it's the default for Docker, for example). But for high-throughput production deployments where latency matters, you may need to look at other options. This is what we most commonly see when Docker is deployed in production (note that the lesson applies to any orchestration system based on linux containers, not just Docker): - Sometimes people dedicate a whole physical interface for the sole use of a container, by moving it into the namespace. The downside is that the interface is completely unavailable to other namespaces, including the host. - macvlan is pretty popular, it allows multiple containers to share access of the same physical interface, without conflicts and without the performance overhead of a veth+bridge combination. - you can also connect your container to an overlay network using a variety of tunneling systems. vxlan is the flavor du jour but there is a flurry of competing standards and implementations in that area. By far the coolest part about container networking on Linux is that it's just regular linux networking. The entire stack, and all the tooling that comes with it, is available to containers. You just need to glue it together. And of course these options are not mutually exclusive: a namespace can contain as many network interfaces as you want. Disclaimer: I am not a networking expert, but a lot of networking experts want their favorite toys natively integrated into Docker, so they take the time to explain to me how they work.