SRv6-TE EVPN-VPWS

[hermanjanson851]

Hi experts,

In an SRv6 network with uSID, I have configured an EVPN-VPWS. Now, I want to enforce this to follow a strict path via SRv6-TE. I’ve assigned a color to the EVPN route through an extended community and created a policy, but it keeps following the IGP path.

I tested the same setup with an L3VPN, and that worked. When I capture the traffic using wireshark, I can see that the destination IPv6 address contains the SID-list. However, with the EVPN-VPWS, I don’t see this.

I have also tried to configure the strict path using both the Node SID and Adjacency SID, but neither works.

In the test environment, I am using IOS-XRv9K version 7.7.1.

[M02@rt37]

Hello @hermanjanson851 

Ensure  that the transport tunnel for the EVPN-VPWS is correctly configured to use SRv6. In some cases, the service may default to using IGP-based routing unless explicitly told to follow the SRv6-TE path.

[hermanjanson851]

Hello M02@rt37 

Thank you for your response.

Below i added the configuration and output of the EVPN-VPWS:

l2vpn
 xconnect group vpws
  p2p cust1
   interface GigabitEthernet0/0/0/0
   neighbor evpn evi 1000 target 112 source 111 segment-routing srv6

Group vpws, XC cust1, state is up; Interworking none
AC: GigabitEthernet0/0/0/0, state is up
Type Ethernet
MTU 1500; XC ID 0x2; interworking none
Statistics:
packets: received 35040, sent 35020
bytes: received 3541405, sent 3538232
EVPN: neighbor ::ffff:10.0.0.1, PW ID: evi 1000, ac-id 112, state is up ( established )
XC ID 0xa0000003
Encapsulation SRv6
Encap type Ethernet
Ignore MTU mismatch: Enabled
Transmit MTU zero: Enabled
Reachability: Up

SRv6 Local Remote
---------------- ---------------------------- --------------------------
uDX2 fcbb:fa00:111:e000:: fcbb:fa00:112:e000::
AC ID 111 112
MTU 1514 0
Locator CLASSIC_IGP N/A
Locator Resolved Yes N/A
SRv6 Headend H.Encaps.L2.Red N/A
Statistics:
packets: received 35020, sent 35040
bytes: received 3538232, sent 3541405

Then the route is 'colored' with 10 as shown below:

Route Distinguisher: 10.112.112.112:1000
*>i[1][0000.0000.0000.0000.0000][112]/120
                                    2a11:b070:be01:999::112:1 C:10

RP/0/RP0/CPU0:CPE1#show bgp l2vpn evpn rd 10.112.112.112:100 [1][0000.0000.0000.0000.0000][112]/120
Local
2a11:b070:be01:999::112:1 C:10 (bsid: fcbb:fa00:111:e006::) (metric 3000) from 2a11:b070:be01:999::6:1 (10.112.112.112)
Received Label 0xe00000
Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, not-in-vrf
Received Path ID 0, Local Path ID 1, version 60
Extended community: Color:10 EVPN L2 ATTRS:0x02:0 RT:64512:1000
Originator: 10.112.112.112, Cluster list: 10.66.66.66
SR policy color 10, up, not-registered, bsid fcbb:fa00:111:e006::

PSID-Type:L2, SubTLV Count:1
SubTLV:
T:1(Sid information), Sid:fcbb:fa00:112::, Behavior:65, SS-TLV Count:1
SubSubTLV:
T:1(Sid structure):

Finally a policy is created to follow a strict-path:

segment-routing
 traffic-eng
  segment-lists
   srv6
    sid-format usid-f3216
   !
  segment-list CPE1-PE1-P1-PE2-CPE2
   srv6
    index 10 sid fcbb:fa00:11::
    index 20 sid fcbb:fa00:1::
    index 30 sid fcbb:fa00:12::
   !
  !
 !
 policy CPE1-to-CPE2-EVPN-VPWS
  srv6
   locator CLASSIC_IGP binding-sid dynamic behavior ub6-insert-reduced
  !
  source-address ipv6 2a11:b070:be01:999::111:1
  color 10 end-point ipv6 2a11:b070:be01:999::112:1
  candidate-paths
   preference 100
    explicit segment-list CPE1-PE1-P1-PE2-CPE2

[M02@rt37]

Thanks @hermanjanson851 

The binding SID (fcbb:fa00:111:e006::) is dynamically assigned with the CLASSIC_IGP locator. This may mean that even though the policy is applied, it might still default to an IGP path due to how the locator is set. You could try using a specific SRv6 locator (different from CLASSIC_IGP) to ensure that the policy follows the intended SRv6-TE path.

srv6
locator SRv6_TE
binding-sid dynamic behavior ub6-insert-reduced

This ensures that SRv6-TE locators are used specifically for transport.

[hermanjanson851]

Hi M02@rt37,

I've tested it with a seperate locator, but with no success.

What i did not mention in my previous post is that it does work with a L3VPN with the CLASSIC_IGP locator.