Juniper SRX High Availability Basics

Devices fail, network fails, disaster occurs. But still, passing traffic is our goal. SRX provides high availability feature and is different
from traditional HA devices. When one router fails, the other router must know about the device configuration and traffic sessions that
first router was dealing with. Otherwise, the second router needs to relearn all the routes and sessions making unnecessary traffic
congestion in the network. The interaction between two HA device is unique compared to other vendors. To get into more detail about
High Availability lets learn about Juniper SRX High Availability basics.
Juniper SRX High Availability Basics
Chassis Cluster
In HA mode the SRX devices act like a single device creating a chassis cluster. In chassis cluster the two devices acts like one. The
flexible PIC concentrator (FPC) starts from zero (0) in one device and ends at other devices last FPC number. For example in the
given figure, the FPC is starting from zero in device A and ends with FPC nine in device B.

Control Plane
The control plane and data plane in SRX is separated. In HA, there can be only one RE no matter what. If the primary RE fails, then
only secondary device takes the initiative of primary RE. The control plane synchronizes the state between the routers by exc hanging
the Hello messages. On RE the process called JSRPD and KSYNCD. JSRPD stands for Junos Stateful redundancy protocol daemon.
This process is responsible for exchanging messages and doing failover between devices. Similarly, KSYNCD stands for kernel state
synchronization daemon. This process is responsible for synchronizing the kernel state between the two devices.
Data Plane
Remember when we talked about traffic sessions and device configuration that second device must know when first device fails. This
information is exchanged between devices by the data plane. Data plane simply synchronizes the sessions and services between the
devices. Sessions are current information about the traffic flow. For example if a user is browsing Googles mail then the session is
maintained by the router. This session information is synchronized between devices. Now, to dive more deeper lets learn about some
JunOS High Availability concepts.
SRX HA Modes

Juniper SRX series device supports HA mode for redundancy. When it comes to serious networking, failure is not an option. So to get
the devices working you can configure pair of SRX devices in High Availability mode. Before getting to know about differences of
HA modes you should first have little knowledge of JunOS HA concepts. After knowing the concepts, you are now ready to learn
about deployment concepts. There are two types of HA modes; active-active and active-passive. There are some differences between
SRX HA modes.








SRX HA Modes
Active/Passive


In the figure there are two SRX 240 routers in a cluster named node 0 and node 1. In active/passive mode, the node 0 is actively
sending data traffic whereas the node 1 waits passively waiting for node 0 to fail. Upon failure of node 0, node 1 will pass traffic.
While node 0 is active, it actively synchronizes sessions to node 1. But not all information is synchronized. For example, if node 0
fails, while it was learning routes for OSPF then it may not be able to synchronize routes fully with router B. This is disadvantage of
this mode. In the figure above, there are two reth interfaces, reth 0 and reth 1 in same redundancy group 1. Reth 0 is for internet and
reth 1 is for internal network. Since the node 0 is the primary RE data traffic is passing through interface of node 0 only i.e. ge-0/0/0
and ge-0/0/3. This is active-passive.
In this mode, node 0 have full load of the traffic whereas node 1 is free. This mode is mostly used in medium sized networks where
traffic load balancing is not needed. This HA mode might have to tolerate some level of downtime because there is some risk in
implementing this mode. The risk is that the node 1 device might not function when node 0 fails since node 1 was not
sending/receiving traffic before. The device was idle for a long time and now the device has to pass the full traffic. This mode is also
used in network where administrators have few knowledge of the device so that troubleshooting is easier in the future.
Active/Active
In active/active mode both devices in HA simultaneously pass the traffic. This mode is similar to active/passive but configured twice.
The routers in cluster are active for their own redundancy group. Synchronization happens between both devices. The advantage of
this mode over active/passive is, passing traffic by backup router ensures that backup router is ready and correctly functioning.
Active/Active is great design because backup router is verified and traffic load is also shared between devices. But the downside of
this mode is that it may be difficult to troubleshoot since traffic is going through both devices. Administrators have to spend more time
looking for problem in both devices. This mode is used in network where 100% uptime is required despite of the complexity of the
troubleshooting.

In the above figure, there are two SRX 240 routers in cluster i.e. node 0 and node 1. In this mode, both routers are sending and
receiving traffic simultaneously. For interface reth 0 and reth 1, the redundancy group is 1 and for RG 1, the primary device is node 0.
Similarly, for interface reth 2 and reth 3, the redundancy group is 2 and for RG 2 the primary device is node 1. Now, we can say that
there are two active/passive mode configured in each device. After knowing about HA modes now you can configure high availabil











Configure High Availability Cluster in Juniper SRX


Juniper SRX series firewall provides high availability options for continuous service operation. There are different ways of
configuring high availability cluster in Juniper SRX. It is easy to configure high availability cluster in Juniper SRX. But before
configuring cluster you must understand some basics of SRX cluster and concepts.
Configure High Availability Cluster in Juniper SRX
Before typing commands for SRX cluster. There are some few important things that is to be done.
1. Upgrade all the SRX devices to latest Juniper recommended JunOS.
2. Backup and delete existing SRX configurations.
So, lets get started. There are different modes for SRX cluster deployments. Most popular is, active/active and active/passive. In this
post, I will show active/passive configuration. Steps to configure active/passive configuration are: -
3. Cluster ID and Node ID: Cluster ID is an identifier which identifies members in a cluster. For example, cluster 1 can have
two nodes or members. Node ID identifies or represents each member device in a cluster. For example, Node 0 is primary and
Node 1 is secondary device in a cluster.
4. Control link and Data link: Control link and data link are two important links in SRX cluster. Nodes in cluster use these link
to talk with each other about status of cluster and other traffic information. Control link is path to configur e devices in a cluster.
Data link allows session synchronization between nodes. Different SRX models have different control port set up. Table below
shows dedicated control ports.

5. Redundancy Groups : Redundancy groups or simply RG defines resources that are grouped from both nodes to be active or
passive.
6. Interfaces: Interfaces can be Reth (Redundant Ethernet) or local interfaces. Reth interfaces is created in cluster to configure
redundant links. You cant use local interfaces in redundancy groups.
The diagram below shows our basic network scenario. We will configure SRX 240 cluster in active passive mode.

Step 1: Enable Chassis Cluster (Configure Cluster ID and Node ID)
To enable chassis cluster in Node 0 type the following command.
root@SRXA> set chassis cluster cluster-id 1 node 0 reboot [This command will enable chassis cluster and make this device node
0] Successfully enabled chassis cluster. Going to reboot now
You can configure cluster ID from 0 to 15 in Juniper SRX. Similarly, enter following command in SRXB to enable cluster.
root@SRXB> set chassis cluster cluster-id 1 node 1 reboot [This command will enable chassis cluster and make this device node
1] Successfully enabled chassis cluster. Going to reboot now
After the reboot you will see a little change in the command prompt of both device. You will see following prompt in node 0.
{primary:node0}
root@SRXA>
So the cluster is enabled. To view the cluster status, type show chassis cluster status.
{primary:node0} root@SRXA> show chassis cluster status
Step 2: Configure Control Link and Data Link
Now lets configure control link and data link. Control link is configured by default. You just need to plug in the cables to ports of
both nodes. For SRX 240 control ports are ge-0/0/1 and ge-5/0/1. Plug in the cable in these ports and reboot node 1. After the reboot
type show chassis cluster status command. You will see primary and secondary for node 0 and node 1 devices respectively.
Data link can be configured on any remaining ports of the device. Here, I will configure data link on port ge-0/0/2 and ge-5/0/2. To
configure data link ports, special type of aggregated interface is configured. This special interface is called fab0 and fab1 for node 0
and node 1 respectively. To make these interfaces as data link type following commands in [edit interface] hierarchy.
{primary:node0}[edit interfaces]
root@SRXA# set fab0 fabric-options member-interfaces ge-0/0/2
{primary:node0}[edit interfaces]
root@SRXA# set fab1 fabric-options member-interfaces ge-5/0/2
Commit the configuration and plug the cables in these ports.
Step 3: Configure Redundancy Groups
Redundancy groups are most vital part of SRX clusters. Redundancy groups define resources to be active or passive. Redundancy
groups contain interfaces of both nodes. Interface of primary node 0 is the interface that pass the traffic. Redundancy group 0 is
created by default after cluster is configured. Similarly, control ports are assigned in redundancy group 0 by default. You can create up
to maximum of 129 redundancy groups in SRX cluster. Here we will create another redundancy group called redundancy group 1
making total of two redundancy groups in our SRX 240 cluster. Each redundancy group (RG) is configured with priority. Higher
priority takes precedence over lower priority. If you do not configure priority for redundancy group then priority of 1 is created by
default for primary node 0.
At first, lets configure priority for default redundancy group 0. Type following commands to configure priority for RG 0.
{primary:node0}[edit chassis cluster]
root@SRXA# set redundancy-group 0 node 0 priority 254
{primary:node0}[edit chassis cluster]
root@SRXA# set redundancy-group 0 node 1 priority 1
Now, to create new redundancy group 1, type following command.
{primary:node0}[edit chassis cluster]
root@SRXA# set redundancy-group 1 node 0 priority 254
{primary:node0}[edit chassis cluster]
root@SRXA# set redundancy-group 1 node 1 priority 1
Step 4: Configure Interfaces
We need to create Reth interfaces to configure redundant interfaces. Before creating Reth interfaces we need to define number of reth
interface to be created. As you can see in our scenario diagram, we will create Reth0 and Reth1 interfaces. So type following
commands to configure reth interfaces.
Defining number of Reth interfaces
{primary:node0}[edit chassis cluster]
root@SRXA# set reth-count 2
Configure Reth 0 interface
{primary:node0}[edit interfaces]
root@SRXA# set ge-0/0/3 gigether-options redundant-parent reth0
{primary:node0}[edit interfaces]
root@SRXA# set ge-5/0/3 gigether-options redundant-parent reth0
{primary:node0}[edit interfaces ]
root@SRXA# set reth0 redundant-ether-options redundancy-group 1
Configure Reth 1 interface
{primary:node0}[edit interfaces]
root@SRXA# set ge-0/0/4 gigether-options redundant-parent reth1
{primary:node0}[edit interfaces]
root@SRXA# set ge-5/0/4 gigether-options redundant-parent reth1
{primary:node0}[edit interfaces ]
root@SRXA# set reth1 redundant-ether-options redundancy-group 1
You can view interfaces by typing following commands.
{primary:node0}
root@SRXA> show chassis cluster interfaces {primary:node0}
root@SRXA> show interfaces terse | match reth
This is how you can configure high availability in Juniper SRX devices.












Configure IP Monitoring in SRX Cluster

There might be case in our network where we want to fail-over to secondary node when the Internet connection breaks or link breaks.
In Juniper SRX cluster, you can configure fail-over in a way that if a specified IP address is unreachable then failover is initiated.
Interface monitor feature configured in redundancy group is unable to accomplish such failover, so there is other feature called IP
monitor. IP monitoring allows you to monitor specific IP address and when the specified IP address is unreachable, the fail-over is
initiated. You can easily configure IP monitoring in SRX cluster. Generally, the IP to be monitored is the gateway IP address.
Configure IP Monitoring in SRX Cluster
In our scenario, we have active/passive SRX cluster configured already. As seen in the diagram below, we have SRX node 0 as
primary and node 1 as secondary. The public IP address configured on Reth0 is 2.2.2.2/29 and the gateway is 2.2.2.1 to reach the
Internet. In case as shown below if one of the internet link between switch and ISP fails, then the Internet connection will not be
available. So IP monitoring feature must be configured in order to switch the SRX cluster node if one of the link between switch and
Internet fails.

