FRR TI-LFA: When the primary path fails, the backup path does not work

[nanjing2020]

Description

In vtysh: input"do show ip route", the result shows that both the primary（30.30.3.1/24） and backup（20.20.2.1/24） paths exist.

However, in the kernel routing table, input"ip route", only the main primary paths （30.30.3.1/24） exists。

When the primary path fails, the backup path does not work？

Version

FRRoutin verssion 9.2-dev

How to reproduce

interface eth0
ip address 30.30.3.2/24
ip ospf area 0
ip ospf cost 30
ip ospf network point-to-point
!
interface eth1
ip address 20.20.2.2/24
ip ospf area 0
ip ospf cost 31
ip ospf network point-to-point
!
interface lo
ip address 3.3.3.3/32
!
router ospf
ospf router-id 3.3.3.3
fast-reroute ti-lfa
capability opaque
segment-routing on
segment-routing global-block 1000 1999 local-block 300 999
segment-routing node-msd 8
segment-routing prefix 3.3.3.3/32 index 100
router-info area

Expected behavior

When the primary path is disconnected, the backup path takes effect so that the packet is not lost

Actual behavior

When the primary path is disconnected, the secondary path does not work, resulting in packet loss

Additional context

No response

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[Jafaral]

FRR does maintain the two routes correctly, but the Linux kernel doesn't have support for primary/secondary route config. If the primary route fails (link goes down for example), FRR will install the secondary route. Have you tested that behavior? or are you just relying on the info you see in the Linux routing table?

[pguibert6WIND]

FRR does maintain the two routes correctly, but the Linux kernel doesn't have support for primary/secondary route config. If the primary route fails (link goes down for example), FRR will install the secondary route. Have you tested that behavior? or are you just relying on the info you see in the Linux routing table?

adding to this, the take over of backup route is triggered by IS-IS events triggered at IS-IS level.
for instance, BFD failover will be detected, and switchover will take place.

[nanjing2020]

FRR does maintain the two routes correctly, but the Linux kernel doesn't have support for primary/secondary route config. If the primary route fails (link goes down for example), FRR will install the secondary route. Have you tested that behavior? or are you just relying on the info you see in the Linux routing table?

Thank you very much for your comments. We believe that the backup route should be sent to kernel after the primary route failure occurs (link goes down) and before the spf calculation starts. Therefore, we delay the spf calculation start time (command: timer throttle spf 10000 20000 30000). Then, we disable the network interface that belongs to the primary path. and check the ip route table of the kernel. We find Before the spf calculation was complete, the primary route was deleted and the backup route did not exist.

[nanjing2020]

FRR does maintain the two routes correctly, but the Linux kernel doesn't have support for primary/secondary route config. If the primary route fails (link goes down for example), FRR will install the secondary route. Have you tested that behavior? or are you just relying on the info you see in the Linux routing table?

adding to this, the take over of backup route is triggered by IS-IS events triggered at IS-IS level. for instance, BFD failover will be detected, and switchover will take place.

Thank you very much for your comments. We use the OSPF protocol. We simulate a primary path failure by disabling the network interface that belongs to the primary path.

[mjstapp]

So there is no support for backup-paths if you are using the linux kernel. The backup-path work was done to offer LFA information to forwarding planes that support something like fast-reroute, as many asics do. If you have some specific ideas about what you think zebra might safely do with that backup information, please open a feature request.

[nanjing2020]

The backup-path work was done to offer LFA information to forwarding planes that support something like fast-reroute, as many asics do.

Thank you so much for your comments. Do you mean that the kernel does not support LFA, or does the kernel lack something to support LFA. My linux kernel version is 5.4.0.145-generic.

[mjstapp]

The linux kernel doesn't have a concept of "fast reroute", or "repair path". It just has ... routes, and the kernel does not necessarily know if a route stops being valid. There might be ways that FRR could use backup-path information on linux, but nothing in that area exists now. That's why I asked if you have some more detailed ideas about what you think we could do on regular linux.

The backup-path work was done to offer LFA information to forwarding planes that support something like fast-reroute, as many asics do.

Thank you so much for your comments. Do you mean that the kernel does not support LFA, or does the kernel lack something to support LFA. My linux kernel version is 5.4.0.145-generic.

[nanjing2020]

and the kernel does not necessarily know if a route stops being valid.

Thank you very much for your answer. After listening to your comments, I found that what I thought was the primary route and backup route sent to the kernel at the same time was wrong. Thank you very much

[nanjing2020]

FRR does maintain the two routes correctly, but the Linux kernel doesn't have support for primary/secondary route config. If the primary route fails (link goes down for example), FRR will install the secondary route. Have you tested that behavior? or are you just relying on the info you see in the Linux routing table?

May I ask whether ti-lfa can only be used for BGP

[nanjing2020]

Please help me!!!!!!!!!!!!!!!

[mjstapp]

Please: no one has information beyond what has been said. At this time, on linux, the expectation is that a topology (link) change will trigger a routing protocol update, and that will result in a new route (if there is a valid route).

[github-actions]

This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.

[frrbot]

This issue will be automatically closed in the specified period unless there is further activity.