Mobilize your workloads with software-defined networking

<?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>Thu, 06 Apr 2017 15:28:48 +0000</lastBuildDate> <language>en-US</language> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <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 &#8220;containerized&#8221; 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 &#8220;containerized&#8221; 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) &#8211; which is used in both Azure Container Service (ACS) Windows worker nodes and on-premises deployments &#8211; 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&amp;t=6s&amp;list=PL69nYSiGNLP2OH9InCcNkWNu2bl-gmIU4&amp;index=1"><em>https://www.youtube.com/watch?v=P-D8x2DndIA&amp;t=6s&amp;list=PL69nYSiGNLP2OH9InCcNkWNu2bl-gmIU4&amp;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 &#8220;automate the deployment, scaling, and management of &#8216;containerized&#8217; applications&#8221;. 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 &#8220;Routing&#8221; 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 &#8211; <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> &#8211; 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&#8217;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&#8217; 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 &#8211; connected to the Service and Pod networks &#8211; 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 &#8220;routing&#8221; 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&#8217;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&#8230;</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&#8230;</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: 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/#respond</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[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: 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>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>0</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>&nbsp;</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 &lt;REST uri of your deployment&gt;</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 &lt;REST uri of your deployment&gt;</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>&nbsp;</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> <item> <title>Dynamic DNS registration process can cause queue build up and failures</title> <link>https://blogs.technet.microsoft.com/networking/2016/11/25/dynamic-dns-registration-process-can-cause-queue-build-up-and-failures/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/11/25/dynamic-dns-registration-process-can-cause-queue-build-up-and-failures/#respond</comments> <pubDate>Fri, 25 Nov 2016 11:55:26 +0000</pubDate> <dc:creator><![CDATA[Kaushik Ainapure [MSFT]]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3745</guid> <description><![CDATA[Hey Folks! Ajay Sarkaria here with new information on the changes in dynamic DNS registrations. In the past, we have had many customers who call Microsoft support with scenarios where dynamic DNS registration from a Microsoft DHCP server either fail or is delayed. This causes printers or other critical devices to not get registered or... <a aria-label="read more about Dynamic DNS registration process can cause queue build up and failures" href="https://blogs.technet.microsoft.com/networking/2016/11/25/dynamic-dns-registration-process-can-cause-queue-build-up-and-failures/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p>Hey Folks! Ajay Sarkaria here with new information on the changes in dynamic DNS registrations. In the past, we have had many customers who call Microsoft support with scenarios where dynamic DNS registration from a Microsoft DHCP server either fail or is delayed. This causes printers or other critical devices to not get registered or get registered with delays.</p> <p>This issue has been difficult to diagnose as the current logs did not provide adequate visibility into the reasons for the failures.</p> <h5>Scenario:</h5> <p>Dynamic DNS updates are attempts to update the PTR record, which is often done in conjunction with HOST A record update. In order to send a PTR update an SOA query is made first for the reverse record for the host to see who is authoritative to accept the update. In case the DNS Server does not have a reverse lookup zone, an error sent back to the DHCP server is interpreted as a general update failure, and this would cause re-queuing of the update request at the DHCP server, eventually causing a queue build-up.</p> <h6>Symptoms:</h6> <ul> <li>Devices after a renewal from Microsoft DHCP Server, fail to update their records in DNS</li> </ul> <p><b><u>For context, the following is how DHCP server-DNS client interaction works:</u></b></p> <p>Whenever a device obtains a new IP address lease from the DHCP server, DHCP server sends a dynamic DNS update request to the DNS server. The DHCP Server does so by calling a DNS client API which puts the request in the dynamic DNS update processing queue of the DNS client. At start of the DHCP server service, DHCP server sets the length of the dynamic DNS update queue in the DNS client. By default, it is set to 2048. It can be overridden by a DHCP server registry key. DHCP server registers a callback function with the DNS client to be called once the dynamic DNS update is completed either successfully or otherwise. DNS clients make 3 attempts to register each DNS record in the queue with a time interval of 5 minutes between retries. When the number of attempts are unsuccessful or the registration is successful, DNS client de-queues the request and calls DHCP server via a callback function indicating success or failure. If the callback function indicates a failure of the registration, DHCP server maintains in it’s lease database that this DNS update status for the lease is “Pending”.</p> <p>If the dynamic DNS registration is successful, it’s marked as “Complete”. A background process (scavenger) in DHCP server wakes up every hour, goes through the lease database and calls the DNS client API to register leases where the DNS update status is “Pending”. These attempts also go to the same DNS client queue mentioned above. If the queue becomes full, scavenger does not call the DNS registration API and moves to process the next unregistered IP address in the lease database.</p> <p>What has been observed is there is often a missing configuration which causes failure of dynamic DNS registration. The more common one being reverse lookup zone not being present. Given the above implementation, in a situation where the reverse lookup zone is not present, the queue inside the DNS client builds up and causes long delays in the registration of other DHCP clients which should have gone through.</p> <p><b><u>To alleviate this problem, the below was done: </u></b></p> <h4><b>On Windows Server 2016: </b></h4> <ol> <li>Currently the DHCP server logs do not give information to an administrator on why the DNS registrations are failing. New events are added in DHCP server on Windows Server 2016 which will help to easily identify that the DNS registration is failing because of a missing reverse lookup zone. You can then resolve the issue by adding that zone on the DNS server. <p><b><strong>New Events in Windows Server 2016:</strong></b></li> </ol> <table width="611" border="1" cellspacing="0" cellpadding="0"> <tbody> <tr> <td width="112" valign="top"><b>Event Category</b></td> <td width="512" valign="top"><b>Event Text</b></td> </tr> <tr> <td width="112" valign="top">DHCPv4.ForwardRecordDNSFailure</td> <td width="512" valign="top">Forward record registration for IPv4 address %1 and FQDN %2 failed with error %3. This is likely to be because the forward lookup zone for this record does not exist on the DNS server.</td> </tr> <tr> <td width="102" valign="top">DHCPv4.ForwardRecordDNSTimeout</td> <td width="512" valign="top">Forward record registration for IPv4 address %1 and FQDN %2 failed with error %3.</td> </tr> <tr> <td width="102" valign="top">DHCPv4.PTRRecordDNSFailure</td> <td width="512" valign="top">PTR record registration for IPv4 address %1 and FQDN %2 failed with error %3. This is likely to be because the reverse lookup zone for this record does not exist on the DNS server.</td> </tr> <tr> <td width="102" valign="top">DHCPv4.PTRRecordDNSTimeout</td> <td width="512" valign="top">PTR record registration for IPv4 address %1 and FQDN %2 failed with error %3</td> </tr> <tr> <td width="102" valign="top">DHCPv6.ForwardRecordDNSFailure</td> <td width="512" valign="top">Forward record registration for IPv6 address %1 and FQDN %2 failed with error %3. This is likely to be because the forward lookup zone for this record does not exist on the DNS server.</td> </tr> <tr> <td width="112" valign="top">DHCPv6.ForwardRecordDNSTimeout</td> <td width="512" valign="top">Forward record registration for IPv6 address %1 and FQDN %2 failed with error %3.</td> </tr> <tr> <td width="102" valign="top">DHCPv6.PTRRecordDNSFailure</td> <td width="512" valign="top">PTR record registration for IPv6 address %1 and FQDN %2 failed with error %3. This is likely to be because the reverse lookup zone for this record does not exist on the DNS server.</td> </tr> <tr> <td width="102" valign="top">DHCPv6.PTRRecordDNSTimeout</td> <td width="512" valign="top">PTR record registration for IPv6 address %1 and FQDN %2 failed with error %3.</td> </tr> <tr> <td width="102" valign="top">DHCPv4.ForwardRecordDNSError</td> <td width="512" valign="top">Forward record registration for IPv4 address %1 and FQDN %2 failed with error %3 (%4).</td> </tr> <tr> <td width="102" valign="top">DHCPv4.PTRRecordDNSError</td> <td width="512" valign="top">PTR record registration for IPv4 address %1 and FQDN %2 failed with error %3 (%4).</td> </tr> <tr> <td width="102" valign="top">DHCPv6.ForwardRecordDNSError</td> <td width="512" valign="top">Forward record registration for IPv6 address %1 and FQDN %2 failed with error %3 (%4).</td> </tr> <tr> <td width="102" valign="top">DHCPv6.PTRRecordDNSError</td> <td width="512" valign="top">PTR record registration for IPv6 address %1 and FQDN %2 failed with error %3 (%4).</td> </tr> </tbody> </table> <p>2. The second change is related to retries in the DNS client. The current implementation made 3 attempts at failed registrations with a time interval of 5 minutes between them. In the scenario of a missing DNS zone, there will be several registrations which will fail and will be present in the DNS client queue for as long as 10 minutes. This causes the queue length to be hit and other valid registrations do not get done or get delayed a lot. In other words, the impact of a missing configuration like reverse lookup zone not being present becomes quite severe.</p> <p>So, a change was made in DNS client to not make any retries for failed registrations. Failed registrations will anyway be retried by the scavenger in the DHCP server as mentioned above. This will ensure that in cases when a zone is not present, the failed registration does not stay in the queue for a long time and the queue build will not be seen. This feature is enabled by default in Windows Server 2016.</p> <h4><b>On Windows Server 2012 R2: </b></h4> <ul> <li>The change in Windows Server 2012 R2 is related to only the retries in the DNS client as mentioned in # 2 above for Windows Server 2016 &amp; no additional events have been added.</li> </ul> <p><b><u>How to get this change on Windows Server 2012 R2?</u></b></p> <p>The change <b>(not enabled by default)</b> is part of the following Monthly Quality Rollup for Windows Server 2012 R2:</p> <blockquote> <h6><a target="_blank" href="https://support.microsoft.com/en-us/kb/3197875">November 2016 Preview of Monthly Quality Rollup for Windows 8.1 and Windows Server 2012 R2</a></h6> </blockquote> <p><strong>Important:</strong> The behavior does not change by simply installing the Monthly Quality Rollup for Windows Server 2012 R2 (<a href="https://support.microsoft.com/en-us/kb/3197875">KB3197875</a>). It is controlled by a registry setting which needs to be implemented:</p> <p><b>Disclaimer</b>: It is always a good idea to take a backup of the registry key before making any changes so please do that!</p> <ol> <li>Create a new key called <i>&#8220;DnsRegistrationMaxRetries&#8221;</i> of type DWORD under<br /> HKLM\System\CurrentControlSet\Services\DhcpServer\Parameters</li> <li>Set the value of <i>&#8220;DnsRegistrationMaxRetries&#8221;</i> to <b>0</b></li> <li>Reboot the DHCP Server</li> </ol> <p><b>Note</b>: If you already have <a href="https://support.microsoft.com/en-us/kb/3197875">KB3197875</a> installed, the <i>“DnsRegistrationMaxRetries”</i> may exist with value <b>3</b>. You need to change the value to <b>0</b> and reboot the DHCP Server.</p> <p>Until next time!</p> <p>Ajay Sarkaria<br /> Microsoft</p> <p>&nbsp;</p> <p><b></b></p> <p>&nbsp;</p> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/11/25/dynamic-dns-registration-process-can-cause-queue-build-up-and-failures/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Network Virtualization in the Windows Server 2016 Software Defined Networking (SDN) Stack</title> <link>https://blogs.technet.microsoft.com/networking/2016/10/26/network-virtualization-with-ws2016-sdn/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/10/26/network-virtualization-with-ws2016-sdn/#comments</comments> <pubDate>Wed, 26 Oct 2016 20:59:08 +0000</pubDate> <dc:creator><![CDATA[Windows Networking Team [MSFT]]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[HNV]]></category> <category><![CDATA[Networking]]></category> <category><![CDATA[SDN]]></category> <category><![CDATA[VXLAN]]></category> <category><![CDATA[Windows Server]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3685</guid> <description><![CDATA[By Jason Messer, Senior Program Manager Using VXLAN for Encapsulation and OVSDB for Policy Distribution Windows Server 2016 is the perfect platform for building your Software-Defined Data Center (SDDC) with new layers of security and Azure-inspired innovation for hosting business applications and infrastructure. A critical piece of this SDDC is the new Software Defined Network... <a aria-label="read more about Network Virtualization in the Windows Server 2016 Software Defined Networking (SDN) Stack" href="https://blogs.technet.microsoft.com/networking/2016/10/26/network-virtualization-with-ws2016-sdn/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p><em>By Jason Messer, Senior Program Manager</em></p> <p><em>Using VXLAN for Encapsulation and OVSDB for Policy Distribution</em></p> <p>Windows Server 2016 is the perfect platform for building your Software-Defined Data Center (SDDC) with new layers of security and Azure-inspired innovation for hosting business applications and infrastructure. A critical piece of this SDDC is the new Software Defined Network (SDN) Stack which provides agility, dynamic security, and hybrid flexibility by enforcing network policy in the Hyper-V Virtual Switch using the Azure Virtual Filtering Platform (VFP) Switch Extension. Instead of programming network configurations into a physical switch using CLI, NetConf, or OpenFlow, the network policy is instead delivered from the new Microsoft Network Controller to the Hyper-V Hosts using the OVSDB protocol and programmed into the VFP extension of the vSwitch by a Host Agent which enforces the policy. By creating overlay virtual networks (VXLAN Tunnels / logical switches) and endpoints which terminate in the vSwitch, each Hyper-V host becomes a software VXLAN Tunnel End Point (VTEP).</p> <p><em>Note: This will be a technical post focusing on networking protocols and some implementation details</em></p> <h1>Virtual Networking</h1> <p>Overlays, VXLAN, virtual networking, HNV, encapsulation, NVGRE, logical switch… why should you care about all these esoteric networking terms? Maybe you have heard hard-core networking types mention these in passing or have customers asking how Microsoft’s network virtualization solution compares with other solutions. Why should you care? <em><u>Because just as compute and storage have been virtualized, traditional networking devices and services are also being virtualized for greater flexibility.</u></em></p> <p>Server hardware is now virtualized through software to mimic CPUs, memory, and disks to create virtual machines. Network hardware is also being virtualized to mimic switches, routers, firewalls, gateways, and load balancers to create <strong>virtual networks</strong>. Not only do virtual networks provide isolation between workloads, tenants, and business units but they also allow IT and network administrators to configure networks and define policy with agility while realizing increased flexibility in where VMs are deployed and workloads run.</p> <p>Virtual networks still require physical hardware and IP networks to connect servers and VMs together. However, the packets transmitted between VMs across these physical links are <strong>encapsulated</strong> within physical network IP packets to create an <strong>overlay</strong> network – Reference Figure 1. This means that the original packet from the VM with its MAC and IP addresses, TCP/UDP ports, and data remains unchanged and is simply placed inside of an IP packet on the physical network. The physical network underneath is then known as the underlay or transport network – traditionally Microsoft has called this the HNV Provider (or PA) network.</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/10/VXLANEncap.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/10/VXLANEncap-300x169.jpg" width="300" height="169" class="alignnone wp-image-3695 size-medium" /></a></p> <p><em><u>Figure 1 – VXLAN Encapsulation</u></em></p> <p>The idea of network virtualization to guarantee isolation has been around for some time in the form of VLANs. VLANs allow network traffic to be “tagged” with an identifier to create logical network segments and segregate network traffic into broadcast and isolation domains. However, VLANs are largely <em>static configurations</em> programmed on individual switch ports and network adapters. Anytime a server or VM moves, the VLAN configuration must be updated (sometimes in multiple places) and the IP addresses of that workload or VM may need to be changed as well. Moreover, since VLANs use a 12-bit field for the network identifier, there is a limit of 4096 logical network segments which can be created.</p> <h1>Hyper-V Network Virtualization (HNV)</h1> <p>The network virtualization solution in Windows Server 2012 and 2012R2 – Hyper-V Network Virtualization (<strong>HNV</strong>) – used an encapsulation format known as <strong>NVGRE</strong> (<a href="https://datatracker.ietf.org/doc/rfc7637/">RFC 7637</a>) to create overlay networks based on network policy managed through SCVMM and programmed through WMI / PowerShell. Another popular industry protocol for encapsulation is <strong>VXLAN </strong>(<a href="https://tools.ietf.org/html/rfc7348">RFC 7348</a>) including guidance on how to distribute or exchange <strong>VXLAN Tunnel Endpoint (VTEP)</strong> information between virtual and physical devices – e.g. Hardware VTEPs.</p> <p><em>Note: The HNV solution in Windows Server 2012 and 2012R2 which used NVGRE for encapsulation and WMI/PowerShell for management is still available in Windows Server 2016. We strongly recommend customers move to Windows Server 2016 and the new SDN stack, as the bulk of development and innovation will occur on this stack as opposed to HNVv1.</em></p> <p>In talking with customers, we observed some confusion around which encapsulation protocol to use (VXLAN or NVGRE), which was taking focus away from the higher-level value of network virtualization. Consequently, in Windows Server 2016 (WS2016), we support both NVGRE and VXLAN encapsulation protocols, with the default being VXLAN. We also built the Microsoft Network Controller as a programmable surface to create and manage these virtual networks and apply fine-grained policies for security, load balancing, and Quality of Service (QoS). A distinct management-plane – either PowerShell scripts, System Center Virtual Machine Manager (SCVMM), or the Microsoft Azure Stack (MAS) components – programs network policy through the RESTful API exposed by the Microsoft Network Controller. The Network Controller then distributes this policy to each of the Hyper-V hosts using the OVSDB Protocol and a set of schemas to represent virtual networks, ACLs, user-defined routing, and other policy.</p> <p>Like VLANs, both NVGRE and VXLAN provide isolation by including an identifier (e.g. VXLAN Network Identifier – VNI) to identify the logical network segment (virtual subnet). In WS2016, multiple VNIs (or virtual subnets) can be combined within a <strong>Routing Domain</strong> so that isolation between tenant virtual networks is maintained thereby allowing for overlapping IP address spaces.  A network compartment is created on the Hyper-V host for each routing domain with a Distributed Router used to route traffic between virtual subnets for a given tenant. Admins can also create User-Defined Routes to chain virtual appliances into the traffic path for increased security and functionality. Unlike physical networks with VLANs where policy is closely tied to location and the physical port to which a server (hosting a VM) is attached, a network endpoint (VM) is free to move across the datacenter while ensuring that all policy moves along with it.</p> <p><em></em>As network equipment manufacturers build support for VXLAN into their NIC cards, switches, and routers, they can support:</p> <ul> <li>Encapsulation Task Offloads to offload operations from the OS and Host CPU onto the NIC Card</li> <li>ECMP Spreading using the UDP source port as a hash to distribute connections</li> </ul> <p>Microsoft has worked with the major NIC vendors to ensure support exists for both NVGRE and VXLAN Task Offloads in Windows Server 2016 NIC drivers. These offloads take the processing burden off the Host CPU and instead perform functions such as LSO and Inner Checksums on the physical NIC card itself. Moreover, Microsoft conforms to the standard VXLAN UDP source port hash over the inner packet to ensure ECMP spreading for different connections will just work from ECMP-enabled routers.</p> <h1>VXLAN Implementation in Windows Server 2016</h1> <p>TCP/IP stacks rely on the Address Resolution Protocol (ARP) and port learning performed by traditional layer-2 switches to determine the MAC address of the remote hosts and the ports on a switch to which they are connected. Overlay Virtual Networking encapsulates the VM traffic’s packet headers and data (inner packet) inside of a Layer-3 IP (outer) packet transmitted on the underlay (physical) network. Therefore, before a VM attached to a virtual network can send a unicast packet destined for another VM in the same virtual subnet, it must first learn or be told the remote VM MAC address as well as the VTEP IP address of the host on which the VM is running. This allows the VM to place the correct Destination MAC address in the inner packet’s Ethernet header and for the host to build the encapsulated packet with the correct Destination IP address to deliver the packet to the remote host.</p> <p>The VXLAN RFC talks about different approaches for distributing the VTEP IP to VM MAC mapping information:</p> <ol> <li>Learning-based control plane</li> <li>Central Authority-/directory-based lookup</li> <li>Distribution of this mapping information to the VTEPs by the central authority</li> </ol> <p>In a learning-based control-plane, encapsulated packets having an unknown destination (VTEP IP) are sent out via broadcast or to an IP multicast group. This requires a mapping between a multicast group and each virtual subnet (identified by a VXLAN Network Identifier (VNI)) such that any VTEPs which host VMs attached to this VNI register for the group through IGMP. The VM MAC addresses and remote host’s IP address (VTEP IP) are then discovered via source-address learning. A clear disadvantage of this approach is that it places a lot of unnecessary traffic on the wire which most network administrators try to avoid.</p> <p>Based on our learnings in Azure, Microsoft chose the distribution by a central authority (i.e. Microsoft Network Controller) approach to send out the VM MAC : VTEP IP mapping information to avoid the unnecessary broadcast/multicast network traffic. The Microsoft Network Controller (OVSDB Client) communicates with the Hyper-V Hosts (VTEPs) using the OVSDB protocol with policy represented in schemas persisted to a Host Agent’s database (OVSDB Server). A local ARP responder on the host is then able to catch and respond to all ARP requests from the VMs to provide the destination MAC address of the remote VM. The Host Agent database also contains the VTEP IP address of all hosts attached to the virtual subnet. The Host Agent programs mapping rules into the VFP extension of the Hyper-V Virtual Switch to correctly encapsulate and send the VM packet based on the destination VM.</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/10/NC-HA-Communication.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/10/NC-HA-Communication-300x169.jpg" alt="NC-HA Communication" width="300" height="169" class="alignnone size-medium wp-image-3705" /></a></p> <p><em><u>Figure 2 – Network Controller &#8211; Host Agent Communication</u></em></p> <h1>Looking Ahead</h1> <p>At present, Microsoft’s implementation of VXLAN does not support interoperability with third party hardware VTEPs due to a difference in OVSDDB schemas. We created a custom OVSDB schema to convey additional policy information such as ACLs and service chaining which was not available in the initial hardware_VTEP schema. However, support for the core protocols  (VXLAN, OVSDB) is in place in the platform for us to bring in support for hardware VTEPs in the future. Our current thinking on implementation is that we will support the hardware_VTEP schema in our Network Controller and distribute mapping information to the hardware VTEPs. We do not think that a learning-based control plane is the right solution due to the increased amount of multicast/broadcast required on the network – network admins are already trying to limit this L2 traffic which by some accounts consumes 50% of network capacity.</p> <p>If this is something of interest, please do reply in the comments field below and let us know. We’d love to speak with you.</p> <h1>SDN Network Virtualization Key Features</h1> <ul> <li>Create thousands of logical network segments</li> <li>User-Defined Routing (UDR) for Virtual Appliances</li> <li>Multi-tenancy support through individual routing domains</li> <li>VXLAN and NVGRE encapsulation</li> <li>Distributed Router on each Hyper-V host</li> <li>Integration with Software Load Balancer (SLB), Gateways, QoS, and Distributed Firewall</li> <li>Network virtualization policy programmed through the Microsoft Network Controller using OVSDB</li> </ul> <p>&nbsp;</p> <h1>RESOURCES</h1> <h3>Documentation</h3> <ul> <li><a href="https://technet.microsoft.com/en-us/library/mt403307.aspx">Planning and Deployment</a></li> <li><a href="https://technet.microsoft.com/en-us/library/dn931986.aspx">Hyper-V Network Virtualization</a></li> <li><span> </span><a href="https://technet.microsoft.com/en-us/library/mt703757.aspx">Manage Tenant Virtual Networks</a></li> </ul> <h3>Deployment Scripts</h3> <ul> <li><span> </span><a href="https://github.com/Microsoft/SDN">Microsoft/SDN GitHub repo</a></li> </ul> <h3>Blogs</h3> <ul> <li><a href="https://blogs.technet.microsoft.com/windowsserver/2016/04/20/ten-reasons-youll-love-windows-server-2016-7-software-defined-networking/">Ten reasons you&#8217;ll love Windows Server 2016 #7: Software-defined networking</a></li> <li><a href="https://blogs.technet.microsoft.com/windowsserver/2015/11/04/4-datacenter-challenges-and-how-windows-server-2016-software-defined-networking-can-help/">4 datacenter challenges and how SDN can help</a></li> </ul> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/10/26/network-virtualization-with-ws2016-sdn/feed/</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>An Update on Windows TCP AutoTuningLevel</title> <link>https://blogs.technet.microsoft.com/networking/2016/08/11/an-update-on-windows-tcp-autotuninglevel/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/08/11/an-update-on-windows-tcp-autotuninglevel/#respond</comments> <pubDate>Thu, 11 Aug 2016 22:31:49 +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=3645</guid> <description><![CDATA[Daniel Havey, Praveen Balasubramanian Like all modern operating systems Windows has receive window auto-tuning to dynamically adjust the receive buffer size to the throughput and latency of the link. Disabling this feature will definitely limit your Internet speeds. Auto-tuning is consistent throughout all variants of TCP and present in all modern operating systems.   In... <a aria-label="read more about An Update on Windows TCP AutoTuningLevel" href="https://blogs.technet.microsoft.com/networking/2016/08/11/an-update-on-windows-tcp-autotuninglevel/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p><span style="color: #5a5a5a;font-family: Calibri">Daniel Havey, Praveen Balasubramanian</span></p> <p>Like all modern operating systems Windows has receive window <a href="https://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx">auto-tuning</a> to dynamically adjust the receive buffer size to the throughput and latency of the link. Disabling this feature will <strong>definitely limit your Internet speeds. </strong>Auto-tuning is consistent throughout all variants of TCP and present in all modern operating systems. <span> </span> In the modern Internet the range of latencies and throughput speeds that must be accommodated is simply too large to manage statically and must be adjusted dynamically. If you have changed your AutoTuningLevel to disabled, please reset it to <span> </span>normal in order to restore your Internet speeds using the following commands in an elevated command prompt:</p> <blockquote> <pre>PS C:\WINDOWS\system32&gt; netsh int tcp set global autotuninglevel=normal Ok. PS C:\WINDOWS\system32&gt; netsh interface tcp show global Querying active state... TCP Global Parameters ---------------------------------------------- Receive-Side Scaling State     : enabled Chimney Offload State                : disabled NetDMA State                         : disabled Direct Cache Access (DCA)            : disabled <strong>Receive Window Auto-Tuning Level      : normal</strong> Add-On Congestion Control Provider   : none ECN Capability                       : disabled RFC 1323 Timestamps                  : disabled Initial RTO                          : 3000 Receive Segment Coalescing State     : disabled Non Sack Rtt Resiliency              : disabled Max SYN Retransmissions              : 2 TCP Fast Open                        : enabled</pre> </blockquote> <p>Some of the confusion may have originated from a misinterpretation of a blog post which suggests disabling heuristics with the following command:</p> <blockquote> <pre>netsh interface tcp set heuristics disabled</pre> </blockquote> <p>Heuristics is a feature that can interfere with auto-tuning and disabling it can improve Internet speeds and in fact heuristics have already been disabled in Windows 8.1 and greater. Auto-Tuning on the other hand should NEVER be disabled.</p> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/08/11/an-update-on-windows-tcp-autotuninglevel/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>How to prevent accidental DNS Zone deletions in Windows Server</title> <link>https://blogs.technet.microsoft.com/networking/2016/08/11/how-to-prevent-accidental-dns-zone-deletions-in-windows-server/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/08/11/how-to-prevent-accidental-dns-zone-deletions-in-windows-server/#respond</comments> <pubDate>Thu, 11 Aug 2016 13:29:34 +0000</pubDate> <dc:creator><![CDATA[Kaushik Ainapure [MSFT]]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[Deletion]]></category> <category><![CDATA[DNS Zone]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3605</guid> <description><![CDATA[My name is Ajay Sarkaria and I am a Supportability Program Manager at Microsoft. We have been seeing support volumes where administrators while performing daily tasks may accidentally delete a DNS Zone which is being used in production. This post comes with inputs from our friends in Microsoft PFE team Brent Whitlow; Bryan Zink; Michael... <a aria-label="read more about How to prevent accidental DNS Zone deletions in Windows Server" href="https://blogs.technet.microsoft.com/networking/2016/08/11/how-to-prevent-accidental-dns-zone-deletions-in-windows-server/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p>My name is Ajay Sarkaria and I am a Supportability Program Manager at Microsoft. We have been seeing support volumes where administrators while performing daily tasks may accidentally delete a DNS Zone which is being used in production.</p> <p>This post comes with inputs from our friends in Microsoft PFE team <b>Brent Whitlow; <strong>Bryan Zink; Michael Hildebrand &amp; Eric Jansen</strong></b></p> <p><b>Note</b>: After you follow the below steps, you will not be able to delete or change the scope of replication for the DNS Zone unless you first unprotect the zone from accidental deletion.</p> <p>Example screenshot if trying to delete from Active Directory Users and Computers:</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion1.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion1-300x104.jpg" alt="DNS_Zone_Deletion1" width="476" height="165" class="alignnone wp-image-3637" /></a></p> <p><i>“You do not have sufficient permissions to delete DNZ_Zone_Name, or this object is protected from accidental deletion”</i></p> <p>OR</p> <p>Example screenshot if trying to delete from the DNS Manager:</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion2.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion2.jpg" alt="DNS_Zone_Deletion2" width="256" height="163" class="alignnone size-full wp-image-3606" /></a></p> <p><i>The zone cannot be deleted.<br /> </i><i>Access was denied</i></p> <p>If you try to change the scope of replication with the protection enabled, you will see a message similar to the below:</p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion3.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion3-300x254.jpg" alt="DNS_Zone_Deletion3" width="401" height="340" class="alignnone wp-image-3615" /></a></p> <p><i>The replication scope could not be set. For more information, see &#8220;DNS zone replication in Active Directory&#8221; in Help and Support. The error was: </i></p> <p><i>Access was denied.</i></p> <p>&nbsp;</p> <p>Now, am going to highlight steps which an administrator can perform to prevent such accidental deletions in the first place. If you remember, Active Directory has a great feature which prevents accidental deletions of Organizational Units by checking a flag. We are going to discuss something similar to prevent accidental DNS Zone deletions.</p> <p><b>Important:</b> As with any changes, you should <strong><u>always</u></strong> exercise caution and test things out in a lab BEFORE implementing any changes to your production environment.</p> <p>Ensuring you have a LAB setup to test the changes first, let’s configure the DNS Zones from accidental deletions. There are a couple of way to prevent accidental DNS zone deletions</p> <p><b>DNS Zones stored in the Domain Partition:</b></p> <p>Doing it from the Active Directory Users &amp; Computers MMC:</p> <ol> <li>Check the flag of “<i>Protect object from accidental deletion”</i> by browsing to Active Directory Users and Computers \ Domain Name \ System \ Microsoft DNS \ DNS Zone name</li> <li>Right click and select properties</li> <li>Select the Object Tab<a href="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion4.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion4-261x300.jpg" alt="DNS_Zone_Deletion4" width="353" height="406" class="alignnone wp-image-3625" /></a><b>Note</b>: The above flag will only be visible in Active Directory Users and Computers if you have stored the DNS Zone in the Domain Partition. You can check where your DNS Zone is stored in DNS Management UI. As an example, the below screenshot shows the replication scope set as “All domain controllers in this domain (for Windows 2000 compatibility)”<a href="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion5.jpg"><img src="https://msdnshared.blob.core.windows.net/media/2016/08/DNS_Zone_Deletion5-300x91.jpg" alt="DNS_Zone_Deletion5" width="353" height="107" class="alignnone wp-image-3635" /></a></li> </ol> <p><b>PowerShell:</b></p> <ul> <li><b><b><b>Enumerate all DNS Zones not protected from deletion in the Domain partition: <p></b></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;CN=MicrosoftDNS,CN=System,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li><b><b><b>Set the protect from accidental deletion flag: <p></b></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;CN=MicrosoftDNS,CN=System,DC=domain,DC=lab &#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $true</li> <li><strong><b>DNS Zones stored in Domain wide application partitions</b></strong><b><b>:</b></b> <ul> <li><b><b><b>Enumerate all DNS Zones not protected from deletion in the domain application partition: <p></b></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;DC=DomainDnsZones,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li><b><b>Set the protect from accidental deletion flag: <p></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;DC=DomainDnsZones,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $true</li> </ul> </li> <li><strong><b>DNS Zones stored in Forest wide application partitions</b></strong><b><b>:</b></b> <ul> <li><b><b>Enumerate all DNS Zones not protected from deletion in the Forest Wide application partition: <p></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;DC=ForestDnsZones,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li><strong><strong>Set the protect from accidental deletion flag: <p></strong></strong>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;DC=ForestDnsZones,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $true</li> </ul> </li> <li><strong><strong>Check the protect from accidental deletion flag:</strong></strong> <ul> <li><b><b>Forest wide application partition: <p></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;DC=ForestDnsZones,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $True} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li><b><b>Domain wide application partition: <p></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;DC=DomainDnsZones,DC=domain,DC=lab&#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $True} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li><b><b>Domain Partition: <p></b></b>Get-ADObject -Filter &#8216;ObjectClass -like &#8220;dnszone&#8221;&#8216; -SearchScope Subtree -SearchBase &#8220;CN=MicrosoftDNS,CN=System,DC=domain,DC=lab &#8221; -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $True} | Select name,protectedfromaccidentaldeletion | out-gridview</li> </ul> </li> </ul> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/08/11/how-to-prevent-accidental-dns-zone-deletions-in-windows-server/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Announcing: New Transport Advancements in the Anniversary Update for Windows 10 and Windows Server 2016</title> <link>https://blogs.technet.microsoft.com/networking/2016/07/18/announcing-new-transport-advancements-in-the-anniversary-update-for-windows-10-and-windows-server-2016/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/07/18/announcing-new-transport-advancements-in-the-anniversary-update-for-windows-10-and-windows-server-2016/#respond</comments> <pubDate>Mon, 18 Jul 2016 20:16:57 +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=3506</guid> <description><![CDATA[Christian Huitema, Daniel Havey, Matt Olson, Osman Ertugay, Praveen Balasubramanian TCP based communication is used ubiquitously in devices from IoT to cloud servers. Performance improvements in TCP benefit almost every networking workload. The Data Transports and Security (DTS) team in Windows and Devices Group is committed to making Windows TCP best in class. This document... <a aria-label="read more about Announcing: New Transport Advancements in the Anniversary Update for Windows 10 and Windows Server 2016" 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/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p><span style="color: #5a5a5a;font-family: Calibri">Christian Huitema, Daniel Havey, Matt Olson, Osman Ertugay, Praveen Balasubramanian</span></p> <p>TCP based communication is used ubiquitously in devices from IoT to cloud servers. Performance improvements in TCP benefit almost every networking workload. The Data Transports and Security (DTS) team in Windows and Devices Group is committed to making Windows TCP best in class. This document will describe the first wave of features in the pipeline of upcoming Windows Redstone releases.</p> <p>Windows is introducing new TCP features in the Anniversary Update for Windows 10 and Windows Server 2016 releasing summer 2016. In this document we will describe five key features designed to reduce latency, improve loss resiliency and to promote better network citizenship. The goals when starting out were to decrease TCP connection setup time, increase TCP startup speed and to decrease time to recover from packet loss.</p> <p>Here is a summary of the feature list:</p> <ol> <li>TCP Fast Open (TFO) for zero RTT TCP connection setup. IETF RFC 7413 [1]</li> <li>Initial Congestion Window 10 (ICW10) by default for faster TCP slow start [5]</li> <li>TCP Recent ACKnowledgment (RACK) for better loss recovery (experimental IETF draft) [4]</li> <li>Tail Loss Probe (TLP) for better Retransmit TimeOut response (experimental IETF draft) [3]</li> <li>TCP LEDBAT for background connections IETF RFC 6817 [2]</li> </ol> <p>&nbsp;</p> <p><strong>TCP Fast Open:</strong> TCP Fast Open (TFO) accomplishes zero RTT connection setup time by generating a TFO cookie during the first three-way handshake (3WH) connection setup. Subsequent connections to the same server can use the TFO cookie to connect in zero-RTT. TFO connection setup really just means that TCP can carry data in the SYN and SYN-ACK. This data can be consumed by the receiving host during the initial connection handshake. TFO is one full Round Trip Time (RTT) faster than the standard TCP setup which requires a three way-handshake. This leads to latency savings and is very relevant to short web transfers over the Internet where the average latency is on the order of 40 msec.</p> <p>Transport Layer Security (TLS) over TCP using Fast Open is typically two Round Trip Times faster than a standard TLS over TCP connection setup because a client_hello can be included in the SYN packet saving an additional RTT in the TLS handshake. This savings can add up to a substantial increase in resource efficiency while using busy servers that deliver many small Internet objects to the same clients (standard web page, mobile APP data, etc.) TLS 1.3 is an ongoing effort at the IETF and it will help us achieve zero-RTT connection setup for HTTP workloads in a subsequent release.</p> <p>Because we are changing the 3WH behavior of TCP there are several issues that we must address and mitigate. Windows recommends that TLS be used over TCP when employing TCP Fast Open to remove the chance that a man in the middle could manipulate TFO cookies for use in amplified DDOS attacks. TLS connections are immune to attacks from behind Shared Public IPs (NATs), however, it is still possible for a compromised host to flood spoofed SYN packets with valid cookies. To address the problem of compromised hosts Windows TFO sets a dynamically adjusted maximum limit on the number of pending TFO connection requests preventing resource exhaustion attacks from compromised hosts running malicious code. Finally, it is possible for the SYN packet to be duplicated in the network. TLS precludes such duplicate delivery but other services need to ensure that TFO is used for idempotent requests. Windows TFO is safe when used as recommended (with TLS) and can provide a substantial increase in resource efficiency.</p> <p>The Anniversary Update for Windows 10 will ship with a fully compliant client side implementation enabled by default. The Microsoft Edge browser will ship with a About:Flags setting for TCP Fast Open which will be disabled by default. The eventual goal is to have it enabled by default in IE and Edge browsers in a subsequent release. In a subsequent release we plan to support early accept and to fully integrate the server side implementation with http.sys/IIS. The server side implementation will be disabled by default.</p> <p><strong>Configuration: </strong>In the Edge browser, navigate to “about:flags” or “about:config” and use checkbox for “Enable TCP Fast Open”, Netsh int tcp set global fastopen=&lt;enabled | disabled&gt;</p> <p><strong>Action Items: </strong>If you operate infrastructure or own software components like middleboxes or packet processing engines that make use of a TCP state machine, please begin looking into supporting RFC 7413. By next year the combination of TLS 1.3 and TFO is expected to be more widespread.  Read more at: <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/">Building a faster and more secure web with TCP Fast Open, TLS False Start, and TLS 1.3</a></p> <p>&nbsp;</p> <p><strong>Initial Congestion Window (IW10): </strong>The Initial Congestion Window (IW or ICW) default value in Windows 10 and Server 2012 R2 is 4 MSS. With the new releases the default value will be 10 MSS. IW10 default improves slow start speed over the previous default value of IW4. This change in Windows TCP’s startup behavior designed to keep pace with the increased emission rates of network routing equipment used on the Internet today. The ICW determines the limit on how much data can be sent in the first RTT. Like Windows TFO, IW10 mostly affects small object transfers over the Internet. Windows IW10 can transfer small Internet objects up to twice as quickly as ICW4.</p> <p>There are some concerns around burst losses with switches and routers that have shallow buffers. We have telemetered such episodes to help us improve the reliability in subsequent releases. In the next Windows Client release, we plan to flight IW 4, IW 10 and IW 16 to have a better performance comparison across device types.</p> <p><strong>Configuration: </strong>This is currently configured through templates (netsh) or set-nettcpsetting (Powershell). On client SKU the only options to change the IW are to switch to the compat template (IW = 4) or to use the SIO_TCP_SET_ICW option, which also restricts the values in range (2, 4, 10). On server SKU IW can be configured up to a maximum of 64.</p> <p><strong>Action Items: </strong>Please notify us if you see increased loss rates or timeouts with Windows clients and servers.</p> <p>&nbsp;</p> <p><strong>Tail Loss Probe (TLP): </strong>Tail Loss Probe is intended to improve Windows TCP’s behavior when recovering from packet loss. TLP improves TCP recovery behavior by converting Retransmit TimeOuts (RTOs) into Fast Retransmits for much faster recovery.</p> <p>TLP transmits one packet in two round-trips when a connection has outstanding data and is not receiving any ACKs. The transmitted packet (the loss probe), can be either new or a retransmission. When there is tail loss, the ACK from a loss probe triggers SACK/FACK based fast recovery, thus avoiding a costly retransmission timeout (which is bad from the point of view of the long duration as well as the reduction of the congestion window and repeat of slow start).</p> <p>TLP is enabled only for connections that have an RTT of at least 10 msec in both Windows Client and Server 2016. This is to avoid spurious retransmissions for low latency connections. The most beneficial scenario for TLP is short web transfers over WAN.</p> <p><strong>Configuration: </strong>The TCP templates have the additional setting called “taillossprobe”. On client SKU switching to compat template turns TLP off. On both client and server SKUs, the Internet template has it enabled by default. The InternetCustom and DatacenterCustom templates can be used for more fine grained control for specific connections.</p> <p>&nbsp;</p> <p><strong>Recent ACKnowledgement (RACK): </strong>RACK uses the notion of time instead of counting duplicate ACKnowledgements to detect missing packets for TCP Fast Recovery. RACK provides improved loss detection over standard TCP Fast Recovery techniques.</p> <p>RACK is based on the notion of time, instead of traditional approaches for packet loss detection such as packet or sequence number checks. Packets are deemed lost if a packet that was sent &#8220;sufficiently later&#8221; has been cumulatively or selectively acknowledged. The TCP sender records packet transmission times and infers losses using cumulative or selective acknowledgements.</p> <p>RACK is enabled only for connections that have an RTT of at least 10 msec in both Windows Client and Server 2016. This is to avoid spurious retransmissions for low latency connections. RACK is also only enabled for connections that successfully negotiate SACK.</p> <p><strong>Configuration: </strong>The TCP templates have the additional setting called “rack”. On client SKU switching to compat template turns RACK off. On both client and server SKUs, the Internet template has it enabled by default. The InternetCustom and DatacenterCustom templates can be used for more fine grained control for specific connections.</p> <p>&nbsp;</p> <p><strong>Windows Low Extra Delay BAckground Transport (LEDBAT): </strong>The fifth feature is in response to a large number of customer requests for a background transport that does not interfere with other TCP connections. In response to these requests we used Windows TCP modular congestion control structure and added a new Congestion Control Module called LEDBAT in order to manage background flows.</p> <p>Windows LEDBAT is implemented as an experimental Windows TCP Congestion Control Module (CCM). Windows LEDBAT transfers data in the background and does not interfere with other TCP connections. LEDBAT does this by only consuming unused bandwidth. When LEDBAT detects increased latency that indicates other TCP connections are consuming bandwidth it reduces its own consumption to prevent interference. When the latency decreases again LEDBAT ramps up and consumes the unused bandwidth.</p> <p><strong>Configuration: </strong>LEDBAT is only exposed through an undocumented socket option at the moment. Please contact us if you would like to enable experimentation for a background workload.</p> <p>&nbsp;</p> <p><strong>Works Cited:</strong></p> <p>[1] Y. Cheng et al, &#8220;RFC: 7413: TCP Fast Open,&#8221; December 2014. [Online]. Available: https://tools.ietf.org/html/rfc7413</p> <p>[2] S. Shalunov et al, &#8220;RFC 6817 Low Extra Delay Background Transport (LEDBAT),&#8221; December 2012. [Online]. Available: https://tools.ietf.org/html/rfc6817</p> <p>[3] N. Dukkipati et al, &#8220;Tail Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses,&#8221; February 2013. [Online]. Available: https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01</p> <p>[4] Y. Cheng et al, &#8221; RACK: a time-based fast loss detection algorithm for TCP,&#8221; October 2015. [Online]. Available: https://www.ietf.org/archive/id/draft-cheng-tcpm-rack-00.txt</p> <p>[5] J. Chu et al, &#8220;RFC 6928 Increasing TCP&#8217;s Initial Window,&#8221; April 2013. [Online]. Available: https://tools.ietf.org/html/rfc6928</p> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/07/18/announcing-new-transport-advancements-in-the-anniversary-update-for-windows-10-and-windows-server-2016/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Enterprise Gateway Configuration for End-to-End validation of HNV Gateway connectivity</title> <link>https://blogs.technet.microsoft.com/networking/2016/06/07/enterprise-gateway-configuration-for-end-to-end-validation-of-hnv-gateway-connectivity/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/06/07/enterprise-gateway-configuration-for-end-to-end-validation-of-hnv-gateway-connectivity/#respond</comments> <pubDate>Tue, 07 Jun 2016 13:08:23 +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=3415</guid> <description><![CDATA[This post will help you to configure Enterprise or Physical Infrastructure Gateways using Windows RRAS to validate the End-to-E2E data path for Gateway connections with SDN Private Cloud that you have set up using the instruction from these deployment guides. To understand the deployment topology for various types of Gateways, we need to first understand... <a aria-label="read more about Enterprise Gateway Configuration for End-to-End validation of HNV Gateway connectivity" href="https://blogs.technet.microsoft.com/networking/2016/06/07/enterprise-gateway-configuration-for-end-to-end-validation-of-hnv-gateway-connectivity/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[<p><span style="color: #000000;font-family: Calibri">This post will help you to configure Enterprise or Physical Infrastructure Gateways using Windows RRAS to validate the End-to-E2E data path for Gateway connections with SDN Private Cloud that you have set up using the instruction from these <a href="https://technet.microsoft.com/en-us/library/mt710657.aspx">deployment guides</a>. </span></p> <p><span style="color: #000000;font-family: Calibri">To understand the deployment topology for various types of Gateways, we need to first understand the corresponding scenarios that these gateways are used in. This will help clarify the placement and configuration of Enterprise or Physical Infrastructure Gateways for their corresponding HNV Gateways.</span></p> <h2><span style="color: #1f4d78;font-family: Calibri Light;font-size: medium">Types of Gateways and their corresponding deployment scenarios</span></h2> <p><span style="color: #000000;font-family: Calibri">There are three types of Gateways available via Windows SDN solution for connectivity with non-SDN infrastructure. This infrastructure could be Enterprise on-premises connected over public internet, or dedicated leased line, or a physical infrastructure. </span></p> <h3><span style="color: #1f4d78;font-family: Calibri Light;font-size: medium">IPsec Gateways</span></h3> <p><span style="color: #000000;font-family: Calibri">IPsec Gateways are used for connecting Virtual Networks with other virtualized or physical networks (usually Enterprise on-premises networks) over the public internet. The Enterprise gateway and the HNV Gateway establish the secure IPSec connection over public Internet IP Addresses to exchange data between the two networks. </span></p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/06/IPSec.jpg"><img class=" wp-image-3435 size-mediumlarge aligncenter" src="https://msdnshared.blob.core.windows.net/media/2016/06/IPSec-500x264.jpg" alt="IPSec" width="500" height="264" /></a></p> <h3><span style="color: #1f4d78;font-family: Calibri Light;font-size: medium">GRE Gateway</span></h3> <p><span style="color: #000000;font-family: Calibri">GRE Gateways are used for connecting Virtual Networks with other physical networks over dedicated connectivity. The Physical Network gateway (GRE Terminating device) and the HNV Gateway establish the connection identified by the unique GRE Key to exchange data between the two networks.</span></p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/06/GRE.jpg"><img class=" wp-image-3426 size-mediumlarge aligncenter" src="https://msdnshared.blob.core.windows.net/media/2016/06/GRE-500x269.jpg" alt="GRE" width="500" height="269" /></a></p> <p>&nbsp;</p> <h3><span style="color: #1f4d78;font-family: Calibri Light;font-size: medium">Layer 3 Forwarding Gateways</span></h3> <p><span style="color: #000000;font-family: Calibri">Layer 3 Forwarding Gateways are used for connecting Virtual Networks with other physical networks (usually shared resources inside the hoster premises) over VLAN isolated network. The Physical Network gateway (a Layer 3 router) and the HNV Gateway establish the connection over this Network isolated by unique VLAN ID to exchange data between the two networks.</span></p> <p><a href="https://msdnshared.blob.core.windows.net/media/2016/06/L3-Fwd-GW.jpg"><img class=" wp-image-3445 size-mediumlarge aligncenter" src="https://msdnshared.blob.core.windows.net/media/2016/06/L3-Fwd-GW-500x265.jpg" alt="L3-Fwd-GW" width="500" height="265" /></a></p> <p>&nbsp;</p> <h2><span style="color: #2e74b5;font-family: Calibri Light;font-size: large">Setting up an Enterprise / Physical Network Gateway</span></h2> <p><span style="color: #000000;font-family: Calibri">To set up or simulate a non-SDN gateway, you will need to deploy a Windows Server Host or Virtual Machine and make sure it has at least 2 Network Adapters. One of these adapters must be available to connect with the HNV Gateways as shown in the diagrams above, and the other Adapter shall be used for connecting with Client Computers inside the non-SDN network.</span></p> <p><span style="color: #000000;font-family: Calibri">Once the Gateway Hosts or VMs are installed, and started, go to the Gateway and configure as per the required scenario by following the instructions below: </span></p> <h3><span style="color: #1f4d78;font-family: Calibri Light;font-size: medium">Install Remote Access Service</span></h3> <h4><em><span style="color: #2e74b5;font-family: Calibri Light">Via PowerShell cmdlets</span></em></h4> <table style="height: 243px" width="641"> <tbody> <tr> <td width="623"> <pre><span style="color: #008000;font-family: Calibri"><span style="font-family: Calibri"># Add RemoteAccess Feature </span></span><span style="color: #000000;font-family: Calibri"><span style="color: #000000;font-family: Calibri"><span style="color: #0000ff">Add-WindowsFeature</span> <span style="color: #000080">-Name</span> <span style="color: #d64ed9">RemoteAccess</span><span style="color: #000080"> -IncludeAllSubFeature -IncludeManagementTools</span> </span></span><span style="color: #000000;font-family: Calibri"><span style="color: #000000;font-family: Calibri"><span style="color: #0000ff">Import-Module</span> <span style="color: #d64ed9">RemoteAccess </span></span></span><span style="color: #008000;font-family: Calibri"><span style="font-family: Calibri"># Install RemoteAccess in VpnS2S Mode </span></span><span style="color: #000000;font-family: Calibri"><span style="color: #000000;font-family: Calibri"><span style="color: #0000ff">Install-RemoteAccess </span> <span style="color: #000080">-VpnType</span> <span style="color: #d64ed9">VpnS2S</span> </span></span><span style="color: #008000;font-family: Calibri"><span style="font-family: Calibri"># Check the service installation status </span></span><span style="color: #000000;font-family: Calibri"><span style="color: #000000;font-family: Calibri"><span style="color: #0000ff">Get-Service</span> <span style="color: #d64ed9">RemoteAccess</span></span></span></pre> </td> </tr> </tbody> </table> <h4><em><span style="color: #2e74b5;font-family: Calibri Light">Via Server Manager UI</span></em></h4> <ul> <li><span style="color: #000000;font-family: Calibri">Open<strong> Service Manager</strong> UI </span></li> <li><span style="color: #000000;font-family: Calibri">On the Dashboard screen, click on <strong>Add roles and features</strong> under <strong>Configure this local server</strong> </span></li> <li><span style="color: #000000;font-family: Calibri">Click <strong>Next</strong> on the <strong>Before You Begin</strong> screen </span></li> <li><span style="color: #000000;font-family: Calibri">Select <strong>Installation type</strong> as <strong>Role-based or feature-based installation</strong> option and click <strong>Next</strong> </span></li> <li><span style="color: #000000;font-family: Calibri">Select the default option (local server) on <strong>Server Selection</strong> screen and click <strong>Next</strong> </span></li> <li><span style="color: #000000;font-family: Calibri">Select <strong>Remote Access</strong> under <strong>Server Roles</strong> and click <strong>Next</strong> </span></li> <li><span style="color: #000000;font-family: Calibri">Click <strong>Next</strong> on <strong>Features screen</strong> </span></li> <li><span style="color: #000000;font-family: Calibri">On <strong>Remote Access</strong> Welcome screen, click <strong>Next</strong> </span></li> <li><span style="color: #000000;font-family: Calibri">Select <strong>DirectAccess and VPN (RAS)</strong> and <strong>Routing</strong> under <strong>Role Services</strong> screen and click on <strong>Add Features </strong>for any dependencies in the pop-up window. Click <strong>Next. </strong></span></li> <li><span style="color: #000000;font-family: Calibri">Click <strong><strong>Next</strong> </strong>on<strong> <strong>Web Server Role (IIS) </strong></strong></span></li> <li><span style="color: #000000;font-family: Calibri">Under<strong><strong> <strong>WebServer</strong> <strong>Role services</strong></strong></strong>, click <strong><strong><strong>Next</strong> </strong></strong>with default selections </span></li> <li><span style="color: #000000;font-family: Calibri">Review the configuration and click on <strong>Install</strong> to install Remote Access Close the windows when Installation finishes.</span></li> </ul> <h3><span style="color: #1f4d78;font-family: Calibri Light;font-size: medium">Setting up an IPsec Network Connection</span></h3> <table style="height: 235px" width="943"> <tbody> <tr> <td width="623"> <pre><span style="color: #000000;font-family: Calibri"><span style="color: #008000"># Add VPN S2S Interfaces</span> </span><span style="color: #000000;font-family: Calibri"><span style="color: #000080">Add-VpnS2SInterface -Name</span> <span style="color: #800000">"ToCloud"</span> <span style="color: #000080">-Protocol</span> <span style="color: #d64ed9">IKEv2</span> <span style="color: #000080">-Destination</span> <span style="color: #800000">"&lt;Cloud GW's Public IPv4 Address&gt;"</span> <span style="color: #000080">-AuthenticationMethod</span> <span style="color: #d64ed9">PSKOnly </span> <span style="color: #000080">-SharedSecret</span><span style="color: #800000"> "P@ssw0rd"</span> <span style="color: #000080">-Persistent -IPv4Subnet</span> <span style="color: #800000">"&lt;Cloud Network&gt;/&lt;Prefix Length&gt;:&lt;Metric&gt;"</span> <span style="color: #000080">-AuthenticationTransformConstants </span><span style="color: #d64ed9"> SHA196</span> <span style="color: #000080">–CipherTransformConstants</span> <span style="color: #d64ed9">AES256</span><span style="color: #000080"> –DHGroup</span> <span style="color: #d64ed9">Group2</span> <span style="color: #000080">–EncryptionMethod</span> <span style="color: #d64ed9">AES256</span> <span style="color: #000080">–IntegrityCheckMethod</span> <span style="color: #d64ed9">SHA1</span> <span style="color: #000080">–PfsGroup </span> <span style="color: #d64ed9">PFS2048</span> <span style="color: #000080">–EnableQoS</span> <span style="color: #d64ed9">Enabled</span> <span style="color: #000080">-NumberOfTries</span> <span style="color: #d64ed9">0 </span></span><span style="color: #008000;font-family: Calibri"># Connect VPN S2S Interfaces with HNV Gateway </span><span style="color: #000000;font-family: Calibri"><span style="color: #0000ff">Connect-VpnS2SInterface</span><span style="color: #000080"> -Name</span> <span style="color: #800000">"ToCloud"</span><span style="color: #000080"> -PassThru</span></span></pre> </td> </tr> </tbody> </table> <p><em><span style="color: #000000;font-family: Calibri"><strong><span style="text-decoration: underline">Note:</span></strong> You can also configure an IPsec network connection (called the Demand-Dial connection) from <strong>Routing and Remote Access UI</strong> by following the <strong>Routing and Remote Access Server Setup Wizard.</strong></span></em></p> <h3><span style="color: #1f4d78;font-family: Calibri Light;font-size: medium">Setting up an GRE Network Connection</span></h3> <table style="height: 187px" width="945"> <tbody> <tr> <td width="623"> <pre><span style="color: #008000;font-family: Calibri"># Add VPN S2S Interfaces</span> <span style="color: #008000;font-family: Calibri"><span style="color: #0000ff">Add-VpnS2SInterface</span> <span style="color: #000080">-GreTunnel -Name</span> <span style="color: #800000">"ToCloud"</span> <span style="color: #000080">-GreKey</span> <span style="color: #d64ed9">1234</span> <span style="color: #000080">-Destination</span> <span style="color: #800000">"&lt;Cloud GW's Public IPv4 Address&gt;" </span> <span style="color: #000080">-IPv4Subnet</span> <span style="color: #800000">"&lt;Cloud Network&gt;/&lt;Prefix Length&gt;:100"</span> <span style="color: #000080">-SourceIPAddress</span> <span style="color: #800000">"&lt;Gateways Internet IP Address&gt;"</span> </span><span style="color: #008000;font-family: Calibri"># Connect VPN S2S Interfaces with HNV Gateway </span><span style="color: #008000;font-family: Calibri"><span style="color: #0000ff">Set-VpnS2SInterface</span> <span style="color: #000080">-Name</span> <span style="color: #800000">"ToCloud"</span> <span style="color: #000080">-GreTunnel -AdminStatus</span>:<span style="color: #ff0000">$true</span></span></pre> </td> </tr> </tbody> </table> <h3><span style="color: #1f4d78;font-family: Calibri Light;font-size: medium">Setting up a Layer 3 Forwarding Gateway</span></h3> <table style="height: 283px" width="952"> <tbody> <tr> <td width="623"> <pre><span style="color: #008000;font-family: Calibri"># Enable Forwarding on all Network Adapters </span><span style="color: #008000;font-family: Calibri"><span style="color: #ff0000">$netAdapters</span> <span style="color: #000000">= @(</span><span style="color: #0000ff">Get-NetAdapter</span><span style="color: #000000">) </span></span><span style="color: #008000;font-family: Calibri"><span style="color: #0000ff">Set-NetIPInterface</span><span style="color: #000080"> -InterfaceIndex</span> <span style="color: #ff0000">$netAdapter</span><span style="color: #000000">.IfIndex</span> <span style="color: #000080">-Forwarding</span> <span style="color: #d64ed9">Enabled</span> </span><span style="color: #008000;font-family: Calibri"># Plumb the routes to Virtual Network Subnets on the DMZ / External Interface </span><span style="color: #008000;font-family: Calibri"><span style="color: #ff0000">$IPv4subnets</span> <span style="color: #000000">= </span><span style="color: #800000"><span style="color: #000000">@(</span>"&lt;Vnet Subnet 1&gt;"<span style="color: #000000">,</span> "&lt;Vnet Subnet 2&gt;"<span style="color: #000000">)</span></span> </span><span style="color: #008000;font-family: Calibri"><span style="color: #000080">foreach</span> <span style="color: #000000">(</span><span style="color: #ff0000">$subnet</span> <span style="color: #0000ff">in</span> <span style="color: #ff0000">$IPv4Subnets</span><span style="color: #000000">) </span></span><span style="color: #000000;font-family: Calibri">{ </span><span style="color: #008000;font-family: Calibri">    <span style="color: #0000ff"> New-NetRoute</span> <span style="color: #000080">-InterfaceAlias</span> <span style="color: #800000">“&lt;Network Adapter connected to VLAN Network&gt;”</span> <span style="color: #000080">-DestinationPrefix</span> <span style="color: #ff0000">$subnet </span> <span style="color: #000080">-NextHop</span> <span style="color: #800000">“&lt;HNV Gateway’s L3 Forwarding IP Address&gt;”</span> <span style="color: #000080">-Confirm:</span><span style="color: #ff0000">$false</span><span style="color: #000080"> -ErrorAction</span> <span style="color: #d64ed9">Ignore </span></span><span style="color: #000000;font-family: Calibri"> }</span></pre> </td> </tr> </tbody> </table> <h3><span style="color: #1f4d78;font-family: Calibri Light;font-size: medium">Setting up a BGP Router</span></h3> <table style="height: 204px" width="957"> <tbody> <tr> <td width="623"> <pre><span style="color: #008000;font-family: Calibri"># Add BGP Routers </span><span style="color: #008000;font-family: Calibri"><span style="color: #0000ff">Add-BgpRouter</span> <span style="color: #000080">-BgpIdentifier</span><span style="color: #800000"> "&lt;Local Gateway's Enterprise IP Address&gt;"</span> <span style="color: #000080">-LocalASN</span> <span style="color: #d64ed9">64522</span><span style="color: #000080"> –PassThru </span></span><span style="color: #008000;font-family: Calibri"># Add BGP Peers </span><span style="color: #008000;font-family: Calibri"><span style="color: #0000ff">Add-BgpPeer</span> <span style="color: #000080">-Name</span> <span style="color: #d64ed9">CloudPeer</span><span style="color: #000080"> -LocalIPAddress</span> <span style="color: #800000">"&lt;Local Gateway's Enterprise IP Address&gt;"</span> <span style="color: #000080">-PeerIPAddress</span> <span style="color: #800000">"&lt;Cloud Gateway's VSID IP Address&gt;" </span> <span style="color: #000080">-PeerASN</span> <span style="color: #d64ed9">64512</span> <span style="color: #000080">–PassThru</span> </span><span style="color: #008000;font-family: Calibri"># Connect BGP Peers and check if the routes are exchanged and Hosted networks are accessible </span><span style="color: #008000;font-family: Calibri"><span style="color: #0000ff">Start-BgpPeer</span> <span style="color: #000080">-Name</span> <span style="color: #d64ed9">CloudPeer</span> </span><span style="color: #008000;font-family: Calibri"><span style="color: #0000ff">Get-BgpPeer</span> <span style="color: #000080">-Name</span> <span style="color: #d64ed9">CloudPeer </span></span><span style="color: #008000;font-family: Calibri"># Retrieve BGP Learned Routes </span><span style="color: #0000ff;font-family: Calibri">Get-BgpRouteInformation</span></pre> </td> </tr> </tbody> </table> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> <p>&nbsp;</p> ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/06/07/enterprise-gateway-configuration-for-end-to-end-validation-of-hnv-gateway-connectivity/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> </channel> </rss>