Contents

Netscaler Deployment Topology

Website Visitors:

A NetScaler appliance resides between the clients and the servers, so that client requests and server responses pass through it. In a typical installation, virtual servers configured on the appliance provide connection points that clients use to access the applications behind the appliance. In this case, the appliance owns public IP addresses that are associated with its virtual servers, while the real servers are isolated in a private network. It is also possible to operate the appliance in a transparent mode as an L2 bridge or L3 router, or even to combine aspects of these and other modes.

Physical deployment modes

A NetScaler appliance logically residing between clients and servers can be deployed in either of two physical modes: inline and one-arm. In inline mode, multiple network interfaces are connected to different Ethernet segments, and the appliance is placed between the clients and the servers. The appliance has a separate network interface to each client network and a separate network interface to each server network. The appliance and the servers can exist on different subnets in this configuration. It is possible for the servers to be in a public network and the clients to directly access the servers through the appliance, with the appliance transparently applying the L4-L7 features.

One-Arm Topology:

One-arm topology uses one interface to connect to clients and servers. Commonly used when changes to physical network are not allowed. With one-arm mode one logical interface connected to one network segment. Netscaler doesn’t isolate clients and servers. Supports single vlan and link aggregation to satisfy any bandwidth requirements.

  • One arm can mean Source NAT (Use Subnet IP), and two-arm can mean don’t do Source NAT (USIP).
  • One arm can mean that web servers can access the clients/Internet directly (through a router), while two-arm can mean that web servers can’t reach clients without going through the NetScaler.
  • One arm can mean one interface, while two arm can mean multiple interfaces.The default behavior is USNIP (source NAT). You can either connect the NetScaler to the server VLAN, or use routing to reach them. You can change the web server’s default gateway to use NetScaler SNIP, or leave it set to a router/firewall.
https://www.mediafire.com/convkey/4fa1/8w1ldsc3hdawbax7g.jpg
One Arm Topology

Here Netscaler is on single network connection and it is not between any other network devices or any other networks. This is the default and most easiest way to configure netscaler.

Drawback here is, all your traffic goes through one interface in netscaler. Depending on the speed of the interface, how much traffic NS sends and receives, this one-arm topology could be a bottleneck. If client knows the ip address of the servers, they can access the servers directly(if it is in single subnet, explained below)

Two-Arm Topology also called as inline mode:

In Two-Arm topology, one interface of netscaler faces clients and other interface faces backend servers. Mostly used when traffic must be physically seperated into zones or when optimal bandwidth efficiency is desired. This ensures that all traffic flows through netscaler appliance.

https://www.mediafire.com/convkey/8abb/9xjzm392fjcuodi7g.jpg
Two Arm Topology

In a two-arm topology, one network interface is connected to the client network and another network interface is connected to the server network, ensuring that all traffic flows through the appliance. This topology might require you to reconnect your hardware and also might result in a momentary downtime. The basic variations of two-arm topology are multiple subnets, typically with the appliance on a public subnet and the servers on a private subnet, and transparent mode, with both the appliance and the servers on the public network.

Difference between one arm and two arm mode

If you have an internal or internal pair of ADCs to load balance StoreFront and then a separate or separate pair of ADCs to serve Citrix Gateway traffic in the DMZ those ADCs would only need to belong to 1 network each and they would be deployed in one arm.

If you have one or a single pair of ADCs that need to load balance StoreFront on an internal network as well as serve Citrix Gateway traffic in like a DMZ, in that situation the ADC needs to belong to multiple networks which is known as two arm.

Which topology to decide?

It depends on how you are allowed to use the network. If you can connect your netscaler to clients and to the backend servers with seperate physical divisions, two arm topology is better than one arm. one arm is easy to deploy, but it has some bandwidth constraints.

Logical topologies:

Single Subnet:

VIP and SNIP/MIP are on same subnet. Client can access backend server IP directly.

https://www.mediafire.com/convkey/1bac/1iizzusb99pm6k87g.jpg
Single Subnet

As this is using one arm topology, it is called, one arm, single subnet topology.

https://www.mediafire.com/convkey/ab32/udqleuh3hrufj047g.jpg
Single Subnet Topology

Similarly, this is two arm single subnet topology. One interface of netscaler is facing client and the other interface is facing servers. Here there is no VIP because, in single subnet topology, clients can access backend servers directly.

Multi-Subnet Topology:

VIP and SNIP are on different subnets. Client doesnt know the ip address of backend servers.

https://www.mediafire.com/convkey/6cbf/7zn5f0dof1p85z67g.jpg
Multi Subnet Topology

This is one arm multi subnet topology. As clients are on public internet and servers are on private network, clients cannot access the servers even if they know the ip address. Clients can access the servers only via netscaler’s VIP.

Two-Arm Multiple Subnet Topology

One of the most commonly used topologies has the NetScaler appliance inline between the clients and the servers, with a virtual server configured to handle the client requests. This configuration is used when the clients and servers reside on different subnets. In most cases, the clients and servers reside on public and private subnets, respectively. This is also called service-only mode.

https://www.mediafire.com/convkey/5387/h06a3jcrge9srx97g.jpg
Two Arm Multi subnet Topology

This is Two arm Multi subnet topology. Here, netscaler has one interface to public network and the other interface to private network. This is the most commonly used topology.

Two-Arm Transparent Topology

Use transparent mode if the clients need to access the servers directly, with no intervening virtual server. The server IP addresses must be public because the clients need to be able to access them.

https://www.mediafire.com/convkey/13b1/wwh4l3zt5zfqts87g.jpg
Two Arm

Source ip address of incoming client request changes to subnet ip address, but destination ip address doesn’t change. Use transparent mode, if clients need to access servers directly with no intervening virtual server. Server ip address should be public as clients need to contact them directly. Netscaler is placed between client and server, so traffic goes through netscaler. You must enable layer 2 mode for bridging packets (https://www.knowcitrix.com/posts/netscaler-supported-layers/). Netscaler ip and mapped ip are on the same public subnet.

How Two-Arm mode works:

  1. User initiates a request to a VIP hosted on netscaler. VIP represents private servers on backend. It is usually represented to users by your company’s URL.
  2. Netscaler forwards request to backend server via SNIP or MIP.
  3. Once information is processed by backend server, server responds to the request via SNIP or MIP. Netscaler processes the response.
  4. Netscaler forwards response back to the client.

Notes:

  • Netscaler can operate on one-arm and two-arm topologies. Two-armed is recommended.
  • In two-armed mode, flow process consists of request, forward request, response, and forward response.
  • Netscaler can operate in OSI model layers 2 and 3. Netscaler drops multicast, unknown protocol and spanning tree packets.

Want to learn more on Citrix Automations and solutions???

Subscribe to get our latest content by email.

If you like our content, please support us by sponsoring on GitHub below: