Any solution to solve unknown unicast flooding due to NLB clusters design..

[ashok_boin]

Hi,

I think you might be already aware about unknown unicast flooding issue with NLB clusters. In brief, the issue is as follows...

L-3 Router - L-2 switch - cluster nodes

L-3 router learns only NLB cluster MAC address and whereas L-2 switch learns individual cluster nodes MAC address but not NLB cluster MAC address. Due to this, if any input packet comes destined to a cluster node IP, then L-3 router encapsulates final frame with dest MAC address as Cluster MAC address and send to L-2 switch.

As L-2 switch can neither learn nor have NLB cluster MAC address, it treats all those packets as unknown unicast packets and sends to all ports in that particular VLAN. This is really a big issue if you have multiple clusters in single VLAN and scalability issue if you would like to have one VLAN per cluster (Imagine 100 clusters).

Is there any solution found for this? I saw in several articles that this is known issue and apply segregate into VLAN/cluster is the solution. Do you have any other ideas?

Thank you in advance...

Regards...

-Ashok.

[unimicron]

My NLB server has the same issue.

I find a info about this in microsoft,microsoft suggest to set static arp in L3.

It can work,when i set in my 6509 L3 switch.

But i think that the NLB cluster MAC is virtual,if one day have a real or the other mac same with it,how can i do ?

Regards...

By Chris

[sbrozius]

Hi,

You probably have your cluster setup to use Multicast. If you have multiple NIC's per server, and not all NIC's per server are used for NLB, you can set the cluster to use Unicast.

If you have a single NIC per server and you want cluster nodes to be able to reach each other with their own individual MAC addresses, you have to use multicast. If you don't care about that (which means for example that you have to use the NLB Manager from a machine not in the cluster) you should still be able to use unicast. That way, you don't have to worry about everything that's in between.

When you create a cluster, and keep it in existance, the virtual MAC-address will remain the same. When you delete and recreate the cluster, it might be that a new MAC address is created for the cluster, but I'm not sure about that one.

So if you do want to use multicasting, the MAC address should remain the same as long as you do not recreate the cluster... And then you should be able to solve this by setting a static ARP-antry on every router that's between the clients and the cluster.