Date created: Monday, September 11, 2023 9:23:21 AM. Last modified: Monday, June 10, 2024 12:32:24 PM

Basic MPLS EVPN

References:
https://www.arista.com/en/support/toi/eos-4-27-2f/14920-mac-limit-per-vlan
https://www.arista.com/en/support/toi/eos-4-25-0f/14053-l2-protocol-forwarding
https://www.arista.com/en/support/toi/eos-4-24-2f/14551-flexible-interface-encapsulation-flexencap

 

L2 Transparency

In order for various types of frames/packets to be passed transparently over the service (and not CPU punted), the following is required:

! IGMP snooping can only be disabled globally:
no ip igmp snooping
!
l2-protocol
 forwarding profile FULL_TRANSPARENCY
 bfd per-link rfc-7130 forward
 e-lmi forward
 isis forward
 lacp forward
 lldp forward
 macsec forward
 pause forward
 stp forward

 

Example with VLAN Tagged Sub-Interface

In the example below, the customer facing VLAN tag (123) is stripped on ingress and the packet is send into VLAN/bridge/broadcast domain 2.

The VLAN tag on the sub-interface can be different to the internal bridge VLAN inside the router. In this case, specify the internal bridge / broadcast domain as the VLAN ID under the interface, and the VLAN to be used for tragging frames on the wire towards the customer, as the client dot1q number:

    no ip igmp snooping
    !
    l2-protocol
       forwarding profile PASS_ALL_THE_SHIT
          bfd per-link rfc-7130 forward
          e-lmi forward
          isis forward
          lacp forward
          lldp forward
          macsec forward
          pause forward
          stp forward
    !
    vlan 2
       name internal_bridge_vlan
       ! no mac address learning ! Uncomment to disable MAC learning, then all traffic is flooded!!!
    !
    interface Ethernet1.123
       vlan id 2
       !
       encapsulation vlan
          client dot1q 123
       shape rate 10000000 burst-size 1024 bytes ! egress shaper
    !
    router bgp 65535
       vlan 2 ! The Internal bridge/VLAN
          rd 65535:2
          route-target both 65535:2
          redistribute learned ! Advertise local MACs as EVPN Type 2 routes

 

By default EOS will advertise routes with an ESI of all zero's:

r1#show bgp evpn route-type mac-ip 10.0.0.201 detail 
BGP routing table information for VRF default
Router identifier 10.0.0..2, local AS number 65535
BGP routing table entry for mac-ip 0000.0000.b835 10.0.0.201, Route Distinguisher: 65535:2
 Paths: 1 available
  Local
    10.0.0.4 from 10.0.0.4 (10.0.0.4)
      Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, internal, best
      Extended Community: Route-Target-AS:65535:1 Route-Target-AS:65535:2 TunnelEncap:tunnelTypeMpls DefaultGateway EvpnMacMobility:sticky
      MPLS label: 1046284 L3 MPLS label: 116384 ESI: 0000:0000:0000:0000:0000

 

Also, by default, the Pseudowire Control Word is used, even though this is an EVPN, not a VPWS service.

Also, the internal VLAN configured on the router (in this example, VLAN 2) is inserting on all frames sent over the EVPN. The receiving end does not need to match. E.g., the receiving end might be configured as follows:


interface Ethernet10.123 vlan id 4 ! encapsulation vlan client dot1q 123 shape rate 10000000 burst-size 1024 bytes ! router bgp 65535 vlan 4 rd 65535:2 route-target both 65535:2 redistribute learned

Packets sent from PE1 to PE2 will have VLAN 2 inserted into the header stack. Packets send from PE2 to PE1 will have VLAN 4 inserted into the header stack. This means the packet is always VLAN tagged across the MPLS core. In both directions, by default, the EOS strips the outer most VLAN when receiving the packet from the MPLS core. Then the packet is passed to the sub-interface and tagged with the appropriate customer facing VLAN tag on egress. This means this is fully transparent to the customer. This local bridge/VLAN isn't signalled at the control plane level, it only exists at the data plane. When the frame is received at the egress PE this "transport" VLAN tag from the ingress PE is PoPed and the MAC address is added to the MAC table for the local bridge domain, regardless of whether the ingress PE VLAN ID matches the VLAN ID of the egress PE. This scenario where the VLAN ID is not signalled at the control plane but is included in the data plane (even though it is just popped off and ignored by the egress PE) is called "VLAN Bundle Service" in Arista terminology.

 

Labels

r3#show bgp evpn instance vlan 4
EVPN instance: VLAN 4
  Route distinguisher: 65535:2
  Route target import: Route-Target-AS:65535:2
  Route target export: Route-Target-AS:65535:2
  Service interface: VLAN-based
  Local MPLS IP address: 10.0.0.2
  VXLAN: disabled
  MPLS: enabled
  Label allocation mode: per-instance
  MAC route MPLS label: 1041533
  IMET route MPLS label: 1047448
  AD route MPLS label: 1041533