CCA-AppDS Traffic Management (1Y0-241) cheat sheet

NetScaler ADC architecture separates the data plane (NetScaler Packet Processing, NSPPE) from the control plane; NSPPE handles per-packet forwarding decisions, while the management CPU runs the configuration and CLI/API.

Request switching means the ADC terminates client TCP connections and creates independent server-side connections; this enables content inspection, persistence, and connection multiplexing.

A virtual server (vserver) is the client-facing listener defined by IP address, port, and protocol; a service is the server-side representation of a backend; a service group bundles multiple services for uniform monitor and member management.

Traffic flow: client -> vserver -> load balancing method selects a service -> NetScaler proxies the request to the backend and returns the response through the same vserver.

MAC-based forwarding (MBF) is the default mode; use USIP or USNIP when backends must see the real client IP, and enable useProxyPort or net profile settings when SNIP routing is asymmetric.

Net profiles bind a source IP (SNIP) to a service for backend-originated traffic; without a net profile the ADC picks a SNIP by route lookup.

The NSIP is the management address; the SNIP is used for server-side traffic; a VIP is the vserver address. Do not use the NSIP for backend traffic in production designs.

Redundancy modes: standalone, high availability (active/standby), and cluster (active/active with n+1). The mode determines how configuration is synchronized and how failover is triggered.

Least Connection selects the service with the fewest active connections; it is the default and best for uneven backend capacity.

Round Robin rotates requests evenly across services regardless of load; Least Response Time picks the service with the lowest measured response time plus active connections.

Least Bandwidth selects the service with the least traffic in Mbps over a defined interval; custom load uses SNMP-based weights.

Source IP hash maps the client IP to a service deterministically; destination IP hash does the same for the destination.

Token method distributes requests in proportion to configured weights; use it when backends have different capacities.

Monitors run on the ADC at a configured interval; a service is UP only when its bound monitors succeed, and DOWN after the configured retries are exhausted.

Monitor types include TCP, HTTP, HTTP-ECV (expects a specific response body), TCP-ECV, PING, and scriptable monitors; bind monitors to services or service groups.

A service group with a member port and server list simplifies scaling; bind one monitor to the group instead of per-member monitors.

Persistence and load balancing interact: a persistent client bypasses the load balancing method until the persistence entry expires.

Content switching uses a content switching vserver plus policies to route requests to target load balancing vservers based on URL, host, header, or other request attributes.

A content switching policy is an expression (for example HTTP.REQ.HOSTNAME.EQ("api.example.com")) bound to a target vserver with a priority; the lowest numeric priority wins.

Default syntax (advanced expressions) is the current policy language; classic expressions are legacy and should be avoided in new configurations.

Policies can also act on responses (responder policies) to rewrite, redirect, or drop traffic; rewrite policies modify requests or responses in flight.

Action types: forward to a target vserver (content switching), respond with a redirect or static content (responder), or rewrite headers/URLs.

Policy evaluation order: priority ascending, then the first matching policy applies unless a goto expression or NEXT is used.

Use content switching for multi-tenant hosting (host-based routing) and for API versioning (path-based routing) on a single VIP.

Bind a fallback/default target vserver so unmatched requests still reach a backend instead of returning an error.

Test with the policy evaluation tool (nstrace or show policy stats) before production; a misordered policy silently sends traffic to the wrong pool.

SSL offloading terminates TLS at the ADC; the backend receives clear HTTP, reducing CPU load on servers. SSL bridging re-encrypts to the backend for end-to-end encryption.

Bind a server certificate and its private key to the vserver; the certificate must match the vserver's hostname and be issued by a trusted CA to avoid client warnings.

Certificate chains: the ADC sends the leaf plus intermediate certificates; install the full chain or clients will fail to validate.

Use SNI (server name indication) to serve multiple certificates on one VIP; enable SNI on the SSL vserver and bind multiple cert-key pairs.

SSL profiles control protocol versions, ciphers, and session reuse; modern profiles disable TLS 1.0/1.1 and weak ciphers.

OCSP stapling and CRL checking validate revocation; configure them when clients require revocation checks.

Certificate renewal: replace the cert-key pair and update the binding; the ADC reloads without dropping established connections in most cases.

Backend SSL: enable SSL on the service and bind a service certificate; use SSL profiles on the service for the backend handshake.

Persistence keeps a client bound to the same backend for the duration of a session; the persistence type determines the key (source IP, cookie, SSL session ID, or custom).

Source IP persistence uses the client IP as the key; it breaks when clients share a NAT address, so prefer cookie persistence for HTTP.

Cookie persistence inserts a cookie naming the selected service; the client returns the cookie and the ADC honors the binding.

Persistence timeout sets how long an idle entry survives; a value of 0 means the entry persists until the session ends, which can pin traffic indefinitely.

Persistence can be configured on the vserver (global) or per service; vserver-level persistence applies to all bound services.

Backup persistence (fallback) applies when the primary persistence method cannot resolve a service, for example after a cookie is missing.

Session management also covers connection keep-alive and HTTP session reuse; tune keep-alive to reduce backend connection churn.

Clear persistence entries (flush cache) after a backend change so clients rebind to healthy services.

GSLB answers DNS queries with the best site's IP based on configured methods (round robin, static proximity, or active-active/active-passive metrics).

GSLB sites contain local and remote GSLB services; the local site's services are the ones the local ADC can health-check directly.

GSLB monitors health-check each site; a site marked DOWN is removed from DNS answers.

Static proximity uses a location database (or GeoIP) to return the site closest to the client's resolver.

DNS delegation: point the domain's NS records at the GSLB vserver, or use a CNAME from the authoritative DNS to the GSLB name.

GSLB persistence keeps a client's DNS answer stable for a configured time to avoid flapping between sites.

The GSLB vserver is a DNS-type vserver; it listens on port 53 and returns A/AAAA records.

Active-passive GSLB uses a primary site with a backup site; failover occurs when the primary's monitors fail.

HA pairs: one node is primary (active) and one is secondary (standby); the primary owns the VIPs and processes traffic.

Failover triggers include heartbeat loss, monitor failure of the peer, and forced failover; the secondary takes over the VIPs.

HA synchronization copies configuration and certificates to the peer; run 'force sync' after changes to avoid split configuration.

HA heartbeat uses the NSIP interfaces; a dedicated HA interface or VLAN reduces false failovers.

Monitoring tools: dashboard, 'show lb vserver', 'show service', 'stat lb vserver', and 'stat service' for live counters.

nstrace captures packets at the ADC; use it to verify the vserver receives traffic and the service responds.

Common troubleshooting order: verify vserver state, service state, monitor results, persistence, and routing (SNIP to backend).

AppFlow and analytics export traffic data to external collectors for per-application visibility.

Cluster mode: n+1 redundancy, with configuration coordinated by the cluster IP; use 'show cluster node' to check member health.