To Route, To Bridge or To Process

NetScaler can process traffic in several ways, for example Layer 2 mode, Layer 3 mode and as a full (reverse) proxy, and before you go and implement there are several considerations you need to take on how you would like to get the traffic processed, some of them include:

• Does the NetScaler need to be transparent in my networks?
• Does the NetScaler need to route traffic not intended for one of the IP’s it owns?
• Does the NetScaler need to send the client IP to the back-end server
• What is the return path of the traffic, and do I want NetScaler the see the traffic (so it can be optimized)
• etc.

I found the below chart on the Citrix Support website. This gives a good overview on what happens if you fire traffic at the NetScaler, and if this traffic will be Bridge, Routed or processed by the local NetScaler.

Traffic Flow Process

Personally I am a big fan of the full proxy model. You do not want the NetScaler to route traffic if you have routers and firewall in place to perform that function. The same goes for layer two mode. But there are scenarios that L2 or L3 mode are a must, and it is good to know NetScaler can handle those scenarios too.

One of the other things I mentioned is the original source IP. Many applications need / want to see those IP addresses and basically the two most used options are Use Source IP (USIP) and IP address insertion into the HTTP headers.

(Once more) I am not a big fan of USIP. If you use this mode the original IP address of the client is send as source address via the NetScaler to the back-end server. This makes the back-end server respond directly to the client using it’s default gateway. This default gateway can be the NetScaler in L3 mode, but can also be a firewall or router. If the latter is the case you will have asynchronous routes in your network. Some firewall will drop this return traffic by default.

The insertion of the IP address in the HTTP header is a way more clean approach where the reverse proxy model is maintained (Client IP -> VIP -> SNIP -> Server). This means the traffic flow is the same both incoming and outgoing traffic. However your protocol needs to be HTTP and your applications / server must be able to extract the IP from those headers.

Some food for thought!

Resources

• http://support.citrix.com/article/CTX125544