Hi, I am facing a problem with NLB on Windows 2008. Before explaining that, would like to know, which of the following is the right way to configure NLB? Config 1: Each Node has two NIC. One NIC named NLB and Other NIC named Public. Both NIC connected to layer 2 switch. .As the name suggests NLB is enabled on NLB NIC in unicast mode. Public NIC Network Settings: IP: 10.1.100.x, Mask: 255.x.x.x, GW: 10.1.100.x, DNS: configured NLB NIC network Settings: IP: 10.1.100.x, Mask: 255.x.x.x, DNS registration disabled Links that support Config 1 http://blogs.technet.com/clint_huffman/archive/2007/10/08/an-optimal-network-load-balancing-nlb-configuration.aspx http://www.msexchange.org/articles_tutorials/exchange-server-2007/high-availability-recovery/load-balancing-exchange-2007-client-access-servers-windows-network-technology-part2.html Config 2: Each Node has two NIC. One NIC named Private and Other NIC named Public. Private NIC connected via crossover cable, Public NIC connected to layer 2 switch. NLB enabled on Public NIC in unicast mode. Public NIC Network Settings: IP: 10.1.100.x, Mask: 255.x.x.x, GW: 10.1.100.x, DNS: configured PrivateNIC network Settings: IP: 192.168.1.x, Mask: 255.x.x.x, Links that supports config 2 http://technet.microsoft.com/en-us/library/cc772392.aspx http://support.microsoft.com/kb/193602 http://support.microsoft.com/kb/323431 http://technet.microsoft.com/en-us/library/cc784848.aspx Please suggest which of the above, is the correct NLB config, considering Windows 2008. Is there any other way? Problem: In both the config, I am not able to access NLB across the subnet (a different client subnet, 10.1.90.x). It works fine from the same subnet. If I enable multicast in both the config, it works fine from all subnets. What has been done so far? Enabled IP forwarding for NLB interface (tried for both interface) as per the following article (both netsh and registry entry). http://www.windowsreference.com/windows-server-2008/dual-nic-nlb-configuration-with-windows-server-2008-nlb-clusters http://social.microsoft.com/Forums/en-US/winserverPN/thread/1369b2cf-627e-4eab-bbf2-c02f4a0e0650 Would appreciate any help/suggestions. Thanks!

Hi There,I have the same issue Have you seen this http://blogs.technet.com/networking/archive/2009/01/15/unable-to-connect-to-windows-server-2008-nlb-virtual-ip-address-from-hosts-in-different-subnets-when-nlb-is-in-multicast-mode.aspxMy problem is also multiplied because I'm using VMwareI hope it's fixed soon

Hi,Ya, I have seen this, but it says the issue applies when NLB is in multicast mode and it should work fine in unicast mode.Which mode are you using?As far as I know VMWARE recomends using multicast.Thanks!

HI Again, We are using Multicast but seem to have this problem as wellhttp://support.microsoft.com/default.aspx/kb/953828/en-useven though we are running VMware I suspect it's all related. If I ping a virtual NLB Ip address from a different subnet my arp cache includes the physical IP MAC and not the NLB Mac which doesnt seem to propogate across subnets. We are moving to a hardware load balancer because it's obviously a problem. I hope your problem gets solved soon though there is too much discussion about problems in 2008 with something that worked fine in 2003

We sorted it out the network team had the wrong Mac in the arp table,Duh

Hi,it will hep if youcan please elaborate on this?What is the config you have now, which arp cleared from switc,how you got wrong arp in etc.?Thanks,

Just to add my experience, I had a 2k8 Cluster that I could not ping or connect to the virtual server from outside the subnet when this resource resided on certain nodes. The public nics on all nodes were configured with teaming using broadcom teaming software. The nic teams were in a failover configuration with one active and one standby adapter. For some reason the team mac address that gets adopted is the same as the standby adapters mac which is not an issue and seems to be by design. Looking at the arp table on the switch I was only seeing the nodes and virtual server resource registered against the primary adapters mac address and not the team mac address. The reason for this behavior and fact that I could not connect to the virtual server resource was that the secondary nic was in a different VLAN to the primary. It was easily missed because you do not see the secondary nic register on the switch at all. I had to disable the primary nic forcing the teaming software to switch to the standby adapter before the network team could see the port it was connected to and the VLAN it was in. Sorted the VLAN issue out and now it registers with the team mac and is accessible by the clients. Simple problem easily missed because of the way the teaming seems to work.

There is a network issue when using multicast NLB. YOur network team may have to add a static arp entry on the gateway of the subnet where the NLB cluster lives for the IP address of the NLB cluster. This has to do with network equipment not liking the use of a multicast mac address with a unicast IP address. Cisco equipment will reject the arp response by default if the mac is multicast and the IP is unicast and requires the static entry. Additionally, whn using Multicast it is advisable for your network team to need to add entries into the MAC Address table of any switches that connect to the NLB for the NLB IP. Without the manual MAC Address Table entries, traffic destined to the NLB IP will end up being flooded out every port of the switch. This is because the switch will have trouble learning which port the NLB is actually conencted to. Moral of the story, is invlove your network team when you are building NLB clusters. Below are links to relavant articles from Cisco, VMware and MS. http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006525 http://technet.microsoft.com/en-us/library/ff849728.aspx