Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Configuring Inter-Chassis Services Redundancy for Next Gen Services

This topic describes how to configure interchassis-services redundancy for Next Gen Services. This topic contains a procedure for configuring non-stop services redundancy (automatic switchovers in both directions) and a procedure for one-way redundancy (automatic switchovers only from the original primary to the original standby).

You can also use a manual request command to release or acquire primary role:

The command automatically triggers the specified redundancy event. You must create a configuration that assigns the redundancy event to a redundancy policy that either releases or acquires primary role. You must also assign the redundancy policy to the redundancy set used in the command.

Configuring Non-Stop Services Redundancy for Next Gen Services Service Set

Non-stop services redundancy gives you automatic services switchovers between the MX Series routers when a critical event occurs. Automatic switchovers from gateway1 to gateway2 and from gateway2 to gateway1 take place without manual intervention.

To configure non-stop services redundancy for a service set, perform the following steps on both gateway1 and gateway2:

  1. Configure one or more redundancy events to monitor the conditions that trigger a services switchover to the peer gateway.
    1. Configure a name for the redundancy event.

      For example:

    2. Specify any interfaces that trigger a services switchover when the interface goes down.
    3. Specify that a process routing daemon restart request triggers a services switchover.
    4. Specify that a process routing daemon terminate request triggers a services switchover.
    5. Specify that a request from the peer to acquire ownership triggers a services switchover.
  2. Configure a redundancy policy that releases primary role and deletes a static route when the redundancy event conditions are met.
    1. Configure a name for the policy.

      For example:

    2. Specify the redundancy events that release primary role.

      For example:

      If you want to be able to run the request services redundancy-set redundancy-set trigger redundancy-event event-name <force> to manually release primary role, include that event-name in the redundancy policy. The redundancy event itself does not need to be configured, because it is triggered by the request command.

      For example:

    3. Release primary role.
    4. Delete the static route.
  3. Configure a redundancy event to identify when the peer gateway releases primary role.

    For example:

  4. Configure a redundancy policy that acquires primary role from the peer gateway and adds a static route.
    1. Configure a name for the policy.

      For example:

    2. Specify the redundancy events that acquire primary role.

      For example:

      If you want to be able to run the request services redundancy-set redundancy-set trigger redundancy-event event-name <force> to manually acquire primary role, include that event-name in the redundancy policy. The redundancy event itself does not need to be configured, because it is triggered by the request command.

      For example:

    3. Acquire primary role.
    4. Add a static route.
  5. Configure the redundancy set.
    1. Configure a name for the redundancy set.

      For example:

    2. Specify the redundancy group ID for the redundancy set.

      For example:

      The redundancy group ID is the same redundancy group ID configured for the ICCP daemon (iccpd) through the existing ICCP configuration hierarchy. For example,

    3. Specify the redundancy policy that releases primary role and the redundancy policy that acquires primary role.

      For example:

    4. Configure the frequency of health check probes of the redundancy set, in seconds.

      The default is 30 seconds.

    5. Configure the maximum wait time for a help check response, in seconds.

      The range is 0 through 3600 seconds.

    6. Configure the frequency of srd hello messages, in seconds.

      The range is 1 through 60 seconds.

  6. Configure routing policies.
    1. Identify signal routes that requires redundancy-related routing changes. Specify the signal route and the routing table that is used.

      For example:

    2. To change the local-preference for the signal route, enter it in a policy statement.
    3. To change as-path-prepend values for the signal route, enter them in the policy statement.
  7. Configure redundancy for the service set by assigning the redundancy set to the service set.
  8. Repeat these steps on the peer gateway.

See Also

Configuring One-Way Services Redundancy for Next Gen Services Service Set

