Citrix CCE-N cheat sheet

One-arm (single NIC) mode places the NSIP and VIP on the same subnet; the ADC forwards client traffic back through the same interface, so upstream devices must route return traffic to the ADC MAC or the deployment breaks asymmetric paths.

Two-arm (multi-NIC) mode separates client-facing and server-facing subnets; the ADC must own default routes for each side, and SNIP addresses must exist in the server subnet for USIP or source-NAT toward backends.

MAC-based forwarding (MBF) disables L3 lookup for return traffic; enable it when the ADC sits in a one-arm topology and the default gateway is not the ADC, otherwise return packets bypass the appliance.

A NetScaler Gateway or content-switching vServer uses a single VIP; a load-balancing vServer requires a service or service group binding before it can pass traffic, and the vServer protocol/port must match the bound services.

Capacity planning uses throughput (Gbps), SSL transactions per second, and concurrent connections; the platform SKU caps each independently, so the binding constraint is the lowest of the three for the target traffic profile.

Citrix ADC CPX is a container/VM form factor for east-west and limited ingress use; it lacks dedicated SSL hardware, so SSL TPS is bounded by CPU and must be sized accordingly.

Admin partitions isolate objects, policies, and RBAC; each partition has its own NSIP alias, and global objects are visible read-only from within a partition.

High-availability pairs share a configuration and a floating VIP; the primary node owns the VIP MAC, and the secondary syncs configuration and state via the HA heartbeats on the dedicated HA interface.

Load-balancing methods: round robin ignores load; least connection picks the service with fewest active connections; least bandwidth uses throughput; response time uses measured latency; hash-based (source IP, URL) provides session persistence without a persistence table.

Persistence options: SOURCEIP uses the client IP with a configurable netmask and timeout; COOKIE inserts or uses a cookie; SSLSESSIONID ties to the TLS session; persistence must be configured on the vServer and matched by the service group.

Monitors determine service state: a service is UP only when its bound monitor succeeds; default monitors exist per protocol, and a custom monitor can set interval, retries, and a response-code or content check.

Content switching selects a target LB vServer by policy evaluation order; the default target handles unmatched requests, and policies can match on host, URL path, header, or source IP.

Rewrite and responder policies differ: rewrite modifies requests/responses in flight; responder can short-circuit with a redirect or a fixed response without contacting a backend.

SSL offload terminates TLS on the ADC; SSL bridge passes encrypted traffic through; SSL backend re-encrypts to the server, and each mode changes where certificates and cipher policy apply.

GSLB distributes across sites using a metric set (connection proxy, site persistence, and load); the MEP protocol exchanges site health over port 3009 (or 3011 with secure MEP), and DNS-based GSLB answers with the selected site's VIP.

IPv6 and NAT64: the ADC can terminate IPv6 client traffic and NAT64 to IPv4 backends; DNS64 synthesis is required on the resolver side for client-initiated connections to IPv4-only names.

Authentication vServers bind authentication policies in priority order; the first matching policy runs, and the policy action points to an authentication server object (LDAP, RADIUS, SAML, Kerberos, certificate).

nFactor flows chain factors: a policy label holds the next set of policies, and a login schema controls the fields presented; the flow ends when a policy action has no next factor and sets the session.

AAA session policies govern authorization, including SSO to backend apps; SSO can be form-based, basic, NTLM, or SAML, and the session profile carries the SSO credential.

LDAP authentication requires a bind DN and password for the search, a base DN, and a search filter or attribute mapping for group extraction; group extraction drives authorization and session policy selection.

Client certificate authentication uses a CERT authentication policy bound to the SSL vServer; the ADC validates the chain against a CA cert and can map the subject to a user name via a certificate profile.

AppFW profiles apply security checks (SQL injection, XSS, buffer overflow, cookie consistency, CSRF) and a signature set; the profile must be bound to the vServer, and a start URL or learned policy defines allowed URLs.

Rate limiting and bot management: a bot policy classifies traffic and applies a mitigation action; a rate-limit policy caps requests per client and can log or drop, protecting login endpoints from credential stuffing.

SSL profiles define protocol versions and ciphers; front-end and back-end profiles are set separately, and deprecated protocols (TLS 1.0/1.1) should be disabled on both sides for compliance.

HA failover triggers: peer heartbeat loss, forced failover, and monitored-interface failure when HA monitoring is enabled; the secondary takes the VIPs and the primary's MAC addresses.

HA synchronization is not automatic for all objects; a forced sync or sync ha files replicates configuration, and SSL certificates/keys must be synced separately via the HA sync setting.

Stateful failover (connection mirroring) preserves established connections; without it, sessions are dropped on failover, and persistence entries are lost unless mirrored.

AppFlow and Insight: AppFlow exports traffic records to Citrix ADM; the ADC needs an ADM IP, an AppFlow policy, and a collector, and the action must be bound to the vServer.

TCP optimization profiles adjust window scaling, buffer sizes, and SACK; enabling TCP buffering and Nagle settings changes latency versus throughput, and the profile must be bound to the vServer or service.

