Skip to content

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 3

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.

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.

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.

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.

  • RFC 4271 defines BGP route withdrawal and hold-timer behavior.
  • RFC 5880 defines BFD failure detection.