The SRX redundancy groups configuration looks like this,
{primary:node0}[edit chassis cluster] root@SRX_NODE01# show
control-link-recovery;
reth-count 3;
redundancy-group 0 { node 0 priority 254; node 1 priority 1; }
redundancy-group 1 { node 0 priority 200; node 1 priority 150; gratuitous-arp-count 15; interface-monitor { ge-0/0/3 weight
255; ge-5/0/3 weight 255; ge-0/0/4 weight 255;
ge-5/0/4 weight 255; } }
Now, lets configure IP Monitoring. Our goal is to configure SRX node failover such that if primary Internet link betwee n switch and
ISP fails, then node 1 will be primary node for redundancy group 1 and Internet traffic will pass from secondary link.
{primary:node0}[edit chassis cluster]
root@SRXNODE01# set redundancy-group 1 ip-monitoring global-weight 255 [This command will set global weight of 255]
{primary:node0}[edit chassis cluster]
root@SRXNODE01# set redundancy-group 1 ip-monitoring global-threshold 80 [This command will set global threshold of 80]
{primary:node0}[edit chassis cluster]
root@SRXNODE01# set redundancy-group 1 ip-monitoring retry-interval 3 [This command will set retry interval of 3 seconds.
This means the device will ping the monitored IP once every 3 seconds.]
{primary:node0}[edit chassis cluster]
root@SRXNODE01# set redundancy-group 1 ip-monitoring retry-count 6 [This command will set retry count of 6 times. If the
gateway is unreachable, the device will ping 6 times every 3 seconds before it declares the monitored IP address is unreachable. So the
wait is total 18 seconds.]
{primary:node0}[edit chassis cluster]
root@SRXNODE01# set redundancy-group 1 ip-monitoring family inet 2.2.2.1 weight 80 [This is the monitored IP address.
This IP is generally the gateway IP address. If the gateway address is declared unreachable, then this weight is deducted from global-
threshold weight. So, if the result is 0 then failover is initiated, otherwise not. In our case, failover is initiated.]
{primary:node0}[edit chassis cluster]
root@SRXNODE01# set redundancy-group 1 ip-monitoring family inet 2.2.2.1 interface reth0.0 secondary-ip-address 2.2.2.3 [This
command sets the source Reth interface that will send the Ping requests, and also sets the secondary IP address that will be used as
source IP addres for secondary node while pinging the monitored IP address.]
To view the configuration type show under the same hierarchy.
{primary:node0}[edit chassis cluster] root@SRX_NODE01# show
control-link-recovery;
reth-count 3;
redundancy-group 0 { node 0 priority 254; node 1 priority 1; }
redundancy-group 1 { node 0 priority 200; node 1 priority 150; gratuitous-arp-count 15; interface- monitor { ge-0/0/3 weight 255; ge-
5/0/3 weight 255; ge-0/0/4 weight 255;
ge-5/0/4 weight 255; } ip-monitoring { global-weight 255;
global-threshold 80;
retry-interval 3;
retry-count 6;
family { inet { 2.2.2.1{ weight 80; interface reth0.0 secondary-ip-address 2.2.2.3; } } } } }
Now commit the configuration.
To view the IP monitoring status type the following command.
{primary:node0}
root@SRXNODE01> show chassis cluster ip-monitoring status redundancy-group 1
node0:
--------------------------------------------------------------------------
Redundancy group: 1
IP address Status Failure count Reason
2.2.2.1 reachable 0 n/a
node1:
--------------------------------------------------------------------------
Redundancy group: 1
IP address Status Failure count Reason
2.2.2.1 reachable 0 n/a

As you can see node 0 and node 1 is reachable. Now, in our scenario, if the primary Internet link between switch and ISP fails, then
node1 will become primary for the chassis cluster and the Internet traffic will now be sent by node 1 via secondary Internet link. In
this way you can configure IP monitoring in SRX Cluster depending upon your scenario.
Configure Filter Based Load Balancing in Juniper SRX
There are various tricks to configure load balancing in JunOS devices. Filter based forwarding and per flow load balancing methods
are quite popular. These type of load balancing can be configured in many Juniper devices like, MX series, J series, SRX series, etc.
Here, I will show steps to configure filter based load balancing in Juniper SRX device. In filter based forwarding, two routing tables
are configured. Each table will have different ISP as their primary gateway and remaining opposite ISP as secondary gateway.




Configure Filter Based Load Balancing in Juniper SRX
We want to balance the traffic coming from internal network to the Internet using both ISP links. At first, we need to create two
routing tables. Then, create firewall filter and create RIB groups. I will show the step by step process of the configuration. Below
shown diagram is our scenario. We have two ISP links and two internal networks. We want to route 192.168.1.0/24 network via ISP A
and ISP B will be the backup. Similarly, route 192.168.2.0/24 via ISP B and ISP A will be its backup.

