cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
935
Views
0
Helpful
3
Replies

About the SID format of SRv6 End DT4 T.Encaps / NCS5501 xr7.2.2

ksiino
Level 1
Level 1

I am building L3vpn using SRv6. The vpnv4 route information of the opposite PE is obtained from RR as shown below.

 

RP/0/RP0/CPU0:5G-PE2#show bgp vrf THU 172.16.0.1/32 detail
Sat Feb 5 20:50:00.313 JST
BGP routing table entry for 172.16.0.1/32, Route Distinguisher: 17676:4100
Versions:
Process bRIB/RIB SendTblVer
Speaker 362 362
Flags: 0x00041001+0x00000000;
Last Modified: Feb 5 20:49:53.552 for 00:00:06
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Flags: 0x4000000085060005, import: 0x9f
Not advertised to any peer
Local
2400:2020:ad3:202:41:0:5300:0 (metric 20000) from 2400:2020::1234:1 (192.168.0.1), if-handle 0x00000000
Received Label 0x4101
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 362
Extended community: RT:17676:4100
Originator: 192.168.0.1, Cluster list: 192.168.0.1
PSID-Type:L3, SubTLV Count:1, R:0x00,
SubTLV:
T:1(Sid information), Sid:2400:2020:ad3:202:41:0:5300:0, F:0x00, R2:0x00, Behavior:111, R3:0x00, SS-TLV Count:1
SubSubTLV:
T:1(Sid structure):
Length [Loc-blk,Loc-node,Func,Arg]:[40,24,16,48], Tpose-len:16, Tpose-offset:64
Source AFI: VPNv4 Unicast, Source VRF: TH, Source Route Distinguisher: 17676:4100

---

 

And you can see that it is in the state of "T.Encaps.Red SID-list {2400: 2020: ad3: 202: 41: 0: 53: 00}" even on CEF as shown below.However, as you can see in the attached capture file, the ipv6 dest address is "2400: 2020: ad3: 202: 41 ::". I want /128 up to the argument field to be the dst address.
What should i do?

 

 

 

---

RP/0/RP0/CPU0:5G-PE2#show cef vrf TH 172.16.0.1/32 detail
Sat Feb 5 20:51:01.846 JST
172.16.0.1/32, version 233, SRv6 Transit, internal 0x5000001 0x30 (ptr 0xa94d9478) [1], 0x0 (0x0), 0x0 (0xa3817180)
Updated Feb 5 20:49:53.582
Prefix Len 32, traffic index 0, precedence n/a, priority 3
gateway array (0xa93ed190) reference count 1, flags 0x2010, source rib (7), 0 backups
[1 type 3 flags 0x48441 (0x8a941f48) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Feb 5 20:49:53.582
LDI Update time Feb 5 20:49:53.583

Level 1 - Load distribution: 0
[0] via 2400:2020:ad3:202::/128, recursive

via 2400:2020:ad3:202::/128, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0x8a46b090 0x0]
next hop VRF - 'default', table - 0xe0800000
next hop 2400:2020:ad3:202::/128 via 2400:2020:ad3:202::/64
SRv6 T.Encaps.Red SID-list {2400:2020:ad3:202:41:0:5300:0}★

Load distribution: 0 (refcount 1)

Hash OK Interface Address
0 Y Bundle-Ether300 fe80::1

 

3 Replies 3

Harold Ritter
Cisco Employee
Cisco Employee

Hi @ksiino ,

 

The destination address you are seeing in the Wireshark looks like the proper one and should correspond to the End.DT4 or End.DX4 on the egress PE.

 

2400:2020:ad3:202:41::

 

You can verify that by issuing a "show segment-routing srv6 sid" on the egress PE.

 

What is strange is that your BGP next hop is in the range of this SID.

 

SID: 2400:2020:ad3:202:41::

BGP NH: 2400:2020:ad3:202:41:0:5300:0

 

Make sure you configure loopback address you use for BGP peering outside of the locator used for SRv6.

 

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hi @Harold Ritter 

 

Actually, this route is publicized by GOBGP. Therefore, the format may be a little strange.

I routed the SID "2400:2020:ad3:202:41:0:5300:0" advertised from GOBGP to the opposite PE,
I want to use argument feild "0:5300:0" on the opposite PE.

 

Therefore, the ipv6 dest address of the packet sent by the T.Encap router is
It should be "2400:2020:ad3:202:41:0:5300:0" instead of "2400:2020:ad3:202:41 ::".
Is this not possible with END DT4? If not, can you suggest any other ideas?

Thanks for the additional info @ksiino ,

 

I now understand what you are trying to achieve. Unfortunately, it looks like IOS-XR does not currently support the argument and will simply ignore the last 48 bits of the SID. I would suggest contacting your Cisco account team, so they can submit a feature request.

 

Regards,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México