Monday, May 27, 2013

Implementing NSRP

NetScreen Redundancy Protocol (NSRP) is a proprietary protocol that provides configuration, run time object (RTO) redundancy, and device failover for NetScreen devices in a high availability (HA) cluster.

Connection

Juniper has pre-configured their more powerful devices with an HA zone. This zone allows the devices in the cluster to transfer and receive NSRP data and information from one another.

The SSG140 and above have this zone pre-installed. For devices that do not natively support it, a license from Juniper and manual configuration is required.

On some NetScreen devices, there are multiple dedicated (physical) HA interfaces. Each interface handles different kinds of HA communication as well as act as a back-up interface should one fail. By default, HA1 handles control messages and H2 handles data messages.

On NetScreen devices that do not have dedicated HA interfaces, you must bind one or two physical ethernet interfaces to the HA zone. For this demonstration we'll be using ethernet1/4.
set int eth1/4 zone "HA"

The devices will now know which interface to listen for NSRP messages. Input the NSRP commands to set up the cluster; the cluster ID must be identical on both devices. An NSRP cluster acts similar to a cluster in any other technology; it simply groups devices together.
set nsrp cluster id <#>
set nsrp cluster name <name>

Priority

A VSD group is a set of physical devices that make up a single virtual security device (VSD). One physical device acts as the primary of the VSD group. The virtual security interface (VSI) of the VSD is bound to the physical interface of the primary device. The other physical device acts as the backup. A VSD acts similar to a RAID array; a single virtual device made up of a cluster of physical devices.

We need to tell the firewalls which one is the master, and which one is the backup. The priority of the preferred backup should be a higher value, as the lower priority takes precedence. We want the device we're configuring to be the master but because we don't want it to take over until we're ready, we'll go ahead and set the priority to 200.
set nsrp vsd-group id 0 priority 200

Ctrl-S

At this point we'll want to save the configurations we've made so they don't conflict when loading the mirror configuration over.
save

Ctrl-C

Because we're configuring a brand new ISG, no extensive config exists. But we've set up NSRP already, and our backup has a configuration, so lets just copy that over.
exec nsrp sync global-config save
NOTE: Because this is an exec command, it has to be issued via a console connection

After this command is input, the device needs to be reset by simply issuing the reset command. Upon reboot, we should go through the configuration to make sure everything is correct. After POST it will tell you which commands (if any) failed, but it never hurts to be thorough.

Sync

Defining a NetScreen device as a member of a cluster and specifying RTO synchronization automatically enables the local device to send and receive RTOs. By default, NSRP cluster members do not synchronize RTOs. Before enabling RTO synchronization, you must first synchronize the configurations between the cluster members. Unless the configurations on both members in the cluster are identical, RTO synchronization might fail.
set nsrp rto-mirror sync
Run-time objects (RTOs) are code objects created dynamically in memory during normal operation. Some examples of RTOs are session table entries, ARP cache entries, DHCP leases, and IPSec security associations (SAs). In the event of a failover, it is critical that the current RTOs be maintained by the new master to avoid service interruptions. To accomplish this, RTOs are backed up by the members of an NSRP cluster. Working together, each member backs up the RTOs from the other, which allows RTOs to be maintained should the master of either VSD group in an active/active HA scheme step down.

Taking Control

Enable the preempt option for a device that you want to be master of the VSD group (which is the one we're configuring). Normally, that device also has the better priority number (closer to 1). In the event of a failover resulting in the new master having a lower priority than the previous master, when the previous master—with the preempt option set—becomes operable and eligible again, it automatically regains mastership of the VSD group. So basically, if our master fails and the backup takes over, but the master recovers it will regain control of the cluster. Because we are configuring a NEW master, once connected and configured it will automatically take over. We'll also want to lower the priority back down to 1.

WARNING: Before making this device the master we'll have to recable
set nsrp vsd-group id 0 priority 1
set nsrp vsd-group id 0 preempt 

Monitor

Now what we have configured the device for NSRP, we need to tell it which connection to monitor. The interface we choose will typically be the WAN interface, if this interface goes down the fail-over initiates and the back-up device takes over control of the VSD.
set nsrp monitor int eth1/3

Restoring Order

Everything is configured as it should be. Now we'll just want to make some tweaks.
First we would want to change the hostname of the device, so we can distinguish between the two.
set hostname <hostname>
If we want to have remote access to the device we'll need to setup management IP interfaces for us to use.
set interface ethernet1/1 manage-ip 192.168.1.2
set interface ethernet1/3 manage-ip 192.168.2.1
Now we'll be able to remote in through 192.168.1.2 and 192.168.2.1

We'll also need to change the speed and duplex settings on the interfaces as these do not get copied over
set int ethernet1/1 phy full 100mb
set int ethernet1/3 phy full 100mb
This will set eth1/1 and eth1/3 to full/100.

And that's it! We're finished and your device should be up and running as before.

No comments:

Post a Comment