06-05-2020 08:37 AM - edited 06-06-2020 01:23 AM
Hello All,
Here is my topology running Segment-Routing with TI-LFA (Node + SRLG-Disjoint).
Here is the tiebreaker scenario.
RP/0/RP0/CPU0:P2(config)#do sh run router isis
Tue May 12 22:02:21.985 UTC
router isis IGP
<..snipped..>
fast-reroute per-prefix tiebreaker node-protecting index 200
fast-reroute per-prefix tiebreaker srlg-disjoint index 100
The TI-LFA (srlg) protection path is via P9 & P-RR3 onwards
RP/0/RP0/CPU0:P2(config)#do sh isis fast-reroute 5.5.5.5/32 detail
Wed May 13 00:51:46.390 UTC
L2 5.5.5.5/32 [30/115] medium priority
via 23.0.0.3, GigabitEthernet0/0/0/0, P-RR3, SRGB Base: 16000, Weight: 0
Backup path: TI-LFA (srlg), via 29.0.0.9, GigabitEthernet0/0/0/5 P9, SRGB Base: 16000, Weight: 0
P node: P9.00 [9.9.9.9], Label: ImpNull
Q node: P-RR3.00 [3.3.3.3], Label: 24022
Prefix label: 16005
Backup-src: PE5.00
P: No, TM: 130, LC: No, NP: No, D: No, SRLG: Yes
src PE5.00-00, 5.5.5.5, prefix-SID index 5, R:0 N:1 P:0 E:0 V:0 L:0
RP/0/RP0/CPU0:P2(config)#
router isis IGP
address-family ipv4 unicast
fast-reroute per-prefix tiebreaker srlg-disjoint index 255
Backup path changes to Node Protection, via P7 and P4
RP/0/RP0/CPU0:P2(config)#do sh isis fast-reroute 5.5.5.5/32 detail
Wed May 13 01:00:00.310 UTC
L2 5.5.5.5/32 [30/115] medium priority
via 23.0.0.3, GigabitEthernet0/0/0/0, P-RR3, SRGB Base: 16000, Weight: 0
Backup path: TI-LFA (node), via 27.0.0.7, GigabitEthernet0/0/0/3 P7, SRGB Base: 16000, Weight: 0
P node: P7.00 [7.7.7.7], Label: ImpNull
Q node: P4.00 [4.4.4.4], Label: 24001
Prefix label: 16005
Backup-src: PE5.00
P: No, TM: 120, LC: No, NP: Yes, D: No, SRLG: No
src PE5.00-00, 5.5.5.5, prefix-SID index 5, R:0 N:1 P:0 E:0 V:0 L:0
RP/0/RP0/CPU0:P2(config)#
So far so good!!!
Tiebreaker between Node-Protection and SRLG-Disjoint works fine.
Removed node-protection and srlg-disjoint both.
SRLG-Disjoint + Global Weighted SRLG Protection also works fine.
router isis IGP address-family ipv4 unicast fast-reroute per-prefix srlg-protection weighted-global
router isis IGP address-family ipv4 unicast fast-reroute per-prefix tiebreaker srlg-disjoint index 100
router isis IGP srlg
router isis IGP srlg name SRLG-100
router isis IGP srlg name SRLG-100 static ipv4 address 34.0.0.3 next-hop ipv4 address 34.0.0.4
RP/0/RP0/CPU0:P2(config)# do sh isis fast-reroute 5.5.5.5/32 detail
Fri Jun 5 15:24:26.693 UTC
L2 5.5.5.5/32 [30/115] Label: 16005, medium priority
via 23.0.0.3, GigabitEthernet0/0/0/0, Label: 16005, P-RR3, SRGB Base: 16000, Weight: 0
Backup path: TI-LFA (srlg), via 29.0.0.9, GigabitEthernet0/0/0/5 P9, SRGB Base: 16000, Weight: 0, Metric: 230
Backup tunnel: tunnel-te32824
P node: P9.00 [9.9.9.9], Label: ImpNull
Q node: P-RR3.00 [3.3.3.3], Label: 24001
Q node: P7.00 [7.7.7.7], Label: 24001
Q node: P4.00 [4.4.4.4], Label: 24001
Prefix label: 16005
Backup-src: PE5.00
P: No, TM: 230, LC: No, NP: No, D: No, SRLG: Yes
src PE5.00-00, 5.5.5.5, prefix-SID index 5, R:0 N:1 P:0 E:0 V:0 L:0, Alg:0
RP/0/RP0/CPU0:P2(config)#
So far so good.
Now add node-protection with lower priority
RP/0/RP0/CPU0:P2(config)#do sh run formal router isis | i "tie|srlg"
Fri Jun 5 15:30:11.356 UTC
router isis IGP address-family ipv4 unicast fast-reroute per-prefix srlg-protection weighted-global
router isis IGP address-family ipv4 unicast fast-reroute per-prefix tiebreaker node-protecting index 200
router isis IGP address-family ipv4 unicast fast-reroute per-prefix tiebreaker srlg-disjoint index 100
router isis IGP srlg
router isis IGP srlg name SRLG-100
router isis IGP srlg name SRLG-100 static ipv4 address 34.0.0.3 next-hop ipv4 address 34.0.0.4
RP/0/RP0/CPU0:P2(config)#
RP/0/RP0/CPU0:P2(config)#do sh isis fast-reroute 5.5.5.5/32 detail
Fri Jun 5 15:28:43.211 UTC
L2 5.5.5.5/32 [30/115] Label: 16005, medium priority
via 23.0.0.3, GigabitEthernet0/0/0/0, Label: 16005, P-RR3, SRGB Base: 16000, Weight: 0
Backup path: TI-LFA (node+srlg), via 27.0.0.7, GigabitEthernet0/0/0/3 P7, SRGB Base: 16000, Weight: 0, Metric: 1120
P node: P7.00 [7.7.7.7], Label: ImpNull
Q node: P4.00 [4.4.4.4], Label: 24001
Prefix label: 16005
Backup-src: PE5.00
P: No, TM: 1120, LC: No, NP: Yes, D: No, SRLG: Yes
src PE5.00-00, 5.5.5.5, prefix-SID index 5, R:0 N:1 P:0 E:0 V:0 L:0, Alg:0
RP/0/RP0/CPU0:P2(config)#
It appears the the default admin-weight is 1000, which is why the metric is now 1120.
Then what is this?
RP/0/RP0/CPU0:P2(config)#router isis IGP srlg ?
admin-weight Default administrative weight for all SRLGs, default is 1
name SRLG Name
<cr>
RP/0/RP0/CPU0:P2(config)#
Changed it to 0, but the backup path does not change, still node+srlg, not sure how and why
RP/0/RP0/CPU0:P2(config)#show
Fri Jun 5 15:32:25.519 UTC
Building configuration...
!! IOS XR Configuration 7.1.1
router isis IGP
srlg
name SRLG-100
admin-weight 0
!
!
!
end
RP/0/RP0/CPU0:P2(config)#commit
Fri Jun 5 15:32:26.591 UTC
RP/0/RP0/CPU0:Jun 5 15:32:27.710 UTC: config[69018]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'ios'. Use 'show configuration commit changes 1000000122' to view the changes.
RP/0/RP0/CPU0:P2(config)#do sh isis fast-reroute 5.5.5.5/32 detail
Fri Jun 5 15:32:33.012 UTC
L2 5.5.5.5/32 [30/115] Label: 16005, medium priority
via 23.0.0.3, GigabitEthernet0/0/0/0, Label: 16005, P-RR3, SRGB Base: 16000, Weight: 0
Backup path: TI-LFA (node+srlg), via 27.0.0.7, GigabitEthernet0/0/0/3 P7, SRGB Base: 16000, Weight: 0, Metric: 120
P node: P7.00 [7.7.7.7], Label: ImpNull
Q node: P4.00 [4.4.4.4], Label: 24001
Prefix label: 16005
Backup-src: PE5.00
P: No, TM: 120, LC: No, NP: Yes, D: No, SRLG: Yes
src PE5.00-00, 5.5.5.5, prefix-SID index 5, R:0 N:1 P:0 E:0 V:0 L:0, Alg:0
RP/0/RP0/CPU0:P2(config)#
Please help me understand the above scenario.
Regards,
Hemant
06-13-2020 04:45 PM
A couple of points. A higher priority for a TI-LFA tiebreaker means a numerically higher index value. So when you say that you added node protection with a lower priority than SRLG, the index value used in the corresponding statement should be lower than the one used for SRLG. For example, see below:
fast-reroute per-prefix tiebreaker node-protecting index 100
fast-reroute per-prefix tiebreaker srlg-disjoint index 200 <----- SRLG has higher priority
Also, when you have both node and SRLG disjoint enabled, TI-LFA will try to provision a path that satisfies both. If that is not possible, it tries to provision a path that matches the condition with the highest preference i.e. index value. If even that is not possible, it proceeds to the next highest tiebreaker. If all tiebreakers fail to result in a path, it uses the default tiebreaker, which is link-protection. Note that node-protection always implies link-protection.
As for the 'admin-weight' in the SRLG hierarchy, think of it as a penalty that is applied during backup path computation to the metric of the links that share the same SRLG. The command 'fast-reroute per-prefix srlg-protection weighted-global' enables what is called Global Weighted SRLG(also Remote SRLG). In weighted SRLG, when computing the backup path for a protected link, instead of pruning the links that share the same SRLG value a penalty is applied to the metric configured on those links so as to make them less viable for transport. This means that those links can still be used for backup paths if a path computation that considers the penalty applied to the link metrics results in a shortest path going over those links. Typically the admin-weight, which is the penalty to be applied, is configured explicitly for each of the named SRLG values as shown below. You can also configure a default admin-weight that is to be applied to all SRLG groups that do not have an explicitly defined admin-weight.
srlg admin-weight 500 <------ This is the default admin-weight name RED admin-weight 100 <------ This is the admin-weight for SRLG group named RED ! name BLUE admin-weight 200 ! name GREEN admin-weight 301 ! !
As per documentation and the context sensitive help, in the absence of a configured default admin-weight a value of 1 should be used in ISIS. But in your case it seems to be using a value of 1000, which is resulting in a total metric of 1120. I know for a fact that weighted SRLG in OSPF uses a default value of 1000. So the value of 1 for ISIS may be a documentation error. It may be worthwhile to get a TAC case raised to settle this. Meanwhile, you can try playing around with explicitly defined admin-weights for the various SRLG groups and see if you come across any other abnormalities.
06-14-2020 01:49 AM
Hi Saptarshi,
Thanks for your reply.
Please find my response below.
The following URL explains that the lower index value gets higher priority.
Go to Step 7 under TI-LFA for ISIS also, it worked in all of my scenarios, except remote srlg.
So higher index results in lower priority and vice versa.
You are right, TI-LFA tries to find a backup path which can provide node+srlg+(link, link is always there) protection concurrently and when it is not possible to do that, it comes to the tiebreaker index.
However, in the above topology, there is no way, P2 can have a node+srlg based backup path, because it is not available.
The backup path shows that it is going via P7 & P4, which could have meant either of the two:
Regarding admin-weight, it does seem to add a penalty metric and I'll take another look at the topology to check whether the same is reflected in the LSDB or not. (as it does in case of LDP-IGP sync, advertise max metric till the sync is completed)
Is there any URL you could share which not only supports the reasoning but provides more details about it? I may have not looked harder.
The backup path computation question is still open, P2 cannot provide node+srlg concurrently:
I had introduced node protection with lower priority, so that SRLG path is preferred, but the router computes a node+srlg.
Question 1, How node+srlg protection is available? Is it because of the explanation above, that only global SRLG is considered?
Question 2, There is no separate tiebreaker index configuration for the global SRLG, but it does appear to be a separate entity in the backup path computation, instead of simply supplementing the local srlg disjoint. True? Because as far as I remember, Global SRLG alone is not enabled unless srlg-disjoint tiebreaker is configured to enable the local srlg, so global srlg should be a supporting feature instead of a standalone one.
Question 3, How do we factor in, both, local as well as global SRLG computations along with Node protection for tiebreaker condition?
Regards,
Hemant
P.S
06-14-2020 08:23 AM
06-14-2020 09:19 AM
Yes, the tiebreaker for ISIS is more preferred with a lower index value. I mixed it up with OSPF, which still follows a 'higher index is more preferred' style. In fact, ISIS used to behave the same way as well, until it was changed via CSCvc90919 to bring it more in line with regular LFA and rLFA.
As for your last tests, I'm not sure I follow what they were and the expected results. However, I will reiterate that enabling weighted SRLG means that your links sharing the same SRLG, local or remote, will no longer be excluded from backup path calculation. They will simply have the admin-weight added to them as a penalty. This penalized metric is not actually flooded in the control plane, and is considered only during a local computation. If you consider that a penalty of 1000 is applied by default, it would make sense in your setup that the backup path would be via P7->P4, since all other paths either does not satisfy the node-protection or have a higher metric. As I had suggested, I advise you to play around by configuring a default-admin weight under 'srlg' hierarchy and test this theory out. Let me know if you find any discrepancy and I can start looking deeper.
Also, configured SRLG values are always advertised in the control plane, either in TLV-138 or TLV-238, even if you have only local SRLG values configured. More recent codes will use TLV-238, which is for advertising SRLG in application specific link attribute, and allows you to advertise different SRLG values for the same link to be used by different applications like SR-TE, LFA or RSVP-TE. The only exception to this is when you have manually configured static SRLG for remote links, as in your case. In such instances the SRLG value need not be advertised by the remote node, since the node doing the backup path calculation already knows the SRLG of the remote link by virtue of the configuration.
06-20-2020 05:43 AM - edited 06-20-2020 05:48 AM
Hi Saptarshi,
Thanks for your regular update on this post.
I agree with your explanation, right from the beginning the output has proved that SRLG has been dis-regarded, which would have been fine, if the output did not mention (node+srlg) in the backup path computation but only node-protection.
It is terribly misleading, even if it is trying to just show that a penalized srlg path has been used for it.
In an RSVP-TE based core, when using MPLSTraffic-Eng (RSVP) SRLGs, which is not the same as TLV-238 application-specific SRLG as advertised in SR-ISIS, the routers signal an SRLG based FRR (Fast Re-Route) auto-tunnel backup, which gives us the following protection:
Having said that, TI-LFA tiebreaker disregarding SRLGs and only adding penalty is a step backwards in terms of FRR protection as compared to the RSVP-TE based protection.
Adding Global Weighted SRLG makes the TI-LFA Tiebreaker disregard its own rule, that when all backup path conditions cannot be satisfied concurrently, then the tiebreaker index with higher priority (lowest index) would be chosen.
Regards,
Hemant
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide