none
Problems with Unicast NLB RRS feed

  • Question

  • Hi,

    we have 2 UAG servers configured as a NLB Array. As we want to use DirectAccess we had to use Unicast mode. We also have installed all necessary hotfixes (KB977342, TMG SP1 - this should include the fix KB980674 and UAG Update-1 as well as the Hotfix KB981932). The configuration seems to be fine: internal NLB with one IP, external NLB with 3 IP addresses. However we cannot access the virtual and dedicated ip addresses from outside. The servers are connected to a Cisco Catalyst switch, the external gateway is a Check Point Firewall-1 Cluster (R70) which seeminlgy operates in Multicast HA Mode (the virtual MAC of the default gateway has a 01- MAC address). We already did some tracing and see for example that the UAG nodes can acquire the MAC address of the default gateway via ARP. However no external traffic can be seen (only Spanning Tree and CP cluster communication). Ping directly from the firewall also does not work neither the ARP resolution (we tried to define static ARP entries on the CP). What puzzles us a little is the the virtual MAC of the NLB addresses is starting with 02-BF whether the MAC addresses of the dedicated IPs is starting with 03-BF (which indicates Multicast).

    Any ideas?

    Best regards

    Thomas

    Thursday, August 12, 2010 2:19 PM

Answers

All replies

  • This sounds like a complicated scenario, so i'd suggest you try to go to customer support.

    However, just to make facts clear:

    * Are you aware that TMG by default is blocking IPv4 PINGs to the external IP addresses of the UAG server?

    * Did you start NLB in UAG's Web Monitor?

    Thanks,

    Yaniv

    Friday, August 13, 2010 12:22 PM
  • Hi Thomas,

    Here's an article I wrote about NLB years ago before I joined Microsoft - you might find it helpful in terms of interpreting your traces.

    http://www.isaserver.org/articles/basicnlbpart2.html

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Friday, August 13, 2010 12:31 PM
    Moderator
  • Hi Yaniv,

    a support call has already been created. PING has been allowed and NLB has been started. Interestingly ARP resolution to the default gateway is working fine but we do not see any traffic reaching the UAG servers, even a ping from the Check Point does not reach the UAGs neither ARP broadcasts are visible. As we want do limit port flooding to the whole vlan we created static MAC entries on the switch (http://cisco.biz/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/configuration/guide/swadmin.html#wp1051104) for the virtual MAC address of the NLB interface (02-bf-...). I was wondering if this can cause such problems. From my understanding the official recommendation for limiting port flooding is using a Hub (which is not an option in this scenario) or creating a separate VLAN for the NLB servers (which is difficult because we therefore would need a new IPv4 range routed by the provider).

    Best regards

    Thomas

    Saturday, August 14, 2010 7:14 AM
  • In unicast mode, the real MAC addresses will be masked with fake source MAC addresses. This prevents the switch from learning a MAC address and associating it to a specific switch port, thereby breaking NLB. This behaviour is controlled by the MaskSourceMac registry key which is enabled by default.

    Unicast NLB *needs* to switch flood, hence you have no option but to limit the flooding, ideally using a VLAN...it sounds to me like you have a pure layer 2 problem though if you cannot even see ARP table entries. Switch flooding would only become an issue under load, so it sounds like you have another fundamental layer 2 problem with the switch.

    What behaviour do you get if you power off one node so that just one node remains?

    What static MAC entries have you created? I would remove them for troubleshooting...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, August 17, 2010 12:11 AM
    Moderator
  • Hi Jason,

    You have some pretty good blogs posts on this issue - can you point him to them?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Tuesday, August 17, 2010 12:54 PM
    Moderator
  • Tuesday, August 17, 2010 1:05 PM
    Moderator
  • Hi Jason,

    That's a great one!

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Thursday, August 19, 2010 2:46 PM
    Moderator
  • Hi,

    just to let you know, the problem is fixed now. The UAG servers were obviously connected to a wrong switch on the external side. Also it seems that static MAC address assignment is not supported with unicast addresses/unicast nlb and several ports. The 03-BF MAC addresses we have seen in the local ARP table of the UAG nodes are there because the cluster communication is done via Multicast (important if you have more than 2 NLB nodes).

    Best regards

    Thomas

    Monday, September 13, 2010 11:33 AM
  • Hi Thomas,

    Great! Good to hear you got it working and thanks for the follow up!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Wednesday, September 22, 2010 2:04 PM
    Moderator