BGP's AS-PATH loop prevention mechanism -- refusing to accept a route whose AS-PATH already contains the local ASN -- is BGP's primary defence against routing loops. In an AI fabric, this mechanism also controls what happens when links fail. Getting the ASN design right is therefore a reliability decision, not just a numbering exercise.

Consider a three-stage Clos fabric. Leaf1 has two servers: Server1 and Server5. Server5 is connected to Leaf2. Leaf1 and Leaf2 both connect to SpineA and SpineB. The normal path for Server1 -> Server5 is: Leaf1 -> SpineA (or SpineB) -> Leaf2 -> Server5. Two hops.

Now a link fails: the Leaf2 -> SpineA link goes down. SpineA can no longer reach Leaf2. What happens next depends entirely on ASN assignment.

Scenario A: all spines share the same ASN (recommended). SpineA and SpineB both have ASN 65000. Leaf1 receives the route to Server5 from SpineA and SpineB with their ASN in the path. When the Leaf2-SpineA link fails, SpineA withdraws the Server5 route. Leaf1 removes SpineA from ECMP. Traffic shifts to SpineB. SpineB still has a path to Leaf2. Two-hop path maintained. Clean.

Now suppose two links fail simultaneously: Leaf2-SpineA and Leaf2-SpineB. SpineA and SpineB both withdraw. Leaf1 has no route to Server5. The job sees a connectivity failure and the orchestrator restarts it on another server. This is correct behaviour -- the fabric is partitioned, and there is no valid path, so BGP truthfully declares it unreachable.

Scenario B: each spine has a unique ASN. SpineA = ASN 65001, SpineB = ASN 65002. When the Leaf2-SpineA link fails, SpineA has no direct route to Leaf2. But SpineA can still see Leaf2's prefixes via SpineB (through a hypothetical spine-to-spine link, or via Leaf1 if route reflection is used). The AS-PATH for Server5 via this route is: 65001 -> 65002 -> 65000 (Leaf2's ASN). SpineA will accept this because 65001 does not appear in the path. SpineA re-advertises it to Leaf1. Leaf1 now sends traffic via SpineA -> SpineB -> Leaf2 -- a three-hop path through an extra spine. That extra hop adds latency, and the intermediate Leaf2-SpineB link now carries twice the load. In an AI fabric where a single link already carries elephant flows at 80-90% utilisation, doubling the load on SpineB -> Leaf2 immediately causes congestion and PFC storms.

The fix is simple: use the same ASN on all switches at the same tier. All spines share one ASN. All super-spines share one ASN. All leaf switches have unique ASNs (they originate prefixes and need to be individually identifiable). This configuration is the recommendation of RFC 7938 and every major hyperscaler deployment.

BGP ADD-PATH extends the same fabric with multipath diversity. In a standard eBGP deployment, each router advertises only its single best path for a prefix. When Spine1 has three routes to Server5 (via Leaf2's three downlinks), it picks one and advertises that to Leaf1. Leaf1 sees only one path. ADD-PATH changes this: Spine1 advertises all three paths, each tagged with a path identifier. Leaf1 installs all three in its ECMP group. If one Leaf2 downlink fails, Leaf1 immediately has two remaining paths in its RIB without waiting for BGP convergence. ADD-PATH is especially valuable with route reflectors (iBGP): the RR can advertise all paths to all clients rather than a single best path, dramatically improving multipath redundancy.

AS-PATH strip and replace handles the case where the AI fabric connects to a private-ASN core network. If Server101 is in a remote data centre and its prefix arrives at the border-spine with a long private AS-PATH, the leaf switches will see different AS-PATH lengths for the same destination depending on which border-spine they ask. Route policies applied at the border-spine normalise this: strip the incoming AS-PATH and replace it with a predefined list of ASNs of equal length. All border-spines apply the same replacement. From the perspective of leaf switches, Server101 now appears equidistant through all border devices, and ECMP distributes traffic evenly across all border links.