Configure Virtual LANs in Layer 2 VPNs

The Layer 2 Virtual Private Network (L2VPN) feature enables Service Providers (SPs) to provide L2 services to geographically disparate customer sites.

A virtual local area network (VLAN) is a group of devices on one or more LANs that are configured so that they can communicate as if they were attached to the same wire, when in fact they are located on a number of different LAN segments. The IEEE's 802.1Q specification establishes a standard method for inserting VLAN membership information into Ethernet frames.

VLANs are very useful for user and host management, bandwidth allocation, and resource optimization. Using VLANs addresses the problem of breaking large networks into smaller parts so that broadcast and multicast traffic does not consume more bandwidth than necessary. VLANs also provide a higher level of security between segments of internal networks.

The 802.1Q specification establishes a standard method for inserting VLAN membership information into Ethernet frames. Cisco IOS XR software supports VLAN sub-interface configuration on Gigabit Ethernet and 10-Gigabit Ethernet interfaces.

The configuration model for configuring VLAN Attachment Circuits (ACs) is similar to the model used for configuring basic VLANs, where the user first creates a VLAN sub-interface, and then configures that VLAN in sub-interface configuration mode. To create an Attachment Circuit, you need to include the l2transport keyword in the interface command string to specify that the interface is a L2 interface.

VLAN ACs support the following modes of L2VPN operation:

  • Basic Dot1Q Attachment Circuit—The Attachment Circuit covers all frames that are received and sent with a specific VLAN tag.

  • QinQ Attachment Circuit—The Attachment Circuit covers all frames received and sent with a specific outer VLAN tag and a specific inner VLAN tag. QinQ is an extension to Dot1Q that uses a stack of two tags.

Each VLAN on a CE-to-PE link can be configured as a separate L2VPN connection (using either VC type 4 or VC type 5).

Restrictions and Limitations

To configure VLANs for Layer 2 VPNs, the following restrictions are applicable.

  • In a point-to-point connection, the two Attachment Circuits do not have to be of the same type. For example, a port mode Ethernet Attachment Circuit can be connected to a Dot1Q Ethernet Attachment Circuit.

  • Pseudowires can run in VLAN mode or in port mode. A pseudowire running in VLAN mode always carries Dot1Q or Dot1ad tag(s), while a pseudowire running in port mode may or may NOT carry tags. To connect these different types of circuits, popping, pushing, and rewriting tags is required.

  • The Attachment Circuits on either side of an MPLS pseudowire can be of different types. In this case, the appropriate conversion is carried out at one or both ends of the Attachment Circuit to pseudowire connection.

  • You can program a maximum number of 16 virtual MAC addresses on your router.

Configure VLAN Sub-Interfaces

Sub-interfaces are logical interfaces created on a hardware interface. These software-defined interfaces allow for segregation of traffic into separate logical channels on a single hardware interface as well as allowing for better utilization of the available bandwidth on the physical interface.

Sub-interfaces are distinguished from one another by adding an extension on the end of the interface name and designation. For instance, the Ethernet sub-interface 23 on the physical interface designated TenGigE 0/1/0/0 would be indicated by TenGigE 0/1/0/0.23.

Before a sub-interface is allowed to pass traffic, it must have a valid tagging protocol encapsulation and VLAN identifier assigned. All Ethernet sub-interfaces always default to the 802.1Q VLAN encapsulation. However, the VLAN identifier must be explicitly defined.

The sub-interface Maximum Transmission Unit (MTU) is inherited from the physical interface with 4 bytes allowed for the 802.1Q VLAN tag.

The following modes of VLAN sub-interface configuration are supported:

  • Basic dot1q Attachment Circuit

  • Q-in-Q Attachment Circuit

To configure a basic dot1q Attachment Circuit, use this encapsulation mode:

encapsulation dot1q vlan extra-id

To configure a basic dot1ad Attachment Circuit, use this encapsulation mode:

encapsulation dot1ad vlan-id

To configure a Q-in-Q Attachment Circuit, use the following encapsulation modes:

  • encapsulation dot1q vlan-id second-dot1q vlan-id

  • encapsulation dot1ad vlan-id dot1q vlan-id

Restrictions and Limitations

To configure VLAN sub-interface, the following restrictions are applicable.

  • For double tagged packet, the VLAN range is supported only on the inner tag.

  • VLAN list is not supported.

    VLANs separated by comma are called a VLAN list. See the example below.

    
    Router(config)#interface tenGigE 0/0/0/2.0 l2transport 
    Router(config-subif)#encapsulation dot1q 1,2  >> VLAN range with comma 
    Router(config-subif)#commit
  • If 0x9100/0x9200 is configured as tunneling ether-type, then dot1ad (0x88a8) encapsulation is not supported.

  • If any sub-interface is already configured under a main interface, modifying the tunneling ether-type is not supported.

  • You can program a maximum number of 16 virtual MAC addresses on your router.

  • Following limitations are applicable to both outer and inner VLAN ranges:

    • 32 unique VLAN ranges are supported per system.

    • The overlap between outer VLAN ranges on sub-interfaces of the same Network Processor Unit (NPU) is not supported. A sub-interface with a single VLAN tag that falls into a range configured on another sub-interface of the same NPU is also considered an overlap.

    • The overlap between inner VLAN ranges on sub-interfaces of the same NPU is not supported.

    • Range 'any' does not result in explicit programming of a VLAN range in hardware and therefore does not count against the configured ranges.

Configuration Example

Configuring VLAN sub-interface involves:

  • Creating a Ten Gigabit Ethernet sub-interface

  • Enabling L2 transport mode on the interface

  • Defining the matching criteria (encapsulation mode) to be used in order to map ingress frames on an interface to the appropriate service instance

Configuration of Basic dot1q Attachment Circuit



Router# configure
Router(config)# interface TenGigE 0/0/0/10.1 l2transport
Router(config-if)# encapsulation dot1q 10
Router(config-if)# no shutdown

Running Configuration


configure
 interface TenGigE 0/0/0/10.1
  l2transport
  encapsulation dot1q 10
 !
!

Verification

Verify that the VLAN sub-interface is active:


router# show interfaces TenGigE 0/0/0/10.1

...
TenGigE0/0/0/10.1 is up, line protocol is up 
  Interface state transitions: 1
  Hardware is VLAN sub-interface(s), address is 0011.1aac.a05a
  Layer 2 Transport Mode
  MTU 1518 bytes, BW 10000000 Kbit (Max: 10000000 Kbit)
     reliability Unknown, txload Unknown, rxload Unknown
  Encapsulation 802.1Q Virtual LAN,
    Outer Match: Dot1Q VLAN 10
    Ethertype Any, MAC Match src any, dest any
  loopback not set,
...

Associated Commands

Introduction to Ethernet Flow Point

An Ethernet Flow Point (EFP) is a Layer 2 logical sub-interface used to classify traffic under a physical or a bundle interface. An EFP is defined by a set of filters ( a set of entries) that are applied to all the ingress traffic to classify the frames that belong to a particular EFP. Each entry usually contains 0, 1 or 2 VLAN tags. You can specify a VLAN or QinQ tagging to match against on ingress. A packet that starts with the same tags as an entry in the filter is said to match the filter; if the start of the packet does not correspond to any entry in the filter, then the packet does not match the filter.

All traffic on ingress are processed by that EFP if a match occurs, and this can in turn change VLAN IDs, add or remove VLAN tags, and change ethertypes. After the frames are matched to a particular EFP, any appropriate feature (such as, any frame manipulations specified by the configuration as well as things such as QoS and ACLs) can be applied.

The benefits of EFP include:

  • Identifying all frames that belong to a particular flow on a given interface

  • Performing VLAN header rewrites

    (See, Configure VLAN Header Rewrite)

  • Adding features to the identified frames

  • Optionally defining how to forward the identified frames in the data path

Limitations of EFP

Egress EFP filtering is not supported on Cisco IOS XR.

Identify Frames of an EFP

The EFP identifies frames belonging to a particular flow on a given port, independent of their Ethernet encapsulation. An EFP can flexibly map frames into a flow or EFP based on the fields in the frame header. The frames can be matched to an EFP using VLAN tag(s).

The frames cannot be matched to an EFP through this:

  • Any information outside the outermost Ethernet frame header and its associated tags such as

    • IPv4, IPv6, or MPLS tag header data

    • C-DMAC, C-SMAC, or C-VLAN

VLAN Tag Identification

Below table describes the different encapsulation types and the EFP identifier corresponding to each.

Encapsulation Type EFP Identifier

Single tagged frames

802.1Q customer-tagged Ethernet frames

Double tagged frames

802.1Q (ethertype 0x8100) double tagged frames

802.1ad (ethertype 0x88a8) double tagged frames

You can use wildcards while defining frames that map to a given EFP. EFPs can distinguish flows based on a single VLAN tag, a stack of VLAN tags or a combination of both (VLAN stack with wildcards). It provides the EFP model, a flexibility of being encapsulation agnostic, and allows it to be extensible as new tagging or tunneling schemes are added.

Apply Features

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 as well as things such as QoS and ACLs. The Ethernet infrastructure provides an appropriate interface to allow the feature owners to apply their features to an EFP. Hence, IM interface handles are used to represent EFPs, allowing feature owners to manage their features on EFPs in the same way the features are managed on regular interfaces or sub-interfaces.

The only L2 features that can be applied on an EFP that is part of the Ethernet infrastructure are the L2 header encapsulation modifications. The L2 features are described in this section.

Encapsulation Modifications

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

  • Push 1 or 2 VLAN tags

  • Pop 1 or 2 VLAN tags


Note

This modification can only pop tags that are matched as part of the EFP.
  • Rewrite 1 or 2 VLAN tags:
    • Rewrite outer tag
    • Rewrite outer 2 tags
    • Rewrite outer tag and push an additional tag
    • Rewrite outer tag and pop inner tag

    For each of the VLAN ID manipulations, these can be specified:

  • The VLAN tag type, that is, C-VLAN, S-VLAN, or I-TAG. The ethertype of the 802.1Q C-VLAN tag is defined by the dot1q tunneling type command.

  • The VLAN ID. 0 can be specified for an outer VLAN tag to generate a priority-tagged frame.


Note

For tag rewrites, the CoS bits from the previous tag should be preserved in the same way as the DEI bit for 802.1ad encapsulated frames.

Define Data-Forwarding Behavior

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:

  • L2 Switched Service (Bridging)—The EFP is mapped to a bridge domain, where frames are switched based on their destination MAC address. This includes multipoint services:
    • Ethernet to Ethernet Bridging
    • Multipoint Layer 2 Services
  • L2 Stitched Service (AC to AC xconnect)—This covers point-to-point L2 associations that are statically established and do not require a MAC address lookup.
    • Ethernet to Ethernet Local Switching—The EFP is mapped to an S-VLAN either on the same port or on another port. The S-VLANs can be identical or different.
  • Tunneled Service (xconnect)—The EFP is mapped to a Layer 3 tunnel. This covers point-to-point services, such as EoMPLS.

Configure VLAN Header Rewrite

EFP supports the following VLAN header rewrites on both ingress and egress ports:

  • Push 1 VLAN tag

  • Pop 1 VLAN tag


    Note

    This rewrite can only pop tags that are matched as part of the EFP.
  • Translate 1 or 2 VLAN tags:
    • 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 tag: Translates the outermost two tags to a single tag

    • Translate 2-to-2 tags: Translates the outermost two tags to two other tags

Various combinations of ingress, egress VLAN rewrites with corresponding tag actions during ingress and egress VLAN translation, are listed in the following sections:

Configuration Example

This topic covers VLAN header rewrites on various attachment circuits, such as:
  • L2 single-tagged sub-interface

  • L2 double-tagged sub-interface

Configuring VLAN header rewrite involves:

  • Creating a TenGigabit Ethernet sub-interface

  • Enabling L2 transport mode on the interface

  • Defining the matching criteria (encapsulation mode) to be used in order to map single-tagged frames ingress on an interface to the appropriate service instance

  • Specifying the encapsulation adjustment that is to be performed on the ingress frame

Configuration of VLAN Header Rewrite (single-tagged sub-interface)


Router# configure
Router(config)# interface TenGigE 0/0/0/10.1 l2transport
Router(config-if)# encapsulation dot1q 10 
Router(config-if)# rewrite ingress tag push dot1q 20 symmteric

Running Configuration


/* Configuration without rewrite */

configure
 interface TenGigE0/0/0/0.1 l2transport
  encapsulation dot1q 10 
 !
!

/* Configuration with rewrite */

/* PUSH 1 */
interface TenGigE0/0/0/0.1 l2transport
 encapsulation dot1q 10
 rewrite ingress tag push dot1q 20 symmteric
 !
!

/* POP 1 */
interface TenGigE0/0/0/0.1 l2transport
 encapsulation dot1q 10
  rewrite ingress tag pop 1
 !
!

/* TRANSLATE 1-1 */

interface TenGigE0/0/0/0.1 l2transport
 encapsulation dot1q 10
  rewrite ingress tag translate 1-to-1 dot1q 20
 !
!

/* TRANSLATE 1-2 */

interface TenGigE0/0/0/0.1 l2transport
 encapsulation dot1q 10
  rewrite ingress tag translate 1-to-2 dot1q 20 second-dot1q 30
 !
!

Running Configuration (VLAN header rewrite on double-tagged sub-interface)


/* Configuration without rewrite */

interface TenGigE0/0/0/0.1 l2transport
 encapsulation dot1q 10 second-dot1q 11
 !
!

/* Configuration with rewrite */

/* PUSH 1 */
interface TenGigE0/0/0/0.1 l2transport
 encapsulation dot1q 10 second-dot1q 11
  rewrite ingress tag push dot1q 20 symmteric
 !
!

/* TRANSLATE 1-1 */

interface TenGigE0/0/0/0.1 l2transport
 encapsulation dot1q 10 second-dot1q 11
  rewrite ingress tag translate 1-to-1 dot1q 20
 !
!

/* TRANSLATE 1-2 */

interface TenGigE0/0/0/0.1 l2transport
 encapsulation dot1q 10 second-dot1q 11
  rewrite ingress tag translate 1-to-2 dot1q 20 second-dot1q 30
 !
!

/* TRANSLATE 2-1 */
interface TenGigE0/0/0/0.1 l2transport
encapsulation dot1q 10 second-dot1q 11
rewrite ingress tag translate 2-to-1 dot1q 20

/* TRANSLATE 2-2 */

interface TenGigE0/0/0/0.1 l2transport
 encapsulation dot1q 10 second-dot1q 11
  rewrite ingress tag translate 2-to-2 dot1q 20 second-dot1q 30
 !
!

Associated Commands

Valid Ingress Rewrite Actions

Table 1. Valid Ingress Rewrite Actions

Interface Configuration

Ingress Rewrite Action

dot1q

No rewrite

dot1q

Pop 1

dot1q

Push 1

dot1q

Push 2

dot1q

Translate 1 to 1

dot1q

Translate 1 to 2

QinQ

No rewrite

QinQ

Pop 1

QinQ

Push 1

QinQ

Translate 1 to 1

QinQ

Translate 1 to 2

QinQ

Translate 2 to 1

Untagged

No rewrite

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.

Valid Ingress-Egress Rewrite Combinations

Table 2. Valid Ingress-Egress Rewrite Combinations

Ingress Interface Configuration

Ingress Interface Rewrite Action

Egress Interface Configuration

Egress Interface Rewrite Action

dot1q

No rewrite

dot1q

No rewrite

dot1q

No rewrite

dot1q

Pop 1

dot1q

No rewrite

dot1q

Push 1

dot1q

No rewrite

dot1q

Translate 1-to-1

dot1q

Pop 1

dot1q

No rewrite

dot1q

Pop 1

dot1q

Pop 1

dot1q

Push 1

dot1q

No rewrite

dot1q

Push 1

dot1q

Push 1

dot1q

Push 1

dot1q

Push 2

dot1q

Push 1

dot1q

Translate 1-to-1

dot1q

Push 1

dot1q

Translate 1-to-2

dot1q

Push 2 / Translate 1-to-2

dot1q

Push 1

dot1q

Push 2 / Translate 1-to-2

dot1q

Push 2

dot1q

Push 2 / Translate 1-to-2

dot1q

Translate 1-to-2

dot1q

Translate 1-to-1

dot1q

No rewrite

dot1q

Translate 1-to-1

dot1q

Push 1

dot1q

Translate 1-to-1

dot1q

Translate 1-to-1

dot1q

No rewrite / Translate 1-to-1

QinQ

No rewrite

dot1q

No rewrite / Translate 1-to-1

QinQ

Pop 1

dot1q

No rewrite / Translate 1-to-1

QinQ

Push 1

dot1q

No rewrite / Translate 1-to-1

QinQ

Translate 1-to-1

dot1q

Pop 1

QinQ

No rewrite

dot1q

Pop 1

QinQ

Pop 1

dot1q

Push 1

QinQ

No rewrite

dot1q

Push 1

QinQ

Pop 1

dot1q

Push 1

QinQ

Push 1

dot1q

Push 1

QinQ

Translate 1-to-1

dot1q

Push 1

QinQ

Translate 1-to-2

dot1q

Push 1

QinQ

Translate 2-to-2

dot1q

Push 2 / Translate 1-to-2

QinQ

No rewrite

dot1q

Push 2 / Translate 1-to-2

QinQ

Push 1

dot1q

Push 2 / Translate 1-to-2

QinQ

Translate 1-to-1

dot1q

Push 2 / Translate 1-to-2

QinQ

Translate 1-to-2

dot1q

Push 2 / Translate 1-to-2

QinQ

Translate 2-to-2

dot1q

No rewrite

Untagged

No rewrite

dot1q

Pop 1

Untagged

No rewrite

dot1q

Push 1

Untagged

No rewrite

dot1q

Push 1

Untagged

No rewrite

dot1q

Push 2

Untagged

No rewrite

dot1q

Translate 1-to-1

Untagged

No rewrite

dot1q

Translate 1-to-2

Untagged

No rewrite

QinQ

No rewrite / push 1 / Translate 1-to-1

QinQ

No rewrite

QinQ

No rewrite / push 1 / Translate 1-to-1

QinQ

Pop 1

QinQ

No rewrite / push 1 / Translate 1-to-1

QinQ

Push 1

QinQ

No rewrite / push 1 / Translate 1-to-1

QinQ

Translate 1-to-1

QinQ

No rewrite / push 1 / Translate 1-to-1

QinQ

Translate 1-to-2

QinQ

No rewrite / push 1 / Translate 1-to-1

QinQ

Translate 2-to-2

QinQ

Pop 1

QinQ

No rewrite

QinQ

Pop 1

QinQ

Pop 1

QinQ

Pop 1

QinQ

Push 1

QinQ

Pop 1

QinQ

Translate 1-to-1

QinQ

Translate 1-to-2 / Translate 2-to-2

QinQ

No rewrite

QinQ

Translate 1-to-2 / Translate 2-to-2

QinQ

Push 1

QinQ

Translate 1-to-2 / Translate 2-to-2

QinQ

Translate 1-to-1

QinQ

Translate 1-to-2 / Translate 2-to-2

QinQ

Translate 1-to-2

QinQ

Translate 1-to-2 / Translate 2-to-2

QinQ

Translate 2-to-2

QinQ

No rewrite

Untagged

No rewrite

QinQ

No rewrite

Untagged

No rewrite

QinQ

No rewrite

Untagged

No rewrite

QinQ

Pop 1

Untagged

No rewrite

QinQ

Pop 1

Untagged

No rewrite

QinQ

Push 1 / Translate 1-to-1

Untagged

No rewrite

QinQ

Push 1 / Translate 1-to-1

Untagged

No rewrite

QinQ

Translate 1-to-2 / Translate 2-to-2

Untagged

No rewrite

Untagged

No rewrite

Untagged

No rewrite

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-2 tags: Translates the outermost two tags to two other tags


Note

The following rewrites are not supported for EoMPLS:

  • Push 2

  • Pop 2

  • Translate 1-to-2

  • Translate 2-to-1

  • Translate 2-to-2