Date created: Thursday, October 8, 2015 10:12:25 AM. Last modified: Monday, November 16, 2015 4:15:05 PM

EFP Examples & Limitations

Examples of EFP configs on Cisco MEF devices like ME3600/ME3800/ASR920/ASR9000 etc

References:
https://supportforums.cisco.com/document/85231/understanding-ethernet-virtual-circuits-evc
https://supportforums.cisco.com/document/59741/asr9000xr-flexible-vlan-matching-evc-vlan-tag-rewriting-irbbvi-and-defining-l2
http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116453-technote-ios-xr-l2vpn-00.html
http://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-3_1_S/configuration/guide/3800x3600xscg/swevc.htm
https://drive.google.com/file/d/0B5Q6qCRMe89_MzRsRXduTC1BX00/view

 

Encapsulation Examples

Matching untagged, single tagged and double tagged frames and terminating them locally.

For IOS the MTU does not need to be increased from 1500 to 1504 or 1508, this is excluded from the MTU size when receiving single and double tagged frames via an EFP. For IOS-XR the MTU must be increased to accommodate the tags, like JunOS.

EFPs encapsulation types can't overlap when configuring them;

EFP 1 VLAN: S-VLAN=1000, C-VLAN_range=1-4095
EFP 2 VLAN= S-VLAN=1000, C-VLAN=2000

This isn't allowed because the more specific C-vlan is part of the range. The following options A and B are achieving the same and are allowed :

A)
EFP 1) VLAN: S-VLAN=1000, C-VLAN_range=1-1999,2001-4095
EFP 2) VLAN= S-VLAN=1000, C-VLAN=2000

B)
EFP 1) VLAN: S-VLAN=1000, C-VLAN=any
EFP 2) VLAN= S-VLAN=1000, C-VLAN=2000

On IOS-XR only, dot1q and dot1ad ethertypes can be configured on the physical interface:

As per IEEE documentation, Ethertype 8100 is for 802.1q and Ethertype 88A8 is for 802.1ad. IEEE also calls any kind of double tagging as QinQ, including dot1ad. That means that under IEEE's point of view, dot1ad = qinq. Cisco, on the other hand, calls qinq a double dot1q, where both Ethertypes (inner and outer) are 8100. Ethertype 9100 and 9200 were used as an option to differentiate the inner Ethertype form the outer Ethertype, but they are obsolete now and the standard became dot1ad (with Ethertype 88A8).

In order to configure ethertype 9100 and 9200 you have to explicitly issue the command "dot1q tunneling ethertype 0x9100" or "dot1q tunneling ethertype 0x9200" under the physical interface you are configuring:

encapsulation dot1q 10 second dot1q 20 -> inner and outer ethertype are 8100
encapsulation dot1ad 10 second dot1q 20 -> inner 8100, outer 88A8

interface GigabitEthernet0/1/0/3
dot1q tunneling ethertype [0x9100|0x9200]
!
interface GigabitEthernet0/1/0/3.13 l2transport
encapsulation dot1q 13 second-dot1q 100
! The outer tag has an Ethertype of 0x9100 or 0x9200, and the inner tag has the dot1q Ethertype 0x8100

encapsulation dot1q 10 second dot1q 20 (with ethertype 9100) -> inner 8100, outer 9100
encapsulation dot1q 10 second dot1q 20 (with ethertype 9200) -> inner 8100, outer 9200

Standard encapsultion types for IOS/IOS-XE/IOS-XR:

interface GigabitEthernet0/1
 switchport trunk allowed vlan none
 switchport mode trunk

 service instance 1 ethernet
  description Untagged frames
  encapsulation dot1q untagged
  bridge-domain 1

 service instance 10 ethernet
  description Single tagged frames
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric ! Pop the outer most tag (there could be more tags)
  bridge-domain 10

 service instance 13 ethernet
  description Frames single tagged in a specific range
  encapsulation dot1q 11-13
  bridge-domain 13 ! At this pointthe frame becomes double tagged with 13 as an outter tag and 11-13 as an inner tag

 service instance 15 ethernet
  description Tagged frames with specific CoS value
  encapsulation dot1q 15 cos 4
  rewrite ingress tag pop 1 symmetric
  bridge-domain 15

 service instance 20 ethernet
  description Frames with at least two tags, where the outer most is 20 and next is 200
  encapsulation dot1q 20 second-dot1q 200
  rewrite ingress tag pop 2 symmetric ! Pop the outer two most tags (there could be more tags)
  bridge-domain 20

 service instance 25 ethernet
  description Frames with exactly two tags, an outer tag of 20 and inner of 25
  encapsulation dot1q 20 second 25 exact
  rewrite ingress tag pop 2 symmetric
  bridge-domain 25

 service instance 30 ethernet
  description Frames with at least two VLAN tags, an outer tag of 20 and any 2nd tag value
  encapsulation dot1q 20 second any
  rewrite ingress tag pop 2 symmetric
  bridge-domain 30

 service instance 999 ethernet
  description Match all other traffic
  encapsulation dot1q default
  bridge-domain 999

