VXLAN and BGP

Hi,
I have a layout with 2 spines and 6 leaf (2 couple in vpc); How many AS numbers should I create?
One per single element, or for 3 leaf vpc, one per vpc couple ?

Hello Paolo

That’s a good question. That is indeed a critical design decision, and there’s a clear best practice that should be followed. The short answer is: Each vPC pair should share a single AS number, not one AS per physical switch. Why? Let me explain…

In a vPC leaf pair, the two switches function as a single logical VTEP with a shared anycast VTEP address. From a BGP perspective, they should present themselves as a single autonomous system. Although each physical switch maintains its own router-id and forms independent BGP neighbor adjacencies to the spines, they share the same AS number because they’re advertising routes for the same VTEP.

Cisco’s NX-OS VXLAN Configuration Guide explicitly states: “A vPC leaf switch pair shares the same AS number.” This is the standard for eBGP VXLAN fabric design, whether you’re using the multi-AS model (unique AS per vPC pair) or the two-AS model (all leaves in one AS).

If each physical switch had its own AS, route-target (RT) auto-generation would create mismatches between vPC peers (the default RT format is ASN:VNI), so different AS numbers would cause the two switches to generate different RTs for the same VLAN. This breaks the seamless route exchange between the vPC pair members and complicates your design unnecessarily.

Your Topology

  • Spines: 1 shared AS (e.g., AS 100)
  • vPC Pair 1 (Leaf1a/Leaf1b): AS 65001
  • vPC Pair 2 (Leaf3a/Leaf3b): AS 65002
  • vPC Pair 3 (Leaf5a/Leaf5b): AS 65003

This gives you 4 total AS numbers, which is much cleaner and aligned with how Cisco designs and automates these fabrics. Remember: sharing an AS doesn’t mean sharing a BGP process; each switch still has its own router bgp configuration and its own neighbors to the spines. Make sense?

I hope this has been helpful!
Laz

Yes, makes sense, currently I have this situation in my lab, each single switch is an AS. Maybe with spine in the same AS I can remove spine bestpath as-path multipath-relax

If a single pair are in the same AS, must I use allowas-in ??

Hello Paolo

Yes, allowas-in is required when leaf switches share the same BGP AS number in a VXLAN/EVPN fabric using eBGP.

In a two-AS VXLAN design (all leafs in one AS, all spines in another), when a spine tries to relay a route learned from LEAF1 back to LEAF2 (both in the same AS), LEAF2 sees its own AS in the path and drops the route due to eBGP’s loop prevention mechanism, even though the spine advertised it correctly.

Actually, the complete fix requires two commands:

  • On the spine switches, disable-peer-as-check must be applied under both address-family ipv4 unicast and address-family l2vpn evpn. This tells the spine, “go ahead and advertise routes back to the other leaf, even though it shares that leaf’s AS.”
  • On the leaf switches, allowas-in must be applied under both address-family ipv4 unicast and address-family l2vpn evpn. This tells the leaf “accept routes with your own AS in the path, because you trust your spines.”

Both are needed because they solve different halves of the same problem: the spine won’t advertise without disable-peer-as-check, and the leaf won’t accept without allowas-in.

Yes, that is a valid design approach. If spine-1 and spine-2 are in the same AS, then the leaves will see the EVPN/underlay routes through both spines with the same AS-path structure, so you can remove the bgp bestpath as-path multipath-relax command on the leaf switches.

I hope this has been helpful!

Laz