LDP VPLS Using BGP Auto-Discovery — Prefer Provisioned SDP
This chapter provides information about LDP VPLS using BGP auto-discovery — prefer provisioned SDP.
Topics in this chapter include:
Applicability
This chapter was initially written for SR OS Release 14.0.R6, but the MD-CLI in the current edition is based on SR OS Release 21.2.R1. BGP Auto-Discovery (BGP-AD) based on RFC 6074 is supported in SR OS Release 6.0, and later. The provisioned-sdp prefer option is supported in SR OS Release 14.0.R1, and later.
Overview
As described in chapter LDP VPLS Using BGP Auto-Discovery, BGP-AD based on RFC 6074 can auto-create SDP bindings, but an operator can force the system to use a provisioned SDP by specifying the provisioned-sdp use option. This chapter compares the provisioned-sdp use option with the provisioned-sdp prefer option. The chapter describes a migration scenario for a VPLS service with a pseudowire (PW) template binding, restricted to using provisioned SDPs toward a PW template binding preferring to use provisioned SDPs, but auto-creating SDPs in case there is no suitable manually created SDP available.
PW templates
PW templates can be configured with the following command:
[ex:/configure service]
A:admin@PE-1# pw-template "PW 1" ?
pw-template
Immutable fields - pw-template-id, provisioned-sdp, auto-gre-sdp
---snip---
When provisioned SDPs are to be used, the provisioned-sdp context must be configured:
*[ex:/configure service pw-template "PW 1"]
A:admin@PE-1# provisioned-sdp ?
provisioned-sdp <keyword>
<keyword> - (use|prefer)
'provisioned-sdp' is: immutable
Provisioned SDP type
Warning: Modifying this element recreates 'configure service pw-template "PW 1"'
automatically for the new value to take effect.
-
When the provisioned-sdp use option is configured, the tunnel manager is forced to look for a provisioned and active SDP to the far-end PE. The far-end PE is auto-discovered from the BGP next hop. If multiple SDPs are active to this far-end PE, the tunnel manager chooses the SDP template with the best metric. If there is a tie, the SDP ID is used as a tie-breaker and the highest SDP ID wins. However, if no provisioned SDP exists, the SDP binding will not be instantiated.
-
When the provisioned-sdp prefer option is configured, the behavior is the same when a provisioned SDP exists. When the tunnel manager finds an existing matching SDP, it will use it even if it is operationally down. Only when no provisioned SDP exists, will the SDP binding be auto-created.
-
When a PW template is configured without the provisioned-sdp use or provisioned-sdp prefer option, the SDP bindings will be auto-created.
LDP VPLS using BGP-AD with provisioned-sdp use option shows the following use case: the metro Ethernet networks were initially built with provisioned SDPs. Intra-metro services are provisioned using provisioned SDPs; for example, customer X has a VPLS service defined in the metro Ethernet networks, using BGP-AD with a PW template to use the provisioned SDPs in the metro Ethernet networks.
The service provider initially started with PE-10 and PE-11 in metro Ethernet 1, but now wants to add PE-20 and PE-30 as new sites to the VPLS service. Therefore, the BGP-AD routes should propagate beyond the boundaries of the metro Ethernet network. The backbone network may be in a different AS, but in this example, all networks are in the same AS. VPLS 1 of customer X can have sites added to the service on PEs in different metro Ethernet networks. A new PW template is configured with the provisioned-sdp prefer option and applied to the VPLS service.
-
When a new site within the metro Ethernet network is added, an SDP is already provisioned to this site and this SDP is used for the SDP binding in the VPLS.
-
When a new site in a different metro Ethernet network is added, no SDP is available to the site in the remote metro Ethernet network and the SDP binding is auto-created.
LDP VPLS using BGP-AD with provisioned-sdp prefer option shows the SDP bindings in VPLS 1 between PE-10 and the other PEs. For simplicity, the SDP bindings between the other PEs are not shown.
When PW templates are in use, it is not possible to modify the provisioned-sdp prefer option to provisioned-sdp use and vice versa. To support migration from one PW template to another with minimal service impact, two PW templates can be applied in parallel, as shown in the Configuration section.
Configuration
Example topology shows the example topology. For simplicity, all nodes are in the same AS.
The initial configuration includes the following:
-
Cards, MDAs, ports
-
Router interfaces
-
IS-IS as IGP (or OSPF) on all interfaces
-
MPLS and RSVP on all interfaces, except "int-P-4-P-6" and "int-P-5-P-6".
-
LDP on all interfaces
BGP is configured on all PE routers for address family l2-vpn, as follows:
# on PE-1, PE-2, PE-3:
configure {
router "Base" {
autonomous-system 64496
bgp {
group "internal" {
peer-as 64496
family {
l2-vpn true
}
}
neighbor "192.0.2.6" {
group "internal"
}
}
The BGP configuration on the route reflector (RR) P-6 is as follows:
# on P-6:
configure {
router "Base" {
autonomous-system 64496
bgp {
group "rr-internal" {
peer-as 64496
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 and PE-2 in metro Ethernet network 1, an RSVP LSP is created that is used in a manually created SDP. The LSP configuration on PE-1 is as follows:
# on PE-1:
configure {
router "Base" {
mpls {
admin-state enable
path "loose" {
admin-state enable
}
lsp "LSP-PE-1-PE-2" {
admin-state enable
type p2p-rsvp
to 192.0.2.2
primary "loose" {
}
}
}
On PE-1, SDP 12 is configured as follows:
# on PE-1:
configure {
service {
sdp 12 {
admin-state enable
description "SDP12 to 192.0.2.2"
delivery-type mpls
far-end {
ip-address 192.0.2.2
}
lsp "LSP-PE-1-PE-2" { }
}
The configuration on PE-2 is similar.
LDP VPLS using AD without provisioned-sdp prefer option
Initially, the following two PW templates are configured on all PEs: PW template 1 has the provisioned-sdp use option and PW template 2 is configured without any option; therefore, SDP bindings will be auto-created.
# on PE-1, PE-2, PE-3:
configure {
service {
pw-template "PW 1" {
pw-template-id 1
provisioned-sdp use
}
pw-template "PW 2" {
pw-template-id 2
}
The following lists the PW templates configured on PE-1:
[/]
A:admin@PE-1# show service pw-template
===============================================================================
PW Template information
===============================================================================
PW Template Id SDP Last Update
-------------------------------------------------------------------------------
1 Use-provisioned 04/01/2021 16:35:27
2 Auto-mpls 04/01/2021 15:33:56
===============================================================================
On all PEs, two VPLS services are configured: VPLS 1 with BGP-AD PW template 1 and VPLS 2 with PW template 2, as follows:
# on PE-1, PE-2, PE-3:
configure {
service {
vpls "VPLS 1" {
admin-state enable
service-id 1
customer "1"
bgp 1 {
route-distinguisher "64496:1"
route-target {
export "target:64496:1"
import "target:64496:1"
}
pw-template-binding "PW 1" {
}
}
bgp-ad {
admin-state enable
vpls-id "64496:1"
}
sap 1/2/1:1 {
}
}
vpls "VPLS 2" {
admin-state enable
service-id 2
customer "1"
bgp 1 {
route-distinguisher "64496:2"
route-target {
export "target:64496:2"
import "target:64496:2"
}
pw-template-binding "PW 2" {
import-rt ["target:64496:2"]
}
}
bgp-ad {
admin-state enable
vpls-id "64496:2"
}
sap 1/2/1:2 {
}
}
On PE-1, the following SDP bindings have been created:
[/]
A:admin@PE-1# show service sdp-using
===============================================================================
SDP Using
===============================================================================
SvcId SdpId Type Far End Opr I.Label E.Label
State
-------------------------------------------------------------------------------
1 12:4294967295 BgpAd 192.0.2.2 Up 524280 524280
2 32766:4294967293 BgpAd 192.0.2.3 Up 524278 524280
2 32767:4294967294 BgpAd 192.0.2.2 Up 524279 524279
-------------------------------------------------------------------------------
Number of SDPs : 3
-------------------------------------------------------------------------------
===============================================================================
The first SDP binding is created by BGP-AD in VPLS 1 and uses the configured SDP 12 with far-end PE-2; the other two SDP bindings have been auto-created by BGP-AD in VPLS 2 and have far-end PE-2 and PE-3.
The list of SDP bindings on PE-2 looks similar:
[/]
A:admin@PE-2# show service sdp-using
===============================================================================
SDP Using
===============================================================================
SvcId SdpId Type Far End Opr I.Label E.Label
State
-------------------------------------------------------------------------------
1 21:4294967295 BgpAd 192.0.2.1 Up 524280 524280
2 32766:4294967293 BgpAd 192.0.2.3 Up 524278 524281
2 32767:4294967294 BgpAd 192.0.2.1 Up 524279 524279
-------------------------------------------------------------------------------
Number of SDPs : 3
-------------------------------------------------------------------------------
===============================================================================
On PE-3, there are only two SDP bindings, both in VPLS 2:
[/]
A:admin@PE-3# show service sdp-using
===============================================================================
SDP Using
===============================================================================
SvcId SdpId Type Far End Opr I.Label E.Label
State
-------------------------------------------------------------------------------
2 32766:4294967294 BgpAd 192.0.2.2 Up 524281 524278
2 32767:4294967295 BgpAd 192.0.2.1 Up 524280 524278
-------------------------------------------------------------------------------
Number of SDPs : 2
-------------------------------------------------------------------------------
===============================================================================
Log "99" on PE-3 shows that the system failed to create a dynamic BGP-L2VPN SDP binding because no provisioned SDP was found, as follows:
69 2021/04/01 16:36:44.405 CEST MAJOR: SVCMGR #2322 Base
"The system failed to create a dynamic bgp-l2vpn SDP Bind in service 1 with SDP pw-template policy 1 for the following reason: suitable manual SDP not found."
SDP bindings in VPLS 1 with provisioned-sdp use option shows the SDPs used in VPLS 1. PE-1 and PE-2 both used the provisioned SDP. PE-3 has no SDP bindings in VPLS 1.
Auto-created SDP bindings in VPLS 2 shows the auto-created SDP bindings in VPLS 2. Each PE has two auto-created SDP bindings to each other PE.
Migrate VPLS 1 to provisioned-sdp prefer option
VPLS 1 uses PW template 1 with the provisioned-sdp use option. This option cannot be modified when the PW template is in use, as follows:
[ex:/configure service pw-template "PW 1"]
A:admin@PE-1# provisioned-sdp prefer
*[ex:/configure service pw-template "PW 1"]
A:admin@PE-1# commit
MINOR: SVCMGR #5609: configure service vpls "VPLS 1" bgp 1 pw-template-binding "PW 1" - PW Template is in use
The following steps are needed to migrate to another PW template with the provisioned-sdp prefer option without service outage:
-
Configure new PW template with provisioned-sdp prefer option.
-
Add new PW template binding to VPLS and verify which PW template is used.
-
Modify old PW template binding to make it not usable.
-
Launch tools command to re-evaluate old PW template in the VPLS.
-
When the old PW template is not used anymore, remove PW template binding from the VPLS configuration.
A new PW template with the provisioned-sdp prefer option is configured on all PEs, as follows:
# on PE-1, PE-2, PE-3:
configure {
service {
pw-template "PW 10" {
pw-template-id 10
provisioned-sdp prefer
}
An additional PW template binding is configured in VPLS 1 on all PEs, as follows:
# on PE-1, PE-2, PE-3:
configure {
service {
vpls "VPLS 1" {
bgp 1 {
pw-template-binding "PW 10" {
}
}
}
The configuration of VPLS 1 includes two PW template bindings, as follows:
[ex:/configure service vpls "VPLS 1"]
A:admin@PE-1# info
admin-state enable
service-id 1
customer "1"
bgp 1 {
route-distinguisher "64496:1"
route-target {
export "target:64496:1"
import "target:64496:1"
}
pw-template-binding "PW 1" {
}
pw-template-binding "PW 10" {
}
}
bgp-ad {
admin-state enable
vpls-id "64496:1"
}
sap 1/2/1:1 {
}
The following shows that no additional SDP bindings have been created. The only SDP binding in VPLS 1 on PE-1 uses the provisioned SDP 12.
[/]
A:admin@PE-1# show service id 1 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId Type Far End addr Adm Opr I.Lbl E.Lbl
-------------------------------------------------------------------------------
12:4294967295 BgpAd 192.0.2.2 Up Up 524280 524280
-------------------------------------------------------------------------------
Number of SDPs : 1
-------------------------------------------------------------------------------
===============================================================================
The following shows that PW template 1 was used for the creation of the SDP binding:
[/]
A:admin@PE-1# show service id 1 sdp detail | match 'SDP Id|PW-Template Id'
SDP Id : 12:4294967295 Type : BgpAd
PW-Template Id : 1
The PW template 10 has a higher ID than PW template 1 and is not used. Re-evaluating the PW template binding for PW template 1 in VPLS 1 will make no difference if both PW templates are usable. However, PW template 1 can be made unusable by adding a dummy import-rt not matching any route in the VPLS, as follows:
# on PE-1, PE-2, PE-3:
configure {
service {
vpls "VPLS 1" {
bgp 1 {
pw-template-binding "PW 1" {
import-rt "target:111:111"
}
As a result, PW template 10 with the provisioned-sdp prefer option is used for the automatic creation of SDP bindings where no provisioned SDP is available, as follows:
[/]
A:admin@PE-1# show service id 1 sdp
===============================================================================
Services: Service Destination Points
===============================================================================
SdpId Type Far End addr Adm Opr I.Lbl E.Lbl
-------------------------------------------------------------------------------
12:4294967295 BgpAd 192.0.2.2 Up Up 524280 524280
32766:4294967292 BgpAd 192.0.2.3 Up Up 524277 524279
-------------------------------------------------------------------------------
Number of SDPs : 2
-------------------------------------------------------------------------------
===============================================================================
For the first SDP binding, PW template 1 is used, and for the second SDP binding, PW template 10 is used, as follows:
[/]
A:admin@PE-1# show service id 1 sdp detail | match 'SDP Id|PW-Template Id'
SDP Id : 12:4294967295 Type : BgpAd
PW-Template Id : 1
SDP Id : 32766:4294967292 Type : BgpAd
PW-Template Id : 10
The following command forces the system to re-evaluate PW template 1 in VPLS 1:
[/]
A:admin@PE-1# tools perform service id 1 eval-pw-template 1 allow-service-impact
eval-pw-template succeeded for Svc 1 12:4294967295 Policy 1
As a result, only PW template 10 is used for the creation of SDP bindings in VPLS 1, as follows:
[/]
A:admin@PE-1# show service id 1 sdp detail | match 'SDP Id|PW-Template Id'
SDP Id : 12:4294967291 Type : BgpAd
PW-Template Id : 10
SDP Id : 32766:4294967292 Type : BgpAd
PW-Template Id : 10
PW template 1 is not used anymore and can be removed from the VPLS configuration, as follows:
# on PE-1, PE-2, PE-3:
configure {
service {
vpls "VPLS 1" {
bgp 1 {
delete pw-template-binding "PW 1" {
}
The configuration of VPLS 1 on PE-1 contains only a PW template binding for PW template 10, as follows:
[ex:/configure service vpls "VPLS 1" bgp 1]
A:admin@PE-1# info
route-distinguisher "64496:1"
route-target {
export "target:64496:1"
import "target:64496:1"
}
pw-template-binding "PW 10" {
}
SDP bindings in VPLS 1 with provisioned-sdp prefer option shows the SDP bindings in VPLS 1 with the provisioned-sdp prefer option. Within metro Ethernet network 1, the provisioned SDP is used, and between metro Ethernet networks, auto-created SDP bindings are used.
Conclusion
LDP VPLS using BGP-AD allows the creation of SDP bindings that are either auto-created or that use provisioned SDPs. When the provisioned-sdp prefer option is used, the tunnel manager will look for a provisioned and active SDP to the far end and use it, if available, even if it is down. When no provisioned SDP is available, the system will auto-create an SDP binding.