NLB Ping question

Has anyone seen this behavior before and is it normal and to be expected?
Could it be associated with the Nodes converging?

We have 2 Windows 2003 Enterprise servers fully patched configured for
Network Load Balancing (NLB) as follows:

Node A:
10.5.105.215

Node B:
10.5.105.216

NLB:
10.5.105.219

When we start a continuous ping on Node A to Node B (10.5.105.216) we'll see
approximately 20% of the pings being dropped. Essentially we'll see the
pings respond within 1ms for 10 minutes, followed by a minute or 2 of no
response. We see the same behaviour from the other Node pinging the first
node at the same time. While the drop outs are occurring we find that we are
able to ping both nodes from client workstations, so the drops appear to be
somehow related to the host servers.

We've checked the logs and find no unusual entries, in either the hardware
or OS logs. We've checked the switches that the servers are connected to and
find no indication of problem on either interface port. We did notice the
MAC address reported for the port doesn't match the one reported on the
server when we run an "ipconfig /all" command, the first 4 numbers are
different, but we suspect this is related to the NLB functions.

Thanks in advance for any insights you might have.

Tim

"Tim Walsh" <> wrote in message
news:O40$...

> We have 2 Windows 2003 Enterprise servers fully patched configured for
> Network Load Balancing (NLB) as follows:
>
> Node A:
> 10.5.105.215
>
> Node B:
> 10.5.105.216
>
> NLB:
> 10.5.105.219
>
> When we start a continuous ping on Node A to Node B (10.5.105.216) we'll
> see approximately 20% of the pings being dropped.

If you want to support intra cluster communication (node to node), then you
need a second NIC and need to implement Unicast. You can then use the second
NIC (the one that is not NLB'd) to handle the intracluster communication.


--
Russ Kaufmann,
MVP, MCSE: Messaging and Security, MCT, MCITP, MCTS and other stuff

ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp

Kind of ironic, our development team has been working with Microsoft trying
to get Sharepoint working, one of the first things they had us do was
disable the second nic on both servers, the one that was setup as a
heartbeat and configure the NLB for Unicast. From the research I've done it
looks like this behaviour is an expected behaviour on a unicast configured
NLB. I'm attempting to duplicate the condition in my lab environment now to
see if the fix works.



"Russ Kaufmann" <> wrote in message
news:4D9A9320-7361-4DEB-94DB-...
> "Tim Walsh" <> wrote in message
> news:O40$...
>
>> We have 2 Windows 2003 Enterprise servers fully patched configured for
>> Network Load Balancing (NLB) as follows:
>>
>> Node A:
>> 10.5.105.215
>>
>> Node B:
>> 10.5.105.216
>>
>> NLB:
>> 10.5.105.219
>>
>> When we start a continuous ping on Node A to Node B (10.5.105.216) we'll
>> see approximately 20% of the pings being dropped.
>
> If you want to support intra cluster communication (node to node), then
> you need a second NIC and need to implement Unicast. You can then use the
> second NIC (the one that is not NLB'd) to handle the intracluster
> communication.
>
>
> --
> Russ Kaufmann,
> MVP, MCSE: Messaging and Security, MCT, MCITP, MCTS and other stuff
>
> ClusterHelp.com, a Microsoft Certified Gold Partner
> Web http://www.clusterhelp.com
> Blog http://msmvps.com/clusterhelp

"Tim Walsh" <> wrote in message
news:%23Hn4vY$...
> Kind of ironic, our development team has been working with Microsoft
> trying to get Sharepoint working, one of the first things they had us do
> was disable the second nic on both servers, the one that was setup as a
> heartbeat and configure the NLB for Unicast. From the research I've done
> it looks like this behaviour is an expected behaviour on a unicast
> configured NLB. I'm attempting to duplicate the condition in my lab
> environment now to see if the fix works.

The real question is whether you need the nodes to talk to each other. In
almost all cases, it is not a requirement, but I know of several where it is
vital.

Good luck.

--
Russ Kaufmann,
MVP, MCSE: Messaging and Security, MCT, MCITP, MCTS and other stuff

ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp

I suspect a lot of our concerns are due to this being our first attempt at
setting up NLB, and not taking the time to practice in the sandbox first.
The registry hack does correct the ping issue, I was able to duplicate it in
my sandbox and then apply the hack. Since the hack I've not been able to
duplicate the problem.

I find it frustrating that my counterparts refuse to use the sandbox, guess
they are afraid a cat may have used it or something.

FYI - My sandbox consists of 4 servers on a physically isolated network,
each running Virtual Server 2007 R2 SP1, iscsi storage, it's own domain,
etc. Can pretty much duplicate our Production network.


"Russ Kaufmann" <> wrote in message
news:eCO3Za$...
> "Tim Walsh" <> wrote in message
> news:%23Hn4vY$...
>> Kind of ironic, our development team has been working with Microsoft
>> trying to get Sharepoint working, one of the first things they had us do
>> was disable the second nic on both servers, the one that was setup as a
>> heartbeat and configure the NLB for Unicast. From the research I've done
>> it looks like this behaviour is an expected behaviour on a unicast
>> configured NLB. I'm attempting to duplicate the condition in my lab
>> environment now to see if the fix works.
>
> The real question is whether you need the nodes to talk to each other. In
> almost all cases, it is not a requirement, but I know of several where it
> is vital.
>
> Good luck.
>
> --
> Russ Kaufmann,
> MVP, MCSE: Messaging and Security, MCT, MCITP, MCTS and other stuff
>
> ClusterHelp.com, a Microsoft Certified Gold Partner
> Web http://www.clusterhelp.com
> Blog http://msmvps.com/clusterhelp