In the EVPN/MPLS Bridging Forwarding Model blog post I mentioned numerous services defined in RFC 7432. That blog post focused on VLAN-Based Service Interface that mirrors the Carrier Ethernet VLAN mode.

RFC 7432 defines two other VLAN services that can be used to implement Carrier Ethernet services:

• Port-based service – whatever is received on the ingress port is sent to the egress port(s)
• VLAN bundle service – multiple VLANs sharing the same bridging table, effectively emulating single outer VLAN in Q-in-Q bridging.

And then there’s the VLAN-Aware Bundle Service, where a bunch of VLANs share the same MPLS pseudowires while having separate bridging tables.

Looking at that, I was left wondering who would ever do something like that. It’s not like we’re trying to limit the number of VLANs on a PE-device, or the number of bridging (MAC address) tables used on that device (remember: each VLAN within that service bundle has a separate MAC address table). The only thing we’re saving are MPLS labels which are signaled between the egress and ingress devices, and are never visible to the network core. Really, IETF 🤦‍♂️

Just in case you’re as confused as I am, here’s the justification from RFC 7209:

For hosted applications for data-center interconnect, network operators require the ability to extend Ethernet VLANs over a WAN using a single L2VPN instance while maintaining data-plane separation between the various VLANs associated with that instance. This is referred to as ‘VLAN-aware bundling service’.

Why would they “require a single L2VPN instance”? Because the transport provider charges per label?

Anyway, time to see how that beast works. We’ll use the very same lab as before, but split the hosts into two VLANs that will be provisioned as a VLAN bundle. The Arista EOS configuration files are on GitHub as is the lab topology in case you want to recreate the lab¹.

Inspecting the EVPN routes advertised by PE3, we can see that all mac-ip routes (RT2) have the same MPLS label, regardless of the VLAN the host belongs to. Likewise, imet (RT3) routes for all VLANs also have the same MPLS label.

pe1#sh bgp evpn next-hop 10.0.0.3 detail
BGP routing table information for VRF default
Router identifier 10.0.0.1, local AS number 65000
BGP routing table entry for mac-ip 1000 5254.009b.a561, Route Distinguisher: 65000:1
 Paths: 1 available
  Local
    10.0.0.3 from 10.0.0.3 (10.0.0.3)
      Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
      Extended Community: Route-Target-AS:65000:1 TunnelEncap:tunnelTypeMpls
      MPLS label: 1042979 ESI: 0000:0000:0000:0000:0000
BGP routing table entry for mac-ip 1001 5254.00c9.82dc, Route Distinguisher: 65000:1
 Paths: 1 available
  Local
    10.0.0.3 from 10.0.0.3 (10.0.0.3)
      Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
      Extended Community: Route-Target-AS:65000:1 TunnelEncap:tunnelTypeMpls
      MPLS label: 1042979 ESI: 0000:0000:0000:0000:0000
BGP routing table entry for imet 1000 10.0.0.3, Route Distinguisher: 65000:1
 Paths: 1 available
  Local
    10.0.0.3 from 10.0.0.3 (10.0.0.3)
      Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
      Extended Community: Route-Target-AS:65000:1 TunnelEncap:tunnelTypeMpls
      MPLS label: 1038234
      PMSI Tunnel: Ingress Replication, MPLS Label: 16611744, Leaf Information Required: false, Tunnel ID: 10.0.0.3
BGP routing table entry for imet 1001 10.0.0.3, Route Distinguisher: 65000:1
 Paths: 1 available
  Local
    10.0.0.3 from 10.0.0.3 (10.0.0.3)
      Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
      Extended Community: Route-Target-AS:65000:1 TunnelEncap:tunnelTypeMpls
      MPLS label: 1038234
      PMSI Tunnel: Ingress Replication, MPLS Label: 16611744, Leaf Information Required: false, Tunnel ID: 10.0.0.3

If you’re wondering how PE3 figures out which MAC address table to use when receiving packets over those MPLS wires you’re probably not alone. The only way to do it is to send 802.1Q tagged packets over MPLS wires. You can see that if you inspect the MPLS LFIB on PE3.

pe3#sh mpls lfib route
MPLS forwarding table (Label [metric] Vias) - 5 routes
MPLS next-hop resolution allow default route: False
Via Type Codes:
          M - MPLS via, P - Pseudowire via,
          I - IP lookup via, V - VLAN via,
          VA - EVPN VLAN aware via, ES - EVPN ethernet segment via,
          VF - EVPN VLAN flood via, AF - EVPN VLAN aware flood via,
          NG - Nexthop group via
Source Codes:
          G - gRIBI, S - Static MPLS route,
          B2 - BGP L2 EVPN, B3 - BGP L3 VPN,
          R - RSVP, LP - LDP pseudowire,
          L - LDP, M - MLDP,
          I>BL - IS-IS SR to BGP LU, IP - IS-IS SR prefix segment,
          IA - IS-IS SR adjacency segment, I>L - IS-IS SR to LDP,
          L>I - LDP to IS-IS SR, BL - BGP LU,
          BL>L - BGP LU to LDP, L>BL - LDP to BGP LU,
          ST - SR TE policy, SMP - SR P2MP,
          BL>I - BGP LU to IS-IS SR, DE - Debug LFIB

 L     116384   [1], 10.0.0.4/32
                via M, 10.1.0.9, pop
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet1
 L     116385   [1], 10.0.0.2/32
                via M, 10.1.0.9, swap 116384
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet1
 L     116386   [1], 10.0.0.1/32
                via M, 10.1.0.9, swap 116385
                 payload autoDecide, ttlMode uniform, apply egress-acl
                 interface Ethernet1
 B2    1038234  [0]
                via AF, control word present
                     dot1q   vlan
                    | 1000 | 1000 |
                    | 1001 | 1001 |
 B2    1042979  [0]
                via VA, control word present
                     dot1q   vlan
                    | 1000 | 1000 |
                    | 1001 | 1001 |

Does that mean that the flow of traffic would be suboptimal, or that (for example) PE2 would receive flooded traffic for red VLAN? Not necessarily – every VLAN has its own MAC address table and could have its own ingress replication list.

OK, so VLAN-aware bundle service has no drawbacks. Does it have any benefits? I can’t see them, unless you’re worried about the number of MPLS labels, route targets, or configuration lines (BGP configuration of VLAN-aware bundle service on Arista EOS takes fewer lines than configuring individual VLANs in the BGP process). Am I missing something? Please write a comment.

Recap: Should you use VLAN-aware Bundle Service? Paraphrasing James Mickens: “In a word: don’t!”