Imagine this:

A user logs into your application, adds items to their cart...
Everything works fine.

Then suddenly — they get logged out or their cart is empty.

Why?

Because their next request went to a different backend server.

This is one of the most common real-world issues in load-balanced environments.

Without session persistence:

• Login sessions break

• Shopping carts reset

• User experience becomes frustrating

2. Concept Explanation

Session Persistence (Sticky Sessions) ensures that:

A user is always sent to the same backend server for the duration of their session.

Simple Analogy

Think of going to a barber shop.

• First time → any barber (load balancing)

• Next visits → you go to the same barber (persistence)

Because:

• They remember your style

• They already know your preferences

3. Types

1. Source IP Persistence

• Uses client IP to stick to a server

• Simple but unreliable because NAT users share the same IP

• Load balancer maintains persistence table

2. Cookie-Based Persistence

• Load balancer inserts or uses cookies

• Most reliable for web applications

• The cookie contains hashed persistence information

3. SSL Session ID

• Uses SSL session information

• Useful for HTTPS traffic without cookies

• This type of persistence is used in SSL-BRIDGE service (NetScaler)

You can refer to NetScaler Docs for more details on different types of persistences supported by NetScaler.

4. How It Works Internally

Step-by-step flow:

1. Client sends first request to Load Balancer

2. Load Balancer selects a backend server

3. Load Balancer creates a persistence record

4. Response sent back to client

5. Client sends next request

6. Load Balancer checks persistence table

7. Request is sent to the same server

Key idea:
Load balancer maintains a mapping table between client and server. In cookie-based persistence, the load balancer may rely on information stored in the cookie instead of a traditional persistence table, but it still maintains mapping logic to route traffic correctly.

5. Diagram

Session Persistence Diagram

This diagram shows how the load balancer remembers a client and routes all future requests to the same backend server.

Figure: session-persistence-diagram.png

What to Observe

• First request → load balancer selects server

• Persistence record / cookie is created

• Subsequent requests → same server

• If server down, Load balancer assigns → New server

6. Real-World Example

E-commerce Scenario

Without Persistence

• Login → Server A

• Add to cart → Server B

• Cart is empty

With Persistence

• Login → Server A

• Add to cart → Server A

• Checkout works

7. Common Issues / Pitfalls

Session loss after failover

• Server crashes and session is lost

Persistence timeout too low

• If the user stays idle, the mapping expires

• Next request goes to a different server and session loss

Uneven load distribution

• One server gets too many sticky users

Cookie mismatch

• Application and load balancer cookie conflict

NetScaler Hands-on

8.1 Commands

# Create LB vServer
add lb vserver lb_vsrv_http HTTP 10.0.0.10 80

# Bind backend services
bind lb vserver lb_vsrv_http svc_server1
bind lb vserver lb_vsrv_http svc_server2

# Enable persistence
set lb vserver lb_vsrv_http -persistenceType COOKIEINSERT

# Verify configuration
show lb vserver lb_vsrv_http

Sample Output (Truncated)

lb_vsrv_http (10.0.0.10:80) - SSL Type: ADDRESS
State: UP
..
Persistence: COOKIEINSERT (version 0) Persistence Timeout: 2 min
..
1) svc_server1 - HTTP State: UP
       Persistence Cookie Value : NSC...

2) svc_server2 - HTTP State: UP
       Persistence Cookie Value : NSC...

Try it Yourself

Interactive Demo

**Best viewed on Laptop and bigger screens

Mini Lab

Objective

Validate session persistence behavior

Setup

• 2 backend servers:

  • Server1 returns "Server A"

  • Server2 returns "Server B"

• NetScaler load balancer in front

Steps

1. Send request

curl http://10.0.0.10

1. Observe response

Server A

1. Repeat multiple times

curl http://10.0.0.10

Expected Output

You should consistently see:

Server A

Key Observation

• Same backend server is hit every time

• Confirms persistence is working

8.3 Experiment

Change persistence type:

set lb vserver lb_vsrv_http -persistenceType SOURCEIP

Observe

• Behavior changes across clients

• Less reliable in NAT environments

9. Key Takeaways

• Session persistence keeps user experience consistent

