sr-te candidate-path switching

[Yvan.hua]

configuration：

segment-routing traffic-eng
segment-list name path1
index 10 mpls prefix 5.5.5.5
index 20 mpls prefix 4.4.4.4
index 30 mpls prefix 6.6.6.6
!
segment-list name path2
index 10 mpls prefix 2.2.2.2
index 20 mpls prefix 6.6.6.6
!
policy test
color 81 end-point 6.6.6.6
candidate-paths
preference 10
explicit segment-list path1
!
preference 5
explicit segment-list path2

When I close all interfaces in 4.4.4.4, the candidate path does not switch.

I found in the book that only the first node is checked by default. If the first node fails, the candidate path will be switched. However, the administrator can set a mandatory check on all nodes.

What command should I use

Cisco IOS XE Software, Version 17.06.04

[Harold Ritter]

Hi @Yvan.hua ,

Only the first hop is validated if the the SID list is expressed as MPLS labels. The whole list is validated if the SID list is expressed as IP addresses. You can see this rule on page 45 of the following presentation:

https://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/

Can you do a "show segment-routing traffic-eng policy name test detail" after closing all interfaces on 4.4.4.4?

Regards,

[Yvan.hua]

Hi Harold,

 Yes, I have seen the same description in the book0--“Only the first hop is validated if the the SID list is expressed as MPLS labels”

I retested and found that the candidate paths would switch.

In the previous test, I waited for a few minutes and found that the candidate path did not switch, so I thought it would not switch。

I closed all interfaces in 4.4.4.4 at 9:10, and the path switched at 9:28.

R3#show segment-routing traffic-eng policy all detail
Name: test (Color: 81 End-point: 6.6.6.6)
Owners : CLI
Status:
Admin: up, Operational: up for 16:30:46 (since 09-27 17:33:04.499)
Candidate-paths:
Preference 10 (CLI):
Explicit: segment-list path1 (inactive)
Inactive Reason: Prefix cannot be resolved
Weight: 1, Metric Type: TE
Preference 5 (CLI):
Explicit: segment-list path2 (active)
Weight: 1, Metric Type: TE
16200 [Prefix-SID, 2.2.2.2]
16600 [Prefix-SID, 6.6.6.6]
Attributes:
Binding SID: 16
Allocation mode: dynamic
State: Programmed
IPv6 caps enabled
Tunnel ID: 65536 (Interface Handle: 0x12)
Per owner configs:
CLI
Binding SID: dynamic
Stats:
5 minute output rate 0 bits/sec, 0 packets/sec
Packets: 22031 Bytes: 2679566

Event history:
Timestamp Client Event type Context: Value
--------- ------ ---------- -------: -----
09-27 17:32:10.292 CLI Policy created Name: CLI
09-27 17:32:10.364 CLI Set colour Colour: 1
09-27 17:32:10.364 CLI Set end point End-point: 6.6.6.6
09-27 17:32:10.524 CLI Set explicit path Path option: path1
09-27 17:32:10.538 CLI BSID allocated FWD: label 16
09-27 17:32:10.538 FH Resolution Policy state UP Status: PATH RESOLVED CP: 10
09-27 17:32:11.606 CLI Set explicit path Path option: path2
09-27 17:33:04.498 CLI Set colour Colour: 0
09-27 17:33:04.498 CLI Set end point End-point: 0.0.0.0
09-27 17:33:04.499 FH Resolution Policy state DOWN Status: PATH NOT RESOLVED
09-27 17:33:08.257 CLI Set colour Colour: 81
09-27 17:33:08.257 CLI Set end point End-point: 6.6.6.6
09-27 17:33:08.265 FH Resolution Policy state UP Status: PATH RESOLVED CP: 10
09-27 17:36:30.368 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 17:44:16.130 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 17:46:11.221 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 17:48:44.140 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 17:51:35.248 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 17:51:44.684 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 5
09-27 17:56:34.897 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 5
09-27 17:56:42.252 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 17:56:42.260 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 17:57:28.315 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 18:05:48.343 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 18:07:42.113 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 18:07:51.548 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 5
09-27 18:12:42.104 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 5
09-27 18:12:46.576 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 18:12:46.584 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 18:17:06.185 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-27 18:27:17.171 CLI Remove path option Path option: 2
09-27 18:32:48.635 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 5
09-28 09:08:29.424 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 5
09-28 09:08:35.844 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-28 09:08:35.851 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-28 09:10:04.420 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 10
09-28 09:28:37.349 FH Resolution REOPT triggered Status: REOPTIMIZED CP: 5

I wonder if TI-LFA can solve the problem of too long switching time. I will go to see related books.

By the way, I tested TI-LFA before and configured it in ISIS. If a link fails, there is no packet loss in the candidate path switching. It's great. The configuration is as follows:

router isis
net 49.0000.0000.0000.0003.00
is-type level-2-only
metric-style wide
log-adjacency-changes
distribute link-state level-2
segment-routing mpls
fast-reroute per-prefix level-2 all
fast-reroute ti-lfa level-2
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-2

If you have any good suggestions, please let me know. Thank you for your help

Yvan Hua

[Yvan.hua]

Hi Harold，

I read the TI-LFA materials this afternoon, and I think my question may have nothing to do with TI-LFA.

So,when the router fails (I shut down all interfaces in 4.4.4.4), what does the time required for candidate path switching depend on?

[Harold Ritter · Accepted solution]

Hi @Yvan.hua ,

> So,when the router fails (I shut down all interfaces in 4.4.4.4), what does the time required for candidate path switching depend on?

It would normally be tied to the IGP convergence.

Starting with 17.4, you can configure performance monitoring on the SR policy to test the end to end connectivity and switchover if there is a failure.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/seg_routing/configuration/xe-17/segrt-xe-17-book/m-sr-performance-measurement.html#verificationendtoenddelaymeasurement

Regards,

[Yvan.hua]

Hi Harold，

     >Starting with 17.4, you can configure performance monitoring on the SR policy to test the end to end connectivity and switchover if there is a failure.

I have tested the use of the end to end delay to switch candidate paths. After performance measurement is enabled for all interfaces, performance measurement is also enabled in the sr policy.Very nice!

thanks for you help

Yvan Hua

[Yvan.hua]

ha-ha, I misunderstood you. I thought you asked me to choose the candidate path according to the delay.

I have just tested, added some configurations, and then can switch candidate paths normally.

Thank you very much for your help!!

configuration：

policy test
color 81 end-point 6.6.6.6
candidate-paths
preference 10
explicit segment-list path1
!
preference 5
explicit segment-list path2
!
!
!
performance-measurement
 delay-measurement
  liveness-detection
  invalidation-action down

[Elvin Arias Soto]

Harold hit it, as usual. ; )

That is the main thing, see this document also, case #1 it explains it.

https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/213935-configuring-non-path-computation-element.html

Elvin

[Yvan.hua]

Thanks for your reply, but ios xe doesn't seem to support PCE configuration, so I didn't test it.