locked
UAG Multi-use IP Requirements RRS feed

  • Question

  • I am planning my first UAG2010 SP1 deployment with a 2 server array using Windows NLB and where 2 trunks will be presented - one for SharePoint and one for DirectAccess.  From what I have read each trunk requires it's own external IP which translates to 1 VIP for SharePoint and 2 VIPs for DirectAccess.  So for a single server 1 will need 4 public IP's including the one used as the DIP (SelfIP) right?

    Q - When you have a two server array, are the VIP addresses shared accross the array members so that my total external IP requirement is only 5 as shown here:

    1 DIP per device (2)

    2 VIPs for Direct Access (2)

    1 VIP for Sharepoint (1)

    Thursday, July 28, 2011 8:13 AM

Answers

  • Since DirectAccess don't use or depend on UAG Trunks you can reuse the external IP addresses for both - the Trunks and DirectAccess.

    In this case each Array Members only need 3 IP addresses.

    DIP - Management and Sync

    VIP - Teredo1 - IPSec EndPoint1 - IPHTTPS

    VIP - Teredo2 - IPSec EndPoint2 - Portal

    The VIPs will be shared between the Array Members resulting in a total of 4 IP addresses for both nodes. But keep in mind that the two VIPs needs to be consecutive in order to support DirectAccess (e.g. Teredo requires it)

    Kindly,

    Kai Wilke


    • Marked as answer by SHUKKERS Thursday, July 28, 2011 8:59 AM
    Thursday, July 28, 2011 8:41 AM

All replies

  • Correct! :)

    P.S. DirectAccess doesn't use a trunk, but it does require two public IP addresses... 


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Thursday, July 28, 2011 8:36 AM
  • Since DirectAccess don't use or depend on UAG Trunks you can reuse the external IP addresses for both - the Trunks and DirectAccess.

    In this case each Array Members only need 3 IP addresses.

    DIP - Management and Sync

    VIP - Teredo1 - IPSec EndPoint1 - IPHTTPS

    VIP - Teredo2 - IPSec EndPoint2 - Portal

    The VIPs will be shared between the Array Members resulting in a total of 4 IP addresses for both nodes. But keep in mind that the two VIPs needs to be consecutive in order to support DirectAccess (e.g. Teredo requires it)

    Kindly,

    Kai Wilke


    • Marked as answer by SHUKKERS Thursday, July 28, 2011 8:59 AM
    Thursday, July 28, 2011 8:41 AM
  • Are those 2 public IP addresses shared across all members of the array and then the server with the least load responds with a 302 to say redirect to me whilst all other members discard the request.

    Or does each member of the array have its own dedicated VIP addresses and when any member receives a request it send its to all teh other members and then only the least loaded member responds. 

    Thursday, July 28, 2011 8:45 AM
  • I would recommend keeping the DirectAccess and portal trunks separate, but up to you...

    NLB doesn't work like that, suggest you have a look here: http://technet.microsoft.com/en-us/library/bb742455.aspx

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, July 28, 2011 8:49 AM
  • Thanks Kai.  This is inline with my expectation and makes more efficient use of the limited public IP's that I have
    Thursday, July 28, 2011 8:59 AM
  • Thanks Jason, I think a look at NLB is definately my next step. I am more akin to using a BigIP device in these scenarios
    Thursday, July 28, 2011 9:02 AM
  • The VIPs are active on both nodes at the same time. And a Kernel Mode Driver will transparently make the decission which node should respond to the client request. So you wouldn't see any 302 redirects at all...

     

    The NLB decision which node responds to the request is not load based. Instead of that its a static Hash function which will balance the requests based on the source IP address of the client. Both nodes will use the same Hash function, one node will respond and the other will silently drop the connection attempt. A different source IP Address "may" cause different Hash results resulting into the load to be distributed between the array members. The more clients you have, the better is the balancing...

     

    -Kai Wilke

    Thursday, July 28, 2011 9:03 AM
  • Thanks Jason, I think a look at NLB is definately my next step. I am more akin to using a BigIP device in these scenarios


    I like NLB a lot, but it does have its own quirks; you may be a little disappoited if you have used HLBs in the past...

    However, DA and NLB work well together and choices are limtied on the HLB front for DA (F5 only one supported by MS IIRC)

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, July 28, 2011 9:07 AM
  • From memory there is a Cisco limitation when using Windows NLB that I need to delve into as well, but I believe this is cleared up if NLB uses Unicast which DA states is mandatory
    Thursday, July 28, 2011 9:17 AM
  • NLB has a few compatability issues, so design it with the networking guys or come back and ask questions. There are also considerations if using NLB with virtual machines.

    FYI - With the advent of UAG SP1, DA is now supported with Multicast in addition to Unicast...and before anyone quotes TechNet at me, it is wrong and in the process of being updated! ;)

    Cheers

    JJ

     


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, July 28, 2011 9:29 AM
  • From memory there is a Cisco limitation when using Windows NLB that I need to delve into as well, but I believe this is cleared up if NLB uses Unicast which DA states is mandatory


    The limitations aren't a big deal and can be easily avoided...

    Using Unicast:

    When using Unicast NLB in a Cisco environment you wont have any compatibility issues at all. The only thing you have to consider is switchflood, since NLB will turn the traffic directed to your VIP to become a L2 broadcast. So is recommended to use a seperate VLAN for the NLB enabled interfaces to reduce the impact of the resulting broadcast.

    Using Multicast:

    Using Multicast NLB will have some compatibility issues, since it uses multicast L2 frames for unicast TCP/IP traffic. But using Multicast NLB will have some benefits compared to Unicast NLB when it comes to avoid switchflooding - so i'll most likely prefer the multicast mode over unicast mode^^

    In a native Cisco environment you have to keep an eye on two things to make a good use of NLB...

    1.) You have to set a static ARP entry on the NLB facing L3 routing instances, since Cisco has a security feature which protects ARP resolution. This feature will reject responces from unicast IP addresses resolving to multicast MAC addresses. 

    Config Example: arp 10.30.12.1 03bf.0a1e.0c01

    2.) To reduce the NLB switchflood you can set static CAM-Entries on your L2 devices. Using this option allows you to eliminate the switchflood without using a seperate VLAN.

    Config Example: mac address-table static 03bf.0a1e.0c01 vlan 30 interface Te1/5 Po1

    NLB vs. Big5

    Big5 LTM is quite expensive but has better health monitoring, management and a slightly better scalability. But i guess the scalabilitiy wont have any noticable impact on DirectAccess at all, since NLB does already provide a good performance for most of the customers (above 1Gbit/s throughput and above 10k Cons/sec i would recommend using Big5)

    NLB has a good integration into the UAG wizzards and doens't cause any additional costs.

    -Kai Wilke





    Thursday, July 28, 2011 10:42 AM
  • Hi Kai,

    Don't get me wrong, I deploy a lot of NLB-based TMG and UAG arrays and I can see the cost benefits, but it does add an element of complication to the deployment as you need to make sure the network design can cater for how it works, otherwise you hit problems. Switch administration is easy yes, but still an admin overhead and creating dedicated L2 VLANs for NLB enabled interfaces is not always possible if TMG/UAG has to go into an existing VLAN or DMZ. I guess we have our own definifions of "quirks" and "compatibility" ;)

    Many customers and networking guys still consider it less than ideal, often problematic and simply prefer HLBs...just being honest from a real-world perspective...because I know the pitfalls and workaround (as do you by the looks of it) I still recommend it for our designs, but for those that don't, it can be a constant cause of headaches :) 

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk


    Thursday, July 28, 2011 11:14 AM
  • Hi Jason,

    Since several years I’m using both technologies with a great success in “very high performance” datacenter environments (e.g. Web-Tracking Systems). And during this time I’d learned all the pros and cons of both technologies.

    In my humble opinion, the complexity of NLB isn’t that big and the knowledge it takes to create a clean NLB deployment is relatively small compared to what it would takes to deploy a clean Big5 LTM deployment.

    Sure both technologies have their own glitches. But the only different I can see between those two is the quality of the documentation. If Microsoft would provide some better integration guides (e.g. containing some Cisco Configuration examples and detailed background knowledge) the problems would most like become less for the NLB starters and would cause that much headadge for the networking folks...

    My bottom line is that NLB isn’t as bad as its disrepute - but I also agree that people with great HLB experience but almost no NLB experience will most likely tell a different story ;)

    -Kai Wilke

    Former ISA/Forefront & Security MVP (2001-2007)

    • Proposed as answer by Kai Wilke Thursday, July 28, 2011 12:51 PM
    • Unproposed as answer by Kai Wilke Thursday, July 28, 2011 12:51 PM
    Thursday, July 28, 2011 12:42 PM
  • Agreed...I thought I recognised your name by the way ;)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, July 28, 2011 1:07 PM