The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request.
If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix. If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix. This hotfix might receive additional testing. Apply this hotfix only to systems that are experiencing the problem described in this article. However, this hotfix is intended to correct only the problem that is described in this article. Resolution Hotfix informationĪ supported hotfix is available from Microsoft. Therefore, the server cannot respond to the client's request.
Because some routers are designed or configured not to reply to packets with this mix of unicast and multicast, the server cannot discover the address of the default gateway. In multicast mode, this ARP request contains a combination of the unicast Virtual IP of the cluster and the multicast MAC address of the interface. When you try to respond to a client on a different subnet, the server must first send an ARP request for its default gateway. Outbound connection attempts from any NLB server nodes that use a node-specific IP are also successful. Attempts to connect to the node-specific IP are successful. In this scenario, clients may experience intermittent connectivity failures when they try to communicate with a server that is part of this NLB cluster. The NLB cluster nodes have not recently communicated with any device on the client's subnet. There is a router between the NLB cluster nodes and the client devices.
NLB is configured to run in multicast mode. (The issue is not our routing as devices from different VLANs are OK.The Network Load Balancing (NLB) feature is enabled on a Windows Server 2008-based computer. If I manually enter the ARP entry into the clients table this works. Our routers have a static ARP entry which is working for clients on different subnets, but when a client tries to discover the MAC address for this NLB cluster within the same broadcast domain it never receives a reply. I know this is an ARP issue, but this ARP problem only impacts guests in the same broadcast domain. I'm having an issue with a Microsoft NLB server cluster, it DOES respond to ICMP from clients on different subnets but it DOES NOT respond to ICMP on the same subnet (broadcast domain).īoth servers are running Windows Server 2012 R2.īoth servers are running with a single NIC.īoth servers were working until a recent restart.īoth servers are VMs running on a 2012 R2 hypervisor.
0 kommentar(er)
