Multinode High Availability Support for vSRX Instances
SUMMARY Read this topic to understand Multinode High Availability support for vSRX instances.
Overview
Starting in Junos OS Release 22.3R1, we support Multinode High Availability on vSRX virtual firewalls. Multinode High availability addresses high availability requirements for private and public cloud deployments by offering inter-chassis resiliency.
We support Multinode High Availability for vSRX instances for the following private and public cloud platforms:
- Kernel-based virtual machine (KVM) and VMWare ESXi
- Amazon Web Services (AWS)
Multinode High Availability in AWS
You can configure Multinode High Availability on the vSRX firewalls deployed on AWS. Participating nodes run both control and data-plane active at the same time and backup each other to ensure a fast synchronized failover in case of system or hardware failure. The Interchassis link (ICL) connection between the two devices synchronizes and maintains the state information and handles device failover scenarios.
Lets begin by getting familiar with Multinode High Availability terms specific to the AWS deployment.
Terminology
| Term | Description |
|---|---|
|
Elastic IP Addresses |
An Elastic IP address is a public IPv4 address, which is routable from the network/Internet. EIPs are dynamically bound to an interface of any node in Multinode High Availability setup. At any given time, EIPs are bound to only one interface and bound to the same node. The Multinode High Availability setup uses EIPs to control the traffic in AWS deployments. EIP acts similar to floating IP address in Layer 3 deployment or virtual IP address as in default gateway deployment. The node with an active SRG1 owns the EIP and draws the traffic toward it. |
|
Inter-chassis link (ICL) |
IP-based link (logical link) that connects nodes over a routed network in a Multinode High Availability system. The security device uses the ICL to synchronize and maintain the state information and to handle device failover scenarios. You can use only ge-0/0/0 interface to configure an ICL. The ICL uses MAC address assigned by AWS (not the virtual MAC created by vSRX VM). When you configure the ICL, ensure that the IP address is subnet of VPC. Note that cross VPC deployment is not supported. |
| Juniper Services Redundancy Protocol (jsrpd) process |
JSRPD manages activeness determination and enforcement, and split-brain protection. |
In Junos OS Release 22.3R1, we don't support IPSec VPN for Multinode High Availability in AWS deployments.
Architecture
Figure 1 shows two vSRX instances in Multinode High Availability setup deployed on AWS. In this deployment, two vSRX instances, one acting as the active node and the other as the backup node form a high availability pair. Two nodes run identical Junos OS image and have equal number of network interfaces configured.
In Multinode High Availability setup, two vSRX instances are operating in active/backup mode. Both nodes connect to each other using an ICL for synchronizing control and data plane states. The vSRX instance, on which the SRG1 is active, hosts the Elastic IP address. The active node steers traffic towards it using the Elastic IP address. Backup node remains in standby mode and takes over on failover.
Juniper Services Redundancy Protocol (jsrpd) process communicates with AWS infrastructure to perform activeness determination and enforcement and provides split-brain protection.
During a failover, the Elastic IP address moves from the old active node to the new active node by triggering API (AWS SDK API) and draws traffic towards it. AWS updates the route tables to divert the traffic to the new active node.
This mechanism enables clients to communicate with the nodes using a single IP address. The Elastic IP is configured on the interface that connects to participating networks/segments.
Split-Brain Protection
When the ICL between two nodes goes down, each node starts pinging to the peer node’s interface IP using the probes. If the peer node is healthy, it responds to the probes. Otherwise, the jsrpd process communicates with AWS infrastructure to enforce the active role for the healthy node.
Configuring Multinode High Availability In Amazon Web Services (AWS) Deployment
In this example, we'll show you how to configure Multinode High Availability on two vSRX instances in the Amazon Virtual Private Cloud (Amazon VPC).
Requirements
This example uses the following hardware and software components:
-
Two vSRX instances
-
Junos OS Release 22.3R1
-
An Amazon Web Services (AWS) account and an Identity and Access Management (IAM) role, with all required permissions to access, create, modify, and delete Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (S3), and Amazon Virtual Private Cloud (Amazon VPC) objects. Check Configure an Amazon Virtual Private Cloud for vSRX for details.
-
In this example, we've set up an Amazon VPC with its associated Internet gateway, subnets, route table, and security groups. See Configure an Amazon Virtual Private Cloud for vSRX.
-
Launched and configured a vSRX instance in Amazon VPC. See Launch a vSRX Instance on an Amazon Virtual Private Cloud.
Topology
Figure 2 shows the topology used in this example.
As shown in the topology, two vSRX instances are deployed in the Amazon Virtual Private Cloud (Amazon VPC). The nodes communicate with each other using a routable IP address (Elastic IP address). Untrust side connects to public network and trust side connects to the protected resources.
Complete the following configurations before configuring Multinode High Availability on vSRX instances:
-
Use instance tag in AWS to identify two vSRX instances as Multinode High Availability peers. For example, in the
Nameoption, you can say vsrx-node-1 and forha-peeroption, you can say vsrx-node-2. - Deploy both vSRX instances in the same Amazon VPC and availability zone.
- Assign IAM role for vSRX instance and launch vSRX as an Amazon Elastic Compute Cloud (EC2) instance with full permissions.
- Enable communication to the Internet by placing vSRX instances in public subnet. In the Amazon VPC, public subnets have access to the Internet gateway.
- Configure one VPC with multiple subnets to form high availability pair. The
subnets are used to connect the two vSRX nodes (using a logical connection,
similar to the physical cables connecting ports). In this example, we have
CIDR for VPC is defined as 10.0.0.0/16, and created a total of four subnets
to host vSRX traffic. Also you need a minimum four interfaces for both vSRX
instances. Table 1 provides subnet and interfaces details.
Table 1: Subnets Configurations Function Port Number Interface Connection Traffic Type Subnet Management 0 Fxp0 Management Interface Management traffic 10.0.254.0/24 ICL 1 ge-0/0/0 Inter-chassis link to peer node RTO, Sync, and probes-related traffic 10.0.253.0/24 Public 2 ge-0/0/1 Connect to public network. (Revenue Interface) External traffic 10.0.1.0/24 Private 3 ge-0/0/2 Connect to private network. (Revenue Interface) Internal traffic 10.0.2.0/24 Note that interface mapping with functionality mentioned in the table are default configuration and we recommend to use the same mapping in the configuration.
- Configure interfaces with primary and secondary IP addresses. You can
associate EIP (Elastic IP address) as secondary IP addresses for an
interface. Primary IP address is required during launching of instance and
secondary IP address is transferable from one vSRX node to another during a
failover. Table 2 show interface and IP address mappings used in this example.
Table 2: Interface and IP Address Mappings Instance Interface Primary IP Secondary IP vSRX-1 ge-0/0/1 10.0.1.101 10.0.1.103 (EIP) ge-0/0/2 10.0.2.201 10.0.2.203 (EIP) vSRX-2 ge-0/0/1 10.0.1.102 10.0.1.103 (EIP) ge-0/0/2 10.0.2.202 10.0.2.203 (EIP) -
Configure neighboring routers to include vSRX in the data path and mark vSRX as the next hop for the traffic. You can use EIP to configure the route. Example:
sudo ip route x.x.x.x/x dev ens6 via 10.0.2.203where the 10.0.2.203 address is EIP.
Configuration
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them
into a text file, remove any line breaks, change any details necessary to
match your network configuration, copy and paste the commands into the CLI
at the [edit] hierarchy level, and then enter
commit from configuration mode.
These configurations are captured from a lab environment, and are provided for reference only. Actual configurations may vary based on the specific requirements of your environment.
On vSRX-1 Device
set chassis high-availability local-id 1 set chassis high-availability local-id local-ip 10.0.3.10 set chassis high-availability peer-id 2 peer-ip 10.0.3.11 set chassis high-availability peer-id 2 interface ge-0/0/0.0 set chassis high-availability peer-id 2 liveness-detection minimum-interval 400 set chassis high-availability peer-id 2 liveness-detection multiplier 5 set chassis high-availability services-redundancy-group 1 deployment-type cloud set chassis high-availability services-redundancy-group 1 peer-id 2 set chassis high-availability services-redundancy-group 1 preemption set chassis high-availability services-redundancy-group 1 activeness-priority 200 set security policies default-policy permit-all set security zones security-zone fab host-inbound-traffic system-services all set security zones security-zone fab host-inbound-traffic protocols all set security zones security-zone fab interfaces ge-0/0/0.0 set security zones security-zone untrust host-inbound-traffic system-services all set security zones security-zone untrust host-inbound-traffic protocols all set security zones security-zone untrust interfaces ge-0/0/1.0 set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone trust host-inbound-traffic protocols all set security zones security-zone trust interfaces ge-0/0/2.0 set security cloud high-availability aws eip-based set security cloud high-availability aws peer-liveliness probe-ip 10.0.1.102 set security cloud high-availability aws peer-liveliness probe-ip routing-instance s1-router set interfaces ge-0/0/0 mtu 9192 set interfaces ge-0/0/0 unit 0 family inet address 10.0.3.10/24 set interfaces ge-0/0/1 mtu 9192 set interfaces ge-0/0/1 unit 0 family inet address 10.0.1.101/24 primary set interfaces ge-0/0/1 unit 0 family inet address 10.0.1.103/24 set interfaces ge-0/0/2 mtu 9192 set interfaces ge-0/0/2 unit 0 family inet address 10.0.2.201/24 primary set interfaces ge-0/0/2 unit 0 family inet address 10.0.2.203/24 set routing-instances s1-router instance-type virtual-router set routing-instances s1-router routing-options static route 0.0.0.0/0 next-hop 10.0.1.1 set routing-instances s1-router interface ge-0/0/1.0 set routing-instances s1-router interface ge-0/0/2.0
On vSRX-2 Device
set chassis high-availability local-id 2 set chassis high-availability local-id local-ip 10.0.3.11 set chassis high-availability peer-id 1 peer-ip 10.0.3.10 set chassis high-availability peer-id 1 interface ge-0/0/0.0 set chassis high-availability peer-id 1 liveness-detection minimum-interval 400 set chassis high-availability peer-id 1 liveness-detection multiplier 5 set chassis high-availability services-redundancy-group 1 deployment-type cloud set chassis high-availability services-redundancy-group 1 peer-id 1 set chassis high-availability services-redundancy-group 1 preemption set chassis high-availability services-redundancy-group 1 activeness-priority 100 set security policies default-policy permit-all set security zones security-zone fab host-inbound-traffic system-services all set security zones security-zone fab host-inbound-traffic protocols all set security zones security-zone fab interfaces ge-0/0/0.0 set security zones security-zone untrust host-inbound-traffic system-services all set security zones security-zone untrust host-inbound-traffic protocols all set security zones security-zone untrust interfaces ge-0/0/1.0 set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone trust host-inbound-traffic protocols all set security zones security-zone trust interfaces ge-0/0/2.0 set security cloud high-availability aws eip-based set security cloud high-availability aws peer-liveliness probe-ip 10.0.1.101 set security cloud high-availability aws peer-liveliness probe-ip routing-instance s1-router set interfaces ge-0/0/0 mtu 9192 set interfaces ge-0/0/0 unit 0 family inet address 10.0.3.11/24 set interfaces ge-0/0/1 mtu 9192 set interfaces ge-0/0/1 unit 0 family inet address 10.0.1.102/24 primary set interfaces ge-0/0/1 unit 0 family inet address 10.0.1.103/24 set interfaces ge-0/0/2 mtu 9192 set interfaces ge-0/0/2 unit 0 family inet address 10.0.2.202/24 primary set interfaces ge-0/0/2 unit 0 family inet address 10.0.2.203/24 set routing-instances s1-router instance-type virtual-router set routing-instances s1-router routing-options static route 0.0.0.0/0 next-hop 10.0.1.1 set routing-instances s1-router interface ge-0/0/1.0 set routing-instances s1-router interface ge-0/0/2.0
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
-
Configure the interface for the ICL.
[edit] user@host# set interfaces ge-0/0/0 mtu 9192 user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.0.3.11/24
- Configure interfaces for internal and external traffic.
[edit] user@host# set interfaces ge-0/0/1 mtu 9192 user@host# set interfaces ge-0/0/1 unit 0 family inet address 10.0.1.102/24 primary user@host# set interfaces ge-0/0/1 unit 0 family inet address 10.0.1.103/24 user@host# set interfaces ge-0/0/2 mtu 9192 user@host# set interfaces ge-0/0/2 unit 0 family inet address 10.0.2.202/24 primary user@host# set interfaces ge-0/0/2 unit 0 family inet address 10.0.2.203/24
The secondary IP address assigned to ge-0/0/1 interface is used as EIP.
-
Configure security zones, assign interfaces to the zones, and specify allowed system services for the security zones .
[edit] user@host# set security zones security-zone fab host-inbound-traffic system-services all user@host# set security zones security-zone fab host-inbound-traffic protocols all user@host# set security zones security-zone fab interfaces ge-0/0/0.0 user@host# set security zones security-zone untrust host-inbound-traffic system-services all user@host# set security zones security-zone untrust host-inbound-traffic protocols all user@host# set security zones security-zone untrust interfaces ge-0/0/1.0 user@host# set security zones security-zone trust host-inbound-traffic system-services all user@host# set security zones security-zone trust host-inbound-traffic protocols all user@host# set security zones security-zone trust interfaces ge-0/0/2.0
-
Configure routing options.
[edit] user@host# set routing-instances s1-router instance-type virtual-router user@host# set routing-instances s1-router routing-options static route 0.0.0.0/0 next-hop 10.0.1.1 user@host# set routing-instances s1-router interface ge-0/0/1.0 user@host# set routing-instances s1-router interface ge-0/0/2.0
Create a separate routing instance type virtual router to separate management traffic and revenue traffic.
-
Configure local node and peer node details.
[edit] user@host# set chassis high-availability local-id 1 user@host# set chassis high-availability local-id local-ip 10.0.3.10 user@host# set chassis high-availability peer-id 2 peer-ip 10.0.3.11
-
Associate the interface to peer node for interface monitoring and configure liveness detection details.
[edit] user@host# set chassis high-availability peer-id 2 interface ge-0/0/0.0 user@host# set chassis high-availability peer-id 2 liveness-detection minimum-interval 400 user@host# set chassis high-availability peer-id 2 liveness-detection multiplier 5
-
Configure SRG1 by setting mode, deployment type.
[edit] user@host# set chassis high-availability services-redundancy-group 1 deployment-type cloud user@host# set chassis high-availability services-redundancy-group 1 peer-id 2 user@host# set chassis high-availability services-redundancy-group 1 preemption user@host# set chassis high-availability services-redundancy-group 1 activeness-priority 200
-
Associate a peer ID to SRG1 and define activeness-priority and preemption.
[edit] user@host# set chassis high-availability services-redundancy-group 1 peer-id 2 user@host# set chassis high-availability services-redundancy-group 1 preemption user@host# set chassis high-availability services-redundancy-group 1 activeness-priority 200
-
Configure AWS deployment related options such as service type as EIP-based and specify details for monitoring options.
[edit] user@host# set security cloud high-availability aws eip-based user@host# set security cloud high-availability aws peer-liveliness probe-ip 10.0.1.101 user@host# set security cloud high-availability aws peer-liveliness probe-ip routing-instance s1-router
Results
vSRX-1
From configuration mode, confirm your configuration by entering the following commands.
If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
[edit]
user@host# show chassis high-availability
local-id 1 local-ip 10.0.3.10;
peer-id 2 {
peer-ip 10.0.3.11;
interface ge-0/0/0.0;
liveness-detection {
minimum-interval 400;
multiplier 5;
}
}
services-redundancy-group 1 {
deployment-type cloud;
peer-id {
2;
}
preemption;
activeness-priority 200;
}
[edit]
user@host# show routing-instances
s1-router {
instance-type virtual-router;
routing-options {
static {
route 0.0.0.0/0 next-hop 10.0.1.1;
}
}
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
[edit]
user@host# show security zones security-zone
security-zone fab {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/0.0;
}
}
security-zone untrust {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/1.0;
}
}
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/2.0;
}
}
[edit]
user@host# show interfaces
ge-0/0/0 {
mtu 9192;
unit 0 {
family inet {
address 10.0.3.10/24;
}
}
}
ge-0/0/1 {
mtu 9192;
unit 0 {
family inet {
address 10.0.1.101/24 {
primary;
}
address 10.0.1.103/24;
}
}
}
ge-0/0/2 {
mtu 9192;
unit 0 {
family inet {
address 10.0.2.201/24 {
primary;
}
address 10.0.2.203/24;
}
}
}
If you are done configuring the device, enter commit from
configuration mode.
vSRX-2
From configuration mode, confirm your configuration by entering the following commands.
If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.
[edit]
user@host# show chassis high-availability
local-id 2 local-ip 10.0.3.11;
peer-id 1 {
peer-ip 10.0.3.10;
interface ge-0/0/0.0;
liveness-detection {
minimum-interval 400;
multiplier 5;
}
}
services-redundancy-group 1 {
deployment-type cloud;
peer-id {
1;
}
preemption;
activeness-priority 100;
}
[edit]
user@host# show routing-instances
s1-router {
instance-type virtual-router;
routing-options {
static {
route 0.0.0.0/0 next-hop 10.0.1.1;
}
}
interface ge-0/0/1.0;
interface ge-0/0/2.0;
}
[edit]
user@host# show security zones
security-zone fab {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/0.0;
}
}
security-zone untrust {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/1.0;
}
}
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
ge-0/0/2.0;
}
}
[edit]
user@host# show interfaces
ge-0/0/0 {
mtu 9192;
unit 0 {
family inet {
address 10.0.3.11/24;
}
}
}
ge-0/0/1 {
mtu 9192;
unit 0 {
family inet {
address 10.0.1.102/24 {
primary;
}
address 10.0.1.103/24;
}
}
}
ge-0/0/2 {
mtu 9192;
unit 0 {
family inet {
address 10.0.2.202/24 {
primary;
}
address 10.0.2.203/24;
}
}
}
If you are done configuring the device, enter commit from
configuration mode.
Verification
- Check Multinode High Availability Details
- Check Multinode High Availability Information on AWS
- Check Multinode High Availability Peer Node Status
- Check Multinode High Availability SRG
- Verify the Multinode High Availability Status Before and After Failover
Check Multinode High Availability Details
Purpose
View and verify the details of the Multinode High Availability setup configured on your vSRX instance.
Action
From operational mode, run the following command:
vSRX-1
user@host> show chassis high-availability information
Node failure codes:
HW Hardware monitoring LB Loopback monitoring
MB Mbuf monitoring SP SPU monitoring
CS Cold Sync monitoring SU Software Upgrade
Node Status: ONLINE
Local-id: 1
Local-IP: 10.0.3.10
HA Peer Information:
Peer Id: 2 IP address: 10.0.3.11 Interface: ge-0/0/0.0
Routing Instance: default
Encrypted: NO Conn State: UP
Cold Sync Status: COMPLETE
SRG failure event codes:
BF BFD monitoring
IP IP monitoring
IF Interface monitoring
CP Control Plane monitoring
Services Redundancy Group: 1
Deployment Type: CLOUD
Status: ACTIVE
Activeness Priority: 200
Preemption: ENABLED
Process Packet In Backup State: NO
Control Plane State: READY
System Integrity Check: N/A
Failure Events: NONE
Peer Information:
Peer Id: 2
Status : BACKUP
Health Status: HEALTHY
Failover Readiness: NOT READY
vSRX-2
user@host> show chassis high-availability information
Node failure codes:
HW Hardware monitoring LB Loopback monitoring
MB Mbuf monitoring SP SPU monitoring
CS Cold Sync monitoring SU Software Upgrade
Node Status: ONLINE
Local-id: 2
Local-IP: 10.0.3.11
HA Peer Information:
Peer Id: 1 IP address: 10.0.3.10 Interface: ge-0/0/0.0
Routing Instance: default
Encrypted: NO Conn State: UP
Cold Sync Status: COMPLETE
SRG failure event codes:
BF BFD monitoring
IP IP monitoring
IF Interface monitoring
CP Control Plane monitoring
Services Redundancy Group: 1
Deployment Type: CLOUD
Status: BACKUP
Activeness Priority: 100
Preemption: ENABLED
Process Packet In Backup State: NO
Control Plane State: NOT READY
System Integrity Check: COMPLETE
Failure Events: NONE
Peer Information:
Peer Id: 1
Status : ACTIVE
Health Status: HEALTHY
Failover Readiness: N/A
Meaning
Verify these details from the command output:
-
Local node and peer node details such as IP address and ID.
-
The field
Deployment Type: CLOUDindicates that configuration is for the cloud deployment. -
The field
Services Redundancy Group: 1indicates the status of the SRG1 (ACTIVE or BACKUP) on that node.
Check Multinode High Availability Information on AWS
Purpose
View and verify cloud deployment details.
Action
From operational mode, run the following command:
user@host> show security cloud high-availability information
Cloud HA Information:
Cloud Type Cloud Service Type Cloud Service Status
AWS EIP Bind to Local Node
Meaning
Verify these details from the command output:
-
The field
Cloud Type: AWSindicates the deployment is for AWS. -
The field
Cloud Service Type: EIPindicates that EIP service type is used to control the traffic in AWS deployment. The field
.Cloud Service Status: Bind to Local Nodedisplays EIP binding with local node. For the backup node, this field displaysBind to Peer Node
Check Multinode High Availability Peer Node Status
Purpose
Check the Multinode High Availability peer node status.
Action
From operational mode, run the following command:
vSRX-1
user@host> show chassis high-availability peer-info
HA Peer Information:
Peer-ID: 2 IP address: 10.0.3.11 Interface: ge-0/0/0.0
Routing Instance: default
Encrypted: NO Conn State: UP
Cold Sync Status: COMPLETE
Internal Interface: N/A
Internal Local-IP: N/A
Internal Peer-IP: N/A
Internal Routing-instance: N/A
Packet Statistics:
Receive Error : 0 Send Error : 0
Packet-type Sent Received
SRG Status Msg 7 6
SRG Status Ack 6 7
Attribute Msg 2 1
Attribute Ack 1 1
vSRX-2
user@host> show chassis high-availability peer-info
HA Peer Information:
Peer-ID: 1 IP address: 10.0.3.10 Interface: ge-0/0/0.0
Routing Instance: default
Encrypted: NO Conn State: UP
Cold Sync Status: COMPLETE
Internal Interface: N/A
Internal Local-IP: N/A
Internal Peer-IP: N/A
Internal Routing-instance: N/A
Packet Statistics:
Receive Error : 0 Send Error : 0
Packet-type Sent Received
SRG Status Msg 9 9
SRG Status Ack 9 9
Attribute Msg 3 2
Attribute Ack 2 2
Meaning
Verify these details from the command output:
-
Peer node details such as interface used, IP address, and ID.
-
Packet statistics across the node.
Check Multinode High Availability SRG
Purpose
View and verify SRG details in Multinode High Availability.
Action
From operational mode, run the following command:
user@host> show chassis high-availability services-redundancy-group 1
SRG failure event codes:
BF BFD monitoring
IP IP monitoring
IF Interface monitoring
CP Control Plane monitoring
Services Redundancy Group: 1
Deployment Type: CLOUD
Status: ACTIVE
Activeness Priority: 200
Preemption: ENABLED
Process Packet In Backup State: NO
Control Plane State: READY
System Integrity Check: N/A
Failure Events: NONE
Peer Information:
Peer Id: 2
Status : BACKUP
Health Status: HEALTHY
Failover Readiness: READY
Split-brain Prevention Probe Info:
DST-IP: 10.0.1.102
SRC-IP: 0.0.0.0
Routing Instance: s1-router
Status: NOT RUNNING
Result: N/A Reason: N/A
Meaning
Verify these details from the command output:
-
SRG details such deployment type, status, activeness priority and preemption details.
-
Peer node details.
-
Split-brain prevention probe details.
Verify the Multinode High Availability Status Before and After Failover
Purpose
Check the change in node status before and after a failover in a Multinode High Availability setup.
Action
Check the Multinode High Availability status on the backup node (SRX-2).
From operational mode, run the following command:
user@host> show chassis high-availability information
Node failure codes:
HW Hardware monitoring LB Loopback monitoring
MB Mbuf monitoring SP SPU monitoring
CS Cold Sync monitoring SU Software Upgrade
Node Status: ONLINE
Local-id: 2
Local-IP: 10.0.3.11
HA Peer Information:
Peer Id: 1 IP address: 10.0.3.10 Interface: ge-0/0/0.0
Routing Instance: default
Encrypted: NO Conn State: UP
Cold Sync Status: COMPLETE
SRG failure event codes:
BF BFD monitoring
IP IP monitoring
IF Interface monitoring
CP Control Plane monitoring
Services Redundancy Group: 1
Deployment Type: CLOUD
Status: BACKUP
Activeness Priority: 100
Preemption: ENABLED
Process Packet In Backup State: NO
Control Plane State: NOT READY
System Integrity Check: COMPLETE
Failure Events: NONE
Peer Information:
Peer Id: 1
Status : ACTIVE
Health Status: HEALTHY
Failover Readiness: N/A
Under Services Redundancy Group: 1 option, you can see the
Status: BACKUP. This indicates that the SRG-1 is in
backup mode for the device.
Initiate the failover on the active node (vSRX-1) and again run the command on the backup node (vSRX-2).
user@host> show chassis high-availability information
Node failure codes:
HW Hardware monitoring LB Loopback monitoring
MB Mbuf monitoring SP SPU monitoring
CS Cold Sync monitoring SU Software Upgrade
Node Status: ONLINE
Local-id: 2
Local-IP: 10.0.3.11
HA Peer Information:
Peer Id: 1 IP address: 10.0.3.10 Interface: ge-0/0/0.0
Routing Instance: default
Encrypted: NO Conn State: UP
Cold Sync Status: COMPLETE
SRG failure event codes:
BF BFD monitoring
IP IP monitoring
IF Interface monitoring
CP Control Plane monitoring
Services Redundancy Group: 1
Deployment Type: CLOUD
Status: ACTIVE
Activeness Priority: 100
Preemption: ENABLED
Process Packet In Backup State: NO
Control Plane State: READY
System Integrity Check: N/A
Failure Events: NONE
Peer Information:
Peer Id: 1
Status : BACKUP
Health Status: HEALTHY
Failover Readiness: NOT READY
Meaning
You can notice that under Services Redundancy Group: 1
option, the status of SRG1 is changed from BACKUP to ACTIVE. This indicates
that the node has transitioned into the active role and the other node
(previous active) has transitioned to the backup role. You can see the other
node's status in the Peer Information option. Here, the
status says BACKUP.