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.
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?
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.
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.
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"
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.
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. :-)
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.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!