Four-Node and Three-Node Multinode High Availability

The four-node MNHA setup involves four identical SRX Series Firewalls, all having the same hardware configurations. These devices are organized into two MNHA domains, with each domain containing two firewalls.

In the topology:

• Domain 1 consists of two firewalls— node1.1 (domain 1 node 1) and node1.2 (domain 1 node 2) .
• Domain 2 consists of two firewalls— node2.1 (domain 2 node 1) and node2.2 (domain 2 node 2) .

Inside each domain, the two nodes communicate through an Interchassis link (ICL), which is a direct connection that allows for fast and efficient communication. Across the two domains, the nodes communicate through inter-domain link (IDL). Both ICL and IDL are logical links, which can operate over dedicated interfaces or in-band traffic interfaces. Both ICL and IDL can be routed and use IPsec encryption.

IDL is a layer-three routable links that enable communication between nodes in different domains. Each IDL is configured on an interface of a node and is part of a private routing instance. This set up ensures that only internal communication packets between MNHA nodes across domains can traverse these links, maintaining security and integrity.

All four nodes are connected to external layer-three routers, which handle traffic from both public and private networks. This setup allows the Firewalls to manage network traffic efficiently.

To set up the four-node MNHA, we recommend first establish MNHA pairs within each domain by connecting two nodes through ICL. Then, connect these pairs (from different domains) through IDL to complete the full MNHA structure.

The four-node MNHA architecture is structured into two domains, each consisting of two nodes. This setup enables redundancy at two levels: within a domain and across domains.

• Within-Domain Redundancy:

  • Each domain has two peer nodes that back each other up. If one node in the domain fails or is out of service, the other node takes over its responsibilities.
  • The nodes within a domain can operate in two modes:
    • Active-backup mode: One node is active, handling all tasks, while the other is on standby, ready to take over if the active node fails.
    • Active-active mode: Both nodes are actively handling tasks, sharing the load, and providing immediate failover capabilities.

• Across-Domain Redundancy:

  • The nodes in one domain are backed up by nodes in the other domain. If all nodes in one domain fail, the nodes in the other domain take over the services.
  • This redundancy also supports both active-backup and active-active modes, similar to the within-domain redundancy.

• Communication and Synchronization:

  • ICL: This is the communication link between the two nodes within the same domain. It allows them to synchronize their states and keep each other updated about their status.
  • IDL: This newly introduced link facilitates communication between nodes across different domains, allowing them to synchronize states and share status information.

• State Synchronization:

  • Each node synchronizes its states with its peer in the same domain via the ICL.
  • The node also synchronizes states with one of the nodes in the other domain via the IDL.
  • When a node receives state information from another domain via the IDL, it relays this information to its peer node in the same domain through the ICL.

    Example: In a setup shown in topology includes four nodes labelled node 1.1, node 1.2, node2.1, and node 2.2.

    • Node 1.1 synchronizes its state with node 1.2 via ICL within the local domain.
    • Node 1.1 also synchronizes with node 2.1 in the remote domain via IDL.
    • Node 2.1, upon receiving this state, forwards it to node 2.2 in the same domain via ICL.

Use the following steps to upgrade software in a four-Node MNHA

1. Ensure your Multinode High Availability setup is healthy, functional, and that the interchassis link (ICL) is up. This step is need to ensure that another node within the same domain is ready to take over the responsibilities of the node being upgraded.

2. Disconnect the inter-domain link (IDL) to isolate the node from the rest of the network, preventing any potential disruptions during the upgrade.

3. Initiate the software upgrade process on the backup node (node 1.2) in domain 1 and commit the configuration using the set chassis high-availability software-upgrade statement.
4. Confirm that the other device (node 1.1) is in an active role and is functioning normally.
5. Install the Junos OS software on the node 1.2 and perform a reboot to apply the updates.
6. Reboot the device using the request system reboot or request vmhost reboot command (depending on your platform) after successful installation.
7. Check that the node is running the correct software version post-reboot using the show version command..
8. Check status of the multinode high availability on the device.
9. Remove the software-upgrade statement on node 1.2 and commit the configuration. This steps enables the system to return to its normal operating mode.
10. Re-establish the inter-domain link to reintegrate the upgraded node into the network.
11. Repeat the steps for the next node (node 1.1) within the same domain, ensuring each node is upgraded sequentially to maintain network stability.
12. After completing upgrades in the current domain, move on to another domain (domain 2) and follow the same procedure to ensure a consistent and orderly upgrade process across the network.

In a Multinode high availability (MNHA) network setup, ensuring that sessions remain consistent across multiple nodes is crucial for maintaining seamless network operations and failover capabilities. Previously, there was a requirement that all nodes within an MNHA configuration had to use the same ingress and egress interface names, zone names, and policy names for a given session. This requirement could be challenging to meet, especially in a four-Node MNHA configuration, as it requires meticulous configuration management across all nodes.

