PDF(417.8 KB) View with Adobe Reader on a variety of devices
ePub(365.5 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(278.9 KB) View on Kindle device or Kindle app on multiple devices
Updated:March 9, 2018
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes functioning of basic Provider Backbone Bridge technology (PBB). It uses Multi Spanning Tree (MST) in the core network for loop avoidance.
Cisco recommends that you have basic knowledge of MST and VPLS (Virtual Private Lan Service).
This document is not restricted to specific software and hardware versions. The information in this document was created using Aggregation Services Router 9000 (ASR9K) devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration.
IEEE 802.1ah Provider Backbone Bridging Overview
The Institute of Electrical and Electronics Engineers (IEEE) 802.1ah PBB feature encapsulates or decapsulates end-user traffic on a Backbone Edge Bridge (BEB) at the edge of the Provider Backbone Bridged Network (PBBN). PBB provides scalability to configure higher number of service instances in network. PBB encapsulates customer's network into 802.1ah headers. These encapsulated packets are exchanged using unique and manually configured backbone address in core network. This obviates the need for backbone core bridges to learn all MAC addresses of every customer and hence adding to scalability. In order to understand technology behavior, it is important to understand meaning of some terminologies that will be frequently used in this document.
This document will be frequently using some terminologies associated with PBB. These are listed below with brief explanation.
B-MAC : All the bridges(routers) in backbone network are manually configured with a unique MAC address. These MAC addresses are used in forwarding base to identify which remote BEB should customer traffic be forwarded to.
B-SA : Denotes backbone MAC address of source bridge.
B-DA : Denotes backbone MAC address of destination bridge.
BEB : Backbone edge bridge is the router that faces customer edge node.
BCB : Backbone core bridge is transit node in provider's core network that switches frame towards destination.
B-VID : Vlan that carries PBB encapsulated customer traffic within core.
I-SID : Represents a unique service identifier associated with service instances.
B-Tag : Contains backbone vlan(B-VLAN) id information. I-Tag : Contains I-SID value and helps destination BEB router to determine which I-Component or service instance should the traffic be forwarded to.
S-VID : Vlan that receives customer traffic and is called Service Vlan identifier(S-VID). C-VID : Vlan tag received in customer's frame. This remains intact while it encapsulated and transported across provider network. C-SA : Original source MAC address of customer's frame. C-DA : Original destination MAC address of customer's frame.
Note: C-VID, C-SA and C-DA and payload that constitute customer frame os never changed in PBB network.
The IEEE 802.1ah provides a framework to interconnect several provider bridged networks, often called as PBNs. It provides means to scale the service Vlans in provider’s network. PBB network comprises of two main components called as I-Component & B-Component.
I-Component: This component resides on BEB (Backbone Edge Nodes) routers and faces customer network. It is responsible for handling customer traffic and adding a PBB header to it. I-Component maintains important mapping information:
- It maintains mapping between S-VID and I-SID
- It maintains customer mac (C-DA) to bridge backbone mac address (B-DA) mapping.
I-Component Configuration: The two components are defined in the form of different l2vpn bridge group and domain.
l2vpn bridge group I-Comp-Grp bridge-domain I-Comp-Dmn
B-Component: This component is responsible for forwarding traffic in the core network. It maintains a database of B-MACs and the interfaces they are learnt from. This information is used by forwarding engine to select an egress path for outgoing traffic to other remote BEBs.
l2vpn bridge group B-Comp-Grp bridge-domain B-Comp-Dmn
interface GigabitEthernet <> // Adds an interface to a bridge domain that allows packets to be // forwarded and received from other interfaces that are part of the same bridge domain. pbb core rewrite ingress tag push dot1ad <B-VID> symmetric // Defines backbone vlan id for core ! ! ! !
B-MAC configuration: Every router in PBB environment is identified by a unique MAC address. These backbone MAC addresses are used in 802.1ah encapsulations to forward traffic in B-VID.
l2vpn pbb backbone-source-mac XXXX.YYYY.ZZZZ ! !
Layer 2 loop avoidance protocol
The two components of PBB receive customer traffic and encapsulate it in 802.1ah. This encapsulate frame uses backbone vlan to reach its destination. Which backbone vlan will be used to forward the traffic is decided by the B-VID value configured in B-Component bridge-domain. All layer 2 networks are prone to loops and hence provider’s core requires loop avoidance protocols to check this. This scenario will utilize Multi Spanning Tree(MST)
The below picture describes the two components present on a BEB router. It shows the headers that are imposed on the customer traffic. Original customer traffic received with 802.1q tag is further imposed with 802.1ad and 802.1ah encapsulations before it is finally set into core network for forwarding.
PBB requires both 'I' and 'B' component to be configured on BEB (customer facing) nodes. BCB (core router) that does not connect to any customer end router only requires B component.
// Below is BEB-1 configuration. Similar configuration applies to other BEBs.
// B-MAC Configuration
l2vpn pbb backbone-source-mac 000a.2500.0001 ! !
l2vpn bridge group I-Comp-Grp bridge-domain I-Comp-Dmn
l2vpn bridge group B-Comp-Grp bridge-domain B-Comp-Dmn
interface Bundle-Ether2.1506 ! pbb core rewrite ingress tag push dot1ad 1506 symmetric ! ! ! !
Likewise BCB-1, BEB-2, BCB-2 also uses similar structure of configuration.
Below is a structure of MST configuration used on all BEBs & BCBs. In this test scenario, B-VID falls in instance 1 of all the four routers. MST provides a loop free layer 2 path between core and edge routers. Node required to be root bridge needs to be set with lower priority.
spanning-tree mst <name> name <name> maximum age <value> revision <rev. no.> provider-bridge
instance 1 vlan-ids 1505-1507 priority 4096
interface Bundle-Ether1 instance 1 cost 10000
interface Bundle-Ether11 instance 1 cost 20000
How PBB works?
Unicast Traffic Forwarding
This scenario discusses the case where traffic received from customer is destined to a unicast destination MAC address. Below is the profile of traffic considered for this scenario.
Encapsulation at source (BEB-1)
Customer Edge (CE) node forwards the traffic towards BEB-1. This traffic has source and destination MAC addresses as 0000.0000.1111 and 0000.0000.2222 respectively.
Traffic is received in Vlan ID 554 (S-VID) on interface GigabitEthernet0/0/0/12.554 which is a part of I-Comp-Dmn.
The I-Component of PBB receives this traffic and looks up forwarding base mapping for customer's destination MAC address 0000.0000.2222 .
Mac AddressTypeLearned from/Filtered onLC learned Resync Age/Last Change Mapped to -------------- ------- --------------------------- ---------- ---------------------- -------------- 0000.0000.1111 dynamic Gi0/0/0/12.5540/0/CPU0 29 Nov 11:16:11N/A 0000.0000.2222 dynamic BD id: 24 0/0/CPU0 29 Nov 11:18:41a000.7500.0001 e0ac.f15f.8a8b routedBD id: 24 N/AN/AN/A
4. I-Component has an entry for destination MAC address 0000.0000.2222 and it is found to be mapped to ' backbone address a000.7500.0001'. This lookup provides the necessary B-MAC (backbone MAC) needed to build the frame.
5. I-Component encapsulates customer frame with necessary fields like I-SID, B-SA, B-DA, S-VID etc. and passes it down to B-Component for forwarding.
6. B-Component performs a lookup for B-DA and determines the egress interface to forward traffic.
Mac AddressTypeLearned from/Filtered onLC learned Resync Age/Last Change Mapped to -------------- ------- --------------------------- ---------- ---------------------- -------------- 000a.2500.0001 dynamic BE2.15060/RSP0/CP29 Nov 11:57:28N/A a000.7500.0001 dynamic BE11.1506 0/RSP0/CP29 Nov 11:56:28N/A a000.3500.0001 S-BMACBD id: 12 N/AN/AN/A
Decapsulation at destination(BEB-2)
1. Destination BEB-2 receives the traffic. It performs a lookup based on I-SID to determine associated I-Component/service instance. In this case, lookup provides with 'I-Comp-Dmn'. The 802.1ah header is then stripped and traffic is sent to associated service instance.
2. A MAC lookup for customer’s destination address 0000.0000.2222 is done to determine the attachment circuit this frame needs to be sent out from. In this case, traffic is forward to customer CE via attachment circuit 'Gi0/0/0/12.554'.
Below is a packet level view of encapsulated customer frame. It has same values/profiles as listed above in Table 1. Every PBB packet is an encapsulated combination of 802.1q , 802.1ah and 802.1ad. These ether-types can be seen in packet HEX dump.
Above scenario described a case where ‘I-Comp-Dmn’ bridge domain already had an S-DA to B-DA mapping. Therefore, router already knew which remote BEB to send next frame to before even it arrived.
Mac AddressTypeLearned from/Filtered onLC learned Resync Age/Last Change Mapped to -------------- ------- --------------------------- ---------- ---------------------- -------------- 0000.0000.1111 dynamic Gi0/0/0/12.5540/0/CPU0 29 Nov 11:16:11N/A 0000.0000.2222 dynamic BD id: 24 0/0/CPU0 29 Nov 11:18:41a000.7500.0001
Customer traffic can be multicast, broadcast or unknown unicast. Destination MAC address of such a traffic is not mapped to any particular remote BEB and hence sender/encapsulating BEB does not know which remote BEB to send this traffic to. This example uses broadcast traffic in the form of ARP to explain how PBB handles such traffic. For this case, two customer host machines are considered to have newly joined network in same broadcast domain on different BEBs. Before these two machines begin to send any packets, they need to send a broadcast ARP request at destination MAC address ffff.ffff.ffff to learn each other's MAC addresses. When source encapsulating BEB receives an ARP request, it determines by looking at the destination MAC address of received frame that it is broadcast traffic.
A special group MAC is used for the backbone destination MAC (B-DA) when handling an unknown unicast, multicast or broadcast frame. This backbone group MAC is derived from the I-service instance identifier (ISID) using following rule.
The ARP request is received by ingress BEB, which encapsulates it in an 802.1ah frame with special B-DA derived as explained above. This frame is then received by core routers (BCBs). Core BCBs forward this frame to all BEBs using same B-VID (1506). When this encapsulated frame is received by remote BEBs, they check the I-SID to determine asociated service instance corresponding to it. Once I-Component (or bridge domain associated with I-SID) is identified, a look up is donw for customer's MAC address to determine the attachment circuit to forward the traffic out. In below scenario, host 10.0.0.20 is behind BEB-4 and it responds with an ARP reply. Other network devices behind BEB-2 and BEB-3 receive ARP request and ignore.