%3CLINGO-SUB%20id%3D%22lingo-sub-1180923%22%20slang%3D%22en-US%22%3EL2bridge%20Container%20Networking%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1180923%22%20slang%3D%22en-US%22%3E%3CP%3E%3CSTRONG%3EOverview%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EContainers%20attached%20to%20a%20l2bridge%20network%20will%20be%20directly%20connected%20to%20the%20physical%20network%20through%20an%26nbsp%3Bexternal%26nbsp%3BHyper-V%20switch.%20L2bridge%20networks%20can%20be%20configured%20with%20the%20same%20IP%20subnet%20as%20the%20container%20host%2C%20with%20IPs%20from%20the%20physical%20network%20assigned%20statically.%20L2bridge%20networks%20can%20also%20be%20configured%20using%20a%20custom%20IP%20subnet%20through%20a%20HNS%20host%20endpoint%20that%20is%20configured%20as%20a%20gateway.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EIn%20l2bridge%2C%20all%20container%20frames%20will%20have%20the%20same%20MAC%20address%20as%20the%20host%20due%20to%20Layer-2%20address%20translation%20(MAC%20re-write)%20operation%20on%20ingress%20and%20egress.%20For%20larger%2C%20cross-host%20container%20deployments%2C%20this%20helps%20reduce%20the%20stress%20on%20switches%20having%20to%20learn%20MAC%20addresses%20of%20sometimes%20short-lived%20containers.%20Whenever%20container%20hosts%20are%20virtualized%2C%20this%20comes%20with%20the%20additional%20advantage%20that%20we%20do%20not%20need%20to%20enable%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fvirtualization%2Fhyper-v-on-windows%2Fuser-guide%2Fnested-virtualization%23mac-address-spoofing%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3EMAC%20address%20spoofing%3C%2FA%3E%20on%20the%20VM%20NICs%20of%20the%20container%20hosts%20for%20container%20traffic%20to%20reach%20destinations%20outside%20of%20their%20host.%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22overview.png%22%20style%3D%22width%3A%20523px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F172381iAE6E20D3FB9C92D7%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20title%3D%22overview.png%22%20alt%3D%22Reference%20l2bridge%20network%22%20%2F%3E%3CSPAN%20class%3D%22lia-inline-image-caption%22%20onclick%3D%22event.preventDefault()%3B%22%3EReference%20l2bridge%20network%3C%2FSPAN%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3EThere%20are%20several%20networking%20scenarios%20that%20are%20essential%20to%20successfully%20containerize%20and%20connect%20a%20distributed%20set%20of%20services%2C%20such%20as%3A%3C%2FP%3E%0A%3COL%3E%0A%3CLI%3EOutbound%20connectivity%20(Internet%20access)%3C%2FLI%3E%0A%3CLI%3EDNS%20resolution%3C%2FLI%3E%0A%3CLI%3EContainer%20name%20resolution%3C%2FLI%3E%0A%3CLI%3EHost%20to%20container%20connectivity%20(and%20vice%20versa)%3C%2FLI%3E%0A%3CLI%3EContainer%20to%20container%20connectivity%20(local)%3C%2FLI%3E%0A%3CLI%3EContainer%20to%20container%20connectivity%20(remote)%3C%2FLI%3E%0A%3CLI%3EBinding%20container%20ports%20to%20host%20ports%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3CP%3EWe%20will%20be%20showing%20all%20the%20above%20on%20l2bridge%20and%20briefly%20touch%20on%20some%20more%20advanced%20use-cases%3A%3C%2FP%3E%0A%3COL%20start%3D%228%22%3E%0A%3CLI%3ECreating%20an%20HNS%20container%20load%20balancer%3C%2FLI%3E%0A%3CLI%3EDefining%20and%20applying%20network%20access%20control%20lists%20(ACLs)%20to%20container%20endpoints%3C%2FLI%3E%0A%3CLI%3EAttaching%20multiple%20NICs%20to%20a%20single%20container%3C%2FLI%3E%0A%3C%2FOL%3E%0A%3CDIV%20id%3D%22tinyMceEditorDavid%20Schott_0%22%20class%3D%22mceNonEditable%20lia-copypaste-placeholder%22%3E%26nbsp%3B%3C%2FDIV%3E%0A%3CP%3E%3CSTRONG%3EPre-requisites%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EIn%20order%20to%20follow%20along%2C%202x%20Windows%20Server%20machines%20(Windows%20Server%2C%20version%201809%20or%20above)%20are%20required%20with%3A%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3EContainers%20feature%20and%20container%20runtime%20(e.g.%20Docker)%20installed%3C%2FLI%3E%0A%3CLI%3EHNS%20Powershell%20Helper%20Module%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CP%3ETo%20achieve%20this%2C%20run%20the%20following%20commands%20on%20the%20machines%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3EInstall-WindowsFeature%20-Name%20Containers%20-Restart%20%0AInstall-PackageProvider%20-Name%20NuGet%20-RequiredVersion%202.8.5.201%20-Force%0AInstall-Module%20-Name%20DockerMsftProvider%20-Repository%20PSGallery%20-Force%0AInstall-Package%20-Name%20Docker%20-ProviderName%20DockerMsftProvider%20-Force%0AStart-Service%20Docker%20%0AStart-BitsTransfer%20https%3A%2F%2Fgithub.com%2Fmicrosoft%2FSDN%2Fblob%2Fmaster%2FKubernetes%2Fwindows%2Fhns.psm1%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3ECreating%20an%20L2bridge%20network%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EMany%20of%20the%20needed%20policies%20to%20setup%20l2bridge%20are%20conveniently%20%3CA%20href%3D%22https%3A%2F%2Fgodoc.org%2Fgithub.com%2Fdocker%2Flibnetwork%2Fdrivers%2Fwindows%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Eexposed%3C%2FA%3E%20through%20Docker%E2%80%99s%20libnetwork%20driver%20on%20Windows.%3C%2FP%3E%0A%3CP%3EFor%20example%2C%20an%20l2bridge%20network%20of%20name%20%E2%80%9Cwinl2bridge%E2%80%9D%20with%20subnet%2010.244.3.0%2F24%20can%20be%20created%20as%20follows%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3Edocker%20network%20create%20-d%20l2bridge%20--subnet%3D10.244.3.0%2F24%20-o%20com.docker.network.windowsshim.dnsservers%3D10.127.130.7%2C10.127.130.8%20--gateway%3D10.244.3.1%20-o%20com.docker.network.windowsshim.enable_outboundnat%3Dtrue%20-o%20com.docker.network.windowsshim.outboundnat_exceptions%3D10.244.0.0%2F16%2C10.10.0.0%2F24%2C10.127.130.36%2F30%20winl2bridge%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThe%20available%20options%20for%20network%20creation%20are%20documented%20in%202%20locations%20(see%20%3CA%20href%3D%22https%3A%2F%2Fdocs.docker.com%2Fengine%2Freference%2Fcommandline%2Fnetwork_create%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3E%231%20here%3C%2FA%3E%20and%20%3CA%20href%3D%22https%3A%2F%2Fgodoc.org%2Fgithub.com%2Fdocker%2Flibnetwork%2Fdrivers%2Fwindows%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3E%232%20here%3C%2FA%3E)%20but%20here%20is%20a%20table%20breaking%20down%20all%20the%20arguments%20used%3A%3C%2FP%3E%0A%3CTABLE%20border%3D%221%22%20width%3D%22100%25%22%3E%0A%3CTBODY%3E%0A%3CTR%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%2227px%22%3E%3CSTRONG%3EName%3C%2FSTRONG%3E%3C%2FTD%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%2227px%22%3E%3CSTRONG%3EDescription%3C%2FSTRONG%3E%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3CTR%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%2254px%22%3E%0A%3CP%3E%3CFONT%20color%3D%22%233366FF%22%3E-d%3C%2FFONT%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%2254px%22%3E%0A%3CP%3EType%20of%20driver%20to%20use%20for%20network%20creation%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3CTR%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%2254px%22%3E%0A%3CP%3E%3CFONT%20color%3D%22%233366FF%22%3E--subnet%3C%2FFONT%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%2254px%22%3E%0A%3CP%3ESubnet%20range%20to%20use%20for%20network%20in%20CIDR%20notation%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3CTR%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%2254px%22%3E%0A%3CP%3E%3CFONT%20color%3D%22%233366FF%22%3E-o%20com.docker.network.windowsshim.dnsservers%3C%2FFONT%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%2254px%22%3E%0A%3CP%3EList%20of%20DNS%20servers%20to%20assign%20to%20containers.%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3CTR%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%2227px%22%3E%0A%3CP%3E%3CFONT%20color%3D%22%233366FF%22%3E--gateway%3C%2FFONT%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%2227px%22%3E%0A%3CP%3EIPv4%20Gateway%20of%20the%20assigned%20subnet.%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3CTR%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%22107px%22%3E%0A%3CP%3E%3CFONT%20color%3D%22%233366FF%22%3E-o%20com.docker.network.windowsshim.enable_outboundnat%3C%2FFONT%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%22107px%22%3E%0A%3CP%3EApply%20outbound%20NAT%20HNS%20policy%20to%20container%20vNICs%2Fendpoints.%20All%20traffic%20from%20the%20container%20will%20be%20SNAT%E2%80%99ed%20to%20the%20host%20IP.%20If%20the%20container%20subnet%20is%20not%20routable%2C%20this%20policy%20is%20needed%20for%20containers%20to%20reach%20destinations%20outside%20of%20their%20own%20respective%20subnet.%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3CTR%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%22187px%22%3E%0A%3CP%3E%3CFONT%20color%3D%22%233366FF%22%3E-o%20com.docker.network.windowsshim.outboundnat_exceptions%3C%2FFONT%3E%3C%2FP%3E%0A%3C%2FTD%3E%0A%3CTD%20width%3D%2250%25%22%20height%3D%22187px%22%3E%0A%3CP%3EList%20of%20destination%20IP%20ranges%20in%20CIDR%20notation%20where%20NAT%20operations%20will%20be%20skipped.%20This%20will%20typically%20include%20the%20container%20subnet%20(e.g.%2010.244.0.0%2F16)%2C%20load%20balancer%20subnet%20(e.g.%2010.10.0.0%2F24)%2C%20and%20a%20range%20for%20the%20container%20hosts%20(e.g.%2010.127.130.36%2F30).%3C%2FP%3E%0A%3C%2FTD%3E%0A%3C%2FTR%3E%0A%3C%2FTBODY%3E%0A%3C%2FTABLE%3E%0A%3CP%3E%3CSTRONG%3E%3CFONT%20color%3D%22%23FF0000%22%3EIMPORTANT%3A%3C%2FFONT%3E%3C%2FSTRONG%3E%20Usually%2C%20l2bridge%20requires%20that%20the%20specified%20gateway%20(%E2%80%9C10.244.3.1%E2%80%9D)%20exists%20somewhere%20in%20the%20network%20infrastructure%20and%20that%20the%20gateway%20provides%20proper%20routing%20for%20our%20designated%20prefix.%20We%20will%20be%20showing%20an%20alternative%20approach%20where%20we%20will%20create%20an%20HNS%20endpoint%20on%20the%20host%20from%20scratch%20and%20configure%20it%20so%20that%20it%20acts%20as%20a%20gateway.%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3E%3CFONT%20color%3D%22%23FF6600%22%3ENOTE%3A%3C%2FFONT%3E%3C%2FSTRONG%3E%20You%20may%20see%20a%20network%20blip%20for%20a%20few%20seconds%20while%20the%20vSwitch%20is%20being%20created%20for%20the%20first%20l2bridge%20network.%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3E%3CFONT%20color%3D%22%23339966%22%3ETIP%3A%3C%2FFONT%3E%3C%2FSTRONG%3E%20You%20can%20create%20multiple%20l2bridge%20networks%20on%20top%20of%20a%20single%20vSwitch%2C%20%E2%80%9Cconsuming%E2%80%9D%20only%20one%20NIC.%20It%20is%20even%20possible%20to%20isolate%20the%20networks%20by%20VLAN%20using%20-o%20com.docker.network.windowsshim.vlanid%20flag.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ENext%2C%20we%20will%20enable%20forwarding%20on%20the%20host%20vNIC%20and%20setup%20a%20host%20endpoint%20as%20a%20quasi%20gateway%20for%20the%20containers%20to%20use.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3E%23%20Import%20HNS%20Powershell%20module%0Aipmo%20.%5Chns.psm1%0A%23%20Enable%20forwarding%0Anetsh%20int%20ipv4%20set%20int%20%22vEthernet%20(Ethernet)%22%20for%3Den%0A%24network%20%3D%20get-hnsnetwork%20%7C%20%3F%20Name%20-Like%20%24(docker%20network%20inspect%20--format%3D'%7B%7B.ID%7D%7D'%20winl2bridge)%0A%23%20Create%20default%20gateway%20(need%20to%20use%20x.x.x.2%20as%20x.x.x.1%20is%20already%20reserved)%0A%24hnsEndpoint%20%3D%20New-HnsEndpoint%20-NetworkId%20%24network.ID%20-Name%20cbr0_ep%20-IPAddress%2010.244.3.2%20-Verbose%20%0A%23%20Attach%20gateway%20endpoint%20to%20host%20network%20compartment%0AAttach-HnsHostEndpoint%20-EndpointID%20%24hnsEndpoint.Id%20-CompartmentID%201%20%0A%23%20Enable%20forwarding%20for%20default%20gateway%0Anetsh%20int%20ipv4%20set%20int%20%22vEthernet%20(cbr0_ep)%22%20for%3Den%20%0Anetsh%20int%20ipv4%20add%20neighbors%20%22vEthernet%20(cbr0_ep)%22%20%2210.244.3.1%22%20%2200-01-e8-8b-2e-4b%22%0A%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CFONT%20color%3D%22%23FF6600%22%3E%3CSTRONG%3ENOTE%3A%20%3C%2FSTRONG%3E%3C%2FFONT%3EThe%20last%20netsh%20command%20above%20would%20not%20be%20needed%20if%20we%20supplied%20a%20proper%20gateway%20that%20exists%20in%20the%20network%20infrastructure%20at%20network%20creation.%20Since%20we%20created%20a%20host%20endpoint%20to%20use%20in%20place%20of%20a%20gateway%2C%20we%20need%20to%20add%20a%20static%20ARP%20entry%20with%20a%20dummy%20MAC%20so%20that%20traffic%20is%20able%20to%20leave%20our%20host%20without%20being%20stuck%20waiting%20for%20an%20ARP%20probe%20to%20resolve%20this%20gateway%20IP.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThis%20is%20all%20that%20is%20needed%20to%20setup%20a%20local%20l2bridge%20container%20network%20with%20working%20outbound%20connectivity%2C%20DNS%20resolution%2C%20and%20of%20course%20container%20to%20container%20and%20container%20to%20host%20connectivity.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3EMulti-host%20Deployment%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EOne%20of%20the%20most%20compelling%20reasons%20for%20using%20l2bridge%20is%20the%20ability%20to%20connect%20containers%20not%20only%20on%20the%20local%20machine%2C%20but%20also%20with%20remote%20machines%20to%20form%20a%20network.%20For%20communication%20across%20container%20hosts%2C%20one%20needs%20to%20plumb%20static%20routes%20so%20that%20each%20host%20knows%20where%20a%20given%20container%20lives.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EFor%20demonstration%2C%20assume%20there%20are%202%20container%20host%20machines%20(Host%20%E2%80%9CA%E2%80%9D%2C%20Host%20%E2%80%9CB%E2%80%9D)%20with%20IP%2010.127.132.38%20and%2010.127.132.36%20and%20container%20subnets%2010.244.2.0%2F24%20and%2010.244.3.0%2F24%20respectively.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22l2bridge_internode.gif%22%20style%3D%22width%3A%20999px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F172382i52E7C44E0E9811C3%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20title%3D%22l2bridge_internode.gif%22%20alt%3D%22Static%20routes%20for%20cross-node%20l2bridge%20container%20connectivity%22%20%2F%3E%3CSPAN%20class%3D%22lia-inline-image-caption%22%20onclick%3D%22event.preventDefault()%3B%22%3EStatic%20routes%20for%20cross-node%20l2bridge%20container%20connectivity%3C%2FSPAN%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ETo%20realize%20connecting%20containers%20across%20the%202%20hosts%2C%20the%20following%20commands%20would%20need%20to%20be%20executed%20on%20host%20A%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3ENew-NetRoute%20-InterfaceAlias%20%22vEthernet%20(Ethernet)%22%20-DestinationPrefix%2010.244.3.0%2F24%20-NextHop%2010.127.132.36%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ESimilarly%2C%20on%20host%20B%20the%20following%20also%20needs%20to%20be%20executed%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3ENew-NetRoute%20-InterfaceAlias%20%22vEthernet%20(Ethernet)%22%20-DestinationPrefix%2010.244.2.0%2F24%20-NextHop%2010.127.132.38%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ENow%20l2bridge%20containers%20running%20both%20locally%20and%20on%20remote%20hosts%20can%20communicate%20with%20each%20other.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CFONT%20color%3D%22%23339966%22%3E%3CSTRONG%3ETIP%3A%3C%2FSTRONG%3E%3C%2FFONT%3E%20On%20public%20cloud%20platforms%2C%20one%20also%20needs%20to%20add%20these%20routes%20to%20the%20default%20system%E2%80%99s%20route%20table%2C%20so%20the%20underlying%20host%20cloud%20network%20knows%20how%20to%20forward%20packets%20with%20container%20IPs%20to%20the%20correct%20destination.%20For%20instance%20on%20Azure%2C%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fvirtual-network%2Fvirtual-networks-udr-overview%23user-defined%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Euser-defined%20routes%3C%2FA%3E%20of%20type%20%E2%80%9Cvirtual%20appliance%E2%80%9D%20would%20need%20to%20be%20added%20to%20the%20Azure%20virtual%20network.%20If%20host%20A%20and%20host%20B%20were%20VMs%20provisioned%20in%20an%20Azure%20resource%20group%20%E2%80%9C%24Rg%E2%80%9D%2C%20this%20could%20be%20done%20by%20issuing%20the%20following%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcli%2Fazure%2Finstall-azure-cli%3Fview%3Dazure-cli-latest%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Eaz%3C%2FA%3E%20commands%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3Eaz%20network%20route-table%20create%20--resource-group%20%24Rg%20--name%20BridgeRoute%20%0Aaz%20network%20route-table%20route%20create%20--resource-group%20%24Rg%20--address-prefix%2010.244.3.0%2F24%20--route-table-name%20BridgeRoute%20%20--name%20HostARoute%20--next-hop-type%20VirtualAppliance%20--next-hop-ip-address%2010.127.130.36%20%0Aaz%20network%20route-table%20route%20create%20--resource-group%20%24Rg%20--address-prefix%2010.244.2.0%2F24%20--route-table-name%20BridgeRoute%20%20--name%20HostBRoute%20--next-hop-type%20VirtualAppliance%20--next-hop-ip-address%2010.127.130.38%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3EStarting%20l2bridge%20containers%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EOnce%20all%20static%20routes%20have%20been%20updated%20and%20l2bridge%20network%20created%20on%20each%20host%2C%20it%20is%20simple%20to%20spin%20up%20containers%20and%20attach%20them%20to%20the%20l2bridge%20network.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EFor%20example%2C%20to%20spin%20up%20two%20IIS%20containers%20with%20ID%20%E2%80%9Cc1%E2%80%9D%2C%20%E2%80%9Cc2%E2%80%9D%20on%20container%20subnet%20with%20gateway%20%E2%80%9C10.244.3.1%E2%80%9D%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-markup%22%3E%3CCODE%3E%24array%20%3D%20%40(%22c1%22%2C%20%22c2%22)%0A%24array%20%7Cforeach%20%7B%0Adocker%20run%20-d%20--rm%20--name%20%24_%20--hostname%20%24_%20--network%20winl2bridge%20mcr.microsoft.com%2Fwindows%2Fservercore%2Fiis%3Awindowsservercore-ltsc2019%0Adocker%20exec%20%24_%20cmd%20%2Fc%20netsh%20int%20ipv4%20add%20neighbors%20%22Ethernet%22%20%2210.244.3.1%22%20%2200-01-e8-8b-2e-4b%22%0A%7D%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CFONT%20color%3D%22%23FF6600%22%3E%3CSTRONG%3ENOTE%3A%20%3C%2FSTRONG%3E%3C%2FFONT%3EThe%20last%20netsh%20command%20above%20would%20not%20be%20needed%20if%20we%20supplied%20a%20proper%20gateway%20that%20exists%20in%20the%20network%20infrastructure%20at%20network%20creation.%20Since%20we%20created%20a%20host%20endpoint%20to%20use%20in%20place%20of%20a%20gateway%2C%20we%20need%20to%20add%20a%20static%20ARP%20entry%20with%20a%20dummy%20MAC%20so%20that%20traffic%20is%20able%20to%20leave%20our%20host%20without%20being%20stuck%20waiting%20for%20an%20ARP%20probe%20to%20resolve%20this%20gateway%20IP.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EHere%20is%20a%20video%20demonstrating%20all%20the%20connectivity%20paths%20available%20after%20launching%20the%20containers%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3C%2FP%3E%3CDIV%20class%3D%22video-embed-center%20video-embed%22%3E%3CIFRAME%20class%3D%22embedly-embed%22%20src%3D%22https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Fsrc%3Dhttps%253A%252F%252Fwww.youtube.com%252Fembed%252FpRWCmqrYSBU%253Ffeature%253Doembed%26amp%3Bdisplay_name%3DYouTube%26amp%3Burl%3Dhttps%253A%252F%252Fwww.youtube.com%252Fwatch%253Fv%253DpRWCmqrYSBU%26amp%3Bimage%3Dhttps%253A%252F%252Fi.ytimg.com%252Fvi%252FpRWCmqrYSBU%252Fhqdefault.jpg%26amp%3Bkey%3Db0d40caa4f094c68be7c29880b16f56e%26amp%3Btype%3Dtext%252Fhtml%26amp%3Bschema%3Dyoutube%22%20width%3D%22400%22%20height%3D%22225%22%20scrolling%3D%22no%22%20title%3D%22YouTube%20embed%22%20frameborder%3D%220%22%20allow%3D%22autoplay%3B%20fullscreen%22%20allowfullscreen%3D%22true%22%3E%3C%2FIFRAME%3E%3C%2FDIV%3E%3CP%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3EPublishing%20container%20ports%20to%20host%20ports%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EOne%20feature%20to%20expose%20containerized%20applications%20and%20make%20them%20more%20available%20is%20to%20map%20container%20ports%20to%20an%20external%20port%20on%20the%20host.%3C%2FP%3E%0A%3CP%3EFor%20example%2C%20to%20map%20TCP%20container%20port%2080%20to%20the%20host%20port%208080%2C%20and%20assuming%20the%20container%20has%20respective%20endpoint%20with%20ID%20%E2%80%9C%3CFONT%20color%3D%22%233366FF%22%3E448c0e22-a413-4882-95b5-2d59091c11b8%3C%2FFONT%3E%E2%80%9D%20this%20can%20be%20achieved%20using%20an%20ELB%20policy%20as%20follows%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3Eipmo%20.%5Chns.psm1%0A%24publish_json%20%3D%20'%7B%0A%20%20%20%20%22References%22%3A%20%5B%0A%20%20%20%20%20%20%20%20%22%2Fendpoints%2F448c0e22-a413-4882-95b5-2d59091c11b8%22%0A%20%20%20%20%5D%2C%0A%20%20%20%20%22Policies%22%3A%20%5B%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Type%22%3A%20%22ELB%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22InternalPort%22%3A%2080%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22ExternalPort%22%3A%208080%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Protocol%22%3A%206%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%5D%0A%7D'%0AInvoke-HNSRequest%20-Method%20POST%20-Type%20policylists%20-Data%20%24publish_json%0A%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EHere%20is%20a%20video%20demonstrating%20how%20to%20apply%20the%20policy%20to%20bind%20a%20TCP%20container%20port%20to%20a%20host%20port%20and%20access%20it%3A%3C%2FP%3E%0A%3CP%3E%3C%2FP%3E%3CDIV%20class%3D%22video-embed-center%20video-embed%22%3E%3CIFRAME%20class%3D%22embedly-embed%22%20src%3D%22https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Fsrc%3Dhttps%253A%252F%252Fwww.youtube.com%252Fembed%252FXttEb0s3H9c%253Ffeature%253Doembed%26amp%3Bdisplay_name%3DYouTube%26amp%3Burl%3Dhttps%253A%252F%252Fwww.youtube.com%252Fwatch%253Fv%253DXttEb0s3H9c%26amp%3Bimage%3Dhttps%253A%252F%252Fi.ytimg.com%252Fvi%252FXttEb0s3H9c%252Fhqdefault.jpg%26amp%3Bkey%3Db0d40caa4f094c68be7c29880b16f56e%26amp%3Btype%3Dtext%252Fhtml%26amp%3Bschema%3Dyoutube%22%20width%3D%22400%22%20height%3D%22225%22%20scrolling%3D%22no%22%20title%3D%22YouTube%20embed%22%20frameborder%3D%220%22%20allow%3D%22autoplay%3B%20fullscreen%22%20allowfullscreen%3D%22true%22%3E%3C%2FIFRAME%3E%3C%2FDIV%3E%3CP%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3EAdvanced%3A%20Setting%20up%20Load%20Balancers%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EThe%20ability%20to%20distribute%20traffic%20across%20multiple%20containerized%20backends%20using%20a%20load%20balancer%20leads%20to%20higher%20scalability%20and%20reliability%20of%20applications.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EFor%20example%2C%20creating%20a%20load%20balancer%20with%20frontend%20virtual%20IP%20(VIP)%2010.10.0.10%3A8090%20on%20host%20A%20(IP%2010.127.130.36)%20and%20backend%20DIPs%20of%20all%20local%20containers%20can%20be%20achieved%20as%20follows%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3Eipmo%20.%5Chns.psm1%0A%5BGUID%5B%5D%5D%20%24endpoints%20%3D%20(Get-HNSEndpoint%20%7C%3F%20Name%20-Like%20%22Ethernet%22%20%7C%20Select%20ID).ID%0ANew-HNSLoadBalancer%20-Endpoints%20%24endpoints%20-InternalPort%2080%20-ExternalPort%208090%20-Vip%20%2210.10.0.10%22%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EFinally%2C%20for%20the%20load%20balancer%20to%20be%20accessible%20from%20inside%20the%20containers%2C%20we%20also%20need%20to%20add%20two%20encapsulation%20rules%20for%20every%20endpoint%20that%20needs%20to%20access%20the%20load%20balancer%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3E%24endpoints%20%7C%20foreach%20%7B%0A%24encap_lb%20%3D%20'%7B%0A%20%20%20%20%22References%22%3A%20%5B%0A%20%20%20%20%20%20%20%20%22%2Fendpoints%2F'%20%2B%20%24_%20%2B'%22%0A%20%20%20%20%5D%2C%0A%20%20%20%20%22Policies%22%3A%20%5B%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Type%22%3A%20%22ROUTE%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22DestinationPrefix%22%3A%20%2210.10.0.0%2F24%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22NeedEncap%22%3A%20true%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%5D%0A%7D'%0A%24encap_mgmt%20%3D%20'%7B%0A%20%20%20%20%22References%22%3A%20%5B%0A%20%20%20%20%20%20%20%20%22%2Fendpoints%2F'%20%2B%20%24_%20%2B'%22%0A%20%20%20%20%5D%2C%0A%20%20%20%20%22Policies%22%3A%20%5B%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Type%22%3A%20%22ROUTE%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22DestinationPrefix%22%3A%20%2210.127.130.36%2F32%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22NeedEncap%22%3A%20true%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%5D%0A%7D'%0AInvoke-HNSRequest%20-Method%20POST%20-Type%20policylists%20-Data%20%24encap_lb%0AInvoke-HNSRequest%20-Method%20POST%20-Type%20policylists%20-Data%20%24encap_mgmt%0A%7D%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EHere%20is%20a%20video%20showing%20how%20to%20create%20the%20load%20balancer%20and%20access%20it%20using%20its%20frontend%20VIP%20%2210.10.0.10%22%20from%20host%20and%20container%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3C%2FP%3E%3CDIV%20class%3D%22video-embed-center%20video-embed%22%3E%3CIFRAME%20class%3D%22embedly-embed%22%20src%3D%22https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Fsrc%3Dhttps%253A%252F%252Fwww.youtube.com%252Fembed%252FJLde-dLMRcg%253Ffeature%253Doembed%26amp%3Bdisplay_name%3DYouTube%26amp%3Burl%3Dhttps%253A%252F%252Fwww.youtube.com%252Fwatch%253Fv%253DJLde-dLMRcg%26amp%3Bimage%3Dhttps%253A%252F%252Fi.ytimg.com%252Fvi%252FJLde-dLMRcg%252Fhqdefault.jpg%26amp%3Bkey%3Db0d40caa4f094c68be7c29880b16f56e%26amp%3Btype%3Dtext%252Fhtml%26amp%3Bschema%3Dyoutube%22%20width%3D%22400%22%20height%3D%22225%22%20scrolling%3D%22no%22%20title%3D%22YouTube%20embed%22%20frameborder%3D%220%22%20allow%3D%22autoplay%3B%20fullscreen%22%20allowfullscreen%3D%22true%22%3E%3C%2FIFRAME%3E%3C%2FDIV%3E%3CP%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3EAdvanced%3A%20Setting%20up%20ACLs%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EWhat%20if%20instead%20of%20making%20applications%20more%20available%2C%20one%20needs%20to%20restrict%20traffic%20between%20containers%3F%20l2bridge%20networks%20are%20ideally%20suited%20for%20network%20access%20control%20lists%20(ACLs)%20that%20define%20policies%20which%20limit%20network%20access%20to%20only%20those%20workloads%20that%20are%20explicitly%20permitted.%3C%2FP%3E%0A%3CP%3EFor%20example%2C%20to%20allow%20inbound%20network%20access%20to%20TCP%20port%2080%20from%20IP%2010.244.3.75%20and%20block%20all%20other%20inbound%20traffic%20to%20container%20with%20endpoint%20%E2%80%9C%3CFONT%20color%3D%22%233366FF%22%3E448c0e22-a413-4882-95b5-2d59091c11b8%3C%2FFONT%3E%E2%80%9D%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3Eipmo%20.%5Chns.psm1%20%0A%24json%20%3D%20'%7B%0A%20%20%20%20%22Policies%22%3A%20%5B%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Type%22%3A%20%22ACL%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Action%22%3A%20%22Allow%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Direction%22%3A%20%22In%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22LocalAddresses%22%3A%20%22%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22RemoteAddresses%22%3A%20%2210.244.3.75%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22LocalPorts%22%3A%20%2280%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Protocol%22%3A%206%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Priority%22%3A%20200%0A%20%20%20%20%20%20%20%20%7D%2C%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Type%22%3A%20%22ACL%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Action%22%3A%20%22Block%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Direction%22%3A%20%22In%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Priority%22%3A%20300%0A%20%20%20%20%20%20%20%20%7D%2C%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Type%22%3A%20%22ACL%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Action%22%3A%20%22Allow%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Direction%22%3A%20%22Out%22%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Priority%22%3A%20300%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%5D%0A%7D'%20%0AInvoke-HNSRequest%20-Method%20POST%20-Type%20endpoints%20-Id%20%22448c0e22-a413-4882-95b5-2d59091c11b8%22%20-Data%20%24acl_json%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EHere%20is%20a%20video%20showing%20the%20ACL%20policy%20in%20action%20and%20how%20to%20apply%20it%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3C%2FP%3E%3CDIV%20class%3D%22video-embed-center%20video-embed%22%3E%3CIFRAME%20class%3D%22embedly-embed%22%20src%3D%22https%3A%2F%2Fcdn.embedly.com%2Fwidgets%2Fmedia.html%3Fsrc%3Dhttps%253A%252F%252Fwww.youtube.com%252Fembed%252FpMgx7mMb7no%253Ffeature%253Doembed%26amp%3Bdisplay_name%3DYouTube%26amp%3Burl%3Dhttps%253A%252F%252Fwww.youtube.com%252Fwatch%253Fv%253DpMgx7mMb7no%26amp%3Bimage%3Dhttps%253A%252F%252Fi.ytimg.com%252Fvi%252FpMgx7mMb7no%252Fhqdefault.jpg%26amp%3Bkey%3Db0d40caa4f094c68be7c29880b16f56e%26amp%3Btype%3Dtext%252Fhtml%26amp%3Bschema%3Dyoutube%22%20width%3D%22400%22%20height%3D%22225%22%20scrolling%3D%22no%22%20title%3D%22YouTube%20embed%22%20frameborder%3D%220%22%20allow%3D%22autoplay%3B%20fullscreen%22%20allowfullscreen%3D%22true%22%3E%3C%2FIFRAME%3E%3C%2FDIV%3E%3CP%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAccess%20control%20lists%20and%20Windows%20fire-walling%20is%20a%20very%20deep%20and%20complex%20topic.%20HNS%20supports%20more%20granular%20capabilities%20to%20implement%20network%20micro-segmentation%20and%20govern%20traffic%20flows%20than%20shown%20above.%20Most%20of%20these%20enhancements%20are%20available%20via%20%3CA%20href%3D%22https%3A%2F%2Fwww.tigera.io%2Ftigera-products%2Fcalico-for-windows%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3ETigera%E2%80%99s%20Calico%20for%20Windows%3C%2FA%3E%20product%20and%20will%20be%20incrementally%20documented%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-server%2Fnetworking%2Ftechnologies%2Fhcn%2Fhcn-top%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehere%3C%2FA%3E%20and%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fvirtualization%2Fwindowscontainers%2Fcontainer-networking%2Fnetwork-isolation-security%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehere%3C%2FA%3E.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3EAdvanced%3A%20Multi-NIC%20containers%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EAttaching%20multiple%20vNICs%20to%20a%20single%20container%20addresses%20various%20traffic%20segregation%20and%20operational%20concerns.%20For%20example%2C%20assume%20there%20are%20two%20VLAN-isolated%20L2bridge%20networks%20called%20%E2%80%9Cwinl2bridge_4096%E2%80%9D%20and%20%E2%80%9Cwinl2bridge_4097%E2%80%9D%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3E%23%20Create%20%E2%80%9Cwinl2bridge_4096%E2%80%9D%20with%20VLAN%20tag%204096%0Adocker%20network%20create%20-d%20l2bridge%20--subnet%3D10.244.4.0%2F24%20-o%20com.docker.network.windowsshim.dnsservers%3D10.127.130.7%20--gateway%3D10.244.4.1%20-o%20com.docker.network.windowsshim.enable_outboundnat%3Dtrue%20-o%20com.docker.network.windowsshim.outboundnat_exceptions%3D10.244.0.0%2F16%2C11.96.0.0%2F24%2C10.127.130.36%2F30%20-o%20com.docker.network.windowsshim.vlanid%3D4096%20winl2bridge_4096%0A%23%20Create%20%E2%80%9Cwinl2bridge_4097%E2%80%9D%20with%20VLAN%20tag%204097%0Adocker%20network%20create%20-d%20l2bridge%20--subnet%3D10.244.5.0%2F24%20-o%20com.docker.network.windowsshim.dnsservers%3D10.127.130.7%20--gateway%3D10.244.5.1%20-o%20com.docker.network.windowsshim.enable_outboundnat%3Dtrue%20-o%20com.docker.network.windowsshim.outboundnat_exceptions%3D10.244.0.0%2F16%2C11.96.0.0%2F24%2C10.127.130.36%2F30%20-o%20com.docker.network.windowsshim.vlanid%3D4097%20winl2bridge_4097%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAttaching%20a%20container%20to%20both%20networks%20can%20be%20done%20as%20follows%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3E%23%20Create%20container%20and%20attach%20to%20%E2%80%9Cwinl2bridge_4096%E2%80%9D%0Adocker%20run%20-d%20--rm%20--name%20%22multi_nic_container%22%20--network%20%22winl2bridge_4096%22%20mcr.microsoft.com%2Fwindows%2Fservercore%2Fiis%3Awindowsservercore-ltsc2019%20%0A%23%20Attach%20to%20%E2%80%9Cwinl2bridge_4097%E2%80%9D%0Adocker%20network%20connect%20%22winl2bridge_4097%22%20%22multi_nic_container%22%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ETo%20add%20more%20vNICs%2C%20we%20can%20create%20HNS%20endpoints%20under%20a%20given%20network%20and%20attach%20them%20to%20the%20container%E2%80%99s%20network%20compartment.%20For%20example%2C%20to%20add%20another%20NIC%20in%20network%20%E2%80%9Cwinl2bridge_4096%E2%80%9D%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%20class%3D%22lia-code-sample%20language-c%22%3E%3CCODE%3E%23%20Get%20compartment%20ID%0A%24compartmentId%20%3D%20docker%20exec%20%22multi_nic_container%22%20powershell.exe%20%22Get-NetCompartment%20%7C%20Select%20-ExpandProperty%20CompartmentId%22%0A%23%20Get%20HNS%20network%20ID%0A%24network%20%3D%20get-hnsnetwork%20%7C%20%3F%20Name%20-Like%20%24(docker%20network%20inspect%20--format%3D'%7B%7B.ID%7D%7D'%20winl2bridge_4096)%0A%23%20Create%20HNS%20endpoint%20under%20network%20%E2%80%9Cwinl2bridge_4096%E2%80%9D%0A%24hnsEndpoint%20%3D%20New-HnsEndpoint%20-NetworkId%20%24network.ID%20-Name%20my_ep%20-IPAddress%2010.244.4.10%20-Verbose%0A%23%20Attach%20endpoint%20to%20target%20container%E2%80%99s%20network%20compartment%0AAttach-HnsHostEndpoint%20-EndpointID%20%24hnsEndpoint.Id%20-CompartmentID%20%24compartmentId%3C%2FCODE%3E%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EBy%20executing%20all%20the%20above%2C%20a%20single%20container%20has%20three%20vNICs%20ready%20to%20use%20now%20(two%20in%20%E2%80%9Cwinl2bridge_4096%E2%80%9D%2C%20one%20from%20%E2%80%9Cwinl2bridge_4097%E2%80%9D).%20Every%20endpoint%20may%20have%20different%20policies%20and%20configurations%20specifically%20tailored%20to%20meet%20the%20needs%20of%20the%20application%20and%20business.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22multi_nic_container.png%22%20style%3D%22width%3A%20684px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Fgxcuf89792.i.lithium.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F172616i8D31866D2F33C235%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20title%3D%22multi_nic_container.png%22%20alt%3D%22Container%20with%20multiple%20endpoints%20belonging%20to%20two%20different%20networks%22%20%2F%3E%3CSPAN%20class%3D%22lia-inline-image-caption%22%20onclick%3D%22event.preventDefault()%3B%22%3EContainer%20with%20multiple%20endpoints%20belonging%20to%20two%20different%20networks%3C%2FSPAN%3E%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CSTRONG%3ESummary%3C%2FSTRONG%3E%3C%2FP%3E%0A%3CP%3EWe%20have%20covered%20several%20supported%20capabilities%20of%20l2bridge%20container%20networking%2C%20including%3A%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3ECross-host%20container%20communication%20(not%20possible%20via%20WinNAT)%3C%2FLI%3E%0A%3CLI%3ELogical%20separation%20of%20networks%20by%20VLANs%3C%2FLI%3E%0A%3CLI%3EMicro-segmentation%20using%20ACLs%3C%2FLI%3E%0A%3CLI%3ELoad%20balancers%3C%2FLI%3E%0A%3CLI%3EBinding%20container%20ports%20to%20host%20ports%3C%2FLI%3E%0A%3CLI%3EAttaching%20multiple%20network%20adapters%20to%20containers%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CP%3EL2bridge%20networks%20require%20upfront%20configuration%20to%20install%20correctly%20but%20offers%20many%20useful%20features%20as%20well%20as%20enhanced%20performance%20and%20control%20of%20the%20container%20network.%20It%20is%20always%20recommended%20to%20leverage%20orchestrators%20such%20as%20Kubernetes%20which%20utilize%20CNI%20plugins%20to%20streamline%20and%20automate%20many%20of%20these%20configuration%20tasks%2C%20while%20still%20rewarding%20advanced%20users%20with%20a%20similar%20level%20of%20configurability.%20All%20of%20the%20HNS%20APIs%20used%20above%20and%20much%20more%20are%20also%20open-source%20in%20a%20Golang%20shim%20(see%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fhcsshim%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehcsshim%3C%2FA%3E).%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAs%20always%2C%20thanks%20for%20reading%20and%20please%20let%20us%20know%20about%20your%20scenarios%20or%20questions%20in%20the%20comments%20section%20below!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-1180923%22%20slang%3D%22en-US%22%3E%3CP%3EL2bridge%20networking%20is%20widely%20used%20in%20software-defined%20data%20centers%20thanks%20to%20its%20high%20configurability%2C%20performance%2C%20reliability%2C%20as%20well%20as%20inbox%20support%20for%20advanced%20scenarios%20such%20as%20network%20ACLs%20and%20container%20load%20balancers.%20This%20blog%20post%20will%20explain%20how%20to%20deploy%20l2bridge%20networks%20and%20which%20environments%20it%20is%20suitable%20for.%3C%2FP%3E%3C%2FLINGO-TEASER%3E
Microsoft

Overview

Containers attached to a l2bridge network will be directly connected to the physical network through an external Hyper-V switch. L2bridge networks can be configured with the same IP subnet as the container host, with IPs from the physical network assigned statically. L2bridge networks can also be configured using a custom IP subnet through a HNS host endpoint that is configured as a gateway.

 

In l2bridge, all container frames will have the same MAC address as the host due to Layer-2 address translation (MAC re-write) operation on ingress and egress. For larger, cross-host container deployments, this helps reduce the stress on switches having to learn MAC addresses of sometimes short-lived containers. Whenever container hosts are virtualized, this comes with the additional advantage that we do not need to enable MAC address spoofing on the VM NICs of the container hosts for container traffic to reach destinations outside of their host.

Reference l2bridge networkReference l2bridge network

There are several networking scenarios that are essential to successfully containerize and connect a distributed set of services, such as:

  1. Outbound connectivity (Internet access)
  2. DNS resolution
  3. Container name resolution
  4. Host to container connectivity (and vice versa)
  5. Container to container connectivity (local)
  6. Container to container connectivity (remote)
  7. Binding container ports to host ports

We will be showing all the above on l2bridge and briefly touch on some more advanced use-cases:

  1. Creating an HNS container load balancer
  2. Defining and applying network access control lists (ACLs) to container endpoints
  3. Attaching multiple NICs to a single container
 

Pre-requisites

In order to follow along, 2x Windows Server machines (Windows Server, version 1809 or above) are required with:

  • Containers feature and container runtime (e.g. Docker) installed
  • HNS Powershell Helper Module

To achieve this, run the following commands on the machines:

 

Install-WindowsFeature -Name Containers -Restart 
Install-PackageProvider -Name NuGet -RequiredVersion 2.8.5.201 -Force
Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
Install-Package -Name Docker -ProviderName DockerMsftProvider -Force
Start-Service Docker 
Start-BitsTransfer https://raw.githubusercontent.com/microsoft/SDN/master/Kubernetes/windows/hns.psm1

 

 

Creating an L2bridge network

Many of the needed policies to setup l2bridge are conveniently exposed through Docker’s libnetwork driver on Windows.

For example, an l2bridge network of name “winl2bridge” with subnet 10.244.3.0/24 can be created as follows:

 

docker network create -d l2bridge --subnet=10.244.3.0/24 -o com.docker.network.windowsshim.dnsservers=10.127.130.7,10.127.130.8 --gateway=10.244.3.1 -o com.docker.network.windowsshim.enable_outboundnat=true -o com.docker.network.windowsshim.outboundnat_exceptions=10.244.0.0/16,10.10.0.0/24,10.127.130.36/30 winl2bridge

 

 

The available options for network creation are documented in 2 locations (see #1 here and #2 here) but here is a table breaking down all the arguments used:

Name Description

-d

Type of driver to use for network creation

--subnet

Subnet range to use for network in CIDR notation

-o com.docker.network.windowsshim.dnsservers

List of DNS servers to assign to containers.

--gateway

IPv4 Gateway of the assigned subnet.

-o com.docker.network.windowsshim.enable_outboundnat

Apply outbound NAT HNS policy to container vNICs/endpoints. All traffic from the container will be SNAT’ed to the host IP. If the container subnet is not routable, this policy is needed for containers to reach destinations outside of their own respective subnet.

-o com.docker.network.windowsshim.outboundnat_exceptions

List of destination IP ranges in CIDR notation where NAT operations will be skipped. This will typically include the container subnet (e.g. 10.244.0.0/16), load balancer subnet (e.g. 10.10.0.0/24), and a range for the container hosts (e.g. 10.127.130.36/30).

IMPORTANT: Usually, l2bridge requires that the specified gateway (“10.244.3.1”) exists somewhere in the network infrastructure and that the gateway provides proper routing for our designated prefix. We will be showing an alternative approach where we will create an HNS endpoint on the host from scratch and configure it so that it acts as a gateway.

NOTE: You may see a network blip for a few seconds while the vSwitch is being created for the first l2bridge network.

TIP: You can create multiple l2bridge networks on top of a single vSwitch, “consuming” only one NIC. It is even possible to isolate the networks by VLAN using -o com.docker.network.windowsshim.vlanid flag.

 

Next, we will enable forwarding on the host vNIC and setup a host endpoint as a quasi gateway for the containers to use.

 

# Import HNS Powershell module
ipmo .\hns.psm1
# Enable forwarding
netsh int ipv4 set int "vEthernet (Ethernet)" for=en
$network = get-hnsnetwork | ? Name -Like $(docker network inspect --format='{{.ID}}' winl2bridge)
# Create default gateway (need to use x.x.x.2 as x.x.x.1 is already reserved)
$hnsEndpoint = New-HnsEndpoint -NetworkId $network.ID -Name cbr0_ep -IPAddress 10.244.3.2 -Verbose 
# Attach gateway endpoint to host network compartment
Attach-HnsHostEndpoint -EndpointID $hnsEndpoint.Id -CompartmentID 1 
# Enable forwarding for default gateway
netsh int ipv4 set int "vEthernet (cbr0_ep)" for=en 
netsh int ipv4 add neighbors "vEthernet (cbr0_ep)" "10.244.3.1" "00-01-e8-8b-2e-4b"

 

 

NOTE: The last netsh command above would not be needed if we supplied a proper gateway that exists in the network infrastructure at network creation. Since we created a host endpoint to use in place of a gateway, we need to add a static ARP entry with a dummy MAC so that traffic is able to leave our host without being stuck waiting for an ARP probe to resolve this gateway IP.

 

This is all that is needed to setup a local l2bridge container network with working outbound connectivity, DNS resolution, and of course container to container and container to host connectivity.

 

Multi-host Deployment

One of the most compelling reasons for using l2bridge is the ability to connect containers not only on the local machine, but also with remote machines to form a network. For communication across container hosts, one needs to plumb static routes so that each host knows where a given container lives.

 

For demonstration, assume there are 2 container host machines (Host “A”, Host “B”) with IP 10.127.132.38 and 10.127.132.36 and container subnets 10.244.2.0/24 and 10.244.3.0/24 respectively.

Static routes for cross-node l2bridge container connectivityStatic routes for cross-node l2bridge container connectivity

 

To realize connecting containers across the 2 hosts, the following commands would need to be executed on host A:

 

New-NetRoute -InterfaceAlias "vEthernet (Ethernet)" -DestinationPrefix 10.244.3.0/24 -NextHop 10.127.132.36

 

 

Similarly, on host B the following also needs to be executed:

 

New-NetRoute -InterfaceAlias "vEthernet (Ethernet)" -DestinationPrefix 10.244.2.0/24 -NextHop 10.127.132.38

 

 

Now l2bridge containers running both locally and on remote hosts can communicate with each other.

 

TIP: On public cloud platforms, one also needs to add these routes to the default system’s route table, so the underlying host cloud network knows how to forward packets with container IPs to the correct destination. For instance on Azure, user-defined routes of type “virtual appliance” would need to be added to the Azure virtual network. If host A and host B were VMs provisioned in an Azure resource group “$Rg”, this could be done by issuing the following az commands:

 

az network route-table create --resource-group $Rg --name BridgeRoute 
az network route-table route create --resource-group $Rg --address-prefix 10.244.3.0/24 --route-table-name BridgeRoute  --name HostARoute --next-hop-type VirtualAppliance --next-hop-ip-address 10.127.130.36 
az network route-table route create --resource-group $Rg --address-prefix 10.244.2.0/24 --route-table-name BridgeRoute  --name HostBRoute --next-hop-type VirtualAppliance --next-hop-ip-address 10.127.130.38

 

 

Starting l2bridge containers

Once all static routes have been updated and l2bridge network created on each host, it is simple to spin up containers and attach them to the l2bridge network.

 

For example, to spin up two IIS containers with ID “c1”, “c2” on container subnet with gateway “10.244.3.1”:

 

$array = @("c1", "c2")
$array |foreach {
docker run -d --rm --name $_ --hostname $_ --network winl2bridge mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
docker exec $_ cmd /c netsh int ipv4 add neighbors "Ethernet" "10.244.3.1" "00-01-e8-8b-2e-4b"
}

 

 

NOTE: The last netsh command above would not be needed if we supplied a proper gateway that exists in the network infrastructure at network creation. Since we created a host endpoint to use in place of a gateway, we need to add a static ARP entry with a dummy MAC so that traffic is able to leave our host without being stuck waiting for an ARP probe to resolve this gateway IP.

 

Here is a video demonstrating all the connectivity paths available after launching the containers:

 

Publishing container ports to host ports

One feature to expose containerized applications and make them more available is to map container ports to an external port on the host.

For example, to map TCP container port 80 to the host port 8080, and assuming the container has respective endpoint with ID “448c0e22-a413-4882-95b5-2d59091c11b8” this can be achieved using an ELB policy as follows:

 

ipmo .\hns.psm1
$publish_json = '{
    "References": [
        "/endpoints/448c0e22-a413-4882-95b5-2d59091c11b8"
    ],
    "Policies": [
        {
            "Type": "ELB",
            "InternalPort": 80,
            "ExternalPort": 8080,
            "Protocol": 6
        }
    ]
}'
Invoke-HNSRequest -Method POST -Type policylists -Data $publish_json

 

 

Here is a video demonstrating how to apply the policy to bind a TCP container port to a host port and access it:

 

Advanced: Setting up Load Balancers

The ability to distribute traffic across multiple containerized backends using a load balancer leads to higher scalability and reliability of applications.

 

For example, creating a load balancer with frontend virtual IP (VIP) 10.10.0.10:8090 on host A (IP 10.127.130.36) and backend DIPs of all local containers can be achieved as follows:

 

ipmo .\hns.psm1
[GUID[]] $endpoints = (Get-HNSEndpoint |? Name -Like "Ethernet" | Select ID).ID
New-HNSLoadBalancer -Endpoints $endpoints -InternalPort 80 -ExternalPort 8090 -Vip "10.10.0.10"

 

 

Finally, for the load balancer to be accessible from inside the containers, we also need to add two encapsulation rules for every endpoint that needs to access the load balancer:

 

$endpoints | foreach {
$encap_lb = '{
    "References": [
        "/endpoints/' + $_ +'"
    ],
    "Policies": [
        {
            "Type": "ROUTE",
            "DestinationPrefix": "10.10.0.0/24",
            "NeedEncap": true
        }
    ]
}'
$encap_mgmt = '{
    "References": [
        "/endpoints/' + $_ +'"
    ],
    "Policies": [
        {
            "Type": "ROUTE",
            "DestinationPrefix": "10.127.130.36/32",
            "NeedEncap": true
        }
    ]
}'
Invoke-HNSRequest -Method POST -Type policylists -Data $encap_lb
Invoke-HNSRequest -Method POST -Type policylists -Data $encap_mgmt
}

 

 

Here is a video showing how to create the load balancer and access it using its frontend VIP "10.10.0.10" from host and container:

 

Advanced: Setting up ACLs

What if instead of making applications more available, one needs to restrict traffic between containers? l2bridge networks are ideally suited for network access control lists (ACLs) that define policies which limit network access to only those workloads that are explicitly permitted.

For example, to allow inbound network access to TCP port 80 from IP 10.244.3.75 and block all other inbound traffic to container with endpoint “448c0e22-a413-4882-95b5-2d59091c11b8”:

 

ipmo .\hns.psm1 
$json = '{
    "Policies": [
        {
            "Type": "ACL",
            "Action": "Allow",
            "Direction": "In",
            "LocalAddresses": "",
            "RemoteAddresses": "10.244.3.75",
            "LocalPorts": "80",
            "Protocol": 6,
            "Priority": 200
        },
        {
            "Type": "ACL",
            "Action": "Block",
            "Direction": "In",
            "Priority": 300
        },
        {
            "Type": "ACL",
            "Action": "Allow",
            "Direction": "Out",
            "Priority": 300
        }
    ]
}' 
Invoke-HNSRequest -Method POST -Type endpoints -Id "448c0e22-a413-4882-95b5-2d59091c11b8" -Data $acl_json

 

 

Here is a video showing the ACL policy in action and how to apply it:

 

Access control lists and Windows fire-walling is a very deep and complex topic. HNS supports more granular capabilities to implement network micro-segmentation and govern traffic flows than shown above. Most of these enhancements are available via Tigera’s Calico for Windows product and will be incrementally documented here and here.

 

Advanced: Multi-NIC containers

Attaching multiple vNICs to a single container addresses various traffic segregation and operational concerns. For example, assume there are two VLAN-isolated L2bridge networks called “winl2bridge_4096” and “winl2bridge_4097”:

 

# Create “winl2bridge_4096” with VLAN tag 4096
docker network create -d l2bridge --subnet=10.244.4.0/24 -o com.docker.network.windowsshim.dnsservers=10.127.130.7 --gateway=10.244.4.1 -o com.docker.network.windowsshim.enable_outboundnat=true -o com.docker.network.windowsshim.outboundnat_exceptions=10.244.0.0/16,11.96.0.0/24,10.127.130.36/30 -o com.docker.network.windowsshim.vlanid=4096 winl2bridge_4096
# Create “winl2bridge_4097” with VLAN tag 4097
docker network create -d l2bridge --subnet=10.244.5.0/24 -o com.docker.network.windowsshim.dnsservers=10.127.130.7 --gateway=10.244.5.1 -o com.docker.network.windowsshim.enable_outboundnat=true -o com.docker.network.windowsshim.outboundnat_exceptions=10.244.0.0/16,11.96.0.0/24,10.127.130.36/30 -o com.docker.network.windowsshim.vlanid=4097 winl2bridge_4097

 

 

Attaching a container to both networks can be done as follows:

 

# Create container and attach to “winl2bridge_4096”
docker run -d --rm --name "multi_nic_container" --network "winl2bridge_4096" mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019 
# Attach to “winl2bridge_4097”
docker network connect "winl2bridge_4097" "multi_nic_container"

 

To add more vNICs, we can create HNS endpoints under a given network and attach them to the container’s network compartment. For example, to add another NIC in network “winl2bridge_4096”:

 

# Get compartment ID
$compartmentId = docker exec "multi_nic_container" powershell.exe "Get-NetCompartment | Select -ExpandProperty CompartmentId"
# Get HNS network ID
$network = get-hnsnetwork | ? Name -Like $(docker network inspect --format='{{.ID}}' winl2bridge_4096)
# Create HNS endpoint under network “winl2bridge_4096”
$hnsEndpoint = New-HnsEndpoint -NetworkId $network.ID -Name my_ep -IPAddress 10.244.4.10 -Verbose
# Attach endpoint to target container’s network compartment
Attach-HnsHostEndpoint -EndpointID $hnsEndpoint.Id -CompartmentID $compartmentId

 

 

By executing all the above, a single container has three vNICs ready to use now (two in “winl2bridge_4096”, one from “winl2bridge_4097”). Every endpoint may have different policies and configurations specifically tailored to meet the needs of the application and business.

Container with multiple endpoints belonging to two different networksContainer with multiple endpoints belonging to two different networks

 

Summary

We have covered several supported capabilities of l2bridge container networking, including:

  • Cross-host container communication (not possible via WinNAT)
  • Logical separation of networks by VLANs
  • Micro-segmentation using ACLs
  • Load balancers
  • Binding container ports to host ports
  • Attaching multiple network adapters to containers

L2bridge networks require upfront configuration to install correctly but offers many useful features as well as enhanced performance and control of the container network. It is always recommended to leverage orchestrators such as Kubernetes which utilize CNI plugins to streamline and automate many of these configuration tasks, while still rewarding advanced users with a similar level of configurability. All of the HNS APIs used above and much more are also open-source in a Golang shim (see hcsshim).

 

As always, thanks for reading and please let us know about your scenarios or questions in the comments section below!

5 Comments

Thanks for sharing this Awesome blogpost with the community :cool:

Senior Member

It's somehow similar to our work in 2014 on early namespaces implementation in ReactOS kernel

https://fr.slideshare.net/interfaceULG-innovationManagement/virtualisationlgredurseaudansreactos-140...

Occasional Visitor

Hi, thanks for this great post. I am currently setting up a docker dev env which contains seven containers. Unfortunately, we have a "special" corporate intranet. Both of NAT and transparent network doesn't work under this intranet. If I use NAT, I can't access any outside resource from the container. For transparent network, the company network has port security which limit at most two MAC address per port, so only one of seven containers can get the ip address from the network at same time. So I came to L2Bridge. 

My goal is: Outbound connectivity (Internet access)

I did setup follow the guide. This is the host network info.

PS C:\Users\212616592> ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : G6CR726W911E
   Primary Dns Suffix  . . . . . . . : "company sensitive"
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : "company sensitive"

Ethernet adapter vEthernet (NATSwitch):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
   Physical Address. . . . . . . . . : 00-15-5D-B5-1A-07
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 172.21.21.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter vEthernet (Ethernet):

   Connection-specific DNS Suffix  . : "company sensitive"
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #4
   Physical Address. . . . . . . . . : C8-D3-FF-BE-B1-D9
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.189.181.26(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Lease Obtained. . . . . . . . . . : Wednesday, April 29, 2020 7:34:25 PM
   Lease Expires . . . . . . . . . . : Monday, May 4, 2020 7:34:21 AM
   Default Gateway . . . . . . . . . : 10.189.180.1
   DHCP Server . . . . . . . . . . . : 10.69.64.200
   DNS Servers . . . . . . . . . . . : 10.220.220.220
                                       10.220.220.221
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter vEthernet (cbr0_ep):

   Connection-specific DNS Suffix  . : "company sensitive"
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #5
   Physical Address. . . . . . . . . : 00-15-5D-F8-BD-3F
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.189.181.2(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.189.181.1
   DNS Servers . . . . . . . . . . . : 10.220.220.220
                                       10.220.220.221
   NetBIOS over Tcpip. . . . . . . . : Enabled
   Connection-specific DNS Suffix Search List :
                                       logon.ds.ge.com

Ethernet adapter vEthernet (Default Switch):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
   Physical Address. . . . . . . . . : 00-15-5D-5B-08-C3
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 172.17.102.177(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.240
   Default Gateway . . . . . . . . . :
   NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter vEthernet (nat):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
   Physical Address. . . . . . . . . : 00-15-5D-93-BA-2C
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 172.19.192.1(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :
   NetBIOS over Tcpip. . . . . . . . : Enabled

This is the docker netwoker info:

Microsoft Windows [Version 10.0.18362.778]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 886fafbe55b5
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : company sensitive

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : company sensitive
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 00-15-5D-F8-B9-E3
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::7113:574e:2920:63d3%4(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.189.181.62(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.189.181.1
   DHCPv6 IAID . . . . . . . . . . . : 67114333
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-26-3D-C8-A3-00-15-5D-F8-B9-E3
   DNS Servers . . . . . . . . . . . : 10.220.220.220
                                       10.220.220.221
   NetBIOS over Tcpip. . . . . . . . : Disabled

This is result when tried to access outsite resource from the container:

C:\>curl https://platform.cloud.coveo.com
curl: (6) Could not resolve host: platform.cloud.coveo.com

One hint which I found: my host ip is 192.168.181.26,default gateway is 192.168.180.1. It's a different pattern. Could you please explain how should I change the settings? 

 

PS: This set up did work in my home network which has same ip/gateway patten.

 

 

 

 

Microsoft
Microsoft

@jamessxxoo This appears to be the case where you are supplying the same subnet as the host and a gateway that actually exists. You can pursue the much simpler option instead of following this guide. You don't need the host endpoint and workarounds, and should be able to get it to work using:

$localContainerSubnet="10.189.181.0/24"
$containerGw="10.189.181.1"
$dnsServer="10.220.220.220"
docker network create -d l2bridge --subnet=$localContainerSubnet -o com.docker.network.windowsshim.dnsservers=$dnsServer --gateway=$containerGw -o com.docker.network.windowsshim.enable_outboundnat=true winl2bridge
 
Should create a l2bridge network that can connect to other VMs, as well as outbound connectivity and DNS resolution.
 
Then to create a container (e.g. "c1") and attach to the winl2bridge network:
docker run -d --rm --name c1 --hostname c1 --network winl2bridge mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019



@Kurt Schenk thank you, the link has been updated.