Troubleshooting order: check vServer state, then service state and monitor results, then persistence and policy hits; show lb vserver, show service, and show policy expose each layer.

Packet capture uses nstrace with a filter (e.g., IP or port) and produces a .cap file for Wireshark; show techsupport bundles logs, config, and counters for Citrix support.

Common failure: a vServer DOWN with services UP usually means the monitor is failing or the port is wrong; a vServer UP with no traffic usually means the VIP is not reachable or a policy is dropping.

SD-WAN consists of a Management/Master Control Node (MCN) and branch appliances; the MCN distributes configuration and coordinates the virtual WAN, and branches register to the MCN via the management IP.

Virtual paths are logical tunnels over physical links (MPLS, internet, LTE); each path has a configured bandwidth and a measured quality (latency, loss, jitter) used by path selection.

Deployment modes: inline (appliance in the data path), one-arm (out-of-path with policy routing), and virtual/VPX; inline is required for full QoS and path control, one-arm is used for incremental migration.

The SD-WAN Center and MCN provide topology, site, and path views; the SD-WAN Center collects statistics and is separate from the MCN, so both need to be reachable for full visibility.

A virtual WAN is defined by a network map and a set of sites; each site has a WAN link set and a LAN subnet, and the MCN pushes the site configuration to the branch appliance.

Zero-touch deployment uses a bootstrap configuration (or DHCP option) to reach the MCN; the branch downloads its full configuration on first boot, so the MCN must be reachable from the branch WAN.

SD-WAN can host a Citrix ADC VPX or a virtualized service on the branch appliance; the service is attached to a virtual path and benefits from path selection and QoS.

Routing: SD-WAN supports static routes, OSPF, and BGP; routes can be advertised into the virtual WAN, and the MCN can redistribute between sites, so a branch can reach a remote LAN via the virtual path.

Path selection policy: per-application rules choose the best path by latency, loss, jitter, or a weighted metric; a rule can prefer one path, allow failover, or load-balance across paths.

QoS classes (e.g., real-time, interactive, bulk) map applications to priority, bandwidth guarantee, and drop policy; the sum of guarantees must not exceed the link bandwidth or the class is oversubscribed.

Application classification uses ports, IP, and DPI signatures; a custom application object can match a port range or a signature, and the classification feeds the QoS and path-selection policy.

WAN optimization features include deduplication, compression, and TCP acceleration; these are enabled per virtual path and require the same feature on both ends of the path.

Multi-path forwarding: packets for a flow can be spread across paths with per-packet or per-flow selection; per-flow preserves ordering, per-packet improves utilization but can reorder.

Bandwidth measurement: the appliance measures available bandwidth per link and uses it for admission and QoS; a link with a configured bandwidth lower than actual throttles QoS guarantees.

SD-WAN HA: a branch pair runs active/standby with a shared virtual IP; the standby syncs state and takes over on heartbeat loss, and the pair must share the same site configuration from the MCN.

Security: IPsec tunnels protect virtual paths; the appliance supports firewall zones and ACLs between LAN and WAN, and a default deny should be applied to the WAN zone.

The MCN itself should be deployed in an HA pair; a single MCN is a management-plane single point of failure, and branches continue forwarding but cannot receive configuration updates.

Troubleshooting path issues: check link status and virtual-path state, then measured latency/loss, then the path-selection policy hit; show commands on the branch expose per-path statistics.

Packet loss on a virtual path with a healthy physical link usually indicates an MTU or tunnel problem; verify the MTU on both ends and the tunnel overhead.

Configuration drift between MCN and branch is resolved by re-pushing the site configuration; a branch that shows out-of-sync has not applied the latest MCN revision.

Logs and alarms: the MCN collects events from branches; syslog and SNMP traps can be forwarded, and an alarm on path quality should be correlated with the QoS class and application mapping.

Citrix Gateway (ADC) fronts Workspace: the Gateway vServer with an authentication vServer and a session policy provides the external access path to StoreFront and published apps.

Workspace app enumeration goes through StoreFront, which queries the Delivery Controller; the Gateway must allow the StoreFront and XML traffic, and the session policy must permit the required protocols.

Citrix ADM provides analytics: it collects AppFlow from ADC and SD-WAN telemetry, and the ADC/SD-WAN must be registered to ADM with a valid license for the analytics features.

AppFlow records include client IP, URL, latency, and response time; ADM aggregates them into dashboards, and a missing AppFlow action or collector binding yields no data.

SD-WAN Center and ADM integration gives a combined view of WAN path quality and application performance; the SD-WAN appliance must be registered and the telemetry export enabled.

HDX Insight requires AppFlow on the Gateway and the ICA traffic; the ADC must see the ICA stream, so SSL offload or a policy must expose the ICA data for AppFlow.

Licensing: ADC analytics and SD-WAN orchestration are licensed separately; an expired ADM license stops new data collection, and the ADC continues to forward traffic.