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.

Cisco ASR 9000 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.

Figure 5. L2VPN QoS Feature Application

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).

Figure 6. L2VPN QoS Reference Model

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.

Figure 7. Multisegment Pseudowire: Example

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.

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.

Figure 8. IP Interworking over MPLS Core

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.

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.

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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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

1.    configure

2.    l2vpn

3.    pw-oam refresh transmit seconds

4.    endorcommit

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

1.    configure

2.    l2vpn

3.    load-balancing flow {src-dst-mac | src-dst-ip}

4.    endorcommit

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

1.    configure

2.    l2vpn

3.    pw-class {name}

4.    encapsulation mpls

5.    load-balancing pw-label

6.    endorcommit

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

1.    configure


2.    l2vpn


3.    pw-grouping


4.    Use the commit or end command.

RP/0/RSP0/CPU0:router# configure

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

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

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]

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 

1.    configure


2.    l2vpn


3.    xconnect groupgroup-name


4.    p2pxconnect-name


5.    interworking ipv4


6.    Use the commit or end command.

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

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

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

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.

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

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.

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