Adding multiple static routes with interface to same non-existent nexthop fail to install correctly #18321
Comments
|
frr.log (look for comments starting with |
|
I disagree staticd should not be installing any routes until the nexthop is valid. |
So in your view, it's still wrong, but you think none of the routes should be visible in "show ip route" until the nexthop is reachable? (So no inactive routes at all in the output?) |
This is not how zebra, staticd, and ZAPI were designed. Daemons submit candidate routes to zebra, zebra resolves and installs them. staticd doesn't even need full NHT, it only needs interface state tracking because we can't submit a nexthop to zebra if the interface doesn't have an ifindex. And because we never wrote down any of this we are now yet again in a situation where we can't answer this question other than with people's opinions, therefore we're don't know what the proper fix for a bug is, and will run into this problem again next time we look at the topic and don't have anything written down. |
|
Actually it is. All upper level protocols are not installing routes until they are actually reachable. static routes pre this change were the only ones that had routes installed that were inactive and I would argue that was a artifact of the implementation instead of any foreplanning from that perspective. |
|
"All upper level protocols" does not make sense here to begin with; this is about unresolved nexthops which can't happen with IS-IS, RIP(ng) or OSPFv3. BGP, staticd and OSPF are the only "classic" protocols where this can happen to begin with. (I'm going to exclude babeld, eigrpd, pbrd & pathd here because I don't know their behavior exactly enough.) OSPF still installs routes (ASEs with 3rd party nexthops) without NHT to this day. They're normally on-link but AFAIR don't have to be. (I'm only 80% confident here, can go look that up at some point.) staticd when it was inside zebra was interwoven with the RIB quite tightly, and the code had to be triggered when nexthops change. When it was isolated out, it "took that code with it", which might not have been the right thing to do to begin with. BGP… is the most complicated setup. It needs NHT in some cases, but in others NHT indirectly substitutes for installation confirmation. But in times before NHT, even BGP just installed routes with no regard to nexthop reachability. There are two issues here:
We've somehow ended up midway between behaviors in staticd right now. Sometimes routes are waiting for NHT, sometimes they're installed inactive in zebra. Clearly this needs to be fixed to consistently be one of the two. But I'd say we really need to answer a few questions here before we make that call. |
Description
When installing multiple static routes to the same non-existent nexthop, only the first route is seen in the routing table (but they are correctly installed in the config).
As soon as another route is installed (to different nexthop), the previously routes show up
Version
How to reproduce
Load a config similar to this. No routing protocols needed, just zebra, mgmtd and staticd.
Please be aware that there is NO default route
Adding 3 routes with the same nexthop and output interface:
Looking at the routes:
--> Only first route is seen
Now adding a 4th route with a different nexthop:
and all the routes are now seen
Expected behavior
All routes are seen in the "show ip route" output
Actual behavior
Adding routes to existing non-existent nexthop don't show up until other routes are added
Additional context
No response
Checklist
The text was updated successfully, but these errors were encountered: