none
Unicast NLB in distributed L3 switch networks RRS feed

  • Question

  • Hi,

    I have been stumbled over this in another project (TMG). If you have a L3 network with distributed switches, i.e. two switches with either one UAG server and you want to use Unicast NLB (mandatory for NLB with DirectAccess), then this scenario does not work. The problem is that the central L3 switch is making his routing/forwarding decisions based on ARP resolution and MAC based forwarding table. He gets an ARP response from the UAGs for the VIP ip address pointing to the virtual MAC (e.g. 02-bf-12-34-56-78). He then would assing this MAC address to the port where he has got the reply from (in my understanding). This means that he can only forward packets to one of the attached switches and therefore only to one UAG. The only solution for this would be to use Multicast NLB but this is not supported with UAG and DirectAccess. I am wondering whether there is a solution for this, especially as there might be many companies which are using such a network layout.

    Best regards

    Thomas

    Friday, February 11, 2011 12:58 PM

Answers

  • Hi Thomas,

    That's why you come to the TechNet forums - to fill in the "white space" :)

    Yes, multicast NLB *is* supported by UAG Service Pack 1.

    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
    • Marked as answer by Thomas Wendler Wednesday, February 16, 2011 4:36 PM
    Wednesday, February 16, 2011 4:27 PM
    Moderator
  • Hi Thomas,

    As discussed above, we had a customer with a similar problem to this who was using unicast mode (we deployed RTM so only had the option of unicast at that time).

    As part of a series of recent changes (like implementing SP1 and moving to enterprise SQL logging), we moved to multicast mode which has solved the problems with traffic passing down the VLAN trunks correctly.

    The change was simple to affect (just change the mode in the UAG console and activate) and after creating the necessary static ARP entries on the edge firewall and core switches we were back in business with everything working as originally expeceted...network guys and UAG guys all happy :)

    Personally I like the streched VLAN solution for UAG DA (if the network is able) but as this is not a tested deployment model, I think it is not officially supported by MS (which is a shame).

    Cheers

    JJ 


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, April 5, 2011 1:42 PM
    Moderator

All replies

  • Hi Thomas,

    UAG SP1 supports multicast NLB.

    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
    Tuesday, February 15, 2011 12:48 PM
    Moderator
  • Hi Tom,

    Technet still says, that only Unicast NLB ist supported when UAG ist used with Direct Access: http://technet.microsoft.com/en-us/library/ee191502.aspx


    Best regards

    Thomas

    Tuesday, February 15, 2011 8:11 PM
  • Hi Thomas,

    That's why you come to the TechNet forums - to fill in the "white space" :)

    Yes, multicast NLB *is* supported by UAG Service Pack 1.

    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
    • Marked as answer by Thomas Wendler Wednesday, February 16, 2011 4:36 PM
    Wednesday, February 16, 2011 4:27 PM
    Moderator
  • Hi Tom,

    o.k. cool, that's good news. There's always a good reason to visit the forums ;-))

    Can you just change from Unicast to Multicast NLB in the UAG configuration and re-activate the configuration or is it more complicated? Obviously a static ARP entry is necessary on the central router as it will not accept a multicast MAC to a unicast IP and you might probably need to specify on which ports the switches to the UAGs are connected as described here: http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080a07203.shtml

    Cheers

    Thomas

    Wednesday, February 16, 2011 4:39 PM
  • Hi Thomas,

    Yes, that should be all you need to do. However, you might need to restart the array if that doesn't work.

    You are also correct regarding the static ARP entries.

    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
    Thursday, February 17, 2011 1:08 PM
    Moderator
  • Interesting thread guys, I think I have a customer with a similar problem that I was working on diagnosing!
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, February 18, 2011 2:31 PM
    Moderator
  • Hi Jason,

    Let us know how it works out for you and if you're switching over from unicast to multicast mode with UAG SP1.

    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
    Friday, February 18, 2011 4:53 PM
    Moderator
  • Hi Jason,

    Let us know how it works out for you and if you're switching over from unicast to multicast mode with UAG SP1.

    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

    The customer is still RTM, but once we get them to SP1 I think we will look at moving to multicast with IGMP for the NLB operating mode...
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Saturday, February 19, 2011 12:55 AM
    Moderator
  • Cool!

    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
    Monday, February 21, 2011 2:24 PM
    Moderator
  • We are in a similar situation. The only difference is, that we are trying to get NLB to work with 2 domain joined TMG 2010 servers that are in a standalone array.

    Each TMG 2010 server is connected to a foundry-brocade switch. The switches are in a redundant setup and have a dedicated VLAN configured on them that the internal network NICS of both TMG 2010 servers are connected to.

    We have the same problem, If we enable NLB with unicast on the internal network nics, the VIP will go down if one of the TMG 2010 servers is rebooted.

    If we connect the internal network NIC of each TMG 2010 server to one single switch, there is no problemen, when one of the TMG 2010 servers is rebooted, the VIP stays up.

    We are inexperienced when it comes to adding static arp entries to a switch, so we would appreciate if someone could help us out with this.

    Are we correct on this?:

    1. We have to add a static arp entry on the port of the switch to which an internal network nic is connected.

    2. When adding the static arp entry, we have to put in the MAC address of the internal network nic.

    3. When adding the static arp entry, we have to put in the ip address of the VIP.

     

     

     

    Monday, February 28, 2011 1:13 PM
  • Hi everybody. Obviously there is something that is not working in your particular environment, but the theory says that it shouldn't happen.

    When using NLB in unicast mode, the frames (L2) originated in the array nodes come with a source MAC that is not the Virtual MAC. In your example, frames originated at node with ID 1 will look like 02-01-12-34-56-78. The corresponding at node with ID 2 will be 02-02-12-34-56-78 (there is a way to change this behavior in the registry modifying the key masksourcemac, though it is not used by default). A switch will learn the MAC table by inspecting the source MAC in the frames. As the virtual MAC never goes in the source MAC then the switches will never learn that address and the packets with destination of the virtual IP will be flooded to all the ports of the switch. So, for me, the question here is that the switch is not behaving like the theory says. Maybe the fact that it is a L3 switch can affect. I found last year this same situation but it was a recognized issue in the switches (Nortel) that was fixed with an firmware upgrade. Could you please confirm that the MAC registered in the switch is the virtual MAC?


    // Raúl - I love this game
    • Proposed as answer by Kai Wilke Tuesday, August 9, 2011 1:57 PM
    Monday, February 28, 2011 5:02 PM
  • Hi Thomas,

    As discussed above, we had a customer with a similar problem to this who was using unicast mode (we deployed RTM so only had the option of unicast at that time).

    As part of a series of recent changes (like implementing SP1 and moving to enterprise SQL logging), we moved to multicast mode which has solved the problems with traffic passing down the VLAN trunks correctly.

    The change was simple to affect (just change the mode in the UAG console and activate) and after creating the necessary static ARP entries on the edge firewall and core switches we were back in business with everything working as originally expeceted...network guys and UAG guys all happy :)

    Personally I like the streched VLAN solution for UAG DA (if the network is able) but as this is not a tested deployment model, I think it is not officially supported by MS (which is a shame).

    Cheers

    JJ 


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, April 5, 2011 1:42 PM
    Moderator
  • Hi Jason,

    do i understand correctly that when you want to use integrated NLB in combination with 2 switches, you have turn to multicast mode and add static arp entries to each switch, BUT also add static addresses to each TMG server?

    Thursday, April 14, 2011 11:42 AM
  • The need for multicast is specific to the example above when using a VLAN that is stretched (tunneled) between two locations. If the switches are in a single location and have some form physical connection between then, then unicast is often fine.

    When using multicast, you need to add static ARP entries to layer 3 devices that are connected to the UAG interfaces that are running NLB. You do not need to add static ARP entries to the UAG servers themselves...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, April 15, 2011 11:15 PM
    Moderator
  • Just to close this case. In this case the problem was the type of the domain name!

    MS Forefront UAG Management > Array Management Wizard Step 1 > Specify array credentials > Step 2 - Specify Array Credentials

    By Credentials you'll find this:
    User name:
    Pasword:
    Confirm Password:
    Domain:

    There is no information if you have to put the NetBIOS name or FQDN of the Domain? If the FQDN of your Domain is 'contoso.com' then you have to use the NetBIOS name in this case 'contoso' by 'Domain'! Thomas Wendler could reproduce this behavior in a lab environment.

    Do more with less :-)

     


    Soheil
    Tuesday, July 5, 2011 12:18 PM