@XRDOCS NCS5500 BLOGS TUTORIALS SEARCH  TAGS

Ahmad Bilal Siddiqui

Technical Marketing Engineer, Cisco. Follow

Save to PDF

Con gure BGP-EVPN Control-Plane & Segment Routing based MPLS

Forwarding-Plane
 10 minutes read

 O N T H I S PA G E

INTRODUCTION TO BGP-EVPN

BGP-EVPN KEY ROUTE TYPES FOR REFERENCE

C O N F I G U R I N G B G P E V P N C O N T R O L- P L A N E A N D I S I S S E G M E N T R O U T I N G F O R W A R D I N G P L A N E

R E F E R E N C E T O P O L O G Y:

Introduction to BGP-EVPN

EVPN is the next generation L2VPN technology, it provides layer-2 as well as layer-3 VPN services in a scalable and
simpli ed manner. The evolution of EVPN started due to the need of a scalable solution to bridge various layer-2 domains
and overcome the limitations faced by VPLS such as scalability, multi-homing and per- ow load balancing.

EVPN uses MAC addresses as routable addresses and distribute them to all participating PEs via MP-BGP EVPN control-
plane. EVPN is used for E-LAN, E-LINE, E-TREE services and provides data-plane and control-plane separation. This
allows the use of di erent encapsulation mechanisms in data plane while maintaining the same control-plane. In addition,
EVPN o ers many advantages over existing technologies, including more e cient load-balancing of VPN tra c. Some of
the prominent advantages are:

Multi-homing and redundancy

Per ow-based load balancing

Scalability

Provisioning simplicity
Reduced operational complexity

In this and next few posts we will cover BGP-EVPN con guration, implementation and veri cation on NCS 5500 Platform
using IOS-XR. The goal of this tutorial is to provide familiarity to BGP-EVPN from con guration perspective and cover the
following use cases.

Con guring BGP EVPN control-plane and Segment Routing based forwarding plane

Con gure EVPN based Multi-homing to the Hosts

EVPN based Layer-2 VPN Service

EVPN-IRB between Leafs in the network

BGP-EVPN Key Route Types for Reference

The EVPN network layer reachability information (NLRI) provides di erent route types. Following is the summary of the
route types and their usage.
Route Type Usage

0x1 Ethernet Auto-Discovery (A-D) Route MAC Mass-Withdraw, Aliasing (load balancing)

0x2 MAC Advertisement Route Advertises Host MAC and IP address

0x3 Inclusive Multicast Route Indicates interest of BUM tra c for attached L2 segments

0x4 Ethernet Segment Route Auto discovery of Multi-homed Ethernet Segments and Designated Forwarder (DF) Election

0x5 IP Pre x Route Advertises IP pre x for a subnet via EVPN address family

Note: We are using Spine Leaf Fabric example in the con guration but essentially a Leaf is a PE and Spine is a P router
as we are implementing MPLS forwarding plane with BGP-EVPN.

Con guring BGP EVPN control-plane and ISIS Segment Routing forwarding plane

In this post, we will con gure the BGP EVPN control-plane and ISIS Segment Routing based forwarding plane. This will
provide the basis to enable us for provisioning of EVPN based services using segment routing transport.

Reference Topology:

Task 1: Con gure the Routing Protocol for Transport:

Con gure IGP routing protocol between Leafs and Spines. In this tutorial we are using ISIS as the underlay routing
protocol.

Loopback 0 Pre x-SID ISIS Net

Spine-1 6.6.6.6/32 16006 49.0001.0000.0000.0006.0

Spine-2 7.7.7.7/32 16007 49.0001.0000.0000.0007.0

Leaf-1 1.1.1.1/32 16001 49.0001.0000.0000.0001.0

Leaf-2 2.2.2.2/32 16002 49.0001.0000.0000.0002.0

Leaf-5 5.5.5.5/32 16005 49.0001.0000.0000.0005.0

Following is a sample con g from Leaf-1 to implement ISIS routing protocol in the network. Similar con gs with relevant
Net address (shown in above table) and interfaces should be used on other devices to bring up the ISIS routing protocol
in the network. Don’t con gure ISIS on the links from host to leafs, these will be set up later as layer-2 links.

router isis 1
is-type level-2-only
net 49.0001.0000.0000.0001.00
nsr
 log adjacency changes
address-family ipv4 unicast
metric-style wide
!
interface Bundle-Ether16
point-to-point
address-family ipv4 unicast
!
interface Bundle-Ether17
point-to-point
address-family ipv4 unicast
!
interface Loopback0
passive
address-family ipv4 unicast
!

Verify that the point-to-point interfaces between the spines and leafs and other devices in the network are up and the
ISIS routing adjacency is formed between the devices as per the topology. In this setup, ISIS routing protocol is
con gured on all the devices except the hosts, the host will be connected layer-2 dual-homed to the Leafs.

The “show isis neighbor” and “show route isis” commands can be used to verify that the adjacency is formed and the
routes of all the Leafs and Spines are learnt via ISIS.

Task 2: Enable ISIS Segment Routing:

Con gure Segment Routing protocol under ISIS routing protocol which enables MPLS on all the non-passive ISIS
interfaces. A pre x SID is associated with an IP pre x and is manually con gured from the segment routing global block
(SRGB) range of labels. It is con gured under the loopback interface with the loopback address of the node as the pre x.
The pre x SID is globally unique within the segment routing domain.

The Pre x-SID can be an absolute value or an indexed value. In this guide, we are con guring Pre x-SID as absolute
value. ISIS Segment Routing is con gured in the Fabric between Leafs and Spines.

Following is a sample con g to enable Segment Routing in the network. Similar con g with pre x-SID that is unique for
each device in the network, should be con gured on other devices (as per the above diagram) to enable ISIS Segment
Routing. In this con g pre x-SID is enabled on the “loopback 0” interface of the devices.
 

Spine-1:

router isis 1
address-family ipv4 unicast
segment-routing mpls
!
interface Loopback0
passive
address-family ipv4 unicast
prefix-sid absolute 16006
!

Spine-2:

router isis 1
address-family ipv4 unicast
segment-routing mpls
!
interface Loopback0
passive
address-family ipv4 unicast
prefix-sid absolute 16007
!

Verify that all devices that have ISIS Segment Routing con gured have advertised their pre x-SIDs. Also verify the pre x-
SIDs are learnt and programmed in the forwarding plane on each device. This output is collected from Spines; we can
see that the pre x-SID labels (identi ed by “Pfx”) of all the Leafs and other routers are learnt and programmed in the
forwarding plane along with their outgoing interfaces.

Spine-1:

RP/0/RP0/CPU0:Spine-1#show isis segment-routing label table

Tue Sep 4 23:35:11.115 UTC

IS-IS 1 IS Label Table

Label Prefix/Interface
---------- ----------------
16001 1.1.1.1/32
16002 2.2.2.2/32
16005 5.5.5.5/32
16006 Loopback0
16007 7.7.7.7/32
RP/0/RP0/CPU0:Spine-1#

RP/0/RP0/CPU0:Spine-1#show mpls forwarding

Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16001 Pop SR Pfx (idx 1) BE16 192.1.6.2 0
16002 Pop SR Pfx (idx 2) BE26 192.2.6.2 0
16005 Pop SR Pfx (idx 5) BE56 192.5.6.2 0
16007 16007 SR Pfx (idx 7) BE16 192.1.6.2 0
16007 SR Pfx (idx 7) BE26 192.2.6.2 0
16007 SR Pfx (idx 7) BE56 192.5.6.2 0
64000 Pop SR Adj (idx 1) BE16 192.1.6.2 0
64001 Pop SR Adj (idx 3) BE16 192.1.6.2 0
64002 Pop SR Adj (idx 1) BE26 192.2.6.2 0
64003 Pop SR Adj (idx 3) BE26 192.2.6.2 0
64004 Pop SR Adj (idx 1) BE56 192.5.6.2 0
64005 Pop SR Adj (idx 3) BE56 192.5.6.2 0

Spine-2:

RP/0/RP0/CPU0:Spine-2#show isis segment-routing label table

Tue Sep 4 23:45:48.834 UTC

IS-IS 1 IS Label Table

Label Prefix/Interface
---------- ----------------
16001 1.1.1.1/32
16002 2.2.2.2/32
16005 5.5.5.5/32
16006 6.6.6.6/32
16007 Loopback0
RP/0/RP0/CPU0:Spine-2#

RP/0/RP0/CPU0:Spine-2#show mpls forwarding

