Building Next-Generation Data Center

Starting on April 25th

Register 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.

There are several ways to make automatic EVPN Route Targets work in EBGP environment:

  • Use the same AS number on all leaf switches, requiring more complex BGP neighbor configuration using allowas-in and/or as-override;
  • Ignore the AS portion of route target community (Free Range Routing implementation), or accept the AS number that matches the AS of the originating leaf. This approach modifies the commonly-understood EVPN Route Target handling and might not work in multi-vendor environment.
  • Using configurable AS number instead of local AS for the AS number part of Route Target extended community. Assuming the vendor implementing this approach uses the Auto-Derived bit specified in RFC 8365, you might experience interoperability challenges in multi-vendor environment.
At the time this article was published, most data center switching vendors did not support automatic EVPN route targets in EBGP 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.

More information

Table of Contents

Upcoming

  • Performance Impact of Running EVPN over EBGP Sessions
  • Impact of MPLS/VPN