Vpls Overview PDF

VPLS
In This Chapter
This chapter provides an overview of Virtual Private LAN Service (VPLS) on the 7705 SAR.
Topics in this chapter include:
• VPLS Overview
• VPLS Features
• Routed VPLS
• VPLS and Spanning Tree Protocol
• ATM PVC Access and Termination on a VPLS Service
• VPLS Service Considerations
• Configuration Notes
• Configuring a VPLS Service with CLI
• VPLS Command Reference
7705 SAR OS Services Guide 475

VPLS Overview
VPLS Overview
Topics in this section include:
• VPLS Packet Walkthrough

• Bridged Mobile Backhaul
• Multi-Tenant Unit (MTU) Termination
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 a transparent, protocol-independent bridged service

• no Layer 2 protocol conversion between LAN and WAN technologies
• no need to design, manage, configure, and maintain separate WAN access
equipment, thereby eliminating the need to train personnel on WAN technologies
such as ATM, IP over ATM, IP over PPP, and so on
476 7705 SAR OS Services Guide

VPLS
VPLS is supported on the cards and platforms listed below. A VPLS SAP can reside on the
following ports:
• any Ethernet port (null or tagged) in access mode

→ on an 8-port Ethernet Adapter card with CLI identifier a8-eth or a8-ethv2
installed on a 7705 SAR-8 or 7705 SAR-18
→ on a 6-port Ethernet 10Gbps Adapter card with CLI identifier a6-eth-10G
installed on a 7705 SAR-8 Shelf V2 with CSMv2 or a 7705 SAR-18
→ on an 8-port Gigabit Ethernet Adapter card with CLI identifier a8-1gb-sfp,
a8-1gb-v2-sfp, or a8-1gb-v3-sfp installed on a 7705 SAR-8 or
7705 SAR-18
→ on a 10-port 1GigE/1-port 10GigE X-Adapter card in 10-port 1GigE mode with
CLI identifier for mda-mode x10-1gb-sfp installed on a 7705 SAR-18
→ on a 7705 SAR-F with CLI identifier i8-eth
→ on a 7705 SAR-M (all variants) with CLI identifier i7-1gb
→ on a GPON module and on DSL modules when the module is installed in the
7705 SAR-M (variants with module slots)
→ on a 4-port SAR-H Fast Ethernet module when the module is installed in the
7705 SAR-H
→ on a 6-port SAR-M Ethernet module when the module is installed in the
7705 SAR-M (variants with module slots)
→ on a 7705 SAR-A (both variants)
→ on a 7705 SAR-W
→ on a 7705 SAR-Wx (all variants)
→ on a 7705 SAR-H with CLI identifier i8-1gb
→ on a 7705 SAR-Hc with CLI identifier i6-1gb
→ on a 7705 SAR-X with CLI identifier i7-mix-eth
• any port using ATM encapsulation on a 4-port OC3/STM1 Clear Channel Adapter
card installed on a 7705 SAR-8 or 7705 SAR-18
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 Redundancy
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.

VPLS Overview
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. See VPLS and Spanning Tree
Protocol for more information.
Access Control and Traffic Management
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:
• at SAP ingress, queue selection for unicast and for broadcast, multicast, and
unknown (BMU) traffic
• at network ingress, separate unicast and BMU queues
• at access ingress, ATM traffic (unicast and BMU) mapped to a single queue
Split Horizon
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.

VPLS
Additional 7705 SAR support for VPLS service includes capabilities such as DHCP relay (on
Ethernet SAPs). See VPLS Enhancements.
VPLS Packet Walkthrough

This section describes an example of VPLS processing based on the network shown in
Figure 70.
Figure 70: VPLS Service Architecture
IP/MPLS
network
PE D
Site D
B
PE A VPLS service 1 PE C
B B
B B
VPLS service 2
Site A Site C
B B
PE B
Legend:
B Virtual bridge
LSP Full mesh Site B
21559
1. PE Router A (Figure 71):

a. Service packets arriving at PE A are associated with a VPLS service instance
(VPLS service 2) based on the combination of the physical port and the
IEEE 802.1Q tag (VLAN-ID) in the packet, if applicable.
b. PE A learns the source MAC address in the packet and creates an entry in the
Forwarding Database (FDB) table that associates the MAC address with the SAP
on which it was received.

VPLS Overview
c. The destination MAC address in the packet is looked up in the FDB table for the
VPLS instance. There are two possibilities: either the destination MAC address
has already been learned (known MAC address) or the destination MAC address
is not yet learned (unknown MAC address).
Figure 71: Access Port Ingress Packet Format and Lookup
Ingress look-up
based on access
port or port/VLAN-ID
IP/MPLS
network
PE A
Site A
Dest Src VLAN Customer

MAC MAC ID Packet
17230
For a Known MAC Address (Figure 72):

d. If the destination MAC address has already been learned by PE A, an existing
entry in the FDB table identifies the far-end PE router and the service VC label
(inner label) to be used before sending the packet to far-end PE C.
e. PE A chooses a transport LSP to send the customer packets to PE C. The
customer packet is sent on this LSP once the IEEE 802.1Q tag is stripped and the
service VC label (inner label) and the transport label (outer label) are added to
the packet.
For an Unknown MAC Address (Figure 72):
f. If the destination MAC address has not been learned, PE A will flood the packet
to both PE B and PE C that are participating in the service by using the VC labels
that each PE router previously signaled for the VPLS instance. The packet is not
sent to PE D since this VPLS service does not exist on that PE router.

VPLS
Figure 72: Network Port Egress Packet Format and Flooding
Pre-assigned and
signaled by PE C
Tunnel VC Dest Src Customer

Label Label X MAC MAC Packet
Apply VC and PE C
tunnel labels IP/MPLS
network
To Site C
Service tunnel B
Access
egress
B port
PE A Service tunnel B To Site B

Site A
PE B

Label Label Y MAC MAC Packet
Pre-assigned and
signaled by PE B
21560
2. Core Router Switching:

a. All the core routers (P routers in IETF nomenclature) between PE A and routers
PE B and PE C are Label Switch Routers (LSRs) that switch the packet based on
the transport (outer) label of the packet until the packet arrives at the far-end PE
router. All core routers are unaware of the content of the LSP payload (that is,
the core routers do not know that this traffic is associated with a VPLS service).

VPLS Overview
3. PE Router C:
a. PE C strips the transport label of the received packet to reveal the inner VC label.
The VC label identifies the VPLS service instance to which the packet belongs.
b. PE C learns the source MAC address in the packet and creates an entry in the
FDB table that associates the MAC address to PE A and the VC label that PE A
signaled for the VPLS service.
c. The destination MAC address in the packet is looked up in the FDB table for the
VPLS instance. Again, there are two possibilities: either the destination MAC
address has already been learned (known MAC address) or it has not been
learned on the access side of PE C (unknown MAC address).
For a Known MAC Address (Figure 73):
d. If the destination MAC address has been learned by PE C, an existing entry in
the FDB table identifies the local access port and the IEEE 802.1Q tag to be
added before sending the packet to customer Location-C. The egress Q tag may
be different from the ingress Q tag.
For an Unknown MAC Address (Figure 73):
e. PE C will flood packets, as applicable.
Figure 73: Access Port Egress Packet Format and Lookup
Pre-assigned and
signaled by PE C

Label Label X MAC MAC Packet
Apply VC and PE C
tunnel labels IP/MPLS
network
To Site C
Service tunnel B
Access
egress
B port
PE A Service tunnel B To Site B

Site A
PE B

Label Label Y MAC MAC Packet
Pre-assigned and
signaled by PE B
21560

VPLS
Bridged Mobile Backhaul

Figure 74 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.
Figure 74: Typical Pseudowire-based Mobile Backhaul
VPRN cell site

7750 SR-1 aggregate
Cell Site
NodeB
7705 SAR
Transport
NW RNC-1
7750 SR-2
Legend:
Active PW
Standby PW
21553
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 75, 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.

VPLS Overview
Returning to the VPLS-3G example in Figure 75, 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.
Figure 75: Local VPLS on 7705 SAR in Mobile Backhaul
VPLS-3G cell site

aggregate
VPLS-3G cell site
7750 SR-1 aggregate
NodeB-1
7705 SAR
NodeB-2 Cell site-1 Transport
NW RNC-1
7750 SR-2
Legend:
VPLS 1-3G active PW
VPLS 1-3G redundant PW
21554
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 75, 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.

VPLS
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).
Multi-Tenant Unit (MTU) Termination

Figure 75 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 75), 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 75 can be replaced by 7705 SAR nodes running Release 4.0 or
later of the 7705 SAR OS. Figure 76 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 76, the node that initiates the redundant PWs is the cell site
7705 SAR). Thus, 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.

VPLS Overview
Figure 76: Spoke-SDP Termination to VPLS using 7705 SAR-18 Routers
VPLS-3G cell site 7705

aggregate
SAR-18_1
NodeB-1
7705 SAR
Core
VPLS 7750 SR
NodeB-2 Cell site-1 Transport NW
NW
VPLS-3G
cell site
aggregate
7705
SAR-18_2
Legend:
VPLS 1-3G active PW
7705
VPLS 1-3G redundant PW
SAR-18_3
21555

VPLS
VPLS Features
• VPLS Enhancements
• Fabric Mode
• Subscriber VLAN
• ATM Encapsulated Residential SAP
• VPLS over MPLS
• VPLS MAC Learning and Packet Forwarding
• Pseudowire Control Word
• Agent Circuit ID Insertion
• MAC Filters
• FDB Table Management
• VPLS and Rate Limiting Via QoS Policy
• MAC Move
• Split Horizon Groups (SAP and Spoke SDP)
• Multicast for VPLS and Routed VPLS (IGMP and MLD Snooping)
VPLS Enhancements
The Alcatel-Lucent VPLS implementation includes several enhancements to basic VPN
connectivity. The following VPLS features can be configured individually for each VPLS:
• MAC and IP filter support (up to Layer 4). MAC and IP filters can be applied on a
per-SAP ingress and per-SDP ingress (mesh and spoke) basis. IP filters can also be
applied on a per-SAP egress basis (Ethernet SAPs only).
• FDB management features on a per-service level, including:
→ configurable FDB size limit
→ FDB size alarms
→ MAC learning disable
→ discard unknown
→ separate aging timers for locally and remotely learned MAC addresses
• ingress rate limiting for broadcast, multicast, and (destination) unknown (BMU)
flooding on a per-SAP basis
• implementation of STP parameters on a per-VPLS and per-SAP basis

VPLS Features
• SHG on a per-SAP and per-spoke SDP basis

• DHCP snooping on a per-SAP basis
• IGMP and MLD snooping on a per-SAP and per-SDP basis
• optional spoke SDP redundancy to protect against node failure
Figure 77 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 77, colocated IP DSLAM (ISAM) traffic can
also be transported by the 7705 SAR.
Figure 77: ATM and IP DSLAM Backhaul
Ingress
ATM DSLAM System #1
STM1
ATM
Shelf-4 Shelf-3 Shelf-2 Shelf-1
ATM DSLAM System #4
STM1
ATM MC-LAG
Shelf-4 Shelf-3 Shelf-2 Shelf-1 7750 SR-1
A/S LAG 7705 SAR
7750 SR-2
GigE
IP DSLAM #1
A/S LAG
GigE
IP DSLAM #4
21599

VPLS
Fabric Mode
Similar to IES and VPRN services, to configure a VPLS instance, the fabric mode must be
set to aggregate mode (not per-destination mode). Thus, VPLS service is 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.
Subscriber VLAN
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.
• When subscriber VLAN is enabled, a VLAN tag (c-tag) is pushed at ATM ingress
and removed at ATM egress. In other words, a symmetrical push/pop operation is
supported and cannot be enabled/disabled on a per-direction basis. The exception to
this occurs when the Ethernet frame received from the network side does not have
any additional VLAN tags; in this case, the received frame is forwarded over the
ATM SAP “as is”. That is, there is no pop operation or error message generated.
• The ATM port is always considered to be “NULL”, which means that when a frame
is received at ATM egress from a dot1q port (Ethernet SAP to ATM SAP) or from a
VLAN vc-type (network), the outer-most VLAN tag is removed (the subscriber tag,
or s-tag). If subscriber VLAN is also enabled, the first two outer-most VLAN tags
are removed (that is, the s-tag and the c-tag).
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.

VPLS Features
ATM Encapsulated Residential SAP

For ATM encapsulated residential SAPs:
• the 7705 SAR always transmits the bridge PDU (BPDU) without FCS
(PID = 0x00-07)
• the 7705 SAR supports reception of a BPDU both with FCS (PID = 0x00-01) and
without FCS (PID = 0x00-07)
VPLS over MPLS

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:
• connecting bridging-capable PE routers with a full mesh of MPLS LSP tunnels

• negotiating per-service VC labels using draft-Martini encapsulation
• replicating unknown and broadcast traffic in a service domain
• enabling MAC learning over tunnel and access ports (see VPLS MAC Learning and
Packet Forwarding)
• using a separate forwarding database (FDB) per VPLS service

VPLS
VPLS MAC Learning and Packet Forwarding

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.
Pseudowire Control Word

The control-word command enables the use of the control word individually on each mesh
SDP or spoke SDP. By default, the control word is disabled. 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.
Agent Circuit ID Insertion

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 78 illustrates the signaling.

VPLS Features
Figure 78: PPPoE Initialization and Agent-Id Push Function
Intercept PADI and PADR

Append/push agent-id
ATM (if configured)
DSLAM
STM1 7750 SR-1

ATM
BRAS
Shelf-1
7705 SAR
7750 SR-2
1. PPPoE Active Discovery Initiation (PADI)
2. PPPoE Active Discovery Offer (PADO)
3. PPPoE Active Discovery Request (PADR)
4. PPPoE Active Discovery Session Confirmation (PADS)
21598
Figure 79 illustrates the agent circuit ID information, where the following definitions apply:
• vendor-type—is always the value 1

• vendor-length—is less than or equal to 65 bits
• string—is the access-node identifier (atm card/slot/port:vpi.vci), which
is automatically assigned by the 7705 SAR to be the system-name (hostname)
Figure 79: Agent Circuit ID Information
Vendor-Type Vendor-Length String
8-bits 8-bits
21381
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.

VPLS
MAC Filters
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:
• source MAC address

• destination MAC address
• Ethertype
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 OS Router Configuration Guide.
FDB Table Management

The following sections describe VPLS features related to management of the FDB, including:
• FDB size
• FDB size alarms
• local and remote aging timers
• Unknown MAC discard
FDB Size
The following MAC table management features are required for each instance of a SAP or
spoke SDP within a particular VPLS instance:
• MAC FDB size limits—allows users to specify the maximum number of MAC FDB
entries that are learned locally for a SAP or a spoke SDP. If the configured limit is
reached, then no new addresses will be learned from the SAP until at least one FDB
entry is aged out or cleared.

VPLS Features
→ When the limit is reached on a SAP, packets with unknown source MAC
addresses are still forwarded (this default behavior can be changed via
configuration). By default, if the destination MAC address is known, it is
forwarded based on the FDB, and if the destination MAC address is unknown, it
is flooded. Alternatively, if discard unknown is enabled at the VPLS service
level, any packets from unknown source MAC addresses are discarded at the
SAP.
→ The log event “SAP MAC limit reached” is generated when the limit is reached.
When the condition is cleared, the log event “SAP MAC Limit Reached
Condition Cleared” is generated.
→ disable-learning allows users to disable the dynamic learning function on
a SAP or a spoke SDP of a VPLS instance
→ disable-aging allows users to turn off aging for learned MAC addresses on
a SAP or a spoke SDP of a VPLS instance
FDB Size Alarms
The size of the VPLS FDB can be configured with a low watermark and a high watermark,
expressed as a percentage of the total FDB size limit. If the actual FDB size grows above the
configured high watermark percentage, an alarm is generated. If the FDB size falls below the
configured low watermark percentage, the alarm is cleared by the system.
Local and Remote Aging Timers
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 up to two
times their respective age timers to be aged out.

VPLS
Disable MAC Aging
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.
Disable MAC Learning
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
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.
VPLS and Rate Limiting Via QoS Policy

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 OS Quality of Service Guide.

VPLS Features
MAC Move
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:
• configuration capabilities to group VPLS ports and to define the order in which they
should be blocked
• criteria defining when individual groups should be blocked
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.

VPLS
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).
Split Horizon Groups (SAP and Spoke SDP)

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.

VPLS Features
Residential Split Horizon Groups
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.
Multicast for VPLS and Routed VPLS (IGMP and MLD

Snooping)
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:
• Sample Scenarios
• Group and Addressing Support
• IP Multicast in r-VPLS
• Multicast Router Ports
• Tagged Access Traffic
• Hardware Support
For more information on multicast, refer to the “IP Multicast” section in the 7705 SAR OS
Routing Protocols Guide.

VPLS
Sample Scenarios
Figure 80 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 80: Video over Mobile Backhaul
Hosts Sources
S2
H1 IGMPv3/ PIM SSM PIM SSM
H2 MLDv2 for IPv4/v6 for IPv4/v6 S1
H3
H4
Metro
Ethernet
eNB Transport
7705 SAR
Multicast
7750 SR
Group DB
IGMP/MLD r-VPLS
Snooping (VPLS + IES)
25374
Figure 81 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 81, 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 81 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.

VPLS Features
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. MLD snooping
allows support for IPv6 addresses through the use of r-VPLS for IPv6.
Figure 81: Metro Cell Multicast
L3 To EPC
Metro Cell FIB GRE
Switch
Data Services Epipe
Unicast
L3 Interface SAP
SAP NAT
VPLS IES
Access L3
SAP PIM
PIM
Metro Cell
IGMP Snooping
25375
Group and Addressing Support
This section contains information on the following topics:
• IPv4 Multicast Support

• IPv6 Layer 2 Multicast Support and Group Address
IPv4 Multicast Support
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.

VPLS
IPv6 Layer 2 Multicast Support and Group Address
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 sample CLI display below, for the
IPv6 address FF04::1:FFFF:0011, the representation of the group address is
33:33:FF:FF:00:11.
Multicast FIB, Service 50

===============================================================================
Source Address Group Address Sap/Sdp Id Svc Id Fwd/Blk
-------------------------------------------------------------------------------
* 33:33:FF:FF:00:11 sap:1/1/1:50 Local Fwd
===============================================================================
7705 SAR supports PIM-SSM only. For IPv6 multicast services, PIM SSM requires SSM
translation in the r-VPLS interface context for (*,G) joins.
IP Multicast in r-VPLS
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 82 and Figure 83 illustrate how Layer 2 multicast interacts with Layer 3 multicast.
In Figure 82, there are three hosts and one channel. The Layer 3 multicast group forwards
source traffic to each port on which there is a corresponding Layer 2 multicast group. All
three Layer 2 groups are within the same r-VPLS. To configure this scenario, create three
Layer 2 groups 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.

VPLS Features
Figure 82: Multiple Hosts in an r-VPLS Receiving the Same Channel
7705 SAR
L2 Multicast
FIB Entry
Hosts_1 Chan_1
L2 Multicast
FIB Entry L3 Multicast
Group
GRT
Hosts_2 Chan_1 Server
Source
L2 Multicast
FIB Entry
R-VPLS
Hosts_3 Chan_1
25376
In Figure 83, 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). Thus, 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 83, 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.

VPLS
Figure 83: Multiple Hosts in an r-VPLS Receiving Different Channels
7705 SAR
L2 Multicast
FIB Entry
Hosts_1 Chan_1 L3 Multicast

Group
L2 Multicast
FIB Entry L3 Multicast
Group
GRT
Hosts_2 Chan_2 L3 Multicast Server
Group Source
L2 Multicast
FIB Entry
R-VPLS
Hosts_3 Chan_3
Legend:
Channel 1
Channel 2
Channel 3
25377
IPv6 Multicast Forwarding Behavior in r-VPLS
In general, the behavior of IPv6 multicast in r-VPLS is as follows.
• Multicast in Layer 2 is only supported by (*,G). That is, (S,G) in Layer 3 gets
translated to (*,G) in Layer 2.
• Multicast in Layer 3 is only supported by (S,G).
The IPv6 multicast control plane behavior is as follows.
• (S,G) is forwarded from the Layer 2 snooping interface to PIM without translation to
(*,G).
• The Layer 2 multicast forwarding table is built based on (*,G) and the MAC-format
multicast-group address scheme, using the four least significant bytes of the IPv6
address (see IPv6 Layer 2 Multicast Support and Group Address)
• The Layer 3 multicast forwarding table is built based on (S,G) and the full IPv6
multicast group address.

VPLS Features
The IPv6 multicast data plane behavior is as follows.
• The Layer 2 forwarding table (see bullet 2 above) is downloaded to the data plane.
• The Layer 3 forwarding table (see bullet 3 above) is downloaded to the data plane.
• Layer 3 multicast for IPv6 supports the entire range of multicast addresses.
• The Layer 2 multicast address is limited and unique to prefix /96. That is, only the
four least significant bytes of the IPv6 multicast address are used. Note the following
items.
→ It is useful to keep the multicast table small at the network edge, where multicast
groups can be effectively managed via 32-bit (4-byte) addressing.
→ A 32-bit multicast address can provide 4 bytes of multicast group addressing.
→ Optionally, multicast zones can be created on the access side with overlapping
32-bit addresses, but in the core—where the entire IPv6 multicast group is
available—multicast zones can guide traffic correctly to the corresponding
access group.
Multicast Router Ports
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.
Tagged Access Traffic
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.

VPLS
Hardware Support
Multicast VPLS and r-VPLS are supported on the following 7705 SAR hardware:
• 8-port Ethernet Adapter card, version 2

• 8-port Gigabit Ethernet Adapter card
• 10-port 1GigE/1-port 10GigE X-Adapter card
• 6-port Ethernet 10Gbps Adapter card
• Packet Microwave Adapter card
• standalone platforms, including the 7705 SAR-M, 7705 SAR-A, 7705 SAR-H,
7705 SAR-Hc, 7705 SAR-W, 7705 SAR-Wx, and 7705 SAR-X
• 7705 SAR-M modules, including the GPON module, 8-port xDSL module, and
6-port DSL Combination module
• 4-port SAR-H Fast Ethernet module
• hardware that supports PPP/MLPPP for uplink spoke SDPs

Routed VPLS
Routed VPLS
• IES or VPRN IP Interface Binding

• IP Interface MTU and Fragmentation
• ARP/ND and VPLS FIB Interactions
• The allow-ip-int-binding VPLS Flag
• DSCP Marking
• VPLS SAP Ingress IP Filter Override
• Routed VPLS Supported Routing-Related Protocols
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.
IES or VPRN IP Interface Binding

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.
• Assigning a Service Name to a VPLS Service

• Binding a Service Name to an IP Interface
• Removing a Bound VPLS Service or Service Name
• IP Interface and VPLS Operational State Coordination

VPLS
Assigning a Service Name to a VPLS Service
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.
Binding a Service Name to an IP Interface
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:
• if the service name is not currently in use by a service, the IP interface will be placed
in an operationally down: Non-existent service name or inappropriate service type
state
• if the service name is currently in use by a VPLS service without the
allow-ip-int-binding flag set, the IP interface will be placed in the operationally
down: VPLS service allow-ip-int-binding flag not set state
• if the service name is currently in use by a valid VPLS service and the
allow-ip-int-binding flag is set, the IP interface will be attached to the VPLS service

Routed VPLS
Removing a Bound VPLS Service or Service Name
A VPLS service that is currently attached to an IP interface cannot be deleted from the system
unless the IP interface is unbound from the VPLS service name.
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.
IP Interface and VPLS Operational State Coordination
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.
IP Interface MTU and Fragmentation

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.

VPLS
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.
ARP/ND and VPLS FIB Interactions
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.

Routed VPLS
Routed VPLS Specific ARP/ND Cache Behavior
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 57 describes how the ARP cache and MAC FIB entry states interact at ingress
and Table 58 describes the corresponding egress behavior.
Table 57: Ingress Behavior for VPLS Next-Hop Routing
Layer 3 Next-Hop Next-Hop MAC Ingress Behavior

ARP Cache Entry FIB Entry
ARP Cache Miss Known or Flood to all egress forwarding engines associated with the VPLS
(No Entry) Unknown 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
Table 58: Egress Behavior for VPLS Next-Hop Routing
Layer 3 Next-Hop ARP Next-Hop MAC Egress Behavior

Cache Entry FIB Entry
ARP Cache Miss Known No ARP entry. The MAC address is unknown and the ARP request
(No Entry) 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

VPLS
The allow-ip-int-binding VPLS Flag

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.
VPLS Feature Restrictions (due to allow-ip-int-binding)
If the allow-ip-int-binding flag is set on a VPLS service, the following features are disabled:
• MAC filters
• residential SHG
• DHCP
• mVPLS
• mac-subnet-length
• GRE SDP (cannot be bound to the VPLS)
Note: The DHCP relay functionality under service>ies>if>dhcp can be used to

dynamically assign IP addresses to the clients connected to routed VPLS SAPs.
DSCP Marking
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.

Routed VPLS
VPLS SAP Ingress IP Filter Override

If an IP interface is attached to a VPLS service context, the VPLS SAP provisioned IP 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 a filter for an IPv4 or IPv6 packet type is not overridden, the SAP-specified filter is applied
to the packet (if defined).
Routed VPLS Supported Routing-Related Protocols

The following protocols are supported on IP interfaces bound to a VPLS service:
• BGP (IPv4 and IPv6)

• OSPF (IPv4 only)
• static routing (IPv4 and IPv6)
• BFD (IPv4 and IPv6)
• VRRP (IPv4 only)
• ARP
• ND protocol
• DHCP (IPv4 and IPv6)

VPLS
VPLS and Spanning Tree Protocol

• VPLS Redundancy
• VPLS Access Redundancy
• MAC Flush Message Processing
The Alcatel-Lucent 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 Alcatel-Lucent 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, refer to 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.
VPLS Redundancy
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:
• connecting MTUs to PEs in a metro area network

• interconnecting the VPLS nodes of two metro networks
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.
Alcatel-Lucent routers have implemented special features for improving the resilience of
hierarchical VPLS instances, in both MTU and inter-metro applications.

Spoke SDP Redundancy for Metro Interconnection
When two or more meshed VPLS instances, such as in Figure 84, 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.
Figure 84: H-VPLS with Spoke Redundancy
MPLS Transit
Network
MPLS tunnel
Spoke
Spoke
Legend:
Metro IP/MPLS Network
Full Mesh
21877
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.

VPLS
Spoke SDP-Based Redundant Access
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 84, 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.
VPLS Access Redundancy

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.
STP-Based Redundant Access to VPLS
In the configuration shown in Figure 85, 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.

Figure 85: Dual Homed MTUs in Two-Tier Hierarchical VPLS
Primary Spoke
Pseudowire
MTUs
H-VPLS full
Custonmer Site 1 mesh Core
CE-1 PE-1 PE-3
Backup Spoke
Custonmer Site 2 Pseudowire
CE-1 PE-2 PE-4
25444
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.
MAC Flush Message Processing

The previous sections described 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.

VPLS
Upon reception of MAC flush messages (regardless of the type), the 7705 SAR PE takes the
following actions:
• clears the FDB entries of all indicated VPLS services conforming to the definition
• propagates the message (preserving the type) to all LDP peers, if the
propagate-mac-flush flag is enabled at the corresponding VPLS level
The flush-all-but-mine message is generated under the following conditions.
• The flush-all-but-mine message is received from an LDP peer and the

propagate-mac-flush flag is enabled. The message is sent to all LDP peers in the
context of the VPLS service in which it was received.
• A flush-all-but-mine message is generated when a switchover occurs between spoke
SDPs of the same endpoint. The message is sent to the LDP peer connected through
the newly active spoke SDP.
• A flush-all-but-mine message is generated when a TCN message is received in an
STP context and the propagate-mac-flush flag is enabled. The message is sent to all
LDP peers connected by spoke and mesh SDPs in the context of the VPLS service
controlled by the STP instance, as determined by the mVPLS definition.
If all LDP peers are in the STP domain, it means that the mVPLS and the VPLS both
have the same topology and the 7705 SAR will not send any flush-all-but-mine
messages. If there are VPLS LDP peers outside the STP domain, the router sends
flush-all-but-mine messages to all its VPLS peers. When a TCN occurs in the Layer 2
domain, the MAC flush message is propagated over spoke SDPs.
The 7705 SAR will only send a withdrawal request if the mVPLS contains a mesh
SDP.
The flush-mine message is generated under the following conditions:
• The flush-mine message is received from an LDP peer and the propagate-mac-flush
flag is enabled. The message is sent to all LDP peers in the context of the VPLS
service in which it was received.
• The flush-mine message is generated when on a SAP or SDP transition from an
operationally up to an operationally down state and the send-flush-on-failure flag is
enabled in the context of the given VPLS service. The message is sent to all LDP
peers connected in the context of the given VPLS service. The send-flush-on-failure
flag is blocked in mVPLS and is only allowed to be configured in a VPLS service
managed by mVPLS. This is to prevent both messages being sent at the same time.
• The flush-mine message is generated when on an MC-LAG SAP or MC-APS SAP
transition from an operationally up state to an operationally down state. The message
is sent to all LDP peers connected in the context of the given VPLS service.

Dual Homing to a VPLS Service
Figure 86 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 86) 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.

VPLS
Figure 86: Dual-Homed CE Connection to VPLS
PE-A PE-C
L2-A L2-B
PE-B PE-C
MAC flush
Link down
X
PE-A PE-C
L2-A L2-B
PE-B PE-C
PE-A PE-C
L2-A L2-B
PE-B PE-C
PE-A PE-C
L2-A L2-B
Legend:
Standby PE-B PE-C
25445

ATM PVC Access and Termination on a VPLS Service
ATM PVC Access and Termination on a VPLS

Service
The application shown in Figure 87 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.
Figure 87: Example of ATM PVC Access and Termination on a VPLS
IP/IPX
RFC2684 IP/IPX IP/IPX
B-PDU Ethernet (VLAN) Ethernet
AAL5 ATM ETHoMPLS (VLAN)
ATM1 APS MPLS
ATM UNI protected POS/GigE
links IP/MPLS CE2
ATM2 Ethernet
CE1 (VLAN) UNI
IP/IPX VPLS VPLS

RFC2684/ PVC/SPVC Ethernet
RFC2427 (VLAN) UNI
B-PDU PE 1 PE 1
AAL5 ATM 7705 SAR-18 7705 SAR-18
ATM CE4
VPLS
ATM3
ATM UNI
CE3
PE 1
7705 SAR-18
21558
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 destination(s) 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.

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

VPLS Service Considerations
VPLS Service Considerations

This section describes general 7705 SAR service features and any special capabilities or
considerations as they relate to VPLS services:
• SAP Encapsulations
• VLAN Processing
• QinQ (VPLS)
SAP Encapsulations
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:
• Ethernet null
• Ethernet dot1q
• Ethernet qinq
• ATM VC with RFC 2684 llc-snap bridged encapsulation (see ATM PVC Access and
Termination on a VPLS Service)
VLAN Processing
The SAP encapsulation definition on Ethernet ingress ports defines which VLAN tags are
used to determine the service that the packet belongs to:
• null encapsulation defined at ingress—any VLAN tags are ignored and the packet
goes to a default service for the SAP
• dot1q encapsulation defined at ingress—only the first label is considered
• qinq encapsulation defined at ingress—only the topmost two labels are considered
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.

VPLS
For dot1q and qinq encapsulations, traffic encapsulated with tags for which there is no
definition are discarded.
Tagging Rules for VPLS
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.
QinQ (VPLS)
VPLS supports QinQ functionality. For details, see QinQ Support.

Configuration Notes
Configuration Notes
The following caveats apply to the implementation of VPLS:
• fabric mode must be set to aggregate mode (not per-destination mode)

• associating a service with a filter policy other than the default policy is optional
Reference Sources
For information on supported IETF drafts and standards, as well as standard and proprietary
MIBs, refer to Standards and Protocol Support.

Vpls Overview PDF

Uploaded by

Copyright:

Available Formats

Vpls Overview PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vpls Overview PDF

Uploaded by

Copyright:

Available Formats

VPLS

7705 SAR OS Services Guide 475

• VPLS Packet Walkthrough

Other VPLS advantages include:

• VPLS is a transparent, protocol-independent bridged service

476 7705 SAR OS Services Guide

• any Ethernet port (null or tagged) in access mode

7705 SAR OS Services Guide 477

Access Control and Traffic Management

In applications such as DSL aggregation, it is useful to extend the split-horizon concept to

478 7705 SAR OS Services Guide

VPLS Packet Walkthrough

Figure 70: VPLS Service Architecture

1. PE Router A (Figure 71):

7705 SAR OS Services Guide 479

Figure 71: Access Port Ingress Packet Format and Lookup

Dest Src VLAN Customer

For a Known MAC Address (Figure 72):

480 7705 SAR OS Services Guide

Figure 72: Network Port Egress Packet Format and Flooding

Tunnel VC Dest Src Customer

PE A Service tunnel B To Site B

Tunnel VC Dest Src Customer

2. Core Router Switching:

7705 SAR OS Services Guide 481

Figure 73: Access Port Egress Packet Format and Lookup

Tunnel VC Dest Src Customer

PE A Service tunnel B To Site B

Tunnel VC Dest Src Customer

482 7705 SAR OS Services Guide

Bridged Mobile Backhaul

Figure 74: Typical Pseudowire-based Mobile Backhaul

VPRN cell site

7705 SAR OS Services Guide 483

Figure 75: Local VPLS on 7705 SAR in Mobile Backhaul

VPLS-3G cell site

484 7705 SAR OS Services Guide

Multi-Tenant Unit (MTU) Termination

7705 SAR OS Services Guide 485

Figure 76: Spoke-SDP Termination to VPLS using 7705 SAR-18 Routers

VPLS-3G cell site 7705

486 7705 SAR OS Services Guide

7705 SAR OS Services Guide 487

• SHG on a per-SAP and per-spoke SDP basis

Figure 77 illustrates VPLS enhancements using an example of ATM DSLAM backhaul,

Figure 77: ATM and IP DSLAM Backhaul

ATM DSLAM System #1

ATM DSLAM System #4

A/S LAG 7705 SAR

488 7705 SAR OS Services Guide

A subscriber VLAN has the following characteristics.

7705 SAR OS Services Guide 489

ATM Encapsulated Residential SAP

VPLS over MPLS

VPLS is provided over MPLS by:

• connecting bridging-capable PE routers with a full mesh of MPLS LSP tunnels

490 7705 SAR OS Services Guide

VPLS MAC Learning and Packet Forwarding

Pseudowire Control Word