SP L3/L2 VPN – Part III

Multicast MPLS VPN

Multicast VPN or an MPLS VPN capable of supporting multicast packet forwarding does not use MPLS forwarding or a control mechanism but uses MPLS VPN architecture and its associated Multicast Border Gateway Protocol (MBGP) route distribution process. This architecture requires that multicast routing be enabled in the SP core network. The multicast VPN solution provides a reduction in the amount of state information while retaining optimal routing. It maps all the particular VPN multicast groups to a single unique group called the Default Multicast Distribution Tree (Default MDT) in the provider network.

Control and low bandwidth data traffic flows through the default MDT. The solution allows the creation of additional distribution groups called Data Multicast Distribution Trees (Data MDTs) in the SP network to transport high bandwidth sources to points in the network that are signaled to receive traffic. This solution includes the support of multicast routing and forwarding in the context of VPN Routing and Forwarding (VRF) and the use of multicast tunnels over the provider network for control and data connectivity.

Routers in the customer sites that will be a part of the multicast tree will have to be enabled for multicast forwarding on the appropriate interfaces. The provider edge (PE) routers maintain PIM adjacency with the CE routers. The customer can run any multicast routing protocol (SSM or PIM) independent of the multicast protocol running in the provider network. PE routers build a per-VRF default MDT that will be used to distribute data packets and control messages for low bandwidth traffic.

Operation of Multicast MPLS VPN

The operation of a multicast MPLS VPN is as follows:

• Default MDT is enabled per customer VRF on every PE router that will forward multicast packets between customer sites. The VRF on the PE routers thus enabled for multicast forwarding is also called the multicast VRF (mVRF).
• Default MDT enables multicast forwarding for all PEs where the VRF resides.
• Control and data packets are transported per VRF over default MDT. Therefore, all low bandwidth data that is transported over the default MDT will be delivered to PEs where the VRFs reside. Hence, the default MDT is always present.
• A Data MDT for higher bandwidth sources can be created on the PE routers per VRF, and only routers that are part of the multicast tree for the high bandwidth source receive the multicast packets generated by the high bandwidth source. The data MDT is created on demand for mVPN (S, G) higher bandwidth traffic.
• MDT group addresses are defined by the provider and are unrelated to the groups used by the customer. Access to the MDT is via a multicast tunnel interface on PE routers where the PE router always functions as the root of the MDT if it is connected to the CE router containing the multicast source.
• Configurations involve enabling multicast as well as a multicast protocol on the interfaces in the customer domain, as well as the provider domain, to forward multicast packets. In addition, the VRF mapping to the customer is enabled for multicast routing using the ip multicast-routing vrf command, and the default and data MDTs are configured under the VRF definition.

GRE - Generic Routing Ecnapsulation

GRE is a tunneling protocol used to transport packets from one network through another network.

A GRE tunnel is a type of a VPN but it isn’t a secure tunneling method. However, you can encrypt GRE with an encryption protocol such as IPSec to form a secure VPN.

In fact, the point-to-point tunneling protocol (PPTP) actually uses GRE to create VPN tunnels. For example, if you configure Microsoft VPN tunnels, by default, you use PPTP, which uses GRE.Why would you tunnel traffic using GRE?

• You need to encrypt multicast traffic. GRE tunnels can carry multicast packets—just like real network interfaces—as opposed to using IPSec by itself, which can’t encrypt multicast traffic. Some examples of multicast traffic are OSPF, EIGRP, and RIPV2. Also, a number of video, VoIP, and streaming music applications use multicast.
• You have a protocol that isn’t routable, such as NetBIOS or non-IP traffic over an IP network. For example, you could use GRE to tunnel IPX or AppleTalk through an IP network.
• You need to connect two similar networks connected by a different network with different IP addressing.

How to configure GRE tunnels?

Router A:

interface Ethernet0/1

ip address 10.12.2.1 255.255.255.0

interface Serial0/0

ip address 192.168.14.1 255.255.255.0

interface Tunnel0

ip address 1.1.1.2 255.255.255.0

tunnel source Serial0/0

tunnel destination 192.168.14.2

Router B:

interface FastEthernet0/1

ip address 10.11.1.1 255.255.255.0

interface Serial0/0

ip address 192.168.14.2 255.255.255.0

interface Tunnel0

ip address 1.1.1.1 255.255.255.0

tunnel source Serial0/0

tunnel destination 192.168.14.1

In this example, the two routers each have a virtual interface—the tunnel interface. This interface is its own network, just like a point-to-point T1 circuit would be. The traffic going over the tunnel network is tunneling through the serial network.To each of the routers, it appears that it has two paths to the remote—the serial interface and the tunnel interface (running through the tunnel). This tunnel could then transmit unroutable traffic.

The tunnel interface on Router B is an interface like any other: See below.

RouterB# sh ip int brie

Interface IP-Address OK? Method Status Protocol

Ethernet0 10.11.1.1 YES manual up down

Serial0 192.168.14.2 YES manual up up

Serial1 unassigned YES unset administratively down down

Tunnel0 1.1.1.1 YES manual up up

RouterB#

Troubleshooting GRE tunnels

Because GRE takes one packet and encapsulates it in another packet, you might run into a situation where the packet you’re sending is larger than your interface allows. The solution to this issue is to configure ip tcp adjust-mss 1436on the tunnel interface.

While GRE doesn’t provide encryption, you can enable a key on each side of the tunnel using the tunnel key command. This is like a simple clear-text password with no encryption.

Because GRE tunnels are stateless, it’s possible for one side of the tunnel to go down while the other side remains up. The solution to this problem is to enable keepalive packets on each side of the tunnel. By doing this, each side of the tunnel periodically sends a keepalive to the other side. If one side doesn’t receive a keepalive in the specified time, the tunnels go down on each side.

Multipoint GRE:

Implementation of mGRE tunnels creates a multipoint tunnel network as an overlay to the IP backbone that interconnects the PE routers to transport VPN traffic. The multipoint tunnel uses BGP to distribute VPNv4 information between PE routers. The advertised next hop in BGP VPNv4 triggers tunnel endpoint discovery. Dynamic L3 VPN implementation over mGRE tunnels provides the ability for multiple SPs to cooperate and offer a joint VPN service with traffic tunneled directly from the ingress PE router at one service provider directly to the egress PE router at a different SP site.

When implementing dynamic Layer 3 VPNs over mGRE tunnels, the addition of new remote VPN peers is simplified because only the new router needs to be configured. The new address is learned dynamically and propagated to the other nodes in the network.

Configuring Layer 3 VPN over mGRE Tunnels

Step 1. Configure an additional VRF to transport mGRE.

Step 2. Configure a tunnel interface and assign it as part of the mGRE-associated VRF. Configure an IP address and a tunnel mode to be gre multipoint l3vpn. Also, configure the tunnel key.

Step 3. Configure a default route for the mGRE VRF pointing to the tunnel interface.

Step 4. Configure route-map to set the next-hop resolution to the mGRE VRF.

Step 5. Associate the route-map inbound for VPNv4 routes learned from MP-BGP neighbors.

 

L2TPv3 – Layer 2 Tunnelling Protocol v3

L2TPv3 defines the L2TP protocol for tunneling Layer 2 payloads over an IP core network using Layer 2 virtual private networks (VPNs). Benefits of this feature include the following:

• L2TPv3 simplifies deployment of VPNs
• L2TPv3 does not require Multiprotocol Label Switching

Prerequisites for Layer 2 Tunnel Protocol Version 3

1. Before you configure an Xconnect attachment circuit for a customer edge (CE) device , the Cisco Express Forwarding (CEF) feature must be enabled. To enable CEF on an interface, use the ip cef or ip cef distributed command.
2. You must configure a loopback interface on the router for originating and terminating the L2TPv3 traffic. The loopback interface must have an IP address that is reachable from the remote provider edge (PE) device at the other end of an L2TPv3 control channel.
3. To enable Simple Network Management Protocol (SNMP) notifications of L2TP session up and down events, enter the snmp-server enable traps l2tun session command before configuring L2TPv3.

 

General L2TPv3 Restrictions

• Cisco Express Forwarding (CEF) must be enabled for the L2TPv3 feature to function. The Xconnect configuration submode is blocked until CEF is enabled. On distributed platforms, such as the Cisco 7500 series, if CEF is disabled while a session is established, the session is torn down and remains down until CEF is reenabled. To enable CEF, use the ip cef or ip cef distributed command.
• Specifying a source IP address to configure a loopback interface is highly recommended. If you do not configure a loopback interface, the router will choose the best available local address, which could be any IP address configured on a core-facing interface. This configuration could prevent a control channel from being established
• The number of sessions on a PPP, high-level data link control (HDLC), Ethernet, or 802.1q VLAN port is limited by the number of interface descriptor blocks (IDBs) that the router can support. For PPP, HDLC, Ethernet, and 802.1q VLAN circuit types, an IDB is required for each circuit.
• When L2TPv3 is used to tunnel Frame Relay data-link connection identifiers (DLCIs), an IDB is not required for each circuit. As a result, the memory requirements are much lower. The scalability targets for the Engineering Field Test (EFT) program are 4000 L2TP sessions.
• Frame Relay support includes only 10-bit DLCI addressing. The L2TPv3 feature does not support Frame Relay extended addressing.
• The interface keepalive feature is automatically disabled on the interface to which Xconnect is applied, except for Frame Relay encapsulation, which is required for the Local Management Interface (LMI).
• Static L2TPv3 sessions do not support Frame Relay LMI interworking.
• Static L2TPv3 sessions do not interoperate with Universal Transport Interface (UTI) using keepalives.
• The ip pmtu command used to configure the pseudowire class (see the section “Configuring the L2TPv3 Pseudowire”) is not supported for static L2TPv3 sessions. As a result, Intermediate System-to-Intermediate System (IS-IS) fragmentation through a static L2TPv3 session is not supported.

 

Frame Relay-Specific Restrictions

1. Frame Relay per-DLCI forwarding and port-to-port trunking are mutually exclusive. L2TPv3 does not support the use of both on the same interface at the same time.
2. The xconnect command is not supported on Frame Relay interfaces directly. For Frame Relay, the Xconnect is applied under the connect command specifying the DLCI to be used.
3. Changing the encapsulation type on any interface removes any existing xconnect command applied to that interface.
4. The discard eligible (DE) bit value does not influence the type of service (ToS) bits.
5. To use DCE or a Network-to-Network Interface (NNI) on a Frame Relay port, you must configure the frame-relay switching command.
6. Frame Relay policing is nondistributed on the Cisco 7500 series. By configuring Frame Relay policing, you cause traffic on the affected PVCs to be sent to the RSP for processing. Frame Relay policing is not supported on the Cisco 12000 series Internet router.
7. Frame Relay support is for 10-bit DLCI addresses. Frame Relay Extended Addressing is not supported.
8. Multipoint DLCI is not supported.
9. The keepalive will automatically be disabled on interfaces that have an Xconnect applied to them, except for Frame Relay encapsulation, which is a requirement for LMI.
10. Static L2TPv3 sessions will not support Frame Relay LMI interworking.

 

VLAN-Specific Restrictions

1. A provider edge (PE) router is responsible only for static VLAN membership entries that are manually configured on the router. Dynamic VLAN membership entries, entry aging, and membership discovery are not supported.
2. Implicit tagging for VLAN membership operating on the other layers (such as at Layer 2, membership by MAC address or protocol type, at Layer 3, or membership by IP subnet) is not supported.
3. Point-to-multipoint and multipoint-to-point configurations are not supported. There is a 1:1 relationship between an attachment circuit and an L2TPv3 session.

 

L2TPv3 Operation

L2TPv3 provides similar and enhanced services to replace the current UTI implementation, including the following features:

• Xconnect for Layer 2 tunneling via a pseudowire over an IP network
• Layer 2 VPNs for PE-to-PE router service via Xconnect that support Ethernet, 802.1q (VLAN), Frame Relay, HDLC and PPP Layer 2 circuits, including both static (UTI-like) and dynamic (using the new L2TPv3 signaling) forwarded sessions

The Cisco IOS Release 12.3(2)T feature supports only the following features:

• Layer 2 tunneling (as used in an L2TP access concentrator, or LAC) to an attachment circuit, not Layer 3 tunneling
• L2TPv3 data encapsulation directly over IP (IP protocol number 115), not using User Datagram Protocol (UDP)
• Point-to-point sessions, not point-to-multipoint or multipoint-to-point sessions
• Sessions between the same Layer 2 protocols; for example, Ethernet-to-Ethernet, VLAN-to-VLAN, but not VLAN-to-Ethernet or Frame Relay

 

Benefits of Using L2TPv3

1. L2TPv3 Simplifies Deployment of VPNs
2. L2TPv3 is an industry-standard Layer 2 tunneling protocol that ensures interoperability among vendors, increasing customer flexibility and service availability.
3. L2TPv3 Does Not Require MPLS
4. With L2TPv3 service providers need not deploy MPLS in the core IP backbone to set up VPNs using L2TPv3 over the IP backbone, resulting in operational savings and increased revenue.
5. L2TPv3 Supports Layer 2 Tunneling over IP for Any Payload
6. L2TPv3 provides enhancements to L2TP to support Layer 2 tunneling of any payload over an IP core network. L2TPv3 defines the base L2TP protocol as being separate from the Layer 2 payload that is tunneled.

L2TPv3 Header Format

IP Delivery Header (20 bytes) & Protocol ID: 115

L2TPV3 Header consisting of:

• Session ID (4 bytes) – identifies the session context on the decapsulating system, note that yhe local session ID must be unique on the decapsulating system and is restricted to the least significant ten bits.
• Cookie (0, 4, or 8 bytes) – can be manually configured for static sessions, or dynamically determined for dynamic sessions, note when different platforms interoperate across an L2TPv3 control channel, both platforms need to encapsulate packets with a 4-byte cookie length.
• Pseudowire Control Encapsulation (4 bytes by default) – contains information used to sequence L2TP packets
• Layer 2 Payload

Static L2TPv3 Sessions can be set up for a PE router by configuring fixed values for the fields in the L2TP data header. A static L2TPv3 session allows the PE to tunnel Layer 2 traffic as soon as the attachment circuit to which the session is bound comes up. Note that in an L2TPv3 static session, you can still run the L2TP control channel to perform peer authentication and dead-peer detection. If the L2TP control channel cannot be established or is torn down because of a hello failure, the static session is also torn down. In addition, when you use a static L2TPv3 session, you cannot perform circuit interworking, such as LMI, because there is no facility to exchange control messages. To perform circuit interworking, you must use a dynamic session. A dynamic L2TP session is established through the exchange of control messages containing attribute-value pairs (AVPs). Each AVP contains information about the nature of the Layer 2 link being forwarded: the payload type, virtual circuit (VC) ID, and so on.

When Layer 2 traffic is tunneled across an IP network, information contained in the ToS [Type of Service] bits may be transferred to the L2TP-encapsulated IP packets in one of the following ways:

• If the tunneled Layer 2 frames encapsulate IP packets themselves, it may be desirable to simply copy the ToS bytes of the inner IP packets to the outer IP packet headers. This action is known as “ToS byte reflection.”
• Static ToS byte configuration. You specify the ToS byte value used by all packets sent across the pseudowire.

KeepAlive:

The keepalive mechanism for L2TPv3 extends only to the endpoints of the tunneling protocol. L2TP has a reliable control message delivery mechanism that serves as the basis for the keepalive mechanism. The keepalive mechanism consists of an exchange of L2TP hello messages.MTU – It is important that you configure a maximum transmission unit (MTU) appropriate for a each L2TPv3 tunneled link. The configured MTU size ensures the following:

• The lengths of the tunneled Layer 2 frames fall below the MTU of the destination attachment circuit
• The tunneled packets are not fragmented, which forces the receiving PE to reassemble them

L2TPv3 handles the MTU as follows:

• The default behavior is to fragment packets that are larger than the session MTU.
• If you enable the ip dfbit set command in the pseudowire class, the default MTU behavior changes so that any packets that cannot fit within the tunnel MTU are dropped.
• If you enable the ip pmtu command in the pseudowire class, the L2TPv3 control channel participates in the path MTU discovery. When you enable this feature, the following processing is performed:

Internet Control Message Protocol (ICMP) unreachable messages sent back to the L2TPv3 router are deciphered and the tunnel MTU is updated accordingly. In order to receive ICMP unreachable messages for fragmentation errors, the Don’t Fragment (DF) bit in the tunnel header is set according to the DF bit value received from the customer edge (CE) router, or statically if the ip dfbit set option is enabled. The tunnel MTU is periodically reset to the default value based on a periodic timer.

ICMP unreachable messages are sent back to the clients on the CE side. ICMP unreachable messages are sent to the CE whenever IP packets arrive on the CE-PE interface and have a packet size greater than the tunnel MTU. A Layer 2 header calculation is performed before the ICMP unreachable message is sent to the CE.

L2TPv3 supports the following Layer 2 payloads that can be included in L2TPv3 packets tunneled over the pseudowire:

Frame Relay:

Port-to-Port Trunking [Port-to-port trunking is where two CE Frame Relay interfaces are connected as by a leased line (UTI "raw" mode). All traffic arriving on one interface is forwarded transparently across the pseudowire to the other interface];

DLCI-to-DLCI Switching [Frame Relay DLCI-to-DLCI switching is where individual Frame Relay DLCIs are connected to create an end-to-end Frame Relay permanent virtual circuit (PVC). Traffic arriving on a DLCI on one interface is forwarded across the pseudowire to another DLCI on the other interface]PVC Status Signaling is propagated toward Frame Relay end users by the LMI protocol. You can configure the LMI to operate in any of the following modes:

1. UNI DTE mode—PVC status is not reported, only received.
2. UNI DCE mode—PVC status is reported but not received.
3. NNI mode—PVC status is reported and received independently.

Note that L2TPv3 supports all three modes.

Sequencing -> Frame Relay provides an ordered service in which packets sent to the Frame Relay network by one end-user device are delivered in order to the other end-user device. When switching is occurring over the pseudowire, packet ordering must be able to be preserved with a very high probability to closely emulate a traditional Frame Relay service.

ToS Marking -> The ToS bytes in the IP header can be statically configured or reflected from the internal IP header. The Frame Relay DE bit does not influence the ToS bytes.

CIR Guarantees -> In order to provide committed information rate (CIR) guarantees, you can configure a queueing policy that provides bandwidth to each DLCI to the interface facing the customer network on the egress PE.

Ethernet -> An Ethernet frame arriving at a PE router is simply encapsulated in its entirety with an L2TP data header. At the other end, a received L2TP data packet is stripped of its L2TP data header. The payload, an Ethernet frame, is then forwarded to the appropriate attachment circuit.

802.1q (VLAN) -> L2TPv3 supports VLAN membership in the following ways:

• Port-based, in which undated Ethernet frames are received
• VLAN-based, in which tagged Ethernet frames are received

HDLC -> L2TPv3 encapsulates an HDLC frame arriving at a PE in its entirety (including the Address, Control, and Protocol fields, but not the Flag fields and the frame check sequence) with an L2TP data header.

PPP -> PEs that support L2TPv3 forward PPP traffic using a “transparent pass-through” model, in which the PEs play no role in the negotiation and maintenance of the PPP link. L2TPv3 encapsulates a PPP frame arriving at a PE in its entirety (including the HDLC Address and Control fields) with an L2TP data header.

Note that Each L2TPv3 tunneled packet includes the entire Layer 2 frame of the payloads described in this section. If sequencing is required, a Layer 2-specific sublayer is included in the L2TPv3 header to provide the Sequence Number field. How to Configure Layer 2 Tunnel Protocol Version 3?

• Configuring L2TP Control Channel Parameters (optional) – 1. Timing Parameters, 2. Authentication Parameters, 3. Maintenance Parameters.
• Configuring the L2TPv3 Pseudowire (required)
• Configuring the Xconnect Attachment Circuit (required)
• Manually Configuring L2TPv3 Session Parameters (required)

Configuring L2TP Control Channel Timing Parameters

1. enable
2. configure terminal
3. l2tp-class [l2tp-class-name]
4. receive-window size
5. retransmit {initial retries initial-retries | retries retries | timeout {max | min} timeout}
6. timeout setup seconds

Configuring L2TP Control Channel Authentication Parameters;

1. enable
2. configure terminal
3. l2tp-class [l2tp-class-name]
4. authentication
5. hostname name
6. hidden
7. password [encryption-type] password

Configuring L2TP Control Channel Maintenance Parameters

1. enable
2. configure terminal
3. l2tp-class [l2tp-class-name]
4. hello interval

Configuring the L2TPv3 Pseudowire (required)

The pseudowire configuration specifies the characteristics of the L2TPv3 signaling mechanism, including the data encapsulation type, the control protocol, sequencing, fragmentation, payload-specific options, and IP properties. The setting that determines if signaling is used to set up the pseudowire is also included.

1. enable
2. configure terminal
3. pseudowire-class [pw-class-name]
4. encapsulation l2tpv3
5. protocol {l2tpv3 | none} [l2tp-class-name]
6. ip local interface interface-name
7. ip pmtu
8. ip tos {value value | reflect}
9. ip dfbit set
10. ip ttl value
11. ip protocol {l2tp | uti | protocol-number}
12. sequencing {transmit | receive | both}

Configuring the Xconnect Attachment Circuit (required)

This configuration procedure binds an Ethernet, 802.1q VLAN, or Frame Relay attachment circuit to an L2TPv3 pseudowire for Xconnect service. The virtual circuit identifier that you configure creates the binding between a pseudowire configured on a PE router and an attachment circuit in a CE device. The virtual circuit identifier configured on the PE router at one end of the L2TPv3 control channel must also be configured on the peer PE router at the other end.

1. enable
2. configure terminal
3. interface type slot/port
4. xconnect peer-ip-address vcid pseudowire-parameters [sequencing {transmit | receive | both}]

Manually Configuring L2TPv3 Session Parameters (required)

When you bind an attachment circuit to an L2TPv3 pseudowire for Xconnect service using the xconnect l2tpv3 manual command because you do not want signaling, you must then configure L2TP-specific parameters to complete the L2TPv3 control channel configuration.

1. enable
2. configure terminal
3. interface type slot/port
4. xconnect peer-ip-address vc-id encapsulation l2tpv3 manual pw-class pw-class-name
5. l2tp id local-session-id remote-session-id
6. l2tp cookie local size low-value [high-value]
7. l2tp cookie remote size low-value [high-value]
8. l2tp hello l2tp-class-name

Verification:

show l2tunnel session all

QinQ

Encapsulating IEEE 802.1Q VLAN tags within 802.1Q enables service providers to use a single VLAN to support customers who have multiple VLANs. The PPPoE – QinQ Support feature on the subinterface level preserves VLAN IDs and keeps traffic in different customer VLANs segregated. PPPoE – QinQ Support simply adds another layer of IEEE 802.1Q tag (called “metro tag” or “PE-VLAN”) to the 802.1Q tagged packets that enter the network. The purpose is to expand the VLAN space by tagging the tagged packets, thus producing a “double-tagged” frame. The expanded VLAN space allows the service provider to provide certain services, such as Internet access on specific VLANs for specific customers, and yet still allows the service provider to provide other types of services for their other customers on other VLANs.

Generally the service provider’s customers require a range of VLANs to handle multiple applications. Service providers can allow their customers to use this feature to safely assign their own VLAN IDs on subinterfaces because these subinterface VLAN IDs are encapsulated within a service provider-designated VLAN ID for that customer. Therefore there is no overlap of VLAN IDs among customers, nor does traffic from different customers become mixed. The double-tagged frame is “terminated” or assigned on a subinterface with an expanded encapsulation dot1q command that specifies the two VLAN ID tags (outer VLAN ID and inner VLAN ID) terminated on the subinterface.

Benefits:

• The primary benefit for the service provider is reduced number of VLANs supported for the same number of customers. Other benefits of this feature include:
• PPPoE scalability. By expanding the available VLAN space from 4096 to approximately 16.8 million (4096 times 4096), the number of PPPoE sessions that can be terminated on a given interface is multiplied.
• When deploying Gigabyte Ethernet DSL Access Multiplexer (DSLAM) in a wholesale model, you can assign the inner VLAN ID to represent the end-customer virtual circuit (VC) and assign the outer VLAN ID to represent the service provider ID.
• The Q-in-Q VLAN tag termination feature is simpler than the IEEE 802.1Q tunneling feature deployed for the Catalyst 6500 series switches or the Catalyst 3550 and Catalyst 3750 switches. Whereas switches require IEEE 802.1Q tunnels on interfaces to carry double-tagged traffic, routers need only encapsulate Q-in-Q VLAN tags within another level of 802.1Q tags in order for the packets to arrive at the correct destination.

How to Configure PPPoE – QinQ Support?

Steps to configure Ethertype field for outer VLAN tag (Optional):

1. enable
2. configure terminal
3. interface type number
4. dot1q tunneling ethertype ethertype

Steps to configure the Q-in-Q subinterface:

1. interface type number.subinterface-number
2. encapsulation dot1q vlan-id second-dot1q {any | vlan-id | vlan-id-vlan-id[,vlan-id-vlan-id]}
3. pppoe enabled [group group-name]
4. ip address ip-address mask [secondary]
5. Repeat Step 5 to configure another subinterface.
6. Repeat Step 6, Step 7, and Step 8, as required, to specify the VLAN tags to be terminated on the subinterface, to enable PPPoE sessions or IP on the subinterface.
7. end

Verification?

1. enable
2. show running-config
3. show vlans dot1q [internal | interface-type interface-number.subinterface-number [detail] | outer-id [interface-type interface-number | second-dot1q [inner-id | any]] [detail]]

References:

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gtl2tpv3.html#wp1027171

Cisco Press – MPLS Configuration on Cisco IOS Software

http://articles.techrepublic.com.com/5100-10878_11-6141478.html

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_qinq.html#wp1050990