• Cookie-based persistence is most reliable

• Persistence affects load distribution

• Always validate with real traffic

10. Conclusion

Session persistence is not optional — it is essential for user experience.

Without it:

• Users lose sessions

• Applications behave unpredictably

With it:

• Systems feel consistent

• Users trust your application

11. Series Continuity

Before this, we explored how requests are processed inside NetScaler.

Read here: https://blog.bgyani.co.in/inside-netscaler-understanding-client-request-flow

Imagine you have multiple backend servers behind a load balancer. Everything works fine... until one server crashes. Now:

• Users are still sent to that failed server

• Some requests succeed, others fail

• Your application feels "randomly broken"

From a user's perspective, this is worse than a full outage. This is exactly the problem health checks solve.

2. What Are Health Checks?

A health check is how a load balancer verifies whether a backend server is ready to handle traffic.

Instead of blindly forwarding requests, NetScaler:

• Continuously checks each server

• Marks it as UP or DOWN

• Sends traffic only to healthy servers

Think of it like a quick "status check" before assigning work.

3. Types of Health Checks

L3 Health Check - ICMP (Ping)

• Works at Network Layer (Layer 3)

• Uses ICMP (Ping) to check reachability

Key Points:

• Very fast: Ping request → Ping response.

• Useful for basic reachability.

• Does NOT validate application health

Note: A server can respond to ping even if the application is down.

L4 Health Checks - Basic Connectivity

• Works at Transport layer (Layer 4) e.g. TCP level.

• Checks: "Can I establish a connection?"

Key Points:

• Fast and Lightweight

• Cannot detect application issues

• Example: TCP handshake success

L7 Health Checks - Application-Level

• Works at Application Layer e.g. HTTP/HTTPS level

• Checks: "Is the application working correctly"

Key Points:

• Most reliable application status

• Detects real application failures

• Slightly more overhead

In most real-world scenarios, L7 checks are preferred. NetScaler ECV monitors not only check if the server is up, but also check if the requested content is present on the website. Example: HTTP GET /health → Expect 200 OK

4. How Health Checks Work Internally

Here's what happens inside NetScaler:

1. Periodic probes are sent (e.g. every 5 seconds)

2. Backend servers respond

3. Based on response:

• Success → marked UP

• Failure → marked DOWN

1. Traffic is routed to healthy servers

NetScaler also uses:

• Failure Threshold &rarr failures before marking DOWN (failureretries)

• Success Threshold &rarr successful checks before marking UP (successretries)

This prevents frequent UP/DOWN state changes (flapping).

Figure: netscaler-load-balancer-health-check-flow.png

5. Real-World Example

Let's take a simple e-commerce scenario:

• Server is reachable (ping works)

• TCP connection works

• But the checkout service is down

With L3 and L4 checks:

• Server still appears healthy

• Users face failures

With L7 checks:

• Checkout health fails

• NetScaler removes server from pool

6. Common Issues

Using Only Ping Checks

Server responds to ping, but application is down. Always combine with L7 checks.

Wrong Health Check Endpoint

Checking instead of health. Use a dedicated health endpoint.

Very Frequent Checks

Too many probes overload servers. Keep interval balanced (5-10 sec).

Ignoring Timeouts

Slow responses may be marked as healthy. Configure proper timeout.

7. NetScaler Commands (Quick Reference)

If you are working with NetScaler, these commands help verify health checks in real environments.

Check Service Status

show service --summary

Sample Output Truncated

Service Name   State    IP           Port   Protocol 
svc-web-1      UP       10.0.0.1     80     HTTP     
svc-web-2      DOWN     10.0.0.2     80     HTTP     

Check Bound Monitor

show service svc-web-1 

Sample Output Tuncated

Monitor Name: http-monitor
State: UP
Last Response: HTTP 200 OK 

Check Monitor Configuration

show lb monitor -summary

Sample Output Truncated

Name           State        Type
http-monitor   ENABLED     HTTP-ECV

Check Monitor Details

show lb monitor http-monitor

Sample Output Truncated

Name: http-monior TYPE: HTTP-ECV State: ENABLED
Interval: 5 sec  Retries: 3
Response timeout: 2 sec

