LDP VPLS Using BGP Auto-Discovery
This chapter provides information about LDP VPLS using BGP Auto-Discovery.
Topics in this chapter include:
Applicability
This chapter was initially written for SR OS Release 9.0.R3. The MD-CLI in this edition is based on SR OS Release 20.10.R2. There are no prerequisites for this configuration.
Knowledge of BGP-auto-discovery RFC 6074 architecture and functionality, RFC 4447 Pseudo-wire set-up using label distribution protocol is assumed throughout this chapter, as well as knowledge of Multi-Protocol BGP (MP-BGP).
Overview
MPLS-based Virtual Private LAN Services (VPLS) may have many different provisioning models to allow the signaling of pseudowires between Provider Edge (PE) routers containing VPLS instances.
Network Management System (NMS) provisioning using Label Distribution Protocol (LDP) signaling is a well understood method of provisioning of Layer 2 VPLS services as described in RFC 4762. This relies on the provisioning of pseudowires between VPLS instances using LDP signaling with a common Virtual Circuit (VC) identifier within the label mapping message to instantiate pseudowires.
Border Gateway Protocol Auto-Discovery (BGP-AD), as specified in RFC 6074, is an alternative method of provisioning of Layer 2 PE routers containing VPLS service instances to those described above where PEs in a common VPLS instance are automatically discovered using BGP-AD techniques.
Each PE router advertises the presence of VPLS instances to other PE routers using defined parameters within a BGP update message.
LDP is used as the pseudowire signaling protocol and relies on the auto-discovery of VPLS endpoints to instantiate pseudowires instead of manually provisioning virtual circuits. Locally configured parameters, along with BGP learned parameters, are used to determine local and remote VPLS endpoints, which are used by LDP to signal service labels to peer routers.
Example topology shows the example topology with six SR OS nodes located in the same autonomous system (AS).There are three PEs and RR-6 acts as a route reflector for the AS. The PE routers are all VPLS-aware. The provider (P) routers are VPLS-unaware and do not take part in the BGP process. A full mesh VPLS between PE-1, PE-2, and PE-3 is described.
The following configuration tasks are completed as a prerequisite:
-
IS-IS or OSPF is enabled on all network interfaces between each of the PE/P routers and route reflector RR-6.
-
MPLS is configured on all interfaces between PE and P routers; MPLS is not required between P-4 and RR-6.
-
LDP is configured on interfaces between PE and P routers; LDP is not required between P-4 and RR-6.
-
The RSVP protocol must be enabled.
BGP-AD
In this architecture, a VPLS service is a collection of local VPLS instances present on a number of PEs in a provider network. In this context, VPLS-aware devices are PE routers. Each VPLS instance has a unique identifier known as the VPLS identifier (VPLS-ID). All PEs that have this VPLS instance present will have a common VPLS-ID configured.
Each VPLS instance within a PE contains a Virtual Switching Instance (VSI). The VPLS attachment circuits and pseudowires are associated with the VSI. Each VSI within a VPLS has a unique identifier called the VSI identifier (VSI-ID) and is a concatenation of the VPLS-ID plus an IP address, usually the system IP address.
The PEs communicate with each other at the control plane level by means of BGP updates containing BGP Layer 2 Network Layer Reachability Information (NLRI). Each update contains enough information for a PE to determine the presence of other local VPLS instances on peering PEs. In turn, this allows peer PE routers to set up pseudowire connectivity using LDP signaling for data flow between peers containing a local VPLS within the same VPLS instances.
Each update contains parameters usually associated with Multi-Protocol BGP updates:
-
NLRI encoded as route target (RT)—usually the VPLS-ID—and PE system address.
-
Next-Hop — The system IP address of the sending PE router.
-
Extended communities — Contains the RT extended community and the VPLS-ID as community values.
Each VPLS instance is configured with import and export RT extended communities to create the required pseudowire topology by controlling the distribution of each NLRI.
This chapter describes the provisioning of a VPLS instance across three PE routers. A full mesh of pseudowires interconnects the VSI of each PE within the VPLS instance. A single attachment circuit is also configured on each VSI.
Configuration
The first step is to configure an MP-iBGP session using the L2-VPN address family between each of the PEs and the RR.
The configuration on the PEs is as follows:
# on PE-1, PE-2, and PE-3:
configure {
router "Base"
autonomous-system 65536
bgp {
group "internal" {
peer-as 65536
family {
l2-vpn true
}
}
neighbor "192.0.2.6" {
group "internal"
}
The IP addresses can be derived from Example topology.
The configuration for RR-6 is as follows:
# on RR-6:
configure {
router "Base"
autonomous-system 65536
bgp {
group "rr-internal" {
peer-as 65536
family {
l2-vpn true
}
cluster {
cluster-id 1.1.1.1
}
}
neighbor "192.0.2.1" {
group "rr-internal"
}
neighbor "192.0.2.2" {
group "rr-internal"
}
neighbor "192.0.2.3" {
group "rr-internal"
}
On PE-1, the BGP session with RR-6 is established with address family L2-VPN capability negotiated, as follows:
[]
A:admin@PE-1# show router bgp neighbor 192.0.2.6
===============================================================================
BGP Neighbor
===============================================================================
-------------------------------------------------------------------------------
Peer : 192.0.2.6
Description : (Not Specified)
Group : internal
-------------------------------------------------------------------------------
Peer AS : 65536 Peer Port : 50296
Peer Address : 192.0.2.6
Local AS : 65536 Local Port : 179
Local Address : 192.0.2.1
Peer Type : Internal Dynamic Peer : No
State : Established Last State : Established
Last Event : recvOpen
Last Error : Cease (Connection Collision Resolution)
Local Family : L2-VPN
Remote Family : L2-VPN
---snip---
On RR-6, the following BGP sessions are established with each PE for the L2-VPN address family:
[]
A:admin@RR-6# show router bgp summary all
===============================================================================
BGP Summary
===============================================================================
Legend : D - Dynamic Neighbor
===============================================================================
Neighbor
Description
ServiceId AS PktRcvd InQ Up/Down State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
-------------------------------------------------------------------------------
192.0.2.1
Def. Instance 65536 18 0 00h07m44s 0/0/0 (L2VPN)
18 0
192.0.2.2
Def. Instance 65536 18 0 00h07m44s 0/0/0 (L2VPN)
18 0
192.0.2.3
Def. Instance 65536 18 0 00h07m44s 0/0/0 (L2VPN)
18 0
-------------------------------------------------------------------------------
A full mesh of RSVP Label Switched Paths (LSPs) is configured between the PE routers. For reference, the MPLS interface configuration and LSPs for PE-1 to PE-2 and PE-3 is as follows:
# on PE-1:
configure {
router "Base"
mpls {
admin-state enable
interface "int-PE-1-P-4" {
}
interface "int-PE-1-PE-2" {
}
path "loose" {
admin-state enable
}
lsp "LSP-PE-1-PE-2" {
admin-state enable
type p2p-rsvp
to 192.0.2.2
primary "loose" {
}
}
lsp "LSP-PE-1-PE-3" {
admin-state enable
type p2p-rsvp
to 192.0.2.3
primary "loose" {
}
}
VPLS PE configuration
Pseudowire templates
Pseudowire templates are used by BGP to dynamically instantiate Service Distribution Point (SDP) bindings. For a given service, pseudowire templates signal the egress service de-multiplexer labels used by remote PEs to reach the local PE.
The template determines the signaling parameters of the pseudowire, control word presence, plus other usage characteristics such as Split Horizon Groups (SHGs), MAC-pinning, filters, and so on.
The MPLS transport tunnel between PE routers can be signaled using either LDP or RSVP.
LDP-based pseudowires can be automatically instantiated; RSVP-based SDPs have to be pre-provisioned.
Pseudowire templates for auto-SDP creation using LDP
In order to use an LDP transport tunnel for data flow between PEs, it is necessary for link layer LDP to be configured between all PEs/Ps so that a transport label for each PE system interface address is available. Using this mechanism, SDPs can be auto-instantiated with SDP-IDs starting at 32767. Any subsequent SDPs created use SDP-IDs decrementing from this value.
A pseudowire template is required which may contain an SHG. Each SDP created with this template is contained within the configured SHG so that traffic cannot be forwarded between them.
# on PE-1, PE-2, PE-3:
configure {
service {
pw-template "PW1" {
pw-template-id 1
split-horizon-group {
name "vpls-shg"
}
}
A pseudowire template can also be created that does not contain a split horizon group. The split horizon group can then be specified when the pw-template is included within the service.
# on PE-1, PE-2, PE-3:
configure {
service {
pw-template "PW2" {
pw-template-id 2
}
Pseudowire templates for provisioned SDPs using RSVP
To use an RSVP tunnel as transport between PEs, it is necessary to bind the RSVP LSPs to the SDPs between each PE.
On PE-1, SDP 12 from PE-1 to PE-2 is configured as follows:
# on PE-1:
configure {
service {
sdp 12 {
admin-state enable
description "RSVP-based SDP from PE-1 to PE-2"
delivery-type mpls
far-end {
ip-address 192.0.2.2
}
lsp "LSP-PE-1-PE-2" { }
}
To create an SDP within a service that uses an RSVP transport tunnel, a pseudowire template is required that has the provisioned-sdp use parameter.
# on PE-1, PE-2, PE-3:
configure {
service {
pw-template "PW3" {
pw-template-id 3
provisioned-sdp use
}
Alternatively, the provisioned-sdp prefer parameter can be used, see chapter LDP VPLS Using BGP Auto-Discovery — Prefer Provisioned SDP.
VPLS BGP-AD using auto-provisioned SDPs
VPLS instance with auto-provisioned SDPs shows a schematic of a VPLS instance where the SDPs are auto-provisioned. SDPs are instantiated by a PE router using LDP signaling upon receipt of BGP Auto-Discovery (BGP-AD) updates from peer PE routers.
PE-1 configuration:
The following output shows the configuration required for a VPLS service using a pseudowire template configured for auto-provisioning of SDPs.
# on PE-1:
configure {
service {
vpls "VPLS-3" {
admin-state enable
service-id 3
customer "1"
bgp 1 {
route-distinguisher "65536:3"
route-target {
export "target:65536:3"
import "target:65536:3"
}
pw-template-binding "PW2" {
split-horizon-group "vpls-shg"
import-rt ["target:65536:3"]
}
}
bgp-ad {
admin-state enable
vpls-id "65536:3"
vsi-id-prefix 192.0.2.1
}
sap 1/1/4:3.0 {
}
Within the bgp context, the pseudowire template is referenced which can be linked to an SHG and an import RT, if required.
Within the bgp-ad context, the signaling parameters are configured. These are two parameters used by each PE to determine the presence of a VPLS instance on a PE router. In turn, these are translated into endpoint identifiers for LDP signaling of pseudowires. As previously discussed, these parameters are:
-
VPLS-ID — a unique identifier of the VPLS instance. Each PE that is a member of a VPLS must share the same VPLS-ID. This is inserted as an extended community value in the format AS:n. In this case, the VPLS-ID for VPLS 3 is 65536:3. This is a mandatory parameter and if it is not configured, it is not possible to enable BGP-AD (admin-state enable).
-
Virtual Switching Instance (VSI) prefix — This identifies a specific instance of the VPLS. This must be unique within the VPLS instance, and is encoded using the 4 byte dotted-decimal notation. Generally, the system address is used as the VSI prefix. If this parameter is not configured, then the system address is used automatically.
The VPLS-ID and VSI prefix for VPLS 3 on each PE is shown in VPLS instance with auto-provisioned SDPs.
The VPLS-ID and VSI prefix are concatenated to form a unique VSI-ID. In this case, PE-1 has a VSI-ID of 65536:3:192.0.2.1. This uniquely identifies the VPLS instance on each individual PE and is advertised as an L2-VPN BGP update.
A BGP-AD update is transmitted to all other PEs via the RR, as follows:
[]
A:admin@PE-1# show router bgp routes l2-vpn rd 65536:3 hunt
===============================================================================
BGP Router ID:192.0.2.1 AS:65536 Local AS:65536
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP L2VPN Routes
===============================================================================
---snip---
-------------------------------------------------------------------------------
RIB Out Entries
-------------------------------------------------------------------------------
Route Type : AutoDiscovery
Route Dist. : 65536:3
Prefix : 192.0.2.1
Nexthop : 192.0.2.1
To : 192.0.2.6
Res. Nexthop : n/a
Local Pref. : 100 Interface Name : NotAvailable
Aggregator AS : None Aggregator : None
Atomic Aggr. : Not Atomic MED : 0
AIGP Metric : None IGP Cost : n/a
Connector : None
Community : target:65536:3 l2-vpn/vrf-imp:65536:3
Cluster : No Cluster Members
Originator Id : None Peer Router Id : 192.0.2.6
Origin : IGP
AS-Path : No As-Path
Route Tag : 0
Neighbor-AS : n/a
Orig Validation: N/A
Source Class : 0 Dest Class : 0
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
The preceding BGP update is transmitted by PE-1 and has route type auto-discovery.
In this L2-VPN update, the VPLS-ID is encoded as the L2-VPN extended community 65536:3.
The VSI is seen as the prefix 192.0.2.1. The combination of the VPLS-ID and the VSI forms the VSI-ID and uniquely identifies the VPLS instance within this PE router.
The next-hop is also encoded as the local system IP address 192.0.2.1, which allows remote PEs to identify a suitable transport tunnel to PE-1 and for the targeted-LDP peer for instantiating the SDP.
As can be seen within the update, the VPLS-ID 65536:3 is also used to determine the RT extended community and the route distinguisher (RD).
PE-2 configuration
On PE-2, VPLS 3 is created using pseudowire template 1, with VPLS-ID 65536:3 and VSI-ID prefix 192.0.2.2 (system IP address), as follows”
# on PE-2:
configure {
service {
vpls "VPLS-3" {
admin-state enable
service-id 3
customer "1"
bgp 1 {
route-distinguisher "65536:3"
route-target {
export "target:65536:3"
import "target:65536:3"
}
pw-template-binding "PW2" {
split-horizon-group "vpls-shg"
import-rt ["target:65536:3"]
}
}
bgp-ad {
admin-state enable
vpls-id "65536:3"
vsi-id-prefix 192.0.2.2
}
sap 1/1/4:3.0 {
}
PE-3 configuration
On PE-3, VPLS 3 is created using pseudowire template 2, with VPLS-ID 65536:3—identical to the VPLS-ID of PE-1 and PE-2—and VSI-ID 192.0.2.3 (system IP address), as follows:
# on PE-3:
configure {
service {
vpls "VPLS-3" {
admin-state enable
service-id 3
customer "1"
bgp 1 {
route-distinguisher "65536:3"
route-target {
export "target:65536:3"
import "target:65536:3"
}
pw-template-binding "PW2" {
split-horizon-group "vpls-shg"
import-rt ["target:65536:3"]
}
}
bgp-ad {
admin-state enable
vpls-id "65536:3"
vsi-id-prefix 192.0.2.3
}
sap 1/1/4:3.0 {
}
PE-1 service operation verification
The following output on PE-1 shows that the VPLS and its objects (SAP and auto-discovered spoke SDPs) are operationally up on PE-1:
[]
A:admin@PE-1# show service id 3 base
===============================================================================
Service Basic Information
===============================================================================
Service Id : 3 Vpn Id : 0
Service Type : VPLS
---snip---
Admin State : Up Oper State : Up
MTU : 1514
SAP Count : 1 SDP Bind Count : 2
---snip---
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sap:1/1/4:3.0 qinq 1522 1522 Up Up
sdp:32766:4294967294 SB(192.0.2.3) BgpAd 0 1556 Up Up
sdp:32767:4294967295 SB(192.0.2.2) BgpAd 0 1556 Up Up
===============================================================================
* indicates that the corresponding row element may have been truncated.
The SB flag indicates that the SDP is of type spoke-SDP (S flag) BGP (B flag).
BGP is used to discover the VPLS endpoints and exchange network reachability information. LDP is used to signal the pseudowires between the PEs.
LDP signaling occurs when each PE has discovered the endpoints of the VPLS instance. This compares with the use of the provisioned virtual circuit IDs used in an NMS provisioned VPLS instances as per RFC 4762.
The ability of PE-1 to reach the other PE routers with VSIs within the VPLS instance is verified from the following L2-route table:
[]
A:admin@PE-1# show service l2-route-table bgp-ad
========================================================================
Services: L2 Route Information - Summary
========================================================================
Svc Id L2-Routes (RD-Prefix) Next Hop Origin
Sdp Bind Id PW Temp Id
------------------------------------------------------------------------
3 *65536:3-192.0.2.2 192.0.2.2 BGP-L2
32767:4294967295 2
3 *65536:3-192.0.2.3 192.0.2.3 BGP-L2
32766:4294967294 2
------------------------------------------------------------------------
No. of L2 Route Entries: 2
========================================================================
This output shows the presence of the signaled pseudowire SDPs. SDPs from PE-1 to PE-2 and PE-3 are signaled using LDP Forwarding Equivalence Class (FEC) Element 129.
Each PE router uses targeted LDP to signal the local and remote endpoints. If there is an endpoint match, then SDPs are instantiated. This compares with the use of LDP for NMS provisioned SDPs, which uses virtual circuit IDs to signal pseudowires using LDP FEC Element 128.
In order to signal the SDPs, the following parameters are required:
-
Attachment Group Identifier (AGI): this is used to carry the VPLS-ID of the local PE router VPLS instance. The VPLS-ID must be identical for all PEs in the same VPLS instance.
-
Source Attachment Individual Identifier (SAII) and Target Attachment Individual Identifier (TAII): these use AII type 1 (RFC 4446) and are used to carry the NLRI (VSI-ID minus the RD) of the remote PE router VPLS instance.
The AGI for each PE must be identical. SAII and TAII must be different.
The following shows the service LDP bindings for VPLS 3 on PE-1:
[]
A:admin@PE-1# show router ldp bindings services service-id 3
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.1)
(IPv6 LSR ID ::)
===============================================================================
Label Status:
U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down, e - Label ELC
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
Service Type:
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, C - Cpipe Service
FEC Flags:
LF - Lower FEC, UF - Upper FEC, M - Community Mismatch,
BA - ASBR Backup FEC
===============================================================================
LDP Service FEC 128 Bindings
===============================================================================
Type VCId SDPId LMTU
Peer SvcId IngLbl RMTU
EgrLbl
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
===============================================================================
LDP Service FEC 129 Bindings
===============================================================================
SAII AGII IngLbl LMTU
TAII Type EgrLbl RMTU
Peer SvcId SDPId
-------------------------------------------------------------------------------
192.0.2.1 1,8:020A00* 524280U 1500
192.0.2.2 V-Eth 524277S 1500
192.0.2.2:0 3 32767
192.0.2.1 1,8:020A00* 524279U 1500
192.0.2.3 V-Eth 524280S 1500
192.0.2.3:0 3 32766
-------------------------------------------------------------------------------
No. of FEC 129s: 2
===============================================================================
* indicates that the corresponding row element may have been truncated.
This shows the two T-LDP bindings for PE-1 toward PE-2 and PE-3 for VPLS 3. The label bindings from this LDP output is identical to the SDP bindings output that follows. The following command can be used to list the SDP IDs and the SDP label bindings:
[]
A:admin@PE-1# show service id 3 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId Type Far End addr Adm Opr I.Lbl E.Lbl
-------------------------------------------------------------------------------
32766:4294967294 BgpAd 192.0.2.3 Up Up 524279 524280
32767:4294967295 BgpAd 192.0.2.2 Up Up 524280 524277
-------------------------------------------------------------------------------
Number of SDPs : 2
-------------------------------------------------------------------------------
===============================================================================
The SDP ID for the auto-provisioned SDP toward PE-2 is 32767, the SDP ID toward PE-3 is 32766.
The actual AGI, SAII, and TAII values are seen in the following detailed SDP output.
-
AGI — 65536:3
-
SAII — Local system IP address 192.0.2.1
-
TAII — Remote system IP address 192.0.2.2 or 192.0.2.3
[] A:admin@PE-1# show service id 3 sdp 32767:4294967295 detail =============================================================================== Service Destination Point (Sdp Id : 32767:4294967295) Details =============================================================================== ------------------------------------------------------------------------------- Sdp Id 32767:4294967295 -(192.0.2.2) ------------------------------------------------------------------------------- Description : (Not Specified) SDP Id : 32767:4294967295 Type : BgpAd PW-Template Id : 2 AGI : 65536:3 SDP Bind Source : bgp-l2vpn Local AII : 192.0.2.1 Remote AII : 192.0.2.2 Split Horiz Grp : vpls-shg Etree Root Leaf Tag: Disabled Etree Leaf AC : Disabled VC Type : Ether VC Tag : n/a Admin Path MTU : 0 Oper Path MTU : 1556 Delivery : MPLS Far End : 192.0.2.2 Tunnel Far End : n/a Oper Tunnel Far End: 192.0.2.2 LSP Types : LDP/BGP ---snip---
PE-2 service operation verification
For completeness, the following shows that the VPLS service is operationally up on PE-2.
[]
A:admin@PE-2# show service id 3 base
===============================================================================
Service Basic Information
===============================================================================
Service Id : 3 Vpn Id : 0
Service Type : VPLS
---snip---
Admin State : Up Oper State : Up
MTU : 1514
SAP Count : 1 SDP Bind Count : 2
---snip---
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sap:1/1/4:3.0 qinq 1522 1522 Up Up
sdp:32766:4294967293 SB(192.0.2.3) BgpAd 0 1556 Up Up
sdp:32767:4294967294 SB(192.0.2.1) BgpAd 0 1556 Up Up
===============================================================================
* indicates that the corresponding row element may have been truncated.
[]
A:admin@PE-2# show service l2-route-table bgp-ad
========================================================================
Services: L2 Route Information - Summary
========================================================================
Svc Id L2-Routes (RD-Prefix) Next Hop Origin
Sdp Bind Id PW Temp Id
------------------------------------------------------------------------
3 *65536:3-192.0.2.1 192.0.2.1 BGP-L2
32767:4294967294 2
3 *65536:3-192.0.2.3 192.0.2.3 BGP-L2
32766:4294967293 2
------------------------------------------------------------------------
No. of L2 Route Entries: 2
========================================================================
[]
A:admin@PE-2# show router ldp bindings services service-id 3
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.2)
(IPv6 LSR ID ::)
===============================================================================
Label Status:
U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down, e - Label ELC
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
Service Type:
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, C - Cpipe Service
FEC Flags:
LF - Lower FEC, UF - Upper FEC, M - Community Mismatch,
BA - ASBR Backup FEC
===============================================================================
LDP Service FEC 128 Bindings
===============================================================================
Type VCId SDPId LMTU
Peer SvcId IngLbl RMTU
EgrLbl
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
===============================================================================
LDP Service FEC 129 Bindings
===============================================================================
SAII AGII IngLbl LMTU
TAII Type EgrLbl RMTU
Peer SvcId SDPId
-------------------------------------------------------------------------------
192.0.2.2 1,8:020A00* 524277U 1500
192.0.2.1 V-Eth 524280S 1500
192.0.2.1:0 3 32767
192.0.2.2 1,8:020A00* 524278U 1500
192.0.2.3 V-Eth 524279S 1500
192.0.2.3:0 3 32766
-------------------------------------------------------------------------------
No. of FEC 129s: 2
===============================================================================
* indicates that the corresponding row element may have been truncated.
[]
A:admin@PE-2# show service id 3 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId Type Far End addr Adm Opr I.Lbl E.Lbl
-------------------------------------------------------------------------------
32766:4294967293 BgpAd 192.0.2.3 Up Up 524278 524279
32767:4294967294 BgpAd 192.0.2.1 Up Up 524277 524280
-------------------------------------------------------------------------------
Number of SDPs : 2
-------------------------------------------------------------------------------
===============================================================================
PE-3 service operation verification
For completeness, the same commands are launched on PE-3, as follows:
[]
A:admin@PE-3# show service id 3 base
===============================================================================
Service Basic Information
===============================================================================
Service Id : 3 Vpn Id : 0
Service Type : VPLS
---snip---
Admin State : Up Oper State : Up
MTU : 1514
SAP Count : 1 SDP Bind Count : 2
---snip---
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sap:1/1/4:3.0 qinq 1522 1522 Up Up
sdp:32766:4294967294 SB(192.0.2.2) BgpAd 0 1556 Up Up
sdp:32767:4294967295 SB(192.0.2.1) BgpAd 0 1556 Up Up
===============================================================================
* indicates that the corresponding row element may have been truncated.
[]
A:admin@PE-3# show service l2-route-table bgp-ad
========================================================================
Services: L2 Route Information - Summary
========================================================================
Svc Id L2-Routes (RD-Prefix) Next Hop Origin
Sdp Bind Id PW Temp Id
------------------------------------------------------------------------
3 *65536:3-192.0.2.1 192.0.2.1 BGP-L2
32767:4294967295 2
3 *65536:3-192.0.2.2 192.0.2.2 BGP-L2
32766:4294967294 2
------------------------------------------------------------------------
No. of L2 Route Entries: 2
========================================================================
[]
A:admin@PE-3# show router ldp bindings services service-id 3
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.3)
(IPv6 LSR ID ::)
===============================================================================
Label Status:
U - Label In Use, N - Label Not In Use, W - Label Withdrawn
S - Status Signaled Up, D - Status Signaled Down, e - Label ELC
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
Service Type:
E - Epipe Service, V - VPLS Service, M - Mirror Service
A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service
P - Ipipe Service, C - Cpipe Service
FEC Flags:
LF - Lower FEC, UF - Upper FEC, M - Community Mismatch,
BA - ASBR Backup FEC
===============================================================================
LDP Service FEC 128 Bindings
===============================================================================
Type VCId SDPId LMTU
Peer SvcId IngLbl RMTU
EgrLbl
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
===============================================================================
LDP Service FEC 129 Bindings
===============================================================================
SAII AGII IngLbl LMTU
TAII Type EgrLbl RMTU
Peer SvcId SDPId
-------------------------------------------------------------------------------
192.0.2.3 1,8:020A00* 524280U 1500
192.0.2.1 V-Eth 524279S 1500
192.0.2.1:0 3 32767
192.0.2.3 1,8:020A00* 524279U 1500
192.0.2.2 V-Eth 524278S 1500
192.0.2.2:0 3 32766
-------------------------------------------------------------------------------
No. of FEC 129s: 2
===============================================================================
* indicates that the corresponding row element may have been truncated.
[]
A:admin@PE-3# show service id 3 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId Type Far End addr Adm Opr I.Lbl E.Lbl
-------------------------------------------------------------------------------
32766:4294967294 BgpAd 192.0.2.2 Up Up 524279 524278
32767:4294967295 BgpAd 192.0.2.1 Up Up 524280 524279
-------------------------------------------------------------------------------
Number of SDPs : 2
-------------------------------------------------------------------------------
===============================================================================
BGP AD using pre-provisioned SDPs
It is possible to configure BGP-AD instances that use RSVP transport tunnels. In this case, the LSPs and SDPs must be manually created.
VPLS instance using pre-provisioned SDPs shows a VPLS instance configured across three PE routers as before.
The following SDPs are configured on the three PEs:
# on PE-1:
configure {
service {
sdp 12 {
admin-state enable
description "RSVP-based SDP from PE-1 to PE-2"
delivery-type mpls
far-end {
ip-address 192.0.2.2
}
lsp "LSP-PE-1-PE-2" { }
}
sdp 13 {
admin-state enable
description "RSVP-based SDP from PE-1 to PE-3"
delivery-type mpls
far-end {
ip-address 192.0.2.3
}
lsp "LSP-PE-1-PE-3" { }
}
# on PE-2:
configure {
service {
sdp 21 {
admin-state enable
description "RSVP-based SDP from PE-2 to PE-1"
delivery-type mpls
far-end {
ip-address 192.0.2.1
}
lsp "LSP-PE-2-PE-1" { }
}
sdp 23 {
admin-state enable
description "RSVP-based SDP from PE-2 to PE-3"
delivery-type mpls
far-end {
ip-address 192.0.2.3
}
lsp "LSP-PE-2-PE-3" { }
}
# on PE-3:
configure {
service {
sdp 31 {
admin-state enable
description "RSVP-based SDP from PE-3 to PE-1"
delivery-type mpls
far-end {
ip-address 192.0.2.1
}
lsp "LSP-PE-3-PE-1" { }
}
sdp 32 {
admin-state enable
description "RSVP-based SDP from PE-3 to PE-2"
delivery-type mpls
far-end {
ip-address 192.0.2.2
}
lsp "LSP-PE-3-PE-2" { }
}
The PW template to be used within each VPLS instance must be provisioned on all PEs and must use the keyword provisioned-sdp use, as follows:
# on PE-1, PE-2, PE-3:
configure {
service {
pw-template "PW3" {
pw-template-id 3
provisioned-sdp use
}
The following output shows the configuration required for a VPLS service using a pseudowire template configured for pre-provisioned RSVP SDPs.
# on PE-1:
configure {
service {
vpls "VPLS-4" {
admin-state enable
service-id 4
customer "1"
bgp 1 {
route-distinguisher "65536:4"
route-target {
export "target:65536:4"
import "target:65536:4"
}
pw-template-binding "PW3" {
split-horizon-group "vpls-shg"
import-rt ["target:65536:4"]
}
}
bgp-ad {
admin-state enable
vpls-id "65536:4"
vsi-id-prefix 192.0.2.1
}
sap 1/1/4:4.0 {
}
Similarly, on PE-2 the configuration is as follows:
# on PE-2:
configure {
service {
vpls "VPLS-4" {
admin-state enable
service-id 4
customer "1"
bgp 1 {
route-distinguisher "65536:4"
route-target {
export "target:65536:4"
import "target:65536:4"
}
pw-template-binding "PW3" {
split-horizon-group "vpls-shg"
import-rt ["target:65536:4"]
}
}
bgp-ad {
admin-state enable
vpls-id "65536:4"
vsi-id-prefix 192.0.2.2
}
sap 1/1/4:4.0 {
}
On PE-3, VPLS 4 is configured as follows:
# on PE-3:
configure {
service {
vpls "VPLS-4" {
admin-state enable
service-id 4
customer "1"
bgp 1 {
route-distinguisher "65536:4"
route-target {
export "target:65536:4"
import "target:65536:4"
}
pw-template-binding "PW3" {
split-horizon-group "vpls-shg"
import-rt ["target:65536:4"]
}
}
bgp-ad {
admin-state enable
vpls-id "65536:4"
vsi-id-prefix 192.0.2.3
}
sap 1/1/4:4.0 {
}
The following output shows that the service and its objects are operationally up on PE-1.
[]
A:admin@PE-1# show service id 4 base
===============================================================================
Service Basic Information
===============================================================================
Service Id : 4 Vpn Id : 0
Service Type : VPLS
---snip---
Admin State : Up Oper State : Up
MTU : 1514
SAP Count : 1 SDP Bind Count : 2
---snip---
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sap:1/1/4:4.0 qinq 1522 1522 Up Up
sdp:12:4294967293 S(192.0.2.2) BgpAd 0 1556 Up Up
sdp:13:4294967292 S(192.0.2.3) BgpAd 0 1556 Up Up
===============================================================================
* indicates that the corresponding row element may have been truncated.
The SDP identifiers are the pre-provisioned SDPs: SDP 12 and 13.
The following command shows that the service and its objects are operationally up on PE-2.
[]
A:admin@PE-2# show service id 4 base
===============================================================================
Service Basic Information
===============================================================================
Service Id : 4 Vpn Id : 0
Service Type : VPLS
---snip---
Admin State : Up Oper State : Up
MTU : 1514
SAP Count : 1 SDP Bind Count : 2
---snip---
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sap:1/1/4:4.0 qinq 1522 1522 Up Up
sdp:21:4294967292 S(192.0.2.1) BgpAd 0 1556 Up Up
sdp:23:4294967291 S(192.0.2.3) BgpAd 0 1556 Up Up
===============================================================================
* indicates that the corresponding row element may have been truncated.
The following command shows that the service and its objects are operationally up on PE-3.
[]
A:admin@PE-3# show service id 4 base
===============================================================================
Service Basic Information
===============================================================================
Service Id : 4 Vpn Id : 0
Service Type : VPLS
---snip---
Admin State : Up Oper State : Up
MTU : 1514
SAP Count : 1 SDP Bind Count : 2
---snip---
-------------------------------------------------------------------------------
Service Access & Destination Points
-------------------------------------------------------------------------------
Identifier Type AdmMTU OprMTU Adm Opr
-------------------------------------------------------------------------------
sap:1/1/4:4.0 qinq 1522 1522 Up Up
sdp:31:4294967291 S(192.0.2.1) BgpAd 0 1556 Up Up
sdp:32:4294967292 S(192.0.2.2) BgpAd 0 1556 Up Up
===============================================================================
* indicates that the corresponding row element may have been truncated.
Conclusion
BGP-AD coupled with LDP pseudowire signaling allows the delivery of L2-VPN services to customers where BGP is commonly used. This example shows the configuration of BGP-AD together with the associated show outputs which can be used for verification and troubleshooting.