Step 1: Create Routing Tables
At first, lets create some routing tables. We need to create two routing tables. Routing tables are configured under [edit routing-
instances] hierarchy. We will create routing tables named ISPA and ISPB.
[edit routing-instances] root@SRX# set ISPA instance-type forwarding [edit routing-instances] root@SRX# set ISPA routing-
options static route 0.0.0.0/0 next-hop 1.1.1.1 [edit routing-instances] root@SRX# set ISPA routing-options static route
0.0.0.0/0 qualified-next-hop 2.2.2.1 preference 7
Type show to view the configuration.
[edit routing-instances] root@SRX# show ISPA { instance-type forwarding; routing-options { static { route 0.0.0.0/0 { next-hop
1.1.1.1; qualified-next-hop 2.2.2.1 { preference 7; } } } } }
Now lets configure ISPB routing instance.
[edit routing-instances] root@SRX# set ISPB instance-type forwarding [edit routing-instances] root@SRX# set ISPB routing-
options static route 0.0.0.0/0 next-hop 2.2.2.1 [edit routing-instances] root@SRX# set ISPB routing-options static route
0.0.0.0/0 qualified-next-hop 1.1.1.1 preference 7
Type show to view the configuration.
[edit routing-instances] root@SRX# show ISPB{ instance-type forwarding; routing-options { static { route 0.0.0.0/0 { next-hop
2.2.2.1; qualified-next-hop 1.1.1.1 { preference 7; } } } } }
Step 2: Create Firewall Filters
Now, lets create firewall filters.
[edit firewall family inet] root@SRX# set filter ISPA-FILTER term FOR-ISPA from source-address 192.168.1.0/24 [edit
firewall family inet] root@SRX# set filter ISPA-FILTER term FOR-ISPA then routing-instance ISPA [edit firewall family
inet] root@SRX# set filter ISPB-FILTER term FOR-ISPB from source-address 192.168.2.0/24 [edit firewall family inet]
root@SRX# set filter ISPB-FILTER term FOR-ISPB then routing-instance ISPB
Type show to view the firewall filter.
[edit firewall family inet] root@SRX# show filter ISPA-FILTER { term FOR-ISPA { from { source-address { 192.168.1.0/24; } }
then { routing-instance ISPA; } } } filter ISPB-FILTER { term FOR-ISPB { from { source-address { 192.168.2.0/24; } } then
{ routing-instance ISPB; } } }
Now apply the filter in for each internal interface.
[edit interface] root@SRX# set ge-0/0/2 unit 0 family inet filter input ISPA-FILTER [edit interface] root@SRX# set ge-0/0/3
unit 0 family inet filter input ISPB-FILTER [edit interface] root@SRX# show ge-0/0/2 { unit 0 { family inet { filter { input
ISPA-FILTER; } address 192.168.1.1/24; } } } ge-0/0/3 { unit 0 { family inet { filter { input ISPB-FILTER; } address
192.168.2.1/24; } } }
Step 3: Create RIB Group
RIB (Routing Information Base) group is created to share route information from master routing table to other custom routing tables.
For inet family, master routing table is inet.o. As of now, routing tables ISPA and ISPB only knows the routes that have been
configured while creating the routing instance. That is, the default route only. We need to copy all the routes from inet.0 to ISPA and
ISPB routing tables to make the routing work properly. RIB group is configured under [edit routing-instances] hierarchy.
[edit routing-instances] root@SRX# set rib-groups LOAD-BALANCE-RIB import-rib inet.0 [edit routing-instances]
root@SRX# set rib-groups LOAD-BALANCE-RIB import-rib ISPA.inet.0 [edit routing-instances] root@SRX# set rib-groups
LOAD-BALANCE-RIB import-rib ISPB.inet.0 [edit routing-instances] root@SRX# show rib-groups { LOAD-BALANCE-
RIB { import-rib [ inet.0 ISPA.inet.0 ISPB.inet.0 ]; } }
You can verify the configuration by running traceroute from client PC in both network. You can also check the routing tables. To view
the routing tables, type
root@SRX> show route table ISPA.inet.0
Load Balance Dual ISP Internet in Juniper SRX
There are different methods for load balancing internet traffic in Juniper SRX series devices. Two of them are per flow load balancing
and filter based load balancing. You can use any method to load balance dual ISP internet in Juniper SRX or MX series or J series
devices. Here, I will load balance dual ISP internet in Juniper SRX device using per flow load balancing method.
Load Balance Dual ISP Internet in Juniper SRX
The diagram below shows our existing scenario. We have two ISPs that we want to load balance the internet traffic to. Two internet
links are in UNTRUST zone whereas the internal network is in TRUST zone. I have already configured required security policies.