Tue Sep 4 23:46:40.028 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16001 Pop SR Pfx (idx 1) BE17 192.1.7.2 0
16002 Pop SR Pfx (idx 2) BE27 192.2.7.2 0
16005 Pop SR Pfx (idx 5) BE57 192.5.7.2 0
16006 16006 SR Pfx (idx 6) BE17 192.1.7.2 0
16006 SR Pfx (idx 6) BE27 192.2.7.2 0
16006 SR Pfx (idx 6) BE57 192.5.7.2 0
64000 Pop SR Adj (idx 1) BE17 192.1.7.2 0
64001 Pop SR Adj (idx 3) BE17 192.1.7.2 0
64002 Pop SR Adj (idx 1) BE27 192.2.7.2 0
64003 Pop SR Adj (idx 3) BE27 192.2.7.2 0
64004 Pop SR Adj (idx 1) BE57 192.5.7.2 0
64005 Pop SR Adj (idx 3) BE57 192.5.7.2 0
RP/0/RP0/CPU0:Spine-2#
After con guring ISIS segment routing, verify that the underlay is capable of forwarding tra c using labels assigned by
segment routing.

Below output shows traceroute from Leaf-1 to Leaf-5 using the loopback address. Trace from Leaf-1 reaches Leaf-5 via
Spines using label forwarding where Spine is the PHP for Leaf-5.

Ping from Leaf-1 to Leaf-5:

RP/0/RP0/CPU0:Leaf-1#ping sr-mpls 5.5.5.5/32

Tue Sep 4 23:40:51.032 UTC

Sending 5, 100-byte MPLS Echos to 5.5.5.5/32,

timeout is 2 seconds, send interval is 0 msec:

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/5/13 ms
RP/0/RP0/CPU0:Leaf-1#

Trace from Leaf-1 to Leaf-5

RP/0/RP0/CPU0:Leaf-1#trace sr-mpls 5.5.5.5/32

Tue Sep 4 23:42:06.069 UTC

Tracing MPLS Label Switched Path to 5.5.5.5/32, timeout is 2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 192.1.7.2 MRU 1500 [Labels: 16005 Exp: 0]

L 1 192.1.7.1 MRU 1500 [Labels: implicit-null Exp: 0] 121 ms
! 2 192.5.7.2 4 ms
RP/0/RP0/CPU0:Leaf-1#

Task 3: Con gure the BGP-EVPN Control-Plane

MP-BGP with its various address families is used to transport speci c reachability information in the network. BGP’s
L2VPN-EVPN address family is capable of transporting tenant-aware/VRF-aware IP (Layer-3) and MAC (Layer-2)
reachability information in MP-BGP. BGP EVPN provides the learnt information to all the devices within the network
through a common control plane. BGP EVPN next-hops are going to be reachable via segment routing paths.
In this con guration guide to con gure EVPN in the Fabric, we will con gure iBGP EVPN, however eBGP EVPN can also
be con gured and is support on NCS 5500 routers. Spines are con gured as the BGP EVPN Route Re ectors. Leaf-1,
Leaf-2 and Leaf-5 will all be Route Re ector clients.

Con gure Spines as RR for BGP EVPN address family.

Spine-1:

router bgp 65001

bgp router-id 6.6.6.6
!
address-family l2vpn evpn
!
neighbor-group RRC
remote-as 65001
update-source Loopback0
address-family l2vpn evpn
route-reflector-client
!
!
neighbor 1.1.1.1
use neighbor-group RRC
description BGP session to Leaf-1
!
neighbor 2.2.2.2
use neighbor-group RRC
description BGP session to Leaf-2
!
neighbor 5.5.5.5
use neighbor-group RRC
description BGP session to Leaf-5
!

Spine-2:

router bgp 65001

bgp router-id 7.7.7.7
!
address-family l2vpn evpn
!
neighbor-group RRC
remote-as 65001
update-source Loopback0
address-family l2vpn evpn
route-reflector-client
!
!
neighbor 1.1.1.1
 use neighbor-group RRC
description BGP session to Leaf-1
!
neighbor 2.2.2.2
use neighbor-group RRC
description BGP session to Leaf-2
!
neighbor 5.5.5.5
use neighbor-group RRC
description BGP session to Leaf-5
!
!

Use the following con guration and apply it to con gure the Leaf-1 Leaf-2 and Leaf-5 to form the BGP EVPN adjacency
between Leafs and Route Re ectors.

Leaf-1:

router bgp 65001

bgp router-id 1.1.1.1
!
address-family l2vpn evpn
!
neighbor 6.6.6.6
remote-as 65001
description "BGP session to Spine-1"
update-source Loopback0
address-family l2vpn evpn
!
!
neighbor 7.7.7.7
remote-as 65001
description "BGP session to Spine-2"
update-source Loopback0
address-family l2vpn evpn
!
!
!

Leaf-2:

router bgp 65001

bgp router-id 2.2.2.2
!
address-family l2vpn evpn
!
neighbor 6.6.6.6
remote-as 65001
description "BGP session to Spine-1"
update-source Loopback0
address-family l2vpn evpn
!
!
neighbor 7.7.7.7
remote-as 65001
description "BGP session to Spine-2"
update-source Loopback0
address-family l2vpn evpn
!
!
!
 Leaf-5:

router bgp 65001

bgp router-id 5.5.5.5
!
address-family l2vpn evpn
!
neighbor 6.6.6.6
remote-as 65001
description "BGP session to Spine-1"
update-source Loopback0
address-family l2vpn evpn
!
!
neighbor 7.7.7.7
remote-as 65001
description "BGP session to Spine-2"
update-source Loopback0
address-family l2vpn evpn
!
!
!

Use “show bgp l2vpn evpn summary” cli command to verify the evpn neighborship between Route Re ectors and Leafs.
Below output from the Spines show that the BGP EVPN neighborship is formed between the Leafs and the Route
Re ectors and the control-plane is up.

Spine-1:

RP/0/RP0/CPU0:Spine-1#show bgp l2vpn evpn summary

BGP router identifier 6.6.6.6, local AS number 65001

Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer

Speaker 1 1 1 1 1 0

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

1.1.1.1 0 65001 8 8 1 0 0 00:06:02 0
2.2.2.2 0 65001 7 7 1 0 0 00:04:53 0
5.5.5.5 0 65001 7 7 1 0 0 00:04:14 0

Spine-2:

RP/0/RP0/CPU0:Spine-2#show bgp l2vpn evpn summary

BGP router identifier 7.7.7.7, local AS number 65001

Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer

Speaker 1 1 1 1 1 0

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd

1.1.1.1 0 65001 9 10 1 0 0 00:06:50 0
2.2.2.2 0 65001 8 8 1 0 0 00:05:43 0
5.5.5.5 0 65001 7 7 1 0 0 00:05:03 0

In this post we covered the con guration and veri cation of BGP-EVPN control-plane and ISIS-SR based MPLS
forwarding plane. In the next post we will leverage the EVPN control-plane and ISIS-SR to provision BGP-EVPN based
Multi-Homing of devices.
 Tags: EVPN evpn iosxr NCS 5500 ncs5500

 Updated: September 04, 2018

SHARE ON

   

Leave a Comment

What do you think?

25 Responses

Upvote Funny Love Surprised

4 Comments 
1 Login

G Join the discussion…

LOG IN WITH OR SIGN UP WITH DISQUS ?

Name

 4 Share Best Newest Oldest

M
Mesghali Rasoul − ⚑
3 months ago edited

Amazing document.

If a platform supports SR/MPLS, and BGP-EVPN-SR functions in a leaf/spine data centre

network, what are the advantages of using VXLAN over SR/MPLS in the data plane of
leaf/spine EVPN data centres?
BGP-EVPN-SR supports multi-site DCI design.

On the other hand, SR supports TI-LFA and using SR policy gives the capability of service
chaining in DC for FW, LB, ...

0 0 Reply ⥅

Josma − ⚑
4 years ago edited
 y g

Superb document Ahmad.

Since P routers must support EVPN, we can't have BGP Free core?
But, we could at least enable only AF for EVPN, no need for IPv4/6, VPNv4/6?

Edit:
What if we have multiple PE rings, all connected to P ring. Can we have MPLS only on the
P routers and RR's in the PE rings?

0 0 Reply ⥅

A
Ahmad Bilal > Josma
− ⚑
4 years ago

You dont need to have EVPN con gured on P routers. In above example I am
using P routers as RRs but you can have MPLS only on P routers with separate
dedicated RRs in the ring.

0 0 Reply ⥅

Josma > Ahmad Bilal − ⚑

4 years ago

Thank you a lot for the con rmation!

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.