One-way services redundancy gives you automatic services switchovers from gateway1, the original primary gateway, to gateway2, the original standby gateway. An automatic switchover from gateway 2 to gateway1 does not happen. To switchover from gateway2 to gateway1, you must perform a manual switchover.

  1. On gateway1, the initial primary, configure one or more redundancy events to monitor the conditions that trigger a services switchover to gateway2, the standby gateway.
    1. Configure a name for the redundancy event.

      For example:

    2. Specify any interfaces that trigger a services switchover when the interface goes down.
    3. Specify that a process routing daemon restart request triggers a services switchover.
    4. Specify that a process routing daemon terminate request triggers a services switchover.
  2. On gateway1, configure a redundancy policy that releases primary role and deletes a static route when the redundancy event conditions are met.
    1. Configure a name for the policy.

      For example:

    2. Specify the redundancy events that release primary role.

      For example:

      If you want to be able to run the request services redundancy-set redundancy-set trigger redundancy-event event-name <force> to manually release primary role, include that event-name in the redundancy policy. The redundancy event itself does not need to be configured, because it is triggered by the request command.

      For example:

    3. Release primary role.
    4. Delete the static route.
  3. On gateway1, configure a redundancy policy that acquires primary role from gateway2 when you perform a manual request on gateway1 (request services redundancy-set redundancy-set trigger redundancy-event event-name <force>) .
    1. Configure a name for the policy.

      For example:

    2. Specify the name of the redundancy event that the manual request uses.

      For example:

      The redundancy event itself does not need to be configured, because it is triggered by the request command.

    3. Acquire primary role.
  4. On gateway1, configure the redundancy set.
    1. Configure a name for the redundancy set.

      For example:

    2. Specify the redundancy group ID for the redundancy set.

      For example:

      The redundancy group ID is the same redundancy group ID configured for the ICCP daemon (iccpd) through the existing ICCP configuration hierarchy. For example,

    3. Specify the redundancy policy that releases primary role and the redundancy policy that acquires primary role.

      For example:

    4. Configure the frequency of health check probes of the redundancy set, in seconds.

      The default is 30 seconds.

    5. Configure the maximum wait time for a help check response, in seconds.

      The range is 0 through 3600 seconds.

    6. Configure the frequency of srd hello messages, in seconds.

      The range is 1 through 60 seconds.

  5. On gateway1, configure routing policies.
    1. Identify signal routes that requires redundancy-related routing changes. Specify the signal route and the routing table that is used.

      For example:

    2. To change the local-preference for the signal route, enter it in a policy statement.
    3. To change as-path-prepend values for the signal route, enter them in the policy statement.
  6. On gateway1, configure redundancy for the service set by assigning the redundancy set to the service set.
  7. On gateway2, the initial standby, configure a redundancy event to identify when the peer gateway releases primary role.

    For example:

  8. On gateway2, configure a redundancy policy that acquires primary role from the peer gateway and adds a static route.
    1. Configure a name for the policy.

      For example:

    2. Specify the configured redundancy event for the peer gateway primary role release event.

      For example:

    3. Acquire primary role.
    4. Add a static route.
  9. On gateway2, configure a redundancy event to identify when the peer gateway requests primary role.

    For example:

  10. On gateway2, configure a redundancy policy that releases primary role and deletes a static route when gateway1 requests primary role.
    1. Configure a name for the policy.

      For example:

    2. Specify the configured redundancy event that identifies when the peer gateway requests primary role.

      For example:

    3. Release primary role.
    4. Delete the static route.
  11. On gateway2, configure one or more redundancy events to monitor the conditions that trigger a warning.
    1. Configure a name for the redundancy event.

      For example:

    2. Specify any interfaces that trigger a warning when the interface goes down.
    3. Specify that a process routing daemon restart request triggers a warning.
    4. Specify that a process routing daemon terminate request triggers a warning.
  12. On gateway2, configure a redundancy policy that broadcasts a warning.
    1. Configure a name for the policy.

      For example:

    2. Specify the configured redundancy events that trigger a warning.

      For example:

    3. Broadcast the warning.
  13. On gateway2, configure the redundancy set.
    1. Configure a name for the redundancy set.

      For example:

    2. Specify the redundancy group ID for the redundancy set.

      For example:

      The redundancy group ID is the same redundancy group ID configured for the ICCP daemon (iccpd) through the existing ICCP configuration hierarchy. For example,

    3. Specify the redundancy policy that releases primary role, the redundancy policy that acquires primary role, and the redundancy policy that triggers a warning.

      For example:

    4. Configure the frequency of health check probes of the redundancy set, in seconds.

      The default is 30 seconds.

    5. Configure the maximum wait time for a help check response, in seconds.

      The range is 0 through 3600 seconds.

    6. Configure the frequency of srd hello messages, in seconds.

      The range is 1 through 60 seconds.

  14. On gateway2, configure routing policies.
    1. Identify signal routes that requires redundancy-related routing changes. Specify the signal route and the routing table that is used.

      For example:

    2. To change the local-preference for the signal route, enter it in a policy statement.
    3. To change as-path-prepend values for the signal route, enter them in the policy statement.
  15. On gateway2, configure redundancy for the service set by assigning the redundancy set to the service set.

See Also