Skip to main content
Sign Out

Welcome to Dell

My Account
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.
Sign In Create an Account Premier Sign In Partner Program Sign In
Contact Us

Dell EMC SmartFabric OS10 User Guide Release 10.5.0

PDF

VXLAN BGP EVPN operation

The EVPN address family allows VXLAN to carry EVPN routes in External Border Gateway Protocol (eBGP) and Internal Border Gateway Protocol (iBGP) sessions. In a data center network, use eBGP or iBGP for route exchange in both the IP underlay network and EVPN.

The following sample BGP EVPN topology shows a leaf-spine data center network where eBGP exchanges IP routes in the IP underlay network, and exchanges EVPN routes in the VXLAN overlay network. All spine nodes are in one autonomous system—AS 65535. All leaf nodes are in another autonomous system—AS 65000.

To advertise underlay IP routes, eBGP peer sessions establish between the leaf and spine nodes using an interface IP address. To advertise EVPN routes, eBGP peer sessions between the leaf and spine nodes use a Loopback IP address.

Figure 1. BGP EVPN topology. BGP EVPN topology
BGP EVPN topology

Leaf nodes

Leaf nodes are typically top-of-rack (ToR) switches in a data center network. They act as the VXLAN tunnel endpoints and perform VXLAN encapsulation and decapsulation. Leaf nodes also participate in the MP-BGP EVPN to support control plane and data plane functions.

Control plane functions include:
  • Initiate and maintain route adjacencies using any routing protocol in the underlay network.
  • Advertise locally learned routes to all MP-BGP EVPN peers.
  • Process the routes received from remote MP-BGP EVPN peers and install them in the local forwarding plane.
Data plane functions include:
  • Encapsulate server traffic with VXLAN headers and forward the packets in the underlay network.
  • Decapsulate VXLAN packets received from remote VTEPs and forward the native packets to downstream hosts.
  • Perform underlay route processing, including routing based on the outer IP address.

Spine nodes

The role of a spine node changes based on its control plane and data plane functions. Spine nodes participate in underlay route processing to forward packets and in the overlay network to advertise EVPN routes to all MP-BGP peers.

Control plane functions include:
  • Initiate BGP peering with all neighbor leaf nodes.
  • Advertise BGP routes to all BGP peers.
  • Initiate and maintain routing adjacencies with all leaf and spine nodes in the underlay network.
Data plane functions include:
  • Perform only underlay route processing based on the outer header in VXLAN encapsulated packets.
  • Does not perform VXLAN encapsulation or decapsulation.

The BGP EVPN running on each VTEP listens to the exchange of route information in the local overlay, encodes the learned routes as BGP EVPN routes, and injects them into BGP to advertise to the peers. Tunnel endpoints advertise as Type 3 EVPN routes. MAC/IP addresses advertise as Type 2 EVPN routes.

EVPN instance

An EVPN instance (EVI) spans across the VTEPs that participate in an Ethernet VPN. Each virtual-network tenant segment, that is advertised using EVPN, must associate with an EVI. In OS10, configure EVIs in auto-EVI or manual configuration mode.
  • Auto-EVI — After you configure a virtual network on a VTEP, auto-EVI mode automatically creates an EVPN instance. The route distinguisher (RD) and route target (RT) values automatically generate:
    • The EVI ID auto-generates with the same value as the virtual-network ID (VNID) configured on the VTEP and associates with the VXLAN network ID (VNI).
    • A Route Distinguisher auto-generates for each EVI ID. A Route Distinguisher maintains the uniqueness of an EVPN route between different EVPN instances.
    • A Route Target import and export value auto-generates for each EVI ID. A Route Target determines how EVPN routes distribute among EVPN instances.
  • Manual EVI configuration — To specify the RD and RT values, manually configure EVPN instances and associate each EVI with the overlay virtual network using the VXLAN VNI. The EVI activates only when you configure the virtual network, RD, and RT values.

    In manual EVI configuration, you can either manually configure the RD and RT or have them auto-configured.

Route distinguisher

The RD is an 8-byte identifier that uniquely identifies an EVI. Each EVPN route is prefixed with a unique RD and exchanged between BGP peers, making the tenant route unique across the network. In this way, overlapping address spaces among tenants are supported.

You can auto-generate or manually configure a RD for each EVI. In auto-EVI mode, the RD is auto-generated. In manual EVI configuration mode, you can auto-generate or manually configure the RD.

As specified in RFC 7432, a manually configured RD is encoded in the format: 4-octet-ipv4-address:2-octet-number. An auto-generated RD has the format: vtep-ip-address:evi.

Route target

While a RD maintains the uniqueness of an EVPN route among different EVIs, a RT controls the way the EVPN routes are distributed among EVIs. Each EVI is configured with an import and export RT value. BGP EVPN routes advertise for an EVI carry the export RT associated with the EVI. A receiving VTEP downloads information in the BGP EVPN route to EVIs that have a matching import RT value.

You can auto-generate or manually configure the RT import and export for each EVI. In auto-EVI mode, RT auto-generates. In manual EVI configuration mode, you can auto-generate or manually configure the RT.

The RT consists of a 2-octet type and a 6-octet value. If you auto-configure a RT, the encoding format is different for a 2-byte and 4-byte AS number (ASN):
  • For a 2-byte ASN, the RT type is set to 0200 (Type 0 in RFC 4364). The RT value is encoded in the format described in section 5.1.2.1 of RFC 8365: 2-octet-ASN: 4-octet-number, where the following values are used in the 4-octet-number field:
    • Type: 1
    • D-ID: 0
    • Service-ID: VNI
  • For a 4-byte ASN, the RT type is set to 0202 (Type 2 in RFC 4364). The RT value is encoded in the format: 4-octet-ASN: 2-octet-number, where the 2-octet-number field contains the EVI ID. In auto-EVI mode, the EVI ID is the same as the virtual network ID (VNID). Therefore, in 4-byte ASN deployment, OS10 supports RT auto-configuration if the VNID-to-VNI mapping is the same on all VTEPs.

Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please select whether the article was helpful or not.
  Comments cannot contain these special characters: <>()\