Within the EVPN/MPLS Bridging Forwarding Mannequin weblog put up I discussed quite a few providers outlined in RFC 7432. That weblog put up centered on VLAN-Based mostly Service Interface that mirrors the Provider Ethernet VLAN mode.
RFC 7432 defines two different VLAN providers that can be utilized to implement Provider Ethernet providers:
- Port-based service – no matter is acquired on the ingress port is shipped to the egress port(s)
- VLAN bundle service – a number of VLANs sharing the identical bridging desk, successfully emulating single outer VLAN in Q-in-Q bridging.
After which there’s the VLAN-Conscious Bundle Service, the place a bunch of VLANs share the identical MPLS pseudowires whereas having separate bridging tables.
Taking a look at that, I used to be left questioning who would ever do one thing like that. It’s not like we’re making an attempt to restrict the variety of VLANs on a PE-device, or the variety of bridging (MAC tackle) tables used on that gadget (bear in mind: every VLAN inside that service bundle has a separate MAC tackle desk). The one factor we’re saving are MPLS labels that are signaled between the egress and ingress units, and are by no means seen to the community core. Actually, IETF 🤦♂️
Simply in case you’re as confused as I’m, right here’s the justification from RFC 7209:
For hosted functions for data-center interconnect, community operators require the flexibility to increase Ethernet VLANs over a WAN utilizing a single L2VPN occasion whereas sustaining data-plane separation between the varied VLANs related to that occasion. That is known as ‘VLAN-aware bundling service’.
Why would they “require a single L2VPN occasion”? As a result of the transport supplier prices per label?
Anyway, time to see how that beast works. We’ll use the exact same lab as earlier than, however break up the hosts into two VLANs that can be provisioned as a VLAN bundle. The Arista EOS configuration information are on GitHub as is the lab topology in case you need to recreate the lab.
Inspecting the EVPN routes marketed by PE3, we will see that every one mac-ip routes (RT2) have the identical MPLS label, whatever the VLAN the host belongs to. Likewise, imet (RT3) routes for all VLANs even have the identical MPLS label.
EVPN routes marketed by PE3
pe1#sh bgp evpn next-hop 10.0.0.3 element
BGP routing desk info for VRF default
Router identifier 10.0.0.1, native AS quantity 65000
BGP routing desk entry for mac-ip 1000 5254.009b.a561, Route Distinguisher: 65000:1
Paths: 1 accessible
Native
10.0.0.3 from 10.0.0.3 (10.0.0.3)
Origin IGP, metric -, localpref 100, weight 0, legitimate, inside, finest
Prolonged Neighborhood: Route-Goal-AS:65000:1 TunnelEncap:tunnelTypeMpls
MPLS label: 1042979 ESI: 0000:0000:0000:0000:0000
BGP routing desk entry for mac-ip 1001 5254.00c9.82dc, Route Distinguisher: 65000:1
Paths: 1 accessible
Native
10.0.0.3 from 10.0.0.3 (10.0.0.3)
Origin IGP, metric -, localpref 100, weight 0, legitimate, inside, finest
Prolonged Neighborhood: Route-Goal-AS:65000:1 TunnelEncap:tunnelTypeMpls
MPLS label: 1042979 ESI: 0000:0000:0000:0000:0000
BGP routing desk entry for imet 1000 10.0.0.3, Route Distinguisher: 65000:1
Paths: 1 accessible
Native
10.0.0.3 from 10.0.0.3 (10.0.0.3)
Origin IGP, metric -, localpref 100, weight 0, legitimate, inside, finest
Prolonged Neighborhood: Route-Goal-AS:65000:1 TunnelEncap:tunnelTypeMpls
MPLS label: 1038234
PMSI Tunnel: Ingress Replication, MPLS Label: 16611744, Leaf Data Required: false, Tunnel ID: 10.0.0.3
BGP routing desk entry for imet 1001 10.0.0.3, Route Distinguisher: 65000:1
Paths: 1 accessible
Native
10.0.0.3 from 10.0.0.3 (10.0.0.3)
Origin IGP, metric -, localpref 100, weight 0, legitimate, inside, finest
Prolonged Neighborhood: Route-Goal-AS:65000:1 TunnelEncap:tunnelTypeMpls
MPLS label: 1038234
PMSI Tunnel: Ingress Replication, MPLS Label: 16611744, Leaf Data Required: false, Tunnel ID: 10.0.0.3
For those who’re questioning how PE3 figures out which MAC tackle desk to make use of when receiving packets over these MPLS wires you’re most likely not alone. The one option to do it’s to ship 802.1Q tagged packets over MPLS wires. You’ll be able to see that if you happen to examine the MPLS LFIB on PE3.
MPLS LFIB (with VLAN tags) on PE3
pe3#sh mpls lfib route
MPLS forwarding desk (Label [metric] Vias) - 5 routes
MPLS next-hop decision permit default route: False
By way of Kind Codes:
M - MPLS by way of, P - Pseudowire by way of,
I - IP lookup by way of, V - VLAN by way of,
VA - EVPN VLAN conscious by way of, ES - EVPN ethernet section by way of,
VF - EVPN VLAN flood by way of, AF - EVPN VLAN conscious flood by way of,
NG - Nexthop group by way of
Supply 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 section,
IA - IS-IS SR adjacency section, 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 coverage, SMP - SR P2MP,
BL>I - BGP LU to IS-IS SR, DE - Debug LFIB
L 116384 [1], 10.0.0.4/32
by way of M, 10.1.0.9, pop
payload autoDecide, ttlMode uniform, apply egress-acl
interface Ethernet1
L 116385 [1], 10.0.0.2/32
by way of M, 10.1.0.9, swap 116384
payload autoDecide, ttlMode uniform, apply egress-acl
interface Ethernet1
L 116386 [1], 10.0.0.1/32
by way of M, 10.1.0.9, swap 116385
payload autoDecide, ttlMode uniform, apply egress-acl
interface Ethernet1
B2 1038234 [0]
by way of AF, management phrase current
dot1q vlan
| 1000 | 1000 |
| 1001 | 1001 |
B2 1042979 [0]
by way of VA, management phrase current
dot1q vlan
| 1000 | 1000 |
| 1001 | 1001 |
Does that imply that the stream of site visitors can be suboptimal, or that (for instance) PE2 would obtain flooded site visitors for purple VLAN? Not essentially – each VLAN has its personal MAC tackle desk and will have its personal ingress replication listing.
OK, so VLAN-aware bundle service has no drawbacks. Does it have any advantages? I can’t see them, except you’re anxious concerning the variety of MPLS labels, route targets, or configuration strains (BGP configuration of VLAN-aware bundle service on Arista EOS takes fewer strains than configuring particular person VLANs within the BGP course of). Am I lacking one thing? Please write a remark.
Recap: Do you have to use VLAN-aware Bundle Service? Paraphrasing James Mickens: “In a phrase: don’t!”