VPLS management overview
HVPLS
A hierarchical VPLS is created by enhancing the VPLS core mesh with a spoke SDP binding that is connected to another site in the same VPLS, a site in another VPLS, or a VLL site.
HVPLS offers the following advantages:
When traffic arrives at an access-spoke circuit, it acts like a bridge port where flooded traffic received on the access spoke is replicated to all other spokes, meshes, or SAPs but it is not transmitted on the port where it is received.
Sample configuration
The following figure shows a sample HVPLS with a mesh and spoke configuration. Spokes 50 and 51 are unidirectional access-spoke circuits bound to service tunnels. The access-spoke circuits exist within the context of a VLL service or VPLS that is interconnected to the original, fully meshed VPLS. Alternatively, the access-spoke circuit can provide interconnectivity to a service site.
Figure 77-1: HVPLS configuration
The NFM-P supports the following HVPLS interconnectivity using spoke SDPs:
MVPLS
VPLS topology loops can occur if either of the following is true:
To remove topology loops, RSTP must be enabled on the redundant spoke SDPs or L2 access interfaces to block some of them from passing traffic. This requires the creation of an MVPLS.
MSTP is an extension of RSTP which allows VLANs to be grouped into spanning tree instances. Each instance has an independent spanning tree topology. MSTP can be run in an MVPLS to provide multiple forwarding paths for data traffic, which allows load balancing and reduces the number of spanning tree instances required to support a large number of VLANs. An MST region comprises a set of interconnected switches that have the same MST configuration. Each region can be configured with up to 16 MST instances. The instance with ID 0 is an internal spanning tree that runs an MST region and sends and receives BPDUs. All other spanning tree instance information is encapsulated within MSTP BPDUs.
An MVPLS is created to run RSTP or MSTP and manage traffic on the associated VPLS. An MVPLS contains sites, spoke SDP bindings, mesh SDP bindings, and L2 access interfaces. The MVPLS spoke SDP bindings and L2 access interfaces are configured to manage the associated VPLS spoke SDP bindings and L2 access interfaces.
In the case of spoke redundancy, the MVPLS runs RSTP on the redundant spoke SDPs and associates the resultant traffic-blocking actions with all VPLS that use the same spoke SDPs.
MVPLS traffic blocking can also be used on the access side to manage redundant L2 access interface connections. A VLAN ID range is specified for each MVPLS L2 access interface which identifies the VC IDs of the managed VPLS L2 access interfaces.
RSTP is enabled by default on an MVPLS. When the Admin state of an MVPLS is down, all managed L2 access interfaces and spoke SDPs in the associated VPLS are disabled. However, if the Admin state of individual L2 access interfaces or spoke SDPs of an MVPLS are down, then the managed VPLS L2 access interfaces or spoke SDPs are not affected by traffic blocking.
A common MVPLS situation occurs when two VPLS are connected by redundant spoke SDPs. If traffic is not blocked on one of the redundant spoke SDPs, then a loop results. To remove the loop, RSTP must be run on the spoke SDPs that form the loop to block one of the redundant spoke SDPs. Blocking is accomplished by creating an MVPLS on each side of the redundant spoke SDPs and creating a composite MVPLS to connect the MVPLS.
Another common MVPLS situation occurs when an access switch with many VLANs is redundantly connected to two other bridges, on which each uplink carries half the VLANs. MSTP allows you to build multiple spanning trees over VLAN trunks and to group and associate the VLANs to spanning tree instances, each with a different port instance cost and port instance priority.
The following figure shows an example of a composite MVPLS that is composed of MVPLS 1, MVPLS 2, and spoke SDPs.
Figure 77-2: Composite MVPLS
Another scenario occurs when multiple L2 access interfaces from a VPLS are connected to the same customer edge equipment. In this case, a single MVPLS must be created with L2 access interfaces defined to manage the traffic on the associated VPLS redundant L2 access interfaces.
Dual homing for VPLS
A VPLS can be configured for dual homing through the use of redundant spoke SDPs. NFM-P handles the redundant spoke SDPs by grouping them together to form an endpoint object. The redundant spoke SDPs provide active and standby pseudowires for the service. This spoke SDP access arrangement allows data flow control and management support without requiring STP, which cannot be enabled on a spoke SDP binding that is under an endpoint. For VPLS, you can associate only spoke SDP bindings with an endpoint, and each endpoint can be associated with a maximum of two spoke SDP bindings.
Sample configurations
The following figure shows a simple dual homing configuration.
Figure 77-3: MTU redundant access to VPLS
VPLS dual homing provides the ability to have an NE deployed as an MTU-s with links to multiple PE NEs without requiring an MVPLS.
Note: You cannot create a VPLS endpoint on a site that has an active or inactive MC ring SAP. See Chapter 45, MC ring groups for more information.
You cannot create an endpoint in an MVPLS.
In this example, the MTU-s has spoke SDPs to two PE devices. One is designated as the primary spoke and the other as the secondary, or standby spoke, based on a precedence value specified for each spoke. The standby spoke is in a blocking state when the primary spoke is available. If the primary spoke becomes unavailable, the MTU-s immediately switches the traffic to the standby spoke. You can configure the service to revert back to the original configuration, after a specified delay, when the primary spoke is again available. Forced manual switchover is also supported.
You can configure a MAC flush to speed the convergence during a switchover. The PE devices that receive the MAC flush remove each MAC address that is associated with the affected VPLS instance and forward the MAC flush to the other PE devices in the VPLS. The following figure shows a dual-homed VPLS for BTV distribution.
Figure 77-4: BTV distribution in redundant VPLS architecture
In the nominal operating mode shown in panel A, the edge router (grey icon) has been configured to statically join all multicast channels and inject them into the aggregation network. The access layer 7x50 unit (directly connected to ISAM) is dual-homed into two aggregation layer 7x50s edge routers (larger icons) using primary and secondary spoke SDPs. A mesh SDP interconnects both aggregation nodes. Injected BTV traffic from the edge router is broadcast on the primary spoke SDPs to the connected MTU devices (panel B).
A copy of the channels is also sent on the mesh SDP to the peer aggregation node, which also replicates the traffic to the connected spoke SDPs (aggregation layer nodes are not aware of primary/secondary spoke selection done by the MTU layer devices). The MTUs only receive traffic from the primary spoke SDP. Traffic received on the secondary spoke SDP is blocked. In the event of a link failure (panel C) or MDA failure (panel D), the MTU switches over to the secondary spoke SDP and immediately start receiving traffic from it instead of the primary spoke SDP.
Composite services also support VPLS with redundant spoke SDP bindings to VLL services. The following figure shows a VPLS and VLL combination example that provides an E2E redundant path.
Figure 77-5: VPLS and VLL combination to provide E2E redundant path
Provider Backbone Bridging in VPLS
Provider Backbone Bridging (PBB) is a technology configuration employed in next-generation networks that utilize carrier-grade Ethernet as the transport architecture. It addresses the potentially enormous increase in MAC addresses stored in the router lookup databases by encapsulating the customer frame in a Provider Ethernet header. The Customer MAC address (C-MAC) is then only dealt with by lower tier (or satellite) H-VPLS PEs. The core H-VPLS PEs only need to handle the MAC addresses (B-MAC) of the backbone provider, which are substantially less in number. For this reason, the technique is also referred to as MAC-in-MAC encapsulation.
IEEE 802.1ah defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB is defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks.
A Provider Backbone Bridged Network is a Virtual Bridged Local Area Network that comprises Backbone Edge Bridges (BEBs) and Backbone Core Bridges (BCBs) under the administrative control of a single backbone provider. Each BEB provides interfaces that encapsulate or verify the encapsulation of customer frames, and then relay those frames across the backbone. The term may also mean a provider who is purchasing a service from another provider and using either a PBN or PBBN internally.
Backbone VLANs are used to create multipoint trunks in the backbone. The B-VLAN determines the route the frames take and limits broadcasting within the backbone. The B-TAG is added to the frame at the Customer Backbone Port (CBP). The selection of B-VLAN used to form the B-TAG is determined by the configuration of the CBP service instance table. This table maps ISIDs to B-VIDs and is created as part of service provisioning.
Backbone VLAN Connectivity
The backbone provider can use and configure MSTP to provide a number of independent spanning tree active topologies and can assign each B-VLAN to one of these active topologies to best use the resources in the network. MVRP, running in the context of each spanning tree active topology, configures the extent of each B-VLAN to the subset of that active topology necessary to support connectivity between the customer points of attachment to the instance of MAC service provided, and can reconfigure that connectivity as required if the spanning tree active topology changes. The operation of MSTP within a backbone provider's network is independent of the operation of any spanning tree protocol within attached provider or customer networks. This is achieved by removing all MSTP BPDUs received or to be transmitted at the service access interfaces. The operation of MVRP within a PBBN is independent of the operation of any configuration protocol within attached customer networks.
SR PBB implementation
The IEEE PBB model is organized around a B-component handling the provider backbone layer and an I-component concerned with the mapping of Customer/Provider Bridge (QinQ) domain (that is, MACs, and VLANs) to the provider backbone (that is, B-MACs, and B-VLANs). The I-component contains the boundary between the customer and backbone MAC domains. PBB encapsulates the customer payload in a provider backbone Ethernet header, which allows the C-MACs to be hidden from the core PEs. A special Group MAC is used for the Backbone Destination MAC when the customer frame type is either unicast, multicast, broadcast, or unknown.
The SR PBB solution can be summarized as follows:
-
Two VPLS variants are employed, namely B-VPLS and I-VPLS, functioning as the B-type BEB, and the I-type BEB respectively. A B-VPLS instance (a service instance within a service router) and its corresponding I-VPLS instances must be co-located in a service router. From a network-wide perspective, a B-VPLS comprises multiple Backbone Virtual Switch Instances (B-VSIs).
Note:
For the description in this section and in the procedures in this chapter, B-VSI is used for a single B-type BEB instance, and is referred to as a B-Site. Similarly, I-VSI is used for a single I-type BEB instance, and is referred to as an I-Site.
-
mB-VPLS and mI-VPLS are also available to provide loop avoidance for B- and I-VPLS in the same way as m-VPLS and regular VPLSs operate.
-
An NFM-P VPLS can include regular sites and either B-Sites or I-Sites. The service should not contain both B-Sites and I-Sites. When a VPLS has at least one B-Site it becomes a B-VPLS. When a VPLS has at least one I-Site, it becomes an I-VPLS.
Note:
Regular sites, B-Sites, and I-Sites cannot change their type after they are created.
-
An I-Site can be bound to one B-Site, but a B-Site can be used by multiple I-VPLSs.
B-VPLS and I-VPLS instances
PBB processing may be seen as a chain of two linked VPLS contexts, namely B-VPLS and I-VPLS. Their characteristics are summarized in the sections that follow.
I-VPLS
I-VPLS is the abbreviated form for Service Instance ID (ISID) VPLS. An I-VPLS instance on a service site is referred to as an I-Site.
The following are I-VPLS and I-Site characteristics:
-
An I-Site operates using customer addressing and maps the C-MACs to B-MACs.
-
You can select one B-Site to associate with an I-Site; the B-Site must be on the same PE NE as the I-Site.
-
I-Sites support only spoke SDP bindings and not mesh SDP bindings.
-
An I-Site L2 access interface, or I-SAP, can co-exist on a port with regular L2 access interfaces or subscriber management M-L2 access interfaces. The existing port encapsulation is supported. An encapsulation tag that is used for service selection on an I-SAP is removed before the PBB encapsulation is added. The appropriate encapsulation tags are added at the remote PBB PE when sending the packet out on the egress access interface.
-
An I-Site can be connected to one or more regular VPLS sites. A regular (network level) VPLS can have a mix of regular sites and I-Sites. The I-Sites of such services are responsible for the mapping of C-MACs to B-MACs. The regular sites of the service function as normal (bridge).
-
ISID is a 24-bit field that carries the service instance identifier associated with this frame. It is used at the destination PE as a demultiplexer field, a function similar to a VC label. Default to service ID only works if the service ID is within the ISID range. For a service with service ID larger than 16 777 215, the ISID value must be specified.
-
The Provider MSTP support in an M-VPLS is in the I-VPLS space.
-
The I-Site MTU must be at least 18 bytes smaller than the B-Site MTU to which it is bound.
-
If a VPLS has an attached I-Site, the Include I-Site(s) indicator on the General tab of the VPLS configuration form is selected.
-
IGMP snooping can be configured for I-Sites and I-L2 Access Interfaces, except on routed I-VPLS services.
-
PIM snooping can be configured for I-Sites and SAP and Spoke SDP bindings of I-VPLS services.
Backbone-VPLS (B-VPLS)
Multiple L2 services can use a single B-VPLS. Ordinarily, a pair of SDP bindings (in opposite directions) provide either point-to-point connection between two sites of a service (as SDP bindings) or between different services (as a service connector). However, a B-VPLS provides a multipoint connection between sites of a service or for multiple services.
The following are properties and characteristics of a B-VPLS and B-Sites:
-
The B-VPLS operates using the provider or backbone addressing (B-MACs).
-
The B-VPLS provides backbone tunneling for one or multiple I-VPLSs.
-
The B-VPLS accepts mesh or spoke SDP bindings, thereby providing both routing and MAC hiding using PBB/PW encapsulation.
-
The B-VPLS accepts access interfaces using PBB encapsulation for tunneling through an Ethernet-only network.
-
A regular (network level) VPLS can have a mix of regular sites and B-Sites to function as a B-VPLS (that is, operating using B-MACs).
-
The backbone’s Source MAC address can be configured on a B-Site. All the I-Sites provisioned under this B-Site shares the provisioned values. By default, this is a loopback chassis MAC address. It must be a unicast MAC address.
-
A B-Site site can not be deleted until all its I-Site associations are removed.
-
A B-Site can have both spoke and mesh SDP bindings and only an MPLS type of tunnel can be used (including LDP SDP). This also applies for a regular pseudowire, where the outgoing PBB frame on a B-SDP (that is, a B-PW) contains a B-VID qtag only if the PW type is Ethernet VLAN. Alternatively, if the pseudowire type is Ethernet, the B-VID qtag is stripped before the frame goes out.
- Only Null, dot1q, and QinQ encapsulation types can be used by a B-Site L2 access interface. These access interfaces must use PBB encapsulation and have the following properties:
-
Ethernet dot1q is applicable to the bulk of PBB use cases, such as one B-VID.
-
Ethernet Null is supported for direct connection between neighboring I-VPLS, for example, when no B-VID is required and all traffic is sent to or from local I-VPLS.
-
There is no requirement for a PBB SAP type for PBB on the B-VPLS SAPs. Only the B-VID is used for tunnel delimitation on the port.
-
The default access interface type is blocked for the B-L2 access interface.
-
The following rules apply to the SAP processing of PBB frames:
> For transit frames (frames not destined to a local MAC), there is no need to process the I-tag component of the PBB frames. Regular Ethernet SAP processing is applied to the backbone header (B-MACs and B-VID).
> If a local I-VPLS instance is associated with the B-VPLS, then local frames (frames originated or terminated on local I-VPLSs) are PBB encapsulated and de-encapsulated using the pbb-etype provisioned under:
related port->I-VPLS->root pbb component
(listed in decreasing order of precedence, where the related port is highest in the order).
-
-
If a VPLS has an attached B-Site, the Include B-Site(s) indicator on the General tab of the VPLS configuration form is selected
Service topology map views
Service and composite service topology maps support PBB.
The service map shows different types of sites with various icons for I-Sites, B-Sites, and Epipe PBB sites. With an I-VPLS bound to B-VPLS, the map shows the PBB backbone network as a cloud. The bindings between I-VPLS and B-VPLS are shown as a binding link.
MRP and MMRP support
The Multiple Registration Protocol allows participants in an MRP application to register Group MAC addresses with other participants in a Bridged LAN. An MRP participant may transmit and receive MRP PDUs. For the PBB implementation, the MRP parameters can be configured at the service site level, on the access interface, or the SDP binding.
If MRP is enabled on the NE, the NFM-P MMRP application automatically advertises the presence of the Group B-MAC address on the active B-VPLS virtual links—that is, on the B-Site spoke bindings or the B-L2 access interfaces. You can view the MMRP entries advertised and/or received on the Forwarding Control→MMRP Entries tabs of the B-Site spoke bindings or the B-L2 access interfaces. All of the MMRP entries may also be viewed together at the I-Site level.
Epipe service with PBB
A PBB tunnel may be linked to an Epipe and to a B-VPLS. MAC switching and learning is not required for the point-to-point service, since all packets ingressing the Epipe access interface are PBB encapsulated and then forwarded to the PBB tunnel for the backbone destination MAC address. Similarly, all the packets ingressing the B-VPLS and destined for the ISID are PBB de-encapsulated and then forwarded to the Epipe access interface. A fully-specified backbone destination address must be provisioned for each PBB Epipe instance to be used for each incoming frame on the related Epipe L2 access interface. If the backbone destination address is not found in the B-VPLS forwarding database, then packets may be flooded through the B-VPLSs.
To enable an Epipe service with PBB, the Epipe site is configured as a PBB site and functions similarly to a VPLS I-Site. This can only be specified during the site’s creation. On the Epipe PBB site, you select a B-Site that acts as the tunnel for the Epipe. You also specify the destination B-MAC address of the remote PE where the other site is located. The following figure shows a simplified view of this configuration.
Figure 77-6: Epipe service link to a B-VPLS
See the 7750 SR OS Services Guide for more information about PBB.
EVPN
The VPLS solution has some limitations: MAC address learning is limited in the data plane, and active-active multi-homing is not available. Ethernet VPN addresses these limitations.
EVPNs are used to connect data centres. An EVPN is a network of PE and CE devices, connected using a layer 2 overlay over a layer 3 network. An EVPN instance is configured on a PE router. The PE router can be the VPLS interface of a VPRN.
In an EVPN, MAC learning between PEs occurs in the control plane. The control plane for advertising MAC reachability information is Multiprotocol BGP (MP-BGP). PEs learn MAC addresses from the CEs that are connected to them and advertise them to other PEs in the control plane using MP-BGP. Control plane learning allows EVPN to support different data plane encapsulation technologies between PEs. The PEs may be connected to each other by an MPLS LSP infrastructure or an IP infrastructure. If an IP or MPLS infrastructure is in use, IP/GRE or MPLS tunneling can be used between the PE devices.
In addition to MAC learning within the control plane, BGP-EVPN is capable of efficient multi-destination traffic delivery and active-active multi-homing.
The data plane is configured in VPLS and Epipe. The following data planes are supported:
-
With EVPN-VXLAN integration the VPLS site performs data plane learning on the traffic received from the VXLAN and implements EVPN to distribute the client MAC addresses learned into BGP. VXLAN or Ethernet frames are encapsulated with MPLS when sending the packets over the MPLS core and with the VXLAN tunnel header when sending the packets over the VXLAN network.
Depending on the NE and release, up to two VXLAN instances can be created on a VPLS. If two instances are created, one sends data to the DC LAN and one toward the WAN.
EVPN tunneling with EVPN-VXLAN:
Each VXLAN can be identified using a VNI in the VPLS. The VNI needs to be the same for the VPLS to communicate. Each VPLS is associated with a VPRN for L3 connectivity. If an EVPN tunnel is configured in an IRB backhaul R-VPLS, there is no need to provision the IRB IPv4 addresses on the VPRN.
-
MPLS edge switches (MES) can be PEs in an EVPN. The MES devices are interconnected using LSPs. EVPN-MPLS integration allows the use of MPLS functionality for routing with EVPN control plane learning.
-
EVPN with VPWS offers the benefits of EVPN in a point-to-point implementation. An EVPN-VPWS network offers single-active or active-active multihoming.
-
With PBB-EVPN, instead of sending the customer MAC addresses as control plane learning, the backbone MAC addresses are distributed in the EVPN. This simplifies control plane learning in the EVPN and allows for increased efficiency in a large network.
-
An ETree service is a type of Ethernet service that is based on a rooted-multipoint Ethernet virtual connection. In an ETree, each attachment circuit is designated as either a root or a leaf AC. A leaf AC can send or receive traffic only from a root. A root can send traffic to another root or to a leaf. If a root or leaf tag specified in a SAP, it will replace the outer VLAN tag for data routing.
Ethernet segments
An ES is a group of ports on an NE that are part of the same redundancy group, and are identified by a unique Ethernet Segment Identifier. They can be associated with ports, LAGs, SDPs, or VXLANs. To support multi-homing, the ESI should be the same between two PEs.
The use of an ES composed of physical links satisfies the redundancy requirements for CEs that are directly connected to the ES PEs by a port, LAG, or SDP, however it does not work when there is an aggregation network between the CEs and the ES PEs, and different ESs must be defined in the same port or LAG.
The concept of the physical links in an ES is extended to Ethernet Virtual Circuits where many of such EVCs can be aggregated on a single physical External Network-to-Network Interface (ENNI). An ES that consists of a set of EVCs is referred to as a virtual ES (vES).
A vES can be associated with:
-
For service ranges to be created, the Network Interconnect VXLAN must be set to 1.
Interconnect Ethernet segments
An I-ES is a virtual ES, that is, an ES that consists of a set of Ethernet Virtual Circuits instead of a set of physical links. An I-ES allows DC GWs with two BGP instances to handle VXLAN access networks. I-ESs support the multi-homing functions of BGP MPLS EVPN.
An I-ES is used to connect a VXLAN to MPLS. Both services will be up at the same time with two different BGP instances.
SPB in VPLS
SPB simplifies network creation and configuration because service provisioning is required only at the network edge. SPB uses IS-IS to dynamically build the topology between NEs. The NFM-P supports SPB on B-VPLS services.
SPB allows shortest path forwarding in a mesh network by using multiple equal cost paths. In addition, SPB supports a link state spanning tree. SPB is appropriate for larger layer 2 topologies, with faster convergence than STP variant protocols for the same size networks, and improved use of the mesh topology.
The main components of B-VPLS SPB are:
The control B-VPLS defines the SPB IS-IS instance and is associated with an ECT algorithm and a set of SAPs or spoke SDPs for link connectivity. The user B-VPLS is a logical B-VPLS subset of the control B-VPLS. User B-VPLSs are associated with the forwarding ID, which is a logical backbone VLAN ID, that you define in the control B-VPLS. The user B-VPLS forwarding ID does not have to match the control B-VPLS forwarding ID. The user B-VPLS must be a subset of the control B-VPLS, or else a black hole can occur.
You can perform the following OAM diagnostic tests on SPB-enabled B-VPLSs:
Note: SPB does not support MEPs on SAPs and spoke SDP bindings. You cannot create an SPB instance on a control or user B-VPLS if any MEPs or MIPs are enabled on a SAP or spoke SDP binding. Virtual MEPs are supported. You cannot configure MIPs on SPB-enabled SAP and spoke SDP bindings.
Static B-MACs and ISIDs
An SPB interface on a SAP or SDP can have static B-MACs and static ISIDs that are not part of the SPB network or region. Static B-MACs and ISIDs allow SPB networks to interface with other PBB networks that use other control planes. Static B-MACs allow remote PBB Epipes to connect to SPB managed networks. Static ISIDs allow I-VPLS services to connect to non-SPB I-VPLS services. You can define an ISID policy to use the default multicast tree and to suppress the advertisement of ISIDs in SPB when I-VPLS or static ISIDs are used for unicast services. See To create a static ISID range on a VPLS B-L2 access interface or spoke SDP binding, To create a static B-MAC on a B-VPLS site, and To create an ISID policy on a control or user B-VPLS site for more information.
SPB B-VPLS audit
You can perform an RCA audit on an SPB-enabled B-VPLS to verify whether:
- all user B-VPLS SAPs and spoke SDP bindings are fate-shared with a control B-VPLS. The following are the fate-sharing rules:
-
a user B-VPLS Dot1Q SAP fate-shares with the control B-VPLS SAP if they are in the same physical port
-
a user B-VPLS QinQ SAP fate-shares with a control B-VPLS SAP if they are in the same physical port and have the same top tag
-
a user B-VPLS spoke SDP binding fate-shares with a control B-VPLS spoke SDP binding if they are in the same SDP
-
-
user B-VPLS instances belonging to the same service on different sites must have same forwarding ID
-
the ECT-to-forwarding ID mapping is consistent on all the sites for the active B-VPLS services
-
the ISID policy (Control/User) of all sites in the B-VPLS is consistent. All sites in this service must have the same ISID configuration if the Use Default Multicast Tree and No Advertise Local parameters are enabled.
-
the ISID policy (Control/User) of all sites in the B-VPLS is configured. ISID ranges that are defined by one service site are be defined by all service sites of this service.
BGP Auto Discovery
BGP Auto Discovery enables a VPLS PE router to discover other PE routers that are part of the same VPLS domain. This allows each PE's configuration to consist only of the identity of the VPLS instance established on a specific PE, and not the identity of every other PE in that VPLS instance. If you need to change the VPLS topology, only the affected PE's configuration needs to change. Other PEs automatically discover the change using MP-BGP and adapt themselves accordingly. In contrast, if the BGP AD functionality is not used, you must then explicitly configure each PE router with the identities of all the other PEs in a specific VPLS.
You must assign a single, globally unique VPLS-ID to each VPLS (that is, the same value for all sites to the same VPLS across the entire network). The VPLS-ID eliminates the possibility of a collision between VPLSs belonging to different service providers.
There is also a globally unique Route Distinguisher (RD) ID associated with a VPLS. Each site also needs a unique ID that is a BGP NLRI. The PE address does not have to be globally routable, but it must be unique within the VPLS. The PE ID can be the PE router ID, for operational convenience.
Each site must also be associated with one or more RT Extended Communities, and the RTs control the distribution of NLRIs.
Each PE distributes the NLRI for each of its sites, with itself as the BGP next hop, and with the appropriate RT for each NLRI. A PE with a specific RT imports all NLRIs that have that same RT (and learns the other PEs addresses through their next hops). H-VPLS can be configured by using multiple RTs.
In summary, the BGP advertisement for a specific site in a PE includes:
Targeted-LDP [(T-)LDP] signaling is set up for the point-to-point PWs between sites using the selected (T-)LDP sessions corresponding to the remote PE(s) that have been recently added to their list.
To auto-create a spoke SDP binding, you must create a PW template policy and distribute the policy to the NEs. The NFM-P policy distribution mechanism is used to send out the template and maintain consistency in the network. The template selection is at the PE level, not at the service level, because not all PEs are capable of supporting BGP AD and some VPLS sites may not support BGP discovery.
Consider the following with regard to tunnel creation:
-
If you plan to use BGP AD for all or part of the VPLS, you must not enable automatic mesh SDP binding creation.
-
A provisioned PW to a specific remote PE takes precedence over one that is auto-discovered using BGP AD. In other words, if there is an existing SDP binding available, the router selects this existing binding and does not automatically create a new one.
-
When the NFM-P auto-tunnel creation function is being used for non-BGP AD VPLSs, the automatically-created components are excluded from discovery. Also, you cannot select an automatically-created SDP or SDP binding when you create a service tunnel that is to be used as part of a BGP AD VPLS.
An NFM-P-managed VPLS or H-VPLS may consist of various site types located on different PEs, and which in turn, may be of differing versions. Due to these possibilities, some restrictions apply in terms of using Auto Discovery. For example, an M-VPLS site cannot be in the same service with a regular site. However, BGP AD-enabled sites and regular sites can be components of the same VPLS.
BGP VPLS
BGP VPLS is an extension of the VPLS concept. When configured as a BGP VPLS, such a service can interconnect with another BGP VPLS across different VPLS domains.
The control plane of the BGP VPLS provides auto-discovery and signaling capability. In this context, auto-discovery is a means for a PE router to discover other remote PE routers that are members of a given VPLS. The signaling function enables a PE router to know which pseudowire label a given remote PE router will use when sending the data to the local PE router. The BGP VPLS control plane carries sufficient information to provide the auto-discovery and signaling functions concurrently.
Some of the major features of the Nokia BGP VPLS solution include:
-
The data plane is identical with the BGP AD (LDP VPLS) solution. For example, VPLS instances are interconnected via a pseudowire mesh. Split horizon groups may be used for loop avoidance between the pseudowires.
-
Addressing is based on a two-byte VE ID assigned to the VPLS instance.
-
The target VPLS instance is identified by the Route Target (RT) contained in the MP-BGP advertisement (extended community attribute).
-
Pseudowire label signaling is MP-BGP based. As a result, the BGP NLRI content also includes label related information such as block offset, block size, label base, and so forth,
The Nokia BGP VPLS solution is compliant with RFC 4761.
See the 7750 SR OS Services Guide for more information regarding BGP VPLS.
BGP VPLS Multi-homing
The NFM-P allows BGP VPLS multi-homing to be established for CEs and access PEs by first configuring the multi-homing VPLS sites and then assigning the same multi-homing site ID to each.
The following figure shows an example of this approach, where a VPLS contains certain CEs that are multi-homed to pairs of VPLS PEs.
Figure 77-7: CE Multi-homing in VPLS
The BGP/LDP-signaled PW infrastructure (shown as the cloud at the center) is used to interconnect the VSIs between PEs. In this example, CE5 and CE6 are dual-homed to PE1 and PE4. To avoid loops, only one SAP must be active at any point in time between any multi-homed CE (such as CE5 or CE6) and its pair of connected PEs (such as PE1 and PE4). The others are blocked. Service providers use their MP-BGP on PE1 and PE4 to control the activation of the SAPs connected to the same customer site.
Other CE topologies (for instance, square connectivity) where, for example, CE1 and CE4 are part of the same customer site (and are themselves interconnected) are also supported.
When multi-homing a VPLS site using BGP (potentially into different autonomous systems), the PE routers (for example, PE1 and PE4) that are connected to the same customer site (for example, CE5) are configured with the same multi-homing ID. In this way, a loop-free topology is constructed using a routing mechanism such as BGP path selection. When a BGP speaker receives two equivalent NLRIs, it applies standard path selection criteria such as local preference and AS path length to determine which NLRI to choose.
Two VPLS NLRIs are considered equivalent from a path selection perspective if the following are identical:
MVR on VPLS
MVR on VPLS is a bandwidth optimization method for applications on a broadband services network. At the port level, MVR allows a VPLS end user to subscribe or unsubscribe to a multicast stream on one or more network-wide multicast VPLS instances without requiring that the stream be part of the customer VPLS.
MVR on VPLS is a mechanism through which the supporting devices are able to participate in a multicast distribution system. Separate, dedicated VLANs must be constructed specifically for multicast traffic distribution.
MVR assumes that hosts join and leave multicast streams by sending IGMP join and leave messages. The IGMP join and leave messages are sent inside the VPLS to which the host port is assigned. The multicast VPLS is shared in the network while the hosts remain in separate VLANs. For example, two user VPLS that are bound to the same MVR VPLS cannot exchange any information, but the same multicast service can still be provided to them.
An MVR VPLS is a VPLS that is responsible for sending multicast traffic through the network. An MVR VPLS is associated with a multicast package policy and has MVR-enabled sites. The MVR VPLS is configured to distribute certain multicast streams. An MVR VPLS can also be configured as a user VPLS to receive multicast traffic.
A user VPLS is a VPLS that contains SAPs that can receive multicast traffic from an MVR VPLS. Each SAP must be configured individually to use a specific MVR VPLS. Any VPLS, including an MVR VPLS, can be used as a multicast receiver for an MVR VPLS. IGMP and/or MLD snooping must be enabled on each site.
The following figure shows an example of MVR on VPLS. MVR reacts only to join and leave IGMP messages from the multicast groups configured for the MVR VPLS with which the user VPLS is associated. Join and leave messages from all other multicast groups are managed by IGMP and/or MLD snooping. Therefore, several MVR VPLS instances can be configured, each with its own set of multicast channels.
Figure 77-8: MVR on VPLS
In some situations, such as when a host is connected to a 7301 ASAM, the multicast traffic cannot be sent from the MVR VPLS to the VLAN on which the IGMP message was received (standard MVR behavior) but to another VLAN. This configuration is known as MVR by proxy. The 7450 ESS, 7750 SR, and 7950 XRS allow multicast traffic to be sent to a SAP other than the SAP from which the IGMP message originated. When configuring MVR by proxy, you must indicate the MVR VPLS on which the multicast channel is available and the SAP to which the multicast traffic must be copied. The following figure shows an example of MVR by proxy.
Figure 77-9: MVR by proxy
Configuring MVR on VPLS using the NFM-P involves the following steps.
-
Configure PIM before configuring MVR. See Chapter 28, Routing protocol configuration for more information.
-
Create a multicast package policy for all supporting NEs in an MVR VPLS. See Chapter 52, Multicast policies for more information.
Alternatively, you can configure NEs individually in an MVR VPLS using a routing policy statement. See To configure a routing policy statement for more information.
- Create the MVR VPLS. See
To configure MVR for a VPLS site for more information.
-
Associate the multicast package policy with the service, which indicates that a VPLS is an MVR VPLS.
-
Specify the VPLS sites that are the sources of the multicast groups. MVR must be enabled on each site.
-
Configure SAPs only if you are configuring the MVR VPLS to be a user VPLS as well. See To create a VPLS for more information about configuring a user VPLS.
-
- Create the user VPLS. See
To create a VPLS for more information.
-
Associate the MVR VPLS with each SAP for which access to multicast traffic is needed. This association means that IGMP requests received at that SAP for a multicast group are fulfilled as long as the multicast group being requested is included in the multicast package policy of the MVR VPLS. After the SAPs in a user VPLS have been associated with a specific MVR VPLS, the SAP becomes known to the MVR VPLS.
-
If using MVR by proxy, configure a VPLS SAP that is to act as the MVR proxy. See To configure MVR for a VPLS site for more information.
In a situation in which an MVR VPLS has VPLS sites that do not support MVR, the following conditions apply:
-
The ability to configure MVR is not available for the VPLS sites and SAPs of a device that does not support MVR.
-
Multicast package policies are not distributed to the devices that do not support MVR.
GSMP group on VPLS
The edge devices determine the circuit that opens an ANCP session. ANCP provides status and control information such as current line rate and port-up and port-down messages to the edge devices. The edge devices perform the following functions:
A GSMP group is created under the GSMP tab of the VPLS site form. Multiple groups can be defined and different ANCP capabilities can be associated with different groups. A neighbor can be defined in a GSMP group. Multiple neighbors can be configured for each group.
Note: A GSMP group must be configured on VPLS, MVPLS or VPRN for an ANCP session to open.
L2 management interfaces on VPLS
L2 management interfaces act as a host. L2 management interfaces are created the same way out-of-band interfaces are created on VPLS. L2 management interfaces are used for CPM protocols such as telnet, SSH, SNMP, ping, and ANCP.
CPM filtering is used to limit access to L2 management interfaces.
Routed VPLS
A routed VPLS connector joins an L3 access interface within an IES or VPRN service context to a VPLS service on the same site. When an IES or VPRN IP interface is bound to a VPLS site name, the site name cannot be bound to another IP interface. While an IES or VPRN IP interface can only be bound to a single VPLS site, the service context containing the IP interface can have other IP interfaces bound to other VPLS sites. Both the IES or VPRN IP interface and VPLS site must be located on the same NE.
If a VPLS site name does not exist within the system, the binding between the IP interface and the VPLS site remains operationally down until a VPLS site name is assigned to the VPLS site. When an IP interface is bound to a VPLS site, the operational state of the RVPLS binding is dependent upon the operational state of the VPLS site, and whether the IP interface binding is enabled on the VPLS site.
This functionality is limited to supporting devices.
Note: You can create and manage a routed VPLS connector from the navigation tree on the Composite Service (Edit) form or from an IES or VPRN access interface form, routed VPLS path.
The routed VPLS binding will not be operationally up until the Enable IP interface binding parameter is set to true and the VPLS site is operationally up. See To configure a VPLS site for more information.
You can add a routed VPLS L3 access interface to an IGMP interface on an IES or VPRN service.
For supported 7210 SAS-K nodes, RVPLS uses an IES, VPRN L3 access interface, or spoke SDP binding on the same NE as the RVPLS connector.
FIBs
The FIB is the set of information that represents the best forwarding information for a destination. A FIB entry is analogous to a static MAC address, and every computer and network node has a MAC address that is hardware-encoded. In NFM-P, static MAC addresses can be also created on VPLS endpoint objects, access interfaces, and service circuits.
The edge devices perform the packet replication required for broadcast and multicast traffic across the bridged domain. Devices perform MAC-address learning to reduce the amount of unknown destination MAC address flooding. The edge devices learn the source MAC addresses of the traffic arriving on their access and network ports. You can also specify and manage static MAC addresses using the FIB entries table.
Each device maintains a FIB for each VPLS instance. Learned MAC addresses are populated in the FIB table of the service. All traffic is switched based on MAC addresses and forwarded between all participating sites using the service. Unknown destination packets (i.e., the destination MAC address has not been learned) are forwarded on all LSPs to the participating devices for that service until the router responds and the MAC address is learned by the device associated with that service.
Note: Each VPLS FIB entry consumes system resources. The devices allow you to set the maximum number of MAC entries allowed in a VPLS instance to prevent a VPLS instance from consuming a disproportionate amount of resources.
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.
MAC learning
Like an L2 device, 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, 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 an access interface, because it ingressed on a SAP. A remote MAC address is a MAC address received using a service tunnel from another device that is part of the VPLS.
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.
MAC learning can also occur for Split Horizon Groups (SHG) but with accompanying risks. For example, in an L2 environment of an SHG, hosts (among whom mutual communication is disallowed) can launch DoS attacks by sending a flood of packets that source an uplink MAC address to unprotected customer SAPs.
This situation can be managed by controlling MAC learning on SAPs and SDPs. When a frame arrives at a protected SAP or SDP, the MAC is applied to its learning table; when a frame arrives at an unprotected customer SAP or SAP containing the address of a protected source MAC address, the system can be configured to take one of the following actions:
-
The frame is immediately dropped and not learned by the unprotected SAP. As a result, the unprotected SAP does not know the MAC address of the uplink and, therefore, cannot use it to flood packets to other SAPs in the SHG.
In addition, you can specify automatic population of the MAC protect list with source MAC addresses learned on the SAP or SDP.
Auto Learn Mac Protect and Restrict Protected Source functionalities are supported on SAPs, spoke and mesh SDP bindings, split horizon groups, and endpoints under a VPLS service. The functionality is also supported on Service PW-Template policies, in order to allow its use with BGP auto discovery for spoke SDP bindings and split horizon groups.
MAC move
A sustained high MAC re-learn rate can be a sign of a loop somewhere in the VPLS topology. Typically, STP detects loops in the topology, but for those networks that do not run STP, the MAC move feature is an alternative way to protect the network against loops.
When enabled on a VPLS, MAC move monitors the re-learn rate of each MAC. If the rate exceeds the configured allowed limit, it disables the SAP on which the source MAC last arrived. The SAP can be disabled permanently or for a length of time that grows linearly with the number of times the SAP is disabled.
There is also the option of marking a SAP as non-blockable, which means that when the re-learn rate exceeds the limit, another SAP—one that is blockable—is disabled instead. When the MAC move parameter is set to blockable, ports can be blocked in a specific order depending on the number of times the re-learn rate exceeds the configured threshold period.
MAC move is configurable on VPLS SAPs and VPLS spoke SDPs. Blocking information for an object is displayed on the MAC move configuration form for the object. This information includes:
-
the number of MAC learning retries that remain before blocking occurs
-
the time that remains before the blocked object is unblocked
-
the order of blocking, starting with tertiary, secondary and primary
MAC rewrite
With Layer 2 policy-based redirects, packets may be discarded by the far-end router when the packets arrive. This can occur if the far-end IP interface has a different MAC address than the IP interface that is reachable via normal forwarding.
To avoid the discards, you can specify a destination MAC overwrite address for VPLS and MPLS SAPs to override the address specified in the device routing table. When enabled, all Unicast packets have their destination MAC rewritten to an operator-configured value that is expected to be that of the far-end IP interface. Multicast and broadcast packets are unaffected. This feature is not supported on B-VPLS, I-VPLS, Capture SAP, or Routed VPLS. See To assign QoS policies or to enable a MAC override address to a VPLS or MVPLS L2 access interface
Flooding
Traffic that is normally 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 queues can be defined per forwarding class to provide shaping of broadcast traffic, MAC multicast traffic and unknown destination MAC traffic. You can also specify how to classify frames.
Multiple services and service types can be configured on a port. VPLS spanning tree protocols are configured on a per-service site basis, not a per-port basis, thus, multiple instances of STP per site are supported. Unknown destinations, broadcasts, and multicasts are flooded to all other SAPs in the service.
The flooding mechanism and the way that the Interior Gateway Protocol (IGP) operates ensure that no packets are duplicated on any interface. If SAPs are connected together, either through misconfiguration or for redundancy purposes, loops can form and duplicate packets can traverse the network. The STP is designed to prevent multiple SAPs from forwarding a packet into the VPLS
Spanning tree protocols
The NFM-P supports RSTP for VPLS instances and maintains support for legacy STP implementations. STP on the 7750 SR and 7950 XRS incorporates an optimized and compatible implementation of IEEE 802.1D which attempts to eliminate STP blocking of links in the core of the VPLS. STP on the 7210 SAS and 7450 ESS is used to guarantee that service tunnels are not blocked in any circumstance while not imposing artificial restrictions on the placement of the root bridge in the network. To provide this support, all mesh service tunnels are configured as root ports or designated ports.
RSTP, which is the default STP mode managed by the NFM-P, is compliant with IEEE standard 802.1D-2004. Other available STP types include an RSTP variant with 802.1w-2001 backward compatibility, an STP variant that is compliant with 802.1w-2001, and MSTP, an STP variant that is compliant with 802.1s-2002.
The NFM-P verifies STP parameters that are configured within each VPLS instance. However, it does not check the compatibility of STP configurations between interconnected VPLS instances.
IGMP snooping
IGMP snooping allows a device to snoop packets sent between IP multicast devices and IP multicast hosts to learn the IP multicast group membership. The device checks the IGMP packets for the group registration information, and configures multicasting accordingly.
Without IGMP snooping, multicast traffic is forwarded to all ports, which is the same as broadcast traffic. IGMP snooping ensures that multicast traffic is forwarded only to ports that are members of a specific multicast group to reduce the amount of multicast traffic that passes through the device.
You can enable IGMP snooping for VPLS sites, access interfaces, and spoke SDPs.
Note: IGMP snooping is not supported when MAC subnetting is enabled.
MLD snooping
Multicast Listener Discovery snooping is essentially the IPv6 version of IGMP snooping. The guidelines and procedures are very similar to IGMP snooping.
When MLD snooping is not enabled, L2 switches treat multicast traffic like an unknown MAC address or broadcast frame, that is, the frame is flooded out on every port of a VLAN. When MLD snooping is enabled, switches snoop the frame's L3 header for more efficient switching. In the context of IP multicast, only hosts that have expressed interest in receiving packets for the multicast groups have the frames forwarded to them.
The 7x50 router allows the enabling of MLD snooping for VPLS. A database of group members (per VPLS instance) is built by listening to MLD queries and reports from each SAP and SDP of the instance. These reports are forwarded to the multicast routers, if any are present.
MLD snooping is not supported when MAC subnetting is enabled.
Consider the following:
-
Multicast groups can be learned (using the destination IP addresses of multicast packets) through MLD snooping or by static configuration at the port.
-
The Fast leave feature modifies the membership leave mechanism by terminating the session immediately, rather than issuing a group-specific query to check if other members are still present on the network. Therefore, if a port (SAP or SDP) is configured for Fast leave, the session is terminated immediately without checking if the port also has other hosts subscribed to that same multicast group.
-
A multicast router retains a list of multicast group memberships for each attached network. Therefore, a multicast router can assume the role of querier or listener. However, there can be only one querier per physical network.
-
MLD snooping statistics are collected for each NE port, SAP, or SDP binding, and are viewable from the Statistics tab of a VPLS site properties form.
-
MLD snooping can co-exist with IGMP snooping and PIM snooping.
-
MAC-based forwarding entries can be built using MLD snooping results.
PIM snooping
Protocol Independent Multicast snooping for VPLS allows a VPLS PE router to build multicast states by snooping PIM protocol packets that are sent over the VPLS. The VPLS PE then forwards multicast traffic based on the multicast states.
When all receivers in a VPLS are IP multicast routers running PIM, multicast forwarding in the VPLS can be efficient when PIM snooping for VPLS is enabled. After PIM snooping is turned up at the service level, all sites have PIM snooping configured and are set to the down state, by default. If any site does not support this feature, the NFM-P treats it as having PIM snooping turned off.
Since PIM snooping operates on PIM Hello packets as well as Join/Prune packets, PIM neighbors of the current router are learned by snooping on Hello packets. Therefore, in a meshed VPLS, every node learns from every other node's Hello packet and considers that node as a neighbor.
VPLS PE routers only snoop on PIM Hello and Join/Prune packets; they do not generate PIM messages on their own. Therefore, when PIM snooping is configured at the service level, all CE routers must have Join/Prune suppression disabled. If a VPLS PE router detects a condition where Join/Prune suppression is not disabled on one or more CE routers, the PE router puts PIM snooping into a non-operational state for the entire service. A trap on the PE is generated to report this condition and an alarm is raised to the NFM-P operator. To bring PIM snooping back to the operational state, PIM snooping must be disabled and then re-enabled.
Since PIM uses state refreshes, VPLS PE routers may not learn multicast states from all the CE routers, if PIM snooping was just enabled or the all snooping state was just cleared, until the next refresh.
To avoid traffic interruption, PIM snooping should hold up its operations for a period of time (60 seconds, if default timer is used). During this period of time, multicast traffic is flooded in the VPLS just like snooping was not enabled. The NFM-P should have this hold-up timer configurable on VPLS properties panel having range 0-120 with 60 secs as default.
A variety of statistics are gathered for PIM snooping operation and are available for viewing and analysis in the PIM Snooping tab of a VPLS configuration form under the Multicast tab.
PIM snooping is not supported when MAC subnetting is enabled.
Split horizon groups
SHGs control traffic that flows through SAPs or spoke SDPs for a VPLS site. SHGs prevent a packet received on a SAP within the group from being propagated to other members of the group.
SHGs are defined when you create or modify a VPLS site. You can create multiple SHGs for a VPLS site. SHGs can support a mix of spoke SDPs and SAPs. When you create SAPs or spoke SDPs they can be associated with an SHG.
Users can:
Residential split horizon groups
RSHGs are SHGs with the Residential parameter enabled. SAPs that are associated with RSHGs are called lightweight SAPs. RSHGs use dual-pass queue optimization and do not support downstream broadcast or multicast traffic.
Users can:
Note: If a SAP or spoke SDP is associated with an RSHG, then the following apply:
-
MAC pinning is enabled by default and cannot be disabled for the interface
-
IGMP snooping, MLD snooping, and MVR are not configurable for the interface
QTag Manipulation
The NFM-P supports QTag Manipulation on supporting NEs. QTag Manipulation allows you to define actions for inner and outer VLAN IDs, and assign tag values where required. For example, you can configure QinQ Tunneling, VLAN Translation, or other manipulations for L2 traffic that ingresses and egresses the interface. QTag Manipulation is configured on the Port tab of the L2 Access Interface properties form. See the NE documentation for more information about QTag Manipulation actions.
Default SAPs
The NFM-P allows you to create default SAPs that you can use in an L2-based service to perform management tasks or to deliver a specific class of end-user service. One default SAP can be defined on any dot1q encapsulated Ethernet port. Up to four default SAPs can be defined on any Q in Q encapsulated Ethernet port.
You can create a default SAP by specifying an outer encapsulation value of 4095 or *. If the XML API is used, the outer encapsulation value is always 4095. You can also enable the Enable Q in Q Untagged Sap parameter on an NE which allows the creation of the following default SAPs for a Q in Q Ethernet port:
-
The SAP type *.null functions as a default SAP for single-tagged frames on a Q in Q port. This SAP accepts single tags in the range 0 to 4095 as well as untagged traffic.
-
The SAP type *.* functions as a default SAP for double-tagged frames on a Q in Q port. This SAP accepts untagged, single-tagged, and double-tagged frames with tags in the range 0 to 4095.
The following figure shows a default SAP used as a dedicated management port.
Figure 77-10: Default SAP as a dedicated management port
The dotted line shows that a business customer uses an entire port to access an L2 service using a VLAN tag ID 1, which is transparent to the network service provider. The service provider has assigned a default SAP for management of the customer network, as shown by the solid line. The customer uses one SAP for service delivery, and the service provider uses the default SAP to manage the customer network.
Default SAPs can also be used to differentiate one class of service from another on a single port. In the following figure the service provider can deliver aggregated high-speed Internet services on a single default SAP for multiple hosts while applying tags that assign one VLAN per host. At the same time, each of the remaining SAPs on the same port can be deployed for higher-level services, such as triple play delivery, in which multiple or individual hosts are assigned to a single SAP. Using such differentiated SAPs is efficient and significantly increases network scalability, because of the reduced number of SAPs allocated to various customers.
Figure 77-11: Default SAP to differentiate subscriber services
Layer 2 protocol tunneling termination
L2PT allows service providers to preserve the VLAN and Layer 2 protocol configurations of individual customers without impacting the traffic of other customers across the core network. L2PT termination allows Layer 2 PDUs to be transparently tunneled across the core network, avoiding interaction between the network provider and customer protocols.
Transparent L2PT is performed on the ingress side of every SAP or spoke SDP of the PE routers configured with L2PT termination. L2PT tunnels PDUs by overwriting the destination MAC address in an Ethernet frame using the multicast MAC address 01-00-0c-cd-cd-d0. The Ethernet frame is then transparently tunneled over the core network to a peer PE router. The peer PE router at the egress side of the tunnel restores the MAC address and the L2 protocol so that packets are forwarded to all ports in the same VLAN.
L2PT termination can only be enabled if STP is disabled on the VPLS.
BPDU translation
VPLS networks typically interconnect customer sites that use different access technologies, such as Ethernet and bridge-encapsulated ATM PVCs. Because of this, BPDU translation may be necessary to provide end-to-end interconnectivity.
If BPDU translation is enabled on a SAP or spoke SDP, the device intercepts all BPDUs and performs the required translation.
BPDU translation can be enabled only on a SAP or spoke SDP binding if STP is disabled on the VPLS.
DoS protection
To protect a VPLS from a high incoming packet rate that characterizes a DoS attack, you can use the NFM-P to create DoS protection policies for the VPLS L2 access interfaces. A DoS protection policy limits the number of control-plane packets that an interface receives each second, and optionally logs a violation notification if a policy limit is exceeded. You can use the NE System Security form to view the violations for a specific NE.
You can configure a DoS protection policy to control the following on a VPLS L2 access interface:
-
the control-plane packet arrival rate per subscriber host on the interface
-
the overall control-plane packet arrival rate for the interface
-
whether an NE sends a notification trap if a policy limit is exceeded
Each VPLS L2 access interface on an NE that supports DoS protection is automatically assigned a default DoS protection policy. The default policy limits only the overall packet arrival rate for the interface, and cannot be deleted or modified. See the procedure to configure an NE DoS protection policy in the NSP System Administrator Guide for information about creating a DoS protection policy.
DDoS protection on access interfaces
You can configure a DDoS protection policy on a VPLS L2 access interface, I-VPLS I-L2 access interface, MVPLS L2 access interface, or I-MVPLS I-L2 access interface. See the procedure to configure an NE DDoS protection policy in the NSP System Administrator Guide for more information.
Copying and moving SAPs between ports
You can copy and move SAPs between ports. See Copying and moving SAPs in Chapter 16, Port and channel object configuration for more information.