- play_arrow Overview
- play_arrow Configuring Redundancy and Failover in a Chassis Cluster
- Chassis Cluster Dual Control Links
- Chassis Cluster Dual Fabric Links
- Monitoring of Global-Level Objects in a Chassis Cluster
- Monitoring Chassis Cluster Interfaces
- Monitoring IP Addresses on a Chassis Cluster
- Configuring Cluster Failover Parameters
- Understanding Chassis Cluster Resiliency
- Chassis Cluster Redundancy Group Failover
- play_arrow Chassis Cluster Operations
- Aggregated Ethernet Interfaces in a Chassis Cluster
- NTP Time Synchronization on Chassis Cluster
- Active/Passive Chassis Cluster Deployments
- Example: Configuring an SRX Series Services Gateway as a Full Mesh Chassis Cluster
- Example: Configuring an Active/Active Layer 3 Cluster Deployment
- Multicast Routing and Asymmetric Routing on Chassis Cluster
- Ethernet Switching on Chassis Cluster
- Media Access Control Security (MACsec) on Chassis Cluster
- Understanding SCTP Behavior in Chassis Cluster
- Example: Encrypting Messages Between Two Nodes in a Chassis Cluster
- play_arrow Upgrading or Disabling a Chassis Cluster
- play_arrow Troubleshooting
- Troubleshooting a Control Link Failure in an SRX Chassis Cluster
- Troubleshooting a Fabric Link Failure in an SRX Chassis Cluster
- Troubleshooting a Redundancy Group that Does Not Fail Over in an SRX Chassis Cluster
- Troubleshooting an SRX Chassis Cluster with One Node in the Primary State and the Other Node in the Disabled State
- Troubleshooting an SRX Chassis Cluster with One Node in the Primary State and the Other Node in the Lost State
- Troubleshooting an SRX Chassis Cluster with One Node in the Hold State and the Other Node in the Lost State
- Troubleshooting Chassis Cluster Management Issues
- Data Collection for Customer Support
- play_arrow Configuration Statements and Operational Commands
- play_arrow Chassis Cluster Support on SRX100, SRX210, SRX220, SRX240, SRX550M, SRX650, SRX1400, SRX3400, and SRX3600 Devices
Conditional Route Advertisement over Redundant Ethernet Interfaces on SRX Series Firewalls in a Chassis Cluster
Conditional route advertising allows you to add criteria on route advertisements before they are installed in the route table or advertised to peers and neighbors. The goal of conditional route advertisement in a chassis cluster is to ensure that incoming traffic from the upstream network arrives on the node that is on the currently active redundant Ethernet interface. For more information, see the following topics:
Understanding Conditional Route Advertising in a Chassis Cluster
Route advertisement over redundant Ethernet interfaces in a chassis cluster is complicated by the fact that the active node in the cluster can change dynamically. Conditional route advertisement enables you to advertise routes in such a way that incoming traffic from the core network is attracted to the Border Gateway Protocol (BGP) interface that exists on the same node as the currently active redundant Ethernet interface. In this way, traffic is processed by the active node and does not traverse the fabric interface between nodes. You do this by manipulating the BGP attribute at the time routes are advertised by BGP.
The goal of conditional route advertisement in a chassis cluster is to ensure that incoming traffic from the upstream network arrives on the node that is on the currently active redundant Ethernet interface. To understand how this works, keep in mind that in a chassis cluster, each node has its own set of interfaces.
See Also
Example: Configuring Conditional Route Advertising in a Chassis Cluster
This example shows how to configure conditional route advertising in a chassis cluster to ensure that incoming traffic from the upstream network arrives on the node that is on the currently active redundant Ethernet interface.
Requirements
Before you begin, understand conditional route advertising in a chassis cluster. See Understanding Conditional Route Advertising in a Chassis Cluster.
Overview
As illustrated in Figure 1, routing prefixes learned from the redundant Ethernet interface through the IGP are advertised toward the network core using BGP. Two BGP sessions are maintained, one from interface ge-0/0/0 and one from ge-1/0/0 for BGP multihoming. All routing prefixes are advertised on both sessions. Thus, for a route advertised by BGP, learned over a redundant Ethernet interface, if the active redundant Ethernet interface is on the same node as the BGP session, you advertise the route with a “good” BGP attribute.

To achieve this behavior, you apply a policy to BGP before exporting routes. An additional term in the policy match condition determines the current active redundant Ethernet interface child interface of the next hop before making the routing decision. When the active status of a child redundant Ethernet interface changes, BGP reevaluates the export policy for all routes affected.
The condition statement in this configuration works as follows. The command states that any routes evaluated against this condition will pass only if:
The routes have a redundant Ethernet interface as their next-hop interface.
The current child interface of the redundant Ethernet interface is active at node 0 (as specified by the
route-active-on node0
keyword).content_copy zoom_out_map{primary:node0}[edit] user@host# set policy-options condition reth-nh-active-on-0 route-active-on node0
Note that a route might have multiple equal-cost next hops, and those next hops might be redundant Ethernet interfaces, regular interfaces, or a combination of both. The route still satisfies the requirement that it has a redundant Ethernet interface as its next hop.
If you use the BGP export policy set for node 0 in the previous example command, only OSPF routes that satisfy the following requirements will be advertised through the session:
The OSPF routes have a redundant Ethernet interface as their next hop.
The current child interface of the redundant Ethernet interface is currently active at node 0.
You must also create and apply a separate policy statement for the other BGP session by using this same process.
In addition to the BGP MED attribute, you can define additional BGP attributes, such as origin-code, as-path, and community.
Configuration
Procedure
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
copy and paste the commands into the CLI at the [edit]
hierarchy
level, and then enter commit
from configuration mode.
{primary:node0}[edit] set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0 from protocol ospf set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0 from condition reth-nh-active-on-0 set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0 then metric 10 set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0 then accept set policy-options condition reth-nh-active-on-0 route-active-on node0
Step-by-Step Procedure
To configure conditional route advertising:
Create the export policies with the created condition using the
condition
statement.content_copy zoom_out_map{primary:node0}[edit] user@host# set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0 from protocol ospf {primary:node0}[edit] user@host# set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0 from condition reth-nh-active-on-0 {primary:node0}[edit] user@host# set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0 then metric 10 {primary:node0}[edit] user@host# set policy-options policy-statement reth-nh-active-on-0 term ospf-on-0 then accept {primary:node0}[edit] user@host# set policy-options condition reth-nh-active-on-0 route-active-on node0
Results
From configuration mode, confirm your configuration
by entering the show policy-options
command. If the output
does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
{primary:node0}[edit] user@host# show policy-options policy-statement reth-nh-active-on-0 { term ospf-on-0 { from { protocol ospf; condition reth-nh-active-on-0; } then { metric 10; accept; } } } condition reth-nh-active-on-0 route-active-on node0;
If you are done configuring the device, enter commit
from configuration mode.