Virtual Private LAN Service

In Layer 2 switches, multicast traffic is treated like an unknown MAC address or broadcast frame, which causes the incoming frame to be flooded out (broadcast) on every port within a VLAN. Although this is acceptable behavior for unknowns and broadcast frames, this flooded multicast traffic may result in wasted bandwidth on network segments and end stations, as IP multicast hosts can join and be interested in only specific multicast groups.

IGMP snooping entails using information in Layer 3 protocol headers of multicast control messages to determine the processing at Layer 2. By doing so, an IGMP snooping switch provides the benefit of conserving bandwidth on those segments of the network in which no node has expressed interest in receiving packets addressed to the group address.

IGMP snooping can be enabled in the context of VPLS services. The IGMP snooping feature allows for optimization of the multicast data flow to only the SAPs members of the group. The system builds a database of group members per service by listening to IGMP queries and reports from each SAP:

• When the switch receives an IGMP report from a host for a multicast group, the switch adds the host port number to the forwarding table entry.

• When it receives an IGMP leave message from a host, it removes the host port from the table entry, if no other group members are present. It also deletes entries if it does not receive periodic IGMP membership reports from the multicast clients.

The following are IGMP snooping features:

• IGMP v1, v2, and v3 are supported (RFC 1112, Host Extensions for IP Multicasting, and RFC 2236, Internet Group Management Protocol, Version 2).

• IGMP snooping can be enabled and disabled on individual VPLS service instances.

• IGMP snooping can be configured on individual SAPs that are part of a VPLS service. When IGMP snooping is enabled on a VPLS service, all its contained SAPs automatically have snooping enabled.

• Fast leave terminates the multicast session immediately, instead of using the standard group-specific query to check if other group members are present on the network.

• SAPs can be statically configured as multicast router ports. This allows the operator to control the set of ports to which IGMP membership reports are forwarded.

• Static multicast group membership on a per SAP basis can be configured.

• The maximum number of multicast groups (static and dynamic) that a SAP can join can be configured. An event is generated when the limit is reached.

• The maximum number of multicast groups (static and dynamic) that a VPLS instance simultaneously supports can be configured.

• Proxy summarization of IGMP messages reduces the number of IGMP messages processed by upstream devices in the network.

• IGMP filtering allows a subscriber to a service or the provider to block, receive, or transmit permission (or both) to individual hosts or a range of hosts.

  The following types of filters can be defined:

  • Filter group membership that report from a host or range of hosts. This filtering is performed by importing an appropriately-defined routing policy into the SAP.

  • Filters that prevent a host from transmitting multicast streams into the network. The operator can define a data-plane filter (ACL) that drops all multicast traffic, and apply this filter to a SAP.

In Layer 2 switches, multicast traffic is treated like an unknown MAC address or broadcast frame, which causes the incoming frame to be flooded out (broadcast) on every port within a VLAN. Although this is acceptable behavior for unknowns and broadcast frames, this flooded multicast traffic may result in wasted bandwidth on network segments and end stations, as IP multicast hosts can join and be interested in only specific multicast groups.

IGMP snooping entails using information in Layer 3 protocol headers of multicast control messages to determine the processing at Layer 2. By doing so, an IGMP snooping switch provides the benefit of conserving bandwidth on those segments of the network in which no node has expressed interest in receiving packets addressed to the group address.

IGMP snooping can be enabled in the context of VPLS services. The IGMP snooping feature allows for optimization of the multicast data flow to only those SAPs and SDPs that are members of the group. The system builds a database of group members per service by listening to IGMP queries and reports from each SAP and SDP:

• When the switch receives an IGMP report from a host for a multicast group, the switch adds the host port number to the forwarding table entry.

• When it receives an IGMP leave message from a host, it removes the host port from the table entry, if no other group members are present. It also deletes entries if it does not receive periodic IGMP membership reports from the multicast clients.

The following are IGMP snooping features:

• IGMP v1, v2, and v3 are supported (RFC 1112, Host Extensions for IP Multicasting, and RFC 2236, Internet Group Management Protocol, Version 2). On 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, IGMP v1, v2, v3 is supported with both with L2 uplinks and MPLS uplinks.

• IGMP snooping can be enabled and disabled on individual VPLS service instances.

• IGMP snooping can be configured on individual SAPs and SDPs that are part of a VPLS service. When IGMP snooping is enabled on a VPLS service, all its contained SAPs and SDPs automatically have snooping enabled.

• Fast leave terminates the multicast session immediately, instead of using the standard group-specific query to check if other group members are present on the network.

• SDPs and SAPs can be statically configured as multicast router ports. This allows the operator to control the set of ports to which IGMP membership reports are forwarded.

• Static multicast group membership on a per SAP and SDP basis can be configured.

• The maximum number of multicast groups (static and dynamic) that a SAP and SDP can join can be configured. An event is generated when the limit is reached.

• The maximum number of multicast groups (static and dynamic) that a VPLS instance simultaneously supports can be configured.

• Proxy summarization of IGMP messages reduces the number of IGMP messages processed by upstream devices in the network.

• IGMP filtering allows a subscriber to a service or the provider to block, receive, or transmit permission (or both) to individual hosts or a range of hosts. The following types of filters can be defined:

  • Filter group membership that report from a particular host or range of hosts. This filtering is performed by importing an appropriately-defined routing policy into the SAP and SDP.

  • Filters that prevent a host from transmitting multicast streams into the network. The operator can define a data-plane filter (ACL) that drops all multicast traffic, and apply this filter to a SAP and SDP.

Multicast VPLS Registration (MVR) is a bandwidth optimization method for multicast in a broadband services network. MVR allows a subscriber on a port to subscribe and unsubscribe to a multicast stream on one or more network-wide multicast VPLS instances.

MVR assumes that subscribers join and leave multicast streams by sending IGMP join and leave messages. The IGMP leave and join message are sent inside the VPLS to which the subscriber port is assigned. The multicast VPLS is shared in the network while the subscribers remain in separate VPLS services. Using MVR, users on different VPLS cannot exchange any information between them, but still multicast services are provided.

On the MVR VPLS, IGMP snooping must be enabled. On the user VPLS, IGMP snooping and MVR work independently. If IGMP snooping and MVR are both enabled, MVR reacts only to join and leave messages from multicast groups configured under MVR. Join and leave messages from all other multicast groups are managed by IGMP snooping in the local VPLS. This way, potentially several MVR VPLS instances could be configured, each with its own set of multicast channels:

• MVR by proxy

  In some situations, the multicast traffic should not be copied from the MVR VPLS to the SAP on which the IGMP message was received (standard MVR behavior) but to another SAP. This is called MVR by proxy.

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

• MAC FIB size limits

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

  • When the limit is reached on a SAP, 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 not supported at the SAP level.

  • Disable aging allows users to turn off aging for learned MAC addresses on a SAP of a VPLS service instance.

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

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

  • When the limit is reached on a SAP and 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/SDP MAC limit reached is generated when the limit is reached. When the condition is cleared, the log event SAP/SDP 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 not supported at the SAP level and spoke-SDP level.

  • Disable aging allows users to turn off aging for learned MAC addresses on a SAP and spoke-SDP of a VPLS service instance.

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). The age timer for the VPLS instance specifies the aging time for locally learned MAC addresses.

The aging mechanism is considered a low priority process. In most situations, the aging out of MAC addresses can happen in within tens of seconds beyond the age time. To minimize overhead, local MAC addresses on a LAG port, in some circumstances, can take up to two times their respective age timer to be aged out.

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 time-period (the aging time). In each VPLS service instance, there are independent aging timers for locally learned MAC and remotely learned MAC entries in the forwarding database (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 in 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 will prevent any 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 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 services.

Unknown MAC discard is a feature which 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 usually flooded throughout the VPLS can be rate limited on SAP ingress using 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-D, 7210 SAS-Dxp, or 7210 SAS-K 2F1C2T shut down the SAP and create an alarm event when the threshold is exceeded.

When MAC move is enabled, the 7210 SAS-K 2F6C4T or 7210 SAS-K 3SFP+ 8C shut down the SAP or spoke-SDP and create an alarm event when the threshold is exceeded.

In many applications, the split-horizon group concept involving a group of SAPs is useful to prevent direct customer-to-customer traffic exchange (without the traffic being sent to the head-end service nodes). This extension is referred to as a split horizon SAP group. Traffic arriving on a SAP or a spoke-SDP within a split horizon group will not be forwarded to other SAPs configured in the same split horizon group, but will be forwarded to other SAPs, which are not part of the split horizon group.

Per 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. Inter-working with these older systems is improved with the comp-dot1w mode. The differences between the RSTP mode and the comp-dot1w mode are:

• 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 one 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:

• Inter-operation with traditional Layer 2 switches in access network.

• Provides 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.

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 introduced 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. Because 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 preceding features ensure that network ports are never blocked and maintain interoperability with bridges external to the mesh running STP instances.

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

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. When TCN (topology change notification) is received with in the VPLS domain all MACs learned on SAPs are flushed except the SAP on which TCN was received.

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 VPLS in this topology is not efficient, the node includes functionality which can associate several 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) 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) if 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 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 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 pseudo wires to interconnect the VPLS instances located in the two domains.

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

The active-standby Pseudowires 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 managed by the specific STP instance.

The Nokia implementation also alternative methods for providing a 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 L2-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. Per 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 (L2-B switch) 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.

The previous sections described operation principle of several redundancy mechanisms available in context of VPLS service. All of them rely on MAC flush message as a tool to propagate topology change in a context of the specific VPLS. This section aims to summarize basic rules for generation and processing of these messages.

As described on respective sections, the 7210 SAS supports two types of MAC flush message, flush-all-but-mine and flush-mine. The main difference between these messages is the type of action they signal. Flush-all-but-mine requests clearing of all FDB entries learned from all other LDP peers except the originating PE. This type is also defined by RFC 4762 as an LDP MAC address withdrawal with an empty MAC address list.

Flush-all-mine message requests clearing all FDB entries learned from originating PE. This means that this message has exactly other effect then flush-all-but-mine message. This type is not included in RFC 4762 definition and it is implemented using vendor specific TLV.

The advantages and disadvantages of the individual types should be apparent from examples in the previous section. The description here focuses on summarizing actions taken on reception and conditions individual messages are generated.

Upon reception of MAC flush messages (regardless the type) SR-Series PE will take following actions:

• clears FDB entries of all indicated VPLS services conforming the definition

• propagates the message (preserving the type) to all LDP peers, if ‟propagate-mac-flush” flag is enabled at corresponding VPLS level

The flush-mine message is generated under following conditions:

• The flush-mine message is received from LDP peer and ‟propagate-mac-flush” flag is enabled. The message is sent to all LDP peers in the context of VPLS service it was received.

• The flush-mine message is generated when on a SAP or SDP transition from operationally up to an operationally down state and send-flush-on-failure flag is enabled in the context of the specific VPLS service. The message is sent to all LDP peers connected in the context of the specific VPLS service. Note, that enabling ‟send-flush-on-failure” the flag is blocked in VPLS service managed by mVPLS. This is to prevent both messages being sent at the same time.

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 L2-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-l2vpnvpls-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 (L2-B switch in Dual homed CE connection to VPLS) 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 on an access port:

• Ethernet null (Supported on all platforms)

• Ethernet Dot1q (Supported on all platforms)

• Ethernet QinQ (Supported on 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C)

The following encapsulations are supported on an access-uplink port:

• Ethernet QinQ (Supported on all platforms)

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

   Any 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. QinQ encapsulation defined on ingress

   Both VLAN tags are considered.

   Note that the SAP can be defined with a wild-card for the inner label (for example, ‟100.*”). In this situation all packets with an outer label of 100 will be treated as belonging to the SAP. If, on the same physical link, there is also a SAP defined with a QinQ encapsulation of 100.1, then traffic with 100.1 will go to that SAP and all other traffic with 100 as the first label will go to the SAP with the *100.* definition.

In situations 2 and 3, traffic encapsulated with tags for which there is no definition are discarded.

If a bound service name is assigned to a service within the system, the system first checks to ensure 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 any time. 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 (that is, SAP) is operational.

In 7210 SAS-D Access-Uplink mode and 7210 SAS-Dxp Access-Uplink mode, VPLS service MTU is not supported. 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 VPLS service is affected by two MTU values, port MTUs and the VPLS service MTU. The MTU on each physical port defines the largest Layer 2 packet (including all DLC headers) that may be transmitted out a port. The VPLS has a service level MTU that defines the largest packet supported by the service. The service MTU does not include the local encapsulation overhead for each port (QinQ, Dot1Q, TopQ or SDP service delineation fields and headers) but does include the remainder of the packet. As SAPs are created in the system, the SAPs cannot become operational unless the configured port MTU minus the SAP service delineation overhead is greater than or equal to the configured VPLS service MTU. Therefore, an operational SAP is ensured to support the largest packet traversing the VPLS service. The service delineation overhead on each Layer 2 packet is removed before forwarding into a VPLS service.

VPLS services do not support fragmentation and must discard any Layer 2 packet larger than the service MTU after the service delineation overhead is removed.

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 VPLS service MTU. The operational IP-MTU cannot be greater than the VPLS service MTU minus 14 bytes.

• If the configured (administrative) IP-MTU is configured for a value greater than the normalized IP-MTU, based on the VPLS service-MTU, then the operational IP-MTU is reset to equal the normalized IP-MTU value (VPLS service MTU – 14 bytes).

• If the configured (administrative) IP-MTU is configured for a value less than or equal to the normalized IP-MTU, based on the VPLS service-MTU, then the operational IP-MTU is set to equal the configured (administrative) IP-MTU value.

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 non-supported 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 non-supported 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 (The flag also 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 called out separately:

• On the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, spoke or mesh SDP bindings cannot be configured.

• On the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the VPLS service type cannot be M-VPLS.

• On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the VPLS Service type must be 'r-vpls' and any other VPLS service is not allowed.

• MVR from Routed VPLS and to another SAP is not supported.

• Default QinQ SAPs is not supported in R-VPLS service.

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

• IPv4 filters (ingress and egress) can be used with the R-VPLS SAPs. Additionally, IP ingress override filters are supported which affects the behavior of the IP filters attached to the R-VPLS SAPs. Please see the following for more information about use of ingress override filters.

• MAC filters (ingress and egress) are not supported for use with R-VPLS SAPs.

• VPLS IP interface is not allowed in a R-VPLS service. The converse also holds.

• On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, during creation of the VPLS service the keyword 'rvpls' must be used. It allows the software know that this is a VPLS service to which an IP interface will be associated.

• On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, the VPLS service can be configured either access SAP or Access-Uplink SAPs.

• On the 7210 SAS-D and 7210 SAS-Dxp, 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, except that default QinQ SAPs cannot be used in a R-VPLS service. The allowed SAP combinations are similar to that available in a plain VPLS service and is as specified in the preceding table in the services Chapter (with the exception noted before).

• On 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, VPLS service can use the following 'svc-sap-type' values: any. Only specific SAP combinations are allowed for a specific svc-sap-type, except that default QinQ SAPs cannot be used in a R-VPLS service. The allowed SAP combinations are similar to that available in a plain VPLS service and is as specified in the preceding table in the services Chapter (with the exception noted before).

• G.8032 or mVPLS/STP based protection mechanism can be used with R-VPLS service. A separate G.8032 control instance or a separate mVPLS/STP instance needs to be used and the R-VPLS SAPs needs to be associated with these control instances such that the R-VPLS SAP's forwarding state is driven by the control instance protocols.

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

• On the 7210 SAS-D, 7210 SAS-Dxp, 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, DHCP snooping is not supported for the SAPs configured in the routed VPLS service. Instead, DHCP relay can be enabled on the IES service associated with the routed VPLS service.

• 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.

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

• On the 7210 SAS-D and 7210 SAS-Dxp, egress port based queuing and shaping are available. It is shared among all the SAPs on the port.

• On the 7210 SAS-D and 7210 SAS-Dxp, 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.

• On the 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, per-SAP egress queuing, shaping and scheduling is available. Per SAP egress Dot1p marking is supported for both routed packet and bridged packets.

• On the7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C, IES IP interface bound to routed 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.

Routed VPLS is supported only in the base routing instance on the 7210 SAS-D, 7210 SAS-Dxp, and 7210 SAS-K 2F1C2T. It is supported in both the base routing instance and VPRN services on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C. The following table lists the support available for routing protocols on IP interfaces bound to a VPLS service for different platforms.

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 service.

Use the following syntax to create a VPLS service (for 7210 SAS-D).

config>service# vpls service-id [customer customer-id] [create] [vpn <vpn-id>]  [m-vpls] [svc-sap-type {null-star|dot1q-preserve|any }] [customer-vid <vlan-id>] 

The following is a sample VPLS configuration (for 7210 SAS-D) 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 svc-sap-type any create
description "This is a Distributed VPLS with ANY SAP"
stp
shutdown
exit
no shutdown
exit
vpls 3000 customer 8 svc-sap-type dot1q-preserve customer-vid 300 create
description "This is a VPLS with QinQ Uplink SAP"
stp
shutdown
exit
no shutdown
exit
...
----------------------------------------------
*A:ALA-1>config>service>vpls#

Use the following syntax to create a VPLS service (for 7210 SAS-Dxp).

— config>service# vpls service-id [customer customer-id] [create] [vpn vpn-id] [m-vpls] [customer-vid vlan-id][svc-sap-type {null-star | dot1q-preserve | any}] [b-vpls | i-vpls | r-vpls] 

The following is a sample VPLS configuration (for 7210 SAS-Dxp) 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 svc-sap-type any create
description "This is a Distributed VPLS with ANY SAP"
stp
shutdown
exit
no shutdown
exit
vpls 3000 customer 8 svc-sap-type dot1q-preserve customer-vid 300 create
description "This is a VPLS with QinQ Uplink SAP"
stp
shutdown
exit
no shutdown
exit
...
----------------------------------------------
*A:ALA-1>config>service>vpls#

Use the following syntax to create a VPLS service (for 7210 SAS-K 2F1C2T, 7210 SAS-K 2F6C4T, and 7210 SAS-K 3SFP+ 8C).

— config>service# vpls service-id [customer customer-id] [create] [vpn <vpn-id>] [m-vpls] [svc-sap-type {dot1q-range |any}] [customer-vid <vlan-id>]

The following is a sample VPLS configuration (for 7210 SAS-2F1C2T) output.

*A:sask_duti>config>service>vpls$ info
----------------------------------------------
            shutdown
            stp
                no shutdown
            exit
----------------------------------------------
*A:sask_duti>config>service>vpls$ info detail
----------------------------------------------
            shutdown
            no description
            service-mtu-check
            service-mtu 1514
            no def-mesh-vc-id
            no disable-learning
            no disable-aging
            no discard-unknown
            fdb-table-size 250
            fdb-table-high-wmark 95
            fdb-table-low-wmark 90
            no host-connectivity-verify
            no shcv-policy-ipv4
            no send-flush-on-failure
            local-age 300
            no mfib-table-size
            mfib-table-high-wmark 95
            mfib-table-low-wmark 90
            remote-age 900
            no propagate-mac-flush
            stp
                priority 32768
                hello-time 2
                forward-delay 15
                max-age 20
                hold-count 6
                mode rstp
                mst-max-hops 20
                no mst-name
                mst-revision 0
                no shutdown
            exit
            igmp-snooping
                shutdown
                query-interval 125
                robust-count 2
                report-src-ip 0.0.0.0
                no query-src-ip
                mvr
                    shutdown
                    no description
                    no group-policy
                exit
            exit
            mac-move
                move-frequency 2
                retry-timeout 10
                shutdown
            exit
            static-mac
            exit
            no vsd-domain
----------------------------------------------
*A:sask_duti>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.

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

1. Create an access uplink SAPs to the peer node.

2. Create a management VPLS.

3. Define a SAP in the m-vpls on the port toward the 7210 SAS. Note that the port must be dot1q. The SAP corresponds to the (stacked) VLAN on the 7210 SAS in which STP is active.

4. Optionally modify STP parameters for load balancing.

5. Create access uplink SAPs in the m-vpls using the access uplink SAPs defined in Step 1.

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

7. Create a list of VLANs on the port managed by this management VPLS.

8. Create one or more user VPLS services with SAPs on VLANs in the range defined by Step 6.

   

config>service# vpls service-id [customer customer-id] [create] [m-vpls] 
    description description-string
    sap sap-id create
    managed-vlan-list
        range vlan-range
        stp
        no shutdown

*A:ALA-1>config>service# info
----------------------------------------------
        vpls 2000 customer 6 m-vpls create
            stp
                no shutdown
            exit
            sap 1/1/1:100 create
            exit
            sap 1/1/2:200 create
            exit
            sap 1/1/3:300 create
               managed-vlan-list
                  range 1-50
            exit
            no shutdown
        exit           
----------------------------------------------
*A:ALA-1>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 SAPs (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 SAPs. Load balancing can be achieved in SAP protection scenarios.

The following figure is an example configuration for load balancing across management VPLS.

 (for 7210 SAS-D)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                          
----------------------------------------------

This section provides important information to describe the different configuration options used to populate the required BGP AD and generate the LDP generalized pseudowire-ID FEC fields. There are a large number of configuration options that are available with the this feature. Not all these configurations option are required to start using BGP AD. At the end of this section, it will be apparent that a very simple configuration will automatically generate the required values used by BGP and LDP. In most cases, deployments will provide full mesh connectivity between all nodes across a VPLS instance. However, capabilities are available to influence the topology and build hierarchies or hub and spoke models.

BGP AD automatically creates SDP-bindings using a template to configure SDP-binding configuration parameters. The l2-auto-bind command initiates 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 ‟l2-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 l2-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 l2-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.

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.

The following CLI example shows the BGP AD CLI command tree.

— config>service>vpls>bgp-ad
    — [no] pw-template-bind
    — [no] route-target
    — [no] shutdown
    — vpls-id
    — [no] vsi-export
    — vsi-id
    — [no] vsi-import

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.

*A:H-SASK# show service l2-route-table 

========================================================================
Services: L2 Route Information - Summary
========================================================================
Svc Id     L2-Routes (RD-Prefix)                 Next Hop        Origin
               Sdp Bind Id                           PW Temp Id  
------------------------------------------------------------------------
------------------------------------------------------------------------
No. of L2 Route Entries: 0
========================================================================

===============================================================================
Services: L2 Multi-Homing Route Information - Summary
===============================================================================
Svc Id     L2-Routes (RD-Prefix)        Next Hop        SiteId     State  DF
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
No. of L2 Multi-Homing Route Entries: 0
===============================================================================

========================================================
Services: L2 Bgp-Vpls Route Information - Summary
========================================================
Svc Id     L2-Routes (RD)        Next Hop        Ve-Id
               Sdp Bind Id           PW Temp Id  
--------------------------------------------------------
--------------------------------------------------------
No. of L2 Bgp-Vpls Route Entries: 0
========================================================

========================================================
Services: L2 Bgp-Vpws Route Information - Summary
========================================================
Svc Id     L2-Routes (RD)        Next Hop        Ve-Id
               Sdp Bind Id           PW Temp Id  
--------------------------------- 

When only one of the endpoints has an entry for the service in the l2-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.

*A:H-SASK# show service sdp-using 

===============================================================================
SDP Using
===============================================================================
SvcId      SdpId              Type   Far End              Opr   I.Label E.Label
                                      :GlobalId           State         
-------------------------------------------------------------------------------
1          1:1                Spok   4.4.4.4              Up    130769  130872
2          2:2                Spok   4.4.4.4              Up    130770  130873
3          3:3                Spok   4.4.4.4              Up    130771  130874
4          4:4                Spok   4.4.4.4              Up    130772  130875
5          5:5                Spok   4.4.4.4              Up    130773  130876
6          6:6                Spok   4.4.4.4              Up    130774  130877
7          7:7                Spok   4.4.4.4              Up    130775  130878
8          8:8                Spok   4.4.4.4              Up    130776  130879
9          9:9                Spok   4.4.4.4              Up    130777  130880
10         10:10              Spok   4.4.4.4              Up    130778  130881
11         11:11              Spok   4.4.4.4              Up    130779  130882
12         12:12              Spok   4.4.4.4              Up    130780  130883 

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.

This section provides a brief overview of the tasks that must be performed to configure a management VPLS for SAP protection and provides the CLI commands. The following tasks should be performed on both nodes providing the protected VPLS service.

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

1. Create an SDP to the peer node.

2. Create a management VPLS.

3. Define a SAP in the m-vpls on the port toward the 7210 SAS. Note that the port must be dot1q. The SAP corresponds to the (stacked) VLAN on the 7210 SAS in which STP is active.

4. Optionally modify STP parameters for load balancing (see Configuring Load Balancing with Management VPLS on page 414).

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

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

7. Create a list of VLANs on the port managed by this management VPLS.

8. Create one or more user VPLS services with SAPs on VLANs in the range defined by Step 6.

 config>service# vpls service-id [customer customer-id] [create] [m-vpls] 
    description description-string
    sap sap-id create
    managed-vlan-list
        range vlan-range
        stp
        no shutdown

The following is a sample VPLS configuration output.

*A:ALA-1>config>service# info
----------------------------------------------
        vpls 2000 customer 6 m-vpls create
            stp
                no shutdown
            exit
            sap 1/1/1:100 create
            exit
            sap 1/1/2:200 create
            exit
            sap 1/1/3:300 create
               managed-vlan-list
                  range 1-50
            exit
            no shutdown
        exit           
----------------------------------------------
*A:ALA-1>config>service# 

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. The following tasks should be performed on all four nodes providing the protected VPLS service.

Before configuring a management VPLS, please first read Configuring VPLS redundancy Configuring VPLS redundancy 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 the following sample).

2. Create an SDP to the remote peer node (node ALA-B1 in the following sample).

3. Create a management VPLS.

4. Create a spoke-SDP in the m-vpls using the SDP defined in Step 1. Ensure that this mesh-spoke-SDP runs over a protected LSP (see following note).

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

The following is a sample VPLS configuration output.

*A:ALA-A1>config>service# info
----------------------------------------------
...
sdp 1 mpls create
            shutdown
            no description
            signaling tldp
            no ldp
            no sr-isis
            no sr-ospf
            no bgp-tunnel
            no path-mtu
            no adv-mtu-override
            keep-alive
                shutdown
                hello-time 10
                hold-down-time 10
                max-drop-count 3
                timeout 5
                no message-length
            exit

...
----------------------------------------------
*A:ALA-A1>config>service#

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.

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

# 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#