Evpn PDF

Chapter 23
EVPN
This chapter describes Arista’s EVPN implementation. Sections in this chapter include:
• Section 23.1: EVPN Overview
• Section 23.2: EVPN Layer 3 Core Operations
• Section 23.3: Integrated Routing and Bridging
• Section 23.4: VPN MPLS Transport Options
• Section 23.5: EVPN Type-5 Routes: IP Prefix Advertisement
• Section 23.6: Inter-VRF Local Route Leaking
• Section 23.7: Configuring EVPN
• Section 23.8: Sample Configurations
• Section 23.9: EVPN and VCS Commands
1159
EVPN Overview Chapter 23: EVPN
23.1 EVPN Overview

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

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

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

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

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

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

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

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

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

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

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

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

When VXLAN Control Services (VCS) is enabled on a CloudVision eXchange (CVX) of a Data Center
(DC), each VXLAN Tunnel End Point (VTEP) connects to the corresponding CVX for sharing the Layer
2 bridging information of it’s attached hosts. In turn, CVX advertises this information to all VTEPs within
the DC.
In a topology consisting of multiple DCs where each DC runs its own CVX instance as shown in
Figure 23-8, a federation of CVXs can be created by using BGP-EVPN. In such Data Center
Interconnect (DCI) topologies, CVX in each DC performs the following functions to advertise the Layer
2 bridging information (MAC-VTEP bindings) to all VTEPs in different DCs:
• Receives the local Layer 2 bridging information in CVX control plane format from all VTEPs within
the DC; and advertises it to remote CVXs in the BGP-EVPN NLRI format.
• Receives the Layer 2 bridging information in BGP-EVPN NLRI format from remote CVXs; and
advertises it to local VTEPs in the CVX control plane format.
Note The distribution of Layer 2 bridging information as described above allows a Layer 2 overlay network
to be stretched across multiple DCs without additional VTEP configurations.
Figure 23-8 illustrates the federation of CVX across multiple DCs.

Figure 23-8: CVX Connected from Multiple DCs
1167
23.1.4 EVPN MPLS LAYER 3 VPN (Type-5 Route)

Ethernet VPN (EVPN) is an extension of the BGP protocol introducing a new address family: Layer 2
VPN (address family number 25) / EVPN (subsequent address family number 70). It is used to
exchange overlay MAC and IP address reachability information between BGP peers using type-2
routes. Additionally, EVPN supports the exchange of layer 3 IP overlay routes through the extensions
described in (type 5 EVPN routes).
An IP VRF is used on a PE router for each layer 3 overlay. VRF IP routes are exported into the EVPN
BGP table and advertised to remote VTEPs as type 5 routes. The exported EVPN routes carry the
Route-Target (RT) extended communities that are configured as export route-targets on the IP VRF
from which they were exported.
The RTs carried by the EVPN type 5 routes received by a PE are matched against the VRF import
route-target configuration. When a received route carries an RT that is configured as an import
route-target on an IP VRF, the route is imported into the IP table for that VRF.
PE routers allocate per-VRF and address family Labels that are advertised as part of the layer 3 (type
5) EVPN route NLRI. Forwarding of overlay packets between PEs across the underlay requires
underlay MPLS connectivity provided by an IP backbone.
The type-5 routes provide the ability to decouple the advertisement of an IP prefix from any specific
MAC address, providing the ability to support floating IP address, optimized the mechanism for
advertising external IP prefixes, and reduce the churn when withdrawing IP prefixes.
The format of the new type-5 IP-prefix route is illustrated in the figure below. Unlike when VXLAN is
used as a transport, BGP route update for MPLS does not specify the router-mac extended community
and sets the tunnel encapsulation to MPLS. Unlike with VXLAN encapsulation, which uses the VNI as
the overlay index, the MPLS Type-5 route uses the MPLS label.
Figure 23-9: EVPN Route Type-5, for Advertisement of IP-Prefixes over MPLS
Path Attribute MP_REACH_NLRI

Next-hop IP for the prefix = PE IP Next-hop for the prefixes within
AFI=25 (L2VPN), SAFI=70 (EVPN) the NLRI=IP of the advertising PE
Route Type (IP Prefix Route, Type 5) Type 5 NLRI

Length Route Distinguisher (RD) Configured Route Distinguisher
Ethernet Segment Identifier = 0 Set to zero as ESI is NOT an overlay index
Ethernet Tag ID = 0
1 - Ethernet A-D Route
IP Prefix Length (0-32, 0-128) Prefix mask IPv4/IPv6 Support, and
2 - MAC-advertisement Route
IPv4 or IPv6 Prefix
3 - Inclusive Multicast Route IP Prefix (IPv4 or IPv6)
4 - Ethernet Segment Route Set to zero for interface-less.
5 - IP prefix Route (optional) GW IP Address = 0 MPLS label is used as overlay index.
MPLS Label VRF label of the advertising PE,
used as overlay index.
Extended Community Route Target Configured Route Target

Tunnel-encapsulation Extended Tunnel-encapsulation type = MPLS
Community
1168
Chapter 23: EVPN EVPN Layer 3 Core Operations
Figure 23-10 offers a more detailed view of the route as displayed on a PE router.
Figure 23-10: EVPN Route Type-5 as Shown on PE
As shown in Figure 23-10, the route contains the VPN route (prefix and RD), the next-hop for the route
and the advertising router ID, along with the extended communities of tunnel type (MPLS), MPLS Label
value and route-target.
Note You require 4.21.1F release and later versions with Jericho/Jericho+ platforms.
23.2 EVPN Layer 3 Core Operations

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

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

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

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

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

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

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

Figure 23-15: EVPN Type-3 IMET Route Format
Figure 23-15 notable fields of the type-3 route:

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

In the traditional data center design, inter-subnet forwarding is provided by a centralized router, where
traffic traverse across the network to a centralized routing node and back again to its final destination.
In a large multi-tenant data center environment this operational model can lead to inefficient use of
bandwidth and sub-optimal forwarding.
To provide a more optimal forwarding model and avoid traffic tromboning, the EVPN inter-subnet draft
(draft-sajassi-l2vpn-evpn-inter-subnet-forwarding) proposes integrating the routing and bridging (IRB)
functionality directly onto the VTEP, thereby allowing the routing operation to occur as close to the end
host as possible. The draft proposes two forwarding models for the IRB functionality, which are termed
asymmetric IRB and symmetric IRB, these two models are described in the following sections.
In the asymmetric IRB model, the inter-subnet routing functionality is performed by the ingress VTEP,
with the packet after the routing action being VXLAN bridged to the destination VTEP. The egress
VTEP only then needs to remove the VXLAN header and forward the packet onto the local Layer 2
domain based on the VNI to VLAN mapping. In the return path, the routing functionality is reversed with
the destination VTEP now performing the ingress routing and VXLAN bridging operation, hence the
term asymmetric IRB.
Figure 23-16: EVPN Asymmetric IRB
To provide inter-subnet routing on all VTEPs for all subnets, an anycast IP address is utilized for each
subnet and configured on each VTEP. The anycast IP acts as the default gateway for the hosts,
therefore regardless of where the host resides the directly attached VTEPs can act as the host’s default
gateway. The host MAC and MAC to IP bindings are learned by each VTEP based on a combination
of local learning/ARP snooping and type-2 route advertisement from remote VTEPs.
In a typical implementation, the optional MAC and IP, type-2 route is advertised separately from the
MAC only type-2 route. This is done so that if the MAC and IP route is cleared, for example the ARP
flushed, or the ARP timeout is set to less than the MAC timeout, then the MAC only route will still exist.
1174
Chapter 23: EVPN Integrated Routing and Bridging
The format of the two advertised type-2 routes for Server-1 are illustrated below, where the RD
IP-A:1010 and route-target 1010:1010 are used to distinguish the uniqueness of the route and allow
the route to be imported into the correct remote MAC-VRF based on the route-target import policy of
the VTEP.
Figure 23-17: EVPN Comparison of MAC & MAC+IP Type 2 Route in Asymmetric IRB
1175
For the traffic flow between Server-1 in subnet-10 and Server-4 in subnet-11, the ingress VTEP
(VTEP-1) locally routes the packet into subnet-11/VNI 1011 and then VXLAN bridges the frame,
inserting the VNI 1011 into the VXLAN header with an inner DMAC equal to the destination host,
Server-4. This requires the receiving VTEP, (VTEP-4) to only perform a local Layer 2 lookup, based on
the VNI to VLAN mapping, for the DMAC of Server-4.
Figure 23-18: EVPN Asymmetric IRB VxLAN Data-plane Forwarding Detail
For the asymmetric model to operate the sending VTEP needs the information for all the tenant’s hosts
(MAC and MAC to IP binding), to route and bridge the packet. This means the VTEP needs to be
member of all the tenant’s subnets/VNI and have an associated SVI with anycast IP for all the subnets,
and this will be required on all VTEPs participating in the routing functionality for the tenant. This
introduces scaling issues on multiple fronts.
• VNI Scaling: The number of VNIs supported on a hardware VTEP will be finite, so not all VNIs
can reside on all VTEPs. This is especially true in data-center deployments, where the TOR’s
have traditionally been more resource constrained than chassis-based edge systems.
• Forwarding memory scaling: The VTEPs needs to store all host MACs and ARP entries for all
subnets in the network, on leaf switch this is hardware resource which again will be a finite
resource defined by the specific hardware platform deployed at the leaf.
Symmetric IRB
To address the scale issues of the asymmetric model, in the symmetric model the VTEP is only
configured with the subnets that are present on the directly attached hosts. Connectivity to non-local
subnets on a remote VTEP is achieved through an intermediate IP-VRF. The subsequent forwarding
model for symmetric IRB is illustrated in the figure below, for traffic between Server-1 on subnet-10
(Green) and Server-4 on the remote subnet-11 (Blue). In this model, the ingress VTEP routes the traffic
1176
between the local subnet-10) and the IP-VRF, which both VTEPs are a member of, the egress VTEP
then routes the frame from the IP-VRF to the destination subnet. The forwarding model results in both
VTEPs performing a routing function, hence the term symmetric IRB.
Figure 23-19: EVPN Symmetric IRB
To provide the inter-subnet routing, when the subnet is stretched across multiple VTEPs, an anycast
IP address is utilized for each subnet, but only configured on the VTEP’s where the subnet exists. The
host MAC and MAC to IP bindings are learned by each VTEP based on a combination of local
learning/ARP snooping and type-2 route advertisements.
For the symmetric IRB model the type-2 (MAC and IP) route is advertised with two labels and two
route-targets corresponding to the MAC-VRF the MAC address is learned on and the IP-VRF. Remote
VTEP’s receiving the route, import the IP host route into the corresponding IP-VRF based on the
IP-VRF route-target and if the corresponding MAC-VRF exists on the VTEP the MAC address is
imported into the local MAC-VRF based on the MAC-VRF’s Route-Target. The import behavior for the
type-2 route is illustrated in the diagrams below for the host Server-1.
If the MAC-VRF exists locally on the receiving router, both the IP host route will be installed in the
IP-VRF, and the MAC address will be installed in the MAC-VRF. As shown in Figure 30. With both a
MAC route in the MAC-VRF and an IP host route in the IP-VRF, the VNI used in the data-path will
depend on whether the traffic is being VXLAN bridged between hosts in the same VNI (1010) or
VXLAN routed (VNI 2000).
1177
Figure 23-20: EVPN Type 2 Route in Symmetric IRB - MAC-VRF on Both VTEPs
1178
Compare this to Figure 4.17, where the MAC-VRF does not exist on the receiving VTEP (VTEP-2). In
this case the MAC route is not installed and ignored, as there is no corresponding Route Target on the
VTEP. In this scenario, only the IP-VRF host route is installed on VTEP-2. Traffic from VTEP-2 destined
to hosts on subnet-10, are therefore always VXLAN routed via the IP-VRF, VNI 2000.
Figure 23-21: EVPN Type 2 Route in Symmetric IRB - MAC-VRF Only Exists on Sending VTEP
The symmetric IRB type-2 route contains a number of additional extended community attributes over
the asymmetric IRB type-2 route, the salient fields of the route are summarized below.
• Multi-protocol Reachable NLRI (MP_REACH_NLRI) attribute is used to carry the next-hop hop
for the advertised route. In the context of a VXLAN forwarding plane, this will be the source
address of the advertising VTEP.
• Route Distinguisher of the advertising node’s MAC-VRF. For Server-1 in the example above
this would be IPA:1010.
• MAC address field contains the 48-bit MAC address of the host being advertised. For Server-1
in the example above this would be MAC-1.
• IP address and length field contain the IP address and 32-bit mask for the host being
advertised. For Server-1 in the example above this would be IP-1.
• MAC-VRF label, this contains the VNI number (label) corresponding to the local Layer 2
domain/MAC-VRF the host MAC was learned on. For Server-1 in the example above this would
be VNI 1010.
• IP-VRF label, this contains the VNI number (label) corresponding to the MAC-VRF’s
associated lP-VRF. For MAC-VRF 10 in the example above this would be IP-VRF 2000.
• Extended community Route Target for the IP-VRF. This contains the route-target of the IP-VRF
associated with the learned MAC address.
• Extended community Router MAC. This field advertises the system MAC of the advertising
VTEP and is used as the DMAC for any packet sent to the VTEP via the IP-VRF.
1179
• Extended community Route Target for the MAC-VRF. This contains the route-target of the
MAC-VRF associated with the learned MAC address.
23.3.1 IP VPN
RFC 4364 allows Service Providers and Enterprises to use their backbone infrastructure to provide the
services to multiple customers, or internal departments; while performing the following functions:
• Maintaining privacy
• Allowing for IP address overlap amongst customers
• Constraining route distribution - so that only the service provider routers which need the routes
have them.
This is achieved through the usage of VRFs, Route Distinguishers and Route-Targets
The IPv4/IPv6 VPN Standard RFC 4364 does the following:
• Specifics an BGP IPv4 VPN control plane with a MPLS data plane
• BGP control plane, new address family to advertise IP VPN prefixes.
• This RFC obsoleted the original RFC 2547
• MPLS data-plane defined in multiple RFCs and drafts.
The RED circle in Figure 23-22 highlights the main Drafts and RFCs in use today for an MPLS
data-plane.
Figure 23-22: MPLS data-plane
IPv4 VPN and IPv6 VPN are an extensions of the BGP protocol introducing new address families: IPv4
(address family number 1), IPv6 (address family number 2), and a subsequent address family number
128: MPLS Layer 3 VPN unicast. It is used to exchange overlay IP prefix reachability information
between MP-BGP peers.
Figure 23-23: IPv4 VPN and IPv6 VPN
IPv4 VPN defines two route types:

• Update
1180
• Withdrawal
Each route type has its own NLRI prefix format and ach route type advertises its own set of prefixes to
update/withdraw.
The format of the IPv4 VPN prefix update route is illustrated in Figure 23-24. As detailed, the update
route contains the VPN route (prefix and RD), the next-hop for the route and the advertising router ID,
along with the MPLS Label, along with a number of path attributes (where the RT extended
communities are defined), which are associated with these IPv4 NLRIs.
Figure 23-24: IPv4 and IPv6 VPN Update Route Detail
The output in Figure 23-25 and Figure 23-26 offer a more detailed view of the route as displayed on a
PE router.
Figure 23-25: IPv4 VPN Route as Shown on PE
Figure 23-26: IPv6 VPN Route as Shown on PE
1181
Figure 23-27 illustrates a basic MPLS Layer 3 VPN topology.

Figure 23-27: MPLS Layer 3 VPN Topology
Active - PE Active - PE
VRF A VRF A
VRF B VRF B
P
CE VRF A CE VRF A
CE VRF A CE VRF A
P P
MPLS
VRF A VRF A
VRF B VRF B
IP Routing MP-iBGP or MP-eBGP Route IP Routing
An IP VRF is used on a PE router for each customer (Layer 3 overlay). VRF IP routes are exported into
the MP-BGP table and advertised to remote PEs as VPN routes. The exported VPN routes carry the
Route-Target (RT) extended communities that are configured as export route-targets on the IP VRF
from which they were exported.
The RTs carried by the VPN routes received by a PE are matched against the VRF import route-target
configuration. When a received route carries an RT that is configured as an import route-target on an
IP VRF, the route is imported into the IPv4 or IPv6 table for that VRF.
PE routers allocate per-VRF and address family Labels that are advertised as part of the VPN route
NLRI. Forwarding of overlay packets between PEs across the underlay requires underlay MPLS
connectivity provided by a backbone.
Note You require 4.21.1F release and later versions with Jericho/Jericho+ platforms.
1182
Chapter 23: EVPN VPN MPLS Transport Options
23.4 VPN MPLS Transport Options

EVPN-MPLS and IP-VPN sample topologies illustrate co-existing LDP, BGP-SR, and ISIS-SR on the
core.
Figure 23-28: Physical Topology For ISIS-SR, LDP and BGP-SR Transport
ISIS-SR LDP
North Edge Lo0: 1.1.1.111 North Edge Lo200: 1.1.1.200
NW Core Lo0: 2.2.2.2 NW-CORE NE-CORE NW Core Lo200: 2.2.2.200
SW Core Lo0: 3.3.3.3 SW Core Lo200: 3.3.3.200
NE Core Lo0: 4.4.4.4 ETH 25 192.168.61.0/24 ETH 25 NE Core Lo200: 4.4.4.200
SE Core Lo0: 5.5.5.5 SE Core Lo200: 5.5.5.200
South Edge Lo0: 6.6.6.6 ETH 1 ETH 1 South Edge Lo200: 6.6.6.200
ETH 2
192.168.58.0/24 ETH 2 ETH 26 ETH 26 ETH 4 192.168.67.0/24
192.168.68.0/24
ETH 1 192.168.62.0/24 ETH 1
NORTH EDGE SOUTH EDGE
ETH 2
IS-IS SR
192.168.60.0/24 LDP 192.168.66.0/24
BGP-SR
ETH 2 ETH 3
192.168.63.0/24
192.168.59.0/24 192.168.69.0/24
ETH 26 ETH 26
ETH 2 ETH 4
BGP-SR ETH 1 ETH 3
North Edge Lo1: 1.1.1.11 ETH 25 192.168.64.0/24 ETH 25
NW Core Lo1: 2.2.2.22
SW Core Lo1: 3.3.3.33
NE Core Lo1: 4.4.4.44 ETH 27 192.168.65.0/24 ETH 27
SE Core Lo1: 5.5.5.55 SW-CORE SE-CORE
South Edge Lo1: 6.6.6.66
LDP, ISIS-SR, and BGP-LU (BGP-SR) demonstrates the corresponding Label Switched Paths (LSPs)
as the MPLS transport LSPs for Layer3 EVPN and IP VPN services.
1183
VPN MPLS Transport Options Chapter 23: EVPN
EVPN Sample Topology

In Figure 23-29 and Figure 23-30, the prefixes from each DC are transported over the WAN/DCI
domain, maintaining the Layer 3 multi-tenancy in tenant-a and tenant-b.
Figure 23-29: Tenant-A DCI
EVPN IPv4 (TENANT-A)

LDP
NW-CORE RR NE-CORE
North Edge Lo200: 1.1.1.200
NW Core Lo200: 2.2.2.200
ETH 25 192.168.61.0/24 ETH 25 SW Core Lo200: 3.3.3.200
NE Core Lo200: 4.4.4.200
ETH 1 ETH 1 SE Core Lo200: 5.5.5.200
ETH 2 South Edge Lo200: 6.6.6.200
192.168.58.0/24 ETH 2 ETH 26 ETH 26 ETH 4 192.168.67.0/24
192.168.68.0/24
ETH 1 192.168.62.0/24 ETH 1
BGP-EVPN BGP-EVPN
ETH 2
IS-IS SR
192.168.60.0/24 LDP 192.168.66.0/24
BGP-SR
TENANT-A ETH 2 ETH 3 TENANT-A
ET 6/3.1 192.168.63.0/24 ET 6/3.1
ET 6/2.1 ET 6/2.1
192.168.59.0/24 192.168.69.0/24
192.168.168.8/30 ETH 26 ETH 26 192.168.168.8/30
ETH 2 ETH 4
192.168.168.12/30 192.168.168.12/30
ETH 1 ETH 3
ET 2.1 ET 2.1
ETH 25 192.168.64.0/24 ETH 25
ET 2.1 ET 2.1
7050SX ETH 27 192.168.65.0/24 ETH 27 7050SX
SW-CORE SE-CORE
7050SX Leaf 12 Leaf 11 7050SX
BGP-SR ISIS-SR
DC1 DC1
Leaf 11 North Edge Lo1: 1.1.1.11 North Edge Lo0: 1.1.1.111 Leaf 12
DC1 NW Core Lo1: 2.2.2.22 NW Core Lo0: 2.2.2.2 DC1
NE Core Lo1: 4.4.4.44 NE Core Lo0: 4.4.4.4
South Edge Lo1: 6.6.6.66 South Edge Lo0: 6.6.6.6
Figure 23-30: Tenant-B DCI
EVPN IPv4 (TENANT-B)

LDP
NW-CORE RR NE-CORE
NW Core Lo200: 2.2.2.200
ETH 25 192.168.61.0/24 ETH 25 SW Core Lo200: 3.3.3.200
NE Core Lo200: 4.4.4.200
ETH 1 ETH 1 SE Core Lo200: 5.5.5.200
192.168.58.0/24 ETH 2 ETH 26 ETH 26 ETH 4 192.168.67.0/24
192.168.68.0/24
ETH 1 192.168.62.0/24 ETH 1
BGP-EVPN BGP-EVPN
ETH 2
IS-IS SR
192.168.60.0/24 LDP 192.168.66.0/24
BGP-SR
TENANT-B ETH 2 ETH 3 TENANT-B
ET 6/3.2 192.168.63.0/24 ET 6/2.2
ET 6/2.2 ET 6/3.2
192.168.59.0/24 192.168.69.0/24
192.168.168.20/31 ETH 26 ETH 26 192.168.168.18/31
ETH 2 ETH 4
192.168.168.22/31 192.168.168.16/31
ETH 1 ETH 3
ET 2.2 ET 2.2
ETH 25 192.168.64.0/24 ETH 25
ET 2.2 ET 2.2
7050SX ETH 27 192.168.65.0/24 ETH 27 7050SX
SW-CORE SE-CORE
BGP-SR ISIS-SR
DC1 DC1
Leaf 11 North Edge Lo1: 1.1.1.11 North Edge Lo0: 1.1.1.111 Leaf 12
DC1 NW Core Lo1: 2.2.2.22 NW Core Lo0: 2.2.2.2 DC1
To provide external connectivity from the DC into the MPLS domain, leaf-11 and leaf-12 are eBGP
peering via the tenants VRFs with the border routers. Both core routers are advertising external
prefixes for Internet and any remote site connectivity (default route and ip-prefixes from the other DC
for the tenant). To provide connectivity within the EVPN domain, the leaf switches (leaf-21 and leaf-2)
re-advertise the prefixes into the tenant’s VRF via a type-5 route advertisement, with a next-hop equal
to the advertising PE.
1184
Let us review the concepts of transport labels, advertised to provide the label switched path, or LSP,
across the back-bone and the VPN, or tenant label, used by the provider edge (PE) routers to identify
a particular tenant.
EVPN MPLS Sample Configuration displays BGP route updates and how the tenant VRF is
transported over these transport LSPs.
IP VPN Sample Topology

Let us review the concepts of transport labels, advertised to provide the label switched path, or LSP,
across the back-bone and the VPN, or tenant label, used by the Provider Edge (PE) routers in
Figure 23-31 to identify a particular tenant.
Figure 23-31: IPv4 & IPv6 VPN Sample Topology
VRF VRF
Tenant-D P Tenant-D
P P
MPLS
Tenant-D CE Tenant-D CE
P P
eBGP IP Routing MP-iBGP or MP-eBGP Route eBGP IP Routing
1185
In Figure 23-32 and Figure 23-33, the prefixes for VRF tenant-d are transported over the MPLS WAN
between North Edge and South Edge routers.
Figure 23-32: Tenant-D IPv4 VPN
ISIS-SR LDP
IPv4 VPN
NW Core Lo0: 2.2.2.2 NW-CORE RR NE-CORE NW Core Lo200: 2.2.2.200
ETH 2
192.168.58.0/24 ETH 2 ETH 26 ETH 26 ETH 4 192.168.67.0/24
192.168.68.0/24
ETH 1 ETH 1
192.168.62.0/24
BGP-IPv4 VPN BGP-IPv4 VPN
ETH 2
IS-IS SR
192.168.60.0/24 LDP 192.168.66.0/24
BGP-SR
TENANT-D ETH 2 ETH 3 TENANT-A
192.168.63.0/24
ET 6/1.120 ET 6/1.620
192.168.59.0/24 192.168.69.0/24
ETH 26 ETH 26
10.255.255.0/30 ETH 2 ETH 4 10.255.255.4/30
ETH 1 ETH 3
VL120 10.255.255.2/30 VL620 10.255.255.6/30
ETH 25 192.168.64.0/24 ETH 25
VL121 201.0.0.1/24 VL621 206.0.0.1/24
ETH 27 192.168.65.0/24 ETH 27

BGP-SR SW-CORE SE-CORE
CE CE
NW Core Lo1: 2.2.2.22
SW Core Lo1: 3.3.3.33
NE Core Lo1: 4.4.4.44
SE Core Lo1: 5.5.5.55
Figure 23-33: Tenant-D IPv6 VPN
ISIS-SR LDP
IPv6 VPN
NW Core Lo0: 2.2.2.2 NW-CORE RR NE-CORE NW Core Lo200: 2.2.2.200
ETH 2
192.168.58.0/24 ETH 2 ETH 26 ETH 26 ETH 4 192.168.67.0/24
192.168.68.0/24
ETH 1 192.168.62.0/24 ETH 1
ETH 2
IS-IS SR
192.168.60.0/24 LDP 192.168.66.0/24
BGP-SR
192.168.63.0/24
ET 6/1.120 ET 6/1.620
192.168.59.0/24 192.168.69.0/24
ETH 26 ETH 26
2010::0/126 ETH 2 ETH 4 2010::4/30
ETH 1 ETH 3
VL120 2010::1/126 VL620 2010::6/126
ETH 25 192.168.64.0/24 ETH 25
VL121 2201::1/64 VL621 2201::6/64
ETH 27 192.168.65.0/24 ETH 27

BGP-SR SW-CORE SE-CORE
CE CE
NW Core Lo1: 2.2.2.22
SW Core Lo1: 3.3.3.33
NE Core Lo1: 4.4.4.44
SE Core Lo1: 5.5.5.55
1186
23.4.1 LDP
Figure 23-34 illustrates how LDP neighbor relationships are built. First each router sends a discovery
to a destination multicast address (TTL=1) 224.0.0.2 on port 646. This discovery contains the router-id
and the transport IPv4 address the router wants to use. The second stage is building the TCP peering
session using the transport IP addresses specified. This is normally loopback to loopback.
Figure 23-34: LDP Peering Establishment
2.2.2.200
1 UDP PORT: S=646 D=646
IP S=I/F Address D=224.0.0.2 TTL=1
LCP: LSID=Router-ID IPv4 Trans TLB IP
2 Multi-hop TCP Session

ETH 1 ETH 25
Trans TLV IP <-> Trans TLV IP ETH 2
Normally Loopback to Loopback
ETH 1 ETH 25
1.1.1.200 4.4.4.200
ETH 2 ETH 26
ETH 2
ETH 1 ETH 26
3.3.3.200
Examples
• The show mpls ldp neighbor command on the North Edge router displays more detail on TCP
session establishment, and the local addresses of the LDP neighbor for which it is binding a label.
Note All connected interfaces are advertised as bound. However, EOS currently advertised labels for /32
addresses, and FEC filter is configured to install only x.x.x.200/32 prefixes.
North Edge.17:51:17#show mpls ldp neighbor

Peer LDP ID: 2.2.2.200:0; Local LDP ID: 1.1.1.200:0
TCP Connection: 2.2.2.200:38395 - 1.1.1.200:646
State: oper; Msgs sent/rcvd: 46/46; downstream unsolicited
Uptime: 0:06:17
KeepAlive expires in: 20.27 sec
LDP discovery sources:
Ethernet1/1
Addresses bound to peer:
2.2.2.200 2.2.2.2 192.168.1.177 192.168.62.11
192.168.1.181 192.168.58.12 192.168.60.11 192.168.61.11
Peer LDP ID: 3.3.3.200:0; Local LDP ID: 1.1.1.200:0
TCP Connection: 3.3.3.200:38510 - 1.1.1.200:646
State: oper; Msgs sent/rcvd: 42/42; downstream unsolicited
Uptime: 0:05:51
KeepAlive expires in: 20.02 sec
LDP discovery sources:
Ethernet2/1
1187
Addresses bound to peer:

192.168.65.11 192.168.59.12 3.3.3.200 192.168.60.12
192.168.63.11 3.3.3.3 192.168.64.11
• The show mpls lfib route 116384 command on the North Edge router displays the label POP and
swap operations for any traffic traversing North Edge. As can be seen if traffic came in with label
116384 it would be swapped to the labels seen in the tunnel table.
North Edge.23:38:28(config)#show mpls lfib route 116384
MPLS forwarding table (Label [metric] Vias) - 1 routes
MPLS next-hop resolution allow default route: False
Via Type Codes:
M - Mpls Via, P - Pseudowire Via,
I - IP Lookup Via, V - Vlan Via,
VA - EVPN Vlan Aware Via, ES - EVPN Ethernet Segment Via,
VF - EVPN Vlan Flood Via, AF - EVPN Vlan Aware Flood Via
Source Codes:
S - Static MPLS Route, B2 - BGP L2 EVPN,
B3 - BGP L3 VPN, P - Pseudowire,
L - LDP, IP - IS-IS SR Prefix Segment,
IA - IS-IS SR Adjacency Segment, IL - IS-IS SR Segment to LDP,
LI - LDP to IS-IS SR Segment, BL - BGP LU,
DE - Debug LFIB
L 116384 [1], 6.6.6.200/32

via M, 192.168.58.12, swap 132768
payload autoDecide, ttlMode autoDecide, apply egress-acl
interface Ethernet1/1
via M, 192.168.59.12, swap 100000
payload autoDecide, ttlMode autoDecide, apply egress-acl
1188
23.4.2 ISIS-SR
Figure 23-35 illustrates how ISIS-SR distributes the SID index information in the ISIS TLVs and
sub-TLVs
Figure 23-35: ISIS Neighbor Adj and TLVs
ISIS Neighbor P2P (IS-IS Hello PDUs) 2.2.2.200

P2P Hello (PDU Type 17)
TLVs (Area, ISIS Neighbor, IP Interface, etc)
135 - EXT IP Reach, 22 - TE ISIS Neighbor,
242 ISIS RTR Capability
1
SRGB SR Cap - TLV 242 Sub-TLV 2 ETH 1 ETH 25
Prefix SID TLV 135 Sub-TLV 3 ETH 2
ADJ SID TLV 22 Sub-TLV 31
2
ETH 1 ETH 25
1.1.1.200 4.4.4.200
ETH 2 ETH 26
ETH 2
ETH 1 ETH 26
3.3.3.200
The Prefix SID index, SRGB, and ADJ SID values are populated in the sub-TLVs in the ISIS neighbor
updates. Each router then builds its own database of Node (Prefix) segments (Labels) and locally
assigned ADJ labels.
1189
Examples
• The show isis neighbors detail command on the North Edge router displays the detailed
information of all ISIS neighbors.
north-edge#show isis neighbors detail
Instance VRF System Id Type Interface SNPA State Hold time Circuit Id
sr_instan default nw-core L2 Ethernet1/1 P2P UP 30 1D
Area Address(es): 49.0001
SNPA: P2P
Advertised Hold Time: 30
State Changed: 6d17h ago
IPv4 Interface Address: 192.168.58.12
IPv6 Interface Address: none
Interface name: Ethernet1/1
Graceful Restart: Supported
Segment Routing Enabled
Router ID: 2.2.2.2
SRGB Base: 408000 Range: 4096
Adjacency Label IPv4: 953252
sr_instan default sw-core L2 Ethernet2/1 P2P UP 28 1E
Area Address(es): 49.0001
SNPA: P2P
Advertised Hold Time: 30
State Changed: 00:06:06 ago
IPv4 Interface Address: 192.168.59.12
IPv6 Interface Address: none
Interface name: Ethernet2/1
Graceful Restart: Supported
Segment Routing Enabled
Router ID: 3.3.3.3
SRGB Base: 408000 Range: 4096
Adjacency Label IPv4: 953253
• The show isis segment-routing adjacency-segments command on the North Edge router
displays the locally assigned Adjacency Segment Identifier (Adj-SIDs).
North Edge#show isis segment-routing adjacency-segments
System ID: north-edge Instance: sr_instance

SR supported Data-plane: MPLS SR Router ID: 1.1.1.111
Adj-SID allocation mode: SR-adjacencies
Adj-SID allocation pool: Base: 953249 Size: 16384
Adjacency Segment Count: 5
Flag Descriptions: F: Ipv6 address family, B: Backup, V: Value
L: Local, S: Set
Segment Status codes: L1 - Level-1 adjacency, L2 - Level-2 adjacency, P2P - Point-to-Point adjacency, LAN -
Broadcast adjacency
Locally Originated Adjacency Segments

Adj IP Address Local Intf SID SID Source Flags Type
-------------------- ---------------- ------------ ---------------- ------------------------- ------
192.168.1.154 Et36/1 953249 Dynamic F:0 B:0 V:1 L:1 S:0 P2P L2
1190
23.4.3 BGP-LU (BGP-SR)

Figure 23-36 illustrates how BGP-LU distributes the label information in BGP.
Figure 23-36: BGP-LU Label Distribution
2.2.2.22
1 TCP PORT: D=179
RTID=Router ID AFI=1 SAFI=4
Multi-hop TCP Session
Trans TLV IP <-> Trans TLV IP
6.6.6.66 6.6.6.66 Normally Loopback to Loopback
L=132771 ETH 1 ETH 25 L=132771
ETH 2
6.6.6.66 6.6.6.66 4.6.6.6.66

L=10003 L=132771 L=3
ETH 1 ETH 25
1.1.1.11 6.6.6.66
ETH 2 ETH 26
6.6.6.66 6.6.6.66
L=10003 6.6.6.66 L=3
L=10001
ETH 2
6.6.6.66 ETH 1 ETH 26 4.6.6.6.66

L=10001 L=10001
3.3.3.33
Figure 23-37 illustrates how BGP-LU distributes the Label SRGB and SID index information in BGP.
This is known as BGP-SR.
Figure 23-37: BGP-SR Index and SRGB Distribution
2.2.2.200
1 TCP PORT: D=179
RTID=Router ID AFI=1 SAFI=4
SRGB SRGB Multi-hop TCP Session
eBGP-SR eBGP-SR Trans TLV IP <-> Trans TLV IP
6.6.6.66/32 6.6.6.66/32 Normally Loopback to Loopback
Label (SID 66) ETH 1 ETH 25 Label (SID 66)
ETH 2
SRGB SRGB SRGB

eBGP-SR eBGP-SR eBGP-SR
6.6.6.66/32 6.6.6.66/32 6.6.6.66/32
Label (SID 66) Label (SID 66) Label (SID 66)
ETH 1 ETH 25
1.1.1.200 4.4.4.200
ETH 2 ETH 26
SRGB SRGB
eBGP-SR eBGP-SR eBGP-SR
6.6.6.66/32 6.6.6.66/32 6.6.6.66/32
Label (SID 66) Label (SID 66) Label (SID 66)
SRGB
ETH 2
SRGB SRGB
eBGP-SR ETH 1 ETH 26 eBGP-SR
6.6.6.66/32 6.6.6.66/32
Label (SID 66) Label (SID 66)
3.3.3.200
1191
The Prefix SID index, and SRGB values are populated in the TLVs in the BGP neighbor updates. Each
router then builds its own database of Node (Prefix) segments (Labels).
Examples
• The show bgp neighbor command displays BGP-SR neighbors.
north-edge#show bgp neighbor | include BGP neighbor|Multiprotocol IPv4 MplsLabel
BGP neighbor is 192.168.2.10, remote AS 64512, internal link

Multiprotocol IPv4 MplsLabel: received
Multiprotocol IPv4 MplsLabel: advertised and received and negotiated
Multiprotocol IPv4 MplsLabel: advertised
BGP neighbor is 192.168.58.12, remote AS 2, external link
Multiprotocol IPv4 MplsLabel: advertised and received and negotiated
BGP neighbor is 192.168.59.12, remote AS 3, external link
• The show ip bgp labeled-unicast 6.6.6.66/32 detail command displays the detailed information
of BGP labeled routes unicast with 6.6.6.66/32.
north-edge(config-if-Et2/1)#show ip bgp labeled-unicast 6.6.6.66/32 detail
BGP routing table information for VRF default
Router identifier 1.1.1.111, local AS number 64512
BGP routing table entry for 6.6.6.66/32
Paths: 2 available
2 4 6
192.168.58.12 labels [ 200066 ] from 192.168.58.12 (2.2.2.222)
Origin IGP, metric -, localpref 100, weight 0, valid, external, ECMP head, best, ECMP contributor
Local MPLS label: 200066, SR Label Index: 66
3 4 6
192.168.59.12 labels [ 200066 ] from 192.168.59.12 (3.3.3.200)
Origin IGP, metric -, localpref 100, weight 0, valid, external, ECMP, ECMP contributor
Not best: ECMP-Fast configured
Local MPLS label: 200066, SR Label Index: 66
Advertised to 2 peers:
192.168.3.9 192.168.59.12
1192
Chapter 23: EVPN EVPN Type-5 Routes: IP Prefix Advertisement
23.5 EVPN Type-5 Routes: IP Prefix Advertisement

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

Inter-VRF local route leaking allows the leaking of routes from one VRF (the source VRF) to another
VRF (the destination VRF) on the same router. Inter-VRF routes can exist in any VRF (including the
default VRF) on the system. Routes can be leaked using the following methods:
• Inter-VRF local route leaking using BGP VPN
• Inter-VRF local route leaking using VRF-leak agent
23.6.1 Inter-VRF Local Route Leaking using BGP VPN

Inter-VRF local route leaking allows the user to export and import routes from one VRF to another on
the same device. This is implemented by exporting routes from a VRF to the local VPN table using
route target extended community list and then importing the same route target extended community
lists from the local VPN table into the target VRF. VRF route leaking is supported on VPN-IPv4,
VPN-IPv6, and EVPN types.
Figure 23-41: Inter-VRF Local Route Leaking using Local VPN Table
Accessing Shared Resources Across VPNs

To access shared resources across VPNs, all the routes from the shared services VRF must be leaked
into each of the VPN VRFs and customer routes must be leaked into the shared services VRF for return
traffic. Accessing shared resources allows one to export the route target of the shared services VRF
into all customer VRFs, and allows the shared services VRF to import route targets from customers A
and B. Figure 23-42 shows how to provide customers, corresponding to multiple VPN domains, access
to services like DHCP available in the shared VRF.
Route leaking across the VRFs is supported on VPN-IPv4, VPN-IPv6, and EVPN.
Figure 23-42: Accessing Shared Resources Across VPNs
1196
Chapter 23: EVPN Inter-VRF Local Route Leaking
23.6.1.1 Configuring Inter-VRF Local Route Leaking

Inter-VRF local route leaking is configured using VPN-IPv4, VPN-IPv6, and EVPN. Prefixes can be
exported and imported using any of the configured VPN types. Ensure that the same VPN type that is
exported is used while importing.
Leaking unicast IPv4 or IPv6 prefixes is supported and achieved by exporting prefixes locally to the
VPN table and importing locally from the VPN table into the target VRF on the same device as shown
in Figure 23-41 using the route-target command.
Exporting or importing the routes to or from the EVPN table is accomplished with the following two
methods:
• Using VXLAN for encapsulation
• Using MPLS for encapsulation
Using VXLAN for Encapsulation

To use VXLAN encapsulation type, ensure that VRF to VNI mapping is present and the interface status
for the VXLAN interface is up. This is the default encapsulation type for EVPN.
Example:
• The configuration for VXLAN encapsulation type is as follows:
switch(config)#router bgp 65001
switch(config-router-bgp)#address-family evpn
switch(config-router-bgp-af)#neighbor default encapsulation vxlan next-hop-self
source-interface Loopback0
switch(config)#hardware tcam
switch(config-hw-tcam)#system profile vxlan-routing
switch(config-hw-tcam)#interface Vxlan1
switch(config-hw-tcam-if-Vx1)#vxlan source-interface Loopback0
switch(config-hw-tcam-if-Vx1)#vxlan udp-port 4789
switch(config-hw-tcam-if-Vx1)#vxlan vrf vrf-blue vni 20001
switch(config-hw-tcam-if-Vx1)#vxlan vrf vrf-red vni 10001
1197
Using MPLS for Encapsulation

To use MPLS encapsulation type to export to the EVPN table, MPLS needs to be enabled globally on
the device and the encapsulation method needs to be changed from default type, that is VXLAN to
MPLS under the EVPN address-family sub-mode.
Example:
switch(config-router-bgp)#address-family evpn
switch(config-router-bgp-af)#neighbor default encapsulation mpls next-hop-self
source-interface Loopback0
23.6.1.2 Route-Distinguisher
Route-Distinguisher (RD) is used to uniquely identify routes from a particular VRF. Route distinguisher
is configured for every VRF from which routes are exported from or imported into.
The following commands are used to configure route distinguisher for a vrf.
Switch(config-router-bgp)#vrf vrf-services
Switch(config-router-bgp-vrf-vrf-services)#rd 1.0.0.1:1
Switch(config-router-bgp)#vrf vrf-blue
Switch(config-router-bgp-vrf-vrf-blue)#rd 2.0.0.1:2
23.6.1.3 Exporting Routes from a VRF

Use the route-target export command to export routes from a VRF to the local VPN or EVPN table
using the route target extended community list.
Examples
• These commands export routes from vrf-red to the local VPN table.
switch(config)#service routing protocols model multi-agent
switch(config)#mpls ip
switch(config-router-bgp)#vrf vrf-red
switch(config-router-bgp-vrf-vrf-red)#rd 1:1
switch(config-router-bgp-vrf-vrf-red)#route-target export vpn-ipv4 10:10
• These commands export routes from vrf-red to the EVPN table.
switch(config-router-bgp-vrf-vrf-red)#route-target export evpn 10:1
23.6.1.4 Importing Routes into a VRF

Use the route-target import command to import the exported routes from the local VPN or EVPN table
to the target VRF using the route target extended community list.
1198
Chapter 23: EVPN Inter-VRF Local Route Leaking
Examples
• These commands import routes from the VPN table to vrf-blue.
switch(config-router-bgp)#vrf vrf-blue
switch(config-router-bgp-vrf-vrf-blue)#rd 2:2
switch(config-router-bgp-vrf-vrf-blue)#route-target import vpn-ipv4 10:10
• These commands import routes from the EVPN table to vrf-blue.
switch(config-router-bgp-vrf-vrf-blue)#route-target import evpn 10:1
23.6.1.5 Exporting and Importing Routes using Route Map

To manage VRF route leaking, control the prefixes that are exported and imported with route-map
export or import commands. The route map is effective only if the VRF paths or the VPN paths are
already candidates for export or import. It is mandatory to have the route-target export or import
command configured first. Setting BGP attributes using route maps is effective only on the export end.
Note Prefixes that are leaked are not re-exported to the VPN table from the target VRF.
Examples
• These commands export routes from vrf-red to the local VPN table.
switch(config-router-bgp-vrf-vrf-red)#route-target export vpn-ipv4 route-map
EXPORT_V4_ROUTES_T0_VPN_TABLE
• These commands export routes to from vrf-red to the EVPN table.
switch(config-router-bgp-vrf-vrf-red)#route-target export evpn route-map
EXPORT_ROUTES_T0_EVPN_TABLE
1199

switch(config-router-bgp-vrf-vrf-blue)#route-target import vpn-ipv4 route-map
IMPORT_V4_ROUTES_VPN_TABLE
switch(config-router-bgp-vrf-vrf-blue)#route-target import evpn route-map
IMPORT_ROUTES_FROM_EVPN_TABLE
23.6.2 Inter-VRF Local Route Leaking using VRF-leak Agent

Inter-VRF local route leaking allows the leaking of routes from one VRF to another using route map as
a VRF-leak agent. VRFs are leaked based on the preferences assigned to each VRF.
23.6.2.1 Configuring Route Maps

Use router general command to configure route maps to leak routes from one VRF to another. Routes
in VRF “VRF1” that match the policy “RM1” are considered for leaking into VRF “VRF2”. If two or more
policies specify leaking the same prefix to the same destination VRF, then the route with a higher
(post-set-clause) distance and preference is chosen.
Example
• These commands configure a route-map to leak routes from “VRF1” to “VRF2” using a route-map
“RM1”.
switch(config)#router general
switch(config-router-general)#vrf VRF2
switch(config-router-general-vrf-VRF2)#leak routes source-vrf VRF1
subscribe-policy RM1
1200
Chapter 23: EVPN Configuring EVPN
23.7 Configuring EVPN

23.7.1 Configuring BGP-EVPN and VCS on CVX
23.7.1.1 Configuring BGP-EVPN
Configuring VNI Bundle

A vni-aware-bundle represents a MAC-VRF that contains Layer 2 route entries from all VXLAN Network
Identifiers (VNI) available across multiple DCs. Use the vni-aware-bundle command available on CVX
to create a MAC-VRF.
Note This command is not available on switches.
Example
cvx(config)#router bgp 100
cvx(config-router-bgp)#vni-aware-bundle bundle1
cvx(config-macvrf-bundle1)#
Configuring RD and RT in VNI Bundle

Use the rd (Router-BGP VRF and VNI Configuration Modes) command to add a Route Distinguisher
(RD) for uniquely identifying Layer 2 routes for the VNI bundle. Use the route-target command to
configure a well-known extended community that is attached to the routes exported by BGP-EVPN;
and to import routes with the specified well-known extended community into the MAC-VRF that
corresponds to the VNI bundle.
Example
cvx(config-macvrf-bundle1)# rd 530:12
cvx(config-macvrf-bundle1)# route-target both 530:12
Enabling Redistribution of Bridging Information

After the VNI aware bundle is created, use the redistribute service vxlan command to redistribute the
Layer 2 bridging information received from VCS.
Example
cvx(config-macvrf-bundle1)#redistribute service vxlan
Disabling Next-Hop Resolution in BGP-EVPN

When BGP-EVPN module receives a route from its BGP peer, it generally tries to resolve the next-hop
indicated in the route. However in the DCI topology, the routes coming from a CVX in another DC
contains next-hops (VTEP addresses) that may not be reachable from the CVX receiving the route. Use
the next-hop resolution disabled command to disable the next-hop resolution on routes received from
BGP-EVPN peers.
Note CVX is a part of the control plane and it is only connected to the VTEPs in its own DC. It does not have
IP connectivity to the VTEPs in a different DC.
1201
Configuring EVPN Chapter 23: EVPN
Example
cvx(config-router-bgp)#address-family evpn
cvx(config-router-bgp-af)#next-hop resolution disabled
23.7.1.2 Configuring VCS
Enabling Redistribution of BGP-EVPN Routes

Use the redistribute bgp evpn vxlan command to redistribute BGP-EVPN routes to VCS, which, in turn
advertises them to all VTEPs within the DC.
Example
cvx(config)#cvx
cvx(config-cvx)#no shutdown
cvx(config-cvx)#service vxlan
cvx(config-cvx-vxlan)#no shutdown
cvx(config-cvx-vxlan)#redistribute bgp evpn vxlan
1202
Chapter 23: EVPN Sample Configurations
23.8 Sample Configurations

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

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

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

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

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

vrf VRF-Blue
VRF Configuration: Leaf-21

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

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

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

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

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

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

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

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

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

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

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

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

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

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

!
!
vlan 10-11,20,210-211,220,111,2111
!
vlan 12-13
name VLAN-AWARE-BUNDLE-TENANT-A
!
vlan 212-213
name VLAN-AWARE-BUNDLE-TENANT-B
!
vrf instance tenant-a
!
vrf instance tenant-b
!
interface lan10
mtu 9164
vrf tenant-a
!
interface Vlan11
mtu 9164
vrf tenant-a
!
interface Vlan12
mtu 9164
vrf tenant-a
!
interface Vlan13
mtu 9164
vrf tenant-a
!
interface Vlan20
mtu 9164
vrf tenant-a
!
interface Vlan210
mtu 9164
vrf tenant-b
!
interface Vlan211
mtu 9164
vrf tenant-b
!
interface Vlan212
mtu 9164
vrf tenant-b
!
interface Vlan213
mtu 9164
1214
vrf tenant-b
!
interface Vlan220
mtu 9164
vrf tenant-b
!
interface Vlan1111
description Unique-highest-IP-in-each-IP-Vrf
mtu 9164
vrf tenant-a
ip address 223.255.255.249/30
!
interface Vlan2111
mtu 9164
vrf tenant-b
ip address 223.255.255.249/30
!
interface Vlan4093
ip address 172.168.11.1/30
1215
Leaf-21 VLAN and Distributed IP Address Configuration

!
!
vlan 10-11,20,210-211,220,111,2111
!
vlan 12-13
name VLAN-AWARE-BUNDLE-TENANT-A
!
vlan 212-213
name VLAN-AWARE-BUNDLE-TENANT-B
!
vrf instance tenant-a
!
vrf instance tenant-b
!
interface Vlan10
mtu 9164
vrf tenant-a
!
interface Vlan11
mtu 9164
vrf tenant-a
!
interface Vlan12
mtu 9164
vrf tenant-a
!
interface Vlan13
mtu 9164
vrf tenant-a
!
interface Vlan21
mtu 9164
vrf tenant-a
!
interface Vlan210
mtu 9164
vrf tenant-b
!
interface Vlan211
mtu 9164
vrf tenant-b
!
interface Vlan212
mtu 9164
vrf tenant-b
!
interface Vlan213
mtu 9164
1216
vrf tenant-b
!
interface Vlan221
mtu 9164
vrf tenant-b
!
interface Vlan1111
mtu 9164
vrf tenant-a
ip address 223.255.255.253/30
!
interface Vlan2111
mtu 9164
vrf tenant-b
ip address 223.255.255.253/30
!
interface Vlan4093
ip address 172.168.11.1/30
!
23.8.2.4 VXLAN Interface Configuration: Leaf-11 and Leaf-21

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This section describes configuring and verifying BGP VPN which has steps similar to the EVPN VXLAN
demonstration. Here, we examine BGP EVPN layer 3 VPN over LDP, Segment Routing (ISIS-SR), and
BGP-SR transport LSPs. This highlights the difference between the transport and the VPN overlay
service.
1236
23.8.3.1 Layer 3 VPN Over ISIS-SR

Figure 23-47 and Figure 23-48 illustrate the overview of combined control and data planes.
Figure 23-47: Control Plane Tenant-A Over ISIS-SR
NW-CORE
iBGP EVPN iBGP-EVPN

1.1.1.111 <-> 2.2.2.222 6.6.6.6 <-> 2.2.2.222
NORTH EDGE RR 2.2.2.222 SOUTH EDGE
AS 64512
TENANT-A TENANT-A
ISIS SR
ET 6/3.1 ET 6/3.1
ET 6/2.1
MPLS ET 6/2.1 eBGP Peering
eBGP Peering
192.168.168.8/30 192.168.168.4/30
192.168.168.12/30 192.168.168.0/30
ET 2.1 ET 2.1
ET 2.1 ET 2.1
7050SX 7050SX
DC1 DC1
Leaf 11 Leaf 12
DC1 DC1
Figure 23-48: Control Plane Tenant-B over ISIS-SR
NW-CORE
iBGP EVPN iBGP-EVPN

1.1.1.111 <-> 2.2.2.222 6.6.6.6 <-> 2.2.2.222
NORTH EDGE RR 2.2.2.222 SOUTH EDGE
AS 64512
TENANT-B TENANT-B
ISIS SR
ET 6/3.2 ET 6/2.2
ET 6/2.2 MPLS ET 6/3.2 eBGP Peering
eBGP Peering
192.168.168.20/31 192.168.168.18/31
192.168.168.16/31
192.168.168.22/31
ET 2.2 ET 2.2
ET 2.2 ET 2.2
7050SX 7050SX
DC1 DC1
Leaf 11 Leaf 12
DC1 DC1
1237
Figure 23-49: Control Plane & Forwarding Tenant-a Over ISIS-SR
eBGP Route IPv4 Unicast

(AFI=1, SAFI=1)
To other PEs
NRLI 100.10.11.0/24
NH 192.168.168.9 ISIS-SR
1.1.1.111/32
NH 1.1.1.111/32
CE SRGB 408000
Index 1 iBGP Route EVPN
6.6.6.6:408006 RR (AFI=25, SAFI=70) Route Type = 5
192.168.168.9
Ethernet Segment Identifier = 0
NRLI 6.6.6.6:6451 2:100.10.11.0/24
ISIS-SR NEXT HOP 6.6.6.6 LABEL 1040210
H1 --> H2 408006 2.2.2.2/32 Route-Target-AS:64512:11
Lo0 1.1.1.111 NH 2.2.2.2/32 Tunnel Encapsulation Type = MPLS
1040210 SRGB 408000
Index 2
H1 --> H2 To RR
6.6.6.6:408006 eBGP Route IPv4 Unicast
ISIS-SR ISIS-SR (AFI=1, SAFI=1)
4.4.4.4/32 6.6.6.6/32 NRLI 100.10.11.0/24
H1 408006 NH 4.4.4.4/32
SRGB 408000
NH 6.6.6.6/32
SRGB 408000
NH 192.168.168.5
1040210 Index 4 Index 6

H1 --> H2
6.6.6.6:3 CE
192.168.168.5
1040210 H1 --> H2
Loopback 0
H1 --> H2 6.6.6.6
100.10.11.0/24
H2
The North Edge router has an eBGP peering session out to leaf-11 and leaf-12 in DC1, while the South
Edge router has peerings to leaf-11 and leaf-12 in DC2. Tenant-a has few additional local interfaces
used for testing.
Example
• The show ip route vrf tenant-a connected command displays the interfaces assigned to the
tenant-a of North Edge router.
north-edge#show ip route vrf tenant-a connected
VRF: tenant-a
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route
C 192.168.168.8/30 is directly connected, Ethernet6/3.1

Activating EVPN
In all scenarios, the EVPN must be activated under BGP and neighbors configured to exchange Layer
2 VPN/EVPN NLRI.The tenant’s VRF (tenant-a and tenant-b) is associated with a dynamically
assigned label by BGP.
An activated EVPN provides the following functionalities:
• Enables the multi-agent routing protocol model, which is required for EVPN support.
1238
• Sets the local autonomous system number to 64512 and configures IBGP neighbors that are
activated for the Layer 2 VPN/EVPN address family.
• Sets the EVPN encapsulation type to MPLS.
• Specifies that Loopback0 will be used as the next-hop for all advertised EVPN routes. The underlay
configuration must provide MPLS LSPs from remote PEs to this loopback interface address.
Example
• The service routing protocols model multi-agent command activates EVPN on the north edge
router.
service routing protocols model multi-agent
router bgp 64512

router-id 1.1.1.111
neighbor 2.2.2.222 update-source Loopback0
neighbor 2.2.2.222 fall-over bfd
neighbor 2.2.2.222 send-community extended
!
address-family evpn
neighbor default encapsulation mpls next-hop-self source-interface Loopback0
neighbor default graceful-restart
neighbor 2.2.2.222 activate
!
Layer 3 Overlay Configuration

Distribution of layer 3 routes over BGP is enabled by configuring one or more IP VRFs under the router
bgp configuration mode. Additionally, IP routing must be enabled in the VRF.
The VRF is assigned a unique Route-Distinguisher (RD). The RD allows the PE to advertise EVPN
routes for the same IP prefix that have been exported by different VRFs. The NLRI RouteKey of a route
exported from the VRF’s IPv4 table into EVPN consists of both the RD and the original IP prefix.
The Route-Target (RT) extended communities for the VRF. The RTs are associated with all routes
exported from the VRF. Received EVPN type-5 routes carrying at least one RT matching the VRFs
configuration are imported into the VRF. The route target directives are configured under the IPv4 or
IPv6 address- family.
1239
Example
The vrf tenant-a and vrf tenant-a commands define overlay VRFs (tenant-a and tenant-b) on the
VTEP of North Edge router and enables IPv4 routing within them.
vrf tenant-a
rd 1.1.1.1:64512
route-target import evpn 64512:11
route-target export evpn 64512:11
router-id 1.1.1.111
neighbor 192.168.168.10 default-originate
neighbor 192.168.168.14 default-originate
redistribute connected
redistribute static
!
vrf tenant-b
rd 1.1.1.1:64513
route-target import evpn 64513:11
route-target export evpn 64513:11
router-id 1.1.1.111
redistribute static
!
Verifying BGP EVPN Layer 3 VPN

Show commands are executed in the North Edge router to view routes to the South Edge router.
Execute the same commands in the South Edge router to view vice-versa routes.
Examples
• The show bgp evpn summary command displays the status of EVPN peers in North Edge router.
north-edge#show bgp evpn summary
BGP summary information for VRF default
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State
PfxRcd PfxAcc
2.2.2.222 4 64512 195 127 0 0 01:13:31 Estab 78 78
• The show bgp evpn route-type ip-prefix ipv4 next-hop 6.6.6.6 command displays all BGP
EVPN ip prefix routes received from the South Edge router (6.6.6.6). Not all are advertised via the
RR 2.2.2.222.
1240
Note Each entry in the table represents a BGP path. The path specific information includes
Route-Distinguisher and IP prefix. Paths are either received from EVPN peers or exported from local
VRFs.
north-edge#show bgp evpn route-type ip-prefix ipv4 next-hop 6.6.6.6

Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric LocPref Weight Path

* > RD: 6.6.6.6:64512 ip-prefix 0.0.0.0/0
6.6.6.6 0 100 0 ? Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > RD: 6.6.6.6:64513 ip-prefix 0.0.0.0/0
6.6.6.6 0 100 0 ? Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > RD: 6.6.6.6:64514 ip-prefix 10.255.255.0/30
6.6.6.6 - 100 0 65010 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > RD: 6.6.6.6:64512 ip-prefix 100.10.10.0/24
6.6.6.6 - 100 0 65006 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > RD: 6.6.6.6:64513 ip-prefix 100.10.10.0/24
6.6.6.6 - 100 0 65006 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > RD: 6.6.6.6:64512 ip-prefix 100.10.10.103/32
6.6.6.6 - 100 0 65006 65005 65006 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > RD: 6.6.6.6:64512 ip-prefix 100.10.10.104/32
6.6.6.6 - 100 0 65006 65005 65006 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > RD: 6.6.6.6:64512 ip-prefix 100.10.11.0/24
6.6.6.6 - 100 0 65006 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > RD: 6.6.6.6:64513 ip-prefix 100.10.11.0/24
6.6.6.6 - 100 0 65006 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > RD: 6.6.6.6:64512 ip-prefix 100.10.11.103/32
6.6.6.6 - 100 0 65006 65005 65006 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > RD: 6.6.6.6:64512 ip-prefix 100.10.11.104/32
6.6.6.6 - 100 0 65006 65005 65006 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
<-------OUTPUT OMITTED FROM EXAMPLE-------->
• The show bgp evpn route-type ip-prefix 100.10.11.0/24 detail command displays a detailed
view of the IP prefix route for 100.10.11.0/24. The output again includes the RD and IP prefix
identifying the route. As seen above the route is received from the route reflector, and the VPN
label for tenant-a is 958810.
north-edge#show bgp evpn route-type ip-prefix 100.10.11.0/24 detail
BGP routing table entry for ip-prefix 100.10.11.0/24, Route Distinguisher: 6.6.6.6:64512
Paths: 1 available
65006
6.6.6.6 from 2.2.2.222 (2.2.2.222)
Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
Extended Community: Route-Target-AS:64512:11 TunnelEncap:tunnelTypeMpls
MPLS label: 958810
Paths: 1 available
65006
6.6.6.6 from 2.2.2.222 (2.2.2.222)
MPLS label: 953372
Note Tenant-a and tenant-b share the same route. Hence, both route with RD 6.6.6.6:64513 and RT
64513:11.
1241
• The show ip bgp vrf tenant-a command displays the BGP table for VRF in tenant-a containing
imported EVPN routes. Each entry in the table represent a BGP path that is either locally
redistributed / received into the VRF or imported from the EVPN table.
north-edge#show ip bgp vrf tenant-a
BGP routing table information for VRF tenant-a
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast

* > 0.0.0.0/0 6.6.6.6 0 100 0 ? Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* >Ec 10.10.10.0/24 192.168.168.14 - 100 0 65002 i
* ec 10.10.10.0/24 192.168.168.10 - 100 0 65002 i
* >Ec 10.10.10.103/32 192.168.168.14 - 100 0 65002 i
* ec 10.10.10.103/32 192.168.168.10 - 100 0 65002 i
* >Ec 10.10.10.104/32 192.168.168.14 - 100 0 65002 i
* >Ec 10.10.44.1/32 192.168.168.14 - 100 0 65002 i
* ec 10.10.44.1/32 192.168.168.10 - 100 0 65002 i
* > 100.10.10.0/24 6.6.6.6 - 100 0 65006 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > 100.10.10.103/32 6.6.6.6 - 100 0 65006 65005 65006 i Or-ID: 6.6.6.6
C-LST: 2.2.2.222
* > 100.10.10.104/32 6.6.6.6 - 100 0 65006 65005 65006 i Or-ID: 6.6.6.6
C-LST: 2.2.2.222
<-------OUTPUT OMITTED FROM EXAMPLE-------->C-LST: 2.2.2.222
* > 100.10.21.102/32 6.6.6.6 - 100 0 65006 65005 65006 i Or-ID: 6.6.6.6
C-LST: 2.2.2.222
* > 100.10.30.0/24 6.6.6.6 - 100 0 65006 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > 100.10.32.0/24 6.6.6.6 - 100 0 65006 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > 192.168.168.0/30 6.6.6.6 - 100 0 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > 192.168.168.4/30 6.6.6.6 - 100 0 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > 192.168.168.8/30 - - - 0 i
* Ec 192.168.168.8/30 192.168.168.14 - 100 0 65002 i
* ec 192.168.168.8/30 192.168.168.10 - 100 0 65002 i
* > 192.168.168.12/30 - - - 0 i
* Ec 192.168.168.12/30 192.168.168.14 - 100 0 65002 i
* ec 192.168.168.12/30 192.168.168.10 - 100 0 65002 i
* > 223.255.254.248/30 6.6.6.6 - 100 0 65006 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > 223.255.254.252/30 6.6.6.6 - 100 0 65006 65005 65006 i Or-ID: 6.6.6.6
C-LST: 2.2.2.222
* >Ec 223.255.255.248/30 192.168.168.14 - 100 0 65002 i
* ec 223.255.255.248/30 192.168.168.10 - 100 0 65002 i
* >Ec 223.255.255.252/30 192.168.168.14 - 100 0 65002 i
* ec 223.255.255.252/30 192.168.168.10 - 100 0 65002 i
Note EVPN routes are received from router 2.2.2.222 C-List (cluster list - basically identifying this route as
from a route-reflector) with originating router being 6.6.6.6.
1242
• The show ip route vrf tenant-b command displays the BGP table for VRF in tenant-b containing
imported EVPN routes.
north-edge#show ip route vrf tenant-b
VRF: tenant-b
Gateway of last resort:

B I 0.0.0.0/0 [200/0] via 6.6.6.6/32, IS-IS SR tunnel index 6, label 953372
via 192.168.58.12, Ethernet1/1, label 408006
B E 10.10.10.0/24 [200/0] via 192.168.168.22, Ethernet6/2.2

via 192.168.168.20, Ethernet6/3.2
B E 10.10.21.0/24 [200/0] via 192.168.168.22, Ethernet6/2.2
via 192.168.168.20, Ethernet6/3.2
B E 223.255.255.248/30 [200/0] via 192.168.168.22, Ethernet6/2.2
via 192.168.168.20, Ethernet6/3.2
B E 223.255.255.252/30 [200/0] via 192.168.168.22, Ethernet6/2.2
via 192.168.168.20, Ethernet6/3.2
Note If we look at the routes in the VRF for tenant-b, we see that the VPN label has now changed, whilst the
transport label for NH 6.6.6.6 is the same. The only difference seen in tenant-b, aside from the different
VPN label, is that there are no host-routes in tenant-b because within each DC tenant-b is running in
asymmetric mode, therefore no host routes are generated/installed in the IP VRF.
1243
23.8.3.2 Layer 3 EVPN Over LDP

Figure 23-50 and Figure 23-51 illustrate an overview of the combines control and data planes.
Figure 23-50: Control Plane Tenant-A Over LDP
NW-CORE
iBGP EVPN iBGP-EVPN

NORTH EDGE 1.1.1.111 <-> 2.2.2.222 6.6.6.6 <-> 2.2.2.222 SOUTH EDGE
RR 2.2.2.222
AS 64512
TENANT-A TENANT-A
ISIS SR
ET 6/3.1 ET 6/3.1
ET 6/2.1
MPLS ET 6/2.1
192.168.168.8/30 192.168.168.4/30
192.168.168.12/30 192.168.168.0/30
ET 2.1 ET 2.1
ET 2.1 ET 2.1
7050SX 7050SX
DC1 DC1
Leaf 11 Leaf 12
DC1 DC1
Figure 23-51: Control Plane Tenant-B over LDP
NW-CORE
iBGP EVPN iBGP-EVPN

1.1.1.111 <-> 2.2.2.222 6.6.6.6 <-> 2.2.2.222 SOUTH EDGE
NORTH EDGE RR 2.2.2.222
AS 64512
TENANT-B TENANT-B
LDP MPLS
ET 6/3.2 ET 6/2.2
ET 6/2.2 ET 6/3.2
192.168.168.20/31 192.168.168.18/31
192.168.168.16/31
192.168.168.22/31
ET 2.2 ET 2.2
ET 2.2 ET 2.2
7050SX 7050SX
DC1 DC1
Leaf 11 Leaf 12
DC1 DC1
1244
Figure 23-52: Control Plane & Forwarding Tenant-a Over LDP

(AFI=1, SAFI=1)
To other PEs
NRLI 100.10.11.0/24
NH 192.168.168.9
LDP
CE PE1 6.6.6.200/32
Label 920485 iBGP Route EVPN
RR (AFI=25, SAFI=70) Route Type = 5
192.168.168.9
NRLI 6.6.6.6:6451 2:100.10.11.0/24
NEXT HOP 6.6.6.200 LABEL 1040210
H1 --> H2 920485 Route-Target-AS:64512:11
Lo200 1.1.1.200 Tunnel Encapsulation Type = MPLS
1040210
LDP
H1 --> H2 6.6.6.200/32 To RR
Label 920486 eBGP Route IPv4 Unicast
(AFI=1, SAFI=1)
920486 NRLI 100.10.11.0/24
H1 1040210
NH 192.168.168.5
H1 --> H2 LDP
6.6.6.200/32
Label 3
CE
192.168.168.5
1040210 H1 --> H2
Loopback 200
H1 --> H2 6.6.6.200
100.10.11.0/24
H2
To switch to using the MPLS LDP transport, we simply need to change the next-hop advertised for
EVPN routes. As per Figure 23-51, the next hop needs to be set to loopback 200 to use the LDP LSP.
This is simply achieved by configuring the next-hop for EVPN routes on both North Edge and South
Edge routes. The output again includes the RD and IP prefix identifying the route. As seen in the output,
we now have the NH set to 6.6.6.200 for tenant-a and tenant-b.
router bgp 64512
!
address-family evpn
Once this is configured, we can check the BGP updates and the routes in the VRF.
north-edge# show bgp evpn route-type ip-prefix 100.10.11.0/24 detail
Paths: 1 available
65006
6.6.6.200 from 2.2.2.222 (2.2.2.222)
MPLS label: 958810
Paths: 1 available
65006
6.6.6.200 from 2.2.2.222 (2.2.2.222)
MPLS label: 953372
Note Again, we have the same route in tenant-a and tenant-b in DC2. Hence, the two other routes with RD
6.6.6.6:64513 and RT 64513:11. The VPN label has not changed, reinforcing the fact that the BGP
VPN label is orthogonal to the transport label.
1245
Finally, let us look at the routes in the VRF tenant-a.

north-edge#show ip route vrf tenant-a
VRF: tenant-a
R - RIP, I L1 - IS-IS ----level 1, I L2 - IS-IS level 2,

B I 0.0.0.0/0 [200/0] via 6.6.6.200/32, LDP tunnel index 1, label 958810
B E 10.10.10.103/32 [200/0] via 192.168.168.14, Ethernet6/2.1

via 192.168.168.10, Ethernet6/3.1
B E 10.10.10.104/32 [200/0] via 192.168.168.14, Ethernet6/2.1
via 192.168.168.10, Ethernet6/3.1
B E 223.255.255.248/30 [200/0] via 192.168.168.14, Ethernet6/2.1
via 192.168.168.10, Ethernet6/3.1
B E 223.255.255.252/30 [200/0] via 192.168.168.14, Ethernet6/2.1
via 192.168.168.10, Ethernet6/3.1
Note As can be seen from the highlighted route above the label stack, the route has the same VPN route
958810, but the transport labels are now 904097 and 904098 on top (this is the ECMP label path to
reach NH 6.6.6.200).
1246
As a comparison, let us look at the routes for tenant-b.

VRF: tenant-b

B E 10.10.10.0/24 [200/0] via 192.168.168.22, Ethernet6/2.2

via 192.168.168.20, Ethernet6/3.2
via 192.168.168.20, Ethernet6/3.2
B E 223.255.255.248/30 [200/0] via 192.168.168.22, Ethernet6/2.2
via 192.168.168.20, Ethernet6/3.2
B E 223.255.255.252/30 [200/0] via 192.168.168.22, Ethernet6/2.2
Note The only difference apart from the missing host routes (no host-route inject for this tenant), is the VPN
label.
1247
23.8.3.3 Layer 3 EVPN Over BGP-SR

Figure 23-53 and Figure 23-54 illustrate an overview of the combined control and data planes.
Figure 23-53: Control Plane Tenant-a Over BGP-SR
AS 2 AS 4
EBGP-SR
NW-CORE NE-CORE
BGP EVPN
EBGP-SR AS 64512
iBGP-EVPN iBGP-EVPN
AS 1 1.1.1.111 <-> 2.2.2.222 6.6.6.6 <-> 2.2.2.222 AS 6
EBGP-SR EBGP-SR EBGP-SR EBGP-SR

TENANT-A TENANT-A
EBGP-SR
ET 6/3.1 ET 6/3.1
ET 6/2.1 ET 6/2.1
eBGP Peering eBGP Peering
192.168.168.8/30 BGP-SR 192.168.168.4/30
192.168.168.12/30 MPLS 192.168.168.0/30
ET 2.1 SW-CORE SE-CORE ET 2.1
EBGP-SR
ET 2.1 AS 3 AS 5 ET 2.1
7050SX 7050SX
DC1 DC1
Leaf 11 Leaf 12
DC1 DC1
Figure 23-54: Control Plane Tenant-b Over BGP-SR
AS 2 AS 4
EBGP-SR
NW-CORE NE-CORE
BGP EVPN
EBGP-SR AS 64512
iBGP-EVPN iBGP-EVPN
AS 1 1.1.1.111 <-> 2.2.2.222 6.6.6.6 <-> 2.2.2.222 AS 6
EBGP-SR EBGP-SR EBGP-SR EBGP-SR

TENANT-B TENANT-B
EBGP-SR
ET 6/3.2 ET 6/2.2
ET 6/2.2 ET 6/3.2
192.168.168.20/31 BGP-SR 192.168.168.18/31
192.168.168.22/31 MPLS 192.168.168.16/31
ET 2.2 SW-CORE SE-CORE ET 2.2
EBGP-SR
ET 2.2 AS 3 AS 5 ET 2.2
7050SX 7050SX
DC1 DC1
Leaf 11 Leaf 12
DC1 DC1
1248
Figure 23-55: Control Plane & Forwarding Tenant-a Over BGP-SR

(AFI=1, SAFI=1)
To other PEs
NRLI 100.10.11.0/24
NH 192.168.168.9
BGP-SR
6.6.6.66/32
CE PE1 Index 66
SRGB 200000 iBGP Route EVPN
RR (AFI=25, SAFI=70) Route Type = 5
192.168.168.9
NRLI 6.6.6.6:6451 2:100.10.11.0/24
NEXT HOP 6.6.6.66 LABEL 1040210
H1 --> H2 200066 Route-Target-AS:64512:11
Lo1 1.1.1.11 Tunnel Encapsulation Type = MPLS
1040210
BGP-SR
H1 --> H2 6.6.6.66/32 To RR
Index 66 eBGP Route IPv4 Unicast
200066 SRGB 200000 (AFI=1, SAFI=1)
NRLI 100.10.11.0/24
H1 1040210
BGP-SR
NH 192.168.168.5
H1 --> H2 6.6.6.66/32
Index 66 [IMPL NULL] CE
SRGB 200000
192.168.168.5
1040210 H1 --> H2
Loopback 1
H1 --> H2 6.6.6.66
100.10.11.0/24
H2
To switch to using the MPLS BGP-SR transport, we simply need to change the next-hop advertised for
the EVPN routes. As per Figure 23-54, the next hop needs to be set to loopback 1 for using the
BGP-SR LSP. This is achieved by configuring the next-hop for the EVPN routes.
router bgp 64512
!
address-family evpn
Once the next-hop for the EVPN routes are configured, we can check the BGP updates and the routes
in the VRF. The output again includes the RD and IP prefix identifying the route. As seen in the output,
we now have the NH set to 6.6.6.66 for tenant-a and tenant-b.
North Edge.17:52:30#show bgp evpn route-type ip-prefix 100.10.11.0/24 detail
north-edge(config-if-Et2/1)#show bgp evpn route-type ip-prefix 100.10.11.0/24 detail
Paths: 1 available
65006
6.6.6.66 from 2.2.2.222 (2.2.2.222)
MPLS label: 958810
Paths: 1 available
65006
6.6.6.66 from 2.2.2.222 (2.2.2.222)
MPLS label: 953372
Note Again, we have the same route in tenant-a and tenant-b in DC2. Hence, the two other routes with RD
6.6.6.6:64513 and RT 64513:11. The VPN label has not changed, reinforcing the fact that the BGP
VPN label is orthogonal to the transport label.
1249
Finally, let us look at the routes in the VRF tenant-a.

North Edge.17:55:01#show ip route vrf tenant-a
VRF: tenant-a

B I 0.0.0.0/0 [200/0] via 6.6.6.66/32, BGP LU tunnel index 8, label 958810
B E 10.10.10.103/32 [200/0] via 192.168.168.14, Ethernet6/2.1

via 192.168.168.10, Ethernet6/3.1
B E 10.10.10.104/32 [200/0] via 192.168.168.14, Ethernet6/2.1
via 192.168.168.10, Ethernet6/3.1
via 192.168.168.10, Ethernet6/3.1
B E 223.255.255.248/30 [200/0] via 192.168.168.14, Ethernet6/2.1
via 192.168.168.10, Ethernet6/3.1
B E 223.255.255.252/30 [200/0] via 192.168.168.14, Ethernet6/2.1
via 192.168.168.10, Ethernet6/3.1
As can be seen from the highlighted route above the label stack, the route are the transport labels
958810 and 200066 on top (this is the ECMP label path to reach NH 6.6.6.66), with the tenant-a VPN
label 958810 next in the stack, identifying the route as belonging to tenant-a.
As a comparison, let us look at the routes for tenant-b. As seen in the output, the VPN label assigned
to tenant-b is 953372.
north-edge#show bgp evpn route-type ip-prefix 100.10.11.0/24 detail
Paths: 1 available
65006
6.6.6.66 from 2.2.2.222 (2.2.2.222)
MPLS label: 958810
Paths: 1 available
65006
6.6.6.66 from 2.2.2.222 (2.2.2.222)
MPLS label: 953372
north-edge#
1250
If we now look at the routes in the VRF for tenant-b, we see that the VPN label has now changed, whilst
the transport label (for NH 6.6.6.66 is the same). The only difference seen in tenant-b, aside from the
different VPN label, is that there are no host-routes in tenant-b because within each DC tenant-b is
running in asymmetric mode, therefore no host routes are generated/installed in the IP VRF.
VRF: tenant-b

B E 10.10.10.0/24 [200/0] via 192.168.168.22, Ethernet6/2.2

via 192.168.168.20, Ethernet6/3.2
B E 10.10.21.0/24 [200/0] via 192.168.168.22, Ethernet6/2.2
via 192.168.168.20, Ethernet6/3.2
B E 223.255.255.248/30 [200/0] via 192.168.168.22, Ethernet6/2.2
via 192.168.168.20, Ethernet6/3.2
B E 223.255.255.252/30 [200/0] via 192.168.168.22, Ethernet6/2.2
via 192.168.168.20, Ethernet6/3.2
23.8.4 IP VPNs Sample Configuration

Here, we examine BGP EVPN layer 3 VPN over an LDP, ISIS-SR, and BGP-SR transport LSPs. This
highlights the separation between the transport and the VPN overlay service.
1251
Figure 23-56 and Figure 23-57 illustrate the sample VPN Physical Topology.
Figure 23-56: IPv4 VPN Physical Topology
LDP
NW-CORE RR NE-CORE
NW Core Lo200: 2.2.2.200
ETH 25 192.168.61.0/24 ETH 25 SW Core Lo200: 3.3.3.200
NE Core Lo200: 4.4.4.200
ETH 1 ETH 1 SE Core Lo200: 5.5.5.200
192.168.58.0/24 ETH 2 ETH 26 ETH 26 ETH 4 192.168.67.0/24
192.168.63.0/24
192.168.68.0/24
ETH 1 192.168.62.0/24 ETH 1
ETH 2
IS-IS SR
192.168.60.0/24 LDP 192.168.66.0/24
BGP-SR
192.168.63.0/24
ET 6/1.120 CE ET 6/1.620
192.168.59.0/24 192.168.69.0/24
ETH 26 ETH 26
ETH 2 ETH 4
10.255.255.0/30 10.255.255.4/30
ETH 1 ETH 3
ETH 25 192.168.64.0/24 ETH 25
VL 120 10.255.255.2/30 ETH 27 192.168.65.0/24 ETH 27

SW-CORE SE-CORE VL 620 10.255.255.6/30
VL 121 201.0.0.1/24
VL 621 206.0.0.1/24
CE CE
BGP-SR ISIS-SR
NW Core Lo1: 2.2.2.22 NW Core Lo0: 2.2.2.2
Figure 23-57: IPv6 VPN Physical Topology
LDP
NW-CORE RR NE-CORE
NW Core Lo200: 2.2.2.200
ETH 25 192.168.61.0/24 ETH 25 SW Core Lo200: 3.3.3.200
NE Core Lo200: 4.4.4.200
ETH 1 ETH 1 SE Core Lo200: 5.5.5.200
192.168.58.0/24 ETH 2 ETH 26 ETH 26 ETH 4 192.168.67.0/24
192.168.63.0/24
192.168.68.0/24
ETH 1 192.168.62.0/24 ETH 1
ETH 2
IS-IS SR
192.168.60.0/24 LDP 192.168.66.0/24
BGP-SR
192.168.63.0/24
ET 6/1.120 CE ET 6/1.620
192.168.59.0/24 192.168.69.0/24
ETH 26 ETH 26
ETH 2 ETH 4
2010::0/126 2010::4/30
ETH 1 ETH 3
ETH 25 192.168.64.0/24 ETH 25
ETH 27 192.168.65.0/24 ETH 27

VL120 2010::1/126 SW-CORE SE-CORE VL620 2010::6/126
VL121 2201::1/64 VL621 2201::6/64

CE CE
BGP-SR ISIS-SR
NW Core Lo1: 2.2.2.22 NW Core Lo0: 2.2.2.2
1252
23.8.4.1 IP VPN over ISIS-SR

Figure 23-58 illustrates an overview of the combined control and data planes.
Figure 23-58: IPv4 VPN and IPv6 VPN Over ISIS-SR MPLS
IPv4 VPN
NW-CORE
iBGP-IPv4 VPN RR 2.2.2.222 iBGP-IPv4 VPN

1.1.1.111 <-> 2.2.2.222 6.6.6.6 <-> 2.2.2.222
NORTH EDGE AS 64512 SOUTH EDGE
IS-IS SR
TENANT-D MPLS TENANT-A
ET 6/1.120 ET 6/1.620
10.255.255.0/30 10.255.255.4/30
VL120 10.255.255.2/30 VL620 10.255.255.6/30
VL121 201.0.0.1/24 VL621 206.0.0.1/24
CE CE
IPv6 VPN
NW-CORE

1.1.1.111 <-> 2.2.2.222 6.6.6.6 <-> 2.2.2.222
IS-IS SR
ET 6/1.120 ET 6/1.620
2010::6/126 2010::4/30
VL120 2010::1/126 VL620 2010::6/126
VL121 2201::1/64 VL621 2201::6/64
CE CE
1253
Figure 23-59 and Figure 23-60 illustrate the forwarding path and control plane for both IP traffic over
ISIS MPLS segment routing.
Figure 23-59: IPv4 VPN Forwarding Over ISIS-SR MPLS

(AFI=1, SAFI=1)
To other PEs
NRU 206.0.0.0/24
NH 10.255.255.5 ISIS-SR
1.1.1.111/32
NH 1.1.1.111/32
CE SRGB 408000
Index 1
6.6.6.6:408006 RR
10.255.255.5 iBGP Route IPv4 VPN
(AFI=1, SAFI=128)
ISIS-SR NRU 6.6.6.6:6451 4:206.0.0.0/24
408006 2.2.2.2/32 LABEL 967920 NEXT HOP 6.6.6.6
H1 --> H2 Route-Target-AS:64512:4364
Lo0 1.1.1.111 NH 2.2.2.2/32
967920 SRGB 408000
Index 2
H1 --> H2 To RR
4.4.4.4/32 6.6.6.6/32 NRU 206.0.0.0/24
H1 408006 NH 4.4.4.4/32
SRGB 408000
NH 6.6.6.6/32
SRGB 408000
NH 10.255.255.2

H1 --> H2
6.6.6.6:3 CE
10.255.255.2
967920 H1 --> H2
Loopback 0
H1 --> H2 6.6.6.6
206.0.0.0/24
H2
Figure 23-60: IPv6 VPN Forwarding Over ISIS-SR MPLS

(AFI=2, SAFI=1)
To other PEs
NRU 2206::/64
NH 2010::5 ISIS-SR
1.1.1.111/32
NH 1.1.1.111/32
CE SRGB 408000
Index 1
6.6.6.6:408006 RR
2010::5 iBGP Route IPv6 VPN
(AFI=2, SAFI=128)
ISIS-SR NRU 6.6.6.6:6451 4:2206::/64
408006 2.2.2.2/32 LABEL 965242 NEXT HOP 6.6.6.6
Lo0 1.1.1.111 NH 2.2.2.2/32
965242 SRGB 408000
Index 2
H1 --> H2 To RR
4.4.4.4/32 6.6.6.6/32 NRU 2206::/64
H1 408006 NH 4.4.4.4/32
SRGB 408000
NH 6.6.6.6/32
SRGB 408000
NH 2010::2

H1 --> H2
6.6.6.6:3 CE
2010::2
965242 H1 --> H2
Loopback 0
H1 --> H2 6.6.6.6
2206::/64
H2
View IPv4 and IPv6 Routes in the VRF

Both North Edge and South Edge routers have an eBGP peering session out to the CE; and learning
routes from CE and remote PE.
1254
• The show ip route vrf tenant-d command displays IPv4 Routes in the VRF of North Edge.
north-edge#show ip route vrf tenant-d
VRF: tenant-d
Gateway of last resort is not set

B E 201.0.0.0/24 [200/0] via 10.255.255.6, Ethernet6/1.120
• The show ip route vrf tenant-d command displays IPv4 Routes in the VRF of South Edge.
south-edge#show ip route vrf tenant-d
VRF: tenant-d

B E 206.0.0.0/24 [200/0] via 10.255.255.2, Ethernet6/1.620
• The show ipv6 route vrf tenant-d command displays IPv6 Routes in the VRF of North Edge.
north-edge#show ipv6 route vrf tenant-d
VRF: tenant-d
Displaying 4 of 7 IPv6 routing table entries
Codes: C - connected, S - static, K - kernel, O3 - OSPFv3, B - BGP, R - RIP, A B - BGP Aggregate, I L1 -
IS-IS level 1, I L2 - IS-IS level 2, DH - DHCP, NG - Nexthop Group Static Route, M - Martian, DP - Dynamic
Policy Route
B 2010::/126 [200/0]
via 6.6.6.6/32, IS-IS SR tunnel index 6, label 965242
C 2010::4/126 [0/0]
via Ethernet6/1.120, directly connected
B 2201::/64 [200/0]
via 2010::6, Ethernet6/1.120
B 2206::/64 [200/0]
1255
• The show ipv6 route vrf tenant-d command displays IPv6 Routes in the VRF of South Edge.
south-edge#show ipv6 route vrf tenant-d
VRF: tenant-d
Policy Route
C 2010::/126 [0/0]
B 2010::4/126 [200/0]
B 2201::/64 [200/0]
B 2206::/64 [200/0]
via 2010::2, Ethernet6/1.620
Activating IP VPN
In all scenarios, the IP VPN must be activated under BGP and neighbors configured to exchange the
IP VPN NLRIs.The tenant’s VRF (tenant-d) is associated with a dynamically assigned label by BGP.
North Edge
router bgp 64512

router-id 1.1.1.111
!
address-family vpn-ipv4
!
!
South Edge
router bgp 64512

router-id 6.6.6.6
!
!
!
The configuration above provides the following.

It enables the multi-agent routing protocol model, which is required for BGP VPN support.
It sets the local autonomous system number to 64512 and configured the route-reflector for both IPv4
VPN and IPv6 VPN capabilities.
1256
It sets the IP VPN encapsulation type to MPLS (default).

It specifies that Loopback0 will be used as the next-hop for all advertised VPN routes. The underlay
configuration must provide MPLS LSPs from remote PEs to this loopback interface address.
Layer 3 Overlay Configuration

Distribution of Layer 3 routes over BGP is enabled by configuring one or more IP VRFs under the router
bgp configuration mode. Additionally, either IPv4 or IPv6 routing must be enabled in the VRF.
• Configure IP VRF in the North Edge router.
vrf definition tenant-d
ip routing vrf tenant-d
ipv6 unicast-routing vrf tenant-d
!
router bgp 64512
vrf tenant-d
rd 1.1.1.1:64514
route-target import vpn-ipv4 64512:4364
route-target export vpn-ipv4 64512:4364
neighbor 2010::6 remote-as 65011
neighbor 2010::6 maximum-routes 12000
!
address-family ipv6
neighbor 2010::6 activate
!
• Configure IP VRF in the South Edge router.
vrf definition tenant-d
ip routing vrf tenant-d
ipv6 unicast-routing vrf tenant-d
!
router bgp 64512
vrf tenant-d
rd 6.6.6.6:64514
neighbor 2010::2 remote-as 65010
neighbor 2010::2 maximum-routes 12000
!
address-family ipv6
neighbor 2010::2 activate
!
These IP VRF configurations provide the following functionalities:

• It defines overlay VRFs (tenant-d) on the PE and enables IP unicast routing.
• The VRF is assigned a unique Route-Distinguisher (RD). The RD allows the PE to advertise VPN
routes for the same IP prefix that have been exported by different VRFs. The NLRI RouteKey of a
route exported from the VRFs IPv4 table into VPN consists of both the RD and the original IP prefix.
• The Route-Target (RT) extended communities for the VRF. The RTs are associated with all routes
exported from the VRF. Received VPN routes carrying at least one RT matching the VRFs
configuration are imported into the VRF.
1257
Verifying IP VPNs over ISIS-SR

• The show bgp vpn-ipv4 summary command displays the status of the VPN IP peers in the North
Edge router with the BGP VPN enabled.
north-edge#show bgp vpn-ipv4 summary
PfxRcd PfxAcc
2.2.2.222 4 64512 172 45 0 0 00:17:16 Estab 2 2
north-edge# sh bgp vpn-ipv6 summary
PfxRcd PfxAcc
2.2.2.222 4 64512 172 45 0 0 00:17:20 Estab 2 2
• The show bgp vpn-ipv4 command displays routes sent and received through IP VPN.
north-edge#show bgp vpn-ipv4

* > RD: 6.6.6.6:64514 IPv4 prefix 10.255.255.0/30
6.6.6.6 - 100 0 65010 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > RD: 1.1.1.1:64514 IPv4 prefix 10.255.255.4/30
- - 100 0 65011 i
* > RD: 1.1.1.1:64514 IPv4 prefix 201.0.0.0/24
- - 100 0 65011 i
* > RD: 6.6.6.6:64514 IPv4 prefix 206.0.0.0/24
6.6.6.6 - 100 0 65010 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
north-edge#show bgp vpn-ipv6


* > RD: 6.6.6.6:64514 IPv6 prefix 2010::/126
6.6.6.6 - 100 0 65010 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > RD: 1.1.1.1:64514 IPv6 prefix 2010::4/126
- - 100 0 65011 i
* > RD: 1.1.1.1:64514 IPv6 prefix 2201::/64
- - 100 0 65011 i
* > RD: 6.6.6.6:64514 IPv6 prefix 2206::/64
6.6.6.6 - 100 0 65010 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
Note Each entry in the table represents a BGP path. The path specific information includes the
Route-Distinguisher and the IP prefix. Paths are either received from VPN peers or exported from local
VRFs.
1258
• The show bgp vpn-ipv4 206.0.0.0/24 detail and show bgp vpn-ipv6 2206::/64 detail commands
display detailed view of the IP prefix route for 206.0.0.0/24 and 2206.::/64 of the North Edge router.
north-edge#show bgp vpn-ipv4 206.0.0.0/24 detail
BGP routing table entry for IPv4 prefix 206.0.0.0/24, Route Distinguisher: 6.6.6.6:64514
Paths: 1 available
65010
6.6.6.6 from 2.2.2.222 (2.2.2.222)
Extended Community: Route-Target-AS:64512:4364
MPLS label: 967920
north-edge#show bgp vpn-ipv6 2206::/64 detail

BGP routing table entry for IPv6 prefix 2206::/64, Route Distinguisher: 6.6.6.6:64514
Paths: 1 available
65010
6.6.6.6 from 2.2.2.222 (2.2.2.222)
MPLS label: 965242
Note The output includes the RD and IP prefix identifying the route. As seen in the output, the IPv4 VPN
route is received from 2.2.2.222 because it is set-up to be a route-reflector, but the next hop is 6.6.6.6.
Both are advertised with tenant VPN label 967920 and 965242 and an RT.
• The show ip bgp vrf tenant-d command displays the BGP table for the VRF containing the
imported EVPN routes.
north-edge#show ip bgp vrf tenant-d
BGP routing table information for VRF tenant-d
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
* >Ec 10.255.255.0/30 6.6.6.6 - 100 0 65010 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* ec 10.255.255.0/30 6.6.6.6 - 100 0 65010 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* > 10.255.255.4/30 10.255.255.6 - 100 0 65011 i
* > 201.0.0.0/24 10.255.255.6 - 100 0 65011 i
* >Ec 206.0.0.0/24 6.6.6.6 - 100 0 65010 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
* ec 206.0.0.0/24 6.6.6.6 - 100 0 65010 i Or-ID: 6.6.6.6 C-LST: 2.2.2.222
Note Each entry in the table represent a BGP path that is either locally redistributed and received into the
VRF or imported from the IPv4 VPN table. VPN routes are received from router 2.2.2.222 C-List
(cluster list - basically identifying this route as from a route-reflector) with originating router being
6.6.6.6.
1259
Finally, let us look at the routes in the VRF tenant-d.
VRF: tenant-d

B E 201.0.0.0/24 [200/0] via 10.255.255.6, Ethernet6/1.120
Note As displayed in the highlighted route above the label stack, the route is the transport label 408006 on
top (this is the label to reach NH 6.6.6.6), with the tenant-a VPN label 967920 next in the stack,
identifying the route as belonging to tenant-d.
A check of the Tunnel FIB confirms that 408006 is the ISIS-SR LSP.
north-edge#show mpls tunnel fib
! 'show mpls tunnel fib' has been deprecated. Please use 'show tunnel fib [options]' moving forward.
Tunnel Type Index Endpoint Nexthop Interface Labels Forwarding
------------------- --------- ------------------ ------------------- ------------------ ----------------
IS-IS SR IPv4 9 2.2.2.22/32 192.168.58.12 Ethernet1/1 [ 3 ] None
LDP 4 2.2.2.200/32 192.168.58.12 Ethernet1/1 [ 3 ] None
BGP LU 5 3.3.3.33/32 192.168.58.12 Ethernet1/1 [ 200033 ] None
IS-IS SR IPv4 3 5.5.5.5/32 192.168.58.12 Ethernet1/1 [ 408005 ] Primary
1260
23.8.4.2 IP VPNs Over LDP

Figure 23-61, Figure 23-62, and Figure 23-63 illustrate an overview of the combined control and data
planes.
Figure 23-61: IPv4 VPN and IPv6 VPN Over LDP MPLS
IPv4 VPN
NW-CORE

1.1.1.111 <-> 2.2.2.222 6.6.6.6 <-> 2.2.2.222
LDP
ET 6/1.120 ET 6/1.620
10.255.255.0/30 10.255.255.4/30
VL120 10.255.255.2/30 VL620 10.255.255.6/30
VL121 201.0.0.1/24 VL621 206.0.0.1/24
CE CE
IPv6 VPN
NW-CORE

1.1.1.111 <-> 2.2.2.222 6.6.6.6 <-> 2.2.2.222
LDP
ET 6/1.120 ET 6/1.620
2010::6/126 2010::4/30
VL120 2010::1/126 VL620 2010::6/126
VL121 2010::1/64 VL621 2201::6/64
CE CE
1261
Figure 23-62: IPv4 VPN Forwarding Over LDP MPLS

(AFI=1, SAFI=1)
To other PEs
NRLI 206.0.0.0/24
NH 10.255.255.5
LDP
CE PE1 6.6.6.200/32
Label 920485
RR
(AFI=1, SAFI=128)
NRLI 6.6.6.6:64514 206.0.0.0/24
920485 LABEL 967920 NEXT HOP 6.6.6.200
Lo200 1.1.1.200
967920
LDP
H1 --> H2 6.6.6.200/32 To RR
(AFI=1, SAFI=1)
920486 NRU 206.0.0.0/24
H1 967920
NH 10.255.255.2
H1 --> H2 LDP
6.6.6.200/32
Label 3
CE
10.255.255.2
967920 H1 --> H2
Loopback 200
H1 --> H2 6.6.6.200
206.0.0.0/24
H2
Figure 23-63: IPv6 VPN Forwarding Over LDP MPLS

(AFI=2, SAFI=1)
To other PEs
NRU 2206::/64
NH 2010::5
LDP
CE PE1 6.6.6.200/32
Label 920485
RR
(AFI=2, SAFI=128)
NRU 6.6.6.6:6451 4:2206::/64
920485 LABEL 965242 NEXT HOP 6.6.6.200
Lo200 1.1.1.200
965242
LDP
H1 --> H2 6.6.6.200/32 To RR
(AFI=2, SAFI=1)
920486 NRU 2206::/64
H1 965242
NH 2010::2
H1 --> H2 LDP
6.6.6.200/32
Label 3
CE
2010::2
965242 H1 --> H2
Loopback 200
H1 --> H2 6.6.6.200
2206::/64
H2
To switch to using the MPLS LDP transport, we just need to change the next-hop we advertised for the
VPN routes. As per Figure 23-62 and Figure 23-63, the next hop needs to be set to loopback 200 for
using the LDP LSP.
This is achieved by configuring the next-hop for the EVPN routes on both north and south edge routers.
router bgp 64512
!
address-family evpn
1262
Once this is configured, we can check the BGP updates and the routes in the VRF. The output again
includes the RD and IP prefix identifying the route. We now have the NH set to 6.6.6.200 for tenant-d.
Paths: 1 available
65010
6.6.6.200 from 2.2.2.222 (2.2.2.222)
MPLS label: 967920
north-edge#
Paths: 1 available
65010
6.6.6.200 from 2.2.2.222 (2.2.2.222)
MPLS label: 965242
north-edge#
Note The VPN label has not changed from the ISIS-SR case above (967920 & 965242), reinforcing the fact
that the BGP VPN label is orthogonal to the transport label.
VRF: tenant-d

B E 201.0.0.0/24 [200/0] via 10.255.255.6, Ethernet6/1.120
north-edge(config-router-bgp)#show ipv6 route vrf tenant-d
VRF: tenant-d
Policy Route
B 2010::/126 [200/0]
C 2010::4/126 [0/0]
B 2201::/64 [200/0]
via 2010::6, Ethernet6/1.120
B 2206::/64 [200/0]
Note As seen from the highlighted route above the label stack, the route are the transport label 904097 on
top (this is the label path to reach NH 6.6.6.200), with the tenant-d VPN label 967920 next in the stack,
and identifying the route as belonging to tenant-a.
1263
A capture of the dataplane on North-Edge matching on the LDP transport label confirms the
encapsulated traffic on the wire. 904097:976920:[Source IP Address][Destination IP Address].
1264
23.8.4.3 IP VPNs Over BGP-SR

Figure 23-64, Figure 23-65, and Figure 23-66 illustrate an overview of the combined control and data
planes.
Figure 23-64: IPv4 VPN and IPv6 VPN Over BGP-SR MPLS
IPv4 VPN
NW-CORE NE-CORE
eBGP-SR
AS 2 IPv4 VPN AS 4
iBGP-IPv4 VPN BGP
1.1.1.111 <-> 2.2.2.222 AS 64512
eBGP-SR
NORTH EDGE iBGP-IPv4 VPN SOUTH EDGE

6.6.6.6 <-> 2.2.2.222
eBGP-SR
AS 1 AS 6
TENANT-D eBGP-SR eBGP-SR TENANT-A
ET 6/1.120 eBGP-SR eBGP-SR ET 6/1.620

BGP-SR
eBGP Peering MPLS eBGP Peering
10.255.255.0/30 AS 3 AS 5 10.255.255.4/30
VL120 10.255.255.2/30 eBGP-SR VL620 10.255.255.6/30
VL121 201.0.0.1/24 VL621 206.0.0.1/24
SW-CORE SE-CORE
CE CE
IPv6 VPN
NW-CORE NE-CORE
eBGP-SR
AS 2 IPv6 VPN AS 4
iBGP-IPv6 VPN BGP
1.1.1.111 <-> 2.2.2.222 AS 64512
eBGP-SR
NORTH EDGE iBGP-IPv6 VPN SOUTH EDGE

6.6.6.6 <-> 2.2.2.222
eBGP-SR
AS 1 AS 6
TENANT-D eBGP-SR eBGP-SR TENANT-A
ET 6/1.120 eBGP-SR eBGP-SR ET 6/1.620

BGP-SR
eBGP Peering MPLS eBGP Peering
2010::6/126 AS 3 AS 5 2010::4/30
VL120 2010::1/126 eBGP-SR VL620 2010::6/126
VL121 2201::1/64 VL621 2201::6/64
SW-CORE SE-CORE
CE CE
1265
Figure 23-65: IPv4 VPN Forwarding Over BGP-SR MPLS

(AFI=1, SAFI=1)
To other PEs
NRU 206.0.0.0/24
NH 10.255.255.5
BGP-SR
6.6.6.66/32
CE PE1 Index 66
SRGB 200000 RR
(AFI=1, SAFI=128)
NRU 6.6.6.6:6451 4:206.0.0.0/24
408006 LABEL 967920 NEXT HOP 6.6.6.66
Lo1 1.1.1.11
967920
BGP-SR
H1 --> H2 6.6.6.66/32 To RR
SRGB 200000 (AFI=1, SAFI=1)
408006 NRU 206.0.0.0/24
H1 967920 BGP-SR
NH 10.255.255.2
H1 --> H2 6.6.6.66/32
SRGB 200000
10.255.255.2
967920 H1 --> H2
Loopback 1
H1 --> H2 6.6.6.66
206.0.0.0/24
H2
Figure 23-66: IPv6 VPN Forwarding Over BGP-SR MPLS

(AFI=2, SAFI=1)
To other PEs
NRU 2206::/64
NH 2010::5
BGP-SR
6.6.6.66/32
CE PE1 Index 66
SRGB 200000 RR
(AFI=2, SAFI=128)
NRU 6.6.6.6:6451 4:2206::/64
408006 LABEL 965242 NEXT HOP 6.6.6.66
Lo1 1.1.1.11
965242
BGP-SR
H1 --> H2 6.6.6.66/32 To RR
SRGB 200000 (AFI=2, SAFI=1)
408006 NRU 2206::/64
H1 965242 BGP-SR
NH 2010::2
H1 --> H2 6.6.6.66/32
SRGB 200000
2010::2
965242 H1 --> H2
Loopback 1
H1 --> H2 6.6.6.66
2206::/64
H2
To switch to using the MPLS BGP-SR transport, we just need to change the next-hop we advertised
for the VPN routes. As per Figure 23-65 and Figure 23-66, the next hop needs to be set to loopback 1
for using the BGP-SR LSP.
This is simply achieved by configuring the next-hop for EVPN routes.
router bgp 64512
!
address-family evpn
1266
Once this is configured, we can check the BGP updates and the routes in the VRF. The output again
includes the RD and IP prefix identifying the route. As seen in the output, we now have the NH set to
6.6.6.66 for tenant-d.
Paths: 1 available
65010
6.6.6.66 from 2.2.2.222 (2.2.2.222)
MPLS label: 967920
north-edge#
Paths: 1 available
65010
6.6.6.66 from 2.2.2.222 (2.2.2.222)
MPLS label: 965242
north-edge#
The output again includes the RD and IP prefix identifying the route. As seen in the output, we now
have the NH set to 6.6.6.66 for tenant-d.
Paths: 1 available
65010
6.6.6.66 from 2.2.2.222 (2.2.2.222)
MPLS label: 967920
north-edge#
Paths: 1 available
65010
6.6.6.66 from 2.2.2.222 (2.2.2.222)
MPLS label: 965242
north-edge#
1267
As displayed in the highlighted route above the label stack, the route are the transport label 200066 on
top (this is the label path to reach NH 6.6.6.66), with the tenant-d VPN label 967920 next in the stack,
and identifying the route as belonging to tenant-a.
VRF: tenant-d

B E 201.0.0.0/24 [200/0] via 10.255.255.6, Ethernet6/1.120
north-edge(config-router-bgp)#show ipv6 route vrf tenant-d
VRF: tenant-d
Policy Route
B 2010::/126 [200/0]
via 6.6.6.66/32, BGP LU tunnel index 8, label 965242
C 2010::4/126 [0/0]
B 2201::/64 [200/0]
via 2010::6, Ethernet6/1.120
B 2206::/64 [200/0]
via 6.6.6.66/32, BGP LU tunnel index 8, label 965242
A capture of the data-plane on North-Edge matching on the BGP-SR transport label confirms the
encapsulated traffic on the wire. 200066:976920:[Source IP Address][Destination IP Address].
monitor session 1 source Ethernet1/1 tx
monitor session 1 destination Cpu
north-edge(config-router-bgp)# bash tcpdump -nei mirror0 -q -c 10 mpls 200066

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on mirror0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:37:15.074916 28:99:3a:4d:3e:f1 > 28:99:3a:4d:3a:f3, MPLS unicast, length 122: MPLS (label 200066, exp 0,
ttl 63) (label 967920, exp 0, [S], ttl 63) 10.255.255.6 > 206.0.0.1: ICMP echo request, id 22573, seq 1,
length 80
16:37:15.075088 28:99:3a:4d:3e:f1 > 28:99:3a:4d:3a:f3, MPLS unicast, length 122: MPLS (label 200066, exp 0,
ttl 63) (label 967920, exp 0, [S], ttl 63) 10.255.255.6 > 206.0.0.1: ICMP echo request, id 22573, seq 2,
length 80
1268
Chapter 23: EVPN EVPN and VCS Commands
23.9 EVPN and VCS Commands

Router BGP Configuration Mode
• next-hop resolution disabled
• redistribute service vxlan
• route-target
• route-target export
• route-target import
• route-target route-map
• vni-aware-bundle
VCS Commands
• redistribute bgp evpn vxlan
Display Commands
• show bgp evpn
• show ip bgp vrf
• show ip route vrf
• show ipv6 bgp vrf
• show ipv6 route vrf
• show service vxlan address-table
• show vrf leak flapping
1269
EVPN and VCS Commands Chapter 23: EVPN
next-hop resolution disabled

The next-hop resolution disabled command disables the next-hop resolution in routes received from
BGP-EVPN peers.
The no next-hop resolution disabled and the default next-hop resolution disabled commands
enable the next-hop resolution in routes received from BGP-EVPN peers.
Command Mode
Router-BGP Address-Family Configuration
Command Syntax
next-hop resolution disabled
Example
This command disables the next-hop resolution in routes received from BGP-EVPN peers.
cvx(config-router-bgp)#address-family evpn
cvx(config-router-bgp-af)#next-hop resolution disabled
cvx(config-router-bgp-af)#
1270
redistribute bgp evpn vxlan

The redistribute bgp evpn vxlan command enables BGP-EVPN routes to be redistributed to VCS
which in turn advertises them to all VTEPs within the DC.
The no redistribute bgp evpn vxlan and the default redistribute bgp evpn vxlan commands disable
the redistribution of BGP-EVPN routes to VCS.
Command Mode
CVX-VXLAN Configuration
Command Syntax
redistribute bgp evpn vxlan
Example
This command enables redistribution of BGP-EVPN routes to VCS.
cvx(config)#cvx
cvx(config-cvx)#no shutdown
cvx(config-cvx)#service vxlan
cvx(config-cvx-vxlan)#no shutdown
cvx(config-cvx-vxlan)#redistribute bgp evpn vxlan
1271
redistribute service vxlan

The redistribute service vxlan command enables BGP to redistribute the Layer 2 bridging information
received from VCS.
The no redistribute service vxlan and the default redistribute service vxlan commands disable the
redistribution of the bridging information received from VCS.
Command Mode
Router-BGP VNI Configuration
Command Syntax
redistribute service vxlan
Example
This command enables redistribution of the Layer 2 bridging information received from VCS.
cvx(config-macvrf-bundle1)#redistribute service vxlan
1272
router general
The router general command configures a route-map to leak routes from one VRF to another VRF
using a route-map named “RM1”.
The no router general and default router general commands disable the router general configuration
from the running-config.
Command Mode
Router General Configuration
Command Syntax
router general
no router general
default router general
Examples
• These commands configure a route-map to leak routes from “VRF1” to “VRF2” using a route-map
“RM1”.
switch(config)#router general
switch(config-router-general)#vrf VRF2
switch(config-router-general-vrf-VRF2)#leak routes source-vrf VRF1
subscribe-policy RM1
• These commands configure a route-map with the prefix 10.0.0.0/8 and the administrative distance
to 10 in the destination VRF.
switch(config)#ip prefix-list PL1
switch(config-ip-pfx)#permit 10.0.0.0/8
switch(config)#ip route-map RM1
switch(config-route-map-RM1)#match ip address prefix-list PL1
switch(config-route-map-RM1)#set distance 10
1273
route-target
The route-target command configures a well-known extended community that is used by BGP-EVPN
to export routes from or import routes into MAC-VRF.
The no route-target and default route-target commands delete the route-target configuration.
Command Mode
Syntax
route-target {export | import | both} rt
no route-target
default route-target
Parameters
• export configures a well-known extended community that is attached to the routes exported by
BGP-EVPN.
• import configures a well known extended community that identifies the received routes that
need to be imported into the MAC-VRF specified by the VNI bundle.
• both configures the same extended community for import and export of routes.
• rt route-target extended community.
Example
This command configures a well-known extended community for import and export of routes.
cvx(config-macvrf-bundle1)#route-target both 503:12
1274
route-target export
The route-target export command allows the user to export routes from a VRF to the local VPN table
using the route target extended community list.
The no route-target export and default route-target export commands remove the routes from the
VPN table.
Command Mode
Syntax
route-target export [evpn|vpn-ipv4|vpn-ipv6] <RT>
no route-target export
default route-target export
Parameters
• evpn EVPN address family.
• vpn-ipv4 MPLS L3 VPN IPv4 unicast address family.
• RT route-target extended community.
Examples
• These commands export routes from vrf-red to the VPN table.
1275
route-target import
The route-target import command allows the user to import route target extended community lists
from the local VPN table to the target VRF.
The no route-target import and default route-target import commands remove the routes from the
VPN table.
Command Mode
Syntax
route-target import [evpn|vpn-ipv4|vpn-ipv6] <RT>
no route-target import
default route-target import
Parameters
• RT route-target extended community.
Examples
1276
route-target route-map
The route-target route-map command allows the user to export and import route target extended
community lists from one VRF to another using route maps.
The no route-target route-map and default route-target route-map commands remove the routes
from the VPN table.
Command Mode
Syntax
route-target {import|export} [evpn|vpn-ipv4|vpn-ipv6] route-map RM
no route-target route-map
default route-target route-map
Parameters
• RM route-map extended community.
Examples
• These commands export routes from vrf-red to the VPN table.
switch(config-router-bgp-vrf-vrf-red)#route-target export evpn route-map
EXPORT_ROUTES_T0_EVPN_TABLE
1277

switch(config-router-bgp-vrf-vrf-blue)#route-target import evpn route-map
IMPORT_ROUTES_FROM_EVPN_TABLE
1278
show bgp evpn

The show bgp evpn command displays information about the BGP-EVPN routes of the switch.
Command Mode
Global Configuration
Command Syntax
show bgp evpn [community | detail | esi esid | extcommunity | host-flap | instance
| large-community AS:nn:nn | next-hop | rd admin:local-assignment | route-type |
summary | vni vni_num]
Parameters
• <no parameters> displays all routes of the switch.
• community displays routes filtered by the specified community. Options include:
• GSHUT well known GSHUT community.
• aa:nn AS and network number, separated by colon. The value ranges from 1 to
4294967295.
• internet advertises route to the Internet community.
• local-as advertises route only to local peers.
• no-advertise does not advertise the route to any peer.
• no-export advertises route only within the BGP-EVPN AS boundary
• comm_num community number. Values range from 1 to 4294967040.
• detail displays detailed information of routes.
• esi esid displays routes filtered by the specified Ethernet Segment Identifier (ESI).
• extcommunity displays routes that match with BGP or VPN extended community list. Options
include:
• esi-label esid displays routes filtered by the specified value of ESI label. The value ranges
from 0 to 16777215.
• mac-mobility displays routes filtered by the specified MAC mobility.
• router-mac H.H.H displays routes filtered by the specified router MAC address.
• rt displays routes filtered by the specified route target.
• tunnel-encap vxlan displays routes filtered by the VXLAN tunnel encapsulation.
• host-flap displays routes that contains MAC addresses that are blacklisted due to duplication.
• instance displays routes with EVPN instances.
• large-community AS:nn:nn displays routes filtered by the specified large community.
• next-hop displays routes filtered by next-hop IPv4 or IPv6 addresses of remote VTEP.
• rd admin:local-assignment displays routes filtered by the specified Route Distinguisher (RD).
• route-type displays routes filtered by NLRI route type.
• summary displays summary of routes.
• vni vni_num displays routes filtered by the specified VXLAN Network Identifier (VNI). Value
ranges from 1 to 4294967294.
1279
Example
• This command displays BGP-EVPN routes filtered by the VNI 3011.
cvx(config-router-bgp-af)#show bgp evpn vni 3011

* >EcRD: 3.3.3.1:3011 auto-discovery 0 009a:f13b:53bb:8800:0000
1.1.1.1 - 100 0 65999 65001 i
* ec RD: 3.3.3.1:3011 auto-discovery 0 009a:f13b:53bb:8800:0000
1.1.1.1 - 100 0 65999 65001 i
* > RD: 3.3.3.2:3011 auto-discovery 0 009a:f13b:53bb:8800:0000
- - - 0 i
* >Ec RD: 3.3.3.1:3011 imet 1.1.1.1
1.1.1.1 - 100 0 65999 65001 i
* ec RD: 3.3.3.1:3011 imet 1.1.1.1
1.1.1.1 - 100 0 65999 65001 i
* > RD: 3.3.3.2:3011 imet 1.1.1.2
- - - 0 i
cvx(config-router-bgp-af)#
• This command displays the prefixes that are exported to the respective VPN table, along with the
route distinguisher.
switch(config)#show bgp evpn
* > RD: 400:1 ip-prefix 45.0.0.1/32
- - - 0 i
* > RD: 400:1 ip-prefix 52.0.0.1/32
- - - 0 i
* > RD: 400:1 ip-prefix 120.0.0.0/24
- - - 0 i
* > RD: 400:1 ip-prefix 130.0.0.0/24
- - - 0 i
* > RD: 400:1 ip-prefix 130.0.1.0/24
1280
show ip bgp vrf

The show ip bgp vrf command displays the type of VPN from the imported route. It shows an
indication that the IPv4 route has been leaked and source VRF information is displayed.
Command Mode
Command Syntax
show ip bgp vrf {vrf_name | all | default}
Parameters
• vrf_name name of the VRF.
• all displays summary of all VRFs.
• default default virtual routing and forwarding instance.
Example
• This command displays the leaked and source VRF information.
switch(config)#show ip bgp 13.0.0.0/24 vrf vrf-blue
BGP routing table information for VRF vrf-blue
BGP routing table entry for 130.110.61.0/24
4.0.0.3 from 4.0.0.3 (52.0.0.1), imported EVPN route, RD 400:1
Origin IGP, metric -, localpref 100, weight 0, valid, external,best
Extended Community: Route-Target-AS:4000:1 TunnelEncap:tunnelTypeVxlan
EvpnRouterMac:74:83:ef:0b:70:f3
Leaked from VRF vrf-red
1281
show ipv6 bgp vrf

The show ipv6 bgp vrf command displays the type of VPN from the imported route. It shows an
indication that the IPv6 route has been leaked and source VRF information is displayed.
Command Mode
Command Syntax
show ipv6 bgp vrf {vrf_name | all | default}
Parameters
• default default virtual routing and forwarding instance.
Example
• This command displays the leaked and source VRF information.
switch(config)#show ipv6 bgp 2001:10:1:0::102/64 vrf default
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E
- ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L -
labeled-unicast
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop -
Link Local Nexthop

* > 2000:0:14:120::/64 2001:db8:1111:9000:: - 100 109 i
* 2000:0:14:120::/64 2001:db8:156:1010::2 - 100 0 i
* 2000:0:14:120::/64 2001:db8:152:1010::2 - 100 0 i
* 2000:0:14:120::/64 2001:db8:203:1010::2 - 100 0 i
1282
show ip route vrf

The show ip route vrf command displays leaked prefixes with the label “ L” in the output that indicates
that the IPv4 route has been leaked. It also displays information about the source VRF from which
these prefixes have been leaked.
Command Mode
Command Syntax
show ip route vrf {vrf_name | all}
Parameters
Example
• These commands display the OSPF or OSPFV3 leaked routes as “redistribute ospf” and
“redistribute ospfv3” are configured on the source VRF vrf-red.
switch(config)#show ip route vrf vrf-blue
VRF: vrf-blue
DP - Dynamic Policy Route, L - VRF Leaked
C 5.0.0.2/31 is directly connected, Ethernet14
B L 57.0.0.3/32 [200/0] (source VRF vrf-red) via 4.0.0.3, Ethernet11
1283
show ipv6 route vrf

The show ipv6 route vrf command displays leaked prefixes with the label “ L” in the output that
indicates that the IPv6 route has been leaked. It also displays information about the source VRF from
which these prefixes have been leaked.
Command Mode
Command Syntax
show ipv6 route vrf {vrf_name | all}
Parameters
Example
• These commands display the OSPF or OSPFV3 leaked routes as “redistribute ospf” and
“redistribute ospfv3” are configured on the source VRF vrf-red.
switch(config)#show ipv6 route vrf vrf-blue
VRF: vrf-blue
Codes: C - connected, S - static, K - kernel, O3 - OSPFv3, B - BGP, R - RIP, A B
- BGP Aggregate, I L1 - IS-IS level 1, I L2 - IS-IS level 2, DH - DHCP, NG -
Nexthop Group Static Route, M - Martian, DP - Dynamic Policy Route, L - VRF Leaked
B L 18::1/128 [200/0] (source VRF vrf-red)
via 4::3, Ethernet11
via fe80::7683:efff:fe0b:963d, Ethernet11
B L 130::/64 [200/0] (source VRF vrf-red)
B L 130:0:0:1::/64 [200/0] (source VRF vrf-red)
1284
show service vxlan address-table

The show service vxlan address-table command displays route entries in the MAC forwarding table
that are added through the CVX.
Command Mode
CVX Global Configuration
Command Syntax
show service vxlan address-table {advertised | received} [address H.H.H | evpn |
hsc | mss | switch [Word | all] | vni vnid | vtep A.B.C.D]
Parameters
• advertised displays the advertised route entries in the MAC forwarding table.
• received displays the received route entries in the MAC forwarding table.
• address H.H.H displays route entries that are filtered by the specified MAC addresses.
• evpn displays route entries filtered by BGP-EVPN.
• hsc displays route entries filtered by Hardware Switch Controller (HSC).
• mss displays route entries filtered by Macro Segmentation Service (MSS).
• switch displays route entries that are filtered by the specified switch or all switches. Options
include:
• Word Hostname, IP address or ID of the switch.
• all all switches
• vni vnid displays route entries filtered by the specified VXLAN Network Identifier (VNI). Value
ranges from 1 to 4294967294.
• vtep A.B.C.D displays route entries filtered by the specified IP address of the remote Virtual
Tunnel End Point (VTEP).
Examples
• This command displays the route entries in MAC forwarding table advertised to BGP-EVPN peers.
cvx#show service vxlan address-table advertised evpn
Advertised Mac Address Table
----------------------------------------------------------------------
VNI Mac Address VTEP Moves

----------- ----------------- --------------- -----
1000 02:01:62:01:00:00 10.0.0.1 1
Total Mac Addresses for this criterion: 1
Advertised Flood Table

---------------------------------------------------
VNI Mac Address VTEP(s)

---------- ----------------- -----------------------------------------
1000 00:00:00:00:00:00 10.0.0.1 10.0.0.2
cvx#
1285
• This command displays the route entries in MAC forwarding table received from BGP-EVPN peers.
cvx#show service vxlan address-table received evpn
Received Mac Address Table
---------------------------------------------------------------------
Source VNI Mac Address VTEP Moves

----------------- ----------- ----------------- --------------- -----
EVPN 1000 02:01:62:02:00:00 10.0.0.3 1
Received Flood Table

---------------------------------------------------------------------
Source VNI Mac Address VTEP

----------------- ----------- ----------------- ---------------------
EVPN 1000 00:00:00:00:00:00 10.0.0.3
EVPN 1000 00:00:00:00:00:00 10.0.0.4
cvx#v
1286
show vrf leak flapping

The show vrf leak flapping command displays the flapping prefixes of the routes leaked from one VRF
to another VRF. Routes that are detected as “flapping” are blocked considering the future leaking policy
execution.
Command Mode
EXEC
Command Syntax
show vrf leak flapping
Parameters
• destination displays flapping prefixes destined to a VRF.
• prefix displays flapping routes for a prefix.
• source displays flapping prefixes sourced from a VRF.
• vrf displays flapping prefixes associated with a VRF
Example
• This command displays the flapping prefixes of the leaked routes.
switch#show vrf leak flapping
Age Source VRF Destination VRF Prefix Created At
-------- ---------------- --------------------- ----------------- -------------
141 VRF1 VRF2 10.0.2.0/24 3357281.40992
1287
vni-aware-bundle
The vni-aware-bundle command configures a BGP MAC-VRF containing Layer 2 routes from a group
of VXLAN Network Identifiers (VNI).
Command Mode
Router BGP Configuration
Command Syntax
vni-aware-bundle vni_bundle_name
Parameter
vni_bundle_name VNI bundle name.
Example
This command configures MAC-VRF BGP to support VNI bundle1.
1288

Evpn PDF

Uploaded by

Copyright:

Available Formats

Evpn PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Evpn PDF

Uploaded by

Copyright:

Available Formats

What are the different VXLAN control planes discussed in the document?

What are the different VXLAN control planes discussed in the document?

What terminology is introduced specific to a Network Virtualization Overlay (NVO) environment?

What terminology is introduced specific to a Network Virtualization Overlay (NVO) environment?

Chapter 23

23.1 EVPN Overview

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

23.1.1 EVPN Terminology

Type-1 Route: Ethernet A-D route

Type-2 Route: Host advertisement Route

Type-3 Route: Inclusive Multicast route

Type-4 Route: Ethernet Segment Route

Type-5 Route: IP-prefix route advertisement

23.1.2 EVPN Service Models

VLAN Based Service Interface

VLAN Bundle Service Interface

VLAN Aware Bundle Service Interface

23.1.3 VCS and EVPN in DCI

Figure 23-8 illustrates the federation of CVX across multiple DCs.

23.1.4 EVPN MPLS LAYER 3 VPN (Type-5 Route)

Path Attribute MP_REACH_NLRI

Route Type (IP Prefix Route, Type 5) Type 5 NLRI

Ethernet Segment Identifier = 0 Set to zero as ESI is NOT an overlay index

Extended Community Route Target Configured Route Target

23.2 EVPN Layer 3 Core Operations

23.2.1 MAC Address Learning.

Figure 23-12 notable fields:

23.2.2 ARP Suppression

23.2.3 MAC Mobility

23.2.4 MAC Address Damping

23.2.5 Broadcast and Multicast Traffic

The format of the type-3 route is illustrated in Figure 23-15.

Figure 23-15 notable fields of the type-3 route:

23.3 Integrated Routing and Bridging

IPv4 VPN defines two route types:

Figure 23-26: IPv6 VPN Route as Shown on PE

Figure 23-27 illustrates a basic MPLS Layer 3 VPN topology.

IP Routing MP-iBGP or MP-eBGP Route IP Routing

23.4 VPN MPLS Transport Options

EVPN Sample Topology

EVPN IPv4 (TENANT-A)

Figure 23-30: Tenant-B DCI

EVPN IPv4 (TENANT-B)

IP VPN Sample Topology

eBGP IP Routing MP-iBGP or MP-eBGP Route eBGP IP Routing

ETH 27 192.168.65.0/24 ETH 27

Figure 23-33: Tenant-D IPv6 VPN

ETH 27 192.168.65.0/24 ETH 27

2 Multi-hop TCP Session

North Edge.17:51:17#show mpls ldp neighbor

Addresses bound to peer:

L 116384 [1], 6.6.6.200/32

ISIS Neighbor P2P (IS-IS Hello PDUs) 2.2.2.200

System ID: north-edge Instance: sr_instance

Locally Originated Adjacency Segments

23.4.3 BGP-LU (BGP-SR)

6.6.6.66 6.6.6.66 4.6.6.6.66

6.6.6.66 ETH 1 ETH 26 4.6.6.6.66