cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
408
Views
5
Helpful
5
Replies
Highlighted
Beginner

XRv9000 7.1.1 TI-LFA tiebreaker dis-regards SRLG-Disjoint due to Global weighted SRLG

Hello All,

 

Here is my topology running Segment-Routing with TI-LFA (Node + SRLG-Disjoint).

 

SR with TI-LFA (Node+SRLG-Disjoint)SR with TI-LFA (Node+SRLG-Disjoint)

  • P2 is running XRv9000 7.1.1
  • Rest of the routers are IOS-XRv 6.1.2

Here is the tiebreaker scenario.

 

TI-LFA Tiebreaker (Node vs SRLG-Disjoint)TI-LFA Tiebreaker (Node vs SRLG-Disjoint)

  • PE5 prefix-SID: 16005
  • Traffic between PE1 to PE5
  • TI-LFA backup path computation on P2

 

SRLG-Disjoint Preferred

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)#

 

Node-Protection Preferred

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.

Introduce Global Weighted SRLG

 

SRLG-Disjoint + Global Weighted SRLGSRLG-Disjoint + Global Weighted SRLG

  • Manually configured remote SRLG on P2, as P-RR3 does not support (running XRv 6.1.2)
  • Enable Global weighted SRLG on P2
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

 

SRLG-Disjoint + Global Weighted SRLG + Node ProtectionSRLG-Disjoint + Global Weighted SRLG + Node Protection

 

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)#

 

Questions:

  • How node+srlg backup path is available?
    • Only possible if the local SRLG-Disjoint is totally dis-regarded, which appears to be the case here.
  • How do we factor in both, local and remote SRLGs?

 

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

 

 

5 REPLIES 5
Highlighted
Cisco Employee

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.

Highlighted

Hi Saptarshi,

 

Thanks for your reply.

Please find my response below.

  • Tiebreaker index

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.

 

TI-LFA for ISIS 

 

So higher index results in lower priority and vice versa.

 

  • Backup path computation

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:

  • It is providing node protection, because it is avoiding P-RR3, even though P7 has a better metric to the destination via P-RR3
    • we can rule it out, as the router clearly mentions, node+srlg
  • That could only mean, node+GlobalSRLG, because the local SRLG-disjoint has been clearly disregarded, otherwise it could not have used the link towards P7
    • node protection itself avoids P-RR3, so if the router says the backup path is node+srlg, that means avoid P-RR3 and the link between P-RR3 - P4, for which there is a static remote srlg confirguration present locally on P2
    • Then what about the local SRLG-Disjoint feature?

 

  • Admin-weight

 

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.

 

 

  • Question?

 

The backup path computation question is still open, P2 cannot provide node+srlg concurrently:

  • node protection path goes via P7 but violates the srlg -protection
  • srlg protection path goes via P-RR3 but violates the node-protection

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

 

  • While responding to your note, I realized that I am trying to use the local srlg-disjoint in conjunction with global srlg, which either may not be a supported feature or, not supposed to work this way.
  • I instructed the router P2 to consider SRLG-disjoint for the 3 directly connected links and 1 global srlg link, concurrently.
  • Maybe, when the global SRLG is enabled, even the directly connected links are supposed to be advertised in the ISIS topology, either statically or via isis advertisement cli, because otherwise the LSDB wont have the SRLG information.
  • Then the global srlg protection takes the local srlg-disjoint under its wing and any tiebreaker competition would be between node and global srlg.
  • I believe (at least I'd like to), if I configure global SRLG for the directly connected links, then the backup path computation would prefer SRLG based path because node-protection has lower priority, also check the reverse scenario to give node-protection a better priority.
  • I will test this and come back with an update.

 

Highlighted

I advertised the local as well as remote SRLG mappings in the isis with the help of static provisioning but it did not work.
Removed the SRLG configuration from ISIS, the backup path still goes via P7-P4.
So the bottom line is that the last theory did not work and the 3 questions are still open.
Highlighted

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.

Highlighted

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:

  • local-srlg
  • remote-srlg
  • node 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.

 

 

  • Is it not possible to get the same level of protection in SR+TI-LFA as RSVP-TE provides?
  • SRLG link is used but the backup path computation still says node+srlg, shouldn't that be node-protection only?

 

Regards,

Hemant