Shortest Path Bridging for MAC
This chapter describes advanced shortest path bridging for MAC configurations.
Topics in this chapter include:
Applicability
This chapter was initially written for SR OS Release 11.0.R4, but the MD-CLI in the current edition is based on SR OS Release 23.7.R2.
Overview
SPB enables a next generation control plane for Provider Backbone Bridges (PBB) and PBB-VPLS that adds the stability and efficiency of link state to unicast and multicast services (Epipes and I-VPLSs). In addition, SPBM provides resiliency, load balancing, and multicast optimization without the need for any other control plane in the B-VPLS (for example, there is no need for spanning tree, or G.8032, or Multiple MAC Registration Protocol (MMRP)).
SPBM exploits the complete knowledge of backbone addressing, which is a key consequence of the PBB hierarchy, by advertising and distributing the backbone MAC addresses (BMACs) through a link-state protocol, namely IS-IS. An immediate effect of this is that the old ‟flood-and-learn” can at last be turned off in the backbone and every B-VPLS node in the network will know what destination BMAC addresses are expected and valid. As a result of that, receiving an unknown unicast BMAC on a B-VPLS SAP or PW is indicative of an error, whereupon the frame is discarded (due to the Reverse Path Forwarding Check (RPFC) performed in SPBM) instead of flooded. Furthermore, SPBM allows condensing all the relevant information distribution (unicast and multicast) into a single control protocol: IS-IS.
SPBM can be easily enabled on the existing B-VPLS instances being used for multiplexing I-VPLS and Epipe services, providing the following benefits:
Per-service flood containment (for I-VPLS services) without the need for an additional protocol such as MMRP,
Loop avoidance in the B-VPLS domain without the need for MSTP or other technologies,
No unknown BMAC flooding in the B-VPLS domain,
No need for MAC notification mechanisms or vMEPs in the B-VPLS to update the B-VPLS forwarding databases (FDBs) (vMEPs can still be configured though for OAM purposes).
Some other characteristics of the SPB implementation in the SR OS are:
The SR OS SPB implementation always uses Multi-Topology (MT) topology instance zero. However, up to four logical instances (that is, SPB instances in different B-VPLS services) are supported if different topologies are required for different services.
Area addresses are not used and SPB is assumed to be a single area. SPB must be consistently configured on nodes in the system. SPB regions information and IS-IS hello logic that detect mismatched configuration are not supported. IS-IS area is always zero.
SPB uses all-intermediate systems 09-00-2B-00-00-05 destination MAC to communicate.
SPB source ID is always zero.
SPB uses a separate instance of IS-IS from the base IP IS-IS. IS-IS for SPB is configured in the SPB context under the B-VPLS component. Up to four ISIS-SPB instances are supported, where the instance identifier can be any number between 1024 and 2047. The instance number is not in TLVs.
Two Equal Cost Tree (ECT) algorithms (IEEE 802.1aq) per SPB instance are supported: low-path-id and high-path-id algorithms.
SPB link state protocol data units (link state packets) contain BMACs, ISIDs (for multicast services) and link and metric information for an IS-IS database.
Epipe ISIDs are not distributed in SR OS SPB allowing high scalability of PBB Epipes.
I-VPLS ISIDs are distributed in SR OS SPB and the respective multicast group addresses (composed of PBB-OUI plus ISID) are automatically populated in a manner that provides automatic pruning of multicast to the subset of the multicast tree that supports an I-VPLS with a common ISID. This replaces the function of MMRP and is more efficient than MMRP.
Multiple ISIS-SPB adjacencies between two nodes are not supported as per the IEEE 802.1aq standard specification. If multiple links between two nodes exist, LAG must be used.
Configuration
This section describes the configuration of SPBM on SR OS as well as the available troubleshooting commands.
Basic SPBM configuration
Basic SPBM topology shows the topology used as an example of a basic SPBM configuration.
Assume the following protocols and objects are configured beforehand:
The six PEs shown in Basic SPBM topology are running IS-IS for the global routing table with all the interfaces being level-2.
LDP is used as the MPLS protocol to signal transport tunnel labels.
LDP SDPs are configured among the six PEs, as shown in Basic SPBM topology (dashed lines and bold lines among PEs).
Once the network infrastructure is properly running, the actual service configuration can be carried out. In the example, B-VPLS-10 will provide backbone connectivity for the services I-VPLS-11 and Epipe-12.
The SPBM configuration is only relevant to the B-VPLS instance and can be added to an existing B-VPLS, assuming that such a B-VPLS does not contain any non-SPB-compatible configuration parameters. The following parameters are not supported in SPB-enabled B-VPLS instances:
Mesh SDPs (only SAPs or spoke-SDPs are supported in SPB-enabled B-VPLS)
Spanning tree protocol (STP)
Split-horizon groups
Non-conditional static-MAC addresses (configured under SAPs or spoke-SDPs, see the Static BMACs and static ISIDs configuration section)
G.8032
mac-flush tldp propagate and mac-flush tldp send-on-failure (because failures within the B-VPLS are handled by SPB)
Maximum number of MAC addresses (fdb maximum-mac-addresses)
Bridge Protocol Data Unit (BPDU) translation
Layer 2 Protocol Termination (L2PT)
MAC-pinning
Operational groups
MAC-move
Any BGP, BGP auto-discovery (BGP-AD), or BGP virtual private LAN services (BGP-VPLS) parameters
Endpoints
Local/remote age
MAC notification
MAC protect
Multiple MAC Registration Protocol (MMRP)
Provider tunnel
Temporary flooding
Assuming all the parameters mentioned are not configured in the B-VPLS (B-VPLS-10 in the example), SPBM can be enabled. The SPBM parameters are all configured in the configure service vpls(b-vpls) spb and configure service vpls(b-vpls) spoke-sdp/sap spb contexts:
[ex:/configure service vpls "B-VPLS-10"]
A:admin@PE-1# spb ?
spb
Immutable fields - isis-instance, fid
admin-state - Administrative state of SPB
apply-groups - Apply a configuration group at this level
apply-groups-exclude - Exclude a configuration group at this level
fid - FID identifier
isis-instance - ISIS instance
level + Enter the level list instance
lsp-lifetime - Time LSP is considered valid by other routers
lsp-refresh-interval + Enter the lsp-refresh-interval context
overload + Enable the overload context
overload-on-boot + Enable the overload-on-boot context
timers + Enter the timers context
[ex:/configure service vpls "B-VPLS-10" spb]
A:admin@PE-1# timers ?
timers
lsp-wait + Enable the lsp-wait context
spf-wait + Enable the spf-wait context
[ex:/configure service vpls "B-VPLS-10" spoke-sdp 12:10]
A:admin@PE-1# spb ?
spb
admin-state - Admin state
apply-groups - Apply a configuration group at this level
apply-groups-exclude - Exclude a configuration group at this level
level + Enter the level list instance
lsp-pacing-interval - Lsp pacing interval
retransmit-interval - Retransmit interval
[ex:/configure service vpls "B-VPLS-10" spoke-sdp 12:10 spb]
A:admin@PE-1# level 1 ?
level
apply-groups - Apply a configuration group at this level
apply-groups-exclude - Exclude a configuration group at this level
hello-interval - Hello interval
hello-multiplier - Hello multiplier
metric - Metric
The parameters configured in the spb context refer to the SPB IS-IS and they should be configured following the same considerations as for the IS-IS base instance:
spb
isis-instance <isis-instance[1024..2047]> identifies the SPB IS-IS process. Up to four different IS-IS SPB processes can be run in a system.
forwarding identifier <fid> identifies the standard SPBM B-VID which is signaled in IS-IS with each advertised BMAC. Each B-VPLS has a single configurable FID.
-
lsp-lifetime <seconds> : [350..65535]
-
lsp-refresh-interval <seconds> : [150..65535]
-
overload [timeout <seconds>] : [60..1800]
-
overload-on-boot [timeout <seconds>] : [60..1800]
-
timers
-
lsp-wait
-
max-wait : [10..120000] in milliseconds
-
initial-wait : [10..100000] in milliseconds
-
second-wait : [10..100000] in milliseconds
-
-
spf-wait
-
max-wait : [10..120000] in milliseconds
-
initial-wait : [10..100000] in milliseconds
-
second-wait : [10..100000] in milliseconds
-
-
spoke-sdp/sap
-
spb
-
lsp-pacing-interval <milli-seconds> : [0..65535]
-
retransmit-interval <seconds> : [1..65535]
-
level 1
-
hello-interval <seconds> : [1..20000]
-
hello-multiplier <multiplier> : [2..100]
-
-
-
-
In the same way, lsp-wait (initial-wait) and spf-wait (initial-wait) can be tuned in the base router IS-IS instance to minimize the convergence time (to 0 and 10 respectively), the equivalent SPB IS-IS parameters should also be adjusted so that failover time is minimized at the service level.
The following parameters are specific to SPBM (note that only IS-IS level 1 is supported for SPB):
spb level 1 bridge-priority <bridge-priority> : [0..15]
This parameter influences the election of the multicast designated bridge through which all the Single Trees (STs) for the multicast traffic are established. The default value will be lowered on that node where the multicast designated bridge function is desired, normally because that node is the best connected node. In the example, PE-2 is the multicast designated bridge for B-VPLS-10 and therefore, PE-2 will be the root of the STs for the I-VPLS instances in that B-VPLS. Default value = 8.
spb level 1 ect-high-path-fid <fid>
Two ECT algorithms are supported: low-path-id and high-path-id. They can provide the required path diversity for an efficient load balancing in the B-VPLS. By default, the low-path-id ECT algorithm applies for all FIDs from 1 to 4095. The ect-high-path-fid <fid> command defines for which FID values the high-path-id ECT algorithm is used.
spb level 1 forwarding-tree topology {spf|st}
This command configures the type of tree to be used for unicast traffic: shortest path tree or single tree. The multicast traffic (that encapsulated I-VPLS Broadcast, Unknown unicast, and Multicast (BUM) traffic always uses the ST path. Using SPF for unicast traffic can produce some packet re-ordering for unicast traffic compared to BUM traffic because different trees are used, therefore, when the B-VPLS transports I-VPLS traffic and the unicast and multicast trees do not follow the same path, it is recommended to use ST paths for unicast and multicast. Default value = spf.
spoke-sdp/sap spb level 1 metric <number> : [1..16777215]
This command configures the metric for each SPB interface (spoke-SDP or SAP). This value helps influence the SPF calculation in order to pick a certain path for the traffic to a remote system BMAC.When the SPB link metric advertised by two peers is different, the maximum value is chosen according to the RFC 6329. Default value = 0 (no metric).
As an example, the following CLI output shows the relevant configuration of PE-1 and PE-2 (the multicast designated bridge). SPB has to be created and enabled at B-VPLS service level first and then created and enabled under every SAP or spoke-SDP in the B-VPLS. Non-SPB-enabled SAPs or spoke-SDPs can exist in the SPB B-VPLS only if conditional static-MACs are configured for them (see the Static BMACs and static ISIDs configuration section). As for regular B-VPLS services, the service MTU has to be changed from the default value (1500) to a number 18 bytes greater than the I-VPLS service MTU in order to allow for the PBB encapsulation.
# on PE-1:
configure {
service {
pbb {
source-bmac {
address 00:00:5e:00:53:01
}
mac "PE-1" {
address 00:00:5e:00:53:01
}
mac "PE-2" {
address 00:00:5e:00:53:02
}
mac "PE-3" {
address 00:00:5e:00:53:03
}
mac "PE-4" {
address 00:00:5e:00:53:04
}
mac "PE-5" {
address 00:00:5e:00:53:05
}
mac "PE-6" {
address 00:00:5e:00:53:06
}
}
vpls "B-VPLS-10" {
admin-state enable
service-id 10
customer "1"
service-mtu 2000
pbb-type b-vpls
spb {
admin-state enable
# isis-instance 1024 # default: 1024
fid 10
overload-on-boot {
timeout 60
}
timers {
lsp-wait {
max-wait 8000
# initial-wait 10 # default
# second-wait 1000 # default
}
spf-wait {
max-wait 2000
initial-wait 50000
second-wait 100000
}
}
}
spoke-sdp 12:10 {
spb {
admin-state enable
}
}
spoke-sdp 16:10 {
spb {
admin-state enable
}
}
}
vpls "I-VPLS-11" {
admin-state enable
service-id 11
customer "1"
pbb-type i-vpls
pbb {
backbone-vpls "B-VPLS-10" {
isid 11
}
}
sap 1/1/c3/1:11 {
}
}
epipe "Epipe-12" {
admin-state enable
service-id 12
customer "1"
pbb {
tunnel {
backbone-vpls-service-name "B-VPLS-10"
isid 12
backbone-dest-mac-name "PE-4"
}
}
sap 1/1/c3/1:12 {
}
}
As discussed, the bridge-priority influences the election of the multicast designated bridge. By making PE-2’s bridge-priority zero, it ensures that PE-2 becomes the root of all the STs for B-VPLS-10 as long as the priority for the rest of the PEs is larger than zero. In case of a tie, the PE owning the lowest system BMAC will be elected as multicast designated bridge. Basic SPBM topology shows the ST for I-VPLS-11 (see a thicker continuous line representing the ST). PE-2 is the root of the ST tree.
# on PE-2:
configure {
service {
pbb {
source-bmac {
address 00:00:5e:00:53:02
}
mac "PE-1" {
address 00:00:5e:00:53:01
}
mac "PE-2" {
address 00:00:5e:00:53:02
}
mac "PE-3" {
address 00:00:5e:00:53:03
}
mac "PE-4" {
address 00:00:5e:00:53:04
}
mac "PE-5" {
address 00:00:5e:00:53:05
}
mac "PE-6" {
address 00:00:5e:00:53:06
}
}
vpls "B-VPLS-10" {
admin-state enable
service-id 10
customer "1"
service-mtu 2000
pbb-type b-vpls
spb {
admin-state enable
isis-instance 1024
fid 10
overload-on-boot {
timeout 60
}
timers {
lsp-wait {
max-wait 8000
}
spf-wait {
max-wait 2000
initial-wait 50000
second-wait 100000
}
}
level 1 {
bridge-priority 0
}
}
spoke-sdp 21:10 {
spb {
admin-state enable
}
}
spoke-sdp 23:10 {
spb {
admin-state enable
}
}
spoke-sdp 25:10 {
spb {
admin-state enable
}
}
spoke-sdp 26:10 {
spb {
admin-state enable
}
}
}
The rest of the nodes is configured accordingly. SPB instance 1024 will set up shortest path first (SPF) trees for unicast traffic and a single tree (ST) per ISID with PE-2 as the root bridge (because it has the lowest bridge priority 0 configured) for BUM traffic. The ECT algorithm chosen for the B-VPLS FID (10) is the low-path-id (default).
Once SPBM is configured on all the six nodes, the six system BMAC addresses and the ISID 11 will be advertised by SPB IS-IS.
The following show commands can help understand the IS-IS configuration for SPB 1024 and the BMAC addresses populated by IS-IS:
show service id "B-VPLS-10" spb base provides the SPB configuration and parameters for a particular SPB B-VPLS.
[/] A:admin@PE-1# show service id "B-VPLS-10" spb base =============================================================================== Service SPB Information =============================================================================== Admin State : Up Oper State : Up ISIS Instance : 1024 FID : 10 Bridge Priority : 8 Fwd Tree Top Ucast : spf Fwd Tree Top Mcast : st Bridge Id : 80:00.00:00:5e:00:53:01 Mcast Desig Bridge : 00:00.00:00:5e:00:53:02 =============================================================================== Rtr Base ISIS Instance 1024 Interfaces =============================================================================== Interface Level CircID Oper L1/L2 Metric Type State ------------------------------------------------------------------------------- sdp:12:10 L1 65538 Up 10/- p2p sdp:16:10 L1 65539 Up 10/- p2p ------------------------------------------------------------------------------- Interfaces : 2 =============================================================================== FID ranges using ECT Algorithm ------------------------------------------------------------------------------- 1-4095 low-path-id ===============================================================================show service id "B-VPLS-10" spb fdb provides the B-VPLS FDB that has been populated by IS-IS, for the unicast and multicast entries.
[/] A:admin@PE-1# show service id "B-VPLS-10" spb fdb ============================================================================== User service FDB information ============================================================================== MAC Addr UCast Source State MCast Source State ------------------------------------------------------------------------------ 00:00:5e:00:53:02 12:10 ok 12:10 ok 00:00:5e:00:53:03 12:10 ok 12:10 ok 00:00:5e:00:53:04 12:10 ok 12:10 ok 00:00:5e:00:53:05 12:10 ok 12:10 ok 00:00:5e:00:53:06 16:10 ok 12:10 ok ------------------------------------------------------------------------------ Entries found: 5 ==============================================================================
The preceding output shows that the unicast (SPF) tree and the multicast (ST) tree differ with respect to PE-6.
The following commands help check the unicast and multicast topology for B-VPLS-10:
show service id "B-VPLS-10" spb routes provides a detailed view of the unicast and multicast routes computed by SPF. As shown in the following command, the SPB unicast and multicast routes match on PE-2 because this node is the multicast designated bridge. Unicast and multicast routes will differ on most other nodes.
[/] A:admin@PE-2# show service id "B-VPLS-10" spb routes ================================================================ MAC Route Table ================================================================ FID MAC Addr Ver. Metric NextHop If SysID ---------------------------------------------------------------- Fwd Tree: unicast ---------------------------------------------------------------- 10 00:00:5e:00:53:01 2 10 sdp:21:10 PE-1 10 00:00:5e:00:53:03 3 10 sdp:23:10 PE-3 10 00:00:5e:00:53:04 5 20 sdp:23:10 PE-3 10 00:00:5e:00:53:05 6 10 sdp:25:10 PE-5 10 00:00:5e:00:53:06 7 10 sdp:26:10 PE-6 Fwd Tree: multicast ---------------------------------------------------------------- 10 00:00:5e:00:53:01 2 10 sdp:21:10 PE-1 10 00:00:5e:00:53:03 3 10 sdp:23:10 PE-3 10 00:00:5e:00:53:04 5 20 sdp:23:10 PE-3 10 00:00:5e:00:53:05 6 10 sdp:25:10 PE-5 10 00:00:5e:00:53:06 7 10 sdp:26:10 PE-6 ---------------------------------------------------------------- No. of MAC Routes: 10 ================================================================ ================================================================ ISID Route Table ================================================================ FID ISID Ver. NextHop If SysID ---------------------------------------------------------------- 10 11 2 sdp:21:10 PE-1 sdp:23:10 PE-3 sdp:26:10 PE-6 ---------------------------------------------------------------- No. of ISID Routes: 1 ================================================================show service id "B-VPLS-10" spb mfib and show service id "B-VPLS-10" mfib show information of the MFIB entries generated in the B-VPLS as well as the outgoing interface (OIF) associated with those MFIB entries.
[/] A:admin@PE-2# show service id "B-VPLS-10" spb mfib =============================================================================== User service MFIB information =============================================================================== MAC Addr ISID Status ------------------------------------------------------------------------------- 01:1E:83:00:00:0B 11 Ok ------------------------------------------------------------------------------- Entries found: 1 ===============================================================================[/] A:admin@PE-2# show service id "B-VPLS-10" mfib =============================================================================== Multicast FIB, Service 10 =============================================================================== Source Address Group Address Port Id Svc Id Fwd Blk ------------------------------------------------------------------------------- * 01:1e:83:00:00:0b b-sdp:21:10 Local Fwd b-sdp:23:10 Local Fwd b-sdp:26:10 Local Fwd ------------------------------------------------------------------------------- Number of entries: 1 ===============================================================================
SPB multicast trees (STs) are pruned for each particular I-VPLS ISID, based on the advertisement of I-VPLS ISIDs in SPB IS-IS by each individual PE. Multicast B-VPLS traffic not belonging to any particular I-VPLS follows the default tree. The default tree is an ST for the B-VPLS which is not pruned and therefore reaches all the PE nodes in the B-VPLS. For instance, Ethernet-CFM CCM messages sent from vMEPs configured on the SPB B-VPLS will use the default tree. The default tree does not consume MFIB entries and can be checked in each node through the use of the following command:
[/]
A:admin@PE-5# tools dump service id 10 spb default-multicast-list
saps : { }
spoke-sdps : { 52:10 }
PE-5 is not part of the tree for I-VPLS-11. However, as with any SPB node part of B-VPLS-10, PE-5 is part of the default tree. Refer to Configuration of ISID policies in SPB B-VPLS to see more use cases for the default tree.
The following tools commands allow the operator to easily see the forwarding path (unicast and multicast) followed by the traffic to a remote node, with the aggregate metric from the source.
[/]
A:admin@PE-1# tools dump service id 10 spb fid 10 forwarding-path destination PE-4 forwarding-tree unicast
Hop BridgeId Metric From Src
0 PE-1 0
1 PE-2 10
2 PE-3 20
3 PE-4 30
[/]
A:admin@PE-1# tools dump service id 10 spb fid 10 forwarding-path destination PE-4 forwarding-tree multicast
Hop BridgeId Metric From Src
0 PE-1 0
1 PE-2 10
2 PE-3 20
3 PE-4 30
In large networks or networks where IP multicast, PBB, and PBB-SPB services coexist, the data plane MFIB entries is a hardware resource that should be periodically checked. The tools dump service vpls-mfib-stats command shows the total number of hardware MFIB entries (in this case, 40959 entries) and the entries being used by IP multicast or PBB (MMRP or SPB) (in this case, 16383 entries). The tools dump service vpls-pbb-mfib-stats shows the breakdown between MFIB entries populated by MMRP, SPB, or by EVPN, and the individual limits, system-wide, and per service:
[/]
A:admin@PE-2# tools dump service vpls-mfib-stats
Service Manager VPLS MFIB info at 10/10/2023 08:50:42:
Statistics last cleared at 10/10/2023 07:22:56
Statistic | Count
---------------------------------------------+-------------
HW limit SG entries | 40959
Current SG entries | 1
Limit Non PBB SG entries | 16383
Current Non PBB SG entries | 0
SG limit hit | 0
---snip---
[/]
A:admin@PE-2# tools dump service vpls-pbb-mfib-stats detail
Service Manager VPLS PBB MFIB statistics at 10/10/2023 08:50:42:
Usage per Service
ServiceId MFIB User Count
------------+--------------+-------
10 spb 1
------------+--------------+-------
Total 1
MMRP
Current Usage : 0
System Limit : 8191 Full, 40959 ESOnly
Per Service Limit : 2048 Full, 8192 ESOnly
SPB
Current Usage : 1
System Limit : 8191
Per Service Limit : 8191
Evpn
Current Usage : 0
System Limit : 40959
Per Service Limit : 8191
Control and user B-VPLS configuration
The SR OS implementation of SPB allows a single SPB IS-IS instance to control the paths and FDBs of many B-VPLS instances. This is done by using the control B-VPLS, user B-VPLS, and fate-sharing concepts.
The control B-VPLS will be SPB-enabled and configured with all the related SPB IS-IS parameters. Although the control B-VPLS might or might not have I-VPLSs or Epipes directly attached, it must be configured on all the nodes where SPB forwarding is expected to be active. SPB uses the logical instance and a forwarding ID (FID) to identify SPB locally on the node. That FID must be consistently configured on all the nodes where the B-VPLS exists. User B-VPLS are other instances of B-VPLS that are usually configured to separate the traffic for manageability reasons, QoS, or ECT different treatment.
Control and user B-VPLS example topology illustrates the control B-VPLS "control B-VPLS-20" and user B-VPLS "user B-VPLS-21" concept. In this example, there is only one user B-VPLS, but there can be several user B-VPLSs sharing fate with the same control B-VPLS. The control B-VPLS and the user B-VPLS must share the same topology and both B-VPLSs must share exactly the same interfaces. The user B-VPLS, which is linked to the control B-VPLS by its FID, follows—that is, inherits the state of—the control B-VPLS, but may use a different ECT path in case of equal metric paths, like in this example: FID 20, that is, the control B-VPLS, follows the low-path-id ECT, whereas FID 21, for example, the user B-VPLS, follows the high-path-id ECT.
The configurations of B-VPLSs 20 and 21, on PE-1 and PE-2, are as follows. The spbm-control-vpls command in user B-VPLS-21 associates FID 21 to the user B-VPLS and links the user B-VPLS to its control B-VPLS.
# on PE-1:
service {
vpls "control B-VPLS-20" {
admin-state enable
service-id 20
customer "1"
service-mtu 2000
pbb-type b-vpls
spb {
admin-state enable
isis-instance 1025
fid 20
level 1 {
ect-high-path-fid 21 { }
ect-high-path-fid 22 { }
ect-high-path-fid 23 { }
---snip---
ect-high-path-fid 63 { }
}
}
spoke-sdp 12:20 {
spb {
admin-state enable
}
}
spoke-sdp 16:20 {
spb {
admin-state enable
}
}
}
vpls "user B-VPLS-21" {
admin-state enable
service-id 21
customer "1"
service-mtu 2000
pbb-type b-vpls
spbm-control-vpls {
service-name "control B-VPLS-20"
fid 21
}
spoke-sdp 12:21 {
}
spoke-sdp 16:21 {
}
}
epipe "Epipe-211" {
admin-state enable
service-id 211
customer "1"
pbb {
tunnel {
backbone-vpls-service-name "user B-VPLS-21"
isid 211
backbone-dest-mac-name "PE-4"
}
}
sap 1/1/c3/1:211 {
}
}
# on PE-2:
configure {
service {
vpls "control B-VPLS-20" {
admin-state enable
service-id 20
customer "1"
service-mtu 2000
pbb-type b-vpls
spb {
admin-state enable
isis-instance 1025
fid 20
level 1 {
ect-high-path-fid 21 { }
ect-high-path-fid 22 { }
ect-high-path-fid 23 { }
---snip---
ect-high-path-fid 63 { }
}
}
spoke-sdp 21:20 {
spb {
admin-state enable
}
}
spoke-sdp 23:20 {
spb {
admin-state enable
}
}
spoke-sdp 25:20 {
spb {
admin-state enable
}
}
spoke-sdp 26:20 {
spb {
admin-state enable
}
}
}
vpls "user B-VPLS-21" {
admin-state enable
service-id 21
customer "1"
service-mtu 2000
pbb-type b-vpls
spbm-control-vpls {
service-name "control B-VPLS-20"
fid 21
}
spoke-sdp 21:21 {
}
spoke-sdp 23:21 {
}
spoke-sdp 25:21 {
}
spoke-sdp 26:21 {
}
}
If there is a mismatch between the topology of a user B-VPLS and its control B-VPLS, only the user B-VPLS links and nodes that are in common with the control B-VPLS will function.
User B-VPLS instances supporting only unicast services (PBB-Epipes) may share the FID with the other B-VPLS (control or user). This is a configuration shortcut that reduces the LSP advertisement size for B-VPLS services but results in the same separation for forwarding between the B-VPLS services. In the case of PBB-Epipes, only BMACs are advertised per FID, but BMACs are populated per B-VPLS in the FIB. If I-VPLS services are to be supported on a B-VPLS, that B-VPLS must have an independent FID.
Although user B-VPLS-21 does not have any SPB setting (other than the spbm-control-vpls), the spoke-SDPs use the same SDPs as the parent control B-VPLS-20. The show service id <user b-vpls> spb fate-sharing command shows the control spoke-SDP/SAPs that control the user spoke-SDP/SAPs.
[/]
A:admin@PE-1# show service id 21 spb fate-sharing
===============================================================================
User service fate-shared sap/sdp-bind information
===============================================================================
Control Control Sap/ FID User User Sap/
SvcId SdpBind SvcId SdpBind
-------------------------------------------------------------------------------
20 12:20 21 21 12:21
20 16:20 21 21 16:21
===============================================================================
SPBM access resiliency configuration
The following example shows how to configure an I-VPLS or Epipe attached to an SPB-enabled B-VPLS when access resiliency is used.
Multi-Chassis LAG (MC-LAG) is the only resiliency mechanism supported for PBB-Epipes. The MC-LAG active node will advertise the MC-LAG BMAC (or SAP BMAC) in SPB IS-IS. In case of failure, when the standby node takes over, it will advertise the MC-LAG SAP BMAC. Without SPB, the MC-LAG solution for PBB-Epipe required the use of MAC notification and periodic MAC notification. SPB provides a faster and more efficient solution without the need for any extra MAC notification mechanism. In the example described in this section, Epipe 31 uses MC-LAG access resiliency to get connected to the B-VPLS-30 on nodes PE-2 and PE-6.
As far as I-VPLS access resiliency is concerned, the same mechanisms supported for regular B-VPLS are supported for SPB-enabled B-VPLS, except for G.8032. A very important aspect of the I-VPLS resiliency is a proper MAC flush propagation when there is a failure at the I-VPLS access links.
If the SPB-enabled B-VPLS uses B-SAPs for its connectivity to the backbone, there is no MAC flush propagation (because there is no TLDP). In this case, if MC-LAG is used and there is an MC-LAG switchover, the new active chassis will keep using the same source BMAC, such as the SAP BMAC, and it will advertise it in the B-VPLS domain so that the remote FDBs can be properly updated. No MAC flush is required in this case.
When the B-VPLS uses spoke-SDPs for its backbone connectivity, the traditional LDP MAC flush propagation mechanisms and commands can be used as follows:
mac-flush tldp send-on-failure works as expected when SPB is used at the B-VPLS. When configured, a flush-all-from-me event is triggered upon a SAP or spoke-SDP failure in the I-VPLS.
pbb i-vpls-mac-flush tldp send-to-bvpls works as expected when SPB is used at the B-VPLS. Two variants are configurable: all-from-me/all-but-mine. Any I-VPLS SAP or spoke-SDP failure is propagated to the I-VPLS on the peers to flush their respective customer MAC addresses (CMACs). It works only in conjunction with mac-flush tldp send-on-failure configuration on I-VPLS. The associated ISID list is passed along with the LDP MAC flush message, which is flushed or retained according to the all-from-me/all-but-me flag.
pbb i-vpls-mac-flush tldp send-on-bvpls-failure works as expected when SPB is used at the B-VPLS. A local B-VPLS failure is propagated to the I-VPLS, which then triggers a LDP MAC flush if it has any spoke SDP on it.
pbb i-vpls-mac-flush tldp propagate-from-bvpls does not work when SPB is used at the B-VPLS (because failures within the B-VPLS are handled by SPB) and its configuration is blocked.
In the example described later in this section, I-VPLS-32 uses active/standby spoke-SDP resiliency to get connected to the B-VPLS-30 on nodes PE-3 and PE-5.
As an example of MC-LAG connectivity, the Epipe-31 configuration is shown. Just like for regular PBB-VPLS, a SAP BMAC is used as source BMAC for the Epipe traffic from PE-2 or PE-6 to PE-1. A SAP BMAC is a virtual BMAC formed from the configured source BMAC plus the MC-LAG LACP-key (if configured this way) and owned by the MC-LAG active chassis.
The following shows the configuration of MC-LAG as well as the generation of the SAP BMAC. Once it is properly configured and the MC-LAG and Epipe are up and running, SPB IS-IS will distribute the SAP BMAC throughout the B-VPLS, as it does for the system BMACs and OAM vMEP MACs. In this example, PE-2 is the MC-LAG active node, therefore the SAP BMAC for Epipe 31 is generated from PE-2.
# on PE-2:
configure {
lag "lag-1" {
admin-state enable
encap-type dot1q
mode access
lacp {
mode active
administrative-key 32768
}
port 1/1/c3/1 {
}
}
redundancy {
multi-chassis {
peer 192.0.2.6 {
admin-state enable
mc-lag {
admin-state enable
lag "lag-1" {
lacp-key 1
system-id 00:00:00:00:02:06
system-priority 65535
source-bmac-lsb use-lacp-key
}
}
}
}
# on PE-2:
configure {
service {
vpls "B-VPLS-30" {
admin-state enable
service-id 30
customer "1"
service-mtu 2000
pbb-type b-vpls
pbb {
source-bmac {
use-mclag-bmac-lsb true
}
}
spb {
admin-state enable
isis-instance 1026
fid 30
level 1 {
bridge-priority 0
}
}
spoke-sdp 21:30 {
spb {
admin-state enable
}
}
spoke-sdp 23:30 {
spb {
admin-state enable
}
}
spoke-sdp 25:30 {
spb {
admin-state enable
}
}
spoke-sdp 26:30 {
spb {
admin-state enable
}
}
}
epipe "Epipe-31" {
admin-state enable
service-id 31
customer "1"
pbb {
tunnel {
backbone-vpls-service-name "B-VPLS-30"
isid 31
backbone-dest-mac-name "PE-1"
}
}
sap lag-1:31 {
}
}
[/]
A:admin@PE-6# show service id 30 spb fdb
==============================================================================
User service FDB information
==============================================================================
MAC Addr UCast Source State MCast Source State
------------------------------------------------------------------------------
00:00:5e:00:00:01 62:30 ok 62:30 ok
00:00:5e:00:53:01 61:30 ok 62:30 ok
00:00:5e:00:53:02 62:30 ok 62:30 ok
00:00:5e:00:53:03 63:30 ok 62:30 ok
00:00:5e:00:53:05 65:30 ok 62:30 ok
------------------------------------------------------------------------------
Entries found: 5
==============================================================================
The VPLS configuration on PE-4 and PE-3 is as follows.
# on PE-4:
configure {
service {
vpls "VPLS-32" { # Ordinary VPLS, no I-VPLS
admin-state enable
service-id 32
customer "1"
endpoint "CORE" {
suppress-standby-signaling false
}
spoke-sdp 43:32 {
endpoint {
name "CORE"
precedence primary
}
stp {
admin-state disable
}
}
spoke-sdp 45:32 {
endpoint {
name "CORE"
}
stp {
admin-state disable
}
}
sap 1/1/c3/1:32 {
}
}
# on PE-3:
configure {
service {
vpls "B-VPLS-30" {
admin-state enable
service-id 30
customer "1"
service-mtu 2000
pbb-type b-vpls
spb {
admin-state enable
isis-instance 1026
fid 30
}
spoke-sdp 32:30 {
spb {
admin-state enable
}
}
spoke-sdp 35:30 {
spb {
admin-state enable
}
}
spoke-sdp 36:30 {
spb {
admin-state enable
}
}
}
vpls "I-VPLS-32" {
admin-state enable
service-id 32
customer "1"
pbb-type i-vpls
mac-flush {
tldp {
send-on-failure true
}
}
pbb {
backbone-vpls "B-VPLS-30" {
isid 32
}
i-vpls-mac-flush {
tldp {
send-to-bvpls {
all-from-me true
}
}
}
}
spoke-sdp 34:32 {
}
}
As discussed, mac-flush tldp send-on-failure true and i-vpls-mac-flush tldp send-to-bvpls all-from-me are configured in the I-VPLS. When the active spoke-SDP goes down on PE-3, a flush-all-from-me message will be propagated through the backbone and will flush the corresponding CMACs associated to I-VPLS-32 in node PE-1. MAC flush-all-from-me messages are automatically propagated in the core up to the remote I-VPLS-32 on node PE-1 (there is no need for any mac-flush propagate in the intermediate nodes).
Static BMACs and static ISIDs configuration
SR OS supports the interworking between SPB-enabled B-VPLS and non-SPB B-VPLS instances. SPB networks can be connected to non-SPB capable nodes, for example third party vendor PBB switches or 7210 SAS nodes. This is possible through the use of conditional static BMACs and static ISIDs on the nodes doing the interworking function. Conditional static BMACs and static ISIDs can be associated to non-SPB B-VPLS SAPs or spoke-SDPs.
The following example shows an SPB-enabled B-VPLS (B-VPLS-40) on nodes PE-2, PE-6, PE-3, and PE-5. Node PE-4 supports PBB, but not SPB and it is connected by a MC-LAG to nodes PE-3 and PE-5. Services I-VPLS-41 and Epipe-42 have endpoints on node PE-4. In this example, nodes PE-3 and PE-5 are acting as interworking nodes. They will be configured with the BMAC of PE-4 so that the MC-LAG active node advertises the non-SPB capable node BMAC into SPB IS-IS. The BMAC will be configured as a conditional static BMAC so that an SPB node, such as PE-3 or PE-5, will only advertise PE-4’s BMAC if its connection to PE-4 is active. Besides the conditional static BMAC, nodes PE-3 and PE-5 should advertise the I-VPLS ISIDs defined in PE-4. Epipe ISIDs are not advertised in SPB IS-IS, therefore, it is not necessary to create a static ISID for Epipe-42.
The commands to configure conditional static BMACs and static ISIDs are as follows.
[ex:/configure service vpls "B-VPLS-40" fdb static-mac]
A:admin@PE-3# mac ?
[mac-address] <unicast-mac-address-no-zero>
<unicast-mac-address-no-zero> - <xx:xx:xx:xx:xx:xx>
Static MAC address to SAP/SDP-binding or black-hole
[ex:/configure service vpls "B-VPLS-40" sap lag-1:40]
A:admin@PE-3# static-isid range ?
[range-id] <number>
<number> - <1..8191>
Range ID for static ISID
The monitor forward-status attribute identifies this to be a conditional MAC and is mandatory for static BMAC addresses. This parameter instructs SR OS to advertise the BMAC only if the corresponding SAP or spoke-SDP is in forwarding state.
[ex:/configure service vpls "B-VPLS-40" fdb static-mac mac 00:00:5e:00:53:04]
A:admin@PE-3# monitor ?
monitor <keyword>
<keyword> - (none|forward-status)
Default - none
'monitor' is: immutable
Entity to be monitored to decide whether this entry can be installed in the FDB
Warning: Modifying this element recreates
'configure service vpls "B-VPLS-40" fdb static-mac mac 00:00:5e:00:53:04' automatically for the new
value to take effect.
The configuration of the conditional static BMAC and static ISID is as follows. The values for spf-wait are the default ones.
# on PE-3:
configure {
service {
vpls "B-VPLS-40" {
admin-state enable
service-id 40
customer "1"
service-mtu 2000
pbb-type b-vpls
fdb {
static-mac {
mac 00:00:5e:00:53:04 {
sap lag-1:40
monitor forward-status
}
}
}
spb {
admin-state enable
isis-instance 1027
fid 40
}
spoke-sdp 32:40 {
spb {
admin-state enable
}
}
spoke-sdp 35:40 {
spb {
admin-state enable
}
}
spoke-sdp 36:40 {
spb {
admin-state enable
}
}
sap lag-1:40 {
}
}
# on PE-5:
configure {
service {
vpls "B-VPLS-40" {
admin-state enable
service-id 40
customer "1"
service-mtu 2000
pbb-type b-vpls
fdb {
static-mac {
mac 00:00:5e:00:53:04 {
sap lag-1:40
monitor forward-status
}
}
}
spb {
admin-state enable
isis-instance 1027
fid 40
}
spoke-sdp 52:40 {
spb {
admin-state enable
}
}
spoke-sdp 53:40 {
spb {
admin-state enable
}
}
spoke-sdp 56:40 {
spb {
admin-state enable
}
}
sap lag-1:40 {
}
}
The conditional static BMAC is added to the FDB based on the forwarding state of the SAP or SDP-binding. The following shows that the LAG is active on PE-3:
[/]
A:admin@PE-3# show lag 1
===============================================================================
Lag Data
===============================================================================
Lag-id Adm Opr Weighted Threshold Up-Count MC Act/Stdby
name
-------------------------------------------------------------------------------
1 up up No 0 1 active
lag-1
===============================================================================
On PE-3, where the forwarding state of SAP lag-1:40 is active, the conditional static BMAC is tagged in the FDB as CStatic, for Conditional Static, as follows:
[/]
A:admin@PE-3# show service id 40 fdb pbb
=======================================================================
Forwarding Database, b-Vpls Service 40
=======================================================================
MAC Source-Identifier iVplsMACs Epipes Type/Age
Transport:Tnl-Id
-----------------------------------------------------------------------
00:00:5e:00:53:02 sdp:32:40 0 0 Spb
00:00:5e:00:53:04 sap:lag-1:40 0 0 CStatic
00:00:5e:00:53:05 sdp:35:40 0 0 Spb
00:00:5e:00:53:06 sdp:36:40 0 0 Spb
=======================================================================
On PE-5, the LAG is in standby, as follows:
[/]
A:admin@PE-5# show lag 1
===============================================================================
Lag Data
===============================================================================
Lag-id Adm Opr Weighted Threshold Up-Count MC Act/Stdby
name
-------------------------------------------------------------------------------
1 up down No 0 0 standby
lag-1
===============================================================================
On PE-5, SAP lag-1:40 in B-VPLS-40 is not forwarding any traffic. The FDB for B-VPLS-40 on PE-5 does not contain any conditional static MAC addresses, even though the static MAC address is configured. In the FDB for B-VPLS-40 on PE-5, this MAC address is assigned to SDP 53:40 (type SPB), as follows:
[/]
A:admin@PE-5# show service id 40 fdb pbb
=======================================================================
Forwarding Database, b-Vpls Service 40
=======================================================================
MAC Source-Identifier iVplsMACs Epipes Type/Age
Transport:Tnl-Id
-----------------------------------------------------------------------
00:00:5e:00:53:02 sdp:52:40 0 0 Spb
00:00:5e:00:53:03 sdp:53:40 0 0 Spb
00:00:5e:00:53:04 sdp:53:40 0 0 Spb
00:00:5e:00:53:06 sdp:56:40 0 0 Spb
=======================================================================
The static-isid command identifies a set of ISIDs for I-VPLS services that are external to SPBM. These ISIDs are advertised as supported locally on this node unless altered by an ISID policy. Although the preceding example shows the use of the static ISID associated to a MC-LAG SAP, regular SAPs or spoke-SDPs are also supported. ISIDs declared in this way become part of the ISID multicast and consume MFIBs. Multiple SPBM static-ISID ranges are allowed under a SAP or spoke-SDP. ISIDs are advertised as if they were attached to the local BMAC. Only remote I-VPLS ISIDs need to be defined. In the MFIB, the backbone group MAC addresses are then associated with the active SAP or spoke-SDP.
Once the conditional static BMAC for PE-4 and the static ISID 41 (for I-VPLS-41) are configured as described, the advertised BMAC and ISID can be checked in the remote SPB nodes:
[/]
A:admin@PE-6# show service id 40 spb fdb
==============================================================================
User service FDB information
==============================================================================
MAC Addr UCast Source State MCast Source State
------------------------------------------------------------------------------
00:00:5e:00:53:02 62:40 ok 62:40 ok
00:00:5e:00:53:03 63:40 ok 62:40 ok
00:00:5e:00:53:04 63:40 ok 62:40 ok
00:00:5e:00:53:05 65:40 ok 62:40 ok
------------------------------------------------------------------------------
Entries found: 4
==============================================================================
[/]
A:admin@PE-6# show service id "B-VPLS-40" spb mfib
===============================================================================
User service MFIB information
===============================================================================
MAC Addr ISID Status
-------------------------------------------------------------------------------
01:1E:83:00:00:29 41 Ok
-------------------------------------------------------------------------------
Entries found: 1
===============================================================================
[/]
A:admin@PE-6# show service id "B-VPLS-40" mfib
===============================================================================
Multicast FIB, Service 40
===============================================================================
Source Address Group Address Port Id Svc Id Fwd
Blk
-------------------------------------------------------------------------------
* 01:1e:83:00:00:29 b-sdp:62:40 Local Fwd
-------------------------------------------------------------------------------
Number of entries: 1
===============================================================================
The group address terminates in hex 29, which corresponds to ISID 41.
The configured static ISIDs can be displayed with the following command (a range 41-100 has been added to the SAP lag-1:40 to demonstrate this output):
# on PE-5:
configure {
service {
vpls "B-VPLS-40" {
sap lag-1:40 {
static-isid {
range 1 {
start 41
end 100
}
}
}
[/]
A:admin@PE-3# show service id "B-VPLS-40" sap lag-1:40 static-isids
===================================
Static Isid Entries
===================================
Entry Range
-----------------------------------
1 41-100
===================================
Configuration of ISID policies in SPB B-VPLS
ISID policies are an optional aspect of SPBM which allow additional control of the advertisement of ISIDs and creation of MFIB entries for I-VPLS (Epipe services do not trigger ISID advertisements or the creation of MFIB entries). By default, if no ISID policies are used, SPBM automatically advertises and populates MFIB entries for I-VPLS and static ISIDs. ISID policies can be used on any SPB-enabled node with locally defined I-VPLS instances or static ISIDs. The ISID policy parameters are as follows:
[ex:/configure service vpls "B-VPLS-40" isid-policy]
A:admin@PE-3# entry 10 ?
entry
advertise-local - Advertise locally-defined I-VPLS ISIDs or static ISIDs
apply-groups - Apply a configuration group at this level
apply-groups-exclude - Exclude a configuration group at this level
range + Enter the range context
use-def-mcast - Use default multicast tree to propagate ISIS range
Where:
advertise-local defines whether the local ISIDs (I-VPLS ISIDs linked to the B-VPLS) or static ISIDs contained in the configured range are advertised in SPBM.
use-def-mcast controls whether the ISIDs contained in the range use MFIB entries (if use-def-mcast false is used) or just the default tree which does not use any MFIB entry.
The ISID policy becomes active as soon as it is defined, as opposed to other policies in SR OS, which require the policy itself to be applied within the configuration.
The typical use of ISID policies is to reduce the number of ISIDs being advertised and to save MFIB space (in deployments where MFIB space is shared with MMRP and IP multicast). The use of ISID policies is recommended for I-VPLS where most of the traffic is unicast or for I-VPLS where the ISID endpoints are present in all the backbone edge bridges (BEBs) of the SPB network. In both cases, advertising ISIDs or consuming MFIB entries for those I-VPLSs has little value because no multicast (first case) or the default tree (second case) are as efficient as using MFIB entries.
The following configuration example will use the example topology in Access resiliency example topology. In this case, the objective of the ISID policy will be to use the default tree for all the I-VPLS services with ISIDs between 41 and 100, excluding the range 80-90. The following example shows the policy configuration in the SPB nodes PE-2, PE-3, PE-5, and PE-6:
# on PE-2, PE-3, PE-5, PE-6:
configure {
service {
vpls "B-VPLS-40" {
isid-policy {
entry 10 {
range {
start 80
end 90
}
}
entry 20 {
advertise-local false
use-def-mcast true
range {
start 41
end 79
}
}
entry 30 {
advertise-local false
use-def-mcast true
range {
start 91
end 100
}
}
}
The advertise-local false option can only be configured if the use-def-mcast true option is also configured.
[ex:/configure service vpls "B-VPLS-40" isid-policy entry 40]
A:admin@PE-3# advertise-local false
[ex:/configure service vpls "B-VPLS-40" isid-policy entry 40]
A:admin@PE-3# commit
MINOR: MGMT_CORE #3001: configure service vpls "B-VPLS-40" isid-policy entry 40 advertise-local -
advertise-local or use-def-mcast option must be specified
Overlapping ISID values can be configured as long as the actions are consistent for the same ISID. Conflicting actions are shown in the CLI.
[ex:/configure service vpls "B-VPLS-40" isid-policy entry 40]
A:admin@PE-3# commit
MINOR: MGMT_CORE #5001: configure service vpls "B-VPLS-40" isid-policy entry 40 -
Range 82..95 is overlaping with entry 10 range 80..90 and advertise-local use-def-mcast conflicts
The ISID policy configured for B-VPLS-40 in all the four nodes makes the SPB network to use the default tree for ISIDs 41-79 and 91-100 and not advertise those ISIDs in SPB ISIS even if the ISID is locally defined (as in the case for ISIDs 41-100 in PE-3). As discussed in Basic SPBM configuration, the default tree path can be checked from each node by using the tools dump service id 40 spb default-multicast-list command.
Due to entry 10 in the policy, ISIDs 80-90 will be advertised by PE-3 (active MC-LAG node). However, nodes PE-2 and PE-6 will not create any MFIB entry for those ISIDs until the corresponding I-VPLS ISIDs are locally created (or configured through static-ISIDs). The following command executed on PE-2 proves that ISIDs 80-90 are indeed being advertised by PE-3:
[/]
A:admin@PE-2# show service id 40 spb database detail
===============================================================================
Rtr Base ISIS Instance 1027 Database (detail)
===============================================================================
Displaying Level 1 database
-------------------------------------------------------------------------------
---snip---
-------------------------------------------------------------------------------
LSP ID : PE-3.00-00 Level : L1
---snip---
TLVs :
---snip---
MT Capability :
TLV Len : 56
MT ID : 0
SPBM Service ID:
Sub TLV Len : 52
BMac Addr : 00:00:5e:00:53:03
Base VID : 40
ISIDs :
80 Flags:TR
81 Flags:TR
82 Flags:TR
83 Flags:TR
84 Flags:TR
85 Flags:TR
86 Flags:TR
87 Flags:TR
88 Flags:TR
89 Flags:TR
90 Flags:TR
TE IS Nbrs :
---snip---
The mfib parameter in the show service id "B-VPLS-40" sap lag-1:40 static-isids mfib command can help understand the state of the MFIB entries added (or not) by the configured static ISID. The following possible states can be shown:
If the static ISID is configured and programmed in the MFIB, the status is shown as:
ok
If the static ISID is not configured and not programmed in the MFIB, the reasons can be (order of priority):
useDefMCTree - ISID policy is applied on the service for the ISID.
sysMFibLimit - system MFIB limit has been exceeded
addPending - adding pending due to processing delays
If the static ISID is not configured, but present in the MFIB:
delPending - cleanup pending due to processing delays.
The following output shows the status of the static ISIDs:
[/]
A:admin@PE-5# show service id 40 sap lag-1:40 static-isids mfib
===================================
ISID Detail
===================================
ISID Status
-----------------------------------
41 useDefMCTree
42 useDefMCTree
---snip---
79 useDefMCTree
80 ok
81 ok
82 ok
83 ok
84 ok
85 ok
86 ok
87 ok
88 ok
89 ok
90 ok
91 useDefMCTree
---snip---
100 useDefMCTree
===================================Conclusion
SR OS supports an efficient SPBM implementation in the context of a B-VPLS, where system BMACs, vMEP OAM BMACs, and SAP BMACs are advertised in SPB IS-IS. SPBM provides a simple solution where no other control plane protocol is required in the B-VPLS to take care of the resiliency, load-balancing, and multicast optimization. The SPBM implementation in the SR OS provides scale optimization through the use of control and user B-VPLSs, allows the interworking between SPB networks and PBB networks, as well as the optimization of the MFIB resources and advertisement of ISIDs through the use of ISID policies.