Mobilize your workloads with software-defined networking

Improve your agility, strengthen your security stance, and present flexible solutions that can change as requirements evolve. It’s the network innovation your IT team needs to deliver the right infrastructure at the right time.

Watch the software-defined networking video

Achieve rapid network scale

Move your network control layer from hardware to software. Deploy complex workloads in a matter of seconds using a scalable network controller, and automatically load balance and shift workloads.

Watch the demo

Enhance network security

Dynamically segment your network based on workloads by using a distributed firewall and network security groups to apply rich policies within, and across, segments. Plus, layer enforcement by routing traffic to virtualized firewall appliances for even greater levels of security.

Read how networking helps solve four datacenter challenges

Gain workload mobility

Take control of your hybrid workloads, including running them in containers, and move them across servers, racks, and clouds using standards-based overlay networks and multitenanted hybrid gateways.

Learn more about networking

VIDEO

Explore the software-defined datacenter

Learn how to improve datacenter efficiency with a look at the Windows Server 2016 software-defined datacenter.

NETWORKING BLOG

Visit the blog

<?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>Fri, 25 Nov 2016 11:55:26 +0000</lastBuildDate> <language>en-US</language> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <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 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[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. This issue has been difficult to diagnose as the current logs did not provide adequate visibility into the reasons for the failures. <h5>Scenario:</h5> 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. <h6>Symptoms:</h6> <ul> <li>Devices after a renewal from Microsoft DHCP Server, fail to update their records in DNS</li> </ul> For context, the following is how DHCP server-DNS client interaction works: 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”. 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. 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. To alleviate this problem, the below was done: <h4>On Windows Server 2016: </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. New Events in Windows Server 2016:</li> </ol> <table width="611" border="1" cellspacing="0" cellpadding="0"> <tbody> <tr> <td width="112" valign="top">Event Category</td> <td width="512" valign="top">Event Text</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> 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. 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. <h4>On Windows Server 2012 R2: </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 & no additional events have been added.</li> </ul> How to get this change on Windows Server 2012 R2? The change (not enabled by default) is part of the following Monthly Quality Rollup for Windows Server 2012 R2: <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> Important: 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: Disclaimer: It is always a good idea to take a backup of the registry key before making any changes so please do that! <ol> <li>Create a new key called “DnsRegistrationMaxRetries” of type DWORD under HKLM\System\CurrentControlSet\Services\DhcpServer\Parameters</li> <li>Set the value of “DnsRegistrationMaxRetries” to 0</li> <li>Reboot the DHCP Server</li> </ol> Note: If you already have <a href="https://support.microsoft.com/en-us/kb/3197875">KB3197875</a> installed, the “DnsRegistrationMaxRetries” may exist with value 3. You need to change the value to 0 and reboot the DHCP Server. Until next time! Ajay Sarkaria Microsoft     ]]></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 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[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 (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). Note: This will be a technical post focusing on networking protocols and some implementation details <h1>Virtual Networking</h1> 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? Because just as compute and storage have been virtualized, traditional networking devices and services are also being virtualized for greater flexibility. 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 virtual networks. 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. 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 encapsulated within physical network IP packets to create an overlay 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. <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> Figure 1 – VXLAN Encapsulation 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 static configurations 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. <h1>Hyper-V Network Virtualization (HNV)</h1> The network virtualization solution in Windows Server 2012 and 2012R2 – Hyper-V Network Virtualization (HNV) – used an encapsulation format known as NVGRE (<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 VXLAN (<a href="https://tools.ietf.org/html/rfc7348">RFC 7348</a>) including guidance on how to distribute or exchange VXLAN Tunnel Endpoint (VTEP) information between virtual and physical devices – e.g. Hardware VTEPs. 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. 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. 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 Routing Domain 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. As network equipment manufacturers build support for VXLAN into their NIC cards, switches, and routers, they can support: <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> 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. <h1>VXLAN Implementation in Windows Server 2016</h1> 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. The VXLAN RFC talks about different approaches for distributing the VTEP IP to VM MAC mapping information: <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> 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. 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. <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> Figure 2 – Network Controller – Host Agent Communication <h1>Looking Ahead</h1> 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. 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. <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>   <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> <a href="https://technet.microsoft.com/en-us/library/mt703757.aspx">Manage Tenant Virtual Networks</a></li> </ul> <h3>Deployment Scripts</h3> <ul> <li> <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’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 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[Daniel Havey, Praveen Balasubramanian 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 definitely limit your Internet speeds. Auto-tuning is consistent throughout all variants of TCP and present in all modern operating systems. 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 normal in order to restore your Internet speeds using the following commands in an elevated command prompt: <blockquote> <pre>PS C:\WINDOWS\system32> netsh int tcp set global autotuninglevel=normal Ok. PS C:\WINDOWS\system32> 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 Receive Window Auto-Tuning Level : normal 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> Some of the confusion may have originated from a misinterpretation of a blog post which suggests disabling heuristics with the following command: <blockquote> <pre>netsh interface tcp set heuristics disabled</pre> </blockquote> 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. ]]></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 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[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 Hildebrand & Eric Jansen Note: 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. Example screenshot if trying to delete from Active Directory Users and Computers: <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> “You do not have sufficient permissions to delete DNZ_Zone_Name, or this object is protected from accidental deletion” OR Example screenshot if trying to delete from the DNS Manager: <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> The zone cannot be deleted. Access was denied If you try to change the scope of replication with the protection enabled, you will see a message similar to the below: <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> The replication scope could not be set. For more information, see “DNS zone replication in Active Directory” in Help and Support. The error was: Access was denied.   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. Important: As with any changes, you should always exercise caution and test things out in a lab BEFORE implementing any changes to your production environment. 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 DNS Zones stored in the Domain Partition: Doing it from the Active Directory Users & Computers MMC: <ol> <li>Check the flag of “Protect object from accidental deletion” 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>Note: 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> PowerShell: <ul> <li>Enumerate all DNS Zones not protected from deletion in the Domain partition: Get-ADObject -Filter ‘ObjectClass -like “dnszone”‘ -SearchScope Subtree -SearchBase “CN=MicrosoftDNS,CN=System,DC=domain,DC=lab” -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li>Set the protect from accidental deletion flag: Get-ADObject -Filter ‘ObjectClass -like “dnszone”‘ -SearchScope Subtree -SearchBase “CN=MicrosoftDNS,CN=System,DC=domain,DC=lab ” -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $true</li> <li>DNS Zones stored in Domain wide application partitions: <ul> <li>Enumerate all DNS Zones not protected from deletion in the domain application partition: Get-ADObject -Filter ‘ObjectClass -like “dnszone”‘ -SearchScope Subtree -SearchBase “DC=DomainDnsZones,DC=domain,DC=lab” -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li>Set the protect from accidental deletion flag: Get-ADObject -Filter ‘ObjectClass -like “dnszone”‘ -SearchScope Subtree -SearchBase “DC=DomainDnsZones,DC=domain,DC=lab” -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $true</li> </ul> </li> <li>DNS Zones stored in Forest wide application partitions: <ul> <li>Enumerate all DNS Zones not protected from deletion in the Forest Wide application partition: Get-ADObject -Filter ‘ObjectClass -like “dnszone”‘ -SearchScope Subtree -SearchBase “DC=ForestDnsZones,DC=domain,DC=lab” -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li>Set the protect from accidental deletion flag: Get-ADObject -Filter ‘ObjectClass -like “dnszone”‘ -SearchScope Subtree -SearchBase “DC=ForestDnsZones,DC=domain,DC=lab” -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $False} | Set-ADObject –ProtectedFromAccidentalDeletion $true</li> </ul> </li> <li>Check the protect from accidental deletion flag: <ul> <li>Forest wide application partition: Get-ADObject -Filter ‘ObjectClass -like “dnszone”‘ -SearchScope Subtree -SearchBase “DC=ForestDnsZones,DC=domain,DC=lab” -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $True} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li>Domain wide application partition: Get-ADObject -Filter ‘ObjectClass -like “dnszone”‘ -SearchScope Subtree -SearchBase “DC=DomainDnsZones,DC=domain,DC=lab” -properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $True} | Select name,protectedfromaccidentaldeletion | out-gridview</li> <li>Domain Partition: Get-ADObject -Filter ‘ObjectClass -like “dnszone”‘ -SearchScope Subtree -SearchBase “CN=MicrosoftDNS,CN=System,DC=domain,DC=lab ” -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 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[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 will describe the first wave of features in the pipeline of upcoming Windows Redstone releases. 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. Here is a summary of the feature list: <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>   TCP Fast Open: 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. 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. 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. 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. Configuration: 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=<enabled | disabled> Action Items: 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>   Initial Congestion Window (IW10): 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. 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. Configuration: 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. Action Items: Please notify us if you see increased loss rates or timeouts with Windows clients and servers.   Tail Loss Probe (TLP): 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. 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). 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. Configuration: 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.   Recent ACKnowledgement (RACK): 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. 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 “sufficiently later” has been cumulatively or selectively acknowledged. The TCP sender records packet transmission times and infers losses using cumulative or selective acknowledgements. 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. Configuration: 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.   Windows Low Extra Delay BAckground Transport (LEDBAT): 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. 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. Configuration: 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.   Works Cited: [1] Y. Cheng et al, “RFC: 7413: TCP Fast Open,” December 2014. [Online]. Available: https://tools.ietf.org/html/rfc7413 [2] S. Shalunov et al, “RFC 6817 Low Extra Delay Background Transport (LEDBAT),” December 2012. [Online]. Available: https://tools.ietf.org/html/rfc6817 [3] N. Dukkipati et al, “Tail Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses,” February 2013. [Online]. Available: https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 [4] Y. Cheng et al, ” RACK: a time-based fast loss detection algorithm for TCP,” October 2015. [Online]. Available: https://www.ietf.org/archive/id/draft-cheng-tcpm-rack-00.txt [5] J. Chu et al, “RFC 6928 Increasing TCP’s Initial Window,” April 2013. [Online]. Available: https://tools.ietf.org/html/rfc6928 ]]></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 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[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>. 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. <h2>Types of Gateways and their corresponding deployment scenarios</h2> 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. <h3>IPsec Gateways</h3> 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. <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> <h3>GRE Gateway</h3> 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. <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>   <h3>Layer 3 Forwarding Gateways</h3> 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. <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>   <h2>Setting up an Enterprise / Physical Network Gateway</h2> 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. 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: <h3>Install Remote Access Service</h3> <h4>Via PowerShell cmdlets</h4> <table style="height: 243px" width="641"> <tbody> <tr> <td width="623"> <pre># Add RemoteAccess Feature Add-WindowsFeature -Name RemoteAccess -IncludeAllSubFeature -IncludeManagementTools Import-Module RemoteAccess # Install RemoteAccess in VpnS2S Mode Install-RemoteAccess -VpnType VpnS2S # Check the service installation status Get-Service RemoteAccess</pre> </td> </tr> </tbody> </table> <h4>Via Server Manager UI</h4> <ul> <li>Open Service Manager UI </li> <li>On the Dashboard screen, click on Add roles and features under Configure this local server </li> <li>Click Next on the Before You Begin screen </li> <li>Select Installation type as Role-based or feature-based installation option and click Next </li> <li>Select the default option (local server) on Server Selection screen and click Next </li> <li>Select Remote Access under Server Roles and click Next </li> <li>Click Next on Features screen </li> <li>On Remote Access Welcome screen, click Next </li> <li>Select DirectAccess and VPN (RAS) and Routing under Role Services screen and click on Add Features for any dependencies in the pop-up window. Click Next. </li> <li>Click Next on Web Server Role (IIS) </li> <li>Under WebServer Role services, click Next with default selections </li> <li>Review the configuration and click on Install to install Remote Access Close the windows when Installation finishes.</li> </ul> <h3>Setting up an IPsec Network Connection</h3> <table style="height: 235px" width="943"> <tbody> <tr> <td width="623"> <pre># Add VPN S2S Interfaces Add-VpnS2SInterface -Name "ToCloud" -Protocol IKEv2 -Destination "<Cloud GW's Public IPv4 Address>" -AuthenticationMethod PSKOnly -SharedSecret "P@ssw0rd" -Persistent -IPv4Subnet "<Cloud Network>/<Prefix Length>:<Metric>" -AuthenticationTransformConstants SHA196 –CipherTransformConstants AES256 –DHGroup Group2 –EncryptionMethod AES256 –IntegrityCheckMethod SHA1 –PfsGroup PFS2048 –EnableQoS Enabled -NumberOfTries 0 # Connect VPN S2S Interfaces with HNV Gateway Connect-VpnS2SInterface -Name "ToCloud" -PassThru</pre> </td> </tr> </tbody> </table> Note: You can also configure an IPsec network connection (called the Demand-Dial connection) from Routing and Remote Access UI by following the Routing and Remote Access Server Setup Wizard. <h3>Setting up an GRE Network Connection</h3> <table style="height: 187px" width="945"> <tbody> <tr> <td width="623"> <pre># Add VPN S2S Interfaces Add-VpnS2SInterface -GreTunnel -Name "ToCloud" -GreKey 1234 -Destination "<Cloud GW's Public IPv4 Address>" -IPv4Subnet "<Cloud Network>/<Prefix Length>:100" -SourceIPAddress "<Gateways Internet IP Address>" # Connect VPN S2S Interfaces with HNV Gateway Set-VpnS2SInterface -Name "ToCloud" -GreTunnel -AdminStatus:$true</pre> </td> </tr> </tbody> </table> <h3>Setting up a Layer 3 Forwarding Gateway</h3> <table style="height: 283px" width="952"> <tbody> <tr> <td width="623"> <pre># Enable Forwarding on all Network Adapters $netAdapters = @(Get-NetAdapter) Set-NetIPInterface -InterfaceIndex $netAdapter.IfIndex -Forwarding Enabled # Plumb the routes to Virtual Network Subnets on the DMZ / External Interface $IPv4subnets = @("<Vnet Subnet 1>", "<Vnet Subnet 2>") foreach ($subnet in $IPv4Subnets) { New-NetRoute -InterfaceAlias “<Network Adapter connected to VLAN Network>” -DestinationPrefix $subnet -NextHop “<HNV Gateway’s L3 Forwarding IP Address>” -Confirm:$false -ErrorAction Ignore }</pre> </td> </tr> </tbody> </table> <h3>Setting up a BGP Router</h3> <table style="height: 204px" width="957"> <tbody> <tr> <td width="623"> <pre># Add BGP Routers Add-BgpRouter -BgpIdentifier "<Local Gateway's Enterprise IP Address>" -LocalASN 64522 –PassThru # Add BGP Peers Add-BgpPeer -Name CloudPeer -LocalIPAddress "<Local Gateway's Enterprise IP Address>" -PeerIPAddress "<Cloud Gateway's VSID IP Address>" -PeerASN 64512 –PassThru # Connect BGP Peers and check if the routes are exchanged and Hosted networks are accessible Start-BgpPeer -Name CloudPeer Get-BgpPeer -Name CloudPeer # Retrieve BGP Learned Routes Get-BgpRouteInformation</pre> </td> </tr> </tbody> </table>         ]]></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> <item> <title>CROSS POST: Fix: Loading DNS zones takes a long time on a Windows Server 2008 R2-based DNS server</title> <link>https://blogs.technet.microsoft.com/networking/2016/04/25/cross-post-fix-loading-dns-zones-takes-a-long-time-on-a-windows-server-2008-r2-based-dns-server/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/04/25/cross-post-fix-loading-dns-zones-takes-a-long-time-on-a-windows-server-2008-r2-based-dns-server/#respond</comments> <pubDate>Mon, 25 Apr 2016 12:25:19 +0000</pubDate> <dc:creator><![CDATA[Kaushik Ainapure [MSFT]]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3385</guid> <description><![CDATA[Here’s another blog by Ajay Sarkaria that we felt needed to also be on the Networking site due to the nature and the popularity of the article. So we are going to cross post it here. Fix: Loading DNS zones takes a long time on a Windows Server 2008 R2-based DNS serverhttp://blogs.technet.com/b/supportingwindows/archive/2016/04/25/fix-loading-dns-zones-takes-a-long-time-on-a-windows-server-2008-r2-based-dns-server.aspx Please keep in... <a href="https://blogs.technet.microsoft.com/networking/2016/04/25/cross-post-fix-loading-dns-zones-takes-a-long-time-on-a-windows-server-2008-r2-based-dns-server/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[Here’s another blog by Ajay Sarkaria that we felt needed to also be on the Networking site due to the nature and the popularity of the article. So we are going to cross post it here. Fix: Loading DNS zones takes a long time on a Windows Server 2008 R2-based DNS server <a title="http://blogs.technet.com/b/supportingwindows/archive/2016/04/25/fix-loading-dns-zones-takes-a-long-time-on-a-windows-server-2008-r2-based-dns-server.aspx" href="http://blogs.technet.com/b/supportingwindows/archive/2016/04/25/fix-loading-dns-zones-takes-a-long-time-on-a-windows-server-2008-r2-based-dns-server.aspx">http://blogs.technet.com/b/supportingwindows/archive/2016/04/25/fix-loading-dns-zones-takes-a-long-time-on-a-windows-server-2008-r2-based-dns-server.aspx</a> Please keep in mind that the latest changes/updates will be in the original blog post. Thanks, Kaushik Ainapure ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/04/25/cross-post-fix-loading-dns-zones-takes-a-long-time-on-a-windows-server-2008-r2-based-dns-server/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>CROSS POST: LBFO Dynamic Teaming mode may drop send packets in Windows Server 2012 R2</title> <link>https://blogs.technet.microsoft.com/networking/2016/03/04/cross-post-lbfo-dynamic-teaming-mode-may-drop-send-packets-in-windows-server-2012-r2/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/03/04/cross-post-lbfo-dynamic-teaming-mode-may-drop-send-packets-in-windows-server-2012-r2/#respond</comments> <pubDate>Fri, 04 Mar 2016 01:37:00 +0000</pubDate> <dc:creator><![CDATA[Kaushik Ainapure [MSFT]]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/?p=3382</guid> <description><![CDATA[Here’s a blog done by Ajay Sarkaria that we felt needed to also be on the Networking site due to the nature and the popularity of the article. So we are going to cross post it here. LBFO Dynamic Teaming mode may drop send packets in Windows Server 2012 R2 http://blogs.technet.com/b/supportingwindows/archive/2016/03/04/lbfo-dynamic-teaming-mode-may-drop-send-packets-in-windows-server-2012-r2.aspx Please keep in mind... <a href="https://blogs.technet.microsoft.com/networking/2016/03/04/cross-post-lbfo-dynamic-teaming-mode-may-drop-send-packets-in-windows-server-2012-r2/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[Here’s a blog done by Ajay Sarkaria that we felt needed to also be on the Networking site due to the nature and the popularity of the article. So we are going to cross post it here. LBFO Dynamic Teaming mode may drop send packets in Windows Server 2012 R2 <a href="http://blogs.technet.com/b/supportingwindows/archive/2016/03/04/lbfo-dynamic-teaming-mode-may-drop-send-packets-in-windows-server-2012-r2.aspx" target="_blank">http://blogs.technet.com/b/supportingwindows/archive/2016/03/04/lbfo-dynamic-teaming-mode-may-drop-send-packets-in-windows-server-2012-r2.aspx</a> Please keep in mind that the latest changes/updates will be in the original blog post. Thanks, Kaushik Ainapure ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/03/04/cross-post-lbfo-dynamic-teaming-mode-may-drop-send-packets-in-windows-server-2012-r2/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item> <title>Backup and Restore DHCP with Failover Configuration</title> <link>https://blogs.technet.microsoft.com/networking/2016/01/07/backup-and-restore-dhcp-with-failover-configuration/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/01/07/backup-and-restore-dhcp-with-failover-configuration/#comments</comments> <pubDate>Thu, 07 Jan 2016 04:59:15 +0000</pubDate> <dc:creator><![CDATA[Kaushik Ainapure [MSFT]]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[Backup and Restore]]></category> <category><![CDATA[DHCP]]></category> <category><![CDATA[Failover]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/2016/01/07/backup-and-restore-dhcp-with-failover-configuration/</guid> <description><![CDATA[[This post comes to us courtesy of Vithalprasad Gaitonde from Product Group and Gopalakrishnan Krishnan from Global Windows Networking Support] The DHCP service has evolved with its own in-built failover capability starting Windows Server 2012. With this coming into the picture, how can one go about backing up the DHCP server service with the failover... <a href="https://blogs.technet.microsoft.com/networking/2016/01/07/backup-and-restore-dhcp-with-failover-configuration/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[[This post comes to us courtesy of Vithalprasad Gaitonde from Product Group and Gopalakrishnan Krishnan from Global Windows Networking Support] The DHCP service has evolved with its own in-built failover capability starting Windows Server 2012. With this coming into the picture, how can one go about backing up the DHCP server service with the failover configuration parameters as well? This would be the essence of discussion in this blog post. Why do we need to backup in the first place? We all know how crucial DHCP is as a service to any environment. This one service goes down– be prepared for all hell to break lose. Though the service is very much improved in terms of features and capabilities, it still operates out of a jet database which essentially makes the service efficient and fast. Though there is built-in backup/restore capability in DHCP, it is always a good idea to have backups taken and stored. While the reliability of the service has been vastly improved over successive Windows server releases, there are rare but critical issues caused by corruption of the DHCP database. If and when such corruption happens, the admin should be able to restore the service using the "Last known best backup" of the DHCP database. How backups worked with DHCP in Windows Server 2008 R2 and earlier? The below articles talk about how backup and restore functioned in the earlier releases of Windows Server (2008 R2 and prior): <ul> <li><a href="https://technet.microsoft.com/en-us/library/dd759235.aspx">https://technet.microsoft.com/en-us/library/dd759235.aspx</a> </li> <li><a href="https://technet.microsoft.com/en-us/magazine/ff621490.aspx">https://technet.microsoft.com/en-us/magazine/ff621490.aspx</a></li> </ul> In addition to the above, we have also seen enterprise customers leverage the "netsh dhcp server export" context to export the DHCP database for Disaster Recovery purposes. The exported file– is then stored in a separate location and can be used to restore DHCP server service via the "netsh dhcp server import" context at times of dire need. Below are a couple of articles that already explained how this could be accomplished so we won't be visiting them here again: <ul> <li>How to move a DHCP database from a computer that is running Windows Server 2003 to Windows Server 2008 <a href="https://support.microsoft.com/en-us/kb/962355">https://support.microsoft.com/en-us/kb/962355</a> </li> <li><a href="http://blogs.technet.com/b/networking/archive/2008/06/27/steps-to-move-a-dhcp-database-from-a-windows-server-2003-or-2008-to-another-windows-server-2008-machine.aspx">http://blogs.technet.com/b/networking/archive/2008/06/27/steps-to-move-a-dhcp-database-from-a-windows-server-2003-or-2008-to-another-windows-server-2008-machine.aspx</a></li> </ul> Note: The advantage of using "netsh dhcp server export" versus "netsh dhcp server dump" context was that the export command would also extract and store the active lease information from the DHCP server. This way when we restore, the active leases are also restored from that point in time. (Note that: The dump context on the contrary would only be able to restore the scopes, options and reservation information but NOT the active leases). What’s different with DHCP and backup in Windows Server 2012 and Windows Server 2012 R2? With Windows server 2012, failover was introduced along with other useful features like Policy based assignment. This essentially means that there has been change to the functionality and the database structure in the background. Why we suggest NOT to use “netsh dhcp server export” in Server 2012 and Windows Server 2012 R2: The "netsh dhcp server export" context works and works well in standalone DHCP server environments. However what happens when we have Windows Server 2012 DHCP role configured in a failover and DHCP policies in the picture as well? Would this still work? The answer is – “YES, BUT WITH LIMITATIONS”. The key point to note here is that the Failover relationships and the Policies are NOT backed up by the "netsh dhcp server export" command. Any attempt to export and import the configuration using this method on Windows Server 2012 would bring up the DHCP server service and also the active leases like in the earlier days. However, it would be sans the failover configuration. In this case, the failover relationships would need to be reconfigured again. And doing this would need us to remove the second server from the failover configuration and reconfigure the failover configuration between the servers from scratch again. Now, doing this can get cumbersome if there are multiple failover relationships configured on the server for the various scopes there. Also as we can see, the export context does not cover the new improvements that were brought in with DHCP in Windows Server 2012. So what could be the best way to go about to backup in such a scenario? Note: Also, the netsh context is being deprecated and this is one of the important reasons why we suggest not to use the netsh context with DHCP going forward. The backup/restore options discussed earlier via the DHCP GUI would also backup the failover configuration information. So we can manually backup via the GUI to a different location/drive altogether. or This can be achieved also via the Backup-DhcpServer and Restore-DhcpServer powershell commands. The commands are discussed here: <ul> <li><a href="https://technet.microsoft.com/en-us/library/jj553820(v=wps.630).aspx">https://technet.microsoft.com/en-us/library/jj553820(v=wps.630).aspx</a> </li> <li><a href="https://technet.microsoft.com/en-us/library/jj553822(v=wps.630).aspx">https://technet.microsoft.com/en-us/library/jj553822(v=wps.630).aspx</a></li> </ul> For example: Let us say that we have 2 DHCP servers: <ol> <li>CampusDHCP1.campus.com </li> <li>CampusDHCP2.campus.com</li> </ol> And there is a failover relationship configured between these servers as seen below: <a href="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image001_35957A24.png" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image001_5F00_35957A24.png"><img title="clip_image001" style="border-left-width:0px;border-right-width:0px;background-image:none;border-bottom-width:0px;padding-top:0px;padding-left:0px;display:inline;padding-right:0px;border-top-width:0px;" border="0" alt="clip_image001" src="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image001_thumb_530A5BE1.png" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image001_5F00_thumb_5F00_530A5BE1.png" width="283" height="324" /></a> There are hundreds of scopes hosted between these servers. To back up the database with the failover configuration now from campusDHCP1 we can execute: Backup–DhcpServer –ComputerName campusDHCP1.campus.com –Path D:\DHCP\Backup The command should complete successfully as shown below: <a href="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image003_097B0DE4.jpg" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image003_5F00_097B0DE4.jpg"><img title="clip_image003" style="border-left-width:0px;border-right-width:0px;background-image:none;border-bottom-width:0px;padding-top:0px;padding-left:0px;display:inline;padding-right:0px;border-top-width:0px;" border="0" alt="clip_image003" src="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image003_thumb_321979EB.jpg" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image003_5F00_thumb_5F00_321979EB.jpg" width="464" height="75" /></a> Note that the backup is being stored in a different drive altogether here. This PowerShell command works very similarly to the backup option provided in the DHCP management console. Taking a look at the back up location we can see files such as the following created: <a href="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image005_3A9CD935.jpg" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image005_5F00_3A9CD935.jpg"><img title="clip_image005" style="border-left-width:0px;border-right-width:0px;background-image:none;border-bottom-width:0px;padding-top:0px;padding-left:0px;display:inline;padding-right:0px;border-top-width:0px;" border="0" alt="clip_image005" src="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image005_thumb_2A24683A.jpg" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image005_5F00_thumb_5F00_2A24683A.jpg" width="430" height="185" /></a> And inside the new folder: <a href="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image007_39C703FC.jpg" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image007_5F00_39C703FC.jpg"><img title="clip_image007" style="border-left-width:0px;border-right-width:0px;background-image:none;border-bottom-width:0px;padding-top:0px;padding-left:0px;display:inline;padding-right:0px;border-top-width:0px;" border="0" alt="clip_image007" src="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image007_thumb_34E6E0F1.jpg" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image007_5F00_thumb_5F00_34E6E0F1.jpg" width="375" height="191" /></a> This is exactly what happens when the DHCP backup operation happens by default every 60 minutes. The only difference in doing the above steps here is that administrators now, can go ahead and run this command at regular intervals and backup the configuration also to a different drive/server location for disaster recovery purposes. Let us consider a scenario now, where the DHCP service on CampusDHCP1.campus.com crashed due to a database corruption. Any attempts to bring the service up again fail with an error saying " Error 4312: The object identifier does not represent a valid object". (Say). Attempts to restore with the file in the backup folder also fail with the same error, this essentially tells us that the contents of the backup folder were also corrupted in time. Jetpack or Esentutl operations to verify consistency of the database have failed to help us to recover from the corruption. Now in this scenario the only option would be to try and restore from a last known good backup that we might have. Luckily here, we do have one taken via the Backup-DhcpServer powershell command. In order to restore the database, we can do the following: First we need to get the DHCP server service up and running. To do so, remove the contents of the C:\Windows\System32\DHCP folder (or the directory that the DHCP service was primarily configured to load the database from). We can either cut these files out to a different location (just in case) or delete the contents from this folder. The above operations can be performed as the service is down and currently not starting up. The main idea behind doing this, is to remove the corrupted database (dhcp.mdb) file from the location that the DHCP server service is trying to read from. Once the folder contents are removed, start the DHCP server service again. This time the service should start up fine and create fresh instances of the files that we just removed. This is like starting from scratch and the DHCP service now has a fresh, clean database to start work with. Note: Do NOT delete the contents of the folder unless you are absolutely sure that you have a good backup. Once the service is back up and running, then run the following PowerShell command to restore the database from the backup that was created previously: Restore–DhcpServer –ComputerName CampusDHCP1.campus.com –Path D:\Dhcp\Backup Say Y (Yes) when prompted asking if we really want to go ahead with this operation or not: <a href="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image009_2F97FA40.jpg" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image009_5F00_2F97FA40.jpg"><img title="clip_image009" style="border-left-width:0px;border-right-width:0px;background-image:none;border-bottom-width:0px;padding-top:0px;padding-left:0px;display:inline;padding-right:0px;border-top-width:0px;" border="0" alt="clip_image009" src="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image009_thumb_4D0CDBFD.jpg" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image009_5F00_thumb_5F00_4D0CDBFD.jpg" width="400" height="128" /></a> When prompted for a service restart, restart the DHCP server service: <a href="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image011_7CCA847C.jpg" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image011_5F00_7CCA847C.jpg"><img title="clip_image011" style="border-left-width:0px;border-right-width:0px;background-image:none;border-bottom-width:0px;padding-top:0px;padding-left:0px;display:inline;padding-right:0px;border-top-width:0px;" border="0" alt="clip_image011" src="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image011_thumb_5356433C.jpg" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image011_5F00_thumb_5F00_5356433C.jpg" width="418" height="135" /></a> Once this is done, you should see the DHCP server service up and running on the server and trying to sync with the partner servers in the failover relationships: <a href="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image013_5BD9A286.jpg" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image013_5F00_5BD9A286.jpg"><img title="clip_image013" style="border-left-width:0px;border-right-width:0px;background-image:none;border-bottom-width:0px;padding-top:0px;padding-left:0px;display:inline;padding-right:0px;border-top-width:0px;" border="0" alt="clip_image013" src="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image013_thumb_19699101.jpg" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image013_5F00_thumb_5F00_19699101.jpg" width="448" height="148" /></a> Checking the Failover tab from the IPv4 properties: <a href="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image014_49273980.png" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image014_5F00_49273980.png"><img title="clip_image014" style="border-left-width:0px;border-right-width:0px;background-image:none;border-bottom-width:0px;padding-top:0px;padding-left:0px;display:inline;padding-right:0px;border-top-width:0px;" border="0" alt="clip_image014" src="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/clip_image014_thumb_1FB2F840.png" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/clip_5F00_image014_5F00_thumb_5F00_1FB2F840.png" width="282" height="334" /></a> You would see that the service has come up and continues to run in the Recover Wait state. The server typically stays in this state for the MCLT duration before resuming Normal operations with its partner. More information on the transition states can be found here: <a href="https://technet.microsoft.com/en-in/library/dn338985.aspx">https://technet.microsoft.com/en-in/library/dn338985.aspx</a> Give the server some time now so that it can sync up with its partner servers before resuming normal operations on the network again. The advantage as we can clearly see are that the backup, restore commands help us to also restore the failover relationships that existed on the servers as well. ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/01/07/backup-and-restore-dhcp-with-failover-configuration/feed/</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>Virtual Machine Queue (VMQ) CPU assignment tips and tricks</title> <link>https://blogs.technet.microsoft.com/networking/2016/01/04/virtual-machine-queue-vmq-cpu-assignment-tips-and-tricks/</link> <comments>https://blogs.technet.microsoft.com/networking/2016/01/04/virtual-machine-queue-vmq-cpu-assignment-tips-and-tricks/#comments</comments> <pubDate>Mon, 04 Jan 2016 09:03:00 +0000</pubDate> <dc:creator><![CDATA[Kaushik Ainapure [MSFT]]]></dc:creator> <category><![CDATA[Uncategorized]]></category> <category><![CDATA[assignment]]></category> <category><![CDATA[CPU]]></category> <category><![CDATA[VMQ]]></category> <guid isPermaLink="false">https://blogs.technet.microsoft.com/networking/2016/01/04/virtual-machine-queue-vmq-cpu-assignment-tips-and-tricks/</guid> <description><![CDATA[Hello First a small introduction. I am Marco Cancillo and have been working at Microsoft since 2013 as a Sr. Support Engineer in the western Europe CTS Network team.Within my work I have seen challenges on how to use set-netadaptervmq and achieve an optimal configuration. set-netadaptervmqcmdlet sets the virtual machine queue (VMQ) properties of the... <a href="https://blogs.technet.microsoft.com/networking/2016/01/04/virtual-machine-queue-vmq-cpu-assignment-tips-and-tricks/" class="read-more">Read more</a>]]></description> <content:encoded><![CDATA[Hello First a small introduction. I am Marco Cancillo and have been working at Microsoft since 2013 as a Sr. Support Engineer in the western Europe CTS Network team. Within my work I have seen challenges on how to use set-netadaptervmq and achieve an optimal configuration. <a href="https://technet.microsoft.com/en-us/library/jj130924(v=wps.630).aspx">set-netadaptervmq</a>cmdlet sets the virtual machine queue (VMQ) properties of the network adapter. VMQ is a scaling networking technology for Hyper-V switch that improves network throughput by distributing processing of network traffic for multiple virtual machines (VMs) among multiple processors. A thorough familiarity with VMQ and dynamic VMQ is highly recommended before changing any default values with this cmdlet. The goal of this article is to assist on how to use set-netadaptervmq and in my experiencing visualizing helps a lot. One of the challenges is that there is no single solution for this. It heavily depends on the following variables <ul> <li>Amount of CPU Sockets used in the server</li> <li>Amount of Physical Cores per CPU socket</li> <li>Amount of NICs in the LBFO team(s). Depending on the LBFO mode</li> <li>Amount of VMQ Queues provided per interface</li> <li>LBFO mode. In the examples I will use Switch Independent Dynamic or Hyper-V port mode as these are the most common and provide the largest set of VMQ Queues</li> <li>What is the LBFO team servicing. Is the team servicing everything or are there multiple teams with different roles like VMguest traffic and management tasks (Management/ Live Migration / Cluster)</li> </ul> When using set-netadaptervmq there are some guidelines you have to take into consideration <ul> <li>Do not use CPU 0</li> <li>Only physical cores can be used</li> <li>Do not span NUMA node</li> <li>Stay below 64 Logical CPUs</li> </ul> Plus be aware that <ul> <li>a VMQ Queue can only use 1 CPU core</li> <li>multiple VMQ queues can use the same CPU core</li> <li>the algorithm only starts using the next CPU in the assigned range when it exceeds a 90% utilization</li> </ul> When you take these into account you have a certain freedom on how you can to distribute the resources. To make it more tangible I created 2 examples, using 6 Core CPU’s with Hyper Threading enabled but the same logic applies if you have more or less core available. Example 1 Customer has a Hyper-V cluster running server 2012R2 Each server has the following hardware <ul> <li>2 CPU’s with 6 Physical and 12 Logical Cores</li> <li>2 10Gbe NICs from HP with 28 VMQ queues per interface</li> </ul> Teaming configuration (with a switch bound to it) <ul> <li>TEAM_HV</li> </ul> <ul> <li>LBFO team configured in Switch Independent Dynamic Port mode</li> <li>NICS CNA_C1 and NICS CNA_C2 are used in this team</li> </ul> The following configuration was active Name        InterfaceDescription              Enabled BaseVmqProcessor MaxProcessors NumberOfReceiveQueues           —-        ——————–              ——- —————- ————- —————- CNA_D2_CSV    HP FlexFabric 20Gb 2-port 65…#6 False   0:16             2             0               CNA_D1_LM    HP FlexFabric 20Gb 2-port 65…#5 False   0:12             2             0               CNA_C2        HP FlexFabric 20Gb 2-port 65…#4 True    0:8              8             28              CNA_C1        HP FlexFabric 20Gb 2-port 65…#3 True    0:0              8             28              CNA_A2        HP FlexFabric 20Gb 2-port 65…#2 False   0:20             2             0               CNA_A1        HP FlexFabric 20Gb 2-port 650F… False   0:20             2             0               TEAM_HV        Microsoft Network Adapter Mu…#2 True    0:0                            56              TEAM_Mgmt    Microsoft Network Adapter Mult… False   0:0                            0               When plotting this configuration on in a table it looks like this <a href="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/1_46152306.png" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/1_5F00_46152306.png"><img width="723" height="97" title="1" style="background-image:none;padding-top:0px;padding-left:0px;display:inline;padding-right:0px;border:0px;" alt="1" src="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/1_thumb_638A04C3.png" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/1_5F00_thumb_5F00_638A04C3.png" border="0" /></a> Which shows an overlap and NUMA spanning which will result in event ID 106. What you want is to spread the load over the CPU cores and offload CPU 0:0 for example like this <a href="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/2_7C8865B9.png" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/2_5F00_7C8865B9.png"><img width="736" height="102" title="2" style="background-image:none;padding-top:0px;padding-left:0px;display:inline;padding-right:0px;border:0px;" alt="2" src="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/2_thumb_7E58BB80.png" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/2_5F00_thumb_5F00_7E58BB80.png" border="0" /></a> The commands to achieve this is the following Set-NetAdapterVmq -Name "CNA_C1" -BaseProcessorNumber 2 -MaxProcessors 5 -MaxProcessorNumber 10 Set-NetAdapterVmq -Name "CNA_C2" -BaseProcessorNumber 14 -MaxProcessors 5 -MaxProcessorNumber 22 Example 2 Customer has a Hyper-V cluster running server 2012R2 Each server has the following hardware <ul> <li>2 CPU’s with 6 Physical and 12 Logical Cores</li> <li>2 10Gbe NICs from vendor XYZ with 32 VMQ queues per interface</li> <li>2 10Gbe NICs with 8 VMQ queues per interface</li> </ul> Teaming configuration (with a switch bound to it) <ul> <li>GuestTrafficLBFO</li> </ul> <ul> <li>LBFO team configured in Switch Independent Dynamic Port mode</li> <li>The 2 XYZ NICs are used in this team named CNA1 & CNA2</li> </ul> <ul> <li>ManagementLBFO</li> </ul> <ul> <li>LBFO team configured in Switch Independent Dynamic Port mode</li> <li>The 2 XYZ NICs are used in this team named CNA3 & CNA4</li> </ul> <a href="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/3_26F72788.png" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/3_5F00_26F72788.png"><img width="685" height="120" title="3" style="background-image:none;padding-top:0px;padding-left:0px;display:inline;padding-right:0px;border:0px;" alt="3" src="https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/55/08/metablogapi/3_thumb_61DE5A51.png" original-url="http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-55-08-metablogapi/3_5F00_thumb_5F00_61DE5A51.png" border="0" /></a> The commands to achieve this is the following Set-NetAdapterVmq -Name "CNA1" -BaseProcessorNumber 2 -MaxProcessors 4 -MaxProcessorNumber 8 Set-NetAdapterVmq -Name "CNA2" -BaseProcessorNumber 14 -MaxProcessors 4 -MaxProcessorNumber 20 Set-NetAdapterVmq -Name "CNA3" -BaseProcessorNumber 10 -MaxProcessors 1 -MaxProcessorNumber 10 Set-NetAdapterVmq -Name "CNA4" -BaseProcessorNumber 22 -MaxProcessors 1 -MaxProcessorNumber 22 Keep in mind that this is just an example. If you expect more network load on the management switch/LBFO team then you could assign more CPU’s to it. Other links: VMQ Deepdive series <ul> <li><a href="/b/networking/archive/2013/09/10/vmq-deep-dive-1-of-3.aspx">http://blogs.technet.com/b/networking/archive/2013/09/10/vmq-deep-dive-1-of-3.aspx</a></li> <li><a href="/b/networking/archive/2013/09/10/vmq-deep-dive-2-of-3.aspx">http://blogs.technet.com/b/networking/archive/2013/09/10/vmq-deep-dive-2-of-3.aspx</a></li> <li><a href="/b/networking/archive/2013/10/22/vmq-deep-dive-3-of-3.aspx">http://blogs.technet.com/b/networking/archive/2013/10/22/vmq-deep-dive-3-of-3.aspx</a></li> </ul> Event ID 106 when a Hyper-V virtual switch is bound to an LBFO team <a href="https://support.microsoft.com/en-us/kb/2974384">https://support.microsoft.com/en-us/kb/2974384</a> Until next time! -Marco ]]></content:encoded> <wfw:commentRss>https://blogs.technet.microsoft.com/networking/2016/01/04/virtual-machine-queue-vmq-cpu-assignment-tips-and-tricks/feed/</wfw:commentRss> <slash:comments>5</slash:comments> </item> </channel> </rss>

Learn more about Windows Server software-defined datacenter solutions

View solutions