The purpose of this blog post is to communicate about NetScaler's Layer 3 traffic segmentation capabilities through the implementation of Traffic Domains and communicate design drivers that would motivate the use of traffic domains on an enterprise network. While this post focuses on NetScalers implementation of Layer 3 (L3) segmentation, this is not unique to NetScaler, all other Load-Balancing players implement a form of this.
What is a Traffic Domain
A Traffic Domain is NetScaler's take on VRF (Virtual Routing and Forwarding). Essentially it allows a single physical device to implement multiple 'virtual routing tables' by assigning a device's routing object (such as an IP address, route entry, or etc.) to a traffic domain ID; an integer between 0 and 4096 where 0 is the default traffic domain.
Traffic Domains help with segregating a device's traffic forwarding objects into separate logical functions. For example a Subnet IP, Virtual Server, and Routing Instances can be separated into traffic domains 1, 2, and 3 with aliases of 'DMZ', 'Production', and 'DEV' respectively.
Segregation is primarily useful for security, but also comes with positive ease of management implications.
Why Use Traffic Domains
There can be many creative use-cases and business drivers that spawn when considering Layer 3 traffic segmentation; however, I believe many of these can be distilled down to two primary motivations: security and ease of management. Both of these motivations also go hand-in-hand.
SECURITY
The security motivation is pretty straight-forward: implement traffic domains to segregate network elements that cary differing security level requirements. For example, DMZ vs internal applications. To follow this example through: The traffic trajectories of DMZ, or, internet facing applications, is very different than the trajectories of internal applications. Internet facing (DMZ) applications have network traffic that originates from the internet while internal applications have traffic that originates from, well, the internal organization. The simplest solution to enforce these trajectories is to implement a technological solution that ensures internet-sourced traffic cannot reach applications that should only be reached by internal-sourced traffic. Traffic Domains are a simple way to achieve this.
EASE OF MANAGEMENT
Ease of Management has many components, but I will focus on a few: ease of security, ease of routing, and ultimately ease of reasoning.
I will address these in reverse order: first focusing on 'ease of reasoning'. A network can be more easily secured if it is more easily to reason about. For example, If we enforce traffic trajectories through Traffic Domains by separating DMZ and Internal applications we only need to implement security policies that pertain to their respective domain. So for the DMZ domain, we only need to implement policies that affect internet-sourced traffic to internet facing (DMZ) applications. Through the implementation of Traffic Domains, no other traffic trajectory is possible. Internet sourced traffic will not be able to reach objects in a differing domain than that of the DMZ. You can think of security being achieved through traffic domains by limiting the number of 'edge-cases' to account for in your security policies.
Imagine the scenario where DMZ and internal applications were in the same traffic domain, which means that technically through routing it would be more feasible for internet source traffic to reach internal applications. As this is most likely against security policy, security rules now need to be implemented to enforce this type of traffic trajectory from occurring. This results in confusing rules on security devices to enforce a trajectory that shouldn't be possible, Traffic Domains simplify this.
Not only are security rules more complicated, but routing also becomes more complicated. Consider trying to make routing work between internet facing applications for their internet sourced users and internal applications for their internal users. Just like on the security front, more routing protocols or entries are required to ensure Layer 3 reachability between this spectrum of applications and their users. This also can be simplified with Traffic Domains. Consider the DMZ domain where, in most cases, a single static route would be required to gain reachability between the internet facing applications and their internet sourced users.