# Citrix NetScaler HA & Clustering — Failover, Sync & Cluster Modes Source: https://ai.techclick.in/blog_citrix_netscaler_high_availability_clustering Markdown: https://ai.techclick.in/blog_citrix_netscaler_high_availability_clustering.md Publisher: Techclick Infosec Pvt Ltd Master Citrix NetScaler ADC high availability in 2026: active-passive HA pairs, failover triggers, sync and propagation, INC mode, and striped versus spotted clustering — with troubleshooting steps for real production issues. Citrix NetScaler HA & Clustering — Failover, Sync & Cluster Modes student learning map A visual study map for Citrix NetScaler HA & Clustering — Failover, Sync & Cluster Modes showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Citrix NetScaler HA & Clustering — Failover,... Citrix · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① HA pair basics — active-passive,... 4. Practice ② Sync & propagation — and... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most people treat NetScaler HA as 'just tick the box and the backup node is ready'. That mental model breaks under exam pressure — and in production at 2 a.m. HA is a carefully choreographed system: a heartbeat channel, an incarnation counter, a floating IP handoff via gratuitous ARP, and a sync-vs-propagation split that confuses almost every first-time candidate. Getting those mechanics right — and knowing when INC mode changes all the rules — is what separates a real deployment from a lucky one. ## ① HA pair basics — active-passive, heartbeat and failover A NetScaler HA pair is always active-passive : the primary node handles all client traffic while the secondary stays in standby, continuously monitoring the primary via heartbeat messages sent over a dedicated link (and optionally over the management network). A failover is triggered when the secondary stops receiving heartbeats for the configured dead-interval (default 3 seconds), or when a route monitor , interface monitor , or VLAN monitor on the primary reports a critical failure. Manual failover is also possible via force failover . On failover the new primary sends a gratuitous ARP (GARP) for every floating IP (MIPs, VIPs, SNIPs) so upstream routers and switches update their ARP tables and route traffic to the new primary immediately. ### What stays on the nodes vs what floats Each node has its own NSIP (management IP — never moves). The MIP, SNIP and VIP are floating and are owned by whichever node is primary. This split is essential for understanding why the secondary can be managed independently even during normal operation. Figure 1 — HA failover sequence — heartbeat to GARP The secondary detects a missed heartbeat, waits the dead-interval, promotes itself, then sends GARPs so clients continue without manual intervention. - HA failover sequence — heartbeat to GARP Heartbeat sent primary to secondary Miss detected dead-interval expires Self-promotion secondary → primary GARP sent floating IPs claimed Traffic resumes on new primary The secondary detects a missed heartbeat, waits the dead-interval, promotes itself, then sends GARPs so clients continue without manual intervention. Quick check · Q1 of 10 · Understand A NetScaler secondary node decides to fail over. What does it send immediately after promoting itself to primary? a) A sync request to copy ns.conf from the old primary b) A gratuitous ARP for every floating IP so switches and routers update c) An SNMP trap to the management server only d) A route-monitor probe to the default gateway Correct: b. After self-promotion, the new primary sends a GARP for each floating IP (MIPs, VIPs, SNIPs). This forces upstream switches to update their ARP tables so client traffic is directed to the new primary without any manual intervention. 👉 So far: NetScaler HA = active-passive pair. Primary handles traffic; secondary monitors via heartbeat. On failover the new primary claims floating IPs with a GARP. NSIPs never float. ## ② Sync & propagation — and when INC mode changes the rules NetScaler keeps the secondary ready through two separate mechanisms. Synchronisation copies the primary's full ns.conf to the secondary — triggered on startup, after a manual sync HA files , or when the incarnation number of the primary is higher than the secondary. Propagation is different: it pushes individual CLI commands to the secondary in real time as they are entered on the primary, so the secondary's running config stays current without a full file copy. Both sync and propagation are enabled by default . They are temporarily disabled during a sync to prevent conflicting commands. The sync log lives in /var/nslog/ha.log . ### INC (Independent Network Configuration) mode INC mode is needed when the two HA nodes are in different subnets — a common pattern for geographically separated data centres. In INC mode: the nodes do not share floating SNIPs (each node keeps its own subnet IPs), gratuitous ARPs are not sent by the new primary (because the L2 domain is not shared), and DNS or GSLB must handle the client redirect after failover. Certain configurations — notably SNIP addresses — are neither synced nor propagated in INC mode, which is the number-one exam trap. Figure 2 — Sync vs propagation — two different jobs Sync and propagation are complementary: sync handles full-file recovery; propagation keeps the running config current in real time. Sync vs propagation — two different jobs Synchronisation Copies full ns.conf to secondary Triggered by incarnation mismatch Runs at startup or on demand Also syncs SSL certs and files Propagation Pushes live CLI commands Real-time, command by command Keeps running config current Disabled during a sync run Sync and propagation are complementary: sync handles full-file recovery; propagation keeps the running config current in real time. 💓 Heartbeat tap to flip Periodic health-check packets sent between HA nodes (default every 200 ms). The secondary initiates failover if the primary misses enough heartbeats within the dead-interval (default 3 s). 🔄 Sync vs Propagation tap to flip Sync copies the full ns.conf (triggered by incarnation mismatch or restart). Propagation pushes individual CLI commands in real time. Both are on by default; sync pauses propagation temporarily. 🌐 INC Mode tap to flip Independent Network Configuration — used when HA nodes are in different subnets. No shared floating SNIPs; no GARPs after failover. DNS or GSLB must redirect clients. SNIPs are NOT synced or propagated in INC mode. 🕸️ Striped vs Spotted tap to flip Striped config is active on all cluster nodes (traffic distributed). Spotted config is bound to a single-node node group (one node handles that workload). Partially striped sits between. Use spotted SNIPs to avoid ARP flux. Never configure the secondary directly Any command you run on the secondary's NSIP directly (not via propagation from the primary) will be overwritten at the next sync. Worse, conflicting commands can break propagation entirely. Always configure via the primary — or via the CLIP in a cluster. Quick check · Q2 of 10 · Remember Which HA mechanism copies individual CLI commands to the secondary in real time? a) Synchronisation — copies the full ns.conf b) The incarnation counter — triggers config checks c) INC mode handshake — bridges subnets d) Propagation — pushes live CLI commands Correct: d. Propagation pushes each CLI command entered on the primary to the secondary as it is typed, keeping the running config current in real time. Synchronisation copies the full ns.conf file and is triggered by an incarnation-number mismatch or a manual sync. 👉 So far: Sync copies the full ns.conf (incarnation-triggered). Propagation pushes live commands in real time. INC mode = different subnets, no floating SNIPs, no GARPs — DNS or GSLB redirects clients instead. ## ③ NetScaler clustering — striped, partially striped and spotted A NetScaler cluster extends the active-active availability model to up to 32 nodes. A single CLIP (Cluster IP) is used to configure and manage the whole cluster, and one node acts as the configuration coordinator (CCO) , propagating changes to all other nodes. Configurations in a cluster are classified by how many nodes they are active on. A striped configuration is active on all nodes — traffic is distributed across the cluster using the striped SNIP or VIP. A spotted configuration is bound to a node group containing a single node, so only that one node handles that workload. A partially striped configuration is bound to a node group with more than one node — a subset of the cluster. ### When to use spotted vs striped Use striped when traffic can be handled by any node (most load-balanced VIPs). Use spotted for workloads that require locality — for example, a specific application that has licensing tied to one node, or where ARP flux from striped SNIPs would be a problem. Citrix recommends spotted SNIP addresses when USIP is disabled to avoid ARP flux; striped SNIPs should be used only when IP addresses are scarce. Figure 3 — NetScaler cluster — CLIP & coordinator One Cluster IP and one CCO manage up to 32 nodes. Config flows from the CLIP through the CCO to all nodes via the cluster backplane. NetScaler cluster — CLIP & coordinator CLIP / CCO single config point Node 1 (CCO) Node 2 Node 3 Node 4 Backplane link One Cluster IP and one CCO manage up to 32 nodes. Config flows from the CLIP through the CCO to all nodes via the cluster backplane. Figure 4 — Cluster config types — striped to spotted Configuration scope narrows from all nodes (striped) to a named node group (partially striped) to a single node (spotted). Cluster config types — striped to spotted Striped Active on all cluster nodes Partially striped Active on a named node group Spotted Active on one node only Configuration scope narrows from all nodes (striped) to a named node group (partially striped) to a single node (spotted). Striped SNIPs causing ARP flux When USIP is disabled and you use striped SNIPs (active on all nodes), each node responds to ARP for the same IP — causing ARP flux and unpredictable routing. The fix is to use spotted SNIPs (one per node) for each subnet and only resort to striped SNIPs when IP address space is genuinely scarce. ### ▶ Watch a NetScaler HA failover happen end-to-end Step through a healthy failover, then Break it to see the classic split-brain scenario and its fix. ① Heartbeat miss The secondary stops receiving heartbeats from the primary — the dead-interval countdown begins. ▼ ② Self-promotion Dead-interval expires. The secondary promotes itself to primary and takes ownership of all floating IPs. ▼ ③ GARP flood The new primary sends a gratuitous ARP for each floating IP (VIPs, SNIPs, MIPs). Switches and routers update their tables. ▼ ④ Traffic resumes Client sessions reconnect to the new primary. Established TCP sessions that were mirrored via connection mirroring survive the failover. Press Play to step through a healthy failover. Then press Break it to see split-brain. ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply You have a NetScaler cluster where a specific application must run on one designated node only. Which configuration type do you use? a) Striped — active on all nodes b) Partially striped — bound to a node group with multiple nodes c) Spotted — bound to a node group with a single node d) INC mode cluster — no node groups needed Correct: c. A spotted configuration is bound to a node group containing exactly one node, so only that node handles the workload. This is the correct choice for locality-sensitive or license-tied applications. 👉 So far: Cluster: one CLIP, one CCO, up to 32 nodes. Striped = config on all nodes. Spotted = config on one node group. Use spotted SNIPs to avoid ARP flux when USIP is off. ## ④ Troubleshooting HA & cluster failures The most dangerous HA failure is split-brain : both nodes believe they are the primary and each sends GARPs for the floating IPs. This happens when the heartbeat link fails but the nodes are otherwise healthy. The fix is ensuring redundant heartbeat paths (management + dedicated HA VLAN) and enabling independent heartbeat monitoring on a separate interface. For sync failures , check /var/nslog/ha.log . Common causes: the secondary's disk is full ( df -h ), the NSIP is unreachable over the sync path, or a command was manually entered on the secondary that conflicts with the primary's config (never configure the secondary directly unless you know what you are doing). ### Cluster node INACTIVE state In a cluster, a node goes INACTIVE when the CCO cannot reach it or when it has a config sync failure. Check show cluster node on the CLIP for the health of each node, review /var/nslog/cl.log for cluster events, and verify the cluster backplane interface is up. If a node rejoins after an outage, the CCO automatically pushes a full config sync to bring it current. Rohan at a Mumbai fintech firm faces this After a network maintenance window, clients report intermittent VIP unreachability. The NOC sees both NetScaler nodes showing as primary in SNMP alerts. Likely cause The dedicated HA heartbeat VLAN was accidentally shut down during the maintenance, and no redundant heartbeat interface was configured. Both nodes declared themselves primary — classic split-brain. Diagnosis Log into each node's NSIP independently. Run show ha node — both report 'Primary'. Check interface status: the HA heartbeat VLAN interface is down on both. NSIP of node 1 ▸ show ha node ▸ check heartbeat VLAN ▸ verify /var/nslog/ha.log Fix Bring the heartbeat VLAN back up. The node with the lower HA ID will revert to secondary. Add a second heartbeat path on the management interface ( set ha node -haStatus ENABLED on the NSIP subnet) so a single VLAN outage cannot repeat this. Verify Run show ha node on both nodes — one shows PRIMARY, the other SECONDARY. VIP reachability restores; SNMP shows only one primary alert. Always read ha.log and cl.log first For HA issues, /var/nslog/ha.log records every heartbeat event, failover, sync start/end, and propagation error with timestamps. For cluster issues, /var/nslog/cl.log does the same for CCO elections, node state changes, and backplane events. Read the log before touching any config — most HA tickets are solved in the first ten lines. Quick check · Q4 of 10 · Analyze Both NetScaler HA nodes believe they are primary and are each sending GARPs for the same VIPs. What is the most likely root cause? a) The heartbeat link has failed, causing split-brain b) INC mode is incorrectly configured c) Sync is disabled on the secondary d) The dead-interval is set to zero Correct: a. Split-brain occurs when the heartbeat link between nodes fails while both nodes remain otherwise healthy. Each node assumes the other is down and promotes itself to primary. Fix by ensuring redundant heartbeat paths across separate interfaces. 👉 So far: Split-brain = both nodes primary due to heartbeat link failure. Fix: redundant heartbeat paths. Sync failures: check /var/nslog/ha.log, disk space, and never direct-config the secondary. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What is the difference between the NSIP and a floating IP in an HA pair? What triggers a full synchronisation between HA nodes? What is INC mode and when must you use it? What is a NetScaler cluster's CLIP and CCO? What is the difference between striped and spotted cluster configs? How do you troubleshoot a NetScaler HA split-brain situation? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which IP address floats between the primary and secondary in a NetScaler HA pair? a) The MIP, SNIP and VIP (floating IPs) b) The NSIP of each node c) The CLIP used for cluster management d) The default gateway of the management network Correct: a. MIPs, SNIPs and VIPs are floating — they are owned by whichever node is primary and are claimed via gratuitous ARP on failover. The NSIP belongs permanently to each node and never moves. Q6 · Understand Why is propagation temporarily disabled during an HA sync? a) To save bandwidth on the heartbeat link b) Because propagation only works in INC mode c) It is not disabled — both run concurrently d) To prevent conflicting commands from being applied while the full ns.conf is being copied Correct: d. If propagation pushed live commands while sync was copying ns.conf, the two processes could create conflicting config on the secondary. NetScaler pauses propagation during sync and resumes it once the sync completes. Q7 · Apply Your organisation has NetScaler nodes in Mumbai and Chennai — different subnets, no shared L2. Which HA feature must you enable? a) Striped SNIP addresses b) INC (Independent Network Configuration) mode c) Connection mirroring only d) A spotted node group Correct: b. INC mode is required when HA nodes are in different subnets. It removes the dependency on shared floating SNIPs and GARPs, and uses DNS or GSLB to redirect clients after a failover instead. Q8 · Apply In a cluster, you need a VIP to be handled only by Node 3 due to an application licence restriction. How do you configure this? a) Bind the VIP as a striped config to all nodes b) Set the VIP's SNIP as a striped address c) Create a node group with Node 3 only and bind the VIP as a spotted config d) Disable all other nodes and use a two-node cluster Correct: c. A spotted configuration is bound to a node group containing a single node. Creating a node group with only Node 3 and binding the VIP there ensures only Node 3 handles that VIP's traffic. Q9 · Evaluate An engineer argues that USIP should always use striped SNIPs to save IP addresses. What is the strongest counter-argument? a) Striped SNIPs cannot be used with USIP at all b) Striped SNIPs cause ARP flux when USIP is disabled, because multiple nodes answer ARP for the same IP — spotted SNIPs eliminate this c) Spotted SNIPs are cheaper to licence d) Striped SNIPs only work in INC mode Correct: b. When USIP is disabled and striped SNIPs are used, every node responds to ARP for the same subnet IP, causing ARP flux and unpredictable routing. Citrix recommends spotted SNIPs per subnet to avoid this; striped SNIPs should only be used when IP space is genuinely scarce. Q10 · Evaluate What is the safest way to avoid HA split-brain in production? a) Set the dead-interval to 1 second so failover is faster b) Disable the secondary node when not needed c) Use INC mode on all HA pairs regardless of subnet topology d) Configure redundant heartbeat paths on separate interfaces so a single link failure cannot isolate both nodes Correct: d. Split-brain is caused by a heartbeat link failure while both nodes remain otherwise healthy. Having at least two independent heartbeat paths (e.g. dedicated HA VLAN + management interface) ensures that a single failure does not cause both nodes to simultaneously declare themselves primary. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: what is the difference between HA synchronisation and propagation, and when would you use INC mode? Then compare with the expert version. Compare with expert answer Expert version: Synchronisation copies the full ns.conf from primary to secondary when the incarnation number diverges (restart, manual sync, or config drift) — it is a bulk recovery operation. Propagation pushes individual CLI commands in real time so the secondary's running config stays current without a full file copy. INC mode is required when the two HA nodes sit in different subnets (e.g. separate data centres) — in INC mode there are no shared floating SNIPs and no GARPs after failover; DNS or GSLB must redirect clients to the new primary's reachable IP instead. The critical exam trap: in INC mode, SNIP addresses are neither synced nor propagated. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Citrix NetScaler (ADC) at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary NSIP (NetScaler IP) The permanent management IP of each node — never floats between nodes. Used to manage each node independently via SSH or the GUI. Floating IP A VIP, SNIP or MIP that is owned by the current primary and claimed by the new primary via gratuitous ARP on failover. Heartbeat Periodic health-check packets (default every 200 ms) sent between HA nodes. Missing the configured dead-interval triggers failover. INC Mode Independent Network Configuration — an HA mode for nodes in different subnets. No shared floating SNIPs; no GARPs; DNS or GSLB redirects post-failover. SNIPs are not synced. CLIP (Cluster IP) A single management IP for an entire NetScaler cluster. All configuration is applied here and distributed by the CCO to every node. CCO (Config Coordinator) The elected node in a cluster that receives configuration from the CLIP and propagates it to all other nodes via the cluster backplane. Striped configuration A cluster config active on all nodes — traffic is distributed across the entire cluster for that VIP or SNIP. Spotted configuration A cluster config bound to a node group containing a single node — only that node handles the workload. Used for locality-sensitive or licence-tied applications. Split-brain The dangerous state where both HA nodes believe they are primary, usually due to heartbeat link failure. Both send GARPs causing network instability. Incarnation number A counter on each node that increments with every config change. A mismatch between primary and secondary triggers a full synchronisation. #### 📚 Sources Citrix / NetScaler Docs — High Availability Introduction (NetScaler 14.1 current release). docs.netscaler.com/en-us/citrix-adc/current-release/system/high-availability-introduction.html - Citrix / NetScaler Docs — Configuring synchronisation in high availability (NetScaler 14.1). docs.netscaler.com/en-us/citrix-adc/current-release/system/high-availability-introduction/configuring-synchronization-high-availability.html - Citrix / NetScaler Docs — Striped, partially striped and spotted configurations (clustering). docs.netscaler.com/en-us/citrix-adc/current-release/clustering/cluster-overview/cluster-config-type.html - Citrix / NetScaler Docs — Troubleshooting NetScaler cluster . docs.netscaler.com/en-us/citrix-adc/current-release/clustering/cluster-troubleshooting.html - Citrix Support — Troubleshooting Citrix ADC High Availability (HA) — cheat-sheet PDF. docs.citrix.com/en-us/tech-zone/learn/downloads/diagrams-posters_cheat-sheet-adc-troubleshooting-high-availability.pdf - Citrix Support Article CTX116748 — How to Set Up a High Availability Pair on ADC . support.citrix.com/article/CTX116748 ### What's next? Got HA and clustering solid? Next, go deep on NetScaler load-balancing algorithms, persistence methods and content switching — and how to pick the right combination for your application tier. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt