Page MenuHomeFreeBSD

netlink: Add RTA_PRIORITY support (metric)
Needs ReviewPublic

Authored by pouria on Apr 8 2026, 9:56 PM.
Tags
None
Referenced Files
F157014835: D56323.diff
Sun, May 17, 11:18 PM
Unknown Object (File)
Thu, May 14, 3:36 PM
Unknown Object (File)
Thu, May 14, 2:49 PM
Unknown Object (File)
Thu, May 14, 6:22 AM
Unknown Object (File)
Thu, May 14, 6:22 AM
Unknown Object (File)
Wed, May 13, 6:39 PM
Unknown Object (File)
Wed, May 13, 6:39 PM
Unknown Object (File)
Wed, May 13, 6:31 PM
Subscribers

Details

Reviewers
melifaro
markj
glebius
kp
ae
Group Reviewers
network
Summary

Also, fix weight overflow of RTA_MULTIPATH, use metric instead
Our weight values are 24-bit. In the original netlink, rtnh_hops is
indeed 8-bit. For backward compatibility, send metric instead of increasing
its size and also send RTA_WEIGHT for multipath routes.

Test Plan

See patches to the route(8) command in the stack revision.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 72758
Build 69641: arc lint + arc unit

Event Timeline

pouria requested review of this revision.Apr 8 2026, 9:56 PM

These changes can be tested in latter route revisions in the revision stack.

sys/netlink/route/route.h
336

It would be awesome to increase rtnh_hops size here.
But we can't, since it's defined at netlink specs.
So we pass the metric instead to avoid overflow below.

sys/netlink/route/rt.c
219

This is where I changed the rtnh_nhops from weight to metric.
But both kernel and userland (even outside the tree) should be okay with this change.
Since the value of weight was always incorrect anyway and now it actually mean something.

You can verify the invalid values by using route -n6 monitor and adding a weight bigger than 8-bit value.

226

To preserve the functionality. I return the weight using another well-known TLV here and I also document it in next revision.

906–907

If user filled the metric, add it to weight.
However, userland may want to directly set the weight and metric at the same time since we return the weight + metric value to them as a single value due to netlink spec restrictions.
In that case, ignore the metric.

Good for backward compatibility. Simple logic.

pouria retitled this revision from netlink: Fix weight overflow of RTA_MULTIPATH, use metric instead to netlink: Add RTA_PRIORITY support (metric).Apr 9 2026, 10:51 PM
pouria edited the summary of this revision. (Show Details)
pouria edited the test plan for this revision. (Show Details)

There is a specific netlink attribute for metric.
Use that instead.

sys/netlink/route/rt.c
906–907

If user filled the metric, add it to weight.
However, userland may want to directly set the weight and metric at the same time since we return the weight + metric value to them as a single value due to netlink spec restrictions.
In that case, ignore the metric.

Good for backward compatibility. Simple logic.

With new attribute, I removed the dirty hack and the sentence above is no longer true.

This revision is now accepted and ready to land.Apr 12 2026, 7:41 PM

This review now only contains the RTA_PRIORITY code and it won't touch RTA_WEIGHT anymore.
Safe to use with routing daemons compiled without this patch.

This revision now requires review to proceed.Mon, May 4, 11:32 AM

To preserve linux netlink behavior, if metric was not specified per nexthop, use route metric instead.
Tested with bird3.

protocol kernel kernel61 {
  **metric 10;**
  ipv6 {
    import all;
    export all;
  };
  learn all;
}

protocol ospf v3 {
  ecmp yes;
  ipv6 {
    export none;
    import all;
  };
  area 0 {
    interface "vtnet1" {};
  };
}

Enforce default metric
Update path_match_func to differenciate between nhops using metric.
Remove support for per nhop RTA_PRIORITY in RTA_MULTIPATH.

sys/netlink/netlink_snl_route_parsers.h
126

Does this break compatibility with utilities compiled against the old version of netlink_snl_route_parsers.h? In particular, is the layout of the structure part of the kernel's ABI? (If I understand correctly, it is not, but I'm not sure.)

What happens if an old application encouters a NL_RTA_PRIORITY value that it doesn't know how to handle? Does it just get silently ignored?

sys/netlink/route/rt.c
243

Is nhop_metric guaranteed to be initialized? I see that nhop_weight is due to the assignment at the beginning of this function.