The first step is to define routing policy. Configure the following policy under [edit-policy-options] hierarchy.
[edit policy-options]
root@SRX240# set policy-statement LOAD-BALANCE then load-balance per-packet [Here, from clause is not used, so it
means from any source then load-balance per-packet.] [edit policy-options]
root@SRX240# show
policy-statement LOAD-BALANCE { then { load-balance per-packet; } }
The second step is to configure the routing option. Configure the following routing information under [edit routing-options]
hierarchy.
[edit routing-options]
root@SRX240# set static route 0.0.0.0/0 next-hop 1.1.1.1
[edit routing-options]
root@SRX240# set static route 0.0.0.0/0 next-hop 2.2.2.1
Now, configure the routing policy called LOAD-BALANCE under the routing option.
[edit routing-options]
root@SRX240#set forwarding-table export LOAD-BALANCE
Type show command to view the configuration.
[edit routing-options]
root@SRX# show static { route 0.0.0.0/0 next-hop [ 1.1.1.1 2.2.2.1 ]; }
forwarding-table { export LOAD-BALANCE; }
You can now view route forwarding table to verify.
root@SRX> show route forwarding-table
You will see two next-hop MAC addresses for default destination network.
By default JunOS include only layer 3 IP address to determine the flow but you can change this behavior and include both layer 3 and
layer 4 information. To do so, hit the following command under [edit forwarding-options] hierarchy.
[edit forwarding-options]
root@SRX#set hash-key family inet layer-3
[edit forwarding-options]
root@SRX# set hash-key family inet layer-4 [edit forwarding-options]
root@SRX# show hash-key {
family inet { layer-3;
layer-4;
} }
You can now see the logs or even do tracert from client PC and test the load sharing. You can test from a single PC in the network.







Configure Dual ISP Link Failover in Juniper SRX
If you have two ISPs or two different links for same destination, then you can configure floating static route. Floating static route
allows you to failover the link if the primary link fails. This is accomplished by using preference and qualified- next hop feature
available in JunOS operating system. To configure dual ISP link failover in Juniper SRX you need two ISP links. This technique is not
just for ISP links. You can apply this technique to any dual link scenario that have same destination network. SRX series, MX series
and J series devices are mostly used in these types of scenario.
Configure Dual ISP Link Failover in Juniper SRX
Below is our scenario. We have two ISPs, ISP A and ISP B. What we want to accomplish is, if primary ISPs link fail, then switch the
link through secondary link to ISP B. So, lets get started.

We need to configure the routing table under [routing-options] hierarchy.
[edit routing-options] user@SRX240# set static route 0.0.0.0/0 next-hop 1.1.1.1 preference 5 [Next hop 1.1.1.1 is the primary
next-hop for 0.0.0.0/0 destination network. Note, 0.0.0.0/0 means default gateway. Preference 5 is the default preference for static
routes. Even if you don' t put preference 5 in this command, it is automatically there.] [edit routing-options] user@SRX240# set
static route 0.0.0.0/0 qualified-next-hop 2.2.2.1 preference 7 [Now next- hop 2.2.2.1 is the secondary next- hop for 0.0.0.0/0 network.
It has the preference of 7. If the primary link is to go down, this link will be the gateway for the default route.] [edit routing-options]
user@SRX240# show static { route 0.0.0.0/0 { next-hop 1.1.1.1; qualified-next-hop 2.2.2.1 {
preference 7; } preference 5;
} }
In this way you can configure floating static route in JunOS systems.