Chapter 77: VPLS management

Overview

Purpose

VPLS is a class of virtual private network multipoint L2 service that allows multiple customer sites to be connected in a single bridged domain contained within the service provider-managed IP/MPLS network. Customer sites in the VPLS appear to be on the same LAN, even if the sites are geographically dispersed.

VPLS offers the following advantages:

Ethernet interfaces on the host access side simplify provisioning.
All routers in the VPLS are part of the same LAN, which simplifies IP addressing and allows customers to control and simplify their routing strategies.
VPLS is protocol independent, which means there is no L2 protocol conversion between LAN and WAN technologies.

You can use HVPLS to eliminate the need for a full mesh of virtual circuits between devices in the VPLS. See HVPLS in this section for more information.

A VPLS can span a single site or multiple sites. A VPLS that spans a single site is called a local VPLS. In a local VPLS, customer data enters the service through multiple access interfaces on a single PE device. No circuit provisioning is required for the local VPLS.

A VPLS that spans multiple sites is called a distributed VPLS. In a distributed VPLS, customer data enters the service using two or more interfaces on different PE devices. The VPLS is transported by service circuits over an IP/MPLS provider core network carried by service tunnels. Service tunnels are created using GRE or MPLS LSPs.

The NFM-P supports end-to-end VPLS configuration using tabbed configuration forms with an embedded navigation tree.

The General tab of the NFM-P service management form displays useful information about the operational state of the service and its sites through the Aggregated Operational State and State Cause indicators.

The Aggregated Operational State indicator has four possible values: Up, Down, Partially Down, and Unknown. The value is derived from the operational states of the sites that are part of the service, as follows:

Up—all sites are operationally up
Partially Down—at least one site is operationally down
Down—all sites are operationally down
Unknown—the service has no provisioned sites

When the Aggregated Service Site Operational State is Partially Down or Down, a check mark appears beside the appropriate State Cause indicator to identify the type of fault to the NFM-P operator. Alarms can be viewed on the Faults page.

When you use the NFM-P to create or discover a service, the NFM-P assigns a default tier value to the service. The Service Tier parameter value is relevant only in the context of composite service topology map views. See Chapter 85, Composite service management for more information about the hierarchical organization of composite services.

Common to all services, such as VPLS, are policies that are assigned to the service. Policies are defined at a global level and can then be applied to components of the service, such as interfaces and circuits, when the service is configured or modified.

The following policies are common to all services:

QoS policies to define ingress classification, policing, shaping, and marking on the ingress side of the interface. QoS policies are configured using the Access Ingress Policy Manager and the Access Egress Policy Manager.
Policer control policies to control access ingress policers and access egress policers under a common hierarchy. Policer control policies are configured using the Policer Control Policy Manager.
Scheduling policies to define hierarchical rate limiting and scheduling to govern the scheduling of queues. Scheduler policies are configured using the Scheduler Policy Manager.
Port scheduler policies define hierarchical bandwidth allocation and scheduling at the egress port level. Port scheduler policies are configured using the Port Scheduler Policy and HSMDA Scheduler Policy forms.
Filter policies to control network traffic into or out of an interface or circuit based on IP or MAC matching criteria. Filter policies are configured using the ACL IP Filter Manager and the ACL MAC Filter Manager.
Accounting policies to count the traffic on a service to ensure proper billing and enforcement of SLAs. Accounting policies are configured using the Accounting Policy Manager.
ANCP policies provide status and control information based on port-up and port-down messages and current line rate changes between the edge device and the access node. ANCP policies are configured using the Manage Subscriber Policies form.
Time of day suites specify time and day restriction policies that are assigned to QoS policies and schedulers, ACL filters, and aggregation schedulers. Time of day suites and time range policies are configured using the Time of Day Suite form and Time Range form, respectively.

See Chapter 49, Policies overview for more information about policies.

Packets that arrive at an edge device are associated with a VPLS based on the access interface on which they arrive. An access interface is uniquely identified using the following parameters:

physical Ethernet port or POS port and channel
encapsulation type
encapsulation identifier (if required)

If there are service issues, the service provider can use OAM tools to troubleshoot service and network transport issues, and ensure problems are handled properly through the physical and logical network.

To provide a VPLS over an MPLS infrastructure, the device is configured to provide bridging and replication for each VPLS. The routers that are part of the VPLS are connected by MPLS LSPs. Multiple VPLS can use the same set of service tunnels. Multiple service tunnels can rely on multiple LSPs. The signaling is specified in sets of ingress and egress VC labels for each VPLS.

The following additional features are configured for the VPLS:

MAC learning for the access ports and tunnels, including filtering based on MAC addresses on a per SAP basis
MAC learning protection on SAPs to prevent DoS attacks from sourcing
rate limiting of broadcast, destination unknown, and multicast traffic on a per access port basis
FIB for each VPLS, including FIB size limits, static MAC addresses, alarms, and discarding unknown locations
optional support for spanning tree for loop detection
GSMP for each VPLS
L2 management interfaces for each VPLS

You can run an OAM Validation test suite for the service by clicking on the Validate button. If the Validate button is not visible, click on More Actions and choose Validate. Alternatively, you can also perform a One Time Validation. If a check mark appears beside the OAM Validation Failed state cause indicator, the test has failed. In addition, the Tested Entity Result tab on the Tests tab displays detailed information about the OAM test result. OAM validation tests are not supported for HVPLS.

Overview

VPLS management overview

Sample VPLS configuration

VPLS management procedures

Workflow to create a VPLS

To view VPLS contents

To modify a VLPS using the topology view