In this blog post, I\u2019ll show the easy steps to set up a screenOS based active\/passive cluster. I\u2019m not going to discuss the configuration of active\/active clusters because, in my opinion, this configuration is only needed in rare circumstances and may introduce some weird behaviour issues. Furthermore, active\/passive clusters have been working quite well for me.<\/p>\n
These are the main requirements to set up a cluster :<\/p>\n
In addition to this, you\u2019ll need additional IP addresses because you will need to set separate management IP addresses on both devices. This will not only allow you to connect to each device separately, but it is also a requirement for track-ip (when used) and for the cluster to operate properly. These management IP\u2019s are not replicated between devices. Login banners are not replicated either.<\/p>\n
In fact, I usually put separate management IP\u2019s on every interface that has management enabled. The interface IP will be the same on each cluster member so you\u2019ll only need one IP per interface.<\/p>\n
The procedures below are based on screenOS 6.2, but it should work with earlier versions as well.<\/p>\n
<\/p>\n
Before looking at the configuration steps, I need to explain some cluster terminology :<\/p>\n
<\/p>\n
When you want to build an A\/P cluster, you need a single VSD. With older versions of screenOS, you could not synchronise dynamic routing between the devices, so you needed to set up a VSD-Less cluster. With screenOS 6 and up, this is no longer needed. Routing entries (both static and dynamic) can be synchronized as well. The static routes will simply be put in the RIB as static routes, the dynamic routes will be marked with a trailing \u2018B\u2019 (Backup route). So OSPF routes will be displayed as \u201cOB\u201d, iBGP will be displayed as \u201ciBB\u201d, eBGP will be displayed as \u201ceBB\u201d and so on<\/p>\n
<\/p>\n
Before looking at the configuration steps, it\u2019s important to know that you can convert a fully working firewall into a cluster without any downtime. You don\u2019t need to reboot. You just have to make sure all interfaces on both devices are used for the same zone\/link\/\u2026<\/p>\n
First, pick the interface on both devices to be used as HA link. Let\u2019s say you want to use eth0\/6 for HA. So on both cluster devices, put this interfaces in nsrp mode :<\/p>\n
set nsrp interface<\/span> eth0\/6<\/pre>\n<\/div>\n(on some devices, you need to put the interface in the HA zone instead : set int e0\/6 zone HA)<\/p>\n
Set up master device<\/h4>\n
Next, create the cluster on the first device. We will create a cluster id 1, name it \u201cMyCluster1\u201d and set some cluster parameters.<\/p>\n
\nset nsrp cluster id 1\nset nsrp cluster name MyCluster1\nset nsrp arp 5\nset nsrp auth password MyAuthPassword\nset nsrp encrypt password MyEncryptionKey<\/pre>\n<\/div>\n\nWhen you enter the \u201cset nsrp cluster id 1\u201d, you will get the message \u201cUnit becomes master of NSRP vsd-group 0\u201d. The prompt now indicates that the device is master (M)<\/p>\n
As soon as you enter the \u201cset nsrp cluster name\u201d command, the command prompt will also indicate the cluster name. On the master device, the prompt will look like this :<\/p>\n
MyCluster1:hostname(M)-><\/strong><\/p>\nOn a backup device, you\u2019ll see MyCluster1:hostname(B)-><\/strong><\/p>\nThe arp, auth and encrypt statements are optional. The \u201carp\u201d statement refers to the number of gratuitous arp messages that need to be sent upon failover. The default is 4.<\/p>\n<\/blockquote>\n
In the current setup, the device can failover when the other device goes down. If you want devices to failover when interfaces go down, you need to set interface monitoring :<\/p>\n
\nset nsrp monitor interface<\/span> eth0\/1<\/pre>\n<\/div>\nThis is optional and is only required if you want to do interface based failover. Keep in mind that not just the interface will failover. The entire device will failover.<\/p>\n
Now it\u2019s time to set some VSD specific settings (priority, preempt and preempt holddown). I usually configure the master device with a priority of 50 and enable preempt :<\/p>\n
\nset nsrp vsd id 0 priority 50\nset nsrp vsd id 0 preempt<\/pre>\n<\/div>\nThen, enable RTO sync and enable route sync<\/p>\n
\nset nsrp rto-mirror sync\nset nsrp rto-mirror route<\/pre>\n<\/div>\nDefine a secondary interface.<\/p>\n
\nset nsrp secondary-path ethernet0\/4<\/pre>\n<\/div>\n <\/p>\n
Set up backup device<\/h4>\n
On the backup device, the configuration is pretty much the same, except for the priority and preempt :<\/p>\n
\nset nsrp cluster id 1\nset nsrp cluster name MyCluster1\nset nsrp arp 5\nset nsrp auth password MyAuthPassword\nset nsrp encrypt password MyEncryptionKey\nset nsrp monitor interface<\/span> eth0\/1\n\nset nsrp vsd id 0 priority 100\n\nset nsrp rto-mirror sync\nset nsrp rto-mirror route\n\nset nsrp secondary-path ethernet0\/4<\/p><\/pre>\n<\/div>\n=> on the backup node, I have set the priority to 100 (higher than the master) and I do not enable preempt. This will make sure that, if the master goes down (e.g. for maintenance) and comes online again, it will surely become the master node again.<\/p>\n
When the cluster devices are configured, they will start synchronizing information. You can check if the configurations are in sync by running :<\/p>\n
\nMyCluster1:fw01(M)-> exec nsrp sync global-config check-sum<\/strong> configuration in<\/span> sync<\/pre>\n<\/div>\nBefore the cluster is fully in sync, you should force sync, by running (on the backup device !<\/strong>):<\/p>\n\nMyCluster1:fw02(B)-> exec nsrp sync global-config save\n load peer system config to save\nSave global configuration successfully.\nSave local configuration successfully.\ndone.\nPlease reset your box to let cluster configuration take effect!\n\n<reset>\n\nSystem change state to Active(1)\nconfiguration in<\/span> sync (local checksum 12345678 == remote checksum 12345678)\nReceived all run-time-object<\/span> from peer.<\/pre>\n<\/div>\nAfter the reboot of the passive (backup) device, the cluster is fully operational. Note : when the device prompts you to save the config, enter \u201cn\u201d (no)<\/p>\n
\nEven if you have create a cluster on an existing device and added a second (new, empty) device into the cluster, you only have to reboot the passive node (and the active node always stays online)<\/p>\n<\/blockquote>\n
When both cluster members are synced ( = when the files are synced), you should enable config sync. <\/p>\n
\nset nsrp config sync<\/pre>\n<\/div>\n <\/p>\n
Verify cluster status<\/h4>\n
You can get some nsrp information with the following commands :<\/p>\n
\u201cget nsrp\u201d : shows information about the cluster and cluster nodes, the vsd group, etc :<\/p>\n
\nMyCluster1:fw01(M)-> get nsrp\nnsrp version: 2.0\n\ncluster info:\ncluster id: 1, name: MyCluster1\nlocal unit id: 8992891\nactive units discovered: \nindex: 0, unit id: 8992891, ctrl mac: 00222386308b , data mac: ffffffffffff\nindex: 1, unit id: 413691, ctrl mac: 0024ac04580a , data mac: ffffffffffff\ntotal number of units: 2\n\nVSD group info:\ninit hold time: 5\nheartbeat lost threshold: 3\nheartbeat interval: 1000(ms)\nmaster always exist: disabled\ngroup priority preempt holddown inelig master PB other members\n 0 50 yes 3 no myself 413691 \ntotal number of vsd groups: 1\nTotal iteration=4632604,time=88222673,max=29752,min=87,average=19\n\nRTO mirror info:\nrun time object<\/span> sync: enabled\nroute synchronization: enabled\nping session sync: enabled\ncoldstart sync done\nnsrp data packet forwarding is<\/span> enabled\n\nnsrp link info:\ncontrol channel: ethernet0\/6 (ifnum: 10) mac: 00222386308b state: up\nha data link not available\nsecondary path channel: ethernet0\/4 (ifnum: 8) mac: 00222386308d state: up\n\nNSRP encryption: enabled\nNSRP authentication: enabled\ndevice based nsrp monitoring threshold: 255, weighted sum: 0, not failed\ndevice based nsrp monitor interface<\/span>: ethernet0\/1\ndevice based nsrp monitor zone: \ndevice based nsrp track ip: (weight: 255, disabled)\nnumber of gratuitous arps: 5\nconfig sync: enabled\n\ntrack ip: disabled<\/pre>\n<\/div>\n <\/p>\n
If you want to see the differences between the 2 nodes, run<\/p>\n
\nMyCluster1:fw01(M)-> exec nsrp sync global diff<\/strong>\nMyCluster1:fw01(M)-> rcv_sys_config_diff: get local config sucess\nLocal have 0 different cmd lines:\nPeer have 0 different cmd lines:<\/pre>\n<\/div>\n <\/p>\n
<\/p>\n
Test failover<\/h3>\n
You can test if the cluster works by turning off the master device and wait a couple of seconds (typically 1 or 2 seconds) before the backup becomes master and processes all traffic.<\/p>\n
Alternatively, you can perform a manual failover using the following command :<\/p>\n
On the master device<\/u> :<\/p>\n\n- If preempt is enabled, run : <\/li>\n<\/ul>\n\n
exec nsrp vsd-group 0 mode ineligible<\/pre>\n<\/div>\n
\n- If preempt is not enabled, run : <\/li>\n<\/ul>\n\n
exec nsrp vsd-group 0 mode backup<\/pre>\n<\/div>\nThese commands will force the primary (master) device to step down. The other device will become master right away<\/p>\n
You can verify which one of the devices is master by performing the routines explained at http:\/\/kb.juniper.net\/KB11199<\/a><\/p>\n <\/p>\n
Impact of cluster on certificates and snmp<\/h3>\n
Cluster members can have different hostnames. If digital certificates\/snmp settings are configured with individual hostnames, then communication may break upon a failover. It\u2019s better to set a cluster name for all members and to use this VSD identity for snmp and digital certificates.<\/p>\n
You can set a cluster name with the following command :<\/p>\n
\nset nsrp cluster name MyGlobalClusterName<\/pre>\n<\/div>\nFor snmp, use the cluster name :<\/p>\n
\nset snmp name MyGlobalClusterName<\/pre>\n<\/div>\nAlso, It is important to install\/sync all PKI related components on both devices before installing the cluster, or you may get \u201cconfig out of sync\u201d messages. (exec nsrp sync pki\u2026)<\/p>\n
See Concepts&Examples PDF [27 MB]<\/a>, page 1864<\/p>\n