Citrix NetScaler Traffic Domains are a way of segmenting network traffic for different applications or even tenants. You are able to use a traffic domain to create fully isolated network environments on a single NetScaler instance. An instance is a single appliance or a HA setup of two appliances.
Citrix NetScaler Traffic Domains were introduced with NetScaler 10.0. At first NetScaler Traffic Domains started as a somewhat hidden feature which you could only configure by CLI. As of version 10.1 Traffic Domains are fully configurable in the NetScaler GUI which makes it a lot simpler to use.
In a way NetScaler Traffic Domains could compete with the NetScaler SDX platform. With Traffic Domains we segment networks on a single NetScaler instance instead of the SDX where we create a virtual appliance per network segment.
A downside of using NetScaler Traffic Domains is the fact that some features are only supported for usage inside of Traffic Domain 0. Traffic Domain 0 is the default Traffic Domain, all services run inside Traffic Domain 0 unless explicitly specified.
An example of non supported features are NetScaler Management and NetScaler Gateway. For a complete list of supported features follow this link.
For non supported features for which you need isolation you have two options, NetScaler SDX or additional NetScaler appliances (virtual or physical).
My expectations are that we will see more and more features being supported on NetScaler Traffic Domains. An amazing feature would be to enable management functionality on Traffic Domains where you would only be able to manage or create services assigned to that Traffic Domain. This would be especially useful for multi-tenancy or multi management in situations where for example one team manages Mobility and one team managing a web application.
A few use cases Citrix describes for NetScaler Traffic Domains:
- Use of duplicate IP addresses
- Use of duplicate NetScaler entities
- Multi Tenancy
A use case I’m actually using NetScaler Traffic Domains for is the ability to deliver services in a DMZ as well as an internal network.
Internal Network services like Microsoft Exchange Client Access Services and Microsoft App-V are heavy on traffic and I don’t like those services traversing the firewall in the DMZ. This also works great combined with Direct Server Return (DSR) which is blocked by most firewalls. Check out more on DSR combined with App-V on this article by Ingmar Verheij.
NetScaler Traffic Domains technical background
Before we start with implementing NetScaler Traffic Domains we need to get in to the basics of a Traffic Domain. Each Traffic Domain consists of:
One of the common mistakes while discussing Traffic Domains is that we also need a network interface per Traffic Domain. Although you can separate traffic by assigning Traffic Domains to interfaces on a one per one basis it’s not a requirement. Just like normal networking you can bind multiple vLANs to a single network interface.
A Traffic Domain is bound to at least one vLAN, a vLAN can only be bound to a single Traffic Domain. This is how a Citrix NetScaler actually isolates the network traffic. As explained, we can bind multiple vLANs to a single network interface. This means that, while binding that vLAN, we bind the Traffic Domain to a network interface.
As we have to configure a Subnet-IP (SNIP) per network a NetScaler connects to directly, we need at least one SNIP per vLAN. Without a SNIP we wouldn’t be able to reach a network gateway or connect to services directly.
As we isolate the network traffic, the routing table has to be configured per Traffic Domain. This is quite logical when you remember that Traffic Domains are isolated and therefore can’t reach a Gateway in a different Traffic Domain. The isolated routing table guarantees security by preventing traffic “accidentally” bypassing a firewall.
How to implement NetScaler Traffic Domains
Lets start with the use case. We want to offer services to internet users from within a DMZ as well as services for internal users. We need to isolate the network traffic for internal services and external services.
As shown in the design we have the external services in the DMZ (Grey Colour) which routes through an internal and external firewall. The internal services (blue color) route or connect directly to back-end services.
One of the external services is “NetScaler Gateway” and as explained in this article NetScaler Gateway is only supported in Traffic Domain 0. We also know that we can only perform NetScaler management tasks in Traffic Domain 0.
The internal services will be running in Traffic Domain 1.
Implementation of all the services in Traffic Domain 0, like management and NetScaler Gateway, is just like every other NetScaler implementation. To keep things simple I’ll skip this part and we’ll assume everything in Traffic Domain 0 is running.
When we start implementing Traffic Domain 1 (remember the blue colors) we start with creating a vLAN. We’ll just use one vLAN but you can of course implement as many as you want. Well, there are limitations but I would love to see the use case where that becomes an issue;).
Open the Citrix NetScaler vLAN menu
Create a vLAN
The next step is binding this vLAN to Traffic Domain 1. Create the Traffic Domain and bind the vLAN to the created Traffic Domain.
Open the Citrix NetScaler Traffic Domains menu
Create the Traffic Domain and select the vLAN we just created.
Now that the Traffic Domain is in place implement the required Subnet-IP and routing tables.
Open the Citrix NetScaler IP Menu.
Create a Subnet-IP.
Notice the option where we can select the Traffic Domain. If you have never used Traffic Domains it probably is unnoticed but this is where we bind items to a Traffic Domain.
The screenshot below shows you that the first route for Traffic Domain 2 is automatically created by adding a Subnet-IP. You can create more routes manually, just don’t forget to select Traffic Domain 2.
Now that the Traffic Domain is fully configured and everything is all set up and working we can add some services.
To keep things simple we’ll create an easy service that load balances a webserver on port 80.
Create the server, and again remind selecting the correct Traffic Domain.
Create the service based on the server we just created.
Create the Virtual Server based on the service we just created.
If you have any questions, new use cases or just want to say hi, please feel free to leave me a comment.
A quick community shoutout to Kees Baggerman, Andy Morgan and Ingmar Verheij for their help and reviews.