I'm a system administrator at a library in Holland. Our personnel uses thin clients which are making a remote desktop session to our session servers. We have two session servers (Windows 2008 R2) configured in a NLB cluster. Both servers are virtualisized. One in Hyper-V (RDS01) the other one in VMWare ESX (RDS03).
The NLB cluster is configured to work in unicast mode. Both servers in the NLB cluster have two network adapters. One for the NLB cluster and the other to use for Peer-to-Peer communication.
The problem we are having is that making a remote desktop session to our NLB cluster often fails (same error as trying to connect to a not existing IP or hostname). After some digging I found out that when I'm trying to view the cluster in NLB manager on RDS03 it often fails to "discover" RDS01. The other way around works just fine (from RDS01 to RDS03).
<I will add images of the NLB Manager on RDS01 and RDS03 as soon as my account is verified>
As you can see on the first picture I disabled the RDS03 in the NLB cluster. Only RDS01 is the active server in the NLB cluster. This solves the connection problem to the NLB cluster for now (so I assume the problem lies around the RDS03).
I learned the NLB Manager uses ICMP to "discover" other hosts in the cluster. So I decided to use a packet sniffer (Microsoft Network Monitoring) to inspect the packets being send out by the NLB Manager. And I noticed in the packet being send out by the RDS01 that it uses the IP address of the Peer-to-Peer adapter on the RDS03. In addition to that, the RDS03 sometimes uses the NLB cluster IP address of RDS01.
Below the packet details captured on the RDS01.
Frame: Number = 2812, Captured Frame Length = 74, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-63-97-23],SourceAddress:[00-15-5D-63-96-2B]
+ Ipv4: Src = 10.81.129.159, Dest = 10.81.129.161, Next Protocol = ICMP, Packet ID = 8406, Total IP Length = 60
+ Icmp: Echo Request Message, From 10.81.129.159 To 10.81.129.161
Next, the packet details captured on the RDS03. When the NLB Managers sends out this package the discovery fails.
Frame: Number = 211, Captured Frame Length = 74, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[02-BF-0A-51-81-A5],SourceAddress:[00-15-5D-63-97-23]
+ Ipv4: Src = 10.81.129.161, Dest = 10.81.129.167, Next Protocol = ICMP, Packet ID = 11326, Total IP Length = 60
+ Icmp: Echo Request Message, From 10.81.129.161 To 10.81.129.167
As last the packet details captured on the RDS03. When the NLB Manager sends out this package the discovery is successful.
Frame: Number = 2095, Captured Frame Length = 74, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-63-96-2B],SourceAddress:[00-15-5D-63-97-23]
+ Ipv4: Src = 10.81.129.161, Dest = 10.81.129.159, Next Protocol = ICMP, Packet ID = 21180, Total IP Length = 60
+ Icmp: Echo Request Message, From 10.81.129.161 To 10.81.129.159
Below the IP configuration for the NLB cluster and its servers.
10.81.129.165 ... NLB cluster IP
10.81.129.167 ... NLB IP for RDS01
10.81.129.169 ... NLB IP for RDS03
10.81.129.159 ... IP RDS01 (second NIC for Peer-to-peer)
10.81.129.161 ... IP RDS03 (second NIC for Peer-to-peer)
Why is the RDS03 using the NLB cluster IP of RDS01? And why does it also uses the peer-to-peer IP of RDS01?What is causing this inconsistent behavior?
