PBB-VPLS
This chapter provides information about Provider Backbone Bridging (PBB) in a Multi-Protocol Label Switching (MPLS) based network.
Topics in this chapter include:
Applicability
This chapter is applicable to SR OS and was initially written for SR OS Release 7.0.R6. The MD-CLI in the current edition is based on SR OS Release 20.10.R2.
Although it can be used in an MPLS-based PBB network as described in this document, the MAC notification feature for dual-homed access is normally used in native PBB networks.
Overview
RFC 7041, Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging, describes the PBB-VPLS model supported by SR OS. This model expands the VPLS PE model to support PBB as defined by the IEEE 802.1ah.
PBB-VPLS combines the best of the PBB and VPLS technologies to deliver the most scalable multi-point Layer 2 VPN in the market. PBB-VPLS inherits all the benefits derived from MPLS (for example, sub-50ms Fast Reroute (FRR) protection, Traffic Engineering (TE), no need for Multiple Spanning Tree Protocol (MSTP) in the backbone) while greatly increasing the scalability of the network by providing MAC hiding, service multiplexing, and pseudowire aggregation.
The SR OS PBB-VPLS implementation also includes support for:
-
Multiple MAC Registration Protocol (MMRP), application within IEEE 802.1ak for flood containment in the backbone instances, as specified in Section 6 of RFC 7041.
-
Extensions to LDP signaling for PBB-VPLS, according to draft-balus-l2vpn-pbb-ldp-ext-00. These extensions avoid network black-hole issues, as described in the Section 3 of the mentioned draft.
This chapter describes how to configure and troubleshoot a PBB-VPLS network.
Knowledge of the VPLS and H-VPLS (RFC 4762, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling) architecture and functionality is assumed throughout this chapter. The most relevant concepts are briefly described in this chapter. For further information, see the relevant Nokia documentation.
Example topology including B-VPLS, I-VPLSs, and protocol stacks shows the example topology that are used throughout the rest of the chapter.
The topology consists of three core nodes (PE-1, PE-2, and PE-3) and three Multi-Tenant Unit (MTU) nodes connected to the core. A backbone VPLS instance (B-VPLS 100) will be defined in all the six nodes, whereas a few customer I-VPLS instances will be defined on the three MTU nodes.
Those I-VPLS instances will be multiplexed into the common B-VPLS, using the ISID field within the I-TAG as the demultiplexer field at the egress MTU to differentiate each specific customer.
The B-VPLS domain constitutes an H-VPLS network itself, with spoke-SDPs from the MTUs to the core PE layer. Active/standby spoke-SDPs can be used from the MTUs to the PEs (for example, in the MTU-4 and MTU-5 cases) or single non-redundant spoke-SDPs (for example, MTU-6). CE-8 is dual-connected to the service provider network through MC-LAG.
The protocol stack being used along the path between the CEs is shown in Example topology including B-VPLS, I-VPLSs, and protocol stacks.
Configuration
This section describes all the relevant PBB-VPLS configuration tasks for the setup shown in Example topology including B-VPLS, I-VPLSs, and protocol stacks. The appropriate associated IP/MPLS configuration is out of the scope of this example. In this particular example, the following protocols will be configured beforehand:
-
ISIS-TE as IGP with all the interfaces being Level-2 (OSPF-TE could have been used instead).
-
RSVP-TE as the MPLS protocol to signal the transport tunnels (LDP could have been used instead).
-
LSPs between core PEs will be fast reroute protected (facility bypass tunnels) whereas LSP tunnels between MTUs and PEs will not be protected.
-
The protection between MTU-4, MTU-5 and PE-1, PE-2 will be based on the active/standby pseudowire protection configured in the B-VPLS.
-
BGP is configured for auto-discovery (Layer 2-VPN family), because FEC 129 will be used for the pseudowires between PEs in the core.
When the IP/MPLS infrastructure is up and running, the service configuration tasks described in the following sections can be implemented.
PBB-VPLS M:1 service configuration
This section describes the process to configure PBB-VPLS services in a M:1 fashion, M being the number of customer I-VPLS services multiplexed into the same B-VPLS instance (instance 100). An alternative configuration is 1:1, where each customer I-VPLS has its own B-VPLS. MTU-4 and PE-1 will be picked to show the relevant CLI configuration commands. The bold digits separated by colons 00:xx are abbreviations for the backbone MAC addresses.
B-VPLS configuration
The first step is to configure the B-VPLS instance that will carry the PBB traffic. The following shows the B-VPLS configuration on MTU-4 and PE-1. The configuration on MTU-5 and MTU-6 resembles the configuration on MTU-4; the configuration on PE-2 and PE-3 resembles the configuration on PE-1.
The configuration for B-VPLS 100 on MTU-4 is as follows:
# on MTU-4:
configure {
service {
vpls "B-VPLS 100" {
admin-state enable
service-id 100
customer "1"
service-mtu 2000
pbb-type b-vpls
pbb {
source-bmac {
address 00:04:04:04:04:04
}
}
endpoint "core" {
suppress-standby-signaling false
}
spoke-sdp 41:100 {
endpoint {
name "core"
precedence primary
}
stp {
admin-state disable
}
}
spoke-sdp 42:100 {
endpoint {
name "core"
}
stp {
admin-state disable
}
}
}
On PE-1, B-VPLS 100 is configured as follows:
# on PE-1:
configure {
service {
pw-template "PW1" {
pw-template-id 1
provisioned-sdp use
split-horizon-group {
name "CORE"
}
}
vpls "B-VPLS 100" {
admin-state enable
service-id 100
customer "1"
service-mtu 2000
pbb-type b-vpls
pbb {
source-bmac {
address 00:01:01:01:01:01
}
}
bgp 1 {
route-target {
export "target:65000:100"
import "target:65000:100"
}
pw-template-binding "PW1" {
}
}
bgp-ad {
admin-state enable
vpls-id "65000:100"
}
spoke-sdp 14:100 {
}
spoke-sdp 15:100 {
}
}
The B-VPLS is a regular VPLS instance in terms of configuration, with the following exceptions:
-
The B-VPLS service MTU must be at least 18 bytes greater than the I-VPLS MTU of the multiplexed instances. In this example, the I-VPLS instances will have the default service MTU (1500 bytes); therefore, any MTU equal to or greater than 1518 bytes must be configured. In this particular example, a MTU of 2000 bytes is configured in the B-VPLS instance throughout the network.
-
The source B-MAC is the MAC address that will be sourced when the PBB traffic is originated from that node. A source B-MAC per B-VPLS instance can be configured (if there are more than one B-VPLS) or a common source B-MAC that will be shared by all the B-VPLS instances in the node. If no specific source B-MAC is provisioned, the system MAC address is used as the source B-MAC. When using the access multi-homing feature for native PBB, the source B-MAC must be a configured one and never the chassis MAC address. The way to configure a common B-MAC for all the B-VPLS instances on MTU-4 is as follows:
# on MTU-4: configure { service { pbb { source-bmac { address 00:04:04:04:04:04 }
The following considerations will be taken into account when configuring the B-VPLS:
-
B-VPLS SAPs:
-
Ethernet null, dot1q, and qinq encapsulations are supported
-
Default SAP (:*) types are blocked in the CLI for the B-VPLS SAP
-
-
B-VPLS SDPs:
-
For MPLS, both mesh and spoke-SDPs with split-horizon groups are supported.
-
Similar to regular pseudowires, the outgoing PBB frame on an SDP (for example, B-pseudowire) contains a BVID qtag only if the pseudowire type is Ethernet VLAN. If the pseudowire type is Ethernet, the BVID q-tag is stripped before the frame goes out.
-
BGP-AD is supported in the B-VPLS; therefore, spoke-SDPs in the B-VPLS can be signaled using FEC 128 or FEC 129. In this example, BGP-AD and FEC 129 are used. A split-horizon group (SHG) has been configured to emulate the behavior of mesh-SDPs in the core.
-
-
If a local I-VPLS instance is associated with the B-VPLS, local frames originated/terminated on local I-VPLS(s) are PBB encapsulated/de-encapsulated using the PBB Ethertype provisioned under the related port or SDP component.
By default, the PBB Ethertype is 0x88e7 (which is the standard one defined in 802.1ah for the I-TAG) but this PBB Ethertype can be changed if required due to interoperability reasons. This is the way to change it at port and/or SDP level:
[ex:configure port 1/1/3 ethernet]
A:admin@MTU-4# pbb-etype ?
pbb-etype <number>
<number> - <0x600..0xffff>
Default - 35047
Ethertype for PBB encapsulation on the Ethernet port
[ex:configure service sdp 41]
A:admin@MTU-4# pbb-etype ?
pbb-etype <number>
<number> - <0x600..0xffff>
Default - 0x88E7
Ethertype used in frames sent out on this SDP when VC type is 'vlan' for
Provider Backbone Bridging frames as 0xXXYY with range 0x0600-0xFFFF.
The following commands are useful to check the actual PBB Ethertype:
[]
A:admin@MTU-4# show port 1/1/3 | match PBB
PBB Ethertype : 0x88e7
[]
A:admin@MTU-4# show service sdp 41 detail | match PBB
Bw BookingFactor : 100 PBB Etype : 0x88e7
I-VPLS configuration
When the common B-VPLS is configured, the next step is to provision the customer I-VPLS instances. The following shows the relevant configuration on MTU-4 for the two I-VPLS instances represented in Example topology with port numbers and IP addresses. The I-VPLS instances are configured on the MTU devices, whereas the core PEs are customer-unaware nodes.
# on MTU-4:
configure {
service {
vpls "I-VPLS 1" {
admin-state enable
service-id 1
customer "1"
pbb-type i-vpls
pbb {
backbone-vpls "B-VPLS 100" {
isid 1
}
}
sap 1/1/1:7 {
}
}
vpls "I-VPLS 2" {
admin-state enable
service-id 2
customer "1"
pbb-type i-vpls
pbb {
backbone-vpls "B-VPLS 100" {
isid 2
}
}
sap lag-1 {
}
}
The I-VPLS instance has to be linked to its corresponding transport B-VPLS instance. That link is specified by the backbone-vpls <b-vpls> isid <isid> command. The ISID is mandatory when configuring the backbone VPLS.
The following considerations will be taken into account when configuring the I-VPLS:
-
I-VPLS SAPs:
-
SAPs can be defined on ports with any Ethernet encapsulation type (null, dot1q, and qinq)
-
The I-VPLS SAPs can coexist on the same port with SAPs for other business services, for example, VLL and VPLS SAPs.
-
-
I-VPLS SDPs:
-
GRE and MPLS SDPs are supported.
-
No mesh-SDPs are supported, only spoke-SDP. Mesh-SDPs can be emulated by using SHGs.
-
Existing SAP processing rules still apply for the I-VPLS case; the SAP encapsulation definition on Ethernet ingress ports defines which VLAN tags are used to determine the service that the packet belongs to:
-
Null encapsulation defined on ingress — Any VLAN tags are ignored and the packet goes to a default service for the SAP.
-
Dot1q encapsulation defined on ingress — only first VLAN tag is considered.
-
QinQ encapsulation defined on ingress — both VLAN tags are considered; wildcard for the inner VLAN tag is supported.
-
For dot1q/qinq encapsulations, traffic encapsulated with VLAN tags for which there is no definition is discarded.
-
Any VLAN tag used for service selection on the I-SAP is stripped before the PBB encapsulation is added. Appropriate VLAN tags are added at the remote PBB PE when sending the packet out on the egress SAP.
MMRP for flooding optimization
When the M:1 model is used (as in this example), any I-VPLS broadcast, unknown unicast, or multicast (BUM) frame is flooded throughout the B-VPLS domain regardless of the nodes where the originating I-VPLS is defined. In other words, in our example in Example topology including B-VPLS, I-VPLSs, and protocol stacks, any BUM frame coming from CE-7 would be flooded in the B domain and would reach PE-2 and MTU-5, even though that traffic only needs to go to PE-3 and MTU-6. To build customer-based flooding trees and optimize the flooding, Multiple MAC Registration Protocol (MMRP) must be configured on the B-VPLS.
MMRP can be enabled with its default settings just by executing the following command on all nodes:
# on all nodes:
configure {
service {
vpls "B-VPLS 100" {
mrp {
admin-state enable
There are specific B-VPLS MRP settings that can be modified. These are the default values:
[ex:configure service vpls "B-VPLS 100" mrp]
A:admin@MTU-4# info detail
admin-state enable
mmrp {
admin-state enable
end-station-only false
## flood-time
attribute-table {
high-wmark 95
low-wmark 90
size 2048
}
}
These attributes can be changed to control the number of MMRP attributes per B-VPLS and optimize the convergence time in case of failures in the B-VPLS:
-
Controlling the number of attributes per B-VPLS
The MMRP exchanges create one entry per attribute (group B-MAC) in the B-VPLS where MMRP protocol is running. PBB uses a group B-MAC address—built using a specific OUI (00:1e:83) with the multicast bit set, and the ISID value for the last 24 bits—as a destination MAC address for flooding any BUM frame into the B-domain.
When the first registration is received for an attribute, an MFIB entry is created for it. The attribute-table size allows the user to control the number of MMRP attributes (group B-MACs) created on a per B-VPLS basis, between 1 and 2048. Based on the configured size, high and low watermarks can be set (in percentage) so that alarms can be triggered upon exceeding the watermarks. This ensures that no B-VPLS will take up all the resources from the total pool. The maximum number of attributes per B-VPLS is 2048 and 4000 can be configured globally on the system.
-
Optimizing the convergence time
Assuming that MMRP is used in a certain B-VPLS, under failure conditions, the time it takes for the B-VPLS forwarding to resume may depend on the data plane and control plane convergence plus the time it takes for MMRP exchanges to stabilize the flooding trees on a per ISID basis. In order to minimize the convergence time, the PBB SR OS implementation offers the selection of a mode where B-VPLS forwarding reverts for a short time to flooding so that MMRP has enough time to converge. This mode can be selected through configuration using the flood-time <value> command where value represents the amount of time in seconds (between 3 and 600) that flooding will be enabled. If this behavior is selected, the forwarding plane starts with B-VPLS flooding for a configurable time period, then it reverts back to the MFIB entries installed by MMRP. The following B-VPLS events initiate the switch from per I-VPLS (MMRP) MFIB entries to B-VPLS flooding:
-
Reception or local triggering of a Spanning Tree Topology Change Notification (TCN)
-
B-SAP failure
-
Failure of a B-SDP binding
-
Pseudowire activation in a primary/standby H-VPLS resiliency solution
-
SF/CPM switchover due to STP reconvergence
-
The IEEE 802.1ak standard, which defines MRP, requires the implementation of different state machines with associated timers that can be tuned. A full MRP participant maintains the following state machines:
-
Registrar state machine
-
Applicant state machine
-
LeaveAll state machine
-
PeriodicTransmission state machine
The two first state machines are maintained for each attribute in which the participant is interested, whereas the two latter are global to all the attributes.
The job of the registrar function is to record declarations of the attribute made by other participants on the LAN. A registrar does not send any protocol messages, because the applicant looks after the interests of all would-be participants.
The job of the applicant is twofold: first, to ensure that this participant’s declaration is correctly registered by other participants’ registrars, and next, to prompt other participants to register again after one withdraws a declaration.
The associated timers can be tuned on a per SAP/SDP basis:
[ex:configure service vpls "B-VPLS 100" spoke-sdp 41:100]
A:admin@MTU-4# mrp ?
mrp
apply-groups - Apply a configuration group at this level
apply-groups-exclude - Exclude a configuration group at this level
join-time - Set the maximum rate for attribute join messages to be sent
on the SDP.
leave-all-time - Set the frequency where all attribute declarations on the
SDP are refreshed.
leave-time - Set the time an attribute is held in leave state before
registration is removed.
periodic-time - Set the freqeuency of retransmission of attribute
declarations.
periodic-timer - Enable/Disable retransmission of attribute declarations.
policy - Specify they MRP policy to control which Group BMAC
attributes will advertise on the egress SDP Bind.
[ex:configure service vpls "B-VPLS 100" spoke-sdp 41:100 mrp]
A:admin@MTU-4# info detail
## apply-groups
## apply-groups-exclude
join-time 2
leave-time 30
leave-all-time 100
periodic-time 10
periodic-timer false
## policy
A brief description of the MRP SAP/SDP attributes follows:
-
Join-time — This command controls the interval between transmit opportunities that are applied to the applicant state machine. An instance of this join period timer is required on a per-port, per-MRP participant basis. For more information, see IEEE 802.1ak-2007 section 10.7.4.1.
-
Leave-time — This command controls the period of time that the registrar state machine will wait in the leave state before transitioning to the MT state when it is removed. An instance of the timer is required for each state machine that is in the leave state. The leave period timer is set to the value leave-time when it is started. A registration is normally in ‟in” state where there is an MFIB entry and traffic being forwarded. When a ‟leave all” is performed (periodically around every 10-15 seconds per SAP/SDP binding – see leave-all-time below), a node sends a message to its peer indicating a leave all is occurring and puts all of its registrations in leave state. The peer refreshes its registrations based on the leave all PDU it receives and sends a PDU back to the originating node with the state of all its declarations. See IEEE 802.1ak-2007 section 10.7.4.2.
-
Leave-all-time — This command controls the frequency with which the leaveall state machine generates leaveall PDUs. The timer is required on a per-port, per-MRP participant basis. The leaveall period timer is set to a random value, T, in the range leavealltime<T<1.5*leave-all-time when it is started. See IEEE 802.1ak-2007, section 10.7.4.3.
-
Periodic-time — This command controls the frequency the periodic transmission state machine generates periodic events if the periodic transmission timer is enabled. The timer is required on a per-port basis. The periodic transmission timer is set to one second when it is started.
-
Periodic-timer — This command enables or disables the periodic transmission timer.
The following command shows the MRP configuration and statistics on a per SAP/SDP basis within the B-VPLS:
[]
A:admin@MTU-4# show service id 100 all | match MRP post-lines 10
Sdp Id 41:100 MRP Information
-------------------------------------------------------------------------------
Join Time : 0.2 secs Leave Time : 3.0 secs
Leave All Time : 10.0 secs Periodic Time : 1.0 secs
Periodic Enabled : false
Mrp Policy : N/A
Rx Pdus : 234 Tx Pdus : 252
Dropped Pdus : 0
Rx New Event : 0 Rx Join-In Event : 246
Rx In Event : 0 Rx Join Empty Evt : 217
Rx Empty Event : 0 Rx Leave Event : 0
SDP MMRP Information
-------------------------------------------------------------------------------
MAC Address Registered Declared
-------------------------------------------------------------------------------
01:1e:83:00:00:01 Yes Yes
01:1e:83:00:00:02 Yes Yes
-------------------------------------------------------------------------------
Number of MACs=2 Registered=2 Declared=2
-------------------------------------------------------------------------------
Sdp Id 42:100 MRP Information
-------------------------------------------------------------------------------
Join Time : 0.2 secs Leave Time : 3.0 secs
Leave All Time : 10.0 secs Periodic Time : 1.0 secs
Periodic Enabled : false
Mrp Policy : N/A
Rx Pdus : 0 Tx Pdus : 0
Dropped Pdus : 0
Rx New Event : 0 Rx Join-In Event : 0
Rx In Event : 0 Rx Join Empty Evt : 0
Rx Empty Event : 0 Rx Leave Event : 0
SDP MMRP Information
-------------------------------------------------------------------------------
MAC Address Registered Declared
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Number of MACs=0 Registered=0 Declared=0
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Number of SDPs : 2
-------------------------------------------------------------------------------
* indicates that the corresponding row element may have been truncated.
Service MRP Information
===============================================================================
Admin State : enabled
-------------------------------------------------------------------------------
MMRP
-------------------------------------------------------------------------------
Admin Status : enabled Oper Status : up
Register Attr Cnt : 2 Declared Attr Cnt: 2
End-station-only : disabled
Max Attributes : 2048 Attribute Count : 2
Hi Watermark : 95% Low Watermark : 90%
Failed Registers : 0 Flood Time : Off
-------------------------------------------------------------------------------
MVRP
-------------------------------------------------------------------------------
MRP SAP Table
=============================================================================
SAP Join Leave Leave All Periodic
Time(sec) Time(sec) Time(sec) Time(sec)
-----------------------------------------------------------------------------
=============================================================================
=============================================================================
MRP SDP-BIND Table
=============================================================================
SDP-BIND Join Leave Leave All Periodic
Time(sec) Time(sec) Time(sec) Time(sec)
-----------------------------------------------------------------------------
41:100 0.2 3.0 10.0 1.0
42:100 0.2 3.0 10.0 1.0
=============================================================================
===============================================================================
-------------------------------------------------------------------------------
The following command is useful to check the MRP configuration and status.
[]
A:admin@MTU-4# show service id 100 mrp
===============================================================================
Service MRP Information
===============================================================================
Admin State : enabled
-------------------------------------------------------------------------------
MMRP
-------------------------------------------------------------------------------
Admin Status : enabled Oper Status : up
Register Attr Cnt : 2 Declared Attr Cnt: 2
End-station-only : disabled
Max Attributes : 2048 Attribute Count : 2
Hi Watermark : 95% Low Watermark : 90%
Failed Registers : 0 Flood Time : Off
-------------------------------------------------------------------------------
MVRP
-------------------------------------------------------------------------------
Admin Status : disabled Oper Status : down
Max Attr : 4095 Failed Register : 0
Register Attr Count : 0 Declared Attr : 0
Hi Watermark : 95% Low Watermark : 90%
Hold Time : disabled Attr Count : 0
-------------------------------------------------------------------------------
=============================================================================
MRP SAP Table
=============================================================================
SAP Join Leave Leave All Periodic
Time(sec) Time(sec) Time(sec) Time(sec)
-----------------------------------------------------------------------------
=============================================================================
=============================================================================
MRP SDP-BIND Table
=============================================================================
SDP-BIND Join Leave Leave All Periodic
Time(sec) Time(sec) Time(sec) Time(sec)
-----------------------------------------------------------------------------
41:100 0.2 3.0 10.0 1.0
42:100 0.2 3.0 10.0 1.0
=============================================================================
===============================================================================
In the example throughout the chapter, as soon as MMRP is enabled, an optimized flooding tree will be built for ISID 1, because the I-VPLS 1 is only defined in MTU-4 and MTU-6, but not in MTU-5. A good way to track the flooding tree for a particular ISID is the following command:
[]
A:admin@MTU-4# show service id 100 mmrp mac
-------------------------------------------------------------------------------
SAP/SDP MAC Address Registered Declared
-------------------------------------------------------------------------------
sdp:41:100 01:1e:83:00:00:01 Yes Yes
sdp:41:100 01:1e:83:00:00:02 Yes Yes
-------------------------------------------------------------------------------
Number of Entries=2 SAPs=0 SDPs=2
-------------------------------------------------------------------------------
[]
A:admin@MTU-5# show service id 100 mmrp mac
-------------------------------------------------------------------------------
SAP/SDP MAC Address Registered Declared
-------------------------------------------------------------------------------
sdp:52:100 01:1e:83:00:00:01 Yes No
sdp:52:100 01:1e:83:00:00:02 Yes No
-------------------------------------------------------------------------------
Number of Entries=2 SAPs=0 SDPs=2
-------------------------------------------------------------------------------
The group B-MAC ending in 01 corresponds to the I-VPLS 1 whereas the one ending in 02 to the I-VPLS 2. MMRP PDUs for the two attributes are sent throughout the loop-tree topology (not over STP blocked ports or standby spoke-SDPs and observing the split-horizon rules). The two attributes are registered on every B-VPLS virtual port; however, the tree is only built on those ports where the attribute is also declared, and not only registered. For instance, the spoke-SDP 52:100 in MTU-5 will not be part of the ISID 1 or ISID 2 flooding trees. Neither attribute is declared because I-VPLS 1 does not exist on MTU-5 and I-VPLS 2 is operationally down on MTU-5 (MC-LAG SAP is in standby state, so the I-VPLS is down).
As soon as a group B-MAC attribute is registered on a particular port, an MFIB entry is added for that B-MAC on that port, regardless of the declaration state for that attribute on the port. For instance, neither B-MAC is declared on MTU-5, however, the two MFIB entries are created as soon as the attributes are registered:
[]
A:admin@MTU-5# show service id 100 mfib
===============================================================================
Multicast FIB, Service 100
===============================================================================
Source Address Group Address Port Id Svc Id Fwd
Blk
-------------------------------------------------------------------------------
* 01:1e:83:00:00:01 b-sdp:52:100 Local Fwd
* 01:1e:83:00:00:02 b-sdp:52:100 Local Fwd
-------------------------------------------------------------------------------
Number of entries: 2
===============================================================================
MAC flush: avoiding black-holes
Both the I-VPLS and B-VPLS components inherit the MAC flush capabilities of a regular VPLS clearing the related C-MAC and respectively B-MAC FIBs. All types of MAC flush—all-but-mine and all-from-me—are supported together with the related CLI. In addition to these features, some extensions have been added so that MAC flush can be triggered on the B-VPLS based on some events happening on the I-VPLS. The following diagram shows a potential scenario where black-holes can occur if the correct configuration is not added.
Under normal conditions, the I-VPLS 2 FIB on MTU-6 shows that CE-8 MAC address is learned through B-MAC 00:04 of MTU-4:
[]
A:admin@MTU-6# show service id 2 fdb pbb
==============================================================================
Forwarding Database, i-Vpls Service 2
==============================================================================
MAC Source-Identifier B-Svc b-Vpls MAC Type/Age
Transport:Tnl-Id
------------------------------------------------------------------------------
00:08:00:00:00:00 b-sdp:63:100 100 00:04:04:04:04:04 L/60
00:10:00:00:00:00 sap:1/1/1:10 100 N/A L/60
==============================================================================
When a failure happens in the CE-8 MC-LAG active link, the link to MTU-5 takes over. However, the FIB on MTU-6 still points at the BMAC of MTU-4 and that will still be the B-MAC used in the PBB encapsulation. Therefore, a black-hole occurs until either bidirectional traffic is sent or the FIB aging timer expires.
The configuration in the I-VPLS can be modified to trigger a MAC flush in the B-VPLS with the following command:
[ex:configure service vpls "I-VPLS 2" pbb i-vpls-mac-flush tldp]
A:admin@MTU-4# send-to-bvpls ?
send-to-bvpls
all-but-mine - Generate LDP MAC withdraw message to b-VPLS
all-from-me - Generate LDP MAC withdraw all from me message to b-VPLS
The following command is executed on all MTUs to solve the black-hole:
# on MTU-4, MTU-5, MTU-6:
configure {
service {
vpls "I-VPLS 2" {
pbb {
i-vpls-mac-flush {
tldp {
send-to-bvpls {
all-from-me true
}
}
}
}
By configuring send-to-bvpls all-from-me true on I-VPLS 2, a failure on the MC-LAG active link on I-VPLS 2 will trigger an LDP MAC flush-all-from-me into the B-VPLS that will flush the FIB in MTU-6 for I-VPLS 2, avoiding the black-hole. A MC-LAG failure is emulated by disabling the LAG on MTU-4, as follows:
# on MTU-4:
configure {
lag 1 {
admin-state disable
}
MTU-4 sends the following LDP MAC flush for all MAC addresses learned from MTU-4:
1 2021/01/12 17:02:25.211 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Send Address Withdraw packet (msgId 263) to 192.0.2.1:0
Protocol version = 1
MAC Flush (All MACs learned from me)
Service FEC PWE3: ENET(5)/100 Group ID = 0 cBit = 0
Number of PBB-BMACs = 1
BMAC 1 = 00:04:04:04:04:04
Number of PBB-ISIDs = 1
ISID 1 = 2
Number of Path Vectors : 1
Path Vector( 1) = 192.0.2.4
"
On MTU-6:
1 2021/01/12 17:02:25.227 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Recv Address Withdraw packet (msgId 206) from 192.0.2.3:0
Protocol version = 1
MAC Flush (All MACs learned from me)
Service FEC PWE3: ENET(5)/100 Group ID = 0 cBit = 0
Number of PBB-BMACs = 1
BMAC 1 = 00:04:04:04:04:04
Number of PBB-ISIDs = 1
ISID 1 = 2
Number of Path Vectors : 3
Path Vector( 1) = 192.0.2.4
Path Vector( 2) = 192.0.2.1
Path Vector( 3) = 192.0.2.3
Immediately after receiving the MAC flush, the CE-8 MAC is flushed. The CE-8 MAC is learned again, but this time linked to the B-MAC 00:05, which is the B-MAC of MTU-5:
[]
A:admin@MTU-6# show service id 2 fdb pbb
==============================================================================
Forwarding Database, i-Vpls Service 2
==============================================================================
MAC Source-Identifier B-Svc b-Vpls MAC Type/Age
Transport:Tnl-Id
------------------------------------------------------------------------------
00:08:00:00:00:00 b-sdp:63:100 100 00:05:05:05:05:05 L/0
00:10:00:00:00:00 sap:1/1/1:10 100 N/A L/120
==============================================================================
The following I-VPLS events are propagated into the B-VPLS depending on the all-but-mine or all-from-me keywords used in the configuration:
If the all-but-mine keyword is configured (positive flush), the following events in the I-VPLS trigger a MAC flush into the B-VPLS:
-
TCN event in one or more of the related I-VPLS/M-VPLS.
-
Pseudowire/SDP binding activation with active/standby pseudowire (standby to active or down to up).
-
Reception of an LDP MAC withdraw flush-all-but-mine in the related I-VPLS.
If the all-from-me keyword is configured (negative flush) the following events in the I-VPLS trigger a MAC flush into the B-VPLS:
-
MC-LAG active link failure (in our example).
-
Failure of a local SAP – requires mac-flush>tldp>send-on-failure true to be enabled in I-VPLS.
-
Failure of a local pseudowire/SDP binding – requires mac-flush>tldp>send-on-failure true to be enabled in I-VPLS.
-
Reception of an LDP MAC withdraws flush-all-from-me in the related I-VPLS.
In addition to this and regardless of what type, MAC flush has been optimized to avoid flushing in the core PEs, flushing only the C-MACs mapped to a specific B-MAC (belonging to a specific ISID FIB) and the ability to indicate to core PEs which messages should always be forwarded endpoint-to-endpoint toward all PBB PEs regardless of the propagate-mac-flush setting in B-VPLS. All of this is implemented without the need of any additional CLI commands and it is part of draft-balus-l2vpn-pbb-ldp-ext-00.
Another extension supported to avoid black-holes within this mix of I- and B-VPLS environments is the block-on-mesh-failure feature in PBB. When the VPLS mesh exists only in I-VPLS or in B-VPLS, and the block-on-mesh-failure feature is enabled, the regular VPLS behavior will apply (when all the mesh-SDPs go down an LDP notification with pseudowire status bits = 0x01—Pseudo Wire Not Forwarding—is sent over the spoke-SDPs). When the active/standby pseudowire resiliency is implemented in I-VPLS such that the PBB PE performs the role of a PE-rs, the B-VPLS core replaces the pseudowire (SDP binding) mesh. The block-on-mesh notification (LDP notification indicating pseudowire not forwarding) will be sent to the MTUs only when the related B-VPLS is operationally down. The B-VPLS core is operationally down only when all of its SAPs and SDPs are down.
The final feature that can be enabled in an I-VPLS with CLI is the send-on-bvpls-failure feature, as follows:
# on MTU-4, MTU-5, MTU-6:
configure {
service {
vpls "I-VPLS 2" {
pbb {
i-vpls-mac-flush {
tldp {
send-on-bvpls-failure true
}
}
This feature is required to avoid black-holes when there is a full mesh of pseudowires in the I-VPLS domain and the B-VPLS instance can go operationally down. Send flush on B-VPLS failure example shows a typical scenario where this feature is needed (normally when PBB-VPLS and multi-chassis end point are combined together).
Access dual-homing and MAC notification
Although this section is focused on PBB in a MPLS based network, the Nokia PBB implementation also allows the operator to use a native Ethernet infrastructure in the PBB core. Native Ethernet tunneling can be emulated using Ethernet SAPs to interconnect the related B-VPLS instances. In those cases, there is no LDP signaling available; therefore, there is no MAC flush sent when the active link in a multi-homed access device fails.
The SR OS supports a mechanism to avoid potential black-holes in native Ethernet PBB networks. In addition to the source B-MAC associated with each B-VPLS, an additional B-MAC is associated with each MC-LAG supporting Multi-homed I-VPLS SAPs. The nodes that are in a multi-homed MC-LAG configuration share a common B-MAC on the related MC-LAG interfaces. When the MAC notification is enabled, an Ethernet CFM notification message is sent from the node holding the active link. That message will be flooded in the B-VPLS domain using the MC-LAG SAP B-MAC as the source MAC address. The remote nodes will learn the customer MAC addresses behind the MC-LAG and will link them to this new SAP B-MAC. MC-LAG will keep track of the active link for each particular LAG associated with a SAP B-MAC. Should MC-LAG detect any new active link in a node, a new CFM notification message will be flooded from the new active node.
The following restrictions and considerations must be taken into account:
-
Only MC-LAG is supported as dual-home mechanism.
-
This mechanism is supported for native PBB and/or MPLS-based PBB-VPLS. Although it is mostly beneficial when native PBB is used in the core, it can also help to optimize the re-learning process in a MPLS-based core in case of MC-LAG failures, in addition to the existing LDP MAC flush procedures.
The example of this configuration shows the setup being used in this configuration example. MAC-notification will be configured in MTU-4 and MTU-5 for the dual-homed CE-8.
The first step is to configure the SAP B-MAC that will be used for the MAC notification messages. The source-bmac-lsb (source backbone MAC least significant bits) command has been added to the MC-LAG branch so that the operator can decide the two last octets to be used in the SAP B-MAC. Those two last octets can be derived from the LACP key (if the use-lacp-key statement is used) or can be specifically defined.
[ex:configure redundancy multi-chassis peer 192.0.2.5 mc-lag]
A:admin@MTU-4# lag 1 ?
lag
Immutable fields - lacp-key, system-id, system-priority
apply-groups - Apply a configuration group at this level
apply-groups-exclude - Exclude a configuration group at this level
lacp-key - Key based on the remote MC-LAG
remote-lag - Lag ID of the remote MC-LAG
source-bmac-lsb - MAC address value to apply to all ingress traffic
system-id - ID based on the remote MC-LAG
system-priority - Priority based on the remote MC-LAG
There must be a different SAP B-MAC per MC-LAG. The use of the LACP key as a default for two least significant octets makes the operations simpler. In this example, the last two octets of the SAP BMAC will come from the lacp-key. The configuration on MTU-4 is as follows:
# on MTU-4:
configure {
redundancy {
multi-chassis {
peer 192.0.2.5 {
admin-state enable
mc-lag {
admin-state enable
lag 1 {
lacp-key 15
system-id 00:00:00:00:00:01
system-priority 65535
source-bmac-lsb use-lacp-key
}
}
}
}
Therefore, the SAP B-MAC will be formed in the following way:
MAC notification in B-VPLS 100 is enabled on all MTUs, as follows:
# on MTU-4, MTU-5, MTU-6:
configure {
service {
vpls "B-VPLS 100"
pbb {
mac-notification {
admin-state enable
}
The mac-notification command activates the described mechanism and has the following parameters:
[ex:configure service vpls "B-VPLS 100" pbb]
A:admin@MTU-4# mac-notification ?
mac-notification
admin-state - Administrative state of MAC notification
count - MAC notification messages count
interval - Interval for MAC notification messages
renotify - Re-notify interval for MAC-notification messages
Where:
-
interval <value> controls how often the subsequent MAC notification messages are sent. Default = 100 ms. Required values: 100 ms – 10 sec, in increments of 100 ms.
-
count <value> controls how often the MAC notification messages are sent. Default: 3. Range: 1–10.
The ‟count” and ‟interval” parameters can also be configured at the service context. The settings configured at the B-VPLS service context take precedence though.
[ex:configure service pbb]
A:admin@MTU-4# mac-notification ?
mac-notification
apply-groups - Apply a configuration group at this level
apply-groups-exclude - Exclude a configuration group at this level
count - MAC notification messages count
interval - Interval for MAC-notification messages
Finally, the B-VPLS is instructed to use the SAP B-MAC. The use-mclag-bmac-lsb statement enables the use of the source B-MAC allocated to the multi-homed SAPs (assigned to the MC-LAG) in the related I-VPLS service (could be Epipe service as well). The command will fail if the value of the source B-MAC assigned to the B-VPLS is the hardware (chassis) B-MAC. In other words, the source B-MAC must be a configured one. The use-mclag-bmac-lsb statement is by default false.
# on MTU-4:
configure {
service {
vpls "B-VPLS 100"
pbb {
source-bmac {
address 00:aa:aa:aa:aa:04
use-mclag-bmac-lsb true
}
# on MTU-5:
configure {
service {
vpls "B-VPLS 100"
pbb {
source-bmac {
address 00:aa:aa:aa:aa:05
use-mclag-bmac-lsb true
}
[]
A:admin@MTU-6# show service id 2 fdb pbb
==============================================================================
Forwarding Database, i-Vpls Service 2
==============================================================================
MAC Source-Identifier B-Svc b-Vpls MAC Type/Age
Transport:Tnl-Id
------------------------------------------------------------------------------
00:08:00:00:00:00 b-sdp:63:100 100 00:aa:aa:aa:00:0f L/0
00:10:00:00:00:00 sap:1/1/1:10 100 N/A L/0
==============================================================================
As soon as MAC notification is enabled, an Ethernet CFM notification message is sent from MTU-4, which is the node where the active MC-LAG link resides. The CFM message will have the source MAC address ‟00:aa:aa:aa:00:0f” (4 first bytes of the configured source BMAC + 2 bytes from the configured source-bmac-lsb, which is 15 in hex) and will be flooded throughout the B-VPLS domain. Should the link between CE-8 and MTU-4 fail, the MC-LAG protocol will activate the redundant link and MTU-5 will immediately issue a CFM message with the shared sourced SAP B-MAC that will be flooded in the B-VPLS domain.
PBB and IGMP snooping
IGMP snooping can be enabled on I-VPLS SAPs and SDPs (it cannot be enabled on B-VPLS). SR OS can keep track of IGMP joins received over individual B-SDPs or B-SAPs, and it starts flooding the multicast group (and only the multicast group) to all B-components (using the group B-MAC for I-SID) as soon as the first IGMP join for that multicast group is received in one of the B-SAP/SDP components.
The first IGMP join message received over the local B-VPLS will add all the B-VPLS SAP/SDP components into the related multicast table associated with the I-VPLS context. When the querier is connected to a remote I-VPLS instance, over the B-VPLS infrastructure, its location is identified by the B-VPLS SDP/SAP on which the query was received and also by the source B-MAC address used in the PBB header for the query message, the B-MAC associated with the B-VPLS instance on the remote PBB PE.
The following configuration on MTU-4 enables IGMP snooping in I-VPLS 1 and adds some static groups on a SAP. The location of the querier is configured by adding the B-MAC where the querier is connected to (in this example, MTU-6) and adding the two B-VPLS spoke-SDPs as mrouter ports (B-VPLS mrouter ports are added in the I-VPLS backbone-vpls context).
The mac command translates MAC address into strings so that the names can be used instead of typing the entire MAC address every time we need to.
# on MTU-4:
configure {
service {
pbb {
source-bmac {
address 00:04:04:04:04:04
}
mac "MTU-4" {
address 00:04:04:04:04:04
}
mac "MTU-5" {
address 00:05:05:05:05:05
}
mac "MTU-6" {
address 00:06:06:06:06:06
}
}
vpls "I-VPLS 1" {
admin-state enable
service-id 1
customer "1"
pbb-type i-vpls
pbb {
backbone-vpls "B-VPLS 100" {
isid 1
igmp-snooping {
mrouter-destination "MTU-6" { }
}
spoke-sdp 41:100 {
igmp-snooping
mrouter-port true
}
}
spoke-sdp 42:100 {
igmp-snooping
mrouter-port true
}
}
}
}
igmp-snooping
admin-state enable
}
sap 1/1/1:7 {
igmp-snooping {
static {
group 228.0.0.1 {
starg
}
group 228.0.0.2 {
starg
}
group 239.0.0.1 {
source 172.16.99.99 { }
}
}
}
}
As in regular VPLS instances, mrouter ports are added to all the multicast groups:
[]
A:admin@MTU-4# show service id 1 mfib
===============================================================================
Multicast FIB, Service 1
===============================================================================
Source Address Group Address Port Id Svc Id Fwd
Blk
-------------------------------------------------------------------------------
* * b-sdp:41:100 100 Fwd
b-sdp:42:100 100 Fwd
* 228.0.0.1 sap:1/1/1:7 Local Fwd
b-sdp:41:100 100 Fwd
b-sdp:42:100 100 Fwd
* 228.0.0.2 sap:1/1/1:7 Local Fwd
b-sdp:41:100 100 Fwd
b-sdp:42:100 100 Fwd
172.16.99.99 239.0.0.1 sap:1/1/1:7 Local Fwd
b-sdp:41:100 100 Fwd
b-sdp:42:100 100 Fwd
-------------------------------------------------------------------------------
Number of entries: 4
===============================================================================
When the show service id x mfib command is issued in an I-VPLS as in the preceding output, the IGMP (S,G) and (*,G) entries for the I and B components are shown if IGMP snooping is enabled. However, when the same command is launched in a B-VPLS as in the following output, the group B-MAC entries are shown.
[]
A:admin@MTU-4# show service id 100 mfib
===============================================================================
Multicast FIB, Service 100
===============================================================================
Source Address Group Address Port Id Svc Id Fwd
Blk
-------------------------------------------------------------------------------
* 01:1e:83:00:00:01 b-sdp:41:100 Local Fwd
* 01:1e:83:00:00:02 b-sdp:41:100 Local Fwd
-------------------------------------------------------------------------------
Number of entries: 2
===============================================================================
MMRP policies and ISID-based filtering for PBB inter-domain expansion
As described in the MMRP for flooding optimization section, MMRP is used in the backbone VPLS instances to build per I-VPLS flooding trees. Each I-VPLS has an associated group B-MAC in the B-VPLS, which is derived from the ISID, and is advertised by MMRP throughout the whole B-VPLS context, regardless of whether a specific I-VPLS is present in one or all the B-VPLS PEs.
In an inter-domain environment, the same B-VPLS can be defined in different domains and therefore MMRP will advertise all the group B-MACs in every domain. The group B-MACs are consuming resources in all the PEs no matter if a particular ISID—and therefore its group B-MAC—is required in one of the domains or not. When MMRP is enabled in a particular PE, data plane and control plane resources are consumed and they must be taken into consideration when designing PBB-VPLS networks:
-
Control plane – MRRP processing takes CPU cycles and the number of attributes that can be advertised is not unlimited
-
Data plane – each group B-MAC registration takes one MFIB entry (the MFIB is shared between MMRP and IGMP/PIM snooping)
SR OS routers support MMRP policies and ISID-based filters so that control plane and data plane resources can be saved when I-VPLS instances are not defined in all the domains.
Inter-domain B-VPLS and MMRP policies/ISID-based filters example illustrates an example of usage for MMRP policies and ISID-based filters that will be configured in this section. ‟Domain 1” and ‟domain 2” will have a range of local ISIDs each and a range of ‟inter-domain” ISIDs:
-
Domain 1 local ISIDs: from 1 to 100
-
Domain 2 local ISIDs: from 101 to 200
-
Inter-domain ISIDs: from 1000 to 2000
By applying the MMRP policies indicated in Inter-domain B-VPLS and MMRP policies/ISID-based filters example, domain 1 attributes will be prevented from being declared and registered in domain 2 and the other way around, domain 2 attributes from being declared and registered in domain 1. The egress MAC filters will drop any traffic sourced from a local ISID preventing it to be transmitted to the remote domain.
MMRP policies
The following shows the MMRP policy configuration on node PE-1. This policy will block any registration/declaration except those for ISIDs 1000-2000. Packets will be compared against the configured matching ISIDs as long as the PBB Etype matches the one configured on the port or SDP.
# on PE-1:
configure {
service {
mrp {
policy "mrp_policy_1" {
description "allow-inter-domain-isids"
default-action block
entry 10 {
action allow
match {
isid 1000 {
higher-value 2000
}
}
}
}
After the MMRP policy is configured, it must be applied on the corresponding SAP or SDP-binding. An MRP policy can be applied to a B-VPLS SAP, B-VPLS spoke-SDP or B-VPLS mesh-SDP:
# on PE-1:
configure {
service {
vpls "B-VPLS 100" {
spoke-sdp 14:100 {
mrp {
policy "mrp_policy_1"
}
}
spoke-sdp 15:100 {
mrp {
policy "mrp_policy_1"
}
}
In the same way, mrp_policy_3 will be configured in PE-3.
Some additional considerations about the MMRP policies:
-
Different entries within the same MRP policy can have overlapping ISID ranges. The entries will be evaluated in the order of their IDs and the first match will cause the implementation to execute the associated action for that entry and then to exit the MRP policy.
-
If no ISID is specified in the match condition then:
-
If the action is ‟end-station”, no entry is added and the action is block.
-
If the action is different from ‟end-station”, every ISID is considered for that action.
-
-
The MRP policy specifies either a forward or a drop action for the group B-MAC attributes associated with the ISIDs specified in the match criteria.
[ex:configure service mrp policy "mrp_policy_1" entry 10] A:admin@PE-1# action ? action <keyword> <keyword> - (block|allow|end-station) Specify the action to take for packets that match this mrp-policy entry -
There is an additional action called end-station. This action specifies that an end-station emulation is present on the SAP/SDP-binding where the policy has been applied. The matching ISIDs will not get declared/registered in the SAP/SDP-binding (just like the block action). However, those attributes will get mapped as static MMRP entries on the SAP/SDP-binding, which implicitly get instantiated in the data plane as MFIB entries associated with that SAP/SDP-binding for the related group B-MAC. When the action is ‟end-station”, the default action must be block:
*[ex:configure service mrp policy "mrp_policy_3"] A:admin@PE-3# default-action allow *[ex:configure service mrp policy "mrp_policy_3"] A:admin@PE-3# commit MINOR: MGMT_CORE #4001: configure service mrp policy "mrp_policy_3" entry 10 action - Mrp-policy default-action must be block when end-station action exists - configure service mrp policy "mrp_policy_3" default-action -
The end-station action can be used in the inter-domain gateways when, for instance, we do not want MMRP control plane exchanges between domains. The following output shows how to define the static MMRP entries 1000-2000 in PE-3 without receiving any declaration for any of those attributes or having any of those locally configured.
# on PE-3: configure { service { mrp { policy "mrp_policy_3" { default-action block entry 10 { action end-station match { isid 1000 { higher-value 2000 } } } }[] A:admin@PE-3# show service id 100 mfib =============================================================================== Multicast FIB, Service 100 =============================================================================== Source Address Group Address Port Id Svc Id Fwd Blk ------------------------------------------------------------------------------- * 01:1e:83:00:03:e8 b-sdp:36:100 Local Fwd * 01:1e:83:00:03:e9 b-sdp:31:4294967294 Local Fwd b-sdp:36:100 Local Fwd ---snip--- * 01:1e:83:00:07:ce b-sdp:36:100 Local Fwd * 01:1e:83:00:07:cf b-sdp:36:100 Local Fwd * 01:1e:83:00:07:d0 b-sdp:36:100 Local Fwd ------------------------------------------------------------------------------- Number of entries: 1001 =============================================================================== -
The MRP policy can be applied to multiple B-VPLS services as long as the scope of the policy is template (the scope can also be exclusive).
-
Any changes made to the existing policy will be applied immediately to all services where this policy is applied. For this reason, when many changes are required on a MRP policy, Nokia recommends copying the policy to a work-in-progress policy. That work-in-progress policy can be modified until complete and then written over the original MRP policy. You can use the configure service mrp copy command to work with the policies in this manner.
[ex:configure service mrp]
A:admin@PE-1# copy policy "mrp_policy_3" to policy ?
[policy-name] <string>
<string> - <1..32 characters>
Specify the policy name associated with the MRP
The rename command can help to change the entries sequence order.
[ex:configure service mrp policy "mrp_policy_3"]
A:admin@PE-3# rename entry 10 to ?
[entry-id] <number>
<number> - <1..65535>
Sepcify an id for the MRP policy entry
An MRP policy cannot be deleted until it is removed from all the SAPs/SDP-bindings where it is applied.
ISID-based filters
The MMRP policies help to control the exchange of group B-MAC attributes across domains. Based on the registration state of a specific group B-MAC on a SAP/SDP-binding, the BUM traffic for a particular I-VPLS will be allowed or dropped. However, to avoid that any local ISID packet is flooded to the remote B-VPLS domain, all the packets tagged with the local ISIDs at the gateway PEs need to be filtered at the data plane. ISID-based filters will prevent the local ISIDs from sending any packet with unicast B-MAC to the remote domain. This is particularly useful for PBB-Epipe services across domains, where all the frames use unicast B-MACs and MMRP policies cannot help because they only act on group B-MAC packets.
The following CLI output shows how to configure an ISID-based filter that drops all the traffic sourced from the local ISIDs on PE-1 (the default action is drop and it does not show up in the configuration).
# on PE-1:
configure {
filter {
mac-filter "MAC 1" {
description "drop_local_isids"
type isid
filter-id 1
entry 10 {
log 101
match {
frame-type 802dot3
isid {
range {
start 1000
end 2000
}
}
}
action {
accept
}
}
Once the filter is configured, it must be applied on a B-VPLS SAP or SDP-binding and always at egress.
# on PE-1:
configure {
service {
vpls "B-VPLS 100" {
spoke-sdp 14:100 {
egress {
filter {
mac "MAC 1"
}
}
}
spoke-sdp 15:100 {
egress {
filter {
mac "MAC 1"
}
}
}
Some additional comments about ISID-based filters:
-
The type isid statement must be added when ISIDs are defined in the match command, otherwise the system will show an error, as follows:
*[ex:configure filter mac-filter "MAC 2"] A:admin@PE-1# commit MINOR: MGMT_CORE #4001: configure filter mac-filter "MAC 2" entry 10 match isid value - The match criteria entered are not compatible with the Mac filter type - Allowed only with mac-filter type ISID - configure filter mac-filter "MAC 2" type -
When the operator sets the ‟type isid”, the filter cannot be applied at ingress. Only egress ISID-based filters are allowed:
[ex:configure service vpls "B-VPLS 100" spoke-sdp 14:100 ingress filter] A:admin@PE-1# mac "MAC 1" *[ex:configure service vpls "B-VPLS 100" spoke-sdp 14:100 ingress filter] A:admin@PE-1# commit MINOR: SVCMGR #2050: configure service vpls "B-VPLS 100" spoke-sdp 14:100 ingress filter mac - Can not apply filter of type 'isid' on ingress - configure filter mac-filter "MAC 1" type -
Like any filter or MMRP policy, the filter can be applied to multiple B-VPLS services as long as the scope of the policy is ‟template” (the scope can also be ‟exclusive”).
-
The following command shows the filter configuration and packets that have matched the filter (field ‟Egr. Matches”):
[] A:admin@PE-1# show filter mac 1 =============================================================================== Mac Filter =============================================================================== Filter Id : 1 Applied : Yes Scope : Template Def. Action : Drop Entries : 1 Type : isid Description : drop_local_isids Filter Name : MAC 1 ------------------------------------------------------------------------------- Filter Match Criteria : Mac ------------------------------------------------------------------------------- Entry : 10 FrameType : Ethernet Description : (Not Specified) Log Id : 101 ISID : 1000..2000 Primary Action : Forward Ing. Matches : 0 pkts Egr. Matches : 5 pkts (580 bytes) =============================================================================== -
Like any other filter, the matching packets can be logged. An example follows (the Ethertype is 0x88e7, which is the default standard Ethertype for PBB):
[] A:admin@PE-1# show filter log 101 =============================================================================== Filter Log =============================================================================== Admin state : Enabled Description : Default filter log Destination : Memory Wrap : Enabled ------------------------------------------------------------------------------- Maximum entries configured : 1000 Number of entries logged : 5 ------------------------------------------------------------------------------- 2021/01/12 17:13:40 Mac Filter: 1:10 Desc: Interface: int-PE-1-MTU-4 Direction: Egress Action: Forward VID match: 0 Src MAC: 00-06-06-06-06-06 Dst MAC: 00-aa-aa-aa-00-0f EtherType: 88e7 Hex: 00 00 03 e9 00 08 00 00 00 00 00 10 00 00 00 00 08 00 45 00 00 54 27 97 00 00 40 01 22 ee ac 10 6c 02 ac 10 6c 01 00 00 f1 ff 00 fb 80 01 5f fd* 2021/01/12 17:13:41 Mac Filter: 1:10 Desc: Interface: int-PE-1-MTU-4 Direction: Egress Action: Forward VID match: 0 Src MAC: 00-06-06-06-06-06 Dst MAC: 00-aa-aa-aa-00-0f EtherType: 88e7 Hex: 00 00 03 e9 00 08 00 00 00 00 00 10 00 00 00 00 08 00 45 00 00 54 27 99 00 00 40 01 22 ec ac 10 6c 02 ac 10 6c 01 00 00 41 05 00 fb 80 02 5f fd* ---snip--- =============================================================================== * indicates that the corresponding row element may have been truncated.
B-VPLS and I-VPLS show and debug commands
For the following output, the MRP policies and ISID-based MAC filters have been removed from the spoke-SDPs on PE-1 and PE-3. The following commands can help to check the B-VPLS and I-VPLS configuration and their related parameters. The first is for the B-VPLS on MTU-4:
[]
A:admin@MTU-4# show service id 100 base
===============================================================================
Service Basic Information
===============================================================================
Service Id : 100 Vpn Id : 0
Service Type : b-VPLS
MACSec enabled : no
Name : B-VPLS 100
Description : (Not Specified)
Customer Id : 1 Creation Origin : manual
Last Status Change: 01/12/2021 16:08:29
Last Mgmt Change : 01/12/2021 17:03:38
Etree Mode : Disabled
Admin State : Up Oper State : Up
MTU : 2000
SAP Count : 0 SDP Bind Count : 2
Snd Flush on Fail : Disabled Host Conn Verify : Disabled
SHCV pol IPv4 : None
Propagate MacFlush: Disabled Per Svc Hashing : Disabled
Allow IP Intf Bind: Disabled
Fwd-IPv4-Mcast-To*: Disabled Fwd-IPv6-Mcast-To*: Disabled
Mcast IPv6 scope : mac-based
Temp Flood Time : Disabled Temp Flood : Inactive
Temp Flood Chg Cnt: 0
SPI load-balance : Disabled
TEID load-balance : Disabled
Src Tep IP : N/A
Vxlan ECMP : Disabled
MPLS ECMP : Disabled
VSD Domain : <none>
Oper Backbone Src : 00:aa:aa:aa:aa:04
Use SAP B-MAC : Enabled
i-Vpls Count : 2
Epipe Count : 0
Use ESI B-MAC : Disabled
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sdp:41:100 S(192.0.2.1) Spok 8000 8000 Up Up
sdp:42:100 S(192.0.2.2) Spok 8000 8000 Up Up
===============================================================================
* indicates that the corresponding row element may have been truncated.
For the I-VPLS on MTU-4:
[]
A:admin@MTU-4# show service id 1 base
===============================================================================
Service Basic Information
===============================================================================
Service Id : 1 Vpn Id : 0
Service Type : i-VPLS
MACSec enabled : no
Name : I-VPLS 1
Description : (Not Specified)
Customer Id : 1 Creation Origin : manual
Last Status Change: 01/12/2021 16:17:52
Last Mgmt Change : 01/12/2021 16:17:52
Etree Mode : Disabled
Admin State : Up Oper State : Up
MTU : 1514
SAP Count : 1 SDP Bind Count : 0
Snd Flush on Fail : Disabled Host Conn Verify : Disabled
SHCV pol IPv4 : None
Propagate MacFlush: Disabled Per Svc Hashing : Disabled
Allow IP Intf Bind: Disabled
Fwd-IPv4-Mcast-To*: Disabled Fwd-IPv6-Mcast-To*: Disabled
Mcast IPv6 scope : mac-based
Temp Flood Time : Disabled Temp Flood : Inactive
Temp Flood Chg Cnt: 0
SPI load-balance : Disabled
TEID load-balance : Disabled
Src Tep IP : N/A
Vxlan ECMP : Disabled
MPLS ECMP : Disabled
VSD Domain : <none>
b-Vpls Id : 100 Oper ISID : 1
b-Vpls Status : Up
Snd Flush in bVpls: None
Flsh On bVpls Fail: Disabled Prop Flsh fr bVpls: Disabled
Force QTag Fwd : Disabled
SendBvplsEvpnFlush: Disabled
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sap:1/1/1:7 q-tag 1518 1518 Up Up
===============================================================================
* indicates that the corresponding row element may have been truncated.
The following command shows all the I-VPLS instances multiplexed into a particular B-VPLS.
[]
A:admin@MTU-4# show service id 100 i-vpls
===============================================================================
Related i-Vpls services for b-Vpls service 100
===============================================================================
i-Vpls SvcId Oper ISID Admin Oper
-------------------------------------------------------------------------------
1 1 Up Up
2 2 Up Up
-------------------------------------------------------------------------------
Number of Entries : 2
-------------------------------------------------------------------------------
===============================================================================
Some useful commands to check the I and B VPLS FIBs correlating C-MACs and B-MACs:
[]
A:admin@MTU-4# show service id 1 fdb pbb
==============================================================================
Forwarding Database, i-Vpls Service 1
==============================================================================
MAC Source-Identifier B-Svc b-Vpls MAC Type/Age
Transport:Tnl-Id
------------------------------------------------------------------------------
00:07:00:00:00:00 sap:1/1/1:7 100 N/A L/0
00:09:00:00:00:00 b-sdp:41:100 100 00:06:06:06:06:06 L/0
==============================================================================
[]
A:admin@MTU-4# show service id 100 fdb pbb
=======================================================================
Forwarding Database, b-Vpls Service 100
=======================================================================
MAC Source-Identifier iVplsMACs Epipes Type/Age
Transport:Tnl-Id
-----------------------------------------------------------------------
00:06:06:06:06:06 sdp:41:100 2 0 L/0
02:0f:ff:00:00:00 sdp:41:100 0 0 L/0
=======================================================================
If MAC names are used in the configuration, the following commands can show the translations:
[]
A:admin@MTU-4# show service pbb mac-name
======================================================================
MAC Name Table
======================================================================
MAC-Name MAC-Address
----------------------------------------------------------------------
MTU-4 00:04:04:04:04:04
MTU-5 00:05:05:05:05:05
MTU-6 00:06:06:06:06:06
======================================================================
[]
A:admin@MTU-4# show service pbb mac-name mac-name-1 "MTU-6" detail
======================================================================
Services Using MAC name='MTU-6' addr='00:06:06:06:06:06'
======================================================================
Svc-Id ISID
----------------------------------------------------------------------
1 N/A
----------------------------------------------------------------------
Number of services: 1
======================================================================
The following command shows the base MAC notification parameters as well as the source B-MAC configured at the service PBB level. Those values are overridden by any potential MAC notification or source B-MAC values configured under the B-VPLS service context.
[]
A:admin@MTU-4# show service pbb base
======================================================================
PBB MAC Information
======================================================================
MAC-Notif Count : 3
MAC-Notif Interval : 1
Source BMAC : 00:04:04:04:04:04
Leaf Source BMAC : Default
======================================================================
If MAC notification is used in a particular B-VPLS, the configured least significant bits for the SAP B-MAC on a particular MC-LAG can be shown by using the detailed view of the show lag command:
[]
A:admin@MTU-4# show lag 1 detail
===============================================================================
LAG Details
===============================================================================
Description : N/A
-------------------------------------------------------------------------------
Details
-------------------------------------------------------------------------------
Lag-id : 1 Mode : access
Adm : up Opr : up
---snip---
MC Peer Address : 192.0.2.5 MC Peer Lag-id : 1
MC System Id : 00:00:00:00:00:01 MC System Priority : 65535
MC Admin Key : 15 MC Active/Standby : active
MC Lacp ID in use : true MC extended timeout : false
MC Selection Logic : local master decided
MC Config Mismatch : no mismatch
Source BMAC LSB : use-lacp-key Oper Src BMAC LSB : 00:0f
---snip---
===============================================================================
The following debug commands (in classic CLI) allow the operator to check the LDP label mapping, label withdrawal, messages and also the MAC-flush messages for regular VPLS, for I-VPLS and B-VPLS including the PBB extensions and TLVs.
debug
router "Base"
ldp
peer 192.0.2.1
event
exit
packet
init detail
label detail
exit
exit
peer 192.0.2.2
event
exit
packet
init detail
label detail
exit
exit
exit
exit
exit
The following debug commands (in classic CLI) can help the operator to troubleshoot MMRP.
A:MTU-4# debug service id 100 mrp ?
- mrp
- no mrp
all-events - Enable/disable MRP debugging for all events
[no] applicant-sm - Enable/disable MRP debugging for applicant state machine
changes
[no] leave-all-sm - Enable/disable MRP debugging for leave all state machine
changes
[no] mmrp-mac - Enable/disable MRP debugging for a particular MAC address
[no] mrpdu - Enable/disable MRP debugging for Rx/Tx MRP PDUs
[no] mvrp-vlan - Enable/disable debugging for a particular vlan
[no] periodic-sm - Enable/disable MRP debugging for periodic state machine
changes
[no] registrant-sm - Enable/disable MRP debugging for registrant state machine
changes
[no] sap - Enable/disable MRP debugging for a particular SAP
[no] sdp - Enable/disable MRP debugging for a particular SDP
Conclusion
PBB-VPLS allows the service providers to scale VPLS services by multiplexing customer I-VPLS instances into one or more B-VPLS instances. This multiplexing dramatically reduces the number of services, pseudowires, and MAC addresses in the core and therefore allows the service provider to scale Layer 2 multi-point networks and provide services across international backbones.
The example used in this chapter shows the configuration of the customer and backbone VPLS instances as well as all the related features which are required for this environment. Show and debug commands have also been suggested so that the operator can verify and troubleshoot the service.