Glossary

BGP FARE

BGP FARE (Full Adaptive Routing Ethernet)

What is BGP FARE

BGP FARE (Full Adaptive Routing Ethernet) is a BGP-based routing extension that gives switches deterministic, bandwidth-aware load balancing across multiple paths, without relying on real-time traffic telemetry. It builds on BGP's Path Bandwidth extended community attribute to propagate each link's true line-rate capacity, hop by hop, from source to destination.

Traditional ECMP (Equal-Cost Multi-Path) spreads traffic by hashing flow five-tuples across equal-cost links. That works well for internet or cloud traffic made up of many small, random flows, but AI training and HPC workloads look very different: a small number of extremely high-bandwidth "elephant flows" moving in tight synchronization. Static hashing has no visibility into physical link capacity, so it can easily collide several elephant flows onto the same link, causing severe micro-burst congestion and packet loss, while other member links sit idle. In non-uniform topologies — built out over multiple phases, mixing hardware generations, or degraded by fiber and optics faults — ECMP's rigid 1:1 distribution makes this worse by sending equal traffic down both healthy and impaired links alike.

BGP FARE was designed to solve this without introducing the instability that comes with dynamic, telemetry-driven traffic engineering, where control planes constantly recompute weights based on port utilization or queue depth and risk route flapping under microsecond-scale AI traffic bursts. Instead, BGP FARE keeps the control plane focused purely on physical link line-rate capacity, giving edge devices a stable, deterministic picture of where the real bandwidth bottleneck lies across the entire path.

How BGP FARE Works

BGP FARE propagates bandwidth constraints through the network using a strict "always take the smaller value" rule as routes are advertised hop by hop:

  1. Origin node: Before advertising a route, the node sets the Path Bandwidth attribute to the line-rate capacity of the outbound port carrying that advertisement.

  2. Transit nodes: A transit node that hears the same destination route from multiple upstream ports sums the advertised Path Bandwidth values from those ports, then divides that sum by the number of local outbound ports re-advertising the route, producing an average available bandwidth. Before re-advertising, it sets the Path Bandwidth attribute to whichever is smaller: this averaged upstream bandwidth, or the local outbound link's own line rate. Formally, for any two adjacent nodes N₁ and N₂ in the path, the outbound bandwidth advertisement is B(N₁→N₂) = min(inbound averaged bandwidth, local physical link line rate).

  3. Edge convergence: Repeating this min() operation at every hop lets true end-to-end bottleneck information synchronize and spread to the network edge, so any node ends up with a deterministic bandwidth figure for every path to every other node — without any active telemetry polling.

Each edge switch then converts these per-path bandwidth figures directly into WCMP (Weighted-Cost Multi-Path) forwarding weights, proportional to each path's advertised bandwidth (Wᵢ = Bᵢ / ΣBⱼ, scaled to integer ASIC weights). Because WCMP is implemented on top of ECMP in hardware — a path's weight determines how many times it's replicated as a member link — BGP FARE can be paired with packet spray, which ignores flow five-tuples entirely and distributes packets member-link by member-link in round-robin or random fashion. Together, this evenly balances both elephant flows and small flows at the packet level, eliminating hash polarization while forwarding traffic in the exact expected ratio.

Because Path Bandwidth is a native BGP attribute, link failures propagate through the same mechanism as any other route withdrawal: a node loses a link, revises its outbound Path Bandwidth value (or withdraws the route), and neighboring nodes recompute and re-advertise — inheriting BGP's mature, out-of-band-free convergence behavior without a separate telemetry controller.

Why BGP FARE is Beneficial

The core value of BGP FARE lies in combining deterministic bandwidth awareness with data-plane-level balancing:

· No route flapping: Weights are derived from static physical link line rates, not real-time occupancy or queue depth, so the control plane never enters the constant recompute cycles that cause route instability under bursty AI traffic.

· Eliminates elephant-flow collisions: Packet spray combined with WCMP distributes traffic packet by packet across all available links in the exact ratio their capacity allows, instead of hashing entire flows onto single links.

· Handles asymmetric topologies natively: In networks built out over multiple phases, mixing switch generations, or affected by partial link degradation, BGP FARE automatically skews traffic away from lower-capacity or impaired paths in proportion to their real capacity — rather than splitting traffic evenly regardless of health.

· Fast, self-contained failure convergence: Failure recovery rides on BGP's native route withdrawal mechanism, requiring no separate out-of-band telemetry controller and inheriting BGP's proven convergence performance at scale.

At Asteraix

What We Can Do at Asteraix

AsterNOS is built to bring BGP FARE's deterministic, bandwidth-aware path selection to large-scale AI and HPC fabrics:

· Line-rate-driven WCMP: AsterNOS derives WCMP forwarding weights directly from physical link bandwidth propagated via BGP Path Bandwidth, avoiding the instability of telemetry-driven dynamic weight recalculation.

· Packet spray for elephant flows: On supported platforms, AsterNOS can distribute packets across all WCMP member links regardless of flow five-tuple, maximizing link utilization for the low-flow-count, high-per-flow-bandwidth traffic typical of distributed AI training.

· Asymmetric and heterogeneous fabric support: In leaf-spine fabrics with mixed-generation hardware or degraded links, AsterNOS recalculates WCMP weights automatically as advertised bandwidth changes, steering traffic proportionally toward healthy, higher-capacity paths.

· Native BGP failure convergence: Because BGP FARE is implemented as a BGP extension, AsterNOS inherits BGP's convergence behavior for fast, controller-free failover when links degrade or fail — well suited to large-scale, long-running AI training clusters where recovery speed directly affects GPU utilization.

· Typical deployment: In a multi-tier Clos fabric connecting thousands to tens of thousands of GPUs, BGP FARE lets each leaf switch automatically shift traffic away from a spine experiencing link degradation or partial failure, without any manual re-tuning of ECMP groups or intervention from a centralized traffic engineering controller.