Xrdocs Io ncs5500 Tutorials BGP Evpn Based Port Active Multihoming

@XRDOCS NCS5500 BLOGS TUTORIALS SEARCH  TAGS
Paban Sarma
Technical Marketing Engineer, Cisco. Follow
Save to PDF
BGP EVPN based Port Active MultiHoming

 23 minutes read
 O N T H I S PA G E
I M P L E M E N TAT I O N O F B G P - E V P N B A S E D P O R T- A C T I V E M U LT I - H O M I N G
R E F E R E N C E TO P O LO GY
Implementation of BGP-EVPN based Port-Active Multi-Homing
In port-active multi-homing, a host/CE is multihomed to one or more Leaf/PEs and only one of the Leaf is active and
forwards the tra c to and from the connected hosts. The rest of the Leaf remain in standby mode. Thus these mode
o ers an active-standby PE/Leaf redundancy for multihomed host/CE.
In this post we will cover the BGP-EVPN based Port-Active Multi-Homing of CE/Hosts. Similar to All active or Single
active mode, Ethernet Segment Identi er (ESI) is used to identify the links towards the same multihomed Host. Port-
active o ers active/standby redundant connectivity with forwarding for all tra c on a single link at a time with switchover
to the second link in case of active link’s failure. Port-Active load balancing mode keeps only one link towards the host as
active and rest of the link stays in LACP standby mode, thus creating a complete active standby multihoming for the
connected host/CEs. This is useful when we need protocol simpli cation from the host network.
Reference Topology
For this post, we will leverage EVPN control-plane and ISIS Segment Routing based forwarding that we con gured in a
previous post. However, the choice of transport is not mandatorily ISIS+SR and we can have OSPF as IGP and LDP
instead of SR as well.
As shown in the above topology, Host-1 is multi-homed to Leaf-1 and Leaf-2. For EVPN port multi-homing, the link
towards the Leaf will be a single ethernet bundle interface. This bundle may operate with di erent VLANs for di erent
services. EVPN port-active mode at the leaf1 and leaf2 will elect only one leaf as the active node and the bundle on that
leaf will be in active state. The bundle on the other leaf will move to standby state and signal LACP out of service towards
the host. As a result all tra c from the host H-1 will be able to forward the tra c only towards the active lacp link to
achieve port active redundancy for multihoming. The election of active Leaf is similar operation like all active DF election,
however in this case the election happens based on the ethernet segment identi er.
Task 1: Con gure Ethernet bundle on Host-1 for multi-homing
As per the reference topology Host-1 is multi-homed to Leaf-1 and Leaf-2 via LACP bundle-ethernet 1 going to both
Leaf-1 and Leaf-2. The host/CE with IP address 10.0.0.10/24 con gured on a vlan sub interface on the bundle. .
Following is the con guration of LAG on Host-1. The LAG on Host-1 will come up after we con gure lacp and port-active
multi-homing using EVPN Ether-Segment on the Leaf-1 and Leaf-2.

Host-1:
interface Bundle-Ether 1
description "Bundle to Leaf-1"
!
interface TenGigE0/0/2/0
description "Link to Leaf-1 ten0/0/0/47"
bundle id 1 mode active
!
description "Link to Leaf-2 ten0/0/0/47"
!
interface Bundle-Ether1.10
encapsulation dot1q 10
ipv4 address 10.0.0.10 255.255.255.0
!
Task 2: Con gure EVPN based port-active multi-homing
Con gure Leaf-1 and Leaf-2 to provision port-active multi-homing to host-1. The set of links from Host-1 to the Leafs
will be con gured as the same Ethernet Segment on the Leafs.
Con gure the LACP bundles on the Leaf-1 and Leaf-2. Use below con guration for the Leafs.
Leaf-1:
description "Link to Host-1"
!
interface Bundle-Ether1
description "Bundle to Host-1 for port-active"
lacp system mac 1212.1212.1212
Leaf-2
description "Link to Host-1"
!
description "Bundle to Host-1 for port-active"
lacp system mac 1212.1212.1212
!
Con gure ESI for the bundle interface to enable multi-homing of the host. Use the identical ethernet-segment
con guration on both the Leafs. Con gure load-balancing mode to port-active using “port-active” keyword for ethernet-
segment.
Note: The configured ESI will be used for the selection of active port. Out of the 10 octet ESI, a modulo operation is performed
on octet 3-6 to elect the active leaf/PE


Leaf-1 and leaf 2
evpn
ethernet-segment
identifier type 0 12.12.12.12.12.12.12.12.12
load-balancing-mode port-active
Use “show bundle bundle-ether” CLI command to verify the state of the bundle interfaces on Leafs and Host-1.
RP/0/RP0/CPU0:Leaf-1#show bundle bundle-ether 1
Bundle-Ether1
Status: Up
Local links &lt active/standby/configured &gt : 1 / 0 / 1
Local bandwidth &lt effective/available&gt : 10000000 (10000000) kbps
MAC address (source): 00bc.601c.d0d9 (Chassis pool)
Inter-chassis link: No
Minimum active links / bandwidth: 1 / 1 kbps
Maximum active links: 64
Wait while timer: 2000 ms
Load balancing:
Link order signaling: Not configured
Hash type: Default
Locality threshold: None
LACP: Operational
Flap suppression timer: Off
Cisco extensions: Disabled
Non-revertive: Disabled
mLACP: Not configured
IPv4 BFD: Not configured
Port Device State Port ID B/W, kbps

-------------------- --------------- ----------- -------------- ----------
Te0/0/0/47 Local Active 0x8000, 0x0001 10000000
Link is Active
RP/0/RP0/CPU0:Leaf-2#show bundle bundle-ether 1
Bundle-Ether1
Status: LACP OOS (out of service)
Local links &lt active/standby/configured &gt : 0 / 1 / 1
Local bandwidth &lt effective/available &gt : 0 (0) kbps
MAC address (source): 00bc.600e.40dc (Chassis pool)
Inter-chassis link: No
Minimum active links / bandwidth: 1 / 1 kbps
Maximum active links: 64
Wait while timer: 2000 ms
Load balancing:
Link order signaling: Not configured
Hash type: Default
Locality threshold: None
LACP: Operational
Flap suppression timer: Off
Cisco extensions: Disabled
Non-revertive: Disabled
mLACP: Not configured
Port Device State Port ID B/W, kbps
-------------------- --------------- ----------- -------------- ----------
Te0/0/0/47 Local Standby 0x8000, 0x0001 10000000
Link is in standby due to bundle out of service state
Also, verify the port-active operation making one leaf active and one leaf standby by verifying the status of the ethernet
segment on each PE
LEAF1:
RP/0/RP0/CPU0:Leaf-1# sh evpn ethernet-segment interface bundle-Ether 1 detail

Legend:
B - No Forwarders EVPN-enabled,
C - Backbone Source MAC missing (PBB-EVPN),
RT - ES-Import Route Target missing,
E - ESI missing,
H - Interface handle missing,
I - Name (Interface or Virtual Access) missing,
M - Interface in Down state,
O - BGP End of Download missing,
P - Interface already Access Protected,
Pf - Interface forced single-homed,
R - BGP RID not received,
S - Interface in redundancy standby state,
X - ESI-extracted MAC Conflict
SHG - No local split-horizon-group label allocated
Ethernet Segment Id Interface Nexthops

------------------------ ---------------------------------- --------------------
0012.1212.1212.1212.1212 BE1 1.1.1.1
2.2.2.2
ES to BGP Gates : Ready
ES to L2FIB Gates : Ready
Main port :
Interface name : Bundle-Ether1
Interface MAC : 00bc.601c.d0d9
IfHandle : 0x08004034
State : Up
Redundancy : Not Defined
ESI type : 0
Value : 12.1212.1212.1212.1212
ES Import RT : 1212.1212.1212 (from ESI)
Source MAC : 0000.0000.0000 (N/A)
Topology :
Operational : MH
Configured : Port-Active
Service Carving : Auto-selection
Multicast : Disabled
Peering Details :
1.1.1.1 [MOD:P:00]
2.2.2.2 [MOD:P:00]
Service Carving Results:

Forwarders : 0
Elected : 0
Not Elected : 0
EVPN-VPWS Service Carving Results:
Primary : 0
Backup : 0
Non-DF : 0
MAC Flushing mode : STP-TCN
Peering timer : 3 sec [not running]
Recovery timer : 30 sec [not running]
Carving timer : 0 sec [not running]
Local SHG label : None
Remote SHG labels : 0
Access signal mode: Bundle OOS (Default)
LEAF2:
RP/0/RP0/CPU0:Leaf-2# sh evpn ethernet-segment interface bundle-Ether 1 detail
Legend:
E - ESI missing,

------------------------ ---------------------------------- --------------------
0012.1212.1212.1212.1212 BE1 1.1.1.1
2.2.2.2
Main port :
Interface MAC : 00bc.600e.40dc
State : Standby
ESI type : 0
Value : 12.1212.1212.1212.1212
Source MAC : 0000.0000.0000 (N/A)
Topology :
Operational : MH
Peering Details :
1.1.1.1 [MOD:P:00]
2.2.2.2 [MOD:P:00]

Forwarders : 0
Elected : 0
Not Elected : 0
Primary : 0
Backup : 0
Non-DF : 0
Note In the example shown the ethernet segment Identifier is 00.12.12.12.12.12.12.12.12.12.12 and the portion impacting DF
election is 12.12.12.12 as highlighted. For Dual homing an odd-even modulo operation will gives a result of 0. Therefore Leaf1 is
our active PE as it has a lower BGP router ID of 1.1.1.1 compared to 2.2.2.2 of Leaf2.
Above output shows that the bundle interfaces are up and port active redundancy mode has created an active standby
Leaf redundancy for the dual homed Host-1. By default the ethernet segment signals bundle OOS on the non-DF PE.
The ES may also be con gured with ‘access-signal bundle-down’. This con guration is used to keep ES down instead of
OOS when EVPN cost-out/core-isolation and similar triggers are applied. In the Down signalling mode, the CE side is
able to switch ES from one to the other when LACP is not supported. The below snippet shows the con guration and CLI
output.
evpn
ethernet-segment
identifier type 0 18.44.18.44.18.44.18.44.00
load-balancing-mode port-active
!
access-signal bundle-down
RP/0/RP0/CPU0:LEAF-1#show evpn ethernet-segment interface bundle-Ether 2 detail

Thu Nov 12 00:43:18.314 GMT+4
Legend:
E - ESI missing,

------------------------ ---------------------------------- --------------------
0018.4418.4418.4418.4400 BE2 1.1.1.1
2.2.2.2
Main port :
Interface MAC : 0032.1780.98de
IfHandle : 0x080040c4
State : Up
ESI type : 0
Value : 18.4418.4418.4418.4400
Source MAC : 0000.0000.0000 (N/A)
Topology :
Operational : MH
Convergence :
Mobility-Flush : Count 0, Skip 0, Last n/a
Peering Details : 2 Nexthops
1.1.1.1 [MOD:P:00]
2.2.2.2 [MOD:P:00]
Forwarders : 0
Elected : 0
Not Elected : 0
Primary : 0
Backup : 0
Non-DF : 0
Access signal mode: Bundle Down
RP/0/RP0/CPU0:LEAF-2#show evpn ethernet-segment interface bundle-Ether 2 detail

Thu Nov 12 04:49:28.018 UTC
Legend:
E - ESI missing,

------------------------ ---------------------------------- --------------------
0018.4418.4418.4418.4400 BE2 1.1.1.1
2.2.2.2
Main port :
Interface MAC : 00bc.6013.44de
IfHandle : 0x0800403c
State : Standby
ESI type : 0
Value : 18.4418.4418.4418.4400
Source MAC : 0000.0000.0000 (N/A)
Topology :
Operational : MH
Convergence :
Mobility-Flush : Count 0, Skip 0, Last n/a
Peering Details : 2 Nexthops
1.1.1.1 [MOD:P:00]
2.2.2.2 [MOD:P:00]
Forwarders : 0
Elected : 0
Not Elected : 0
Primary : 0
Backup : 0
Non-DF : 0
Access signal mode: Bundle Down
Next, lets’ provision the EVPN layer-2 service over this redundancy.
Task 3: Con gure BGP EVPN based layer-2 multipoint service
Here we will con gure a EVPN layer-2 service between Leaf-1, Leaf-2 and Leaf-5 to provide a L2VPN between H1 and
H5. Post con guration we will check the status of ethernet segment. For detailed explanation of con guring BGP EVPN
based layer-2 service, refer to this post.
Here , the L2 service is con gured on VLAN 10 (sub-interface on the bundle) and only one VPN (EVI) is shown. We may
have multiple services running over di erent sub-interface (VLAN).
Leaf-1:
interface Bundle-Ether 1.10 l2transport
rewrite ingress tag pop 1 symmetric
!
l2vpn
bridge group bg-1
bridge-domain bd-10
interface Bundle-Ether 11.10
evi 10
!
!
evpn
evi 10
bgp
route-target import 1001:11
route-target export 1001:11
!
advertise-mac
!
!
!
Leaf-2:
interface Bundle-Ether 1.10 l2transport

!
l2vpn
bridge group bg-1
bridge-domain bd-10
interface Bundle-Ether 1.10
evi 10
!
!
evpn
evi 10
bgp
!
advertise-mac
!
!
Leaf-5:
interface TenGigE0/0/0/45.10 l2transport

!
evpn
evi 10
bgp
!
advertise-mac
!
!
!
l2vpn
bridge group bg-1
bridge-domain bd-10
interface TenGigE0/0/0/45.10
!
evi 10
!
!
Host-5 is single-homed to Leaf-5, below is the Host-5 con guration for reference.
Host-5:
description "Link to Leaf-5"
ipv4 address 10.0.0.50 255.255.255.0
Once , the EVPN service is up, H1 will be able to reach H5 and vice-versa.
Task 4: Verify that EVPN based Port-active multi-homing is operational
As we have con gured the BGP EVPN layer-2 service as well as the ethernet segment, we have already veri ed the port
active operation. Now using the same command again we can see in the service carving details and con rm that the
EVPN service is only active on the active PE.

LEAF1:
RP/0/RP0/CPU0:Leaf-1#show evpn ethernet-segment interface bundle-Ether 1 detail

Thu Aug 13 11:58:07.149 UTC
Legend:
E - ESI missing,

------------------------ ---------------------------------- --------------------
0012.1212.1212.1212.1212 BE1 1.1.1.1
2.2.2.2
Main port :
State : Up
ESI type : 0
Value : 12.1212.1212.1212.1212
Source MAC : 0000.0000.0000 (N/A)
Topology :
Operational : MH
Peering Details :
1.1.1.1 [MOD:P:00]
2.2.2.2 [MOD:P:00]

Forwarders : 1
Elected : 1
Not Elected : 0
Primary : 0
Backup : 0
Non-DF : 0
Local SHG label : 24001
24001 : nexthop 2.2.2.2
LEAF2:
RP/0/RP0/CPU0:Leaf-2#show evpn ethernet-segment interface bundle-Ether 1 detail
Thu Aug 13 11:58:50.921 UTC
Legend:
E - ESI missing,

------------------------ ---------------------------------- --------------------
0012.1212.1212.1212.1212 BE1 1.1.1.1
2.2.2.2
Main port :
Interface MAC : 00bc.600e.40dc
State : Standby
ESI type : 0
Value : 12.1212.1212.1212.1212
Source MAC : 0000.0000.0000 (N/A)
Topology :
Operational : MH
Peering Details :
1.1.1.1 [MOD:P:00]
2.2.2.2 [MOD:P:00]

Forwarders : 1
Elected : 0
Not Elected : 1
Primary : 0
Backup : 0
Non-DF : 0
24001 : nexthop 1.1.1.1
The above output on both PE shows that elected eld is up only for the active PE, although the output of both the Leafs
show that both are forwarders of 1 service. Unlike All-active or Single-active, the same PE will be the elected PE for any
other vlan con gured on these ethernet segment. This is the nature of port active redundancy mode. To
Ping from Host-1 to Host-5 shows that the hosts can reach each other.
Host-1:
RP/0/RSP0/CPU0:Host-1#ping 10.0.0.50
Thu Aug 13 11:29:24.024 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.50, timeout is 2 seconds:
!!!!!
Let’s now take a look at the BGP EVPN control plane by checking the types of routes received on di erent leaf’s. We are
ltering the route for the speci c PE and speci c service using rd which is PE:EVI . for example , routes from leaf1 for EVI
10 will come with a RD of 1.1.1.1:10
RP/0/RP0/CPU0:Leaf-1#show bgp l2vpn evpn rd 5.5.5.5:10

------
Status codes: s suppressed, d damped, h history, * valid, &gt best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 5.5.5.5:10
*>i[2][0][48][a03d.6f3d.5447][0]/104
5.5.5.5 100 0 i
*>i[3][0][32][5.5.5.5]/80
5.5.5.5 100 0 i
Processed 2 prefixes, 2 paths

-------
*>i[1][0012.1212.1212.1212.1212][0]/120
2.2.2.2 100 0 i
*>i[3][0][32][2.2.2.2]/80
2.2.2.2 100 0 i
From Above output from Leaf-1 clearly shows it has reached the RT2 (MAC) from Leaf-5. From Leaf2 it has only
received the ESI route.

