Website under construction

Figure 3-11:
Containers network connectivity 

---

103 
CHAPTER 3 | Application platform 
As Figure 3-11 demonstrates, each container will connect via vNIC (Windows Server container) or a 
vmNIC (Hyper-V container) to the vSwitch configured in a host. Each vNIC is isolated from the next 
and is considered its own compartment. These vNICs connect to the vSwitch by ports (much like 
Hyper-V). The Physical Host vNIC is isolated from the containers. Network connectivity to Hyper-V 
containers is transparent to the utility VM through the vmNIC. 
External connectivity is provided in a number of ways. Each one depends on the scenario you are 
using for containers. For example, if you want to offer a container environment for developers, 
Network Address Translation (NAT) is the best option for container network. It provides a private IP 
space (IPs issued via DHCP) that is isolated from the outside world. It restricts cross-container 
connectivity but does give you the ability to port forward into the container environment with which 
you are working. Any traffic arriving on the public NAT IP (the external NIC IP of the host) will be 
compared to a table managed via WinNAT and forwarded into the container. 
If the developers or the business required a small deployment and required that the containers sit on 
the corporate IP space, you can use transparent networking for containers. This just uses (via DHCP or 
Static Assignment) your existing IP space to assign IPs to the containers you run. If you do not use 
DHCP, you are unable to set a Gateway IP address. In transparent networking, containers can 
communicate with one another and external services like SQL and so on. 
Finally, if you are looking at cloud-scale deployments, we can use Layer 2 (L2) tunneling or an L2 
bridge. Both are essentially network virtualization for containers that make it possible for you to fully 
isolate traffic across a multinode deployment of containers in a datacenter. 
In L2 bridge mode, the Virtual Filtering Platform (VFP) vSwitch extension in the container host will act 
as a bridge and perform Media Access Control (MAC) address rewrite as required. Layer 3 (L3) or 
Layer 4 (L4) remain unchanged. 
You use L3 tunnel mode when you require a network policy in a cloud deployment scenario. The 
external vSwitch provides all the connectivity options for the container. All container traffic is 
forwarded through the physical host and the MAC address is rewritten before entering the network 
fabric. 
By default, Docker will try to bind to NAT networking, if it does not find a NAT network to bind to, it 
will attempt to create one. Any containers created after this will attach to the NAT network for 
connectivity. You can override this default behavior by running the following, for example: 
Docker -b "none" 
The 
"none"
represents the name of a network; 
-b
represents bridge. In this case, we are not attaching 
to anything. 
To create to a transparent network, you could use the following: 
Docker network create -d transparent -gateway 192.168.0.254 "TransparentNET"