Service Redundancy Daemon
Service Redundancy Daemon Overview
- Introduction to the Service Redundancy Daemon
- Service Redundancy Daemon Components
- Service Redundancy Daemon Constraints
- Service Redundancy Daemon Operation
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:
The srd runs on the Routing Engine. It continuously monitors configured redundancy events.
When a redundancy event is detected, the srd:
Adds or removes signal routes specified in the redundancy policy.
Switches services to the next preferred standby gateway.
Updates stateful sync roles as needed.
Resulting route changes cause:
The routing policy connected to this route to advertise routes differently.
VRRP to change advertised priorities.
To summarize the switchover process:
A critical event occurs.
srd adds or removes a signal route.
A routing policy advertises routes differently. VRRP changes advertised priorities.
Services switch over to the next preferred standby gateway.
Stateful synchronization is updated accordingly.
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
- Configuring Redundancy Policies
- Configuring Redundancy Set and Group
- Configuring Routing Policies Supporting Redundancy
- Configuring Service Sets
Configuring Redundancy Events
To configure redundancy events:
Configuring Redundancy Policies
Service redundancy policies specify actions triggered by monitored redundancy events.
To configure redundancy policies:
The following example demonstrates configuring redundancy policies for two peer gateways:
user@gateway1# edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-events ACQU_MSHIP_MANUAL_EV then [edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-event ACQU_MSHIP_MANUAL_EV then] user@gateway1# set acquire-mastership add-static-route 10.45.45.0/24 receive routing-instance SGI-PRIVATE user@gateway1# top user@gateway1# edit policy-options redundancy-policy RELS_MSHIP_POL redundancy-events PEER_MSHIP_ACQU_EV then [edit policy-options redundancy-policy RELS_MSHIP_POL redundancy-events PEER_MSHIP_ACQU_EV then] user@gateway1# set release-mastership-force delete-static-route 10.45.45.0/24 receive routing-instance SGI-PRIVATE
user@gateway2# edit policy-options redundancy-policy RELS_MSHIP_POL redundancy-events PEER_MSHIP_ACQU_EV then [edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-events ACQU_MSHIP_MANUAL_EV then] user@gateway2# set release-mastership-force add-static-route 10.45.45.0/24 receive routing-instance SGI-PRIVATE user@gateway2# top user@gateway2# edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-events PEER_MSHIP_RELS_EV then [edit policy-options redundancy-policy ACQU_MSHIP_POL redundancy-events PEER_MSHIP_RELS_EV then] user@gateway2# set acquire-mastership delete-static-route 10.45.45.0/24 receive routing-instance SGI-PRIVATE user@gateway2# top user@gateway2# edit policy-options redundancy-policy WARN_POL redundancy-events WARN_EV then [edit policy-options redundancy-policy WARN_POL redundancy-events WARN_EV then] user@gateway2# set broadcast-warning
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.
iccp { local-ip-addr 10.1.1.1; peer 10.2.2.2 { redundancy-group-id-list 1; liveness-detection { minimum-interval 1000; } } }
To configure redundancy sets:
Configuring Routing Policies Supporting Redundancy
To configure routing policies that support redundancy:
Configuring Service Sets
Specify stateful synchronization of services for a service set.
[edit] user@gateway1# set services service-set service-set-name redundancy-set-id redundancy-set
For example:
[edit] user@gateway1# set services service-set CGN4_SP-7-0-0 redundancy-set-id 1
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.
[edit] user@host# set system scripts op file sdg-inservice.slax user@host# set system scripts op file sdg-oos.slax user@host# set system scripts op file services-oids.slax user@host# set system scripts op file srd-status.slax user@host# set system scripts op max-datasize 512m
Use the srd scripts as the root user: