Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

IN THIS PAGE

Configuring the Service Redundancy Daemon

 

Before you configure srd processing, we recommend that you be familiar with Configuring ICCP for Multichassis Link Aggregation, which explains peer relationships between gateways that are enabled to exchange master and standby roles.

You use the following configuration statements:

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

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

  • redundancy-set under 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 ICCPd configuration. Finally, service sets and redundancy sets are associated through the redundancy-sets statement in service sets configuration.

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

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 mastership-release or mastership-acquire. If an event is associated with a policy that takes the release-mastership action, srd checks whether the redundancy peer’s state is ready or warned. If the standby is in a warned state, then the release-mastership action fails. You can take restore the healthcheck and manually execute the release-mastership action.

To release mastership in any case, you can either configure the policy action as release-mastership-force or use force option in the operational CLI. Even if your configuration specifies the force option, using the force option in the CLI takes precedence and mastership is released. Similarly, if a redundancy event is configured with a policy with an acquire-mastership action, then srd checks the local redundancy set state. In the case of a wait state, the action fails unless the force option is used. 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 mastership change action succeeds.

Configuring Redundancy Events

To configure redundancy events:

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

    For example:

  2. Configure any process redundancy events for the master 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 master gateway. Follow the same steps for the standby gateway.
  2. Specify an action of acquiring or releasing mastership.

    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 master 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 set a condition based on the existence of signal routes that requires redundancy-related routing changes. Specify the routing table that includes

    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 sync of services for a service set.

  1. Specify the service set and redundancy-set.

    For example:

  2. Specify the replication threshold and services to be replicated.

    For example:

Related Documentation