So after reading trough alot of forum posts and blogposts on the subject and also getting alot of feedback on my previous ebook I decided to write a blogpost on the subject. Let us consider the following we have a NetScaler two-arm mode where we have an service located in DMZ and backend-server on another subnet.

So some important things to think about:

• VIP is NOT an packet generating IP by default, it has the load balancing logic (Methods, Persistency and so on)
• Internally on the NetScaler when traffic hits a VIP it will look up the service group(services) servers to see if the NetScaler is located on L2 directly to the backend servers, if not it will look at the routing table to see if it can talk to that network.
• When adding a SNIP to the NetScaler, it will create a DIRECT ROUTE to that particular layer 2 network. ( In case of SNIP 192.168.1.110 (It will add a DIRECT ROUTE 192.168.1.0/24 where the GW is set to 192.168.1.110. The SNIP is used for the route lookup capability, which the NetScaler is commonly used for when returing traffic.
• Most of the monitors which are attached to a service are using the SNIP as Source IP

So when a client accesses a VIP all traffic will be directed to the VIP, where the destimation MAC  will be directed to Interface 1. Remember that on a NetScaler a IP address is not directly bound to a Interface, unless specifically configured.

The NetScaler has an interal table which looks at the servers  that are attached and will then using the closest IP from SNIP to talk with the backend server.

Now the problem with the example above is that it will not work with the default settings. Because since a VIP cannot generate outgoing packets on its own, the traffic flow will stop.

It is important that we have an L2 IP address on the same L2 network that we have the VIP. This is because SNIP is a Packet generating IP. So if we look at the example above again

This time we have a SNIP where the VIP is located. Meaning that we have a SNIP for each L2 network that we have. So in this the traffic flow will work like so.

Client –> VIP –> NetScaler –> SNIP (Closest L2 IP) –> Server, and when the NetScaler now responds back to the client

Server –> SNIP –> NetScaler (Session Table) –> VIP (Check if SNIP is present) –> Client

So even if we setup a SNIP on the same network where the VIP is located, this is never used as a source when going back to the client, it is just needed to establish a packet generating feature.

Mac based forwarding

Another option that we have, which many use which is called MAC Based forwarding.

Q. What is MBF?

A: MBF alters the way the NetScaler appliance routes the server replies back to clients. MBF caches the MAC address of the uplink router that forwarded the client request to the appliance. When a reply is received, it is passed through to the same router that sent the client request without going through any route lookup. If MBF is disabled, then the return path is determined by a route lookup, or is sent to the default route if no specific route exists.

Which is essentially turning of the routing lookup feature. IF we use this feature, then we do NOT require a SNIP where the VIP is located because then the packet generating feature is located on the interface itself. But still features like static routes will still work because when the NetScaler initiates a connection, it uses the route and ARP tables for the lookup function

Different backend subnets and monitors

What about the SNIP’s if we want to communicate with server 2 which is located on another network? Since we already have a SNIP in the default backend subnet. We can just add a new static route

Network to access:          netmask 10.200.200.0 – 255         the gateway that I need to talk to with to reach that network
192.168.0.0                      255.255.255.0                                 192.168.1.1

This presumes that the Router 1 (192.168.1.1 has knowledge of the second router on the network) another option that we have if we do not want to have that SNIP traversing between the different network is to add another SNIP directly to that subnet, with using for instance VLAN or direct attaching the interface.

What if I have multiple SNIPs connected to the same subnet?

The NetScaler would use the SNIPs in a round-robin fashion to communicate with the resources. If you want to dedicate a SNIP to a particular service you should create a net profile which allows us to restrict traffc to a particular subnet from a SNIP.

We can also specify a netprofile to a VIP, which allows us to seperate SNIP traffic from customer 1 to customer 2 for instance. For instance if we have two net profiles containing SNIP 1 and SNIP 2, and we bind those to a VIP 1 and VIP 2, we can distigunish traffic coming from which source to the same backend server

Client —> VIP 1 (netprofile) –> SNIP 1 –> Server1

Client –> VIP 2 (netprofile) –> SNIP 2 –> Server1

• If there is no net profile on the virtual server or the service/service group, NetScaler uses the default method.
• If there is a net profile only on the service/service group, NetScaler uses that net profile.
• If there is a net profile only on the virtual server, NetScaler uses the net profile.
• If there is a net profile both on the virtual server and service/service group, NetScaler uses the net profile bound to the service/service group.

We can also bind a particular SNIP to a monitor which in essence will only use a particular SNIP for monitoring purposes, which allows us to even more granulary filter out which SNIPs are used for monitoring and which SNIPs are used for direct backend communication. 

• If there is a net profile bound to the monitor, NetScaler uses the net profile of the monitor. It ignores the net profiles bound to the virtual server or service/service group.
• If there is no net profile bound to the monitor,
  • If there is a net profile on the service/service group, NetScaler uses the net profile of the service/service group.
  • If there is no net profile even on the service/service group, NetScaler uses the default method of selecting a source IP.

We can also specify a Net Profile to

called policy based routing, which allows us  to specify which type of traffic that should be routed and so on.

So for instance we want to route web traffic using the gateway (Since we have an application firewall) but regular monitoring can be going using the direct connection in that case we can specify a PBR (Policy Based Routing) to send HTTP traffic to a particular network to be processed via a Gateway ( Firewall) and therefore eliminating unecessery traffic going via the firewall

NOTE: PBR are evaluated before regular routes, so if there is traffic that is not evaluated via the PBR routes, the regular routing table will  be processed.