Ethernet Features

This chapter describes how to configure Layer 2 (L2) Ethernet features on the Cisco Routers supporting Cisco IOS XR software.

Layer 2 Protocol Tunneling

Table 1. Feature History Table

Feature Name

Release Information

Feature Description

L2PT Support for Layer 2 Control Protocols

Release 7.9.1

This feature provides Layer 2 Protocol Tunneling (L2PT) support for the following extended protocols:

  • Link Layer Discovery Protocol (LLDP)

  • Link Aggregation Control Protocol (LACP)

  • Operation, Administration, Management (OAM)

  • Ethernet Local Management Interface (ELMI)

  • EtherChannel Port Aggregation Protocol (PAgP)

  • Unidirectional Link Detection (UDLD)

  • Multiple MAC Registration Protocol (MMRP)

  • Multiple VLAN Registration Protocol (MVRP)

Previously only CPSV (C-CDP, P-PVRST, S-STP, V -VTP) protocol set was supported for L2PT. Now with the extended protocol support, all the Layer 2 Control Protocols (L2CP) are supported with L2PT. This allows different network devices to communicate with each other, with high data security for critical applications.

This feature introduces the hw-module profile l2pt ext-protocols-enable command. You must reload the router to activate the command.

Layer 2 Protocol Tunneling

Release 7.3.1

This feature enables you to send Layer 2 protocol data over IP or other L3 networks. Support of this feature is now extended to the Cisco NCS 540 series routers.

This feature introduces the l2protocol command.

Layer 2 Protocol Tunneling (L2PT) is a Cisco proprietary protocol for tunneling Ethernet protocol frames across Layer 2 (L2) switching domains.

When an L2 protocol frame enters the interface of an L2 switching device, the switch or router performs one of these actions on the frame:

  • forward—the frame is switched or routed with no exceptional handling.

  • drop—the frame is discarded on the router.

  • terminate—the router recognizes that the frame is an L2 protocol frame, and therefore sends it to the router's control plane for protocol processing.

  • tunnel—the router encapsulates the frame to hide its identity as a protocol frame. This prevents the frame from being terminated on other routers. The opposite end of the tunnel performs a decapsulation, returning the frame to its original state.

L2PT Features

  • Tunnels these protocols:

    • Cisco Discovery Protocol (CDP)

    • Spanning Tree Protocol (STP)

    • Per VLAN Spanning Tree (PVST+)

    • Virtual Trunking Protocol (VTP)

  • Starting from Cisco IOS XR Release 7.9.1 the L2PT is enhanced to support the following extended Layer 2 Control Protocols (L2CP) for tunneling:

    • Link Layer Discovery Protocol (LLDP)

    • Link Aggregation Control Protocol (LACP)

    • Operation, Administration, Management (OAM)

    • Ethernet Local Management Interface (ELMI)

    • EtherChannel Port Aggregation Protocol (PAgP)

    • Unidirectional Link Detection (UDLD)

    • Multiple MAC Registration Protocol (MMRP)

    • Multiple VLAN Registration Protocol (MVRP)

    • 802.1X protocol

  • Supports the forwarding modes of tunneling

  • L2PT is also supported for frames with VLAN tags


Note


There are no dedicated L2PT counters. There are no L2PT-specific adjustments for QoS or other miscellaneous parameters.


Restrictions

  • Reverse tunnel isn’t supported.

  • Drop option isn’t supported.

L2PT in the Forward Mode

This topology depicts a Service Provider network (S-network).

Figure 1. L2PT in forward mode
L2PT in forward mode
  • The customer network (C-network) connects to router R1 at the GigabitEthernet subinterface 0/1/0/1.1, and to router R2 at the GigabitEthernet subinterface 0/5/0/2.1.

  • The C-network is not shown in the diagram; however, the C-network sends L2 traffic through the S-network, and the S-network switches the traffic from end to end.

  • The customer traffic also carries L2 protocol frames. The purpose of L2PT is to allow these protocol frames to pass through the S-network.

  • In forward mode, L2PT is applied to the customer facing interfaces of the S-network, R1 GigabitEthernet 0/1/0/1.1 and R2 GigabitEthernet 0/5/0/5.1.

These assumptions are made:

  • Customer traffic entering router R1 is trunked, that is all traffic is tagged. The only untagged traffic is the protocol traffic, which arrives from the customer network.

  • The Customer-facing interfaces GigabitEthernet 0/1/0/1 at router R1 and Gigabit Ethernet 0/5/0/5 at router R2 belong to the same customer. Customer-facing interfaces GigabitEthernet 0/1/0/2 at router R1 and GigabitEthernet 0/5/0/6 at router R2 belong to a different customer.

  • Traffic from different customers remain segregated.

  • Only L2 protocol traffic is sent through the customer-facing interfaces.

  • L2 protocol traffic entering the customer-facing interfaces is untagged.

  • Traffic must be L2PT encapsulated to successfully pass through the switch cloud.

The purpose of this topology is that router R1 and R2 must receive customer protocol traffic from multiple customer interfaces, and multiplex the traffic across a single service provider interface and link. At the decapsulation end, the reverse is performed. Traffic entering router R1 on the GigabitEthernet subinterface 0/1/0/1.1 exits router R2 from the GigabitEthernet subinterface 0/5/0/5.1 only while traffic entering router R1 at GigabitEthernet subinterface 0/1/0/2.1 exits router R2 from GigabitEthernet subinterface 0/5/0/6.1 only.

A protocol frame entering router R1 on GigabitEthernet interface 0/1/0/1 travels through the network in this manner:

  • The protocol frame is directed to GigabitEthernet subinterface 0/1/0/1.1, as the frame is untagged.

  • The rewrite statement with GigabitEthernet subinterface 0/1/0/1.1 causes a tag of ID 100 to be added to the frame.

  • The frame enters router R1’s bridge domain r1-bridge.

  • The bridge (r1-bridge) floods the frame to all attachment circuits (AC) on the bridge domain, except the originating AC (split horizon AC).

  • Ethernet egress filtering on GigabitEthernet subinterface 0/1/0/2.1 detects a tag ID mismatch, and drops the frame. In this way, the bridge domain’s flooded traffic is prevented from exiting other customer interfaces.

  • A flooded copy of the frame is sent to GigabitEthernet subinterface 0/1/0/3.1.

  • GigabitEthernet subinterface 0/1/0/3.1 adds a second tag.

  • The frame passes to router R2 GigabitEthernet interface 0/5/0/4 because of the L2PT encapsulation.


    Note


    The frame is now double-tagged (100 inner, 500 outer) and has the L2PT MAC DA.


  • The frame after having entered router R2 on GigabitEthernet interface 0/5/0/4 is directed to GigabitEthernet subinterface 0/5/0/4.1.

  • The outer tag ID 500 is removed by GigabitEthernet subinterface 0/5/0/4.1

  • Router R2’s bridge (r2-bridge) floods the frames to all ACs.

  • Ethernet egress filtering drops the frames on all ACs except the AC through which the frame exits.

  • As the frame exits router R2 from GigabitEthernet subinterface 0/5/0/5.1, the tag of ID 100 is removed.

  • The frame that exits router R2 from GigabitEthernet interface 0/5/0/5 is identical to the original frame that entered router R1 through GigabitEthernet interface 0/1/0/1.

L2PT Configuration Notes

Keep these points in mind while configuring L2PT:

  • The l2protocol command can be configured on either a main or L2 subinterface.

  • The l2protocol command can be configured on physical or bundle interfaces.

  • When the l2protocol and ethernet filtering commands are configured on the same interface, L2PT encapsulation occurs before ethernet filtering. This means that L2PT prevents the CDP, STP, and VTP protocol frames from being dropped by ethernet filtering.

  • When L2PT is configured with other interface features, L2PT encapsulation occurs before the processing for other interface features.

  • L2PT encapsulation and decapsulation is supported for untagged protocol frames, single-tagged, and double-tagged frames. Tag Ethertypes of 0x8100, 0x88A8, and 0x9100 are supported, however, 0x9200 is not.

Configuration Example

At R1:

!
interface GigabitEthernet0/1/0/1
 negotiation auto
!
interface GigabitEthernet0/1/0/1.1 l2transport
 encapsulation untagged
 rewrite ingress tag push dot1q 100 symmetric
 l2protocol cpsv tunnel
 !
interface GigabitEthernet0/1/0/2
 negotiation auto
!
interface GigabitEthernet0/1/0/2.1 l2transport
 encapsulation untagged
 rewrite ingress tag push dot1q 200 symmetric
!
interface GigabitEthernet0/1/0/3
 negotiation auto
!
interface GigabitEthernet0/1/0/3.1 l2transport
 encapsulation dot1q 500
 rewrite ingress tag pop 1 symmetric
 !
l2vpn
 bridge group examples
  bridge-domain r1-bridge
   interface GigabitEthernet0/1/0/1.1
   !
   interface GigabitEthernet0/1/0/2.1
!
   interface GigabitEthernet0/1/0/3.1
   !
  !
 !
!
At R2:


!
interface GigabitEthernet0/5/0/4
 negotiation auto
!
interface GigabitEthernet0/5/0/4.1 l2transport
 encapsulation dot1q 500
 rewrite ingress tag pop 1 symmetric
!
interface GigabitEthernet0/5/0/5
 negotiation auto
!
interface GigabitEthernet0/5/0/5.1 l2transport
 encapsulation untagged
 rewrite ingress tag push dot1q 100 symmetric
 l2protocol cpsv tunnel
!
interface GigabitEthernet0/5/0/6
 negotiation auto
!
interface GigabitEthernet0/5/0/6.1 l2transport
 encapsulation untagged
 rewrite ingress tag push dot1q 200 symmetric
!
l2vpn
 bridge group examples
  bridge-domain r2-bridge
   interface GigabitEthernet0/5/0/4.1
   !
   interface GigabitEthernet0/5/0/5.1
   !
   interface GigabitEthernet0/5/0/6.1
   !
  !
 !
!