Achieve rapid network scale
Move your network control layer from hardware to software. Deploy complex workloads in a matter of seconds using a scalable network controller, and automatically load balance and shift workloads.
Enhance network security
Dynamically segment your network based on workloads by using a distributed firewall and network security groups to apply rich policies within, and across, segments. Plus, layer enforcement by routing traffic to virtualized firewall appliances for even greater levels of security.
Gain workload mobility
Take control of your hybrid workloads, including running them in containers, and move them across servers, racks, and clouds using standards-based overlay networks and multitenanted hybrid gateways.
VIDEO
Explore the software-defined datacenter
Learn how to improve datacenter efficiency with a look at the Windows Server 2016 software-defined datacenter.
Watch the software-defined datacenter video
<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
>
<channel>
<title>Networking Blog</title>
<atom:link href="https://blogs.technet.microsoft.com/networking/feed/" rel="self" type="application/rss+xml" />
<link>https://blogs.technet.microsoft.com/networking</link>
<description>Windows Networking support team and Product team blog</description>
<lastBuildDate>Mon, 06 Nov 2017 16:11:16 +0000</lastBuildDate>
<language>en-US</language>
<sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>1</sy:updateFrequency>
<item>
<title>Available to Windows 10 Insiders Today: Access to published container ports via “localhost”/127.0.0.1</title>
<link>https://blogs.technet.microsoft.com/networking/2017/11/06/available-to-windows-10-insiders-today-access-to-published-container-ports-via-localhost127-0-0-1/</link>
<comments>https://blogs.technet.microsoft.com/networking/2017/11/06/available-to-windows-10-insiders-today-access-to-published-container-ports-via-localhost127-0-0-1/#respond</comments>
<pubDate>Mon, 06 Nov 2017 16:11:16 +0000</pubDate>
<dc:creator><![CDATA[KallieBracken[msft]]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=4255</guid>
<description><![CDATA[Until now, a lingering limitation on Windows 10 has prevented access to published ports for containers via “localhost” or 127.0.0.1 (a.k.a. loopback). What this meant, was that if you had, say, a container running as an IIS Web server and exposing content through port 80 of your host machine, you wouldn’t be able to access... <a aria-label="read more about Available to Windows 10 Insiders Today: Access to published container ports via “localhost”/127.0.0.1" href="https://blogs.technet.microsoft.com/networking/2017/11/06/available-to-windows-10-insiders-today-access-to-published-container-ports-via-localhost127-0-0-1/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>Until now, a lingering limitation on Windows 10 has prevented access to published ports for containers via “localhost” or 127.0.0.1 (a.k.a. loopback). What this meant, was that if you had, say, a container running as an <a href="https://www.iis.net/">IIS Web server</a> and exposing content through port 80 of your host machine, you wouldn’t be able to access that content locally, using the “http://localhost/” or even “http://127.0.0.1/”.</p>
<p>But at last, this limitation has been removed! Beginning with Build 17025, available today to Windows Insiders, <strong>it’s now possible on Windows 10 to access your containers via their locally published ports using “localhost” or 127.0.0.1.</strong></p>
<p>Although simple, this is a little tedious to visualize, so let’s lay it out with an example. The image below shows a container running on its host, with content published to host port 8080. In the past, to access this content developers on Windows 10 have had to use either their host’s external IP address or the internal IP address of their container–so, in this example, “http://10.137.196.122:8080/” or “http://172.18.23.136:8080/”. Now, however, we have added the plumbing on Windows 10 enable “http://localhost:8080/” and “http://127.0.0.1:8080/” as additional ways to access your published containers locally.</p>
<p><a href="https://msdnshared.blob.core.windows.net/media/2017/11/Diagram.png"><img width="879" height="271" class="alignleft size-large wp-image-4257" alt="" src="https://msdnshared.blob.core.windows.net/media/2017/11/Diagram-1024x316.png" /></a></p>
<p><strong>Ready to try this out?</strong> This functionality is <a href="https://blogs.windows.com/windowsexperience/2017/10/25/announcing-windows-10-insider-preview-build-17025-pc/#62bk5RlkvY7yVkHz.97">included in the latest Windows 10 Insider Preview Build 17025.</a> If you’re already a Windows Insider running Build 17025, you have this capability now! If not, <a href="https://insider.windows.com/en-us/">click here</a> to learn more about the Windows Insider program and sign up to start receiving Windows 10 Preview Builds.</p>
<p> </p>
<p> </p>
<p> </p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/11/06/available-to-windows-10-insiders-today-access-to-published-container-ports-via-localhost127-0-0-1/feed/</wfw:commentRss>
<slash:comments>0</slash:comments>
</item>
<item>
<title>SDN Troubleshooting: UDP Communication failures and changing the Network Controller Certificate</title>
<link>https://blogs.technet.microsoft.com/networking/2017/08/25/sdn-troubleshooting-udp-communication-failures-and-network-controller-certificate-updation/</link>
<comments>https://blogs.technet.microsoft.com/networking/2017/08/25/sdn-troubleshooting-udp-communication-failures-and-network-controller-certificate-updation/#respond</comments>
<pubDate>Fri, 25 Aug 2017 22:12:40 +0000</pubDate>
<dc:creator><![CDATA[AnirbanPaul]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<category><![CDATA[certificates]]></category>
<category><![CDATA[NAT]]></category>
<category><![CDATA[Network Controller]]></category>
<category><![CDATA[SDN]]></category>
<category><![CDATA[Software Defined Networking]]></category>
<category><![CDATA[Software Load Balancer]]></category>
<category><![CDATA[UDP]]></category>
<category><![CDATA[Windows Server 2016]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=4217</guid>
<description><![CDATA[With this blog post, I wanted to highlight a couple of issues that we have encountered recently with Software Defined Networking (SDN) customer deployments in Windows Server 2016. Issue #1: UDP communication isn’t working when outbound NAT is configured Customer had configured outbound NAT access for his virtual network through SCVMM (this internally uses SDN... <a aria-label="read more about SDN Troubleshooting: UDP Communication failures and changing the Network Controller Certificate" href="https://blogs.technet.microsoft.com/networking/2017/08/25/sdn-troubleshooting-udp-communication-failures-and-network-controller-certificate-updation/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>With this blog post, I wanted to highlight a couple of issues that we have encountered recently with Software Defined Networking (SDN) customer deployments in Windows Server 2016.</p>
<h2>Issue #1: UDP communication isn’t working when outbound NAT is configured</h2>
<p>Customer had configured outbound NAT access for his virtual network through <a href="https://docs.microsoft.com/en-us/system-center/vmm/sdn-set-up-nat">SCVMM</a> (this internally uses SDN Software Load Balancer), so that machines in the virtual network could access the Internet. The customer noticed that TCP traffic to the Internet was working fine, but all User Datagram Protocol (UDP) traffic was getting dropped. Moreover, this only happened when the Software Load Balancer MUX was on a different HyperV host than the tenant VM.</p>
<p>On deeper analysis, it was revealed that the destination VM was rejecting the packet because the UDP checksum was incorrect. Further investigations revealed a physical NIC issue. The customer was using a physical NIC which was not certified for SDN with Windows Server 2016. The NIC was incorrectly marking the <strong>UdpChecksumFailed</strong> flag when the inner packet had a valid checksum.</p>
<p>If you are planning to use SDN with Windows Server 2016, please ensure that you use certified NICs. You can verify whether a network adapter is or is not certified by checking the <a href="https://www.windowsservercatalog.com/results.aspx?&bCatID=1468&cpID=0&avc=85&ava=0&avt=0&avq=0&OR=1&PGS=25">Windows Server Catalog</a>.</p>
<p>Click <strong>Software-Defined Data Center (SDDC) Premium</strong> to filter the Windows Server Catalog LAN card list.</p>
<h2>Issue #2: Changing the Network Controller Server certificate</h2>
<p>A customer wanted to change the Network Controller server certificate used for communication with the Northbound clients. He was using self-signed certificates and wanted to move to Certificate Authority based certificates. After installing the new certificate on all the Network Controller nodes, he used the <strong>Set-NetworkController </strong>Powershell command to point Network Controller to the new certificate.</p>
<p>Although the command succeeded, Network Controller communication with SCVMM stopped working.</p>
<p>This is due to a bug in the product where the certificate binding is only changed on one Network Controller node (where the command was run) and is not updated on the other nodes. We are planning to release a fix soon.</p>
<p>As a workaround, you need to manually change the certificate binding on the other Network Controller nodes. Process is as follows:</p>
<ul>
<li>Install the new certificate in Personal store of LocalMachine account</li>
<li>Execute the Powershell command: <strong>Set-NetworkController -ServerCertificate <new cert></strong></li>
<li>Retrieve the thumbprint of the new SSL certificate that you want to use with Network Controller</li>
<li>Double click the certificate and click on Details, note the value of Thumbprint parameter. Remove any spaces in between</li>
</ul>
<p>The following illustration depicts the Thumbprint property of the certificate.</p>
<p><a href="https://msdnshared.blob.core.windows.net/media/2017/08/abc.png"><img width="300" height="200" class="alignnone size-medium wp-image-4225" alt="" src="https://msdnshared.blob.core.windows.net/media/2017/08/abc-300x200.png" /></a></p>
<p>On each Network Controller node, check the SSL binding by executing the following command from a command prompt:</p>
<p><strong>netsh http show sslcert<em> </em></strong></p>
<p>If the result shows the thumbprint of the old certificate, change the binding by executing the following commands:</p>
<p><strong>netsh http delete sslcert ipport=0.0.0.0:443 </strong></p>
<p><strong>netsh http add sslcert certhash= <thumbprint of the new certificate> appid=<application ID> ipport=0.0.0.0:443 certstorename=MY<em> </em></strong></p>
<p>You can retrieve the <strong>appid</strong> from the output parameter Application ID of the <strong>netsh http show sslcert </strong>command.</p>
<p>If the binding shows the thumbprint of the new certificate, no further action is needed on that node.</p>
<p><strong>Additional Information</strong></p>
<p>Here are a few links to SDN topics to assist with your planning and deployment:</p>
<p>If you plan to assess your needs and environment for deploying SDN, see the topic <a href="https://docs.microsoft.com/en-us/windows-server/networking/sdn/plan/plan-a-software-defined-network-infrastructure">Plan a Software Defined Network Infrastructure</a>.</p>
<p>If you want to deploy SDN using System Center Virtual Machine Manager, see the topic <a href="https://docs.microsoft.com/en-us/system-center/vmm/deploy-sdn">Set up a Software Defined Network (SDN) infrastructure in the VMM fabric</a>.</p>
<p>If you have any questions/feedback about SDN, send an email to <strong><a href="mailto:sdn_feedback@microsoft.com">sdn_feedback@microsoft.com</a></strong>.</p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/08/25/sdn-troubleshooting-udp-communication-failures-and-network-controller-certificate-updation/feed/</wfw:commentRss>
<slash:comments>0</slash:comments>
</item>
<item>
<title>Core Network Stack Features in the Creators Update for Windows 10</title>
<link>https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/</link>
<comments>https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/#comments</comments>
<pubDate>Thu, 13 Jul 2017 22:27:05 +0000</pubDate>
<dc:creator><![CDATA[Daniel Mark Havey]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=4156</guid>
<description><![CDATA[By: Praveen Balasubramanian and Daniel Havey This blog is the sequel to our first Windows Core Networking features announcements post. It describes the second wave of core networking features in the Windows Redstone series. The first wave of features is described here: Announcing: New Transport Advancements in the Anniversary Update for Windows 10 and Windows... <a aria-label="read more about Core Network Stack Features in the Creators Update for Windows 10" href="https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p><strong>By:</strong> Praveen Balasubramanian and Daniel Havey</p>
<p>This blog is the sequel to our first Windows Core Networking features announcements post. It describes the second wave of core networking features in the Windows Redstone series. The first wave of features is described here: <a href="https://blogs.technet.microsoft.com/networking/2016/07/18/announcing-new-transport-advancements-in-the-anniversary-update-for-windows-10-and-windows-server-2016/">Announcing: New Transport Advancements in the Anniversary Update for Windows 10 and Windows Server 2016</a>. We encourage the Windows networking enthusiast community to experiment and provide feedback. If you are interested in Windows Transport please follow our Facebook feedback and discussion page: <a href="https://www.facebook.com/Windows.10.Data.Transport/">@Windows.10.Data.Transport</a>.</p>
<p> </p>
<h2>TCP Improvements:</h2>
<h3>TCP Fast Open (TFO) updates and server side support</h3>
<p>In the modern age of popular Web services and e-commerce , latency is a killer when it comes to page responsiveness. We’re adding support in TCP for <a href="https://tools.ietf.org/html/rfc7413">TCP Fast Open (TFO)</a> to cut down on round trips that can severely impact how long it takes for a page to load. <a href="https://blogs.windows.com/msedgedev/2016/06/15/building-a-faster-and-more-secure-web-with-tcp-fast-open-tls-false-start-and-tls-1-3/#AhXmKETXhfrDFOjw.97">Here’s how it works<span style="color: #001000">:</span></a> TFO establishes a secure TFO cookie in the first connection using a standard 3-way handshake. Subsequent connections to the same server use the TFO cookie to connect without the 3-way handshake (zero RTT). This means TCP can carry data in the SYN and SYN-ACK.</p>
<p><span>What we found together with </span><a href="https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-13.pdf">others in the industry</a><span> is that </span><a href="http://conferences.sigcomm.org/co-next/2013/workshops/HotMiddlebox/program/p37.pdf">middleboxes are interfering</a><span> with such traffic and </span><a href="http://conferences.sigcomm.org/imc/2011/docs/p181.pdf">dropping connections</a><span>. Together with our large population of Windows enthusiasts (that’s you!), we conducted experiments over the past few months, and tuned our algorithms to avoid usage of this option on networks where improper middlebox behavior is observed.</span><span> </span><span>Specifically, we enabled TFO in Edge using a checkbox in about:flags.</span></p>
<p><span>To harden against such challenges, Windows automatically detects and disables TFO on connections that traverse through these problematic middleboxes. </span><span> </span><span>For our Windows Insider Program community, we enabled TFO in Edge (About:flags) by default for all insider flights in order to get a better understanding of middlebox interference issues as well as find more problems with anti-virus and firewall software.</span><span> </span><span>The data helped us improve our fallback algorithm which detects typical middlebox issues.</span><span> </span><span>We intend to continue our partnership with our Windows Insider Program (WIP) professionals to improve our fallback algorithm and identify unwanted anti-virus, firewall and middlebox behavior.</span><span> </span><span>Retail and non WIP releases will not participate in the experiments.</span><span> </span><span>If you operate infrastructure or software components such as middleboxes or packet processing engines that make use of a TCP state machine, please incorporate support for TFO.</span><span> </span><span>In the future, the combination of TLS 1.3 and TFO is expected to be more widespread.</span></p>
<pre>The Creators Update also includes a fully functional server side implementation of TFO. The server side implementation also supports a pre-shared key for cases where a server farm is behind a load balancer. The shared key can be set by the following knob (requires elevation):
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v TcpFastopenKey /t REG_BINARY /f /d 0123456789abcdef0123456789abcdef
netsh int tcp reload</pre>
<p>We encourage the community to test both client and server side functionality for interop with other operating system network stacks. The subsequent releases of Windows Server will include TFO functionality allowing deployment of IIS and other web servers which can take advantage of reduced connection setup times.</p>
<p> </p>
<h3>Experimental Support for the High Speed CUBIC Congestion Control Algorithm</h3>
<p><a href="https://www.ietf.org/id/draft-ietf-tcpm-cubic-04.txt">CUBIC</a> is a TCP Congestion Control (CC) algorithm featuring a cubic congestion window (Cwnd) growth function. The Cubic CC is a high-speed TCP variant and uses the amount of time since the last congestion event instead of ACK clocking to advance the Cwnd. In large BDP networks the <a href="https://www.researchgate.net/profile/Sangtae_Ha/publication/220623913_CUBIC_a_new_TCP-friendly_high-speed_TCP_variant/links/574b20e608ae5f7899ba14ec/CUBIC-a-new-TCP-friendly-high-speed-TCP-variant.pdf">Cubic algorithm</a> takes advantage of throughput much faster than ACK clocked CC algorithms such as New Reno TCP. There have been reports that CUBIC can cause bufferbloat in networks with <a href="https://queue.acm.org/detail.cfm?id=2209336">unmanaged queues</a> (LTE and ADSL). In the Creators Update, we are introducing a Windows native implementation of CUBIC. We encourage the community to experiment with CUBIC and send us feedback.</p>
<pre>The following commands can be used to enable CUBIC globally and to return to the default Compound TCP (requires elevation):
netsh int tcp set supplemental template=internet congestionprovider=cubic
netsh int tcp set supplemental template=internet congestionprovider=compound</pre>
<p>*** The Windows implementation of Cubic does not have the “Quiescence bug” that was recently <a href="https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-8.pdf">uncovered</a> in the Linux implementation.</p>
<p> </p>
<h3><span>Improved Receive Window Autotuning</span></h3>
<p>TCP autotuning logic computes the “receive window” parameter of a TCP connection as described in <a href="https://technet.microsoft.com/en-us/library/2007.01.cableguy.aspx">TCP autotuning logic</a>.<span> </span>High speed and/or long delay connections need this algorithm to achieve good performance characteristics.<span> </span>The takeaway from all this is that using the SO_RCVBUF socket option to specify a static value for the receive buffer is almost universally a <a href="https://blogs.technet.microsoft.com/networking/2017/05/08/windows-network-performance-suffering-from-bad-buffering/">bad idea</a>.<span> </span><span>For those of you who choose to do so anyways please remember that calculating the correct size for TCP send/receive buffers is complex and requires information that applications do not have access to. It is far better to allow the Windows autotuning algorithm to </span>size the buffer for you<span>.</span><span> </span>We are working to identify such suboptimal usage of SO_RCVBUF/SO_SENDBUF socket options and to convince developers to move away from fixed window values.<span> </span>If you are an app developer and you are using either of these socket options please contact us.<span> </span></p>
<p>In parallel to our developer education effort we are improving the autotuning algorithm.<span> </span>Before the Creators Update the TCP receive Window autotuning algorithm depended on correct estimates of the connection’s bandwidth and RTT.<span> </span>There are two problems with this method.<span> </span>First, the TCP RTT estimate is only measured on the sending side as described in <a href="https://tools.ietf.org/html/rfc793">RFC 793</a>.<span> However, t</span>here are many examples of receive heavy workloads such as OS updates etc.<span> </span>The RTT estimate taken at the receive heavy side could be inaccurate.<span> </span>Second, there could be a feedback loop between altering the receive window (which can change the estimated bandwidth) and then measuring the bandwidth to determine how to alter the receive window.<span> </span></p>
<p>These two problems caused the receive window to constantly vary over time.<span> </span>We eliminated the unwanted behavior by modifying the algorithm to use a step function to converge on the maximum receive window value for a given connection.<span> </span>The step function algorithm results in a larger receive buffer size, however, the advertised receive window size is not backed by non-paged pool memory allocation and system resources are not used unless data is received and queued so the larger size is fine.<span> </span>Based on experimental results, the new algorithm adapts to the BDP much more quickly than the old algorithm.<span> </span>We encourage user and system administrators to also take note of our earlier post: <span><a href="https://blogs.technet.microsoft.com/networking/2016/08/11/an-update-on-windows-tcp-autotuninglevel/">An Update on Windows TCP AutoTuningLevel</a>. This should clear </span>misconceptions that autotuning and receive window scaling are bad for performance.</p>
<h3>TCP stats API</h3>
<p>The <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/bb485738(v=vs.85).aspx">Estats</a> API requires elevation and enumerates statistics for all connections. This can be inefficient especially on busy servers with lots of connections. In the Creators Update we are introducing a new API called SIO_TCP_INFO. SIO_TCP_INFO allows developers to query rich information on individual TCP connections using a socket option. The SIO_TCP_INFO API is versioned and we plan to add more statistics over time. In addition, we plan to add SIO_TCP_INFO to .Net NCL and HTTP APIs in subsequent releases.</p>
<pre>The MSDN documentation for this API will be up soon and we will add a link here as soon as it is available.</pre>
<h2>IPv6 improvements</h2>
<p>The Windows networking stack is dual stack and supports both IPv4 and IPv6 by default since Windows Vista. Over the Windows 10 releases, we are actively working on improving the support for IPv6. The following are some of the advancements in Creators Update.</p>
<h3>RFC 6106 support</h3>
<p>The Creators Update includes support for <a href="https://tools.ietf.org/html/rfc6106">RFC 6106 </a>which allows for DNS configuration through router advertisements (RAs). RDNSS and DNSSL ND options contained in router advertisements are validated and processed as described in the RFC. The implementation supports a max of 3 RDNSS and DNSSL entries each per interface. If there are more than 3 entries available from one or more routers on an interface, then entries with greater lifetime are preferred. In the presence of both DHCPv6 and RA DNS information, Windows gives precedence to DHCPv6 DNS information, in accordance with the RFC.</p>
<p>In Windows, the lifetime processing of RA DNS entries deviates slightly from the RFC. In order to avoid implementing timers to expire DNS entries when their lifetime ends, we rely on the periodic Windows DNS service query interval (15 minutes) to remove expired entries, unless a new RA DNS message is received in which case the entry is updated immediately. This enhancement eliminates the complexity and overhead of kernel timers while keeping the DNS entries fresh.The following knob can be used to control this feature (requires elevation):</p>
<pre>The following command can be used to control this feature (requires elevation):
netsh int ipv6 set interface <ifindex> rabaseddnsconfig=<enabled | disabled></pre>
<pre></pre>
<h3>Flow Labels</h3>
<p>Before the Creators update, the FlowLabel field in the IPv6 header was set to 0. Beginning with the Creators Update, outbound TCP and UDP packets over IPv6 have this field set to a <a href="https://tools.ietf.org/html/rfc6437#appendix-A">hash of the 5-tuple</a> (Src IP, Dst IP, Src Port, Dst Port). Middleboxes can use the FlowLabel field to perform ECMP for in-encapsulated native IPv6 traffic without having to parse the transport headers. This will make IPv6 only datacenters doing load balancing or flow classification more efficient.</p>
<pre>You can use this admin only knob to enable/disable IPv6 flow labels :
netsh int ipv6 set flowlabel=[disabled|enabled] (enabled by default)
The following knob can be used to control this feature (requires elevation):
netsh int ipv6 set global flowlabel=<enabled | disabled>
</pre>
<h3>ISATAP and 6to4 disabled by default</h3>
<p>IPv6 continues to see uptake and IPv6 only networks are no longer a rarity. ISATAP and 6to4 are IPv6 transition technologies that have been enabled by default in Windows since Vista/Server 2008. As a step towards future deprecation, the Creators Update will have these technologies disabled by default. There are administrator and group policy knobs to re-enable them for specific enterprise deployments. An upgrade to the Creators Update will honor any administrator or group policy configured settings. By disabling these technologies, we aim to increase native IPv6 traffic on the Internet. Teredo is the last transition technology that is expected to be in active use because of its ability to perform NAT traversal to enable peer-to-peer communication.</p>
<h3>Improved 464XLAT support</h3>
<p><a href="https://tools.ietf.org/html/rfc6877">464XLAT</a> was originally designed for cellular only scenarios since mobile operators are some of the first ISPs with IPv6 only networks. However, some apps are not IP-agnostic and still require IPv4 support. Since a major use case for mobile is tethering, 464XLAT should provide IPv4 connectivity to tethered clients as well as to apps running on the mobile device itself. Creators Update adds support for 464XLAT on cellular-equipped desktops and tablets too. We also enabled support for TCP Large Send Offload (LSO) over 464XLAT improving throughput and reducing CPU usage.</p>
<h2>Multi-homing improvements</h2>
<p>Devices with multiple network interfaces are becoming ubiquitous. The trend is especially prevalent on mobile devices, but, 3G and LTE connectivity is becoming common on laptops, hybrids and many other form factors. For the Creators Update we collaborated with the Windows Connection Manager (WCM) team to make the WiFi to cellular handover faster and to improve performance when a mobile device is docked with wired Ethernet connectivity and then undocked causing a failover to WiFi.</p>
<h3>Dead Gateway Detection (DGD)</h3>
<p>Windows has always had a DGD algorithm that automatically transitions connections over to another gateway when the current gateway is unreachable, but, that algorithm was designed for server scenarios. For the Creators update we improved the DGD algorithm to respond to client scenarios such as switching back and forth between WiFi to 3G or LTE connectivity. DGD signals WCM whenever transport timeouts suggest that the gateway has gone dead. WCM uses this data to decide when to migrate connections over to the cellular interface. DGD also periodically re-probes the network so that WCM can migrate connections back to WiFi. This behavior only occurs if the user has opted in for automatic failover to cellular.</p>
<h3>Fast connection teardown</h3>
<p>In Windows, TCP connections are preserved for about 20 seconds to allow for fast reconnection in the case of a temporary loss of wired or wireless connectivity. However, in the case of a true disconnection such as docking and undocking this is an unacceptably long delay. Using the Fast Connection Teardown feature WCM can signal the Windows transport layer to instantly tear down TCP connections for a fast transition.</p>
<h3>Improved diagnostics using Test-NetConnection</h3>
<p><a href="https://technet.microsoft.com/en-us/itpro/powershell/windows/nettcpip/test-netconnection">Test-NetConnection</a> (alias tnc) is a built-in cmdlet in powershell that performs a variety of network diagnostics. In Creators Update we have enhanced this cmdlet to provide detailed information about both route selection as well as source address selection.</p>
<pre>The following command when run elevated will describe the steps to select a particular route per RFC 6724. This can be particularly useful in multi-homed systems or when there are multiple IP addresses on the system.
Test-NetConnection -ComputerName "www.contoso.com" -ConstrainInterface 5 -DiagnoseRouting -InformationLevel "Detailed"</pre>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/feed/</wfw:commentRss>
<slash:comments>4</slash:comments>
</item>
<item>
<title>HTTPS Client Certificate Request freezes when the Server is handling a large PUT/POST Request</title>
<link>https://blogs.technet.microsoft.com/networking/2017/07/12/https-client-certificate-request-freezes-when-the-server-is-handling-a-large-putpost-request/</link>
<comments>https://blogs.technet.microsoft.com/networking/2017/07/12/https-client-certificate-request-freezes-when-the-server-is-handling-a-large-putpost-request/#respond</comments>
<pubDate>Wed, 12 Jul 2017 18:53:26 +0000</pubDate>
<dc:creator><![CDATA[Gabriel Montenegro]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=4005</guid>
<description><![CDATA[HTTPS Client Certificate Request freezes when the Server is handling a large PUT/POST Request   There is a class of problems that may occur when using client-side certificates in HTTPS. Sometimes, the server’s request for a client certificate will freeze (until the timeout of two minutes or so) when processing PUT/POST request with a large... <a aria-label="read more about HTTPS Client Certificate Request freezes when the Server is handling a large PUT/POST Request" href="https://blogs.technet.microsoft.com/networking/2017/07/12/https-client-certificate-request-freezes-when-the-server-is-handling-a-large-putpost-request/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<h1>HTTPS Client Certificate Request freezes when the Server is handling a large PUT/POST Request</h1>
<p> </p>
<p>There is a class of problems that may occur when using client-side certificates in HTTPS.</p>
<p>Sometimes, the server’s request for a client certificate will <em>freeze</em> (until the timeout of two minutes or so) when processing PUT/POST request with a large payload (e.g., >40KB).</p>
<p>Ideally, the server should request the client certificate before any large request exchange.</p>
<p>Otherwise, the server should request the client certificate immediately after either:</p>
<ul>
<li>a request has been completely received, or</li>
<li>a request has been responded to.</li>
</ul>
<p>Otherwise, the large payload fills the network buffers, which cannot be emptied until the certificate is received and everything processed. This leads to deadlock if the server issues a synchronous call for the client certificate. Although it is not illegal, this is what causes the problem. Furthermore, this represents a trivial DoS vector against any such server.</p>
<p>This may depend on the component sitting directly above http.sys. IIS for example, tries to read as much entity body as possible before requesting the client certificate.</p>
<p>These are some alternatives to fix this issue, but only the first one listed below is deterministic.</p>
<h2>By Modifying Only the Server side (when the client cannot be modified):</h2>
<ol>
<li>(<strong>recommended</strong>) Set “client certificate required” on the SSL binding so that client certificate is requested at SSL/TLS connection time, before any HTTP request exchange. This forces client certificate to be requested for every connection on that binding. Depending on your configuration, you might need a dedicated VIP and/or SSL SNI name for this communication. This requires <u>no server code changes</u>, but a configuration change via “netsh http” on the SSL binding:<i> </i><em>clientcertnegotiation=enable</em></li>
</ol>
<p><strong>Note</strong>: If the server is IIS-based the change needs to be done through IIS. Otherwise, since IIS has a different config, it may overwrite any changes made directly to Http.sys.</p>
<ol start="2">
<li>If the server sees this is a PUT/POST request, you need to ensure that the server’s TCP buffers have enough space for the client certificate when it arrives. This leads to strategies such as
<ol>
<li>reading as much entity body as possible requesting for the client certificate using an asynchronous call, or,</li>
<li>Modify your web server app so that it asynchronously pulls the request body while it waits for client certificate retrieval to finish. If too much entity body is pulled (e.g., several MB) and client certificate retrieval has still not finished then cancel the request/connection. Requires server code changes.</li>
<li>even better, issuing the asynchronous call for the client certificate as early as possible and draining as much of the entity body as possible as you wait for the client certificate to arrive.</li>
</ol>
</li>
</ol>
<p>This requires server code changes for sure. To increase the chances of this working, *all* relevant buffers on the server as well as the client <u>and in between</u>, need to have enough space for the client certificate to not be stuck behind large payloads. So modifying the client to drain buffers (in addition to the server) helps, but is not sufficient, as intermediate buffers along the way may also pose a problem (e.g., bufferbloat). This is not a deterministic method.</p>
<p> </p>
<h2>By Modifying the Client side in addition to the Server side:</h2>
<ol>
<li>(<strong>recommended</strong>) Use requests such as GET or HEAD to prime the connection so that the server can request for the certificate without being blocked to receive the entity body. This also implies an extra round trip for the priming request, but if client certificates are involved the application is already making some latency tradeoffs. This is not deterministic, as the immediately following “real” request may use a different connection, but usually reuses the “primed” connection from the connection pool. This will require client-side changes and requires that the server expose such an endpoint, as well.</li>
<li>Use the status code 100 Continue (requires client to send “<em>Expect:</em> <em>100-continue</em>” header). This may require both client and server changes to be supported. Furthermore, it is not a deterministic mechanism.</li>
</ol>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
<p> </p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/07/12/https-client-certificate-request-freezes-when-the-server-is-handling-a-large-putpost-request/feed/</wfw:commentRss>
<slash:comments>0</slash:comments>
</item>
<item>
<title>Troubleshooting certificate issues in Software Defined Networking (SDN)</title>
<link>https://blogs.technet.microsoft.com/networking/2017/05/19/troubleshooting-certificate-issues-in-software-defined-networking-sdn/</link>
<comments>https://blogs.technet.microsoft.com/networking/2017/05/19/troubleshooting-certificate-issues-in-software-defined-networking-sdn/#respond</comments>
<pubDate>Fri, 19 May 2017 20:47:33 +0000</pubDate>
<dc:creator><![CDATA[AnirbanPaul]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<category><![CDATA[certificates]]></category>
<category><![CDATA[Network Controller]]></category>
<category><![CDATA[SDN]]></category>
<category><![CDATA[security]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3985</guid>
<description><![CDATA[As you may be aware, Network Controller in Windows Server 2016 uses certificate based authentication for communicating with Hyper-V hosts and Software Load Balancer MUX virtual machines (VMs). Some SDN customers have complained about communication issues between Network Controller and hosts, although certificates were correctly configured on both the entities. On debugging, we found that... <a aria-label="read more about Troubleshooting certificate issues in Software Defined Networking (SDN)" href="https://blogs.technet.microsoft.com/networking/2017/05/19/troubleshooting-certificate-issues-in-software-defined-networking-sdn/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>As you may be aware, Network Controller in Windows Server 2016 uses certificate based authentication for communicating with Hyper-V hosts and Software Load Balancer MUX virtual machines (VMs).</p>
<p>Some SDN customers have complained about communication issues between Network Controller and hosts, although certificates were correctly configured on both the entities.</p>
<p>On debugging, we found that the customer had installed a non self-signed certificate into the computer’s <strong>Trusted Root Certification Authorities</strong> store. Although this certificate was not involved in communication between Network Controller and the hosts, the presence of such a certificate broke client authentication. Here is a view of some of the certificate properties:</p>
<p> </p>
<p><a href="https://msdnshared.blob.core.windows.net/media/2017/05/dd.png"><img width="300" height="97" class="alignnone size-medium wp-image-3986" alt="dd" src="https://msdnshared.blob.core.windows.net/media/2017/05/dd-300x97.png" /></a></p>
<p>The following Knowledge Base article provides information about this issue: <a href="https://support.microsoft.com/en-us/help/2802568/internet-information-services-iis-8-may-reject-client-certificate-requests-with-http-403.7-or-403.16-errors">Internet Information Services (IIS) 8 may reject client certificate requests with HTTP 403.7 or 403.16 errors</a></p>
<p>To resolve this issue, you can uninstall the non self-signed certificate from the <strong>Trusted Root Certification Authorities</strong> certificate store for the Local Computer, or move the certificate to the <strong>Intermediate Certification Authorities</strong> store.</p>
<p>One more thing to note is that that the <strong>Personal</strong> (My – cert:\localmachine\my) certificate store on the Hyper-V host must have exactly one X.509 certificate with Subject Name (CN) as the host FQDN. This certificate is used for communication with the Network Controller.</p>
<p>This behavior is due to a bug in the system and will be fixed shortly. For now, please ensure that you have only one certificate with the Subject Name (CN) as the host FQDN.</p>
<p>For more information, see the following topics in the Windows Server 2016 Technical Library.</p>
<ul>
<li><a href="https://docs.microsoft.com/en-us/windows-server/networking/sdn/security/nc-security">Network Controller Security</a></li>
<li><a href="https://docs.microsoft.com/en-us/windows-server/networking/sdn/security/sdn-manage-certs">Managing certificates for Software Defined Networking</a></li>
</ul>
<p>Anirban Paul, Senior Program Manager</p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/05/19/troubleshooting-certificate-issues-in-software-defined-networking-sdn/feed/</wfw:commentRss>
<slash:comments>0</slash:comments>
</item>
<item>
<title>Windows network performance suffering from bad buffering</title>
<link>https://blogs.technet.microsoft.com/networking/2017/05/08/windows-network-performance-suffering-from-bad-buffering/</link>
<comments>https://blogs.technet.microsoft.com/networking/2017/05/08/windows-network-performance-suffering-from-bad-buffering/#comments</comments>
<pubDate>Mon, 08 May 2017 18:26:57 +0000</pubDate>
<dc:creator><![CDATA[Daniel Mark Havey]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3945</guid>
<description><![CDATA[Daniel Havey, Praveen Balasubramanian Windows telemetry results have indicated that a significant number of data connections are using the SO_RCVBUF and/or the SO_SNDBUF winsock options to statically allocate TCP buffers. There are many websites that recommend setting the TCP buffers with these options in order to improve TCP performance. This is a myth. Using Winsock... <a aria-label="read more about Windows network performance suffering from bad buffering" href="https://blogs.technet.microsoft.com/networking/2017/05/08/windows-network-performance-suffering-from-bad-buffering/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>Daniel Havey, Praveen Balasubramanian</p>
<p>Windows telemetry results have indicated that a significant number of data connections are using the SO_RCVBUF and/or the SO_SNDBUF winsock options to statically allocate TCP buffers. There are many websites that recommend setting the TCP buffers with these options in order to improve TCP performance. This is a myth. Using Winsock options (SO_RCVBUF and/or SO_SNDBUF) to statically allocate TCP buffers will not make Windows networking stack “faster”. In fact, static allocation of the TCP buffers will degrade performance in terms of how fast the connection responds (latency) and how much data it delivers (bandwidth). The Windows transports team officially recommends <strong>not</strong> doing this.</p>
<p>TCP buffers need to be dynamically allocated in proportion to the Bandwidth Delay Product (BDP) of the TCP connection. There are two good reasons why we should let the Windows networking stack dynamically set the TCP buffers for us and not set them statically at the application layer. 1.) The application does not know the BDP (TCP does) so it cannot properly set the TCP buffers and 2.) Dynamic buffer management requires complex algorithmic control which TCP already has. In summary, Windows 10 has autotuning for TCP. Let the autotuning algorithm manage the TCP buffers.</p>
<p><strong>Example:</strong> I am going to use the Cygwin application as an example since they recently fixed their buffering (thank you Corinna). The experiment is conducted across the Internet to an iperf server in France (from my desk in Redmond).</p>
<h3><strong>Experiment 1 — Cygwin (Bad buffering):</strong></h3>
<h6>Pinging 178.250.209.22 with 32 bytes of data:<br />
Reply from 178.250.209.22: bytes=32 time=176ms TTL=35<br />
Reply from 178.250.209.22: bytes=32 time=173ms TTL=35<br />
Reply from 178.250.209.22: bytes=32 time=173ms TTL=35<br />
Reply from 178.250.209.22: bytes=32 time=172ms TTL=35</h6>
<h6>Ping statistics for 178.250.209.22:<br />
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),<br />
Approximate round trip times in milli-seconds:<br />
Minimum = 172ms, Maximum = 176ms, Average = 173ms<br />
————————————————————<br />
Client connecting to 178.250.209.22, TCP port 5001<br />
TCP window size: 208 KByte (default)<br />
————————————————————<br />
[ 3] local 10.137.196.108 port 56758 connected with 178.250.209.22 port 5001<br />
[ ID] Interval Transfer Bandwidth<br />
[ 3] 0.0- 1.0 sec 512 KBytes 4.19 Mbits/sec<br />
[ 3] 1.0- 2.0 sec 1.50 MBytes 12.6 Mbits/sec<br />
[ 3] 2.0- 3.0 sec 1.50 MBytes 12.6 Mbits/sec<br />
[ 3] 3.0- 4.0 sec 1.25 MBytes 10.5 Mbits/sec<br />
[ 3] 4.0- 5.0 sec 1.50 MBytes 12.6 Mbits/sec<br />
[ 3] 5.0- 6.0 sec 1.50 MBytes 12.6 Mbits/sec<br />
[ 3] 6.0- 7.0 sec 1.50 MBytes 12.6 Mbits/sec<br />
[ 3] 7.0- 8.0 sec 1.25 MBytes 10.5 Mbits/sec<br />
[ 3] 8.0- 9.0 sec 1.50 MBytes 12.6 Mbits/sec<br />
[ 3] 9.0-10.0 sec 1.50 MBytes 12.6 Mbits/sec<br />
[ 3] 0.0-10.1 sec 13.6 MBytes 11.3 Mbits/sec</h6>
<p> </p>
<p>We can see that the RTT is the same for both Experiment 1 & 2 about 177ms. However, in Experiment 1 Cygwin has bad buffering and the throughput averages 11.3 Mbps and tops out at 12.6 Mbps. This is because in Experiment 1 Cygwin was using SO_RCVBUF to allocate 278,775 bytes for the TCP receive buffer and the throughput is buffer limited to 12.6 Mbps.</p>
<h3><strong>Experiment 2 — Cygwin (Good buffering):</strong></h3>
<h6>Pinging 178.250.209.22 with 32 bytes of data:<br />
Reply from 178.250.209.22: bytes=32 time=172ms TTL=35<br />
Reply from 178.250.209.22: bytes=32 time=172ms TTL=35<br />
Reply from 178.250.209.22: bytes=32 time=172ms TTL=35<br />
Reply from 178.250.209.22: bytes=32 time=173ms TTL=35</h6>
<h6>Ping statistics for 178.250.209.22:<br />
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),<br />
Approximate round trip times in milli-seconds:<br />
Minimum = 172ms, Maximum = 173ms, Average = 172ms<br />
————————————————————<br />
Client connecting to 178.250.209.22, TCP port 5001<br />
TCP window size: 64.0 KByte (default)<br />
————————————————————<br />
[ 3] local 10.137.196.108 port 56898 connected with 178.250.209.22 port 5001<br />
[ ID] Interval Transfer Bandwidth<br />
[ 3] 0.0- 1.0 sec 768 KBytes 6.29 Mbits/sec<br />
[ 3] 1.0- 2.0 sec 11.8 MBytes 98.6 Mbits/sec<br />
[ 3] 2.0- 3.0 sec 18.0 MBytes 151 Mbits/sec<br />
[ 3] 3.0- 4.0 sec 16.6 MBytes 139 Mbits/sec<br />
[ 3] 4.0- 5.0 sec 16.4 MBytes 137 Mbits/sec<br />
[ 3] 5.0- 6.0 sec 18.0 MBytes 151 Mbits/sec<br />
[ 3] 6.0- 7.0 sec 18.0 MBytes 151 Mbits/sec<br />
[ 3] 7.0- 8.0 sec 18.0 MBytes 151 Mbits/sec<br />
[ 3] 8.0- 9.0 sec 15.6 MBytes 131 Mbits/sec<br />
[ 3] 9.0-10.0 sec 17.4 MBytes 146 Mbits/sec<br />
[ 3] 0.0-10.0 sec 151 MBytes 126 Mbits/sec</h6>
<p> </p>
<p>In Experiment 2 we see Cygwin perform without static application level buffering. The average throughput is 126 Mbps and the maximum is 151 Mbps which is the true unloaded line speed of this connection. By statically allocating the receive buffer using SO_RCVBUF we limited ourselves to a top speed of 12.6 Mbps. By letting Windows TCP autotuning dynamically allocate the buffers we achieved the true unloaded line rate of 151 Mbps. That is about an order of magnitude better performance. Static allocation of TCP buffers at the app level is a bad idea. <strong>Don’t do it</strong>.</p>
<p>Sometimes there are corner cases where as a developer one might think that there is justifiable cause to statically allocate the TCP buffers. Let’s take a look at three of the most common causes for thinking this:</p>
<p>1.) Setting the buffers for performance sake. <strong>Don’t.</strong> TCP autotuning is a kernel level algorithm and can do a better job than any application layer algorithm.<br />
2.) Setting the buffers because you are trying to rate limit traffic. <strong>Be Careful!</strong> The results may not be what you expect. In the Cygwin example the connection is buffer limited to 12.6 Mbps maximum. However, if the RTT were to change to about 40 ms then the connection would be limited to about 50 Mbps. You cannot reliably set a bandwidth cap in this manner (See the BDP equations).<br />
3.) Setting the buffers for some other reason. Let’s have a discussion. Please comment on the post and we will respond.</p>
<p> </p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/05/08/windows-network-performance-suffering-from-bad-buffering/feed/</wfw:commentRss>
<slash:comments>4</slash:comments>
</item>
<item>
<title>Windows Networking for Kubernetes</title>
<link>https://blogs.technet.microsoft.com/networking/2017/04/04/windows-networking-for-kubernetes/</link>
<comments>https://blogs.technet.microsoft.com/networking/2017/04/04/windows-networking-for-kubernetes/#respond</comments>
<pubDate>Tue, 04 Apr 2017 21:51:27 +0000</pubDate>
<dc:creator><![CDATA[JMesser81]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3886</guid>
<description><![CDATA[A seismic shift is happening in the way applications are developed and deployed as we move from traditional three-tier software models running in VMs to “containerized” applications and micro-services deployed across a cluster of compute resources. Networking is a critical component in any distributed system and often requires higher-level orchestration and policy management systems to... <a aria-label="read more about Windows Networking for Kubernetes" href="https://blogs.technet.microsoft.com/networking/2017/04/04/windows-networking-for-kubernetes/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>A seismic shift is happening in the way applications are developed and deployed as we move from traditional three-tier software models running in VMs to “containerized” applications and micro-services deployed across a cluster of compute resources. Networking is a critical component in any distributed system and often requires higher-level orchestration and policy management systems to control IP address management (IPAM), routing, load-balancing, network security, and other advanced network policies. The Windows networking team is swiftly adding new features (<a href="https://blogs.technet.microsoft.com/virtualization/2017/02/09/overlay-network-driver-with-support-for-docker-swarm-mode-now-available-to-windows-insiders-on-windows-10/">Overlay networking and Docker Swarm Mode on Windows 10</a>) and working with the larger containers community (e.g. <a href="https://github.com/kubernetes/community/tree/master/sig-windows">Kubernetes sig-windows group</a>) by contributing to open source code and ensuring native networking support for any orchestrator, in any deployment environment, with any network topology.</p>
<p>Today, I will be discussing how Kubernetes networking is implemented in Windows and managed by an extensible Host Networking Service (HNS) – which is used in both Azure Container Service (ACS) Windows worker nodes and on-premises deployments – to plumb network policy in the OS .</p>
<p><em>Note: A video recording of the 4/4 #sig-windows meetup where I describe this is posted here: </em><a href="https://www.youtube.com/watch?v=P-D8x2DndIA&t=6s&list=PL69nYSiGNLP2OH9InCcNkWNu2bl-gmIU4&index=1"><em>https://www.youtube.com/watch?v=P-D8x2DndIA&t=6s&list=PL69nYSiGNLP2OH9InCcNkWNu2bl-gmIU4&index=1</em></a></p>
<h1>Kubernetes Networking</h1>
<p>Windows containers can be orchestrated using either <a href="https://docs.docker.com/engine/swarm/">Docker Swarm</a> or <a href="https://kubernetes.io/">Kubernetes </a><a href="https://docs.docker.com/engine/swarm/"></a><a href="https://kubernetes.io/"></a>to help “automate the deployment, scaling, and management of ‘containerized’ applications”. However, the networking model used by these two systems is different.</p>
<p>Kubernetes networking is built on the fundamental requirements listed <a href="https://kubernetes.io/docs/admin/networking/">here</a> and is either agnostic to the network fabric underneath or assumes a flat Layer-2 networking space where all containers and nodes can communicate with all other containers and nodes across a cluster <strong>without using NAT (encapsulation is permitted)</strong>. Windows can support these requirements using a few different networking modes exposed by HNS and working with external IPAM drivers and route configurations.</p>
<p>The other large difference between Docker and Kubernetes networking is the scope at which IP assignment and resource allocation occurs. Docker assigns an IP address to every container whereas Kubernetes assigns IP addresses to a <a href="https://kubernetes.io/docs/user-guide/pods/">Pod</a> which represents a network namespace and could consist of multiple containers running inside the Pod. Windows also has a network namespace concept called a <strong><em>network compartment</em></strong> and a management surface is being built in Windows to allow for multiple containers in a Pod to communicate with each other through localhost.</p>
<p>Connectivity between pods located on different nodes in a Kubernetes cluster can be accomplished either by using an overlay (e.g. vxlan) network or without an overlay by configuring routes and IPAM on the underlying (virtual) network fabric. Realizing this network model can be done through:</p>
<ul>
<li>CNI Network Plugin</li>
<li>Implementing the “Routing” interface in Kubernetes code</li>
<li>External configuration</li>
</ul>
<p>The sig-windows community (led by <a href="https://apprenda.com/">Apprenda</a>) did a lot of work to come up with an initial solution for getting Kubernetes networking to work on Windows. The networking teams at Microsoft are building on this work and continues to partner with the community to add support for the native Kubernetes networking model – <em>defined by the </em><a href="https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration"><em>Container Network Interface (CNI)</em></a><em> which, is different from the <a href="https://github.com/docker/libnetwork/blob/master/docs/design.md">Cloud Network Model (CNM) </a></em><a href="https://github.com/docker/libnetwork/blob/master/docs/design.md"></a><em>used by Docker</em> – and surfacing policy management capabilities through HNS.</p>
<h2>Kubernetes networking in Azure Container Service (ACS)</h2>
<p>Azure Container Service recently announced <a href="https://azure.microsoft.com/en-us/blog/kubernetes-now-generally-available-on-azure-container-service/">Kubernetes general availability</a> which uses a routable-vip approach (no overlay) to networking and configures <a href="https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview">User-Defined Routes (UDR)</a> in the Hyper-V (virtualization) host for Pod communication between Linux and Windows cluster node VMs. A /24 CIDR IP pool (routable between container host VMs) is allocated to each container host with one IP assigned per Pod (one container).</p>
<p><img src="https://msdnshared.blob.core.windows.net/media/2017/04/UDR-in-ACS-Kubernetes-1024x576.png" alt="udr-in-acs-kubernetes" width="879" height="494" class="alignnone wp-image-3905 size-large" /></p>
<p>With the recent Azure VNet for Containers announcement which includes support for a CNI network plugin used in Azure (pre-released here: <a href="https://github.com/Azure/azure-container-networking/releases/tag/v0.7">https://github.com/Azure/azure-container-networking/releases/tag/v0.7</a>), tenants can connect their ACS clusters (containers and hosts) directly to Azure Virtual Networks. This means that individual IPs from a tenant’s Azure VNet IP space will be assigned to Kubernetes nodes and pods in potentially the same subnet. The Windows networking team is also working to build a CNI plugin to support and extend container management through Kubernetes on Windows for on-premises deployments.</p>
<h2>Kubernetes networking in Windows</h2>
<p>Microsoft engineers across Windows and Azure product groups actively contributed code to the Kubernetes repo to enhance kube-proxy (used for DNS and service load-balancing) and kubelet (for Internet access) binaries which are installed on ACS Kubernetes Windows worker nodes. This overcame gaps <a href="http://blog.kubernetes.io/2016/12/windows-server-support-kubernetes.html">previously identified</a> so that both DNS and service load-balancing worked correctly without the need for Routing and Remote Access Services (RRAS) or netsh port proxy. In this implementation, the Windows network uses Kubernetes’ default kubenet plugin without CNI plugin.</p>
<p>Using HNS, one <em>transparent</em> and one <em>NAT</em> network is created on each Windows container host for inter-Pod and external communication respectively. Two container endpoints – connected to the Service and Pod networks – are required for each Windows container which will participate in the Kubernetes service. Static routes must be added to the running Windows containers themselves on the container endpoint attached to the service network.</p>
<p><a href="https://msdnshared.blob.core.windows.net/media/2017/04/Windows-Container-Host-ACS-Kubernetes.png"><img src="https://msdnshared.blob.core.windows.net/media/2017/04/Windows-Container-Host-ACS-Kubernetes-1024x576.png" alt="windows-container-host-acs-kubernetes" width="879" height="494" class="alignnone wp-image-3915 size-large" /></a></p>
<p>In the absence of ACS-managed User-Defined Routes, Out-of-Band (OOB) configuration of these routes need to be realized in the Cloud Service Provider network, implemented using the “routing” interface of the Kubernetes cloud provider, or connected via overlay networks. Other solutions include using the HNS overlay network driver for inter-Pod communication or using the OVS Hyper-V switch extension with OVN Controller.</p>
<p>Today, with the publicly available versions of Windows server and client you can deploy Kubernetes with the following restrictions:</p>
<ul>
<li>One container per Pod</li>
<li>CNI Network Plugins are not supported</li>
<li>Each container requires two container endpoints (vNICs) with IP routing manually plumbed</li>
<li>Service IPs can only be associated with one Container Host and will not be load-balanced</li>
<li>Policy specifications (e.g. network security) are not supported</li>
</ul>
<h1>What’s Coming Next?</h1>
<p>Windows is moving to a faster release cadence such that new platform features will be made available in a matter of months rather than years. In some circumstances, early builds can be made available to Insiders as well as to TAP customers and EEAP partners for early feature validation.</p>
<p>Stay tuned for new features which will be made available soon…</p>
<h1>Summary</h1>
<p>In this blog post, I described some of the nuances of the Kubernetes networking model and how it differs from the Docker networking model. I also talked about the code updates made by Microsoft engineering teams to the kubelet and kube-proxy binaries for Windows in open source repos to enable networking support. Finally, we ended with how Kubernetes networking is implemented in Windows today and the plans for how it will be implemented through a CNI plugin in the near future…</p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/04/04/windows-networking-for-kubernetes/feed/</wfw:commentRss>
<slash:comments>0</slash:comments>
</item>
<item>
<title>Coming Soon: (It’s here) Transport Advancements in the Windows 10 Creators update</title>
<link>https://blogs.technet.microsoft.com/networking/2017/03/27/coming-soon-transport-advancements-in-the-windows-10-creators-update/</link>
<comments>https://blogs.technet.microsoft.com/networking/2017/03/27/coming-soon-transport-advancements-in-the-windows-10-creators-update/#comments</comments>
<pubDate>Mon, 27 Mar 2017 17:17:03 +0000</pubDate>
<dc:creator><![CDATA[Windows Networking Team [MSFT]]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3866</guid>
<description><![CDATA[Core Network Stack Features in the Creators Update for Windows 10 Windows 10 Creators update is coming soon along with an exciting array of new transport features. Stay tuned for the official announcement!... <a aria-label="read more about Coming Soon: (It’s here) Transport Advancements in the Windows 10 Creators update" href="https://blogs.technet.microsoft.com/networking/2017/03/27/coming-soon-transport-advancements-in-the-windows-10-creators-update/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p><a href="https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/"><span>Core Network Stack Features in the Creators Update for Windows 10</span></a></p>
<p>Windows 10 Creators update is coming soon along with an exciting array of new transport features. Stay tuned for the official announcement!</p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/03/27/coming-soon-transport-advancements-in-the-windows-10-creators-update/feed/</wfw:commentRss>
<slash:comments>2</slash:comments>
</item>
<item>
<title>How to find the SDN gateway local address for BGP peering in Windows Server 2016</title>
<link>https://blogs.technet.microsoft.com/networking/2017/03/23/how-to-find-the-sdn-gateway-local-address-for-bgp-peering-in-windows-server-2016/</link>
<comments>https://blogs.technet.microsoft.com/networking/2017/03/23/how-to-find-the-sdn-gateway-local-address-for-bgp-peering-in-windows-server-2016/#respond</comments>
<pubDate>Thu, 23 Mar 2017 16:17:24 +0000</pubDate>
<dc:creator><![CDATA[AnirbanPaul]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<category><![CDATA[BGP]]></category>
<category><![CDATA[Gateway]]></category>
<category><![CDATA[RRAS]]></category>
<category><![CDATA[SDN]]></category>
<category><![CDATA[Troubleshooting]]></category>
<category><![CDATA[Windows Server 2016]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3815</guid>
<description><![CDATA[A few days back, I wrote a blog post about some issues being faced by Software Defined Networking (SDN) customers. The issue was specific to changing VPN bandwidth settings in Windows Server 2016. You can read more about that issue and the solution here. Another area where we have seen customers struggle is finding out the... <a aria-label="read more about How to find the SDN gateway local address for BGP peering in Windows Server 2016" href="https://blogs.technet.microsoft.com/networking/2017/03/23/how-to-find-the-sdn-gateway-local-address-for-bgp-peering-in-windows-server-2016/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p>A few days back, I wrote a blog post about some issues being faced by Software Defined Networking (SDN) customers. The issue was specific to changing VPN bandwidth settings in Windows Server 2016. You can read more about that issue and the solution <a href="https://blogs.technet.microsoft.com/networking/2017/03/06/troubleshoot-configuring-sdn-ras-gateway-vpn-bandwidth-settings-in-virtual-machine-manager/">here</a>.</p>
<p>Another area where we have seen customers struggle is finding out the local SDN gateway server address. The local SDN gateway Server address is required for the following reasons:</p>
<ol>
<li>When you configure the remote VPN endpoint (in your enterprise or your local datacenter), you need to provide the local SDN gateway server address as the destination IP. This is the IP address advertised by the gateway for external connectivity</li>
<li>If you are using BGP for learning dynamic routes over VPN, you will need the local SDN gateway server address to configure the BGP peering information. Note that this address will be different from the destination IP I have mentioned above, since this is the IP address of the internal interface of the VPN server.</li>
</ol>
<h2>Finding the external address of SDN gateway</h2>
<p>This address will be used as the destination IP address when you configure the on-premise VPN server (or a GRE endpoint in the same datacenter). This address may be different for different tenants because the SDN gateway is a multi-tenant server.</p>
<p>This address is displayed in the System Center Virtual Machine Manager (SCVMM) console when you configure the connection, as depicted in the illustration below.</p>
<p><a href="https://msdnshared.blob.core.windows.net/media/2017/03/a2.jpg"><img width="300" height="223" class="alignnone size-medium wp-image-3835" alt="a" src="https://msdnshared.blob.core.windows.net/media/2017/03/a2-300x223.jpg" /></a></p>
<p> </p>
<h2>Finding the BGP router IP address of the SDN gateway</h2>
<h3>BGP Router IP for tenant connections</h3>
<p>If you are using Border Gateway Protocol (BGP) with your tenant IPsec, GRE or L3 connections for dynamically learning remote routes, you need to know the BGP router IP address so that you can configure that address as the peer address on the remote router. When you configure the VPN connections through SCVMM, SCVMM automatically assigns an IP Address from the gateway routing subnet to the tenant compartment of the gateway VM. SCVMM uses this IP address as the BGP router IP address. Because this router is tenant-specific, the router address is different for each tenant.</p>
<p>First, execute the following Windows Powershell commands on a Network Controller machine or a machine that is configured as a Network Controller client:</p>
<p><em>$gateway = Get-NetworkControllerVirtualGateway -ConnectionUri <REST uri of your deployment></em></p>
<p><em>$gateway.Properties.NetworkConnections.Properties.DestinationAddress</em></p>
<p>The results of this command can display multiple virtual gateways, depending on how many tenants have configured gateway connections. Also, each virtual gateway can have multiple connections (IPSec, GRE, L3). Because you already know the destination address of the connection, you can identify the correct connection based on the destination address. After you have the correct network connection, run the following command (on the corresponding virtual gateway) to get the BGP router IP address of the virtual gateway</p>
<p><em>$gateway.Properties.BgpRouters.Properties.RouterIp</em></p>
<p>The result of this command provides the IP address that you must configure on the remote router as the peer IP Address.</p>
<h3>BGP router IP for GRE gateway</h3>
<p>If you are using GRE connectivity in your SDN deployment, you must create a GRE VIP logical network and advertise the GRE VIPs from your SDN gateways to the physical network using internal BGP peering. You can get more details in the SDN planning document <a href="https://technet.microsoft.com/en-us/windows-server-docs/networking/sdn/plan/plan-a-software-defined-network-infrastructure">here</a>.</p>
<p>You need to create a BGP peer on the Top of Rack router (ToR) that is used by your SDN infrastructure to receive routes for the GRE VIP logical network advertised by the SDN Gateways. BGP peering only needs to occur one way (from SDN Gateway to external BGP peer). To configure the BGP peer, you will need to provide the peer IP i.e, the BGP router IP of the SDN gateways.</p>
<p>To get the BGP router IP of the SDN gateway, execute the following Powershell commands on a Network Controller machine or a machine that is configured as a Network Controller client:</p>
<p><em>$gateway = Get-NetworkControllerGateway -ConnectionUri <REST uri of your deployment></em></p>
<p><em>$gateway.Properties.BgpConfig.RouterIp</em></p>
<p>The result of this command provides the IP address that you must configure on the remote router as the peer IP Address.</p>
<p> </p>
<p>If you want to setup SDN through SCVMM, there is a bunch of detailed documentation on Technet <a href="https://technet.microsoft.com/en-us/system-center-docs/vmm/scenario/sdn-overview">here</a>. Before starting the deployment, please go through the SDN planning guidance <a href="https://technet.microsoft.com/en-us/windows-server-docs/networking/sdn/plan/plan-a-software-defined-network-infrastructure">here</a>.</p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/03/23/how-to-find-the-sdn-gateway-local-address-for-bgp-peering-in-windows-server-2016/feed/</wfw:commentRss>
<slash:comments>0</slash:comments>
</item>
<item>
<title>Troubleshoot Configuring SDN RAS Gateway VPN Bandwidth Settings in Virtual Machine Manager</title>
<link>https://blogs.technet.microsoft.com/networking/2017/03/06/troubleshoot-configuring-sdn-ras-gateway-vpn-bandwidth-settings-in-virtual-machine-manager/</link>
<comments>https://blogs.technet.microsoft.com/networking/2017/03/06/troubleshoot-configuring-sdn-ras-gateway-vpn-bandwidth-settings-in-virtual-machine-manager/#respond</comments>
<pubDate>Mon, 06 Mar 2017 17:38:31 +0000</pubDate>
<dc:creator><![CDATA[AnirbanPaul]]></dc:creator>
<category><![CDATA[Uncategorized]]></category>
<category><![CDATA[bandwidth]]></category>
<category><![CDATA[Gateway]]></category>
<category><![CDATA[RRAS]]></category>
<category><![CDATA[SDN]]></category>
<category><![CDATA[Troubleshooting]]></category>
<category><![CDATA[Windows Server 2016]]></category>
<guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3785</guid>
<description><![CDATA[I wanted to share some of my experiences with debugging Windows Server 2016 Software Defined Networking (SDN) related customer issues. These issues are related to SDN RAS Gateways.If you’ve deployed Software Defined Networking (SDN) in Windows Server 2016 Datacenter by using System Center Virtual Machine Manager (SCVMM), you might have encountered problems configuring the RAS Gateway... <a aria-label="read more about Troubleshoot Configuring SDN RAS Gateway VPN Bandwidth Settings in Virtual Machine Manager" href="https://blogs.technet.microsoft.com/networking/2017/03/06/troubleshoot-configuring-sdn-ras-gateway-vpn-bandwidth-settings-in-virtual-machine-manager/" class="read-more">Read more</a>]]></description>
<content:encoded><![CDATA[<p><span>I wanted to share some of my experiences with debugging Windows Server 2016 Software Defined Networking (SDN) related customer issues. These issues are related to SDN RAS Gateways.If you’ve deployed Software Defined Networking (SDN) in Windows Server 2016 Datacenter by using System Center Virtual Machine Manager (SCVMM), you might have encountered problems configuring the RAS Gateway virtual private network (VPN) connection inbound and outbound bandwidth settings.</span></p>
<p>Gateways are used in SDN to provide external connectivity to a virtual network. This can be connectivity to an on-premises network or to the physical network in the same datacenter. You can get more information about gateways in the topic <a href="https://technet.microsoft.com/en-us/windows-server-docs/networking/sdn/technologies/network-function-virtualization/ras-gateway-for-sdn">RAS Gateway for SDN</a>.</p>
<p><strong>Issue #1</strong></p>
<p>The customer was unable to change VPN connection inbound and outbound bandwidth settings by using the SCVMM user interface (UI) setting <strong>Maximum Incoming</strong> and <strong>Maximum Outgoing</strong>.</p>
<p><a href="https://msdnshared.blob.core.windows.net/media/2017/03/scvmm-01.jpg"><img width="300" height="226" class="alignnone size-medium wp-image-5535" alt="scvmm-01" src="https://msdnshared.blob.core.windows.net/media/2017/03/scvmm-01-300x226.jpg" /></a></p>
<p><span>When the customer tried to change these gateway bandwidth settings from the SCVMM UI, he received the error ID 26909, <strong>Network service ‘SA19N30NC’ doesn’t support this type of traffic metering, </strong>as depicted in the following screen shot.</span></p>
<p><a href="https://msdnshared.blob.core.windows.net/media/2017/03/scvmm-02.jpg"><img width="300" height="226" class="alignnone size-medium wp-image-5545" alt="scvmm-02" src="https://msdnshared.blob.core.windows.net/media/2017/03/scvmm-02-300x226.jpg" /></a></p>
<p><strong>Solution for Issue #1</strong></p>
<p>SCVMM currently does not support changing bandwidth settings for a VPN connection. They will start supporting this shortly. By default, the inbound and outbound bandwidth is set as 500 Kbps.</p>
<p>Meanwhile, if you want to change bandwidth settings, you can use the Network Controller Windows PowerShell command <a href="https://technet.microsoft.com/itpro/powershell/windows/network-controller/new-networkcontrollervirtualgatewaynetworkconnection">New-NetworkControllerVirtualGatewayNetworkConnection</a> with the parameters <strong>OutboundKiloBitsPerSecond</strong> and <strong>InboundKiloBitsPerSecond</strong>.</p>
<p><em>NOTE: If you make any other changes to the VPN connection through SCVMM after changing the bandwidth settings, the bandwidth settings will be reset to the default (500 Kbps). So, you will need to run the Network Controller Powershell again to update the bandwidth settings.</em></p>
<p><strong>Issue #2</strong></p>
<p><span>Even after changing the VPN network connection bandwidth settings to 200 Mbps by using Network Controller Windows PowerShell commands, the customer observed a bandwidth cap of about 150 Mbps for the connection.</span></p>
<p><strong>Solution for Issue #2</strong></p>
<p>The customer had set the gateway capacity as 1000 Mbps (this is the default value in the SCVMM UI). <span>The <strong>Gateway capacity (Mbps)</strong> parameter denotes the normal TCP bandwidth which is expected out of the gateway VM. Customer should fill this accordingly based on his underlying network speed.</span></p>
<p><a href="https://msdnshared.blob.core.windows.net/media/2017/03/scvmm-03.jpg"><img width="300" height="226" class="alignnone size-medium wp-image-5555" alt="scvmm-03" src="https://msdnshared.blob.core.windows.net/media/2017/03/scvmm-03-300x226.jpg" /></a></p>
<p><span>Maximum IPsec tunnel bandwidth is limited to (3/20)* Gateway Capacity on a particular gateway. So, if the gateway capacity is set to 1000 Mbps, the equivalent IPsec tunnel capacity would be 150 Mbps.</span></p>
<p><span>The equivalent ratios for GRE and L3 tunnels are 1/5 and 1/2, respectively.</span></p>
<p><span>NOTE: You must be wondering why the customer was allowed to add a connection with 200 Mbps bandwidth if the gateway did not have available capacity. Actually, the configuration change never succeeded. This configuration change is an asynchronous operation. After changing the settings, if the customer had executed <strong>Get-NetworkControllerVirtualGatewayNetworkConnection</strong> and checked the <strong>ConfigurationState</strong> of the resource, the “Status” would have been “Failure” with “DetailedInfo” giving more details about the error. </span></p>
<p>If you want to setup SDN through SCVMM, see the topic <a href="https://technet.microsoft.com/en-us/system-center-docs/vmm/scenario/sdn-overview">Set up a Software Defined Network (SDN) infrastructure in the VMM fabric</a>. Before starting the setup, you can review the SDN planning guidance in the topic <a href="https://technet.microsoft.com/en-us/windows-server-docs/networking/sdn/plan/plan-a-software-defined-network-infrastructure">Plan a Software Defined Network Infrastructure</a>.</p>
<p>Anirban Paul, Senior Program Manager</p>
]]></content:encoded>
<wfw:commentRss>https://blogs.technet.microsoft.com/networking/2017/03/06/troubleshoot-configuring-sdn-ras-gateway-vpn-bandwidth-settings-in-virtual-machine-manager/feed/</wfw:commentRss>
<slash:comments>0</slash:comments>
</item>
</channel>
</rss>
