Contents

1   Overview

This document provides an overview of Virtual Private LAN Services (VPLS) and describes the tasks and commands used to configure, operate, monitor, and troubleshoot VPLS features through the SmartEdge® router.

VPLS enables networks at separate geographical locations to communicate with each other across a WAN as if they were directly attached to each other in a LAN. Creating VPLS pseudowires (PWs) makes the WAN transparent.

A PW emulates the attributes and function of Ethernet connectivity over a WAN. Any required switching functionality or service translation is outside the scope of the pseudowire and of the transport network. Pseudowires are carried over Multiprotocol Label Switching (MPLS) tunnels on the network.

MPLS signaling protocols are used to automatically provision a service on a PW end-to-end, so you can provision a PW by pointing to its two endpoints, and MPLS automatically negotiates the path.

Figure 1 displays the network topology for a typical VPLS configuration.

Customer edge (CE) routers, which are on the edge of geographically separate customer networks, are connected by Ethernet to provider edge (PE) routers on an MPLS provider network. A PW is established for each pair of CE routers that are to be connected into a virtual private LAN. For example, the PW_1 pseudowire is used to connect the CE_1 and CE_3 routers. The CE_4, and CE_5 routers connect with the CE_1 router over the VPLS network, but not necessarily to each other.

To create PWs, a VPLS-enabled bridge must first be configured on each PE router, and then peering (neighbor) sessions can be established across that bridge. The PW is the circuit across which the peering session occurs. A VPLS-enabled bridge can have multiple peering sessions.

VPLS supports pseudowire load balancing, RSVP object tracking, and VCCV on pseudowires, as described in the sections that follow.

For procedures to troubleshoot issues with VPLS, see Troubleshooting VPLS.

1.1   Pseudowire Load Balancing

Pseudowire load balancing is supported for VPLS traffic. By default, load balancing is disabled, and traffic from all channels of a pseudowire traverse the same path. When load balancing is enabled, traffic from individual IPTV channels in a pseudowire is distributed among the links in the link group. The load balancing scheme for each pseudowire is based on source and destination information. Use the pseudowire multi-path command in global configuration mode to enable load balancing on all VPLS pseudowires configured on the router or in the current context. Be aware that load balancing is enabled and disabled in global configuration mode; this means that load balancing is globally enabled or disabled for all pseudowires that are configured on the router.

The SmartEdge router supports the mapping of traffic from a PW carrying traffic from a given VPLS instance to a specific RSVP tunnel. The SmartEdge router maps all MPLS traffic exiting the PW to a specific tunnel destined for the peer of the VPLS instance.

1.2   RSVP Object Tracking

In a typical hub-and-spoke network configuration, link aggregation nodes communicate with maximum transmission units (MTUs) through access nodes in a pseudowire-to-RSVP-tunnel configuration. In VPLS networks that use RSVP, an RSVP object tracking feature can be enabled to ensure that a MTU does not lose connectivity to the required link aggregation nodes if a link failure occurs between the MTU and its primary access node. When a primary access node loses connectivity to its associated aggregation nodes, the RSVP object tracking feature transparently changes MTU connectivity to a standby access node, and traffic flow continues uninterrupted.

Configuring RSVP object tracking is a three-step process:

1. Determine which interfaces need to be tracked. To track these interfaces, you must include them in an RSVP tracking object, as described in step 2.
2. On the primary access node, create an RSVP tracking object. A tracking object typically contains all the interfaces that exist between an access node and its associated link aggregation nodes.
3. On the primary access node, apply the tracking object name to the primary RSVP LSP or LSPs that must track the interfaces in that object.

The state of an RSVP object is reflected by its associated LSPs. If an RSVP tracking object is up, then the LSPs that reference that tracking object remain up. If an RSVP tracking object goes down, then the LSPs that reference that tracking object go down. When an RSVP tracking object is down, the RSVP LSPs that are tracking that object switch over to the standby spoke. In this case, the MTU switches over from the primary access node to the standby access node so that it does not lose connectivity to the aggregation nodes. After an access node loses connectivity to the aggregation nodes, RSVP continuously attempts to restore the down interfaces between the aggregation node and the access node. When at least one of the aggregation-facing interfaces comes back up and remains stable for five minutes, the tracking object that contains that interface comes back up, and connectivity transparently changes back to the primary access node.

Figure 2 shows an example of a hub-and-spoke network that has RSVP object tracking configured:

In Figure 2, the interfaces 1, 2, and 3 belong to a single tracking object. If all three of those interfaces go down, then MTU-1 switches over from the a primary spoke (carried within tunnel MTU1-AC1 ) to the standby spoke (carried within tunnel MTU1-AC2 ) and accesses the aggregation routers (AG-1 and AG-2) through the standby access node (AC-2). If any one of the down interfaces (interface 1, 2, or 3) comes back up and remains stable for five minutes, then MTU-1 switches back over to MTU1-AC1, and accesses the aggregation nodes through the primary access server (AC-1 ) once again. In addition, if MTU1-AC1 itself goes down, then MTU-1 switches over to the standby spoke until MTU1-AC1 becomes available again.

1.3   VCCV on Pseudowires

LDP uses the Virtual Circuit Connectivity Verification (VCCV) protocol during PW setup for connectivity verification. VCCV provides a control channel on a pseudowire over which connectivity verification messages are sent.

1.3.1   Including Control Words

You can choose to include a control word in the PW cell header. The control word is used to detect packet reordering and packet loss, and to perform ECMP path avoidance and various OAM tasks.

The control word can be enabled for both ATM and Ethernet PWs. However, control-word functionality is somewhat different between ATM and Ethernet PWs. These differences are described in the sections that follow.

1.3.1.1   Control Word on ATM PWs

All ATM pseudowire cross-connections allow you to enable or disable the inclusion of a four-byte PW control word after the MPLS labels. The control word contains the following fields:

• 16-bit packet sequence number used to detect packet reordering and packet loss
• Payload length

The sequence number is 16-bits and ranges from 1 through 65535. Sequence numbers are added to the control word incrementally, and the number wraps to 1 after reaching the maximum value. The inclusion of a sequence number ensures that packets are reordered properly if they become disassembled while traveling over the pseudowire.

Note:  

With n-to-1 cell encapsulation, the control word is optional.

Use the control-word command in L2VPN XC group configuration mode to enable inclusion of a control word in an ATM PW cell header. After you enable inclusion of the control word, the SmartEdge OS includes a single control word for the specified cross-connection group. The control word is applied to all pseudowires configured under the particular group.

To disable inclusion of a sequence number, enter the control-word sequence-number 0 command in the appropriate command mode.

1.3.1.2   Control Word on Ethernet PWs

All Ethernet pseudowire cross-connections that are not statically defined now allow you to enable or disable the inclusion of a control word between the Ethernet Frame and the MPLS label. The use of the control word ensures that all traffic for a given label stack follows the same path if hashing occurs while ECMP exists. When the control word is present, all traffic follows a single path because further lookups for the packet do not occur. The control word also permits the VCCV packet to follow the same path through the data plane that is taken by the PW data packets. Because sequencing is not required for Ethernet PWs, the Ethernet control word is made up of all zeroes. The control word is supported on both tagged and untagged Ethernet frames.

During Ethernet PW setup, LDP advertises the control word capability to the underlying PW. If the peer does not have control word capabilities enabled, then the control word is not included in the header of the packets that are sent over the PW.

Note:  

The control word is not available for Ethernet PWs that are statically defined.

Use the control-word command in the appropriate mode to enable the inclusion of a sequence number in an Ethernet PW cell header, as follows:

• VPLS profile neighbor configuration mode—Configures the control word attribute for a VPLS neighbor in a VPLS profile. The attributes in the VPLS profile are automatically applied to the XC to which the profile is attached.
• L2VPN profile peer configuration mode—Configures the control word setting in an L2VPN profile. The attributes in the L2VPN profile are automatically applied to the XC to which the profile is attached.

Note:  

This feature is available on VPLS and L2VPN Ethernet and VLAN PWs only. Be aware that this feature is not operational on L2VPN or VPLS PWs that are configured over a GRE tunnel.

1.3.2   VCCV Capability Negotiation During PW Setup

The VCCV-capable PW setup feature provides the following functionality for L2VPN or VPLS PWs:

• When a user first configures VPLS peers or L2VPNs, LDP advertises the following local VCCV capabilities to the underlying PWs:
  • CC-Type=0x01—Pseudowire Emulation Edge to Edge (pwe3) control word with 0001 as the first bit. Be aware that CC-Type=0x01 is advertised only if the control word is enabled in an L2VPN XC group or in a L2VPN or VPLS profile with the control-word command.
  • CC-Type=0x02—Router Alert Label
  • CV-Type=0x02—LSP ping

  Note:  

  If the control word is not enabled in an L2VPN XC group or in an L2VPN or VPLS profile, then only CC-Type=0x02 and CV-Type=0x02 are advertised.

  
  
• During PW setup, LDP engages in the following VCCV capability negotiation:
  • If only CC-Type=0x01 is received from the peer, the PW uses CC-Type=0x01 for VCCV.
  • If only CC-Type=0x02 is received from the peer, the PW uses CC-Type=0x02 for VCCV
  • If both CC-Type=0x01 and CC-Type=0x02 are received from the peer, the PW uses CC-Type=0x01 for VCCV. Be aware that CC-Type=0x01 takes precedence over CC-Type=0x02.
  • If no VCCV capability is received from the peer, the PW is set up without VCCV capabilities.
• When LM processes are restarted, the PW objects within the SEOS are recreated with the existing VCCV capabilities. The VCCV capabilities of the PWs that are being recreated are not renegotiated.
• When the primary XCRP fails over to the backup XCRP, PWs are recreated from the synchronized shared memory. The VCCV capabilities of those PWs are maintained, and no VCCV capability negotiation occurs.

Note:  

If the PW is negotiated with only VCCV CC Type 2 for MPLS PSNs, VCCV traffic may not follow the same path as the data traffic if ECMP is applied to the outer LSP label.

1.3.3   PW Connectivity and VCCV Capability Verification

When end-user packets do not reach their destination, you can verify the connectivity of the PWs associated with the target L2VPN or L2VPN instance. Use the ping mpls pw pw-id command to verify connectivity of PWs in the following situations:

• When end-user packets do not reach their destination
• When the remote end experiences loss of packet or high RTT

If the SmartEdge router is on the middle of a PW and the PW failure is at that SmartEdge router, the SmartEdge router responds to the ping and indicates that it is not the egress point for the PW. The ping response helps the administrator identify the point of failure.

You can also use the ping mpls pw pw-id command on the data plane to verify whether a target PW is VCCV capable. If a PW is not VCCV capable, the following error message is displayed and the operation is terminated:

Pseudo-wire is not VCCV capable.  Ping aborted.

If the PW is VCCV capable, the VCCV ping retrieves the following information from the PW:

• PW encapsulation details
• Next-hop and adjacency details

Note:  

When using the ping mpls pw pw-id command to verify VCCV capabilities, do not include the control-plane keyword in the command string.

Note:  

If a router at the remote end of the ping is running a version of the SmartEdge OS earlier than Release 6.1.3, you must include the send-mode and control-plane keywords in the ping mpls pw pw-id command on the local router to ensure that the ping is sent over the control plane. In releases prior to 6.1.3, the router could send pings only over the control plane.

To verify the remote and local VCCV capabilities for all L2VPN LDP PWs currently configured on your system, use the show ldp l2vpn fec detail command in any mode.

2   Configuration and Operations Tasks

Configuration of VPLS in a SmartEdge router context requires the following basic steps:

1. Setup of the MPLS core background

   The MPLS core must be up and running before configuring VPLS. For instructions on configuring MPLS, see Configuring MPLS.

2. Setup of Label Distribution Protocol (LDP) between PE peers

   LDP targeted discovery must be enabled between PE peers before configuring VPLS. For more information on configuring LDP targeted discovery, see “Targeted LDP” in Configuring LDP.

3. Setup of a VPLS profile in which the IP addresses of the VPLS neighbors must be entered

   Detailed instructions and notes are found in Section 2.2.

4. Setup of the VPLS-enabled bridge

   For procedures to troubleshoot issues with VPLS, see Troubleshooting VPLS.

   Detailed configuration instructions are found in Section 2.3. You must include the following in this step:

   • The name of the VPLS profile (from step 3)
   • The pseudowire IDs that pass through the LAN to the other routers in the MPLS backbone
   • The names of the bridging-capable interfaces bound to CE devices that use the VPLS bridge

Note:  

Additional configuration options might be required depending on the application for which you are configuring VPLS.

2.1   Configuring a Bridge Profile

You can assign a named bridge profile to a neighbor. When the subscriber circuit is bound to a bridged interface, the attribute values in the named bridge profile assigned to the neighbor override those in the default bridge profile for the circuit, unless the circuit is also assigned a named bridge profile.

The configuration of bridge profiles is described in the "Configure Bridge Profiles" section of the Configuring Bridging document.

2.2   Configuring a VPLS Profile

A VPLS profile contains one or more neighbors, with each neighbor defining the attributes necessary to establish a separate peer instance (pseudowire) to a remote PE device. When a VPLS profile is assigned to a VPLS-enabled bridge, the bridge uses the neighbors in the profile to establish the peer instances and enable bridging over the pseudowires.

To configure a VPLS profile (with one or more neighbors), perform the tasks described in Table 1. Enter all commands in VPLS profile neighbor configuration mode, unless otherwise noted.

2.3   Configuring a VPLS-Enabled Bridge

A VPLS-enabled bridge is used to establish peer instances to neighbors.

To configure a VPLS-enabled bridge, perform the tasks described in Table 2. Enter all commands in VPLS configuration mode, unless otherwise noted.

2.4   Configuring a Pseudowire-to-RSVP LSP Tunnel

The SmartEdge router supports the mapping of traffic from a PW carrying traffic from a given VPLS instance to a specific RSVP tunnel. You can administratively select an RSVP tunnel to carry traffic that is sent to a specific neighbor.To configure the mapping of traffic from a PW carrying traffic from a given VPLS instance to a specific RSVP tunnel, perform the tasks described in Table 3.

2.5   Configuring RSVP Object Tracking

This section provides information for configuring RSVP object tracking on a SmartEdge router in a hub-and-spoke area.

Before you can configure RSVP object tracking in a hub-and-spoke area, you must perform the following tasks:

• You must have VPLS with RSVP enabled in the appropriate hub-and-spoke area of your network.
• You need to have configured all the required pseudowires between the access nodes and the aggregation nodes.
• You need to have configured all of the required LSP tunnels between the MTUs and the access nodes.

Consider the following restrictions before configuring RSVP object tracking in a hub-and-spoke area:

• Backup LSPs cannot be configured to track objects.
• Only RSVP LSPs can monitor tracked objects.
• The maximum number of interfaces that can be tracked by a single object is 10.
• The maximum number of LSPs that can track a single RSVP tracking object is 50.

To configure RSVP object tracking in a hub-and-spoke area, perform the tasks described in Table 4.

2.6   Configuring L2TPv3 Lite Tunnels on VPLS Pseudowires

This section describes the configuration of VPLS pseudowires to function as L2TPv3 lite tunnels that terminate in a VPLS instance. L2TPv3 lite tunnel service is a useful way to provide Layer 2 tunneling service over a non-MPLS based IP backhaul network.

2.6.1   SmartEdge Router L2TPv3 Lite Tunnel Behavior

The configuration of the SmartEdge router for L2TPv3 lite tunnels encapsulated in VPLS pseudowires includes a step in which the static encapsulation l2tpv3 command specifies a static L2TPv3 encapsulation consisting of a 32-bit session ID and 32-bit cookie.

Figure 4 shows how the SmartEdge router implements the L2TPv3 header with the embedded MPLS stack.

• When a packet is sent from the router over the VPLS pseudowire, it adds the L2TPv3 header to the inner MPLS packet. The L2TPv3 header is followed by a 32-bit MPLS label stack. When a non-MPLS remote peer receives a packet on the tunnel, it treats the packet as if it is an L2TPv3 packet sent with a 64-bit cookie.
• When an L2TPv3 packet is received by the SmartEdge router, it treats the packet as a L2TPv3 packet with a 64-bit cookie. The SmartEdge router strips off the session ID and 32-bit cookie and extracts the 32-bit MPLS label stack embedded in the lower 32 bits of the cookie. The embedded MPLS label stack then identifies the VPLS pseudowire corresponding to the tunnel, and the packet is injected into the corresponding VPLS instance.

2.6.2   Requirements and Restrictions (L2TPv3 Tunnels on VPLS Pseudowires)

• Only statically configured L2TPv3 tunnels (RFC 3931) are supported, and only the data plane specifications recommended in RFC 3391 are supported. The signal plan specifications are not supported.
• If you configure a large number of L2TPv3 tunnels, the chassis bootup and switchover time are slowed.
• When QoS propagation is enabled for static L2Tpv3 encapsulation, the MPLS EXP values are updated as well. This can cause remote peers that validate the cookie to drop packets. As a workaround, configure class maps to set the EXP bits to 0.

2.6.3   Example (L2TPv3 Tunnel on a VPLS Pseudowire with QoS)

The following example shows the configuration of rock1200 which is part of a VPLS bridge that includes two other PE routers. The VPLS pseudowire between rock1200 and jazz has an L2TPv3 tunnel configured in it. The pseudowire ID is 20. The L2TPv3 tunnel is statically configured in VPLS pseudowire 20 with a session-id of 30 for incoming packets and 30 for outgoing packets.

[local]rock1200#show config
Building configuration...

Current configuration:
!
!  Configuration last changed by user 'test' at Wed May 26 12:07:04 2010
!
!
service multiple-contexts
!
!
!
! VPLS global configuration
vpls profile P11
  neighbor 67.1.1.2
    pw-label in 5001 out 5001
    static encapsulation l2tpv3 session-id in 30 out 30
    static encapsulation l2tpv3 cookie out 32 0 15
! Additional neighbors can be configured
!
qos class-map pd-to-exp mpls out
 qos 1 to mpls 0
 qos 2 to mpls 0
 qos 3 to mpls 0
 qos 4 to mpls 0
 qos 5 to mpls 0
 qos 6 to mpls 0
 qos 7 to mpls 0
 qos 8 to mpls 0
 qos 9 to mpls 0
 qos 10 to mpls 0
 qos 11 to mpls 0
 qos 12 to mpls 0
 qos 13 to mpls 0
 qos 14 to mpls 0
 qos 15 to mpls 0
 qos 16 to mpls 0
 qos 17 to mpls 0
 qos 18 to mpls 0
 qos 19 to mpls 0
 qos 20 to mpls 0
 qos 21 to mpls 0
 qos 22 to mpls 0
 qos 23 to mpls 0
 qos 24 to mpls 0
 qos 25 to mpls 0
 qos 26 to mpls 0
 qos 27 to mpls 0
 qos 28 to mpls 0
 qos 29 to mpls 0
 qos 30 to mpls 0
 qos 31 to mpls 0
 qos 32 to mpls 0
 qos 33 to mpls 0
 qos 34 to mpls 0
 qos 35 to mpls 0
 qos 36 to mpls 0
 qos 37 to mpls 0
 qos 38 to mpls 0
 qos 39 to mpls 0
 qos 40 to mpls 0
 qos 41 to mpls 0
 qos 42 to mpls 0
 qos 43 to mpls 0
 qos 44 to mpls 0
 qos 45 to mpls 0
 qos 46 to mpls 0
 qos 47 to mpls 0
 qos 48 to mpls 0
 qos 49 to mpls 0
 qos 50 to mpls 0
 qos 51 to mpls 0
 qos 52 to mpls 0
 qos 53 to mpls 0
 qos 54 to mpls 0
 qos 55 to mpls 0
 qos 56 to mpls 0
 qos 57 to mpls 0
 qos 58 to mpls 0
 qos 59 to mpls 0
 qos 60 to mpls 0
 qos 61 to mpls 0
 qos 62 to mpls 0
 qos 63 to mpls 0
!
qos class-map pd-to-ip ip out
!
!
!
!
context local
!
 no ip domain-lookup
!
 interface loopback_rock1200 loopback
  ip address 10.10.10.2/32
!
 interface mgmt
  ip address 10.18.17.103/24
!
 interface to_jazz
  ip address 192.168.1.2/24
  propagate qos to ip class-map pd-to-ip
 logging console
!
 ip soft-gre source 10.10.10.2
!
 router mpls
  propagate qos to mpls class-map pd-to-exp
  interface loopback_rock1200
  interface to_jazz
!
!
 administrator test encrypted 1 $1$........$kvQfdsjs0ACFMeDHQ7n/o.
   privilege start 15
!
!
 ip route 67.1.1.2/32 192.168.1.1
 ip route 155.53.0.0/16 10.18.17.254
 ip route 155.53.0.0/16 10.18.49.254
!
!
!
!
context yellow
!
 no ip domain-lookup
!
 interface bridge-if bridge
  bridge name A
 no logging console
!
 bridge A
  vpls
   profile P11 pw-id 20
!
!
!
!
!
! ** End Context **
 logging tdm console
 logging active
 logging standby short
!
!
!
!
port ethernet 7/1
! XCRP management ports on slot 7 and 8 are configured through 7/1
 no shutdown
 bind interface mgmt local
!
card ge-20-port 9
!
port ethernet 9/1
 no shutdown
 bind interface to_jazz local
!
 system hostname rock1200
 timeout session idle 9999
!
no service console-break
!
service crash-dump-dram
!
no service auto-system-recovery
!
end

2.6.4   Configuring L2TPv3 Tunnels on VPLS Pseudowires with QoS

This configuration procedure constructs a QoS-provisioned L2TPv3 tunnel on the VPLS pseudowire connection between a local SmartEdge router and a remote PE router.

The configuration steps are specific to the rock1200 SmartEdge router in the example configuration in Section 2.6.3; however, you can substitute in your own network specifics.

To configure L2TPv3 Tunnels on VPLS Pseudowires with QoS, do the following:

1. Configure an interface to the remote PE router (jazz) and a static route to the loopback address of the remote customer edge (CE) router (jazz). The remote CE router could be either directly connected or multiple hops away.

   context local
    ip route 67.1.1.2/32 192.168.1.1
    interface to_jazz
     ip address 192.168.1.2/24
   

2. Enable MPLS routing in the local context of the SmartEdge router.
   • Configure a loopback interface address for the local MPLS router.
   • Enable soft-GRE for that router using the loopback address.
   • Enable MPLS on all interfaces that bind to the local context with the following commands.

   context local
    interface loopback_rock1200 loopback
     ip address 10.10.10.2/32
   !
    router mpls
     ip soft-gre source 10.10.10.2
     interface to_jazz
     interface loopback_rock1200
   

3. Enter VPLS profile configuration mode and do the following:
   1. Configure the IP address in the neighbor statement with the loopback address of the remote PE router.
   2. Configure static inbound and outbound pseudowire labels.
   3. Use the static encapsulation l2tpv3 command to configure the L2TPv3 session ID and cookie.

      The session ID for incoming and outgoing packets must be identical and consistent with the configuration on the remote peer PE router. The cookie configuration must also be consistent with the configuration of the peer PE router.

      All other attributes in VPLS profile configuration attributes are optional.

   vpls profile  P11
    neighbor 67.1.1.2
     pw-label in 5001 out 5001
     static encapsulation l2tpv3 session-id in 30 out 30
     static encapsulation l2tpv3 cookie out 32 0 15

4. In any context other than the local context, configure a bridge instance and bridge interface and apply the VPLS profile to the bridge.

   The local context is conventionally used for interfaces to PE routers, while other contexts are conventionally used for interfaces to CE routers. This configuration deviates from that convention.

   context yellow
    interface bridge-if bridge
     bridge name A
    bridge A
     vpls
      profile P11 pw-id 20
   

5. Bind the attachment circuits and other VPLS peers (using VPLS profiles) to the bridge instance.

   This step is not illustrated.

6. Before enabling QoS propagation for static L2TPv3 encapsulation, you must first configure two class maps for outgoing packets transmitted by the rock1200 SmartEdge router.
   • The first class map (pd-to-exp) sets the EXP bits values to 0. This prevents QoS from updating the MPLS EXP values as explained in Section 2.6.2.
   • The second class map (pd-to-ip) updates the outer IP DSCP values.

   qos class-map pd-to-exp mpls out
    qos 1 to mpls 0
    qos 2 to mpls 0
    qos 3 to mpls 0
    qos 4 to mpls 0
    qos 5 to mpls 0
    qos 6 to mpls 0
    qos 7 to mpls 0
    qos 8 to mpls 0
    qos 9 to mpls 0
    qos 10 to mpls 0
    qos 11 to mpls 0
    qos 12 to mpls 0
    qos 13 to mpls 0
    qos 14 to mpls 0
    qos 15 to mpls 0
    qos 16 to mpls 0
    qos 17 to mpls 0
    qos 18 to mpls 0
    qos 19 to mpls 0
    qos 20 to mpls 0
    qos 21 to mpls 0
    qos 22 to mpls 0
    qos 23 to mpls 0
    qos 24 to mpls 0
    qos 25 to mpls 0
    qos 26 to mpls 0
    qos 27 to mpls 0
    qos 28 to mpls 0
    qos 29 to mpls 0
    qos 30 to mpls 0
    qos 31 to mpls 0
    qos 32 to mpls 0
    qos 33 to mpls 0
    qos 34 to mpls 0
    qos 35 to mpls 0
    qos 36 to mpls 0
    qos 37 to mpls 0
    qos 38 to mpls 0
    qos 39 to mpls 0
    qos 40 to mpls 0
    qos 41 to mpls 0
    qos 42 to mpls 0
    qos 43 to mpls 0
    qos 44 to mpls 0
    qos 45 to mpls 0
    qos 46 to mpls 0
    qos 47 to mpls 0
    qos 48 to mpls 0
    qos 49 to mpls 0
    qos 50 to mpls 0
    qos 51 to mpls 0
    qos 52 to mpls 0
    qos 53 to mpls 0
    qos 54 to mpls 0
    qos 55 to mpls 0
    qos 56 to mpls 0
    qos 57 to mpls 0
    qos 58 to mpls 0
    qos 59 to mpls 0
    qos 60 to mpls 0
    qos 61 to mpls 0
    qos 62 to mpls 0
    qos 63 to mpls 0
    exit
   !
   qos class-map pd-to-ip ip out

7. Enable QoS propagation on the MPLS router and the interface to the VPLS peer.

   context local
    router mpls
     propagate qos to mpls class-map pd-to-exp
   !
    interface to_jazz
     propagate qos to ip class-map pd-to-ip
   

2.7   Verifying PW Connectivity and VCCV Capabilities

To verify PW connectivity and VCCV capabilities, perform the tasks described in Table 5. Enter the ping mpls pw command in exec mode.

2.8   VPLS Operations

To manage VPLS functions, perform the appropriate tasks described in Table 6. Enter the show commands in any mode; enter the debug commands in exec mode.

3   Configuration Examples

The VPLS configuration examples provided in this section assume that the following conditions are true:

• MPLS core backbone configuration is up and running.

  For more information on configuring MPLS, see Configuring MPLS.

• LDP targeted discovery has been enabled between PE peers.

  For more information on configuring LDP targeted discovery, see Targeted LDP in Configuring LDP.

3.1   Bridge Profile

The following configuration example how to create two bridge profiles, 100Mbps-bc and 120Mbps-mc. The 100Mbps-bc bridge profile sets a rate limit of 125 Mbps (12,500 kbps) for broadcast traffic on the VPLS pseudowire circuit to which this bridge profile is assigned. The 120Mbps-mc bridge profile sets a rate limit of 150 Mbps (15,000 kbps) for multicast traffic on the VPLS pseudowire circuit to which this bridge profile is assigned. The attributes of these bridge profiles will be applied to VPLS neighbor configurations:

[local]Redback#config
[local]Redback(config)#bridge profile 100Mbps-bc
[local]Redback(config-bridge-profile)#broadcast rate-limit 12500000
[local]Redback(config-bridge-profile)#exit
[local]Redback(config)#bridge profile 120Mbps-mc
[local]Redback(config-bridge-profile)#multicast rate-limit 15000000
[local]Redback(config-bridge-profile)#end

3.2   VPLS Profile

The following configuration example shows how to create a VPLS profile, vprofile1, and two neighbors, 64.10.192.112 and 110.32.164.5. The attributes from the bridge profile, 100Mbps-bc, are applied to the neighbor given the description, dallas-to-nyc. The attributes from the bridge profile, 120Mbps-mc, are applied to the neighbor given the description, dallas-to-sfo. The neighbor attributes in this bridge profile will be applied to VPLS-enabled bridge instance:

[local]Redback#config
[local]Redback(config)#vpls profile vprofile1
[local]Redback(config-vpls-profile)#neighbor 64.10.192.112
[local]Redback(config-vpls-profile-neighbor)#description dallas-to-nyc
[local]Redback(config-vpls-profile-neighbor)#bridge-profile 100Mbps-bc
[local]Redback(config-vpls-profile-neighbor)#exit
[local]Redback(config-vpls-profile)#neighbor 110.32.164.5
[local]Redback(config-vpls-profile-neighbor)#description dallas-to-sfo
[local]Redback(config-vpls-profile-neighbor)#bridge-profile 120Mbps-mc
[local]Redback(config-vpls-profile-neighbor)#end

3.3   VPLS-Enabled Bridge

The following configuration example shows how to create a VPLS-enabled bridge instance, truecom.net, configures a default pseudowire number, 100, for this instance, and applies the attributes from the VPLS profile, vprofile1, to this instance:

[local]Redback#config
[local]Redback(config)#context local
[local]Redback(config-ctx)#bridge truecom.net
[local]Redback(config-bridge)#vpls
[local]Redback(config-vpls)#pw-id 100
[local]Redback(config-vpls)#profile vprofile1
[local]Redback(config-vpls)#end

3.4   Pseudowire-to-RSVP LSP Tunnel Traffic Mapping

The following example shows how to map traffic exiting a PW to a specific VPLS instance. :

[local]Redback#config
[local]Redback(config)#vpls profile blue
[local]Redback(config-vpls-profile)#neighbor 110.32.164.5
[local]Redback(config-vpls-profile-neighbor)#tunnel lsp blue005
[local]Redback(config-vpls-profile-neighbor)#exit
[local]Redback(config-vpls-profile)#exit
[local]Redback(config)#context local
[local]Redback(config-ctx)#bridge local-x vpls
[local]Redback(config-bridge)#vpls profile blue
[local]Redback(config-bridge)#end

3.5   RSVP Object Tracking

The following example describes how to configure RSVP object tracking on the example network shown in Figure 2.

On the appropriate access node, create a tracking object called san-jose-1 and add interfaces 1, 2, and 3 to san-jose-1:

[local]Redback#configure
[local]Redback(config)#context local
[local]Redback(config-ctx)#router rsvp
[local]Redback(config-rsvp)#track san-jose-1
[local]Redback(config-rsvp-track_obj)#interface 1
[local]Redback(config-rsvp-track_obj)#interface 2
[local]Redback(config-rsvp-track_obj)#interface 3

On the access node, configure the RSVP LSP called MTU1-AC1 to track the interfaces contained in the object called san-jose-1:

[local]Redback#config
[local]Redback(config)#context local
[local]Redback(config-ctx)#router rsvp
[local]Redback(config-rsvp)#lsp MTU1-AC1
[local]Redback(config-rsvp-lsp)#track san-jose-1
[local]Redback(config-rsvp-lsp)#exit
[local]Redback(config-rsvp)#

After committing the configuration, verify that the tracking object is up and tracking the appropriate interfaces:

[local]Redback#show rsvp track san-jose-1
Track Object san-jose-1 is UP
   Number of members: 3      RSVP interface:1 is DOWN       RSVP interface:2 is DOWN
   RSVP interface:3 is UP    Tracked by 1 observers
    RSVP LSP:MTU1-AC1