PBB-EVPN ISID-based Route Targets
This chapter provides information about PBB-EVPN ISID-based Route Targets.
Topics in this chapter include:
Applicability
This chapter was initially written based on SR OS Release 15.0.R4, but the MD-CLI in the current edition corresponds to SR OS Release 21.5.R1. PBB-EVPN ISID-based route targets are supported in SR OS Release 15.0.R1, and later.
Overview
The following BGP-EVPN routes are used in PBB-EVPN according to RFC 7623:
-
B-MAC routes—based on BGP-EVPN route type 2—are sent with the B-VPLS Route Target (RT), so they are sent to all the PEs where the B-VPLS is defined.
-
Ethernet Segment (ES) routes—route type 4—are used for multi-homing. ES routes are sent with an RT auto-derived from the ES Identifier (ESI). If the RT-constraint is enabled, the routes are sent to only those PEs that are part of the ES.
-
Inclusive Multicast Ethernet Tag (IMET) routes—route type 3—are used for the setup of per-ISID flooding domains and can be sent with a B-VPLS RT or with an ISID-based RT.
-
IMET routes are, by default, sent with a B-VPLS RT (referred to as IMET/0 routes), so they are imported by all the PEs where the B-VPLS is defined, as per RFC 7623, and supported in SR OS Release 13.0.R4, and later.
-
IMET routes with an ISID-based RT (referred to as IMET/ISID routes) are imported by only the PEs where the ISID is defined. RFC 7623 recommends these routes for deployments where the ISIDs are sparsely distributed in the network. This is supported in SR OS Release 15.0.R1, and later. The service ISID is encoded in the Ethernet tag field.
-
PBB-EVPN B-VPLS-based RT shows how the B-MAC and IMET routes with a B-VPLS RT sent by PE-1 are advertised to all other PEs (via the Route Reflector (RR)), regardless of the ISID.
PBB-EVPN ISID-based RT shows how the B-MAC routes are sent to all PEs within the B-VPLS, whereas the IMET routes sent by PE-1 are selectively reflected by the RR (due to RT-constraints) and only sent to PE-2, which is the only PE with the same ISID.
IMET routes with ISID-based RTs (IMET/ISID) can significantly reduce the number of IMET/ISID routes distributed by the RRs. The RT for the IMET/ISID route can be auto-derived from the corresponding Ethernet tag (ISID).
In addition to RFC 7623, the ISID-derived RTs can be used for BMAC/ISID routes if ISID-based CMAC flush is enabled, as per draft-snr-bess-pbb-evpn-isid-cmacflush. The service ISID is encoded in the Ethernet tag field.
PBB-EVPN ISID-based RT format
PBB-EVPN ISID-based RT format shows the ISID-based RT format:
For an auto-derived ISID-based RT, the values are as follows:
-
The Autonomous System (AS) number is obtained from the config>router>autonomous-system command:
-
Value = 2-byte AS number
-
For AS numbers with more than 2 bytes, the low-order 16-bit value is used.
-
-
A = 0 for auto-derivation
-
Type = 011 = 3 for ISID-based RT
-
Domain ID = 0000 (default)
-
ISID value
The auto-derived RT will be AS:00110000+ISID = AS:0x30+ISID Hex.
The type and sub-type of the BGP extended community is 0x00 and 0x02.
Enabling ISID-based RT
The following command is used to enable ISID-based RT for specific ISID ranges for IMET/ISID and BMAC/ISID routes.
*[ex:/configure service vpls "B-VPLS 100" bgp-evpn]
A:admin@PE-1# isid-route-target ?
isid-route-target
range + Enter the range list instance
The ISID range is configured as follows:
[ex:/configure service vpls "B-VPLS 100" bgp-evpn isid-route-target]
A:admin@PE-1# range ?
[start] <number>
<number> - <1..16777215>
Starting value of the isid-range entry
[ex:/configure service vpls "B-VPLS 100" bgp-evpn isid-route-target range 1]
A:admin@PE-1# end ?
end <number>
<number> - <1..16777215>
'end' is: mandatory
Ending value of the isid-range entry
The RT to be used for the I-VPLS can be auto-derived (default) or explicitly configured. The following configures an ISID range from 20 to 29 with auto-derived RT (default: type auto), whereas ISID 30 has a manually configured RT of 64500:30.
# on PE-1:
configure {
service {
vpls "B-VPLS 100" {
bgp-evpn {
isid-route-target {
range 20 {
end 29
# type auto # default
}
range 30 {
end 30
type configured
route-target "target:64500:30"
}
}
If isid-route-target is enabled, the IMET/ISID and BMAC/ISID route processing is modified in the export and import directions:
-
"Exported IMET/ISID and BMAC/ISID routes:
-
IMET/ISID routes are sent with an ISID-based RT for the local I-VPLS ISIDs and static ISIDs, unless the ISID is contained in an ISID policy for which advertise-local false is configured.
-
When isid-route-target and ivpls-mac-flush>bgp-evpn>send-to-bvpls are both enabled for an I-VPLS, the BMAC/ISID route will also be sent with the ISID-based RT instead of the B-VPLS-based RT.
-
The isid-route-target command has impact only on IMET/ISID and BMAC/ISID, not on IMET/0, BMAC/0, or ES routes.
-
When a new ISID-based RT is added for an I-VPLS, a BGP update is sent for the existing IMET/ISID and BMAC/ISID routes. The new RT will be added when the routes are advertised.
-
-
Imported IMET/ISID and BMAC/ISID routes:
-
When isid-route-target is enabled for an I-VPLS, BGP will start importing IMET/ISID routes and—if ivpls-mac-flush>bgp-evpn>send-to-bvpls is enabled—BMAC/ISID routes with ISID-based RTs.
-
ISID-based RTs are added for import operations when the I-VPLS is associated with the B-VPLS (regardless of the operational state of the I-VPLS) and/or when the static ISID has been added.
-
Ensure that the ISID-based RTs are configured consistently in the network. The system does not keep a mapping of RTs and ISIDs for imported routes.
-
The system will not check the format of the received auto-derived RTs. Routes will be imported when the RT is on the list of RTs for the B-VPLS.
-
-
When isid-route-target is configured for an I-VPLS, VSI import/export policies are blocked in the B-VPLS, whereas BGP import/export policies are allowed and matching on the export ISID-based RT is supported.
Some other considerations:
-
ISID ranges cannot overlap within a B-VPLS, but they can overlap across different B-VPLSs.
-
The explicitly configured RT is meant to be used in two cases:
-
ISID aggregation - when multiple ISIDs are using the same ISID RT
-
Interoperability - in case the peer sends an RT in a different format
-
ISID-based RTs and RT-constraint
The use of the RT-constraint feature (BGP family route-target) maximizes the benefits of using different RTs per ISID; therefore, service providers are expected to enable both ISID-based RTs and RT-constraint. RT-constraint is enabled by adding the BGP address family route-target in the general BGP settings, per group, or per neighbor, as follows:
configure {
router "Base" {
bgp {
family {
route-target true
---snip---
group "internal" {
family {
route-target true
---snip---
neighbor 192.0.2.4 {
family {
route-target true
---snip---
The system will advertise the RT-constraint route when the I-VPLS is associated with the B-VPLS, regardless of the operational state of the I-VPLS. However, the IMET/ISID and the BMAC/ISID routes are sent based on the I-VPLS operational state.
Configuration
Example topology shows the example topology with three PEs and an RR.
Initial configuration
The initial configuration on the nodes includes the following:
-
Cards, MDAs, ports
-
Router interfaces
-
IS-IS enabled on all router interfaces (alternatively, OSPF could be used)
-
SR-ISIS enabled on the PEs (but disabled on the RR)
BGP is configured on all PEs for address family EVPN, as follows.
# on PE-1, PE-2, PE-3:
configure {
router "Base" {
autonomous-system 64500
bgp {
rapid-withdrawal true
split-horizon true
family {
ipv4 false
evpn true
}
rapid-update {
evpn true
}
group "internal" {
peer-as 64500
}
neighbor "192.0.2.4" {
group "internal"
}
}
On RR-4, BGP is configured as follows:
# on RR-4:
configure {
router "Base" {
autonomous-system 64500
bgp {
rapid-withdrawal true
split-horizon true
family {
ipv4 false
evpn true
}
rapid-update {
evpn true
}
group "internal" {
peer-as 64500
cluster {
cluster-id 1.1.1.1
}
}
neighbor "192.0.2.1" {
group "internal"
}
neighbor "192.0.2.2" {
group "internal"
}
neighbor "192.0.2.3" {
group "internal"
}
}
For the RT-constraint feature, the route-target address family can be configured in combination with the EVPN address family; see section ISID-based RTs and RT-constraint.
The initial service configuration on PE-1 without ISID-based RTs is as follows:
# on PE-1:
configure {
service {
system {
bgp-auto-rd-range {
ip-address 192.0.2.1
community-value {
start 10
end 99
}
}
}
vpls "B-VPLS 100" {
admin-state enable
service-id 100
customer "1"
service-mtu 2000
pbb-type b-vpls
pbb {
source-bmac {
address 00:00:00:00:00:01
}
}
bgp 1 {
}
bgp-evpn {
evi 100
mpls 1 {
admin-state enable
auto-bind-tunnel {
resolution any
}
}
}
}
vpls "I-VPLS 1" {
admin-state enable
service-id 1
customer "1"
pbb-type i-vpls
pbb {
backbone-vpls "B-VPLS 100" {
isid 1
}
}
bgp 1 {
route-distinguisher auto-rd
route-target {
export "target:64500:1"
import "target:64500:1"
}
}
sap 1/2/1:1 {
}
}
vpls "I-VPLS 2" {
admin-state enable
service-id 2
customer "1"
pbb-type i-vpls
pbb {
backbone-vpls "B-VPLS 100" {
isid 2
}
}
bgp 1 {
route-distinguisher auto-rd
route-target {
export "target:64500:2"
import "target:64500:2"
}
}
sap 1/2/1:2 {
}
}
The service configuration on PE-2 is similar, but only I-VPLS 1 is configured. On PE-3, only I-VPLS 2 is configured.
PE-1 sends the following default BGP-EVPN IMET/0 update to the RR:
# on PE-1:
2 2021/05/28 08:55:18.406 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 77
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family EVPN
NextHop len 4 NextHop 192.0.2.1
Type: EVPN-INCL-MCAST Len: 17 RD: 192.0.2.1:100, tag: 0, orig_addr len: 32,
orig_addr: 192.0.2.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:64500:100
bgp-tunnel-encap:MPLS
Flag: 0xc0 Type: 22 Len: 9 PMSI:
Tunnel-type Ingress Replication (6)
Flags: (0x0)[Type: None BM: 0 U: 0 Leaf: not required]
MPLS Label 8388560
Tunnel-Endpoint 192.0.2.1
"
The following BGP-EVPN IMET routes are received on PE-1. Toward each other PE, there is a route with Ethernet tag 0; toward PE-2, there is a route with Ethernet tag 1 for ISID 1; toward PE-3, there is a route with Ethernet tag 2.
[/]
A:admin@PE-1# show router bgp routes evpn incl-mcast
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN Inclusive-Mcast Routes
===============================================================================
Flag Route Dist. OrigAddr
Tag NextHop
-------------------------------------------------------------------------------
u*>i 192.0.2.2:100 192.0.2.2
0 192.0.2.2
u*>i 192.0.2.2:100 192.0.2.2
1 192.0.2.2
u*>i 192.0.2.3:100 192.0.2.3
0 192.0.2.3
u*>i 192.0.2.3:100 192.0.2.3
2 192.0.2.3
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
All these routes have a B-VPLS-based RT equal to 64500:100, as follows:
[/]
A:admin@PE-1# show router bgp routes evpn incl-mcast detail | match Community
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
In the preceding output, each of the four inclusive multicast routes occurs twice: the first time with the original attributes, the second time with the modified attributes, but in this example, the attribute did not change.
For the EVPN MAC routes, the output is similar. ISID-based CMAC flush is not enabled yet, so there are only BMAC/0 routes, no BMAC/ISID routes, as follows:
[/]
A:admin@PE-1# show router bgp routes evpn mac
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN MAC Routes
===============================================================================
Flag Route Dist. MacAddr ESI
Tag Mac Mobility Label1
Ip Address
NextHop
-------------------------------------------------------------------------------
u*>i 192.0.2.2:100 00:00:00:00:00:02 ESI-0
0 Static LABEL 524285
n/a
192.0.2.2
u*>i 192.0.2.3:100 00:00:00:00:00:03 ESI-0
0 Static LABEL 524285
n/a
192.0.2.3
-------------------------------------------------------------------------------
Routes : 2
===============================================================================
Both EVPN MAC routes have the same B-VPLS-based RT with value 64500:100, as follows:
[/]
A:admin@PE-1# show router bgp routes evpn mac detail | match Community
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
ISID-based RTs
On the PEs, B-VPLS 100 is configured with ISID-based RTs, but initially without ISID-based CMAC flush, as follows:
# on PE-1, PE-2:
configure {
service {
vpls "B-VPLS 100" {
bgp-evpn {
isid-route-target {
range 1 {
end 2
}
range 10 {
end 11
type configured
route-target "target:64500:10"
}
}
}
B-VPLS 100 has two ISID-ranges configured:
-
For ISIDs 1 and 2, the RT is auto-derived. The hexadecimal value for ISID 1 is 0x30000001, which corresponds to decimal value 805306369. The hexadecimal value for ISID 2 is 0x30000002 (decimal value 805306370). For ISID 1, the RT is 64500: 805306369; for ISID 2, the RT is 64500: 805306370.
-
For ISIDs 10 and 11, the RT is manually configured as 64500:10.
The configuration is identical on PE-2. On PE-3, only ISID range 2 is configured, as follows:
# on PE-3:
configure {
service {
vpls "B-VPLS 100" {
bgp-evpn {
isid-route-target {
range 2 {
end 2
}
}
}
On PE-1, the same four BGP-EVPN IMET routes are shown, as follows:
[/]
A:admin@PE-1# show router bgp routes evpn incl-mcast
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN Inclusive-Mcast Routes
===============================================================================
Flag Route Dist. OrigAddr
Tag NextHop
-------------------------------------------------------------------------------
u*>i 192.0.2.2:100 192.0.2.2
0 192.0.2.2
u*>i 192.0.2.2:100 192.0.2.2
1 192.0.2.2
u*>i 192.0.2.3:100 192.0.2.3
0 192.0.2.3
u*>i 192.0.2.3:100 192.0.2.3
2 192.0.2.3
-------------------------------------------------------------------------------
Routes : 4
The IMET route with Ethernet tag 1 now has RT 64500:805306369 (ISID 1) and the IMET route with Ethernet tag 2 has RT 64500:805306370 (ISID 2), as follows:
[/]
A:admin@PE-1# show router bgp routes evpn incl-mcast detail | match Community
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:805306369 bgp-tunnel-encap:MPLS
Community : target:64500:805306369 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:805306370 bgp-tunnel-encap:MPLS
Community : target:64500:805306370 bgp-tunnel-encap:MPLS
Again, each route has two identical entries in the preceding command: one with the original attributes and another with the modified attributes.
The following BGP-EVPN IMET/ISID route is sent by PE-1 for ISID 1. The Ethernet tag is 1 and the RT is 64500:805306369.
# on PE-1:
11 2021/05/28 08:59:47.220 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 77
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family EVPN
NextHop len 4 NextHop 192.0.2.1
Type: EVPN-INCL-MCAST Len: 17 RD: 192.0.2.1:100, tag: 1, orig_addr len: 32,
orig_addr: 192.0.2.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:64500:805306369
bgp-tunnel-encap:MPLS
Flag: 0xc0 Type: 22 Len: 9 PMSI:
Tunnel-type Ingress Replication (6)
Flags: (0x0)[Type: None BM: 0 U: 0 Leaf: not required]
MPLS Label 8388560
Tunnel-Endpoint 192.0.2.1
"
The following BGP-EVPN IMET/ISID route is sent by PE-1 for ISID 2. The Ethernet tag is 2 and the RT is 64500:805306370.
# on PE-1:
12 2021/05/28 08:59:47.220 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 77
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family EVPN
NextHop len 4 NextHop 192.0.2.1
Type: EVPN-INCL-MCAST Len: 17 RD: 192.0.2.1:100, tag: 2, orig_addr len: 32,
orig_addr: 192.0.2.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:64500:805306370
bgp-tunnel-encap:MPLS
Flag: 0xc0 Type: 22 Len: 9 PMSI:
Tunnel-type Ingress Replication (6)
Flags: (0x0)[Type: None BM: 0 U: 0 Leaf: not required]
MPLS Label 8388560
Tunnel-Endpoint 192.0.2.1
"
When a SAP (or SDP binding) is added with static ISID 11, RT 64500:10 will be added. The service configuration on PE-1 is modified as follows:
# on PE-1:
configure {
service {
vpls "B-VPLS 100" {
bgp-evpn {
isid-route-target {
range 1 {
end 2
}
range 10 {
end 11
type configured
route-target "target:64500:10"
}
}
}
sap 1/1/1:100 {
static-isid {
range 1 {
start 11
end 11
}
}
}
isid-policy {
entry 10 {
range {
start 11
end 11
}
}
}
The configuration is similar on PE-2. Only on PE-1 and PE-2, SAPs are configured, with static ISID 11. The following IMET/ISID route with RT 64500:10 is sent by PE-1:
# on PE-1:
13 2021/05/28 08:59:47.251 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 77
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family EVPN
NextHop len 4 NextHop 192.0.2.1
Type: EVPN-INCL-MCAST Len: 17 RD: 192.0.2.1:100, tag: 11, orig_addr len: 32,
orig_addr: 192.0.2.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:64500:10
bgp-tunnel-encap:MPLS
Flag: 0xc0 Type: 22 Len: 9 PMSI:
Tunnel-type Ingress Replication (6)
Flags: (0x0)[Type: None BM: 0 U: 0 Leaf: not required]
MPLS Label 8388560
Tunnel-Endpoint 192.0.2.1
"
This RT 64500:10 is not auto-derived, but configured manually for ISID range 10 to 11.
ISID-based CMAC flush
ISID-based CMAC flush is described in chapter PBB-EVPN ISID-based CMAC Flush and requires the following configuration on PE-1:
# on PE-1:
configure {
service {
vpls "I-VPLS 1" {
pbb {
i-vpls-mac-flush {
bgp-evpn {
send-to-bvpls true
}
}
}
}
vpls "I-VPLS 2" {
pbb {
i-vpls-mac-flush {
bgp-evpn {
send-to-bvpls true
}
}
}
}
vpls "B-VPLS 100" {
bgp-evpn {
accept-ivpls-evpn-flush true
}
The configuration on PE-2 and PE-3 is similar, but only needs to be applied for I-VPLS 1 on PE-2 (I-VPLS 2 is not configured on PE-2) and for I-VPLS 2 on PE-3. The configuration for B-VPLS 100 is the same on all PEs.
When ISID-based CMAC flush is enabled on the PEs, additional BGP-EVPN MAC routes are sent by PE-1 for ISIDs 1 and 2:
# on PE-1:
27 2021/05/28 09:02:38.769 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 89
Flag: 0x90 Type: 14 Len: 44 Multiprotocol Reachable NLRI:
Address Family EVPN
NextHop len 4 NextHop 192.0.2.1
Type: EVPN-MAC Len: 33 RD: 192.0.2.1:100 ESI: ESI-0, tag: 2, mac len: 48
mac: 00:00:00:00:00:01, IP len: 0, IP: NULL, label1: 8388560
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 24 Extended Community:
target:64500:805306370
bgp-tunnel-encap:MPLS
mac-mobility:Seq:0/Static
"
25 2021/05/28 09:02:38.769 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 89
Flag: 0x90 Type: 14 Len: 44 Multiprotocol Reachable NLRI:
Address Family EVPN
NextHop len 4 NextHop 192.0.2.1
Type: EVPN-MAC Len: 33 RD: 192.0.2.1:100 ESI: ESI-0, tag: 1, mac len: 48
mac: 00:00:00:00:00:01, IP len: 0, IP: NULL, label1: 8388560
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 24 Extended Community:
target:64500:805306369
bgp-tunnel-encap:MPLS
mac-mobility:Seq:0/Static
"
The BGP-EVPN MAC routes for ISIDs 1 and 2 use the same auto-derived RT values as the IMET/ISID routes. The following four BGP-EVPN MAC routes are received in PE-1:
[/]
A:admin@PE-1# show router bgp routes evpn mac
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP EVPN MAC Routes
===============================================================================
Flag Route Dist. MacAddr ESI
Tag Mac Mobility Label1
Ip Address
NextHop
-------------------------------------------------------------------------------
u*>i 192.0.2.2:100 00:00:00:00:00:02 ESI-0
0 Static LABEL 524285
n/a
192.0.2.2
u*>i 192.0.2.2:100 00:00:00:00:00:02 ESI-0
1 Static LABEL 524285
n/a
192.0.2.2
u*>i 192.0.2.3:100 00:00:00:00:00:03 ESI-0
0 Static LABEL 524285
n/a
192.0.2.3
u*>i 192.0.2.3:100 00:00:00:00:00:03 ESI-0
2 Static LABEL 524285
n/a
192.0.2.3
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
The BMAC/0 routes have an RT based on the B-VPLS, whereas the BMAC/ISID routes have an RT derived from the ISID, as follows:
[/]
A:admin@PE-1# show router bgp routes evpn mac detail | match Community
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:805306369 bgp-tunnel-encap:MPLS
Community : target:64500:805306369 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:100 bgp-tunnel-encap:MPLS
Community : target:64500:805306370 bgp-tunnel-encap:MPLS
Community : target:64500:805306370 bgp-tunnel-encap:MPLS
ISID-based RTs and RT-constraint
To show that RT BGP updates are sent when the I-VPLS is associated with the B-VPLS, the I-VPLSs are initially disassociated from B-VPLS 100 on PE-1, as follows:
# on PE-1:
configure {
service {
vpls "I-VPLS 1" {
pbb {
delete backbone-vpls "B-VPLS 100"
}
}
vpls "I-VPLS 2" {
pbb {
delete backbone-vpls "B-VPLS 100"
}
}
The BGP configuration is modified on all nodes to include address families route-target and EVPN, as follows:
# on PE-1, PE-2, PE-3, RR-4:
configure {
router "Base" {
bgp {
family {
route-target true
evpn true
}
The following RT-constraint route is sent by PE-1 after I-VPLS 1 is associated with B-VPLS 100. The RT is auto-derived from the ISID 1:
# on PE-1:
configure {
service {
vpls "I-VPLS 1" {
pbb {
backbone-vpls "B-VPLS 100" {
isid 1
}
}
}
vpls "I-VPLS 2"
pbb {
backbone-vpls "B-VPLS 100" {
isid 2
}
}
}
# on PE-1:
73 2021/05/28 09:09:34.587 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 47
Flag: 0x90 Type: 14 Len: 22 Multiprotocol Reachable NLRI:
Address Family RTC_V4
NextHop len 4 NextHop 192.0.2.1
[RT-Const-V4] origin-as 64500, Target target:64500:805306369
Flag: 0x40 Type: 1 Len: 1 Origin: 2
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
"
When the I-VPLS goes operationally down, the IMET/ISID and BMAC/ISID routes are withdrawn, but not the RT-constraint route.
# on PE-1:
configure {
service {
vpls "I-VPLS 1" {
admin-state disable
# on PE-1:
83 2021/05/28 09:10:33.458 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 61
Flag: 0x90 Type: 15 Len: 57 Multiprotocol Unreachable NLRI:
Address Family EVPN
Type: EVPN-INCL-MCAST Len: 17 RD: 192.0.2.1:100, tag: 1, orig_addr len: 32,
orig_addr: 192.0.2.1
Type: EVPN-MAC Len: 33 RD: 192.0.2.1:100 ESI: ESI-0, tag: 1, mac len: 48
mac: 00:00:00:00:00:01, IP len: 0, IP: NULL, label1: 0
"
The RT-constraint route is withdrawn when the I-VPLS is disassociated from B-VPLS 100, as follows:
# on PE-1:
configure {
service {
vpls "I-VPLS 1" {
pbb {
delete backbone-vpls "B-VPLS 100"
# on PE-1:
84 2021/05/28 09:11:28.205 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.4
"Peer 1: 192.0.2.4: UPDATE
Peer 1: 192.0.2.4 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 20
Flag: 0x90 Type: 15 Len: 16 Multiprotocol Unreachable NLRI:
Address Family RTC_V4
[RT-Const-V4] origin-as 64500, Target target:64500:805306369
"
Conclusion
PBB-EVPN ISID-based RTs, in combination with RT-constraint, reduce the number of advertised IMET routes to only those nodes where the ISID is configured. The ISID-based RT can be auto-derived from the ISID or configured manually. When ISID-based CMAC flush is also enabled, the BMAC/ISID routes will contain the same auto-derived RT.