Citrix CCA-N cheat sheet

ADC data-plane throughput is bounded by the packet engine (NSPPE) cores assigned to a traffic domain; NetScaler MPX throughput scales with the number of active packet engines, each pinned to a CPU core.

A NetScaler SDX/virtual appliance uses VLANs and NetScaler IP (NSIP) as the management address; each ADC entity (VIP, SNIP, NSIP) must be reachable per routing and PBR rules.

The NSIP is the management address and must reside in the management VLAN; it is not used for load-balanced traffic unless explicitly configured.

Citrix ADC networking is L2/L3 transparent: it can operate as a one-arm (single NIC) or two-arm (multiple NICs) deployment; one-arm requires MAC-based forwarding or PBR for return traffic symmetry.

The ADC uses a default route plus policy-based routing (PBR) to steer traffic; PBR rules are evaluated in priority order and can select a next hop by source IP, destination IP, or protocol.

Traffic domains partition the ADC into isolated logical instances sharing hardware; each domain has its own NSIP, SNIPs, VIPs, and routing table, and cannot see other domains' entities.

The ADC feature set is enabled per-appliance (basic, advanced, enterprise); features not enabled in the license are unavailable regardless of configuration.

ADC high-availability and clustering use the NSIP for heartbeat and the Sync VLAN for config and session synchronization; keep the NSIP reachable on both nodes for management.

NetScaler packet flow order: ingress NIC -> packet engine -> L2/L3 lookup -> feature processing (ACL, LB, SSL, etc.) -> egress; ACLs are applied early, so a deny ACL drops traffic before load balancing.

In active/active HA, both nodes process traffic; the primary node owns the VIPs and the secondary takes over on failover; in active/standby only the primary processes traffic.

HA failover triggers on heartbeat loss (default 3 seconds, configurable), interface failure, or forced failover; a failover also flushes the connection table unless session synchronization is enabled.

HA synchronization includes config (via the Sync VLAN or NSIP) and, optionally, persistent sessions and connection state; session sync requires 'sync sessions' to be enabled on both nodes.

A cluster (n-way) uses a cluster IP (CLIP) and multiple nodes with a striped configuration; traffic distribution is by flow, and cluster backplane (CBP) handles inter-node traffic.

INC (independent network computing) mode allows different software builds on cluster nodes; it is used for staged upgrades but disables some cluster-wide features.

In a two-arm deployment, the ADC has separate client-facing and server-facing interfaces; in one-arm, both directions use the same interface and MAC-based forwarding is required.

The ADC supports HA pair with both nodes in the same subnet; the NSIP of each node must be unique and reachable, and the HA heartbeat uses the NSIP and the Sync VLAN.

Graceful shutdown and 'force failover' commands are used for maintenance; a forced failover makes the secondary primary without waiting for heartbeat timeout.

Transparent mode (one-arm) can use MAC-based forwarding (MBF) so return traffic goes to the ADC; otherwise return traffic bypasses the ADC and breaks the connection.

A load-balancing vServer binds a VIP:port to a protocol and a set of services or service groups; the default LB method is round robin, and least connection is a common alternative.

Monitors define health checks; a service is UP only when its bound monitor succeeds; monitor intervals and retries determine failover speed and false-positive risk.

Persistence (sticky) methods: source IP, cookie, SSL session ID, and rule-based; cookie persistence inserts or rewrites the HTTP cookie so subsequent requests stick to the same backend.

The LB method 'least connection' picks the service with the fewest active connections; 'least response time' also factors in server response time, and 'least bandwidth' uses throughput.

Content switching (CS) vServers route by policy to target LB vServers; CS policies use expressions (e.g., HTTP host, URL) and are evaluated in priority order.

A backup vServer handles traffic when all services in the primary vServer are DOWN; a redirect URL can send clients to a maintenance page instead.

Service groups reduce configuration by binding many services to one vServer; group members share monitor bindings, and member state is managed per service.

SSL offload on an LB vServer terminates TLS at the ADC; the backend can be plain HTTP, and the ADC can re-encrypt to the backend if configured.

Connection multiplexing (HTTP keep-alive reuse) reduces backend connection churn; disabling it can be required for backends that do not support persistent connections.

SSL offload terminates TLS at the ADC (front-end) and optionally re-encrypts to the backend (back-end); the ADC holds the server certificate and private key in its certificate store.

A certificate and its private key must be linked before binding to an SSL vServer; the link operation associates the cert-key pair, and an unlinked key causes the bind to fail.

