L2VPN and Ethernet Services Configuration Guide for Cisco ASR 9000 Series Routers, IOS XR Release 7.5.x - Implementing Point to Point Layer 2 Services [Cisco ASR 9000 Series Aggregation Services Routers] (2024)

Layer 2 Virtual Private Network (L2VPN) emulates the behavior of a LAN across an L2 switched, IP or MPLS-enabled IP network, allowing Ethernet devices to communicate with each other as they would when connected to a common LAN segment. Point-to-point L2 connections are vital when creating L2VPNs.

As Internet service providers (ISPs) look to replace their Frame Relay or Asynchronous Transfer Mode (ATM) infrastructures with an IP infrastructure, there is a need to provide standard methods of using an L2 switched, IP or MPLS-enabled IP infrastructure. These methods provide a serviceable L2 interface to customers; specifically, to provide virtual circuits between pairs of customer sites.

Building a L2VPN system requires coordination between the ISP and the customer. The ISP provides L2 connectivity; the customer builds a network using data link resources obtained from the ISP. In an L2VPN service, the ISP does not require information about a the customer's network topology, policies, routing information, point-to-point links, or network point-to-point links from other ISPs.

The ISP requires provider edge (PE) routers with these capabilities:

• Encapsulation of L2 protocol data units (PDU) into Layer 3 (L3) packets.

• Interconnection of any-to-any L2 transports.

• Emulation of L2 quality-of-service (QoS) over a packet switch network.

• Ease of configuration of the L2 service.

• Support for different types of tunneling mechanisms (MPLS, L2TPv3, IPSec, GRE, and others).

• L2VPN process databases include all information related to circuits and their connections.

Virtual Circuit Connection Verification (VCCV) is an L2VPN Operations, Administration, and Maintenance (OAM) feature that allows network operators to run IP-based provider edge-to-provider edge (PE-to-PE) keepalive protocol across a specified pseudowire to ensure that the pseudowire data path forwarding does not contain any faults. The disposition PE receives VCCV packets on a control channel, which is associated with the specified pseudowire. The control channel type and connectivity verification type, which are used for VCCV, are negotiated when the pseudowire is established between the PEs for each direction.

Two types of packets can arrive at the disposition egress:

• Type 1—Specifies normal Ethernet-over-MPLS (EoMPLS) data packets.

• Type 2—Specifies VCCV packets.

CiscoASR9000 Series Router supports Label Switched Path (LSP) VCCV Type 1, which uses an inband control word if enabled during signaling. The VCCV echo reply is sent as IPv4 that is the reply mode in IPv4. The reply is forwarded as IP, MPLS, or a combination of both.

VCCV pings counters that are counted in MPLS forwarding on the egress side. However, on the ingress side, they are sourced by the route processor and do not count as MPLS forwarding counters.

Using L2VPN technology, you can assign a quality of service (QoS) level to both Port and VLAN modes of operation.

L2VPN technology requires that QoS functionality on PE routers be strictly L2-payload-based on the edge-facing interfaces (also know as attachment circuits). The following figure illustrates L2 and L3 QoS service policies in a typical L2VPN network.

The following figure shows four packet processing paths within a provider edge device where a QoS service policy can be attached. In an L2VPN network, packets are received and transmitted on the edge-facing interfaces as L2 packets and transported on the core-facing interfaces as MPLS (EoMPLS).

L2VPN uses control planes in both route processors and line cards, as well as forwarding plane elements in the line cards.

The availability of L2VPN meets these requirements:

• A control plane failure in either the route processor or the line card will not affect the circuit forwarding path.

• The router processor control plane supports failover without affecting the line card control and forwarding planes.

• L2VPN integrates with existing Label Distribution Protocol (LDP) graceful restart mechanism.

Preferred tunnel path functionality lets you map pseudowires to specific traffic-engineering tunnels. Attachment circuits are cross-connected to specific MPLS traffic engineering tunnel interfaces instead of remote PE router IP addresses (reachable using IGP or LDP). Using preferred tunnel path, it is always assumed that the traffic engineering tunnel that transports the L2 traffic runs between the two PE routers (that is, its head starts at the imposition PE router and its tail terminates on the disposition PE router).

Note	Currently, preferred tunnel path configuration applies only to MPLS encapsulation.

Pseudowires transport Layer 2 protocol data units (PDUs) across a public switched network (PSN). A multisegment pseudowire is a static or dynamically configured set of two or more contiguous pseudowire segments. These segments act as a single pseudowire, allowing you to:

• Manage the end-to-end service by separating administrative or provisioning domains.

• Keep IP addresses of provider edge (PE) nodes private across interautonomous system (inter-AS) boundaries. Use IP address of autonomous system boundary routers (ASBRs) and treat them as pseudowire aggregation routers. The ASBRs join the pseudowires of the two domains.

A multisegment pseudowire can span either an inter-AS boundary or two multiprotocol label switching (MPLS) networks.

A pseudowire is a tunnel between two PE nodes. There are two types of PE nodes:

• A Switching PE (S-PE) node

  • Terminates PSN tunnels of the preceding and succeeding pseudowire segments in a multisegment pseudowire.

  • Switches control and data planes of the preceding and succeeding pseudowire segments of the multisegment pseudowire.

• A Terminating PE (T-PE) node

  • Located at both the first and last segments of a multisegment pseudowire.

  • Where customer-facing attachment circuits (ACs) are bound to a pseudowire forwarder.

Note	Every end of a multisegment pseudowire must terminate at a T-PE.

A multisegment pseudowire is used in two general cases when:

• It is not possible to establish a PW control channel between the source and destination PE nodes.

  For the PW control channel to be established, the remote PE node must be accessible. Sometimes, the local PE node may not be able to access the remote node due to topology, operational, or security constraints.

  A multisegment pseudowire dynamically builds two discrete pseudowire segments and performs a pseudowire switching to establish a PW control channel between the source and destination PE nodes.

• Pseudowire Edge To Edge Emulation (PWE3) signaling and encapsulation protocols are different.

  The PE nodes are connected to networks employing different PW signaling and encapsulation protocols. Sometimes, it is not possible to use a single segment PW.

  A multisegment pseudowire, with the appropriate interworking performed at the PW switching points, enables PW connectivity between the PE nodes in the network.

Pseudowire redundancy allows you to configure your network to detect a failure in the network and reroute the Layer 2 service to another endpoint that can continue to provide service. This feature provides the ability to recover from a failure of either the remote provider edge (PE) router or the link between the PE and customer edge (CE) routers.

L2VPNs can provide pseudowire resiliency through their routing protocols. When connectivity between end-to-end PE routers fails, an alternative path to the directed LDP session and the user data takes over. However, there are some parts of the network in which this rerouting mechanism does not protect against interruptions in service.

Pseudowire redundancy enables you to set up backup pseudowires. You can configure the network with redundant pseudowires and redundant network elements.

Prior to the failure of the primary pseudowire, the ability to switch traffic to the backup pseudowire is used to handle a planned pseudowire outage, such as router maintenance.

Note	Pseudowire redundancy is provided only for point-to-point Virtual Private Wire Service (VPWS) pseudowires.

To maximize networks while maintaining redundancy typically requires traffic load balancing over multiple links. To achieve better and more uniformed distribution, load balancing on the traffic flows that are part of the provisioned pipes is desirable. Load balancing can be flow based according to the IP addresses, Mac addresses, or a combination of those. Load balancing can be flow based according to source or destination IP addresses, or source or destination MAC addresses. Traffic falls back to default flow based MAC addresses if the IP header cannot proceed or IPv6 is be flow based.

This feature applies to pseudowires under L2VPN; this includes VPWS and VPLS.

Note	Enabling virtual circuit (VC) label based load balancing for a pseudowire class overrides global flow based load balancing under L2VPN.

If the frame is IP-based, the load-balancing flow “src-dst-ip” configuration causes the Layer 2 interfaces to use the IP header for flow balancing hash calculation. If the frame is not IP-based, the MAC header is used for the hash calculation. In previous releases, for an MPLS header between the MAC and IP headers, the code would use the MAC header for the flow balancing hash.

From Release 6.4.1 onwards, the code analyzes the MPLS header, and if an IP header is available, it uses that for hash calculation.

If the MPLS label stack is more than four labels deep, the code stops looking for an IP header and reverts to the MAC header hash calculation.

When L2VPN flow-based src-dst-ip load-balancing is configured, and if a payload with encapsulated GTP is used, the GTP ID is considered for load-balancing criteria. Starting from Release 6.5.1, you do not have to configure the cef load-balancing command to use GTP ID as a criteria for load-balancing for L2VPN scenarios. However, you must explicitly configure CEF load-balancing for Layer 3 scenarios.

When pseudowires (PWs) are established, each PW is assigned a group ID that is common for all PWs created on the same physical port. When a physical port becomes non-functional or disabled, Automatic Protection Switching (APS) signals the peer router to get activated and L2VPN sends a single message to advertise the status change of all PWs that have the Group ID associated with the physical port. A single L2VPN signal thus avoids a lot of processing and loss in reactivity.

For CEM interfaces, various levels of configuration are permitted for the parent controllers, such as T1 and T3, framed or unframed. To achieve best grouping, the physical controller handle is used as the group ID.

Note	Pseudowire grouping is disabled by default.

An Ethernet Wire Service is a service that emulates a point-to-point Ethernet segment. This is similar to Ethernet private line (EPL), a Layer 1 point-to-point service, except the provider edge operates at Layer 2 and typically runs over a Layer 2 network. The EWS encapsulates all frames that are received on a particular UNI and transports these frames to a single-egress UNI without reference to the contents contained within the frame. The operation of this service means that an EWS can be used with VLAN-tagged frames. The VLAN tags are transparent to the EWS (bridge protocol data units [BPDUs])—with some exceptions. These exceptions include IEEE 802.1x, IEEE 802.2ad, and IEEE 802.3x, because these frames have local significance and it benefits both the customer and the Service Provider to terminate them locally.

Since the service provider simply accepts frames on an interface and transmits these without reference to the actual frame (other than verifying that the format and length are legal for the particular interface) the EWS is indifferent to VLAN tags that may be present within the customer Ethernet frames.

EWS subscribes to the concept of all-to-one bundling. That is, an EWS maps a port on one end to a point-to-point circuit and to a port on another end. EWS is a port-to-port service. Therefore, if a customer needs to connect a switch or router to n switches or routers it will need n ports and n pseudowires or logical circuits.

One important point to consider is that, although the EWS broadly emulates an Ethernet Layer 1 connection, the service is provided across a shared infrastructure, and therefore it is unlikely that the full interface bandwidth will be, or needs to be, available at all times. EWS will typically be a sub-line rate service, where many users share a circuit somewhere in their transmission path. As a result, the cost will most likely be less than that of EPL. Unlike a Layer 1 EPL, the SP will need to implement QoS and traffic engineering to meet the specific objectives of a particular contract. However, if the customer's application requires a true wire rate transparent service, then an EPL service—delivered using optical transmission devices such as DWDM (dense wavelength division multiplexing), CDWM (coarse wavelength division multiplexing), or SONET/SDH—should be considered.

Customer deployments require a solution to support AToM with disparate transport at network ends. This solution must have the capability to translate transport on one customer edge (CE) device to another transport, for example, Frame relay to Ethernet. The Cisco ASR 9000 Series SPA Interface Processor-700 and the Cisco ASR 9000 Series Ethernet line cards enable the Cisco ASR 9000 Series Routers to support multiple legacy services.

IP Interworking is a solution for transporting Layer 2 traffic over an IP/MPLS backbone. It accommodates many types of Layer 2 frames such as Ethernet and Frame Relay using AToM tunnels. It encapsulates packets at the provider edge (PE) router, transports them over the backbone to the PE router on the other side of the cloud, removes the encapsulation, and transports them to the destination. The transport layer can be Ethernet on one end and Frame relay on the other end. IP interworking occurs between disparate endpoints of the AToM tunnels.

Note	Only routed interworking is supported between Ethernet and Frame Relay based networks for MPLS and Local-connect scenarios.

The following figure shows the interoperability between an Ethernet attachment VC and a Frame Relay attachment VC.

An attachment circuit (AC) is a physical or logical port or circuit that connects a CE device to a PE device. A pseudowire (PW) is a bidirectional virtual connection (VC) connecting two ACs. In an MPLS network, PWs are carried inside an LSP tunnel. The core facing line card on the PE1 and PE2 could be a Cisco ASR 9000 Series SPA Interface Processor-700 or a Cisco ASR 9000 Series Ethernet line card.

In the IP Interworking mode, the Layer 2 (L2) header is removed from the packets received on an ingress PE, and only the IP payload is transmitted to the egress PE. On the egress PE, an L2 header is appended before the packet is transmitted out of the egress port.

In Figure above , CE1 and CE2 could be a Frame Relay (FR) interface or a GigabitEthernet (GigE) interface. Assuming CE1 is a FR and CE2 is either a GigE or dot1q, or QinQ. For packets arriving from an Ethernet CE (CE2), ingress LC on the PE (PE2) facing the CE removes L2 framing and forwards the packet to egress PE (PE1) using IPoMPLS encapsulation over a pseudowire. The core facing line card on egress PE removes the MPLS labels but preserves the control word and transmits it to the egress line card facing FR CE (CE1). At the FR PE, after label disposition, the Layer 3 (L3) packets are encapsulated over FR.

Similarly, IP packets arriving from the FR CE are translated into IPoMPLS encapsulation over the pseudowire. At the Ethernet PE side, after label disposition, the PE adds L2 Ethernet packet header back to the packet before transmitting it to the CE, as the packets coming out from the core carry only the IP payload.

These modes support IP Interworking on AToM:

• Ethernet to Frame Relay

  Packets arriving from the Ethernet CE device have MAC (port-mode, untagged, single, double tag), IPv4 header and data. The Ethernet line card removes the L2 framing and then forwards the L3 packet to the egress line card. The egress line card adds the FR L2 header before transmitting it from the egress port.

• Ethernet to Ethernet

  Both the CE devices are Ethernet. Each ethernet interface can be port-mode, untagged, single, or double tag, although this is not a typical scenario for IP interworking.

Frame Relay over MPLS (FRoMPLS) provides leased line type of connectivity between two Frame Relay islands. Frame Relay traffic is transported over the MPLS network.

Note	The Data Link Connection Identifier (DLCI) DCLI-DLCI mode is supported. A control word (required for DLCI-DLCI mode) is used to carry additional control information.

When a Provider Edge (PE) router receives a Frame Relay protocol packet from a subscriber site, it removes the Frame Relay header and Frame Check Sequence (FCS) and appends the appropriate Virtual Circuit (VC) label. The removed Backward Explicit Congestion Notification (BECN), Forward Explicit Congestion Notification (FECN), Discard Eligible (DE) and Command/Response (C/R) bits are (for DLCI-DLCI mode) sent separately using a control word.

MPLS transport profile (MPLS-TP) tunnels provide the transport network service layer over which IP and MPLS traffic traverse. Within the MPLS-TP environment, pseudowires (PWs) use MPLS-TP tunnels as the transport mechanism. MPLS-TP tunnels help transition from SONET/SDH TDM technologies to packet switching, to support services with high bandwidth utilization and low cost. Transport networks are connection oriented, statically provisioned, and have long-lived connections. Transport networks usually avoid control protocols that change identifiers (like labels). MPLS-TP tunnels provide this functionality through statically provisioned bidirectional label switched paths (LSPs).

For more information on configuring MPLS transport profile, refer to the Cisco ASR 9000 Series Aggregation Services Router MPLS Configuration Guide.

MPLS-TP supports these combinations of static and dynamic multisegment pseudowires:

• Static-static

• Static-dynamic

• Dynamic-static

• Dynamic-dynamic

MPLS-TP supports one-to-one L2VPN pseudowire redundancy for these combinations of static and dynamic pseudowires:

• Static pseudowire with a static backup pseudowire

• Static pseudowire with a dynamic backup pseudowire

• Dynamic pseudowire with a static backup pseudowire

• Dynamic pseudowire with a dynamic backup pseudowire

The existing TE preferred path feature is used to pin down a PW to an MPLS-TP transport tunnel. See Configuring Preferred Tunnel Path for more information on configuring preferred tunnel path. For a dynamic pseudowire, PW status is exchanged through LDP whereas for static PW, status is transported in PW OAM message. See Configuring PW Status OAM for more information on configuring PW status OAM. By default, alarms are not generated when the state of a PW changes due to change in the state of MPLS TP tunnel carrying that PW.

The L2VPN Nonstop Routing (NSR) feature avoids label distribution path (LDP) sessions from flapping on events such as process failures (crash) and route processor failover (RP FO). NSR on process failure (crash) is supported by performing RP FO, if you have enabled NSR using NSR process failure switchover.

NSR enables the router (where failure has occurred) to maintain the control plane states without a graceful restart (GR). NSR, by definition, does not require any protocol extension and typically uses Stateful Switch Over (SSO) to maintain it’s control plane states.

Note	NSR is enabled by default for L2VPN on Cisco IOS XR 64 bit operating system. You cannot configure the nsr command under L2VPN configuration submode.

A L2TPv3 over IPv6 tunnel is a static L2VPN cross-connect that uses Layer 2 Tunneling Protocol version 3 (L2TPv3) over IPv6, with a unique IPv6 source address for each cross-connect. The L2TPv3 over IPv6 tunnels consists of one L2TPv3 tunnel for each subscriber VLAN. The unique IPv6 address completely identifies the customer, and the service that is delivered.

Note	L2TPv3 over IPv6 tunnels are supported on the ASR 9000 Enhanced Ethernet line cards by a scale of 15000 crossconnects for each router and line card.

Note	nV satellite access interfaces do not support L2TPv3 over IPv6.

Traffic Injection from L2TPv3 over IPv6 Tunnel feature allows you to inject diagnostic traffic through Layer 2 Tunneling Protocol version 3 (L2TPv3) Switched Port Analyzer (SPAN) tunnel. The diagnostic traffic allows you to monitor and troubleshoot the network traffic. You can send the diagnostic traffic from customer office (CO) using traffic generator towards the customer or towards the network.

In previous releases, with traffic mirroring feature the user was only able to send the mirrored traffic from customer towards the monitoring device, the mirror tunnel was unidirectional.

Traffic mirroring copies traffic from one or more source ports and sends the copied traffic to one or more destinations for analysis by a network analyzer or other monitoring device. Traffic mirroring does not affect the flow of traffic on the source interfaces or sub-interfaces, and allows the mirrored traffic to be sent to a destination interface or sub-interface

Topology

Consider a topology where an L2TPv3 tunnel is created between two ASR 9000 devices. Customer Office (CO) sends diagnostic traffic using traffic generator over L2TPv3 over IPv6 tunnel to the ASR 9000 router. The ASR 9000 router on the left-hand side sends the diagnostic traffic towards the customer as though it is sent from the network or sends the diagnostic traffic towards the network as though it is sent from the customer.

