Arista's EVPN Implementation Explained

Chapter 21
EVPN
This chapter describes Arista’s EVPN implementation. Sections in this chapter include:
• Section 21.1: EVPN Overview
• Section 21.2: EVPN Core Operations
• Section 21.3: Integrated Routing and Bridging
• Section 21.4: EVPN Type-5 Routes: IP Prefix Advertisement
• Section 21.5: Configuration Examples
1005
EVPN Overview Chapter 21: EVPN
21.1 EVPN Overview

Ethernet VPN (EVPN) is a standards-based BGP control plane to advertise MAC addresses, MAC and
IP bindings and IP Prefixes. This document focuses on EVPN and it’s operation with a VXLAN data
plane for building overlay networks in the data center.
A number of control planes exist today for VXLAN, based on specific use cases, whether it be a
requirement to integrate with an SDN overlay controller, or operate in a standards based flood and
learn control plane model.
Current flood and learn models operate either with a multicast control plane, or ingress replication,
where the operator manually configures the remote VTEPs in the flood list. Both of these are
data-plane driven, that is, MAC’s are learned via flooding. In the IP multicast model MAC’s are learned
in the underlay via flooding to an IP multicast group, while ingress replication (HER) floods to
configured VTEP endpoints and no IP Multicast is required in the underlay.
The controller based solution with cloud vision exchange (CVX), locally learned MAC’s are published
to a centralized controller and these MAC’s are then programed to all participating VTEPs.
Figure 21-1: Different VXLAN Control Planes
A controller-less BGP EVPN MAC learning is a standards-based control-plane (MP-BGP) is used to

discover remote VTEPs and advertise MAC address and MAC/IP bindings in the VXLAN overlay, thus
eliminating the flood and learn paradigms of the previously mentioned (multicast or HER)
controller-less approaches. As a standards-based approach, the discovery and therefore the
advertisement of the EVPN service models can inter-operate amongst multiple vendors.
This highlights an important and powerful advantages of BGP EVPN; that being, it is a single control
plane for multiple data-plane encapsulations and defines both Layer 2 and layer 3 VPN services. As
network operators drive toward simplicity and automation, having one control plane protocol and
address family for all data-planes and VPN services will prove extremely powerful.
Figure 21-2: VXLAN Control Plane and Data-plane Definitions
1006
Chapter 21: EVPN EVPN Overview
The initial EVPN standard is RFC 7432 defined the BGP EVPN control plane and specifies an MPLS
data-plane. The control plane with an MPLS data plane was extended to consider additional data
plane encapsulations models including VXLAN, NVGRE and MPLS over GRE.
21.1.1 EVPN Terminology

The EVPN standard in the context of an NVO environment, defines the functionality for delivering
multi-tenant Layer 2/3 VPN services using either VXLAN, NVGRE or MPLS over GRE encapsulation,
across a common physical IP infrastructure. The standard introduces new terminology specific to a
NVO environment, which are summarized below in relation to VXLAN encapsulation.
• Network Virtualization Overlay (NVO): The overlay network used to deliver the Layer 2 and
Layer 3 VPN services. For VXLAN encapsulation, this would define a VXLAN domain, which
would include one or more VNIs, for the transportation of tenant traffic over a common IP
underlay infrastructure.
• Network Virtualization End-Point (NVE): The provider edge node within the NVO
environment responsible for the encapsulation of tenant traffic into the overlay network. For a
VXLAN data plane, this defines the Virtual Tunnel End-Point (VTEP)
• Virtual Network Identifier (VNI): The label identifier within the VXLAN encapsulated frame,
defining a layer 2 domain in the overlay network.
• EVPN instance (EVI): A logical switch within the EVPN domain which spans and
interconnects multiple VTEPs to provide tenant layer 2 and layer 3 connectivity.
• MAC-VRF: A Virtual Routing and Forwarding table for storing Media Access Control (MAC)
addresses on a VTEP for a specific tenant.
Figure 21-3: EVPN Terminology for a VXLAN Data Plane
The new EVPN Network Layer Reachability Information (NLRI) is carried in BGP using Multi-protocol
BGP Extensions with a newly defined Address Family Identifier (AFI) and Subsequent Address Family
Identifier (SAFI).
To provide multi-tenancy, the standard uses the above traditional VPN methods to control the import
and export of routes and provide support for overlapping IP address between tenants.
1007
• Multi-protocol BGP for EVPN: A new AFI and SAFI have been defined for EVPN. These are
AFI=25 (L2VPN) and SAFI = 70 (EVPN)
• EVPN L2/L3 tenant segmentation: Similar to standard MPLS VPN configurations Route
Distinguisher's (RD’s) and Route Targets (RT’s) are defined for the VPN.
• Route Target (RT): To control the import and export of routes across VRFs, EVPN routes are
advertised with Route-Target (RT) (BGP extended communities). The RT can be auto derived
to simplify the rule configuration, typically this is based on the AS number and the VNI of the
MAC-VRF.
• Route Distinguisher (RD): Unique number prepended to the advertised address within the
VRF, ensuring support for overlapping IPs and MACs across different tenants.
The format of the MP_REACH_NLRI/MP_UNREACH_NLRI attribute, holding the new EVPN NLRI is
illustrated below, where the next-hop address within the NLRI is the IP address of the VTEP advertising
the EVPN route.
Figure 21-4: EVPN NLRI Route Format
As illustrated in Figure 21-4, the original MPLS RFC (7348) and subsequent IP prefix draft
(draft-ietf-bess-evpn-prefix-advertisement-04), introduce five unique EVPN route types.
Type-1 Route: Ethernet A-D route

Ethernet A-D route per ESI route, announces the reachability of a multi-homed Ethernet Segment. The
route type is used for fast convergence (ie: ‘mass withdraw’) functions, as well as split horizon filtering
used for active-active multi-homing.
Ethernet A-D route per EVI route, is used to implement the Aliasing and Backup Path features of EVPN
associated with active-active multi-homing.
Type-2 Route: Host advertisement Route

Used to advertise the reachability of a MAC address, or optionally a MAC and IP binding as learned by
a specific EVI. With the advertisement of the optional IP address of the host, EVPN provides the ability
for VTEPs to perform ARP suppression and ARP proxy to reduce flooding within the layer 2 VPN.
1008
Type-3 Route: Inclusive Multicast route

The type-3 route is used to advertise the membership of a specific layer 2 domain (VNI within the
VXLAN domain), allowing the dynamic discovery of remote VTEPs in a specific VNI and the population
of a VTEP ingress flood list for the forwarding of Broadcast Unknown unicast and Multicast (BUM)
traffic.
Type-4 Route: Ethernet Segment Route

The type-4 route is specific to VTEPs supporting the EVPN multi-homing model, for active-active and
active-standby forwarding. The route is used to discover VTEPs which are attached to the same shared
Ethernet Segment. Additionally, this route type is used in the Designated Forwarder (DF) election
process.
Type-5 Route: IP-prefix route advertisement

The type-5 route is used to advertise IP prefixes rather the MAC and IP hosts addresses of the type-2
route. This advertisement of prefixes into the EVPN domain provides the ability to build classic layer 3
VPN topologies.
A detailed understanding of the function of each of these route types in the operation of EVPN to
provide multi-tenant layer 2 and 3 VPN services, is defined in Section 4 of this document.
While this guide focuses on EVPN with VXLAN data-plane encapsulation, it’s important to note that, in
addition to the new routes type, a BGP encapsulated extended community is included in all
advertisements to determine the data-plane encapsulation.
The Encapsulation extended community is defined in RFC 5512. The different IANA registered tunnel
types for an NVO environment are summarized in the table below.
Table 21-1 Defined Data-Plane Encapsulations
1009
21.1.2 EVPN Service Models

