Hierarchical VPLS

Hierarchical VPLS

Virtual Private LAN Service (VPLS) has become a very attractive technology over the past few years with the advent of MPLS. The reason being some enterprises are very reluctant to relinquish routing control of their network to the service provider and desire L2VPN services with multipoint connectivity. VPLS allows service providers to deploy carrier-class service over Ethernet/MPLS-based network in a realiable and flexible way. This article will start with some VPLS basics and continue with H-VPLS.

VPLS

As its name implies, the purpose of VPLS is to provide a private multipoint LAN-type Ethernet connectivity service i.e. VPLS emulates a LAN segment over MPLS backbone across pseudowires or virtual circuits. VPLS creates one or more LANs for each customer who is using the service from the service provider. Each LAN is completely separate from the other emulated LAN segments. When a customer with different Ethernet sites connects to an MPLS backbone where VPLS is deployed, it appears as if all the sites are interconnected through a virtual Ethernet switch.

VPLS Terminology

• u-PE: User facing Provider Edge bridge that is used to connect Customer Edge (CE) devices to the service
• n-PE: Network Provider Edge that acts as a gateway between MPLS core and edge domain, which may be MPLS or Ethernet
• PE-Agg: Provider Edge - Aggregation Switch is an Ethernet switch that aggregates several u-PE connections for onward connection onto n-PE
• VSI: Virtual Switch Instance - A VSI describes an Ethernet bridge function within an n-PE that equates to a multipoint L2VPN. A unique atttribute of a VSI is that it terminates PW virtual interfaces, which differs from an Ethernet bridge that terminates physical Ethernet interface.
• PW: PsuedoWire - A PW is a virtual connection that connects two VSIs. A PW is bi-directional in nature and consists of a pair of uni-directional MPLS Virtual Circuits (VCs). A PW may also be used to connect a point-to-point circuit.
• AC: Attachment Circuit - An AC is the customer connection to a service provider network. An AC may be a physical port, or a virtual port.

VPLS Architecture

An Ethernet switch has the following characteristics:

• Forwarding of Ethernet frames
• Forwarding of Unicast frames with an unknown destination MAC address
• Replication of broadcast and multicast frames to more than one port
• Loop prevention
• Dynamic learning of MAC addresses
• MAC address aging

VPLS should also have these characteristics. If the PE router receives an Ethernet frame with unknown destination MAC address, the frame is replicated and forwarded to all ports that belong to that LAN segment.

VPLS Overview

For each VPLS, the PE routers are fully meshed with pseudowires. A PE receiving a frame from another PE can identify which VPLS the frame belongs to, on the basis of pseudowire label or VC label. As far as each customer is concerned, an Ethernet frame that is sent into the service provider network is delivered to the correct site(s), on the basis of destination MAC address. It is the task of each PE router to inspect the destination MAC address of each frame arriving from a locally attached site and to forward it to appropriate destination site. This destination site may be attached to the same PE on a different port or a remote PE. If the destination site is attached to the same PE, the PE locally switches the frame to correct port. If the destination site is attached to a remote PE, the ingress PE must forward the frame to appropriate pseudowire to the remote PE. This means that the ingress PE needs to know which egress PE to send the frame to.

There are two ways in which this can be achieved- one is to have a control plane signalling to carry information about MAC addresses between PEs, or to have a scheme based on MAC address learning. VPLS takes the latter approach by having each PE take the responsibility of learning which remote PE is associated with a given MAC address. Thus an ingress PE simply needs to identify which frames need to be sent to egress PEs, and egress PEs takes care of identifying which local ports to forward the packet to. By inspecting the source MAC address, say A, of the frame arriving on a port, whether an actual local port or a pseudowire from a remote PE, and by creating a corresponding entry in the forwarding table, the PE learns where to send frames in the future having destination MAC address, A.

In the case where Ethernet switches are used as CE devices and connected to PE routers, the PEs need to learn the MAC addresses of individual hosts attached to the switches. So, if a host is plugged into the office network served by a switch as a CE, the effect will be felt by all PEs. Thus, for a large deployment, it is better to use routers as CEs than switches.

Forwarding of Unicast Frames

In figure 1, suppose that the MAC address of host C is C and the MAC address of host B is B, for the customer network X. Suppose host C sends a frame with source MAC address C and destination MAC address B. Suppose that PE3 does not know the location of MAC address B. As a learning bridge would do, PE3 floods the packet on all ports except the port on which it arrived. This means the packet is flooded to the pseudowire to PE2 and the pseudowire to PE1.

PE1 and PE2 know that the packet belongs to customer X's VPLS, by virtue of the pseudowire on which the frame arrived. PE1 and PE2 both perform destination MAC address lookup in their VPLS forwarding tables corresponding to customer X. If PE1 does not know the location of MAC address B, it floods the frame on its local ports to CE. However, it does not flood the frame to any other PEs. This split horizon scheme ensures no forwarding loops occur. Similarly, PE2 forwards the frame on to the port facing the switch CE.

Receiving frames with MAC address C enables each PE to learn the location of host C. Thus, PE2 and PE1 creates an entry in their forwarding tables with an association between MAC address C and their respective pseudowires to PE3. In this way, all PEs learn the MAC addresses and creates an association between MAC addresses and pseudowires (for remote destinations) in their forwarding tables for that particular VPLS instance.

Forwarding of Broadcast and Multicast Frames

In figure 1, suppose PE3 receives a broadcast frame sent by host C. The frame must be sent to all sites of customer X's VPLS. PE3 floods the frame onto pseudowires to PE1 and PE2. In turn, PE1 and PE2 floods the frame to the attached CEs, but due to split horizon, do not send the frames to any PEs. Multicast traffic is also treated exactly this way.

VPLS Discovery - How does a PE know which other PEs have members of a particular VPLS attached?

The capability to manually configure the addresses of remote PEs is required. However, the use of manual configuration is not necessary if auto-discovery is used. Auto-discovery allows PE devices to automatically discover other PE devices that have an association with a particular VPLS instance. Once the PEs have discovered other PEs for a VPLS instance, they can then signal connections to interconnect the PEs.

There are a number of mechanisms that can be used to distribute VPLS associations between PE devices, which includes extensions to BGP version 2 (multiprotocol BGP), LDP-based, DNS-based, RADIUS-based, and static.

• Static configuration requires that each PE associated with a VPLS instance is configured as a peer. The scalability of this solution is low as manual configuration is required every time a VPLS is added, changed or deleted. However, as the peers are manually configured, the security and flexibility to signal additional attributes of the solution is fairly robust.
• NMS/OSS configuration uses a central management point that distributes VPLS membership to each PE associated with a particular VPLS. This provides syntax checking based upon the type of device being configured and allows other service specific attributes to be provisioned at the same time.
• DNS configuration uses a DNS to distribute VPLS membership information. This mechanism provides centralized management and also uses a common syntax. This mechanism requires that the requesting PE must belong to the DNS entries for the VPLS instance. However, this can not signal additional attributes and other mechanism is required to provide additional information.
• RADIUS configuration uses RADIUS attributes to distribute VPLS membership information. In this scheme, the PE sends a request to the RADIUS server containing an identifier specific to a VPLS instance. The RADIUS server returns a list of addresses of PEs belonging to that VPLS instance. This mechanism is centralized and requires that the requesting PE must belong to have a RADIUS attribute associating the PE with the requested VPLS. RADIUS attribute-value pairs can be used to signal additional attributes.
• LDP signalling requires that each PE is identified and a targeted LDP session is active for auto-discovery; it has no inherent auto-discovery, so the pseudowires must be manually configured or some external auto-discovery mechanism must be used. The overall scalability is poor as a PE must be associated with all other PEs for LDP discovery to work, which can lead to a large number of targeted LDP sessions. LDP can signal additional attributes but additional configuration is required from NMS/OSS or static.
• BGP signalling requires that a PE associated with a particular VPLS is configured under a BGP process. BGP then advertises VPLS membership information using NLRIs. Hence, BGP has inherent mechanism for auto-discovery and so frees the user from having to configure the pseudowires manually. BGP cannot easily distribute attributes such as bandwidth profiles without introducing additional overhead.

VPLS Signaling - How is a full mesh of pseudowires setup between PEs?

Once the PEs have ascertained that other PEs have an association with the same VPLS instance, each PE needs to setup a PE between each other and bind the PWs to the particular VSI. There are 2 solutions that have been described for signalling of PW between PEs-

• BGP-based VPLS (RFC 4761)
• LDP-based VPLS (RFC 4762)

LDP-based Signaling

LDP is used for the signaling of pseudowires that are used to interconnect the VPLS instance of a given customer on the PEs. In order to signal a full mesh of pseudowires required, a full mesh of targeted LDP (T-LDP) sessions is required between the PEs. In absence of auto-discovery, these sessions must be manually configured on each PE router. This LDP session is used to communicate the "inner label" or "VC label" that must be used for each pseudowire. The network operator assigns a VC ID which is used to identify a particular pseudowire, is configured to be the same for a particular VPLS instance on all PE routers.

Following is the information communicated over the LDP session including the label value itself. The FEC element includes the following fields-

• VC ID
• Control Word bit - This indicates whether a control word will be used.
• VC Type - This indicates the encapsulation type. This would be Ethernet or VLAN-tagged Ethernet.
• Interface parameters field - This contains information such as media MTU, etc.

Cisco IOS uses LDP to signal the setup, maintenance and teardown of a PW between PE devices. Once a PE discovers that other PEs have an association for a particular VPLS instance, the PEs signal using T-LDP to other PEs that a PW is required to be setup between PEs. When a PE device is associated with a particular VSI, LDP transmits a label-mapping message with VC-Type 0x0005 and a 4-byte VC-ID value. If the remote PE has an association with that particular VC ID, it will accept the LDP label-mapping message and respond with its own label-mapping message. Once the two uni-directional VCs are operational, they are combined to form a bi-directional PW.

BGP-based Auto-discovery and Signaling

The BGP NLRI takes care of auto-discovery and signaling at the same time, the NLRI generated by a given PE containing the necessary information required by any other PE. These components enable the automatic setting up of full mesh of pseudowires for each VPLS.

On each PE, a Route Distinguisher (RD) and a Router Target (RT) is configured for each VPLS, like in L3VPN and L2VPN. The RT is same for a particular VPLS across all PEs, and is used to identify which VPLS a particular BGP message pertains to. The RD is used to disambiguate routes. On each PE, for each VPLS an identifier is configured called VPLS Edge Identifier (VE ID). Each PE involved in a particular VPLS must be configured with a different VE ID. BGP is used to advertise the VE ID to other PEs. This, along with other information in NLRI, is used to calculate the value of pseudowire label required to reach the advertising PE.

For a given VPLS, a PE requires that each remote PE uses a different pseudowire label to send traffic to that PE. This is to facilitate the MAC learning process. This way, the receiving PE can learn which PE is associated with the source MAC address of the frame. A PE could send a list of pseudowire labels required to reach it, one per remote VPLS Edge in that VPLS. However, this would mean that a PE send a long list of labels if there are a large number of PEs. Instead, the necessary information is carried in BGP NLRI. This allows all remote PEs to calculate the pseudowire label expected by the advertising PE.

A BGP Update message contains the following items-

• Extended Community Route Target - This allows the receiving PE to ascertain which particular VPN the advertisement pertains to.
• Layer 2 Info - This is automatically generated by sending PE. It contains following information-
  • Control Flags to indicate whether a Control Word is included
  • Encapsulation type - Ethernet or VLAN tagged
  • MTU
• Other BGP attributes like AS Path, Origin, etc
• The NLRI contains the following information-
  • Route Distinguisher
  • VE ID
  • Label Base
  • VE Block Offset
  • VE Block size

The label base, VE block offset and VE block size are the information the receiving PE requires to calculate the pseudowire label when sending traffic for VPLS to the advertising PE. A PE allocates blocks of labels. Each block is a contiguous set of label values. The PE simply advertises the value of the first label (label base) and the number of labels in the block (block size). The label value that a remote PE having a VE ID value must use to reach the advertising PE is computed as

label value = label base + VE ID - 1

For example, say in figure 1, suppose PE1 advertises a label base of 100 to PE2 and PE3. Suppose the VE IDs of customer X's VPLS instance on PE1 is 1, on PE2 is 2 and on PE3 is 3. When PE2 wants to send traffic to PE1, PE2 calculates the pseudowire label as follows-

label value = 100 (label base of PE1) + 2 (VE ID of PE2) - 1

= 101

So, PE2 uses 101 as the VC label to send traffic to PE1. Similarly, PE3 calculates the VC label 102 for the VPLS. The VE Block offset is used in case there are multiple label blocks advertised in separate NLRIs.

Both of these implementation options are identical from forwarding plane point-of-view, but they differ in control plane, particularly in the protocol they use to signal and establish the pseudowires. The BGP implementation advertises a PE's association with a particular VPLS as well as the label block from which labels may be assigned to communicate with that PE. This approach has many disadvantages-

1. All label information is broadcast to all PEs associated with a particular VPLS due to full mesh. This is acceptable for initial VPLS auto-discovery, subsequent PW discovery is inefficient.
2. PW signalling of peer-to-peer parameters are broadcast to all PE routers which wastes bandwidth.
3. This mechanism uses BGP for MAC address flush instead of IEEE Spanning Tree TCNs that makes it incompatible with IEEE bridges.
4. BGP scaling mechanisms such as Route Reflectors (RRs) have to take into account increased signalling overhead.

Although a full mesh of PWs is formed between PEs, each individual PW has a set of unique attributes that are specific to a PW and have significance to that PW only. As attributes are point-to-point in nature, targeted LDP (T-LDP) is best suited. Further, since most MPLS implementations are LDP based, the use of LDP does not introduce a new protocol into the network.

To prevent packets looping, split horizon forwarding technique is used. It prevents transmitting a packet back out of the interface it was received upon. If a packet is received on a PW, it cannot be forwarded on any other PW associated with a particular VSI. The VPLS implementation allows customer BPDUs to be transported across the network. These customer BPDUs are tunneled through VPLS network.

VPLS Summary

VPLS enables a multipoint Ethernet service to be delivered over MPLS infrastructure. However, it has several scaling limitations like the requirement for a full mesh targeted LDP sessions for VPLS discovery and signalling. The PE device must form adjacency with all other PE devices. This requires the PE devices to learn the IP addresses of all remote PE devices, and exchange label information with them. Also, the replication of broadcast and multicast frames which occurs at the ingress PE router, causes an inefficient use of network bandwidth. With VPLS, you can transparently tunnel Layer 2 control protocols like CDP, STP, or VTP.

H-VPLS

To address the scaling limitations within flat VPLS architecture, H-VPLS is described. VPLS requires a full mesh of tunnel LSPs between all PE routers that participate in the VPLS service. For each VPLS service, n*(n-1)/2 PWs must be setup between PEs. This creates signalling overhead. Also, packet replication requirement detriments large scale deployment. Hierarchical connectivity reduces signalling and replication overhead.

H-VPLS introduces u-PE and n-PE routers. u-PE routers are user-facing PE routers, while n-PE routers are network-facing PE routers. The hierarchy provides the benefits of less signalling in MPLS core network and less packet replication on n-PE routers. The u-PE routers have an aggregation role and do some packet replication and MAC address learning.

RFC 4762 defines 2 mechanisms for access domain in H-VPLS. They are-

1. H-VPLS with Q-in-Q in Access layer
2. H-VPLS with MPLS in Access layer

The VPLS core PWs (hub) are augmented with access PWs (spoke) to form a two-tier H-VPLS. In figure 2, 3 customer sites are connected to u-PE devices. The u-PE devices have single connection (PW) to n-PE routers. The n-PE routers are connected in a basic VPLS full mesh service. For each VPLS service, a single spoke PW is setup between u-PE and n-PE devices. Unlike traditional PWs that terminate on a physical or logical port, a spoke PW terminates on a VSI on u-PE and n-PE devices. The u-PEs and n-PEs treat each spoke connection like an attachment circuit of the VPLS service. The PW label is used to associate the traffic from the spoke PW to a VPLS instance.

u-PE Operation

The u-PE device supports Layer 2 switching and does all the normal bridging functions of learning and replication on all its ports, including spoke PW. Packets to unknown destination are replicated to all ports in the service including spoke PW. Once the MAC addresses of CE devices connected to the same u-PE device are learned, traffic between them is switched localled, saving the capacity of the spoke PW to n-PEs. Similarly, traffic between remotely connected CE devices to different u-PE devices is switched directly onto spoke PW and sent to n-PEs over the point-to-point PW.

Since the u-PE is bridging capable, only a single PW is required per VPLS instance for any number of access connections in the same VPLS service. This reduces the signalling overhead between u-PEs and n-PEs. If the u-PE is directly connected to n-PEs, Q-in-Q encapsulation can be used for spoke PW.

n-PE Operation

An n-PE device supports all bridging functions for VPLS service and supports the routing and MPLS encapsulation like in basic VPLS. The operation of n-PE is independent of the type of device at the other end of the spoke PW. Thus the n-PE will switch traffic between spoke PW, hub PWs, and ACs once it has learned the MAC addresses.

Dual-Homed u-PE

The failure of n-PE or connection of PW, the u-PE can suffer total loss of connectivity. To prevent this, redundant connections can be provided. The u-PE is dual-homed into two n-PE routers. In figure 2, the u-PE sets up two PWs for each VPLS instance. One of the two PWs is designated as primary and the other as standby. The u-PEs negotiate pseudowire labels for both PWs, but does not use the standby PW unless the primary PW fails. Spanning tree instance or manual configuration can be used to designate primary and standby status.

Upon failure of primary PW, the u-PE immediately switches to the standby PW. At this point, the n-PE that terminates the standby PW, starts learning MAC addresses on the spoke PW. All other n-PEs initially continue to send traffic to initial n-PE until they learn that the devices are now connected to a new n-PE. To enable faster unlearning process, the new n-PE may send out a flush message using the MAC List TLV (Type 0x404) to all n-PEs. Upon receiving the message, the n-PEs flush the MAC addresses associated with that VPLS instance.

H-VPLS Model using Ethernet Access Network

H-VPLS model is expanded to include an Ethernet access network. It still requires n-PEs fully meshed in MPLS core, but there is no restriction on the topology of Ethernet access network, so u-PEs and n-PEs are not hubs and spokes. One approach of tunneling customer's Ethernet traffic via an Ethernet access network is to add an additional VLAN tag customer's data i.e. a S-VLAN tag. The customer's data may be tagged or untagged. Inside the provider's network, each S-VLAN designates a VPLS instance for a customer. Therefore, there is 1-1 correspondence between S-VLAN and VPLS instance. The u-PEs must have the capability of adding S-VLAN tag to customer data.

The n-PEs need to perform bridging functionality over the standard Ethernet ports toward the access network, as well as over the PWs towards the core network. Also, the n-PEs may need to run STP in the access network as well as split horizon in core network. The n-PEs need to map a S-VLAN to a VPLS instance and its associated PWs, and vice versa.

Configuration Example

Here, R4, R5, R6 and R7 form full-mesh of pseudowires using BGP auto-discovery and signalling mechanism. Also, R2 & R4 setup spoke-pseudowire using LDP mechanism. Similarly, R3 & R5, R6 & R8, and R7 & R9.

Since, multi-homing with VPLS is not supported (although, a new draft is submitted to IETF), R2 and R3 form redundancy group using ICCP to allow mLACP with R1. Similarly, R8 and R9 form redundancy group to allow mLACP with R10.

The configuration of R2 is as follows:

R2 : IOS-XR

redundancy

iccp

group 23

mlacp node 2

mlacp system mac 0000.0000.0023

mlacp system priority 32768

member

neighbor 3.3.3.3

!

l2vpn

bridge group BG_H-VPLS

bridge-domain BD_R1

interface Bundle-Ether23.110

!

neighbor 4.4.4.4 pw-id 24

!

Similar configuration applies to R3, R8 and R9 and hence not repeated here.

The configuration of R4 is as follows:

R4 : IOS-XR

router bgp 100

address-family l2vpn vpls-vpws

!

neighbor-group IBGP

remote-as 100

update-source Loopback0

address-family l2vpn vpls-vpws

!

!

neighbor 5.5.5.5

use neighbor-group IBGP

!

neighbor 6.6.6.6

use neighbor-group IBGP

!

neighbor 7.7.7.7

use neighbor-group IBGP

!

!

l2vpn

bridge group BG_H-VPLS

bridge-domain BD_BGP-VPLS

neighbor 2.2.2.2 pw-id 24

!

vfi BGP-VPLS

vpn-id 100

autodiscovery bgp

rd 4.4.4.4:100

route-target 100:2565

signaling-protocol bgp

ve-id 4

!

Note the address-family BGP configuration for auto-discovery and exchanging L2VPN NLRIs. A new AFI/SAFI is defined for this - AFI=25, and SAFI=65.

Also note that, R4 is configured to setup spoke-PW with R2 using the neighbor command in L2VPN.

Once the BGP session is established, R4, R5, R6 and R7 exchange L2VPN NLRI.

RP/0/RSP0/CPU0:R4# show bgp l2vpn vpls

Sat Sep 14 13:53:20.525 UTC

BGP router identifier 4.4.4.4, local AS number 100

BGP generic scan interval 60 secs

BGP table state: Active

Table ID: 0x0 RD version: 1269790052

BGP main routing table version 8

BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best

i - internal, r RIB-failure, S stale, N Nexthop-discard

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Rcvd Label Local Label

Route Distinguisher: 4.4.4.4:100 (default for vrf BG_H-VPLS:BD_BGP-VPLS)

*> 4:1/32 0.0.0.0 nolabel 16015

*>i5:1/32 5.5.5.5 16030 nolabel

*>i6:1/32 6.6.6.6 16030 nolabel

*>i7:1/32 7.7.7.7 16015 nolabel

Route Distinguisher: 5.5.5.5:100

*>i5:1/32 5.5.5.5 16030 nolabel

Route Distinguisher: 6.6.6.6:100

*>i6:1/32 6.6.6.6 16030 nolabel

Route Distinguisher: 7.7.7.7:100

*>i7:1/32 7.7.7.7 16015 nolabel

RP/0/RSP0/CPU0:R4# show bgp l2vpn vpls rd 4.4.4.4:100 4:1/32

Sat Sep 14 13:55:04.597 UTC

BGP routing table entry for 4:1/32, Route Distinguisher: 4.4.4.4:100

Versions:

Process bRIB/RIB SendTblVer

Speaker 2 2

Local Label: 16015

Last Modified: Sep 14 12:01:35.879 for 01:53:28

Paths: (1 available, best #1)

Advertised to update-groups (with more than one peer):

0.2

Path #1: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.2

Local

0.0.0.0 from 0.0.0.0 (4.4.4.4)

Origin IGP, localpref 100, valid, redistributed, best, group-best, import-candidate

Received Path ID 0, Local Path ID 1, version 2

Extended community: RT:100:2565 L2VPN:19:0:1500

Block Size:10

4:1/32 indicates the VE-ID (4) and Offset (1); ignore the prefix-length.

In the following output, it can be seen that R4 has a spoke-pseudowire (PW ID 24) to R2, and full-mesh (PW ID 100) to R5, R6 and R7.

RP/0/RSP0/CPU0:R4# show l2vpn bridge-domain detail

Sat Sep 14 13:57:52.586 UTC

Legend: pp = Partially Programmed.

Bridge group: BG_H-VPLS, bridge-domain: BD_BGP-VPLS, id: 0, state: up, ShgId: 0, MSTi: 0

Coupled state: disabled

MAC learning: enabled

MAC withdraw: enabled

MAC withdraw for Access PW: enabled

MAC withdraw sent on: bridge port up

MAC withdraw relaying (access to access): disabled

Flooding:

Broadcast & Multicast: enabled

Unknown unicast: enabled

MAC aging time: 300 s, Type: inactivity

MAC limit: 4000, Action: none, Notification: syslog

MAC limit reached: no

MAC port down flush: enabled

MAC Secure: disabled, Logging: disabled

Split Horizon Group: none

Dynamic ARP Inspection: disabled, Logging: disabled

IP Source Guard: disabled, Logging: disabled

DHCPv4 snooping: disabled

IGMP Snooping profile: none

MLD Snooping profile: none

Bridge MTU: 1500

MIB cvplsConfigIndex: 1

Filter MAC addresses:

Create time: 14/09/2013 11:40:19 (02:17:33 ago)

No status change since creation

ACs: 0 (0 up), VFIs: 1, PWs: 4 (4 up), PBBs: 0 (0 up)

List of ACs:

List of Access PWs:

PW: neighbor 2.2.2.2, PW ID 24, state is up ( established )

PW class not set, XC ID 0xc0000001

Encapsulation MPLS, protocol LDP

Source address 4.4.4.4

PW type Ethernet, control word disabled, interworking none

PW backup disable delay 0 sec

Sequencing not set

PW Status TLV in use

MPLS Local Remote

------------ ------------------------------ ---------------------------

Label 16002 16009

Group ID 0x0 0x2

Interface Access PW Access PW

MTU 1500 1500

Control word disabled disabled

PW type Ethernet Ethernet

VCCV CV type 0x2 0x2

(LSP ping verification) (LSP ping verification)

VCCV CC type 0x6 0x6

(router alert label) (router alert label)

(TTL expiry) (TTL expiry)

------------ ------------------------------ ---------------------------

Incoming Status (PW Status TLV):

Status code: 0x0 (Up) in Notification message

MIB cpwVcIndex: 3221225473

Create time: 14/09/2013 11:40:19 (02:17:33 ago)

Last time status changed: 14/09/2013 11:40:19 (02:17:33 ago)

MAC withdraw messages: sent 0, received 0

Static MAC addresses:

Statistics:

packets: received 4118, sent 1901

bytes: received 263552, sent 121664

Storm control drop counters:

packets: broadcast 0, multicast 0, unknown unicast 0

bytes: broadcast 0, multicast 0, unknown unicast 0

MAC learning: enabled

Flooding:

Broadcast & Multicast: enabled

Unknown unicast: enabled

MAC aging time: 300 s, Type: inactivity

MAC limit: 4000, Action: none, Notification: syslog

MAC limit reached: no

MAC port down flush: enabled

MAC Secure: disabled, Logging: disabled

Split Horizon Group: none

DHCPv4 snooping: disabled

IGMP Snooping profile: none

MLD Snooping profile: none

Storm Control: disabled

List of VFIs:

VFI BGP-VPLS (up)

VPN-ID: 100, Auto Discovery: BGP, state is Provisioned (Service Connected)

Route Distinguisher: 4.4.4.4:100

Import Route Targets:

100:2565

Export Route Targets:

100:2565

Signaling protocol: BGP

Local VE-ID: 4 , Advertised Local VE-ID : 4

VE-Range: 10

PW: neighbor 5.5.5.5, PW ID 100, state is up ( established )

PW class not set, XC ID 0xc0000002

Encapsulation MPLS, Auto-discovered (BGP), protocol BGP

Source address 4.4.4.4

PW type VPLS, control word disabled, interworking none

Sequencing not set

MPLS Local Remote

------------ ------------------------------ -------------------------

Label 16019 16033

MTU 1500 1500

Control word disabled disabled

PW type VPLS VPLS

VE-ID 4 5

------------ ------------------------------ -------------------------

MIB cpwVcIndex: 3221225474

Create time: 14/09/2013 12:03:36 (01:54:16 ago)

Last time status changed: 14/09/2013 12:03:36 (01:54:16 ago)

MAC withdraw messages: sent 0, received 0

Static MAC addresses:

Statistics:

packets: received 0, sent 3421

bytes: received 0, sent 218944

DHCPv4 snooping: disabled

IGMP Snooping profile: none

MLD Snooping profile: none

PW: neighbor 6.6.6.6, PW ID 100, state is up ( established )

PW class not set, XC ID 0xc0000003

Encapsulation MPLS, Auto-discovered (BGP), protocol BGP

Source address 4.4.4.4

PW type VPLS, control word disabled, interworking none

Sequencing not set

MPLS Local Remote

------------ ------------------------------ -------------------------

Label 16020 16033

MTU 1500 1500

Control word disabled disabled

PW type VPLS VPLS

VE-ID 4 6

------------ ------------------------------ -------------------------

MIB cpwVcIndex: 3221225475

Create time: 14/09/2013 12:25:12 (01:32:39 ago)

Last time status changed: 14/09/2013 12:25:12 (01:32:39 ago)

MAC withdraw messages: sent 0, received 0

Static MAC addresses:

Statistics:

packets: received 1899, sent 2773

bytes: received 121536, sent 177472

DHCPv4 snooping: disabled

IGMP Snooping profile: none

MLD Snooping profile: none

PW: neighbor 7.7.7.7, PW ID 100, state is up ( established )

PW class not set, XC ID 0xc0000004

Encapsulation MPLS, Auto-discovered (BGP), protocol BGP

Source address 4.4.4.4

PW type VPLS, control word disabled, interworking none

Sequencing not set

MPLS Local Remote

------------ ------------------------------ -------------------------

Label 16021 16018

MTU 1500 1500

Control word disabled disabled

PW type VPLS VPLS

VE-ID 4 7

------------ ------------------------------ -------------------------

MIB cpwVcIndex: 3221225476

Create time: 14/09/2013 12:30:07 (01:27:45 ago)

Last time status changed: 14/09/2013 12:30:07 (01:27:45 ago)

MAC withdraw messages: sent 0, received 0

Static MAC addresses:

Statistics:

packets: received 0, sent 2627

bytes: received 0, sent 168128

DHCPv4 snooping: disabled

IGMP Snooping profile: none

MLD Snooping profile: none

VFI Statistics:

drops: illegal VLAN 0, illegal length 0

H-VPLS Summary

H-VPLS provides a solution for VPLS for improved pseudowire scalability. This improvement is achieved by reducing the number of PE devices connected in full mesh topology and thus improves control plane scalability. It reduces the burden on core devices presented by frame replication. However, there are better way to address scalability problems than those defined by LDP-based H-VPLS. Also, H-VPLS does not offer a better solution to efficiently address multicast traffic. BGP-based VPLS with point-to-multipoint LSPs is a good option for service providers.