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.

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.

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.