In his fourth guest appearance on this blog, Microsoft Senior Program Manager Anirban Paul provides the following advice on how to restore failed UDP communication and how to change the certificate used by Network Controller. This information might be useful for you if you've deployed Software Defined Networking (SDN) with Windows Server 2016 Datacenter.
With this blog post, I wanted to highlight a couple of issues that we have encountered recently with SDN customer deployments in Windows Server 2016.
Issue 1: UDP Communication Isn't Working when Outbound NAT is Configured
Customer had configured outbound NAT access for his virtual network through SCVMM (this internally uses SDN Software Load Balancer), so that machines in the virtual network could access the Internet. The customer noticed that TCP traffic to the Internet was working fine, but all UDP traffic was getting dropped. Moreover, this only happened when the Software Load Balancer MUX was on a different HyperV host than the tenant VM.
On deeper analysis, it was revealed that the destination VM was rejecting the packet because the UDP checksum was incorrect. Further investigations revealed a physical NIC issue. The customer was using a physical NIC which was not certified for SDN with Windows Server 2016. The NIC was incorrectly marking the UdpChecksumFailed flag when the inner packet had a valid checksum.
If you are planning to use SDN with Windows Server 2016 Datacenter, please ensure that you use certified NICs.
You can verify whether a network adapter is or is not certified by checking the Windows Server Catalog.
Click Software-Defined Data Center (SDDC) Premium to filter the Windows Server Catalog LAN card list.
Issue 2: Changing the Network Controller Server Certificate
A customer wanted to change the Network Controller server certificate used for communication with the Northbound clients. He was using self-signed certificates and wanted to move to Certificate Authority based certificates. After installing the new certificate on all the Network Controller nodes, he used the Set-NetworkController Powershell command to point Network Controller to the new certificate.
Although the command succeeded, Network Controller communication with SCVMM stopped working.
This is due to a bug in the product where the certificate binding is only changed on one Network Controller node (where the command was run) and is not updated on the other nodes. We are planning to release a fix soon.
As a workaround, you need to manually change the certificate binding on the other Network Controller nodes. Process is as follows:
- Install the new certificate in Personal store of LocalMachine account
- Execute the Powershell command: Set-NetworkController -ServerCertificate <new cert>
- Retrieve the thumbprint of the new SSL certificate that you want to use with Network Controller.
- Double click the certificate and click on Details, note the value of Thumbprint parameter. Remove any spaces in between.
The following illustration depicts the Thumbprint property of a certificate.
On each Network Controller node, check the SSL binding by executing the following command from a command prompt:
netsh http show sslcert
If the result shows the thumbprint of the old certificate, change the binding by executing the following commands:
netsh http delete sslcert ipport=0.0.0.0:443
netsh http add sslcert certhash= <thumbprint of the new certificate> appid=<application ID> ipport=0.0.0.0:443 certstorename=MY
You can retrieve the appid from the output parameter Application ID of the netsh http show sslcert command.
If the binding shows the thumbprint of the new certificate, no additional action is needed on that node.
Here are a few links to SDN topics to assist with your planning and deployment.
If you want to assess your needs and environment for deploying SDN, see the topic Plan a Software Defined Network Infrastructure.
If you want to deploy SDN using scripts, see Deploy a Software Defined Network Infrastructure Using Scripts.
If you want to deploy SDN by using System Center Virtual Machine Manager, see Set up a Software Defined Network (SDN) infrastructure in the VMM fabric.
If you have any questions or feedback about SDN, send an email to firstname.lastname@example.org.