L2VPN Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

PDF

L2VPN Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

Ethernet flow points

Updated: June 15, 2026

Want to summarize with AI?

Describes Ethernet Flow Point features, including classification, processing, and benefits, identifies EFP frames, outlines feature application and encapsulation modifications, provides VLAN header rewrite and configuration procedures, and explains EFP visibility and data-forwarding behavior.

An Ethernet Flow Point is a Layer 2 logical subinterface that

classifies ingress traffic with filters that match zero, one, or two VLAN tags
applies VLAN rewrite, QoS, and forwarding behavior to matching traffic, and
operates under a physical interface or a bundle interface.

The source uses these terms interchangeably: VLAN AC, L2 interface, and EFP.

Feature history

Table 1. Feature History Table
Feature Name	Release Information	Feature Description
Ethernet Flow Point	Release 26.1.1	Introduced in this release on: Centralized Systems (8400 [ASIC: K100]) (select variants only) This feature is now supported on the Cisco 8404-SYS-D routers.
Ethernet Flow Point	Release 24.4.1	Introduced in this release on: Fixed Systems (8700) (select variants only) The Ethernet Flow Point functionality is now extended to the Cisco 8712-MOD-M routers.
Ethernet Flow Point	Release 24.3.1	Introduced in this release on: Fixed Systems (8200 [ASIC: Q200, P100], 8700 [ASIC: P100])(select variants only); Modular Systems (8800 [LC ASIC: Q100, Q200, P100])(select variants only) * The Ethernet Flow Point functionality is now extended to these fixed systems and line cards: 8212-48FH-M 8711-32FH-M 88-LC1-52Y8H-EM 88-LC1-12TH24FH-E
Ethernet Flow Point	Release 24.2.11	Introduced in this release on: Modular Systems (8800 [LC ASIC: P100]) (select variants only) An Ethernet Flow Point (EFP) enhances traffic management and network efficiency by classifying and processing Layer 2 traffic under a physical or bundle interface based on specific filters, such as VLAN tags. This logical sub-interface allows for precise traffic classification and manipulation, including changing VLAN IDs, adding or removing VLAN tags, and modifying ethertypes upon ingress. This functionality is now extended to routers with the 88-LC1-36EH line cards.

Ethernet flow point features

Ethernet flow points (EFPs) are Layer 2 logical sub-interfaces for physical or bundle interfaces.
EFPs classify ingress traffic using configurable filters, called entries, based on VLAN tags (0, 1, or 2 tags).
Matching criteria:
- Single VLAN tag
- QinQ double tagging
When a packet matches an EFP filter, the EFP applies frame handling actions:
- changes VLAN IDs
- adds or removes VLAN tags
- changes Ethertypes
After classification, additional actions like frame manipulation and Quality of Service (QoS) can be applied.

Note

These terms are used interchangeably throughout this document:

VLAN AC

L2 interface

EFP

Ethernet flow point operational capabilities

Identify all frames that belong to a particular flow on a given interface.
Perform VLAN header rewrites to accommodate different service requirements.
Add features to the identified frames as required by the service.
Optionally define forwarding actions for identified frames within the data path.

Frame identification methods for an EFP

Key facts about EFP frame identification

Ethernet Flow Points (EFPs) identify frames belonging to a particular flow on a specific port by examining fields within the Ethernet frame header, independent of higher-level payload encapsulation. EFPs flexibly map frames into flows based on VLAN tags in the outer Ethernet header.

An EFP can match frames by one or two outer VLAN tags.
Frame matching is independent of encapsulation beyond the Ethernet header.
Frames cannot be matched to an EFP using information outside the outermost Ethernet frame header and its tags.

Table 2. VLAN tag identification
Encapsulation type	EFP identifier rule
Single outer-most tag	The tag must use EtherType 0x8100 or 0x88A8.
Two outer-most tags	The outer-most tag can use 0x8100, 0x9100, or 0x88A8 depending on platform or configuration, and the second outer-most tag must use 0x8100.
Unsupported match inputs	The EFP does not classify by IPv4, IPv6, or MPLS tag header data, or by C-DMAC, C-SMAC, or C-VLAN information outside the outermost Ethernet frame header and tags.

Apply features

Applied features are Layer 2 service behaviors that

apply QoS and other configured policies after a frame matches an EFP
modify VLAN header encapsulation on ingress and egress, and
use symmetric rewrite behavior for the supported actions.

