OSPF segment routing fails when another command is entered after the initial "on" command. #12007
Closed
1 of 2 tasks
Assignees
Labels
triage
Needs further investigation
Comments
Cheeze-It
changed the title
12 tasks
|
Hi, Do you attempt to run ospf alone? I mean without zebra. In this case, the behavior you observe is normal. Indeed, when Segment Routing is started on ospfd with So, I saw 2 possibles problems:
Can check and verify the 2 points above and provide log for zebra ad ospfd when failure occurs ? i.e. when you configure the SRGB. Regards Olivier |
|
Hello hello @odd22 :)
I personally did not disable Zebra when I ran this. I actually don't know how to disable Zebra, but that's more my lack of knowledge. To my understanding though, Zebra should be running per checking here:
This makes sense. Do we know by chance if this behavior is expected from ISIS as well? I am thinking it might make sense to have a similar behavior between the two daemons but I genuinely don't know if it would.
Yeah, I think what you're describing here is what is occurring. I was able to add configurations without specifying the segment routing global block and it worked properly:
Yessir, I will absolutely check this. Thank you thank you. I have a question on this if I may. Are there specific reservation ranges we should know about or be able to query just so what we can kinda just avoid using them so that we don't any unexpected issues? That would be way faster than necessarily having to put in a PR to FRR over a behavior that isn't really a problem but more of a behavior.
Absolutely sir. Will do. Thank you for the suggestion. I am unsure if I know how to do this but I will ask around and try to figure it out. |
|
Here's something interesting, I think @odd22 you are spot on with your understanding on this. I did a check on the zebra client commands and this is what we see: I will see if I can do the process from up top and see if I can get it to error. |
|
So when I do a debug, here's what we get my good sir: It seems that error code points to here (https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-37/Monitoring-and-Troubleshooting/FRRouting-Log-Message-Reference/) and says: |
|
I feel like imposing a minimum label range for SRGB for a value of 100 can be an extremely easy workaround. I did find the minimum value, it seems to be 80: |
|
I made changes and made the minimum label value 100, that way we have some buffer room for segment routing in ISIS and OSPF. Things seem to work in one commit, separately configured: I am completely ok and happy to keep it at 100 for minimum label value. @odd22, if you feel that the behavior of SR is proper here and then I'm good with this. |
10 tasks
c-po
added a commit
to vyos/vyos-1x
that referenced
this issue
Oct 11, 2022
|
Here's a frustration that I found, a new one. So we did a test to do the same but this time to get 100 - 200 for OSPF: That failed. When I did it for 100-150 it succeeded: I tried it from 100 to 300, and that failed: Tried 100 - 1000, failed: Tried at 200, failed: Tried at 2000, this time it worked: Tried 1000 - 1100, and it worked: Tried 900 - 1000, worked: Tried 150 - 200, failed: Tried 150 - 199, failed: Tried 250 - 300, failed: Tried 250 - 299, failed: Tried 300 - 400, it worked: Tried 300 - 399, it worked: It seems, when under 300, things just get....weird. Maybe we should do a recommended limit of 300 as the minimum for SRGB for OSPF and ISIS just so that we don't run into odd allocation issues? What do you think @odd22? |
|
Hi, This is a good suggestion and simple to fix: just a matter of CLI modification to add verification about lower limit. But, I would investigate more about this problem to determine why lower block allocation is weird. |
|
Thank you my good sir, we will take that suggestion. I'm pretty sure everything else works as expected though. Also, don't work too hard :) |
|
@odd22, seems we might have bigger problems. Per enabling SR on OSPF it seems that adjacency labels are created but prefix labels are not :( Here's my configs on my lab of 8 routers: MPLS interfaces are enabled: Here's the adjacency labels seen: OSPF is working though. Here's the routing tables from all of the routers. These should be the loopbacks, the ones where the prefix SIDs should be announced from: Here's the info from OSPF on segment routing specifically: When I do a debug just on OSPF SR I get the following when I delete and re-add OSPF: Definitely seems rather odd that OSPF won't allocate the prefix SID. It also seems interesting that segment routing information is seemingly not being sent via the LSAs....if I am reading this correctly. Also, if you need more information, or if you'd like to see the lab I have setup I can let you see it and run commands just in case you want to gather more info. Thank you sir. Please reach out if you have any questions :) |
Cheeze-It
changed the title
|
Hello First, apologize for the late reply as I don't get notification of your last update. The problem is simple. It is missing the statement 'capability opaque' in your configuration. Without this explicit configuration, ospfd doesn't advertise Opaque LSA which are used by Segment Routing. Just add the missing configuration and all should work as expected. I'll check if it is clearly mention in the documentation. This is also a remaining old statement that normally should be enabled by default. I remember that there is a Pull Request for that, but perhaps, not yet merged. Regards Olivier |
|
Thank you @odd22, I will absolutely go test this. As long as it works then it's absolutely not at all a problem. I was under the impression that Opaque LSAs are enabled automatically. |
|
@odd22, yessir you are absolutely correct. That DID make things work. Before adding the capability opaque: Afterwards: Here's the routing table before: Here's the routing table after: |
|
I'll change the name of the title to reflect that this is specifically on the label minimums. Thank you @odd22 |
Cheeze-It
changed the title
|
This issue is stale because it has been open 180 days with no activity. Comment or remove the |
|
This issue will be automatically closed in the specified period unless there is further activity. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
To Reproduce
So what ends up happening with this is, in VyOS when we try to add other parts of the configuration inside of segment-routing it just straight up stops working and fails and says:
This causes the FRR reload to fail. Below is the code in VyOS that is used to load configs into FRR using the frr-reload. It basically says that VyOS attempted to frr-reload 5 times and it exceeded. Therefore it stops trying to do the reload because something is absolutely broken:
We can do the failure to show the "OSPF SR is not turned on" error manually as well:
Expected behavior
What we expect is that the command "segment-routing on" stays on and that when we do an FRR reload that everything commits. What we are seeing currently is that FRR seems to remove the "segment-routing on" command when we enter anything else after it. This also causes a fail in FRR reload. We don't expect FRR to reload as well.
These steps work properly in ISIS segment routing. We reused the configurations in ISIS and just modified them to work with OSPF. So we know that they do work as in ISIS it works every single time. But broke in OSPF.
Screenshots
Please read up top in the reproduction steps. That should be sufficient. If not, will provide more data.
Versions
Additional context
This was found here on VyOS PR: vyos/vyos-1x#1551
The text was updated successfully, but these errors were encountered: