Lost network connectivity

[chicagotech]

Q: Recently, we keep having a network issue. We can't access some network device such as printer and wireless. When we ping them, it keeps time out. How do you troubleshoot it?

A: This link may help:
Narrow down problematical network device in network - http://www.chicagotech.net/netissues/networkissue1.htm

[chicagotech]

We had a similar case. We have Exchange 2010 setup Network Load Balance that cause the problem. Disabling the NLB fix the problem. Microsoft has this state:

When you use Network Load Balancing (NLB), network adapters that provide fault tolerance may cause problems. When you use NLB in unicast mode, NLB uses a shared virtual media access control address. The shared virtual media access control address is used instead of the physical adapter's media access control address for all communications to the load-balanced IP addresses. With some teaming adapters, the virtual media access control address cannot to overwrite the physical media access control address. This causes in IP address conflicts in the cluster.

Note If you use Application Center 2000 to configure NLB, it will set NLB to unicast mode.

If you use NLB in unicast mode, you may have to manually set the card's Locally Administered address (LAA) to the NLB cluster unicast MAC address. To do this, you must configure the driver software for the load balanced adapter on each computer in the cluster. Do not set the LAA for NLB clusters that operate in multicast mode.

Important If you manually set the unicast LAA, you must also manually remove the unicast LAA when you remove the server from the cluster. If you do not remove the unicast LAA when the server is removed from the cluster, you may receive MAC address conflicts.

This difficulty occurs only on the NLB interface and does not affect teamed, non-clustered interfaces on the same server. Many hardware manufacturers have updated drivers to correct this problem. Also, when you use multicast instead of unicast for NLB, NLB can function in a network adapter teaming environment because NLB does not overwrite the physical media access control address. From the perspective of Microsoft Product Support Services (PSS), use of teaming on clustered or dedicated interfaces is acceptable. However, if problems that occur seem to be related to teaming, PSS may require that you disable teaming while the problem is investigated. If this disabling of teaming itself resolves the problem, you must seek assistance from the hardware manufacturer.

[guest]

Windows Network Load Balancing (WNLB) is the most common software load balancer used for Exchange servers. There are several limitations associated with deploying WNLB with Microsoft Exchange.

WNLB can't be used on Exchange servers where mailbox DAGs are also being used because WNLB is incompatible with Windows failover clustering. If you're using an Exchange 2010 DAG and you want to use WNLB, you need to have the Client Access server role and the Mailbox server role running on separate servers.

Due to performance issues, we don't recommend putting more than eight Client Access servers in an array that's load balanced by WNLB.

WNLB doesn't detect service outages. WNLB only detects server outages by IP address. This means if a particular Web service, such as Outlook Web App, fails, but the server is still functioning, WNLB won’t detect the failure and will still route requests to that Client Access server. Manual intervention is required to remove the Client Access server experiencing the outage from the load balancing pool.

WNLB configuration can result in port flooding, which can overwhelm networks.

Because WNLB only performs client affinity using the source IP address, it's not an effective solution when the source IP pool is small. This can occur when the source IP pool is from a remote network subnet or when your organization is using network address translation.

[guest]

Microsoft's changing advice on whether Windows' Network Load Balancing should be used with Client Access Servers to balance client traffic.

"What we [Microsoft] recommend is a hardware load balancer for most deployments.. there are several reasons..
Hardware load balancers provide you service awareness, so you can actually get down to the individual, not only the individual TCP port, TCP 443 as an example, but you can potentially get down to the individual application as part of that service, depending on the load balancer you deploy. So now you can know if the web service, or the EWS service I should say, is failed - but OWA is still functioning on the CAS array. And you could take that member out of service as the result of that one failure because maybe you have.. Lync deployed and you rely heavily on the EWS service.
Hardware load balancers allow you to deploy different types of persistent methods for the different types of clients, which can then enable you to do different thing depending on your architecture.
What we don't recommend - is DNS round robining; DNS round robin does not provide persistent. It merely provides a means to alternate which servers are responding at a particular time. It does not provide any sort of persistence, or necessarily fault tolerance. So we don't recommend it.
We don't recommend Windows Network Load Balancing, and from a cross site architecture, while there are ways to deploy a single, unified, namespace across multiple datacentres, it's extremely complex, it requires extremely expensive load balancing solutions - you can do it, but it is an operational cost that you have to manage.
So - from our perspective, we recommend creating two separate namespaces, and accessing those namespaces from that perspective."