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 master to the original standby).

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

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 mastership. 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 abort 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 mastership 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 mastership.

      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 mastership, 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 mastership.
    4. Delete the static route.
  3. Configure a redundancy event to identify when the peer gateway releases mastership.

    For example:

  4. Configure a redundancy policy that acquires mastership 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 mastership.

      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 mastership, 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 mastership.
    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 mastership and the redundancy policy that acquires mastership.

      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 master 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 master, 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 abort request triggers a services switchover.
  2. On gateway1, configure a redundancy policy that releases mastership 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 mastership.

      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 mastership, 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 mastership.
    4. Delete the static route.
  3. On gateway1, configure a redundancy policy that acquires mastership 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 mastership.
  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 mastership and the redundancy policy that acquires mastership.

      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 mastership.

    For example:

  8. On gateway2, configure a redundancy policy that acquires mastership 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 mastership release event.

      For example:

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

    For example:

  10. On gateway2, configure a redundancy policy that releases mastership and deletes a static route when gateway1 requests mastership.

    1. Configure a name for the policy.

      For example:

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

      For example:

    3. Release mastership.
    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 abort 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 mastership, the redundancy policy that acquires mastership, 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