802.1ah (MAC-in-MAC)
Last updated
Last updated
802.1ah Provider Backbone Bridging provides for similar scalability that a “BGP free” Core, or L3VPN provides. In a BGP free Core and L3VPN, pure core routers do not need to concern themselves with customer VRFs or even BGP at all. Core routers simply preform label switching on the top transport label, which represents the egress PE.
Similarly, in 802.1ah, core provider switches don’t need to concern themselves with the totality of all customer MAC addresses. Core provider switches simply need to know the destination MACs of all core switches. Customer frames are encapsulated into a second layer 2 header (an 802.1ah header). The destination MAC of this new header is always a provider MAC. This is similar to how the top MPLS label of an L3VPN service is always represents egress PE.
The 802.1ah header, besides having “normal” source and destination MAC fields, and an 802.1q tag field, also has an Instance field. This field is used similar to an L3VPN service label. When the egress provider switch receives the frame, it looks at the Instance field to know which customer bridge domain the frame belongs to.
You can now see the reason that 802.1ah is called “MAC-in-MAC.” You are literally encapsulating the MAC header inside a new MAC header. 802.1ah adds an 18 byte header.
The B-Tag is the backbone VLAN ID. It is no different than a regular VLAN ID. It just is used for the backbone bridging domain.
In the diagram above, a BEB is a Backbone Edge Bridge and is responsible for encapsulation and decapsulating 802.1ah traffic. The BCB devices are Backbone Core Bridges and are only responsible for forwarding traffic based on the backbone destination MAC address. These switches will not learn customer MAC addresses.
The BEBs participating in a common customer bridge domain will need to agree on the I-SID (Instance Service ID). When a BEB receives a frame from a customer device with a destination MAC that is located on a remote BEB, the device will push a 802.1ah header onto the frame. The destination MAC will be the remote BEB’s MAC address in the backbone VLAN. The I-SID will be the configured value that the local BEB has for this customer bridge domain. The remote BEB will have to have the same I-SID value configure. When the remote BEB receives the frame in the backbone bridging instance, it will see the I-SID field and know that it is for the particular customer’s bridge domain. It removes the 802.1ah header and then preforms basic MAC forwarding based on the customer bridge domain.
As you can see, with 802.1ah you get an N:1 mapping of customer bridge domains to a single backbone bridge domain. In the core, besides the obvious MAC scalability benefits, you also get a reduction in flood traffic, and ease of layer 2 traffic engineering. The reduction in flood traffic is a direct result of having less MAC addresses in the backbone core. There are simply less MAC addresses to learn. Secondly, changing the layer 2 topology of the backbone bridge domain for traffic engineering purposes is much easier, because you might be only dealing with a single backbone VLAN, instead of dealing with all customer traffic and those associated service VLANs.
In a modern service provider network, you will usually see IP/MPLS as opposed to a layer 2 switched core. The modern solution for VPLS is to use EVPN, in which every single customer MAC address is advertised via MP-BGP.
Interestingly, PBB can be used for EVPN and solves the same issue as with legacy VPLS MAC scalability. If you have millions of Type 2 EVPN routes in your routing table, you may be concerned with scalability in the control plane. This is in contrast the to the scalability issue with legacy VPLS, which was scalability in the data plane.
With PBB-EVPN, you can run a separate EVPN instance for the backbone, and only advertise the PE MACs for this backbone EVPN instance in MP-BGP. Now your EVPN routes have reduced substantially, maybe down to a few hundred at most.
The drawback with this is that you’ve moved customer MAC learning from the control plane “back” to the data plane. PEs will now learn customer MAC to PE MAC bindings in the data plane.
Essentially, PBB-EVPN uses the same 802.1ah header but instead of running a legacy layer 2 bridge domain for the backbone bridging instance, you use EVPN to be able to label switch the traffic in the core.
https://www.youtube.com/watch?v=Rmlk_xIi0rA&ab_channel=Nokia
https://tgregory.org/2016/11/15/evpn-vs-pbb-evpn-and-massive-scale/
