switches and other components are automatically configured via the Docker network
configurations performed. If you have a Linux background, the management actions
are the same—it is the underlying implementation that is different. Linux enables
network connectivity through a Linux bridge device that is really just a connection
from a physical NIC to a virtual Ethernet pair, which is not as feature rich as the
Hyper-V virtual switch. For isolation, Linux has namespaces, which is not a universal
feature in Windows, so instead each component in Windows implements its own
isolation feature, which in the case of networking is the network compartment.
Three modes are available for container networking:
NAT This is the simplest option, and it is the default. It is aimed at developers and
smaller deployments utilizing the IP address of the container host OS and then
using Network Address Translation to enable the private IP range used for the
container instances to communicate to the external network. Port forwarding rules
can be used to enable ports on the container host to map to ports on specific
containers. If NAT is utilized, the virtual switch is an internal type, and it then
connects via another host vNIC that is assigned the IP address selected as the
gateway IP for the private network, which then utilizes WinNAT to provide the
address translation and connectivity via the TCP/IP stack in the container host that
has external connectivity. This is shown in Figure 10.4, where both Windows
containers and Hyper-V containers share networking, with the only difference
being that a Hyper-V container uses a vmNIC instead of a host vNIC, and it does
not require a network compartment because the container is already isolated in its
own network stack, since it runs inside its own VM.