Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No connected/local/kernel nexthops at first #16688

Merged
merged 2 commits into from
Aug 30, 2024

Conversation

donaldsharp
Copy link
Member

When creating these three types of routes, we are also implicitly creating a nexthop group that matches these routes. If these routes already exist in the kernel using the old style of nexthops there is no need to immediately install these nexthops. Make it so that they initially will pretend install and then when it is really needed install them.

@@ -4483,6 +4490,9 @@ int rib_add(afi_t afi, safi_t safi, vrf_id_t vrf_id, int type,
/* Add nexthop. */
nexthop = *nh;
nexthop_group_add_sorted(&ng, &nexthop);

//if (type == ZEBRA_ROUTE_CONNECT)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftovers?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep fixed

if (re->type == ZEBRA_ROUTE_CONNECT ||
re->type == ZEBRA_ROUTE_LOCAL ||
re->type == ZEBRA_ROUTE_KERNEL) {
zlog_debug(" Is a CONNECT OR KERNEL setting flag");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftovers?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep fixed

Currently the FRR code will receive both kernel and
connected routes that do not actually have an underlying
nexthop group at all.  Zebra turns around and creates
a `matching` nexthop hash entry and installs it.
For connected routes, this will create 2 singleton
nexthops in the dplane per interface (v4 and v6).
For kernel routes it would just create 1 singleton
nexthop that might be used or not.

This is bad because the dplane has a limited amount
of space available for nexthop entries and if you
happen to have a large number of interfaces then
all of a sudden you have 2x(# of interfaces) singleton
nexthops.

Let's modify the code to delay creation of these singleton
nexthops until they have been used by something else in the
system.

Signed-off-by: Donald Sharp <[email protected]>
@donaldsharp donaldsharp force-pushed the no_connected_nexthops_at_first branch from 6b26022 to 8f47dc9 Compare August 30, 2024 12:24
@Jafaral Jafaral merged commit 0c14da4 into FRRouting:master Aug 30, 2024
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants