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.
|
Before You Begin |
|---|
|
For background information, read Understanding Chassis Cluster Formation |
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, bear in mind that in a chassis cluster, each node has its own set of interfaces. Figure 74 shows a typical scenario, with a redundant Ethernet interface connecting the corporate LAN, through a chassis cluster, to an external network segment.
Figure 74: Conditional Route Advertising

As illustrated in Figure 74, routing prefixes learned from the redundant Ethernet interface through the interior gateway protocol (IGP) are advertised toward the network core using BGP. Two BGP sessions are maintained, one off interface t1-1/0/0 and one off t1-1/0/1 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.
- {primary:node1}
- user@host# set policy-options policy-statement
reth-nh-active-on-0 term ospf-on-0 from
protocol ospf
- {primary:node1}
- user@host# set policy-options policy-statement
reth-nh-active-on-0 term ospf-on-0 from
condition reth-nh-active-on-0
- {primary:node1}
- user@host#set policy-options policy-statement
reth-nh-active-on-0 term ospf-on-0 then
metric 10
- {primary:node1}
- user@host# set policy-options policy-statement
reth-nh-active-on-0 term ospf-on-0 then
accept
- {primary:node1}
- user@host# set policy-options condition reth-nh-active-on-0
route-active-on node0
The condition statement in this configuration works as follows. The command states that any routes evaluated against this condition will pass only if:
- {primary:node1}
- 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:
You must also create and apply a separate policy statement for the other BGP session using this same concept.
In addition to the BGP MED attribute, you can define additional BGP attributes, such as origin-code, as-path, and community.
Verifying the Chassis Cluster Configuration