Virtual Private LAN
Services (VPLS) is a multipoint Layer 2 VPN (L2VPN) technology that allows
multiple sites to be connected over a simulated Ethernet broadcast domain,
which is supported across a provider-provisioned IP/MPLS network. In other
words, VPLS delivers multipoint Layer 2 connectivity over a Layer 3 network
architecture. VPLS evolved as a logical extension of Ethernet over MPLS
(EoMPLS), which was developed to enable point-to-point Ethernet-based L2VPN
services.
At a basic level, VPLS
can be defined as a group of Virtual Switch Instances (VSIs) that are
interconnected using EoMPLS circuits to form a single, logical bridge. In
concept, a VSI is similar to the bridging function found in IEEE 802.1q bridges
where a frame is switched based on the destination MAC and membership in a
Layer 2 VPN (a virtual LAN or VLAN). If the destination address is unknown, or
is a broadcast or multicast address, the frame is flooded to all ports
associated with the VSI, where a port, in the context of VPLS, is an EoMPLS
virtual circuit (VC) pseudowire.
VPLS uses the provider
core to join multiple attachment circuits together to simulate a virtual bridge
that connects the multiple attachment circuits together. From a
user-perspective, there is no topology for VPLS. All of the customer edge (CE)
devices appear to connect to a logical bridge emulated by the provider core.
See the figure below:
Figure 1. Virtual
Private LAN Services
With VPLS, all CE
devices participating in a single VPLS instance appear to be on the same LAN;
therefore, each CE device can communicate directly with one another in a
multipoint topology, without requiring a full mesh of point-to-point circuits
at the CE device. In a VPLS network, CE and provider edge (PE) devices are not
routing peers, so there is no need for service providers to provision customer
IP routers; this is a significant advantage over MPLS L3 VPN services. Compared
to traditional LAN switching technologies, VPLS is also more flexible in its
geographic scaling, so that CE sites may be within the same metropolitan
domain, or may be geographically dispersed on a regional or national basis.
VPLS using Label
Distribution Protocol (LDP) Signaling is supported in this release of Carrier
Packet Transport(CPT). To enable VPLS over a CPT network, a full-mesh or ring
configuration with bridge-domains (pseudowires or Ethernet Flow Points (EFPs))
must be established using the Label Distribution Protocol (LDP). Dynamic
pseudowires over LDP signalled, Static Pseudowire, Traffic Engineering (TE), or
Transport Profile (TP) label switched path is supported in this release.
VPLS can be enabled
on these configurations:
Full-Mesh
Configuration
The full-mesh
configuration requires a full mesh of label-switched paths (LSPs) tunnels
between all the PEs that participate in the VPLS. The tunnel label switched
paths are required only for TE and TP configurations and not for LDP. With a
full-mesh configuration, signaling overhead and packet replication requirements
for each provisioned VC on a PE can be high.
To set up a VPLS, a
virtual forwarding instance (VFI) must be created on each participating PE
router. The VFI specifies the VPN ID of a VPLS domain, the addresses of other
PE routers in the domain, and the type of tunnel signaling and encapsulation
mechanism for each peer PE router.
The set of VFIs
formed by the interconnection of the emulated VCs is called a
VPLS
instance; it is the VPLS instance that forms the logic bridge over a
packet-switched network (PSN). The VPLS instance is assigned a unique VPN ID.
The PE routers use
the VFI to establish a full-mesh LSP of emulated VCs to all the other PE
routers in the VPLS instance. PE routers obtain the membership of a VPLS
instance.
The full-mesh
configuration allows the PE router to maintain a single broadcast domain. The
CE devices view the VPLS instance as an emulated LAN.
To avoid the problem
of a packet looping in the provider core, the PE devices enforce a
split-horizon principle for the emulated VCs. That means if
a packet is received on an emulated VC, it is not forwarded on any other
emulated VC.
After the VFI has
been defined, it needs to be bound to a bridge-domain to the CE device.
The packet
forwarding decision is made by looking up the Layer 2 VFI of a particular VPLS
domain.
A VPLS instance on a
particular PE router receives Ethernet frames that enter on specific physical
or logical ports and populates a MAC table similarly to how an Ethernet switch
works. The PE router can use the MAC address to switch those frames into the
appropriate LSP to be delivered to another PE router at a remote site.
If the MAC address
is not in the MAC address table, the PE router replicates the Ethernet frame
and floods it to all logical ports associated with that VPLS instance, except
the ingress port where it just entered. The PE router updates the MAC table as
it receives packets on specific ports and removes addresses that are not used
for specific periods.
Ring
Configuration
Ring configuration
reduces both signaling and replication overhead, and also the bandwidth
utilization for multicast traffic. Ring VPLS has an interconnection of PEs in a
ring fashion. The main difference between ring and mesh VPLS is that in mesh
VPLS, split horizon is enabled between the core PWs, and in a ring VPLS, split
horizon is disabled. To prevent the consequential loop, at least one span in
the ring is deprived of the PW configuration, that is, in a ring formed from X
number of PEs, there will be (X-1) PWs with split horizon disabled.
Comparison of
Mesh VPLS with Ring VPLS
VPLS builds a full
mesh of connections by default. In full mesh VPLS, multiple copies of customer
traffic is present in the network path. In full mesh VPLS, if the number of
multicast receiving node is N, there will be around N/2~1 copies of traffic
along the network path.
In ring VPLS, a
single copy of customer traffic traverses the network path. IGMP snooping
feature replicates multicast steam to all destination sites which have joined
the multicast group. Its forwarding mechanism is similar to Ethernet multicast
forwarding mechanism. Ring topology is best suited for multicast application
where the receivers are distributed across the PEs. Flooding of multicast
traffic in the ring can be controlled by enabling IGMP snooping on the VPLS
service.
Fault Handling
in Ring VPLS
It is recommended
to have protected TP tunnels between all PEs for robust network. In such a
topology, a single link fault has no effect on the multicast entries and has a
switch time of 50 milli-seconds. To counter multiple failures in the ring,
redundancy at the router end is relied upon as shown in the below figure.
Figure 2. Efficient
Video Distribution Logical Topology
The active or the
standby state at the router is handled by the native multicast protocol and
redundancy configurations at the router end.
Configuring
VPLS
Provisioning a VPLS
link involves provisioning the associated bridge-domain and the VFI on the PE.
Before you configure VPLS, ensure that the network is configured as follows:
-
(Only Dynamic
MPLS) Configure IP routing in the core network so that the PE routers can reach
each other through the IP.
-
Configure MPLS
in the core network so that a LSP exists between the PE routers.
-
Configure a
loopback interface for originating and terminating Layer 2 traffic. Make sure
that the PE routers can access the loopback interface of other routers.
VPLS configuration
requires you to identify peer PE routers and to attach Layer 2 circuits to the
VPLS at each PE router.
- On the CPT platform, the
attachment circuit (AC)-less model is used to provision PWs. There is no AC-VFI
binding in any of the VPLS deployment scenarios. AC is transparent to VFI and
is handled completely by the bridge-domain.
-
VC Type 5
(Ethernet) is supported and not VC Type 4 pseudowire for VPLS.
- Double tag encapsulation
with rewrite POP 1 operation is not supported for VPLS EFP.
Supported
Features on VPLS
-
Multicast ring
topology
-
Internet Group
Management Protocol (IGMP) Snooping
-
MAC learning and
flushing
-
Port-based
Quality of Service (QoS) for MPLS core port
-
Service-based
QoS for VPLS EFP
-
Split-horizon
and shut or no shut operations on VPLS EFP
Interaction of
VPLS with other Features
The CPT VPLS feature
supports QoS, In-Service Software Upgrade (ISSU), High Availability (HA), and
active-active forwarding. Active-Active forwarding is supported by VPLS only
when graceful-restart is enabled.
The CPT VPLS
feature provides multicast support that is required for efficient video traffic
distribution. This is achieved by enabling IGMP snooping on the VPLS
bridge-domain. The IGMP snooping for VPLS on CPT, provides the ability to send
Layer 2 multicast frames from the CE in a VPLS VFI only to those remote peer
CEs that have sent an IGMP request to join the multicast group. To configure
IGMP on VPLS, follow the restrictions and usage guidelines stated in the
chapter,
Configuring IGMP
Snooping. IGMP on VPLS does not support static multicast routers.
The CPT VPLS feature
supports MAC learning and MAC flush on the VPLS bridge-domain and MAC
withdrawal, based on the LDP update. VPLS-capable systems must dynamically
learn MAC addresses on the EFPs and PWs and must be able to forward and
replicate packets across both EFPs and PWs. MAC entries are learnt per VFI. The
CPT system is a distributed system that has fabric cards, line cards, and
CPT-50 shelf. Therefore, the MAC addresses learned on one line card needs to be
learned (or distributed) on the other line cards as well. The CPT VPLS feature
distributes the MAC addresses learnt on one line card to other line cards and
thereby avoids flooding even after a PW switchover. Also, a software MAC
address table is maintained on the fabric cards. This MAC address table
contains all the MAC addresses learned on all the line cards. This table is
used to distribute the MAC addresses in case of a line card reboot or a line
card Online Insertion and Removal (OIR). The MAC address learned are
distributed to all the cards and are stored in their respective hardware
tables. The CPT system supports static MAC entry commands.
The CPT VPLS feature
supports Link Aggregation (LAG) on the EFP side and not the PW side.
On the EFP side, if
Resilient Ethernet Protocol (REP) is enabled, the CPT VPLS feature supports MAC
flush and withdrawal when REP switchover is triggered. MAC flush is triggered
when access PW switchover occurs and when the VPLS EFP comes up per
bridge-domain. When the core PW goes down, the MAC flush occurs per PW. The
following figure explains the REP and VPLS interaction:
When there is a link
failure, the REP ports are unblocked and the REP ring is restored in less than
a second. REP access failure is propagated through REP Topology Change
Notification (TCN) across the ring. REP TCN triggers MAC withdrawal and the
traffic can be quickly restored over the VPLS domain
Supported
Encapsulation and Rewrite Operations
The supported
encapsulation and rewrite operations for VPLS are listed in
Table 2.
Example: Mesh
Topology
This section
contains examples that show how to configure VPLS using Cisco IOS commands.
The example in this
section explains how to configure VPLS in case of a mesh topology that is shown
in the below figure:
! Configuration on PE1
bridge-domain 100
mode vpls
l2 vfi vpls-100 manual
vpn id 100
bridge-domain 100
neighbor 2.2.2.2 encapsulation mpls
neighbor 3.3.3.3 encapsulation mpls
neighbor 4.4.4.4 encapsulation mpls
! Configuration on PE2
bridge-domain 100
mode vpls
l2 vfi vpls-100 manual
vpn id 100
bridge-domain 100
neighbor 1.1.1.1 encapsulation mpls
neighbor 3.3.3.3 encapsulation mpls
neighbor 4.4.4.4 encapsulation mpls
! Configuration on PE3
bridge-domain 100
mode vpls
l2 vfi vpls-100 manual
vpn id 100
bridge-domain 100
neighbor 1.1.1.1 encapsulation mpls
neighbor 2.2.2.2 encapsulation mpls
neighbor 4.4.4.4 encapsulation mpls
! Configuration on PE4
bridge-domain 100
mode vpls
l2 vfi vpls-100 manual
vpn id 100
bridge-domain 100
neighbor 1.1.1.1 encapsulation mpls
neighbor 2.2.2.2 encapsulation mpls
neighbor 3.3.3.3 encapsulation mpls
The example in this
section explains how to configure VPLS in case of a ring topology that is shown
in the below figure:
Note |
Split-horizon is
disabled on PE1 and PE2 to allow packet to go from one VPLS PW to another VPLS
PW
|
! Configuration on PE1
bridge-domain 100
mode vpls
l2 vfi vpls-100 manual
vpn id 100
bridge-domain 100
neighbor 2.2.2.2 encapsulation mpls no-split-horizon
neighbor 4.4.4.4 encapsulation mpls no-split-horizon
Interface 36/11
Service instance 10 ethernet
Encap dot1q 10
Bridge-domain 100
! Configuration on PE2
bridge-domain 100
mode vpls
l2 vfi vpls-100 manual
vpn id 100
bridge-domain 100
neighbor 1.1.1.1 encapsulation mpls no-split-horizon
neighbor 3.3.3.3 encapsulation mpls no-split-horizon
Interface 36/12
Service instance 10 ethernet
Encap dot1q 10
Bridge-domain 100
! Configuration on PE3
bridge-domain 100
mode vpls
l2 vfi vpls-100 manual
vpn id 100
bridge-domain 100
neighbor 2.2.2.2 encapsulation mpls
Interface 4/2
Service instance 10 ethernet
Encap dot1q 10
Bridge-domain 100
! Configuration on PE4
bridge-domain 100
mode vpls
l2 vfi vpls-100 manual
vpn id 100
bridge-domain 100
neighbor 1.1.1.1 encapsulation mpls
Interface 4/2
Service instance 10 ethernet
Encap dot1q 10
Bridge-domain 100
The following
example shows how to enable IGMP snooping on the VPLS bridge-domain and how to
configure the source and host ports:
! Configuration on the bridge-domain
Router(config)# bridge-domain 200
Router(config-bdomain)# mode vpls
Router(config-bdomain)# ip igmp snooping
! Configuration on port 1
Router(config)# interface gi 36/1
Router(config-if)# service instance 10 ethernet
Router(config-if-srv)# encapsulation untagged
Router(config-if-srv)# bridge-domain 30
! Configuration on port 2
Router(config)# interface gi 36/2
Router(config-if)# service instance 10 ethernet
Router(config-if-srv)# encapsulation dot1q 200
Router(config-if-srv)# rewrite ingress pop 1 symmetric
Router(config-if-srv)# bridge-domain 30
! Configuration on port 3
Router(config)# interface gi 36/6
Router(config-if)# service instance 10 ethernet
Router(config-if-srv)# encapsulation dot1q 101 second-dot1q 20
Router(config-if-srv)# rewrite ingress pop 2 symmetric
Router(config-if-srv)# bridge-domain 30
The following
example shows how to enable IGMP immediate leave on the VPLS bridge-domain:
Router(config)# bridge-domain 200
Router(config-bdomain)# mode vpls
Router(config-bdomain)# ip igmp snooping immediate-leave
The following
example shows how to disable IGMP report suppression on the VPLS bridge-domain:
Router(config)# bridge-domain 200
Router(config-bdomain)# mode vpls
Router(config-bdomain)# no ip igmp snooping report-suppression