The diagram below outlines the physical connections. This exercise assumes the specific firewall rules are configured for needed access between nodes. Also this exercise will contain configuration from the previous post (such as enabling the chassis cluster, previous interfaces and redundancy groups etc.).
The diagram below outlines the logical configuration. Two redundancy groups will be used for the data plane in order to have both SRX units participate in forwarding traffic.
1. Existing Configuration Recap
As mentioned earlier please reference the earlier post High Availability - SRX Active/Passive Configuration if you have not already. This exercise and configuration builds off of the configuration done in this post.
2. Configure Additional Redundancy Group
In this step an additional redundancy group (redundancy group 2) is created. The node priorities are updated so that node0 will be primary for redundancy group 2 and node1 will be primary for redundancy group 1. See the screenshot below for command details.
3. Configure Additional RETH Interfaces
Additional RETH interfaces are needed for the additional networks that we will be configuring. The RETH count will also need to be updated to reflect the additional two RETH interfaces added. As was done in the previous post, IP addresses are also assigned to the RETH interfaces. See the screenshot below for command details.
4. Configure Interface Monitoring for Redundancy Group 2
Interface monitoring is configured in the same fashion as it is for redundancy group 1. Any single interface failure will result in the associated nodes priority changing to 0 resulting in a failover. See the screenshot below for command details.
Verification & Testing
1. Verify Chassis Cluster
The following commands can be used to verify chassis cluster operation and current state.
The command 'show chassis cluster status' can be used to view the cluster status. We can confirm that node0 is primary for redundancy group 2 and node1 is primary for redundancy group 1.
The command 'show chassis cluster interfaces' can be used to view the status of monitored interfaces.
2. Test Failover - Interface Monitoring
Testing failover would be the same as the steps completed in the previous post with the addition of a new redundancy group. Please reference High Availability - SRX Active/Passive Configuration for details.
In an active/passive design traffic flow is very deterministic. All data traffic flows through the active SRX regardless of what the source and destination networks are. This is not the case in an active/active design. In an active/active design traffic may flow through a single SRX or from one SRX to another via the fabric link. The following traffic examples outline two examples, one traffic flow through a single SRX and another traffic flow through both SRX devices.
1. Flow Within a Single SRX Device
The following diagram depicts a traffic flow in red. In this example the traffic source is 192.168.2.10 and the traffic destination is 100.100.100.254. In this example traffic only flows through SRX-A as SRX-A is primary for Redundancy Group 2 and RETH2 and RETH3 are members of this Redundancy Group.
2. Flow Traversing both SRX Device
The following diagram depicts a different traffic flow in red. In this example the traffic source is 192.168.1.10 and the traffic destination is 100.100.100.254. In this example traffic flows through SRX-B and SRX-A as RETH0 and RETH3 are members of different Redundancy Groups and each SRX is primary for one of the Redundancy Groups. When traffic flows from one SRX to another the fabric link is used.
The following graphic builds on the previous post's conceptual diagram adding the new elements for the Active/Active configuration.
Since both SRX units cannot both be active for a single network segment or RETH interface a better term of describing the Active/Active configuration on an SRX (in my opinion) would be 'load sharing' configuration. In the next post I will be configuring a HA Cluster utilizing link aggregation and dual fabric links.