For When You Can't Have The Real Thing
[ start | index | login ]
start > Netscreen > NSRP

NSRP

Created by dave. Last edited by dave, 12 years and 295 days ago. Viewed 8,916 times. #5
[diff] [history] [edit] [rdf]
labels
attachments

Simple Netscreen Redundancy

We've done this on SSG520s and SSG140s, ScreenOS 5.4.0 and 6.2.0.

Starting

I like to do a basic configuration. Each device needs:

  • a unique management address (usually in Trust)
  • the shared Trust IP address
On the master:
set nsrp cluster id 15
set nsrp rto-mirror sync
set nsrp rto-mirror route
set nsrp vsd-group id 0 priority 100
set nsrp vsd-group id 0 preempt

On the backup:

set nsrp cluster id 15
set nsrp rto-mirror sync
set nsrp rto-mirror route
set nsrp vsd-group id 0 priority 50

Check configuration synchronization:

SSG140(M)-> exec nsrp sync global-config check-sum
configuration in sync

At this point, your cluster should be up and running. So after this you should be able to enter commands on the master and they will be duplicated on the backup.

Set interfaces to be monitored:

SSG140(M)-> set nsrp ha-link probe
SSG140(M)-> set nsrp monitor interface ethernet0/8

The ha-link probe makes it actively poke its partner regularly to make sure it is still there.

The monitor interface means that if that interface goes down on the master, it will fail over to the backup. You can/should add all interfaces which will be in use.

If you need to force resynchronization:

SSG140(M)-> exec nsrp sync global-config save
Note you will have to reset both devices in the cluster.

If you can figure out what the differences between the master and backup are, you can manually add the missing commands to the backup and bring the configs back into sync again without having to reset both devices. Once the configs are in sync again, changes to the master will be automatically propagated to the backup again (until it falls out of sync for whatever reason) without the reset.

If you do it right you should be able to diff the configs between the master and the backup, and it will always boil down to:

565c565
< set interface bgroup0/0 manage-ip 172.xx.yy.aa
---
> set interface bgroup0/0 manage-ip 172.xx.yy.bb
628,629c628
< set nsrp vsd-group id 0 priority 50
< set nsrp vsd-group id 0 preempt
---
> set nsrp vsd-group id 0 priority 100
(offsets and IPs will vary of course.)

Beware

This works fine for a while then the firewalls fall out of sync for unknown reasons. In the few incidents we've talked to Juniper about this they've been handy-wavey about the problem. We now have a procedure where the config for the backup is always verified against the master with diff, and if the diffs are other than expected, we force the backup to catch up.

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