Implementing Multipoint Layer 2 Services

This module provides the conceptual and configuration information for Multipoint Layer 2 Bridging Services, also called Virtual Private LAN Services (VPLS).

Note

VPLS supports Layer 2 VPN technology and provides transparent multipoint Layer 2 connectivity for customers. This approach enables service providers to host a multitude of new services such as broadcast TV and Layer 2 VPNs.

For Point to Point Layer 2 Services, see Implementing Point to Point Layer 2 Services chapter.

For descriptions of the commands listed in this module, see the “Related Documents” section. To locate documentation for other commands that might appear while executing a configuration task, search online in the Cisco IOS XR software master command index.

Feature History for Implementing Multipoint Layer 2 Services


Release	Modification
Release 3.7.2	This feature was introduced.
Release 3.9.0	These features were added: Blocking unknown unicast flooding. Disabling MAC flush. Multiple Spanning Tree Access Gateway Scale enhancements were introduced. See Table 1 for more information on scale enhancements.
Release 3.9.1	Support for VPLS with BGP Autodiscovery and LDP Signaling was added.
Release 4.0.1	Support was added for the following features: Dynamic ARP Inspection IP SourceGuard MAC Address Security
Release 4.1.0	Support was added for these VPLS features on the ASR 9000 SIP-700 line card: MAC learning and forwarding. MAC address aging support MAC Limiting Split Horizon Group MAC address Withdrawal Flooding of unknown unicast, broadcast and multicast packets Access pseudowire H-VPLS PW-access PW redundancy Support was added for the G.8032 Ethernet Ring Protection feature.
Release 4.2.1	Support was added for Flow Aware Transport (FAT) Pseudowire feature.
Release 4.3.0	Support was added for these features: Pseudowire Headend (PWHE) Scale enhancements on ASR 9000 Enhanced Ethernet line card: Support for 128000 pseudowires within VPWS and VPLS Support for 128000 pseudowires across VPLS and VPWS instances Support for upto 512 pseudowires in a bridge Support for 128000 bundle attachment circuits Support for 128000 VLANs L2VPN over GRE
Release 4.3.1	Support was added for: VC type 4 in VPLS with BGP Autodiscovery IPv6 support for PWHE
Release 5.1.0	Support was added for Multipoint Layer 2 Services Label Switched Multicast feature.
Release 5.1.1	Support was added for: Pseudowire Headend PW-Ether sub-interfaces (VC Type 5) and Pseudowire Headend PW-IW interworking interfaces (VC Type 11) LFA over Pseudowire Headend.
Release 6.1.2	Support was added for: Service Path Preference for L2VPN L2VPN Route Policy

Prerequisites for Implementing Multipoint Layer 2 Services

Before configuring Multipoint Layer 2 Services, ensure that these tasks and conditions are met:

You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command.

If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
Configure IP routing in the core so that the provider edge (PE) routers can reach each other through IP.

Configure a loopback interface to originate and terminate Layer 2 traffic. Make sure that the PE routers can access the other router's loopback interface.

Note

The loopback interface is not needed in all cases. For example, tunnel selection does not need a loopback interface when Multipoint Layer 2 Services are directly mapped to a TE tunnel.

Configure MPLS and Label Distribution Protocol (LDP) in the core so that a label switched path (LSP) exists between the PE routers.

Information About Implementing Multipoint Layer 2 Services

To implement Multipoint Layer 2 Services, you should understand these concepts:

Multipoint Layer 2 Services Overview

Multipoint Layer 2 Services enable geographically separated local-area network (LAN) segments to be interconnected as a single bridged domain over an MPLS network. The full functions of the traditional LAN such as MAC address learning, aging, and switching are emulated across all the remotely connected LAN segments that are part of a single bridged domain.

Some of the components present in a Multipoint Layer 2 Services network are described in these sections.

Note

Multipoint Layer 2 services are also called as Virtual Private LAN Services.

Bridge Domain

The native bridge domain refers to a Layer 2 broadcast domain consisting of a set of physical or virtual ports (including VFI). Data frames are switched within a bridge domain based on the destination MAC address. Multicast, broadcast, and unknown destination unicast frames are flooded within the bridge domain. In addition, the source MAC address learning is performed on all incoming frames on a bridge domain. A learned address is aged out. Incoming frames are mapped to a bridge domain, based on either the ingress port or a combination of both an ingress port and a MAC header field.

By default, split horizon is enabled for pseudowires under the same VFI. However, in the default configuration, split horizon is not enabled on the attachment circuits (interfaces or pseudowires).

Flood Optimization

A Cisco ASR 9000 Series Router, while bridging traffic in a bridge domain, minimizes the amount of traffic that floods unnecessarily. The Flood Optimization feature accomplishes this functionality. However, in certain failure recovery scenarios, extra flooding is actually desirable in order to prevent traffic loss. Traffic loss occurs during a temporary interval when one of the bridge port links becomes inactive, and a standby link replaces it.

In some configurations, optimizations to minimize traffic flooding is achieved at the expense of traffic loss during the short interval in which one of the bridge's links fails, and a standby link replaces it. Therefore, Flood Optimization can be configured in different modes to specify a particular flooding behavior suitable for your configuration.

These flood optimization modes can be configured:

Bandwidth Optimization Mode

Flooded traffic is sent only to the line cards on which a bridge port or pseudowire that is attached to the bridge domain resides. This is the default mode.

Convergence Mode

Flooded traffic is sent to all line cards in the system. Traffic is flooded regardless of whether they have a bridge port or a pseudowire that is attached to the bridge domain. If there are multiple Equal Cost MPLS Paths (ECMPs) attached to that bridge domain, traffic is flooded to all ECMPs.

The purpose of Convergence Mode is to ensure that an absolute minimum amount of traffic is lost during the short interval of a bridge link change due to a failure.

TE FRR Optimized Mode

The Traffic Engineering Fast Reroute (TE FRR) Optimized Mode is similar to the Bandwidth Optimized Mode, except for the flooding behavior with respect to any TE FRR pseudowires attached to the bridge domain. In TE FRR Optimized Mode, traffic is flooded to both the primary and backup FRR interfaces. This mode is used to minimize traffic loss during an FRR failover, thus ensuring that the bridge traffic complies with the FRR recovery time constraints.

Dynamic ARP Inspection

Dynamic ARP Inspection (DAI) is a method of providing protection against address resolution protocol (ARP) spoofing attacks. It intercepts, logs, and discards ARP packets with invalid IP-to-MAC address bindings. This capability protects the network from certain man-in-the-middle attacks. The DAI feature is disabled by default.

ARP enables IP communication within a Layer 2 broadcast domain by mapping an IP address to a MAC address. Spoofing attacks occur because ARP allows a response from a host even when an ARP request is not actually received. After an attack occurs, all traffic, from the device under attack, first flows through the attacker's system, and then to the router, switch, or the host. An ARP spoofing attack affects the devices connected to your Layer 2 network by sending false information to the ARP caches of the devices connected to the subnet. The sending of false information to an ARP cache is known as ARP cache poisoning.

The Dynamic ARP Inspection feature ensures that only valid ARP requests and responses are relayed. There are two types of ARP inspection:

Mandatory inspection—The sender’s MAC address, IPv4 address, receiving bridge port XID and bridge are checked.
Optional inspection—The following items are validated:
- Source MAC: The sender’s and source MACs are checked. The check is performed on all ARP or RARP packets.
- Destination MAC: The target and destination MACs are checked. The check is performed on all Reply or Reply Reverse packets.
- IPv4 Address: For ARP requests, a check is performed to verify if the sender’s IPv4 address is 0.0.0.0, a multicast address or a broadcast address. For ARP Reply and ARP Reply Reverse, a check is performed to verify if the target IPv4 address is 0.0.0.0, a multicast address or a broadcast address. This check is performed on Request, Reply and Reply Reverse packets.

Note

The DAI feature is supported on attachment circuits and EFPs. Currently, the DAI feature is not supported on pseudowires.

IP Source Guard

IP source guard (IPSG) is a security feature that filters traffic based on the DHCP snooping binding database and on manually configured IP source bindings in order to restrict IP traffic on non-routed Layer 2 interfaces.

The IPSG feature provides source IP address filtering on a Layer 2 port, to prevent a malicious hosts from manipulating a legitimate host by assuming the legitimate host's IP address. This feature uses dynamic DHCP snooping and static IP source binding to match IP addresses to hosts.

Initially, all IP traffic, except for DHCP packets, on the EFP configured for IPSG is blocked. After a client receives an IP address from the DHCP server, or after static IP source binding is configured by the administrator, all traffic with that IP source address is permitted from that client. Traffic from other hosts is denied. This filtering limits a host's ability to attack the network by claiming a neighbor host's IP address.

Note

The IPSG feature is supported on attachment circuits and EFPs. Currently, the IPSG feature is not supported on pseudowires.

Pseudowires

A pseudowire is a point-to-point connection between pairs of PE routers. Its primary function is to emulate services like Ethernet over an underlying core MPLS network through encapsulation into a common MPLS format. By encapsulating services into a common MPLS format, a pseudowire allows carriers to converge their services to an MPLS network.

The following scale enhancements are applicable to ASR 9000 Enhanced Ethernet line card:

Support for 128000 pseudowires within VPWS and VPLS
Support for 128000 pseudowires across VPLS and VPWS instances
Support for upto 512 pseudowires in a bridge

Note

This scale enhancement is supported in hardware configurations where RSP3 and ASR 9000 Enhanced Ethernet line cards are used. However, these enhancements are not applicable to the RSP2, ASR 9000 Ethernet Line Card and Cisco ASR 9000 Series SPA Interface Processor-700 line cards.

DHCP Snooping over Pseudowire

The Cisco ASR 9000 Series Routers provide the ability to perform DHCP snooping, where the DHCP server is reachable on a pseudowire. The Pseudowire is considered as a trusted interface.

The dhcp ipv4 snoop profile {dhcp-snooping-profile1 } command is provided under the bridge domain to enable DHCP snooping on a bridge and to attach a DHCP snooping profile to the bridge.

Virtual Forwarding Instance

VPLS is based on the characteristic of virtual forwarding instance (VFI). A VFI is a virtual bridge port that is capable of performing native bridging functions, such as forwarding, based on the destination MAC address, source MAC address learning and aging, and so forth.

A VFI is created on the PE router for each VPLS instance. The PE routers make packet-forwarding decisions by looking up the VFI of a particular VPLS instance. The VFI acts like a virtual bridge for a given VPLS instance. More than one attachment circuit belonging to a given VPLS are connected to the VFI. The PE router establishes emulated VCs to all the other PE routers in that VPLS instance and attaches these emulated VCs to the VFI. Packet forwarding decisions are based on the data structures maintained in the VFI.

VPLS for an MPLS-based Provider Core

VPLS is a multipoint Layer 2 VPN technology that connects two or more customer devices using bridging techniques. A bridge domain, which is the building block for multipoint bridging, is present on each of the PE routers. The access connections to the bridge domain on a PE router are called attachment circuits. The attachment circuits can be a set of physical ports, virtual ports, or both that are connected to the bridge at each PE device in the network.

After provisioning attachment circuits, neighbor relationships across the MPLS network for this specific instance are established through a set of manual commands identifying the end PEs. When the neighbor association is complete, a full mesh of pseudowires is established among the network-facing provider edge devices, which is a gateway between the MPLS core and the customer domain.

The MPLS/IP provider core simulates a virtual bridge that connects the multiple attachment circuits on each of the PE devices together to form a single broadcast domain. This also requires all of the PE routers that are participating in a VPLS instance to form emulated virtual circuits (VCs) among them.

Now, the service provider network starts switching the packets within the bridged domain specific to the customer by looking at destination MAC addresses. All traffic with unknown, broadcast, and multicast destination MAC addresses is flooded to all the connected customer edge devices, which connect to the service provider network. The network-facing provider edge devices learn the source MAC addresses as the packets are flooded. The traffic is unicasted to the customer edge device for all the learned MAC addresses.

In the MPLS provider core, the VPLS pseudowire traffic can be dynamically routed over any interface that supports LDP protocol.

VPLS Architecture

The basic or flat VPLS architecture allows for the end-to-end connection between the provider edge (PE) routers to provide multipoint ethernet services. Following figure shows a flat VPLS architecture illustrating the interconnection between the network provider edge (N-PE) nodes over an IP/MPLS network.

The VPLS network requires the creation of a bridge domain (Layer 2 broadcast domain) on each of the PE routers. The VPLS provider edge device holds all the VPLS forwarding MAC tables and bridge domain information. In addition, it is responsible for all flooding broadcast frames and multicast replications.

The PEs in the VPLS architecture are connected with a full mesh of Pseudowires (PWs). A Virtual Forwarding Instance (VFI) is used to interconnect the mesh of pseudowires. A bridge domain is connected to a VFI to create a Virtual Switching Instance (VSI), that provides Ethernet multipoint bridging over a PW mesh. VPLS network links the VSIs using the MPLS pseudowires to create an emulated Ethernet Switch.

With VPLS, all customer equipment (CE) devices participating in a single VPLS instance appear to be on the same LAN and, therefore, can communicate directly with one another in a multipoint topology, without requiring a full mesh of point-to-point circuits at the CE device. A service provider can offer VPLS service to multiple customers over the MPLS network by defining different bridged domains for different customers. Packets from one bridged domain are never carried over or delivered to another bridged domain, thus ensuring the privacy of the LAN service.

VPLS transports Ethernet IEEE 802.3, VLAN IEEE 802.1q, and VLAN-in-VLAN (q-in-q) traffic across multiple sites that belong to the same Layer 2 broadcast domain. VPLS offers simple VLAN services that include flooding broadcast, multicast, and unknown unicast frames that are received on a bridge. The VPLS solution requires a full mesh of pseudowires that are established among PE routers. The VPLS implementation is based on Label Distribution Protocol (LDP)-based pseudowire signaling.

VPLS for Layer 2 Switching

VPLS technology includes the capability of configuring the Cisco ASR 9000 Series Routers to perform Layer 2 bridging. In this mode, the Cisco ASR 9000 Series Routers can be configured to operate like other Cisco switches.

These features are supported:

Bridging IOS XR Trunk Interfaces
Bridging on EFPs

Refer to the Configuration Examples for Multipoint Layer 2 Services section for examples on these bridging features.

VPLS Discovery and Signaling

VPLS is a Layer 2 multipoint service and it emulates LAN service across a WAN service. VPLS enables service providers to interconnect several LAN segments over a packet-switched network and make it behave as one single LAN. Service provider can provide a native Ethernet access connection to customers using VPLS.

The VPLS control plane consists of two important components, autodiscovery and signaling:

VPLS Autodiscovery eliminates the need to manually provision VPLS neighbors. VPLS Autodiscovery enables each VPLS PE router to discover the other provider edge (PE) routers that are part of the same VPLS domain.
Once the PEs are discovered, pseudowires (PWs) are signaled and established across each pair of PE routers forming a full mesh of PWs across PE routers in a VPLS domain

Figure 2. VPLS Autodiscovery and Signaling

BGP-based VPLS Autodiscovery

An important aspect of VPN technologies, including VPLS, is the ability of network devices to automatically signal to other devices about an association with a particular VPN. Autodiscovery requires this information to be distributed to all members of a VPN. VPLS is a multipoint mechanism for which BGP is well suited.

BGP-based VPLS autodiscovery eliminates the need to manually provision VPLS neighbors. VPLS autodiscovery enables each VPLS PE router to discover the other provider edge (PE) routers that are part of the same VPLS domain. VPLS Autodiscovery also tracks when PE routers are added to or removed from the VPLS domain. When the discovery process is complete, each PE router has the information required to setup VPLS pseudowires (PWs).

Even when BGP autodiscovery is enabled, pseudowires can be manually configured for VPLS PE routers that are not participating in the autodiscovery process.

BGP Auto Discovery With BGP Signaling

The implementation of VPLS in a network requires the establishment of a full mesh of PWs between the provider edge (PE) routers. The PWs can be signaled using BGP signaling.

Figure 3. Discovery and Signaling Attributes

The BGP signaling and autodiscovery scheme has the following components:

A means for a PE to learn which remote PEs are members of a given VPLS. This process is known as autodiscovery.
A means for a PE to learn the pseudowire label expected by a given remote PE for a given VPLS. This process is known as signaling.

The BGP Network Layer Reachability Information (NLRI) takes care of the above two components simultaneously. The NLRI generated by a given PE contains the necessary information required by any other PE. These components enable the automatic setting up of a full mesh of pseudowires for each VPLS without having to manually configure those pseudowires on each PE.

NLRI Format for VPLS with BGP AD and Signaling

The following figure shows the NLRI format for VPLS with BGP AD and Signaling

BGP Auto Discovery With LDP Signaling

Signaling of pseudowires requires exchange of information between two endpoints. Label Distribution Protocol (LDP) is better suited for point-to-point signaling. The signaling of pseudowires between provider edge devices, uses targeted LDP sessions to exchange label values and attributes and to configure the pseudowires.

Figure 5. Discovery and Signaling Attributes

A PE router advertises an identifier through BGP for each VPLS. This identifier is unique within the VPLS instance and acts like a VPLS ID. The identifier enables the PE router receiving the BGP advertisement to identify the VPLS associated with the advertisement and import it to the correct VPLS instance. In this manner, for each VPLS, a PE router learns the other PE routers that are members of the VPLS.

The LDP protocol is used to configure a pseudowire to all the other PE routers. FEC 129 is used for the signaling. The information carried by FEC 129 includes the VPLS ID, the Target Attachment Individual Identifier (TAII) and the Source Attachment Individual Identifier (SAII).

The LDP advertisement also contains the inner label or VPLS label that is expected for the incoming traffic over the pseudowire. This enables the LDP peer to identify the VPLS instance with which the pseudowire is to be associated and the label value that it is expected to use when sending traffic on that pseudowire.

NLRI and Extended Communities

The following figure depicts Network Layer Reachability Information (NLRI) and extended communities (Ext Comms).

Interoperability Between Cisco IOS XR and Cisco IOS on VPLS LDP Signaling

The Cisco IOS Software encodes the NLRI length in the fist byte in bits format in the BGP Update message. However, the Cisco IOS XR Software interprets the NLRI length in 2 bytes. Therefore, when the BGP neighbor with VPLS-VPWS address family is configured between the IOS and the IOS XR, NLRI mismatch can happen, leading to flapping between neighbors. To avoid this conflict, IOS supports prefix-length-size 2 command that needs to be enabled for IOS to work with IOS XR. When the prefix-length-size 2 command is configured in IOS, the NLRI length is encoded in bytes. This configuration is mandatory for IOS to work with IOS XR.

This is a sample IOS configuration with the prefix-length-size 2 command:


router bgp 1
 address-family l2vpn vpls
  neighbor 5.5.5.2 activate
  neighbor 5.5.5.2 prefix-length-size 2 --------> NLRI length = 2 bytes
 exit-address-family

MAC Address-related Parameters

The MAC address table contains a list of the known MAC addresses and their forwarding information. In the current VPLS design, the MAC address table and its management are maintained on the route processor (RP) card.

These topics provide information about the MAC address-related parameters:

Note

After you modify the MAC limit or action at the bridge domain level, ensure that you shut and unshut the bridge domain for the action to take effect. If you modify the MAC limit or action on an attachment circuit (through which traffic is passing), the attachment circuit must be shut and unshut for the action to take effect.

MAC Address Flooding

Ethernet services require that frames that are sent to broadcast addresses and to unknown destination addresses be flooded to all ports. To obtain flooding within VPLS broadcast models, all unknown unicast, broadcast, and multicast frames are flooded over the corresponding pseudowires and to all attachment circuits. Therefore, a PE must replicate packets across both attachment circuits and pseudowires.

MAC Address-based Forwarding

To forward a frame, a PE must associate a destination MAC address with a pseudowire or attachment circuit. This type of association is provided through a static configuration on each PE or through dynamic learning, which is flooded to all bridge ports.

Note

Split horizon forwarding applies in this case, for example, frames that are coming in on an attachment circuit or pseudowire are sent out of the same pseudowire. The pseudowire frames, which are received on one pseudowire, are not replicated on other pseudowires in the same virtual forwarding instance (VFI).

MAC Address Source-based Learning

When a frame arrives on a bridge port (for example, pseudowire or attachment circuit) and the source MAC address is unknown to the receiving PE router, the source MAC address is associated with the pseudowire or attachment circuit. Outbound frames to the MAC address are forwarded to the appropriate pseudowire or attachment circuit.

MAC address source-based learning uses the MAC address information that is learned in the hardware forwarding path. The updated MAC tables are propagated and programs the hardware for the router.

Note

Static MAC move is not supported from one port, interface, or AC to another port, interface, or AC. For example, if a static MAC is configured on AC1 (port 1) and then, if you send a packet with the same MAC as source MAC on AC2 (port 2), then you can’t attach this MAC to AC2 as a dynamic MAC. Therefore, do not send any packet with a MAC as any of the static MAC addresses configured.

The number of learned MAC addresses is limited through configurable per-port and per-bridge domain MAC address limits.

MAC Address Aging

A MAC address in the MAC table is considered valid only for the duration of the MAC address aging time. When the time expires, the relevant MAC entries are repopulated. When the MAC aging time is configured only under a bridge domain, all the pseudowires and attachment circuits in the bridge domain use that configured MAC aging time.

A bridge forwards, floods, or drops packets based on the bridge table. The bridge table maintains both static entries and dynamic entries. Static entries are entered by the network manager or by the bridge itself. Dynamic entries are entered by the bridge learning process. A dynamic entry is automatically removed after a specified length of time, known as aging time, from the time the entry was created or last updated.

If hosts on a bridged network are likely to move, decrease the aging-time to enable the bridge to adapt to the change quickly. If hosts do not transmit continuously, increase the aging time to record the dynamic entries for a longer time, thus reducing the possibility of flooding when the hosts transmit again.

MAC Address Limit

The MAC address limit is used to limit the number of learned MAC addresses. The bridge domain level limit is always configured and cannot be disabled. The default value of the bridge domain level limit is 4000 and can be changed in the range of 1-512000.

When a limit is exceeded, the system is configured to perform these notifications:

Syslog (default)
Simple Network Management Protocol (SNMP) trap
Syslog and SNMP trap
None (no notification)

MAC Address Withdrawal

For faster VPLS convergence, you can remove or unlearn the MAC addresses that are learned dynamically. The Label Distribution Protocol (LDP) Address Withdrawal message is sent with the list of MAC addresses, which need to be withdrawn to all other PEs that are participating in the corresponding VPLS service.

For the Cisco IOS XR VPLS implementation, a portion of the dynamically learned MAC addresses are cleared by using the MAC addresses aging mechanism by default. The MAC address withdrawal feature is added through the LDP Address Withdrawal message. To enable the MAC address withdrawal feature, use the withdrawal command in l2vpn bridge group bridge domain MAC configuration mode. To verify that the MAC address withdrawal is enabled, use the show l2vpn bridge-domain command with the detail keyword.

Note

By default, the LDP MAC Withdrawal feature is enabled on Cisco IOS XR.

The LDP MAC Withdrawal feature is generated due to these events:

Attachment circuit goes down. You can remove or add the attachment circuit through the CLI.
MAC withdrawal messages are received over a VFI pseudowire. RFC 4762 specifies that both wildcards (by means of an empty Type, Length and Value [TLV]) and a specific MAC address withdrawal. Cisco IOS XR software supports only a wildcard MAC address withdrawal.

MAC Address Security

You can configure MAC address security at the interfaces and at the bridge access ports (subinterfaces) levels. However, MAC security configured under an interface takes precedence to MAC security configured at the bridge domain level. When a MAC address is first learned, on an EFP that is configured with MAC security and then, the same MAC address is learned on another EFP, these events occur:

the packet is dropped
the second EFP is shutdown
the packet is learned and the MAC from the original EFP is flushed

MAC Address Move and Unicast Traffic Counters

MAC Address Move and Unicast Traffic counters are introduced on the VPLS bridge ports on the ASR9K platform. These counters essentially are L2VPN bridge port stats counters. MAC move and unicast traffic counters are introduced for troubleshooting. Cisco ASR 9000 High Density 100GE Ethernet Line Cards and Cisco ASR 9000 Enhanced Ethernet Line Cards support these counters.

For more information, on MAC Move and Unicast Traffic counters, use the show l2vpn bridge-domain command with the detail keyword on an AC Bridge, PW Bridge, PBB Edge, and VXLAN Bridge Ports.

Note

If the bridge port traffic is forwarded, either completely or partially to ASR 9000 Ethernet line cards, MAC Address Move and Unicast Traffic counters may not be accurate.

LSP Ping over VPWS and VPLS

For Cisco IOS XR software, the existing support for the Label Switched Path (LSP) ping and traceroute verification mechanisms for point-to-point pseudowires (signaled using LDP FEC128) is extended to cover the pseudowires that are associated with the VFI (VPLS). Currently, the support for the LSP ping and traceroute for LDP signalled FEC128 pseudowires is limited to manually configured VPLS pseudowires. In addition, Cisco IOS XR software supports LSP ping for point-to-point single-segment pseudowires that are signalled using LDP FEC129 AII-type 2 applicable to VPWS or signalled using LDP FEC129 AII-type 1 applicable to VPLS. For information about Virtual Circuit Connection Verification (VCCV) support and the ping mpls pseudowire command, see the MPLS Command Reference for Cisco ASR 9000 Series Routers.

Split Horizon Groups

An IOS XR bridge domain aggregates attachment circuits (ACs) and pseudowires (PWs) in one of three groups called Split Horizon Groups. When applied to bridge domains, Split Horizon refers to the flooding and forwarding behavior between members of a Split Horizon group. The following table describes how frames received on one member of a split horizon group are treated and if the traffic is forwarded out to the other members of the same split horizon group.

Bridge Domain traffic is either unicast or multicast.

Flooding traffic consists of unknown unicast destination MAC address frames; frames sent to Ethernet multicast addresses (Spanning Tree BPDUs, etc.); Ethernet broadcast frames (MAC address FF-FF-FF-FF-FF-FF).

Known Unicast traffic consists of frames sent to bridge ports that were learned from that port using MAC learning.

Traffic flooding is performed for broadcast, multicast and unknown unicast destination address.

Table 1. Split Horizon Groups Supported in Cisco IOS-XR
Split Horizon Group	Who belongs to this Group?	Multicast within Group	Unicast within Group
0	Default—any member not covered by groups 1 or 2.	Yes	Yes
1	Any PW configured under VFI.	No	No
2	Any AC or PW configured with split-horizon keyword.	No	No

Important notes on Split Horizon Groups:

All bridge ports or PWs that are members of a bridge domain must belong to one of the three groups.
By default, all bridge ports or PWs are members of group 0.
The VFI configuration submode under a bridge domain configuration indicates that members under this domain are included in group 1.
A PW that is configured in group 0 is called an Access Pseudowire.
The split-horizon group command is used to designate bridge ports or PWs as members of group 2.
The ASR9000 only supports one VFI group.

Layer 2 Security

These topics describe the Layer 2 VPN extensions to support Layer 2 security:

Port Security

Use port security with dynamically learned and static MAC addresses to restrict a port’s ingress traffic by limiting the MAC addresses that are allowed to send traffic into the port. When secure MAC addresses are assigned to a secure port, the port does not forward ingress traffic that has source addresses outside the group of defined addresses. If the number of secure MAC addresses is limited to one and assigned a single secure MAC address, the device attached to that port has the full bandwidth of the port.

These port security features are supported:

Limits the MAC table size on a bridge or a port.
Facilitates actions and notifications for a MAC address.
Enables the MAC aging time and mode for a bridge or a port.
Filters static MAC addresses on a bridge or a port.
Marks ports as either secure or nonsecure.
Enables or disables flooding on a bridge or a port.

After you have set the maximum number of secure MAC addresses on a port, you can configure port security to include the secure addresses in the address table in one of these ways:

Statically configure all secure MAC addresses by using the static-address command.
Allow the port to dynamically configure secure MAC addresses with the MAC addresses of connected devices.
Statically configure a number of addresses and allow the rest to be dynamically configured.

Dynamic Host Configuration Protocol Snooping

Dynamic Host Configuration Protocol (DHCP) snooping is a security feature that acts like a firewall between untrusted hosts and trusted DHCP servers. The DHCP snooping feature performs these activities:

Validates DHCP messages received from untrusted sources and filters out invalid messages.
Rate-limits DHCP traffic from trusted and untrusted sources.
Builds and maintains the binding database of DHCP snooping, which contains information about untrusted hosts with leased IP addresses.
Utilizes the binding database of DHCP snooping to validate subsequent requests from untrusted hosts.

For additional information regarding DHCP, see the Cisco ASR 9000 Series Aggregation Services Router IP Addresses and Services Configuration Guide.

G.8032 Ethernet Ring Protection

Ethernet Ring Protection (ERP) protocol, defined in ITU-T G.8032, provides protection for Ethernet traffic in a ring topology, while ensuring that there are no loops within the ring at the Ethernet layer. The loops are prevented by blocking either a pre-determined link or a failed link.

Overview

Each Ethernet ring node is connected to adjacent Ethernet ring nodes participating in the Ethernet ring using two independent links. A ring link never allows formation of loops that affect the network. The Ethernet ring uses a specific link to protect the entire Ethernet ring. This specific link is called the ring protection link (RPL). A ring link is bound by two adjacent Ethernet ring nodes and a port for a ring link (also known as a ring port).

Note

The minimum number of Ethernet ring nodes in an Ethernet ring is two.

The fundamentals of ring protection switching are:

the principle of loop avoidance
the utilization of learning, forwarding, and Filtering Database (FDB) mechanisms

Loop avoidance in an Ethernet ring is achieved by ensuring that, at any time, traffic flows on all but one of the ring links which is the RPL. Multiple nodes are used to form a ring:

RPL owner—It is responsible for blocking traffic over the RPL so that no loops are formed in the Ethernet traffic. There can be only one RPL owner in a ring.
RPL neighbor node—The RPL neighbor node is an Ethernet ring node adjacent to the RPL. It is responsible for blocking its end of the RPL under normal conditions. This node type is optional and prevents RPL usage when protected.
RPL next-neighbor node—The RPL next-neighbor node is an Ethernet ring node adjacent to RPL owner node or RPL neighbor node. It is mainly used for FDB flush optimization on the ring. This node is also optional.

The following figure illustrates the G.8032 Ethernet ring.

Nodes on the ring use control messages called RAPS to coordinate the activities of switching on or off the RPL link. Any failure along the ring triggers a RAPS signal fail (RAPS SF) message along both directions, from the nodes adjacent to the failed link, after the nodes have blocked the port facing the failed link. On obtaining this message, the RPL owner unblocks the RPL port.

Note

A single link failure in the ring ensures a loop-free topology.

Line status and Connectivity Fault Management protocols are used to detect ring link and node failure. During the recovery phase, when the failed link is restored, the nodes adjacent to the restored link send RAPS no request (RAPS NR) messages. On obtaining this message, the RPL owner blocks the RPL port and sends RAPS no request, root blocked (RAPS NR, RB) messages. This causes all other nodes, other than the RPL owner in the ring, to unblock all blocked ports. The ERP protocol is robust enough to work for both unidirectional failure and multiple link failure scenarios in a ring topology.

A G.8032 ring supports these basic operator administrative commands:

Force switch (FS)—Allows operator to forcefully block a particular ring-port.
- Effective even if there is an existing SF condition
- Multiple FS commands for ring supported
- May be used to allow immediate maintenance operations

Manual switch (MS)—Allows operator to manually block a particular ring-port.
- Ineffective in an existing FS or SF condition
- Overridden by new FS or SF conditions
- Multiple MS commands cancel all MS commands

Clear—Cancels an existing FS or MS command on the ring-port
- Used (at RPL Owner) to clear non-revertive mode

A G.8032 ring can support multiple instances. An instance is a logical ring running over a physical ring. Such instances are used for various reasons, such as load balancing VLANs over a ring. For example, odd VLANs may go in one direction of the ring, and even VLANs may go in the other direction. Specific VLANs can be configured under only one instance. They cannot overlap multiple instances. Otherwise, data traffic or RAPS packet can cross logical rings, and that is not desirable.

G.8032 ERP provides a new technology that relies on line status and Connectivity Fault Management (CFM) to detect link failure. By running CFM Continuity Check Messages (CCM) messages at an interval of 100ms, it is possible to achieve SONET-like switching time performance and loop free traffic.

For more information about Ethernet Connectivity Fault Management (CFM) and Ethernet Fault Detection (EFD) configuration, refer to the Configuring Ethernet OAM on the Cisco ASR 9000 Series Router module in the Cisco ASR 9000 Series Aggregation Services Router Interface and Hardware Component Configuration Guide.

Timers

G.8032 ERP specifies the use of different timers to avoid race conditions and unnecessary switching operations:

Delay Timers—used by the RPL Owner to verify that the network has stabilized before blocking the RPL

After SF condition, Wait-to-Restore (WTR) timer is used to verify that SF is not intermittent. The WTR timer can be configured by the operator, and the default time interval is 5 minutes. The time interval ranges from 1 to 12 minutes.
After FS/MS command, Wait-to-Block timer is used to verify that no background condition exists.

Note

Wait-to-Block timer may be shorter than the Wait-to-Restore timer

Guard Timer—used by all nodes when changing state; it blocks latent outdated messages from causing unnecessary state changes. The Guard timer can be configured and the default time interval is 500 ms. The time interval ranges from 10 to 2000 ms.
Hold-off timers—used by underlying Ethernet layer to filter out intermittent link faults. The hold-off timer can be configured and the default time interval is 0 seconds. The time interval ranges from 0 to 10 seconds.
- Faults are reported to the ring protection mechanism, only if this timer expires.

Single Link Failure

The following figure represents protection switching in case of a single link failure.

The following figure represents an Ethernet ring composed of seven Ethernet ring nodes. The RPL is the ring link between Ethernet ring nodes A and G. In these scenarios, both ends of the RPL are blocked. Ethernet ring node G is the RPL owner node, and Ethernet ring node A is the RPL neighbor node.

These symbols are used:

This sequence describes the steps in the single link failure, represented in Figure 8:

Link operates in the normal condition.
A failure occurs.
Ethernet ring nodes C and D detect a local Signal Failure condition and after the holdoff time interval, block the failed ring port and perform the FDB flush.
Ethernet ring nodes C and D start sending RAPS (SF) messages periodically along with the (Node ID, BPR) pair on both ring ports, while the SF condition persists.
All Ethernet ring nodes receiving an RAPS (SF) message perform FDB flush. When the RPL owner node G and RPL neighbor node A receive an RAPS (SF) message, the Ethernet ring node unblocks it’s end of the RPL and performs the FDB flush.
All Ethernet ring nodes receiving a second RAPS (SF) message perform the FDB flush again; this is because of the Node ID and BPR-based mechanism.
Stable SF condition—RAPS (SF) messages on the Ethernet Ring. Further RAPS (SF) messages trigger no further action.

The following figure represents reversion in case of a single link failure.

Figure 9. Single link failure Recovery (Revertive operation)

This sequence describes the steps in the single link failure recovery, as represented in Figure 9:

Link operates in the stable SF condition.
Recovery of link failure occurs.
Ethernet ring nodes C and D detect clearing of signal failure (SF) condition, start the guard timer and initiate periodical transmission of RAPS (NR) messages on both ring ports. (The guard timer prevents the reception of RAPS messages).
When the Ethernet ring nodes receive an RAPS (NR) message, the Node ID and BPR pair of a receiving ring port is deleted and the RPL owner node starts the WTR timer.
When the guard timer expires on Ethernet ring nodes C and D, they may accept the new RAPS messages that they receive. Ethernet ring node D receives an RAPS (NR) message with higher Node ID from Ethernet ring node C, and unblocks its non-failed ring port.
When WTR timer expires, the RPL owner node blocks its end of the RPL, sends RAPS (NR, RB) message with the (Node ID, BPR) pair, and performs the FDB flush.
When Ethernet ring node C receives an RAPS (NR, RB) message, it removes the block on its blocked ring ports, and stops sending RAPS (NR) messages. On the other hand, when the RPL neighbor node A receives an RAPS (NR, RB) message, it blocks its end of the RPL. In addition to this, Ethernet ring nodes A to F perform the FDB flush when receiving an RAPS (NR, RB) message, due to the existence of the Node ID and BPR based mechanism.

Flow Aware Transport Pseudowire (FAT PW)

Routers typically loadbalance traffic based on the lower most label in the label stack which is the same label for all flows on a given pseudowire. This can lead to asymmetric loadbalancing. The flow, in this context, refers to a sequence of packets that have the same source and destination pair. The packets are transported from a source provider edge (PE) to a destination PE.

Flow-Aware Transport Pseudowires (FAT PW) provide the capability to identify individual flows within a pseudowire and provide routers the ability to use these flows to loadbalance traffic. FAT PWs are used to loadbalance traffic in the core when equal cost multipaths (ECMP) are used. A flow label is created based on indivisible packet flows entering a pseudowire; and is inserted as the lower most label in the packet. Routers can use the flow label for loadbalancing which provides a better traffic distribution across ECMP paths or link-bundled paths in the core.

The following figure shows a FAT PW with two flows distributing over ECMPs and bundle links.

Figure 10. FAT PW with two flows distributing over ECMPs and Bundle-Links

An additional label is added to the stack, called the flow label, which contains the flow information of a virtual circuit (VC). A flow label is a unique identifier that distinguishes a flow within the PW, and is derived from source and destination MAC addresses, and source and destination IP addresses. The flow label contains the end of label stack (EOS) bit set and inserted after the VC label and before the control word (if any). The ingress PE calculates and forwards the flow label. The FAT PW configuration enables the flow label. The egress PE discards the flow label such that no decisions are made.

All core routers perform load balancing based on the flow-label in the FAT PW. Therefore, it is possible to distribute flows over ECMPs and link bundles.

Pseudowire Headend

Pseudowires (PWs) enable payloads to be transparently carried across IP/MPLS packet-switched networks (PSNs). PWs are regarded as simple and manageable lightweight tunnels for returning customer traffic into core networks. Service providers are now extending PW connectivity into the access and aggregation regions of their networks.

Pseudowire Headend (PWHE) is a technology that allows termination of access pseudowires (PWs) into a Layer 3 (VRF or global) domain or into a Layer 2 domain. PWs provide an easy and scalable mechanism for tunneling customer traffic into a common IP/MPLS network infrastructure. PWHE allows customers to provision features such as QOS access lists (ACL), L3VPN on a per PWHE interface basis, on a service Provider Edge (PE) router.

Note

Encapsulation default is not supported by PWHE.

PWHE cross-connects to a pseudowire neighbour, which is reachable through recursive as well as non-recursive prefix. The reachability through recursive prefix is through introduction of BGP RFC3107 support on the Cisco ASR 9000 Series Router. Consider the following network topology for an example scenario.

For PWHE x-connect configuration, interconnectivity between A-PE (Access Provider Edge) and S-PE is through BGP RFC3107 that distributes MPLS labels along with IP prefixes. The customer network can avoid using an IGP to provide connectivity to the S-PE device, which is outside the customer's autonomous system.

For all practical purposes, the PWHE interface is treated like any other existing L3 interface. PWs operate in one of the following modes:

Bridged interworking (VC type 5 or VC type 4)
IP interworking mode (VC type 11)

With VC type 4 and VC type 5, PWs carry customer Ethernet frames (tagged or untagged) with IP payload. Thus, an S-PE device must perform ARP resolution for customer IP addresses learned over the PWHE. With VC type 4 (VLAN tagged) and VC type 5 (Ethernet port/raw), PWHE acts as a broadcast interface. Whereas with VC type 11 (IP Interworking), PWHE acts as a point-to-point interface. Therefore there are two types of PWHE interface—PW-Ether (for VC type 4 and 5) and PW-IW (for VC type 11). These PWs can terminate into a VRF or the IP global table on S-PE.

Benefits of PWHE

Some of the benefits of implementing PWHE are:

dissociates 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
implements a uniform method of OAM functionality
providers can extend or expand the Layer 3 service footprints
provides a method of terminating customer traffic into a next generation network (NGN)

Restrictions

FAT (flow-aware transport) labels or entropy labels are not supported on PWHE.
The system load balances PWHE based on PWID on the originating PE router over the interfaces in the generic interface list, and also on PWID on subsequent P routers.
PWHE is not supported over 2^nd level BGP Labeled Unicast (LU) recursion.

Generic Interface List

A generic interface list contains is a list of physical or bundle interfaces that is used in a PW-HE connection.

The generic interface list supports only main interfaces, and not sub-interfaces. The generic interface list is bi-directional and restricts both receive and transmit interfaces on access-facing line cards. The generic interface list has no impact on the core-facing side.

A generic interface list is used to limit the resources allocated for a PWHE interface to the set of interfaces specified in the list.

Only the S-PE is aware of the generic interface list and expects that the PWHE packets arrive on only line cards with generic interface list members on it. If packets arrive at the line card without generic interface list members on it, they are dropped.

LFA over Pseudowire Headend

From Release 5.1.1, PW-HE is supported on loop free alternate (LFA) routes.

For LFA to be effective on a PW-HE interface, all the routing paths (protected and backup) must be included in the generic interface list of that PW-HE interface. If all the routing paths are not included in the generic interface list, then there may be loss of traffic even if LFA is enabled. This is because the LFA route could be the one that was not included in the generic interface list.

To configure LFA on PW-HE interface, do the following:

Configuring Generic Interface List
Configuring IP/LDP Fast Reroute

For more information about configuring the IP Fast Reroute Loop-free alternate, see Implementing IS-IS on Cisco IOS XR Software module of the Cisco ASR 9000 Series Aggregation Services Router Routing Configuration Guide.

PW-HE Multicast

Multicast support for Pseudowire Head-end (PW-HE) interfaces is available only on the enhanced ethernet cards.

For more information about PW-HE multicast feature, see the Implementing Layer 3 Multicast Routing chapter in the Cisco ASR 9000 Series Aggregation Services Router Multicast Configuration Guide, Release 5.1.x.

PW-HE over MPLS-TE Tunnels

The PW-HE over MPLS-TE Tunnels feature supports forwarding of pseudowire traffic (with pseudowire headend) over TE tunnels.

For more information about PW-HE over MPLS TE Tunnels, see the Implementing MPLS Traffic Engineering chapter in the Cisco ASR 9000 Series Aggregation Services Router MPLS Configuration Guide, Release 5.1.x.

L2VPN over GRE

To transport an IP packet over a generic routing encapsulation (GRE) tunnel, the system first encapsulates the original IP packet with a GRE header. The encapsulated GRE packet is encapsulated once again by an outer transport header that is used to forward the packet to it’s destination. The following figure captures how GRE encapsulation over an IP transport network takes place.

Note

In the new IP packet, new payload is similar to the original IP packet. Additionally, the new IP header (New IP Hdr) is similar to the tunnel IP header which in turn is similar to the transport header.

When a GRE tunnel endpoint decapsulates a GRE packet, it further forwards the packet based on the payload type. For example, if the payload is a labeled packet then the packet is forwarded based on the virtual circuit (VC) label or the VPN label for L2VPN and L3VPN respectively.

L2VPN over GRE Restrictions

Some of the restrictions that you must consider while configuring L2VPN over GRE:

For VPLS flow-based load balancing scenario, the GRE tunnel is pinned down to outgoing path based on tunnel source or destination cyclic redundancy check (CRC). Unicast and flood traffic always takes the same physical path for a given GRE tunnel.
Ingress attachment circuit must be an ASR 9000 Enhanced Ethernet Line Card for L2VPN over GRE. Additionally, GRE tunnel destination should be reachable only on an ASR 9000 Enhanced Ethernet Line Card.
The L2VPN over GRE feature is not supported on the ASR 9000 Ethernet Line Card or Cisco ASR 9000 Series SPA Interface Processor-700 line cards as the ingress attachment circuit and GRE destination is reachable over GRE.
Pseudowire over TE over GRE scenario is not supported.
Preferred Path Limitations:
- When you configure GRE as a preferred path, egress features are not supported under the GRE tunnel (Egress ACL).
- VCCV ping or traceroute are not supported for preferred path.
- Preferred path is supported only for pseudowires configured in a provider egde (PE) to PE topology.

GRE Deployment Scenarios

In an L2VPN network, you can deploy GRE in the following scenarios:

Configuring GRE tunnel between provider edge (PE) to PE routers
Configuring GRE tunnel between P to P routers
Configuring GRE tunnel between P to PE routers

The following diagrams depict the various scenarios:

Figure 13. GRE tunnel configured between PE to PE routers

Figure 14. GRE tunnel configured between P to P routers

Figure 15. GRE tunnel configured between P to PE routers

Note

These deployment scenarios are applicable to VPWS and VPLS.

GRE Tunnel as Preferred Path

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

Multipoint Layer 2 Services Label Switched Multicast

Multipoint Layer 2 Services Label Switched Multicast (LSM) is a Layer 2 based solution that sends multicast traffic over a multiprotocol label switching (MPLS) network. In Multipoint Layer 2 Services, point-to-point (P2P) pseudowires (PWs) are setup at PE routers participating in a Multipoint Layer 2 Services domain, to provide Ethernet LAN emulation. Broadcast, multicast and unknown unicast traffic can be sent through ingress replicaton or label switched multicast in the Multipoint Layer 2 Services domain.

Ingress Replication and its Limitations

In ingress replication, broadcast, multicast and unknown unicast traffic are replicated at the ingress PE router. Individual copies of the same packets are sent to remote PE routers that participate in the same VPLS domain. However, ingress replication has these limitations:

Results in significant waste of link bandwidth when there is heavy broadcast and multicast VPLS traffic
Is resource intensive because the ingress PE router is most impacted by the replication

VPLS LSM as a Solution

VPLS Label Switched Multicast (LSM) is an effective multicast solution for overcoming the limitations of ingress replication. This solution employs point-to-multipoint (P2MP) label switched path (LSP) in the MPLS network to transport multicast traffic over a VPLS domain.

Note

Only broadcast, multicast or unknown unicast traffic is sent over P2MP LSPs

The VPLS LSM solution supports BGP based P2MP PW signaling. As a result, remote PEs participating in the VPLS domain are discovered automatically using the BGP autodiscovery mechanism. Creating a P2MP PW for each VPLS domain allows emulating VPLS P2MP service for PWs in the VPLS domain.

Multicast trees used for VPLS can be of two types:

Inclusive trees
Selective trees

Inclusive trees—This option supports the use of a single multicast distribution tree in the SP network to carry all the multicast traffic from a specified set of VPLS sites connected to a given PE. A particular multicast tree can be set up to carry the traffic originated by sites belonging to a single VPLS instance, or belonging to different VPLS instances. The ability to carry the traffic of more than one VPLS instance on the same tree is called Aggregate Inclusive. The tree needs to include every PE that is a member of any of the VPLS instances that are using the tree. A PE may receive multicast traffic for a multicast stream even if it doesn't have any receivers that are interested in receiving traffic for that stream. An Inclusive multicast tree in VPLS LSM is a P2MP tree.

Selective trees—A Selective multicast tree is used by a PE to send IP multicast traffic for one or more specific IP multicast streams, received by the PE over PE-CE interfaces that belong to the same or different VPLS instances, to a subset of the PEs that belong to those VPLS instances. This is to provide a PE the ability to create separate SP multicast trees for specific multicast streams, e.g. high bandwidth multicast streams. This allows traffic for these multicast streams to reach only those PE routers that have receivers for these streams. This avoids flooding other PE routers in the VPLS instance.

VPLS LSM Limitations

VPLS LSM has these limitations:

Only BGP-AD signaling with RSVP-TE multicast trees are supported.
Statically configured PWs are not supported.
Only Inclusive trees are supported.
Selective multicast trees are not supported.
LDP signalled P2P PW is not supported. Only BGP signalled PWs are supported.
Only RSVP-TE multicast trees are supported.
If IGMP snooping is enabled in a bridge domain participating in the P2MP multicast tree root, IGMP snooping traffic is forwarded using ingress replication. P2MP multicast trees are not used.
P2MP PW signaling is initiated when P2MP is enabled in a VPLS domain. Therefore, it is possible that one or more Leaf PEs are unable to join the multicast tree. In this scenario, the leaf PEs do not receive traffic sent over the P2MP tree.
Traffic is blackholed until Leaf PEs successfully join the multicast tree. Automatic recovery is not supported.
MAC learning occurs when unknown unicast traffic is sent on a P2MP multicast tree. As a result, traffic is switched to a P2P PW. Packet reordering may occur as P2P and P2MP PWs potentially take different paths through the network. Traffic, which is already in transit over P2MP, may arrive later than newer traffic on P2P PW for the same flow.
With respect to VPLS LSM, the A9K-SIP-700 Line Card has some specific limitations as follows:
- ISSU is not supported.
- QoS is not supported on Access-PW on this line card.
- MPLS-TE is not supported on serial interfaces.
- If TE or RSVP or both are configured, RSVP does not remove the interface and neighbors.
- Only FRR Link Protection is supported. FRR Node Protection is not supported.
- The maximum number of P2MP-enabled BD-VFI supported is 1000.
- To transition from Bud to Mid node, remove the entire l2vpn configuration using the no l2vpn command. Configuring no multicast p2mp command is not enough.

How to Implement Multipoint Layer 2 Services

This section describes the tasks that are required to implement Multipoint Layer 2 Services:

Configuring a Bridge Domain

These topics describe how to configure a bridge domain:

Creating a Bridge Domain

Perform this task to create a bridge domain .

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge-domain bridge-domain-name
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters L2VPN configuration mode.
Step 3	bridge group `bridge-group-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group that can contain bridge domains, and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring a Pseudowire

Perform this task to configure a pseudowire under a bridge domain.

SUMMARY STEPS

configure
l2vpn
bridge group bridge group name
bridge-domain bridge-domain name
vfi { vfi-name }
exit
neighbor { A.B.C.D} { pw-id value }
dhcp ipv4 snoop profile { dhcp_snoop_profile_name }
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters L2VPN configuration mode.
Step 3	bridge group `bridge group name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	vfi { `vfi-name` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# vfi v1 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)#` Configures the virtual forwarding interface (VFI) parameters and enters L2VPN bridge group bridge domain VFI configuration mode. Use the `vfi-name` argument to configure the name of the specified virtual forwarding interface.
Step 6	exit Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)# exit RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Exits the current configuration mode.
Step 7	neighbor { `A.B.C.D`} { pw-id `value` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# neighbor 10.1.1.2 pw-id 1000 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-pw)#` Adds an access pseudowire port to a bridge domain or a pseudowire to a bridge virtual forwarding interface (VFI). Use the `A.B.C.D` argument to specify the IP address of the cross-connect peer. Use the pw-id keyword to configure the pseudowire ID and ID value. The range is 1 to 4294967295.
Step 8	dhcp ipv4 snoop profile `{ dhcp_snoop_profile_name }` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-pw)#dhcp ipv4 snoop profile profile1` Enables DHCP snooping on the bridge, and attaches a DHCP snooping profile.
Step 9	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Associating Members with a Bridge Domain

After a bridge domain is created, perform this task to assign interfaces to the bridge domain. These types of bridge ports are associated with a bridge domain:

Ethernet and VLAN
VFI

Note

BVI is not supported in a bridge domain that is configured with VFI.

SUMMARY STEPS

configure
l2vpn
bridge group bridge group name
bridge-domain bridge-domain name
interface type interface-path-id
(Optional) static-mac-address { MAC-address }
routed interface BVI-id
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn` Enters L2VPN configuration mode.
Step 3	bridge group `bridge group name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	interface `type interface-path-id` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# interface GigabitEthernet 0/4/0/0 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-ac)#` Enters interface configuration mode and adds an interface to a bridge domain that allows packets to be forwarded and received from other interfaces that are part of the same bridge domain.
Step 6	(Optional) static-mac-address { `MAC-address` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-ac)# static-mac-address 1.1.1 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-ac)# exit RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Configures the static MAC address to associate a remote MAC address with a pseudowire or any other bridge interface.
Step 7	routed interface `BVI-id` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# routed interface BVI100 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-ac)#` Perform this step if you need the VPLS pseudowire traffic routed over an Integrated Routing and Bridging (IRB). This command enters bridge-group virtual interface configuration mode and adds a bridge-group virtual interface (BVI) to the bridge domain that allows packets to be forwarded and received from other interfaces that are part of the same bridge domain. This step is essential to bring the BVI's status up.
Step 8	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring Bridge Domain Parameters

To configure bridge domain parameters, associate these parameters with a bridge domain:

Maximum transmission unit (MTU)—Specifies that all members of a bridge domain have the same MTU. The bridge domain member with a different MTU size is not used by the bridge domain even though it is still associated with a bridge domain.
Flooding—Flooding is enabled always.
Dynamic ARP Inspection (DAI)—Ensures only valid ARP requests and responses are relayed.
IP SourceGuard (IPSG)—Enables source IP address filtering on a Layer 2 port.

Note

To verify if the DAI and IPSG features are working correctly, look up the packets dropped statistics for DAI and IPSG violation. The packet drops statistics can be viewed in the output of the show l2vpn bridge-domain bd-name <> detail command.

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge-domain bridge-domain-name
flooding disable
mtu bytes
dynamic-arp-inspection { address-validation | disable | logging }
ip-source-guard logging
Use the commit or end command.

DETAILED STEPS

Step 1

configure

Example:

RP/0/RSP0/CPU0:router# configure

Enters the Global Configuration mode.

Step 2

l2vpn

Example:


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

Enters the l2vpn configuration mode.

Step 3

bridge group bridge-group-name

Example:


RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco
RP/0/RSP0/CPU0:router(config-l2vpn-bg)#

Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.

Step 4

bridge-domain bridge-domain-name

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc
RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#

Establishes a bridge domain and enters l2vpn bridge group bridge domain configuration mode.

Step 5

flooding disable

Example:


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

Disables flooding.

Step 6

mtu bytes

Example:


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

Adjusts the maximum packet size or maximum transmission unit (MTU) size for the bridge domain.

Use the bytes argument to specify the MTU size, in bytes. The range is from 64 to 65535.

Step 7

dynamic-arp-inspection { address-validation | disable | logging }

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# dynamic-arp-inspection

Enters the dynamic ARP inspection configuration submode. Ensures only valid ARP requests and responses are relayed.

Note

You can configure dynamic ARP inspection under the bridge domain or the bridge port.

Step 8

ip-source-guard logging

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# ip-source-guard logging

Enters the IP source guard configuration submode and enables source IP address filtering on a Layer 2 port.

You can enable IP source guard under the bridge domain or the bridge port. By default, bridge ports under a bridge inherit the IP source guard configuration from the parent bridge.

By default, IP source guard is disabled on the bridges.

Step 9

Use the commit or end command.

commit - Saves the configuration changes and remains within the configuration session.

end - Prompts user to take one of these actions:

Yes - Saves configuration changes and exits the configuration session.
No - Exits the configuration session without committing the configuration changes.
Cancel - Remains in the configuration mode, without committing the configuration changes.

Disabling a Bridge Domain

Perform this task to disable a bridge domain. When a bridge domain is disabled, all VFIs that are associated with the bridge domain are disabled. You are still able to attach or detach members to the bridge domain and the VFIs that are associated with the bridge domain.

SUMMARY STEPS

configure
l2vpn
bridge group bridge group name
bridge-domain bridge-domain name
shutdown
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters L2VPN configuration mode.
Step 3	bridge group `bridge group name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters l2vpn bridge group bridge domain configuration mode.
Step 5	shutdown Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Shuts down a bridge domain to bring the bridge and all attachment circuits and pseudowires under it to admin down state.
Step 6	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Blocking Unknown Unicast Flooding

Perform this task to disable flooding of unknown unicast traffic at the bridge domain level.

You can disable flooding of unknown unicast traffic at the bridge domain, bridge port or access pseudowire levels. By default, unknown unicast traffic is flooded to all ports in the bridge domain.

Note

If you disable flooding of unknown unicast traffic on the bridge domain, all ports within the bridge domain inherit this configuration. You can configure the bridge ports to override the bridge domain configuration.

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge-domain bridge-domain-name
flooding unknown-unicast disable
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters L2VPN configuration mode.
Step 3	bridge group `bridge-group-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters l2vpn bridge group bridge domain configuration mode.
Step 5	flooding unknown-unicast disable Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# flooding unknown-unicast disable` Disables flooding of unknown unicast traffic at the bridge domain level.
Step 6	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Changing the Flood Optimization Mode

Perform this task to change the flood optimization mode under the bridge domain:

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge-domain bridge-domain-name
flood mode convergence-optimized
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn` Enters L2VPN configuration mode.
Step 3	bridge group `bridge-group-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters l2vpn bridge group bridge domain configuration mode.
Step 5	flood mode convergence-optimized Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# flood mode convergence-optimized` Changes the default flood optimization mode from Bandwidth Optimization Mode to Convergence Mode.
Step 6	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring Layer 2 Security

These topics describe how to configure Layer 2 security:

Enabling Layer 2 Security

Perform this task to enable Layer 2 port security on a bridge.

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge domain bridge-domain-name
security
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters L2VPN configuration mode.
Step 3	bridge group `bridge-group-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Assigns each network interface to a bridge group and enters L2VPN bridge group configuration mode.
Step 4	bridge domain `bridge-domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	security Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# security` Enables Layer 2 port security on a bridge.
Step 6	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Attaching a Dynamic Host Configuration Protocol Profile

Perform this task to enable DHCP snooping on a bridge and to attach a DHCP snooping profile to a bridge.

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge-domain bridge-domain-name
dhcp ipv4 snoop { profile profile-name }
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters L2VPN configuration mode.
Step 3	bridge group `bridge-group-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Assigns each network interface to a bridge group and enters L2VPN bridge group configuration mode.
Step 4	bridge-domain `bridge-domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	dhcp ipv4 snoop { profile `profile-name` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# dhcp ipv4 snoop profile attach` Enables DHCP snooping on a bridge and attaches DHCP snooping profile to the bridge. Use the profile keyword to attach a DHCP profile. The profile-name argument is the profile name for DHCPv4 snooping.
Step 6	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring a Layer 2 Virtual Forwarding Instance

These topics describe how to configure a Layer 2 virtual forwarding instance (VFI):

Creating the Virtual Forwarding Instance

Perform this task to create a Layer 2 Virtual Forwarding Instance (VFI) on all provider edge devices under the bridge domain.

SUMMARY STEPS

configure
l2vpn
bridge group bridge group name
bridge-domain bridge-domain name
vfi {vfi-name}
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters L2VPN configuration mode.
Step 3	bridge group `bridge group name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	vfi {`vfi-name`} Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# vfi v1 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)#` Configures virtual forwarding interface (VFI) parameters and enters L2VPN bridge group bridge domain VFI configuration mode.
Step 6	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Associating Pseudowires with the Virtual Forwarding Instance

After a VFI is created, perform this task to associate one or more pseudowires with the VFI.

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge-domain bridge-domain-name
vfi { vfi name }
neighbor { A.B.C.D } { pw-id value }
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters L2VPN configuration mode.
Step 3	bridge group `bridge-group-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	vfi { `vfi name` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# vfi v1 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)#` Configures virtual forwarding interface (VFI) parameters and enters L2VPN bridge group bridge domain VFI configuration mode.
Step 6	neighbor { `A.B.C.D` } { pw-id `value` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)# neighbor 10.1.1.2 pw-id 1000 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-pw)#` Adds a pseudowire port to a bridge domain or a pseudowire to a bridge virtual forwarding interface (VFI). Use the `A.B.C.D` argument to specify the IP address of the cross-connect peer. Use the pw-id keyword to configure the pseudowire ID and ID value. The range is 1 to 4294967295.
Step 7	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Associating a Virtual Forwarding Instance to a Bridge Domain

Perform this task to associate a VFI to be a member of a bridge domain.

SUMMARY STEPS

configure
l2vpn
bridge group bridge group name
bridge-domain bridge-domain name
vfi { vfi name }
neighbor { A.B.C.D } { pw-id value }
static-mac-address { MAC-address }
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters the L2VPN configuration mode.
Step 3	bridge group `bridge group name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	vfi `{` `vfi name` `}` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# vfi v1 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)#` Configures virtual forwarding interface (VFI) parameters and enters L2VPN bridge group bridge domain VFI configuration mode.
Step 6	neighbor `{` `A.B.C.D` `}` `{` pw-id `value` `}` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)# neighbor 10.1.1.2 pw-id 1000 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-pw)#` Adds a pseudowire port to a bridge domain or a pseudowire to a bridge virtual forwarding interface (VFI). Use the `A.B.C.D` argument to specify the IP address of the cross-connect peer. Use the pw-id keyword to configure the pseudowire ID and ID value. The range is 1 to 4294967295.
Step 7	static-mac-address `{` `MAC-address` `}` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-pw)# static-mac-address 1.1.1` Configures the static MAC address to associate a remote MAC address with a pseudowire or any other bridge interface.
Step 8	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Attaching Pseudowire Classes to Pseudowires

Perform this task to attach a pseudowire class to a pseudowire.

SUMMARY STEPS

configure
l2vpn
bridge group bridge group name
bridge-domain bridge-domain name
vfi { vfi-name }
neighbor { A.B.C.D } { pw-id value }
pw-class { class-name }
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters the L2VPN configuration mode.
Step 3	bridge group `bridge group name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	vfi `{` `vfi-name` `}` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# vfi v1 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)#` Configures virtual forwarding interface (VFI) parameters and enters L2VPN bridge group bridge domain VFI configuration mode.
Step 6	neighbor `{` `A.B.C.D` `}` `{` pw-id `value` `}` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)# neighbor 10.1.1.2 pw-id 1000 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-pw)#` Adds a pseudowire port to a bridge domain or a pseudowire to a bridge virtual forwarding interface (VFI). Use the `A.B.C.D` argument to specify the IP address of the cross-connect peer. Use the pw-id keyword to configure the pseudowire ID and ID value. The range is 1 to 4294967295.
Step 7	pw-class `{` `class-name` `}` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-pw)# pw-class canada` Configures the pseudowire class template name to use for the pseudowire.
Step 8	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring Pseudowires Using Static Labels

Perform this task to configure the Any Transport over Multiprotocol (AToM) pseudowires by using the static labels. A pseudowire becomes a static AToM pseudowire by setting the MPLS static labels to local and remote.

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge-domain bridge-domain-name
vfi { vfi-name }
neighbor { A.B.C.D } { pw-id value }
mpls static label { local value } { remote value }
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters the L2VPN configuration mode.
Step 3	bridge group `bridge-group-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	vfi { `vfi-name` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# vfi v1 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)#` Configures virtual forwarding interface (VFI) parameters and enters L2VPN bridge group bridge domain VFI configuration mode.
Step 6	neighbor `{` `A.B.C.D` `}` `{` pw-id `value` `}` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)# neighbor 10.1.1.2 pw-id 1000 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-pw)#` Adds a pseudowire port to a bridge domain or a pseudowire to a bridge virtual forwarding interface (VFI). Use the `A.B.C.D` argument to specify the IP address of the cross-connect peer. Use the pw-id keyword to configure the pseudowire ID and ID value. The range is 1 to 4294967295.
Step 7	mpls static label { local `value` } { remote `value` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-pw)# mpls static label local 800 remote 500` Configures the MPLS static labels and the static labels for the pseudowire configuration. You can set the local and remote pseudowire labels.
Step 8	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Disabling a Virtual Forwarding Instance

Perform this task to disable a VFI. When a VFI is disabled, all the previously established pseudowires that are associated with the VFI are disconnected. LDP advertisements are sent to withdraw the MAC addresses that are associated with the VFI. However, you can still attach or detach attachment circuits with a VFI after a shutdown.

SUMMARY STEPS

configure
l2vpn
bridge group bridge group name
bridge-domain bridge-domain name
vfi { vfi-name }
shutdown
Use the commit or end command.
show l2vpn bridge-domain [ detail ]

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters the L2VPN configuration mode.
Step 3	bridge group `bridge group name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	vfi { `vfi-name` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# vfi v1 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)#` Configures virtual forwarding interface (VFI) parameters and enters L2VPN bridge group bridge domain VFI configuration mode.
Step 6	shutdown Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)# shutdown` Disables the virtual forwarding interface (VFI).
Step 7	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.
Step 8	show l2vpn bridge-domain [ detail ] Example: `RP/0/RSP0/CPU0:router# show l2vpn bridge-domain detail` Displays the state of the VFI. For example, if you shut down the VFI, the VFI is shown as shut down under the bridge domain.

Configuring the MAC Address-related Parameters

These topics describe how to configure the MAC address-related parameters:

The MAC table attributes are set for the bridge domains.

Configuring the MAC Address Source-based Learning

Perform this task to configure the MAC address source-based learning.

SUMMARY STEPS

configure
l2vpn
bridge group bridge group name
bridge-domain bridge-domainname
mac
learning disable
Use the commit or end command.
show l2vpn bridge-domain [ detail ]

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters the L2VPN configuration mode.
Step 3	bridge group `bridge group name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domainname` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	mac Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# mac RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac)#` Enters L2VPN bridge group bridge domain MAC configuration mode.
Step 6	learning disable Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac)# learning disable` Disables MAC learning at the bridge domain level.
Step 7	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.
Step 8	show l2vpn bridge-domain [ detail ] Example: `RP/0/RSP0/CPU0:router# show l2vpn bridge-domain detail` Displays the details that the MAC address source-based learning is disabled on the bridge.

Enabling the MAC Address Withdrawal

Perform this task to enable the MAC address withdrawal for a specified bridge domain.

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge-domain bridge-domain-name
mac
withdrawal
Use the commit or end command.
show l2vpn bridge-domain [detail]

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters L2VPN configuration mode.
Step 3	bridge group `bridge-group-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN l2vpn bridge group bridge domain configuration mode.
Step 5	mac Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# mac RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac)#` Enters L2VPN l2vpn bridge group bridge domain MAC configuration mode.
Step 6	withdrawal Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac)# withdrawal` Enables the MAC address withdrawal for a specified bridge domain.
Step 7	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.
Step 8	show l2vpn bridge-domain [detail] Example: `RP/0/RSP0/CPU0:router# show l2vpn bridge-domain detail` Displays detailed sample output to specify that the MAC address withdrawal is enabled. In addition, the sample output displays the number of MAC withdrawal messages that are sent over or received from the pseudowire.

Configuring the MAC Address Limit

Perform this task to configure the parameters for the MAC address limit.

Note

MAC Address Limit action is supported only on the ACs and not on the core pseudowires.

SUMMARY STEPS

configure
l2vpn
bridge group bridge group name
bridge-domain bridge-domain name
(Optional) interface type interface_id
mac
limit
maximum { value }
action { flood | no-flood | shutdown }
notification { both | none | trap }
mac limit threshold 80
Use the commit or end command.
show l2vpn bridge-domain [ detail ]

DETAILED STEPS

Step 1

configure

Example:

RP/0/RSP0/CPU0:router# configure

Enters the Global Configuration mode.

Step 2

l2vpn

Example:


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

Enters the L2VPN configuration mode.

Step 3

bridge group bridge group name

Example:


RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco
RP/0/RSP0/CPU0:router(config-l2vpn-bg)#

Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.

Step 4

bridge-domain bridge-domain name

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc
RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#

Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.

Step 5

(Optional) interface type interface_id

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# interface gigabitEthernet 0/2/0/1
RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-ac)#

Enters the interface configuration mode of the specified interface and adds this interface as the bridge domain member interface.

Note

Run this step if you want to configure the MAC address limit only for a specific interface. The further steps show the router prompt displayed when you have skipped this step to configure the MAC address limit at the bridge domain level.

Step 6

mac

Example:


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

Enters L2VPN bridge group bridge domain MAC configuration mode.

Step 7

limit

Example:


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

Sets the MAC address limit for action, maximum, and notification and enters L2VPN bridge group bridge domain MAC limit configuration mode.

Step 8

maximum { value }

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac-limit)# maximum 5000

Configures the specified action when the number of MAC addresses learned on a bridge is reached.

Step 9

action { flood | no-flood | shutdown }

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac-limit)# action flood

Configures the bridge behavior when the number of learned MAC addresses exceed the MAC limit configured.

Step 10

notification { both | none | trap }

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac-limit)# notification both

Specifies the type of notification that is sent when the number of learned MAC addresses exceeds the configured limit.

Step 11

mac limit threshold 80

Example:


RP/0/RSP0/CPU0:router(config-l2vpn)# mac limit threshold 80

Configures the MAC limit threshold. The default is 75% of MAC address limit configured in step 8.

Step 12

Use the commit or end command.

commit - Saves the configuration changes and remains within the configuration session.

end - Prompts user to take one of these actions:

Yes - Saves configuration changes and exits the configuration session.
No - Exits the configuration session without committing the configuration changes.
Cancel - Remains in the configuration mode, without committing the configuration changes.

Step 13

show l2vpn bridge-domain [ detail ]

Example:


RP/0/RSP0/CPU0:router# show l2vpn bridge-domain detail

Displays the details about the MAC address limit.

Configuring the MAC Address Aging

Perform this task to configure the parameters for MAC address aging.

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge-domain bridge-domain-name
mac
aging
time { seconds }
Use the commit or end command.
show l2vpn bridge-domain [ detail ]

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters the L2VPN configuration mode.
Step 3	bridge group `bridge-group-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters L2VPN bridge group bridge domain configuration mode.
Step 5	mac Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# mac RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac)#` Enters L2VPN bridge group bridge domain MAC configuration mode.
Step 6	aging Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac)# aging RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac-aging)#` Enters the MAC aging configuration submode to set the aging parameters such as time and type. The maximum MAC age for ASR 9000 Ethernet and ASR 9000 Enhanced Ethernet line cards is two hours.
Step 7	time { `seconds` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac-aging)# time 300` Configures the maximum aging time. Use the `seconds` argument to specify the maximum age of the MAC address table entry. The range is from 300 to 30000 seconds. Aging time is counted from the last time that the switch saw the MAC address. The default value is 300 seconds.
Step 8	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.
Step 9	show l2vpn bridge-domain [ detail ] Example: `RP/0/RSP0/CPU0:router# show l2vpn bridge-domain detail` Displays the details about the aging fields.

Disabling MAC Flush at the Bridge Port Level

Perform this task to disable the MAC flush at the bridge domain level.

You can disable the MAC flush at the bridge domain or bridge port level. By default, the MACs learned on a specific port are immediately flushed, when that port becomes nonfunctional.

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge-domain bridge-domain-name
mac
port-down flush disable
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn RP/0/RSP0/CPU0:router(config-l2vpn)#` Enters L2VPN configuration mode.
Step 3	bridge group `bridge-group-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `bridge-domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain and enters l2vpn bridge group bridge domain configuration mode.
Step 5	mac Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# mac RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac)#` Enters l2vpn bridge group bridge domain MAC configuration mode.
Step 6	port-down flush disable Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-mac)# port-down flush disable` Disables MAC flush when the bridge port becomes nonfunctional.
Step 7	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring MAC Address Security

Perform this task to configure MAC address security.

SUMMARY STEPS

configure
l2vpn
bridge groupbridge-group-name
bridge-domainbridge-domain-name
neighbor { A.B.C.D } { pw-id value }
mac
secure [action | disable | logging]
Use the commit or end command.

DETAILED STEPS

Step 1

configure

Example:

RP/0/RSP0/CPU0:router# configure

Enters the Global Configuration mode.

Step 2

l2vpn

Example:


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

Enters L2VPN configuration mode.

Step 3

bridge groupbridge-group-name

Example:


RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco
RP/0/RSP0/CPU0:router(config-l2vpn-bg)#

Creates a bridge group so that it can contain bridge domains and then assigns network interfaces to the bridge domain.

Step 4

bridge-domainbridge-domain-name

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain abc
RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#

Establishes a bridge domain and enters L2VPN l2vpn bridge group bridge domain configuration mode.

Step 5

neighbor { A.B.C.D } { pw-id value }

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# neighbor 10.1.1.2 pw-id 1000
RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-pw)#

Adds an access pseudowire port to a bridge domain, or a pseudowire to a bridge virtual forwarding interface (VFI).

Use the A.B.C.D argument to specify the IP address of the cross-connect peer.
Use the pw-id keyword to configure the pseudowire ID and ID value. The range is 1 to 4294967295.

Step 6

mac

Example:


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

Enters L2VPN l2vpn bridge group bridge domain MAC configuration mode.

Step 7

secure [action | disable | logging]

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-pw-mac)#
secure
RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-pw-mac-
secure)#

Enters MAC secure configuration mode.

By default, bridge ports (interfaces and access pseudowires) under a bridge inherit the security configuration from the parent bridge.

Note

Once a bridge port goes down, a clear command must be issued to bring the bridge port up.

Step 8

Use the commit or end command.

commit - Saves the configuration changes and remains within the configuration session.

end - Prompts user to take one of these actions:

Yes - Saves configuration changes and exits the configuration session.
No - Exits the configuration session without committing the configuration changes.
Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring an Attachment Circuit to the AC Split Horizon Group

These steps show how to add an interface to the split horizon group for attachment circuits (ACs) under a bridge domain.

SUMMARY STEPS

configure
l2vpn
bridge groupbridge-group-name
bridge-domainbridge-domain-name
interface type instance
split-horizon group
commit
end
show l2vpn bridge-domain detail

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn` Enters L2VPN configuration mode.
Step 3	bridge group`bridge-group-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group metroA` Enters configuration mode for the named bridge group.
Step 4	bridge-domain`bridge-domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain east` Enters configuration mode for the named bridge domain.
Step 5	interface `type instance` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# interface GigabitEthernet0/1/0/6` Enters configuration mode for the named interface.
Step 6	split-horizon group Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-ac)# split-horizon group` Enters configuration mode for the named interface.
Step 7	commit Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-ac)# commit` Saves configuration changes
Step 8	end Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-ac)# end` Returns to EXEC mode.
Step 9	show l2vpn bridge-domain detail Example: `RP/0/RSP0/CPU0:router show l2vpn bridge-domain detail` Displays information about bridges, including whether each AC is in the AC split horizon group or not.

Adding an Access Pseudowire to the AC Split Horizon Group

These steps show how to add an access pseudowire as a member to the split horizon group for attachment circuits (ACs) under a bridge domain.

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge-domain bridge-domain-name
neighbor A.B.C.D pw-id pseudowire-id
split-horizon group
commit
end
show l2vpn bridge-domain detail

DETAILED STEPS

Step 1

configure

Example:

RP/0/RSP0/CPU0:router# configure

Enters the Global Configuration mode.

Step 2

l2vpn

Example:

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

Enters L2VPN configuration mode.

Step 3

bridge group bridge-group-name

Example:

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

Enters configuration mode for the named bridge group.

Step 4

bridge-domain bridge-domain-name

Example:

RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain east

Enters configuration mode for the named bridge domain.

Step 5

neighbor A.B.C.D pw-id pseudowire-id

Example:

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

Configures the pseudowire segment.

Step 6

split-horizon group

Example:

RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-ac)# split-horizon group

Adds this interface to the split horizon group for ACs. Only one split horizon group for ACs

Note

Only one split horizon group for ACs and access pseudowires per bridge domain is supported

Step 7

commit

Example:

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

Saves configuration changes

Step 8

end

Example:

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

Returns to EXEC mode.

Step 9

show l2vpn bridge-domain detail

Example:

RP/0/RSP0/CPU0:router # show l2vpn bridge-domain detail

Displays information about bridges, including whether each AC is in the AC split horizon group or not.

Configuring VPLS with BGP Autodiscovery and Signaling

Perform this task to configure BGP-based autodiscovery and signaling.

SUMMARY STEPS

configure
l2vpn
bridge group bridge group name
bridge-domain bridge-domain name
vfi { vfi-name }
vpn-id vpn-id
autodiscovery bgp
rd { as-number:nn | ip-address:nn | auto }
route-target { as-number:nn | ip-address:nn | export | import }
route-target import { as-number:nn | ip-address:nn }
route-target export { as-number:nn | ip-address:nn }
signaling-protocol bgp
ve-id { number }
ve-range { number }
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn` Enters L2VPN configuration mode.
Step 3	bridge group `bridge group name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group metroA` Enters configuration mode for the named bridge group.
Step 4	bridge-domain `bridge-domain name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain east` Enters configuration mode for the named bridge domain.
Step 5	vfi { `vfi-name` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# vfi vfi-east` Enters virtual forwarding instance (VFI) configuration mode.
Step 6	vpn-id `vpn-id` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)# vpn-id 100` Specifies the identifier for the VPLS service. The VPN ID has to be globally unique within a PE router. i.e., the same VPN ID cannot exist in multiple VFIs on the same PE router. In addition, a VFI can have only one VPN ID.
Step 7	autodiscovery bgp Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)# autodiscovery bgp` Enters BGP autodiscovery configuration mode where all BGP autodiscovery parameters are configured. This command is not provisioned to BGP until at least the VPN ID and the signaling protocol is configured.
Step 8	rd { `as-number:nn` \| `ip-address:nn` \| auto } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad)# rd auto` Specifies the route distinguisher (RD) under the VFI. The RD is used in the BGP NLRI to identify VFI. Only one RD can be configured per VFI, and except for rd auto the same RD cannot be configured in multiple VFIs on the same PE. When rd auto is configured, the RD value is as follows: {BGP Router ID}:{16 bits auto-generated unique index}.
Step 9	route-target { `as-number:nn` \| `ip-address:nn` \| export \| import } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad)# route-target 500:99` Specifies the route target (RT) for the VFI. At least one import and one export route targets (or just one route target with both roles) need to be configured in each PE in order to establish BGP autodiscovery between PEs. If no export or import keyword is specified, it means that the RT is both import and export. A VFI can have multiple export or import RTs. However, the same RT is not allowed in multiple VFIs in the same PE.
Step 10	route-target import { `as-number:nn` \| `ip-address:nn` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad)# route-target import 200:20` Specifies the import route target for the VFI. Import route target is what the PE compares with the RT in the received NLRI: the RT in the received NLRI must match the import RT to determine that the RTs belong to the same VPLS service.
Step 11	route-target export { `as-number:nn` \| `ip-address:nn` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad)# route-target export 100:10` Specifies the export route target for the VFI. Export route target is the RT that is going to be in the NLRI advertised to other PEs.
Step 12	signaling-protocol bgp Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad)# signaling-protocol bgp` Enables BGP signaling, and enters the BGP signaling configuration submode where BGP signaling parameters are configured. This command is not provisioned to BGP until VE ID and VE ID range is configured.
Step 13	ve-id { `number` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad-sig)# ve-id 10` Specifies the local PE identifier for the VFI for VPLS configuration. The VE ID identifies a VFI within a VPLS service. This means that VFIs in the same VPLS service cannot share the same VE ID. The scope of the VE ID is only within a bridge domain. Therefore, VFIs in different bridge domains within a PE can use the same VE ID.
Step 14	ve-range { `number` } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad-sig)# ve-range 40` Overrides the minimum size of VPLS edge (VE) blocks. The default minimum size is 10. Any configured VE range must be higher than 10.
Step 15	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring VPLS with BGP Autodiscovery and LDP Signaling

Perform this task to configure BGP-based Autodiscovery and signaling:

SUMMARY STEPS

configure
l2vpn
router-id ip-address
bridge group bridge-group-name
bridge-domain bridge-domain-name
transport-mode vlan passthrough
vfi {vfi-name}
autodiscovery bgp
vpn-id vpn-id
rd {as-number:nn | ip-address:nn | auto}
route-target {as-number:nn | ip-address:nn | export | import }
route-target import {as-number:nn | ip-address:nn}
route-target export {as-number:nn | ip-address:nn}
signaling-protocol ldp
vpls-id {as-number:nn | ip-address:nn}
Use the commit or end command.

DETAILED STEPS

Step 1

configure

Example:

RP/0/RSP0/CPU0:router# configure

Enters the Global Configuration mode.

Step 2

l2vpn

Example:


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

Enters L2VPN configuration mode.

Step 3

router-id ip-address

Example:


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

Specifies a unique Layer 2 (L2) router ID for the provider edge (PE) router.

The router ID must be configured for LDP signaling, and is used as the L2 router ID in the BGP NLRI, SAII (local L2 Router ID) and TAII (remote L2 Router ID). Any arbitrary value in the IPv4 address format is acceptable.

Note

Each PE must have a unique L2 router ID. This CLI is optional, as a PE automatically generates a L2 router ID using the LDP router ID.

Step 4

bridge group bridge-group-name

Example:


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

Enters configuration mode for the named bridge group.

Step 5

bridge-domain bridge-domain-name

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain east

Enters configuration mode for the named bridge domain.

Step 6

transport-mode vlan passthrough

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# transport-mode vlan passthrough

Enables VC type 4 for BGP autodiscovery.

Step 7

vfi {vfi-name}

Example:


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

Enters virtual forwarding instance (VFI) configuration mode.

Step 8

autodiscovery bgp

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)# autodiscovery bgp

Enters BGP autodiscovery configuration mode where all BGP autodiscovery parameters are configured.

This command is not provisioned to BGP until at least the VPN ID and the signaling protocol is configured.

Step 9

vpn-id vpn-id

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi)# vpn-id 100

Specifies the identifier for the VPLS service. The VPN ID has to be globally unique within a PE router. i.e., the same VPN ID cannot exist in multiple VFIs on the same PE router. In addition, a VFI can have only one VPN ID.

Step 10

rd {as-number:nn | ip-address:nn | auto}

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad)# rd auto

Specifies the route distinguisher (RD) under the VFI.

The RD is used in the BGP NLRI to identify VFI. Only one RD can be configured per VFI, and except for rd auto the same RD cannot be configured in multiple VFIs on the same PE.

When rd auto is configured, the RD value is as follows: {BGP Router ID}:{16 bits auto-generated unique index}.

Step 11

route-target {as-number:nn | ip-address:nn | export | import }

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad)# route-target 500:99

Specifies the route target (RT) for the VFI.

At least one import and one export route targets (or just one route target with both roles) need to be configured in each PE in order to establish BGP autodiscovery between PEs.

If no export or import keyword is specified, it means that the RT is both import and export. A VFI can have multiple export or import RTs. However, the same RT is not allowed in multiple VFIs in the same PE.

Step 12

route-target import {as-number:nn | ip-address:nn}

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad)# route-target import 200:20

Specifies the import route target for the VFI.

Import route target is what the PE compares with the RT in the received NLRI: the RT in the received NLRI must match the import RT to determine that the RTs belong to the same VPLS service.

Step 13

route-target export {as-number:nn | ip-address:nn}

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad)# route-target export 100:10

Specifies the export route target for the VFI.

Export route target is the RT that is going to be in the NLRI advertised to other PEs.

Step 14

signaling-protocol ldp

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad)# signaling-protocol ldp

Enables LDP signaling.

Step 15

vpls-id {as-number:nn | ip-address:nn}

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-vfi-ad-sig)# vpls-id 10:20

Specifies VPLS ID which identifies the VPLS domain during signaling.

This command is optional in all PEs that are in the same Autonomous System (share the same ASN) because a default VPLS ID is automatically generated using BGP's ASN and the configured VPN ID (i.e., the default VPLS ID equals ASN:VPN-ID). If an ASN of 4 bytes is used, the lower two bytes of the ASN are used to build the VPLS ID. In case of InterAS, the VPLS ID must be explicitly configured. Only one VPLS ID can be configured per VFI, and the same VPLS ID cannot be used for multiple VFIs.

Step 16

Use the commit or end command.

commit - Saves the configuration changes and remains within the configuration session.

end - Prompts user to take one of these actions:

Yes - Saves configuration changes and exits the configuration session.
No - Exits the configuration session without committing the configuration changes.
Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring G.8032 Ethernet Ring Protection

To configure the G.8032 operation, separately configure:

An ERP instance to indicate:
- which (sub)interface is used as the APS channel
- which (sub)interface is monitored by CFM
- whether the interface is an RPL link, and, if it is, the RPL node type
CFM with EFD to monitor the ring links

Note

MEP for each monitor link needs to be configured with different Maintenance Association.

The bridge domains to create the Layer 2 topology. The RAPS channel is configured in a dedicated management bridge domain separated from the data bridge domains.
Behavior characteristics, that apply to ERP instance, if different from default values. This is optional.

This section provides information on:

Configuring ERP Profile

Perform this task to configure Ethernet ring protection (ERP) profile.

SUMMARY STEPS

configure
Ethernet ring g8032 profile profile-name
timer { wtr | guard | hold-off } seconds
non-revertive
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	Ethernet ring g8032 profile `profile-name` Example: `RP/0/RSP0/CPU0:router(config)# Ethernet ring g8032 profile p1` Enables G.8032 ring mode, and enters G.8032 configuration submode.
Step 3	timer { wtr \| guard \| hold-off } `seconds` Example: `RP/0/RSP0/CPU0:router(config-g8032-ring-profile)# timer hold-off 5` Specifies time interval (in seconds) for the guard, hold-off and wait-to-restore timers.
Step 4	non-revertive Example: `RP/0/RSP0/CPU0:router(config-g8032-ring-profile)# non-revertive` Specifies a non-revertive ring instance.
Step 5	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring CFM MEP

For more information about Ethernet Connectivity Fault Management (CFM), refer to the Configuring Ethernet OAM on the Cisco ASR 9000 Series Router module in the Cisco ASR 9000 Series Aggregation Services Router Interface and Hardware Component Configuration Guide.

Configuring an ERP Instance

Perform this task to configure an ERP instance.

SUMMARY STEPS

configure
l2vpn
bridge group bridge-group-name
bridge-domain domain-name
interface type port0-interface-path-id.subinterface
interface type port1-interface-path-id.subinterface
bridge-domain domain-name
interface type interface-path-id.subinterface
ethernet ring g8032 ring-name
instance number
description string
profile profile-name
rpl { port0 | port1 } { owner | neighbor | next-neighbor }
inclusion-list vlan-ids vlan-id
aps-channel
level number
port0 interface type path-id
port1 { interface type interface-path-id | bridge-domain bridge-domain-name | xconnect xconnect-name | none }
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn` Enters L2VPN configuration mode.
Step 3	bridge group `bridge-group-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# bridge group csco RP/0/RSP0/CPU0:router(config-l2vpn-bg)#` Creates a bridge group that can contain bridge domains, and then assigns network interfaces to the bridge domain.
Step 4	bridge-domain `domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain bd1 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain for R-APS channels, and enters L2VPN bridge group bridge domain configuration mode.
Step 5	interface `type port0-interface-path-id.subinterface` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# interface GigabitEthernet 0/0/0/0.1 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-ac)#` Enters interface configuration mode and adds an interface to a bridge domain that allows packets to be forwarded and received from other interfaces that are part of the same bridge domain.
Step 6	interface `type port1-interface-path-id.subinterface` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# interface GigabitEthernet 0/0/0/1.1 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-ac)#` Enters interface configuration mode and adds an interface to a bridge domain that allows packets to be forwarded and received from other interfaces that are part of the same bridge domain.
Step 7	bridge-domain `domain-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg)# bridge-domain bd2 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)#` Establishes a bridge domain for data traffic, and enters L2VPN bridge group bridge domain configuration mode.
Step 8	interface `type interface-path-id.subinterface` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd)# interface GigabitEthernet 0/0/0/0.10 RP/0/RSP0/CPU0:router(config-l2vpn-bg-bd-ac)#` Enters interface configuration mode and adds an interface to a bridge domain that allows packets to be forwarded and received from other interfaces that are part of the same bridge domain.
Step 9	ethernet ring g8032 `ring-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# ethernet ring g8032 r1` Enables G.8032 ring mode, and enters G.8032 configuration submode.
Step 10	instance `number` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp)# instance 1` Enters the Ethernet ring G.8032 instance configuration submode.
Step 11	description `string` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp-instance)# description test` Specifies a string that serves as description for that instance.
Step 12	profile `profile-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp-instance)#profile p1` Specifies associated Ethernet ring G.8032 profile.
Step 13	rpl { port0 \| port1 } { owner \| neighbor \| next-neighbor } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp-instance)#rpl port0 neighbor` Specifies one ring port on local node as RPL owner, neighbor or next-neighbor.
Step 14	inclusion-list vlan-ids `vlan-id` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp-instance)# inclusion-list vlan-ids e-g` Associates a set of VLAN IDs with the current instance.
Step 15	aps-channel Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp-instance)# aps-channel` Enters the Ethernet ring G.8032 instance aps-channel configuration submode.
Step 16	level `number` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp-instance-aps)# level 5` Specifies the APS message level. The range is from 0 to 7.
Step 17	port0 interface `type path-id` Example: `RP/0/RSP0/CPU0:router(configl2vpn-erp-instance-aps)# port0 interface GigabitEthernet 0/0/0/0.1` Associates G.8032 APS channel interface to port0.
Step 18	port1 { interface `type interface-path-id` \| bridge-domain `bridge-domain-name` \| xconnect `xconnect-name` \| none } Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp-instance-aps)# port1 interface GigabitEthernet 0/0/0/1.1` Associates G.8032 APS channel interface to port1.
Step 19	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring ERP Parameters

Perform this task to configure ERP parameters.

SUMMARY STEPS

configure
l2vpn
ethernet ring g8032ring-name
port0 interfacetype interface-path-id
monitor port0 interfacetype interface-path-id
exit
port1 { interface type interface-path-id | virtual | none}
monitor port1 interfacetype interface-path-id
exit
exclusion-list vlan-idsvlan-id
open-ring
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn` Enters L2VPN configuration mode.
Step 3	ethernet ring g8032`ring-name` Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# ethernet ring g8032 r1` Enables G.8032 ring mode, and enters G.8032 configuration submode.
Step 4	port0 interface`type interface-path-id` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp)# port0 interface GigabitEthernet 0/1/0/6` Enables G.8032 ERP for the specified port (ring port).
Step 5	monitor port0 interface`type interface-path-id` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp-port0)# monitor port0 interface 0/1/0/2` Specifies the port that is monitored to detect ring link failure per ring port. The monitored interface must be a sub-interface of the main interface.
Step 6	exit Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp-port0)# exit` Exits port0 configuration submode.
Step 7	port1 { interface `type interface-path-id \|` virtual \| none} Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp)# port1 interface GigabitEthernet 0/1/0/8` Enables G.8032 ERP for the specified port (ring port).
Step 8	monitor port1 interface`type interface-path-id` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp-port1)# monitor port1 interface 0/1/0/3` Specifies the port that is monitored to detect ring link failure per ring port. The monitored interface must be a sub-interface of the main interface.
Step 9	exit Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp-port1)# exit` Exits port1 configuration submode.
Step 10	exclusion-list vlan-ids`vlan-id` Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp)# exclusion-list vlan-ids a-d` Specifies a set of VLAN IDs that is not protected by Ethernet ring protection mechanism.
Step 11	open-ring Example: `RP/0/RSP0/CPU0:router(config-l2vpn-erp)# open-ring` Specifies Ethernet ring G.8032 as open ring.
Step 12	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring TCN Propagation

Perform this task to configure topology change notification (TCN) propagation.

SUMMARY STEPS

configure
l2vpn
tcn-propagation
Use the commit or end command.

DETAILED STEPS

Step 1	configure Example: `RP/0/RSP0/CPU0:router# configure` Enters the Global Configuration mode.
Step 2	l2vpn Example: `RP/0/RSP0/CPU0:router(config)# l2vpn` Enters L2VPN configuration mode.
Step 3	tcn-propagation Example: `RP/0/RSP0/CPU0:router(config-l2vpn)# tcn-propagation` Allows TCN propagation from minor ring to major ring and from MSTP to G.8032.
Step 4	Use the commit or end command. commit - Saves the configuration changes and remains within the configuration session. end - Prompts user to take one of these actions: Yes - Saves configuration changes and exits the configuration session. No - Exits the configuration session without committing the configuration changes. Cancel - Remains in the configuration mode, without committing the configuration changes.

Configuring Flow Aware Transport Pseudowire

This section provides information on

Enabling Load Balancing with ECMP and FAT PW for VPWS

Perform this task to enable load balancing with ECMP and FAT PW for VPWS. Creating a PW-Class in L2VPN configuration leads to load-balancing.

SUMMARY STEPS

configure
l2vpn
pw-class { name }
encapsulation mpls
load-balancing flow-label { both | code | receive | transmit } [ static ]
exit
exit
xconnect group group-name
p2p xconnect-name
interface type interface-path-id
neighbor A.B.C.D pw-id pseudowire-id
pw-class class-name
Use the commit or end command.

DETAILED STEPS

Step 1

configure

Example:

RP/0/RSP0/CPU0:router# configure

Enters the Global Configuration mode.

Step 2

l2vpn

Example:


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

Enters L2VPN configuration mode.

Step 3

pw-class { name }

Example:


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

Configures the pseudowire class template name to use for the pseudowire.

Step 4

encapsulation mpls

Example:


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

Configures the pseudowire encapsulation to MPLS.

Step 5

load-balancing flow-label { both | code | receive | transmit } [ static ]

Example:


RP/0/RSP0/CPU0:router(config-l2vpn-pwc-mpls)# load-balancing flow-label both

Enables load-balancing on ECMPs. Also, enables the imposition and disposition of flow labels for the pseudowire.

Note

If the static keyword is not specified, end to end negotiation of the FAT PW is enabled.

Step 6

exit

Example:


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

Exits the pseudowire encapsulation submode and returns the router to the parent configuration mode.

Step 7

exit

Example:


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

Exits the pseudowire submode and returns the router to the l2vpn configuration mode.

Step 8

xconnect group group-name

Example:


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

Specifies the name of the cross-connect group.

Step 9

p2p xconnect-name

Example:


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

Specifies the name of the point-to-point cross-connect.

Step 10

interface type interface-path-id

Example:


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

Specifies the interface type and instance.

Step 11

neighbor A.B.C.D pw-id pseudowire-id

Example:


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

Configures the pseudowire segment for the cross-connect.

Use the A.B.C.D argument to specify the IP address of the cross-connect peer.

Note

A.B.C.D can be a recursive or non-recursive prefix.

Step 12

pw-class class-name

Example:


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

Associates the pseudowire class with this pseudowire.

Step 13

Use the commit or end command.

commit - Saves the configuration changes and remains within the configuration session.

end - Prompts user to take one of these actions:

Yes - Saves configuration changes and exits the configuration session.
No - Exits the configuration session without committing the configuration changes.
Cancel - Remains in the configuration mode, without committing the configuration changes.

Enabling Load Balancing with ECMP and FAT PW for VPLS

Perform this task to enable load balancing with ECMP and FAT PW for VPLS.

SUMMARY STEPS

configure
l2vpn
load-balancing flow {src-dst-mac | src-dst-ip}
pw-class { class - name }

Cisco ASR 9000 Series Aggregation Services Router L2VPN and Ethernet Services Configuration Guide, Release 6.0.x

Bias-Free Language

Results

Chapter: Implementing Multipoint Layer 2 Services

Implementing Multipoint Layer 2 Services

Prerequisites for Implementing Multipoint Layer 2 Services

Information About Implementing Multipoint Layer 2 Services

Multipoint Layer 2 Services Overview

Bridge Domain

Flood Optimization

Bandwidth Optimization Mode

Convergence Mode

TE FRR Optimized Mode

Dynamic ARP Inspection

IP Source Guard

Pseudowires

DHCP Snooping over Pseudowire

Virtual Forwarding Instance

VPLS for an MPLS-based Provider Core

VPLS Architecture

VPLS for Layer 2 Switching

VPLS Discovery and Signaling

BGP-based VPLS Autodiscovery

BGP Auto Discovery With BGP Signaling

NLRI Format for VPLS with BGP AD and Signaling

BGP Auto Discovery With LDP Signaling

NLRI and Extended Communities

Interoperability Between Cisco IOS XR and Cisco IOS on VPLS LDP Signaling

MAC Address-related Parameters

MAC Address Flooding

MAC Address-based Forwarding

MAC Address Source-based Learning

MAC Address Aging

MAC Address Limit

MAC Address Withdrawal

MAC Address Security

MAC Address Move and Unicast Traffic Counters

LSP Ping over VPWS and VPLS

Split Horizon Groups

Layer 2 Security

Port Security

Dynamic Host Configuration Protocol Snooping

G.8032 Ethernet Ring Protection

Overview

Timers

Single Link Failure

Flow Aware Transport Pseudowire (FAT PW)

Pseudowire Headend

Benefits of PWHE

Restrictions

Generic Interface List

LFA over Pseudowire Headend

PW-HE Multicast

PW-HE over MPLS-TE Tunnels

L2VPN over GRE

L2VPN over GRE Restrictions

GRE Deployment Scenarios

GRE Tunnel as Preferred Path

Multipoint Layer 2 Services Label Switched Multicast

Ingress Replication and its Limitations

VPLS LSM as a Solution

VPLS LSM Limitations

How to Implement Multipoint Layer 2 Services

Configuring a Bridge Domain

Creating a Bridge Domain

SUMMARY STEPS

DETAILED STEPS

Example:

Example:

Example:

Example:

Configuring a Pseudowire

SUMMARY STEPS

DETAILED STEPS

Example:

Example:

Example:

Example:

Example:

Example: