- Home
- Multi-Cloud Networking
- Customer Edge diagnostics
- Customer Edge high availability
- Routing and failover
Routing and failover
In a routing-level high-availability design, each Customer Edge (CE) site originates the same service prefix through Border Gateway Protocol (BGP). The northbound router installs the usable advertisements as Equal-Cost Multi-Path (ECMP) next hops and becomes the point that distributes traffic and removes failed paths.
service VIP /32 |upstream router: equal-cost next hops | | | CE site 1 CE site 2 CE site 3Advertise service addresses as routes
Section titled “Advertise service addresses as routes”Advertise an individual virtual IP address (VIP) as a /32 host route when the service is
IPv4. Reserve a route-only prefix for these service addresses, and do not attach that prefix
to a Virtual Private Cloud (VPC), Virtual Network (VNet), VLAN, or local subnet. The network
should learn the service addresses from routing advertisements rather than Address Resolution
Protocol (ARP) on an attached segment.
Keeping the service prefix separate avoids ambiguity between a connected route and the BGP route. It also makes route policy, filtering, and capacity planning explicit. Allocate the prefix according to the organization’s address-management process; do not copy a lab prefix into another network.
Let routing remove a failed path
Section titled “Let routing remove a failed path”An established BGP session gives the upstream router a liveness signal. When the session is closed or its hold timer expires, the peer withdraws the routes learned over that session. Bidirectional Forwarding Detection (BFD), when both peers support and enable it, can provide faster failure detection. Convergence time therefore depends on the configured protocol and timers; it is not instantaneous.
A static route has no equivalent session state. Static ECMP paths remain eligible after a CE fails unless the customer router or Software-Defined Wide Area Network (SD-WAN) controller tracks the next hop with a supported health mechanism and removes the route. Without that mechanism, the router can continue selecting a failed CE and blackhole some flows.
Size the router before the CE fleet
Section titled “Size the router before the CE fleet”The router decides how many equal-cost paths it installs. Compare its maximum ECMP path count with the number of CE advertisements expected for each VIP. When the advertisement count is greater than the installed-path limit, additional healthy CE sites may remain unused for that prefix.
Check the installed forwarding table rather than relying only on the BGP received-routes view. The control plane can retain more candidates than the data plane installs.
Treat preference and ECMP as different policies
Section titled “Treat preference and ECMP as different policies”Paths are equal-cost only while the route-selection attributes and metric make them equal. Changing local preference, Multi-Exit Discriminator (MED), administrative distance, or a static-route metric can make one CE preferred for a VIP. That is a valid steering policy, but it is active/preferred behavior rather than equal distribution.
Apply preference per prefix only when that asymmetry is intentional. Confirm that a less preferred path becomes usable when the preferred path is withdrawn, and do not leave an untracked static preferred path that survives its CE.
Separate control-plane labels from traffic evidence
Section titled “Separate control-plane labels from traffic evidence”In a design with multiple tunnels or paths, an ACTIVE label can identify the path selected
for control-plane synchronization without proving that other ECMP paths carry no data. Do not
infer forwarding state from that label alone. Verify the route or tunnel table and observe
traffic counters on every expected path.
Verify the complete path
Section titled “Verify the complete path”For each service prefix, verify all of the following:
- every intended CE advertises the prefix;
- the upstream BGP table accepts the expected paths;
- the forwarding table installs no more and no fewer paths than the platform supports;
- withdrawing one advertisement removes that next hop after the configured detection and convergence interval;
- application checks succeed through the remaining paths.
Use the repository’s BGP diagnostic workflow to distinguish CE advertisement problems from upstream forwarding problems.