Managing Redundant Routing Engines

Problem

Your router has two Routing Engines, and you want them both to have the same configuration.

Solution

Configure a hostname for each Routing Engine and an IP address for each fxp0 interface:

	[edit groups]
	aviva@router1# set re0 system host-name router1
	aviva@router1# set re0 interfaces fxp0 unit 0 family inet address 192.168.15.1/24
	aviva@router1# set re1 system host-name router1-a
	aviva@router1# set re1 interfaces fxp0 unit 0 family inet address 192.168.15.2/24
	[edit]
	aviva@router1# set apply-groups [re0 re1]

Commit the same configuration on both Routing Engines:

	aviva@router1# commit synchronize
	re0:
	configuration check succeeds
	re1:
	configuration check succeeds

 

Discussion

Most routers, especially those used by network providers, have redundant hardware components, such as fans, power supplies, and Routing Engines, so that if one of them fails, a backup component takes over immediately and router operation continues. You can replace most redundant components without having to power down the router; this is called hot swapping. For most hardware components, no software configuration is required. They are simply present in the router, which you can verify with the show chassis hardware command, and if any problems occur, a message or alarm is logged by the system logging facility (described in Chapter 5). Redundant Routing Engines, however, require some configuration.

By default, the Routing Engine in slot 0 is the master (RE0) and is used when the router boots. The one Routing Engine in slot 1 (RE1) is the backup. You configure hostnames and addresses for the two Routing Engines using configuration groups (in the [edit groups] hierarchy level). Specifically, you must use the special configuration group re0 (for the Routing Engine in slot 0) and re1 (for the Routing Engine in slot 1) to define properties specific to the individual Routing Engines. Configuring the re0 and re1 groups lets both Routing Engines use the same configuration file. Then use the apply-groups statement to propagate the configuration group information to the main part of the configuration.

The commit synchronize command commits the same configuration on both Routing Engines. This command makes the active or applied configuration for both Routing Engines the same with the exception of the groups, re0 being applied only to RE0 and re1 being applied only to RE1. If you don't synchronize the configurations between the two Routing Engines and one of them fails, the router may end up in a very crippled state if the backup Routing Engine has a different configuration.

If the configuration on the other Routing Engine has been modified but not committed, the commit synchronize operation fails:

	[edit]
	aviva@router1# commit synchronize
	re0:
	error: configuration database modified
	re1:
	error: remote lock-configuration failed on re1

If you use the show | display inheritance command to see the statements that are inherited from the re0 and re1 groups, you see only what is inherited from the master Routing Engine, re0; you won't see anything inherited from the backup:

	[edit]
	aviva@router1# show | display inheritance | match re0
	 ## 'router1' was inherited from group 're0'
	 ## 'fxp0' was inherited from group 're0'
	 ## '0' was inherited from group 're0'
	 ## 'inet' was inherited from group 're0'
	 ## '192.168.15.1/24' was inherited from group 're0'
	[edit system]
	aviva@router1# show | display inheritance | match re1
	[edit system]
	aviva@router1#

Use the following command to see which Routing Engine is the master and which is the backup:

	aviva@router1>  
show chassis routing-engine
	Routing Engine status:
	Slot 0:
	 Current state Master
	 Election priority Backup
	 Temperature 33 degrees C / 91 degrees F
	 CPU temperature 38 degrees C / 100 degrees F
	 DRAM 768 MB
	 Memory utilization 20 percent
	 CPU utilization:
	 User 11 percent
	 Background 0 percent
	 Kernel 19 percent
	 Interrupt 1 percent
	 Idle 69 percent
	 Model RE-2.0
	 Serial ID 58000007348d9a01
	 Start time 2005-04-26 22:31:45 UTC
	 Uptime 3 minutes, 13 seconds
	 Load averages: 1 minute 5 minute 15 minute
	 0.86 0.65 0.28
	Routing Engine status:
	 Slot 1:
	 Current state Backup
	 Election priority Backup (default)
	 Temperature 30 degrees C / 86 degrees F
	 CPU temperature 30 degrees C / 86 degrees F
	 DRAM 768 MB
	 Memory utilization 15 percent
	 CPU utilization:
	 User 0 percent
	 Background 0 percent
	 Kernel 0 percent
	 Interrupt 0 percent
	 Idle 100 percent
	 Model RE-2.0
	 Serial ID d800000734745701
	 Start time 2005-02-18 07:48:14 UTC
	 Uptime 67 days, 14 hours, 46 minutes, 37 seconds

The highlighted lines show the master and backup information, and the remainder of the output shows Routing Engine status information.

To find out which software version is running on the backup Routing Engine or to edit its configuration file, log in to that Routing Engine:

	aviva@router1> request routing-engine login re1
	--- JUNOS 7.4-R1.7
	aviva@router1a>

The prompt shows the hostname you configured for RE1.

Both Routing Engines have an identical filesystem layout, and the filesystems are distinguished by the identifiers re0 and re1. When you list files, you see the ones on the Routing Engine you are logged in to. To list files on the other Routing Engine, include the identifier:

	aviva@router1> file list re1:/
	re1:
	/:
	COPYRIGHT
	altconfig/
	altroot/
	bin/
	boot/
	config/
	data/
	dev/
	etc/
	kernel@ -> /packages/jkernel
	mnt/
	modules/
	packages/
	proc/
	root/
	sbin/
	tmp/
	usr/
	var/

The master and backup Routing Engines exchange keepalive messages to detect that each is alive and well. You can protect the operation of the router by automatically switching from the master to the backup Routing Engine if the backup has not received keepalives from the master for five minutes:

	[edit chassis redundancy]
	aviva@router1# set failover on-loss-of-keepalives

The problem with this type of failoverand with manually resetting the master-shipis that the router stops forwarding packets during the time it takes to start the routing protocol software on the other Routing Engine. A way to automate the failure without packet loss is to use graceful switchover:

	[edit chassis redundancy]
	aviva@router1#  
set graceful-switchover enable

The CLI prompt then changes to indicate which Routing Engine you are using:

	{master}[edit]
	aviva@router1a#
	{backup}
	aviva@router1>

With graceful switchover, the backup Routing Engine regularly synchronizes its configuration and state with the master Routing Engine. The master Routing Engine sends keepalives to the backup every two seconds by default.(You can change this value with the set chassis redundancy keepalive-time command.) If the backup Routing Engine stops receiving these messages, it assumes mastership and the router's Packet Forwarding Engine (PFE) breaks its connection with the routing tables on the old master and connects to the new master. From the point of view of packet forwarding, the switching of the PFE connection from one router to the next happens immediately, so no packet loss occurs. One caveat about graceful switchover is that both Routing Engines must be running the same version of the JUNOS soft-ware. If you are using the backup Routing Engine to upgrade to a different software release, you need to disable graceful switchover.

If you are using graceful switchover, you can automatically switch to the backup Routing Engine if it receives a hard disk failure error from the master:

	[edit chassis redundancy]
	aviva@router1# set failover on-disk-failure

By default, when you reboot the router, RE0 is the master. Use the following commands to have RE1 permanently be the master even after a reboot:

	[edit chassis]
	aviva@router1# set 
redundancy routing-engine 0 backup
	aviva@router1# set redundancy routing-engine 1 master
	aviva@router1# commit synchronize

 

See Also

Recipe 8.12