Putting Together Provider Bridging, Provider Backbone Bridging, S-Tags and C-Tags

Putting Together Provider Bridging, Provider Backbone Bridging, S-Tags and C-Tags


Putting Together Provider Bridging, Provider Backbone Bridging, S-Tags and C-Tags

Putting Together Provider Bridging, Provider Backbone Bridging, S-Tags and C-Tags: Understanding carrier bridging techniques is important, not just for provider operators, but also for engineers on the customer edge. When turning up or troubleshooting a circuit, carrier operators will ramble off C-tag and S-tag when many in the enterprise, are used to hearing Vlan ID in single tenancy deployments. More customers are transitioning to L2 circuits from carriers, to cut out carrier L3 routing that is often a complete nightmare to troubleshoot between carrier and customer. Provider bridging (QinQ) and provider backbone bridging (MAC-in-MAC) can be conceptually viewed as the layer 2 equivalent of virtual route forwarding (VRF-lite). These technologies can be signaled via MPLS. L3/VPNs have some advantages, when it comes to draining spoke sites to the Internet by reducing hub to spoke traffic. That said, most organizations drain traffic to the hub sites for policy application. This is a review of one of many ways providers carry L2 customer bridges, as less customers are willing to deal with the headache of having carriers route their traffic. Provider bridging can give the customer a dark fiber experience, which in turn, reduces OpEx to carrier and customer.

Provider Bridging 802.1ad

Provider Bridging 802.1ad

Provider bridging is conceptually pretty simple, vlan stacking or QinQ (802.1Q in 802.1Q). The customer traffic is identified by a Vlan ID (VID) referred to as the C-tag (customer VID) in the 802.1Q framing format. When the C-tagged frame goes upstream to the service provider, it is encapsulated again by the carriers provider bridging edge network. Using 802.1ad encapsulation, the C-tag is then wrapped up with an S-tag (Service VID). Encapsulation in the carrier network allows for overlapping customer VIDs.

Provider Backbone Bridging 802.1ah

Just as customer VIDs need to be masked off from one another to avoid overlap, so does the carrier. Provider Backbone Bridging is also reffered to as MAC in MAC since depending on the scenario, there can be up to 5 Ethertypes doing encapsulation. Some carriers require well over 4094 Vlan IDs to support circuits. Provider Backbone Bridging or MAC-in-MAC (802.1ah) allows for overlapping of S-Tag VIDs, while provider bridging or QinQ (802.1ad) allows for overlapping C-tags. MAC-in-MAC is backwards compatible with QinQ, as they are both tightly coupled to one another. The process is very similar to L3 VPN/VRFs and RFC1918 IPv4 addresses and path isolation for the customer and virtualization of the carrier network to oversubscribe for slicing. Both QinQ and provider backbone bridging are addressed in OpenFlow v1.3 spec.

Provider Backbone Bridging

Provider bridging can be designed in a hierarchal fashion to add scale and reduce complexity.

Additional Reading

The details are pretty deep on Provider Backbone Bridging but most vendors configurations abstract most of the nuances. In the end, just think of each layer needing a distinct value to key on, to avoid overlap and scale issues. The wikis do a nice job summarizing both 802.1ad and 802.1ah. There are various methods of extending L2 service and virtualization for customers and tenants over your network, this is just one mechanism, right, wrong or stupid. What I do highly recommend is, if you are receiving L3/VPN services from your carrier, make sure you have a good business case for doing so. Final note, the IEEE is a joke for still charging to review their documents. Some day these will be open source problems, as standards bodies have lost their minds in hubris.

Thanks for stopping by

About the Author

Brent SalisburyI have over 15 years of experience wearing various hats from, network engineer, architect, devops and software engineer. I currently have the pleasure of working at the company that develops my favorite software I have ever used, Docker. My comments here are my personal thoughts and opinions. More at Brent's BioView all posts by Brent Salisbury →