Home | Articles | About | Contact | Forum |
Tuesday, March 19, 2024



Lunarpages.com Web Hosting

Mailing List

E-mail:
By Joining the mailing list you will be notified of site updates.


Show Your Support For
This Site By Donating:











Audience: Network Admins
Last Updated: 9/6/2013 5:32:02 PM
**All times are EST**





HOWTO - Juniper SRX Cluster Configuration

By Erik Rodriguez

Tags: Juniper SRX Cluster, JunOS cluster config, Juniper HA pair, Juniper SRX550 cluster

This article provides a step by step guide to creating an active-passive cluster between two SRX550 firewalls. This configuration will vary slightly between models, but the steps are same regardless.

Requirements

You will need conole access to both devices. Some commands will be entered on one or both firewalls which is indicated throughout the article. If you have performed any cluster configurations previously, enter the following commands on each (notice the hostnames) device via console from cli mode:

root@srx-primary> set chassis cluster cluster-id 0 node 0 reboot
root@srx-secondary> set chassis cluster cluster-id 0 node 1 reboot


Each device will reboot and once they return, enter the following from configuration mode, load the factory default configuration and set a root password:

root# load factory-default
warning: activating factory configuration

[edit] root# set system root-authentication plain-text-password
New password:
Retype new password:

[edit] root# commit
commit complete


At this point, we should have a factory default configuration. We will need to remove some things to get the system ready for cluster configuration. We will need to delete the interfaces to be used by the cluster and any security zones, and vlans. From configuration mode:

root# delete vlans 

[edit]
root# delete interfaces vlan 

[edit]
root# delete interfaces ge-0/0/1.0 family ethernet-switching 

[edit]
root# delete interfaces ge-0/0/2.0 family ethernet-switching    

[edit]
root# delete interfaces ge-0/0/3.0 family ethernet-switching    

[edit]
root# delete interfaces ge-0/0/4.0 family ethernet-switching    

[edit]
root# delete interfaces ge-0/0/5.0 family ethernet-switching    

[edit]

root# delete interfaces ge-0/0/0    

[edit]

root# delete interfaces ge-0/0/1

[edit]

root# delete interfaces ge-0/0/2    

[edit]

root# delete security 

[edit]
root# commit 
commit complete


REMEMBER TO SWITCH YOU CONSOLE CABLE TO THE SECONDARY FIREWALL AND COMPLETE THE SAME STEPS. After you done, switch your console cable back to the primary firewall.



Since we have no interfaces configured, we can now start configuring the cluster and assigning the ports needed for cluster to communicate. I am using the SRX 550, so the interfaces used will be onboard interfaces ge-0/0/1 and ge-0/0/2. Once the devices are in cluster mode they will change.

Next, we will start the cluster configuration, your cluster-id will be 1 and your nodes will be 0 and 1 accordingly. DO NOT USE a cluster ID of 0, as it will disable clustering. Only use 1 or higher. You will need to console to each devices to issue these commands. On your primary firewall via console in cli mode but NOT configure mode:

root> set chassis cluster cluster-id 1 node 0 reboot
Successfully enabled chassis cluster. Going to reboot now


The device will reboot, switch your console cable to your secondary firewall:

root> set chassis cluster cluster-id 1 node 1 reboot
Successfully enabled chassis cluster. Going to reboot now


Both devices will reboot. Now look at the firewalls units, you will now notice the HA light on the front of each is now red. That is because the devices are clustered but cannot communicate with eachother. You can verify this from the primary node via console issue this command:

root> show chassis cluster status  
Cluster ID: 1 
Node                  Priority          Status    Preempt  Manual failover

Redundancy group: 0 , Failover count: 1
    node0                   1           primary        no       no  
    node1                   0           lost           n/a      n/a 

{primary:node0}


Once you plug in two cables between the firewalls (straight-through cables), your HA light should turn green. You will also see activity on ports ge-0/0/1. Run the command again:

root> show chassis cluster status   
Cluster ID: 1 
Node                  Priority          Status    Preempt  Manual failover

Redundancy group: 0 , Failover count: 1
    node0                   1           primary        no       no  
    node1                   1           secondary-hold no       no  

{primary:node0}


Next, we will set hostnames for each device, you will not need to switch the console cable any longer. The primary node will will transfer the configuration onces the cluster interfaces come up. Next we will setup the hostnames for each device and a network range for communication between the two devices. This network will only be used for communication betwee the clusters and nowhere else on your network(s).

root# set groups node0 system host-name srx.rdv-primary   
{primary:node0}[edit]

root# set groups node0 interfaces fxp0 unit 0 family inet address 192.168.168.1/24                
{primary:node0}[edit]

root# set groups node1 system host-name srx.rdv-secondary 

{primary:node0}[edit]
root# set groups node1 interfaces fxp0 unit 0 family inet address 192.168.168.2/24

{primary:node0}[edit]

root# set apply-groups "${node}"

{primary:node0}[edit]
root# commit 
node0: 
configuration check succeeds
node1: 
commit complete
node0: 
commit complete

{primary:node0}[edit]


Notice when we commit those changes the system pushes the config to each node. Now that the cluster is working, you will notice the interface names have changed. My SRX550s each have a 16-port PIM in addition to the 10 native ports. THe interfaces will be renamed as following:

The native ports ge-0/0/x (on the primary) remain the same while secondary device will change those interfaces to ge-3/0/x. The 16-port PIMs will be named ge-9/0/x (on the primary) and ge-12/0/x (on the secondary). You can view the interface names buy running the following command (some results omitted):

root@srx.rdv-primary# run show interfaces terse 
Interface               Admin Link Proto    Local                 Remote
ge-0/0/0                up    down
gr-0/0/0                up    up
ip-0/0/0                up    up
ge-0/0/1                up    up
ge-0/0/2                up    up
ge-0/0/3                up    down
ge-0/0/3.0              up    down
ge-0/0/4                up    down
ge-0/0/4.0              up    down
ge-0/0/5                up    down
ge-0/0/5.0              up    down
ge-0/0/6                up    down
ge-0/0/7                up    down
ge-0/0/8                up    down
ge-0/0/9                up    down
ge-3/0/0                up    down
---- omitted ----
ge-3/0/9                up    down
ge-3/0/10               up    down
ge-3/0/11               up    down
---- omitted ----
ge-3/0/15               up    down
ge-9/0/0                up    down
---- omitted ----
ge-9/0/9                up    down
ge-12/0/0               up    down
---- omitted ----
ge-12/0/14              up    down
ge-12/0/15              up    down


Next we will configure the fabric links for each device. You will need to speicify the correct interfaces that will be used here and they differ from model to model. I am using the SRX550 so they are ge-0/0/2 and ge-9/0/2 (from the native ports on the SRX).

root@srx.rdv-primary# set interfaces fab0 fabric-options member-interfaces ge-0/0/2   

{primary:node0}[edit]
root@srx.rdv-primary# set interfaces fab1 fabric-options member-interfaces ge-9/0/2

{primary:node0}[edit]

root@srx.rdv-primary# commit 
node0: 
configuration check succeeds
node1: 
commit complete
node0: 
commit complete

{primary:node0}[edit]



Once commited, we will view the status by running the following command:

root@srx.rdv-primary# run show chassis cluster data-plane interfaces 
fab0:

    Name               Status      
                       (Physical/Monitored)
    ge-0/0/2           Up   / Up        
fab1:

    Name               Status      
                       (Physical/Monitored)
    ge-9/0/2           Up   / Up        

{primary:node0}[edit]


NOTE: you may need to reboot both devices for this to come up correctly. Sometimes when configuring these I know the configuration is correct but they don't show as up/up. Try a reboot of the devices before troubleshooting further if needed.

Now that we have those created, we will need to some redundancy groups. You will need at least 2 of them. One will be dedicated to the control plane, and the other will serve as a host for any and all redundant interfaces.

root@srx.rdv-primary# set chassis cluster reth-count 2   

{primary:node0}[edit]
root@srx.rdv-primary# set chassis cluster redundancy-group 0 node 0 priority 100

{primary:node0}[edit]

root@srx.rdv-primary# set chassis cluster redundancy-group 0 node 1 priority 99

{primary:node0}[edit]

root@srx.rdv-primary# set chassis cluster redundancy-group 1 node 0 priority 100

{primary:node0}[edit]

root@srx.rdv-primary# set chassis cluster redundancy-group 1 node 1 priority 99

{primary:node0}[edit]

root@srx.rdv-primary# set chassis cluster redundancy-group 1 preempt

{primary:node0}[edit]

root@srx.rdv-primary# commit 
node0: 
configuration check succeeds
node1: 
commit complete
node0: 
commit complete

{primary:node0}[edit]


Let's verify our configuration using the following command:

root@srx.rdv-primary# run show configuration chassis cluster     
reth-count 2;
redundancy-group 1 {
    node 0 priority 100;
    node 1 priority 99;
    preempt;
}
redundancy-group 0 {
    node 0 priority 100;
    node 1 priority 99;
}

{primary:node0}[edit]


Now that we have the redundancy groups setup we can assign interfaces to them. We will need to create redundant intefaces (reth) and then assign regular interfaces as members of the reth. For this example I will configure the first ports on my 16-port PIM which are ge-9/0/0 and ge-12/0/0

root@srx.rdv-primary# set interfaces reth0 redundant-ether-options redundancy-group 1  

{primary:node0}[edit]

root@srx.rdv-primary# set interfaces reth0 unit 0 family inet address 172.16.0.108/16 

{primary:node0}[edit]

root@srx.rdv-primary# set interfaces ge-3/0/0 gigether-options redundant-parent reth0

{primary:node0}[edit]

root@srx.rdv-primary# set interfaces ge-12/0/0 gigether-options redundant-parent reth0

{primary:node0}[edit]
root@srx.rdv-primary# commit 
node0: 
configuration check succeeds
node1: 
commit complete
node0: 
commit complete

{primary:node0}[edit]


Now that we have a redundant interface (reth0) we can now apply that to our redundancy group as an interface monitor:

root@srx.rdv-primary# set chassis cluster redundancy-group 1 interface-monitor reth0 weight 255

{primary:node0}[edit]

root@srx.rdv-primary# commit 
node0: 
configuration check succeeds
node1: 
commit complete
node0: 
commit complete

{primary:node0}[edit]


If you don't have the interfaces connected to anything, you should now see the HA light on the firewalls turn amber. This is because the interface is configured, but not active. Once you plug them into a switch or device the HA lights will turn green again.

Repeat this process for any other redundant interfaces you wish to create. Remember to only use redundancy group 1 and NOT group 0. Apply security zones to reth interfaces just as you would with standard interface configurations.

Contact Us

If you found this information useful, click the +1 button



Your E-mail:


Subject:


Type verification image:
verification image, type it in the box

Message:


NOTE: this form DOES NOT e-mail this article, it sends feedback to the author.


TCP vs. UDP
Juniper SRX anti-spam filtering config
Windows Server 2008 Clustering Configuration
Windows 2008 R2 Network Load Balancing (NLB)
Extreme Networks: Downloading new software image
Juniper SRX save config to USB drive
Juniper SRX logout sessions
Extreme Networks Syslog Configuration
Command line drive mapping
Neoscale vs. Decru
Data Security vs. Data Protection
Juniper SRX Cluster Configuration
HOWTO - Create VLAN on Extreme Switch
Using a Non-local Colocation Facility
Linux Server Administration
IT Chop Shops
Flow Viewers: SFLOW, NetFLOW, and JFLOW
Exchange 2007 Back Pressure
IPtables open port for specific IP
Politics in IT Departments
HOWTO - Block Dropbox
Cisco IOS Cheat Sheet
Subnet Cheat Sheet
Design a DMZ Network
How DNS works
Firewall Configuration
Juniper SSG Firewalls
Server Management
Configuring VLANs
Runlevels in Linux
Server Clustering
SONET Networks
The Red Hat Network
Server Colocation
Complicated Linux Servers
Dark Fiber
Data Center Network Design
Firewall Types
Colocation Bandwidth






Copyright © 2002-2016 Skullbox.Net All Rights Reserved.
A division of Orlando Tech Works, LLC
By using this site you agree to its Terms and Conditions.
Contact Erik Rodriguez