For more information about QoS polices that are supported on L2 interfaces, see Modular QoS Configuration Guide for Cisco 8000 Series Routers.

Features applied after EFP matching

After the frames are matched to a particular EFP, any appropriate features can be applied. In this context, features means any frame manipulations specified by the configuration. For example, QoS. You can apply QoS policy on Layer 2 interfaces.

The Layer 2 header encapsulation modification is the Layer 2 interface VLAN tag rewrite that is applied on an EFP as part of the Ethernet infrastructure.

Encapsulation modifications for EFP

EFP supports these Layer 2 header encapsulation modifications on both ingress and egress:

Push 1 VLAN tag: push an EtherType 0x8100 or 0x88A8 VLAN tag at ingress, and pop the top VLAN tag at egress.
Push 2 VLAN tags: push an outer EtherType 0x8100 or 0x9100, depending on tunneling configuration, or 0x88A8 VLAN tag and an inner EtherType 0x8100 VLAN tag at ingress, and pop the top two VLAN tags at egress.
Pop 1 VLAN tag: pop the top VLAN tag at ingress, and push an EtherType 0x8100 VLAN tag or EtherType 0x88A8 VLAN tag at egress.
Pop 2 VLAN tags: pop the top two VLAN tags at ingress, and push an inner EtherType 0x8100 VLAN tag and an outer EtherType 0x8100 or 0x9100, depending on tunneling configuration, or 0x88A8 VLAN tag at egress.
Rewrite one or two VLAN tags, including rewriting the outer tag, rewriting the outer two tags, translating one outer tag and pushing an additional outer VLAN tag, and popping the outer tag while rewriting the second outer VLAN tag.

This modification can only pop tags that are matched as part of the EFP.

For each of the VLAN ID manipulations, you can specify EtherType 0x88A8, 0x8100, or 0x9100 depending on the tunneling configuration.

Valid ingress rewrite actions

The following notations are used for the rewrite actions mentioned in the table:

Translate 1-to-1 tag: Translates the outermost tag to another tag.
Translate 1-to-2 tags: Translates the outermost tag to two tags.
Translate 2-to-1 tags: Translates the outermost two tags to a single tag.
Translate 2-to-2 tags: Translates the outermost two tags to two other tags.

Note

Prior to Cisco IOS XR Software Release 7.8.1, the EtherType cannot be changed at 1-to-1 and 2-to-2 VLAN tag translation operations.

The following encapsulation types are supported:

encapsulation dot1q <x>
encapsulation dot1q priority-tagged (Supported from Cisco IOS XR Software Release 24.4.1 onwards)
encapsulation dot1ad <x> (Supported from Cisco IOS XR Software Release 24.4.1 onwards)
encapsulation dot1ad priority-tagged (Supported from Cisco IOS XR Software Release 24.4.1 onwards)
encapsulation dot1ad <x> dot1q <y>
encapsulation dot1q <x> second-dot1q <y> (Supported on Q200-based line cards from Cisco IOS XR Software Release 24.1.1 onwards and supported for all systems in the Cisco 8000 Series Routers from Cisco IOS XR Software Release 24.4.1 onwards.)
dot1q tunneling ethertype 0x9100 (Supported from Cisco IOS XR Software Release 24.4.1 onwards)
hw-module profile encap-exact (Supported from Cisco IOS XR Software Release 24.4.1 onwards)

The following lists the supported L2 sub-interface rewrite actions:

rewrite ingress tag push dot1q <x> symmetric
rewrite ingress tag push dot1ad <x> symmetric
rewrite ingress tag push dot1ad <x> dot1q <y> symmetric
rewrite ingress tag push dot1q <x> second-dot1q <y> symmetric (Supported on Q200-based line cards from Cisco IOS XR Software Release 24.1.1 onwards and supported for all systems in the Cisco 8000 Series Routers from Cisco IOS XR Software Release 24.4.1 onwards.)
rewrite ingress tag pop 1 symmetric
rewrite ingress tag pop 2 symmetric
rewrite ingress tag translate 1-to-1 dot1q <x> symmetric
rewrite ingress tag translate 1-to-1 dot1ad <x> symmetric
rewrite ingress tag translate 1-to-2 dot1ad <x> dot1q <y> symmetric
rewrite ingress tag translate 1-to-2 dot1q <x> second-dot1q <y> symmetric (Supported on Q200-based line cards from Cisco IOS XR Software Release 24.1.1 onwards and supported for all systems in the Cisco 8000 Series Routers from Cisco IOS XR Software Release 24.4.1 onwards.)
rewrite ingress tag translate 2-to-1 dot1q <x> symmetric
rewrite ingress tag translate 2-to-1 dot1ad <x> symmetric
rewrite ingress tag translate 2-to-2 dot1ad <x> dot1q <y> symmetric
rewrite ingress tag translate 2-to-2 dot1q <x> second-dot1q <y> symmetric (Supported on Q200-based line cards from Cisco IOS XR Software Release 24.1.1 onwards and supported for all systems in the Cisco 8000 Series Routers from Cisco IOS XR Software Release 24.4.1 onwards.)

Configure VLAN header rewrite on Layer 2 subinterfaces

Enable VLAN header rewrite for single-tagged or double-tagged Layer 2 subinterfaces.

This task allows you to adjust the VLAN headers on ingress frames, ensuring that Layer 2 services meet network design requirements through precise encapsulation and rewrite actions. Typical scenarios include mapping single- or double-tagged frames to specific service instances.

Before you begin

Create the subinterface and decide which ingress rewrite action is required.

Procedure

Create the Layer 2 subinterface and define encapsulation.

Example:

Router# configure
Router(config)# interface HundredGigE 0/0/0/0.1 l2transport
Router(config-subif)# encapsulation dot1q 10

Apply the required rewrite behavior.

Example:

Router(config-subif)# rewrite ingress tag push dot1q 20 symmetric
Router(config-subif)# rewrite ingress tag pop 1 symmetric
Router(config-subif)# rewrite ingress tag translate 1-to-1 dot1q 20 symmetric

For double-tagged services:

interface HundredGigE0/0/0/0.1 l2transport
 encapsulation dot1ad 2 dot1q 1
  rewrite ingress tag pop 2 symmetric
 !
!

interface HundredGigE0/0/0/0.1 l2transport
 encapsulation dot1ad 2 dot1q 1
  rewrite ingress tag translate 1-to-2 dot1ad 2 dot1q 1 symmetric
 !
!

Commit the configuration and review the running configuration.

Example:

Router(config-subif)# commit

The running configuration for the double-tagged examples:

/* Configuration without rewrite */
interface HundredGigE0/0/0/0.1 l2transport
 encapsulation dot1ad 2 dot1q 1
 !
!

/* Configuration with rewrite */

/* POP 2 */
interface HundredGigE0/0/0/0.1 l2transport
 encapsulation dot1ad 2 dot1q 1
  rewrite ingress tag pop 2 symmetric
 !
!

/* TRANSLATE 1-2 */
interface HundredGigE0/0/0/0.1 l2transport
 encapsulation dot1ad 2 dot1q 1
  rewrite ingress tag translate 1-to-2 dot1ad 2 dot1q 1 symmetric
 !
!

Data-forwarding behaviors

A data-forwarding behaviour is a Layer 2 service forwarding method that

uses the EFP to identify the frames that belong to a specific Ethernet flow
maps those frames to a bridge domain for switching by destination MAC address, and
supports multipoint Ethernet-to-Ethernet bridging services.

Forwarding cases for EFP

The EFP can be used to designate the frames belonging to a particular Ethernet flow forwarded in the data path. These forwarding cases are supported for EFPs in Cisco IOS XR software.

Layer 2 switched service (bridging): The EFP is mapped to a bridge domain, where frames are switched based on their destination MAC address.
Multipoint Ethernet-to-Ethernet bridging: Frames are forwarded across multiple Ethernet segments in a multipoint configuration.

Ethernet flow point visibility

Ethernet flow point visibility is an operational capability that

allows multiple VLAN-based service instances to coexist within the same bridge domain
uses one or two VLAN tags to identify each EFP service instance, and
lets you add multiple EFPs within a bridge group regardless of the number of available ports.

EFP visibility fundamentals

EFP visibility enables you to configure multiple VLANs in the same bridge domain by providing these features:

Multiple VLANs in a bridge domain: Allows you to configure more than one VLAN within a single bridge-domain for flexible service delivery.
Ethernet Flow Point (EFP) service instances: Logical interfaces that connect a bridge domain to a physical port or EtherChannel group. EFPs are identified using one or two VLAN tags.
Flexible EFP addition: Supports adding multiple EFPs to one bridge group, regardless of the number of available ports, allowing for expanded networking capabilities.

Configure Ethernet flow point interfaces

Use this task to configure VLAN interfaces under bridge domains by using multiple EFPs.

This example shows how to configure VLAN interfaces under a bridge domain with multiple EFPs. To configure an EFP, the source explicitly uses three interface configuration commands:

l2transport to identify the interface as an EFP
encapsulation to define VLAN matching criteria
rewrite to define VLAN tag rewrite criteria

Before you begin

Know which VLAN IDs map to each EFP and which EFPs belong to each bridge domain.

Procedure

	1.	Create the EFP interfaces and configure VLAN matching. Example: `Router# configure Router(config)# interface HundredGigE0/0/0/4.1 l2transport Router(config-subif)# encapsulation dot1q 1 Router(config-subif)# rewrite ingress tag pop 1 symmetric Router(config-subif)# exit` Repeat the source sequence for the other EFPs: Router(config)# interface HundredGigE0/0/0/4.2 l2transport Router(config-subif)# encapsulation dot1q 2 Router(config-subif)# rewrite ingress tag pop 1 symmetric Router(config-subif)# exit Router(config)# interface HundredGigE0/0/0/5.1 l2transport Router(config-subif)# encapsulation dot1q 3 Router(config-subif)# rewrite ingress tag pop 1 symmetric Router(config-subif)# exit Router(config)# interface HundredGigE0/0/0/5.2 l2transport Router(config-subif)# encapsulation dot1q 4 Router(config-subif)# rewrite ingress tag pop 1 symmetric Router(config-subif)# exit
	2.	Create the first bridge domain and add the required EFP interfaces. Example: `Router(config)# l2vpn Router(config-l2vpn)# bridge group bg1 Router(config-l2vpn-bg)# bridge-domain bd1 Router(config-l2vpn-bg-bd)# interface HundredGigE0/0/0/4.1 Router(config-l2vpn-bg-bd-ac)# exit Router(config-l2vpn-bg-bd)# interface HundredGigE0/0/0/5.1 Router(config-l2vpn-bg-bd-ac)# exit`
	3.	Create the second bridge domain and add the remaining EFP interfaces. Example: `Router(config-l2vpn-bg-bd)# exit Router(config-l2vpn-bg)# exit Router(config-l2vpn)# bridge group bg2 Router(config-l2vpn-bg)# bridge-domain bd2 Router(config-l2vpn-bg-bd)# interface HundredGigE0/0/0/4.2 Router(config-l2vpn-bg-bd-ac)# exit Router(config-l2vpn-bg-bd)# interface HundredGigE0/0/0/5.2`
	4.	Commit the configuration. Example: `Router(config-l2vpn-bg-bd-ac)# commit`
	5.	Use the show interfaces HundredGigE0/0/0/4.2 to verify the interface and bridge-domain state. Example: Router# show interfaces HundredGigE0/0/0/4.2 HundredGigE0/0/0/4.2 is up, line protocol is up Interface state transitions: 101 Hardware is VLAN sub-interface(s), address is c4b2.39da.1620 Layer 2 Transport Mode MTU 1518 bytes, BW 100000000 Kbit (Max: 100000000 Kbit) reliability Unknown, txload Unknown, rxload Unknown Encapsulation 802.1Q Virtual LAN, Outer Match: Dot1Q VLAN 2 Ethertype Any, MAC Match src any, dest any loopback not set, Last link flapped 2d10h Last input 00:00:00, output 00:00:00 Last clearing of "show interface" counters 3d18h 21364536641 packets input, 2734660346522 bytes 0 input drops, 0 queue drops, 0 input errors 8420820982 packets output, 1077864630044 bytes 0 output drops, 0 queue drops, 0 output errors Router# show l2vpn bridge-domain summary Number of groups: 2, VLAN switches: 0 Number of bridge-domains: 510, Up: 510, Shutdown: 0, Partially- programmed: 0 Default: 510, pbb-edge: 0, pbb-core: 0 Number of ACs: 1530 Up: 1275, Down: 255, Partially-programmed: 0 Number of PWs: 0 Up: 0, Down: 0, Standby: 0, Partially-programmed: 0 Number of P2MP PWs: 0, Up: 0, Down: 0, other-state: 0 Number of VNIs: 0, Up: 0, Down: 0, Unresolved: 0

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.