Virtual Private LAN Service

The following IGMP snooping considerations apply:

• Layer-2 multicast is supported in VPLS services.

• IGMP snooping is not supported for VCs (vc-ether or vc-vlan) with control-word enabled.

• IGMP snooping fast leave processing can be enabled only on SAPs and SDPs. IGMP snooping proxy summarization is enabled by default on SAPS and SDPs and cannot be disabled. Proxy summarization and fast leave processing are supported only on SDPs for which VCs are configured to use vc-type ether and do not have control-word enabled.

• IGMP filtering using policies is available on SAPs and SDPs. It is supported only on SDPs for which VCs are configured to use vc-type ether and do not have control-word enabled.

• Dynamic learning is only supported on SDPs for which VCs are configured to use vc-type ether and do not have control-word enabled.

• SDPs that are configured to use VCs of type vc-vlan that need to be mrouter ports must be configured statically. Multicast group memberships for such SDPs must be configured statically. Dynamic learning is not available for these SDPs.

• IGMP snooping is not supported for control-word enabled SDP.

• All 7210 SAS platforms as described in this document, except those configured in the access-uplink operating mode, support only IGMPv1 and IGMPv2 snooping in a VPLS service. These platforms do not support IGMPv3 snooping in a VPLS service.

• All 7210 SAS platforms as described in this document, except those configured in the access-uplink operating mode, support IGMPv3 in an R-VPLS service only. See R-VPLS and IGMPv3 snooping for more information.

DHCPv6 snooping enables users to identify client and network-facing service objects, in accordance with RFC 6221. Use the following commands to specify if the service object is client-facing, network-facing, or both:

• config>service>vpls>sap>dhcp6>snoop [client-facing | network-facing | both]
• config>service>vpls>mesh-sdp>dhcp6>snoop [network-facing]
• config>service>vpls>spoke-sdp>dhcp6>snoop [network-facing]

To support ring deployments, which employs a ring protection mechanism and the forwarding state of the ring port can change dynamically, a configured service object (for example, a SAP or SDP binding) on a ring port can be client-facing or network-facing depending on the forwarding state of the ring port. To support this scenario, the both option is provided. When the both option is configured, the processing rules that apply to both client-facing and network-facing service objects are applied.

On the 7210 SAS, SAPs in a VPLS service are configured as client-facing (customer-facing ports) by default. In other words, all SAPs with DHCPv6 snooping enabled are client facing. The option to configure the SAP as network-facing or both is supported; for example, access ports facing the core as a Layer 2 switch with a high SAP scale mode may need to be configured as network-facing or both.

SDP bindings that are explicitly configured for DHCPv6 snooping are network-facing ports by default.

In accordance with RFC 6221, the 7210 SAS does not forward a DHCPv6 relay-forward message out of client-facing service objects. The message is only forwarded out of network-facing service objects or objects configured as both.

DHCPv6 snooping inspects the DHCP message type and only forwards the relay-reply message. The other DHCP message types are silently discarded.

The 7210 SAS processes the DHCPv6 client messages received on client-facing interfaces when DHCPv6 snooping is enabled on the SAP or SDP binding and the client-facing option is configured.

When snooping is enabled, all DHCPv6 messages that match the preceding criteria are trapped to the CPU. Only the DHCPv6 client messages are processed further; other messages are silently dropped.

The 7210 SAS provides an option to add option-18 (interface ID option) and option-37 (relay agent remote ID option).

To configure option-18, use the config>service>vpls>sap>dhcp6>option> [no] interface-id command . To configure option-37, use the config>service>vpls>sap>dhcp6>option> [no] remote-id command.

The interface-id option is added to relay-forward messages when DHCPv6 snooping is enabled on client-facing service objects.

The remote-id command is optional and only added to relay-forward messages if configured by the user. Configure the no remote-id option to disable the addition of this option. IANA Enterprise-numbers.txt specifies the Nokia Enterprise ID value to use with the DHCPv6 remote-id option.

DHCPv6 messages processed by the node are rate-controlled toward the CPU. A Self-Generated Traffic (SGT) QoS configuration is not supported for DHCPv6 messages. However, in most scenarios the incoming packet markings is used to determine the ingress FC and color (if applicable) and the FC is used for forwarding it out of the appropriate queue on the egress with the appropriate packet header markings (depending on the egress object that packet is forwarded out of - dot1p, IP DSCP, and MPLS EXP field in the packet is updated).

In an MVR configuration, the svc-sap-type of the VPLS service that is the source (also known as MVR VPLS service) and the svc-sap-type of the VPLS service that is the sink (also known as user VPLS service) should match.

The following MAC table management features are required for each instance of a SAP or spoke-SDP within a particular VPLS service instance:

• MAC FIB size limits

  Allows users to specify the maximum number of MAC FIB entries that are learned locally for a SAP or remotely for a spoke-SDP. If the configured limit is reached, no new addresses will be learned from the SAP or spoke-SDP until at least one FIB entry is aged out or cleared, as follows:

  • When the limit is reached on a SAP or spoke-SDP, packets with unknown source MAC addresses are still forwarded (this default behavior can be changed by configuration). By default, if the destination MAC address is known, it is forwarded based on the FIB, and if the destination MAC address is unknown, it will be flooded. Alternatively, if discard unknown is enabled at the VPLS service level, unknown destination MAC addresses are discarded.

  • The log event SAP MAC limit reached is generated when the limit is reached. When the condition is cleared, the log event SAP MAC Limit Reached Condition Cleared is generated.

  • Disable learning at the VPLS service level allows users to disable the dynamic learning function on the service. Disable Learning is supported at the SAP and spoke-SDP level as well.

  • Disable aging allows users to turn off aging for learned MAC addresses. It is supported at the VPLS service level, SAP level and spoke-SDP level.

The size of the VPLS FIB can be configured with a low watermark and a high watermark, expressed as a percentage of the total FIB size limit. If the actual FIB size grows above the configured high watermark percentage, an alarm is generated. If the FIB size falls below the configured low watermark percentage, the alarm is cleared by the system.

Like a Layer 2 switch, learned MACs within a VPLS instance can be aged out if no packets are sourced from the MAC address for a specified period of time (the aging time). In each VPLS service instance, there are independent aging timers for locally learned MAC and remotely learned MAC entries in the FIB. A local MAC address is a MAC address associated with a SAP because it ingressed on a SAP. A remote MAC address is a MAC address received by an SDP from another router for the VPLS instance. The local-age timer for the VPLS instance specifies the aging time for locally learned MAC addresses, and the remote-age timer specifies the aging time for remotely learned MAC addresses.

In general, the remote-age timer is set to a longer period than the local-age timer to reduce the amount of flooding required for destination unknown MAC addresses. The aging mechanism is considered a low priority process. In most situations, the aging out of MAC addresses can happen within tens of seconds beyond the age time. To minimize overhead, local MAC addresses on a LAG port and remote MAC addresses, in some circumstances, can take up to two times their respective age timer to be aged out.

The MAC aging timers can be disabled, which prevents learned MAC entries from being aged out of the FIB. When aging is disabled, it is still possible to manually delete or flush learned MAC entries. Aging can be disabled for learned MAC addresses on a SAP or a spoke-SDP of a VPLS service instance.

When MAC learning is disabled for a service, new source MAC addresses are not entered in the VPLS FIB. MAC learning can be disabled for individual SAPs or spoke-SDPs.

Unknown MAC discard is a feature that discards all packets ingressing the service where the destination MAC address is not in the FIB. The normal behavior is to flood these packets to all end points in the service.

Unknown MAC discard can be used with the disable MAC learning and disable MAC aging options to create a fixed set of MAC addresses allowed to ingress and traverse the service.

Traffic that is flooded throughout the VPLS can be rate limited on SAP ingress through the use of service ingress QoS policies. In a service ingress QoS policy, individual meters can be defined per forwarding class to provide rate-limiting/policing of broadcast traffic, MAC multicast traffic, and unknown destination MAC traffic.

The MAC move feature is useful to protect against undetected loops in a VPLS topology as well as the presence of duplicate MACs in a VPLS service.

If two clients in the VPLS have the same MAC address, the VPLS will experience a high relearn rate for the MAC. When MAC move is enabled, the 7210 SAS will shut down the SAP or spoke-SDP and create an alarm event when the threshold is exceeded.

MAC move allows sequential order port blocking. By configuration, some VPLS ports can be configured as ‟non-blockable” which allows simple level of control which ports are being blocked during loop occurrence.

For each VPLS instance, a preferred STP variant can be configured. The STP variants supported are:

• rstp

  Rapid Spanning Tree Protocol (RSTP) compliant with IEEE 802.1D-2004 - default mode

• dot1w

  compliant with IEEE 802.1w

• comp-dot1w

  operation as in RSTP but backwards compatible with IEEE 802.1w

  (this mode allows interoperability with some MTU types)

• mstp

  compliant with the Multiple Spanning Tree Protocol specified in IEEE 802.1Q-REV/D5.0-09/2005. This mode of operation is only supported in an mVPLS.

While the 7210 SAS initially uses the mode configured for the VPLS, it will dynamically fall back (on a per-SAP basis) to STP (IEEE 802.1D-1998) based on the detection of a BPDU of a different format. A trap or log entry is generated for every change in spanning tree variant.

Some older 802.1W compliant RSTP implementations may have problems with some of the features added in the 802.1D-2004 standard. Interworking with these older systems is improved with the comp-dot1w mode. The differences between the RSTP mode and the comp-dot1w mode are as follows:

• The RSTP mode implements the improved convergence over shared media feature, for example, RSTP will transition from discarding to forwarding in 4 seconds when operating over shared media. The comp-dot1w mode does not implement this 802.1D-2004 improvement and transitions conform to 802.1w in 30 seconds (both modes implement fast convergence over point-to-point links).

• In the RSTP mode, the transmitted BPDUs contain the port's designated priority vector (DPV) (conforms to 802.1D-2004). Older implementations may be confused by the DPV in a BPDU and may fail to recognize an agreement BPDU correctly. This would result in a slow transition to a forwarding state (30 seconds). For this reason, in the comp-dot1w mode, these BPDUs contain the port's port priority vector (conforms to 802.1w).

The 7210 SAS supports two BDPU encapsulation formats, and can dynamically switch between the following supported formats (on a per-SAP basis):

• IEEE 802.1D STP

• Cisco PVST

The Multiple Spanning Tree Protocol (MSTP) extends the concept of the IEEE 802.1w Rapid Spanning Tree Protocol (RSTP) by allowing grouping and associating VLANs to Multiple Spanning Tree Instances (MSTI). Each MSTI can have its own topology, which provides architecture enabling load balancing by providing multiple forwarding paths. At the same time, the number of STP instances running in the network is significantly reduced as compared to Per VLAN STP (PVST) mode of operation. Network fault tolerance is also improved because a failure in one instance (forwarding path) does not affect other instances.

The 7210 SAS implementation of Management VPLS (mVPLS) is used to group different VPLS instances under single RSTP instance. Introducing MSTP into the mVPLS allows the following:

• interoperation with traditional Layer 2 switches in access network

• an effective solution for dual homing of many business Layer 2 VPNs into a provider network

MSTP runs in a MVPLS context and can control SAPs from source VPLS instances. QinQ SAPs are supported. The outer tag is considered by MSTP as part of VLAN range control.

Provider MSTP is specified in (IEEE-802.1ad-2005). It uses a provider bridge group address instead of a regular bridge group address used by STP, RSTP, MSTP BPDUs. This allows for implicit separation of source and provider control planes.

The 802.1ad access network sends PBB PE P-MSTP BPDUs using the specified MAC address and also works over QinQ interfaces. P-MSTP mode is used in PBBN for core resiliency and loop avoidance.

Similar to regular MSTP, the STP mode (for example, PMSTP) is only supported in VPLS services where the m-VPLS flag is configured.

To interconnect 7210 SAS devices (PE devices) across the backbone, service tunnels (SDPs) are used. These service tunnels are shared among multiple VPLS instances. The Nokia implementation of the Spanning Tree Protocol (STP) incorporates some enhancements to make the operational characteristics of VPLS more effective. The implementation of STP on the router is modified to guarantee that service tunnels will not be blocked in any circumstance without imposing artificial restrictions on the placement of the root bridge within the network. The modifications are fully compliant with the 802.1D-2004 STP specification.

When running MSTP, spoke-SDPs cannot be configured. Also, ensure that all bridges connected by mesh SDPs are in the same region. If not, the mesh will be prevented from becoming active (trap is generated).

To achieve this, all mesh SDPs are dynamically configured as either root ports or designated ports. The PE devices participating in each VPLS mesh determine (using the root path cost learned as part of the normal protocol exchange) which of the 7210 SAS devices is closest to the root of the network. This PE device is internally designated as the primary bridge for the VPLS mesh. As a result of this, all network ports on the primary bridges are assigned the designated port role and therefore remain in the forwarding state.

The second part of the solution ensures that the remaining PE devices participating in the STP instance see the SDP ports as a lower cost path to the root instead of a path that is external to the mesh. Internal to the PE nodes participating in the mesh, the SDPs are treated as zero cost paths toward the primary bridge. As a consequence, the path through the mesh are seen as lower cost than any alternative and the PE node will designate the network port as the root port. This ensures that network ports always remain in forwarding state.

A combination of the previously mentioned features ensure that network ports are never blocked and maintain interoperability with bridges external to the mesh that are running STP instances.

When two or more meshed VPLS instances are interconnected by redundant spoke-SDPs (as shown in H-VPLS with spoke redundancy), a loop in the topology results. To remove such a loop from the topology, Spanning Tree Protocol (STP) can be run over the SDPs (links) which form the loop such that one of the SDPs is blocked. As running STP in each and every VPLS in this topology is not efficient, the node includes functionality which can associate a number of VPLSes to a single STP instance running over the redundant SDPs. Node redundancy is therefore achieved by running STP in one VPLS, and applying the conclusions of this STP to the other VPLS services. The VPLS instance running STP is referred to as the ‟management VPLS” or mVPLS.

In the case of a failure of the active node, STP on the management VPLS in the standby node will change the link states from disabled to active. The standby node will then broadcast a MAC flush LDP control message in each of the protected VPLS instances, so that the address of the newly active node can be relearned by all PEs in the VPLS.

It is possible to configure two management VPLS services, where both VPLS services have different active spokes (this is achieved by changing the path-cost in STP). By associating different user VPLSes with the two management VPLS services, load balancing across the spokes can be achieved.

This feature provides the ability to have a node deployed as MTUs (Multi-Tenant Unit Switches) to be multi-homed for VPLS to multiple routers deployed as PEs without requiring the use of mVPLS.

In the configuration example displayed in H-VPLS with spoke redundancy, the MTUs have spoke-SDPs to two PEs devices. One is designated as the primary and one as the secondary spoke-SDP. This is based on a precedence value associated with each spoke. If the primary and secondary spoke-SDPs have the same precedence value, the spoke-SDP with lower ID functions as the primary SDP.

The secondary spoke is in a blocking state (both on receive and transmit) as long as the primary spoke is available. When the primary spoke becomes unavailable (because of link failure, PEs failure, and so on), the MTU immediately switches traffic to the backup spoke and starts receiving/sending traffic to/from the standby spoke. Optional revertive operation (with configurable switch-back delay) is applicable only when one of the spokes is configured with precedence of primary. If not, this action does not take place. Forced manual switchover is also supported.

To speed up the convergence time during a switchover, MAC flush is configured. The MTUs generates a MAC flush message over the newly unblocked spoke when a spoke change occurs. As a result, the PEs receiving the MAC flush will flush all MACs associated with the impacted VPLS service instance and forward the MAC flush to the other PEs in the VPLS network if ‟propagate-mac-flush” is enabled.

Inter-domain VPLS refers to a VPLS deployment where sites may be located in different domains. An example of inter-domain deployment can be where different Metro domains are interconnected over a Wide Area Network (Metro1-WAN-Metro2) or where sites are located in different autonomous systems (AS1-ASBRs-AS2).

Multi-chassis endpoint (MC-EP) provides an alternate solution that does not require RSTP at the gateway VPLS PEs while still using pseudowires to interconnect the VPLS instances located in the two domains.

MC-EP expands the single chassis endpoint based on active-standby pseudowires for VPLS shown in the following figure. In the solution depicted by the following figure, 7210 SAS devices are used as MTUs.

The active-standby pseudowire solution is appropriate for the scenario when only one VPLS PE (MTU-s) needs to be dual-homed to two core PEs (PE1 and PE2).

In configuration shown in the preceding figure, STP is activated on the MTU and two PEs to resolve a potential loop.

To remove such a loop from the topology, Spanning Tree Protocol (STP) can be run over the SDPs (links) which form the loop such that one of the SDPs is blocked. Running STP in every VPLS in this topology is not efficient as the node includes functionality which can associate a number of VPLSes to a single STP instance running over the redundant SDPs. Node redundancy is therefore achieved by running STP in one VPLS. Therefore, this applies the conclusions of this STP to the other VPLS services.

The VPLS instance running STP is referred to as the ‟management VPLS” or mVPLS. In the case of a failure of the active node, STP on the management VPLS in the standby node will change the link states from disabled to active. The standby node will then broadcast a MAC flush LDP control message in each of the protected VPLS instances, so that the address of the newly active node can be relearned by all PEs in the VPLS. It is possible to configure two management VPLS services, where both VPLS services have different active spokes (this is achieved by changing the path-cost in STP). By associating different user VPLSes with the two management VPLS services, load balancing across the spokes can be achieved.

In this configuration the scope of STP domain is limited to MTU and PEs, while any topology change needs to be propagated in the whole VPLS domain.

This is done by using ‟MAC-flush” messages defined by RFC 4762, Virtual Private LAN Services Using LDP Signaling. In the case where STP acts as a loop resolution mechanism, every Topology Change Notification (TCN) received in a context of STP instance is translated into an LDP-MAC address withdrawal message (also referred to as a MAC-flush message) requesting to clear all FDB entries except the ones learned from the originating PE. Such messages are sent to all PE peers connected through SDPs (mesh and spoke) in the context of VPLS services which are managed by the specific STP instance.

The Nokia implementation also provides alternative methods for providing redundant access to Layer 2 services, such as MC-LAG. Also in this case, the topology change event needs to be propagated into VPLS topology to provide fast convergence.

H-VPLS with spoke redundancy shows a dual-homed connection to VPLS service (PE-A, PE-B, PE-C, PE-D) and operation in case of link failure (between PE-C and Layer 2-B). Upon detection of a link failure PE-C will send MAC-Address-Withdraw messages, which will indicate to all LDP peers that they should flush all MAC addresses learned from PE-C. This will lead that to a broadcasting of packets addressing affected hosts and relearning process in case an alternative route exists.

Note that the message described here is different from the message described in previous section and in RFC 4762, Virtual Private LAN Services Using LDP Signaling. The difference is in the interpretation and action performed in the receiving PE. According to the standard definition, upon receipt of a MAC withdraw message, all MAC addresses, except the ones learned from the source PE, are flushed,

This section specifies that all MAC addresses learned from the source are flushed. This message has been implemented as an LDP address message with vendor-specific type, length, value (TLV), and is called the flush-mine message.

The advantage of this approach (as compared to RSTP based methods) is that only MAC-affected addresses are flushed and not the full forwarding database. While this method does not provide a mechanism to secure alternative loop-free topology, the convergence time is dependent on the speed of the specific CE device will open alternative link (Layer 2-B switch in Figure 57) as well as on the speed PE routers will flush their FDB.

In addition, this mechanism is effective only if PE and CE are directly connected (no hub or bridge) as it reacts to physical failure of the link.

A second application of Hierarchical VPLS is in the use of Multi Tenant Units (MTU). MTUs are typically not MPLS-enabled, and therefore have Ethernet links to the closest PE node (see the following figure). To protect against failure of the PE node, an MTU could be dual-homed and therefore have two SAPs on two PE nodes. To resolve the potential loop, STP is activated on the MTU and the two PEs.

Like in the previous scenario, STP only needs to run in a single VPLS instance, and the results of the STP calculations are applied to all VPLSes on the link. Equally, the standby node will broadcast MAC flush LDP messages in the protected VPLS instances when it detects that the active node has failed.

When using STP as described previously is not appropriate, the ‟Selective MAC flush” feature can be used instead.

In this scenario, the 7210 SAS that detects a port failure will send out a flush-all-from-ME LDP message to all PEs in the VPLS. The PEs receiving this LDP message will remove all MAC entries originated by the sender from the indicated VPLS.

A drawback of this approach is that the selective MAC flush does not signal that a backup path was found, only that the previous path is no longer available. In addition, the selective MAC Flush mechanism is effective only if the CE and PE are directly connected (no intermediate hubs or bridges) as it reacts only to a physical failure of the link. Consequently, Nokia recommends using the MAC flush with STP method previously described where possible.

The preceding figure shows a dual-homed connection to VPLS service (PE-A, PE-B, PE-C, PE-D) and operation in case of link failure (between PE-C and Layer 2-B). Upon detection of a link failure PE-C will send MAC-Address-Withdraw messages, which will indicate to all LDP peers that they should flush all MAC addresses learned from PE-C. This will lead that to a broadcasting of packets addressing affected hosts and relearning process in case an alternative route exists.

Note that the message described here is different from the message described in draft-ietf-l2vpn-vpls-ldp-xx.txt, Virtual Private LAN Services over MPLS. The difference is in the interpretation and action performed in the receiving PE. According the draft definition, upon receipt of a MAC-withdraw message, all MAC addresses, except the ones learned from the source PE, are flushed, This section specifies that all MAC addresses learned from the source are flushed. This message has been implemented as an LDP address message with vendor-specific type, length, value (TLV), and is called the flush-all-from-ME message.

The draft definition message is currently used in management VPLS which is using RSTP for recovering from failures in Layer 2 topologies. The mechanism described in this document represent an alternative solution.

The advantage of this approach (as compared to RSTP based methods) is that only MAC-affected addresses are flushed and not the full forwarding database. While this method does not provide a mechanism to secure alternative loop-free topology, the convergence time is dependent on the speed of the specific CE device will open alternative link (Layer 2-B switch in the preceding figure) as well as on the speed PE routers will flush their FDB.

In addition, this mechanism is effective only if PE and CE are directly connected (no hub or bridge) as it reacts to physical failure of the link.

VPLS services are designed to carry Ethernet frame payloads, so it can provide connectivity between any SAPs that pass Ethernet frames. The following SAP encapsulations are supported on the VPLS service:

• Ethernet null

• Ethernet Dot1q

• Ethernet Dot1q Default

• Ethernet Dot1q Explicit Null

The SAP encapsulation definition on Ethernet ingress ports defines which VLAN tags are used to determine the service that the packet belongs:

1. null encapsulation defined on ingress

   VLAN tags are ignored and the packet goes to a default service for the SAP.

2. dot1q encapsulation defined on ingress

   Only first VLAN tag is considered.

3. dot1q Default encapsulation defined on ingress

   Accepted tagged packets not matching any of the configured VLAN encapsulations. This is like a default SAP for tagged packets.

4. dot1q Explicit Null encapsulation defined on ingress

   Any untagged or priority-tagged packets will be accepted.

If a bound service name is assigned to a service within the system, the system first checks to ensure that the service type is VPLS. Secondly, the system ensures that the service is not already bound to another IP interface through the service name. If the service type is not VPLS or the service is already bound to another IP interface through the service ID, the service name assignment fails.

A single VPLS instance cannot be bound to two separate IP interfaces.

An IP interface within an IES or VPRN service context may be bound to a service name at anytime. Only one interface can be bound to a service. When an IP interface is bound to a service name and the IP interface is administratively up, the system scans for a VPLS service context using the name and takes the following actions:

• If the name is not currently in use by a service, the IP interface is placed in an operationally down: Non-existent service name or inappropriate service type state.

• If the name is currently in use by a non-VPLS service or the wrong type of VPLS service, the IP interface is placed in the operationally down: Non-existent service name or inappropriate service type state.

• If the name is currently in use by a VPLS service without the allow-ip-int-binding flag set, the IP interface is placed in the operationally down: VPLS service allow-ip-int-binding flag not set state. There is no need to toggle the shutdown or no shutdown command.

• If the name is currently in use by a valid VPLS service and the allow-ip-int-binding flag is set, the IP interface is eligible to be placed in the operationally up state depending on other operational criteria being met.

When a VPLS service has been bound to an IP interface through its service name, the service name assigned to the service cannot be removed or changed unless the IP interface is first unbound from the VPLS service name.

A VPLS service that is currently attached to an IP interface cannot be deleted from the system unless the IP interface is unbound from the VPLS service name.

The allow-ip-int-binding flag within an IP interface attached VPLS service cannot be reset. The IP interface must first be unbound from the VPLS service name to reset the flag.

When the IP interface is successfully attached to a VPLS service, the operational state of the IP interface is dependent upon the operational state of the VPLS service.

The VPLS service remains down until at least one virtual port (SAP, spoke-SDP, or mesh SDP) is operational.

The user must ensure that the port MTU is configured appropriately so that the largest packet traversing through any of the SAPs (virtual ports) of the VPLS service can be forwarded out of any of the SAPs. VPLS services do not support fragmentation and can discard packets larger than the configured port MTU.

When an IP interface is associated with a VPLS service, the IP-MTU is based on either the administrative value configured for the IP interface or an operational value derived from port MTU of all the SAPs configured in the service. The port MTU excluding the Layer 2 Header and tags for all the ports which have SAPs configured in this VPLS service are considered and the minimum value among those are computed (which is called computed MTU). The operational value of the IP interface is set as follows:

• If the configured (administrative) value of IP MTU is greater than the computed MTU, then the operational IP MTU is set to the computed MTU.

• If the configured (administrative) value of IP MTU is lesser than or equal to the computed MTU, then operational IP MTU is set to the configured (administrative) value of IP MTU.

The allow-ip-int-binding flag on a VPLS service context is used to inform the system that the VPLS service is enabled for routing support. The system uses the setting of the flag as a key to determine what type of ports the VPLS service may span.

The system also uses the flag state to define which VPLS features are configurable on the VPLS service to prevent enabling a feature that is not supported when routing support is enabled.

If a LAG has a unsupported port type as a member, a SAP for the routing-enabled VPLS service cannot be created on the LAG. When one or more routing-enabled VPLS SAPs are associated with a LAG, a unsupported Ethernet port type cannot be added to the LAG membership.

When the allow-ip-int-binding flag is set on a VPLS service, the following features cannot be enabled. Additionally, the flag cannot be enabled while any of these features are applied to the VPLS service. The following restrictions apply to both network mode and access-uplink mode, unless otherwise noted:

• Spoke SDPs and mesh SDPs cannot be configured in an R-VPLS service.

• In access-uplink mode, the VPLS service type cannot be MVPLS.

• In network mode, the VPLS service type must be R-VPLS; no other VPLS service is allowed.

• In access-uplink mode, MVR from an R-VPLS SAP to another SAP is not supported.

• In access-uplink mode, default QinQ SAPs are not supported in an R-VPLS service.

• In network mode, MVR from an R-VPLS SAP to another R-VPLS SAP is supported. See R-VPLS and IGMPv3 snooping for more information.

• The allow-ip-int-binding command cannot be used in a VPLS service that is acting as the G.8032 control instance.

• IP (IPv4 and IPv6) filters (ingress and egress) can be used with R-VPLS SAPs. Additionally, IP ingress override filters are supported, which affects the behavior of the IP filters attached to the R-VPLS SAPs.

• MAC filters (ingress and egress) are supported with R-VPLS SAPs only on the 7210 SAS-Mxp.

• In access-uplink mode, a VPLS IP interface is not allowed in an R-VPLS service, and an R-VPLS service/SAP cannot be configured with a VPLS IP interface.

• In access-uplink mode, the VPLS service can be configured with either access SAPs or access-uplink SAPs. In network mode, the VPLS service can be configured only with access SAPs or with SAPs on hybrid ports.

• In access-uplink mode, the VPLS service can use the following svc-sap-type values: any, dot1q-preserve, and null-star. Only specific SAP combinations are allowed for a specific svc-sap-type. Allowed SAP combinations are similar to those for plain VPLS service, except that default QinQ SAPs are not supported.

• In network mode, the VPLS service can use the following svc-sap-type values: any, null-star, and dot1q-preserve.

• G.8032 or MVPLS/STP based protection mechanisms can be used with an R-VPLS service. A separate G.8032 control instance or a separate MVPLS/STP instance must be used and the R-VPLS SAPs must be associated with these control instances such that the R-VPLS SAP forwarding state is driven by the control instance protocols.

• IP multicast is not supported in an R-VPLS service.

• IGMP snooping is supported in an R-VPLS service for 7210 SAS-T (network mode), 7210 SAS-Mxp, 7210 SAS-S, and 7210 SAS-Sx.

• In access-uplink mode, DHCP snooping is not supported for the SAPs configured in an R-VPLS service. Instead, DHCP relay can be enabled on the IES service associated with the R-VPLS service.

• In network mode, only on 7210 SAS-Mxp, DHCP IPv6 relay can be enabled on the IES service and VPRN service associated with the R-VPLS service. DHCPv6 snooping is not supported.

• In network mode, DHCP snooping is not supported for the SAPs configured in an R-VPLS service. Instead, DHCP relay (IPv4) can be enabled on the IES service associated with the R-VPLS service.

• In network mode, R-VPLS SAPs are allowed on access ports and hybrid ports.

• In network mode, an R-VPLS SAP drops packets received with extra tags. That is, if a packet is received on an R-VPLS SAP, with the number of tags greater than the SAP tags to which it is mapped, then it is dropped. This is true for all supported encapsulations (that is, null, dot1q, and QinQ encapsulations) of the port. For example, double-tagged packets received on a Dot1q SAP configured in an R-VPLS service is dropped on ingress.

• In the saved configuration file, for the R-VPLS service, the R-VPLS service instance appears twice, once for service creation and once with all the other configuration parameters. This is required to resolve references to the R-VPLS service and to execute the configuration without any errors.

The follows information describes QoS support for VPLS SAPs and IP interface in an R-VPLS service:

• SAP ingress classification (IPv4, IPv6, and MAC criteria) is supported for SAPs configured in the service. SAP ingress policies cannot be associated with IES IP interface.

• On 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE, egress port-based queuing and shaping are available. It is shared among all the SAPs on the port.

• On 7210 SAS-Mxp, when the node is operating in SAP based queuing mode, unicast traffic sent out of R-VPLS SAPs uses SAP based egress queues while BUM traffic sent out of R-VPLS SAPs uses per port egress queues. When the node is operating in port based queuing mode, both unicast and BUM traffic sent out of R-VPLS SAPS uses per port egress queues. For more information, see the 7210 SAS-Mxp, R6, R12, S, Sx, T Quality of Service Guide.

• Port based Egress Marking is supported for both routed packets and bridged packets. The existing access egress QoS policy can be used for Dot1p marking and DSCP marking.

• In access-uplink mode, IES IP interface bound to R-VPLS services, IES IP interface on access SAPs, and IES IP interface on access-uplink SAPs are designed for use with inband management of the node. Consequently, they share a common set of queues for CPU-bound management traffic. All CPU bound traffic is policed to predefined rates before being queued into CPU queues for application processing. The system uses meters per application or a set of applications. It does not allocate meters per IP interface. The possibility of CPU overloading has been reduced by use of these mechanisms. Users must use appropriate security policies either on the node or in the network to ensure that this does not happen.

In access-uplink mode, R-VPLS is supported only in the base routing instance. Only IPv4 addressing support is available for IES interfaces associated with a R-VPLS service.

In network mode, R-VPLS is supported in both base routing instances (IES) and VPRN services. IPv4 and IPv6 addressing support is available for IES and VPRN IP interfaces associated with a R-VPLS service.

The following table lists the support available for routing protocols on IP interfaces bound to a VPLS service in access-uplink mode and network mode.

The R-VPLS context supports all spanning tree capabilities that a non R-VPLS service supports. Service-based SHGs are not supported in an R-VPLS context.

This following information describes R-VPLS feature support in conjunction with MAC ACLs:

• MAC criteria are supported with the following features in an R-VPLS service:

  • SAP ingress and egress for both bridged and routed packets with drop and forward action

  • matching for source MAC addresses, destination MAC addresses, Ethertype, and dot1p

  • filter entry counters and mirroring (ingress filters only)

  • either MAC or IP filters can be associated with SAP ingress or SAP egress; that is, they are mutually exclusive

• MAC filter policies are supported in R-VPLS services associated with either an IES or VPRN service.

• MAC filter policies are supported in sap-scale-mode high and low.

• MAC criteria filter policies associated with R-VPLS SAP ingress and SAP egress use the resources for the ingress ACL and egress ACL resource pools configured using the system resource profile. If there are no resources allocated for MAC criteria, the association of the MAC criteria filter policy fails. That is, the user must first allocate the required resources for MAC criteria using the system resource profile before associating a MAC criteria policy with SAPs.

• For routed packets, when the SAP ingress MAC filters and IP override ingress filters are configured, if the entries are matched in both filters and the drop action is configured, the drop action in either the MAC filter policy or IP override filter policy takes precedence. That is, if both the MAC filter policy and IP filter (IP override) policy match a routed packet, the packet is forwarded only if the action configured for all matched entries in both the MAC filter policy and IP filter policy is forward. Otherwise, the packet is dropped if there is a matched entry in either the MAC filter policy of IP filter policy with a drop action.If a counter is associated with both the MAC filter and IP override filter, the counter is incremented for matched entries in both the MAC filter and IP override filter. See VPLS SAP ingress IP filter override for more information about ACL behavior for IP override filters.

• When an IP filter is associated with an R-VPLS SAP on ingress and an IP override filter is associated with the R-VPLS IP interface, and the R-VPLS SAP and IP interface belong to the same R-VPLS service, routed traffic is matched only with IP override filter entries. It is not matched with R-VPLS SAP ingress filter entries. See VPLS SAP ingress IP filter override for more information about ACL behavior for IP override filters.

The following items apply to IGMP snooping in R-VPLS and should be included with the regular VPLS multicast configuration guidelines (see Configuration guidelines for IGMP snooping in VPLS service and R-VPLS supported functionality and restrictions):

• R-VPLS without an IP interface association can be used to emulate VPLS service with support for IGMPv3 snooping.

• R-VPLS with or without IP interface association can be used for IGMPv3 snooping. If enabling MVR on the service then the service should not have an IP interface association.

• IGMPv3 snooping can be enabled in the context of the R-VPLS (both with and without MVR). It cannot be enabled in regular VPLS service. Regular VPLS service supports IGMP v1 and v2 only.

• MVR can be configured in an R-VPLS without an IP interface association. It can be used to leak multicast traffic to a user R-VPLS service with an IP interface configuration. Therefore, a user R-VPLS can be used to forward both unicast and multicast services.

In addition, the following list of guidelines and restrictions pertain to IGMP snooping in an R-VPLS service:

• R-VPLS service can only have a single SAP per port configured in a service. That is, two SAPs on the same port cannot be configured in the same service.

• Spoke-SDPs and mesh SDPs cannot be configured in an R-VPLS service.

• On 7210 SAS devices, on ingress of a port, multicast traffic can be processed in the context of either igmp-snooping (Layer 2 Ethernet multicast with IGMP v1 or v2 snooping) or l3-multicast (either multicast in an Layer 3 service or IGMP snooping in an R-VPLS), but not both. That is, it is not possible to configure SAPs on the port such that one SAP is a receiver for multicast traffic to be processed by IGMP snooping, and another SAP is a receiver for multicast traffic to be processed by IP multicast in the context of Layer 3 service or R-VPLS. An option per port is available using the configure> port> ethernet> multicast-ingress {l2-mc | ip-mc} command to enable one or the other. See the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide for more information about this command. By default, IGMP snooping is enabled to be backward compatible. Users need to explicitly change the IGMP snooping configuration to allow processing of received multicast traffic as IP multicast in the context of Layer 3 service or R-VPLS.

• If a VPLS SAP is configured on the same port as the port on which IP multicast is enabled, then multicast traffic received on the SAP is dropped. Unicast, broadcast, and unknown-unicast packets received on the SAP are forwarded appropriately. This behavior is true only for VPLS SAPs and does not apply to VPLS SDPs, Epipe SAPs, and Epipe SDPs.

• With R-VPLS multicast and when using MVR capability, a port on which receivers are present can be configured to perform either Layer 2 multicast replication (that is, no IP TTL decrement and no source MAC replacement) or Layer 3 multicast replication (that is, IP TTL is decremented and source MAC is replaced with 7210 SAS chassis MAC or IP interface MAC). An option to use either Layer 2 or Layer 3 multicast replication is available using the configure port ethernet multicast-egress {l2-switch | l3-forward} command. See the 7210 SAS-Mxp, R6, R12, S, Sx, T Interface Configuration Guide for more information about this command. All SAPs on the port have the same behavior.

• An MVR R-VPLS must be configured without an IP interface and will support Layer 2 forwarding of both unicast and multicast traffic (that is, no IP forwarding).

• A user RPVLS can be configured with an IP interface and will support Layer 2 forwarding of both unicast and multicast (with (S,G) IP multicast replications) and support Layer 3 forwarding of unicast traffic.

• On 7210 SAS-Mxp and 7210 SAS-R6, when using SAP-based egress queues and scheduler, R-VPLS BUM traffic uses per port egress queues—not per SAP egress queues.

• In an MVR configuration, the svc-sap-type of the R-VPLS service that is the source (also known as MVR R-VPLS service) and the svc-sap-type of the R-VPLS service that is the sink (also known as user R-VPLS service) should match.

• On 7210 SAS-Mxp and 7210 SAS-T, the MVR R-VPLS service configured with IGMPv3 snooping shares resources with TWAMP. An increase in one decreases the amount of resources available for the other. Contact your Nokia representative for more information about scaling of these features.

Use the following syntax to create a VPLS service.

For 7210 SAS (other than access-uplink mode):
    config>service# vpls service-id [customer customer-id] [create][vpn vpn-id] [m-vpls]
    description description-string
    no shutdown
    For 7210 SAS in Access uplink mode:
    config>service# vpls service-id [customer customer-id] [create][ vpn vpn-id] [m-vpls] <service-id> [customer <customer-id>] [create] [vpn <vpn-id>] [m-vpls] [svc-sap-type {null-star|dot1q-preserve|any}] [customer-vid <vlan-id>] 
    description description-string
    no shutdown

The following is a sample VPLS configuration output.

*A:ALA-1>config>service>vpls# info
----------------------------------------------
...
        vpls 1000 customer 1 create
            description "This is a VPLS with NULL SAP"
            stp
                shutdown
            exit
            no shutdown
        exit
        vpls 2000 customer 6 create
            description "This is a Distributed VPLS with DOT1Q SAP"
            stp
                shutdown
            exit
            no shutdown
        exit
...
----------------------------------------------
*A:ALA-1>config>service>vpls#

A default QoS policy is applied to each ingress SAP. Additional QoS policies can be configured in the config>qos context. There are no default filter policies. Filter policies are configured in the config>filter context and must be explicitly applied to a SAP.

VPLS provides scaling and operational advantages. A hierarchical configuration eliminates the need for a full mesh of VCs between participating devices. Hierarchy is achieved by enhancing the base VPLS core mesh of VCs with access VCs (spoke) to form two tiers. Spoke-SDPs are generally created between Layer 2 switches and placed at the Multi-Tenant Unit (MTU). The PE routers are placed at the service provider's Point of Presence (POP). Signaling and replication overhead on all devices is considerably reduced.

A spoke-SDP is treated like the equivalent of a traditional bridge port where flooded traffic received on the spoke-SDP is replicated on all other ‟ports” (other spoke-SDPs or SAPs) and not transmitted on the port it was received (unless a split horizon group was defined on the spoke-SDP, see section Configuring VPLS spoke-SDPs with split horizon).

A spoke-SDP connects a VPLS service between two sites and, in its simplest form, could be a single tunnel LSP. A set of ingress and egress VC labels are exchanged for each VPLS service instance to be transported over this LSP. The PE routers at each end treat this as a virtual spoke connection for the VPLS service in the same way as the PE-MTU connections. This architecture minimizes the signaling overhead and avoids a full mesh of VCs and LSPs between the two metro networks.

A VC-ID can be specified with the SDP-ID. The VC-ID is used instead of a label to identify a virtual circuit. The VC-ID is significant between peer SRs on the same hierarchical level. The value of a VC-ID is conceptually independent from the value of the label or any other datalink specific information of the VC.

This section provides a brief overview of the tasks that must be performed to configure a management VPLS for spoke-SDP protection and provides the CLI commands, see Example configuration for protected VPLS spoke-SDP. The following tasks should be performed on all four nodes providing the protected VPLS service.

Before configuring a management VPLS, please first read Configuring a VPLS SAP for an introduction to the concept of management VPLS and spoke-SDP redundancy:

1. Create an SDP to the local peer node (node ALA-A2 in Example configuration for protected VPLS spoke-SDP).

2. Create an SDP to the remote peer node (node ALA-B1 in Example configuration for protected VPLS spoke-SDP).

3. Create a management VPLS.

4. Create a spoke-SDP in the m-vpls using the SDP defined in Step 1. Ensure that this spoke-SDP runs over a protected LSP.

5. Enable the management VPLS service and verify that it is operationally up.

6. Create a spoke-SDP in the m-vpls using the SDP defined in Step 2.

   Optionally, modify STP parameters for load balancing.

7. Create one or more user VPLS services with spoke-SDPs on the tunnel SDP defined by Step 2.

As long as the user spoke-SDPs created in step 7 are in this same tunnel SDP with the management spoke-SDP created in step 6, the management VPLS will protect them.

Use the following syntax to create a management VPLS for spoke-SDP protection.

config>service# sdp sdp-id mpls create
    far-end ip-address
    lsp lsp-name
    no shutdown

vpls service-id customer customer-id [m-vpls] create
    description description-string
    spoke-sdp sdp-id:vc-id create
    stp
    no shutdown

*A:ALA-A1>config>service# info
----------------------------------------------
...
       sdp 100 mpls create
            far-end 10.0.0.30
            lsp "toALA-B1"
            no shutdown
       exit
       sdp 300 mpls create
            far-end 10.0.0.20
            lsp "toALA-A2"
            no shutdown
       exit
       vpls 101 customer 1 m-vpls create
            spoke-sdp 100:1 create
            exit
            spoke-sdp 300:1 create
            exit
            stp
            exit
            no shutdown
        exit
...
----------------------------------------------
*A:ALA-A1>config>service#

With the concept of management VPLS, it is possible to load balance the user VPLS services across the two protecting nodes. This is done by creating two management VPLS instances, where both instances have different active QinQ spokes (by changing the STP path-cost). When different user VPLS services are associated with either the two management VPLS services, the traffic will be split across the two QinQ spokes. Load balancing can be achieved in SAP protection scenarios.

The following figure shows an example of a configuration for load balancing with management VPLS.

Note: the STP path costs in each peer node should be reversed.

config>service# vpls service-id [customer customer-id] [create] [m-vpls] [svc-sap-type {null-star | dot1q | dot1q-preserve}] [customer-vid vlan-id]
    description description-string
    sap sap-id create
    managed-vlan-list
        range vlan-range
    stp
    no shutdown

*A:ALA-1>config>service# info
----------------------------------------------
        vpls 100 customer 1 m-vpls svc-sap-type dot1q create
            stp
                no shutdown
            exit
            sap 1/1/2:100.* create
                managed-vlan-list
                    range 1-10
                exit
                stp
                    path-cost 1
                exit
            exit
            sap 1/1/3:500.* create
                shutdown
                managed-vlan-list
                    range 1-10
                exit                  
            exit
            no shutdown
        exit
        vpls 200 customer 6 m-vpls svc-sap-type dot1q create
            stp
                no shutdown
            exit
            sap 1/1/2:1000.* create
                managed-vlan-list
                    range 110-200
                exit
            exit
            sap 1/1/3:2000.* create
                managed-vlan-list
                    range 110-200
                exit
                stp
                    path-cost 1
                exit
            exit
            no shutdown
        exit
        vpls 101 customer 1 svc-sap-type dot1q create
            stp
                shutdown
            exit
            sap 1/1/1:100 create
            exit
            sap 1/1/2:1.* create
            exit
            sap 1/1/3:1.* create
            exit
            no shutdown
        exit
        vpls 201 customer 1 svc-sap-type dot1q create
            stp
                shutdown
            exit
            sap 1/1/1:200 create
            exit
            sap 1/1/2:110.* create
            exit
            sap 1/1/3:110.* create
            exit
            no shutdown
        exit                          
----------------------------------------------
*A:ALA-1>config>service# 

config>service# sdp-template sdp-template-id

config>service# l2-auto-bind policy-id [use-provisioned-sdp]

BGP-AD automatically creates SDP-bindings using a template to configure SDP-binding configuration parameters. Layer 2-auto-bind is a command used to initiate a template that is used by BGP-AD for PW instantiation under related VPLS instances.

The template may be referenced in the ‟service vpls bgp-ad” object and used subsequently to instantiate PWs to a remote PE and VSI instance advertised through BGP Auto-Discovery. Changes to these dynamically created objects cannot be performed directly through CLI or SNMP. There are two possible methods to initiate the change:

• Configure a new ‟Layer 2-auto-bind” association under service>vpls>bgp-ad. This method is used when the existing policy is used by multiple VPLS services and only one or a few require the change.

• Change the parameters of the current template. This method is used when a change in parameter is required for the majority of VPLS services that use the template.

Changes are not automatically propagated to the instantiated objects and must be done through one of two tool commands:

tools>perform>service# eval-pw-template policy-id [allow-service-impact]

tools>perform>service>id# eval-pw-template policy-id [allow-service-impact]

This command forces evaluation of changes that were made in the Layer 2-auto-bind template indicated in the command. This command can be applied to an individual VPLS service or all VPLS services that reference the template if no service is specified.

The parameters are divided into three classes:

• class 1 - modified at create time only

• class 2 - modified only when the object is administratively shutdown

• class 3 - no restrictions

Parameters that fall into class 1 will destroy existing objects and recreate objects with the new values. Parameters in class 2 will momentarily shutdown the object, change the parameter, then re-enable the object. Class 3 can be changed without affecting the operational status of the objects of service.

For the Layer 2-auto-bind template, the parameters are treated as follows:

• class 1 - adding or removing a split-horizon-group, switching between a manual and auto SDP

• class 2 - changing the vc-type {ether | vlan}

• class 3 - all other changes

The keyword allow-service-impact enables service impacting changes. If this keyword is not configured, an error message is generated if the parameter changes are service impacting.

With the concept of management VPLS, it is possible to load balance the user VPLS services across the two protecting nodes. This is done by creating two management VPLS instances, where both instances have different active spokes (by changing the STP path-cost). When different user VPLS services are associated with either the two management VPLS services, the traffic will be split across the two spokes.

Load balancing can be achieved in both the SAP protection and spoke-SDP protection scenarios. The following figure shows an example with the following configuration.

• Dut-C - Spoke-SDP

       mvpls 100
       MVPLS M1
       Dut-A — Spoke SDP 1201:100 (STP blocked); 1401:100
       Dut-B — Spoke SDP 1201:100; 2301:100
  

• Dut-C - Spoke-SDP 1401:100; 2301:100

       uvpls 101
       UVPLS U1
       Dut-A — Spoke SDP 1201:101; 1401:101
       Dut-B — Spoke SDP 1201:101; 2301:101
  

• Dut-C - Spoke-SDP 1401:101; 2301:101

       mvpls 200
       MVPLSM2 
       Dut-A — Spoke SDP 1202:200; 1402:200 (STP blocked)
       Dut-B — Spoke SDP 1202:200; 2302:200
  

• Dut-C - Spoke-SDP 1402:200; 2302:200

       uvpls 201
       UVPLS U2
       Dut-A — Spoke SDP 1202:201; 1402:201
       Dut-B — Spoke SDP 1202:201; 2302:201
       Dut-C — Spoke SDP 1402:201; 2302:201
  

Use the following syntax to create a load balancing across two management VPLS instances.

config>service# sdp sdp-id mpls create
    far-end ip-address
    lsp lsp-name
    no shutdown

vpls service-id customer customer-id [m-vpls] create
    description description-string
    spoke-sdp sdp-id:vc-id create
    stp
        path-cost 
    stp
    no shutdown

This following output shows example configurations for load balancing across two protected VPLS spoke-SDPs:

# MVPLS 100 configs

*A:ALA-A# configure service vpls 100 
*A:ALA-A>config>service>vpls# info 
----------------------------------------------
            description "Default tls description for service id 100"
            stp
                no shutdown
            exit
            sap lag-3:100 create
                description "Default sap description for service id 100"
                managed-vlan-list
                    range 101-110
                exit
            exit
            spoke-sdp 1201:100 create
                stp
                    path-cost 100
                exit
            exit
            spoke-sdp 1401:100 create
            exit
            no shutdown
----------------------------------------------
*A:ALA-A>config>service>vpls# 


# UVPLS 101 configs

*A:ALA-A>config>service# vpls 101 
*A:ALA-A>config>service>vpls# info 
----------------------------------------------
            description "Default tls description for service id 101"
            sap lag-3:101 create
                description "Default sap description for service id 101"
            exit
            spoke-sdp 1201:101 create
            exit
            spoke-sdp 1401:101 create
            exit
            no shutdown
----------------------------------------------
*A:ALA-A>config>service>vpls# 


# MVPLS 200 configs
 
*A:ALA-A# configure service vpls 200 
*A:ALA-A>config>service>vpls# info 
----------------------------------------------
            description "Default tls description for service id 200"
            stp
                no shutdown
            exit
            sap lag-3:200 create
                description "Default sap description for service id 200"
                managed-vlan-list
                    range 201-210
                exit
            exit
            spoke-sdp 1202:200 create
            exit
            spoke-sdp 1402:200 create
                stp
                    path-cost 100
                exit
            exit
            no shutdown
----------------------------------------------
*A:ALA-A>config>service>vpls#


# UVPLS 201 configs

*A:ALA-A>config>service# vpls 201 
*A:ALA-A>config>service>vpls# info 
----------------------------------------------

            description "Default tls description for service id 201"
            sap lag-3:201 create
                description "Default sap description for service id 201"
            exit
            spoke-sdp 1202:201 create
            exit
            spoke-sdp 1402:201 create
            exit
            no shutdown
----------------------------------------------
*A:ALA-A>config>service>vpls# exit all

# MVPLS 100 configs

*A:ALA-B# configure service vpls 100 
*A:ALA-B>config>service>vpls# info 
----------------------------------------------
            description "Default tls description for service id 100"
            stp
                priority 0
                no shutdown
            exit
            spoke-sdp 1201:100 create
            exit
            spoke-sdp 2301:100 create
            exit
            no shutdown
----------------------------------------------
*A:ALA-B>config>service>vpls#


# UVPLS 101 configs

*A:ALA-B>config>service# vpls 101 
*A:ALA-B>config>service>vpls# info 
----------------------------------------------

            description "Default tls description for service id 101"
            spoke-sdp 1201:101 create
            exit
            spoke-sdp 2301:101 create
            exit
            no shutdown
----------------------------------------------
*A:ALA-B>config>service>vpls#


# MVPLS 200 configs
 
*A:ALA-B# configure service vpls 200 
*A:ALA-B>config>service>vpls# info 
----------------------------------------------
            description "Default tls description for service id 200"
            stp
                priority 0
                no shutdown
            exit
            spoke-sdp 1202:200 create
            exit
            spoke-sdp 2302:200 create
            exit
            no shutdown
----------------------------------------------
*A:ALA-B>config>service>vpls#




# UVPLS 201 configs

*A:ALA-B>config>service# vpls 201 
*A:ALA-B>config>service>vpls# info 
----------------------------------------------

            description "Default tls description for service id 201"
            spoke-sdp 1202:201 create
            exit
            spoke-sdp 2302:201 create
            exit
            no shutdown
----------------------------------------------
*A:ALA-B>config>service>vpls#

# MVPLS 100 configs

*A:ALA-C# configure service vpls 100 
*A:ALA-C>config>service>vpls# info 
----------------------------------------------

            description "Default tls description for service id 100"
            stp
                priority 4096
                no shutdown
            exit
            spoke-sdp 1401:100 create
            exit
            spoke-sdp 2301:100 create
            exit
            no shutdown
----------------------------------------------
*A:ALA-C>config>service>vpls#


# UVPLS 101 configs

*A:ALA-C>config>service# vpls 101 
*A:ALA-C>config>service>vpls# info 
----------------------------------------------

            description "Default tls description for service id 101"
            spoke-sdp 1401:101 create
            exit
            spoke-sdp 2301:101 create
            exit
            no shutdown
----------------------------------------------
*A:ALA-C>config>service>vpls#

# MVPLS 200 configs
 
*A:ALA-C# configure service vpls 200 
*A:ALA-C>config>service>vpls# info 
----------------------------------------------
            description "Default tls description for service id 200"
            stp
                priority 4096
                no shutdown
            exit
            spoke-sdp 1402:200 create
            exit
            spoke-sdp 2302:200 create
            exit
            no shutdown
----------------------------------------------
*A:ALA-C>config>service>vpls# 


# UVPLS 201 configs

*A:ALA-C>config>service# vpls 201 
*A:ALA-C>config>service>vpls# info 
----------------------------------------------

            description "Default tls description for service id 201"
            spoke-sdp 1402:201 create
            exit
            spoke-sdp 2302:201 create
            exit
            no shutdown
----------------------------------------------
*A:ALA-C>config>service>vpls#

Use the following syntax to enable selective MAC Flush in a VPLS.

config>service# vpls service-id 
    send-flush-on-failure

Use the following syntax to disable selective MAC Flush in a VPLS.

config>service# vpls service-id 
    no send-flush-on-failure

With the concept of management VPLS, it is possible to load balance the user VPLS services across the two protecting nodes. This is done by creating two management VPLS instances, where both instances have different active QinQ spokes (by changing the STP path-cost). When different user VPLS services are associated with either the two management VPLS services, the traffic will be split across the two QinQ spokes. Load balancing can be achieved in SAP protection scenarios.

The following figure shows an example of a configuration for load balancing with management VPLS.

config>service# vpls service-id [customer customer-id] [create][m-vpls] [svc-sap-type {null-star | any | dot1q-preserve}] [customer-vid vlan-id]
    description description-string
    sap sap-id create
    managed-vlan-list
        range vlan-range
    stp
    no shutdown

*A:ALA-1>config>service# info
----------------------------------------------
        vpls 100 customer 1 m-vpls svc-sap-type any create
            stp
                no shutdown
            exit
            sap 1/1/2:100.* create
                managed-vlan-list
                    range 1-10
                exit
                stp
                    path-cost 1
                exit
            exit
            sap 1/1/3:500.* create
                shutdown
                managed-vlan-list
                    range 1-10
                exit                  
            exit
            no shutdown
        exit
        vpls 200 customer 6 m-vpls svc-sap-type any create
            stp
                no shutdown
            exit
            sap 1/1/2:1000.* create
                managed-vlan-list
                    range 110-200
                exit
            exit
            sap 1/1/3:2000.* create
                managed-vlan-list
                    range 110-200
                exit
                stp
                    path-cost 1
                exit
            exit
            no shutdown
        exit
        vpls 101 customer 1 svc-sap-type any create
            stp
                shutdown
            exit
            sap 1/1/1:100 create
            exit
            sap 1/1/2:1.* create
            exit
            sap 1/1/3:1.* create
            exit
            no shutdown
        exit
        vpls 201 customer 1 svc-sap-type any create
            stp
                shutdown
            exit
            sap 1/1/1:200 create
            exit
            sap 1/1/2:110.* create
            exit
            sap 1/1/3:110.* create
            exit
            no shutdown
        exit                          
----------------------------------------------
*A:ALA-1>config>service# 

Using the following figure, assume PE6 was previously configured with VPLS 100 as indicated by the configurations lines in the upper right. The BGP AD process will commence after PE134 is configured with the VPLS 100 instance as shown in the upper left. This shows a very basic and simple BGP AD configuration. The minimum requirement for enabling BGP AD on a VPLS instance is configuring the VPLS-ID and point to a pseudowire template.

In many cases, VPLS connectivity is based on a pseudowire mesh. To reduce the configuration requirement, the BGP values can be automatically generated using the VPLS-ID and the MPLS router-ID. By default, the lower six bytes of the VPLS-ID are used to generate the RD and the RT values. The VSI-ID value is generated from the MPLS router-ID. All of these parameters are configurable and can be coded to suit requirements and build different topologies

A helpful command displays the service information, the BGP parameters and the SDP bindings in use. When the discovery process is completed successfully each endpoint will have an entry for the service.

PE134># show service l2-route-table

When only one of the endpoints has an entry for the service in the Layer 2-routing-table, it is most likely a problem with the RT values used for import and export. This would most likely happen when different import and export RT values are configured using a router policy or the route-target command.

Service-specific commands continue to be available to display service-specific information, including status.

PERs6# show service sdp-using

BGP AD advertises the VPLS-ID in the extended community attribute, VSI-ID in the NLRI and the local PE ID in the BGP next hop. At the receiving PE, the VPLS-ID is compared against locally provisioned information to determine whether the two PEs share a common VPLS. If it is found that they do, the BGP information is used in the signaling phase.