EVPN

Author: Fenghai Guo

 Copyright
Author: Fenghai Guo
Release Date: 2023-08-01
Issue: 02

Copyright © Huawei Technologies Co., Ltd. 2023. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and
recommendations in this document are provided "AS IS" without warranties, guarantees or representations of
any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
 Preface

Author Introduction
Fenghai Guo: Senior documentation engineer for Huawei data communication
products. He joined Huawei in 2011 and has been engaged in EVPN-related
documentation development for many years. He produced a series of Massive
Open Online Course (MOOC) videos titled New IP Technologies — EVPN.

About This Book

This book describes the background of EVPN and explores the value brought by
this technology. While Chapter 1 and Chapter 2 provide an overview and
background of EVPN, Chapter 3 briefly describes each value point and the
fundamentals of EVPN. Chapter 4 describes the successful application cases of
EVPN on cloud data center networks, telco cloud networks, and all-service 5G
transport networks. Chapter 5 provides deployment suggestions for evolution
from traditional L2VPN and L3VPN to EVPN. And Chapter 6 looks at how EVPN
application will develop in the future. Overall, this book aims to provide you with
a more comprehensive and in-depth understanding of the EVPN technology.

i
Preface
Intended Audience
This book is intended for network management engineers, network planning
engineers, and network design engineers at service providers and enterprises,
and readers who want to understand cutting-edge IP network technologies.
Because EVPN involves technologies such as L2VPN, L3VPN, BGP, MPLS, VXLAN,
and SRv6, readers of this book should have a basic understanding of these
technologies.

Symbol Conventions
Supplements important information in the main text. Note is
used to address information not related to personal injury, equipment damage,
or environment deterioration.

ii
Preface
 Table of Contents

Chapter 1 EVPN Overview .............................................................................................. 1

Chapter 2 EVPN Background .......................................................................................... 3

2.1 Challenges Facing Traditional L2VPN Technologies ...............................3

2.2 New Pursuit of Next-Generation Networks ...............................................7

Chapter 3 Technical Benefits and Fundamentals of EVPN ................................... 10

3.1 Improved Network Utilization...................................................................... 10

3.2 Simplified Network Deployment and Maintenance ............................ 22

3.3 Accelerated Network Convergence ............................................................ 26

3.4 Converged Transport of Various Services ................................................ 28

Chapter 4 Successful Applications of EVPN .............................................................. 41

4.1 Cloud DCN ........................................................................................................... 41

4.2 Telco Cloud Network ....................................................................................... 43

4.3 All-Service 5G Transport Network .............................................................. 44

Chapter 5 Deployment Suggestions for Evolution to EVPN ................................. 46

iii
Table of Contents
Chapter 6 EVPN Application Prospects ...................................................................... 48

iv
Table of Contents
 Chapter 1
EVPN Overview

Ethernet Virtual Private Network (EVPN) is a next-generation all-service

transport VPN technology. It unifies the control plane for various L2VPN and
L3VPN services by using BGP extensions to transmit Layer 2 and Layer 3
reachability information, separating the forwarding plane from the control plane.

With the rapid development of cloud Data Center Networks (DCNs) and next-
generation transport networks, application-oriented End-to-End (E2E)
communication services are booming. Traditionally, L2VPN technologies such as
Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) are
used to carry these services. But EVPN is gaining popularity, as unlike traditional
L2VPN technologies, it can implement load balancing, simplify deployment and
maintenance, and speed up fault recovery. Furthermore, EVPN can meet the
requirements for protocol simplification and multi-service transport imposed by
next-generation transport networks.

Figure 1-1 shows the development of EVPN in terms of service types and
tunneling technologies.

1
EVPN Overview
 Figure 1-1 History of EVPN development

In terms of service types, EVPN has gradually expanded its range of supported
services from EVPN VPLS to EVPN VPWS, EVPN E-Tree, and EVPN Integrated
Routing and Bridging (IRB), and then to EVPN L3VPN, and EVPN Data Center
Interconnect (DCI). In the future, EVPN will also support services such as
multicast VPN, Bit Index Explicit Replication (BIER), and Bit Index Explicit
Replication IPv6 Encapsulation (BIERv6). In terms of tunneling technologies,
EVPN has undergone the following development phases: EVPN over
Multiprotocol Label Switching (MPLS), EVPN over VXLAN, EVPN over Segment
Routing MPLS (SR-MPLS), and EVPN over Segment Routing IPv6 (SRv6). As
EVPN evolves, it will become more adaptable and support VXLANv6 tunnels and
seamless interconnection between multiple types of tunnels.

Simply put, EVPN is rapidly adapting to more and more VPN scenarios.

2
EVPN Overview
 Chapter 2
EVPN Background

There are generally two drivers behind a new technology. One is that an existing
technology has certain defects. Although these defects were tolerated in the
early business environment, their impact became greater as services developed,
giving rise to the emergence of an alternative technology. The second is that an
existing technology cannot meet requirements posed by emerging services. In
this case, research on new technologies will become increasingly popular.
Against this backdrop, the following sections discuss why EVPN came about and
how it will develop.

2.1 Challenges Facing Traditional

L2VPN Technologies
Traditional L2VPN technologies include VPWS and VPLS, which carry Point-to-
Point (P2P) and Multipoint-to-Multipoint (MP2MP) services, respectively. When
they first emerged, these technologies quickly gained favor. VPWS leverages
MPLS to establish P2P virtual private lines over an IP network, so that E2E
services can benefit from private line transmission similar to that provided by the
Asynchronous Transfer Mode (ATM) or Frame Relay (FR) network. In addition to
MPLS, VPLS also leverages Ethernet technologies to create a virtual Layer 2
switching network over an IP network. From the perspective of users, the entire

3
EVPN Background
IP network functions as a Layer 2 switching device, allowing them to
communicate as if they were directly connected through a Local Area Network
(LAN). Although these technologies enable application-oriented E2E services to
be transmitted over an IP network, they have a few defects that have led to
them losing favor and being replaced by EVPN. After all, no technology is ever
perfect. The following takes a look at what these defects are.

Single-Active Access Only

A traditional L2VPN typically supports only single-active access. Access here
refers to the connection from a Customer Edge (CE) device to a Provider Edge
(PE) device. This connection is a path that service data traverses to enter the
transport network from the user network. Mature VPN technologies must take
into account the reliability of such connections. To do so, VPWS and VPLS —
both mature MPLS VPN technologies — generally implement dual-homing of
one CE to two PEs, as shown in Figure 2-1. Specifically, a redundant link is
established to ensure reliability. However, this redundant link really is
"redundant", because it remains idle most of the time, forwarding data only
when the active link fails. After the active link recovers, the redundant link
returns to the standby state and remains idle again.

Figure 2-1 Dual-homing of CEs to PEs

As we can see, this mode wastes a link, wasting an entire forwarding path if we
also consider subsequent links that may be involved. Over time, the scale of IP

4
EVPN Background
networks has increased significantly, and that of L2VPN services is growing
rapidly. With the emergence of DCNs in particular, even a slight waste creates a
big problem. And as the number of L2VPN services increases, so too does
bandwidth waste. In addition, single-active access also contributes to another
problem: load imbalance. For example, the active link might work 24/7 while the
standby link just sits idle — it is completely wasted. This is the first challenge
faced by traditional L2VPN technologies today.

Full-Mesh PWs
Pseudo Wires (PWs) are direct logical channels used by VPWS and VPLS to
forward services. Those familiar with networks should know that full-mesh
connectivity is not a good thing. Unfortunately, VPWS and VPLS both require PEs
to be fully meshed through PWs, as shown in Figure 2-2.

Figure 2-2 Full-mesh PWs

The side effects of using full-mesh PWs are as follows:

1. Low network scalability. Each time a PE is added, a PW needs to be

established between this PE and each existing PE for each service. In other
words, the number of PWs is approximately equal to half the squared
number of PEs, multiplied by the number of services.
2. Heavy deployment and maintenance workload. The establishment of a PW
involves a great deal of configuration. In combination with the preceding
side effect, this places a heavy burden on the network administrator.

5
EVPN Background
3. High performance requirements for PEs. A PW is a type of connection and
requires many PE resources to maintain connectivity, adding further pressure
on PEs.

As the network scale and service quantity increase sharply, the preceding side
effects are magnified. This is the second challenge faced by traditional L2VPN
technologies.

MAC Address Learning Through the Forwarding

Plane
Layer 2 forwarding relies on MAC addresses. Unlike VPWS, which does not need
to learn MAC addresses due to being P2P L2VPN, VPLS needs to learn MAC
addresses through the forwarding plane. While this may seem insignificant, PEs
on a VPLS network learn new MAC addresses through broadcast, meaning that
MAC address information is flooded on the network. Flooding causes the
following two issues:

1. Each time a device with a new MAC address connects to the network, this
address is flooded across the entire network for all PEs to learn, regardless
of whether these PEs need to learn the address. This not only wastes
network bandwidth, but also increases the burden on PEs. Learning new
MAC addresses is always a worthwhile activity, even if it consumes
unnecessary bandwidth to do so. But the next issue is really annoying.
2. If a fault occurs, the reachability of existing MAC addresses changes
accordingly, requiring the related PEs to re-learn the MAC addresses as soon
as possible to ensure service continuity. However, re-learning MAC addresses
takes time due to the flooding process, meaning that network convergence
and protection switching are both slow. Even if the wasted bandwidth can
be tolerated, the potential service impact cannot.

This is the third and biggest challenge faced by traditional L2VPN technologies.

While VPLS does have a control plane, it is only used to establish, maintain, and
tear down PWs — it is not used for MAC address learning. In the days when
VPWS and VPLS were popular, their lack of MAC address learning was
acceptable because all MAC addresses were learned through broadcast on the
Ethernet. The protocols were designed for specific functions, meaning that VPWS
and VPLS were not designed to incorporate MAC address learning functions. Of

6
EVPN Background
course, the business environment played a decisive role. At that time, only the
E2E services of VIP customers used such advanced technologies. The networking
was relatively stable, and the service scale was limited.

Despite their various defects, VPWS and VPLS were very popular at the beginning
because they eliminated the need for people to use technologies such as ATM
and FR to establish Virtual Circuits (VCs) — hard private lines that involve high
construction and maintenance costs. Compared with the associated expense of
hard private lines, the defects of cost-effective VPWS and VPLS were acceptable.
However, as the scale of L2VPN services continued to expand, small defects
became major issues. Consequently, research on technologies to replace VPWS
and VPLS gained pace, culminating in the emergence of EVPN.

2.2 New Pursuit of Next-Generation

Networks
While the defects of traditional L2VPN technologies are the drivers behind the
emergence of EVPN, the key to further developing EVPN is the pursuit of next-
generation networks such as cloud DCNs and 5G transport networks.

Call from Cloud DCNs

Of all the buzzwords in recent years, "cloud computing" and "big data" are likely
to be the most prominent. Behind both of these is the cloud DCN, an important
digital infrastructure that schedules computing power for cloud computing and
transmits data for big data. So why do cloud DCNs need EVPN? To answer this
question, we have to mention another popular technology: Virtual eXtensible
Local Area Network (VXLAN).

VXLAN and cloud DCNs have a love-hate relationship that would take another
book to describe. Simply put, VXLAN is a tunneling technology that builds
virtualized large Layer 2 networks within DCNs or on DCI networks. It allows
Virtual Machines (VMs) in a data center to be freely migrated, making resource
utilization more flexible and efficient. In addition, it can divide a network into
many virtual networks to isolate numerous tenants. Despite its strengths,
however, VXLAN also has a significant disadvantage: it lacks a control plane,

7
EVPN Background
having only a forwarding plane. Initially, all VXLAN capabilities are implemented
through packet forwarding. And similar to VPLS, MAC address learning is also
performed on the forwarding plane. However, unlike VPLS, which has a control
plane for PW peer discovery and maintenance, VXLAN does not even discover or
maintain peer relationships. All peer relationships need to be manually
configured, which is far too laborious.

So how can VXLAN help cloud DCNs achieve great feats? It itself needs help,
which comes in the form of EVPN. The relationship between EVPN and VXLAN is
mutually beneficial: VXLAN offers EVPN an opportunity to make headway into
cloud DCNs, while EVPN brings a control plane to VXLAN, freeing VXLAN from
MAC address learning concerns by transmitting Layer 2 reachability information.
Moreover, EVPN helps VXLAN implement automatic peer discovery and
maintenance. Through close collaboration in the cloud DCN field, EVPN and
VXLAN are becoming more and more popular due to their exceptional
performance.

While EVPN facilitates the success of cloud DCNs, the successful application of
EVPN in cloud DCNs further promotes the development of EVPN. Shared success
relies on cooperation, with reciprocity laying the foundation of a mutually
beneficial relationship — one that is clearly evident between EVPN and cloud
DCNs.

Vision of 5G Transport Networks

As mentioned earlier, cloud computing and big data are likely to be some of the
most prominent buzzwords recently. But if we narrow the time range down to
only the last few years, 5G certainly eclipses them both. In a narrow sense, 5G is
simply a fifth-generation mobile communications technology. In a broad sense,
however, 5G also covers Radio Access Networks (RANs), transport networks, and
core networks with 5G requirements. Let's focus on the transport network as an
example. Empowered with 5G, the transport network is bound to realize major
success. Many ambitious goals have been set for the 5G transport network: high
bandwidth, high reliability, Service-Level Agreement (SLA) assurance, intelligent
O&M, protocol simplification, and converged transport. Let's take a look at two
of these goals: protocol simplification and converged transport.

For VPNs, to what extent should protocols be simplified? Simply put, P2P Layer 2
services, MP2MP Layer 2 services, and Layer 3 services have — in the past —

8
EVPN Background
required different protocol-based service models, such as VPWS, VPLS, and MPLS
L3VPN models. Now, however, only one EVPN-based service model is sufficient.
And in terms of converged transport, how converged should it be? It should
support convergence between the Layer 2 and Layer 3 services mentioned
earlier, between new tunnels represented by Segment Routing (SR) and old
tunnels represented by MPLS, and between IPv4 and IPv6 protocols. But is there
any VPN family member that can provide such functions? Yes, EVPN does.

While the demands from cloud DCNs will drive the depth of EVPN development,
the vision of 5G transport networks will drive the breadth of continuous EVPN
progress.

9
EVPN Background
 Chapter 3
Technical Benefits and
Fundamentals of EVPN

Following on from the background information provided earlier, this chapter

explores the technical benefits of EVPN and discusses how it delivers them.

3.1 Improved Network Utilization

Because EVPN was originally designed to replace traditional L2VPN technologies,
it must be able to tackle challenges faced by traditional L2VPN technologies.

All-Active Access
As mentioned earlier, traditional L2VPN technologies do not support all-active
access of CEs to PEs. One of the main reasons for this is that loops may occur on
the access side. EVPN supports all-active access, which maximizes the benefits of
multi-homing networking on the access side and improves network bandwidth
utilization. To explain how EVPN eliminates the issue of loops, we need to
understand two basic tools of EVPN: Ethernet Segment Identifiers (ESIs) and
EVPN routes.

10
Technical Benefits and Fundamentals of EVPN
ES & ESI

As shown in Figure 3-1, when a CE connects to one or more PEs over a group of
Ethernet links, this group of links is called an Ethernet Segment (ES). To uniquely
identify each ES, an ESI is used, with one ESI corresponding to one CE. PE
interfaces connected to the same CE have the same ESI. ESI 0 indicates that a CE
is single-homed to a PE. An ESI can be statically configured, or it can be
dynamically generated through Link Aggregation Control Protocol (LACP) on an
interface. ESIs are a key factor in EVPN and help prevent access-side loops.

Figure 3-1 ES and ESI

EVPN Routes

EVPN routes are the core of EVPN. EVPN leverages the advantages of BGP, which
is a powerful routing protocol on IP networks. Although BGP itself does not
calculate routes, it imports them from other protocols and then employs its rich
extended attributes and flexible control capabilities. This enables BGP to
eliminate many tricky problems on IP networks. It is extended to define the BGP-
EVPN address family for EVPN and new types of Network Layer Reachability
Information (NLRI) in the address family. These NLRIs cover five types of
commonly used EVPN routes, as listed in the following table.

11
Technical Benefits and Fundamentals of EVPN
 Table 3-1 EVPN route types

Type Route Major Function

Type 1 Ethernet Auto-Discovery (A-D) Split horizon, fast fault convergence,

routes, which are further classified aliasing, and Layer 2 traffic forwarding
into the following types: guidance (EVPN VPWS)
 Per-ES A-D routes

 Per-EVI A-D routes (EVI stands

for EVPN Instance)

Type 2 MAC/IP advertisement routes, also MAC advertisement, ARP advertisement,

called MAC/IP routes Neighbor Discovery (ND) advertisement,
and IRB advertisement

Type 3 Inclusive Multicast Ethernet Tag Automatic discovery of peers and Broadcast,
(IMET) routes Unknown Unicast, and Multicast (BUM)
traffic forwarding guidance

Type 4 ES routes Automatic discovery of ES members and

Designated Forwarder (DF) election

Type 5 IP prefix routes Advertisement of IP host routes and IP

prefix routes

There are more types of EVPN routes defined in standards, but because those
routes are not widely used at present, they are not mentioned here. Instead, we'll
concentrate on the value points achieved through EVPN routes.

To highlight the key points, we'll focus on the key information they carry rather
than delving into their formats. ES routes carry PEs' local ESIs and EVPN source
addresses, whereas per-ES A-D routes carry PEs' local ESIs and label values
allocated by PEs to ESIs. On the network shown in Figure 3-2, CE1 is dual-homed
to PE1 and PE2. After exchanging ES routes, these two PEs find that they have
the same ESI and add each other's EVPN source address to the local ES member
list. Then, PE1 and PE2 exchange per-ES A-D routes. They again find that they
have the same ESI. As such, they attach the label carried in the received route to
the corresponding ES member in their ES member list.

12
Technical Benefits and Fundamentals of EVPN
 Figure 3-2 ES member discovery process

On the network shown in Figure 3-3, the links between CE1 and PE1 and
between CE1 and PE2 are both active. Assume that CE1 sends a broadcast
packet. After receiving the packet, PE1 checks whether the broadcast object is in
the local ES member list. Because PE2 is in the list, PE1 adds the corresponding
ESI label (label in the ES member list) to the broadcast packet and then
broadcasts the packet to PE2. After receiving the packet, PE2 finds that it
contains the local ESI label and then discards the packet. This process is called
split horizon, which prevents routing loops on the access side.

13
Technical Benefits and Fundamentals of EVPN
 Figure 3-3 Split horizon

By eliminating routing loops, split horizon enables EVPN access links to remain
active. This means that redundant links can be fully utilized, allowing access-side
load to be evenly balanced and improving bandwidth utilization.

BUM Traffic Multi-Receiving Avoidance

Although eliminating access-side loops in all-active mode is a major
accomplishment, other problems still exist. For example, in all-active mode on
the network shown in Figure 3-4, PE1 and PE2 receive a copy of BUM traffic at
the same time and send the traffic to CE1. While it might seem like receiving two
copies of the same traffic is no problem, repeatedly transmitting BUM traffic
wastes the link bandwidth between the PEs and CE. Furthermore, receiving
multiple copies of the same traffic might cause issues such as ghosting in videos
or echoes in audio streams. As such, this problem must be solved.

14
Technical Benefits and Fundamentals of EVPN
 Figure 3-4 BUM traffic multi-receiving

In theory, solving this problem is simple: just allow only one PE to send the
traffic. However, deciding which device should send the traffic is the tricky part.
For this, we can use an election process. To preside over the election, EVPN sends
ES routes. The winner of the election is called the Designated Forwarder (DF)
and is allowed to forward BUM traffic to CE1. The loser, conversely, is called a
non-DF and is not allowed to forward BUM traffic. In cases where the DF is
unavailable — for example, it is faulty — the loser is elevated to be the DF.
Let's take a look at the election process. As shown in Figure 3-5, after PE1 and
PE2 exchange ES routes, they generate their own ES member lists. DF election is
then performed based on these lists in either of the following modes:

1. Rough mode: interface-based election. The status of PE interfaces connected

to the CE is checked first — those that are in the down state are excluded
from the election. Among PEs whose interfaces are in the up state, the one
with the smallest EVPN source address in the ES member list is elected as
the DF. This implementation applies to all services.
2. Fine-grained control mode: VLAN-based election. As in the rough mode,
interfaces in the down state are excluded from the election to minimize
resource waste. Then, the DF is elected among the remaining PEs whose
interfaces are in the up state according to the formula V mod N = i. Here, V

15
Technical Benefits and Fundamentals of EVPN
 indicates the VLAN ID, N the number of PEs connected to the same CE, and i
the sequence number of the PE that is selected as the DF in the ES member
list. To clarify this, let's use an example. On the network shown in Figure 3-5,
there are two VLANs. For services in VLAN 10, 10 mod 2 = 0 is used. This
means that PE1, which has the sequence number of 0, is the DF. For services
in VLAN 11, 11 mod 2 = 1 is used. In this case, PE2 is the DF because it has
the sequence number of 1. The advantage of this mode is that services in
different VLANs can have their own DFs, facilitating fine-grained control.

Figure 3-5 DF election

Minimized Broadcasting
To improve network utilization, EVPN needs to solve the issue of MAC address
learning through the forwarding plane — specifically, it needs to minimize MAC
address learning through broadcast. This is achieved through MAC/IP routes,
which leverage two key concepts: MAC advertisement and ARP advertisement. To
understand how an MAC/IP route works, we first need to know its NLRI format.

16
Technical Benefits and Fundamentals of EVPN
Table 3-2 shows the NLRI format of a MAC/IP route, in which the key
information includes the advertised MAC address, advertised IP address, ESI, and
Layer 2 forwarding label.

Table 3-2 NLRI format of a MAC/IP route

Field Length (Bytes) Description

Route 8 RD of an EVPN instance. RDs are used to distinguish the

Distinguisher VPN address space of different EVPN instances.

