This chapter provides an overview of Virtual Private LAN Service (VPLS) on the 7705 SAR.
Topics in this chapter include:
Topics in this section include:
Virtual Private LAN Service (VPLS), as described in RFC 4762, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, is a type of virtual private network service that allows the connection of multiple sites in a single bridged domain over a provider-managed IP/MPLS network or a Layer 2 Ethernet bridged network. The customer sites in a VPLS instance appear to be on the same LAN, regardless of their location. VPLS uses a native Ethernet SAP or a bridged PDU encapsulated SAP on the customer-facing (access) side, which simplifies the LAN/WAN boundary and allows for rapid and flexible service provisioning.
VPLS offers a balance between point-to-point pseudowire service (Epipe, Ipipe, etc.) and outsourced routed services (VPRN). Unlike VPRN service, VPLS enables each customer to maintain control of their own routing strategies. All customer routers in the VPLS service are part of the same subnet (LAN), which simplifies the IP addressing plan, especially when compared to a mesh architecture constructed from many separate point-to-point connections. The VPLS service management is simplified since the service is not aware of, nor participates in, the IP addressing and routing.
A VPLS service provides connectivity between two or more SAPs on one (local service) or more (distributed service) service routers. The connection appears to be a bridged domain to the customer sites so that protocols, including routing protocols, can traverse the VPLS service.
Other VPLS advantages include:
VPLS is supported on the cards and platforms listed below. A VPLS SAP can reside on the following ports:
The transport of VPLS service is supported by LDP, GRE, and RSVP-TE tunnels, as well as static LSPs and dot1q-, qinq-, or null-encapsulated Ethernet SAPs at uplink.
VPLS scalability can be enabled with the vpls-high-scale command, allowing the 7705 SAR-8 Shelf V2 and 7705 SAR-18 to support up to 255 VPLS instances on access and network links on the following cards:
Refer to the 7705 SAR Basic System Configuration Guide, “System Command Reference”, for more information.
Redundancy for a VPLS instance is provided using the endpoint concept to define primary and secondary spoke SDPs. This type of redundancy functions in a similar manner to PW redundancy. Refer to Pseudowire Redundancy for more information.
In addition, VPLS supports Spanning Tree Protocol (STP) on a per-VPLS instance basis, as well as management VPLS (mVPLS), where several VPLS instances are associated with a single STP instance running over redundant SAPs. The result of this STP is applied to the other VPLS services associated with the mVPLS instance. The VLAN range covering SAPs to be managed by a mVPLS instance is set under a specific mVPLS SAP definition. The 7705 SAR supports RSTP on the designated VLAN for fast detection of failures. See VPLS and Spanning Tree Protocol for more information.
Access Control to and within VPLS is controlled via IP and MAC filter policies for ingress SAPs and SDPs (spoke and mesh), and IP filter policies for egress Ethernet SAPs. Traffic Management (TM) support at ingress and egress for unicast traffic is almost the same as TM support for an Ethernet PW SAP. The TM implementation is extended to support:
Within the context of VPLS services, a loop-free topology within a fully meshed VPLS core is achieved by applying a split-horizon forwarding concept whereby packets received from a mesh SDP are never forwarded to other mesh SDPs within the same service. The advantage of this approach is that no protocol is required to detect loops within the VPLS core network.
The 7705 SAR supports split horizon groups (SHGs) and residential SHGs, making it possible to control how traffic is propagated via configuring and applying forwarding directions to the received traffic. SHGs prevent multicast traffic from flowing within the same group, thereby preventing any loops.
In applications such as DSL aggregation, it is useful to extend the split-horizon concept to groups made up of SAPs and spoke SDPs. This extension is referred to as a split horizon group or residential bridging.
Traffic arriving on a SAP or a spoke SDP within a split horizon group is not copied to other SAPs and spoke SDPs in the same split horizon group; however, it is copied to SAPs and spoke SDPs in other split horizon groups, if these exist within the same VPLS.
Residential SHGs are only supported by ATM encapsulated SAPs. Residential (ATM) SAPs do not forward broadcast or unknown traffic; they only process known unicast traffic. Residential SAPs allow one queue per direction (ingress and egress) for all traffic types (unicast and BMU). In addition, OAM processing is allowed on residential (ATM) SAPs.
OAM support includes support for VPLS mac-ping, mac-trace, and cpe-ping.
Additional 7705 SAR support for VPLS service includes capabilities such as DHCP relay (on Ethernet SAPs). See VPLS Enhancements.
This section describes an example of VPLS processing based on the network shown in Figure 80.
Figure 84 shows a PW-based backhaul option for mobile operators, where 7705 SAR-initiated Ethernet PWs terminate at 7750 SR nodes. In most cases, the 7705 SAR-initiated PWs terminate into a VPRN or IES service for routing purposes, or into a VPLS service for MAC forwarding purposes. PW termination into VPLS prevents unwanted exposure of IP addresses and eliminates concerns about the effect of IP addresses that change, thereby avoiding reconfiguration of the VPRN or IES access interfaces and routing entries.
In addition, capacity changes in a radio network could make mobile operators shuffle their transmission links. A simple Layer 2-based backhaul could avoid this complication because the IP addresses are not required to be configured on SAPs (that is, the interfaces facing the base stations or similar equipment), meaning that the 7705 SAR and the backhaul network would not be impacted by mobile layer IP changes. Alternatively, the 7705 SAR implements VPLS to provide any-to-any connectivity at the Layer 2 level and an IP-agnostic network build-out option.
As is the case with VPRN, VPLS also supports multiple virtual forwarding instances. For example, in Figure 85, the 7705 SAR access SAPs facing NodeB-1 and NodeB-2 are bound to VPLS-3G. Another VPLS instance can be configured on the same 7705 SAR for handling eNB 4G traffic. In such a scenario, MAC addresses learned via these two different VPLS instances are stored in separate FDBs ensuring virtualization, which is similar to multiple IP-VPN instances.
Returning to the VPLS-3G example in Figure 85, upon receiving an Ethernet frame from a SAP, the 7705 SAR learns the MAC address and records it together with information from that SAP. If the destination MAC address is known, then the 7705 SAR switches the received Ethernet frame to its destination. If the destination MAC address is not known, then the 7705 SAR floods the frame to all possible destinations that are part of the same VPLS instance (that is, all the SAPs and the network site links).
On the network side, the 7705 SAR supports spoke SDPs to transport customer MAC frames. At ingress, the 7705 SAR strips off the dot1q or qinq header associated with the SAP and switches the Ethernet frame to its destination over the Ethernet PW. Loops can be avoided by using PW redundancy with standby signaling for spoke SDPs and mesh SDPs to ensure proper propagation of broadcast, multicast, and unknown (BMU) frames. Using standby signaling for spoke SDPs, the 7705 SAR ensures that only one spoke is active in the redundant PW deployment model. As a consequence, the 7750 SR disables the spoke SDP binding to VPLS for the standby PWs in order to ensure loop-free operation.
In the case where the 7705 SAR receives an Ethernet frame from a SAP bound to a VPLS and the destination MAC address is not known, it replicates the frame to all other SAPs that are part of the same VPLS and switches a copy of the frame over all the active Ethernet spoke and mesh SDPs. In Figure 85, the 7705 SAR would switch the incoming frame over an Ethernet PW to 7750 SR-1 after stripping off the incoming dot1q or qinq header.
In terms of label activity, the inner label (the Ethernet PW label for VPLS) identifies the VPLS instance to which the frame belongs, and the outer label identifies the far-end LER node. Using a two-label model means that the traffic from multiple VPLS instances can be transported over a single tunnel between two LER nodes with unique PW labels on a per-VPLS-instance basis.
Upon receiving a VPLS packet, an LER uses the inner label to locate the correct FDB from which to perform MAC lookups. The associated FDB is checked against known and learned MAC addresses. If the lookup is successful, the frame is forwarded to the identified SAP with the appropriate dot1q or qinq header. If the lookup fails, the LER floods the frame to all SAPs that are members of the VPLS instance (that is, the VPLS instance designated by the inner PW label).
Figure 85 can also be used to show how the 7705 SAR can serve as an MTU as described in RFC 4762, section 10.2, to help the scalability of a VPLS core mesh architecture. To function as an MTU, the 7705 SAR is spoke SDP-terminated to a VPLS node (7750 SR node in Figure 85), eliminating the necessity to have a full mesh architecture for all VPLS-enabled nodes. Thus the mesh requirement is “pushed” to the core nodes only (that is, to the 7750 SR nodes).
The 7750 SR nodes in Figure 85 can be replaced by 7705 SAR nodes. Figure 86 illustrates this scenario, where a 7705 SAR MTU is spoke SDP-terminated to two 7705 SAR-18 nodes (7705 SAR-18_1 and 7705 SAR-18_2).
Using spoke-SDP termination means that it is important that the PW-signaling master node is a 7705 SAR (in Figure 86, the node that initiates the redundant PWs is the cell site 7705 SAR). Therefore, only the 7705 SAR-18 that hosts the active spoke SDP will forward the Ethernet traffic to the 7705 SAR and the other 7705 SAR-18 will keep its spoke SDP in the operationally down state. If any failure of the active spoke SDP occurs (that is, if the PW activity switch takes place and the active endpoint of the PW moves from one 7705 SAR-18 to the other one), a mac-flush message is sent, which improves convergence times. In addition, the 7705 SAR-18 nodes can be configured to ignore standby signaling, which improves reconvergence times around failures for services that can tolerate dual-stream reception, such as broadcast TV.
Topics in this section include:
The Nokia VPLS implementation includes several enhancements to basic VPN connectivity. The following VPLS features can be configured individually for each VPLS:
Figure 87 illustrates VPLS enhancements using an example of ATM DSLAM backhaul, where the 7705 SAR might not be used solely for DSLAM backhaul purposes or not all the services might be bound to VPLS. In Figure 87, colocated IP DSLAM (ISAM) traffic can also be transported by the 7705 SAR.
Similar to IES and VPRN services, to configure a VPLS instance, the fabric mode must be set to aggregate mode (not per-destination mode). VPLS service is therefore only supported by aggregate-mode fabric profiles. The CLI blocks the creation of a VPLS instance when the fabric mode is set to per-destination. When a VPLS instance is configured, attempting to change the fabric mode to per-destination is blocked.
The subscriber VLAN feature can be enabled for ATM SAPs bound to a VPLS instance. Subscriber VLAN supports only residential ATM SAPs.
The subscriber VLAN pushes a VLAN tag onto the received bridged PDU on a per-subscriber basis, which helps to uniquely identify subscribers throughout the entire network. After ATM-layer VC termination—where each subscriber has a unique identifier (port:vpi/vci)—all the subscribers would be sharing the same uplink. This might present problems to CO IP nodes (such as a BRAS) that want to offer per-subscriber services and identify the subscribers based on dot1q and VLAN tags, which is compatible with the model offered in a native Ethernet model. In order to maintain the uniqueness of a subscriber, a subscriber VLAN tag can be pushed as per the configuration settings (commonly referred to as customer-tag, or c-tag).
A subscriber VLAN has the following characteristics.
Since the ATM port is considered to be “NULL”, when a frame is received at ATM ingress and is going out on a dot1q Ethernet SAP (SAP-to-SAP) or VLAN vc-type (network), a new VLAN tag is pushed (s-tag). If the subscriber VLAN is also enabled, a c-tag and an s-tag are pushed. In short, Ethernet frames at ATM ingress or egress are manipulated in the same way as a null encapsulated Ethernet port.
For ATM encapsulated residential SAPs:
The VPLS architecture proposed in RFC 4664, Framework for Layer 2 Virtual Private Networks (L2VPNs) and RFC 4665, Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks, specifies the use of provider equipment (PE) that is capable of learning, bridging, and replicating on a per-VPLS basis. The PE routers that participate in the service are connected using MPLS LSP tunnels in a full mesh composed of mesh SDPs or based on an LSP hierarchy composed of mesh SDPs at the core and spoke SDPs as the access points.
Multiple VPLS instances can be offered over the same set of LSP tunnels. Signaling specified in RFC 4905, Encapsulation Methods for Transport of Layer 2 Frames over MPLS Networks, is used to negotiate a set of ingress and egress VC labels on a per-service basis. The VC labels are used by the PE routers for demultiplexing traffic arriving from different VPLS services over the same set of LSP tunnels.
VPLS is provided over MPLS by:
The 7705 SAR edge devices perform the packet replication required for broadcast and multicast traffic across the bridged domain. MAC address learning is performed by the 7705 SAR to reduce the amount of unknown destination MAC address flooding.
7705 SAR routers learn the source MAC addresses of the traffic arriving on their access and network ports. Each 7705 SAR maintains an FDB for each VPLS service instance, and learned MAC addresses are populated in the FDB table of the service. All traffic is switched based on MAC addresses and forwarded between all participating 7705 SAR routers using the LSP tunnels. Unknown destination packets (for example, the destination MAC address has not been learned) are forwarded on all LSPs to the participating 7705 SAR routers for that service until the target station responds and the MAC address is learned by the 7705 SAR associated with that service.
The control-word command enables the use of the control word individually on each mesh SDP or spoke SDP. The control word is optional and is disabled by default. When the control word is enabled, all VPLS packets are encapsulated along with the control word. The T-LDP control word signaling behavior is the same as that for the control word for VLL services. The configuration at the two endpoints of the VPLS service must match.
One of the main applications for VPLS is ATM DSLAM backhaul. DSL operators typically make use of PPPoE over ATM DSL lines for subscriber authentication, authorization, and accounting. When an ATM DSLAM is connected to VPLS service on a 7705 SAR such that the 7705 SAR offers an interworking function for ATM traffic to Ethernet traffic, the 7705 SAR can append the agent-circuit ID to the PPPoE frames received from the ATM DSLAM.
In accordance with RFC 4679, section 3.3.1: Agent-Circuit-ID, agent-circuit ID information can be appended to PPPoE Active Discovery Initiation (PADI) and PPPoE Active Discovery Request (PADR) frames on bridged llc-snap encapsulated SAPs bound to an ATM VPLS instance. Figure 88 illustrates the signaling.
Figure 89 illustrates the agent circuit ID information, where the following definitions apply:
Appending the agent circuit ID to a PADI or PADR frame is enabled and disabled via the pppoe-circuit-id command, which can be issued at the VPLS service and VPLS residential SAP levels. At the service level, the command sets the default value for all SAPs in the VPLS instance. At the SAP level, the command overrides the service level default. If there is a mix of enabled and disabled pppoe-circuit-id settings, reissuing the command at the service level will reset all SAPs to the new service level value.
As per the DSL Forum TR-101 April’06 specification, section 3.9.3, any PPPoE vendor-specific tag that may already be present in the received frame is replaced by the 7705 SAR client-id tag.
MAC filters offer the ability to transport Ethernet frames that match certain criteria over the service to which the frames are bound. The 7705 SAR supports MAC filters at a VPLS ingress SAP and ingress SDP (spoke and mesh). MAC filters can be set to accept or reject the transport of filtered Ethernet frames over the VPLS. Via MAC filters, it is possible to filter traffic received from a defined source or destined for a certain host. MAC filters are the equivalent of IP ACLs, but apply to the Layer 2 MAC layer.
MAC filters support the following fields:
Any single item or combination of items can be used to define a MAC filter entry. For information on configuring MAC filters, see the “Filter Policies” chapter in the 7705 SAR Router Configuration Guide.
The following sections describe VPLS features related to management of the FDB, including:
The following MAC table management features are required for each instance of a SAP or spoke SDP within a particular VPLS instance:
The size of the VPLS FDB can be configured with a low-water mark and a high-water mark, expressed as a percentage of the total FDB size limit. If the actual FDB size grows above the configured high-water mark percentage, an alarm is generated. If the FDB size falls below the configured low-water mark percentage, the alarm is cleared by the system.
Similar to a Layer 2 switch, learned MACs within a VPLS instance can be aged out if no packets are sourced from the MAC address for a specified period of time (the aging time). In each VPLS instance, there are independent aging timers for locally learned MAC and remotely learned MAC entries in the FDB.
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 via an SDP from another 7705 SAR 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 and remote MAC addresses, in some circumstances, can take about two times their respective age timers to be aged out.
The MAC aging timers can be disabled, which will prevent any learned MAC entries from being aged out of the FDB. When aging is disabled, it is still possible to manually delete or flush learned MAC entries. Aging can be disabled for learned MAC addresses on a SAP or a spoke SDP of a VPLS instance.
When MAC learning is disabled for a service, new source MAC addresses are not entered in the VPLS FDB, whether the MAC address is local or remote. MAC learning can be disabled for individual SAPs or spoke SDPs.
Unknown MAC discard is a feature that discards all packets that ingress the service whose destination MAC address is not in the FDB. The normal behavior is to flood these packets to all endpoints 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 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.
For more information on QoS policies for broadcast, multicast, and unknown (BMU) traffic, see the “Filter Policies” chapter in the 7705 SAR Quality of Service Guide.
The MAC move feature is useful to protect against undetected loops in a VPLS topology when STP is not used. It also protects against the presence of duplicate MACs in a VPLS service.
A sustained high relearn 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 your network against loops.
When enabled in a VPLS, MAC-move monitors the relearn rate of each MAC address. If the rate exceeds the configured maximum allowed limit, MAC move disables the SAP where the source MAC address was last seen. The SAP can be disabled permanently (until a shutdown/no shutdown command is executed) or for a length of time that grows linearly with the number of times the given SAP was disabled. A SAP can be optionally configured as non-blockable, meaning that when the relearn rate has exceeded the limit, another (blockable) SAP will be disabled instead. By default, all SAPs and spoke SDPs are configured as blockable when MAC-move is enabled.
When MAC-move is enabled and the relearn rate exceeds the maximum limit, the 7705 SAR sends a “Mac move rate for MAC ... exceeded” alarm. This alarm is raised for both blockable and non-blockable SAPs and spoke SDPs. The alarm frequency for non-blockable SAPs and spoke SDPs decreases if the MAC-move condition persists.
The mac-move command enables the feature at the service level for SAPs and spoke SDPs. The operation of this feature is the same on the SAP and spoke SDP. For example, if a MAC address moves from SAP to SAP, SAP to spoke SDP, or between spoke SDPs, it will block one of them to prevent thrashing. The relearn rate is computed as the number of times a MAC address moves in a 5 s interval. Therefore, the fastest a loop can be detected and broken is 5 s.
MAC move allows sequential order port blocking. By configuration, some VPLS ports can be configured as “non-blockable”, which allows a simple level of control over which ports are being blocked during loop occurrence.
There are two control mechanisms that allow blocking of ports in a sequential order:
For the first mechanism, the configuration CLI is extended by definition of “primary” and “secondary” ports. As the default, all VPLS ports are considered “tertiary” ports unless they are explicitly declared primary or secondary. The order of blocking will always follow a strict order, starting from tertiary, to secondary and then to primary.
The criterion for the second control mechanism is the number of periods during which the given relearn rate has been exceeded. The mechanism is based on the “cumulative” factor for every group of ports. Tertiary VPLS ports are blocked if the relearn rate exceeds the configured threshold during one period, while secondary ports are blocked only when relearn rates are exceeded during two consecutive periods, and so forth. The retry timeout period must be larger than the period before blocking the highest-priority port so it sufficiently spans across the period required to block all ports in sequence. The period before blocking the highest-priority port is the cumulative factor of the highest configured port multiplied by 5 s (the retry timeout can be configured through the CLI).
Within the context of VPLS services, a loop-free topology within a fully meshed VPLS core is achieved by applying a split horizon forwarding concept whereby packets received from a mesh SDP are never forwarded to other mesh SDPs within the same service. The advantage of this approach is that no protocol is required to detect loops within the VPLS core network.
In applications such as DSL aggregation, it is useful to extend the split horizon concept to groups of SAPs and/or spoke SDPs. This extension is referred to as a split horizon SAP group or residential bridging.
Traffic arriving on a SAP or a spoke SDP within a split horizon group will not be copied to other SAPs and spoke SDPs in the same split horizon group (but will be copied to SAPs or spoke SDPs in other split horizon groups if these exist within the same VPLS).
A split horizon group must be created before SAPs and spoke SDPs can be assigned to the group.
The split horizon group is defined within the context of a single VPLS. The same group name can be reused in different VPLS instances. Up to 30 split horizon groups can be defined per VPLS instance. A split horizon group can contain a combination of spoke SDPs and SAPs.
A SAP or spoke SDP can only be added to a split horizon group during its creation. Similarly, a SAP or spoke SDP can be removed from a split horizon group only by its deletion. A split horizon group can be deleted only after all its members have been deleted.
Residential split horizon groups are supported on ATM SAPs connected to VPLS on 4-port OC3/STM1 Clear Channel Adapter cards. While split horizon groups prevent multicast traffic from flowing within the same group, residential ATM SAPs do not forward broadcast or unknown traffic; they only process known unicast traffic. Residential split horizon groups allow one queue per direction (ingress and egress) for all traffic types (unicast and BMU). OAM processing is also allowed on residential ATM SAPs.
IGMP and MLD snooping allows a 7705 SAR to listen to the IGMP traffic between hosts and routers. The 7705 SAR extracts information from the traffic to create and maintain a multicast forwarding information base (MFIB) to track which hosts want which IP multicast streams. Multicasts may be filtered to control which ports receive specific multicast traffic.
For example, service providers that use a flat IP network to deliver video over a mobile backhaul network can take advantage of Layer 2 services (VPLS) to save IPv4 addresses. A Layer 2 domain with n nodes needs n IP addresses, whereas a point-to-point connections requires 2×n addresses. Service providers using VPLS and IGMP or MLD snooping to relay IGMP or MLD requests to uplink (network) PIM interfaces will save addresses.
This section contains information on the following topics:
For more information on multicast, refer to the “IP Multicast” section in the 7705 SAR Routing Protocols Guide.
Figure 90 shows a typical deployment. Host traffic arrives at the routed VPLS (r-VPLS), where IGMP or MLD snooping extracts all IGMP or MLD packets and sends them to the CSM, and from the CSM the packets are forwarded via PIM to the head-end 7750 SR nodes. The VPLS multicast FIB (MFIB) tracks all the IGMP or MLD join requests in an internal 7705 SAR forwarding table. On the upstream nodes, PIM builds the multicast tree from the 7705 SAR to the 7750 SR. In the reverse direction, the video source sends multicast traffic, which is forwarded by the PIM nodes to the addresses in the previously built multicast tree. As traffic from various sources arrives at the 7705 SAR, the r-VPLS MFIB directs each multicast stream to the correct eNodeB.
Figure 91 shows another example of IGMP and MLD snooping, where service providers can offer evolved multimedia broadcast multicast services (eMBMS) on their metro cell network (data services).
In Figure 91, the data VPLS performs IGMP or MLD snooping to build the MFIB. The extracted IGMP and MLD requests are forwarded via PIM over an Epipe or, preferably, via PIM over a Layer 3 spoke SDP to remove the external physical connection between two ports from the 7705 SAR. The traffic between IES access and NAT is unicast traffic. The Layer 3 spoke-SDP traffic is transported over a GRE tunnel via the Internet to the evolved packet core (EPC), where a secure gateway forwards the PIM join message to the multicast source servers. The GRE logical Layer 3 spoke SDP does not need to be part of the NAT function; if it is not, this logical interface must obtain its own public interface IP address.
Figure 91 also shows the typical metro cell deployment, where IGMP snooping is done on the r-VPLS of the data IES service. The IGMP join messages translate to PIM SSM via the uplink network interface, as described at the beginning of this section.
MLD snooping allows support for IPv6 addresses through the use of r-VPLS for IPv6, allowing the network design for IPv4 and IPv6 domains to be the same.
This section contains information on the following topics:
The 7705 SAR supports (S,G) and (*,G) for IPv4 multicast in Layer 2 services only, including Layer 2 services within the context of VPLS and r-VPLS.
7705 SAR supports PIM-SSM only. For IPv4 multicast services, PIM SSM requires SSM translation in the r-VPLS interface context for (*,G) joins.
The 7705 SAR supports (S,G) and (*,G) for IPv6 multicast in Layer 2 services only, including Layer 2 services within the context of VPLS and r-VPLS, and uses the MAC-format group-addressing scheme to minimize the size of the MFIB.
The multicast MAC-format group address consists of the IPv6 multicast prefix (33:33) and the four least significant bytes of the IPv6 address. In the CLI display below, for the IPv6 address FF04::1:FFFF:0011, the representation of the group address is 33:33:FF:FF:00:11.
7705 SAR supports PIM-SSM only. For IPv6 multicast services, PIM SSM requires SSM translation in the r-VPLS interface context for (*,G) joins.
When creating a Layer 2 multicast service in the context of an r-VPLS with PIM configuration on the r-VPLS Layer 3 interface, the 7705 SAR creates two multicast groups: one Layer 2 multicast group and one Layer 3 multicast group. Once the Layer 2 group is created, the Layer 3 group is created automatically. The 7705 SAR uses one Layer 3 multicast group per source, and one Layer 2 multicast group per source per VPLS.
Note: IP multicast on r-VPLS is supported only if IGMP or MLD snooping is enabled on the VPLS associated with the IES. That is, configuring IGMP or MLD on the IES that is associated with the VPLS without configuring snooping on the VPLS will not flood multicast traffic out the VPLS. |
Figure 92 and Figure 93 illustrate how Layer 2 multicast interacts with Layer 3 multicast.
In Figure 92, there are three hosts and one channel. The Layer 3 multicast group forwards source traffic to each port for which there is a corresponding Layer 2 multicast instance of a Layer 2 FIB entry. All three Layer 2 FIB entries are within the same r-VPLS. To configure this scenario, create three Layer 2 FIB entries on the 7705 SAR (one for each host), and one Layer 3 group for the source. The single Layer 3 multicast group streams the multicast traffic to all three hosts.
In Figure 93, there are three hosts and three channels. Each host connects to a different port and wants to receive a different (S,G) group (that is, a different channel). Therefore, three Layer 3 (S,G) groups are needed. To achieve this scenario, create three Layer 2 multicast groups (one for each host) and three Layer 3 multicast groups (one for each channel).
Note: For r-VPLS, the 7705 SAR supports multicast data flows only from a Layer 3 to a Layer 2 domain. For example, in Figure 93, multicast data can only flow from the server source in the Layer 3 domain to the hosts in the Layer 2 domain. Currently, the 7705 SAR does not support multicast data flow from a Layer 2 to a Layer 3 domain. |
In general, the behavior of IPv6 multicast in r-VPLS is as follows.
The IPv6 multicast control plane behavior is as follows.
The IPv6 multicast data plane behavior is as follows.
Membership reports are only sent to multicast router (mrouter) ports. An mrouter port is a port through which membership queries are received. An mrouter port can be configured manually on a VPLS SAP or SDP using the mrouter-port command under igmp-snooping or mld-snooping.
The 7705 SAR processes tagged querier requests arriving on a null-encapsulated port and installs the querier message. This means that an IGMP or MLD router is recognized to exist on that port and reports (joins and leaves) will be forwarded out that port.
Similarly, for multicast data, the 7705 SAR processes tagged multicast traffic arriving on a null-encapsulated port according to the MFIB.
Multicast VPLS and r-VPLS are supported on the following 7705 SAR hardware:
PIM snooping is used in Layer 2 networks to stitch together the PIM session of two disjointed Layer 3 networks. In most provider networks, strategic industry (SI) applications, or mobile backhaul applications, the access routers are connected to the core Layer 3 network via a Layer 2 network. For multicast scenarios, PIM can be used to build the multicast data trees (MDTs) on the Layer 3 routers. However, PIM is a Layer 3 protocol and Layer 2 networks do not understand PIM messages. This creates an inefficient multicast domain in the Layer 2 network, as all packets will be broadcast. PIM snooping in a Layer 2 network can be used to stitch the PIM session from the access routers to the core Layer 3 network. Figure 94 illustrates this scenario.
Because PIM snooping stitches the PIM session between two routers, it might be desirable to start the PIM session from the same router (a 7705 SAR) that initiates the VPLS PIM snooping service. In this case, an external loop cable can be used to connect the network Layer 3 interface, which has PIM configured, to the SAP of the VPLS that is performing the PIM snooping, as shown in Figure 95, thereby simulating routed VPLS.
PIM snooping supports both (*,G) as well as (S,G) to address scenarios where the sources only support PIM ASM.
The 7705 SAR supports PIM snooping for IPv4 and IPv6.
Snooping mode does not stop or intercept a PIM message. Snooping listens to network traffic between hosts and routers, and maintains a table that maps multicast streams between sources and hosts.
Proxy mode intercepts PIM messages and generates a single message when necessary. Proxy allows a switch to send PIM messages on behalf of routers. For example, when multiple routers are connected to the same PIM-enabled switch and all the routers want to join to the same source, the proxy can intercept the messages and generate a single message in order to minimize the flood of PIM messages in the Layer 2 domain.
Configure snooping or proxy mode by using the config>service>vpls> pim-snooping>mode command. By default, proxy mode is enabled in VPLS.
The router supports the MPLS entropy label as per RFC 6790. The entropy label provides greater granularity for load balancing on an LSR where load balancing is typically based on the MPLS label stack.
For more information, refer to the “MPLS Entropy Labels” section in the 7705 SAR MPLS Guide and to the “LAG and ECMP Hashing” section in the 7705 SAR Interface Configuration Guide.
The 7705 SAR supports Ethernet OAM functions for ETH-CFM (according to the 802.1ag and Y.1731 standards) and for Y.1731 Performance Monitoring on VPLS Ethernet SAPs and SDPs. VPLS OAM MAC diagnostics are also supported.
For information on Ethernet OAM, see ETH-CFM (802.1ag and Y.1731) and refer to the “Ethernet OAM Capabilities” and “VPLS MAC Diagnostics” sections in the 7705 SAR OAM and Diagnostics Guide.
The 7705 SAR supports a number of mechanisms for node security, including Access Control Lists (ACLs), Network Address Translation (NAT), and stateful, zone-based firewalls. For information about ACLs, NAT, and firewalls, refer to the 7705 SAR Router Configuration Guide, “Configuring Security Parameters”.
NAT and firewall security configurations are both based on zones. Zones segment a network, making it easier to control and organize traffic. A zone consists of a group of Layer 2 endpoints or Layer 3 interfaces with common criteria, bundled together. Security policies, which define a set of rules that determine how NAT or firewall should direct traffic, can be applied to the entire zone or to multiple zones. Layer 3 zones support both NAT and firewall security policies. Layer 2 zones support only firewalls. To enable NAT or firewall functionality, security policy and profile parameters must be configured under the config>security context in the CLI, and a security zone must be configured under one or more of the following contexts:
Layer 2 and Layer 3 firewalls share system resources; that is, they share the maximum number of policies, profiles, and session ID space supported by the system.
A zone is created by adding at least one Layer 2 endpoint or Layer 3 interface to the zone configuration. Multiple zones can be created within each Layer 3 service or within the router context. Layer 2 services support only one zone. Layer 2 endpoints or Layer 3 interfaces from different services cannot be grouped into a single common zone. Table 62 lists the supported interfaces and endpoints that can be added to zones in each CLI context for NAT or firewall.
CLI Context | Interface/Endpoint Type | NAT | Firewall |
Router | Layer 3 | ✓ | ✓ |
Epipe | SAP | ✓ | |
Spoke-SDP termination | ✓ | ||
VPLS | SAP | ✓ | |
Spoke-SDP termination | ✓ | ||
Mesh SDP | ✓ | ||
EVPN | |||
VPRN | SAP | ✓ | ✓ |
Spoke-SDP termination | ✓ | ✓ | |
IPSec private | ✓ | ✓ | |
IPSec public | ✓ | ||
Routed VPLS | ✓ | ✓ | |
IES | SAP | ✓ | ✓ |
Spoke-SDP termination | ✓ | ✓ | |
IPSec public | ✓ | ||
Routed VPLS | ✓ | ✓ |
Note: A group of endpoints used for pseudowire redundancy cannot be added to a zone configured under an Epipe. |
A zone configured under a Layer 2 service (VPLS or Epipe context) allows the 7705 SAR to perform Layer 3 firewall functionality on IPv4 packets.
NAT is not supported for zones configured under a Layer 2 service. A zone cannot be configured on a VPLS service with EVPN.
Unicast, multicast, and broadcast IPv4 packets are firewalled when they cross a Layer 2 service zone boundary.
If routed VPLS is configured on a VPLS service, and traffic is traversing between two Layer 2 endpoints, the firewall security policies for the Layer 2 service are used. If the traffic is traversing between Layer 2 and Layer 3, the Layer 3 security policy in IES or VPRN is used. The system ignores the firewall rules for the Layer 2 service and instead uses the Layer 3 NAT and firewall rules. Firewall rules for Layer 2 services are always ignored when traffic is traversing between Layer 2 and Layer 3, even when there are no Layer 3 firewall rules.
Users can configure bypass policies to allow certain traffic, such as control plane protocols (OSPF, RIP, BGP, IGMP, PIM, LDP, RSVP, VRRP, DHCP, NTP, and so on) to bypass a firewall in a Layer 2 service. Refer to the 7705 SAR Router Configuration Guide, “Bypass Policies for Firewalls in a Layer 2 Service”, for details. If not configured to bypass the zone, these packets are firewalled as normal unicast, multicast, or broadcast traffic and should be regulated by configuring firewall security policies for these protocols.
Topics in this section include:
Hosts within the same subnet communicate directly with each other without the need for a router, but any communication with a host that is external to the subnet requires routing. With routed VPLS, you can use bridging for local destinations when possible and routing for non-local destinations that cannot be reached directly.
Routed VPLS appears similar to a LAN Ethernet switch and a router. The VPLS instance on the 7705 SAR node grants Ethernet switch functionality among connected nodes. When the destination IP is not local, the 7705 SAR routes the traffic by means of the VPRN or the IES instance.
Routed VPLS is enabled for IPv4 and IPv6 forwarding.
A standard IP interface within an existing IES or VPRN service context can be bound to a VPLS service. A VPLS service only supports binding for a single IP interface.
Although an IP interface can only be bound to a single VPLS service, the routing context containing the IP interface (IES or VPRN) can have other IP interfaces bound to other VPLS service contexts.
Topics in this section include:
If a service name is applied to a VPLS service context, the name and service ID association is registered with the system. A service name cannot be assigned to more than one service ID.
If the config>service>vpls>allow-ip-int-binding command is enabled on the VPLS service, when the service name is applied to the VPLS service, the system will scan the existing IES and VPRN services for an IP interface that is bound to the specified service name. If found, the IP interface will be attached to the VPLS service associated with the service name. Only one interface can be bound to the specified service name.
If the allow-ip-int-binding command is not enabled on the VPLS service, the system will not attempt to resolve the VPLS service name to an IP interface. As soon as the allow-ip-int-binding flag is enabled on the VPLS, the corresponding IP interface will be attached and become operationally up. There is no need to toggle the shutdown/no shutdown command.
An IP interface within an IES or VPRN service context can be bound to a service name at any time. Only one interface can be bound to a service name.
If an IP interface is bound to a service name and the IP interface is administratively up, the system will scan for a VPLS service context using the service name and take the following actions:
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.
If an IP interface has been bound to a VPLS service by the VPLS service name, the VPLS service name cannot be removed or changed unless the IP interface is first unbound from the VPLS service name.
If an IP interface is attached to a VPLS service, the allow-ip-int-binding flag cannot be reset. The IP interface must first be unbound from the VPLS service name to reset the flag.
If the IP interface is successfully attached to a VPLS service, the operational state of the IP interface is dependent upon the operational state of the VPLS service.
The VPLS service remains down until at least one virtual port (SAP, spoke SDP or mesh SDP) is operational.
The 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 of a port. The VPLS itself has a service-level MTU that defines the largest packet supported by the service. This MTU does not include the local encapsulation overhead for each port (dot1q, qinq, or SDP service delineation fields and headers) but does include the remainder of the packet. As virtual ports are created in the system, any given virtual port cannot become operational unless the configured port MTU minus the virtual port service delineation overhead is greater than or equal to the configured VPLS service MTU. This ensures that an operational virtual port can 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.
If 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 the VPLS service MTU. The operational IP MTU cannot be greater than the VPLS service MTU minus 14, 18, or 22 bytes (for null, dotq1, or qinq port encapsulations, respectively) to account for the Layer 2 headers and tags.
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 VPLS service MTU and the IP interface MTU parameters can be changed at any time.
Note: References to ARP in this section also apply to Neighbor Discovery (ND) protocol. ARP applies to IPv4. ND protocol applies to IPv6. |
Two address-oriented table entries are used when routing into a VPLS service. On the routing side, an ARP entry is used to determine the destination MAC address used by an IP next hop. If the destination IP address in the routed packet is a host on the local subnet represented by the VPLS instance, the destination IP address is used as the next-hop IP address in the ARP cache lookup. If the destination IP address is in a remote subnet that is reached by another router attached to the VPLS service, the routing lookup returns the local IP address on the VPLS service of the remote router. If the next hop is not currently in the ARP cache, the system generates an ARP request to determine the destination MAC address associated with the next-hop IP address. IP routing to all destination hosts associated with the next-hop IP address stops until the ARP cache is populated with an entry for the next hop. The ARP cache can be populated with a static ARP entry for the next-hop IP address. Dynamically populated ARP entries will age out according to the ARP aging timer; static ARP entries never age out.
The second address table entry that affects VPLS routed packets is the MAC destination lookup in the VPLS service context. The MAC address associated with the ARP table entry for the IP next hop may or may not currently be populated in the VPLS Layer 2 FIB table. If the destination MAC address is unknown (not populated in the VPLS FIB), the system floods all packets destined for that MAC address (routed or bridged) to all virtual ports within the VPLS service context. Once the MAC address is known (populated in the VPLS FIB), all packets destined for the MAC address (routed or bridged) are targeted to the specific virtual port where the MAC address has been learned. As with ARP entries, static MAC address entries can be created in the VPLS FIB. Dynamically learned MAC addresses are allowed to age out or be flushed from the VPLS FIB while static MAC address entries always remain associated with a specific virtual port. Dynamic MAC addresses can also be relearned on another VPLS virtual port other than the current virtual port in the FIB. In this case, the system automatically moves the MAC FIB entry to the new VPLS virtual port.
Note: References to ARP in this section also apply to Neighbor Discovery (ND) protocol. ARP applies to IPv4. ND protocol applies to IPv6. |
In typical routing behavior, the system uses the IP routing table to select the egress interface, and at the egress forwarding engine, an ARP entry is used to forward the packet to the appropriate Ethernet MAC address. With routed VPLS, the egress IP interface can be represented by multiple egress forwarding engines (wherever the VPLS service virtual ports exist). To optimize routing performance, the ingress forwarding engine performs an ingress ARP lookup in order to resolve which VPLS MAC address the IP frame must be routed towards.Table 63 describes how the ARP cache and MAC FIB entry states interact at ingress and Table 64 describes the corresponding egress behavior.
Layer 3 Next-Hop ARP Cache Entry | Next-Hop MAC FIB Entry | Ingress Behavior |
ARP Cache Miss (No Entry) | Known or Unknown | Flood to all egress forwarding engines associated with the VPLS context |
ARP Cache Hit | Known | Forward to specific egress forwarding engine associated with VPLS virtual port |
Unknown | Flood to all egress forwarding engines associated with the VPLS for forwarding out to all VPLS virtual ports |
Layer 3 Next-Hop ARP Cache Entry | Next-Hop MAC FIB Entry | Egress Behavior |
ARP Cache Miss (No Entry) | Known | No ARP entry. The MAC address is unknown and the ARP request is flooded out to all virtual ports of the VPLS instance. |
Unknown | ARP processing request transmitted out to all virtual ports associated with the VPLS service. Only the first egress forwarding engine ARP processing request triggers the egress ARP request. | |
ARP Cache Hit | Known | Forward out to specific egress VPLS virtual port where MAC address has been learned |
Unknown | Flood to all egress VPLS virtual ports on forwarding engine |
The allow-ip-int-binding flag on a VPLS service context informs 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 and forwarding planes the VPLS service can 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 if routing support is enabled.
Once the allow-ip-int-binding flag is set (routing support enabled) on a VPLS service, SAPs within the service can be created on standard Ethernet ports. ATM SAPs are not supported.
If the allow-ip-int-binding flag is set on a VPLS service, the following features are disabled:
Note: The DHCP relay functionality under config>service>ies>if>dhcp or config>service>ies>if>ipv6>dhcp6-relay can be used to dynamically assign IP addresses to the clients connected to routed VPLS SAPs. |
Note: The 7705 SAR does not support ingress DSCP marking. |
Egress DSCP re-marking is supported on routed VPLS service for bridged packets only. It is not supported for packets routed out from a VPLS SAP.
The egress re-marking defined in the SAP egress QoS policy is not performed for packets that are routed out an egress VPLS SAP.
If an IP interface is attached to a VPLS service context, the VPLS SAP or SDP configured IP or MAC filter for ingress routed packets can be optionally overridden in order to provide special ingress filtering for routed packets. This allows different filtering for routed packets and non-routed packets. The filter override is defined on the IP interface bound to the VPLS service name. A separate override filter can be specified for IPv4 and IPv6 packet types.
If filter override is configured, the IP or MAC filter configured on the SAP or SDP applies to non-routed packets. If filter override is not configured, the IP or MAC filter configured on the SAP or SDP applies to both routed and non-routed packets.
The following protocols are supported on IP interfaces bound to a VPLS service:
Topics in this section include:
The Nokia VPLS service provides a bridged or switched Ethernet Layer 2 network. Equipment connected to SAPs or spoke SDPs forward Ethernet packets into the VPLS service. The 7705 SAR participating in the service learns where the customer MAC addresses reside on ingress SAPs or ingress SDPs.
Unknown destinations, broadcasts, and multicasts are flooded to all other SAPs or spoke SDPs in the service. If SAPs or spoke SDPs are connected together, either through misconfiguration or for redundancy purposes, loops can form and flooded packets can keep flowing through the network. The Nokia implementation of STP is designed to remove these loops from the VPLS topology. This is done by putting one or more SAPs or spoke SDPs in the discarding state.
STP parameters allow a balance between resiliency and speed of convergence extremes. Modifying particular parameters can affect the behavior. For information on command usage, descriptions, and CLI syntax, see Configuring a VPLS Service with CLI.
Each VPLS instance on the 7705 SAR operates in Rapid Spanning Tree Protocol (RSTP) mode and is compliant with IEEE 802.1D-2004 - default mode.
The VPLS standard (RFC 4762, Virtual Private LAN Services Using LDP Signalling) includes provisions for hierarchical VPLS using point-to-point spoke SDPs. Two applications have been identified for spoke SDPs:
In both applications, the spoke SDPs improve the scalability of VPLS. Since node redundancy is implicit in non-hierarchical VPLS services (using a full mesh of SDPs between PEs), node redundancy for spoke SDPs needs to be provided separately.
Nokia routers have implemented special features for improving the resilience of hierarchical VPLS instances, in both MTU and inter-metro applications.
When two or more meshed VPLS instances, such as in Figure 96, are interconnected by redundant spoke SDPs, a loop in the topology results. In order to remove a topology loop, STP can be run over the SDPs (links) that form the loop, which then blocks one of the SDPs.
To avoid the inefficiency of running STP separately in every VPLS in the topology, the node can associate a number of VPLS services with a single STP instance running over redundant SDPs. Node redundancy is achieved by running STP in one VPLS, and then 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.
If the active node fails, STP on the mVPLS on the standby node changes the link state from disabled to active. The standby node broadcasts 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 mVPLS services, where both mVPLS services have different active spokes (this is achieved by changing the path cost in STP). Load balancing across the spokes is achieved by associating different user VPLS services with the two mVPLS services.
This feature provides the ability to have a node deployed as MTU switches to be multi-homed for VPLS to multiple routers deployed as PEs without requiring the use of mVPLS.
In the configuration example displayed in Figure 96, the MTUs have spoke SDPs to two PE 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.
The secondary spoke is in a blocking state (both on receive and transmit) as long as the primary spoke is available. If the primary spoke becomes unavailable (due to link failure, PEs failure, and so on), the MTU immediately switches traffic to the backup spoke and starts receiving traffic from the standby spoke. Optional revertive operation (with configurable switch-back delay) is supported. Forced manual switchover is also supported.
To speed up the convergence time during a switchover, MAC flush is configured. The MTUs generate 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 instance and forward the MAC flush to the other PEs in the VPLS network if propagate-mac-flush is enabled.
Another application of hierarchical VPLS uses MTUs that are not MPLS-enabled and must have Ethernet links to the closest PE node. To protect against failure of the PE node, an MTU can be dual-homed and have two SAPs on two PE nodes.
On the 7705 SAR, the mechanism used to resolve a loop in an access circuit uses STP-based access, with or without mVPLS.
In the configuration shown in Figure 97, STP is activated on the MTU and two PEs in order to resolve a potential loop. STP needs to run only in a single VPLS instance, and the results of the STP calculations are applied to every VPLS on the link. In this configuration, the scope of the STP domain is limited to the MTU and PEs but any topology change must be propagated across the whole VPLS domain, including mesh SDPs. This is done with MAC flush messages defined by RFC 4762.
When STP is used as a loop resolution mechanism, every Topology Change Notification (TCN) received in an STP instance is translated into a MAC flush message request to clear all FDB entries except the ones learned from the originating PE. MAC flush messages are sent to all PE peers connected through mesh and spoke SDPs in the context of the VPLS services managed by the given STP instance.
The previous sections describe the operating principle of redundancy mechanisms available in the context of a VPLS service. All of them rely on MAC flush messages as a tool to propagate topology change in the context of the given VPLS. This section summarizes basic rules for generation and processing of these messages.
The 7705 SAR 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 the 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-mine requests the clearing of all FDB entries learned from the originating PE. This means that this message has the opposite effect of the flush-all-but-mine message. This type is not included in the RFC 4762 definition and is implemented using vendor-specific TLV.
Upon reception of MAC flush messages (regardless of the type), the 7705 SAR PE takes the following actions:
The flush-all-but-mine message is generated under the following conditions.
The flush-mine message is generated under the following conditions:
Figure 98 illustrates a dual-homed connection to a VPLS service (PE-A, PE-B, PE-C, PE-D) and the operation in case of link failure (between PE-C and L2-B). Upon detection of a link failure, PE-C sends MAC Address Withdraw messages, which indicate to all LDP peers that they should flush all MAC addresses learned from PE-C. This triggers packets to be broadcast addressing the affected hosts and a relearning process in case an alternative route exists.
The MAC Address Withdraw message is different from the message described in draft-ietf-l2vpn-vpls-ldp-xx.txt, Virtual Private LAN Services over MPLS. The difference is in the interpretation and action performed at the receiving PE. According to the draft definition, upon receipt of a MAC withdraw message, all MAC addresses, except the ones learned from the source PE, are flushed. In the 7705 SAR implementation, upon receipt of the MAC Address Withdraw message, all MAC addresses learned from the source are flushed. In this implementation, this message is an LDP address message with vendor-specific TLV, and is called the flush-all-from-ME message.
The message as defined in the draft definition is currently used in any mVPLS that is using RSTP to recover from failures in Layer 2 topologies. The advantage of the alternative messaging behavior over RSTP-based methods is that only MAC-affected addresses are flushed, and not the full forwarding database. This method does not provide a mechanism to secure alternative loop-free topology. However, the convergence time depends on how quickly the given CE device opens the alternative link (L2-B switch in Figure 98) as well as how quickly the PE routers flush their FDBs. Additionally, since this method relies on reacting to the physical failure of the link, it is effective only if the PE and CE are directly connected with no hub or bridge.
The application shown in Figure 99 provides access to a VPLS service for ATM users connected either directly or through an ATM access network to a 7705 SAR PE node. The 7705 SAR supports an ATM VC-delimited SAP terminating on a VPLS service.
RFC 2427-encapsulated or RFC 2684-encapsulated untagged Ethernet/802.3 frames (with or without Frame Check Sequence (FCS)) or BPDUs from a customer’s bridge device are received on a given SAP over an ATM interface on the 7705 SAR. The ATM-related encapsulation is stripped, and the frames (without FCS) are forwarded towards destination SAPs either locally or using SDPs associated with the VPLS service (as dictated by destination MAC address VPLS processing). In the egress direction, the received untagged frames are encapsulated into RFC 2427 or RFC 2684 (no Q-tags are added, no FCS in the forwarded frame) and sent over the ATM VC towards the customer CPE.
When AAL5 RFC 2427/2684 encapsulated tagged frames are received from the customer’s bridge on an ATM SAP, the tags are transparent and the frames are processed as described above, with the exception that the frames forwarded towards the destinations will have the received tags preserved. Similarly, in the egress direction, the received tagged Ethernet frames are encapsulated as is (Q-tags are again transparent and preserved) into RFC 2427/2684 and sent over the ATM PVC towards the customer CPE.
Since the tagging is transparent, the 7705 SAR performs unqualified MAC learning (for example, MAC addresses are learned without reference to the VLANs they are associated with). Hence, MAC addresses used must be unique across all the VLANs used by the customer for a given VPLS service instance. If a customer wants a per-VLAN separation, then the VLAN traffic that needs to be separated must travel on different VCs (different SAPs) associated with different VPLS service instances.
All VPLS functionality available on the 7705 SAR is applicable to ATM-delimited VPLS SAPs. For example, bridged PDUs received over an ATM SAP can be tunneled through or dropped, all Forwarding Database (FDB) functionality applies, packet-level QoS and MAC filtering applies. Also, split horizon groups are applicable to ATM SAPs terminating on VPLS. In other words, frame forwarding between ATM SAPs, also referred to as VCI-to-VCI forwarding, is disabled within the same group.
The Ethernet pseudowire is established using Targeted LDP (T-LDP) signaling and uses the ether, vlan, or vpls VC type on the SDP. The SDP can be an MPLS or a GRE type.
This section describes general 7705 SAR service features and any special capabilities or considerations as they relate to VPLS services:
VPLS services are designed to carry Ethernet frame payloads; therefore, VPLS can provide connectivity between any SAPs and SDPs that pass Ethernet frames. The following SAP encapsulations are supported on the 7705 SAR VPLS service:
The SAP encapsulation definition on Ethernet ingress ports defines which VLAN tags are used to determine the service that the packet belongs to:
Note: The SAP can be defined with a wildcard (*) for the inner label (for example, “SAP 100:100.*”). In this example, 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 by the QinQ encapsulation of SAP 100:100.1, then traffic with 100:1 will go to that SAP while all other traffic with 100 as the first label will go to the SAP with the SAP 100:100.* definition. |
For dot1q and qinq encapsulations, traffic encapsulated with tags for which there is no definition are discarded.
VLAN tagging rules for VPLS SAPs are the same as those for Epipe SAPs except that VPLS includes the force-c-vlan-forwarding command.
The force-c-vlan-forwarding command provides users with the ability to preserve a customer VLAN tag and append a configured egress SAP VLAN ID on top of the customer tag. See the force-c-vlan-forwarding command for details.
For information on tagging rules, see Tagging Rules for Epipe.
VPLS supports QinQ functionality. For details, see QinQ Support.
The following guidelines and caveats apply to the implementation of VPLS: