Octet

Explain route distinguishers and route targets in EVPN. What breaks when you use auto-derived route targets with eBGP?

Show the answer

Say this first

The RD only makes routes unique in BGP, so the same MAC or prefix from two leaves does not collide. The RT is an extended community that decides import: a leaf imports a route into a MAC-VRF or IP-VRF when an RT matches. NX-OS derives auto RTs as local-ASN:VNI. With one ASN per leaf, LEAF1 exports 65001:10010 and LEAF2 imports 65002:10010, so nothing is imported. Fix it with the same manual RTs everywhere, or with NX-OS rewrite-evpn-rt-asn on the eBGP EVPN neighbors.

Go deeper

Route distinguisher

  • NX-OS rd auto for a MAC-VRF is router-ID:(32767 + VLAN ID). VLAN 10 on router ID 10.0.0.11 gives 10.0.0.11:32777.
  • Keep RDs unique per leaf. If two leaves used the same RD for the same prefix, a spine or route reflector would see one NLRI, keep one best path and hide the other leaf, which breaks ECMP to anycast or multihomed destinations.

Route target

  • Set per MAC-VRF (L2VNI) and per IP-VRF (L3VNI). A MAC+IP type 2 carries both.
  • Import policy can differ from export: a shared-services VRF can import from many tenants.

The eBGP auto RT mismatch

LeafASNAuto export RTAuto import RT
LEAF16500165001:1001065001:10010
LEAF26500265002:1001065002:10010

Fixes:

  1. Manual RTs with a fabric convention, for example route-target both 65000:10010 for VNI 10010.
  2. rewrite-evpn-rt-asn under the L2VPN EVPN address family of each eBGP neighbor on NX-OS: the receiver replaces the ASN part of incoming RTs with its own before import.

Spine behavior with eBGP EVPN

  • NX-OS spines have no VNIs, so they drop routes with no matching import RT unless you configure retain route-target all under address-family l2vpn evpn.
  • Spines must keep the next hop: NX-OS uses an outbound route-map with set ip next-hop unchanged, EOS uses neighbor ... next-hop-unchanged.

Traps

  • Treating the RD as import control. It has no policy meaning at all.
How did you do?