Decision: one spine ASN or many?

Context

An eBGP leaf-spine fabric, AI back-end or front-end, with BGP unnumbered. Every leaf gets its own ASN. The question is the spines: one shared ASN, or one each?

The failure that decides it

The link between Spine 1 and Leaf 3 fails. Spine 1 no longer hears Leaf 3 directly, but it still hears Leaf 3’s prefix from Leaf 2, which learned it through Spine 2.

• Unique spine ASNs: the AS path 65002 65102 65003 contains nothing Spine 1 recognises, so it accepts the route. Traffic from Leaf 1 that hashes to Spine 1 now goes down to Leaf 2, back up to Spine 2 and down to Leaf 3. Four hops instead of two, through a leaf never meant to carry transit, exactly when the fabric has lost capacity. This is a valley path.
• Shared spine ASN: Spine 1 sees its own ASN in the path and rejects it, as BGP always does. It withdraws Leaf 3’s prefix, and leaves use the other spines in two hops.

Options

Option	For	Against
Shared ASN on all spines	Loop prevention blocks valley paths for free; simple, as in RFC 7938	Spines are not distinguishable by ASN in AS paths
Unique ASN per spine	Easy to see which spine a path crossed	Valley paths after failures, unless filtered on every leaf

Decision

One shared ASN for all spines; in a three-tier fabric, one per pod’s spines and another for the super-spines. No allowas-in anywhere; if a design needs it, the ASN plan is fighting the topology.

What would change my mind

A fabric with deliberate transit through leaves, which an AI back-end never wants, or an IGP-based underlay where the question does not arise.

See RFC 7938 for the full eBGP data center design. Validate behavior in a lab before production.