Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Service Redundancy Daemon

Service Redundancy Daemon Overview

Introduction to the Service Redundancy Daemon

  • The service redundancy daemon (srd) provides configurable events that can decide when redundancy occurs across multiple gateways on MX Series routers with MS-MPCs and MS-MICs. This enables you to manage primary-role switchovers based on a monitored event. You can configure redundancy based on monitored events, including:

    • Link down events.

    • FPC and PIC reboots.

    • Routing protocol daemon (rpd) terminates and restarts.

    • Peer gateway events, including requests to acquire or release primary role, or to broadcast warnings.

Service Redundancy Daemon Components

The following configurable components control srd processing:

  • Redundancy Event—A monitored critical event that triggers the srd to acquire or release primary role for redundancy peers, or to trigger warning-only events, and to add or delete signal routes. Monitored events include interface or link down events, rpd events, and acquire or release primary role events from peers.

  • Redundancy Policy—A policy that defines the set of actions taken when a redundancy event occurs. Available actions include acquisition or release of primary role, and addition or deletion of signal routes.

  • Redundancy Set—A collection of one or more service sets with a common redundancy policy or policies. A redundancy set applies to two or more system gateways. Only one of the gateways is primary and the peer or peers are standby at any time. Redundancy policies define the actions to be taken for a redundancy set when the srd detects a triggering event.

  • Redundancy Group—A one-to-one relationship exists between a redundancy set and a redundancy group. One redundancy set can be part of only one redundancy group.

  • Signal routes—Static routes that are added or deleted by the srd based on primary role state changes.

  • Routing Policies—Policies that are configured to advertise routes based on the existence or non-existence of signal routes using the if-route-exists condition.

  • VRRP (Virtual Router Redundancy Protocol) route tracking—TA standard Junos OS VRRP feature, but optional srd component, that tracks whether a reachable route exists in the routing table of the routing instance included in the configuration and dynamically changes the priority of the VRRP group based on the reachability of the tracked route, triggering a new primary router election. The route to be tracked is a signal route.

Service Redundancy Daemon Constraints

The following constraints apply to srd processing configurations:

  • A one-to-one relationship exists between a redundancy set and a redundancy group. One redundancy set can be part of only one redundancy group.

  • One redundancy policy can be part of only one redundancy set, but one redundancy set can have multiple redundancy policies. For example, redundancy set RS1 can include redundancy policies RP1 and RP2. Redundancy policies RP1 and RP2 cannot be included in redundancy sets other than RS1.

  • One redundancy event can be part of only one redundancy policy, but one redundancy policy can have multiple redundancy events. For example, redundancy policy RP1 can include redundancy events RE1 and RE2. Redundancy events RE1 and RE2 cannot be included in redundancy policies other than RP1.

  • One monitored interface or link can be part of only one redundancy event, but one redundancy event can have multiple monitored interfaces.

  • One service set can be part of only one redundancy set, but one redundancy set may have multiple service sets.

  • If gateway 1, the chassis that is configured with the lower IP address, is the primary chassis and you deactivate SRD on it, a switchover to gateway 2 occurs. If gateway 2, the chassis that is configured with the higher IP address, is the primary chassis and you deactivate SRD on it, a switchover does not occur.

  • A particular redundancy-set can be active on only one gateway, but not all redundancy sets have to be active on the same gateway. For example, redundancy set A can be active on gateway 1 while redundancy set B is active on gateway 2.

Service Redundancy Daemon Operation

The srd operates as follows:

  1. The srd runs on the Routing Engine. It continuously monitors configured redundancy events.

  2. When a redundancy event is detected, the srd:

    1. Adds or removes signal routes specified in the redundancy policy.

    2. Switches services to the next preferred standby gateway.

    3. Updates stateful sync roles as needed.

  3. Resulting route changes cause:

    1. The routing policy connected to this route to advertise routes differently.

    2. VRRP to change advertised priorities.

To summarize the switchover process:

  1. A critical event occurs.

  2. srd adds or removes a signal route.

  3. A routing policy advertises routes differently. VRRP changes advertised priorities.

  4. Services switch over to the next preferred standby gateway.

  5. Stateful synchronization is updated accordingly.

Note:

The order of routing priorities must match the order of services primary role.

Configuring the Service Redundancy Daemon

Before you configure srd processing, we recommend that you be familiar with Configuring ICCP for MC-LAG, which explains peer relationships between gateways that are enabled to exchange primary and standby roles.

You use the following configuration statements:

  • redundancy-policy at the [edit policy-options] hierarchy level

  • redundancy-event at the [edit event-options] hierarchy level

  • redundancy-set at the [edit services] hierarchy level

The actions to be performed when configured redundancy events occur are defined in redundancy policies. Redundancy polices are associated with redundancy sets; they are analogous to rules associated with service sets. Redundancy sets are associated to redundancy groups by redundancy group IDs. Redundancy group details are defined by the underlying Inter-Chassis Communication Protocol daemon (iccpd) configuration. Service sets and redundancy sets are associated through the redundancy-sets statement in service sets configuration.

In the procedures that follow, redundancy events that are configured and associated with a redundancy policy. The redundancy policy is associated with a redundancy set to take appropriate action of primary-role release or primary-role acquire. If an event is associated with a policy that takes the primary-role release action, srd checks whether the redundancy peer’s state is ready or warned. If the standby is in a warned state, then the primary-role release action fails. You can restore the health check and manually execute the release primary role action.

To release primary role in any case, you can either configure the policy action as release-mastership-force or use the request services redundancy-set redundancy-set redundancy-event redundancy-event trigger force command in the operational CLI. Even if your configuration specifies the release-mastership-force option, using the request services redundancy-set redundancy-set redundancy-event redundancy-event trigger force CLI command takes precedence and primary role is released. Similarly, if a redundancy event is configured with a policy with an acquire primary-role action, then srd checks the local redundancy set state. In the case of a wait state, the action fails unless you use the request services redundancy-set redundancy-set redundancy-event redundancy-event trigger force CLI command. We recommend that you determine why health checks fail and take action to correct the failure. After that, when the redundancy set state returns to STANDBY, then this primary-role change action succeeds.

A particular redundancy-set can be active on only one gateway, but not all redundancy sets have to be active on the same gateway. For example, redundancy set A can be active on gateway 1 while redundancy set B is active on gateway 2.

To configure srd, perform the following configuration tasks in the recommended sequence. Configurations are shown for two gateways for which primary role may change.

Configuring Redundancy Events

To configure redundancy events:

  1. Configure any link-down redundancy events for the primary gateway.

    For example:

  2. Configure any process redundancy events for the primary gateway.

    For example:

  3. Configure any link-down redundancy events for the standby gateway.

    For example:

  4. Configure any process redundancy events for the standby gateway.

    For example:

  5. Configure any peer redundancy events for the standby gateway.

    For example:

Configuring Redundancy Policies

Service redundancy policies specify actions triggered by monitored redundancy events.

To configure redundancy policies:

  1. Specify a redundancy policy and redundancy event for the primary gateway. Follow the same steps for the standby gateway.
  2. Specify an action of acquiring or releasing primary role.

    or

  3. (Optional) Specify an action of adding a static route.
    Best Practice:

    We recommend using the receive option.

  4. (Optional) Specify an action of deleting a static route.

The following example demonstrates configuring redundancy policies for two peer gateways:

Configuring Redundancy Set and Group

The redundancy group IDs that srd uses are associated with those configured for the ICCP daemon (iccpd) through the existing ICCP configuration hierarchy by using the same redundancy group ID in the configuration of the services redundancy group.

To configure redundancy sets:

  1. Specify redundancy set and group for the primary gateway.

    For example:

  2. Specify redundancy policies for the redundancy set.

    For example:

  3. Specify redundancy set and group for the peer gateway.

    For example:

  4. Specify redundancy policies for the redundancy set.

    For example:

Configuring Routing Policies Supporting Redundancy

To configure routing policies that support redundancy:

  1. At the [edit policy-options condition] hierarchy level, use the if-route-exists configuration statement to set a condition based on the existence of signal routes that requires redundancy-related routing changes. Specify the routing table that is used.

    For example:

  2. At the [edit policy-options policy-statement statement-name] hierarchy level, specify routing changes based on the condition indicating the existence of the signal route. For BGP, routing changes typically include change to local-preference and as-path-prepend values.
    1. To change local-preference, specify local-preference in the then clause of the policy statement.

      For example:

    2. To change as-path-prepend values, specify as-path-prepend in the then clause of the policy statement.

      For example:

Configuring Service Sets

Specify stateful synchronization of services for a service set.

Specify the service set and redundancy set.

For example:

Using Service Redundancy Daemon Scripts to View and Change the Status of a Gateway

You can determine the status of a gateway, disable or enable all the interfaces on the gateway, or pull services-related MIB information from the gateway by running service redundancy daemon (srd) scripts.

Before you can use these scripts, you must enable them:

  • Enable the srd scripts.

Use the srd scripts as the root user:

  • Disable all the interfaces on the MX series router and power off the MS-MPC cards.
    1. Ensure that all local redundancy sets are in standby mode.
    2. Run the sdg-oos script.
  • Enable all the interfaces on the MX series router and power on the MS-MPC cards.
  • Check the service state of a gateway.
  • Pull services-related MIB information from the gateway.