Chapter 11. BGP for MPLS L2VPN Services
The following topics are covered in this chapter:
L2VPN Services
Virtual Private Wire Service
Virtual Private LAN Service
L2VPN Services
The networking industry has seen development of various access services over the years. This includes IP, ATM, Frame-Relay (FR), Ethernet, and so on. As new innovations happen in the industry, more and more technologies are deployed, and some customers move to those newer technologies. Service providers (SP) still need to serve the old customers but also have to meet the requirements of customers who want to move to newer technologies. For example, customer ABC with 100 sites, using ATM or Frame-Relay connections from the service providers, wants to move Ethernet-based infrastructure. The service provider servicing customer ABC now has to upgrade its infrastructure to support customer ABC, but at the same time maintain the infrastructure to support other customers still using ATM, Frame-Relay, or broadband services.
Multiple access services require multiple core technologies. This adds heavily to the cost of production networks and also adds complexity to manage such network infrastructure. If there was a common infrastructure in the service provider core that could serve almost all access services, that would reduce the cost for the service providers to a great extent.
Over the years, Multiprotocol Label Switching (MPLS) and IP capabilities have evolved not just to provide Layer 3 VPN services but also provide Layer 2 Virtual Private Network (L2VPN) services. L2VPN enables SPs to carry multiple network services over a single converged network using IP/MPLS. In L2VPN, service providers extend a Layer 2 circuit to customers with literally any Layer 2 medium, and the customers can connect their network with the remote sites using the same or a different Layer 2 medium. For example, company ABC, having three sites, might be running Frame-Relay on site 1 but may run ATM on site 2 and Ethernet on site 3 and still maintain connectivity between each of them. The three sites are still getting a Layer 2 termination point from the service provider, but now company ABC does not have to maintain the same infrastructure at all sites to maintain connectivity. This gives more flexibility to the customers but at the same time reduces the cost of the service providers because they maintain a common infrastructure in their core network.
The main benefits of L2VPNs are as follows:
Single infrastructure for both IP and legacy services.
Seemless migration of legacy ATM / Frame-Relay services to IP/MPLS-based core without affecting any existing services.
Incremental provisioning of new services.
Cost saving due to reduced capital or operations expenses achieved through IP/MPLS infrastructure.
Service providers do not participate in routing with customer’s network and save resources on the provider routers.
The L2VPN services can be run across two cores:
MPLS Core
IP Core
The L2VPN services using IP/MPLS cores can be divided into two categories:
VPWS: Wire Service
VPLS: Local-Area Network (LAN) Service
Virtual Private Wire Service (VPWS) provides point-to-point services between two customer sites over the provider core. Virtual Private LAN Service (VPLS) provides multipoint-to-multipoint services between multiple customer sites using a mesh of point-to-point pseudowires over the provider core and a virtual switch to emulate a LAN. VPWS makes use of Any Transport over MPLS (AToM) pseudowires when the provider core is MPLS. VPLS service also uses the MPLS in the service provider core. Layer 2 Tunneling Protocol version 3 (L2TPv3) provides similar capabilities (only point-to-point services) but over an IP Core.
Figure 11-1 shows the various L2VPN models and their Layer 2 infrastructure support hierarchies. The MPLS-based L2VPNs provides point-to-point, point-to-multipoint, and multipoint-to-multipoint connections, whereas L2TPv3 provides only point-to-point connections.
Note
Because there is no involvement for Border Gateway Protocol (BGP)-based services for L2TPv3 pseudowires, this chapter does not cover L2TPv3 concepts. It covers only MPLS-based L2VPN services; that is, VPWS and VPLS.
Terminologies
Let’s take a look at a few terminologies frequently used in context of L2VPNs.
Attachment Circuit (AC): A physical or a virtual circuit connecting the customer edge (CE) to a provider edge (PE). An attachment circuit (AC) may be an ATM virtual circuit identifier (VCI) / virtual path identifier (VPI) or FR data link connection identifier (DLCI), Virtual LAN (VLAN), an Ethernet port, or even an MPLS label switch path (LSP).
Terminating PE (T-PE): A terminating PE is a PE where the endpoint of a pseudowire (PW) is terminated.
Switching PE (S-PE): A switching PE is a one where one pseudowire segment is switched to another pseudowire segment. This is seen usually in case of multisegment pseudowires.
Pseudowires (PW): Pseudowires can be defined as a virtual tunnel between two provider edge routers that connect two attachment circuits and carry customer packet data units (PDUs) over the service provider core. A PW may connect the pseudowire end-services (PWESs), a.k.a. ACs, of the same or a different type. The PWES can be of any of the following types:
Ethernet
Ethernet Virtual Circuits (EVC)
ATM VCI/VPI
802.1Q (VLAN)
High-level Data Link Control (HDLC)
Point-to-Point Protocol (PPP)
Frame-Relay VC
The customer PDU is encapsulated inside the header and is seen as a MPLS or IP packet inside the service provider core. This helps the service providers migrate from a traditional Layer 2 infrastructure, such as ATM or FR, to an IP/MPLS-based core. Figure 11-2 illustrates how the PWs connect different customer sites.
Table 11-1 lists the various PW types as defined by Request for Comments (RFC) 4446. There are some more PW types that are defined by IETF but not listed in Table 11-1.
VC Label: A VC label is used to identify an AToM virtual circuit (VC).
Control Word: The control word is an optional 4-byte field that takes care of address packet sequentiality, small packet size, control bits, and the like. It is used to maintain information provided in the header of various L2 PDUs. The control word has two formats:
Generic: Where first nibble is 0000
Inband Virtual Circuit Connectivity Verification (VCCV): Where first nibble is 0001
The following are the functions of generic control word:
Padding: Pad small size packets
Sequence Number: To detect out of order packets
Carry control bits of the Layer 2 header of the transported protocol
Facilitating fragmentation and reassembly
Aids in load-balancing AToM frames in MPLS core
The inband VCCV is used as payload identifier. The control word is optional for some protocols but mandatory for others.
Virtual Private Wire Service
VPWS provides point-to-point services between two CE devices over the provider MPLS core network. The traffic from the CE devices is sent over the PW A VC label, or the PW label is used to process packets at each PE. Hence, each PE must reserve a PW label (local label) and advertise it to the peer. A tunnel label is then used to forward the PDU from one PE to another PE. Because the peer can be multiple hops away, a targeted Label Distribution Protocol (LDP) session is used for label distribution. The VC label bindings exchanged over this LDP session use the Forward Equivalence Class (FEC) element type 128 via the LDP—downstream unsolicited mode. Only one targeted session is created for multiple VCs between the PEs. If there is already a targeted session between the PEs by another application, that session is used. LDP uses the FEC type 128 to determine that the message is for AToM application. This is described in RFC 4447.
To understand the control plane of VPWS, examine the topology in Figure 11-3. A native service is provided by the PE router toward the CE using an AC. In the core, the P and the PE routers are running IGP and LDP between them for exchanging routing and label information. The two PEs can be discovered by manual configuration or by using the BGP autodiscovery mechanism. A targeted LDP session is used between the PE routers to exchange VC label information and control information.
The following steps give a run down on the sequence of events between the two PE routers for exchanging VC label and control information:
Step 1. Attachment circuit is configured with Peer Address and Virtual Circuit Identifier (VCID).
Step 2. PE1 starts targeted LDP session with PE2 if one does not already exist.
Step 3. PE1 allocates VC label for new circuit and binds to configured VC ID.
Step 4. PE1 sends LDP label Mapping Message containing VC FEC TLV and VC label Type Length Value (TLV).
Step 5. PE2 receives VC FEC TLV and VC label TLV that matches local VCID.
Step 6. PE2 repeats Steps 1 through 5 so that bidirectional label/VCID mappings are established.
Note
The FEC element type used for LDP signaling is 128, whereas FEC element type used with BGP autodiscovery is 129.
Figure 11-4 illustrates the data plane for a VPWS circuit. Notice that customer PDU is followed by an optional field C that represents control word, VC label, and the Tunnel label. At each hop within the service provider core, packets are forwarded using the underlying label switching mechanism.
Interworking
VPWS service allows for establishment of PW across heterogeneous ACs. Each circuit type behaves and functions differently based on the underlying Layer 2 medium. Thus, it becomes difficult to forward traffic across PWs when either side is having a different type of AC. To overcome this problem, the Interworking feature is used. There are two types of interworking mainly supported in L2VPN:
Ethernet Interworking: This mode is also known as bridged mode. In this mode of operation, Ethernet frames are extracted from the AC and sent over the PW. AC on the other end of the PW performs the adaptation of the Ethernet frame to the Layer 2 technology used. In this mode, CE routers can natively bridge Ethernet or can use a bridged encapsulation model such as Bridge Virtual Interface (BVI). This mode provides LAN services and connectivity services.
IP Interworking: This mode is also known as the routed mode. In this mode of operation, the Layer 3 payload is extracted from the Layer 2 payload and sent over the PW. This method is used for providing IP connectivity between sites, regardless of their Layer 2 infrastructures.
Apart from the preceding two interworking methods, IOS XR and NX-OS also supports the VLAN Interworking mode. In this mode of operation, the VLAN ID is included in the payload along with the Layer 2 payload. Without this interworking, the packets on the main interface do not send the VLAN tag over the PW.
Note
Refer to Cisco.com documentation links in the reference section on how interworking functions between different types of ACs on both sides.
Configuration and Verification
The default method for configuring VPWS circuits is manual configuration. In other words, the PWs have to be manually configured between the PE routers. The configuration can be laid out in few simple steps, as follows:
Step 1. Configure IGP. Configure IGP between the P and the PE routers in the service provider network. Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) are recommended, and PE should advertise the LDP-ID as a /32 route.
Step 2. Configure LDP. Configure LDP on the core interfaces using the command mpls ip on both Cisco IOS and NX-OS platforms or enabling the interfaces under mpls ldp configuration mode on IOS XR platform to allocate labels for Interior Gateway Protocol (IGP) learned prefixes. This ensures LSP is formed between the source and the terminating PE router.
Step 3. Configure Attachment Circuit. Configure the AC on both PE routers. When configuring the AC, ensure the same maximum transmission unit (MTU) settings are defined on both sides.
Step 4. Configure Interworking. Enable the relevant interworking mode between both the PE for the PW. This is configured by defining a pseudowire-class. Note that interworking is not required when using like-to-like PWs.
Step 5. Configure xconnect. Configure the xconnect between the PE routers using a unique VCID—that is, the VCID value should have been used on either of the PE routers. The VCID value should be same on both PE routers.
Step 6. Enable Attachment Circuit. After the xconnect is configured, enable the AC by bringing up the customer facing interfaces.
Examine the topology as shown in Figure 11-5. PE1, PE2, and PE3 are forming a VPWS circuit over Ethernet—that is, Ethernet over MPLS (EoMPLS). A PW is formed between PE1 and PE2 and between PE1 and PE3. For simplicity, the AC is the same on both sides—like-to-like.
Note
EoMPLS is a VPWS service for Ethernet attachment circuits. An Ethernet PW is used to carry Ethernet/802.3 PDUs over an MPLS network. This allows the service providers to offer emulated Ethernet services over existing MPLS networks. EoMPLS is a point-to-point service. EoMPLS encapsulation is defined in RFC 4448. The VC setup is performed as described in RFC 3985. Two type of modes are supported in EoMPLS: the raw (VC type 4) and the tagged (VC type 5) mode. The encapsulation performed depends on whether the VLAN tag is service-delimiting or non-service-delimiting. If non-service-delimiting, the tags are passed transparently over the PW as payload. If it’s service-delimiting and tagged mode, the tags can be rewritten, stripped, or left unchanged in tagged mode. If it’s service-delimiting and raw mode, no rewrite or removal of tags is required.
Example 11-1 illustrates the configuration for a EoMPLS circuit (VPWS) between PE1, PE2, and PE3, which are running Cisco IOS, IOS XR, and NX-OS software, respectively. The core facing interfaces on the PE routers and P router P1 are running IGP and LDP.
Example 11-1 VPWS Configuration
PE1 – Cisco IOS
pseudowire-class EOMPLS
encapsulation mpls
interworking ethernet
!
interface Loopback0
ip address 192.168.1.1 255.255.255.255
!
interface GigabitEthernet1/1/2
no ip address
no keepalive
service instance 100 ethernet
encapsulation dot1q 100
rewrite ingress tag pop 1 symmetric
xconnect 192.168.2.2 100 encapsulation mpls pw-class EOMPLS
!
service instance 101 ethernet
encapsulation dot1q 101
rewrite ingress tag pop 1 symmetric
xconnect 192.168.3.3 101 encapsulation mpls pw-class EOMPLS
PE2 – IOS XR
interface Loopback0
ipv4 address 192.168.2.2 255.255.255.255
!
interface GigabitEthernet0/0/0/1
!
interface GigabitEthernet0/0/0/1.2 l2transport
encapsulation dot1q 100
!
l2vpn
pw-class EOMPLS
!
xconnect group test
p2p VPWS
interface GigabitEthernet0/3/0/2.100
neighbor 192.168.1.1 pw-id 100
!
interworking Ethernet
PE3 – NX-OS
feature-set mpls
feature mpls ldp
feature mpls l2vpn
feature evc
!
l2vpn xconnect context EOMPLS
interworking ethernet
member Ethernet3/3 service-instance 101
member pseudowire101
!
interface pseudowire101
neighbor 192.168.1.1 101
encapsulation mpls
!
interface Ethernet3/3
no shutdown
service instance 101 ethernet
encapsulation dot1q 101
no shutdown
Note
In the preceding example, EVC is used on Cisco IOS and NX-OS devices. The Metro Ethernet forum describes EVC as a port-based point-to-point or multipoint-to-multipoint Layer 2 circuit. An EVC is configured using the interface level command service instance instance-id ethernet.
After the configuration is done, all the PE routers establish a targeted LDP session between them. To verify the targeted LDP session, use the command show mpls ldp neighbor. This command displays all the LDP sessions to the adjacent neighbors as well as targeted LDP neighbor sessions to the remote neighbors. Example 11-2 displays the targeted LDP session on all the PE routers.
Example 11-2 Verifying Targeted LDP Session
IOS
PE1# show mpls ldp neighbor
Peer LDP Ident: 192.168.2.2:0; Local LDP Ident 192.168.1.1:0
TCP connection: 192.168.2.2.35456 - 192.168.1.1.646
State: Oper; Msgs sent/rcvd: 99/96; Downstream
Up time: 01:03:14
LDP discovery sources:
Targeted Hello 192.168.1.1 -> 192.168.2.2, active, passive
Addresses bound to peer LDP Ident:
10.122.167.207 192.168.2.2 10.1.24.2
Peer LDP Ident: 192.168.3.3:0; Local LDP Ident 192.168.1.1:0
TCP connection: 192.168.3.3.44119 - 192.168.1.1.646
State: Oper; Msgs sent/rcvd: 42/33; Downstream
Up time: 00:17:18
LDP discovery sources:
Targeted Hello 192.168.1.1 -> 192.168.3.3, active, passive
Addresses bound to peer LDP Ident:
192.168.3.3 10.1.34.3
IOS XR
RP/0/1/CPU0:PE2# show mpls ldp neighbor
Peer LDP Identifier: 192.168.1.1:0
TCP connection: 192.168.1.1:646 - 192.168.2.2:35456
Graceful Restart: No
Session Holdtime: 180 sec
State: Oper; Msgs sent/rcvd: 99/101; Downstream-Unsolicited
Up time: 01:05:11
LDP Discovery Sources:
Targeted Hello (192.168.2.2 -> 192.168.1.1, active)
Addresses bound to this peer:
1.1.1.1 10.1.14.1 13.13.13.1 192.168.1.1
NX-OS
PE3# show mpls ldp neighbor
Peer LDP Ident: 192.168.1.1:0; Local LDP Ident 192.168.3.3:0
TCP connection: 192.168.1.1.646 - 192.168.3.3.44119
State: Oper; Msgs sent/rcvd: 37/47; Downstream
Up time: 00:21:34
LDP discovery sources:
Targeted Hello 192.168.3.3 -> 192.168.1.1, active, passive
Addresses bound to peer LDP Ident:
1.1.1.1 13.13.13.1 192.168.1.1 10.1.14.1
To view the details of the pseudowire connection, use the command show mpls l2transport vc vcid [detail] on Cisco IOS, show l2vpn xconnect detail on IOS XR, and show l2vpn atom vc detail on NX-OS. These commands display the VC status, local and remote VC label information, MTU settings, AC status, packets received and sent, and most importantly, the signaling mechanism being used. Example 11-3 displays the VC information using these commands.
Example 11-3 Verifying VC Information
PE1# show mpls l2transport vc 100 detail
Local interface: Gi1/1/2 up, line protocol up, Eth VLAN 100 up
Interworking type is Ethernet
Destination address: 192.168.2.2, VC ID: 100, VC status: up
Output interface: Gi1/1/0, imposed label stack {23 16000}
Preferred path: not configured
Default path: active
Next hop: 12.12.12.2
Create time: 00:00:43, last status change time: 00:00:34
Last label FSM state change time: 00:00:34
Last peer autosense occurred at: 00:00:34
Signaling protocol: LDP, peer 192.168.2.2:0 up
Targeted Hello: 192.168.1.1(LDP Id) -> 192.168.2.2, LDP is UP
Graceful restart: not configured and not enabled
Non stop routing: not configured and not enabled
Status TLV support (local/remote) : enabled/supported
LDP route watch : enabled
Label/status state machine : established, LruRru
Last local dataplane status rcvd: No fault
Last BFD dataplane status rcvd: Not sent
Last BFD peer monitor status rcvd: No fault
Last local AC circuit status rcvd: No fault
Last local AC circuit status sent: No fault
Last local PW i/f circ status rcvd: No fault
Last local LDP TLV status sent: No fault
Last remote LDP TLV status rcvd: No fault
Last remote LDP ADJ status rcvd: No fault
MPLS VC labels: local 40, remote 16000
Group ID: local 0, remote 67110912
MTU: local 1500, remote 1500
Remote interface description: GigabitEthernet0_3_0_2.100
Sequencing: receive disabled, send disabled
Control Word: Off (configured: autosense)
SSO Descriptor: 192.168.2.2/100, local label: 40
Dataplane:
SSM segment/switch IDs: 24588/12293 (used), PWID: 2
VC statistics:
transit packet totals: receive 0, send 0
transit byte totals: receive 0, send 0
! Output omitted for brevity
RP/0/1/CPU0:PE2# show l2vpn xconnect detail
Group test, XC VPWS, state is up; Interworking Ethernet
AC: GigabitEthernet0/3/0/2.100, state is up
Type VLAN; Num Ranges: 1
VLAN ranges: [100, 100]
MTU 1500; XC ID 0x4000001; interworking Ethernet
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
drops: illegal VLAN 0, illegal length 0
PW: neighbor 192.168.1.1, PW ID 100, state is up ( established )
PW class not set, XC ID 0xff000001
Encapsulation MPLS, protocol LDP
Source address 192.168.2.2
PW type Ethernet, control word disabled, interworking Ethernet
PW backup disable delay 0 sec
Sequencing not set
PW Status TLV in use
MPLS Local Remote
------------ ------------------------------ -----------------------------
Label 16000 40
Group ID 0x4000800 0x0
Interface GigabitEthernet0/3/0/2.100 unknown
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
Outgoing Status (PW Status TLV):
Status code: 0x0 (Up) in Notification message
MIB cpwVcIndex: 4278190081
Create time: 16/03/2016 23:01:25 (00:44:45 ago)
Last time status changed: 16/03/2016 23:37:58 (00:08:11 ago)
Statistics:
packets: received 0, sent 0
bytes: received 0, sent 0
PE3# show l2vpn atom vc detail
pseudowire101 is up, VC status is up PW type: Ethernet
Create time: 00:43:15, last status change time: 00:03:11
Last label FSM state change time: 00:03:11
Destination address: 192.168.1.1 VC ID: 101
Output interface: Ethernet3/2, imposed label stack {39 16}
Preferred path: not configured
Default path: active
Next hop: 10.1.34.4
Member of xconnect service EOMPLS
Associated member EFP-Eth3/3.101 is up, status is up
Interworking type is Like2Like
Signaling protocol: LDP, peer 192.168.1.1:0 up
Targeted Hello: 192.168.3.3(LDP Id) -> 192.168.1.1, LDP is UP
Graceful restart: configured and not enabled
Non stop routing: not configured and not enabled
PWid FEC (128), VC ID: 101
Status TLV support (local/remote) : enabled/supported
LDP route watch : enabled
Label/status state machine : established, LruRru
Local dataplane status received : No fault
BFD dataplane status received : Not sent
BFD peer monitor status received : No fault
Status received from access circuit : No fault
Status sent to access circuit : No fault
Status received from pseudowire i/f : No fault
Status sent to network peer : No fault
Status received from network peer : No fault
Adjacency status of remote peer : No fault
Sequencing: receive disabled, send disabled
Bindings
Parameter Local Remote
------------ ------------------------------ ------------------------------
Label 16 39
Group ID 0 0
Interface
MTU 1500 1500
Control word on (configured: autosense) on
PW type Ethernet Ethernet
VCCV CV type 0x02 0x02
LSPV [2] LSPV [2]
VCCV CC type 0x06 0x07
RA [2], TTL [3] CW [1], RA [2], TTL [3]
Status TLV enabled supported
Rx Counters
0 input transit packets, 0 bytes
0 drops, 0 seq err
Tx Counters
0 output transit packets, 0 bytes
0 drops
Note
Illustration on all the various VPWS circuit types is outside the scope of this book. Refer to the Cisco documentation as mentioned in reference section for more details. Also, refer to the Cisco Press book Layer 2 VPN Architectures.
VPWS BGP Signaling
VPWS services can also be set up using BGP signaling. RFC 6624 describes the autodiscovery and signaling mechanism for L2VPNs using BGP. Although the BGP autodiscovery mechanism for VPWS services is limited to IOS XR platforms, BGP provides signaling capability for VPWS circuits. BGP uses an NLRI update message with address-family identifier (AFI) 25 and sub-address-family identifier (SAFI) 65 for both VPWS and VPLS.
Examine the BGP network layer reachability information (NLRI) for VPWS, as shown in Figure 11-6. This new NLRI carries the individual VPWS information. The route distinguisher (RD), CE_ID, and CE Block Offset (Label Block Offset) are used to uniquely determine a VPWS NLRI. The CE_ID is nothing but the Site Id.
A new sub-TLV is carried on the NLRI and represents the state of the circuit, as shown in Figure 11-7. The bits correspond to each piece of CE information that is carried in the NLRI. Circuit status is represented by checking both the attachment circuit state and LSP state.
A L2VPN extended community parameter is sent along with the NLRI with L2VPN information. The Encap Type is used to specify the type of attachment circuit (ATM, FR, Ethernet, and so on). Details of different assignments are described in draft-kompella-ppvpn-l2vpn-03. In addition to CE ID and label block information, BGP also signals control flags, as shown in Figure 11-8. The control flags indicate whether the control word is included in the encapsulation and if the sequence number is present for the packets being sent.
Note
If a control word mismatch occurs, the PW remains in down state.
VPWS service involves configuration where each PE defines the association between the local and remote CE ID via configuration. Along with this, the CE range, route target (RT), and RD information need to be specified in the configuration. This triggers the NLRI exchanged between the BGP peers, and L2VPN is informed about the remote circuit status and label binding information. This is used by L2VPN to set up the circuits.
Note
At the time of this writing, both IOS and NX-OS do not have support for BGP-based signaling and autodiscovery for VPWS circuits. Only IOS XR has support for BGP signaling and autodiscovery.
Configuration
When a VPWS xconnect is configured with BGP signaling and autodiscovery enabled, BGP distributes the NLRI with the appropriate BGP next-hop and CE_ID. Under the l2vpn configuration mode, an xconnect group is configured using the command xconnect group group-name. Under the xconnect group, both the autodiscovery mechanism and the signaling protocol are defined. It is important to remember that the signaling protocol can be either LDP or BGP. The RD can be set to auto mode but can also be manually assigned. The other important configuration under the xconnect group required is the vpn-id and the ce-id.
For both VPWS and VPLS, there is a new L2VPN address-family configuration introduced that is used for BGP signaling and autodiscovery purposes on IOS XR, named address-family l2vpn vpls-vpws. Example 11-4 displays the configuration for setting up the VPWS circuit on IOS XR with BGP signaling and autodiscovery.
Example 11-4 BGP Signaling and Autodiscovery on IOS XR for VPWS
! Configuring L2VPN Section
RP/0/1/CPU0:PE2(config)# l2vpn
RP/0/1/CPU0:PE2(config-l2vpn)# xconnect group VPWS
RP/0/1/CPU0:PE2(config-l2vpn-xc)# mp2mp EOMPLS
RP/0/1/CPU0:PE2(config-l2vpn-xc-mp2mp)# vpn-id 100
RP/0/1/CPU0:PE2(config-l2vpn-xc-mp2mp)# l2-encapsulation vlan
RP/0/1/CPU0:PE2(config-l2vpn-xc-mp2mp)# autodiscovery bgp
RP/0/1/CPU0:PE2(config-l2vpn-xc-mp2mp-ad)# rd auto
RP/0/1/CPU0:PE2(config-l2vpn-xc-mp2mp-ad)# route-target 192.168.2.2:100
RP/0/1/CPU0:PE2(config-l2vpn-xc-mp2mp-ad)# signaling-protocol bgp
RP/0/1/CPU0:PE2(config-l2vpn-xc-mp2mp-ad-sig)# ce-id 100
RP/0/1/CPU0:PE2(config-l2vpn-xc-mp2mp-ad-sig-ce)# int g0/3/0/2.100 remote-ce-id 1
RP/0/1/CPU0:PE2(config-l2vpn-xc-mp2mp-ad-sig-ce)# commit
! Configuring BGP Section
RP/0/0/CPU0:PE2(config)# router bgp 100
RP/0/0/CPU0:PE2(config-bgp)# address-family l2vpn vpls-vpws
RP/0/0/CPU0:PE2(config-bgp-af)# exit
RP/0/0/CPU0:PE2(config-bgp)# neighbor 192.168.3.3
RP/0/0/CPU0:PE2(config-bgp-nbr)# remote-as 100
RP/0/0/CPU0:PE2(config-bgp-nbr)# update-source loopback0
RP/0/0/CPU0:PE2(config-bgp-nbr)# address-family l2vpn vpls-vpws
RP/0/0/CPU0:PE2(config-bgp-nbr-af)# commit
Note
Verification and troubleshooting steps for VPWS and VPLS are same and are covered later in the chapter under the VPLS section.
Virtual Private LAN Service
VPWS is used for connecting two remote locations of the same or different attachment circuit type. For example, EoMPLS provides point-to-point Ethernet services by connecting two LAN environments. But when an organization’s Layer 2 domains are expanded across multiple sites and geographical boundaries, creating multiple point-to-point VPWS connections can increase complexity for the network and requires more resources on the PE routers.
A multipoint service is required to maintain the communication between the distributed LAN infrastructure. VPLS provides multipoint services for LAN. The primary motivation behind VPLS is to provide connectivity between geographically dispersed sites across metropolitan-area networks (MAN) and wide-area networks (WAN) to a shared LAN segment, which is virtualized over a service provider core versus point-to-point circuits in VPWS. Figure 11-9 displays a VPLS deployment. Notice that in this topology there are three PE routers, each of which is connected to the different sites of the same customer. The service provider core network runs IP and MPLS services providing label switching paths between PE routers.
In VPLS, the sites belong to the same broadcast domain, are connected across a service provider MPLS network, and can transmit unicast, broadcast, and multicast traffic to the desired customer locations. Because of this capability, VPLS circuits require media access control (MAC) address learning/aging on a per pseudowire basis. Also, it requires packet replication for multicast/broadcast traffic and for flooding of unknown unicast frames. This is done at the platform (hardware) level on most of the Cisco platforms where hardware forwarding is supported to allow greater scalability (more customer circuits) on the PE router.
The customer packet forwarding decision is made by looking at the Layer 2 Virtual Forwarding Instance (VFI) of a particular VPLS domain. An Ethernet or Layer 2 frame received from the customer network can be forwarded to one or more local interfaces and/or emulated VCs in the VPLS domain. On receiving the frame, the source MAC address is learned just like in traditional switching. Based on the populated MAC entries, the PE router switches those frames to the appropriate LSP to be transmitted to remote PE routers. If the destination MAC address is not found in the MAC table, the frame is then replicated to all the remote PE routers by the originating PE router.
Note
To prevent forwarding loops in a full-mesh VPLS topology, enable Layer 2 split-horizon. It is a loop prevention mechanism that prevents packets received on one PW from being forwarded to another PW.
Configuration
Configuring VPLS is similar to configuring VPWS with a difference that in VPLS, the circuits are point-to-multipoint. Thus each router should be configured with the neighboring PE router in that VPLS domain. VPLS can be set up using various methods:
Manual configuration with LDP signaling
BGP Autodiscovery with LDP signaling
BGP Autodiscovery with BGP signaling
The following steps can be used to configure VPLS using the first method.
Step 1. On the PE router, configure Layer 2 interfaces that connect to the CE. These interfaces can be configured either as access ports, trunk ports, Q-in-Q, or using EVCs.
Step 2. Based on platform requirements, configure VLANs or bridge domains on the PE router.
Step 3. Configure MPLS in Service Provider Core. Enable MPLS LDP on core interfaces on both the PE and the P routers. This allows you to build an LSP between the PE routers.
Step 4. Configure VFI. Configure L2VPN VFI context for VPLS domains. Under the VFI contexts, configure the vpn-id and other PE neighbor information within the same VPLS domain.
Step 5. Associate AC with the VFI.
Step 6. Enable AC. After the xconnect is configured, enable the AC by bringing up the customer facing interfaces.
For illustrating VPLS configuration, examine the same topology as shown in Figure 11-5. PE routers PE1, PE2, and PE3 are all part of same VPLS domain connecting three sites for the same customer. Example 11-5 illustrates the configuration for VPLS using manual configuration and LDP signaling. Notice that on all three PE routers, the other two PE routers are configured as the peer routers. This is required in case of a manual configuration method.
Example 11-5 VPLS Configuration
Configuration PE1 – Cisco IOS
l2 vfi VPLS-VFI manual
vpn id 100
bridge-domain 100
neighbor 192.168.3.3 encapsulation mpls
neighbor 192.168.2.2 encapsulation mpls
!
interface GigabitEthernet1/1/2
no ip address
negotiation auto
service instance 100 ethernet
encapsulation dot1q 100
rewrite ingress tag pop 1 symmetric
bridge-domain 100
Configuration PE2 – IOS XR
l2vpn
bridge group BD-GRP
bridge-domain 100
interface GigabitEthernet0/3/0/2.100
!
vfi VPLS-VFI
neighbor 192.168.1.1 pw-id 100
!
neighbor 192.168.3.3 pw-id 100
!
interface GigabitEthernet0/3/0/2.100 l2transport
dot1q vlan 100
Configuration PE3 – NX-OS
l2vpn vfi context VPLS-VFI
vpn id 100
member pseudowire1
member pseudowire2
bridge-domain 100
member vfi VPLS-VFI
member Ethernet3/3 service instance 100
!
interface pseudowire1
neighbor 192.168.1.1 100
encapsulation mpls
!
interface pseudowire2
neighbor 192.168.2.2 100
encapsulation mpls
!
interface Ethernet3/3
no shutdown
service instance 100 ethernet
encapsulation dot1q 100
no shutdown
Verification
The very first step in verification and troubleshooting process for VPLS is to verify three primary things:
PE to PE LSP is complete.
AC is up.
VFI status is up.
The PE to PE LSP is verified using the command ping mpls ipv4 ip-address subnet-mask. Ensure that Layer 2 interfaces facing the customer equipment or CE router are up. The VFI status is verified using the command show l2vpn vfi name vfi-name on Cisco IOS and NX-OS and command show l2vpn bridge-domain summary on IOS XR. Example 11-6 displays the output of the command show l2vpn vfi name and show l2vpn bridge-domain summary. The show l2vpn vfi name vfi-name command displays the VFI status, Signaling protocol, VPN ID, and the PW status.
Example 11-6 Verifying VFI Status
IOS
PE1# show l2vpn vfi name VPLS-VFI
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
VFI name: VPLS-VFI, state: up, type: multipoint, signaling: LDP
VPN ID: 100
Bridge-Domain 100 attachment circuits:
Pseudo-port interface: pseudowire100001
Interface Peer Address VC ID S
pseudowire100003 192.168.2.2 100 Y
pseudowire100002 192.168.3.3 100 Y
RP/0/1/CPU0:PE2# show l2vpn bridge-domain summary
Number of groups: 1, bridge-domains: 1, Up: 1, Shutdown: 0, Partially-
programmed: 0
Default: 1, pbb-edge: 0, pbb-core: 0
Number of ACs: 1 Up: 1, Down: 0, Partially-programmed: 0
Number of PWs: 2 Up: 2, Down: 0, Standby: 0, Partially-programmed: 0
NX-OS
PE3# show l2vpn vfi name VPLS-VFI
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
VFI name: VPLS-VFI, state: up, type: multipoint, signaling: LDP
VPN ID: 100
Bridge-Domain 100 attachment circuits:
Pseudo-port interface: vfi100001
Interface Peer Address VC ID S
pseudowire2 192.168.2.2 100 Y
pseudowire1 192.168.1.1 100 Y
On IOS devices, the command show xconnect all also displays the status of the PWs and the VFI. Example 11-7 displays the output of the command show xconnect all on PE1.
Example 11-7 show xconnect all Command Output
PE1# show xconnect all
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+-----------------------------+--+--------------------------------- +--
UP pri vfi VPLS-VFI UP mpls 192.168.2.2:100 UP
UP pri vfi VPLSA UP mpls 192.168.3.3:100 UP
UP pri bd 100 UP vfi VPLSA UP
Similar to VPWS, for VPLS, multiple PWs are formed with multiple PEs with same VPN ID. Thus, the VPLS connection with each PE is verified using the command show mpls l2transport vc [destination ip-address] vcid vc-id [detail] on Cisco IOS, the command show l2vpn bridge-domain [neighbor ip-address] [pw-id vc-id] [detail] on IOS XR, and the command show l2vpn atom vc [destination ip-address] [vcid vc-id] [detail] on NX-OS. Example 11-8 displays the output of the commands to verify the VPLS PWs.
Example 11-8 Verfying VPLS PWs
IOS
PE1# show mpls l2transport vc destination 192.168.2.2 vcid 100 detail
Local interface: VFI VPLS-VFI vfi up
Interworking type is Ethernet
Destination address: 192.168.2.2, VC ID: 100, VC status: up
Output interface: Gi1/1/0, imposed label stack {23 16000}
Preferred path: not configured
Default path: active
Next hop: 12.12.12.2
Create time: 01:23:36, last status change time: 01:12:09
Last label FSM state change time: 01:12:11
Last peer autosense occurred at: 01:12:11
Signaling protocol: LDP, peer 192.168.2.2:0 up
Targeted Hello: 192.168.1.1(LDP Id) -> 192.168.2.2, LDP is UP
Graceful restart: not configured and not enabled
Non stop routing: not configured and not enabled
Status TLV support (local/remote) : enabled/supported
LDP route watch : enabled
Label/status state machine : established, LruRru
Last local dataplane status rcvd: No fault
Last BFD dataplane status rcvd: Not sent
Last BFD peer monitor status rcvd: No fault
Last local AC circuit status rcvd: No fault
Last local AC circuit status sent: No fault
Last local PW i/f circ status rcvd: No fault
Last local LDP TLV status sent: No fault
Last remote LDP TLV status rcvd: No fault
Last remote LDP ADJ status rcvd: No fault
MPLS VC labels: local 35, remote 16000
Group ID: local 0, remote 0
MTU: local 1500, remote 1500
Remote interface description: VPLS-VFI
Sequencing: receive disabled, send disabled
Control Word: Off (configured: autosense)
SSO Descriptor: 192.168.2.2/100, local label: 35
Dataplane:
SSM segment/switch IDs: 16391/8194 (used), PWID: 2
VC statistics:
transit packet totals: receive 7, send 213
transit byte totals: receive 664, send 17736
transit packet drops: receive 4, seq error 0, send 0
IOS XR
RP/0/1/CPU0:PE2# show l2vpn bridge-domain neighbor 192.168.1.1 pw-id 100 detail
Legend: pp = Partially Programmed.
Bridge group: BD-GRP, bridge-domain: 100, id: 0, state: up, ShgId: 0, MSTi: 0
! Output omitted for brevity
Create time: 26/03/2016 21:51:28 (01:38:02 ago)
No status change since creation
ACs: 1 (1 up), VFIs: 1, PWs: 1 (1 up), PBBs: 0 (0 up)
List of Access PWs:
List of VFIs:
VFI VPLS-VFI (up)
PW: neighbor 192.168.1.1, PW ID 100, state is up ( established )
PW class not set, XC ID 0xff000001
Encapsulation MPLS, protocol LDP
Source address 192.168.2.2
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 16000 35
Group ID 0x0 0x0
Interface VPLS-VFI unknown
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: 4278190081
Create time: 26/03/2016 21:51:28 (01:38:02 ago)
Last time status changed: 26/03/2016 21:57:17 (01:32:13 ago)
MAC withdraw message: send 0 receive 0
Static MAC addresses:
Statistics:
packets: received 328, sent 850
bytes: received 21262, sent 73198
DHCPv4 snooping: disabled
IGMP Snooping profile: none
VFI Statistics:
drops: illegal VLAN 0, illegal length 0
NX-OS
PE3# show l2vpn atom vc destination 192.168.1.1 vcid 100 detail
pseudowire1 is up, VC status is up PW type: Ethernet
Create time: 01:46:28, last status change time: 01:41:40
Last label FSM state change time: 01:42:41
Destination address: 192.168.1.1 VC ID: 100
Output interface: Ethernet3/2, imposed label stack {16 16}
Preferred path: not configured
Default path: active
Next hop: 10.1.34.4
Member of vfi service VPLS-VFI
Bridge-Domain id: 100
Signaling protocol: LDP, peer 192.168.1.1:0 up
Targeted Hello: 192.168.3.3(LDP Id) -> 192.168.1.1, LDP is UP
Graceful restart: configured and not enabled
Non stop routing: not configured and not enabled
PWid FEC (128), VC ID: 100
Status TLV support (local/remote) : enabled/supported
LDP route watch : enabled
Label/status state machine : established, LruRru
Local dataplane status received : No fault
BFD dataplane status received : Not sent
BFD peer monitor status received : No fault
Status received from access circuit : No fault
Status sent to access circuit : No fault
Status received from pseudowire i/f : No fault
Status sent to network peer : No fault
Status received from network peer : No fault
Adjacency status of remote peer : No fault
Sequencing: receive disabled, send disabled
Bindings
Parameter Local Remote
------------ ------------------------------ ------------------------------
Label 16 16
Group ID 0 0
Interface
MTU 1500 1500
Control word on (configured: autosense) on
PW type Ethernet Ethernet
VCCV CV type 0x02 0x02
LSPV [2] LSPV [2]
VCCV CC type 0x06 0x06
RA [2], TTL [3] RA [2], TTL [3]
Status TLV enabled supported
Rx Counters
322 input transit packets, 20608 bytes
0 drops, 0 seq err
Tx Counters
304 output transit packets, 28576 bytes
0 drops
VPLS Autodiscovery Using BGP
Conventional VPLS implementation requires manual configuration of each neighbor remote PE router in the VPLS domain. When a new PE is added or removed from the VPLS domain, manual configuration changes are required on each PE router, which is part of the same VPLS domain. In a large service provider network, where there could be hundreds or thousands of customers availing VPLS services, manual configuration adds to a lot of operational cost and also increases the chance of misconfigurations.
Defined in RFC 4761, VPLS autodiscovery provides a mechanism to automatically discover neighbors in a VPLS domain, eliminating the need to manually provision a VPLS neighbor. This helps in automatically updating the VPLS domain whenever a neighbor is added or removed. To perform autodiscovery of VPLS neighbors in a domain, BGP sends the NLRI as an update, as shown in Figure 11-10.
After a PE is configured as part of a particular VPLS domain, the information needed to set up connection with remote PEs in the same VPLS domain is distributed through the discovery process. After the discovery process is complete, each PE forms a full mesh with other neighbors in the VPLS domain. The signaling for VPLS, by default, is taken care of by LDP. RFC 4762 defines the LDP-based signaling mechanism for VPLS.
VPLS autodiscovery can also be achieved using RADIUS. In this method, each PE device is connected to one or more RADIUS servers. The RADIUS server keeps track of all PE requests per VPN. The RADIUS server then sends the list of PEs to the PE requesting authentication. The PE then sets the pseudowires using the information.
One major difference between VPLS autodiscovery and manual configuration is that in this method, FEC 129 is used. FEC 129 is also known as Generalized FEC. FEC 128 is used when using VPLS with manual configuration. Under FEC 128, both endpoints use a 32-bit identifier (PW ID) and should be same in order for PW to establish. But with FEC 129, each endpoint has its own distinct identifier. In other words, the generalized FEC 129 signaling may not be compatible with those endpoint identifiers provisioned with 32-bit PW ID values. Unlike FEC 128, the values of the PW ID with FEC 129 do not have to match on both the local and remote nodes. Figure 11-11 displays the FEC 129 element structure.
Under the FEC 129 structure, the three main elements are the following:
Attachment Group Identifier (AGI): The identifier of the VPLS domain—VPLS-ID.
Source Attachment Individual Identifier (SAII): The identifier of the local endpoint. The L2VPN Router ID of the local PE.
Target Attachment Individual Identifier (TAII): The identifier of the remote endpoint. The L2VPN Router ID of the remote PE.
Other important feature that is essential for the BGP autodiscovery mechanism is Flexible Target Address. Targeted LDP session address is based on the next-hop received from BGP. This may be different from the LDP router-id on the remote end. Flexible Target Address functionality allows the LDP targeted hello accept-list to be modified by peer when the BGP NLRI is received.
To configure BGP VPLS autodiscovery, the BGP L2VPN address-family is used. Example 11-9 illustrates the configuration of BGP VPLS autodiscovery with LDP signaling. For enabling BGP autodiscovery, the autodiscovery bgp command is used in all the platforms, which is defined under the l2vpn context. In Example 11-9, on both IOS and IOS XR, additional configuration is also done, such as vpls-id, rd, route-target. These configurations are optional and are not required to be configured when establishing VPLS PWs using BGP autodiscovery and LDP signaling mechanism.
Example 11-9 VPLS BGP Autodiscovery Configuration
PE1 Configuration – Cisco IOS
l2vpn
router-id 192.168.1.1
l2vpn vfi context VPLS-VFI
vpn id 100
autodiscovery bgp signaling ldp
vpls-id 100:100
rd 100:100
route-target export 100:100
route-target import 100:100
!
router bgp 100
bgp router-id 192.168.1.1
neighbor 192.168.2.2 remote-as 100
neighbor 192.168.2.2 update-source Loopback0
neighbor 192.168.3.3 remote-as 100
neighbor 192.168.3.3 update-source Loopback0
address-family l2vpn vpls
neighbor 192.168.2.2 activate
neighbor 192.168.2.2 send-community extended
neighbor 192.168.2.2 prefix-length-size 2
neighbor 192.168.3.3 activate
neighbor 192.168.3.3 send-community extended
neighbor 192.168.3.3 prefix-length-size 2
PE2 Configuration – IOS XR
l2vpn
router-id 192.168.2.2
bridge group BD-GRP
bridge-domain 100
interface GigabitEthernet0/3/0/2.100
!
vfi VPLS-VFI
vpn-id 100
autodiscovery bgp
rd auto
route-target 100:100
signaling-protocol ldp
!
router bgp 100
bgp router-id 192.168.2.2
address-family l2vpn vpls-vpws
!
neighbor 192.168.1.1
remote-as 100
update-source Loopback0
address-family l2vpn vpls-vpws
Signalling bgp disable
!
!
neighbor 192.168.3.3
remote-as 100
update-source Loopback0
address-family l2vpn vpls-vpws
Signalling bgp disable
PE3 Configuration – NX-OS
feature mpls l2vpn
l2vpn
router-id 192.168.3.3
!
l2vpn vfi context VPLS-VFI
vpn id 100
autodiscovery bgp signaling ldp
!
bridge-domain 100
member vfi VPLS-VFI
!
router bgp 100
router-id 192.168.3.3
address-family l2vpn vpls
neighbor 192.168.1.1
remote-as 100
update-source loopback0
address-family l2vpn vpls
send-community both
neighbor 192.168.2.2
remote-as 100
update-source loopback0
address-family l2vpn vpls
send-community both
Note
IOS XR supports configuration to support for automatic assignment of RD using the command rd auto. This command option is not available in other platforms, but RD is automatically assigned by default on all the other platforms.
One important thing to notice in Example 11-9 is that under the Cisco IOS configuration on router PE1, there is an additional neighbor configuration command neighbor neighbor-ip prefix-length-size [1-2]. This command is required for interoperability between Cisco IOS and IOS XR or Cisco IOS and NX-OS. The reason is that the IOS software encodes the NLRI length in the first byte in bits format in the BGP Update message. However, the Cisco IOS XR Software interprets the NLRI length in 2 bytes. Therefore, when the BGP neighbor with VPLS address-family is configured between the IOS and the IOS XR or NX-OS, NLRI mismatch can happen, leading to flapping between neighbors. To avoid this conflict, IOS supports the prefix-length-size 2 command that needs to be enabled for IOS to work with IOS XR. Example 11-10 displays the output of the BGP notification message received when the IOS router tries forming a neighbor relationship with the IOS XR or NX-OS device under l2vpn vpls address-family. Notice that the Cisco IOS router (PE1) receives a notification from the peer 192.168.2.2 that it received an illegal network, which is of 1 byte.
Example 11-10 Cisco IOS Interoperability Error Message
09:41:01.872: %BGP-5-ADJCHANGE: neighbor 192.168.2.2 Up
09:41:01.880: %BGP-3-NOTIFICATION: received from neighbor 192.168.2.2 3/10
(illegal network) 1 bytes 60
09:41:01.880: %BGP-5-NBR_RESET: Neighbor 192.168.2.2 reset
(BGP Notification received)
09:41:01.880: %BGP-5-ADJCHANGE: neighbor 192.168.2.2 Down
BGP Notification received
09:41:01.880: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.2.2 L2VPN Vpls
topology base removed from session BGP Notification received
The BGP neighbors established under the L2VPN VPLS address-family is viewed using the command show bgp l2vpn vpls summary. Example 11-11 displays the established BGP neighbors and the prefixes received from those neighbors.
Example 11-11 Autodiscovered VPLS Neighbors and Prefixes
IOS
PE1# show bgp l2vpn vpls all summary
! Output omitted for brevity
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.2.2 4 100 70 78 17 0 0 01:06:57 1
192.168.3.3 4 100 101 109 17 0 0 01:33:30 1
PE1# show bgp l2vpn vpls all
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100
*> 100:100:192.168.1.1/96
0.0.0.0 32768 ?
*>i 100:100:192.168.3.3/96
192.168.3.3 100 0 i
Route Distinguisher: 192.168.2.2:32768
*>i 192.168.2.2:32768:192.168.2.2/96
192.168.2.2 100 0 i
IOS XR
RP/0/1/CPU0:PE2# show bgp l2vpn vpls summary
! Output omitted for brevity
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
192.168.1.1 0 100 753 626 14 0 0 01:14:19 1
192.168.3.3 0 100 362 341 14 0 0 01:40:52 1
RP/0/1/CPU0:PE2# show bgp l2vpn vpls
! Output omitted for brevity
Network Next Hop Rcvd Label Local Label
Route Distinguisher: 100:100
*>i192.168.1.1/32 192.168.1.1 nolabel nolabel
*>i192.168.3.3/32 192.168.3.3 nolabel nolabel
Route Distinguisher: 192.168.2.2:32768 (default for vrf BD-GRP:100)
*>i192.168.1.1/32 192.168.1.1 nolabel nolabel
*> 192.168.2.2/32 0.0.0.0 nolabel nolabel
*>i192.168.3.3/32 192.168.3.3 nolabel nolabel
Processed 5 prefixes, 5 paths
NX-OS
PE3# show bgp l2vpn vpls summary
! Output omitted for brevity
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.1 4 100 122 112 14 0 0 01:45:06 1
192.168.2.2 4 100 109 112 14 0 0 01:45:07 1
PE3# show bgp l2vpn vpls
! Output omitted for brevity
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 BGP-AD (VFI VPLS-VFI)
*>i192.168.1.1/32 192.168.1.1 0 100 0 ?
*>i192.168.2.2/32 192.168.2.2 100 0 i
*>l192.168.3.3/32 0.0.0.0 100 32768 i
Route Distinguisher: 192.168.2.2:32768 BGP-AD
*>i192.168.2.2/32 192.168.2.2 100 0 i
After the BGP peering is established under the L2VPN VPLS address-family, the VPLS peers are discovered and verified on each PE router under the respective VFI using the command show l2vpn vfi name vfi-name on Cisco IOS and NX-OS and the command show l2vpn discovery bridge-domain on IOS XR. Example 11-12 examines the output of these commands. Notice the output in Example 11-12, that on IOS and NX-OS, dynamic PW interfaces are created for each VPLS peer in that domain. This is done automatically by the L2VPN process.
Example 11-12 Autodiscovered VPLS Peers
IOS
PE1# show l2vpn vfi name VPLS-VFI
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
VFI name: VPLS-VFI, state: up, type: multipoint, signaling: LDP
VPN ID: 100, VPLS-ID: 100:100
RD: 100:100, RT: 100:100, 100:100
Bridge-Domain 100 attachment circuits:
Pseudo-port interface: pseudowire100007
Interface Peer Address VC ID Discovered Router ID S
pseudowire100011 192.168.2.2 100 192.168.2.2 Y
pseudowire100009 192.168.3.3 100 192.168.3.3 Y
IOS XR
RP/0/1/CPU0:PE2# show l2vpn discovery bridge-domain
Service Type: VPLS, Connected
List of VPNs (1 VPNs):
Bridge group: BD-GRP, bridge-domain: 100, id: 0, signaling protocol: LDP
VPLS-ID: (auto) 100:100
Local L2 router id: 192.168.2.2
List of Remote NLRI (2 NLRIs):
Local Addr Remote Addr Remote L2 RID Time Created
--------------- --------------- --------------- -------------------
192.168.2.2 192.168.1.1 192.168.1.1 03/30/2016 08:42:58
192.168.2.2 192.168.3.3 192.168.3.3 03/30/2016 08:22:51
NX-OS
PE3# show l2vpn vfi name VPLS-VFI
Legend: RT=Route-target, S=Split-horizon, Y=Yes, N=No
VFI name: VPLS-VFI, state: up, type: multipoint, signaling: LDP
VPN ID: 100, VPLS-ID: 100:100
RD: 100:100, RT: 100:100
Bridge-Domain 100 attachment circuits:
Pseudo-port interface: vfi100003
Interface Peer Address VC ID Discovered Router ID S
pseudowire100016 192.168.2.2 100 192.168.2.2 Y
pseudowire100015 192.168.1.1 100 192.168.1.1 Y
After the VPLS peers are discovered in the VPLS domain, the allocated VC labels and the PW status is viewed using the command show l2vpn service vfi name vfi-name [detail] on both Cisco IOS and NX-OS and the commands show l2vpn bridge-domain autodiscovery bgp [detail] and show l2vpn bridge-domain bd-name name [detail] on IOS XR. Example 11-13 displays the output of the command show l2vpn service vfi name and also the command show l2vpn bridge-domain autodiscovery bgp. Notice that the command show l2vpn service vfi name vfi-name not only displays the label information but also the status of the PW interface and the xconnect status.
IOS
PE1# show l2vpn service vfi name VPLS-VFI detail
Legend: St=State XC St=State in the L2VPN Service Prio=Priority
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
m=manually selected
Interface Group Encapsulation Prio St XC St
--------- ----- ------------- ---- -- -----
VPLS name: VPLS-VFI, State: UP
pw100004 VPLS-VFI(VFI) 0 UP UP
pw100006 core_pw 192.168.2.2:100(MPLS) 0 UP UP
Local VC label 29
Remote VC label 16013
pw100005 core_pw 192.168.3.3:100(MPLS) 0 UP UP
Local VC label 28
Remote VC label 22
IOS XR
RP/0/1/CPU0:PE2# show l2vpn bridge-domain autodiscovery bgp detail
Legend: pp = Partially Programmed.
Bridge group: BD-GRP, bridge-domain: 100, 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 down: 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
Bridge MTU: 1500
MIB cvplsConfigIndex: 1
Filter MAC addresses:
Create time: 30/03/2016 17:27:47 (11:40:36 ago)
No status change since creation
ACs: 1 (1 up), VFIs: 1, PWs: 2 (2 up), PBBs: 0 (0 up)
List of VFIs:
VFI VPLS-VFI (up)
VPN-ID: 100, Auto Discovery: BGP, state is Provisioned (Service Connected)
Route Distinguisher: (auto) 192.168.2.2:32768
Import Route Targets:
100:100
Export Route Targets:
100:100
Signaling protocol: LDP
AS Number: 100
VPLS-ID: (auto) 100:100
L2VPN Router ID: 192.168.2.2
PW: neighbor 192.168.1.1, PW ID 100:100, state is up ( established )
PW class not set, XC ID 0xff000001
Encapsulation MPLS, Auto-discovered (BGP), protocol LDP
Source address 192.168.2.2
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 16013 29
BGP Peer ID 192.168.2.2 192.168.1.1
LDP ID 192.168.2.2 192.168.1.1
AII 192.168.2.2 192.168.1.1
AGI 100:100 100:100
Group ID 0x0 0x0
Interface VPLS-VFI unknown
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: 4278190081
Create time: 30/03/2016 17:34:10 (11:34:13 ago)
Last time status changed: 30/03/2016 23:34:22 (05:34:01 ago)
MAC withdraw message: send 0 receive 0
Static MAC addresses:
Statistics:
packets: received 0, sent 9996
bytes: received 0, sent 859656
DHCPv4 snooping: disabled
IGMP Snooping profile: none
NX-OS
! Output omitted for brevity
PE3# show l2vpn service vfi name VPLS-VFI detail
Legend: St=State XC St=State in the L2VPN Service Prio=Priority
UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
m=manually selected
Interface Group Encapsulation Prio St XC St
--------- ----- ------------- ---- -- -----
VPLS name: VPLS-VFI, State: UP
vfi100001 VPLS-VFI(VFI) 0 UP UP
pw100002 core_pw 192.168.2.2:100(MPLS) 0 UP UP
Local VC label 24
Remote VC label 16014
port-profile:
pw100001 core_pw 192.168.1.1:100(MPLS) 0 UP UP
Local VC label 22
Remote VC label 28
port-profile:
The following steps should be used when troubleshooting BGP VPLS autodiscovery issues:
Step 1. BGP autodiscovery. Ensure that BGP autodiscovery is enabled on all the PEs in the VPLS domain.
Step 2. VPN ID. Verify that the VPN ID (also referred to as VPLS-ID) is matching on both the local and remote PE routers. BGP protocol exchanges the VPLS-ID information as an extended community with other PEs. If VPLS-ID is not matching on one of the PEs, then VPLS autodiscovery won’t happen for that PE.
Step 3. Route target. The BGP advertises and imports the associated VPLS instance information using BGP route-target ext community. If the PE is not configured with the correct import or export communities, then BGP autodiscovery may not work.
Step 4. IOS and other OSs interoperability. Ensure that the prefix-length-size is set to 2 when the remote PE router is a non-IOS router.
Autodiscovery
Signaling
Signaling by default is handled by LDP, when using either manual configuration method or the BGP VPLS autodiscovery method. But BGP can also be used for signaling purposes, which involves setting up and tearing down of PWs. The BGP signaling mechanism for VPLS is defined in RFC 4761. When using BGP for signaling, BGP sends the NLRI as an update to the remote peer for updating the label information, as shown in Figure 11-12.
VE ID: Uniquely identify the VPLS Edge device (VE). This is typically configured by the network administrator.
Label Block (LB): A label block is a set of de-multiplexor labels used to reach a given VE ID. The label block for a given VE ID is given next. There is one-to-one correspondence between the remote system and local system; that is, (VBO+n) corresponds to (LB + n).
Label block for local system: LB = LB + VBS – 1
Label block for remote system: VBO = VBO + VBS – 1
Along with this information, L2VPN information is carried in the L2VPN Extended Community attribute, as shown in Figure 11-13. Included in the extended community are control word and sequencing information, which is carried over in the control flag field.
BGP signaling carries label blocks for a set of VPLS edge devices. The logic employed by the edge device is shown in Example 11-14. Assume that the VE_ID 100 and 101 are used for the two edge devices PE1 and PE2 and that VE block size (VBS) of 10 is used. When the NLRI [100,100,10,5000] is sent to the PE2 device, it checks its own VE_ID (101) in the VE range received. Because 101 is in the range, it accepts the NLRI and calculates the remote label for the PE1 device from the LB = 5000. It is 5000 + 101 – 100 = 5001. It then checks whether it has sent any NLRI for VE_ID (100). If it has not, it constructs a NLRI [101, 100, 10, 6000] and sends it to the PE1 device. Now, because it has allocated both the local and remote label and associated bridge ID, it informs L2VPN to set up the PW to the PE1. PE1 sets up the PW to the PE2 after receiving the NLRI.
When the NLRI is received with a range that does not match with the VE_ID of the PE router, it creates a new block and sends it to the peers. This causes discovery of the new device and also triggers actions as illustrated in the preceding paragraph to perform label allocation.
Note
BGP signaling provides a mechanism to address the dual homed devices (DHD). DHD devices have same VE_ID and also are associated with a site-id. The DHD devices can set preferences for path selection via BGP. Therefore, DHD device selection is purely a BGP path selection decision and it is mostly used for active-standby type of forwarding from the DHD devices.
LDP signaling is a better choice than BGP signaling for VPLS for the following reasons:
Route Reflector increases the signaling delays because the signaling updates have to go through the RR router to reach the remote PE.
Route Reflector does not reduce the information to be sent as part of the update, hence it does not help in a scaled environment. In other words, RR helps in peer scaling but not in reducing the updates exchanged between PE routers.
Preallocation of label is done in blocks. Hence, it increases the chances of label space exhaustion at the edge device because if a large block of label space is not available, the smaller blocks of labels are reserved, causing possible fragmentation of label space.
Existing Route-Reflector software upgrades might be required to support the BGP signaling for VPLS.
To configure BGP signaling for VPLS, use the autodiscovery bgp signaling bgp command under l2vpn context. Along with setting the signaling to BGP, VE ID should also be assigned in the l2vpn configuration section. Example 11-14 illustrates the configuration for VPLS with BGP autodiscovery and BGP signaling. Notice the neighbor command suppress-signaling-protocol ldp on Cisco IOS and NX-OS or the command signaling [ldp|bgp] disable on IOS XR. These commands are used to disable LDP signaling when the signaling protocol is configured as BGP. This is required because the LDP signaling is enabled by default.
Example 11-14 VPLS BGP Autodiscovery and Signaling
PE1 Configuration – Cisco IOS
l2vpn
router-id 192.168.1.1
l2vpn vfi context VPLS-VFI
vpn id 100
autodiscovery bgp signaling bgp
ve id 1
rd 100:100
route-target export 100:100
route-target import 100:100
!
router bgp 100
bgp router-id 192.168.1.1
neighbor 192.168.2.2 remote-as 100
neighbor 192.168.2.2 update-source Loopback0
neighbor 192.168.3.3 remote-as 100
neighbor 192.168.3.3 update-source Loopback0
address-family l2vpn vpls
neighbor 192.168.2.2 activate
neighbor 192.168.2.2 send-community extended
neighbor 192.168.2.2 suppress-signaling-protocol ldp
neighbor 192.168.3.3 activate
neighbor 192.168.3.3 send-community extended
neighbor 192.168.3.3 suppress-signaling-protocol ldp
PE2 Configuration – IOS XR
l2vpn
router-id 192.168.2.2
bridge group BD-GRP
bridge-domain 100
interface GigabitEthernet0/3/0/2.100
!
vfi VPLS-VFI
vpn-id 100
autodiscovery bgp
rd 100:100
route-target 100:100
signaling-protocol bgp
ve-id 2
!
router bgp 100
bgp router-id 192.168.2.2
address-family l2vpn vpls-vpws
!
neighbor 192.168.1.1
remote-as 100
update-source Loopback0
address-family l2vpn vpls-vpws
Signalling ldp disable
!
!
neighbor 192.168.3.3
remote-as 100
update-source Loopback0
address-family l2vpn vpls-vpws
Signalling ldp disable
PE3 Configuration – NX-OS
l2vpn vfi context VPLS-VFI
vpn id 100
autodiscovery bgp signaling bgp
rd 100:100
ve id 3
!
bridge-domain 100
member vfi VPLS-VFI
!
router bgp 100
router-id 192.168.3.3
address-family l2vpn vpls
neighbor 192.168.1.1
remote-as 100
update-source loopback0
address-family l2vpn vpls
send-community both
suppress-signaling-protocol ldp
neighbor 192.168.2.2
remote-as 100
update-source loopback0
address-family l2vpn vpls
send-community both
suppress-signaling-protocol ldp
For VPLS BGP signaling, the Cisco IOS and NX-OS devices maintain the RIB information for all the signaling data. To view the information, use the command show l2vpn signaling rib [detail]. The command displays both the NLRI as well as routing information base (RIB) information for the signaling. Example 11-15 displays the output of the command show l2vpn signaling rib detail on both PE1 and PE3 running Cisco IOS and NX-OS, respectively.
Example 11-15 L2VPN Signaling RIB
IOS
PE1# show l2vpn signaling rib detail
Route 100:100:2 (epoch:1) from iBGP peer 192.168.2.2
Provisioned (Y) Stale (N)
Route-Target: 100:100
NLRI [6A000002]
VE-ID:2 VBO:1 VBS:10 LB:16000
MTU: 1500 Control Word: off
RIB Filter [97000003]
RD: 100:100
VE-ID: 1, VBO: 1, VBS: 10 LB: 38
Forwarder [1A000002] VFI VPLS-VFI
Route 100:100:3 (epoch:1) from iBGP peer 192.168.3.3
Provisioned (Y) Stale (N)
Route-Target: 100:100
NLRI [F0000001]
VE-ID:3 VBO:1 VBS:10 LB:24
MTU: 1500 Control Word: off
RIB Filter [97000003]
RD: 100:100
VE-ID: 1, VBO: 1, VBS: 10 LB: 38
Forwarder [1A000002] VFI VPLS-VFI
NX-OS
PE3# show l2vpn signaling rib detail
Route 100:100:1 (epoch:0) from iBGP peer 192.168.1.1
Provisioned (Y) Stale (N)
Route-Targets:
[0] 100:100
NLRI [0x16000006]
VE-ID:1 VBO:1 VBS:10 LB:38
MTU: 1500 Control Word: off
RIB Filter [0x45000003]
RD: 100:100
VE-ID: 3, VBO: 1, VBS: 10 LB: 24
Forwarder [0xb0000003] VFI VPLS-VFI
Route 100:100:2 (epoch:0) from iBGP peer 192.168.2.2
Provisioned (Y) Stale (N)
Route-Targets:
[0] 100:100
NLRI [0xa3000005]
VE-ID:2 VBO:1 VBS:10 LB:16000
MTU: 1500 Control Word: off
RIB Filter [0x45000003]
RD: 100:100
VE-ID: 3, VBO: 1, VBS: 10 LB: 24
Forwarder [0xb0000003] VFI VPLS-VFI
Note
The BGP VPLS autodiscovery commands remain the same when using BGP VPLS autodiscovery and BGP signaling.
On IOS XR platforms, the command show bgp l2vpn vpls displays the local labels as well as remote labels for the prefixes. These labels are nothing but the LB and is viewed only when BGP signaling is enabled. Example 11-16 displays the output of the command show bgp l2vpn vpls. The local label can be viewed only for the locally originated PW.
Example 11-16 VC Labels in BGP L2VPN VPLS Table
IOS XR
RP/0/1/CPU0:PE2# show bgp l2vpn vpls
Fri Apr 1 03:29:54.805 UTC
BGP router identifier 192.168.2.2, local AS number 100
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0x0 RD version: 2903485008
BGP main routing table version 17
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Rcvd Label Local Label
Route Distinguisher: 100:100 (default for vrf BD-GRP:100)
*>i1:1/32 192.168.1.1 38 nolabel
*> 2:1/32 0.0.0.0 nolabel 16000
*>i3:1/32 192.168.3.3 24 nolabel
Processed 3 prefixes, 3 paths
Troubleshooting
Cisco platforms also have support for internal event-traces or event-history, which maintains historical data related to events, errors, and finite state machines (FSM). These trace logs are useful for debugging l2vpn issues, especially in live production environments where running a debug could potentially be service impacting. To capture event-traces for l2vpn, use the command show l2vpn internal event-trace [event | error | major] on Cisco IOS software. Table 11-2 lists the options used in the show l2vpn internal event-trace command.
On IOS XR, use the command show l2vpn trace. This command displays all the trace logs related to the l2vpn component. The command show l2vpn internal event-history [cli | errors | events | msgs] displays the event-history information related to l2vpn on NX-OS. The command on NX-OS has two more options under the event-history command listed in Table 11-3.
Example 11-17 displays the output of the event traces related to L2VPN errors.
Example 11-17 L2VPN Error Event Traces
PE1# show l2vpn internal event-trace error
! Output omitted for brevity
! The below error event occurs when one kind of signaling method is configured
! and other signaling mechanism is being tried to configure on top of the
! existing signaling method.
*Mar 31 10:04:53.754: error: XC ERROR: VFI auto-discovery signaling protocol
changes are not allowed. Delete the VFI and
reconfigure.
*Mar 31 10:04:53.754: error: XC ERROR: PRC_GEN_FAILURE:PRC_FAILURE_PERMANENT
*Mar 31 10:06:53.997: error: SSM ERROR SM[SSS:AToM:16399]: Unprovision failed
*Mar 31 10:06:53.997: error: SSM ERROR CM[SSS:AToM:16399]: unable to deallocate
segment 1
RP/0/1/CPU0:PE2# show l2vpn trace
! Output omitted for brevity
! The below trace logs displays the NLRI update received and the respective
! values received in the NLRI
11:29:41.527 l2vpn/ad 0/1/CPU0 t15 AUTO-DISCO:500: REQ_NLRI_REFRESH SVC=0
VPNID=0 FLAGS=0x1
11:29:41.528 l2vpn/ad 0/1/CPU0 t15 AUTO-DISCO:604: VPN ADD PART1: SVC=1
VPNID=0 NAME=BD-GRP:100 RD[0-3]=0x1c0a8 RD[4-7]=0x2028000 sig =1
11:29:41.528 l2vpn/ad 0/1/CPU0 t15 AUTO-DISCO:608: VPN ADD PART2: shutdown=0
mtu = 1500 cfbv=0x0 encap=19, VPLS-ID[0-3] = 0 VPLS-ID[4-7] = 0
11:29:41.530 l2vpn/ad 0/1/CPU0 t1 AUTO-DISCO:218: AD_RCV_RESYNC_DONE SVC=0
PE3# show l2vpn internal event-histor errors
L2VPN Process Event History Error:
!Output omittied for brevity
23:19:18.73302: XC ERROR i/f: [pw100003]PW interface does not exist
in config PSS, can't delete it
23:19:18.21888: XC ERROR UFDM: [4] ack peer-id count is 0
23:14:55.70402: XC ERROR i/f: [pw100001]Failed to remove PW interfac
e from PSS
23:14:55.70401: XC ERROR i/f: [pw100001]PW interface does not exist
in config PSS, can't delete it
23:14:55.18887: XC ERROR UFDM: [4] ack peer-id count is 0
! The below error log indicates that there was a mis-match in the cbit field
! between the local PE and the remote PE router, causing the pseudowire not
! to come up.
10:33:11.24402: AToM ERROR[192.168.2.2, 100]: .. Remote is invalid
10:33:11.24390: AToM ERROR[192.168.2.2, 100]: .. Mismatch cbit, loca
l 1, remote 0
Note
For a detailed set of trace logs and other event-history logs, show tech-support l2vpn and show tech-support bgp can be captured on NX-OS. On IOS XR platform, show tech-support routing bgp and show tech-support l2vpn and the command show tech-platform l2vpn platform can be captured during problematic conditions.
Summary
There are various methods used for L2VPN services over MPLS. The default signaling method is a manual method using LDP signaling. The L2VPN services such as VPWS and VPLS can also be enabled using BGP extensions to L2VPN. BGP provides autodiscovery and signaling services for both VPWS and VPLS. The VPWS provides point-to-point services, whereas VPLS provides multipoint services. It has to be carefully defined where to use VPWS versus VPLS solutions. Although BGP extension is available for both VPWS and VPLS, it is not a good method to use BGP for VPWS. BGP for VPLS provides the service providers with following benefits:
Scalability
Peer autodiscovery
Less configuration load
Advertise VC labels
This chapter explained how both the manual as well as the autodiscovery mechanism can be useful for VPLS services and how to troubleshoot them. The chapter then detailed the BGP signaling mechanism for VPLS and platform troubleshooting commands that can be used during troubleshooting. Because the BGP troubleshooting for L2VPN address family is similar to any other AFI/SAFI, it makes it easier for service providers to implement BGP for providing L2VPN services to customers while availing other benefits.
References
RFC 3985, Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture, S. Bryant, P. Pate, IETF, http://tools.ietf.org/html/rfc3985, March 2005.
RFC 4446, IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3), L. Martini, IETF, http://tools.ietf.org/html/rfc4446, April 2006.
RFC 4447, Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP), L. Martini, Ed., E. Rosen, N. El-Aawar, T. Smith, G. Heron, IETF, http://tools.ietf.org/html/rfc4447, April 2006.
RFC 4448, Encapsulation Methods for Transport of Ethernet over MPLS Networks, L. Martini, Ed., E. Rosen, N. El-Aawar, G. Heron, IETF, http://tools.ietf.org/html/rfc4448, April 2006.
RFC 6624, Layer 2 Virtual Private Networking using BGP for Auto-Discovery and Signaling, K. Kompella, B. Kothari, R. Cherukuri. IETF, https://tools.ietf.org/html/rfc6624, May 2012.
RFC 4761, VPLS Using BGP for Auto-Discovery and Signaling, K. Kompella, Y. Rekhter. IETF, https://tools.ietf.org/html/rfc4761, Jan 2007.
RFC 4762, VPLS Using LDP for Signaling, M. Lasserre, K. Kompella. IETF, https://tools.ietf.org/html/rfc4762, Jan 2007.
Cisco Press, Layer 2 VPN Architectures, Wei Luo, Carlos Pignataro, Anthony Chan, Dmitry Bokotey.
Cisco. L2VPN Interworking, http://www.cisco.com/c/en/us/td/docs/ios/ios_xe/mpls/configuration/guide/convert/mp_l2_vpns_book_xe/mp_l2vpn_intrntwkg_xe.html.