Tuesday, September 1, 2009

Netscaler 1 or 2 arm mode "which is right for you?"

By:Rick Rohne

In the short of it, Netscaler can be placed in many different kind of Network Scenarios. There's One arm and Two arm, Public/Private, MBF, USIP, VLAN's, Aggregated Interfaces, ACL's, Layer 2 and Layer 3, or both... Huh... I could write a book on the many different ways to configure a Netscaler (and I would get about 10 buyers / of those buyers none of them would agree with me), so in light of saving me a few months of my life for a measley 400$ before taxes and lawyer fees, I think I'll start with the simple explanation on 1 and 2 arms. What are the advantages of each and which is right for your organisation?


First, I want to explain the differences between the two (Or three as you will find out). Fundamental difference between one arm and two arms are related to layer 3 networking, not how many interfaces are hanging out of your Netscaler. One arm mode is a Netscaler connected to one network and consists of one IP subnet on the Netscaler. This mode has a single route (The default gateway). Two arm mode actually has multiple Networks configured on the Netscaler. In this mode, there is usually a default route but sometimes (But not always) you will have additional routes that point to the next hop to access backend resources.

Don't confuse one and two arm modes with how many interfaces are plugged into the switch. For instance, a Netscaler can have one interface plugged into the network, but have VLAN trunking configured so that multiple networks are attached to the NS, this is referred to as two arm mode. At the same time, a Netscaler can have up to four interfaces connected to a single switch and aggregated together to form a network bond, this is referred to as one arm mode. Now lets go deep into the different modes...

One Arm Mode

One arm mode is by far the simplest configuration. But don't confuse simple with the only way to do it. In this mode, the Netscaler is generally sitting in a DMZ on the same subnet as the web servers that it is serving content.

The Advantages of this is that it is easy. One arm mode is typically the way that most engineers prefer to implement Netscaler, because you only have to worry about a single route (The all zeros to the Firewall), and they don't have to make any configuration changes on the application servers themselves.

There are a few things to understand before choosing this method. First of all, since the Application Servers are on the same subnet as your VIP, you will use additional IP's on that subnet for non Internet facing recources. This is generally not a problem, but if the subnet happens to be a public subnet (with public IP's), your application servers will have public IP's bound to their NIC's. Obviously the workaround here is to NAT the entire subnet at the firewall.
Another common issue with one arm mode is if you are configuring the Netscaler in a DMZ and expect to load balance internal resource (or you are using the Netscaler for SSLVPN access into your private LAN). In this scenario, you will have to open rules on your inbound leg of the firewall. While this is usually no problem for setting up a public facing Sharepoint site or Web interface, it does pose an issue with full SSLVPN.

Security folks will generally look at this configuration and think that the Web Servers can be compromised because they are not behind the Netscaler... Well,,, yes and NO! Your Firewall should be your first level of defense against attackers, therefore, a security administrator can easily mitigate this risk by locking down public access to only the VIP's and not the individual machines. This being said, of course placing the application servers behind the Netscaler in a two arm mode configuration will add a bit more security (even if it is only security through obscurity). The Netscaler is going to perform the same security related functions (App Firewall, Filtering, Surge Protection, HTTP DoS, etc.) reguardless if the App Servers are in front, behind, or 10 routes past the Netscaler in another city. So i really don't buy it, but I am willing to argue that point....

Two Arm Mode (Traditional)

If you are familiar with the old load balancing products, you might remember that we had to configure the load balance devices "in line" with the web servers. Although not required on the Netscaler (Unless USIP mode is being used in some scenarios), Two arm mode allows an admin to place the Web Apps on a network behind the Netscalers. This configuration is generally not preferred any more and generally requires the Web Apps to change their addresses and default gateway pointed to the Netscalers SNIP or MIP address.

Some admins might say that this is the best way to do it because it hides the web servers from the Public Internet and it saves the amount of public IP's that are needed.... While these are not valid reasons to consider when choosing the way the Netscaler is implemented (Simply look at my earlier conversation about one arm mode and twist it around a bit), there are some especially important reasons for implementing two arm mode.

The first, of course, is that you are replacing a legacy load balancer and you want the migration to be quick and painless. Most legacy load balancers were implemented in a two arm mode so a config and drop will be your quickest turn around.

If you would like all hosts to appear as if their Internet Communications are coming from the Netscaler and not the actual hosts, then you should place the NS's in a two arm mode with RNAT enabled on the Netscalers for those specific hosts. Note that this is usually done when the hosts source Internet Comminications such as Credit Card Transactions and/or SMTP relay where the hosts IP address must match the DNS record. Please note that RNAT can also be done at the firewall in most scenarios.

Alternativly, if you have multiple DMZ's and you want to use "one pair" of Netscalers for all of the DMZ's, this scenario might be the right choice for you. In this scenario, you can perform VLAN tagging from the firewall to the Netscaler and the Netscaler to the backend switches. The Netscaler is then configured with Mac Based Forwarding and each VLAN is basically configured as it's own virtual Netscaler. This is a great configuration for Cloud Hosting providors because they can seperate their customers on their own VLAN's while only having to purchase a single pair of Netscalers to host all of their customers' content.

NOTE: When using two armed mode, you should consider implementing VLANS to separate the two arms. This is very important when configuring HA in two arm mode because in some scenario's the Netscaler can send sync/heartbeat packets out the wrong interface which may result in both Netscalers becoming the primary. This is Generally BAD!

There is one gotcha when configuring the Netscaler in Two arm mode... If you configure the NS in Two Arm mode and you decide to use the Netscaler as the default gateway of the load balancing hosts, the Netscaler will perform "ALL" routing decisions on behalf of the hosts. While this may not seem to be a big issue, it does, however alter your ability to make future design changes such as drop in a leg into your private Network, etc...

Two Arm Mode (Public / Private)

Two arm mode (Public/Private) is configured no differently than two arm (Traditional) with the exception that the second arm actually hooks into your private network. Why would you do this you might ask???

By extending an Interface to the internal Network, you can use the same Netscaler hardware for load balancing external apps as well as internal apps. It also allows you to perform functions such as SSL VPN without having to open a bunch of holes in the firewall when using one arm mode. This mode saves money, but it does add some complexity.

First of all, in a Two Arm (Public / Private) mode, you have to pay attention to routing... You will most likely have an external route (Same as always all zeros to the Firewall) but you will also have to add internal routes to internal resources.
Second, you may have to pay attention to routing loops. If connections from internal hosts are accessing VIPS on the external Interface, the Netscaler may try to send packets back to the internal host using the internal connection, hence a routing loop is born. This can easily be fixed by either adding duplicate internal VIPS, NATTING at the DMZ, or by turning on Mac Based Forwarding on the Netscaler.
Many security folks seem to bark at this as being an "in-secure" way of deploying the Netscaler. True, this specific mode does raise some security concerns. But all of these concerns can be addressed by features built into the Netscaler. First of all, you should ALWAYS assign VLANS to the internal and external interfaces to ensure that there is some layer 2 separation between the two networks (Remember, it is called an Application Switch). Second, make sure the device is only in Layer 3 mode and Layer 2 is disabled. Third, you can always configure ACL's to further lock down the environment. Finally. if you are worried about SSLVPN traversing your network, you really should take a look at the SMART ACCESS features of the Netscaler. Inbound access with SSLVPN is not only controlled at the Network layer, but also at the user, group, device, and individual scenario layer such as the presence of Anti-Virus or a specific Service Pack!
I really do like configuring Two Arm mode (Public / Private) because it basically turns your Netscaler into a buy one get one free deal. Of course, it usually goes beyond just the price. Simple management, easy administration, and easy provisioning of new VServers on the inside and out! Now if you ask me, it's worth it!

What about all the other modes?

I know, there are many other ways of configuring the Netscaler. USIP, Layer 2, Layer 3, HA, MBF... Well, I'm not going to cover them all.... I guess you will just have to wait for that book, or maybe you can sit in one of my classes. In either case, you should get to know the product before making rash decisions on how it should be placed in your Network. the Netscaler is an amazing product that can do more than you could ever guess, but you could easily back yourself into a corner and make it very difficult to add functionality if the wrong mode has been chosen.
Now let's hear the roars!!!

More information on Netscaler

blog comments powered by Disqus
Microsoft Virtualization, Citrix, XENServer, Storage, iscsi, Exchange, Virtual Desktops, XENDesktop, APPSense, Netscaler, Virtual Storage, VM, Unified Comminications, Cisco, Server Virtualization, Thin client, Server Based Computing, SBC, Application Delivery controllers, System Center, SCCM, SCVMM, SCOM, VMware, VSphere, Virtual Storage, Cloud Computing, Provisioning Server, Hypervisor, Client Hypervisor.