Evpn PDF
Evpn PDF
Evpn PDF
Ethernet virtual
private network
(EVPN)
Usman Khan/Tech-Strategy &
Planning/Lahore
+92-321-4915619
3/3/2020
EVPN.
Overview of EVPN:
Definition:
Ethernet virtual private network (EVPN) is used for Layer 2 internetworking. EVPN is similar to
BGP/MPLS IP VPN. Using extended BGP reachability information, EVPN implements MAC
address learning and advertisement between Layer 2 networks at different sites on the control
plane instead of on the data plane.
Purpose:
As services grow rapidly, different sites have an increasingly strong need for Layer 2
interworking. VPLS, which is generally used for such a purpose, has the following shortcomings:
Lack of support for load balancing: VPLS does not support traffic load balancing in multi-
homing networking scenarios.
High network resource usage: Interworking between sites requires all PEs serving these sites
on the ISP backbone network to be fully meshed, with PWs established between any two
PEs. If a large number of PEs exist, PW establishment will consume a significant amount of
network resources. In addition, a large number of ARP messages must be transmitted for
MAC address learning. These ARP messages not only consume network bandwidth but may
also consume CPU resources on remote sites that do no need to learn the MAC addresses
carried in them.
Benefits:
EVPN offers the following benefits:
Improved link usage and transmission efficiency: EVPN supports load balancing, fully utilizing
network resources and reducing network congestion.
Reduced network resource consumption: By deploying RRs on the public network, EVPN
decreases the number of logical connections required between PEs on the public network. In
addition, EVPN enables PEs to use locally stored MAC addresses to respond to ARP Request
messages from connected sites, minimizing the number of broadcast ARP Request messages.
Understanding EVPN:
EVPN Networking:
An EVPN has a similar network structure to a BGP/MPLS IP VPN. In EVPN networking, CEs at
each site connect to PEs on the ISP backbone network. These PEs have EVPN instances
configured and establish BGP EVPN peer relationships and MPLS/SR tunnels with each other.
Unlike a BGP/MPLS IP VPN, an EVPN has its sites on Layer 2 networks. Therefore, the PEs learn
MAC addresses but not IP routes from the CEs, and then advertise the learned MAC addresses
to other sites using EVPN routes.
In EVPN networking, a CE can be single-homed to one PE or multi-homed to several PEs. On the
network shown in Figure 12-1, CE1, CE2, and CE4 use the single-homing mode, whereas CE3
uses the multi-homing mode. Load balancing can be implemented in CE multi-homing
networking.
EVPN defines Ethernet segment identifiers (ESIs) to identify links between PEs and CEs. Links
connecting multiple PEs to the same CE have the same ESI, and links connecting multiple PEs to
different CEs have different ESIs. PEs exchange routes that carry ESIs, so that a PE can discover
other PEs connecting to the same CE as itself.
Ethernet Segment Identifier: a 10-byte field that identifies links between PEs and CEs.
Ethernet Tag ID: The value of this field is all zeros except that it is the same as the local
service ID in an EVPN VPWS scenario or the same as the BD tag value in BD EVPN access in
VLAN-aware mode.
MAC Address Length: a 1-byte field representing the length of the MAC address
advertised by the route.
MAC Address: a 6-byte field representing the MAC address advertised by the route.
IP Address Length: a field representing the mask length of the host IP address advertised
by the route.
IP Address: a field representing the host IP address advertised by the route.
MPLS Label1: a field representing the label used for Layer 2 service traffic forwarding.
MPLS Label2: a field representing the label used for Layer 3 service traffic forwarding.
To implement Layer 2 service interworking between hosts connected to different PEs, the
two PEs need to learn host MAC addresses from each other. The PEs function as BGP
EVPN peers to exchange MAC/IP routes so that they can obtain the host MAC addresses.
The MAC Address Length and MAC Address fields identify the MAC address of a host.
ARP advertisement
A MAC/IP advertisement route can carry both the MAC and IP addresses of a host, and
therefore can be used to advertise ARP entries between PEs. The MAC Address and MAC
Address Length fields identify the MAC address of the host, whereas the IP Address and IP
Address Length fields identify the IP address of the host. This type of MAC/IP route is
called the ARP route.
IP route advertisement
To implement Layer 3 service interworking between IPv4 hosts connected to different
PEs, the two PEs need to learn host IPv4 routes from each other. After a BGP EVPN peer
relationship is established between the PEs, they exchange MAC/IP advertisement routes
to advertise host IPv4 addresses to each other. The IP Address Length and IP Address
fields carried in the MAC/IP advertisement routes indicate the destination addresses of
host IP routes, and the MPLS Label2 field must carry a label used for Layer 3 service traffic
forwarding. In this case, MAC/IP advertisement routes are also called Integrate Routing
and Bridge (IRB) routes.
NOTE:
An ARP route carries host MAC and IP addresses and a Layer 2 VNI. An IRB route carries
host MAC and IP addresses, a Layer 2 VNI, and a Layer 3 VNI. Therefore, IRB routes carry
ARP routes and can be used to advertise IP routes as well as ARP entries.
Host ND information advertisement
A MAC/IP advertisement route can carry both the MAC and IPv6 addresses of a host, and
therefore can be used to advertise ND entries between PEs. The MAC Address and MAC
Address Length fields identify the MAC address of the host, whereas the IPv6 Address and
IPv6 Address Length fields identify the IPv6 address of the host. This type of MAC/IP route
is called the ND route.
IPv6 route advertisement
To implement Layer 3 service interworking between IPv6 hosts connected to different
PEs, the two PEs need to learn host IPv6 routes from each other. After a BGP EVPN peer
relationship is established between the PEs, they exchange MAC/IP advertisement routes
to advertise host IPv4 addresses to each other. The IP Address Length and IP Address
fields carried in the MAC/IP advertisement routes indicate the destination addresses of
host IPv6 routes, and the MPLS Label2 field must carry a label used for Layer 3 service
traffic forwarding. In this case, MAC/IP advertisement routes are also called IRBv6 routes.
Ethernet Tag ID: The value of this field is all zeros except that it is the same as the local
service ID in an EVPN VPWS scenario or the same as the BD tag value in BD EVPN access in
VLAN-aware mode.
IP Address Length: a 1-byte field representing the length of the source IP address
configured on the local PE.
Originating Router's IP Address: a 4-byte or 16-byte field representing the source IP
address configured on the local PE.
Ethernet segment route: carries the EVPN instance RD and ESI information and source IP
address on the local PE. PEs connecting to the same CE use Ethernet segment routes to
discover each other. This type of route is used in Designated forwarder election. Figure 12-
5 shows the format of an EVPN NLRI specific to the Ethernet segment route.
Figure 12-5 EVPN NLRI specific to the Ethernet segment route
Ethernet Segment Identifier: a 10-byte field that identifies links between PEs and CEs.
Ethernet Tag ID: Currently, each bit of the field value must be 0.
IP Prefix Length: IP prefix mask length carried in the route.
IP Prefix: IP prefix address carried in the route.
GW IP Address: default gateway address.
MPLS Label: a field representing the label used for Layer 3 service traffic forwarding.
NOTE:
In the case where a CE is dual-homed to two PEs, an EVPN ESI label will be encapsulated into
the BUM packets exchanged between the two PEs to prevent loops.
1. The PEs establish BGP EVPN peer relationships with each other and then
exchange Ethernet segment routes.
An Ethernet segment may have multiple VLANs configured. In this case, the smallest
VLAN ID is used as the V value.
Split Horizon:
On the network shown in Figure 12-11, CE1 is dual-homed to PE1 and PE2 and has load
balancing enabled. If PE1 and PE2 have established a BGP EVPN peer relationship with each
other, after PE1 receives BUM traffic from CE1, PE1 forwards the BUM traffic to PE2. If PE2
forwards BUM traffic to CE1, a loop will occur. To prevent this problem, EVPN uses split
horizon. After PE1 forwards the BUM traffic to PE2, PE2 checks the EVPN ESI label carried in
the traffic. If the ESI carried in the label equals the ESI for the link between PE2 and CE1, PE2
does not forward the traffic to CE1, preventing a loop.
If PE1 and PE2 are both configured to work in All-Active mode, after PE1 and PE2
send Ethernet auto-discovery route carrying the redundancy mode to PE3, PE3 sends
unicast traffic destined for CE1 to both PE1 and PE2 in load balancing mode.
If either PE1 or PE2 or both PE1 and PE2 are configured to work in Single-Active mode,
after PE1 and PE2 send Ethernet auto-discovery route carrying the redundancy mode to
PE3, PE3 uses the optimal received route as the primary route and the second optimal
received route as the backup route to implement FRR.
EVPN also supports aliasing, which is the ability of a PE to signal that it has reachability to an
EVPN instance on a given Ethernet segment even when it has learned no MAC addresses
from that Ethernet segment. In the case where a CE is multi-homed to several PEs, it is
possible that only a single PE learns a set of the MAC addresses associated with traffic
transmitted by the CE. Aliasing enables remote PEs to learn the reachability of CE-side MAC
addresses based on the ESIs carried in Ethernet auto-discovery route received from multi-
homing PEs. On the network shown in Figure 12-12, only PE1 sends MAC/IP advertisement
routes that carry CE-side MAC addresses to PE3, but PE3 can learn from Ethernet auto-
discovery route that PE2 is also reachable to CE1. As a result, PE3 load-balances traffic
destined for CE1 between PE1 and PE2.
Background:
The use of MPLS networks increases requirements for service scalability of network
architecture. Different MANs of a service provider or collaborative backbone networks of
different service providers often span multiple ASs.
Implementation:
Through seamless MPLS networking, all services (support inter-AS Option C) are signaled to an
LSP only by access nodes, and all network-side faults are rectified using the same transport
layer convergence technology, which does not affect service transmission.
Usage Scenario:
Network Description
Deployment
Forwarding plane 1. The CSG pushes a BGP LSP label and an MPLS tunnel label in
sequence into each EVPN packet and forwards the packets to
the AGG.
2. Upon receipt, the AGG removes the access-layer MPLS tunnel
labels from the packets and swaps the existing BGP LSP labels
for new labels. The AGG then pushes an aggregation-layer MPLS
tunnel label into each packet and proceeds to forward the
packets to the core ABR. If the penultimate hop popping (PHP)
Network Description
Deployment
1. The CSG pushes a BGP LSP label and an MPLS tunnel label in
sequence into each EVPN packet and forwards the packets to
the AGG.
2. Upon receipt, the AGG removes the access-layer MPLS tunnel
Forwarding plane labels from the packets and swaps the existing BGP LSP labels for
new labels. The AGG then pushes an aggregation-layer MPLS
tunnel label into each packet and proceeds to forward the
packets to the AGG ASBR. If the PHP function is enabled on the
AGG, the CSG has removed the MPLS tunnel labels from the
packets, and therefore, the AGG receives packets without MPLS
tunnel labels.
3. Upon receipt, the AGG ASBR removes the MPLS tunnel labels
from the EVPN packets and swaps the existing BGP LSP label for
a new label in each packet. It then forwards the packets to the
core ASBR. If the PHP function is enabled on the AGG ASBR, the
AGG has removed the MPLS tunnel labels from the packets, and
Reliability:
Seamless MPLS network reliability can be improved using various functions. If a network fault
occurs, a device immediately detects the fault and switch traffic to a standby link.
The following examples demonstrate reliability functions on an inter-AS seamless MPLS
network.
A fault occurs on a link between a CSG and an AGG.
On the inter-AS seamless MPLS network shown in Figure 12-21, the active link along the
primary path between CSG1 and AGG1 fails. After BFD for LDP LSP or BFD for CR-LSP detects
the fault, the BFD module uses LDP FRR, TE hot-standby, or BGP FRR to switch traffic from
the primary path to the backup path.
Figure 12-21 Traffic protection triggered by a fault on the link between the CSG and AGG
on the inter-AS seamless MPLS network
Figure 12-23 Traffic protection triggered by a fault on the link between an AGG and an
AGG ASBR on the inter-AS seamless MPLS network
A fault occurs on the link between an AGG ASBR and a core ASBR.
On the inter-AS seamless MPLS network shown in Figure 12-25, BFD for interface is
configured on AGG ASBR1 and core ASBR1. If the BFD module detects a fault on the link
between AGG ASBR1 and core ASBR1, the BFD module triggers BGP Auto FRR. BGP auto FRR
switches both upstream and downstream traffic from the primary path to backup paths.
Figure 12-25 Traffic protection triggered by a fault on the link between an AGG ASBR and a
core ASBR on the inter-AS seamless MPLS network
Figure 12-26 Traffic protection triggered by a fault on a core ASBR on the inter-AS seamless
MPLS network
Figure 12-27 Traffic protection from a link fault in a core area on the inter-AS seamless
MPLS network
Figure 12-28 Traffic protection triggered by a fault on an MASG on the inter-AS seamless
MPLS network
Port-based
VLAN-based
VLAN bundle
VLAN-aware bundle
Port-based Mode:
In port-based mode, an interface is used to access a user service. Specifically, the physical
interface connected to a user network is directly bound to a common EVI (neither an EVI in BD
mode nor an EVI in VPWS mode) and has no sub-interfaces created. This service mode is used
only to carry Layer 2 services.
On the network shown in Figure 12-30, in VLAN-based mode, the physical interfaces connected
to user networks each have different sub-interfaces created. Each sub-interface is associated
with a unique VLAN and added to a specific bridge domain (BD). Each BD is bound to a specific
EVI. In this service mode, the sub-interface, VLAN, BD, and EVI are exclusive for a user to access
a network, and a separate MAC forwarding table is used on the forwarding plane for each user.
Therefore, this mode effectively ensures service isolation. However, an EVI is required per user,
consuming numerous EVI resources. This service mode is used to carry Layer 2 or Layer 3
services.
Figure 12-30 VLAN-based mode
VLAN Bundle:
On the network shown in Figure 12-31, in VLAN bundle mode, an EVI connects to multiple
users, who are divided by VLAN, and the EVI is bound to a BD. In this service mode, the users
connected to the same EVI share a MAC forwarding table, requiring each user on the network
to have a unique MAC address. This service mode is used to carry Layer 2 or Layer 3 services.
NOTE:
In a VLAN bundle scenario, only termination EVC sub-interfaces support both Layer 2 and Layer
3 interfaces. Non-termination EVC sub-interfaces support only Layer 2 services.
On the network shown in Figure 12-32, in VLAN-aware bundle mode, an EVI connects to
multiple users, who are divided by VLAN. Additionally, the EVI can be bound to multiple BDs, in
which case, the EVI must have different BD tags configured. When EVPN peers send routes to
each other, a BD tag is encapsulated into the Ethernet Tag ID field of an Ethernet auto-
discovery route, MAC/IP advertisement route, and inclusive multicast route. In this service
mode, users connected to the same EVI use separate forwarding entries. During traffic
forwarding, the system uses the BD tag carried in user packets to locate the corresponding MAC
forwarding table and searches the table for a forwarding entry based on a MAC address.
Unlike the other service mode, in VLAN-aware bundle mode, load balancing, designated
forwarder (DF), host migration, and route re-origination are implemented based on a BD:
Load balancing: In VLAN-aware bundle mode, load balancing can be implemented only if a
MAC/IP advertisement route and Ethernet auto-discovery route have the same Ethernet
segment identifier (ESI) and the same BD tag. If the BD tags are inconsistent, the routes
belong to different BDs, preventing load balancing from being implemented.
DF election:
For interface-based DF election, the system chooses the first interface to go Up in a BD
for DF election.
During DF election after an AC interface is enabled to influence DF election, a PE cannot
participate in DF election if the system does not receive the Ethernet auto-discovery
route advertised by the PE. If the VLAN-aware bundle mode is enabled in this scenario, an
Ethernet auto-discovery route is generated for each BD tag. The PE can participate in DF
election only if the system receives Ethernet auto-discovery routes in all BDs bound to a
specified EVI.
Host migration: When the system generates a local MAC/IP advertisement route, the system
checks whether it has received a MAC/IP advertisement route from the remote end. If the
system has received such a route, the MAC address transfer attribute is added to the locally
generated route, or the value of the sequence field in the MAC address transfer attribute is
EVPN – VXLAN:
EVPN VXLAN Fundamentals:
Introduction:
Ethernet virtual private network (EVPN) is a VPN technology used for Layer 2 internetworking.
EVPN is similar to BGP/MPLS IP VPN. EVPN defines a new type of BGP network layer
reachability information (NLRI), called the EVPN NLRI. The EVPN NLRI defines new BGP EVPN
routes to implement MAC address learning and advertisement between Layer 2 networks at
different sites.
VXLAN does not provide the control plane, and VTEP discovery and MAC addresses learning are
implemented by traffic flooding on the data plane, resulting in high traffic volumes on DC
networks. To address this problem, VXLAN uses EVPN as the control plane. EVPN allows VTEPs
to exchange BGP EVPN routes to implement automatic VTEP discovery and host information
advertisement, preventing unnecessary traffic flooding.
EVPN uses extended BGP and defines new BGP EVPN routes to transmit VTEP addresses and
host information. As such, the application of EVPN on VXLANs moves VTEP discovery and host
information learning from the data plane to the control plane.
EVPN NLRI defines the following BGP EVPN route types applicable to the VXLAN control plane:
Type 2 route—MAC/IP route:
Figure 12-33 shows the format of MAC/IP routes.
Field Description
Ethernet Segment Identifier Unique ID for defining the connection between local and
remote devices
MAC Address Length Length of the host MAC address carried in the route
IP Address Length Mask length of the host IP address carried in the route
An ARP route carries host MAC and IP addresses and a Layer 2 VNI. An IRB route carries host
MAC and IP addresses, a Layer 2 VNI, and a Layer 3 VNI. Therefore, IRB routes carry ARP
routes and can be used to advertise IP routes as well as ARP entries.
Host IPv6 route advertisement
In a distributed gateway scenario, to implement Layer 3 communication between hosts on
different subnets, the VTEPs (functioning as Layer 3 gateways) must learn host IPv6 routes
from each other. To achieve this, VTEPs as EVPN peers exchange MAC/IP routes to advertise
host IPv6 routes to each other. The IP Address Length and IP Address fields carried in the
MAC/IP routes indicate the destination addresses of host IPv6 routes, and the MPLS
Label2 field must carry a Layer 3 VNI. MAC/IP routes in this case are also called IRBv6 routes.
NOTE:
An ND route carries the following valid information: host MAC address, host IPv6 address,
and Layer 2 VNI. An IRBv6 route carries the following valid information: host MAC address,
host IPv6 address, Layer 2 VNI, and Layer 3 VNI. It can be seen that an IRBv6 route includes
Field Description
IP Address Length Mask length of the local VTEP's IP address carried in the route
Field Description
Ethernet Segment Identifier Unique ID for defining the connection between local and
remote devices
EVPN – VPWS:
EVPN VPWS Fundamentals:
Overview:
Ethernet virtual private network (EVPN) virtual private wire service (VPWS) provides a P2P
L2VPN service solution based on the EVPN service architecture. This solution simplifies the
EVPN technology by using MPLS tunnels over a backbone network to provide Layer 2 packet
forwarding between access circuits (ACs) with no need of searching for MAC address entries.
On the basis of BGP, EVPN defines a new type of network layer reachability information (NLRI),
which is called EVPN NLRI. EVPN VPWS supports the following types of EVPN NLRIs:
Ethernet Auto-Discovery (Ethernet AD) routes: include Ethernet Auto-Discovery Per EVI
routes and Ethernet Auto-Discovery Per ES routes.
Ethernet Auto-Discovery Per ES routes: are sent by PEs on an EVPN VPWS network to
notify the peer device of whether the local redundancy mode is single-active or all-active.
o RD: can be either the RD value of an EVPN instance or a combination of the source IP
address configured on a PE and :0, such as X.X.X.X:0.
o Ethernet Segment Identifier: uniquely identifies a connection between a PE and a CE.
o Ethernet Tag ID: indicates the local service ID of the EVPL instance on the local PE.
o MPLS Label: indicates the EVPL label assigned for each EVI Ethernet Auto-Discovery
route.
In addition to NLRI, an EVI Ethernet Auto-Discovery route carries the Layer 2 extended
community attribute that includes the following control fields:
o C: identifies a control word. If this control field is set to 1, packets sent by the local PE
must carry control information.
o P: is used to identify whether the local PE is the master PE. In all-active scenarios, this
control field must be set to 1.
o B: is used to identify whether the local PE is the backup PE in dual-homing single-active
scenarios.
Ethernet Segment (ES) route: An ES route carries the RD, Ethernet segment identifier (ESI)
value, and source IP address of the local PE to allow automatic discovery and DF election
between PEs connecting to the same CE. Figure 12-38 shows the NLRI format of ES routes.
Route Distinguisher: is a combination of the source IP address on the local PE and :0, such
as X.X.X.X:0.
Ethernet Segment Identifier: uniquely identifies a connection between a PE and a CE.
IP Address Length: indicates the length of the source IP address configured on the local
PE.
Originating Router's IP Address: indicates the source IP address configured on the local
PE.
Figure 12-36 shows the packet exchange process in EVPN VPWS single-homing scenarios.
1. PE1 and PE2 are each configured with an EVPL instance and an EVPN VPWS instance. The
EVPL instance must be bound to an AC interface and an EVPN VPWS instance, and each
EVPL instance must be configured with a local service ID and a remote service ID. After the
configuration, the local PE generates the forwarding entries indicating the association
between the AC interface and EVPL instance.
2. PE1 and PE2 each send EVI Ethernet AD routes to the peer device. The EVI Ethernet AD
routes carry the RD, RT, next-hop information, local service ID, and EVPL label.
3. PE1 and PE2 each receive EVI Ethernet AD routes from the peer device and match the RTs
of the corresponding EVPN VPWS instance. PE1 and PE1 then select an MPLS or SRv4 tunnel
to perform traffic recursion based on the next-hop information. If the service ID in the
received routes is the same as the remote service ID configured for the local EVPL instance,
the forwarding entries indicating the association between the MPLS or SR tunnel and local
EVPL instance are generated.
On the CE dual-homing network shown in Figure 12-39, PE1 and PE2 work in single-active mode
and an E-Trunk is deployed between them. In this case, DF election is not triggered, and the
1. Each PE is configured with an EVPL instance and an EVPN VPWS instance. The EVPL instance
must be bound to an AC interface and an EVPN VPWS instance, and each EVPL instance
must be configured with a local service ID and a remote service ID. After the configuration,
the local PE generates the forwarding entries indicating the association between the AC
interface and EVPL instance. The access-side interfaces on PE1 and PE2 must be configured
with the same ESI.
2. PE1 and PE2 send ES routes that carry the RD, RT, ESI, and source IP address. DF election is
not triggered between PE1 and PE2 upon receipt of ES routes. The master/backup
relationship between PE1 and PE2 are determined based on the E-Trunk deployed between
them. In this example, PE1 is the master PE, and PE2 is the backup PE.
3. PE1 and PE2 send PE3 the ES Ethernet AD routes that carry the RD, RT, next-hop
information, and single-active mode information.
4. The PEs send each other the EVI Ethernet AD routes that carry the RD, RT, next-hop
information, local service ID, EVPL label, and master/backup role.
5. Upon receipt of EVI Ethernet AD routes from PE3, PE1 and PE2 match RTs of the
corresponding EVPN VPWS instance and select an MPLS or SRv4 tunnel to perform traffic
recursion based on the next-hop information. If the service ID in the received routes is the
same as the remote service ID configured for the local EVPL instance, the forwarding
entries indicating the association between the MPLS or SR tunnel and local EVPL instance
are generated.
6. Upon receipt of EVI Ethernet AD routes from PE1 and PE2, PE3 matches RTs of the
corresponding EVPN VPWS instance and select an MPLS or SRv4 tunnel to perform traffic
recursion based on the next-hop information. If the service ID in the received routes is the
same as the remote service ID configured for the local EVPL instance, the FRR entries
indicating the association between the MPLS or SR tunnel and local EVPL instance are
generated. The entries destined for PE1 are the master entries, and the entries destined for
PE2 are the backup entries.
7. PE1 and PE2 each receive EVI Ethernet AD routes from the peer device and match the RTs
of the corresponding EVPN VPWS instance. PE1 and PE1 then select an MPLS or SRv4 tunnel
to perform traffic recursion based on the next-hop information. If the service ID in the
received routes is the same as the remote service ID configured for the local EVPL instance,
the bypass entries indicating the association between the MPLS or SR tunnel and local EVPL
instance are generated.
On the CE dual-homing network shown in Figure 12-40, PE1 and PE2 work in single-active mode
and an E-Trunk is not deployed between them. The packet exchange process in this scenario is
similar to that in the scenario with an E-Trunk deployed. The only difference is that the
master/backup relationship between PE1 and PE2 in this scenario is determined by the DF
election mechanism of EVPN VPWS.
Figure 12-40 EVPN VPWS dual-homing single-active networking (with no E-Trunk deployed)
By default, the PE with a smaller source IP address is elected as the master DF. This, however,
causes all service traffic to travel through the same PE, which may lead to unbalanced network
load. To address this problem, enable the service ID-based DF election. Taking Figure 12-41 as
an example, the service ID-based DF election process is as follows:
1. PE1 and PE2 send each other the ES routes that carry the RD, RT, ESI, and source IP address.
2. Upon receipt of ES routes, PE1 and PE2 construct PE lists based on different ESIs. The PEs in
a PE list are ordered by the source IP address in ascending order, and the system assigns an
index starting at 0 to each PE in ascending order.
The DF election result determines the P control field in EVI Ethernet AD routes.
On the CE dual-homing network shown in Figure 12-42, PE1 and PE2 work in all-active mode.
The packet exchange process in this scenario is as follows:
1. Each PE is configured with an EVPL instance and an EVPN VPWS instance. The EVPL instance
must be bound to an AC interface and an EVPN VPWS instance, and each EVPL instance
must be configured with a local service ID and a remote service ID. After the configuration,
the local PE generates the forwarding entries indicating the association between the AC
interface and EVPL instance. PE1 and PE2 are configured to work in all-active mode and the
access-side interfaces of PE1 and PEs are configured with the same ESI.
The data packets sent from AC-side interfaces are forwarded to the peer PE over the
corresponding MPLS tunnel based on the forwarding entries indicating the association between
tunnels and EVPL instances. Upon receipt of packets, the peer PE searches for the association
PBB – EVPN:
PBB-EVPN Fundamentals:
PBB-EVPN Networking:
PBB: a technique defined in IEEE 802.1ah. PBB precedes C-MAC addresses with B-MAC
addresses in a packet to completely separate the user network from the carrier network.
This implementation enhances network stability and eases the pressure on the capacity of
PEs' MAC forwarding tables.
I-EVPN: accesses the user network by being bound to a PE interface connecting to a CE. After
an I-EVPN instance receives a data packet from the user network, the I-EVPN instance
encapsulates a PBB header into the packet.
B-EVPN: accesses the backbone network. A B-EVPN instance manages EVPN routes received
from other PEs.
I-SID: uniquely identifies a broadcast domain. One I-EVPN instance corresponds to one I-SID.
If two PEs share the same I-SID, the two PEs belong to the same BUM group.
PBB-EVPN Routes:
MAC advertisement route: carries B-EVPN instance RD, B-MAC address, and VPN label
information on the local PE. Figure 12-44 shows the prefix format of a MAC advertisement
route packet. A PE uses MAC advertisement routes to advertise B-MAC address reachability
information to other PEs. When network topology changes due to a CE node failure or CE-PE
link failure, the corresponding PE sends MAC advertisement routes to instruct other PEs to
refresh C-MAC addresses corresponding to the specified B-MAC address, thereby
achieving fast convergence.
Figure 12-44 Prefix format of a MAC advertisement route packet
Other Concepts:
Fast convergence:
On the network shown in Figure 12-47, if the link between CE1 and PE1 fails, PE1 will send
a MAC advertisement route that carries the MAC mobility extended community attribute to
PE3, notifying PE3 that C-MAC addresses at Site1 are unreachable. Upon receipt of the route,
PE3 sends traffic to Site1 only through PE2, implementing fast convergence.
Figure 12-47 Fast convergence networking
1. The PEs establish EVPN BGP peer relationships with each other and then
exchange Ethernet segment routes.
2. Upon receipt of the Ethernet segment routes, each PE generates a multi-homing PE list
based on the ESIs carried in Ethernet segment routes. Each multi-homing PE list contains
information about all PEs connecting to the same CE.
3. Each PE then sequences the PEs in each multi-homing PE list based on the source IP
addresses carried in Ethernet segment routes. The PEs are numbered from 0.
4. The primary DF is elected based on I-SIDs. Specifically, PBB-EVPN uses the formula of "I-
SID modulo Number of PEs in the PE list corresponding to the I-SID" to calculate a
number and then elects the PE with the same number as the calculated one as the
primary DF.
Figure 12-48 DF election networking
Split horizon:
On the network shown in Figure 12-49, CE1 is dual-homed to PE1 and PE2. If PE1 and PE2
have established an EVPN BGP peer relationship with each other, after PE1 receives BUM
traffic from CE1, it forwards the BUM traffic to PE2. If PE2 forwards BUM traffic to CE1, a
loop will occur. To prevent this problem, EVPN uses split horizon. After PE1 forwards the
BUM traffic to PE2, PE2 checks the B-SMAC address carried in the traffic. If the B-SMAC
Redundancy mode:
If a CE is multi-homed to several PEs, a redundancy mode can be configured to specify the
redundancy mode of PEs connecting to the same CE. The redundancy mode determines
whether load balancing is implemented for unicast traffic in CE multi-homing scenarios. On
the network shown in Figure 12-50, if PE1 and PE2 are both configured to work in All-Active
mode, after PE1 and PE2 send Ethernet segment routes carrying the redundancy mode
information to PE3, PE3 sends unicast traffic destined for CE1 to both PE1 and PE2 in load
balancing mode.
Figure 12-50 Redundancy mode networking
On the network shown in Figure 12-51, unicast MAC addresses are advertised as follows:
1. Site1 sends an ARP request or gratuitous packet that carries Site1's C-MAC address C-MAC
A and the corresponding IP address to Site2.
2. Upon receipt of the packet, Site2 returns an ARP reply or gratuitous packet that carries
Site2's C-MAC address C-MAC B and the corresponding IP address to Site1.
3. PE1 and PE2 exchange MAC advertisement routes that carry B-MAC addresses, next hops,
and EVPN instance extended community attributes (such as RTs).
4. PE1 and PE2 construct B-EVPN instance forwarding entries based on the RTs carried in
received MAC advertisement routes.
Figure 12-51 Unicast MAC address advertisement networking
After two PEs establish an EVPN BGP peer relationship, they exchange inclusive multicast
routes. PEs then form redundancy groups based on I-SIDs carried in received inclusive multicast
routes, with PEs having the same I-SID belonging to the same redundancy group. On the
network shown in Figure 12-52, BUM packets are transmitted as follows:
NOTE:
Use the network shown in Figure 12-50 as an example. If PE1 and PE2 both work in Single-
Active mode, the bidirectional BUM traffic between CE2 and CE1 will be dropped by the backup
DF. If PE1 and PE2 both work in All-Active mode, only the BUM traffic from CE2 to CE1 will be
dropped by the backup DF.
Figure 12-52 BUM packet transmission networking
On the network shown in Figure 12-53, unicast packets are transmitted as follows:
1. CE1 forwards unicast packets that carry the source C-MAC (C-SMAC) and destination C-
MAC (C-DMAC) addresses to PE1 at Layer 2.
2. Upon receipt of the packets, the I-EVPN instance on PE1 searches its C-MAC address table
for a matching forwarding entry. After finding such an entry, PE1 encapsulates a PBB
header, a tunnel label, and a VPN label into these packets and forwards these packets to
PE2. The PBB header carries the I-SID and B-SMAC address configured in the I-EVPN
instance and the B-DMAC address obtained from the C-DMAC address table.
EVPN E-Tree:
As the number of services carried on an EVPN increases, the number of user MAC addresses
managed by the EVPN is also going Up. The user MAC addresses are flooded on the network
through EVPN routes. As a result, all interfaces in the same broadcast domain can communicate
with each other at Layer 2. However, broadcast, unknown unicast, multicast (BUM), and unicast
traffic cannot be isolated for users who do not need to communicate with each other. To
isolate interfaces that do not need to communicate with each other in the same broadcast
domain, you can deploy the EVPN E-Tree function on the network.
A leaf AC interface and a root AC interface can send traffic to each other. However, flows
between leaf AC interfaces are isolated from each other.
A root AC interface can communicate with other root AC interfaces and with leaf AC
interfaces.
To implement the preceding functions, an E-Tree extended community attribute is defined in a
standard protocol. Figure 12-54 shows the packet format of this attribute. The packet format
includes the Leaf Label field and the Flags field. The Flags field contains eight bits, in which the
first seven are all zeros and the last identifies whether an EVPN MAC route is from a leaf AC
interface. If the MAC route comes from this interface, the value is set to 1. The extended
community attribute can be advertised through Ethernet auto-discovery (A-D) per ES routes
and MAC routes on an EVPN, so that known unicast traffic and BUM traffic on leaf AC interfaces
are isolated from each other.
Figure 12-54 Packet format of the extended community attribute used by EVPN E-Tree
Take the network shown in Figure 12-55 as an example. Known unicast traffic is isolated
through the following process:
1. PE1 and PE2 transmit AC-side MAC addresses to each other through MAC routes. Take the
MAC address (MAC1) of the AC interface on CE2 as an example. Because the AC interface
has the leaf attribute, a MAC route carrying the MAC1 address also carries the extended
community attribute of EVPN E-Tree. All bits in the Leaf Label field of the attribute are set
to 0, and the L bit in the Flags field is set to 1. PE1 then sends this MAC route to PE2.
2. Upon receipt, PE2 checks the L bit in the Flags field. Because this bit is set to 1, PE2 marks
the entry corresponding to MAC1 in the local MAC routing table.
3. When PE2 receives traffic destined for CE2 from its own leaf AC interface, PE2 determines
that the traffic needs to be sent to the remote leaf AC interface based on the flag in the
local MAC routing table and discards the traffic. In this way, known unicast traffic is isolated
between leaf AC interfaces.
In the preceding example, BUM traffic is isolated through the following process:
1. After EVPN E-Tree is configured on the network, PE1 and PE2 send a special Ethernet A-D
per ES route to each other. A regular Ethernet A-D per ES route carries the ESI attribute.
NOTE:
EVPN E-Tree supports the following types of AC interfaces: main interfaces bound to common
EVPN instances, EVC Layer 2 sub-interfaces associated with BDs, and VLAN sub-interfaces.
In a CE dual-homing scenario, ensure that the same root or leaf attribute is set for the same
VLAN sub-interface in the same broadcast domain on two PEs. If the leaf attribute is set on both
PEs, the Leaf label can replace the ESI label to implement split horizon.
Different root or leaf attributes can be set for a PE's interfaces or sub-interfaces that connect to
different CEs.
On the network shown in Figure 12-56, EVPN runs between PE1 and PE2. CE1 and CE2 access
PE1 and PE2 respectively in one of the following ways: VLAN, QinQ, static or dynamic PW, or
static VXLAN. PE1 and PE2 can communicate with each other both through network-side and
access-side links, which induces a BUM traffic loop:
1. After PE1 receives BUM traffic from CE1, PE1 first replicates it, and then forwards it to both
the network-side and access-side links (traffic 1 in Figure 12-56).
On the network shown in Figure 12-57, in addition to a BUM traffic loop, route flapping also
occurs:
1. After PE1 receives BUM traffic from CE1, PE1 learns CE1's MAC address (M1) from the
source MAC address of the traffic. PE1 sends a MAC route with a destination address of M1
to PE2 by means of EVPN.
2. Upon receipt, PE2 matches the RT of the MAC route, imports the MAC route into a
matching EVPN instance, generates a MAC entry, and iterates the MAC route to the
network-side VXLAN or MPLS tunnel to PE1.
3. PE2 can also receive BUM traffic from PE1 through the direct access-side link between
them. Upon receipt, PE2 also generates a MAC route to M1 based on the source MAC
address of the traffic. In this case, PE2 considers M1 to have moved to its own access
network. PE2 preferentially selects the MAC address received from the local access side.
After black-hole MAC routing has been configured, the system sets the suppressed MAC
routes to black-hole routes. If a PE receives traffic with the same source or destination MAC
address as the MAC address of a black-hole MAC route, the PE discards the traffic.
If AC interface blocking is also configured, that is, if the traffic comes from a local AC
interface and the source MAC address of the traffic is the same as the MAC address of a
black-hole MAC route, the AC interface is blocked. In this way, a loop can be removed
quickly. Only BD-EVPN instances support AC interface blocking.
Implementation:
After EVPN ORF is configured, each PE on the EVPN sends the import VPN target (IRT) and
original AS number of the local EVPN instance to the other PEs or BGP EVPN RRs that function
as BGP-EVPN peers. The information is sent through ORF routes. Upon receipt, the peers
construct export route policies based on these routes so that the local PE only receives the
expected routes, which reduces the receiving pressure on the local PE.
Figure 12-58 shows the basic EVPN ORF network on which each device supports EVPN ORF. PE1,
PE2, and PE3 establish BGP-EVPN peer relationships with the RR, and are also clients of the RR.
An EVPN instance with a specific RT is configured on each PE.
In addition to configuring an L3VPN instance, you can also configure the RR to advertise default
ORF routes to PE1 and PE3 and delete the BGP-VT peer relationship between the RR and PE3.
After the configuration is complete, PE1, PE2, and PE3 advertise all routes to the RR. The RR
then advertises routes with ERTs of 1:1 and 2:2 to PE1, routes with an ERT of 1:1 to PE2, and all
routes to PE3.
If both EVPN and L3VPN services are deployed on the network in Figure 12-58, the preceding
two ways cannot be used. If you use either of them, the L3VPN service cannot run properly. On
the network shown in Figure 12-59, only PE3 does not support EVPN ORF. After EVPN ORF is
enabled on the network, the EVPN service cannot run properly. If an L3VPN instance is created,
the new L3VPN instance receives the other PEs' L3VPN routes from the RR, which compromises
the L3VPN service. To resolve this issue, you can disable the RR from filtering routes based on
the IRT for PE3, thereby ensuring that both EVPN and L3VPN services can run properly.
Benefits
Bandwidth consumption is lowered (because the number of routes being advertised is
smaller).
System resources such as CPU and memory are saved.
SMET route
SMET routes are used to transmit multicast group information between BGP EVPN peers. A
device that receives an SMET route can construct local (*, G) or (S, G) entries based on the
routing information. As shown in Figure 12-60, the fields in the routing information are
described as follows:
1. PE1, PE2, and PE3 periodically send IGMP Query messages to the access side in BD1.
2. Receiver A and Receiver B send IGMP Report messages to CE2 and CE3, respectively. For
example, Receiver A sends an IGMPv3 (S, G) Report message, and Receiver B sends an
IGMPv2 (*, G) Report message.
3. After receiving the corresponding IGMP Report messages, PE2 and PE3 establish (S, G) and
(*, G) entries of IGMP snooping in BD1 and add the interfaces connected to CE2 and CE3 as
outbound interfaces, respectively.
4. PE2 sends a BGP EVPN SMET route to other PEs through BGP EVPN peer relationships. The
route carries (S, G) entries, and the Flags field in the route is set to IGMPv3 and Include.
5. PE3 sends a BGP EVPN SMET route to other PEs through BGP EVPN peer relationships. The
route carries (*, G) entries, and the Flags field in the route is set to IGMPv2.
6. After receiving the corresponding BGP EVPN SMET routes, PE1 establishes (S, G) and (*, G)
entries of IGMP snooping in BD1 and adds the mLDP tunnel interfaces of the corresponding
EVPN instances as outbound interfaces.
7. PE1 sends IGMPv3 (S, G) Report and IGMPv2 (*, G) Report messages to CE1. CE1 establishes
IGMP and PIM entries and forwards multicast traffic to PE1.
8. After receiving the multicast traffic, PE1 forwards the traffic to PE2 and PE3 through the
mLDP tunnel interfaces based on the (S, G) and (*, G) entries in BD1.
9. After receiving the multicast traffic, PE2 and PE3 forward the traffic to Receiver A and
Receiver B based on the (S, G) and (*, G) entries, respectively.
Dual-homing access for IGMP snooping over EVPN MPLS on the multicast source side:
Figure 12-64 shows dual-homing access for IGMP snooping over EVPN MPLS on the multicast
source side. Configure an EVPN instance on PE1, PE2, PE3, and PE4, and bind a BD to the EVPN
instance. Establish BGP EVPN peer relationships between the PEs, and deploy EVPN IGMP proxy
on each PE. Deploy PE1 and PE2 as sender PEs, and deploy PE3 and PE4 as receiver PEs.
Connect BD1 on PE3 and PE4 to CE3 and CE4 through VLAN dot1q sub-interfaces, respectively.
Connect CE1 to PE1 and PE2 through Eth-Trunk interfaces, and configure PIM-SM and IGMP on
the interfaces. Bind the Eth-Trunk interfaces of CE1 to an E-Trunk on PE1 and PE2. Configure
static router interfaces, and set the same ESI. Configure the E-Trunk to work in dual-active
mode, and ensure that the Eth-Trunk interfaces on PE1 and PE2 are both Up.
The process of IGMP snooping over EVPN MPLS (dual-homing access on the multicast source
side) is described as follows:
1. PE3 and PE4 periodically send IGMP Query messages to the access side in BD1.
2. Receiver A and Receiver B send IGMP Report messages to CE2 and CE3, respectively. For
example, Receiver A sends an IGMPv3 (S, G) Report message, and Receiver B sends an
IGMPv2 (*, G) Report message.
3. After receiving the corresponding IGMP Report messages, PE3 and PE4 establish (S, G) and
(*, G) entries of IGMP snooping in BD1 and add the interfaces connected to CE2 and CE3 as
outbound interfaces, respectively.
Dual-homing access for IGMP snooping over EVPN MPLS on the access side:
Figure 12-65 shows dual-homing access for IGMP snooping over EVPN MPLS on the access side.
Configure an EVPN instance on PE1, PE2, and PE3, and bind a BD to the EVPN instance. Establish
BGP EVPN peer relationships between the PEs, and deploy EVPN IGMP proxy on each PE.
1. PE2 periodically sends IGMP Query messages to the access side in BD1.
2. The receiver sends an IGMP Report message, for example, IGMPv2 (*, G) Report message,
to CE2.
3. After receiving an IGMP Report message, PE2 establishes (*, G) entries of IGMP snooping,
adds the Eth-Trunk interface to CE2 as the outbound interface, and sends the IGMP Join
Synch route of BGP EVPN to other PEs. The route carries the access-side ESI of PE2 and
contains the IGMP version and V2 source filtering mode.
4. After receiving the IGMP Join Synch route, PE3 creates the corresponding (*, G) entries of
IGMP snooping in BD1. PE3 does not need to send a BGP EVPN SMET route, because it is a
non-DF. Additionally, PE3 does not add the Eth-Trunk interface to CE2 as the outbound
interface, because the Eth-Trunk interface is Down.
5. PE2 functioning as a DF sends a BGP EVPN SMET route based on (*, G) entries of IGMP
snooping.
6. After receiving the BGP EVPN SMET route from PE2, PE1 creates (*, G) entries of IGMP
snooping and sends an IGMP Report message to CE1.
7. After receiving an IGMP Report message, CE1 creates IGMP and PIM entries and forwards
multicast traffic to PE1.
8. CE1 sends the multicast traffic received from the multicast source to PE1.
9. After receiving the multicast traffic, PE1 forwards the traffic to PE2 and PE3 through the
mLDP tunnel interfaces based on the (*, G) entries in BD1.
10. After PE2 and PE3 receive the multicast traffic, PE2 forwards the traffic to CE2 based on the
(*, G) entries, but PE3 does not. In this case, the receiver receives only one copy of
multicast traffic.
11. If some receivers are disconnected or do not need to receive multicast traffic, PE2 updates
the (*, G) entries based on the IGMP Report messages received from CE2, and sends IGMP
Background:
With the wide application of MPLS VPN solutions, different MANs of a service provider or
collaborative backbone networks of different service providers often span multiple ASs. Similar
to L3VPN services, EVPN services running on an MPLS network must also have the capability of
spanning ASs.
By advertisement of labeled routes between PEs, end-to-end BGP LSPs can be established to
carry Layer 2 traffic in BGP ASs (including inter-IGP areas) and inter-BGP ASs that only support
Option C.
In Option C mode, an autonomous system boundary router (ASBR) does not maintain or
advertise EVPN routes. Instead, PEs exchange EVPN routes directly. EVPN routes include the
following:
Figure 12-66 Inter-AS EVPN Option C networking where PEs advertise labeled EVPN routes
To improve expansibility, you can specify a route reflector (RR) in each AS. An RR stores all
EVPN routes and exchanges EVPN routes with PEs in the AS. RRs in two ASs establish MP-EBGP
connections with each other and advertise EVPN routes.
A local ASBR learns a labeled public network BGP route from the peer ASBR, assigns a label
to this route based on a matching policy, and advertises this route to its IBGP peer. Then, a
complete public network LSP is established.
The IBGP peer relationship between a PE and ASBR in the same AS is not required. In this
solution, a local ASBR learns a labeled public network BGP route from the peer ASBR and
imports this route to an IGP to trigger LDP LSP establishment. Then, a complete LSP is
established between the ingress and egress on the public network.
Benefits:
EVPN routes are directly exchanged between an ingress PE and egress PE. The routes do not
have to be stored and forwarded by intermediate devices.
Only PEs exchange EVPN routing information. Ps and ASBRs forward packets only. The
intermediate devices need to support only MPLS forwarding rather than MPLS VPN services.
In such a case, ASBRs are no longer the performance bottlenecks. Inter-AS EVPN Option C,
therefore, is suitable for an EVPN that spans multiple ASs.
DCI Scenarios:
Concept Description
Individual deployment of DC-GWs and A DC-GW and a DCI-PE are different devices.
DCI-PEs
Integrated deployment of DCI-PEs and A DC-GW and a DCI-PE are a single device, which
DC-GWs applies to scenarios where carriers build their own
DCs.
On the network shown in Figure 12-68, gateways in the DCs (DC-GW1 and DC-GW2) can access
the carrier's network edge devices (DCI-PE1 and DCI-PE2) in EVPN-VXLAN or VLAN mode. The
L3VPN or EVPN-MPLS function can be deployed on the DCI backbone network to transmit Layer
2 or Layer 3 service traffic. When DC A and DC B exchange their tenant host IP addresses or
MAC addresses, EVPN integrated routing and bridging (IRB) routes, EVPN IP prefix routes, BGP
VPNv4 routes, EVPN MAC routes, or ARP routes are used. For details about these routes,
see Table 12-8.
The DCI control plane advertises both Layer 3 and Layer 2 routes:
During Layer 3 route advertisement, a DC sends an IRB route or IP prefix route carrying a
tenant's host IP address to a DCI-PE through the EVPN protocol. Upon receipt, the DCI-PE re-
encapsulates the routing information into a BGP VPNv4 route if an L3VPN is deployed on the
backbone network. Alternatively, if EVPN-MPLS is deployed on the backbone network, the
DCI-PE re-encapsulates the received route into an IRB or IP prefix route. The re-encapsulated
routes carry the VM's IP route and are transmitted to the remote DCI-PE through the
backbone network.
The process of Layer 2 route advertisement is that a DC uses EVPN to send packets carrying
the host's MAC address or ARP entries to the local DCI-PE. The local DCI-PE then re-
Advertisement Process
Deployment
Services
Mode DC-GW1 to DCI- DCI-PE1 to DCI- DCI-PE2 to DC-
PE1 PE2 GW2
DCI-PE1 re- Upon receipt,
encapsulates the DCI-PE2 imports
EVPN route the BGP VPNv4
DC-GW1 sends a
tenant's host IP received from route into the
address to DCI- DC-GW1 into a local IP VPN
PE1 through an BGP VPNv4 instance based
IRB route or IP route, applying on the route RT
prefix route. DCI- the following and delivers
PE1 parses the
changes: information
tenant's host IP
route from the about MPLS
Changes the
received EVPN next hop to tunnel recursion
route. Then the the local to the VPN
system imports device's IP forwarding table.
L3VPN the tenant's address used
Layer 3 DCI-PE2 re-
(VXLAN route into the IP to establish a
services encapsulates the
access) VPN instance BGP VPNv4
based on RT received BGP
peer
matching relationship. VPNv4 route into
between the an IP prefix
Replaces the
EVPN route and route, applying
RD and RT
the IP VPN the following
values of the
instance and
EVPN route changes:
delivers
with those of
information Changes the
an L3VPN
about VXLAN next hop to
instance.
tunnel recursion the VTEP
Applies for
to the VPN address of
forwarding table. and
encapsulates DCI-PE2.
a VPN label. Replaces the
After re- RD and RT
DCI-PE1 re-
encapsulates the
VPN route into After receiving
DC-GW1 sends an IP prefix the EVPN route,
routes destined route, applying DCI-PE2 imports
for the network the following the route into
segment on the local IP VPN
changes:
which a tenant's instance based
host IP address Changes the on the RT of the
EVPN-MPLS resides to DCI- next hop to EVPN route,
Layer 3
(VLAN PE1 through an the local generates a VPN
services
access) IGP or BGP device's IP route forwarding
route. Upon address used entry, and
receipt, DCI-PE1 to establish a advertises the
delivers these BGP EVPN EVPN route to
routes to the peer DC-GW2 through
VPN forwarding relationship. a VPN IGP or BGP
table. peer
Adds the RD
relationship.
and RT
attributes to
the EVPN
DCI-PE1
generates an
EVPN MAC
route, applying
the following
changes:
DCI-PE1 re-
encapsulates the
route into an IRB
DC-GW1 sends a or IP prefix
tenant's host IP route. The
address to DCI- Upon receipt,
encapsulation
PE1 through an DCI-PE2 imports
IRB route or IP mode changes the IRB or IP
prefix route. DCI- from VXLAN to prefix route into
PE1 parses the MPLS: the IP VPN
tenant's host IP instance and
route from the Changes the delivers
received EVPN next hop to information
route. Then the the local about MPLS
system imports device's IP tunnel recursion
EVPN-MPLS the tenant's address used to the VPN
Layer 3 to establish a
(VXLAN route into the IP forwarding table.
services BGP EVPN
access) VPN instance DCI-PE2 changes
based on RT peer the L2 and L3
matching relationship. VPN labels in the
between the Adds the RD route to L2 and
local EVPN and RT L3 VNIs, re-
instance and the attributes to encapsulates the
IP VPN instance the EVPN route into an IRB
and delivers route. or IP prefix
information Applies for route, and then
about VXLAN and sends the route
tunnel recursion encapsulates to DC-GW2.
to the VPN a VPN label.
forwarding table. After re-
encapsulation,
DCI-PE1 sends
the route to DCI-
Upon receipt,
DCI-PE2 imports
DCI-PE1 re-
the MAC/IP
encapsulates the
advertisement
EVPN routes and
route into the
change the next-
local EVPN
hop IP address to
instance based
DC-GW1 sends a the IP address of
on RT matching.
tenant's host the locally
DCI-PE2 re-
MAC address to established EVPN
encapsulates the
DCI-PE1 through peer. The RD and
EVPN route by
a MAC/IP RT attributes in
changing the
advertisement the EVPN routes
next hop to its
route. DCI-PE1 that carry the
own VTEP
imports the VXLAN
Layer 2 address,
MAC/IP encapsulation
services replacing the RD
advertisement attribute are
and RT values of
route into the replaced with
the EVPN route
local EVPN the RD and RT of
with those of the
instance based the local EVPN
local EVPN
on RT matching instance. The
instance and
and generates a MPLS label is
padding the
MAC forwarding requested. The
route with an
entry. re-encapsulated
L2VNI. Then DCI-
MAC/IP
PE2 sends the re-
Advertisement
encapsulated
routes are then
MAC address
advertised to
advertisement
DCI-PE2.
route to DC-
GW2.
Table 12-10 describes Layer 2 traffic forwarding and Layer 3 traffic forwarding.
Table 12-10 Service traffic forwarding
DCI-PE2 parses
Upon receipt,
the VXLAN data
DCI-PE1 removes
packet to obtain
the public MPLS
the VNI and data
tunnel label, and,
packet. Based on
based on the
the VNI, DCI-PE2
VPN label, finds
finds the
the
corresponding
corresponding
VPN instance
VPN instance.
and, based on
Then, based on
the tenant's host
the tenant's host
IP address for
DC-GW2 sends a IP address for
the MPLS tunnel
L3VPN data packet to the VXLAN
Layer 3 to DCI-PE1,
(VXLAN DCI-PE2 through tunnel to DC-
services searches the
access) the VXLAN GW1, DCI-PE1
corresponding
tunnel. searches the
VPN instance
corresponding
forwarding table.
VPN instance
After
forwarding table.
encapsulating a
DCI-PE1
VPN label and a
encapsulates the
public MPLS
data packet with
tunnel label into
a VXLAN header
the data packet,
and then sends
DCI-PE2 sends
the VXLAN
the packet to
packet to DC-
DCI-PE1 through
GW1.
the MPLS tunnel.
DCI-PE2 parses
Upon receipt,
the VXLAN data
DCI-PE1 removes
packet to obtain
the public MPLS
the VNI and data
tunnel label, and,
packet. Based on
based on the
the VNI, DCI-PE2
VPN label, finds
finds the
the
corresponding
corresponding
VPN instance
VPN instance.
and, based on
Then, based on
the tenant's host
the tenant's host
IP address for
DC-GW2 sends a IP address for
the MPLS tunnel
data packet to the VXLAN
Layer 3 to DCI-PE1,
DCI-PE2 through tunnel to DC-
services searches the
the VXLAN GW1, DCI-PE1
corresponding
EVPN-MPLS tunnel. searches the
VPN instance
(VXLAN corresponding
forwarding table.
access) VPN instance
After
forwarding table.
encapsulating a
DCI-PE1
VPN label and a
encapsulates the
public MPLS
data packet with
tunnel label into
a VXLAN header
the data packet,
and then sends
DCI-PE2 sends
the VXLAN
the packet to
packet to DC-
DCI-PE1 through
GW1.
the MPLS tunnel.
1. Configure a B-EVPN instance on the SPE and specify a unique B-MAC address for the B-
EVPN instance.
2. Change the existing VSI on the SPE to be an MP2MP I-VSI and bind the I-VSI to the B-EVPN
instance previously configured. The I-tag for the I-VSI must be the same as the I-tag for the
B-EVPN instance. Otherwise, services cannot be forwarded.
3. Specify each UPE as an EVPN BGP peer for the SPE.
4. Configure a B-EVPN instance on each UPE and specify the SPE as an EVPN BGP peer for
each UPE. Then, UPEs will learn B-MAC addresses from their EVPN BGP peers and the SPE
will learn the B-MAC addresses of the entire network.
5. Change the existing VSI on each UPE to be an I-EVPN instance, bind the I-EVPN instance to
the previously configured B-EVPN instance, and bind the AC interface on each UPE to the I-
EVPN instance on that UPE. After all configurations are complete, the network becomes a
PBB-EVPN.
Figure 12-69 Typical networking
Configure a PE on the backbone network as an EVPN RR and the other PEs as RR clients.
Establish BGP EVPN peer relationships between the RR and clients, but not between the
clients. To improve reliability, you can configure two EVPN RRs, one as the master and the
other as the backup.
Create EVPN instances on PEs. Configure the same RT values for the PEs to allow EVPN route
cross.
Configure PE redundancy. If all PEs connecting to the same CE are configured to work in All-
Active mode, these PEs load-balance traffic destined for the CE.
Figure 12-70 EVPN application networking
EVPN Splicing
Background:
The current MAN is evolving into EVPN. However, because there are a large number of devices
at the aggregation layer, it is difficult for the MAN to evolve into EVPN at a time. To allow
traditional L3VPN, VPWS or VPLS to be still used at the aggregation layer and the core layer to
evolve into EVPN first, splicing between EVPN and the traditional network must be supported.
The network between the UPE and NPE1 resides at the aggregation layer. The network
between NPE1 and NPE2 resides at the core layer. An L3VPN is deployed at the aggregation
layer, and EVPN-MPLS is deployed at the core layer. After receiving user routes from the access
side, the UPE sends these routes to NPE1 through a BGP VPNv4 peer relationship. Both an EVPN
instance and an L3VPN instance are configured on NPE1. After receiving BGP VPNv4 routes,
NPE1 imports these routes into the L3VPN instance, encapsulates the routes into EVPN routes,
and sends the EVPN routes to NPE2 through a BGP EVPN peer relationship. This
implementation is L3VPN accessing EVPN as such.
Figure 12-71 L3VPN accessing EVPN
On a network with VLL accessing EVPN, CE1 and CE2 stand for two users. Each user has three
sites: CE1-1, CE1-2, and CE1-3 for CE1, and CE2-1, CE2-2, and CE2-3 for CE2. NIDs, which
function as aggregation devices on the user side, are attached to the user sites and access the
aggregation network. When accessing the aggregation network, the CEs use the S-VLAN and C-
VLAN tags. S-VLAN indicates an NID, and C-VLAN indicates the user site connected to the NID.
The users access the VLL network, a Layer 2 network, through the NIDs. The UPE and NPE1
belong to the aggregation layer, at which an MPLS network is deployed. Services between the
devices are carried using a VLL. NPE1 and NPE2 belong to the core layer, at which an MPLS
network is deployed. Services between them are carried through an EVPN.
To allow communication between different sites of the same user, VLL accessing EVPN supports
the following scenarios:
Single-homing scenario:
An NID on the access side can be single-homed to a UPE through a main interface. The UPE
establishes a PW with NPE1 for each NID. On NPE1 and NPE2, an EVPN instance is created
for each user. On NPE1, a VLL is connected to the EVPN through a PW VE interface. The VLL
is bound to the PW VE interface, and the EVPN instances are bound to the PW VE sub-
interfaces that are configured as QinQ VLAN tag termination sub-interfaces. In this manner,
traffic of user packets is imported to different EVPN instances based on the S-VLAN and C-
VLAN tags.
Figure 12-72 Single-homing scenario 1 for VLL accessing EVPN (per NID per PW)
Dual-homing scenario:
A UPE is dual-homed to the master and slave NPEs through primary and secondary PWs
respectively to improve access reliability. On the EVPN, the NPE1-NPE3 link and the NPE2-
NPE3 link can be configured to work in single-active mode or in all-active mode, which allows
for load balancing.
Figure 12-74 Dual-homing scenario for VLL accessing EVPN
Splicing Primary and Secondary PWs with an Anycast VXLAN Tunnel in an EVPN Active-Active
Scenario:
On the network shown in Figure 12-76, PE1 and PE2 are egress devices of the data center
network. PE1 and PE2 work in active-active mode with a bypass VXLAN tunnel deployed
between them. They use an anycast VTEP address to establish a VXLAN tunnel with the TOR. In
this manner, PE1, PE2, and the TOR can communicate with each other. PE1 and PE2
communicate with the external network (an access network or the Internet) through the VPLS
network. PW redundancy is deployed on the VPLS network. That is, the PE-AGG connects to PE1
and PE2 through primary and secondary PWs, respectively. In this example, the PW between
the PE-AGG and PE1 is the primary PW.
Through the TOR, the server in the data center can send traffic to PE1 and PE2. Traffic received
by PE1 is directly sent to the PE-AGG through the primary PW. Traffic received by PE2 is
VPLS has inherent defects, such as a lack of support in load balancing and heavy consumption
of network resources (MAC learning and ARP learning require packet broadcast on the entire
network). As EVPN becomes widely used, VPLS networks are gradually evolving to EVPNs.
However, such evolution cannot be implemented at a time due to complex network
environments. Specifically, some devices may be deployed with VPLS and some other devices
are deployed with EVPN. In this case, the function of VPLS splicing with MPLS EVPN can be
deployed to ensure interworking on the entire network.
As shown in Figure 12-77, VPLS is deployed between CSGs and ASGs, and CSGs are connected to
ASGs through the primary and secondary PWs. EVPN is deployed between ASGs and RSGs. On
ASG1 and ASG2, a BD is configured and bound to a VSI and an EVPN instance. In this manner, all
PWs in the VSI can be connected to the EVPN through BDs. On the CSG dual-homed to ASG1
and ASG2, the same ESI is configured for the primary and secondary PW interfaces. The
procedure for traffic forwarding is as follows:
1. Because an ESI is configured on ASG1's PW interface and the PW is in the Up state, ASG1
sends Ethernet A-D routes to the RSG.
2. After the Layer 2 packets sent by Site 1 reach ASG1 through the CSG, ASG1 generates MAC
routes for the EVPN based on the MAC address of Site 1 in the Layer 2 packets. Such MAC
routes are sent to the RSG based on the BGP EVPN peer relationship, and the RSG
generates MAC forwarding entries based on the received Ethenet A-D routes. Similarly, the
RSG sends MAC routes that carry the MAC address of Site 2 to ASGs and generate the
corresponding MAC forwarding entries.
NOTE:
Although ASG1 and ASG2 transmit Ethernet Segment routes to each other, DF election between
ASG1 and ASG2 is implemented based on the PW status. The device (ASG1) connected to the
primary PW is the primary DF, and the device (ASG2) connected to the secondary PW is the
backup DF.
In BUM traffic forwarding scenarios, because the network is deployed with split horizon and the
backup DF blocks traffic, loops or extra packets do not occur on the network.
Figure 12-77 Networking of VPLS splicing with MPLS EVPN
1. After EVPN is enabled on PE1, PE1 starts to advertise inclusive multicast routes to the other
PEs. Because PE1 does not receive any inclusive multicast routes from the other PEs, traffic
between PE1 and the other PEs continues to be forwarded through VPLS connections.
2. When EVPN continues to be enabled on another PE, for example PE2, PE2 starts to send
inclusive multicast routes to the remaining EVPN-disabled PEs.
3. After PE1 and PE2 receive inclusive multicast routes from each other, they discover each
other and disable the VPLS connection between them. The service between PE1 and PE2 is
carried through an EVPN. Simultaneously, services between PE1/PE2 and the other PEs
remain carried through the VPLS connections.
UPE: A UPE is a device that is directly connected to a user and is referred to as an underlayer
PE or a user-end PE, therefore shortened as UPE. UPEs provide access services for users.
SPE: An SPE is a superstratum PE or service provider-end PE, which is connected to UPEs and
located at the core of a network. An SPE manages and advertises VPN routes.
NPE: An NPE is a network provider-end PE that is connected to SPEs and located at the
network side.
Figure 12-79 Basic EVPN L3VPN HVPN architecture
EVPN L3VPN HVPN is classified into EVPN L3VPN HoVPN or EVPN L3VPN H-VPN:
Splicing between EVPN L3VPN HoVPN and common L3VPN: EVPN L3VPN HoVPN is deployed
between the UPEs and SPE, and L3VPN is deployed between the SPE and NPE. The SPE
advertises only default routes or summarized routes to the UPEs. After receiving specific
routes (EVPN routes) from the UPEs, the SPE encapsulates these routes into VPNv4 routes
and advertises them to the NPE.
Splicing between L3VPN HoVPN and BD EVPN L3VPN: L3VPN HoVPN is deployed between
the UPEs and SPE, and BD EVPN L3VPN is deployed between the SPE and NPE. The SPE
advertises only default routes or summarized routes to the UPEs. After receiving specific
routes (L3VPN routes) from the UPEs, the SPE encapsulates these routes into EVPN routes
and advertises them to the NPE.
Route Advertisement from CE1 to Device 1 on an EVPN L3VPN HoVPN or EVPN L3VPN H-VPN:
Figure 12-80 shows route advertisement from CE1 to Device 1 on an EVPN L3VPN HoVPN or
EVPN L3VPN H-VPN.
Figure 12-81 shows route advertisement from Device 1 to CE1 on an EVPN L3VPN HoVPN.
Figure 12-82 shows route advertisement from Device 1 to CE1 on an EVPN L3VPN H-VPN.
Route Advertisement from Device 1 to CE1 on an EVPN L3VPN HoVPN or EVPN L3VPN H-VPN:
Packet forwarding from Device 1 to CE1 on an EVPN L3VPN HoVPN or EVPN L3VPN H-VPN is as
follows:
Splicing between EVPN L3VPN HoVPN and common L3VPN: After receiving the IP prefix
route carrying CE1's specific route from the UPE, the SPE re-encapsulates the IP prefix route
into a BGP VPNv4 route and advertises it to the NPE.
Splicing between L3VPN HoVPN and BD EVPN L3VPN: After receiving the BGP VPNv4 route
carrying CE1's specific route from the UPE, the SPE re-encapsulates the BGP VPNv4 route
into an IP prefix route and advertises it to the NPE.
https://support.huawei.com/