An EVPN instance (EVI), can contain, one or more layer 2 broadcast domains (VLANs). The
association of a VLAN-IDs to a specific EVI instance and how a VLAN tag can be transported within
the EVI if required, is defined by three EVPN service models: VLAN based, VLAN Bundle, and VLAN
aware bundle.
VLAN Based Service Interface

In the VLAN based service there is a one-to-one mapping between the VLAN-ID and the MAC-VRF of
the EVPN instance. With the MAC-VRF mapping directly to the associated VLAN, there will be a single
bridge table within the MAC-VRF. The VLAN tag is not carried in any route update and the VNI label in
the route advertisement is used to uniquely identify the bridge domain of the MAC-VRF in the VXLAN
forwarding plane.
Figure 21-5: VLAN Based Service Interface
With a one-to-one mapping between the VLAN-ID and the MAC-VRF of EVI instance, the EVI will
represent an individual tenant subnet/VLAN in the overlay. The one-to-one mapping also means the
route-target associated with the MAC-VRF, uniquely identifies the tenant’s subnet/VLAN, providing
granular importing of MAC routes on a per VLAN basis on each VTEP.
In this service, the associated MAC-VRF table is identified by the Route-Target in the control plane and
by the VNI in the data plane and the MAC-VRF table corresponds to a single VLAN bridge domain.
VLAN Bundle Service Interface

In the VLAN bundle service, there is a many-to-one mapping between the VLAN-IDs and the MAC-VRF
of the EVPN instance. The MAC-VRF however only contains a single layer 2 bridge table and VNI label,
thus MAC addresses must be unique across all associated VLANs.
1010
With the MAC-VRF containing a single layer 2 bridge table and a single VNI, the original VLAN tag has
no significance in the control plane and is not carried in any EVPN route update. The original Ethernet
tag and the VNI label are carried in the VXLAN data plane, to allow forwarding to the correct tenant
VLAN.
Figure 21-6: VLAN Bundle Service Interface
In this service, the Route-Target associated with the MAC-VRF identifies the tenant rather than an
individual subnet/VLAN of a tenant. This means all MAC routes for the tenant will be imported on the
VTEP regardless of whether or not the specific tenant VLAN exists. The MAC-VRF table is identified
by the Route-Target in the control plane and forwarding to the appropriate tenant VLAN is achieved via
a combination of the VNI and Ethernet tag in the VXLAN data plane.
VLAN Aware Bundle Service Interface

In the VLAN aware bundle service, there is a many-to-one mapping between the VLAN-IDs and the
MAC-VRF of the EVPN instance. However, the MAC-VRF contains a unique layer 2 bridge table for
each associated VLAN-ID and a unique VNI label for each bridge domain.
With the MAC-VRF containing multiple layer 2 bridge tables, the VLAN tag is carried in any EVPN route
update to allow mapping to the correct tenant bridge table within the MAC-VRF. Only the unique VNI
label is carried in the VXLAN data plane, to allow forwarding to the correct VLAN with the MAC-VRF.
Figure 21-7: VLAN Aware Bundle Service
1011
EVPN Core Operations Chapter 21: EVPN
In this service, the MAC-VRF of the EVI instance represents multiple subnet/VLANs of the tenant. The
layer 2 bridge table of the MAC-VRF is identified by a combination of the Route-Target and the Ethernet
tag in the control plane and by the unique VNI and in the VXLAN data plane.
This service type is a common DCI/WAN deployment, where a tenant’s VLANs are bundled into single
EVI instance, while VLAN “awareness” can be retained in the EVPN service as the VNI tag is
advertised in the MAC-IP route (which now identifies the VLAN within the EVI). Bundling into a service
like this reduces the number of EVI’s that need to be configured, reducing complexity and the
control-plane signaling between PE’s.
21.2 EVPN Core Operations

The EVPN standard defines a number of operations and functionality to allow the dynamic learning of
MAC and IP bindings, management of MAC moves (VM/host mobility), ARP suppression, automated
discovery of remote VTEPs and multi-homing to support active-active topologies.
21.2.1 MAC Address Learning.

Figure 21-8 refers to MAC address learning on the local interface of a VTEP is still flow-based learning,
however once the MAC’s are learned locally they are advertised to BGP peers within the EVI via an
EVPN route update. The next hop of the update is set to IP of the advertising VTEP. In the case of
EVPN VXLAN the label advertised in the update is the VNI, which identifies the MAC-VRF in the case
of a VLAN Based service, or the EVI for a VLAN aware bundle service.
Figure 21-8: EVPN Type 2 Route Announcement
1012
Chapter 21: EVPN EVPN Core Operations
The route advertisements are EVPN type-2 routes, which can advertise just the MAC address of the
host, or optionally the MAC and IP address of the host. The format of the type-2 route is illustrated in
the figure below, along with the mandatory and optional extended community attached to the route.
Figure 21-9: EVPN Type 2 MAC and IP Route Format
Figure 21-9 notable fields:

• Multi-protocol Reachable NLRI (MP_REACH_NLRI) attribute of the route is used to carry the
next-hop hop for the advertised route. In the context of a VXLAN forwarding plane, this will be
the source address (VTI) of the advertising VTEP.
• Route Distinguisher of the advertising node’s MAC-VRF.
• Ethernet Segment Identifier (ESI), this field is populated when the VTEP participating in a
multi-homed topology. This is discussed in the following sections.
• Ethernet tag ID that will be 0 for VLAN-based service, and the customer VLAN ID in a
VLAN-aware bundle service.
• IP address of the host which is associated with advertised MAC address. The advertisement
of the Host’s IP address is optional.
• Label in the context of a VXLAN forwarding plane is the VNI associated with the
MAC-VRF/layer 2 domain the advertised MAC address has been learned on.
• Route Target associated with the MAC-VRF advertised with route to allow the control of the
import and export of routes.
The MAC mobility extended community, as discussed in the following section is used during MAC
moves to update all VTEPs of the new location of the host.
21.2.2 ARP Suppression

Providing the option to advertise the MAC and IP binding in the type-2 route, ARP suppression can be
supported on the remote VTEPs. The MAC to IP binding can be learned locally, via ARP snooping or
DHCP traffic on the VTEP. Once the MAC and IP binding has been learned, it is advertised to the
remote VTEPs as a type-2 route. This allows remote VTEPs to respond to any ARP requests for the
host locally, thus reducing the amount of ARP traffic across the EVI.
Importantly, the optional MAC and IP route can be advertised separately from the MAC only type-2
route. This is done so that if the MAC and IP route is cleared, i.e. ARP flushed, or the ARP timeout is
set to less than the MAC timeout, then the MAC only route will still exist.
1013
21.2.3 MAC Mobility

A common scenario in a data center environment is virtual machines (VMs) moving between physical
servers, for maintenance or performance reasons, this will result in the MAC of the VM being learned
and advertised by a new VTEP.
To cater for this situation a sequence number is attached to the new MAC advertisement ensuring an
EVI wide refresh of the MAC table, with VTEPs updating their forwarding tables to point to the
advertising VTEP as the new next-hop for MAC address.
Figure 21-10: EVPN type-2 MAC Mobility Behavior
When a MAC address is learned and advertised for the first time, it is advertised without a sequence
number and the receiving VTEP assume the sequence to be zero. On detection of a MAC move, i.e. a
MAC is learned locally when the same MAC route is active via a type-2 advertisement, then the
sequence number is incremented by one, and the MAC route is advertised to the remote peers. The
original advertising VTEP, receives the MAC route with a now higher sequence number and withdraws
its own local MAC route. All other VTEPs flush the original MAC route, and update their tables with the
new higher sequence number route.
21.2.4 MAC address Damping

In addition to MAC mobility, EVPN defines a protection mechanism to detect and prevent MAC routes
flapping between VTEPs, which can occur during network instability or when hosts have been
mis-configured with the same (duplicate) MAC address.
On advertising a locally learned MAC, the VTEP will start a M second counter (default is 180s), if the
VTEP detects N MAC moves (default is 5) for the route within the M second window, it will generate a
syslog message and stop sending and processing any further updates for the route.
1014
Chapter 21: EVPN EVPN Core Operations
21.2.5 Broadcast and Multicast Traffic

Broadcast, unknown unicast and Multicast (BUM) traffic is handled within the EVPN forwarding model
using ingress replication. Where the BUM frame is replicated on the ingress VTEP to each of the
remote VTEPs in the associated EVI/VNI. The VTEP replication list for the EVI, is dynamically
populated based on Type-3 route advertisements (Inclusive Multicast Ethernet Tag Route), where
VTEPs advertise type-3 routes for each EVI they are members.
Figure 21-11: EVPN type-3 IMET Route Behavior for Ingress Replication
The format of the type-3 route is illustrated in Figure 21-12.

Figure 21-12: EVPN type-3 IMET Route Format
Figure 21-12 notable fields of the type-3 route:

• Multi-protocol Reachable NLRI (MP_REACH_NLRI) attribute of the route is used to carry the
next-hop hop for the advertised route. In the context of a VXLAN forwarding plane, this will be
the source address (VTI) of the advertising VTEP.
• Route Distinguisher of the advertising node’s MAC-VRF.
• Ethernet tag that will be 0 for VLAN-based service, and the MAC-VRF VNI for a VLAN-aware
bundle service.
• IP address of the VTEP advertising the type 3 route.
• Route Target associated with the MAC-VRF or the EVI in a VLAN-aware bundle service.
1015
• PMSI Tunnel Attribute, to advertise the replication model the VTEP is supporting. The
supported options defined within the standard are ingress replication and IP multicast.
1016
Chapter 21: EVPN Integrated Routing and Bridging
21.3 Integrated Routing and Bridging

In the traditional data center design, inter-subnet forwarding is provided by a centralized router, where
traffic traverse across the network to a centralized routing node and back again to its final destination.
In a large multi-tenant data center environment this operational model can lead to inefficient use of
bandwidth and sub-optimal forwarding.
To provide a more optimal forwarding model and avoid traffic tromboning, the EVPN inter-subnet draft
(draft-sajassi-l2vpn-evpn-inter-subnet-forwarding) proposes integrating the routing and bridging (IRB)
functionality directly onto the VTEP, thereby allowing the routing operation to occur as close to the end
host as possible. The draft proposes two forwarding models for the IRB functionality, which are termed
asymmetric IRB and symmetric IRB, these two models are described in the following sections.
In the asymmetric IRB model, the inter-subnet routing functionality is performed by the ingress VTEP,
with the packet after the routing action being VXLAN bridged to the destination VTEP. The egress
VTEP only then needs to remove the VXLAN header and forward the packet onto the local layer 2
domain based on the VNI to VLAN mapping. In the return path, the routing functionality is reversed with
the destination VTEP now performing the ingress routing and VXLAN bridging operation, hence the
term asymmetric IRB.
Figure 21-13: EVPN Asymmetric IRB
To provide inter-subnet routing on all VTEPs for all subnets, an anycast IP address is utilized for each
subnet and configured on each VTEP. The anycast IP acts as the default gateway for the hosts,
therefore regardless of where the host resides the directly attached VTEPs can act as the host’s default
gateway. The host MAC and MAC to IP bindings are learned by each VTEP based on a combination
of local learning/ARP snooping and type-2 route advertisement from remote VTEPs.
In a typical implementation, the optional MAC and IP, type-2 route is advertised separately from the
MAC only type-2 route. This is done so that if the MAC and IP route is cleared, for example the ARP
flushed, or the ARP timeout is set to less than the MAC timeout, then the MAC only route will still exist.
1017
Integrated Routing and Bridging Chapter 21: EVPN
The format of the two advertised type-2 routes for Server-1 are illustrated below, where the RD
IP-A:1010 and route-target 1010:1010 are used to distinguish the uniqueness of the route and allow
the route to be imported into the correct remote MAC-VRF based on the route-target import policy of
the VTEP.
Figure 21-14: EVPN Comparison of MAC & MAC+IP Type 2 Route in Asymmetric IRB
1018
For the traffic flow between Server-1 in subnet-10 and Server-4 in subnet-11, the ingress VTEP
(VTEP-1) locally routes the packet into subnet-11/VNI 1011 and then VXLAN bridges the frame,
inserting the VNI 1011 into the VXLAN header with an inner DMAC equal to the destination host,
Server-4. This requires the receiving VTEP, (VTEP-4) to only perform a local layer 2 lookup, based on
the VNI to VLAN mapping, for the DMAC of Server-4.
Figure 21-15: EVPN Asymmetric IRB VxLAN Data-plane Forwarding Detail
For the asymmetric model to operate the sending VTEP needs the information for all the tenant’s hosts
(MAC and MAC to IP binding), to route and bridge the packet. This means the VTEP needs to be
member of all the tenant’s subnets/VNI and have an associated SVI with anycast IP for all the subnets,
and this will be required on all VTEPs participating in the routing functionality for the tenant. This
introduces scaling issues on multiple fronts.
• VNI Scaling: The number of VNIs supported on a hardware VTEP will be finite, so not all VNIs
can reside on all VTEPs. This is especially true in data-center deployments, where the TOR’s
have traditionally been more resource constrained than chassis-based edge systems.
• Forwarding memory scaling: The VTEPs needs to store all host MACs and ARP entries for all
subnets in the network, on leaf switch this is hardware resource which again will be a finite
resource defined by the specific hardware platform deployed at the leaf.
Symmetric IRB
To address the scale issues of the asymmetric model, in the symmetric model the VTEP is only
configured with the subnets that are present on the directly attached hosts. Connectivity to non-local
subnets on a remote VTEP is achieved through an intermediate IP-VRF. The subsequent forwarding
model for symmetric IRB is illustrated in the figure below, for traffic between Server-1 on subnet-10
(Green) and Server-4 on the remote subnet-11 (Blue). In this model, the ingress VTEP routes the traffic
1019
between the local subnet-10) and the IP-VRF, which both VTEPs are a member of, the egress VTEP
then routes the frame from the IP-VRF to the destination subnet. The forwarding model results in both
VTEPs performing a routing function, hence the term symmetric IRB.
Figure 21-16: EVPN Symmetric IRB
To provide the inter-subnet routing, when the subnet is stretched across multiple VTEPs, an anycast
IP address is utilized for each subnet, but only configured on the VTEP’s where the subnet exists. The
host MAC and MAC to IP bindings are learned by each VTEP based on a combination of local
learning/ARP snooping and type-2 route advertisements.
For the symmetric IRB model the type-2 (MAC and IP) route is advertised with two labels and two
route-targets corresponding to the MAC-VRF the MAC address is learned on and the IP-VRF. Remote
VTEP’s receiving the route, import the IP host route into the corresponding IP-VRF based on the
IP-VRF route-target and if the corresponding MAC-VRF exists on the VTEP the MAC address is
imported into the local MAC-VRF based on the MAC-VRF’s Route-Target. The import behavior for the
type-2 route is illustrated in the diagrams below for the host Server-1.
If the MAC-VRF exists locally on the receiving router, both the IP host route will be installed in the
IP-VRF, and the MAC address will be installed in the MAC-VRF. As shown in Figure 30. With both a
MAC route in the MAC-VRF and an IP host route in the IP-VRF, the VNI used in the data-path will
depend on whether the traffic is being VXLAN bridged between hosts in the same VNI (1010) or
VXLAN routed (VNI 2000).
1020
Figure 21-17: EVPN Type 2 Route in Symmetric IRB - MAC-VRF on Both VTEPs
1021
Compare this to Figure 4.17, where the MAC-VRF does not exist on the receiving VTEP (VTEP-2). In
this case the MAC route is not installed and ignored, as there is no corresponding Route Target on the
VTEP. In this scenario, only the IP-VRF host route is installed on VTEP-2. Traffic from VTEP-2 destined
to hosts on subnet-10, are therefore always VXLAN routed via the IP-VRF, VNI 2000.
Figure 21-18: EVPN Type 2 Route in Symmetric IRB - MAC-VRF Only Exists on Sending VTEP
The symmetric IRB type-2 route contains a number of additional extended community attributes over
the asymmetric IRB type-2 route, the salient fields of the route are summarized below.
• Multi-protocol Reachable NLRI (MP_REACH_NLRI) attribute is used to carry the next-hop hop
for the advertised route. In the context of a VXLAN forwarding plane, this will be the source
address of the advertising VTEP.
• Route Distinguisher of the advertising node’s MAC-VRF. For Server-1 in the example above
this would be IPA:1010.
• MAC address field contains the 48-bit MAC address of the host being advertised. For Server-1
in the example above this would be MAC-1.
• IP address and length field contain the IP address and 32-bit mask for the host being
advertised. For Server-1 in the example above this would be IP-1.
• MAC-VRF label, this contains the VNI number (label) corresponding to the local layer 2
domain/MAC-VRF the host MAC was learned on. For Server-1 in the example above this would
be VNI 1010.
• IP-VRF label, this contains the VNI number (label) corresponding to the MAC-VRF’s
associated lP-VRF. For MAC-VRF 10 in the example above this would be IP-VRF 2000.
• Extended community Route Target for the IP-VRF. This contains the route-target of the IP-VRF
associated with the learned MAC address.
• Extended community Router MAC. This field advertises the system MAC of the advertising
VTEP and is used as the DMAC for any packet sent to the VTEP via the IP-VRF.
1022
• Extended community Route Target for the MAC-VRF. This contains the route-target of the
MAC-VRF associated with the learned MAC address.
1023
EVPN Type-5 Routes: IP Prefix Advertisement Chapter 21: EVPN
21.4 EVPN Type-5 Routes: IP Prefix Advertisement

The EVPN type 2 routes can be used to advertises IP prefixes by making use of the optional IP address
and IP address length fields in the route, however they are explicitly linked to the MAC address
advertised within the route. The EVPN type-5 route defined within the draft
https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-04, provides the ability to decouple
the advertisement of an IP prefix from any specific MAC address, providing the ability to support
floating IP address, optimize the mechanism for advertising external IP prefixes, and reduce the churn
when withdrawing IP prefixes.
Figure 21-19 displays the format of the new type-5 IP-prefix route.
Figure 21-19: EVPN Route Type-5, for Advertisement of IP Prefixes
The IP prefix draft defines a number of specific uses cases for the type-5 route, which consequently
affect the format and content of the fields within the route. The different deployment scenarios and use
cases defined within the draft are summarized below.
• Advertising of IP prefixes behind an appliance, when the appliance is not running a routing
protocol and only supporting static routes. This could be the typical use case for a Virtual
Firewall with a number of local subnets directly attached, but the firewall is only supporting
static routes into the associated EVI.
• Support for active-standby deployment of appliances using a shared floating IP model. This is
an extension of the previous case where there is now a virtual IP (or VIP) for clustering the
appliances, rather than a dedicated physical IP address on the appliance.
• Support for layer 2 appliances, acting as a “bump in the wire” with no physical IP addresses
configured, where instead of the appliances having an IP next-hop there is only a MAC
next-hop.
• IP-VRF to IP-VRF model, which is similar to inter-subnet forwarding for host routes (detailed
in the symmetric/asymmetric section), except only Type-5 routes and IP prefixes are
advertised, allowing announcement of IP prefixes into a tenant’s EVI domain for external
connectivity outside the domain.
1024
Chapter 21: EVPN EVPN Type-5 Routes: IP Prefix Advertisement
Interface-less
In interface-less mode, the IP prefixes within the type-5 route, whether they are local or learned from
a connected router are advertised to remote peers via the shared IP-VRF, as illustrated in the figure
below.The IP-VRF to IP-VRF model, is further divided in the draft into three distinct use cases.
Figure 21-20: EVPN Route Type-5, Interface-less Update
As illustrated in Figure 21-20, the IP prefix (subnet-A) residing behind the router (Rtr-1) is learned via
an IGP in EVI-1 on VTEP-1. The prefix is announced and learned by the remote VTEPs residing in the
same EVI, via the type-5 route announcement. The type-5 route, is advertised along with the prefix,
with a route-target (2000:2000) and a VNI label (2000) equal to the IP-VRF which interconnects the
VTEPs in the EVI, the router-mac extended community of the route is used to define the inner DMAC
(equal to system MAC of VTEP-1) for any VXLAN frame destined to advertised IP prefix.
From a forwarding perspective, host residing on subnet-B communicating with a host on subnet-A, will
send traffic to their default gateway which is the IRB interface on VTEP-2 in VLAN 11/VNI 1011.
VTEP-2 performs a route lookup for the destination subnet-A), which has been learned in the IP-VRF
with a next-hop of VTEP-1 and VNI label of 2000. The packet is thus VXLAN encapsulated with VNI
label of 2000 an inner DMAC of A (VTEP-1 system/router MAC), and routed to VTEP-1, which is the
next-hop for the prefix. Receiving the frame, VTEP-1 de-encapsulates the packet, with an inner DMAC
of the VTEPs router MAC, it performs a local route lookup for the destination subnet-A), which has been
1025
EVPN Type-5 Routes: IP Prefix Advertisement Chapter 21: EVPN
learned with a next-hop of rtr-1. The frame is forwarded directly to rtr-1, which subsequently routes the
packet to the local host on subnet-A. The format of the type-5 route in interface-less mode is illustrated
in figure below.
Figure 21-21: EVPN Type-5 Route Format for Interface-less Mode
In this model, the VTEPs forming the EVI are interconnected via an IP-VRF, meaning there is no IRB
interface (MAC and IP) created for the interconnection on each of the VTEPs, hence the term
“interface-less”. With no IRB interface the gateway IP address within the type-5 route is set to zero,
traffic is routed to the prefix based on the next-hop of the route (VTEP IP) as well as MAC address
conveyed within the Router MAC extended community, which represents the inner destination MAC of
the VXLAN encapsulated frame.
1026
Chapter 21: EVPN Configuration Examples
21.5 Configuration Examples

In the topology below, we are connecting a layer 2 site with a layer 3 site using L3 EVPN
(type-5 route). Right side leaves are MLAG leaves and have SVI 10 in VRF-Blue. A number
of directly connected hosts are simulated behind the right side leaf. The left side leaves are
individual leaves that connect with a remote switch in vrf VRF-Blue to learn L3 routes using
BGP. The left side leaves are configured as 2 independent layer 3 only VTEPs.
Figure 21-22: Layer 3 EVPN Configuration
To provide VXLAN routing and bridging between the two MLAG domains, each leaf switch is EVPN
peering with the four spine switches via a loopback interface.
1027
Configuration Examples Chapter 21: EVPN
eBGP Underlay Configuration: Leaf-11

Underlay configuration is straightforward and all neighbors are eBGP. Since all leaves share the same
AS number, the allowas-in command was added in the leaf.
interface Ethernet1
description Spine-1-et1/1
mtu 9214
no switchport
ip address 172.168.1.1/31
interface Ethernet8/1
description ck428-et8/1
speed forced 40gfull
no switchport
ip address 172.168.1.10/31
interface Loopback0
ip address 1.1.1.11/32
ip prefix-list loopback
seq 10 permit 1.1.1.0/24 ge 24
!
route-map loopback permit 10
match ip address prefix-list loopback
router bgp 65004

neighbor SPINE peer-group
neighbor SPINE remote-as 65001
neighbor SPINE allowas-in 1
neighbor SPINE soft-reconfiguration inbound all
neighbor SPINE send-community
neighbor 172.168.1.0 peer-group SPINE
neighbor 172.168.1.11 remote-as 65003
redistribute connected route-map loopback
eBGP Underlay Configuration: Spine-1

interface Ethernet1/1
description Leaf-11-et1
mtu 9214
no switchport
ip address 172.168.1.0/31
interface Loopback0
!
seq 10 permit 1.1.1.0/24 ge 24
!
!
router bgp 65001
1028
VRF Configuration: Leaf-11

VRF-Blue is configured on all the left leaves. The left leaves have pure L3-interfaces and the right side
has SVI 10.
vrf definition VRF-Blue
ip routing vrf VRF-Blue
interface Ethernet36
no switchport
vrf forwarding VRF-Blue
ip address 172.168.1.9/31
router bgp 65004

vrf VRF-Blue
VRF Configuration: Leaf-21

vlan 10
vrf definition VRF-Blue
ip routing vrf VRF-Blue
interface Vlan10
vrf forwarding VRF-Blue
ip address virtual 10.10.10.1/24
ip virtual-router mac-address 00:aa:aa:aa:aa:aa
interface Port-Channel3
switchport mode trunk
mlag 3
VXLAN Configuration: Leaf-11

Make sure all VTEPs have unique loopback0 addresses to represent unique VTEP identifiers. For
every VNI that EVPN receives, a dynamic VLAN is allocated, so it is a good practice to keep the same
VNI.
interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan vrf VRF-Blue vni 10001
VXLAN Configuration: Leaf-21

interface Vxlan1
vxlan udp-port 4789
vxlan vrf VRF-Blue vni 10001
1029
EVPN Configuration: Leaf-11

Leaf establishes the EVPN neighborship with all 4 spines for redundancy. EVPN neighborship is on the
loopback address and the multihop keyword is used. Make sure to disable the IPv4 address family for
EVPN neighbors.
Since the spine is acting like a route-reflector for EVPN routes, make sure to configure the
next-hop-unchanged.
router bgp 65004
neighbor SPINE_EVPN peer-group
neighbor SPINE_EVPN remote-as 65001
neighbor SPINE_EVPN update-source Loopback0
neighbor SPINE_EVPN ebgp-multihop 3
neighbor SPINE_EVPN send-community extended
neighbor SPINE_EVPN maximum-routes 12000
neighbor 1.1.1.1 peer-group SPINE_EVPN
!
address-family evpn
neighbor SPINE_EVPN activate
!
address-family ipv4
no neighbor SPINE_EVPN activate
EVPN Configuration: Leaf-21

router bgp 65002
neighbor SPINE_EVPN allowas-in 1
!
address-family evpn
!
address-family ipv4
EVPN Configuration: Spine-1

router bgp 65004
!
address-family evpn
!
address-family ipv4
1030
Advertise VRF Routes in EVPN: Leaf-11

By configuring VRF under router-bgp, you are advertising routes from that VRF into EVPN using the
RD/RT. The remote end can install the route by importing the RT.
Leaf-11 has routes in VRF-Blue learned through eBGP with the neighbor down south. Since the routes
are already in BGP VRF table, we don't to configure the redistribute command.
router bgp 65004
!
address-family evpn
!
address-family ipv4
Advertise VRF Routes in EVPN: Leaf-21

On the other hand Leaf-21 wants to export the connected SVI into EVPN and hence require redistrib-
ute connected command.
router bgp 65002
!
address-family evpn
!
address-family ipv4
21.5.1 Multi-Tenant EVPN VXLAN IRB Sample Configuration

The following configuration example shows a deployment using both symmetric and asymmetric IRB
with VLAN-based and VLAN-aware bundle services and eBGP overlay and underlay.
1031
21.5.1.1 Topology Overview

Figure 21-23: Tenant-A: Symmetric IRB
1032
Figure 21-24: Tenant-B: Asymmetric IRB
In the symmetric and asymmetric IRB configurations illustrated in the figures above, for Tenant-A, four
subnets are stretched across the two MLAG domains with two subnets (VLAN 10, 10.10.10.0/24 and
VLAN 11, 10.10.11.0/24) configured as a VLAN-based service, and two other subnets (VLAN
12,10.10.12.0/24 and VLAN 13, 10.10.13.0/24) as a VLAN-aware bundle service.
For Tenant-B, four subnets are stretched across the two MLAG domains with two subnets (VLAN 210,
10.10.10.0/24 and VLAN 211,10.10.11.0/24) configured as a VLAN-based service, and two other
subnets (VLAN 212,10.10.12.0/24 and VLAN 213,10.10.13.0/24) as a VLAN-aware bundle service.
In addition each MLAG domain has a single local subnet (Rack-1 subnet 10.10.20.0/24 and Rack-2
subnet 10.10.21.0/24) for the tenant. To provide direct distributed routing, each leaf switch is configured
with the same virtual IP address for the four stretched subnets. For the local-only subnets, the virtual
IP address is configured in both physical leaf switches of the relevant MLAG domain.
For each MLAG domain, a logical VTEP is created with the same shared loopback address. For
Rack-1, the logical VTEP IP is 2.2.2.1 and for the Rack-2, the logical VTEP IP is 2.2.2.2. Directly
connected to each leaf switch is a host, which is a member of one of the two IP subnets. To provide
layer 2 connectivity across the racks, VXLAN bridging is enabled by mapping VLAN to VNIs as detailed
in the diagram.
To provide IP connectivity across all subnets both stretched and directly connected, an IP-VRF is
shared between the two MLAG domains for the tenant. This is used as a transit network for announcing
and forwarding the locally attached subnets. Each leaf switch is EVPN peering with the four spine
switches via a loopback interface on the leaf and again on the spine switches. To provide external
connectivity, Leaf-11 and Leaf-12 are eBGP peering via the tenants’ VRFs with the border routers. Both
core routers are advertising external prefixes for Internet and any remote site connectivity (default route
1033
and IP prefixes from the other DC for the tenant). To provide connectivity within the EVPN domain, the
leaf switches (Leaf-21 and Leaf-22) re-advertise the prefixes into the tenant’s VRF via a type-5 route
advertisement, with a next-hop equal to the advertising VTEP.
21.5.2 Multi-Tenant Configuration
21.5.2.1 MLAG Configuration: Leaf-11 and Leaf-12
Leaf-11 MLAG Configuration

spanning-tree mode mstp
no spanning-tree vlan 4093-4094
!
ip virtual-router mac-address mlag-peer
!
vlan 4094
name MLAG_PEER
trunk group MLAG
!
vlan 4093
name LEAF_PEER_L3
trunk group LEAF_PEER_L3
!
interface Vlan4094
ip address 172.168.10.1/30
!
description port-channel to access switch
switchport trunk allowed vlan 10-13,20,210-213,220
mlag 1
!
switchport trunk group LEAF_PEER_L3
switchport trunk group MLAG
!
mlag configuration
domain-id Rack-1
local-interface Vlan4094
peer-address 172.168.10.2
peer-link Port-Channel1000
1034

!
!
vlan 4094
name MLAG_PEER
trunk group MLAG
!
vlan 4093
name LEAF_PEER_L3
!
interface Vlan4094
ip address 172.168.10.2/30
!
switchport trunk allowed vlan 10-13,20,210-213,220
mlag 1
!
!
mlag configuration
domain-id Rack-1
1035
21.5.2.2 MLAG Configuration: Leaf-21 and Leaf-22

!
!
vlan 4094
name MLAG_PEER
trunk group MLAG
!
vlan 4093
name LEAF_PEER_L3
!
interface Vlan4094
ip address 172.168.10.1/30
!
switchport trunk allowed vlan 10-13,21,210-213,220-221
mlag 1
!
!
mlag configuration
domain-id Rack-1
1036

!
!
vlan 4094
name MLAG_PEER
trunk group MLAG
!
vlan 4093
name LEAF_PEER_L3
!
interface Vlan4094
ip address 172.168.10.2/30
!
switchport trunk allowed vlan 10-13,21,210-213,220-221
mlag 1
!
!
mlag configuration
domain-id Rack-1
peer-link Port-Channel1000hannel1000
21.5.2.3 VLAN and Distributed IP Address Configuration: Leaf-11 and Leaf-21

VLAN and interface configuration for VLAN 10 (virtual IP address10.10.10.254) and VLAN 11 (virtual
IP address 10.10.11.254), along with SVIs 12, 13 and 20, are similarly configured. To provide
multi-tenancy, the two tenant VLANs are placed in a dedicated VRF, named “Tenant-A.” A further five
tenant VLANs are configured and assigned to VRF “Tenant-B.”
The other VLANs are for peering, MLAG, and a unique VLAN SVI. These VLANs do not use virtual IP
addresses.
The tenants’ stretched subnets (Tenant-A: VLANs 10,11,12 and 13; Tenant-B: VLANs 210, 211, 211,
212 and 213) are mapped to unique overlay VXLAN VNIs. The tenants’ IP-VRF (Tenant-A and
Tenant-B) is associated with a VNI using the vxlan vrf command under the VXLAN interface. In the
forwarding model for symmetric IRB, this VNI will be used as the transit VNI for routing to subnets which
are not locally configured on the VTEP.
As a standard MLAG configuration, both leaf switches in each MLAG domain share the same logical
VTEP IP address. Thus MLAG domain, Rack-1 (Leaf-11 + Leaf-12) has a shared logical VTEP IP of
2.2.2.1 and Rack-2 (Leaf-21 + Leaf-22) has a shared logical VTEP IP of 2.2.2.2
1037
Leaf-11 VLAN and Distributed IP Address Configuration

!
!
vlan 10-11,20,210-211,220,111,2111
!
vlan 12-13
name VLAN-AWARE-BUNDLE-TENANT-A
!
vlan 212-213
name VLAN-AWARE-BUNDLE-TENANT-B
!
vrf definition tenant-a
!
Vrf definition tenant-b
!
interface Vlan10
mtu 9164
vrf forwarding tenant-a
!
interface Vlan11
mtu 9164
!
interface Vlan12
mtu 9164
!
interface Vlan13
mtu 9164
!
interface Vlan20
mtu 9164
!
interface Vlan210
mtu 9164
vrf forwarding tenant-b
!
interface Vlan211
mtu 9164
!
interface Vlan212
mtu 9164
!
interface Vlan213
mtu 9164
1038

!
interface Vlan220
mtu 9164
!
interface Vlan1111
description Unique-highest-IP-in-each-IP-Vrf
mtu 9164
ip address 223.255.255.249/30
!
interface Vlan2111
mtu 9164
ip address 223.255.255.249/30
!
interface Vlan4093
ip address 172.168.11.1/30
1039
Leaf-21 VLAN and Distributed IP Address Configuration

!
!
vlan 10-11,20,210-211,220,111,2111
!
vlan 12-13
name VLAN-AWARE-BUNDLE-TENANT-A
!
vlan 212-213
name VLAN-AWARE-BUNDLE-TENANT-B
!
vrf definition tenant-a
!
vrf definition tenant-b
!
interface Vlan10
mtu 9164
!
interface Vlan11
mtu 9164
!
interface Vlan12
mtu 9164
!
interface Vlan13
mtu 9164
!
interface Vlan21
mtu 9164
!
interface Vlan210
mtu 9164
!
interface Vlan211
mtu 9164
!
interface Vlan212
mtu 9164
!
interface Vlan213
mtu 9164
1040

!
interface Vlan221
mtu 9164
!
interface Vlan1111
mtu 9164
ip address 223.255.255.253/30
!
interface Vlan2111
mtu 9164
ip address 223.255.255.253/30
!
interface Vlan4093
ip address 172.168.11.1/30
!
21.5.2.4 VXLAN Interface Configuration: Leaf-11 and Leaf-21

The tenants’ VLANs are mapped to unique overlay VXLAN VNIs. VLAN 10 is mapped to VNI 1010 on
both MLAG domains, and VLAN 11 is mapped to VNI 1011. As standard MLAG configuration, both leaf
switches in each MLAG domain share the same logical VTEP IP address. Thus MLAG domain Rack-1
(Leaf-11 + Leaf-12) has a shared logical VTEP IP of 2.2.2.1 and Rack-2 (Leaf-21 + Leaf-22) has a
shared logical VTEP IP of 2.2.2.2. Also configured is the VRF-to-VXLAN mapping for Tenant-A.
Leaf-11 VXLAN Interface Configuration

!
interface Loopback1
!
interface Vxlan1
vxlan udp-port 4789
vxlan vlan 10 vni 1010
vxlan vrf tenant-a vni 1000
vxlan vrf tenant-b vni 1001
1041
Leaf-21 VXLAN Interface Configuration

!
interface Loopback1
!
interface Vxlan1
vxlan udp-port 4789
vxlan vrf tenant-a vni 1000
vxlan vrf tenant-b vni 1001
Note This configuration uses VXLAN routing. For single-chip T2 and TH platforms, recirculation must be
enabled. For R-Series platforms, the following configuration commands must be added:
hardware tcam
system profile vxlan-routing
Refer to diagrams for VLAN and SVI assignment to tenant; Leaf-11 also has peering out to the border
router in addition to the connected SVIs.
21.5.2.5 eBGP Underlay Configuration on the Leaf Switches

The leaf switches for the underlay network peer with each spine on the physical interface. For EVPN
route advertisement, the BGP EVPN session is between loopback addresses.
In this case, the underlay is all eBGP, and peering is on the physical interfaces. The MLAG leaves also
peer with each other in the underlay to retain BGP EVPN connectivity (loopback reachability) in the
very unlikely case that all spine links are down. This is a failover configuration that can be implemented
if there is ever the chance a leaf could be “core isolated.”The configuration can be viewed on each leaf
using the command show running-configuration section bgp.
The examples below show the underlay configuration on all four leaf switches, and also on two of the
spine switches as an example of the underlay configuration on the spine.
The configuration uses the following peer groups:
SPINE configuration inherited for underlay (eBGP) peering to the spines
1042
SPINE_EVPN overlay eBGP peering between spine and leaf, using loopbacks
Figure 21-25: Physical Underlay Topology
1043

!
route-map dont_advertise_loopbacks deny 10
!
route-map dont_advertise_loopbacks permit 20
!
seq 10 permit 1.1.1.11/32
seq 20 permit 1.1.1.12/32
seq 30 permit 1.1.1.22/32
seq 40 permit 1.1.1.21/32
seq 50 permit 2.2.2.1/32
seq 60 permit 2.2.2.2/32
!
router bgp 65002
router-id 1.1.1.11
maximum-paths 8 ecmp 16
neighbor SPINE route-map loopback out
neighbor 172.168.11.2 local-as 65002 no-prepend replace-as
neighbor 172.168.11.2 allowas-in 1
neighbor 172.168.11.2 maximum-routes 12000
1044

!
!
!
seq 10 permit 1.1.1.11/32
seq 20 permit 1.1.1.12/32
seq 30 permit 1.1.1.22/32
seq 40 permit 1.1.1.21/32
seq 50 permit 2.2.2.1/32
seq 60 permit 2.2.2.2/32
!
router bgp 65002
router-id 1.1.1.12
1045

!
seq 10 permit 1.1.1.11/32
seq 20 permit 1.1.1.12/32
seq 30 permit 1.1.1.22/32
seq 40 permit 1.1.1.21/32
seq 50 permit 2.2.2.1/32
seq 60 permit 2.2.2.2/32
!
router bgp 65002
router-id 1.1.1.21
neighbor SPINE maximum-routes 20000
1046

!
seq 10 permit 1.1.1.11/32
seq 20 permit 1.1.1.12/32
seq 30 permit 1.1.1.22/32
seq 40 permit 1.1.1.21/32
seq 50 permit 2.2.2.1/32
seq 60 permit 2.2.2.2/32
!
router bgp 65002
router-id 1.1.1.22
neighbor SPINE maximum-routes 20000
21.5.2.6 EVPN BGP Configuration on the Spine Switches

The EVPN BGP configuration on two of the spine switches is summarized below. Note that only the
EVPN BGP sessions are listed for the two spine switches: the BGP underlay configuration is not
included.
1047
EVPN BGP Configuration: Spine-1

!
seq 10 permit 1.1.1.11/32
seq 20 permit 1.1.1.12/32
seq 30 permit 1.1.1.22/32
seq 40 permit 1.1.1.21/32
seq 50 permit 2.2.2.1/32
seq 60 permit 2.2.2.2/32
!
router bgp 65001
router-id 1.1.1.1
distance bgp 20 200 200
neighbor LEAF peer-group
neighbor LEAF remote-as 65002
neighbor LEAF maximum-routes 20000
neighbor 172.168.1.2 peer-group LEAF
EVPN BGP Configuration: Spine-2

!
seq 10 permit 1.1.1.11/32
seq 20 permit 1.1.1.12/32
seq 30 permit 1.1.1.22/32
seq 40 permit 1.1.1.21/32
seq 50 permit 2.2.2.1/32
seq 60 permit 2.2.2.2/32
!
router bgp 65001
router-id 1.1.1.2
neighbor LEAF peer-group
neighbor LEAF remote-as 65002
neighbor LEAF maximum-routes 20000
21.5.2.7 eBGP Overlay on Leaf Switches

The MAC VRFs and IP VRF for the tenants’ subnets are created in the BGP router context with unique
Route-Distinguishers (RD) and Route-Targets (RT) attached to each MAC-VRF and IP-VRF. The RDs
provide support for overlapping MAC and IP addresses across tenants, while the RTs allow control of
the routes imported and exported between MAC VRFs.
1048
To ensure all routes are correctly imported between VTEPs sharing the same Layer-2 domain, the
import and export RTs are equal across the two MLAG domains. The redistribute learned statement
under each MAC VRF ensures any locally learned MACs in the VLAN are automatically announced as
type-2 routes.
The IP VRF (Tenant-A) is created on all leaf switches which have subnets attached to the tenant’s VRF
with the same route target ensuring that routes are correctly imported and exported between VTEPs
in the VRF. On Leaf-21 and Leaf-22, to import the external routes an eBGP session with the BGP
peering router is created under the IP VRF (Tenant-A) context, and a peering from each to the other is
created on the overlay.
Note All MAC VRFs are unique, and each has its own RT, matched by the other leaves in the DC. The
“tenants” as such are defined at layer 3 by assigning SVIs to the appropriate VRF. To view this
assignment, use the show ip route vrf <tenant> connected command. Note below that VLANs 12-13
and 212-213 (shown in bold) are configured as a bundle-aware EVPN service. Also note the peering
from Leaf-11 to the BGP border router in each tenant VRF.
1049
EVPN BGP Overlay Configuration for the Tenants’ MAC VRFs and IP VRF: Leaf-11
!
!
!
seq 10 permit 1.1.1.11/32
seq 20 permit 1.1.1.12/32
seq 30 permit 1.1.1.22/32
seq 40 permit 1.1.1.21/32
seq 50 permit 2.2.2.1/32
seq 60 permit 2.2.2.2/32
!
router bgp 65002
router-id 1.1.1.11
maximum-paths 4
!
vlan 10
rd 1.1.1.11:1010
route-target both 1010:1010
redistribute learned
!
vlan 11
rd 1.1.1.11:1011
!
vlan 20
rd 1.1.1.11:1020
!
vlan 210
rd 1.1.1.11:1210
no redistribute host-route
!
vlan 211
rd 1.1.1.11:1211
!
1050
vlan 220
rd 1.1.1.11:1220
!
vlan-aware-bundle Tenant-A-VLAN-12-13
rd 1.1.1.11:1213
vlan 12-13
!
vlan-aware-bundle Tenant-B-VLAN-212-213
rd 1.1.1.11:21213
vlan 212-213
!
address-family evpn
!
address-family ipv4
!
vrf tenant-a
rd 1.1.1.11:1000
route-target import 1000:1000
route-target export 1000:1000
neighbor 223.255.255.250 peer-group LEAF_PEER_OVERLAY
redistribute connected route-map dont_advertise_loopbacks
!
vrf tenant-b
rd 1.1.1.11:1001
1051
!
!
!
seq 10 permit 1.1.1.11/32
seq 20 permit 1.1.1.12/32
seq 30 permit 1.1.1.22/32
seq 40 permit 1.1.1.21/32
seq 50 permit 2.2.2.1/32
seq 60 permit 2.2.2.2/32
!
router bgp 65002
router-id 1.1.1.12
maximum-paths 4
!
vlan 10
rd 1.1.1.12:1010
!
vlan 11
rd 1.1.1.12:1011
!
vlan 20
rd 1.1.1.12:1020
!
vlan 210
rd 1.1.1.12:1210
!
vlan 211
rd 1.1.1.12:1211
!
1052
vlan 220
rd 1.1.1.12:1220
!
rd 1.1.1.12:1213
vlan 12-13
!
rd 1.1.1.12:21213
vlan 212-213
!
address-family evpn
!
address-family ipv4
!
vrf tenant-a
rd 1.1.1.12:1000
!
vrf tenant-b
rd 1.1.1.12:1001
1053
!
!
!
router bgp 65002
router-id 1.1.1.21
maximum-paths 4
!
vlan 10
rd 1.1.1.21:1010
!
vlan 11
rd 1.1.1.21:1011
!
vlan 21
rd 1.1.1.21:1021
!
vlan 210
rd 1.1.1.21:1210
!
vlan 211
rd 1.1.1.21:1211
!
vlan 221
rd 1.1.1.21:1221
!
rd 1.1.1.21:1213
1054

vlan 12-13
!
rd 1.1.1.21:21213
vlan 212-213
!
address-family evpn
!
address-family ipv4
!
vrf tenant-a
rd 1.1.1.21:1000
neighbor 223.255.255.254 next-hop-self
neighbor 223.255.255.254 update-source Vlan1111
!
vrf tenant-b
rd 1.1.1.21:1001
1055
!
!
!
router bgp 65002
router-id 1.1.1.22
maximum-paths 4
!
vlan 10
rd 1.1.1.22:1010
!
vlan 11
rd 1.1.1.22:1011
!
vlan 21
rd 1.1.1.22:1021
!
vlan 210
rd 1.1.1.22:1210
!
vlan 211
rd 1.1.1.22:1211
!
vlan 221
rd 1.1.1.22:1221
!
rd 1.1.1.22:1213
1056

vlan 12-13
!
rd 1.1.1.22:21213
vlan 212-213
!
address-family evpn
!
address-family ipv4
!
vrf tenant-a
rd 1.1.1.22:1000
!
vrf tenant-b
rd 1.1.1.22:1001
21.5.2.8 eBGP Overlay on Spine Switches

The EVPN BGP configuration on the spine switches is summarised in the examples below. Note that
only the EVPN BGP sessions are listed for two spine switches; the BGP underlay configuration is not
included.
1057
EVPN BGP Overlay Configuration: Spine-1

!
router bgp 65001
router-id 1.1.1.1
neighbor LEAF_EVPN peer-group
neighbor LEAF_EVPN remote-as 65002
neighbor LEAF_EVPN update-source Loopback0
neighbor LEAF_EVPN ebgp-multihop 5
neighbor LEAF_EVPN send-community extended
neighbor LEAF_EVPN next-hop-unchanged
neighbor LEAF_EVPN maximum-routes 12000
neighbor 1.1.1.11 peer-group LEAF_EVPN
!
address-family evpn
neighbor LEAF_EVPN activate
!
address-family ipv4
no neighbor LEAF_EVPN activate
!
address-family ipv6
!
EVPN BGP Overlay Configuration: Spine-2

!
router bgp 65001
router-id 1.1.1.2
neighbor LEAF_EVPN peer-group
neighbor LEAF_EVPN remote-as 65002
neighbor LEAF_EVPN update-source Loopback0
neighbor LEAF_EVPN ebgp-multihop 5
neighbor LEAF_EVPN send-community extended
neighbor LEAF_EVPN next-hop-unchanged
neighbor LEAF_EVPN maximum-routes 12000
!
address-family evpn
neighbor LEAF_EVPN activate
!
address-family ipv4
!
address-family ipv6
!
1058
21.5.2.9 Symmetric IRB Configuration (Tenant-A)

In symmetric IRB, the host routes are generated by advertising type-2 routes with both the MAC VRF
VNI and the routing (or VRF) VNI. On Leaf-11, the MAC VRFs for Tenant-A are left in their default
configuration (i.e., redistributing host routes). The example below shows the configuration for the MAC
VRF.
MAC VRF Configuration for Tenant-A: Leaf-11

The redistribute learned commands below cause type-2 routes to be advertised with two labels: in
VLAN 10, 1010 and 1000; in VLAN 11, 1011 and 1000; in VLAN 21, 1021 and 1000.
vlan 10
rd 1.1.1.11:1010
!
vlan 11
rd 1.1.1.11:1011
!
vlan 21
rd 1.1.1.11:1021
!
With this configuration, any locally learned MAC-IP binding on a leaf switch will be advertised as a
type-2 route with two labels. For example, on switches Leaf-21 and Leaf-22, any MAC-IP binding locally
learned on subnets 10.10.10.0/24, 10.10.11.0/24, or 10.10.21.0/24 will be advertised as type-2 routes
with two labels (the MAC VRF of 1010,1011, or 1021 and the IP VRF of 1000) and two route targets
equal to the relevant MAC VRF for the host and IP VRF for the tenant (1000:1000). The remote leaf
switches (Leaf-11 and Leaf-12), will now learn the host route in the IP VRF.
In addition to advertising the type-2 routes with dual labels, the switch will still advertise type-5 routes.
This ensures connectivity to the remote subnet even when no host on the subnet has been learned.
With both a layer-2 route and layer-3 host route for Server-3 learned on the MAC VRF(1010) and the
IP VRF (1000) on Leaf-11, traffic ingressing on Leaf-11 from the local subnet 10.10.10.103 (i.e., VLAN
10) will be VXLAN bridged based on the MAC VRF entry. Traffic ingressing from outside the subnet
(i.e., VLAN 11,12,13, or 20) will be routed to the host via the IP VRF host route.
The VLAN-aware bundle VLAN type-2 routes are advertised with the VNI ID within the update.
The type-5 routes are advertised with the IP VRF Route Distinguisher and the VNI label, signifying that
the forwarding path for the prefix would be the IP VRF. The imported routes from the eBGP peering
with the BGP border router in Leaf-11 and Leaf-12 are imported by both switches respectively and
redistributed via type-5 advertisements to Leaf-21 and Leaf-22.
21.5.2.10 Asymmetric IRB Configuration (Tenant-B)

In asymmetric IRB, the host routes are generated by advertising type-2 routes with just the MAC VRF
VNI. On leaf 11, the MAC VRFs for Tenant-B are configured with no redistribute host route within the
MAC VRF configuration. The example below shows the configuration for the MAC VRF.
1059
MAC VRF Configuration for Tenant-B: Leaf-11

The no redistribute host-route commands below cause type-2 routes to be advertised with a single
label: in VLAN 210, 1110; in VLAN 211, 1211; in VLAN 220, 1220; and in the VLAN-aware bundle
(Tenant-B-VLAN-212-213), 1212 and 1213.
vlan 210
rd 1.1.1.11:1210
!
vlan 211
rd 1.1.1.11:1211
!
vlan 220
rd 1.1.1.11:1220
!
rd 1.1.1.11:21213
vlan 212-213
!
With this configuration, any locally learned MAC-IP binding on a leaf switch will be advertised as a
type-2 route with a single label. For example, on Leaf-11 and Leaf-12, any MAC-IP binding locally
learned on subnets 10.10.10.0/24, 10.10.11.0/24, or 10.10.21.0/24 will be advertised as type-2 routes
with a single label, the MAC VRF (1210,1211,1220,1212,1213 or 21111). The IP VRF (1001) still
advertises the type-5 prefix routes. This ensures connectivity to the remote subnet even when no host
on the subnet has been learned.
The VLAN-aware bundle VLAN type-2 routes are advertised with the VNI ID within the update.
1060

Arista's EVPN Implementation Explained

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Arista's EVPN Implementation Explained

Hochgeladen von

Copyright:

Verfügbare Formate

Chapter 21

21.1 EVPN Overview

A controller-less BGP EVPN MAC learning is a standards-based control-plane (MP-BGP) is used to

21.1.1 EVPN Terminology

Type-1 Route: Ethernet A-D route

Type-2 Route: Host advertisement Route

Type-3 Route: Inclusive Multicast route

Type-4 Route: Ethernet Segment Route

Type-5 Route: IP-prefix route advertisement

21.1.2 EVPN Service Models

VLAN Based Service Interface

VLAN Bundle Service Interface

VLAN Aware Bundle Service Interface

21.2 EVPN Core Operations

21.2.1 MAC Address Learning.

Figure 21-9 notable fields:

21.2.2 ARP Suppression

21.2.3 MAC Mobility

21.2.4 MAC address Damping

21.2.5 Broadcast and Multicast Traffic

The format of the type-3 route is illustrated in Figure 21-12.

Figure 21-12 notable fields of the type-3 route:

21.3 Integrated Routing and Bridging

21.4 EVPN Type-5 Routes: IP Prefix Advertisement

Figure 21-21: EVPN Type-5 Route Format for Interface-less Mode

21.5 Configuration Examples

eBGP Underlay Configuration: Leaf-11

router bgp 65004

eBGP Underlay Configuration: Spine-1

VRF Configuration: Leaf-11

ip routing vrf VRF-Blue

router bgp 65004

VRF Configuration: Leaf-21

vrf definition VRF-Blue

ip routing vrf VRF-Blue

ip virtual-router mac-address 00:aa:aa:aa:aa:aa

VXLAN Configuration: Leaf-11

VXLAN Configuration: Leaf-21

EVPN Configuration: Leaf-11

EVPN Configuration: Leaf-21

EVPN Configuration: Spine-1

Advertise VRF Routes in EVPN: Leaf-11

Advertise VRF Routes in EVPN: Leaf-21

21.5.1 Multi-Tenant EVPN VXLAN IRB Sample Configuration

21.5.1.1 Topology Overview

Figure 21-24: Tenant-B: Asymmetric IRB

21.5.2 Multi-Tenant Configuration

21.5.2.1 MLAG Configuration: Leaf-11 and Leaf-12

Leaf-11 MLAG Configuration

Leaf-12 MLAG Configuration

21.5.2.2 MLAG Configuration: Leaf-21 and Leaf-22

Leaf-21 MLAG Configuration

Leaf-22 MLAG Configuration

21.5.2.3 VLAN and Distributed IP Address Configuration: Leaf-11 and Leaf-21

Leaf-11 VLAN and Distributed IP Address Configuration

vrf forwarding tenant-b

Leaf-21 VLAN and Distributed IP Address Configuration

vrf forwarding tenant-b

21.5.2.4 VXLAN Interface Configuration: Leaf-11 and Leaf-21

Leaf-11 VXLAN Interface Configuration

Leaf-21 VXLAN Interface Configuration

21.5.2.5 eBGP Underlay Configuration on the Leaf Switches