An EFP can match on multiple traffic properties, not just the VLAN number.

 service instance 15 ethernet
  description Tagged frames with specific CoS value
  encapsulation dot1q 15 cos 4
  bridge-domain 15 ! Tag is pushed on
  ! Now the frame is double-tagged internally

 service instance 20 ethernet
  description IPv6 traffic only
   encapsulation dot1q 20 etype ipv6
   bridge-domain 20

The "bridge-domain" clause will bridge the EFP into a global VLAN on the device, by doing this it will also push a VLAN tag onto the frame:

! Example 1:
interface GigabitEthernet0/1
 switchport trunk allowed vlan none
 switchport mode trunk

 service instance 10 ethernet
  description Single tagged frames
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric ! Tag is PoP'ed
  bridge-domain 10 ! Tag is pushed back on
  ! Now when the frame egresses via a different port the VLAN 10 tag is present, such as a "switchport mode trunk" port, otherwise the frame would leave the switch untagged


! Example 2: A frame tagged as VLAN 100 that enters port Gi0/5 will leave port Gi0/1 with the additional tag VLAN 10 pushed on as the outter most tag with VLAN 100 as an inner tag

! A double tagged from coming into Gi0/1 with 10 outter tag and 100 inner tag will leave port 5 will only one tag, VLAN 100.

! As the traffic goes into BD 2000 and leaves it again into an EFP, the internal VLAN tag 2000 is pushed on them pop'ed off again allowing the flexibility of EFPs with varying encapsulation parameters:

interface GigabitEthernet0/5
 switchport trunk allowed vlan none
 switchport mode trunk
 !
 service instance 1 ethernet
  encapsulation dot1q 1-4094
  bridge-domain 2000
 !
interface TenGigabitEthernet0/1
 switchport trunk allowed vlan none
 switchport mode trunk
 !
 service instance 1 ethernet
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  bridge-domain 2000


! Example 3: QinQ EFP and Switchport. Traffic that enters port gi0/1 tagged in vlan 10 will leave port gi0/2 with an outter tag of 100 and innter tag of 10.

interface GigabitEthernet0/1
 description ! Customer facing UNI port
 switchport trunk allowed vlan none
 switchport mode trunk
 service instance 10 ethernet
  encapsulation dot1q 10
  bridge-domain 100

interface GigabitEthernet0/2
 description ! NNI facing port
 switchport mode trunk

 

CoS Values

CoS values are preserved when using EFPs, they can also be manipulated:

! Frame enters Gi0/14 with CoS 4, leaves Gi0/4 with CoS 4
GigabitEthernet0/14
 switchport trunk allowed vlan none
 switchport mode trunk
 service instance 1 ethernet
  encapsulation dot1q 3200
  rewrite ingress tag pop 1 symmetric
  bridge-domain 1200
 !
interface GigabitEthernet0/4
 switchport trunk allowed vlan none
 switchport mode trunk
 service instance 1 ethernet
  encapsulation dot1q 20
  rewrite ingress tag pop 1 symmetric
  bridge-domain 1200


! Example of CoS rewrite on ingress: Frame enters gi0/14 with CoS 5, is rewritten to CoS 3 then transit switch internally before leaves Gi0/4 with CoS 3
policy-map set-cos-3
 class class-default
  set cos 3

interface GigabitEthernet0/14
 switchport trunk allowed vlan none
 switchport mode trunk
 service instance 1 ethernet
  encapsulation dot1q 3200
  rewrite ingress tag pop 1 symmetric
  service-policy input set-cos-3
  bridge-domain 1200
 !
interface GigabitEthernet0/4
 switchport trunk allowed vlan none
 switchport mode trunk
 service instance 1 ethernet
  encapsulation dot1q 20
  rewrite ingress tag pop 1 symmetric
  bridge-domain 1200


! Example of CoS re-write on exit so a frame entering Gi0/14 with CoS 5 transit the switch with CoS 5 then is re-written to CoS 3 before leaving Gi0/4

policy-map set-cos-3
 class class-default
  set cos 3

policy-map set-cos-3-parent
 class vlan3200
  service-policy set-cos-3

interface GigabitEthernet0/14
 switchport trunk allowed vlan none
 switchport mode trunk
 service instance 1 ethernet
  encapsulation dot1q 3200
  bridge-domain 1200
 !
interface GigabitEthernet0/4
 switchport trunk allowed vlan none
 switchport mode trunk
 service instance 1 ethernet
  encapsulation dot1q 20
  rewrite ingress tag pop 1 symmetric
  service-policy output set-cos-3-parent
  bridge-domain 1200

Split Horizon

Inter-EFP communication for EFPs that connect to the same bridge-domain can be limited using the "split horizon" keyword so traffic ingressing an EFP can only communicate into the bridge-domain. Service instances in the same bridge domain and split-horizon group cannot forward data between each other, but can forward data between other service instances that are in the same bridge domain, but not in the same split-horizon group.

Service instances do not have to be in a split-horizon group. If a service instance does not belong to a group, it can send and receive from all ports within the bridge domain. A service instance cannot join more than one split-horizon group. VPLS core pseudowires or split-horizon enabled pseudowires are put in split horizon group 0. Therefore, EFPs in group 0 are not able to forward to or receive packets from these pseudowires. Max service-instances per group: here.


interface GigabitEthernet0/1
 switchport trunk allowed vlan none
 switchport mode trunk

 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingres tag pop 1 symmetric
  bridge-domain 10 split-horizon

 service instance 20 ethernet
  encapsulation dot1q 20
  rewrite ingress tag pop 1 symmetric
  bridge-domain 10 split-horizon

 

In IOS-XE only, the bridge-domain can be derived from the VLAN ID using trunk service instance with a range of VLANs in the encapsulation stansa, so each VLAN will bridge into a bridge-domain with the same ID:

interface GigabitEthernet0/0/0
 service instance trunk 1 ethernet
  encapsulation dot1q 1 - 5, 7, 9-12  
  bridge-domain from-encapsulation

 

Rewrite Examples

ME3600x/ME3800x/ASR920
rewrite ingress tag pop 1 symmetric  = remove the top 802.1q tag
rewrite ingress tag pop 2 symmetric  = remove the top two 802.1q tags
rewrite ingress tag translate 1-to-1 dot1q 28 symmetric = remove the top tag and replace it with 28
rewrite ingress tag translate 2-to-2 dot1 22 second-dot1q 23 = remove the top two tags and replace them with 22 and 23 (23 will be the inner tag)
rewrite ingress tag push dot1q 20 = Push an extra outer most tag on with VLAN ID 20
rewrite ingress tag push dot1q 56 second-dot1q 55  = push two new tags on top of the existing frame. The top tag will be 56; inner tag of 55

IOS-XR or 7600 with ES+ cards only:
rewrite ingress tag translate 2-to-1 dot1q 10 = Replaces a pair of tags defined in the encapsulation command with vlan-id 10
rewrite ingress tag translate 1-to-2 dot1q 10 second-dot1q 20 = Replaces the incoming tag defined by the encapsulation command by a pair of 802.1Q tags

 

l2protocol Forward Option

For ME3600X/ME3800X the l2protocol forward option causes the EVC interface to flood the untagged/tagged BPDU packets on:

-another trunk interface on the same VLAN/BD
-SVI or VFI Pseudowire
-EVCs on the same BD
-EVC on Xconnect

You can apply the l2protocol forward command to CDP, DTP, ELMI, ESMC, LACP, LLDP, LOAM, PAGP, PTPPD, STP, UDLD and VTP traffic. Layer 2 Protocol (L2PT) can forward LinkOAM, ESMC, ELMI, and other reserved MAC addresses in the IEEE range of 0180C2000000-0F to comply with CE2.O requirements.

On ME 3800X and ME 3600X switches, Layer 2 protocol tunneling is supported on EFPs, but not on switchports. This required the command "l2ptocol tunnel ...". Layer 2 protocol tunneling is not supported on cross-connect EFPs.

Limitations:

-Pause frames that use 0180C2000001 cannot be L2PT forwarded or dropped because they are consumed by the forwarding ASIC's physical registers without sending them to the CPU.
-Dot1x that uses 0180c2000003 is disabled by the Cisco ME 3800 and ME 3600 switches. This functionality is the same as in previous releases.
-L2PT tunneling for the reserved MACs is not supported since the reserved MACs do not have known link types. Reserved MACs tunneled with 0180C200000B are replaced to ensure packets egress.
-The LinkOAM, ELMI, and ESMC protocols are considered to be "L2PT peer" even if the L2PT CLI is not applied on the interface. Unlike other protocols, L2PT code assumes it to be drop. This is done to avoid L2PT peer configuration for LinkOAM, ELMI, and ESMC since these protocols previously worked without L2PT configurations.

interface GigabitEthernet0/1
 switchport trunk allowed vlan none
 switchport mode trunk

service instance 10 ethernet 
 encapsulation dot1q 10
 ! Tunnel the frames received on VLAN 10 over the SP core, which
 ! is using layer 2 it's self, by re-writing the dest MAC to a multicast MAC
 ! so the frame won't be processed by SP devices in the path. Assume
 ! This frame will leave this PE via a trunk link, which is why the tunneling
 ! is required
 l2protocol tunnel cdp stp vtp dtp pagp lacp 
 bridge domain 10

service instance 20 ethernet
  encapsulation dot1q 20
  ! Forward frames in VLAN 20 exactly as they are over an MPLS xconnect
  ! to a remote PE, including all L2 control protocol frame types
  l2protocol forward 
  xconnect 4.3.2.1 20 encapsulation mpls

service instance 1 ethernet
  encapsulation default
  ! A default catch-all EFP, if the customer is using MST betweek sites
  ! either "default" or "untagged" is required, as MST BPDUs are untagged
  ! for all instances and VLANs, so this xconnect carries MST info for all
  ! VLANs/MST instances/regions etc
  l2protocol forward
  xconnect 4.3.2.1 1 encapsulation mpls

Previous page: Track OSPF Route Metric
Next page: L2 Bridging (IRB)