Information About Implementing Multipoint Layer 2 Services
To implement Multipoint Layer 2 Services, you must 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. 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.
![]() Note |
VPLS PW is not supported over BGP multipath. |
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.
Bridge Domain and BVI Scale
The number of bridge domains (BDs) depends on the number of attachment circuits (ACs) configured per BD and also if Bridge-Group Virtual Interface (BVI) is configured or not. The number of logical interfaces (LIF) supported is less than 4000.
The following table provides an example of how the number of logical interfaces (LIF) required is calculated when two ACs are configured per BD.
Bridge Domain |
Number of Bridges |
AC |
Total LIF required |
---|---|---|---|
BD with BVI |
625 |
2 |
3750 |
BD without BVI |
125 |
2 |
250 |
Total BD |
750 |
- |
- |
Here is how the number of LIF required is calculated:
a*3+b, where a is the number of ACs with BVI and b is the number of ACs without BVI, must not exceed 4000.
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.
Access Pseudowire
The Access Pseudowire feature allows you to reduce the number of pseudowires (PWs) between the network Provider Edge (N-PE) devices. The user Provider Edge (U-PE) device connects to the N- PE device using access pseudowire (PW). This feature prevents signalling overhead and packet replication.
Unlike traditional VPLS where PWs terminate on a physical or logical port, an access PW terminates on N-PE devices. For each VPLS service, create an access PW between U-PEs and N-PEs.
VPLS requires a full mesh of pseudowire (PWs) between L2VPN PEs that participate in the VPLS service. For each VPLS service, PWs must be set up between the PEs. In a full mesh of PWs, the number of PWs increases as the number of PEs increases causing scalability issues. You can decrease the number of PWs with a hierarchy of PEs.
![](/c/dam/en/us/td/i/500001-600000/520001-530000/520001-521000/520140.jpg)
In this topology, a user Provider Edge (U-PE) device has ACs to the CEs. The U-PE device transports the CE traffic over an access PW to a network Provider Edge (N-PE) device. The N-PE is a core VPLS PE connected with other N-PEs in a VPLS mesh. On the N-PE, the access PW coming from the U-PE is much like an AC. The U-PE is not part of the mesh with the other N-PEs. So the N-PE considers the access PW as an AC. The N-PE forwards traffic from that access PW to the core PWs that are part of the VPLS full mesh. Configure the core PWs between N-PEs under a VFI. Apply the split horizon rule to all the core PWs configured under the VFI. Access PWs from U-PEs are not configured under a VFI, so they do not belong to the same Split Horizon Groups (SHGs) as the VFI PWs. Traffic is forwarded from an access PW to a VFI PW and conversely.
You must configure the access pseudowire in a split-horizon group.
Configure Access Pseudowire
Perform this task to configure Access Pseudowire feature.
/* Configure U-PE1 */
Router#configure
Router(config)# iinterface TenGigE0/1/0/5.2 l2transport
Router(config-l2vpn-subif)# encapsulation dot1q 2
Router(config-l2vpn-subif)# rewrite ingress tag pop 1 symmetric
Router(config-l2vpn-subif)# exit
Router# configure
Router(config)# l2vpn
Router(config-l2vpn)# xconnect group XCON1
Router(config-l2vpn-xc)# p2p xc1
Router(config-l2vpn-xc-p2p)# interface TenGigE0/1/0/5.2 l2transport
Router(config-l2vpn-xc-p2p)# neighbor 172.16.0.1 pw-id 1
Router(config-l2vpn-xc-p2p-pw)# commit
/* Configure N-PE1 */
Router#configure
Router(config)l2vpn
Router(config-l2vpn)#router-id 172.16.0.1
Router(config-l2vpn)#pw-class class1
Router(config-l2vpn-pwc)#encapsulation mpls
Router(config-l2vpn-pwc-mpls)#transport-mode ethernet
Router(config-l2vpn-pwc-mpls)#exit
Router# configure
Router(config)# l2vpn
Router(config-l2vpn)# bridge group bg1
Router(config-l2vpn-bg)# bridge-domain bd1
Router(config-l2vpn-bg-bd)# interface GigabitEthernet0/1/0/3.2
Router(config-bg-bd-ac)# split-horizon group
Router(config-l2vpn-bg-bd-ac)#exit
Router(config-l2vpn-bg-bd)#vfi vfi1
Router(config-l2vpn-bg-bd-vfi)#neighbor 10.0.0.1 pw-id 2
Router(config-l2vpn-bg-bd-vfi-pw)#pw-class class1
Router(config-l2vpn-bg-bd-vfi-pw-pwc)#commit
Running Configuration
This sections shows Access Pseudowire running configuration.
/* On U-PE1 */
configure
interface TenGigE0/1/0/5.2 l2transport
encapsulation dot1q 2
rewrite ingress tag pop 1 symmetric
!
l2vpn
xconnect group XCON1
p2p xc1
interface TenGigE0/1/0/5.2 l2transport
neighbor 172.16.0.1 pw-id 1
!
!
--------------------------------------------------------------------------
/* On N-PE1 */
l2vpn
router-id 172.16.0.1
pw-class class1
encapsulation mpls
transport-mode ethernet
!
!
l2vpn
bridge group bg1
bridge-domain bd1
interface GigabitEthernet0/1/0/3.2
split-horizon group
!
!
!
vfi vf1
neighbor 10.0.0.1 pw-id 2
pw-class class1
!
!
Verification
Verify Access Pseudowire configuration.
Router:U-PE1#show l2vpn xconnect group XCON1
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
SB = Standby, SR = Standby Ready, (PP) = Partially Programmed
XConnect Segment 1 Segment 2
Group Name ST Description ST Description ST
----------------- ----- -------------- ----------------------------- ------
XCON_1 xc1 UP Te0/1/0/5.2 UP 172.16.0.1 1 UP
-----------------------------------------------------------------------------------
Router:N-PE1#show l2vpn bridge-domain bd1
PW: neighbor 10.0.0.1, PW ID 2, state is up ( established )
PW class mpls, XC ID 0xc0000008
Encapsulation MPLS, protocol LDP
Source address 172.16.0.1
PW type Ethernet, control word disabled, interworking none
PW backup disable delay 0 sec
Sequencing not set
LSP : Up
PW Status TLV in use
MPLS Local Remote
------------ ------------------------------ ---------------------------
Label 24752 24752
Group ID 0x2 0x2
Interface Access PW Access PW
MTU 1500 1500
Control word disabled disabled
PW type Ethernet Ethernet
VCCV CV type 0x2 0x2
(LSP ping verification) (LSP ping verification)
VCCV CC type 0x6 0x6
(router alert label) (router alert label)
(TTL expiry) (TTL expiry)
------------ ------------------------------ ---------------------------
Related Topics
Associated Commands
-
show l2vpn xconnect group
-
show l2vpn bridge-domain
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.
VPLS for Layer 2 Switching
VPLS technology includes the capability of configuring the router to perform Layer 2 bridging. In this mode, the router can be configured to operate like other Cisco switches.
![]() Note |
The storm control configuration is supported only on one sub-interface under a main interface, though the system allows you to configure storm control on more than one sub-interface. However, only the first storm control configuration under a main interface takes effect, though the running configuration shows all the storm control configurations that are committed. After reload, any of the storm control configurations may take effect irrespective of the order of configuration. |
These features are supported:
-
Bridging IOS XR Trunk Interfaces
-
Bridging on EFPs
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
VPLS VFI with BVI as Routed Interface
The VPLS VFI with BVI as Routed Interface feature allows you to route the VPLS PW traffic dynamically over the BVI interface.
Integrated routing and bridging (IRB) enables you to route the packets received from a host on a bridge group and a routed interface using a Bridge-Group Virtual Interface (BVI). The BVI is a virtual interface configured on the router. It acts as a gateway routed interface towards the core network.
Configure a BVI on a single bridge domain that represents the link between the bridging and the routing domains on the router. To receive the packets from a bridged interface that are destined to a routed interface, configure BVI with the appropriate IP address, which is in the same subnet as the hosts in the bridge domain.
![](/c/dam/en/us/td/i/500001-600000/520001-530000/520001-521000/520214.jpg)
This topology explains two types of traffic flow:
-
Routed local traffic: Consider a traffic flow from AC1 Host to Host1. AC1 Host sends the traffic to BVI1. Attach AC1 Host and BVI1 to the same bridge domain of PE1. PE1 routs the traffic through BVI1 and sends it to Host1. L3 interface connects Host1 and PE1.
-
Routed remote traffic: Consider a traffic flow from AC2 Host to Host2. AC2 Host sends the traffic to the bridge domain of PE1. PE1 sends the traffic to BVI2. AC2 Host is part of BVI2 subnet. PW sends the traffic to the bridge domain of PE2. PE2 routs the traffic through BVI2 and sends it to Host2. L3 interface connects Host2 and PE2.
The following protocols are not supported when the bridge domain is attached with both PW and BVI: DHCP, ERPS, CDP, IGMP Snooping, CDP, VRRP, CFM, LACP, and BFDoBVI.
Configure VPLS VFI with BVI as Routed Interface
Perform this task to route the VPLS PW traffic dynamically over the BVI interface.
Configuration Example
/* PE1 Configuration */
Router#configure
Router(config)#l2vpn
Router(config-l2vpn)#bridge group bg1
Router(config-l2vpn-bg)#bridge-domain bd1
Router(config-l2vpn-bg-bd)#interface TenGigE0/0/0/0.1 -> AC1-L2 Sub-Interface (AC)
Router(config-l2vpn-bg-bd-ac)#exit
Router(config-l2vpn-bg-bd)#vfi core
Router(config-l2vpn-bg-bd-vfi)#neighbor 209.165.200.225 pw-id 1 -> VPLS Core-PW
Router(config-l2vpn-bg-bd-vfi-pw)#exit
Router(config-l2vpn-bg-bd-vfi)#exit
Router(config-l2vpn-bg-bd)#routed interface BVI1 -> BVI-1 Interface
Router(config-l2vpn-bg-bd-bvi)#exit
Router(config-l2vpn-bg-bd)#interface BVI1
Router(config-if)#ipv4 address 10.0.0.1 255.0.0.0
Router(config-if)#commit
/* PE2 Configuration */
Router#configure
Router(config)#l2vpn
Router(config-l2vpn)#bridge group bg1
Router(config-l2vpn-bg)#bridge-domain bd1
Router(config-l2vpn-bg-bd)#interface TenGigE0/0/0/1.1 -> AC3 L2 subinterface(AC)
Router(config-l2vpn-bg-bd-ac)#exit
Router(config-l2vpn-bg-bd)#vfi core
Router(config-l2vpn-bg-bd-vfi)#neighbor 209.165.200.226 pw-id 1 -> VPLS Core-PW
Router(config-l2vpn-bg-bd-vfi-pw)#exit
Router(config-l2vpn-bg-bd-vfi)#exit
Router(config-l2vpn-bg-bd)#routed interface BVI2 -> BVI-2 Interface
Router(config-l2vpn-bg-bd-bvi)#exit
Router(config-l2vpn-bg-bd)#interface BVI2
Router(config-if)#ipv4 address 172.16.0.1 255.240.0.0
Router(config-if)#commit
Running Configuration
This section shows VPLS VFI with BVI as Routed Interface configuration.
/* PE1 Configuration */
configure
l2vpn
bridge group bg1
bridge-domain bd1
interface TenGigE0/0/0/0.1 -> AC1-L2 Sub-Interface (AC)
!
vfi core
neighbor 209.165.200.225 pw-id 1 -> VPLS Core-PW
!
!
routed interface BVI1 -> BVI-1 Interface
!
!
interface BVI1
ipv4 address 10.0.0.1 255.0.0.0
/* PE2 Configuration */
configure
l2vpn
bridge group bg1
bridge-domain bd2
interface TenGigE0/0/0/1.1 -> AC3 L2 Sub-Interface (AC)
!
vfi core
neighbor 209.165.200.226 pw-id 1 -> VPLS Core-PW
!
!
routed interface BVI2 -> BVI2 Interface
!
!
interface BVI2
ipv4 address 172.16.0.1 255.240.0.0
Verification
Verify that you have configured the VPLS VFI with BVI as Routed Interface feature successfully.
Router-PE1#show l2vpn bridge-domain neighbor 209.165.200.225 detail
Legend: pp = Partially Programmed.
Bridge group: 1, bridge-domain: 1, id: 0, state: up, ShgId: 0, MSTi: 0
VINE state: BVI Resolved
MAC learning: enabled
MAC withdraw: enabled
Flooding:
Broadcast & Multicast: enabled
Unknown unicast: enabled
MAC aging time: 300 s, Type: inactivity
Create time: 10/01/2020 04:18:29 (00:14:06 ago)
ACs: 2 (2 up), VFIs: 1, PWs: 1 (1 up), PBBs: 0 (0 up), VNIs: 0 (0 up)
List of Access PWs:
List of VFIs:
VFI 1 (up)
PW: neighbor 209.165.200.225, PW ID 1, state is up ( established )
PW class mpls, XC ID 0xc0000002
Encapsulation MPLS, protocol LDP
Source address 209.165.200.226
PW type Ethernet, control word disabled, interworking none
Sequencing not set
LSP : Up
PW Status TLV in use
MPLS Local Remote
------------ ------------------------------ -------------------------
Label 24006 24002
Group ID 0x0 0x0
Interface 1 1
MTU 1500 1500
Control word disabled disabled
------------ ------------------------------ -------------------------
Related Topics
Associated Commands
-
show l2vpn bridge-domain detail
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:
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.
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.
The range of MAC address aging time is from 300 seconds to 30,000 seconds. The maximum MAC address aging time among all bridges is considered for calculating the age. You cannot configure the MAC address aging time on each AC or PW interface. Configure MAC address aging time in the bridge domain configuration mode. There is no show command to display the highest MAC address aging time.
MAC Address Limit
The MAC address limit is used to limit the number of learned MAC addresses. The default value for the MAC address limit is 64000 for Cisco NCS 5501 and Cisco NCS 5502.
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)
To generate syslogs messages and SNMP trap notifications, use the mac limit notification both command in the L2VPN bridge-domain configuration mode.
MAC address limit action applies only when the number of local MAC addresses exceeds the configured limit. The software unlearns the MAC addresses until it reaches the configured MAC limit threshold value. Later, the router restarts learning new MAC addresses. In the event when the MAC limit threshold is not configured, the default threshold is 75% of the configured MAC address limit.
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.