Although it was previously recommended that vpws-service-id should be unique across the Ethernet VPN network, for example in each router and in all routers in the network, customers may find it difficult to generate and maintain such uniqueness.
This article demonstrates that duplicate vpws-service-ids can be used for the EVPN-VPWS service without any problems.
Note: See Configuring VPWS with EVPN Signaling Mechanisms and Example: Configuring VPWS with EVPN Signaling Mechanisms for configuration reference.
An EVPN instance (EVI) is an EVPN routing and forwarding instance that spans all the PE routers that are participating in that VPN. An EVI is configured on the PE routers on a per-customer basis.
The virtual private wire service (VPWS) service identifier identifies the endpoints of the EVPN-VPWS network. These endpoints are autodiscovered by the Border Gateway Protocol (BGP), and are used to exchange the service labels (learned from the respective PE routers) that are used by the autodiscovered routes per EVI route type.
Due to each EVI having a unique route distinguisher and one or more route targets, duplicate vpws-service-ids will not affect the EVPN-VPWS service.
An example of two EVPN instances using the same vpws-service-id on one router is shown here. This example shows how to implement virtual private wire service (VPWS) with Ethernet virtual private network (EVPN) signaling using duplicate vpws-service-ids in two EVIs.
The example uses a topology that consists of two PE routers and four CE routers. Routers CE1 and CE2 are single-homed to Routers PE1; Routers CE3 and CE4 are single-homed to Routers PE2. CE1 and CE3 are in the same EVI, and CE2 and CE4 are in another EVI. The two EVI VPWS-1 and VPWS-2 use the same local and remote vpws-service-id.
labroot@PE1# show routing-instances
VPWS-1 {
instance-type evpn-vpws;
interface ge-0/0/1.71;
route-distinguisher 198.100.100.1:11;
vrf-target target:100:11;
protocols {
evpn {
interface ge-0/0/1.71 {
vpws-service-id {
local 9999;
remote 1111;
}
}
}
}
}
VPWS-2 {
instance-type evpn-vpws;
interface ge-0/0/0.72;
route-distinguisher 198.100.100.1:12;
vrf-target target:100:12;
protocols {
evpn {
interface ge-0/0/0.72 {
vpws-service-id {
local 9999;
remote 1111;
}
}
}
}
}
labroot@PE2# show routing-instances
VPWS-1 {
instance-type evpn-vpws;
interface ge-0/0/0.71;
route-distinguisher 198.200.200.2:11;
vrf-target target:100:11;
protocols {
evpn {
interface ge-0/0/0.71 {
vpws-service-id {
local 1111;
remote 9999;
}
}
}
}
}
VPWS-2 {
instance-type evpn-vpws;
interface ge-0/0/1.72;
route-distinguisher 198.200.200.2:12;
vrf-target target:100:12;
protocols {
evpn {
interface ge-0/0/1.72 {
vpws-service-id {
local 1111;
remote 9999;
}
}
}
}
}
labroot@PE1> show evpn vpws-instance
Instance: VPWS-1
Route Distinguisher: 198.100.100.1:11
Number of local interfaces: 1 (1 up)
Interface name ESI Mode Role Status
ge-0/0/1.71 00:00:00:00:00:00:00:00:00:00 single-homed Primary Up
Local SID: 9999 Advertised Label: 299904
Remote SID: 1111
PE addr ESI Label Mode Role TS Status
198.200.200.2 00:00:00:00:00:00:00:00:00:00 299808 single-homed Primary 2019-05-15 20:26:41.894 Resolved
Instance: VPWS-2
Route Distinguisher: 198.100.100.1:12
Number of local interfaces: 1 (1 up)
Interface name ESI Mode Role Status
ge-0/0/0.72 00:00:00:00:00:00:00:00:00:00 single-homed Primary Up
Local SID: 9999 Advertised Label: 299936
Remote SID: 1111
PE addr ESI Label Mode Role TS Status
198.200.200.2 00:00:00:00:00:00:00:00:00:00 299840 single-homed Primary 2019-05-15 20:26:41.895 Resolved
labroot@PE1> show route table bgp.evpn.0
bgp.evpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1:198.200.200.2:11::0::1111/192 AD/EVI
*[BGP/170] 00:27:13, localpref 100, from 198.200.200.2
AS path: I, validation-state: unverified
> to 10.0.1.2 via ge-0/0/2.70, label-switched-path to-pe2
1:198.200.200.2:12::0::1111/192 AD/EVI
*[BGP/170] 00:27:13, localpref 100, from 198.200.200.2
AS path: I, validation-state: unverified
> to 10.0.1.2 via ge-0/0/2.70, label-switched-path to-pe2
labroot@PE1> show route table VPWS-1.evpn.0
VPWS-1.evpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1:198.100.100.1:11::0::9999/192 AD/EVI
*[EVPN/170] 17:43:01
Indirect
1:198.200.200.2:11::0::1111/192 AD/EVI
*[BGP/170] 00:27:42, localpref 100, from 198.200.200.2
AS path: I, validation-state: unverified
> to 10.0.1.2 via ge-0/0/2.70, label-switched-path to-pe2
labroot@PE1> show route table VPWS-2.evpn.0
VPWS-2.evpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1:198.100.100.1:12::0::9999/192 AD/EVI
*[EVPN/170] 17:43:05
Indirect
1:198.200.200.2:12::0::1111/192 AD/EVI
*[BGP/170] 00:27:46, localpref 100, from 198.200.200.2
AS path: I, validation-state: unverified
> to 10.0.1.2 via ge-0/0/2.70, label-switched-path to-pe2
Verification
-
Verify that the PE devices have exchanged and learned the service identifiers, and established the VPWS.
-
Verify that the autodiscovery information is being shared across the VPWS.
-
Verify that both local and remote reachability information is being added into the EVPN table.