-------------

*>i[1][0012.1212.1212.1212.1212][0]/120
1.1.1.1 100 0 i
*>i[2][0][48][6c9c.ed6d.1d89][0]/104
1.1.1.1 100 0 i
*>i[3][0][32][1.1.1.1]/80
1.1.1.1 100 0 i

-------------
*>i[2][0][48][a03d.6f3d.5447][0]/104
5.5.5.5 100 0 i
*>i[3][0][32][5.5.5.5]/80
5.5.5.5 100 0 i
Above output shows Leaf-2 has learnt ESI and MAC of host 1 from Leaf1 and from Leaf 5 it has learnt the MAC of host-
5.

-------
Status codes: s suppressed, d damped, h history, * valid, > best
*>i[1][0012.1212.1212.1212.1212][0]/120
1.1.1.1 100 0 i
*>i[2][0][48][6c9c.ed6d.1d89][0]/104
1.1.1.1 100 0 i
*>i[3][0][32][1.1.1.1]/80
1.1.1.1 100 0 i

-----------
Status codes: s suppressed, d damped, h history, * valid, > best
*>i[1][0012.1212.1212.1212.1212][0]/120
2.2.2.2 100 0 i
*>i[3][0][32][2.2.2.2]/80
2.2.2.2 100 0 i
Processed 2 prefixes, 2 paths100 0 i
Leaf-5 also learns the MAC of host1 only via Leaf1 as it was the only active PE and there is no aliasing in port active
multihoming.
Lastly, run “show evpn evi vpn-id 10 mac” command to verify the MAC address learnt for EVI 10. We see that Leaf-1
and Leaf-2 have learnt Host-5’s MAC address with Leaf-5 as the next-hop. However , Leaf5 has learnt Host-1’s MAC
with only Leaf-1 as nexthop.
RP/0/RP0/CPU0:Leaf-1#show evpn evi vpn-id 10 mac

Thu Aug 13 12:12:45.065 UTC
VPN-IDEncap MAC address IP address Nexthop Label

---------- ---------- -------------- ----------------------------
10 MPLS 6c9c.ed6d.1d89 :: Bundle-Ether1.10 24000
10 MPLS a03d.6f3d.5447 :: 5.5.5.5 24004

Thu Aug 13 12:12:45.065 UTC

---------- ---------- -------------- ----------------------------
10 MPLS 6c9c.ed6d.1d89 :: 1.1.1.1 24000
10 MPLS a03d.6f3d.5447 :: 5.5.5.5 24004

Thu Aug 13 12:12:45.065 UTC

---------- ---------- -------------- ----------------------------
10 MPLS 6c9c.ed6d.1d89 :: 1.1.1.1 24000
10 MPLS a03d.6f3d.5447 :: TenGigE0/0/0/45.10 24004
The above output veri es the BGP-EVPN control plane for EVPN multipoint service over Port-active multihoming. Note:
As Leaf-2 sees Host-1's MAC reachable via Leaf-1, in case of another Host/ESI connected to Leaf-2 wants to reach to Host-1 it
will have to go over Leaf-1 to reach to Host-1.
Task 5: Con gure and Verify BGP-EVPN Distributed Anycast Gateway for IRB service
In this section we will demonstrate the Layer-3 inter-subnet routing use case over EVPN port active multihoming. Similar
to Host-1’s layer-2 reachability, Host-1’s IP will also only be reachable via Leaf-1 as next-hop. After we con gure BGP-
EVPN distributed anycast gateway for inter-subnet routing, we will observe the routing table of Leaf-5.
Con gure the BGP-EVPN Distributed Anycast Gateway on Leaf-1, Leaf-2 and Leaf-5. We will con gure the IRB service
over a di erent VLAN and show the coexistence of both service over the port active ESI. For detailed explanation of
EVPN distributed anycast gateway, refer to this post.
Configure VRFs on Leaf-1, Leaf-2 and Leaf-5.
vrf 11
address-family ipv4 unicast
import route-target
11:11
!
export route-target
11:11
!
router bgp 65001
address-family vpnv4 unicast
!
vrf 11
rd auto
additional-paths receive
maximum-paths ibgp 10
redistribute connected
!
Configure BVI as distributed anycast gateway
On Leaf 1 and Leaf 2:
interface BVI11
host-routing
vrf 11
ipv4 address 111.0.0.1 255.255.255.0
mac-address 1001.1001.1001
!
interface Bundle-Ether1.11 l2transport

!
evpn
evi 11
advertise-mac
!
!
!
l2vpn
bridge group bg1
bridge-domain irb1
!
routed interface BVI11
!
evi 11
Configure BVI as distributed anycast gateway
On Leaf 5:
interface BVI11
host-routing
vrf 11
ipv4 address 111.0.1.1 255.255.255.0
mac-address 5001.5001.5001
interface TenGigE0/0/0/45.11 l2transport

!
evpn
evi 11
advertise-mac
!
l2vpn
bridge group bg1
bridge-domain irb1
!
routed interface BVI11
!
evi 11
We will also con gure a two di erent subnet on the Host’s and respective static routing towards the gateways.
HOST1:
ipv4 address 111.0.0.10 255.255.255.0
!
router static
111.0.0.0/16 111.0.0.1
!
!
HOST5:
ipv4 address 111.0.1.50 255.255.255.0
!
router static
111.0.0.0/16 111.0.1.1
BGP-EVPN IRB control plane can be veri ed by observing the route tables on the Leaf node. As we can see the route for
remote host’s are learnt on Leaf1 and Leaf-5 via BGP. As Leaf-2 is in standby mode it lean’s route to Host-1 from Leaf-1
via BGP instead of learning directly.
RP/0/RP0/CPU0:Leaf-1#sh route vrf 11

---------
Gateway of last resort is not set
C 111.0.0.0/24 is directly connected, 00:32:09, BVI11

L 111.0.0.1/32 is directly connected, 00:32:09, BVI11
B 111.0.1.50/32 [200/0] via 5.5.5.5 (nexthop in vrf default), 00:22:24
RP/0/RP0/CPU0:Leaf-2#sh route vrf 11

--------

RP/0/RP0/CPU0:Leaf-5#show route vrf 11

--------------

C 111.0.1.0/24 is directly connected, 00:29:27, BVI11
L 111.0.1.1/32 is directly connected, 00:29:27, BVI11
As of now we have con gured 2 di erent services over the EVPN port-active multihoming and we see Leaf-1 as DF for
both of this service. This is due to the fact that load balancing happens per port/ESI and the bundle on the non DF nodes
are in LACP OOS status. If we see the Ethernet segment status on Leaf-1, we will see it as elected forwarder for all the
con gured services.
RP/0/RP0/CPU0:Leaf-1#show evpn ethernet-segment in bundle-Ether 1 carving detail

Thu Aug 13 13:16:23.816 UTC
---------

------------------------ ---------------------------------- --------------------
0012.1212.1212.1212.1212 BE1 1.1.1.1
2.2.2.2
Main port :
State : Up
ESI type : 0
Value : 12.1212.1212.1212.1212
Source MAC : 0000.0000.0000 (N/A)
Topology :
Operational : MH
Peering Details :
1.1.1.1 [MOD:P:00]
2.2.2.2 [MOD:P:00]

Forwarders : 2
Elected : 2
EVI E : 10, 11
Not Elected : 0
Primary : 0
Backup : 0
Non-DF : 0
24001 : nexthop 2.2.2.2
This concludes the BGP-EVPN based port-active implementation. We have shown example of both Layer2 bridging and
IRB services over port-active redundancy. However, this redundancy mode can be used for any other services like layer3
or legacy layer 2. For further technical details refer to our e-vpn.io webpage that has a lot of material explaining the core
concepts of EVPN, its operations and troubleshooting.
 Tags: EVPN iosxr NCS 5500
 Updated: September 01, 2020
SHARE ON
   
Leave a Comment
What do you think?
3 Responses
Upvote Funny Love Surprised
1 Comment 
1 Login
G Join the discussion…
LOG IN WITH OR SIGN UP WITH DISQUS ?
Name
 Share Best Newest Oldest
A
Alfonso Nah − ⚑
3 years ago
Hi Paban.
thank you for this document, i have a question.
what is the possible solution when the out put of the command "show evpn ethernet-
segment interface bundle-Ether 1 detail", is the following?
ES to BGP Gates : O
ES to L2FIB Gates : O
thank you and regards!
0 0 Reply ⥅
Subscribe Privacy Do Not Sell My Data
FOLLOW:  TWITTER  GITHUB  FEED
This site is maintained by Cisco Systems, Inc. employees. Powered by Jekyll & Minimal Mistakes.

Xrdocs Io ncs5500 Tutorials BGP Evpn Based Port Active Multihoming

Uploaded by

Copyright:

Available Formats

You might also like

Xrdocs Io ncs5500 Tutorials BGP Evpn Based Port Active Multihoming

Uploaded by

Document Information

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

Xrdocs Io ncs5500 Tutorials BGP Evpn Based Port Active Multihoming

Uploaded by

Copyright:

Available Formats

@XRDOCS NCS5500 BLOGS TUTORIALS SEARCH  TAGS

BGP EVPN based Port Active MultiHoming

Implementation of BGP-EVPN based Port-Active Multi-Homing

Task 1: Con gure Ethernet bundle on Host-1 for multi-homing

Task 2: Con gure EVPN based port-active multi-homing

on octet 3-6 to elect the active leaf/PE

Leaf-1 and leaf 2

RP/0/RP0/CPU0:Leaf-1#show bundle bundle-ether 1

Port Device State Port ID B/W, kbps

RP/0/RP0/CPU0:Leaf-2#show bundle bundle-ether 1

RP/0/RP0/CPU0:Leaf-1# sh evpn ethernet-segment interface bundle-Ether 1 detail

Ethernet Segment Id Interface Nexthops

Service Carving Results:

RP/0/RP0/CPU0:Leaf-2# sh evpn ethernet-segment interface bundle-Ether 1 detail

Ethernet Segment Id Interface Nexthops

Service Carving Results:

RP/0/RP0/CPU0:LEAF-1#show evpn ethernet-segment interface bundle-Ether 2 detail

Ethernet Segment Id Interface Nexthops

RP/0/RP0/CPU0:LEAF-2#show evpn ethernet-segment interface bundle-Ether 2 detail

Ethernet Segment Id Interface Nexthops

Task 3: Con gure BGP EVPN based layer-2 multipoint service

interface Bundle-Ether 1.10 l2transport

interface TenGigE0/0/0/45.10 l2transport

Task 4: Verify that EVPN based Port-active multi-homing is operational

RP/0/RP0/CPU0:Leaf-1#show evpn ethernet-segment interface bundle-Ether 1 detail

Ethernet Segment Id Interface Nexthops

Service Carving Results:

Ethernet Segment Id Interface Nexthops

Service Carving Results:

RP/0/RP0/CPU0:Leaf-1#show bgp l2vpn evpn rd 5.5.5.5:10

Processed 2 prefixes, 2 paths

RP/0/RP0/CPU0:Leaf-1#show bgp l2vpn evpn rd 2.2.2.2:10

RP/0/RP0/CPU0:Leaf-2#show bgp l2vpn evpn rd 1.1.1.1:10

Status codes: s suppressed, d damped, h history, * valid, &gt best

Processed 3 prefixes, 3 paths

RP/0/RP0/CPU0:Leaf-2#show bgp l2vpn evpn rd 5.5.5.5:10

Processed 2 prefixes, 2 paths

RP/0/RP0/CPU0:Leaf-5#show bgp l2vpn evpn rd 1.1.1.1:10

Processed 3 prefixes, 3 paths

RP/0/RP0/CPU0:Leaf-5#show bgp l2vpn evpn rd 2.2.2.2:10

Processed 2 prefixes, 2 paths100 0 i

RP/0/RP0/CPU0:Leaf-1#show evpn evi vpn-id 10 mac

VPN-IDEncap MAC address IP address Nexthop Label

RP/0/RP0/CPU0:Leaf-2#show evpn evi vpn-id 10 mac

VPN-IDEncap MAC address IP address Nexthop Label

RP/0/RP0/CPU0:Leaf-1#show evpn evi vpn-id 10 mac

VPN-IDEncap MAC address IP address Nexthop Label

will have to go over Leaf-1 to reach to Host-1.

Configure VRFs on Leaf-1, Leaf-2 and Leaf-5.

Configure BVI as distributed anycast gateway

On Leaf 1 and Leaf 2:

interface Bundle-Ether1.11 l2transport

Configure BVI as distributed anycast gateway

interface TenGigE0/0/0/45.11 l2transport

RP/0/RP0/CPU0:Leaf-1#sh route vrf 11

C 111.0.0.0/24 is directly connected, 00:32:09, BVI11

RP/0/RP0/CPU0:Leaf-2#sh route vrf 11

Gateway of last resort is not set