Special Paramters:
Send String: "GET /health"
Receive String: "200"

Mini Lab: Try This Yourself

1. Run:

show service 

1. Stop service on one backend server

2. Run again:

show service 

Observe

• Server moves from UP → DOWN

4. Restart service → becomes UP again

Bonus Round:

• Use only Ping monitor

• Stop application

Server shows UP, but application is broken

Key learning: Reachability ≠ Application Health

What You Learned

• Health checks are continuous

• NetScaler dynamically adjusts traffic

• L3 and L4 checks are limited

• L7 checks provide real reliability

9. Conclusion

Health checks are one of the most critical components of load balancing.

They ensure:

• Only healthy servers receive traffic

• Failures are automatically isolated

• Users get a consistent experience

Without proper health checks, load balancing becomes unreliable.

Continue Learning

If you're new to this series, start here:

NetScaler Packet Flow Explained

Inside NetScaler: Client Request Flow

When a user opens a website or application, the request does not immediately reach the backend server. Instead, it first passes through an Application Delivery Controller (ADC) that manages how traffic is handled and distributed. In environments using Citrix NetScaler (Citrix ADC), every client request goes through several processing stages before reaching the application servers.

These stages include:

• Virtual IP (VIP)

• Load Balancing Virtual Server (LB vServer)

• Service Group

• Backend Servers

Understanding this request flow helps engineers:

• Troubleshoot production issues faster

• Design scalable architectures

• Understand how traffic moves through the ADC

In this article, we will walk through how a client request is processed inside NetScaler step by step.

Why Understanding Request Flow is Important

Many engineers configure load balancing successfully, but when issues occur in production, identifying the problem becomes difficult.

Understanding the request flow helps in several real world scenarios.

Faster Troubleshooting

If an application stops responding, the issue could be at multiple layers:

• DNS resolution issue

• VIP not reachable

• vServer misconfiguration

• Backend server down

• Health checks failing

Knowing the traffic flow helps quickly identify where the failure might be.

Real Production Scenarios

In real deployments, engineers often face:

• Intermittent application failures

• Slow response times

• Backend server instability

Understanding how NetScaler processes traffic helps isolate the root cause faster.

High Level Request Journey

Before diving deeper, let's first understand the simplified request path.

Client → VIP → LB vServer → Service Group → Backend Server

Step-by-Step Processing Inside NetScaler

Step 1: Client Sends Request

A user opens an application URL. Example: blog.bgyani.co.in DNS resolves the domain to the VIP configured on NetScaler. The request is sent to the NetScaler appliance. The client initiates a TCP handshake with the VIP.

Step 2: Traffic Hits the VIP

The VIP acts as the entry point for application traffic. At this stage NetScaler:

• Accepts the client connection and completes the TCP handshake (SSL handshake if HTTPS)

• Identifies which virtual server should handle the request

• Starts the internal packet processing You can think of the VIP as the front door of the application.

Step 3: NetScaler Identifies the vServer

Once traffic reaches the VIP, NetScaler maps it to a Load Balancing Virtual Server (LB vServer).

The vServer is responsible for:

• Managing the connection

• Applying policies

• Selecting backend servers

If the vServer is down, traffic will fail at this stage.

Step 4: Policy Evaluation

Before forwarding traffic, NetScaler evaluates configured policies such as :

• SSL processing

• Content switching

• Traffic policies

• Security policies

This is where NetScaler determines how the request should be handled.

Step 5: Backend Server Selection

Next, NetScaler selects a server from the Service Group.

It checks:

• Which servers are healthy

• Which load balancing method is configured

• Which server should receive the request

Common algorithms include:

• Round Robin

• Least Connection

• Least Response Time

Step 6: Health Check Verification

NetScaler never sends traffic blindly. The Monitor continuously probes backend servers (via ICMP, TCP or HTTP-ECV). If a monitor fails, the service is marked DOWN and NetScaler instantly bypasses it.

Step 7: Request Forwarded to Backend Server

After selecting a healthy server, NetScaler forwards the request to the backend server. The backend server processes the request and sends response back to the client through NetScaler. NetScaler replaces the Destination IP with the selected backend Server IP.

Note: Depending on your configuration(SNIP/MIP), the source IP might also be translated.

Request flow:

Client &rarr NetScaler &rarr Backend Server &rarr NetScaler &rarr Client

Components Involved in the Request Processing

VIP (Virtual IP)

The VIP is the public IP address that client connects to. It acts as the entry point for application traffic

Load Balancing Virtual Server

The vServer is responsible for:

• Handling client connections

• Applying policies

• Selecting backend servers

It is the core decision making component in NetScaler.

Service Group

A Service Group contains multiple backend servers that provide the same service. This enables:

• Traffic distribution

• Redundancy

• Application High availability

Backend Servers

These are the servers where the application runs. Examples:

• Web Servers

• Application Servers

• API Servers

Comparison of Core Components

NetScaler Request Processing Flow Diagram

Diagram: NetScaler-request-processing-flow-diagram.png

Quick Troubleshooting Checklist

If traffic is not reaching backend servers, check:

1. VIP reachable:

   • Can you ping the VIP/ is the firewall blocking the port.

2. vServer status

   • Is the status UP / if DOWN, are the bound services also down.

3. Service Group status

   • Is the status UP / if DOWN, are majority of bound services down.

4. Backend server health

   • Are backend servers UP/ if DOWN, are the servers reachable directly.

5. Health monitor status

   • Is the monitor bound/ Check the "Failure Retries" log.

6. Policy configuration

   • Is a "Responder/ rewrite" policy accidentally dropping the request.

This is a common troubleshooting approach used by engineers in production environments.

Key Takeaways

• NetScaler acts as the entry point for application traffic.

• Every request first reaches the VIP.

• The LB vServer processes and evaluates the request.

• NetScaler selects the backend server using the Load balancing logic.

• Health checks ensure traffic is not sent to failed servers.

• This architecture improves scalability and reliability.

Conclusion

Understanding how NetScaler processes client requests is essential for engineers working in networking and application delivery. Although the high level flow appears simple, NetScaler performs multiple checks and decisions to ensure traffic is handled efficiently. Once you understand this process, troubleshooting and architecture design become much easier.

Related Article in The Series

If you want to understand how NetScaler processes packets internally and how traffic moves through different processing stages inside the appliance, check out my earlier article:

NetScaler Packet Flow Explained

This article provides a deeper look into the internal packet processing of NetScaler.

In modern application architectures, traffic management plays a critical role in performance, availability, and scalability. Two popular solutions used by organizations are NetScaler (Citrix ADC) and Google Cloud Load Balancer (GCLB)

While both help distribute traffic efficiently, they are designed for different environments and architectures.

What is NetScaler

NetScaler is an Application Delivery Controller (ADC) commonly deployed in:

• On-premises datacenters

• Hybrid cloud environments

• Private cloud infrastructure

It provides advanced features like:

• Layer 4/ Layer 7 load balancing

• SSL offloading

• Web Application Firewall (WAF)

• Traffic optimization

• Application acceleration

One key characteristic of NetScaler is that traffic typically enters through VIP (Virtual IP) and is processed inside the appliance before reaching backend servers

What is Google Cloud Load Balancer

Google Cloud Load Balancer is a globally distributed load balancing service built on Google's infrastructure.

Key characteristics:

• Global Anycast IP

• Traffic enters the nearest Google Edge PoP

• Automatic scaling

• Integration with GCP services like GKE and Compute Engine

Unlike traditional ADC deployments, traffic is distributed across Google's global network before reaching backend services.

Architecture and Traffic Flow

The key difference between NetScaler and Google Load Balancer is where traffic is processed. NetScaler typically sits inside a datacenter and manages traffic using a Virtual IP (VIP) before forwarding requests to backend servers. Google Cloud Load Balancer operates on Google's global edge network. Traffic enters through an Anycast IP and is routed to the nearest Google edge location before reaching backend services. The diagram below shows how traffic flows in both architectures.

Figure: NetScaler-vs-Google-Loadbalancer-flow.png

NetScaler vs Google Cloud Load Balancer Traffic Flow

When to Use NetScaler

• Applications run in on-prem datacenters

