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.
Details
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
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. | |
| sys/netlink/route/rt.c | ||
| 219 | This is where I changed the rtnh_nhops from weight to metric. 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. Good for backward compatibility. Simple logic. | |
| sys/netlink/route/rt.c | ||
|---|---|---|
| 906–907 |
With new attribute, I removed the dirty hack and the sentence above is no longer true. | |
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.
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. | |