The diagnostic traffic header contains destination MAC address, source MAC address, and IP payload. If the header contains destination MAC address of the ASR 9000 router, the diagnostic traffic is sent to the network as though it sent from the customer. If the header contains source MAC address of the ASR 9000 router, the diagnostic traffic is sent to the customer as though it sent from the network.

Layer 2 Tunneling Protocol version 3 (L2TPv3) over IPv4 provides a dynamic mechanism for tunneling Layer 2 (L2) circuits across a packet-oriented data network, with multiple attachment circuits multiplexed over a single pair of IP address endpoints, using the L2TPv3 session ID as a circuit discriminator.

The following figure shows how the L2TPv3 feature is used to set up VPNs using Layer 2 tunneling over an IP network. All traffic between two customer network sites is encapsulated in IP packets carrying L2TP data messages and sent across an IP network. The backbone routers of the IP network treat the traffic as any other IP traffic and needn’t know anything about the customer networks.

In the above figure the PE routers R1 and R2 provide L2TPv3 services. The R1 and R2 routers communicate with each other using a pseudowire over the IP backbone network through a path comprising the interfaces int1 and int2 , the IP network, and interfaces int3 and int4 . The CE routers R3 and R4 communicate through a pair of cross-connected Ethernet or 802.1q VLAN interfaces using an L2TPv3 session. The L2TPv3 session tu1 is a pseudowire configured between interface int1 on R1 and interface int4 on R2. Any packet arriving on interface int1 on R1 is encapsulated and sent through the pseudowire control-channel (tu1) to R2. R2 decapsulates the packet and sends it on interface int4 to R4. When R4 needs to send a packet to R3, the packet follows the same path in reverse.

Note	L2TPv3 over IPv4 feature is supported only on Cisco ASR 9000 High Density 100GE Ethernet line cards.

Note	nV satellite access interfaces do not support L2TPv3 over IPv4.

For more information on:

• Configuration procedures, see Configuring L2TPv3 over IPv4 Tunnels.

• Configuration examples, see Configuring L2TPv3 over IPv4 Tunnels: Example.

A single-segment pseudowire (SS-PW) is a point-to-point pseudowire (PW) where the PW segment is present between two PE routers.

In this feature, a single-segment pseudowire is established between two PE routers of the same autonomous system (AS) dynamically using the FEC 129 information. The objective of this feature is to ensure interoperability of the Cisco routers with the third-party routers.

The EVPN-VPWS is a BGP control plane solution for point-to-point services. It implements the signaling and encapsulation techniques for establishing an EVPN instance between a pair of PEs. It has the ability to forward traffic from one network to another without MAC lookup. The use of EVPN for VPWS eliminates the need for signaling single-segment and multi-segment PWs for point-to-point Ethernet services. You can also configure the PWHE interface and a bridge domain access pseudowire using EVPN-VPWS.

EVPN-VPWS single homed technology works on IP and MPLS core; IP core to support BGP and MPLS core for switching packets between the endpoints.

Increasingly, your customers are looking for efficient methods to backhaul Layer 3 services on their service PE devices over Layer 2 networks, while still being able to monitor and provide assurances on per-service granularity. To achieve this efficiency, a key requirement is resilient Layer 3 service for their non-directly connected end users and to be able to protect against active Layer 3 service failures. In achieving Layer 3 gateway and service redundancy, traditional first-hop resilience mechanisms suffer from scalability limitations.

The alternative solution is Multi-homed EVPN Head End that, in analogy, is the EVPN flavor of Pseudo-Wire Head End (PWHE). Multi-homed EVPN Head End allows the termination of Access pseuodwires or PWs (like EVPN-VPWS) into a Layer 3 [virtual routing and forwarding (VRF) or global] domain. PWHE subinterface resides in customer VRFs allowing service providers to offer IP services such as DHCP, NTP, and Layer 3 VPN for internet connectivity.

Multi-homed EVPN Head End has the following advantages:

• Decouples the customer-facing interface (CFI) of the service PE from the underlying physical transport media of the access or aggregation network.

• Reduces capex in the access or aggregation network and service PE.

• Distributes and scales the customer-facing Layer 2 UNI interface set.

• Extends and expands service provider’s Layer 3 service footprints.

• Allows provisioning features such as QoS and ACL, L3VPN on a per PWHE subinterface

The Multi-homed EVPN headend solution supports redundant Layer 3 gateway functionality over PW-Ether interface termination, residing on a pair of redundant PE routers. The PW-Ether subinterfaces offer redundancy in the Core and first-hop router towards the access on a per-customer-service basis.

Multi-homed EVPN is supported with:

• Regular attachment circuits

• Physical Ethernet ports

• Bundle interfaces

• PW-Ether interfaces

Multi-homed EVPN headend supports three load balancing modes. These load balancing modes apply to the access side only.

• Single-Active (Layer 2 Access), also referred to as anycast single-active mode. That is, all-active in Layer 3 Core and single-active in Layer 2 Access, which is the default load-balancing mode for PWHE.

• All-Active

• Port-Active

Note	The load balancing mode for the EVPN headend at the core is always ALL-ACTIVE and cannot be modified.

As part of the Multi-Homed EVPN Headend functionality, a new syntax is added under the interface (EVPN) command as shown in the following example:

router(config)#evpn interface ? PW-Ether PWHE Ethernet Interface | short name is PE

For details about the interface (EVPN) command, see the VPN and Ethernet Services Command Reference for Cisco ASR 9000 Series Routers.

SUMMARY STEPS

1. configure
2. interface type interface-path-id
3. l2transport
4. exit
5. interface type interface-path-id
6. Use the commit or end command.
7. show interface type interface-id

DETAILED STEPS

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# interface TenGigE 0/0/0/0

RP/0/RSP0/CPU0:router(config-if)# l2transport

RP/0/RSP0/CPU0:router(config-if-l2)# exit

RP/0/RSP0/CPU0:router(config)# interface TenGigE 0/0/0/0

RP/0/RSP0/CPU0:router show interface TenGigE 0/0/0/0

SUMMARY STEPS

1. configure
2. l2vpn
3. xconnect group group-name
4. p2p xconnect-name
5. interface type interface-path-id
6. interface type interface-path-id
7. Use the commit or end command.

DETAILED STEPS

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config-subif)# l2vpn

RP/0/RSP0/CPU0:router(config-l2vpn)# xconnect group grp_1

RP/0/RSP0/CPU0:router(config-l2vpn-xc)# p2p vlan1

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interface TenGigE 0/7/0/6.5

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interface GigabitEthernet0/4/0/30

SUMMARY STEPS

1. configure
2. l2vpn
3. xconnect group group-name
4. p2p xconnect-name
5. backup interface type interface-path-id
6. interface type interface-path-id
7. interface type interface-path-id
8. Use the commit or end command.

DETAILED STEPS

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config-subif)# l2vpn

RP/0/RSP0/CPU0:router(config-l2vpn)# xconnect group grp_1

RP/0/RSP0/CPU0:router(config-l2vpn-xc)# p2p vlan1

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# backup interface Bundle-Ether 0/7/0/6.5

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interface Bundle-Ether 0/7/0/6.2

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interface Bundle-Ether 0/7/0/6.1

Note

Consider this information about cross-connects when you configure static point-to-point cross-connects: An cross-connect is uniquely identified with the pair; the cross-connect name must be unique within a group. A segment (an attachment circuit or pseudowire) is unique and can belong only to a single cross-connect. A static VC local label is globally unique and can be used in one pseudowire only. No more than 16,000 cross-connects can be configured per router.

Note	Static pseudowire connections do not use LDP for signaling.

Perform this task to configure static point-to-point cross-connects.

SUMMARY STEPS

1. configure
2. l2vpn
3. xconnect group group-name
4. p2p xconnect-name
5. interface type interface-path-id
6. neighbor A.B.C.D pw-id pseudowire-id
7. mpls static label local { value } remote { value }
8. Use the commit or end command.

DETAILED STEPS

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# l2vpn

RP/0/RSP0/CPU0:router(config-l2vpn)# xconnect group grp_1

RP/0/RSP0/CPU0:router(config-l2vpn-xc)# p2p vlan1

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interface gigabitethernet 0/1/0/9

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# neighbor 10.2.2.2 pw-id 2000

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p-pw)# mpls static label local 699 remote 890

Perform this task to configure dynamic point-to-point cross-connects.

Note	For dynamic cross-connects, LDP must be up and running.

SUMMARY STEPS

1. configure
2. l2vpn
3. xconnect group group-name
4. p2p xconnect-name
5. interface type interface-path-id
6. neighbor A.B.C.D pw-id pseudowire-id
7. Use the commit or end command.

DETAILED STEPS

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# l2vpn

RP/0/RSP0/CPU0:router(config-l2vpn)# xconnect group grp_1

RP/0/RSP0/CPU0:router(config-l2vpn-xc)# p2p vlan1

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interface GigabitEthernet0/0/0/0.1

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# neighbor 2.2.2.2 pw-id 2000

The Inter-AS configuration procedure is identical to the L2VPN cross-connect configuration tasks (see “Configuring Static Point-to-Point Cross-Connects” section and “Configuring Dynamic Point-to-Point Cross-Connects” section) except that the remote PE IP address used by the cross-connect configuration is now reachable through iBGP peering.

Note	You must be knowledgeable about IBGP, EBGP, and ASBR terminology and configurations to complete this configuration.

This procedure describes how to configure a preferred tunnel path.

Note	The tunnel used for the preferred path configuration is an MPLS Traffic Engineering (MPLS-TE) tunnel.

SUMMARY STEPS

1. configure
2. l2vpn
3. pw-class {name }
4. encapsulation mpls
5. preferred-path {interface } {tunnel-ip value | tunnel-te value | tunnel-tp value } [fallback disable ]
6. Use the commit or end command.

DETAILED STEPS

RP/0/RP0/CPU0:router# configure

RP/0/RP0/CPU0:router(config)# l2vpn

RP/0/RP0/CPU0:router(config-l2vpn)# pw-class path1

RP/0/RP0/CPU0:router(config-l2vpn-pwc)# encapsulation mpls

RP/0/RP0/CPU0:router(config-l2vpn-pwc-encap-mpls)# preferred-path interface tunnel-te 11 fallback disable

SUMMARY STEPS

1. configure
2. l2vpn
3. pw-oam refresh transmit seconds
4. endorcommit

DETAILED STEPS

RP/0/RSP0RP0/CPU0:router# configure

RP/0/RSP0RP0/CPU0:router(config)# l2vpn

RP/0/RSP0RP0/CPU0:router(config-l2vpn)# pw-oam refresh transmit 100

RP/0/RSP0RP0/CPU0:router(config-l2vpn)# end

RP/0/RSP0RP0/CPU0:router(config-l2vpn)# commit

SUMMARY STEPS

1. configure
2. l2vpn
3. load-balancing flow {src-dst-mac | src-dst-ip}
4. endorcommit

DETAILED STEPS

RP/0/RSP0RP0/CPU0:router# configure

RP/0/RSP0RP0/CPU0:router(config)# l2vpn

RP/0/RSP0RP0/CPU0:router(config-l2vpn)# load-balancing flow src-dst-ip

RP/0/RSP0RP0/CPU0:router(config-l2vpn)# end

RP/0/RSP0RP0/CPU0:router(config-l2vpn)# commit

SUMMARY STEPS

1. configure
2. l2vpn
3. pw-class {name}
4. encapsulation mpls
5. load-balancing pw-label
6. endorcommit

DETAILED STEPS

RP/0/RSP0RP0/CPU0:router# configure

RP/0/RSP0RP0/CPU0:router(config)# l2vpn

RP/0/RSP0RP0/CPU0:router(config-l2vpn)# pw-class path1

RP/0/RSP0RP0/CPU0:router(config-l2vpn-pwc)# encapsulation mpls

RP/0/RSP0RP0/CPU0:router(config-l2vpn-pwc-encap-mpls)# load-balancing pw-label

RP/0/RSP0RP0/CPU0:router(config-l2vpn-pwc-encap-mpls)# end

RP/0/RSP0RP0/CPU0:router(config-l2vpn-pwc-encap-mpls)# commit

SUMMARY STEPS

1. configure
2. l2vpn
3. pw-grouping
4. Use the commit or end command.

DETAILED STEPS

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# l2vpnRP/0/RSP0/CPU0:router(config-l2vpn)#

RP/0/RSP0/CPU0:router(config-l2vpn)# pw-grouping

SUMMARY STEPS

1. configure
2. multicast-routing [address-family ipv4]
3. interface all enable
4. exit
5. router igmp
6. version {1 | 2 | 3}
7. endorcommit
8. show pim [ipv4] group-map [ip-address-name] [info-source]
9. show pim [vrf vrf-name] [ipv4] topology [source-ip-address [group-ip-address] | entry-flag flag | interface-flag | summary] [route-count]

DETAILED STEPS

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# multicast-routing

RP/0/RSP0/CPU0:router(config-mcast-ipv4)# interface all enable

RP/0/RSP0/CPU0:router(config-mcast-ipv4)# exit

RP/0/RSP0/CPU0:router(config)# router igmp 

RP/0/RSP0/CPU0:router(config-igmp)# version 3 

RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# end

RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#commit

RP/0//CPU0:router# show pim ipv4 group-map

RP/0/RSP0/CPU0:router# show pim topology 

SUMMARY STEPS

1. configure
2. l2vpn
3. xconnect groupgroup-name
4. p2pxconnect-name
5. interworking ipv4
6. Use the commit or end command.

DETAILED STEPS

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# l2vpn

RP/0/RSP0/CPU0:router(config-l2vpn)# xconnect group grp_1

RP/0/RSP0/CPU0:router(config-l2vpn-xc)# p2p vlan1

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interworking ipv4

SUMMARY STEPS

1. configure
2. interface type interface-path-id
3. encapsulation ppp
4. l2transport
5. end
6. l2vpn
7. xconnect group group-name
8. p2p xconnect-name
9. interface type interface-path-id
10. interface type interface-path-id
11. interworking ipv4
12. interface type interface-path-id
13. neighborA.B.C.Dpw-id
14. pw-class interface-path-id
15. exit
16. interworking ipv4
17. endorcommit

DETAILED STEPS

RP/0/0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# interface Serial0/2/1/0/1/1/1:0

RP/0/RSP0/CPU0:router(config-if)# encapsulation ppp

RP/0/RSP0/CPU0:router(config-if)# l2transport

RP/0/RSP0/CPU0:router(config-if-l2)# end

RP/0/RSP0/CPU0:router(config)# l2vpn

RP/0/RSP0/CPU0:router(config-l2vpn)# xconnect group grp_1

RP/0/RSP0/CPU0:router(config-l2vpn-xc)# p2p 1

RP/0/RSP0/CPU0:router(config)# interface Serial0/2/1/0/1/1/1:0

RP/0/RSP0/CPU0:router(config)# interface GigabitEthernet0/0/0/1.1

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interworking ipv4

RP/0/RSP0/CPU0:router(config)# interface GigabitEthernet0/0/0/1.1

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interface Serial0/0/0/0/2/1/1:0

RP/0/RSP0/CPU0:router (config-l2vpn-xc-p2p-pw)# pw-class class_c1

RP/0/RSP0/CPU0:router (config-l2vpn-xc-p2p-pw)# exit

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interworking ipv4

RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# end

RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#commit

SUMMARY STEPS

1. configure
2. interface typeinterface-path-id
3. l2transport
4. end
5. l2vpn
6. xconnect groupgroup-name
7. p2pxconnect-name
8. interface typeinterface-path-id
9. interface type interface-path-id
10. interworking ipv4
11. interface type interface-path-id
12. neighborA.B.C.Dpw-id
13. pw-classclass-name
14. pw-classclass-name
15. exit
16. interworking ipv4
17. Use the commit or end command.

DETAILED STEPS

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# interface Serial0/2/1/0/1/1/1:0

RP/0/RSP0/CPU0:router(config-if)# l2transport

RP/0/RSP0/CPU0:router(config-if-l2)# end

RP/0/RSP0/CPU0:router(config)# l2vpn

RP/0/RSP0/CPU0:router(config-l2vpn)# xconnect group grp_1

RP/0/RSP0/CPU0:router(config-l2vpn-xc)# p2p 1

RP/0/RSP0/CPU0:router(config)# interface Serial0/2/1/0/1/1/1:0

RP/0/RSP0/CPU0:router(config)# interface GigabitEthernet0/0/0/1.1

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interworking ipv4

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interface Serial0/0/0/0/2/1/1:0

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interface Serial0/0/0/0/2/1/1:0

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interface Serial0/0/0/0/2/1/1:0

RP/0/RSP0/CPU0:router (config-l2vpn-xc-p2p-pw)# pw-class class_cem

RP/0/RSP0/CPU0:router (config-l2vpn-xc-p2p-pw)# exit

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interworking ipv4

SUMMARY STEPS

1. configure
2. interface typeinterface-path-id
3. multilink [fragment|interleave|ncp]
4. l2transport
5. end
6. l2vpn
7. xconnect group group-name
8. p2p xconnect-name
9. interface typeinterface-path-id
10. interface typeinterface-path-id
11. interworking ipv4
12. interface typeinterface-path-id
13. neighbor{A.B.C.D}{pw-idvalue}
14. pw-classclass-name
15. exit
16. interworking ipv4
17. Use the commit or end command.

DETAILED STEPS

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# interface Multilink0/2/1/0/1 

RP/0/RSP0/CPU0:router(config-if)# multilink

RP/0/RSP0/CPU0:router(config-if-multilink)# l2transport

RP/0/RSP0/CPU0:router(config-if-l2)# end

RP/0/RSP0/CPU0:router(config)# l2vpn

RP/0/RSP0/CPU0:router(config-l2vpn)# xconnect group grp_1

RP/0/RSP0/CPU0:router(config-l2vpn-xc)# p2p 1

RP/0/RSP0/CPU0:router(config)# interface Serial0/2/1/0/1/1/1:0

RP/0/RSP0/CPU0:router(config)# interface GigabitEthernet0/0/0/1.1

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interworking ipv4

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interface Serial0/0/0/0/2/1/1:0

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# neighbor 120.120.120.120 pw-id 3

RP/0/RSP0/CPU0:router (config-l2vpn-xc-p2p-pw)# pw-class class_cem

RP/0/RSP0/CPU0:router (config-l2vpn-xc-p2p-pw)# exit

RP/0/RSP0/CPU0:router(config-l2vpn-xc-p2p)# interworking ipv4

Perform these tasks to configure CEoP:

SUMMARY STEPS

1. configure
2. l2vpn
3. nsr
4. logging nsr
5. Use the commit or end command.

DETAILED STEPS

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# l2vpn

RP/0/RSP0/CPU0:router (config-l2vpn)# nsr

RP/0/RSP0/CPU0:router (config-l2vpn)# logging nsr

SUMMARY STEPS

1. configure
2. mpls ldp
3. nsr
4. Use the commit or end command.

DETAILED STEPS

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# mpls ldp

RP/0/RSP0/CPU0:router(config-ldp)# nsr

Perform these tasks to configure the L2TPv3 over IPv6 tunnels: