Product Documentation
ADC
14.1-Current Release 13.1
View PDF

Enable Secure Management on a high availability pair

September 7, 2026
Contributed by: 
C

The Secure Management feature enforces strict separation of the Management and Data planes. For a complete description of the feature, see Secure management: Implement strict separation of Management and Data planes.

When you enable Secure Management, the NSIP moves to the Management plane in the management traffic domain (TD 4094 by default), and the feature requires a reboot to take effect. In a high availability (HA) deployment, enable the feature on each node individually rather than on the pair at once. Enable it first on the secondary node, fail over to the migrated node, and then enable it on the original primary node before you restore HA synchronization. This node-by-node approach keeps production traffic running throughout the migration and prevents a split-brain condition.

Note:

The Secure Management feature can be configured only through the CLI, not the GUI. It is not supported in a cluster setup. For the full list of unsupported features, see the Limitations in the feature documentation.

Before you begin

  • The examples in this procedure assume that Node 1 is the current primary node and Node 2 is the current secondary node.
  • Use identical Secure Management values on both nodes. The NSVLAN ID, the tagging mode, and the management traffic domain must match on Node 1 and Node 2. Asymmetric values cause a split-brain condition after both nodes reboot.
  • If a tagged NSVLAN is used, ensure that the upstream switch port is configured as a trunk that carries the NSVLAN. A tagged NSVLAN on a non-trunk port causes the feature to appear ENABLED without engaging.
  • (Optional, but recommended as a backup) Keep console access to both nodes available. If you lose management access over the network after a reboot, the console is the recovery path.

How the HA pair moves to Secure Management

Apply the change to one node at a time while the HA pair is running. The pair remains available during the migration, except for a brief, planned interruption at cutover.

The migration follows six steps:

  1. Prepare the HA pair.
  2. Enable Secure Management on the secondary node (Node 2).
  3. Verify Node 2 after the reboot.
  4. Fail over to Node 2.
  5. Enable Secure Management on Node 1 (the original primary).
  6. Re-form the HA pair.

The following sections describe each step.

Step 1: Prepare the HA pair

  1. On both nodes, temporarily disable configuration synchronization and propagation. Run the commands separately so that each setting is applied correctly:

    set ha node -haSync DISABLED
set ha node -haProp DISABLED
save ns config
<!--NeedCopy-->

    Note:

    On the primary node, do not combine -haSync and -haProp in a single command. If you set both options in one command, the primary node applies only the first option and ignores the second. The command returns no error. Always issue the two commands separately so that both settings take effect.

  2. On the secondary node (Node 2) only, force the node to remain secondary so that it does not take over unexpectedly during preparation:

    set ha node -hastatus STAYSECONDARY
save ns config
<!--NeedCopy-->

  3. On both nodes, verify that synchronization and propagation are DISABLED before you continue:

    show ha node
<!--NeedCopy-->

    The output shows both nodes UP, with synchronization and propagation DISABLED and Node 2 held as STAYSECONDARY:

    > show ha node
1)  Node ID:      0
    IP:           10.102.37.238  (NS-1)
    Node State:   UP
    Master State: Primary
    Sync State:   DISABLED
    Propagation:  DISABLED
2)  Node ID:      1
    IP:           10.102.37.239
    Node State:   UP
    Master State: STAYSECONDARY
    Sync State:   DISABLED
    Propagation:  DISABLED
 Done
<!--NeedCopy-->

Step 2: Enable Secure Management on the secondary node (Node 2)

  1. Enable Secure Management with your NSVLAN and interface values:

    set ns config -secureManagementTraffic ENABLED -secureManagementTD 4094 -nsvlan <nsvlan-id> -ifnum <interface-name> -tagged NO
<!--NeedCopy-->

  2. Verify that the configuration is staged. Run show ns config and confirm that the feature shows ENABLED and that your NSVLAN and SecureManagementTD values appear:

    show ns config
<!--NeedCopy-->

    In the output, confirm SecureManagementTraffic:ENABLED, SecureManagementTD:4094, and your NSVLAN:

    > show ns config

    NetScaler IP: 10.102.37.239  (mask: 255.255.255.0)
    Number of MappedIP(s): 0
    Node: Secondary
    NetScaler IP Vlan: 4000 Tagged: NO Bound Ports: 1/1
    SecureManagementTraffic:ENABLED SecureManagementTD:4094    (4094 is the default; you can configure any traffic domain)
                   System Time: Wed Jul 23 07:42:32 2025
          Last Config Changed Time: Tue Jul 22 05:04:53 2025
            Last Config Saved Time: Tue Jul 22 08:04:53 2025
    Config Changed since Last Saved Config: FALSE
 Done
<!--NeedCopy-->

    If the output does not show ENABLED, re-run the configuration command from the previous step and verify again before you continue.

  3. Save the configuration and reboot:

    save ns config
reboot
<!--NeedCopy-->

Step 3: Verify Node 2 after the reboot

Reconnect to Node 2 on the management VLAN. Use the console if necessary, and then verify the following:

show ns config       ← shows ENABLED, SecureManagementTD 4094, and the NSVLAN
show ns ip           ← the NSIP is in traffic domain 4094
show route -mgmt     ← the management routing table is not empty (NSIP subnet and management gateway)
show ha node         ← the peer node still shows UP
<!--NeedCopy-->

If your management gateway is not in the same subnet as the NSIP, add the Management plane default route now from the console:

add route 0.0.0.0 0.0.0.0 <mgmt-gateway> -mgmt
save ns config
<!--NeedCopy-->

Step 4: Fail over to Node 2

  1. On Node 2, clear the STAYSECONDARY status so that the node can take over:

    set ha node -hastatus ENABLED
<!--NeedCopy-->

  2. Confirm that heartbeats are flowing, and then trigger the failover:

    show ha node
force ha failover
<!--NeedCopy-->

    When prompted, confirm the failover. The configuration-loss warning is expected during this controlled failover. Node 2 becomes primary and takes over production traffic, and Node 1 becomes secondary.

  3. Immediately force Node 1 to remain secondary so that it does not fail back unexpectedly:

    set ha node -hastatus STAYSECONDARY
<!--NeedCopy-->

  4. Confirm that Node 2 is now the primary node and that the virtual servers are UP before you continue.

Step 5: Enable Secure Management on Node 1 (the original primary)

  1. On Node 1, follow the same procedure as in Step 2, using identical values:

    set ns config -secureManagementTraffic ENABLED -secureManagementTD 4094 -nsvlan <nsvlan-id> -ifnum <interface-name> -tagged NO
show ns config
save ns config
reboot
<!--NeedCopy-->

  2. After the reboot, run the same verification as in Step 3 on Node 1, and add the Management plane and Data-plane routes as needed. Both nodes are now running Secure Management.

Step 6: Re-form the HA pair

  1. With both NSIPs now on the Management plane, heartbeats resume. Verify that the peer node is UP before you re-enable synchronization:

    show ha node
<!--NeedCopy-->

    Both nodes show UP. Node 2 is now the primary, and Node 1 is the secondary. Synchronization and propagation are still DISABLED because you re-enable them in the next step:

    > show ha node
1)  Node ID:      0
    IP:           10.102.37.239  (NS-2)
    Node State:   UP
    Master State: Primary
    Sync State:   DISABLED
    Propagation:  DISABLED
2)  Node ID:      1
    IP:           10.102.37.238
    Node State:   UP
    Master State: Secondary (STAYSECONDARY)
    Sync State:   DISABLED
    Propagation:  DISABLED
 Done
<!--NeedCopy-->

  2. After the peer shows UP, re-enable synchronization and propagation on both nodes, and clear STAYSECONDARY on Node 1. Issue the commands separately:

    set ha node -haSync ENABLED
set ha node -haProp ENABLED
set ha node -hastatus ENABLED
save ns config
<!--NeedCopy-->

  3. Node 1 synchronizes its configuration from Node 2. Allow a moment for the sync to complete, and then verify:

    show ha node    ← both nodes UP, Sync: SUCCESS, Propagation: ENABLED
show ns ip      ← the NSIP is in traffic domain 4094 on both nodes
<!--NeedCopy-->

At this point, production traffic runs on Node 2, HA is healthy, and both nodes operate with Secure Management enabled.

Common mistakes to avoid

Mistake What happens Fix
Trying to demote the primary node with set ha node -hastatus STAYSECONDARY The command is rejected on the primary node. Use force ha failover to cut over.
A tagged NSVLAN on a non-trunk switch port Secure Management shows ENABLED but does not engage, and the NSIP stays in TD 0. Configure the switch port as a trunk, save the configuration, and reboot.
No Management plane default route You lose SSH or GUI access after the reboot. Recover through the console, and add the -mgmt route.
Reusing a data port, untagged, for management The port is pulled off its current VLAN. Use a dedicated port, or a tagged port on a trunk.
Setting -haSync and -haProp in one command on the primary node The command silently has no effect. Always issue the commands separately.
Asymmetric NSVLAN between the nodes A split-brain condition occurs after both nodes reboot. Use an identical VLAN ID, tagging mode, and subnet on both nodes.

Troubleshooting

If the migration does not go as expected, use the following guidance to recover:

  • You lose management access after the reboot: Connect through the console. If no Management plane route exists, add it. If you must back out Secure Management, run:

     unset ns config -secureManagementTraffic
 unset ns config -nsvlan
 save ns config
 reboot
 <!--NeedCopy-->

    Unset the NSVLAN only if you configured a tagged NSVLAN.

  • The peer node does not show UP after both nodes are on Secure Management: Do not re-enable synchronization until the peer state is healthy. Confirm the following:

    • Both nodes use the same NSVLAN ID and tagging mode.
    • Secure Management is active on both nodes, with the NSIP in TD 4094.
    • The management ports are connected to the same L2 segment.

    Keeping the standby node in STAYSECONDARY helps prevent a split-brain condition while you troubleshoot.

Enable Secure Management on a high availability pair
September 7, 2026
Contributed by: 
C
September 7, 2026
Contributed by: 
C

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.