Data-Plane Redundancy

Also known as hot standby, data-plane redundancy lets you configure primary and secondary (backup) Multiservices PICs to mirror runtime data.

Data is mirrored to the secondary PIC in real time, so that both contain identical information.

The two Multiservices PICs are paired in the configuration using a virtual interface, rms-, that represents the union of the two ms- interfaces on the PICs. The following figure shows how this works:


Data-Plane Redundancy Architecture

One PIC is active, while the other functions as the backup. If the active PIC fails, the framework guarantees that all traffic (for both control and data) is switched over to the backup in less than five seconds.

This release provides the infrastructure with fast switchover support; it does not address any state replication maintained by the plugins or services running on the Multiservices PICs. To replicate data between PICs, you can use the libjunos-sync APIs, described in Synchronizing Runtime Data.

The reliable configuration download feature ensures that the configuration data can be easily pushed down to both the Multiservices PICs. Once the rms- interface is online, all blobs can be added, and the kernel infrastructure on the Routing Engine automatically sends the blobs to both the PICs. (For more information about Reliable Configuration Download, see Reliable Configuration Download.)

Both the Multiservices PICs must be identical in all respects - capacity, scalability, performance and configuration.

Switchover Notification

When the Multiservices PIC fails, the system notifies the Routing Engine kernel driver through either the PIC interface down or the PIC interface health status down event. This invokes the rms- interface state machine (see Switchover State Machine) and triggers the switchover.

Switchover to the backup PIC is guaranteed to occur within five seconds. However, because the control plane notification goes through several different elements in the system, a minimum time for state synchronization cannot be guaranteed. (Ideally, both PICs in a hot standby (one-to-one) configuration should be ready to receive traffic at any time.) Thus, the final switchover time for the application is five seconds for traffic switch, plus any additional time needed for application state switchover.

Notification on the Routing Engine

Applications running on the Routing Engine receive an asychronous KCOM message of IFD_CHANGE. The application can then execute a synchronous KCOM call to read back the redundancy information for the current state of the rms- interface child links. For sample code using the KCOM component of failure handling, see KCOM Monitoring Example in the programming task, Monitoring the System Programmatically.

Notification on the Multiservices PIC

Switchover notification for control daemons on the PIC proceeds as follows:

The following figure illustrates this process:


Switchover Notification on the Multiservices PIC

Data-plane daemon notification works the same way as control-plane notification. Plugins are notified through a SWITCHOVER event.

Switchover State Machine

The state machine logic has four states:

The following events are involved:

The switchover logic is as follows:

State transitions occur as follows:

Current State Event Action

wait-for-primary or ready

Primary PIC is up rms0 moves to on-primary state.


Primary PIC is down (PIC crash or any failure) rms0 moves to on-secondary state if secondary is online.
rms0 moves to ready state if secondary is offline.


Primary is up None (remains on-secondary); auto revert is not supported.


Secondary failure If primary is up, moves to primary state; if primary is not online, moves to ready state.

An informational syslog is shown at every state transition.

SDK Events

The rms- physical interface is associated with the redundancy options TLV. This TLV contains the following information:

Applications can read this information synchronously and can also be notified asynchronously when redundancy options change.

Configuration for Data-Plane Redundancy

You configure the rms- interface as follows:

interfaces rms0 {
       redundancy-options {
          primary ms-1/1/0;
          secondary ms-1/3/0;

       unit 0 {
          family inet {

In this example:

The roles of active and standby can change as PICs fail and come back online.

Other configurations that can use rms- along with ms- interfaces include service sets, (both interface style and nexthop style,) class-of-service, and routes.

You cannot configure subunits on the ms- interfaces that participate in the rms- configuration.

On an M120 router, you must configure at least one logical interface for the -rms interface to function.

Monitoring Data Redundancy

You can use the debug CLI, MSPDBG-CLI, on the PIC to detect failures. The following command displays redundancy information:

	   MSPDBG-CLI> show services redundancy

This displays the following sample output:

	   Redundancy information
	   Redundancy State                : On Secondary
	   Redundancy Last update Sec      : 1227493501
	   Redundancy Last update millisec : 226968
	   Redundancy Primary ifd          : ms-0/1/0
	   Redundancy Secondary ifd        : ms-0/2/0
	   Redundancy Active ifd           : ms-0/2/0

Triggering a Switchover

Applications can trigger a switchover programmatically by calling the following functions in libmsvcs-pmon:

There are parallel CLI commands to trigger switchovers from the command line, as follows:


The following notes apply to using data-plane redundancy in this release:

For sample code and usage on handling switchovers in your applications, see Monitoring the System Programmatically, Synchronizing Runtime Data, and IP Reassembly in the Plugin.
2007-2009 Juniper Networks, Inc. All rights reserved. The information contained herein is confidential information of Juniper Networks, Inc., and may not be used, disclosed, distributed, modified, or copied without the prior written consent of Juniper Networks, Inc. in an express license. This information is subject to change by Juniper Networks, Inc. Juniper Networks, the Juniper Networks logo, and JUNOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Generated on Sun May 30 20:26:47 2010 for Juniper Networks Partner Solution Development Platform JUNOS SDK 10.2R1 by Doxygen 1.4.5