Falling in love with the Netscaler Content Switching feature is dramatically easy. It’s a wonderful feature that enables you to move all your entry points to just a single one. Imagine having just one public IP for all services you are providing your users.
Beside that, It is Worth to mention that you could host almost any kind of service behind a content switch vServer (CS VIP), even an access gateway vServer (AG VIP) if you take advantage of the Unified Gateway feature on Netscaler 11. As per today you can just host one AG VIP behind a content switch vServer, and I’ll be really disappointed if Citrix does not add support for multiple AG VIPs behind such a wonderful feature.

In most common scenarios the Netscaler analyzes the traffic comming in through the CS VIPs, and parses through the bound content switch policies (CS Policy). When a match is found the CS VIP sends the request to the target load balancing vServer in question.

In some cases you may find a need of binding other types of policies to a CS VIP, like responder or rewrite policies. Note that responder policies are always executed before a CS Policy, since they are usually applied to HTTP requests. A rewrite policy, tho, could be bound at content switch or load balancing level, depending on whatever the request or respons needs to be modified.

• Status of a content switch vServer
  By default the CS VIP Always shows the status “UP”, despite of the status of the Load Balancing vServer (LB VIP) bound to it. This may come handy when you would like to blackhole unwanted traffic. In some other critical scenarios it is a “MUST” to know the status of LB VIPs bound to the CS VIP in question. Meaning, if the LB VIP is showing status down, then we would like the CS VIP to return the same status. You can simply achieve this by using the “stateupdate” parameter while creating the CSVIP.add cs vserver <Name> <ServiceType> <IPAddress> -stateupdate ENABLED
  In case you want to turn it off again, simply use the following:

  add cs vserver <Name> <ServiceType> <IPAddress> -stateupdate DISABLED

• Multiple domains securely on a single SSL content switch vServer using SNI
  State of the Server Name Indication (SNI) feature on the virtual server and service-based offload. SNI helps to enable SSL encryption on multiple domains on a single virtual server or service if the domains are controlled by the same organization, and share the same second-level domain name. Let’s imagine a scenario, when we do have just one CS VIP available to provide secure access to a single web application that contains two different domains, such as “https://smali.net” and “https://smali.net.int”.
  To resolve this issue, you have the possibility of binding multiple certificates to the CS VIP using the SNI (Server Name Indication) option, instead of configuring multiple CS VIPs (one for each domain). Note that your CS VIP need to be in SSL protocol mode, and SNI option need to be enabled in SSL Parameter tab on the CS VIP, Before linking the certificates
• Content Switching Using Global Server Load Balancing (GSLB) Database
  Image a big global customer with hundreds of IP/subnets ranges that need to be categorized.
  To achieve this task, you may want to take advantage of GSLB locationdatabase. You need to enable the GSLB feature for this to work.Well,Let’s start by opening notepad++ and define all our subnets and save the file as “subnet.db”
  Exampel of how the file could look like:

   NSGEO1.0
  Start
  10.10.10.1, 10.10.10.254, EnvokeIT-SE-Site
  20.20.20.1, 20.20.20.254, EnvokeIT-UK-Site

  Upload the file to your Netscaler appliance to “locdb” folder, usually located here: “/var/netscaler/” (you may also want to create a custom folder for this purpose, It’s up to you). From the CLI, Initiate the DB file by the following command (Remember to iniate the command each time you perform any updates to the DB file):

  add locationfile /var/netscaler/locdb/subnet.db

  Now, type the following to see the status of our locationparameters

  show locationparameter

  and the result should be something like this, depending of the amount of entries in DB file of course (In our case we did define two entries):

  Static Proximity
  —————-
  Database mode: File
  Flushing: Idle; Loading: Idle
  Context: geographic
  Qualifier 1 label: Continent
  Qualifier 2 label: Country
  Qualifier 3 label: Region
  Qualifier 4 label: City
  Qualifier 5 label: ISP
  Qualifier 6 label: Organization
  IPv4 Location file (format: netscaler):
  /var/netscaler/locdb/subnet.db
  Lines: 4 Warnings: 0 Errors: 0
  Current static entries: 2  Current custom entries: 0
  IPv6 Location File
  Location file (format: ):
  Not loaded
  Lines: 0 Warnings: 0 Errors: 0
  Current static entries: 0  Current custom entries: 0

  Now initiate the Shell prompt, and check whether an IP adress is part of our DB pre-defined ranges or not…
  (as you see below I chose to check for 10.10.10.25 & 20.20.20.36)…

  Shell
  nsmap -d -t
  Enter IP address to test or q to exit: 10.10.10.25 10.10.10.25 10.10.10.1-10.10.10.254 “EnvokeIT-SE-Site”.”*”.”*”.”*”.”*”.”*” nocoords
  Enter IP address to test or q to exit: 20.20.20.36 20.20.20.36 20.20.20.1-20.20.20.254 “EnvokeIT-UK-Site”.”*”.”*”.”*”.”*”.”*” nocoords

  As you see above, things are working quite well for us. We are getting positive respons for both entered IPs…

  Next step will be creating some content switching policies, and bind them to respective load balancing vServers, using different priorities
  (I’ll be skipping the part of creating content switching actions and target load balancers)…

  Let’s create two CS Policies as examples:

  add cs policy EnvokeIT-SE-Site –rule  “CLIENT.IP.SRC.MATCHES_LOCATION(\”EnvokeIT-SE-Site.*.*.*.*.*\”)” add cs policy EnvokeIT-UK-Site -rule “CLIENT.IP.SRC.MATCHES_LOCATION(\”EnvokeIT-UK-Site.*.*.*.*.*\”)”

  and bind those to respective Load balancing vServers

  bind cs vs EnvokeIT-CS-SE -policyName EnvokeIT-SE-Site EnvokeIT-SE-LBVS -priority 10
  bind cs vs EnvokeIT-CS-UK -policyName EnvokeIT-UK-Site EnvokeIT-UK-LBVS -priority 20

  This means that when a client request comes within a range of 10.10.10.1/24 the Netscaler will forward the request to Envokeit SE vServer, and when a client request comes within a range of 20.20.20.1/24 the Netscaler will forward the request to Envokeit UK vServer.