• Advanced ADC features are required

• Hybrid deployments are in place

• Fine-grained traffic control is needed

When to Use Google Cloud Load Balancer

Google Cloud Load Balancer is ideal when:

• Applications run in GCP

• Global traffic distribution is required (NetScaler also has feature GSLB)

• Auto scaling is important

• You want a fully managed service

Real World Deployment Example

In many enterprise environments, NetScaler and Google Cloud Load Balancer work together.

A common architecture looks like this: Users -> Google Cloud Load Balancer -> Hybrid Connectivity(VPN/Interconnect) -> NetScaler -> Backend Applications

In this model:

• Google Cloud Load Balancer handles global traffic distribution

• NetScaler manages application delivery and traffic optimization

• Backend applications may run in on-prem infrastructure

This approach is common during:

• Cloud migration

• Hybrid deployments

• Application modernization

Quick Comparison Summary

Conclusion

Both NetScaler and Google Cloud Load Balancer are powerful solutions designed for different architectures. NetScaler excels in application delivery within data centers, while Google Cloud Load Balancer is built for global-scale traffic distribution. Understanding how traffic flows through each solution helps engineers design better and more scalable systems.

Series: Application Delivery & Traffic Engineering

NetScaler Packet Flow Explained

Application Delivery Controllers (ADCs) are critical components in modern application infrastructure. NetScaler processes thousands of client connections and efficiently distributes traffic across backend servers.

Understanding NetScaler packet flow is essential for network engineers and administrators. It helps troubleshoot connectivity issues, debug load balancing problems, and optimize application delivery performance.

In this article, we will walk through how a packet flows through NetScaler from the client request to the backend server response.

Table of Contents

• NetScaler Architecture Overview

• Packet Flow Steps

• Useful NetScaler CLI Commands

• Common Packet Flow Issues

• Conclusion

NetScaler Architecture Overview

The following diagram illustrates how client traffic flows through NetScaler before reaching backend application servers.

Figure 1: NetScaler Packet Flow Architecture

Packet Flow Steps

The packet flow in NetScaler follows a structured path before reaching the backend application servers.

1. Client Request Initiation

   The client initiates a request to the NetScaler Virtual IP (VIP) exposed to the internet.

2. Traffic Reaches NetScaler

   The request arrives at the NetScaler appliance where it is processed by the configured Load Balancing Virtual Server.

3. Load Balancing Decision

   NetScaler evaluates the load balancing algorithm and selects an appropriate backend service.

4. Forwarding Request to Backend

   The request is forwarded to one of the backend servers associated with the service.

5. Server Response

   The backend server processes the request and sends the response back through NetScaler to the client.

Useful NetScaler CLI Commands

The following CLI commands can be used to verify the configuration and troubleshoot packet flow in NetScaler.

Check Load Balancing Virtual Servers

show lb vserver

This command displays the configured load balancing virtual servers and their current state.

Check Backend Services

show service

This command verifies whether the backend services are up or down.

Check Active Connections

show ns connectiontable

This command shows active client connections passing through NetScaler.

Check Running Configuration

show ns runningConfig

Common Packet Flow Issues

503 Service Unavailable

This occurs when backend services are down or not responding.

Persistence Issues

Improper persistence configuration may cause sessions to switch between backend servers.

SSL Handshake Failures

Incorrect SSL certificates or cipher configurations can cause connection failures.

Conclusion

Understanding NetScaler packet flow is fundamental for network engineers and administrators working with application delivery infrastructure.

By understanding how traffic moves from the client through the NetScaler Virtual IP, Load Balancing Virtual Server, and backend services, engineers can troubleshoot issues more effectively and optimize application delivery.

In this article, we explored the basic packet flow architecture, useful CLI commands, and common troubleshooting scenarios related to NetScaler.

A solid understanding of packet flow helps engineers quickly diagnose issues and maintain reliable application delivery environments.

About the Author

I am a Technical Account Manager working extensively with NetScaler (Citrix ADC) technologies. I enjoy sharing knowledge around application delivery, networking, and cloud infrastructure.

Through BGyani, I aim to simplify complex networking concepts and share practical troubleshooting knowledge with the engineering community.