Certificate chains must include intermediate CAs; the ADC sends the full chain if the intermediate certificates are linked and bound, otherwise clients see an incomplete chain.

SSL profiles control protocol versions, ciphers, and TLS settings; binding a profile to an SSL vServer overrides the vServer's default SSL parameters.

SNI (Server Name Indication) allows multiple certificates on one VIP:port; the ADC selects the certificate by the client's SNI hostname, so each hostname needs its own cert-key pair.

OCSP stapling and CRL checks validate revocation; OCSP stapling lets the ADC present a signed revocation response, avoiding a client-side OCSP lookup.

Back-end SSL (re-encryption) requires a separate SSL service with the backend's certificate validation; 'sslProfile' and 'serverAuth' settings control backend trust.

Cipher suite order and TLS version are configured in the SSL profile; disabling TLS 1.0/1.1 and weak ciphers is a common hardening step for PCI-DSS.

Certificate renewal: replace the cert-key pair, relink, and rebind; a stale binding to a removed certificate causes handshake failures.

GSLB distributes DNS answers across sites; the GSLB vServer (a DNS-based vServer) selects a site by metric and returns that site's IP address.

GSLB methods: static proximity (client subnet to site), round robin, least connection, and least response time; static proximity uses a location database of client subnets.

A GSLB site contains local and remote GSLB services; local services are monitored locally, and remote sites are reached via site-to-site RPC on port 3009 (default).

GSLB persistence keeps a client on the same site for a configured TTL; without persistence, DNS answers can change between queries and break sessions.

Active-active GSLB returns the closest healthy site; active-passive GSLB returns the passive site only when the active site's services are DOWN.

The GSLB domain (FQDN) is configured on the GSLB vServer; the ADC answers DNS queries for that FQDN and uses the configured method to pick a site.

GSLB metrics exchange between sites via the GSLB protocol (RPC); firewall rules must allow TCP 3009 between site NSIPs, and the RPC password must match.

DNS delegation: the parent zone must delegate the GSLB FQDN to the ADC's GSLB vServer IP, or clients query the ADC directly as their DNS server.

GSLB service state is determined by monitors bound to the service; a site with all services DOWN is excluded from answers unless it is the only site.

Authentication vServers front-end the login flow; they bind authentication policies that reference an authentication action (LDAP, RADIUS, SAML, certificate, or local).

Authentication policy evaluation: the policy expression selects the action, and the resulting session carries the user identity to the LB vServer via SSO (form-based, basic, or cookie-based).

Authorization (AAA) uses authorization policies to allow or deny a user after authentication; a default deny policy is common for least-privilege access.

LDAP authentication actions specify the server, base DN, bind DN, and login attribute; the ADC binds to LDAP to validate credentials and can retrieve group membership.

SAML SSO: the ADC acts as SAML SP or IdP; the assertion is validated against the IdP certificate, and clock skew or expired assertions cause login failures.

Client certificate authentication uses the SSL vServer's client certificate settings; the ADC validates the client cert against a CA and can map the cert subject to a user.

Authorization can be enforced by responder policies (e.g., block by URL, geo, or header) and by app firewall (AppFW) profiles; AppFW inspects requests for SQLi, XSS, and buffer overflow.

Rate limiting and bot management use responder or bot policies; a rate-limit policy can drop or redirect traffic exceeding a threshold per client.

AAA session timeout and single sign-on domain settings determine how long the authenticated session persists and which domains share the cookie.

show lb vserver <name> displays vServer state, bound services, and hit counts; show service <name> shows per-service state and monitor results.

stat lb vserver <name> and stat service <name> show current connections, request rate, and bytes; use them to identify a saturated backend.

show monitor <name> and show service <name> reveal monitor failures; a service in DOWN state with a passing monitor usually indicates a routing or firewall issue.

nstrace captures packets on the ADC; the capture can be filtered by IP, port, or VLAN, and the resulting file can be decoded with Wireshark.

show techsupport collects logs, config, and stats into a bundle for support; it is the standard artifact for escalation.

The ADC dashboard and stat system show CPU, memory, and packet engine utilization; high NSPPE utilization indicates a data-plane bottleneck.

Connection table exhaustion shows as 'Max connections reached' or dropped new connections; increase the connection limit or add packet engines.

ping and traceroute from the ADC (via the NSIP) test reachability; use trace route in the CLI, not the shell, to respect the routing table.

Optimization: enable HTTP compression and caching for static content, tune TCP profiles for high-latency clients, and enable keep-alive to reduce backend churn.