none
UAG & NLB Config RRS feed

  • Question

  • Hi,

    Firstly, here is another show-stopper (Technet source):

    'After configuring a network adapter to use NLB, configuring multiple dedicated IP addresses (DIPs) on the adapter is not supported. If multiple DIPs were previously configured, only one will remain after you configure NLB; the rest will be deleted'

    Great, so we will now need multiple physical NICs.

    Q1) So if we are publishing multiple HTTP and HTTPs trunk, each will need its own physical NIC?

    Lets assume I have https://secure.company.com. Lets assume I have 2 UAG machines. Lets assume I want to NLB them. Each machine will have at least one DIP, and then the VIP will be shared between the 2 machines.

    But now, lets assume I want to also load balance https://finance.company.com.

    Q2) a) From the above Technet article, I will require a new physical NIC per UAG machine, correct?

    Q2) b) To NLB this second URL, will I need another VIP? or can I use the already existing VIP?

    Last question for this post:

    Q3) I have seen conflicting reports on this - does UAG NLB support load balancing on both internal and external NIC's?

    Regards.

    Wednesday, April 28, 2010 2:56 PM

Answers

  • So our testing has led us to this conclusion:

    - we cannot use the internal IP address of UAG when we point to the webpart (as discussed here:  http://www.ssl-vpn.de/wiki/Default.aspx?Page=How%20to%20integrate%20the%20IAG%20portal%20into%20Sharepoint&Aspx) - it simply does not work.

    - instead, we have to use the UAG trunk name when calling the webpart (which IMHO is the external FQDN of that UAG trunk + unique_signature_of_the_trunk).

    - So by using the external UAG trunk FQDN, and having UAG in an array & NLB configuration...the issue of fault tolerance we are currently discussing is sorted out (as long as we register this UAG FQDN trunk name with an ISP DNS)

    Regards

    • Marked as answer by Erez Benari Wednesday, May 12, 2010 6:58 PM
    Monday, May 3, 2010 3:36 PM

All replies

  • Q1: Yes.  Each IP address / Port combination requires it's own NIC.  Example, you can only have a single trunk on 1 NIC for port 443.

    Q2: Yes.  You will require a new physical NIC in each machine.

    Q3: Yes.  To NLB the second URL, it will need a new dedicated VIP since the VIP from the 1st configuration will be routing traffic to the first two NICs.

    Wednesday, April 28, 2010 3:03 PM
  • Thanks Clement....and what about this one...

    -  I have seen conflicting reports on this - does UAG NLB support load balancing on both internal and external NIC's?

    Wednesday, April 28, 2010 3:04 PM
  • Not sure about that... but from a simple infrastructure standpoint, I don't see why not.  Windows has NLB built in so technically speaking, you can NLB any NICs on your box.  Whether UAG 'supports' it or not, I don't know.
    Wednesday, April 28, 2010 3:57 PM
  • Have a look here: http://technet.microsoft.com/en-us/library/dd903059.aspx

    One line says: "You can configure NLB on the internal network adapter or on the external network adapter."

    The next line says: "Note that when you set up NLB to load balance traffic to Forefront UAG trunks, you can configure a VIP on the external network only. Configuring VIPs on the internal network is not supported."

    What am I misreading?

    Wednesday, April 28, 2010 5:52 PM
  • Not sure about that... but from a simple infrastructure standpoint, I don't see why not.  Windows has NLB built in so technically speaking, you can NLB any NICs on your box.  Whether UAG 'supports' it or not, I don't know.

    That's what I meant about whether it's supported or not.  Apparently it's not.  Might be something to do with the routing tables, but I don't know how UAG interacts with the internal NICs.
    Wednesday, April 28, 2010 6:48 PM
  • One line says: "You can configure NLB on the internal network adapter or on the external network adapter."

    The next line says: "Note that when you set up NLB to load balance traffic to Forefront UAG trunks, you can configure a VIP on the external network only. Configuring VIPs on the internal network is not supported."


    NLB can be used on both the internal and external NICs of a UAG box.

     

    However, configuring NLB on the internal NIC is only supported (and needed) for DA on UAG. For UAG trunks (meaning application publishing) NLB is supported (and needed) only on the external NIC.

     

    Note that NLB load balances traffic to the UAG box, not from it, so I am not sure why you would need it on the internal NIC in a trunk scenario. If you’re looking for a way to load balance traffic from UAG to backend application servers, than you can use UAG’s Web Farm Load Balancing (see this blog post, for more info).

    Thursday, April 29, 2010 6:10 AM
  • Ran,

    We are looking at publishing the UAG webpart inside a Sharepoint portal. According to http://www.ssl-vpn.de/wiki/Default.aspx?Page=How%20to%20integrate%20the%20IAG%20portal%20into%20Sharepoint&Aspx it advises that the webpart points to the INTERNAL IP address of UAG.

    Since we require fault tolerance, we are deploying 2 x UAG devices, hence NLB the internal network card for the webpart component.

    What you reckon?

    Regards.

     

     

    Thursday, April 29, 2010 6:55 AM
  • F5 offers a product the will do NLB for UAG.

    cheers,

    GmFlanagan

    Thursday, April 29, 2010 2:12 PM
  • Ran,

    We are looking at publishing the UAG webpart inside a Sharepoint portal. According to http://www.ssl-vpn.de/wiki/Default.aspx?Page=How%20to%20integrate%20the%20IAG%20portal%20into%20Sharepoint&Aspx it advises that the webpart points to the INTERNAL IP address of UAG.

    Since we require fault tolerance, we are deploying 2 x UAG devices, hence NLB the internal network card for the webpart component.

    What you reckon?

    Regards.

     

     


    Hi S,

    I deleted an earlier response because it wasn't correct. There is no advantage to enabling internal interface NLB because the UAG doesn't act as a outbound web proxy (in contrast to ISA/TMG). While that would be useful for ISA/TMG, you will need to configure the webpart to use another device for outbound web proxy.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, April 29, 2010 2:26 PM
    Moderator
  • So internal VIP (NLB) won't do the trick you say...wonder why not since TMG is running on the box too...and since the UAG boxes will be arrayed, isnt the array informaiton stored in the TMG ADLDS, so perhaps internal webpart URL could link to the array name?
    Thursday, April 29, 2010 2:35 PM
  • One line says: "You can configure NLB on the internal network adapter or on the external network adapter."

    The next line says: "Note that when you set up NLB to load balance traffic to Forefront UAG trunks, you can configure a VIP on the external network only. Configuring VIPs on the internal network is not supported."


    NLB can be used on both the internal and external NICs of a UAG box.

     

    However, configuring NLB on the internal NIC is only supported (and needed) for DA on UAG. For UAG trunks (meaning application publishing) NLB is supported (and needed) only on the external NIC.

     

    Note that NLB load balances traffic to the UAG box, not from it, so I am not sure why you would need it on the internal NIC in a trunk scenario. If you’re looking for a way to load balance traffic from UAG to backend application servers, than you can use UAG’s Web Farm Load Balancing (see this blog post, for more info).


    How about when you are presenting a unique trunk for internal users (maybe with different authentication needs) and want NLB enabled for this?

     


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, April 29, 2010 11:07 PM
    Moderator
  • So internal VIP (NLB) won't do the trick you say...wonder why not since TMG is running on the box too...and since the UAG boxes will be arrayed, isnt the array informaiton stored in the TMG ADLDS, so perhaps internal webpart URL could link to the array name?


    TMG is used as firewall to protect the UAG server and to prevent external users from entering the internal network. There is no outbound access through the UAG server - or if you manage to configure the UAG to do that, it'll fall outside the support boundaries of the product.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, April 30, 2010 12:47 PM
    Moderator
  • OK, I understand.

    So how do we ensure fault tolerance of the UAG webpart inside SPS if we use the INTERNAL IP address of UAG as recommended?

    The only way I can see here is that the webpart points to the external (Internet) name of the published SPS application.

    Friday, April 30, 2010 12:49 PM
  • OK, I understand.

    So how do we ensure fault tolerance of the UAG webpart inside SPS if we use the INTERNAL IP address of UAG as recommended?

    The only way I can see here is that the webpart points to the external (Internet) name of the published SPS application.


    Hi S,

    That's a good question - one for which I don't have an answer :(

    From my understanding of how Web parts work, you need to configure them to use a proxy server, is that right? Since the UAG can't be their proxy server, you need to point them to another address for that.

    Maybe we're talking about two different things?

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Monday, May 3, 2010 2:35 PM
    Moderator
  • So our testing has led us to this conclusion:

    - we cannot use the internal IP address of UAG when we point to the webpart (as discussed here:  http://www.ssl-vpn.de/wiki/Default.aspx?Page=How%20to%20integrate%20the%20IAG%20portal%20into%20Sharepoint&Aspx) - it simply does not work.

    - instead, we have to use the UAG trunk name when calling the webpart (which IMHO is the external FQDN of that UAG trunk + unique_signature_of_the_trunk).

    - So by using the external UAG trunk FQDN, and having UAG in an array & NLB configuration...the issue of fault tolerance we are currently discussing is sorted out (as long as we register this UAG FQDN trunk name with an ISP DNS)

    Regards

    • Marked as answer by Erez Benari Wednesday, May 12, 2010 6:58 PM
    Monday, May 3, 2010 3:36 PM