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.
vpws-service-id
This article demonstrates that duplicate vpws-service-id s 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-id s 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-id s in two EVIs.
vpws
-service-id
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.
show evpn vpws-instance
Verify that the autodiscovery information is being shared across the VPWS.
show route table bgp.evpn.0
Verify that both local and remote reachability information is being added into the EVPN table.
show route table Routing-instance_name.evpn.0