Ethernet 10 ESI value, which uniquely identifies a connection

Segment between PEs and a CE.
Identifier

Ethernet Tag 4 Ethernet tag ID.

ID

MAC Address 1 Length of the MAC address advertised by the current

Length route.

MAC Address 6 MAC address advertised by the current route.

IP Address 1 Length of the IP address advertised by the current route.

Length

IP Address 0, 4, or 16 IP address (IPv4 or IPv6) advertised by the current route.

MPLS Label1 3 Label used to guide Layer 2 service traffic forwarding.

MPLS Label2 0 or 3 Label used to guide Layer 3 service traffic forwarding.

MAC/IP routes are classified into the following types depending on the
information carried:

MAC Advertisement Routes

A MAC advertisement route carries MAC address, ESI, and Layer 2 forwarding
label information. It is responsible for eliminating MAC address learning through
broadcast by remote PEs. On the network shown in Figure 3-6, assume that CE1
is newly deployed and dual-homed to PE1 and PE2. PE1 and PE2 exchange
messages (such as ARP requests) with CE1 to learn its MAC address (mac1 in

17
Technical Benefits and Fundamentals of EVPN
this case). At this time, PE1 and PE2 learn mac1 from the forwarding plane
because they need to start from scratch — learning MAC addresses from a local
device does not incur much workload. Then, PE1 and PE2 each generates a
MAC/IP route and advertises mac1 to all their EVPN peers.

Let's first examine how PE1 and PE2 respond. After receiving MAC/IP routes from
each other, PE1 and PE2 compare ESIs carried in these routes with local ESIs and
find that they belong to the same ES. To prevent detours in packet forwarding,
PE1 and PE2 preferentially select the locally generated mac1 route. Now let's
examine how PE3 and PE4 respond. These two remote PEs learn mac1 from two
routes with different next hops, laying the foundation for subsequent load
balancing. PE3 and PE4 learn mac1 without the need for broadcast and can
unicast received packets destined for mac1 instead of broadcasting them as
unknown unicast packets. This significantly reduces the number of broadcast
packets on the network side.

Figure 3-6 MAC address learning

ARP Advertisement Routes

An ARP advertisement route carries MAC address, IP address, ESI, and Layer 2
forwarding label information. It is responsible for eliminating ARP request
broadcast by remote PEs and needs to be used together with proxy ARP. Similar
to the MAC advertisement route described earlier, on the network shown in
Figure 3-7, PE1 and PE2 learn the IP address (ip1) as well as the MAC address

18
Technical Benefits and Fundamentals of EVPN
(mac1) of the newly deployed CE1 by exchanging messages. In other words, PE1
and PE2 obtain a new ARP entry. Then, these two PEs each generates a MAC/IP
route and advertises the new ARP entry to all their EVPN peers.

PE1 and PE2 respond by generating an ARP snooping entry based on local ARP
information for proxy ARP. Conversely, PE3 and PE4 respond by generating an
ARP snooping entry based on the latest ARP information, because they favor
new ARP information over old ARP information. If PE3 or PE4 receives an ARP
request packet destined for ip1 again, PE3 or PE4 will check local ARP snooping
entries for a matching MAC address based on ip1 and then unicast these
packets. In this way, PE3 and PE4 eliminate the need of broadcasting ARP
request packets, further reducing the number of broadcast packets on the
network side.

Figure 3-7 Proxy ARP

IRB advertisement routes are another type of MAC/IP route. This type of route
carries MAC address, IP address, ESI, Layer 2 forwarding label, and Layer 3
forwarding label information. We'll discuss this type of route later.

19
Technical Benefits and Fundamentals of EVPN
Load Balancing
There are two levels to utilization improvement: full utilization (primary level)
and full, balanced utilization (secondary level). As a promising VPN technology,
EVPN aims to reach the second level. By supporting all-active access, EVPN
achieves full, balanced traffic distribution on the access side. And through
MAC/IP routes, EVPN also achieves full, balanced traffic distribution on the
network side. To understand how EVPN load balancing works, let's take a look at
a forwarding example. On the network shown in Figure 3-8, assume that four
unicast service flows are sent from CE2 to CE1. The forwarding process is as
follows:

1. CE2 sends traffic over active-active links in load-balancing mode to PE3 and
PE4.
2. On PE3 and PE4, there are two MAC routes with the same destination MAC
address (mac1) but different next hops. As a result, PE3 and PE4 send traffic
to PE1 and PE2 in load-balancing mode.
3. After receiving the traffic, PE1 and PE2 forward the traffic to CE1 according
to their local MAC address tables.

Figure 3-8 Traffic load balancing

This forwarding process is straightforward, but networks always involve a certain

degree of uncertainty. For example, on the network shown in Figure 3-9, CE1 is
dual-homed to PE1 and PE2. Assume that PE2 fails to learn the MAC address
mac1 — this could be due to any number of reasons (in normal situations, both
PE1 and PE2 would learn mac1). In this case, only PE1 generates a MAC/IP route

20
Technical Benefits and Fundamentals of EVPN
to advertise mac1 to PE3 and PE4. As a result, PE3 and PE4 cannot send traffic
destined for mac1 in load-balancing mode.

Figure 3-9 PE2 failing to learn mac1

To address this issue, EVPN introduces per-EVI A-D routes and utilizes aliasing.
Figure 3-10 shows how this works.

1. PE1 generates a MAC/IP route and advertises mac1 to PE3 and PE4.
2. PE2 advertises a per-EVI A-D route carrying ESI and unicast forwarding label
information to PE3 and PE4.
3. Although PE3 and PE4 do not receive any MAC/IP route from PE2, they find
that the ESI carried in the MAC/IP route from PE1 is the same as the ESI
carried in the route received from PE2. As such, PE3 and PE4 consider that
PE2 is also reachable to mac1 and update their MAC address tables
accordingly.
4. When PE3 and PE4 send subsequent unicast traffic to mac1, they continue to
load-balance traffic between PE1 and PE2.

21
Technical Benefits and Fundamentals of EVPN
 Figure 3-10 Aliasing

However, even though PE3 and PE4 consider PE2 a device for load-balancing
unicast traffic destined for mac1, PE2 has not learned mac1 yet, meaning that
PE2 cannot forward traffic to this destination. To solve this problem, EVPN
introduces a mechanism called MAC redirection. We can understand this
mechanism as follows: After PE1 generates a MAC/IP route, PE1 also advertises
mac1 to PE2. PE2 finds that the ESI carried in the route also exists locally, so it
redirects the outbound interface for mac1 to the local interface connected to
CE1. In this way, PE2 directly forwards the traffic destined for mac1 through the
local interface. This mechanism is a key enabler in how EVPN implements load
balancing.

3.2 Simplified Network Deployment

and Maintenance
During the time when IP first emerged, many other network-layer protocols were
far more powerful than IP. But IP won out due to its simplicity. In much the
same way, EVPN stands out in the VPN world because it can simplify network
deployment and maintenance.

22
Technical Benefits and Fundamentals of EVPN
Automatic Peer Discovery
EVPN peer relationships must be established for EVPN to work properly. This
involves more than just configuration — PEs need to exchange basic
information about themselves, similar to how new business acquaintances
exchange business cards. On an EVPN network, the process of exchanging
"business cards" is called peer discovery. In this automatic process, IMET routes
(Type 3 routes) are responsible for sending "business cards".

Take the network shown in Figure 3-11 as an example. After EVPN is enabled on
PEs, they advertise IMET routes to each other. These routes carry information
such as the EVPN instance RD, PE source address, and tunnel forwarding label.
After receiving such routes, a PE detects all its EVPN peers and generates a peer
list based on the EVPN instance (identifying a service). This list — called a BUM
traffic forwarding table — is similar to an address book, which is used to guide
BUM traffic forwarding. Assume that PE1 receives an unknown unicast packet.
Although PE1 does not know to which device the packet is bound, it does not
care. It only needs to send a copy of the packet to each peer in the BUM traffic
forwarding table.

23
Technical Benefits and Fundamentals of EVPN
 Figure 3-11 Automatic peer discovery

The main advantage of automatic peer discovery is that it simplifies network

deployment and maintenance. Specifically, each newly deployed PE on an EVPN
can automatically interact with other devices once the administrator performs
basic configurations on the PE.

Full-Mesh Connection Avoidance

As mentioned earlier, an important reason why traditional L2VPN technologies
have fallen out of favor is that they require full-mesh PWs to forward services,
and manually configuring many PWs involves a heavy workload. Given that we
can automate tasks such as cleaning floors and windows, manually configuring
PWs today appears outdated. This is not the case with EVPN, which is a
technology for today and the future.

On an EVPN, each pair of PEs need to establish an EVPN peer relationship for
EVPN route exchange. While this might appear the same as a full-mesh
connection scenario, it is not. By leveraging BGP's Route Reflector (RR)

24
Technical Benefits and Fundamentals of EVPN
mechanism, EVPN frees itself from the full-mesh constraints. On the network
shown in Figure 3-12, PEs only need to establish peer relationships with the RR,
which then reflects EVPN routes among PEs. The RR mechanism brings the
following benefits to EVPN:

1. It significantly improves EVPN scalability. When a new PE is deployed, it only

needs to establish an EVPN peer relationship with the RR. This means that
EVPN is applicable to large-scale networks.
2. It significantly reduces the configuration workload. Unlike traditional L2VPN
technologies that involve complex configurations, the administrator
workload in EVPN is reduced thanks to the RR mechanism, which minimizes
the number of peer relationships needed.
3. It effectively reduces the burden on PEs. Because PEs only need to maintain
peer relationships with the RR, they can focus more resources on operating
services.

Figure 3-12 RR mechanism

Network Protocol Simplification

The ultimate vision is to have only one protocol running on the network.
Although EVPN cannot realize this vision, it does take a solid step toward
simplifying network protocols for VPN.

As mentioned earlier, before EVPN was developed, Layer 2 services involved

VPWS and VPLS, and used either LDP or BGP as the signaling protocol; Layer 3
services involved MPLS L3VPN, and used BGP as the signaling protocol. As shown

25
Technical Benefits and Fundamentals of EVPN
in Figure 3-13, with the introduction of EVPN, the service layer requires only
EVPN, while only BGP is needed for signaling. This makes the network much
simpler. The direct benefit of network protocol simplification is that service
deployment is more convenient. There are also considerable indirect benefits. For
example, when a service-layer fault occurs on the network, it is no longer
necessary to demarcate the fault — only EVPN troubleshooting is required. For
maintenance engineers, this makes their work much easier.

Figure 3-13 Protocol simplification

3.3 Accelerated Network Convergence

Whether or not a person is up to the task largely depends on how well the
person behaves in times of crisis. This also holds true for a technology. The
success of EVPN is closely related to its excellent performance when network
faults occur.

A VPN is generally complex, involving various devices and cables physically and
various connections and layer-specific protocols logically. As such, expecting a
VPN to run normally forever is unrealistic. But if a fault occurs, the VPN must be
able to quickly complete convergence to ensure service continuity. The key word
here is "quickly".

In the traditional L2VPN scenario shown in Figure 3-14, if the link between PE1
and CE1 fails, PE1 sends a MAC Withdraw message to PE3 after detecting the

26
Technical Benefits and Fundamentals of EVPN
fault. Once PE3 receives the message, it deletes the corresponding MAC address
entries. There are two issues here:

1. PE1 sends MAC Withdraw messages for all newly unreachable MAC
addresses one by one. If there are many such MAC addresses, there will be a
large number of MAC Withdraw messages. This is both inefficient and
wastes bandwidth.
2. After PE3 deletes MAC address entries, it no longer knows how to reach
these MAC addresses. Because traditional L2VPN cannot learn MAC
addresses in advance through the control plane, PE3 has to broadcast traffic
destined for these MAC addresses to learn the deleted MAC addresses again
during data forwarding.

The question is then: How can we accelerate convergence?

Figure 3-14 Fault convergence in a traditional L2VPN scenario

Let's take a look at how EVPN works in this case. On the network shown in
Figure 3-15, if the link between PE1 and CE1 fails, PE1 advertises a per-ES A-D
route (Type 1 route) to PE3 after detecting the fault. Note that this route is not
used to withdraw MAC addresses one by one. Instead, it instructs PE3 to
withdraw all the MAC routes with the next hop being PE1 and the ESI being esi1.
Regardless of how many MAC addresses are involved, only this one step is
necessary. Furthermore, because PE3 has learned other paths through MAC/IP
routes in advance (see Load Balancing), service traffic can be automatically
switched to paths with the next hop being PE2. As such, there is no need to re-

27
Technical Benefits and Fundamentals of EVPN
learn MAC addresses or broadcast packets in this case, resulting in quick — and
smooth — convergence.

Figure 3-15 EVPN route convergence in the case of a fault

3.4 Converged Transport of Various

Services
EVPN's comprehensive capabilities are another factor that sets it apart from
many other VPN technologies. Table 3-3 lists the various service scenarios that
EVPN supports and the corresponding transport solution for each user service
model. This is the so-called converged transport.

Table 3-3 Service scenarios supported by EVPN

EVPN Service Scenario Public Network Tunnel Type User Service Model

EVPN VPLS MPLS, SR-MPLS, SRv6 MP2MP Layer 2 services, also

called Ethernet Local Area
Network (E-LAN) services

EVPN VPWS MPLS, SR-MPLS, SRv6 P2P Layer 2 services, also

called Ethernet Line (E-Line)
services

28
Technical Benefits and Fundamentals of EVPN
 EVPN Service Scenario Public Network Tunnel Type User Service Model

EVPN E-Tree MPLS, SR-MPLS, SRv6 For special P2MP Layer 2

services, CEs that do not need
to communicate with each
other are isolated from each
other.

EVPN L3VPN MPLS, SR-MPLS, SRv6, VXLAN Layer 3 services similar to

traditional L3VPN services

EVPN VXLAN VXLAN Layer 2 and Layer 3 services

on DCNs

The first three sections of this chapter describe the technical value and
implementation principles of EVPN through EVPN VPLS service scenarios. This
chapter briefly describes other EVPN service scenarios.

EVPN VPWS
EVPN VPWS, as its name suggests, is a substitute for traditional VPWS and
provides P2P L2VPN services. Unlike EVPN VPLS, EVPN VPWS introduces the
following concepts, as shown in Figure 3-16:

 Attachment Circuit (AC) interface: An AC is an independent link between a

CE and a PE. An AC interface can be either a physical or a logical interface.
 Service ID: It is used to identify the local and remote AC interfaces.
 Ethernet Virtual Private Line (EVPL) instance: It associates an AC interface
(service ID) with a local EVPN instance.

