Link to home
Start Free TrialLog in
Avatar of Yeloball
Yeloball

asked on

Unable to ping NLBS cluster IP from different subnet

I have a NLBS cluster setup on 2008 R2. I am able to ping the two physical IP addresses, but not the two virtual IP's or the single cluster IP address.

I need to be able to reach these IP addresses from my 192.168.1.0 network. The unreachable IP addresses are 10.100.1.98 - Single, virtual
10.100.1.99 - Single, virtual
10.100.1.100 - Cluster IP

It is my understanding that a static MAC addresses needs to be entered onto a switch, but I am not exactly sure which switch it needs setup on.

My NLBS servers are plugged into a switch in my DMZ, this DMZ switch resides on 172.20.1.0 network.

The DMZ switch then plugs into the DMZ interface on my firewall. Then LAN interface off the firewall that connects to a Cisco layer 3 switch on the 192.168.1.0 network.
ASKER CERTIFIED SOLUTION
Avatar of Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Yeloball
Yeloball

ASKER

Andrew, are you saying I should enter the static MAC address on ALL of my switches?
Correct, the Cluster MAC Adddress, and IP Address.... see the articles for configuration required on Cisco switch.
Andrew, do you think I should just enter that information on the individual "uplink" interfaces or should I just add it to ALL interfaces on each switch to ensure that I am covered?
ALL interfaces and uplinks.

The switch need to know, where to expect the multicast, for the NLB cluster nodes to work, and converge correctly.
is there a way to do a interface range command within the static mac address command?
that depends on your physical switch config.
On all switches but one, everything is on VLAN 1
Does not matter about VLAN, you need to notify the switch, where the MAC address, should be observed.
Didn't you just tell me above that it needs to be on all interfaces, on all switches fa0/1 - fa0/24 ? Or am I getting confuses here?
If you have a physical switch.... switch A

and you have two ESXi Server, ESXi A and ESXi B connected to Switch A

if you are connecting four interfaces from each host server.

ALL those physical ports, need to be configured for Static ARP entries for IP address and Mac address, because the multicast packets could be entering any of those ports for the cluster IP Address.

If we take it a little further and switch A is connected to Switch B

both Switch A and Switch B, also need to be configured, e.g. trunking ports, to show that the multicast packets could also be on those trunks.

this is how we approach it.
can you ping anything else on the 10.100.1.x range or is it just the NLBS IPs you cannot contact?
as your description suggests you are sending traffic through a firewall, have you configured it to allow traffic to these IPs without NATing?
I have setup WNLB under Hyper-V and it doesn't require any switch or router configuration. I use unicast mode which requires a second vNIC on each WNLB cluster member, and you have to tell the hypervisor to allow thone secondary vNICs to do MAC address spoofing. Not too complicated. Should be the same under VMware.
totallytonto, yes I can ping other nodes in the 10.100.1.x range

It is only the virtual custer IP and individual virtual IP's of the NLBS I am unable to ping. I can ping the physical addresses.
It's not the same under VMware vSphere as Hyper-V.

Multicast is recommended under VMware vSphere. and with multicast, you need to complete switch configuration. - simple!

If you do not configure your physical switches for multicast, multicast will not work.

you could always try a better Load Balancer, try the FREE

http://www.zenloadbalancer.com/
well, as you can ping other IPs on the same subnet it confirms there's no routing/access issue.
I'm afraid it has to be the multicast issue mentioned above.