For When You Can't Have The Real Thing
[ start | index | login ]
start > Juniper > SRX240 > Clustering

Clustering

Created by dave. Last edited by dave, 6 years and 330 days ago. Viewed 10,292 times. #7
[diff] [history] [edit] [rdf]
labels
attachments

SRX240 Clustering

(17 January 2012)

Just following the cook book at >>Juniper KB 15504 is incomplete in some key areas. The main problem is that the out-of-the-box settings for JunOS 10.x (up to 10.4 which is what arrived on my most recent set of SRXs) conflict with the proposed clustering setup.

(You've probably arrived here after trying the cookbook and had problems. Sorry about that.)

Anyways, this is what I did the second time around to get clustering going from more-or-less stock (first I upgraded one of the SRXs to have the same firmware that the first one did).

Before you get going on this, read about fxp0 Addressing

# On each node, set root password
set system root-authentication plain-text-password

# On each node, turn off ethernet-switching delete vlans delete interfaces vlan # this next line doesn't work on my srx240s delete interfaces interface-range interfaces-trust # these ones work delete security zones security-zone trust interfaces delete interfaces ge-0/0/1 unit 0 family ethernet-switching delete interfaces ge-0/0/2 unit 0 family ethernet-switching delete interfaces ge-0/0/3 unit 0 family ethernet-switching delete interfaces ge-0/0/4 unit 0 family ethernet-switching delete interfaces ge-0/0/5 unit 0 family ethernet-switching delete interfaces ge-0/0/6 unit 0 family ethernet-switching delete interfaces ge-0/0/7 unit 0 family ethernet-switching delete interfaces ge-0/0/8 unit 0 family ethernet-switching delete interfaces ge-0/0/9 unit 0 family ethernet-switching delete interfaces ge-0/0/10 unit 0 family ethernet-switching delete interfaces ge-0/0/11 unit 0 family ethernet-switching delete interfaces ge-0/0/12 unit 0 family ethernet-switching delete interfaces ge-0/0/13 unit 0 family ethernet-switching delete interfaces ge-0/0/14 unit 0 family ethernet-switching delete interfaces ge-0/0/15 unit 0 family ethernet-switching

# on each node, you have to delete the first two ports entirely so that they can be redefined for HA: delete interface ge-0/0/0 delete interface ge-0/0/1

# on each node, you have to clean up ge-0/0/2 to permit fabric definition: delete interface ge-0/0/2.0

# on each node, you have to clean up the switching configuration that the default leaves behind: delete system service dhcp delete security

# commit commit

# on node A only: set chassis cluster cluster-id 1 node 0 reboot

# on node B only: set chassis cluster cluster-id 1 node 1 reboot

# If all goes well, you should be able to connect ge-0/0/1 on both devices and the HA # light will go green after a short delay. # From here you should be able to make changes to unit0 and have them propagate back to unit1 on commit.

# If you need to talk to node 1 directly (ie for software upgrades):

request routing-engine login node 1

# Things that need doing:

# Cluster name:

set system host-name srx240-cluster

# Set up fxp0 on both nodes: # beware! fxp0 can't exist on a network that will be reachable via routes or directly from other # interfaces! If fxp0 and reth0 are on the same subnet, you won't be able to route to/from reth0! # This means that you have to set up fxp0 on a private out-of-band network!

set group node0 system host-name srx240-node0 set group node0 interfaces fxp0 unit 0 family inet address 192.168.1.1/24 set group node1 system host-name srx240-node1 set group node1 interfaces fxp0 unit 0 family inet address 192.168.1.2/24

# This magic splits the groups so that node-specific configs only go to that node at commit time:

set apply-groups "${node}"

# Create the fabric links (data plane, RTO sync, et)

set interfaces fab0 fabric-options member-interfaces ge-0/0/2 set interfaces fab1 fabric-options member-interfaces ge-5/0/2

# Setup redundancy-group 0 for the routing engine:

set chassis cluster redundancy-group 0 node 0 priority 100 set chassis cluster redundancy-group 0 node 1 priority 1

# Redundancy-group 1 is for our interfaces:

set chassis cluster redundancy-group 1 node 0 priority 100 set chassis cluster redundancy-group 1 node 1 priority 1

# We're following the example on the web, kinda: # ge-0/0/5 and 5/0/5 will be reth0 in zone trust # ge-0/0/6 and 5/0/6 will be reth1 in zone untrust # ge-0/0/7 and 5/0/7 will be reth2 in zone untrust

# First: tell the cluster how many redundant ethernet interfaces we are setting:

set chassis cluster reth-count 3

# For each reth: first set interface monitoring in redundancy group 1:

set chassis cluster redundancy-group 1 interface-monitor ge-0/0/5 weight 255 set chassis cluster redundancy-group 1 interface-monitor ge-5/0/5 weight 255

# If you are following this cook-book, you probably have to clear the # defined unit from the interface on node 0:

delete interfaces ge-0/0/5 unit 0

# (you don't have to do this for 5/0/5 because it isn't actually defined # in the config at this point.)

# Glue the interfaces together into the reth:

set interfaces ge-0/0/5 gigether-options redundant-parent reth0 set interfaces ge-5/0/5 gigether-options redundant-parent reth0

# Put the reth into the redundancy group:

set interfaces reth0 redundant-ether-options redundancy-group 1

# IP and security zone:

set interfaces reth0.0 family inet address 192.168.99.1/24 set security zones security-zone trust interfaces reth0.0

# Repeat for reth1 (ge-0/0/6 and ge-5/0/6) and reth2 (ge-0/0/7 and ge-5/0/7) # differences for me:

set security zones security-zone untrust interfaces reth1.0 set security zones security-zone untrust interfaces reth2.0

# Now you should be able to commit:

commit

# Enable web management on reth0:

set security zones security-zone trust interfaces reth0 host-inbound-traffic system-services ssh set security zones security-zone trust interfaces reth0 host-inbound-traffic system-services https set system services web-management https interface reth0.0 commit

You should be able to do the following:

  • connect ge-0/0/2 on both nodes together with an ethernet cable
  • plug all of ge-0/0/5, 6, and 7 into the appropriate ethernet switches
...and your HA lights should go green again.

(Now that you've done this, you probably want to read Cluster Failover which shows an example of playing with failover.)

The example on the web is perhaps a bit confusing to my mind:

  • it uses ge-0/0/5 and 0/0/6 without commenting on 0/0/4 (which is the first interface on the next physical block after the clustering pieces are done)
  • it uses ge-0/0/5 with 5/0/5 as reth1, and 0/0/6 with 5/0/6 as reth0, so that mixes up the physical ordering (reth1 is before reth0 which is counter-intuitive)
I kept the starting-at-0/0/5 because I didn't think before I started, but I fixed the ordering problem.

Previous Entry

Important: read and follow >>http://www.juniper.net/techpubs/software/junos-security/junos-security10.1/junos-security-swconfig-security/topic-43896.html before trying to set up clustering!

Starting with JUNOS Release 10.0, the factory default configuration for SRX100, SRX210, and SRX240 devices automatically enables Layer 2 Ethernet switching. Because Layer 2 Ethernet switching is not supported in chassis cluster mode, for these devices, if you use the factory default configuration, you must delete the Ethernet switching configuration before you enable chassis clustering.

Setup

Follow >>Juniper KB 15504

This should result in a configuration of:

  • ge0/0/0 on both systems being management ports for the individual firewalls
  • ge0/0/1 on both systems connected to each other
  • ge0/0/2 on both systems connected to each other
  • ge0/0/5 on both systems as re1 (redundant ethernet 1) or the shared "Trust" interface
  • ge0/0/6 on both systems as re0 (or the shared "Untrust" interface)

Checking

Commands to check the health of the cluster:

  • show chassis cluster status
  • show chassis cluster interfaces
  • show chassis cluster statistics
  • show chassis cluster control-plane statistics
  • show chassis cluster data-plane statistics
  • show chassis cluster status redundancy-group <rg number>

Unclustering

  • set chassis cluster disable reboot
no comments | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful:


snipsnap.org | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt