close

keyboard_arrow_left

Table of Contents Expand all

play_arrow Overview
- play_arrow Next Gen Services Overview
  - Next Gen Services Overview
- play_arrow Configuration Overview
- play_arrow Global System Logging Overview and Configuration
- play_arrow Next Gen Services SNMP MIBS and Traps
  - Next Gen Services SNMP MIBs and Traps
play_arrow Carrier Grade NAT (CGNAT)
- play_arrow Deterministic NAT Overview and Configuration
  - Deterministic NAPT Overview for Next Gen Services
  - Configuring Deterministic NAPT for Next Gen Services
- play_arrow Dynamic Address-Only Source NAT Overview and Configuration
  - Dynamic Address-Only Source Translation Overview
  - Configuring Dynamic Address-Only Source NAT for Next Gen Services
- play_arrow Network Address Port Translation Overview and Configuration
  - Network Address Port Translation (NAPT) Overview
  - Configuring Network Address Port Translation for Next Gen Services
  - Configuring Syslog Events for NAT Rule Conditions with Next Gen Services
- play_arrow NAT46
  - NAT46 Next Gen Services Configuration Examples
- play_arrow Stateful NAT64 Overview and Configuration
  - Stateful NAT64 Overview
  - IPv4 Addresses Embedded in IPv6 Addresses
  - Configuring Next Gen Services Stateful NAT64
- play_arrow IPv4 Connectivity Across IPv6-Only Network Using 464XLAT Overview and Configuration
  - 464XLAT Overview
  - IPv4 Addresses Embedded in IPv6 Addresses
  - Configuring 464XLAT Provider-Side Translator for IPv4 Connectivity Across IPv6-Only Network for Next Gen Services
- play_arrow IPv6 NAT Protocol Translation (NAT PT)
  - IPv6 NAT PT Overview
  - IPv6 NAT-PT Communication Overview
- play_arrow Stateless Source Network Prefix Translation for IPv6 Overview and Configuration
  - Stateless Source Network Prefix Translation for IPv6
- play_arrow Transitioning to IPv6 Using Softwires
  - 6rd Softwires in Next Gen Services
- play_arrow Transitioning to IPv6 Using DS-Lite Softwires
  - DS-Lite Softwires—IPv4 over IPv6 for Next Gen Services
  - Configuring Next Gen Services DS-Lite Softwires
  - DS-Lite Subnet Limitation
  - Protecting CGN Devices Against Denial of Service (DOS) Attacks
- play_arrow Reducing Traffic and Bandwidth Requirements Using Port Control Protocol
  - Port Control Protocol Overview
  - Configuring Port Control Protocol
- play_arrow Transitioning to IPv6 Using Mapping of Address and Port with Encapsulation (MAP-E)
  - Mapping of Address and Port with Encapsulation (MAP-E) for Next Gen Services
  - Equal Cost Multiple Path (ECMP) support for Mapping of Address and Port with Encapsulation (MAP-E)
- play_arrow Monitoring and Troubleshooting Softwires
  - Ping and Traceroute for DS-Lite
  - Monitoring Softwire Statistics
  - Monitoring CGN, Stateful Firewall, and Softwire Flows
- play_arrow Port Forwarding Overview and Configuration
  - Port Forwarding for Next Gen Services
- play_arrow Port Translation Features Overview and Configuration
  - Address Pooling and Endpoint Independent Mapping for Port Translation
  - Round-Robin Port Allocation
  - Secured Port Block Allocation for Port Translation
- play_arrow Static Source NAT Overview and Configuration
  - Static Source NAT Overview
  - Configuring Static Source NAT44 or NAT66 for Next Gen Services
- play_arrow Static Destination NAT Overview and Configuration
  - Static Destination NAT Overview
  - Configuring Static Destination NAT for Next Gen Services
- play_arrow Twice NAPT Overview and Configuration
  - Twice NAPT Overview
  - Configuring Twice NAPT for Next Gen Services
- play_arrow Twice NAT Overview and Configuration
  - Twice Static NAT Overview
  - Configuring Twice Static NAT44 for Next Gen Services
  - Twice Dynamic NAT Overview
  - Configuring Twice Dynamic NAT for Next Gen Services
- play_arrow Class of Service Overview and Configuration
  - Class of Service for Services PICs (Next Gen Services)
play_arrow Stateful Firewall Services
- play_arrow Stateful Firewall Services Overview and Configuration
  - Stateful Firewall Overview for Next Gen Services
  - Configuring Stateful Firewalls for Next Gen Services
play_arrow Intrusion Detection Services
- play_arrow IDS Screens for Network Attack Protection Overview and Configuration
play_arrow Traffic Load Balancing
- play_arrow Traffic Load Balancing Overview and Configuration
  - Traffic Load Balancer Overview
  - Configuring TLB
play_arrow DNS Request Filtering
- play_arrow DNS Request Filtering Overview and Configuration
  - DNS Request Filtering for Disallowed Website Domains
  - DNS Request Filtering System Logging Error Messages
play_arrow URL Filtering
- play_arrow URL Filtering
  - URL Filtering Overview
  - Configuring URL Filtering
play_arrow Integration of Juniper ATP Cloud and Web filtering on MX Routers
- play_arrow Integration of Juniper ATP Cloud and Web filtering on MX Routers
  - Integration of Juniper ATP Cloud and Web Filtering on MX Series Routers
play_arrow Aggregated Multiservices Interfaces
- play_arrow Enabling Load Balancing and High Availability Using Multiservices Interfaces
play_arrow Inter-Chassis Services PIC High Availability
- play_arrow Inter-Chassis Services PIC High Availability Overview and Configuration
play_arrow Application Layer Gateways
- play_arrow Enabling Traffic to Pass Securely Using Application Layer Gateways
play_arrow NAT, Stateful Firewall, and IDS Flows
- play_arrow Inline NAT Services Overview and Configuration
play_arrow Configuration Statements

list Table of Contents

English

Configuring Inter-Chassis Services Redundancy for Next Gen Services

date_range 06-Dec-23

arrow_backward

arrow_forward

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:

content_copy zoom_out_map
request services redundancy-set redundancy-set trigger redundancy-event event-name <force>

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:

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.
  [edit services] user@host# set event-options redundancy-event event-name
  For example:
  [edit services] user@host# set event-options redundancy-event RELS_MSHIP_CRIT_EV
2. Specify any interfaces that trigger a services switchover when the interface goes down.
  [edit services event-options redundancy-event event-name] user@host# set monitor link-down [interface-name]
3. Specify that a process routing daemon restart request triggers a services switchover.
  [edit services event-options redundancy-event event-name] user@host# set monitor process routing restart
4. Specify that a process routing daemon terminate request triggers a services switchover.
  [edit services event-options redundancy-event event-name] user@host# set monitor process routing abort
5. Specify that a request from the peer to acquire ownership triggers a services switchover.
  [edit services event-options redundancy-event event-name] user@host# set monitor peer mastership-acquire
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.
  user@host# edit policy-options redundancy-policy policy-name
  For example:
  user@host# edit policy-options redundancy-policy RLS_MSHIP_POL
2. Specify the redundancy events that release primary role.
  [edit policy-options redundancy-policy policy-name] user@host# set redundancy-events [event-list]
  For example:
  [edit policy-options redundancy-policy RLS_MSHIP_POL user@host# set redundancy-events RELS_MSHIP_CRIT_EV
  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:
  [edit policy-options redundancy-policy RLS_MSHIP_POL user@host# set redundancy-events [RELS_MSHIP_CRIT_EV RELS_MSHIP_MANUAL_EV]
3. Release primary role.
  [edit policy-options redundancy-policy policy-name] user@host# set then release-mastership
4. Delete the static route.
  [edit policy-options redundancy-policy policy-name] user@host# set then delete-static-route destination (receive | next-hop next-hop) routing-instance routing-instance

Configure a redundancy event to identify when the peer gateway releases primary role.

content_copy zoom_out_map
[edit services]
user@host# set event-options redundancy-event event-name monitor peer release-mastership

For example:

content_copy zoom_out_map
[edit services]
user@host# set event-options redundancy-event PEER_RELS_MSHIP_EV monitor peer release-mastership

Configure a redundancy policy that acquires primary role from the peer gateway and adds a static route.
1. Configure a name for the policy.
  user@host# edit policy-options redundancy-policy policy-name
  For example:
  user@host# edit policy-options redundancy-policy ACQU_MSHIP_POL
2. Specify the redundancy events that acquire primary role.
  [edit policy-options redundancy-policy policy-name] user@host# set redundancy-events [event-list]
  For example:
  [edit policy-options redundancy-policy ACQU_MSHIP_POL] user@host# set redundancy-events PEER_RELS_MSHIP_EV
  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:
  [edit policy-options redundancy-policy ACQU_MSHIP_POL] user@host# set redundancy-events [PEER_RELS_MSHIP_EV ACQU_MSHIP_MANUAL_EV]
3. Acquire primary role.
  [edit policy-options redundancy-policy policy-name] user@host# set then acquire-mastership
4. Add a static route.
  [edit policy-options redundancy-policy policy-name] user@host# set then add-static-route destination (receive | next-hop next-hop) routing-instance routing-instance
Configure the redundancy set.
1. Configure a name for the redundancy set.
  [edit services] user@host# set redundancy-set redundancy-set
  For example:
  [edit services] user@host# set redundancy-set 1
2. Specify the redundancy group ID for the redundancy set.
  [edit services redundancy-set redundancy-set] user@host# set redundancy-group redundancy-group
  For example:
  [edit services redundancy-set 1] user@host# set redundancy-group 1
  The redundancy group ID is the same redundancy group ID configured for the ICCP daemon (iccpd) through the existing ICCP configuration hierarchy. For example,
  iccp { local-ip-addr 10.1.1.1; peer 10.2.2.2 { redundancy-group-id-list 1; liveness-detection { minimum-interval 1000; } } }
3. Specify the redundancy policy that releases primary role and the redundancy policy that acquires primary role.
  [edit services redundancy-set redundancy-set] user@host# set redundancy-policy [redundancy-policy-list]
  For example:
  [edit services redundancy-set 1] user@host# set redundancy-policy [ACQU_MSHIP_POL RLS_MSHIP_POL]
4. Configure the frequency of health check probes of the redundancy set, in seconds.
  [edit services redundancy-set redundancy-set] user@host# set healthcheck-timer-interval healthcheck-timer-interval
  The default is 30 seconds.
5. Configure the maximum wait time for a help check response, in seconds.
  [edit services redundancy-set redundancy-set] user@host# set hold-time hold-time
  The range is 0 through 3600 seconds.
6. Configure the frequency of srd hello messages, in seconds.
  [edit services redundancy-set redundancy-set] user@host# set keepalive keepalive
  The range is 1 through 60 seconds.

Configure routing policies.

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

content_copy zoom_out_map
[edit policy-options condition condition-name}
user@host# set if-route-exists signal-route table routing-table

For example:

content_copy zoom_out_map
[edit policy-options condition switchover-route-exists]
user@host# set if-route-exists 10.45.45.0/24 table bgp1_table

To change the local-preference for the signal route, enter it in a policy statement.

content_copy zoom_out_map
[edit policy-options policy-statement policy-name]
user@host# set term term from protocol [protocol variables] prefix-list prefix-list condition condition-name then local-preference preference-value accept 

To change as-path-prepend values for the signal route, enter them in the policy statement.

content_copy zoom_out_map
[edit policy-options policy-statement policy-name]
user@host#  set term term from prefix-list prefix-list condition condition-name then as-path-prepend [as-prepend-values] next-hop self accept 

Configure redundancy for the service set by assigning the redundancy set to the service set.
```
[edit]
user@host# set services service-set service-set-name redundancy-set-id redundancy-set
```
Repeat these steps on the peer gateway.

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.

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.
  [edit services] user@gateway1# set event-options redundancy-event event-name
  For example:
  [edit services] user@gateway1# set event-options redundancy-event RELS_MSHIP_CRIT_EV
2. Specify any interfaces that trigger a services switchover when the interface goes down.
  [edit services event-options redundancy-event event-name] user@gateway1# set monitor link-down [interface-name]
3. Specify that a process routing daemon restart request triggers a services switchover.
  [edit services event-options redundancy-event event-name] user@gateway1# set monitor process routing restart
4. Specify that a process routing daemon terminate request triggers a services switchover.
  [edit services event-options redundancy-event event-name] user@gateway1# set monitor process routing abort
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.
  user@gateway1# edit policy-options redundancy-policy policy-name
  For example:
  user@gateway1# edit policy-options redundancy-policy RLS_MSHIP_POL
2. Specify the redundancy events that release primary role.
  [edit policy-options redundancy-policy policy-name] user@gateway1# set redundancy-events [event-list]
  For example:
  [edit policy-options redundancy-policy RLS_MSHIP_POL] user@gateway1# set redundancy-events RELS_MSHIP_CRIT_EV
  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:
  [edit policy-options redundancy-policy RLS_MSHIP_POL] user@gateway1# set redundancy-events [RELS_MSHIP_CRIT_EV RELS_MSHIP_MANUAL_EV]
3. Release primary role.
  [edit policy-options redundancy-policy policy-name] user@gateway1# set then release-mastership force
4. Delete the static route.
  [edit policy-options redundancy-policy policy-name] user@gateway1# set then delete-static-route destination (receive | next-hop next-hop) routing-instance routing-instance
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.
  user@gateway1# edit policy-options redundancy-policy policy-name
  For example:
  user@gateway1# edit policy-options redundancy-policy ACQU_MSHIP_POL
2. Specify the name of the redundancy event that the manual request uses.
  [edit policy-options redundancy-policy policy-name] user@gateway1# set redundancy-events event-name
  For example:
  [edit policy-options redundancy-policy ACQU_MSHIP_POL] user@gateway1# set redundancy-events ACQU_MSHIP_MANUAL_EV
  The redundancy event itself does not need to be configured, because it is triggered by the request command.
3. Acquire primary role.
  [edit policy-options redundancy-policy policy-name] user@host# set then acquire-mastership
On gateway1, configure the redundancy set.
1. Configure a name for the redundancy set.
  [edit services] user@gateway1# set redundancy-set redundancy-set
  For example:
  [edit services] user@gateway1# set redundancy-set 1
2. Specify the redundancy group ID for the redundancy set.
  [edit services redundancy-set redundancy-set] user@gateway1# set redundancy-group redundancy-group
  For example:
  [edit services redundancy-set 1] user@gateway1# set redundancy-group 1
  The redundancy group ID is the same redundancy group ID configured for the ICCP daemon (iccpd) through the existing ICCP configuration hierarchy. For example,
  iccp { local-ip-addr 10.1.1.1; peer 10.2.2.2 { redundancy-group-id-list 1; liveness-detection { minimum-interval 1000; } } }
3. Specify the redundancy policy that releases primary role and the redundancy policy that acquires primary role.
  [edit services redundancy-set redundancy-set] user@gateway1# set redundancy-policy [redundancy-policy-list]
  For example:
  [edit services redundancy-set 1] user@gateway1# set redundancy-policy [ ACQU_MSHIP_POL RLS_MSHIP_POL]
4. Configure the frequency of health check probes of the redundancy set, in seconds.
  [edit services redundancy-set redundancy-set] user@gateway1# set healthcheck-timer-interval healthcheck-timer-interval
  The default is 30 seconds.
5. Configure the maximum wait time for a help check response, in seconds.
  [edit services redundancy-set redundancy-set] user@gateway1# set hold-time hold-time
  The range is 0 through 3600 seconds.
6. Configure the frequency of srd hello messages, in seconds.
  [edit services redundancy-set redundancy-set] user@gateway1# set keepalive keepalive
  The range is 1 through 60 seconds.

On gateway1, configure routing policies.

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

content_copy zoom_out_map
[edit policy-options condition condition-name}
user@gateway1# set if-route-exists signal-route table routing-table

For example:

content_copy zoom_out_map
[edit policy-options condition switchover-route-exists]
user@gateway1# set if-route-exists 10.45.45.0/24 table bgp1_table

To change the local-preference for the signal route, enter it in a policy statement.

content_copy zoom_out_map
[edit policy-options policy-statement policy-name]
user@gateway1# set term term from protocol [protocol variables] prefix-list prefix-list condition condition-name then local-preference preference-value accept 

To change as-path-prepend values for the signal route, enter them in the policy statement.

content_copy zoom_out_map
[edit policy-options policy-statement policy-name]
user@gateway1# set term term from prefix-list prefix-list condition condition-name then as-path-prepend [as-prepend-values] next-hop self accept 

On gateway1, configure redundancy for the service set by assigning the redundancy set to the service set.
```
[edit]
user@gateway1# set services service-set service-set-name redundancy-set-id redundancy-set
```

On gateway2, the initial standby, configure a redundancy event to identify when the peer gateway releases primary role.

content_copy zoom_out_map
[edit services]
user@gateway2# set event-options redundancy-event event-name monitor peer release-mastership

For example:

content_copy zoom_out_map
[edit services]
user@gateway2# set event-options redundancy-event PEER_RELS_MSHIP_EV monitor peer release-mastership

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

Configure a name for the policy.

content_copy zoom_out_map
user@gateway2# edit policy-options redundancy-policy policy-name

For example:

content_copy zoom_out_map
user@gateway2# edit policy-options redundancy-policy ACQU_MSHIP_POL

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

content_copy zoom_out_map
[edit policy-options redundancy-policy policy-name]
user@gateway2# set redundancy-events event-name 

For example:

content_copy zoom_out_map
[edit policy-options redundancy-policy ACQU_MSHIP_POL]
user@gateway2# set redundancy-events PEER_RELS_MSHIP_EV

Acquire primary role.

content_copy zoom_out_map
[edit policy-options redundancy-policy policy-name]
user@gateway2# set then acquire-mastership

Add a static route.

content_copy zoom_out_map
[edit policy-options redundancy-policy policy-name]
user@gateway2# set then add-static-route destination (receive | next-hop next-hop) routing-instance routing-instance

On gateway2, configure a redundancy event to identify when the peer gateway requests primary role.

content_copy zoom_out_map
[edit services]
user@gateway2# set event-options redundancy-event event-name monitor peer mastership-acquire

For example:

content_copy zoom_out_map
[edit services]
user@gateway2# set event-options redundancy-event PEER_MSHIP_ACQU_EV monitor peer mastership-acquire

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

Configure a name for the policy.

content_copy zoom_out_map
user@gateway2# edit policy-options redundancy-policy policy-name

For example:

content_copy zoom_out_map
user@gateway2# edit policy-options redundancy-policy RELS-MSHIP_POL

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

content_copy zoom_out_map
[edit policy-options redundancy-policy policy-name]
user@gateway2# set redundancy-events event-name

For example:

content_copy zoom_out_map
[edit policy-options redundancy-policy RELS-MSHIP_POL]
user@gateway2# set redundancy-events PEER_MSHIP_ACQU_EV

Release primary role.

content_copy zoom_out_map
[edit policy-options redundancy-policy policy-name]
user@gateway2# set then release-mastership force

Delete the static route.

content_copy zoom_out_map
[edit policy-options redundancy-policy policy-name]
user@gateway2# set then delete-static-route destination (receive | next-hop next-hop) routing-instance routing-instance

On gateway2, configure one or more redundancy events to monitor the conditions that trigger a warning.
1. Configure a name for the redundancy event.
  [edit services] user@gateway2# set event-options redundancy-event event-name
  For example:
  [edit services] user@gateway2# set event-options redundancy-event WARN_EV
2. Specify any interfaces that trigger a warning when the interface goes down.
  [edit services event-options redundancy-event event-name] user@gateway2# set monitor link-down [interface-name]
3. Specify that a process routing daemon restart request triggers a warning.
  [edit services event-options redundancy-event event-name] user@gateway2# set monitor process routing restart
4. Specify that a process routing daemon terminate request triggers a warning.
  [edit services event-options redundancy-event event-name] user@gateway2# set monitor process routing abort

On gateway2, configure a redundancy policy that broadcasts a warning.

Configure a name for the policy.

content_copy zoom_out_map
user@gateway2# edit policy-options redundancy-policy policy-name

For example:

content_copy zoom_out_map
user@gateway2# edit policy-options redundancy-policy WARN_POL

Specify the configured redundancy events that trigger a warning.

content_copy zoom_out_map
[edit policy-options redundancy-policy policy-name]
user@gateway2# set redundancy-events [event-list]

For example:

content_copy zoom_out_map
[edit policy-options redundancy-policy WARN_POL]
user@gateway2# set redundancy-events WARN_EV

Broadcast the warning.

content_copy zoom_out_map
[edit policy-options redundancy-policy policy-name]
user@gateway2# set then broadcast-warning

On gateway2, configure the redundancy set.
1. Configure a name for the redundancy set.
  [edit services] user@gateway2# set redundancy-set redundancy-set
  For example:
  [edit services] user@gateway2# set redundancy-set 1
2. Specify the redundancy group ID for the redundancy set.
  [edit services redundancy-set redundancy-set] user@gateway2# set redundancy-group redundancy-group
  For example:
  [edit services redundancy-set 1] user@gateway2# set redundancy-group 1
  The redundancy group ID is the same redundancy group ID configured for the ICCP daemon (iccpd) through the existing ICCP configuration hierarchy. For example,
  iccp { local-ip-addr 10.1.1.1; peer 10.2.2.2 { redundancy-group-id-list 1; liveness-detection { minimum-interval 1000; } } }
3. Specify the redundancy policy that releases primary role, the redundancy policy that acquires primary role, and the redundancy policy that triggers a warning.
  [edit services redundancy-set redundancy-set] user@gateway2# set redundancy-policy [redundancy-policy-list]
  For example:
  [edit services redundancy-set 1] user@gateway2# set redundancy-policy [ ACQU_MSHIP_POL RLS_MSHIP_POL WARN_POL]
4. Configure the frequency of health check probes of the redundancy set, in seconds.
  [edit services redundancy-set redundancy-set] user@gateway2# set healthcheck-timer-interval healthcheck-timer-interval
  The default is 30 seconds.
5. Configure the maximum wait time for a help check response, in seconds.
  [edit services redundancy-set redundancy-set] user@gateway2# set hold-time hold-time
  The range is 0 through 3600 seconds.
6. Configure the frequency of srd hello messages, in seconds.
  [edit services redundancy-set redundancy-set] user@gateway2# set keepalive keepalive
  The range is 1 through 60 seconds.

On gateway2, configure routing policies.

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

content_copy zoom_out_map
[edit policy-options condition condition-name}
user@gateway2# set if-route-exists signal-route table routing-table

For example:

content_copy zoom_out_map
[edit policy-options condition switchover-route-exists]
user@gateway2# set if-route-exists 10.45.45.0/24 table bgp1_table

To change the local-preference for the signal route, enter it in a policy statement.

content_copy zoom_out_map
[edit policy-options policy-statement policy-name]
user@gateway2# set term term from protocol [protocol variables] prefix-list prefix-list condition condition-name then local-preference preference-value accept 

To change as-path-prepend values for the signal route, enter them in the policy statement.

content_copy zoom_out_map
[edit policy-options policy-statement policy-name]
user@gateway2#  set term term from prefix-list prefix-list condition condition-name then as-path-prepend [as-prepend-values] next-hop self accept 

On gateway2, configure redundancy for the service set by assigning the redundancy set to the service set.
```
[edit]
user@gateway2# set services service-set service-set-name redundancy-set-id redundancy-set
```

arrow_backward PREVIOUS Inter-Chassis Services Redundancy Overview for Next Gen Services

NEXT arrow_forward Next Gen Services Application Layer Gateways

Next Gen Services Interfaces User Guide for Routing Devices

ON THIS PAGE

Configuring Inter-Chassis Services Redundancy for Next Gen Services

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

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

Stay in touch

Helped me install or use the product
Accelerated my deployment

Discuss the product with a co-worker
Make a purchase inquiry

Next Gen Services Interfaces User Guide for Routing Devices

ON THIS PAGE

Configuring Inter-Chassis Services Redundancy for Next Gen Services

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

See Also

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

See Also

Stay in touch