Building Next-Generation Data Center

12 module online course

Start now!

EVPN Route Target Considerations

ipSpace.net » Documents » Using BGP in a Data Center Leaf-and-Spine Fabric » EVPN Route Target Considerations

Similar to MPLS/VPN, EVPN uses Route Target extended BGP community to indicate the VPN membership of individual prefixes advertised EVPN BGP updates. The Route Target community could take any of the common formats, using IP address or AS number in the high-order bits.

Most vendors did not support 32-bit (4-octet) AS numbers and corresponding Large BGP Communities (RFC 8195) with EVPN at the time this article was been published. You could, however, use the 4-octet AS number with 2-octet identifier within a standard BGP community.

BGP MPLS-Based Ethernet VPN (RFC 7432) and A Network Virtualization Overlay Solution Using Ethernet VPN (RFC 8365) advocate the use of automatic Route Targets based on local AS number and VLAN (RFC 7432) or VXLAN/NVGRE/I-SID/VLAN ID (RFC 8365) in simple EVPN topologies. This approach works very well as long as all the PE-switches use the same BGP AS number, resulting in matching Route Target values on all PE-routers.

You cannot use automatic Route Targets with standard BGP communities and 4-octet AS numbers, as the automatically-generated portion of the Route Target community does not fit into two octets.

Simplest designs using EBGP as the underlay fabric routing protocol use a different AS number on every leaf switch (see Autonomous Systems and AS Numbers section), resulting in automatic Route Targets that are not comparable between PE-switches. It’s thus impossible to deploy simple EBGP-based EVPN fabric without manual Route Target configuration or modification of Route Target handling during the EVPN prefix import process.

At the time this article was published, most data center switching vendors did not support automatic EVPN route targets in EBGP environment.

There are several ways to make automatic EVPN Route Targets work in environments using EBGP as the underlay fabric routing protocol.

An oft-proposed approach uses the same AS number on all leaf switches. This design clearly works, but requires more complex BGP neighbor configuration using allowas-in and/or as-override.

Several vendors modified local BGP behavior to support auto-generated EVPN route targets across multiple AS numbers:

  • Free Range Routing ignores the AS portion of route target community;
  • Cisco Nexus OS can rewrite the EVPN Route Target AS number in incoming BGP updates to local AS number[1].

Other tweaks you might see include:

  • Accept the AS number that matches the AS of the originating leaf;
  • Use configurable AS number instead of local AS for the AS number part of Route Target extended community, including proposed use of AS_TRANS (defined in RFC 4893) in 4-byte ASN environment.

All these options are vendor-specific modifications to local BGP behavior (similar to BGP weights). While they should have no impact on other EVPN nodes in the same fabric, I’d recommend extensive testing if you want to use them in multi-vendor environment.

Summary:

  • If you’re building a large EVPN fabric that requires EBGP as the underlay routing protocol, use an implementation that supports automatic route targets in multi-AS environment, or fully automate the EVPN/VXLAN deployment.
  • In smaller fabrics, particularly when using vendors that don’t support automatic route targets in multi-AS environment, use IBGP-based EVPN with an IGP as the underlying routing protocol.

Notes

  1. See EBGP underlay IP network section in Cisco Programmable Fabric with VXLAN BGP EVPN Configuration Guide (http://goo.gl/gbNjsf).

More information