Content switching (Must know)

CS is the ability to redirect traffic based on content file extensions and, going a step further, in redirecting based on geographical locations. Multiple hostnames can be mapped to the same CS VIP using the server name indication feature from NetScaler 9.2 onwards. Starting with the NetScaler version 10 software, the version of MySQL software can be set for content switching virtual servers (this is to avoid compatibility problems between the client and server). This section deals with the implementation of content switching.

Getting ready

We will start with the packet flow of NetScaler and where content switching comes into play. The following diagram is self-explanatory (it is not the entire packet flow to the receiver's endpoint; the focus here is only to CS and LB):

The content switching vserver can be used for HTTP/HTTPS/TCP and UDP protocols, and it can direct it only to another vserver, not to the backend service directly.

Note

The content switching vserver doesn't need an LB vserver to be bound to it for its status to be UP. Even with nothing bound to the CS vserver, the status would show UP (this comes in handy when you want to blackhole unwanted traffic).Hence, it is always recommended to check whether the load balancing vservers that are bound to the content switching vserver are up and running.

If you want to avoid the preceding condition, the following CLI command will help you achieve it (by default, the value is disabled):

root@ NetScaler> add cs vserver <name> <serviceType> (<IPAddress>)  [-stateupdate ( ENABLED | DISABLED )]

Content switching can be done based on the following client attributes:

• Mobile user/PC

• Images/videos

• Dynamic/static content

• Client with/without cookies

• Geographical locations.

• Per VLAN

Similarly, server-side differentiations can also be made based on the following attributes:

• Server speed and capacity

• Source/destination port

• Source/destination IP

• SSL/HTTP

Citrix also has an additional feature (starting from NetScaler version 9.3) that dynamically selects the load balancing feature based on any criteria or condition provided in the CS action/policy:

>add cs action <name> -targetLBVserver <string-expression>
>add cs policy <policyName> -rule <RULEValue> -action <actionName>

The policy is then bound to the CS vserver

Tip

CS vservers can be configured to process URLs in a case-sensitive manner. By default, this option is ON:

>set cs vserver CSVserver -caseSensitive ON

The load balancing vserver bound to the CS vserver need not have any IP address configured unless it is used in a different access as well.

How to do it...

We shall focus on a few case studies that we commonly come across, and that can be solved with the help of content switching:

Case 1: Customer ABC accesses an online shopping portal and gets redirected to a secure connection at the payment gateway. For this scenario, an HTTP LB vserver is used and is bound to the CS vserver, which is on HTTPS:

The configuration in the preceding screenshot shows that a CS policy as well as a responder policy is bound to the CS vserver named testVserver.

The CS policy works on directing the traffic to the target LB vserver (if there are no CS policies bound at all, it goes to the default LB vserver; this default LB vserver should be configured on the CS Vserver). The responder policy, if bound to the CS vserver works on HTTP requests before matching any CS policy.

The configuration is verified by using show cs vserver <vserver name>. A packet capture taken on NetScaler will clearly show the redirect from HTTP to HTTPS as <HTTP 302>.

If there is any traffic that doesn't match any specific CS policies that are bound, then it uses the default policy. If there is no default policy, the user will get an error – HTTP 1.1 Service Unavailable error message.

Case 2: The customer Star Networks has a single web application that contains two domains, namely www.starnetworks.com and www.starnetworks.com.edu and has a content switching setup, which works fine when accessing www.starnetworks.com, but throws an error when accessing www.starnetworks.com.edu.

This happens because the peceding domains are not the same; they are different and the certificate that is bound to the CS vserver would be of type www.starnetworks.com only. To resolve this issue, we can bind multiple certificates to the CS vserver with the Server Name Indication (SNI) option enabled. The SNI option can be enabled in the SSL Parameters tab (this would pop up only if the SSL protocol is chosen while creating the vserver).

The CLI command to enable SNI is as follows:

>bind sslvserver star_cs_vserver -certkeyname    -SNICert
> bind sslvserver star_cs_vserver -certkeyname     -SNICert

For each domain added, NetScaler will establish a secure channel between itself and the client. With this solution, you can avoid configuring multiple CS vservers.

Case 3: A Customer has a large pool of IP subnets that needs categorizing, and it would be a next to impossible task to configure that number of content switching policies; how does he go about deploying this scenario?

The solution is as follows:

1. A database file should be created that includes the IP address range and the domain:

   >shell
   #cd /var/ NetScaler/locdb
   # vi test.db 
   

   (Here, the gslb entries are added, which will be discussed in detail in the Disaster recovery (Should know) recipe.)

2. Run the following command to apply the changes made to the database file:

   > add locationfile aol.db
   

3. Bind the CS policy with an expression stating, for example, as follows:

   "CLIENT.IP.SRC.MATCHES_LOCATION (\"star.*.*.*.*.*\")""
   

How it works...

The working of NetScaler in all three preceding scenarios is that it analyzes the incoming traffic directed to the CS VIP and parses through the bound CS policies, if any. If a match is found, it goes to the target LB vserver. If there are any other policies that are bound (for example, a responder policy or a rewrite policy), then the responder policy gets executed even before the CS policy is executed (since responder policies are usually applied to the HTTP requests).However, rewrite policies can be bound either at the CS or LB level, depending on whether the request or response needs to be modified.

To recap what we have seen in the case studies mentioned before, the first case helps us to do a simple redirect from HTTP to HTTPS using a responder policy bound at the CS level. The second case shows us how multiple certificates with the SNI option are used to solve domain differences that would otherwise cause issues. The final case study shows us the basic but handy setting to map IP address ranges to target load balancing vservers. An important thing to note – there are scenarios where the vserver and the services that are bound to them may be different ports altogether (for example, HTTP LB VIP would be listening on port 80, but the services would be on port 8080). In such cases, the redirectPortRewrite feature should be enabled.

There's more...

This section concentrates on tidbits and troubleshooting techniques:

Tips and troubleshooting

1. We can start with checking the output of show cs and show lb vservers, to see if the services bound to them are up and running:

          root@ns > show cs vserver cs_star_vserver
          
                   1) cs_star_vserver (IP_ADDRESS_HERE:80) - HTTP   Type: CONTENT
                         State: UPClient Idle Timeout: 180 sec
                     Down state flush: ENABLED
                    Port Rewrite : DISABLED
                          Default: lb_vserver       Content Precedence:                  RULEVserver IP and Port insertion: OFF
                          Case Sensitivity: OFF
   

2. If there are responder and rewrite policies, then we can check whether the number of hits on that policy are incrementing or not.

3. Packet captures (using Wireshark) on the server and NetScaler. In some cases, the client would show us the packet flow in depth.

4. The Down state flush feature of the NetScaler is useful for admins planning their downtimes in advance. This feature is enabled, by default, on the vserver and service level. When the feature is enabled, the connections that are already open and established will be terminated and the users will have to retry their connections again. The requests that are already being processed alone would be honored. When the feature is disabled, the open and established connections are honored, and no new connections will be accepted at this time. If enabled at the vserver level, and if the state of the vserver is DOWN, then the vserver will flush the client and server connections that are linked. Otherwise, it would terminate only the client facing connections. At the server level, if the service is marked as DOWN, then only the server facing connections would be flushed.

5. There is another option on the Advanced tab of the CS/LB vserver to direct the excess traffic to a backup vserver. In cases where the backup server also overflows, there is an option to use the redirect URL, which is also found in the Advanced tab of the CS/LB vserver.