The four-node MNHA relaxes some of these restrictions. Specifically, it removes the need for ingress and egress interfaces to have the same names across all nodes within the MNHA domain. This change means that while previously, the same session on different nodes had to use interfaces with identical names (such as ge-0/0/0 on all nodes), the new configuration allows these interfaces to have different names on each node.

Example: A session on node1.1 have ingress interface ge-0/0/0 and egress interface ge-0/0/1, when the same session is active on node 2.1 can have ingress interface ge-0/0/2 and egress interface ge-0/0/3. But, ge-0/0/0 and ge-0/0/2 should be in the same zone, and similarly ge-0/0/1 and ge-0/0/3 must be in a same zone.

You must meet the following requirements to ensure secure and reliable session handling

1. Zone consistency: The interfaces used for the same session on different nodes must belong to the same zone (as described in previos section).

2. Policy consistency: The policies applied to these zones must remain consistent across all nodes. This setting ensures that the security and routing behaviors remain the same, even if the physical interfaces differ.

3. Routing instances/VRF consistency: Similarly, VR names must remain the same across nodes to ensure consistent routing behavior.

The following configuration snippets outline the high-level steps required to set up a four-node MNHA system

1. Local domain and node ID configuration:

   • Set the local domain ID and size:

     • domain-id: Unique identifier for the local domain (either 1 or 2).
     • size: Number of nodes in the domain (1 or 2). For a four-node MNHA, domain size is 2.

   • Set the local node ID:

     local-node-id: Unique identifier for the local node within its domain (1 through 10).

2. Inter-Chassis Link (ICL) configuration:

   This configuration is for connecting the local node to a peer node within the same domain.

   • Set local node IP:

3. Peer node configuration:

4. Inter-domain link (IDL) configuration: This configuration is for connecting nodes across different domains.
5. Service redundancy group (SRG0) configuration:

   • Set peer node in the same domain ( (1 through 10):

   • Set peer node in a different domain:

     Note: Ensure the following criteria is met:

     • Each domain ID must be unique and the ID can only be 1 or 2.
     • Node IDs are unique within the same domain.
     • The MNHA infrastructure supports four-node configurations for SRG0 only if a peer-domain-id is configured. Without it, the setup supports a 2-node configuration.
     • Reboot the device once you configure local domain ID, local node ID, peer domain ID, peer node ID, and domain size.

     Use the commands such as show chassis high-availability information and show chassis high-availability peer-info to verify if your configuration is working as expected.

Four-node Multinode High Availability (MNHA) with Inter-Domain Link (IDL) enhances high availability by extending it across data center domains. IDL facilitates communication between nodes across different domains, allowing the nodes to synchronize states and share status information.

IDL is a logical IP link and it is established using IP addresses that are routable in the network.

Nodes across the domains use the IDL to synchronize control plane and data plane states between them. IDL communication could go over a shared or untrusted network and packets sent over the IDL might traverse a path that is not always trusted. Therefore, you must secure the packets traversing the IDL by encrypting the traffic using IPsec standards.

IPsec protects traffic by establishing an encryption tunnel for the IDL. When you apply HA link encryption, the HA traffic flows between the nodes across the domains only through the secure, encrypted tunnel. Without HA link encryption, communication between the nodes might not be secure.

IDL supports IKEv2 and a custom Multi-SA implementation, to securely exchange encrypted data across domains through IPsec VPNs. The system supports robust AES-GCM-256 encryption and both PSK and PKI authentication, ensuring secure inter-domain communications.

The Three-Node MNHA setup involves three identical SRX Series Firewalls, all having the same hardware configurations. These devices are organized into two MNHA domains, with one domain containing two firewalls and another domain containing one firewall.

In a three-node MNHA setup, node 1.1 and node 1.2 belong to domain 1, while node 2.1 is in domain 2. For a four-node MNHA configuration, each node is equipped with one Inter-Cluster Link (ICL) and one Inter-Domain Link (IDL). In a three-node MNHA configuration, the two nodes in domain 1 each have one ICL and one IDL, whereas the node in domain 2 has two IDLs and no ICL.

State Synchronization:

• In domain 1, node 1.1 synchronizes its states with its peer (node 1.2) through ICL.
• Node 1.1 also synchronizes states with Node 2.1 in the other domain through the IDL.
• Node 2.1 synchronizes states to node 01.1 and Nnode 1.2 through IDL .
• When a node receives state information from another domain through the IDL, it does not relay this information to its peer node within the same domain via the ICL. This approach prevents unnecessary duplication of data transmission within the domain.

In the event of a single IDL failure—specifically, if the direct link between node 1.1 and Nnode 2.1 is down—routing is employed to maintain connectivity. Node 1.1 can still communicate with node 2.1 by using a predefined route through Nnode 1.2. This routing ensures that the IDL between node 1.1 and node 2.1 remains operational, eliminating the need for forwarding packets from IDL to ICL peers, whether for hot sync or cold sync processes.