0

I have an older ISA2006 based NLB cluster which I plan to migrate to a new TMG2010 NLB cluster. I need to have both clusters active for some time during migration (with different IPs of course).

Both NLB clusters operate in multicast mode, and packets are flooded by the physical network on all ports of the respective VLAN as it should be the case for NLB.

Here is an overview of the logical network layout:

The problem I'm now facing is that when I enable NLB on the new cluster, it will also process traffic destined to the currently active other NLB cluster even though the destination MAC of the frames doesn't belong to it. This causes a lot of headaches like duplicate packet forwarding (e.g. I get 4 replies for a single DNS query) or loads of logs for packets on the new cluster being dropped as TCP out of state.

Consider the following: Both NLBs are active and Host A sends an IP packet to Host B on the other side of the NLB clusters. This is what happens:

  1. Host A will check it's routing table and notice it has to forward the packet to it's default gateway 192.168.1.6 (old NLB)
  2. Host A broadcasts an ARP request for the IP and it's answered with the respective virtual NLB-MAC of the old cluster
  3. Host A sends the packet with the destination IP of B and destination MAC of the old cluster on the wire
  4. The packet is flooded on all ports of the VLAN because the destination MAC isn't learned anywhere and is a multicast destination MAC, there is also no IGMP snooping or anything going on
  5. The frame arrives as intended at the cluster members of the old NLB, they process and forward it accordingly
  6. The frame also arrives at the cluster members of the new NLB cluster (because it's flooded), but instead of discarding the frame at layer 2 since the destination MAC does not match any of it's own, it's also processing the same packet and forwarding it

The same thing happens with packets originating from the other network. This is really confusing me because I thought the OS layer 2 networking stack should discard the frames right away long before they are forwarded to the application layer.

Once I disable NLB on the new cluster, it will stop processing traffic that is destined for the other cluster.
Does anyone have an idea on how I can prevent this behaviour or if this is really how it's supposed to work?

2
  • TMG is a discontinued product, just FYI.
    – MDMarra
    Mar 26, 2014 at 11:43
  • I am well aware of that.
    – Youmoe
    Mar 26, 2014 at 11:56

0

You must log in to answer this question.