Transparent Layer 2 protocol tunneling

Updated: June 15, 2026

Want to summarize with AI?

Describes Transparent Layer 2 protocol tunneling, detailing requirements for deployment, supported protocols, protocol handling processes, and provides instructions to verify tunneling functionality in network environments.

Transparent Layer 2 protocol tunneling is a Layer 2 service that

tunnels Layer 2 protocol data units (PDUs) across the core network without being interpreted and processed by intermediary network devices
forwards any packet on the L2 network without any change, and
is enabled by default.

Feature History Table

Table 1. Feature History Table
Feature Name	Release Information	Feature Description
Transparent Layer 2 Protocol Tunneling	Release 25.1.1	Introduced in this release on: Fixed Systems (8010 [ASIC: A100])(select variants only) This feature is supported on Cisco 8011-4G24Y4H-I routers.
Transparent Layer 2 Protocol Tunneling	Release 24.4.1	Introduced in this release on: Fixed Systems (8200, 8700); Modular Systems (8800 [LC ASIC: P100]) (select variants only) The Layer 2 protocol tunneling functionality is now extended to: 8212-48FH-M 8711-32FH-M 88-LC1-52Y8H-EM 88-LC1-12TH24FH-E 88-LC1-36EH 8712-MOD-M
Transparent Layer 2 Protocol Tunneling	Release 7.3.2	This feature allows Layer 2 protocol data units (PDUs) to be kept intact and delivered across the service-provider network to the other side of the customer network. Such delivery is transparent because the VLAN and Layer 2 protocol configurations are maintained throughout. With this feature, service providers can send traffic from multiple customers across a core network without impacting the traffic of other customers. This feature is enabled by default.

Requirements for transparent Layer 2 protocol tunneling

Follow these requirements to ensure transparent Layer 2 protocol tunneling operates correctly:

Configure supported protocols only on main and bundle interfaces.
To punt specific protocol packets over bundle members or subinterfaces, enable the protocol on the main interface as well.
For CFM and PVRST protocols, enable these protocols on a subinterface.

Supported protocols for transparent Layer 2 protocol tunneling

Transparent Layer 2 protocol tunneling supports these protocols:

Link Layer Discovery Protocol (LLDP) and Cisco Discovery Protocol (CDP)
Multiple Spanning Tree Protocol (MSTP)
Per-VLAN Rapid Spanning Tree (PVRST)
Connectivity Fault Management (CFM)
Link Aggregation Control Protocol (LACP)
Operation, Administration, Management (OAM)
Synchronized Ethernet (SyncE)
MAC security
Priority Flow Control (PAUSE)

All packets on PW VPLS or VPWS are always tunnelled and no packet is sent to the CPU for processing (punted).

Protocol handling for transparent Layer 2 protocol tunneling

This table provides details on how the router treats Layer 2 protocol traffic when specific protocols are enabled or disabled on an interface.


L2 Protocol	Untagged Packet	Tagged Packet
Cisco Protocols	If Cisco protocols are enabled on the physical port, the traffic is sent to the CPU for processing. If Cisco protocols are disabled, the traffic is tunneled.	Traffic is always tunneled.
LLDP	If this protocol is enabled on the physical port, the traffic is sent to the CPU for processing. If this protocol is disabled, the traffic is tunneled.	Traffic is always tunneled.
PVRST/PVRST+	If this protocol is enabled on the main port, the traffic is sent to the CPU for processing. If this protocol is disabled, the traffic is tunneled.	If this protocol is enabled on the subinterface, the traffic is sent to CPU for processing. If it is disabled, the traffic is tunneled.
MSTP	If this protocol is enabled on the physical port, the traffic is sent to the CPU for processing. If this protocol is disabled, the traffic is tunneled.	Traffic is always tunneled.
CFM	If this protocol is enabled on the physical port, the traffic is sent to the CPU for processing. If this protocol is disabled, the traffic is tunneled.	If this protocol is enabled on the Xconnect, the traffic is sent to CPU for processing. If it is disabled, the traffic is tunneled.
LACP/SyncE/LOAM	If this protocol is enabled on the physical port, the traffic is sent to the CPU for processing. If this protocol is disabled, the traffic is tunneled.	Traffic is always tunneled.
PFC	If this protocol is enabled on the physical port, the traffic is sent to the CPU for processing. If this protocol is disabled, the traffic is tunneled.	Traffic is always tunneled.

Verify transparent Layer 2 protocol tunneling

Determine which protocols are enabled for each interface and whether Layer 2 packets are flooded or forwarded by the network processing unit (NPU).

Transparent protocol tunneling is always enabled by default and cannot be disabled. This task helps you check protocol state and traffic handling for Layer 2 interfaces.

Procedure

Use the show ofa objects ethport base location 0/1/CPU0 command to display the protocols that are enabled per interface.

Example:

Router# show ofa objects ethport base location 0/1/CPU0
ethport element 0 (hdl:0x308f38e360):
  base
  |-- dpd_slf -   pending(cr/up/dl):0/0/0, sibling:0x3093b811c8, child:2, num_parents:3, parent-trans_id:1523, visits:0
   color_mask:0, last_bwalk_id:0 num_bwalks_started:0
  |-- keylen - 4
  |-- trans_id - 489153
  |-- create_trans_id - 1523
  |-- obj_handle - 0x308f38e360
  |-- flag - 10
  |-- reason - 0
  |-- table_operation - 6
  |-- total_obj_size - 632
  |-- idempotent - 0
  |-- inflight - 0
  |-- table_prop - jid=169 mtime=(GMT)2021.Jan.09 13:05:46.670570
  |--  (cont'd)  - replayed=0times
  `-+ npu_results
    |-- npu0 - 0:Success
    |-- npu1 - 0:Success
    |-- npu2 - 0:Success
    `-- npu3 - 0:Success
  ofa_npu_mask_t npu_mask =>
...
  ofa_bool_t remote_chain_in_use => TRUE
  ofa_bool_t local_chain_in_use => TRUE
  uint8_t copc_profile => 0
  ofa_bool_t lldp_enable => FALSE
  ofa_bool_t slow_proto_enable => FALSE
  ofa_bool_t cdp_enable => (not set)
  ofa_bool_t pvrst_enable => FALSE
  ofa_bool_t mstp_enable => FALSE
  ofa_bool_t macsec_enable => FALSE
  ofa_bool_t mka_enable => FALSE
  ofa_bool_t pfc_enable => FALSE
  ofa_bool_t cfm_enable => FALSE
  dpa_npu_mask_t npu_bmap => (not set)

Use the show ofa objects l2if base location 0/1/CPU0 command to display the enabled protocol state for the Layer 2 interface.

Example:

Router# show ofa objects l2if base location 0/1/CPU0
l2if element 0 (hdl:0x3094ba70a8):
  base
  |-- dpd_slf -   pending(cr/up/dl):0/0/0, sibling:0x308f8087c8, child:1, num_parents:1, visits:0
   color_mask:0, last_bwalk_id:0 num_bwalks_started:0
  |-- flag - 10
      |-- flag.is_id_alloced - 0x1
  |-- keylen - 4
  |-- trans_id - 18311
  |-- create_trans_id - 18299
  |-- obj_handle - 0x3094ba70a8
  |-- obj_rc - 0x0
  |-- reason - 0
  |-- table_operation - 6
  |-- total_obj_size - 776
  |-- idempotent - 1
  |-- inflight - 0
  |-- table_prop - jid=137 mtime=(GMT)2021.Jun.21 14:53:56.644917
  |--  (cont'd)  - replayed=0times
  `-- obj_rc - 0:Success
  ofa_npu_mask_t npu_mask => 0 (not set)
  uint32_t member_count => 1
 @dpa_intf_t intf => 0x0f00000a
...
ofa_l2vpn_fwd_state_type fwd_state => (not set)
  ofa_bool_t cfm_enable => FALSE
  ofa_bool_t pvrst_enable => TRUE
  dpa_npu_mask_t npu_bmap => 1

Look at the interface counters to verify whether the L2 packet is flooded or forwarded by NPU.

In case of flood, like multicast MAC, you will notice an increment in the output counters of the interface. When the traffic is forwarded with unicast MAC, you will notice an increment in the output counters only on the egress interface.

The following output displays the interface counters:

Example:

Router# show interface hundredGigE 0/0/2/0 accounting

HundredGigE0/0/2/0
  Protocol              Pkts In         Chars In     Pkts Out        Chars Out
  CDP                         0                0       163608         21923472

You can identify which protocols are enabled and determine whether the traffic is flooded or forwarded on the interface.

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.