Exchange 2010 NLB Cluster

[Steven]

I have a NLB Cluster configured for our Exchange 2010 environment. I have manually added the ARP entry for the Cluster to the interface of the PA. Everything works fine, until you make any change to the PA and commit it. Once you commit it, the PA can no longer ping the Exchange cluster and the entry in the ARP table is not present. All traffic inbound from the Internet to the Cluster shows "incomplete" in the traffic logs and ActiveSync and OWA are not accessible.

To fix the situation, the ARP entry must be removed and then re-added to the interface. This sometimes has to be done multiple times before the ARP entry shows up in the the tables and/or the cluster can be pinged.

Has anybody had this problem and been able to resolve the issue? It's a bit annoying and unacceptable to have connectivity to your email services "die" everytime you make a change to the firewall  config. This symptom never occured until we replace our PIX with the PA.

[bpappas]

Steven,

forgive my ignorance regarding Exchange Clustering, but why do you have to manually add an ARP entry on the PA for the Exchange cluster? Doesn't it respond to ARP requests?

Benjamin

[mharding]

This may help:

NLB can be configured either in unicast or multicast mode.  The former changes the MAC address of each NLB cluster member’s NIC to a virtual cluster MAC address, to which clients connect.  The latter allows the NICs to maintain their existing MAC addresses and adds a virtual cluster MAC address.  Unicast is the preferred method for NLB, so I will explain the process for this method in my details below.

[Steven]

This issue actually originated from the PA's limitation of 500 arp entries in the table. I have resolved this issue; however, having the NLB in multicast is the default configuration for an Exchange 2010 cluster and this issue occurs only with PA equipment. None of our Cisco or HP equipment experience the ARP issue with multicast configured.

[migration]

Hi, take a look at

“Configuration options forWLBS hosts connected to layer 2 switches” at http://support.microsoft.com/kb/193602/EN-US

"If you connect Network Load Balancing hosts with a switch, the switch must be layer 2instead of layer 3 or higher, because all the hosts share the same IP address (the cluster IPaddress), and layer 3 switches direct network packets (incoming client requests) according to theIP address of the destination computer.>><< The cluster uses a multicast MAC address that is mapped to a unicast IP address. The switchdoes not associate the multicast MAC addresses to a port, so the switch sends frames to this MACaddress on all the ports. IP Multicast pruning implementations cannot limit the port flooding,therefore you must use a virtual LAN. Multicast provides no advantage over unicast from theswitches perspective. The increased multicast processing overhead for routers andswitches may lead to slower performance. Carefully analyze the effect on your network whenyou uses multicast to avoid congesting other network devices"

[Steven]

While this is great information, our CAS servers and array are virtualized through VMWare ESX hosts. When you configure a WNLB array for virtual Exchange 2010 CAS servers that uses VMware ESX Server as the virtualization platform, it is highly recommended to configure your WNLB in multi-cast mode since you otherwise will expect an issue with the WNLB array not working properly.

[migration]

I know.

Unfortunately WNLB is not the perfect way to create a Load Balancing method (dedicated systems are better).

So, if you have to use Multicast mode in L3 switching environment the only good way is making use of static ARP entries on the switche.

It would be interesting the point of view of PAN Engineer. 🙂

Thanks

[bhelman]

What was your final resolution to this issue?  We are in the process of upgrading to Exchange 2010 now and the consultants just sprang this multicast issue on me.

[JKoss]

I would also like to chime in that we are looking for a good way to handle our long-standing NLB clusters.  If there were better information around, we would have long ago switched from a unicast approach to anything better than running things off (cringe) HUBS.

[RNC]

For anyone unfamiliar with NLB, these three articles - particularly part 2 - explain how it works. They refer to the Windows 2003 version.

www.isaserver.org/tutorials/basicnlbpart1.html

www.isaserver.org/articles/basicnlbpart2.html

www.isaserver.org/tutorials/nlbpart3.html

[bhelman]

And how does it work in a Palo Alto environment?

[JKoss]

My experience with NLB (previously wlb) is that it is highly dependent on the switches to which the cluster uplinks as well.   What makes this especially difficult, is that the terms for every switch vendor and indeed the NLB documentation use similar, but not identical terms to describe the needed features to make NLB function.   In our case, the switches are not really documented in the same terminology, so it makes it very difficult to figure out what is needed.    So while the PA is relevant, it really is only one part of a much more complicated system.

[friento]

I think arp entry issue is being address on patch 4.04. My issue is adding additional arp entry for NLB traffic.

[Steven]

You should be able to add your static ARP entries form the Ethernet Interface management. We have a few resources that have static entries and have not experience any further issues after manually adding the entries.

[friento]

In my case I can add them in GUI but after I click ok it dis-appear. Only way I can add them is thru CLI commands. But if you view it in GUI and hit ok it will get remove. I've open a case to support and they told me that a fix will be included in version 4.04.