PEs advertise to each other per-EVI A-D routes, which carry the EVPN instance
RD, ESI, service ID, tunnel label, and primary/backup tunnel status information.
After receiving such a route, a PE constructs a forwarding entry based on this
information (excluding the EVPN instance RD) to establish a P2P forwarding
path between AC interfaces on both ends. The PE does not need to learn MAC
addresses. This is similar to two phones connected over a private line: Two
people can directly pick up the phones to talk to each other without dialing.

29
Technical Benefits and Fundamentals of EVPN
 Figure 3-16 EVPN VPWS networking

Table 3-4 describes the differences between EVPN VPWS and EVPN VPLS.

Table 3-4 Comparison between EVPN VPWS and EVPN VPLS

Function EVPN VPWS EVPN VPLS

All-active Supported. Per-EVI A-D routes are used Supported. Per-ES A-D routes are
access to transfer all-active status information. used to transfer all-active status
information.

Split horizon N/A. P2P forwarding does not involve Supported.

this function.

DF election Supported. The DF and non-DF are Supported. DF election is

preferentially determined based on the performed based on interfaces or
E-Trunk master/backup status. If no E- VLANs.
Trunk is configured, DF election is
performed based on service IDs.

Load Supported. Equal-cost forwarding paths Supported. Load balancing is

balancing are established based on per-EVI A-D performed based on MAC routes,
routes, and aliasing is not required. and aliasing is supported.

30
Technical Benefits and Fundamentals of EVPN
 Function EVPN VPWS EVPN VPLS

Automatic N/A. Unicast traffic and BUM traffic are Supported.

peer not distinguished during forwarding.
discovery

Fast Supported. Invalid forwarding paths can Supported. Invalid MAC routes
convergence be quickly withdrawn using per-ES A-D can be quickly withdrawn using
routes. per-ES A-D routes.

EVPN E-Tree
EVPN also supports a special P2MP Layer 2 service model called E-Tree —
named as such because its networking logically resembles a tree. This model
involves two roles: root and leaf. The root and leaf nodes can communicate with
each other, but leaf nodes cannot communicate with each other. E-Tree is useful
in certain scenarios — for example, an enterprise wants to allow the
headquarters and business departments to communicate with each other but
isolate the business departments from each other.

EVPN E-Tree services can be implemented in either per-PE or per-AC mode.

Figure 3-17 shows EVPN E-Tree in per-PE mode. For an EVPN instance, each PE
can be either a root or a leaf node. This mode uses the matching relationships
between EVPN instance Route Targets (RTs) to control whether a PE can receive
EVPN routes, implementing communication between the root and leaf nodes
and isolation between leaf nodes.

31
Technical Benefits and Fundamentals of EVPN
 Figure 3-17 EVPN E-Tree in per-PE mode

Figure 3-18 shows EVPN E-Tree in per-AC mode. Each AC interface associated
with an EVPN instance can be either a root or a leaf interface. This means that,
unlike the per-PE mode, the per-AC mode allows a PE to have both root and leaf
AC interfaces. In this mode, PEs use MAC/IP routes to advertise the leaf flags of
MAC routes and use per-ES A-D routes to advertise their leaf labels to each
other.

Figure 3-18 EVPN E-Tree in per-AC mode (1)

32
Technical Benefits and Fundamentals of EVPN
Figure 3-19 shows traffic forwarding in per-AC mode from the perspective of
PE1. Assume that PE1 receives unicast traffic destined for CE3 from an AC
interface with the leaf attribute. In this case, PE1 checks the local MAC address
table and finds that the MAC route destined for CE3 carries the leaf flag. As
such, PE1 discards the traffic. If PE1 receives BUM traffic from an AC interface
with the leaf attribute, PE1 does not need to encapsulate a leaf label into the
BUM traffic when sending the traffic to PE2. After receiving the BUM traffic, PE2
directly forwards it to the AC interface with the root attribute. When sending
BUM traffic to PE3, PE1 encapsulates the leaf label of PE3 into the traffic. After
receiving this traffic, PE3 identifies its own leaf label and discards the traffic
(because it cannot send traffic carrying the leaf label to AC interfaces with the
leaf attribute).

Figure 3-19 EVPN E-Tree in per-AC mode (2)

EVPN E-Tree can be considered a special form of EVPN VPLS. EVPN VPLS
functions are also supported in EVPN E-Tree service scenarios.

EVPN L3VPN
The preceding sections describe only Layer 2 service scenarios. As a VPN
technology for all-service transport, EVPN also has tremendous advantages in
Layer 3 service scenarios.

The implementation principles of EVPN L3VPN are similar to those of traditional

L3VPN. As shown in Figure 3-20, on the control plane, EVPN uses prefix routes
(Type 5 routes) in substitute of VPNv4 and VPNv6 routes to transmit VPN IP

33
Technical Benefits and Fundamentals of EVPN
routes. On the forwarding plane, EVPN L3VPN packets are encapsulated with
double labels. The inner label is an EVPN L3VPN label, which is used to identify
the VPN instance to which the packet belongs, whereas the outer label is a
public network tunnel label, which is used to forward packets on the public
network.

Figure 3-20 EVPN L3VPN

EVPN L3VPN and traditional L3VPN — both of which are similar to each other
and rely heavily on BGP — belong to the BGP-EVPN address family and BGP-
VPNv4/VPNv6 address family, respectively. Traditional L3VPN is relatively mature
and provides various measures covering loop avoidance, load balancing, and
reliability. Given how alike they are, EVPN L3VPN only needs to inherit
traditional L3VPN functions.

EVPN VXLAN
In 2.2 , we touched on the inextricable relationship between EVPN and VXLAN. In
this section, we'll explore this relationship in greater detail.

34
Technical Benefits and Fundamentals of EVPN
The name of the EVPN VXLAN service scenario is slightly controversial. From the
perspective of EVPN, VXLAN provides only public network tunnels, so the service
scenario should be called EVPN over VXLAN. But from the perspective of VXLAN,
EVPN provides only the control plane and service transport for VXLAN, so the
scenario should be called EVPN VXLAN. However, from the perspective of users,
the service scenario typically covers cloud DCNs, where VXLAN plays a leading
role. As such, the service scenario is called EVPN VXLAN.

EVPN VXLAN Layer 2 Services

In Layer 2 service scenarios, EVPN helps VXLAN implement automatic discovery

of VXLAN Tunnel Endpoints (VTEPs), dynamically establish VXLAN tunnels, and
generate ingress replication lists for forwarding BUM traffic. After the ingress of
a VXLAN tunnel receives a BUM packet, it replicates the packet and sends a copy
to each VTEP in the ingress replication list.

On the network shown in Figure 3-21, Leaf1 and Leaf2 advertise IMET routes to
each other. The IMET routes carry local VTEP address and Layer 2 VXLAN
Network Identifier (VNI) information. After receiving IMET routes, Leaf1 and
Leaf2 obtain each other's VTEP address and Layer 2 VNI. If the peer VTEP
address is reachable, the local end triggers the establishment of a VXLAN tunnel
to the peer end, creates a VNI-based ingress replication list, and adds the peer
VTEP address to the list.

35
Technical Benefits and Fundamentals of EVPN
 Figure 3-21 VXLAN tunnel establishment

After VXLAN tunnels are established, EVPN also helps VXLAN dynamically learn
MAC addresses on the control plane to guide Layer 2 unicast service forwarding.
On the network shown in Figure 3-22, Leaf1 and Leaf2 learn the MAC addresses
of local hosts through the forwarding plane, generate a MAC/IP route (MAC
advertisement route), and advertise the route to each other. The route carries
information such as the MAC address and Layer 2 VNI of the local host. After
both ends receive the route, they find the corresponding Bridge Domain (BD)
based on the Layer 2 VNI and generate a remote MAC address entry in the
corresponding EVPN instance. The outbound interface in the entry recurses to a
VXLAN tunnel based on the next-hop VTEP address. This eliminates the need to
learn MAC addresses through broadcast.

36
Technical Benefits and Fundamentals of EVPN
 Figure 3-22 MAC address learning

Similar to EVPN VPLS, EVPN VXLAN also supports ARP advertisement. Leaf1 and
Leaf2 learn the IP addresses and MAC addresses of their local hosts through the
forwarding plane, generate a MAC/IP route (ARP advertisement route), and
advertise the route to the peer end. This route carries information such as the IP
address, MAC address, and Layer 2 VNI of the local host. After receiving the
route, both ends locally generate an ARP entry for the remote host. Then, after
receiving a broadcast ARP request packet, a leaf node searches local ARP entries.
If the packet matches an ARP entry, the leaf node replaces the broadcast MAC
address with the corresponding destination MAC address, converting the
broadcast packet into a unicast packet. This process is called ARP broadcast
suppression. The leaf node can also directly respond to the ARP requests in this
case. Both modes can further reduce broadcast.

EVPN VXLAN Layer 3 Services

In Layer 3 service scenarios, VXLAN also uses EVPN to transmit IP routing

information. EVPN provides two types of routes for this purpose: prefix routes
and MAC/IP routes (IRB advertisement routes). IRB advertisement routes apply
to both Layer 2 and Layer 3 services, but we'll discuss that later. Here, we'll focus
on the prefix routes for Layer 3 services.

37
Technical Benefits and Fundamentals of EVPN
On a VXLAN network, hosts access leaf nodes through BDs. To implement Layer
3 communication, we need to create Virtual Bridge Domain Interfaces (VBDIFs)
to function as Layer 3 gateways on leaf nodes. On the network shown in Figure
3-23, Leaf1 and Leaf2 import the IP address of the local host or the address of
the network segment where the host resides into the VPN instance. They then
generate a prefix route and advertise it to the peer end. This route carries
information such as the IP address and Layer 3 VNI. After receiving the route, a
leaf node checks the reachability of the next hop VTEP address. If it is reachable,
the leaf node initiates VXLAN tunnel establishment. The leaf node then finds the
corresponding VPN instance based on the Layer 3 VNI and generates an IP route
or network segment route to the remote host in the instance. The outbound
interface of the route recurses to a VXLAN tunnel based on the next hop VTEP
address.

Figure 3-23 IP route learning

EVPN VXLAN Layer 2 + Layer 3 Services

As mentioned earlier, MAC/IP routes are classified into three types: MAC
advertisement routes, ARP advertisement routes, and IRB advertisement routes.
We've discussed the first two already, so now we'll focus on IRB advertisement
routes. To understand this type of route, it's necessary to know its NLRI format,

38
Technical Benefits and Fundamentals of EVPN
which is shown in Table 3-5. In a VXLAN scenario, an IRB advertisement route
carries information such as the MAC address, IP address, ESI, Layer 2 VNI, and
Layer 3 VNI.

Table 3-5 NLRI format of IRB advertisement routes

Field Length (Bytes) Description

Route Distinguisher 8 RD of an EVPN instance. RDs are used to

distinguish the VPN address space of different
EVPN instances.

Ethernet Segment 10 ESI value, which uniquely identifies a

Identifier connection between PEs and a CE.

Ethernet Tag ID 4 Ethernet tag ID. In EVPN VXLAN scenarios, the

value of this field is the VLAN ID configured
on the access side.

MAC Address Length 1 Length of the MAC address advertised by the

current route.

MAC Address 6 MAC address advertised by the current route.

IP Address Length 1 Length of the IP address advertised by the

current route.

IP Address 0, 4, or 16 IP address (IPv4 or IPv6) advertised by the

current route.

MPLS Label1 3 Layer 2 VNI carried in the route.

MPLS Label2 0 or 3 Layer 3 VNI carried in the route.

IRB advertisement routes are most suitable for Layer 2 + Layer 3 service
scenarios. On the network shown in Figure 3-24, Leaf1 and Leaf2 obtain the
MAC addresses and IP addresses (network segment addresses are not supported)
of their local hosts, generate a MAC/IP route (IRB advertisement route), and
advertise the route to the peer end. After the peer end receives the route, the
peer end initiates VXLAN tunnel establishment if the next hop VTEP address is
reachable. The leaf device then finds the BD based on the Layer 2 VNI and
generates a remote MAC address entry in the EVPN instance bound to the BD. In

39
Technical Benefits and Fundamentals of EVPN
addition, the leaf device finds the corresponding VPN instance based on the
Layer 3 VNI and generates an IP route to the remote host in the VPN instance.
The outbound interfaces in MAC address entries and IP routes recurse to VXLAN
tunnels based on next-hop VTEP addresses.

Figure 3-24 IRB advertisement route learning

40
Technical Benefits and Fundamentals of EVPN
 Chapter 4
Successful Applications of
EVPN

To demonstrate how effective EVPN is, this chapter explores some examples of
real-world applications on live networks.

4.1 Cloud DCN

DCNs — the key infrastructure of Information and Communications Technology
(ICT) — play an important role in the digital transformation of industries. As the
cloud computing business model reaches maturity, various applications and
traditional IT services are being cloudified, and cloud services are becoming a
new driver of revenue. The mainstream trend is now to transform from
traditional DCNs to cloud DCNs. To meet the requirements of cloud DCNs,
Huawei developed its CloudFabric Data Center Network Solution. Figure 4-1
shows the solution architecture.

This solution is mainly comprised of the following components:

 Servers: can be VMs, containers, or Physical Machines (PMs), which are used
to host applications.

41
Successful Applications of EVPN
 Fabric network: is composed of network devices such as switches, firewalls,
and load balancers. It provides network services for servers to communicate
with each other in a data center and to access resources outside the data
center.
 Resource management module: consists of the data center controller
(iMaster NCE), Virtual Machine Manager (VMM), intelligent analysis
platform (iMaster NCE-FabricInsight), and cloud management platform. It
abstracts storage, computing, and network resources in a data center and
manages them in a unified manner.
 Upper-layer applications: are the recipients of network services provided by
CloudFabric. These applications are managed by business departments.
Common Business to Consumer (B2C) services include game and video apps,
and common Business to Business (B2B) services include DCI private line
and Virtual Private Cloud (VPC) services.

EVPN is mainly deployed on the fabric network. EVPN and VXLAN form the core
protocols for the service layer of a fabric network, working together closely to
provide simple, efficient, and reliable transport for various services.

Figure 4-1 Huawei's CloudFabric DCN architecture

42
Successful Applications of EVPN
4.2 Telco Cloud Network
Traditional telecom devices use dedicated hardware, meaning that it usually
takes several months to expand capacity and roll out new services. In addition,
this type of business model relies heavily on device vendors, increasing the costs
of rolling out new services. Carriers therefore want telecom devices to have a
similar level of hardware and software decoupling as that of IT devices. Not only
do carriers want to enhance capabilities and capacities by purchasing universal
hardware, they also want to reduce costs and improve response speed by adding
new functions and rolling out new services through software upgrades. Network
Functions Virtualization (NFV) has been introduced to meet these requirements,
enabling flexible network expansion and service deployment. NFV technologies
have been developed over many years, meaning that related standards and
specifications have become mature. As a result, cloudification of telecom devices
is being adopted by more and more carriers. These factors drive the emergence
of telco cloud networks.

Figure 4-2 shows the overall development trend of carriers' telco clouds.
Generally, carriers establish Central DCs (CDCs) to deploy control-plane NFV
NEs, and establish Regional DCs (RDCs) to deploy data-plane NFV NEs. To meet
constantly increasing service requirements, carriers build more Edge DCs (EDCs)
and mini-EDCs, while also deploying certain service gateways downwards to
edge nodes, thereby providing better user experience.

Figure 4-2 Hierarchical telco cloud deployment

This section describes interconnection between the Wide Area Network (WAN)
and telco cloud DC. In the telco cloud network architecture shown in Figure 4-3,
the WAN and DCN can interconnect in either of the following modes:

Solution 1: Back-to-Back Interconnection Between the WAN and DCN

43
Successful Applications of EVPN
In this solution, traditional L2VPN and L3VPN, as well as EVPN, are deployed at
the service layer of the WAN, but the tunnel layer of the WAN is not unified. On
the DCN, EVPN is deployed at the service layer, and VXLAN is deployed at the
tunnel layer. This solution applies to scenarios where the WAN and DCNs are
managed and maintained separately. Note that an access mode (such as VLAN)
needs to be configured between DC gateways and PEs.

Solution 2: Deployment of SRv6 to DC Gateway on the WAN

In this solution, EVPN is deployed at the service layers of the WAN and DCN for
E2E service deployment and O&M. SRv6 is deployed at the tunnel layer of the
WAN, and VXLAN is deployed at the tunnel layer of the DCN. In this case,
interworking between EVPN SRv6 and EVPN VXLAN needs to be configured on
DC gateways. This solution applies to scenarios where the WAN and DCN are
managed and maintained in a unified manner. EVPN works with SRv6 and
VXLAN to form a DCI network over the WAN between DCs.

Figure 4-3 Overall architecture of the telco cloud network

4.3 All-Service 5G Transport Network

A 5G transport network connects a 5G Radio Access Network (RAN) and core
network. To provide the ultra-high bandwidth, ultra-low latency, and flexible and

44
Successful Applications of EVPN
intelligent connection services necessary in 5G application scenarios, the 5G
transport network uses a new network architecture and key technologies. In
addition, because network evolution cannot be achieved overnight, the 5G
transport network needs to support multiple types of services, such as 4G, 5G,
and private line services. This means that the 5G transport network must support
all-service transport.

Figure 4-4 shows the target architecture of an all-service 5G transport network,

in which EVPN works on the control plane of the service transport layer. On this
plane, E2E SRv6 and EVPN are used to build a seamlessly connected network.
EVPN over SRv6 replaces traditional L2VPN and L3VPN to implement converged
service transport and network protocol simplification.

Figure 4-4 Architecture of the all-service 5G transport network

45
Successful Applications of EVPN
 Chapter 5
Deployment Suggestions for
Evolution to EVPN

EVPN offers numerous advantages over traditional VPNs, but because they are
still widely deployed on live networks, replacing them overnight is unrealistic. To
protect customers' investments on live networks and implement smooth upgrade
without interrupting services, it is recommended to use either of the following
solutions to evolve toward EVPN.

Interworking Solution

As shown in Figure 5-1, this solution applies to scenarios where existing VPN
services are deployed hierarchically. The core idea is as follows: upgrade the
traditional VPN to EVPN on a few key nodes, and allow other nodes to continue
running the traditional VPN. In this case, we need to configure VPN and EVPN
interworking on boundary nodes. As networks and customer services gradually
evolve, other nodes can systematically be upgraded to run EVPN, ultimately
achieving network-wide coverage.

46
Deployment Suggestions for Evolution to EVPN
 Figure 5-1 Interworking solution deployment

Integration Solution

As shown in Figure 5-2, this solution applies to scenarios where existing VPN
services are not deployed hierarchically. The core idea is as follows: deploy EVPN
on desired nodes so that both traditional VPN and EVPN run on these nodes to
transport services. Then, deploy EVPN on other nodes gradually. After EVPN is
deployed on all nodes, traditional VPN can be eliminated.

Figure 5-2 Integration solution deployment

47
Deployment Suggestions for Evolution to EVPN
 Chapter 6
EVPN Application Prospects

IP networks have experienced three eras. The first is the Internet era, in which
IPv4 is the core technology. The second is the all-IP era, in which MPLS is the
core technology. And the third is today's intelligence era featuring Internet of
Everything. In this era, we believe that the core technology is IPv6 Enhanced
Innovation (IPE).

With the rapid development of 5G, Internet of Things (IoT), and cloud services,
people-to-people communication further extends to people-to-thing and thing-
to-thing connections. As the numbers of nodes and connections that the network
needs to support have increased to an unprecedented scale, IPv4 is no longer
viable due to its insufficient address space. And while IPv6 provides a huge
address space that can meet the address allocation requirements of Internet of
Everything, this is just the foundation. Changes in service scenarios and
connection applications pose higher requirements on the IP network. These
requirements include flexibly providing differentiated connection services for
different services and monitoring network conditions in real time for prompt
network adjustment. To meet these requirements, IPE is developed. IPE combines
IPv6 with other technologies to build IPE networks, as shown in Figure 6-1.

48
EVPN Application Prospects
 Figure 6-1 IPE network

The other technologies involved in building IPE networks include:

 In-situ Flow Information Telemetry (IFIT): This technology marks real service
flows on a network to directly measure network performance indicators. IFIT
can significantly improve the timeliness and effectiveness of IPE network
O&M, thereby promoting the development of intelligent O&M.
 SRv6: It is a protocol designed to forward IPv6 data packets on a network
using the source routing model. Simply put, SRv6 is a combination of SR and
IPv6. It reduces the number of required protocol types, offers great
extensibility and programmability, and meets the diversified requirements of
more new services. In the future, it will become the main transport protocol
for unicast services on basic IPv6 networks.
 BIERv6: It is a new multicast technology that encapsulates a set of
destination nodes of multicast packets into the packet header as a bit string.
BIERv6 does not need to explicitly establish a multicast tree or maintain the
state of each multicast stream on intermediate nodes. It can be seamlessly
integrated into an SRv6 network, reducing protocol complexity. In the future,

49
EVPN Application Prospects
 it will become the main transport protocol for multicast services on basic
IPv6 networks.
 EVPN: It serves as the pillar for the overlay layer of an IPE network, just like
SRv6 and BIERv6 serve as pillars for the underlay layer. Currently, EVPN has
unified the control planes of L2VPN and L3VPN unicast services and is
gradually extending to multicast VPN services. In the future, EVPN is
expected to unify the control planes of unicast and multicast services to
further simplify the control protocols of IPE networks.
 Network slicing: This technology provides multiple logical networks —
called network slices — over the same network infrastructure. Each network
slice can flexibly define its logical topology, SLA requirements, reliability, and
security level to meet differentiated requirements of different services,
industries, and users.

EVPN has become an important part to IPE. In the future, it is expected to help
IPE build next-generation IP networks that are intelligent, simplified, automated,
and SLA-guaranteed.

50
EVPN Application Prospects
Contact Us
networkinfo@huawei.com

More IP Network eBooks

https://e.huawei.com/en/topic/enterprise-network/ip-ebook

51
错误!文档中没有指定样式的文字。