SRP Module Redundancy
This section covers general issues of SRP module redundancy. It does not cover NVS cards or the behavior on systems running high availability features such as hitless SRP switchover. For information about managing NVS in a router that contains two SRP modules, see Managing Flash Cards on SRP Modules. For information about managing high availability in a router, see Chapter 7, Managing High Availability.
The information in this section does not apply to the ERX-310 router, which does not support SRP module redundancy. For this reason, any references to synchronization that may appear in command output or system messages do not apply to the ERX-310 router.
SRP Module Behavior
The SRP module uses a 1:1 redundancy scheme. When two SRP modules are installed in the router, one acts as a primary and the second as a redundant module. On ERX-7xx models, ERX-14xx models, and the ERX-310 router, both SRP modules share a single SRP I/O module located in the rear of the chassis. On the E120 router and the E320 router, both SRP modules share an SRP IOA located in the rear of the chassis.
After you install two SRP modules, the modules negotiate for the primary role. A number of factors determine which module becomes the primary; however, preference is given to the module in the lower slot. The SRP modules record their latest roles and retain them the next time you switch on the router.
With the default software settings, if the primary SRP module fails, the redundant SRP module assumes control without rebooting itself. For information about preventing the redundant SRP module from assuming control, see Managing SRP Module Redundancy.
On E120 and E320 routers, the switch fabric is distributed between the SFMs and the SRP modules. If the primary SRP module fails a diagnostic test on its resident slice of switch fabric, then it abdicates control to the redundant SRP module if both of the following are true:
- The standby SRP module does not indicate any error.
- The standby SRP module passes diagnostics on its attached fabric slice.
When the redundant SRP module assumes control, the following sequence of events occurs:
- The original primary SRP module reboots and assumes the redundant role.
- The redundant SRP module restarts and assumes the primary role without reloading new code. (When upgrading software, you must reload the software on the redundant SRP module. See Chapter 3, Installing JUNOSe Software.)
- All line modules reboot.
The following actions activate the redundant SRP module:
- Failure of the primary SRP module (hardware or software)
- Pushing the recessed reset button on the primary SRP module (see Figure 25 and Figure 26)
- Issuing the srp switch command
- Issuing the redundancy force-switchover command
![]()
![]()
Specifying the Configuration for Redundant SRP Modules
On a router with redundant SRP modules, you can specify the configuration that both the primary and redundant modules load in the event of a reload or switchover. A switchover can result from an error on the primary SRP module or from an srp switch command. The following behavior takes place only in the event of a cold restart; it does not take place in the event of a warm restart.
When you arm a configuration (.cnf) file by issuing the boot config cnfFilename command, a subsequent SRP switchover causes the redundant SRP module to assume the role of primary SRP module with the configuration specified by the .cnf file. The new primary SRP module does not use the running configuration.
If you want the redundant SRP module to instead use the running configuration when it assumes the primary role, then you must first arm a configuration file with the boot config cnfFilename once command. To exhaust the once option, you must then cause the redundant SRP module to reload for some reason, such as by issuing a reload command or by arming a new JUNOSe release or a hotfix file.
When a switchover subsequently occurs, the redundant SRP module reloads with the running configuration and assumes the primary role. For more information about the boot config command, see Chapter 11, Booting the System.
Installing a Redundant SRP Module
You can install a redundant SRP module into a running router, provided that the redundant SRP module has a valid, armed software release on its NVS card. Access to a software release in NVS ensures that the redundant SRP module can boot; the release need not be the same as that on the primary SRP module. To install a redundant SRP module into a running router, follow these steps:
- Install the redundant SRP module into the open SRP slot (slot 6 or 7 for ERX-14xx models, the E120 router, and the E320 router; slot 0 or 1 for ERX-7xx models).
For detailed information about installing the SRP module, see the ERX Hardware Guide or the E120 and E320 Hardware Guide.
When the module is in standby state, the REDUNDANT LED is on and the ONLINE LED is off. If you issue the show version command, the state field for the slot that contains the redundant SRP module is standby.
- Synchronize the NVS file system of the redundant SRP module to that of the primary SRP module.
NOTE: The SRP module reboots after synchronization is complete.
reload slot
- Use to reboot a selected slot on the router.
- If you specify a slot on the E120 router or the E320 router that contains an SRP module, you reboot the SC subsystem on that slot by default. You do not, however, reboot the fabric slice that resides on the slot.
- Use the srp keyword to reboot the portion of the SC subsystem that resides on a specified SRP module.
- Use the fabric keyword to reboot the fabric slice that resides on the specified SRP module.
host1#reload slot 7Example 2Reboots the SC on the SRP module in slot 7 (applies only to E120 and E320 routers) host1#reload slot 7 srpThere is no no version. synchronize
- Use to force the file system of the redundant SRP module to synchronize with the NVS file system of the primary SRP module.
- If you synchronize the redundant SRP module with the primary SRP module and the redundant module is armed with a release different from the one it is currently running, the redundant SRP module is automatically rebooted to load the armed release.
- Optionally, you can use the low-level-check keyword to force the router to validate all files or only configuration files in NVS, and to synchronize all files that failed the checksum test during the flash-disk-compare command as well as any other files that are unsynchronized. See Validating and Recovering Redundant SRP File Integrity for details.
- Examples
host1#synchronizehost1#synchronize low-level-check allhost1#synchronize low-level-check configurationThere is no no version. Managing SRP Module Redundancy
You can prevent the redundant SRP module from taking over when:
- The primary SRP module experiences a software failure.
- You push the reset button on the primary SRP module.
- Issue the disable-switch-on-error command.
- Synchronize the NVS file system of the redundant SRP module to that of the primary SRP module.
Refer to the commands and guidelines in the previous section and below.
disable-switch-on-error
- Use to prevent the redundant SRP module from taking over if the primary SRP module experiences a software failure or if you push the reset button on the primary SRP module.
- Issue the synchronize command immediately before you issue this command.
- If you issue the disable-switch-on-error command, and later issue the srp switch command, the redundant SRP module waits about 30 seconds before it takes over from the primary SRP module.
- Example
host1(config)#disable-switch-on-errorUse the no version to revert to the default situation, in which the redundant SRP module takes over if the primary SRP module experiences a software failure. synchronize
- Use to force the NVS file system of the redundant SRP module to synchronize with the NVS file system of the primary SRP module.
- If you synchronize the redundant SRP module with the primary SRP module and the redundant module is armed with a release different from the one it is currently running, the redundant SRP module is automatically rebooted to load the armed release.
- Optionally, you can use the low-level-check keyword to force the router to validate all files or only configuration files in NVS, and to synchronize all files that failed the checksum test during the flash-disk-compare command as well as any other files that are unsynchronized. See Validating and Recovering Redundant SRP File Integrity for details.
- Examples
host1#synchronizehost1#synchronize low-level-check allhost1#synchronize low-level-check configurationThere is no no version. Switching to the Redundant SRP Module
To switch immediately from the primary SRP module to the redundant SRP module, issue the redundancy force-switchover command or the srp switch command. You can configure the router to prompt you if the modules are in a state that could lead to loss of configuration data or NVS corruption.
redundancy force-switchover
- Use to force the router to switch from the primary line module in the specified slot or the primary SRP module to the spare line module or SRP module.
- The command causes a single switchover. When you reboot, the router reverts to the configured setting for this slot.
- With the srp option, the command is equivalent to the srp switch command.
- The redundancy force-switchover command overrides the redundancy lockout command.
- Example
host1#redundancy force-switchover 5There is no no version. srp switch
- Use to switch from the primary SRP module to the redundant SRP module.
- When the high availability state is active, this command delays until all transaction data, up to when you issue the command, has been mirrored to the standby SRP module. This preserves legacy behavior requiring that SRP modules be synchronized before the switchover.
- If you specify the force keyword, the procedure fails if the SRP modules are in certain states, such as during a synchronization. In these cases, the router displays a message that indicates that the procedure cannot currently be performed and the reason why. However, if the SRP modules are in other states that could lead to a loss of configuration data or an NVS corruption, the router displays a message that explains the state of the SRP modules, and asks you to confirm (enter yes or no) whether you want to proceed.
- If you do not specify the force keyword, the procedure fails if the SRP modules are in any state that could lead to a loss of configuration data or an NVS corruption, and the router displays a message explaining the command failure.
- When you issue this command, the router prompts you for a confirmation before the command takes effect.
- If you issue the disable-switch-on-error command and later issue the srp switch command, the redundant SRP module waits about 30 seconds before it takes over from the primary SRP module.
- If the router does not contain a redundant SRP module, this command has no effect.
- Example
host1#srp switchhost1#srp switch forceThere is no no version. Upgrading Software on a Redundant SRP Module
For information about upgrading software on SRP modules on ERX-7xx models, ERX-14xx models, or the ERX-310 router, see Chapter 3, Installing JUNOSe Software.
Monitoring the Status LEDs
You can determine the redundancy state of line modules and SRP modules by examining their status LEDs. See Table 43 for a description of the LEDs functions. In addition, if you issue the show version command, the state field for the slot that contains the redundant SRP module should be standby.