sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

routing: provide dedicated function for nhgrp creation and linking.

There is a need to store client metadata in nexthops and nexthop groups.
This metadata is immutable and participate in nhop/nhg co

routing: provide dedicated function for nhgrp creation and linking.

There is a need to store client metadata in nexthops and nexthop groups.
This metadata is immutable and participate in nhop/nhg comparison.

Nexthops KPI already supports its: nexthop creation pattern is
```
nhop_alloc()
nhop_set_...()
...
nhop_get_nhop()
```

This change provides a similar pattern for the nexthop groups.
Specifically, it adds nhgrp_alloc(), nhgrp_get_nhgrp() and
nhgrp_set_uidx().

MFC after: 2 weeks

show more ...

routing: constantify nh/nhg argument in <nhop|nhgrp>_get_origin().

MFC after: 1 month

routing: add abitity to set the protocol that installed route/nexthop.

Routing daemons such as bird need to know if they install certain route
so they can clean it up on startup, as a form of achie

routing: add abitity to set the protocol that installed route/nexthop.

Routing daemons such as bird need to know if they install certain route
so they can clean it up on startup, as a form of achieving consistent
state during the crash recovery.
Currently they use combination of routing flags (RTF_PROTO1) to detect
these routes when interacting via route(4) rtsock protocol.
Netlink protocol has a special "rtm_protocol" field that is filled and
checked by the route originator. To prepare for the upcoming netlink
introduction, add ability to record origing to both nexthops and
nexthop groups via <nhop|nhgrp>_<get|set>_origin() KPI. The actual
calls will be used in the followup commits.

MFC after: 1 month

show more ...

routing: extend nhop(9) kpi

* add nhop_get_unlinked() used to prepare referenced but not
linked nexthop, that can later be used as a clone source.
* add nhop_check_gateway() to check for allowed ad

routing: extend nhop(9) kpi

* add nhop_get_unlinked() used to prepare referenced but not
linked nexthop, that can later be used as a clone source.
* add nhop_check_gateway() to check for allowed address family
combinations between the rib family and neighbor family (useful
for 4o6 or direct routes)
* add nhop_set_upper_family() to allow copying IPv6 nexthops to
IPv4 rib.
* add rt_get_rnd() wrapper, returning both nexthop/group and its
weight attached to the rtentry.
* Add CHT_SLIST_FOREACH_SAFE(), allowing to delete items during
iteration.

MFC after: 2 weeks

show more ...

routing: add ability to store opaque indentifiers in nhops/nhgs

This is a pre-requisite for the direct nexthop/nexhop group operations
via netlink.

MFC after: 2 weeks

routing: populate fibs with interface routes after growing net.fibs.

Currently it is possible to extend number of fibs in runtime, but this
functionality is of limited use when net.add_addrs_all_fi

routing: populate fibs with interface routes after growing net.fibs.

Currently it is possible to extend number of fibs in runtime, but this
functionality is of limited use when net.add_addrs_all_fibs is
non-zero, as the routing tables are created empty.

This change automatically populate newly-created fibs with the kernel-originated
interface routes (filtered by RTF_PINNED flag) if net.add_addrs_all_fibs
is set.

```
-> sysctl net.add_addr_allfibs=1
net.add_addr_allfibs: 0 -> 1
-> sysctl net.fibs
net.fibs: 2
-> sysctl net.fibs=3
net.fibs: 2 -> 3

BEFORE:
-> setfib 2 netstat -rn
Routing tables (fib: 2)

AFTER:
-> setfib 2 netstat -rn
Routing tables (fib: 2)

Internet:
Destination Gateway Flags Netif Expire
10.0.0.0/24 link#1 U vtnet0
10.0.0.5 link#1 UHS lo0
127.0.0.1 link#2 UH lo0

Internet6:
Destination Gateway Flags Netif Expire
::1 link#2 UHS lo0
2a01:4f9:3a:fa00::/64 link#1 U vtnet0
2a01:4f9:3a:fa00:5054:ff:fe15:4a3b link#1 UHS lo0
fe80::%vtnet0/64 link#1 U vtnet0
fe80::5054:ff:fe15:4a3b%vtnet0 link#1 UHS lo0
fe80::%lo0/64 link#2 U lo0
fe80::1%lo0 link#2 UHS lo0
```

Differential Revision: https://reviews.freebsd.org/D36075
MFC after: 1 month

show more ...

routing: add nhop(9) kpi.

Differential Revision: https://reviews.freebsd.org/D35985
MFC after: 1 month

routing: move route expiration time to its nexthop

Expiration time is actually a path property, not a route property.
Move its storage to nexthop to simplify upcoming nhop(9) KPI changes
and netlin

routing: move route expiration time to its nexthop

Expiration time is actually a path property, not a route property.
Move its storage to nexthop to simplify upcoming nhop(9) KPI changes
and netlink introduction.

Differential Revision: https://reviews.freebsd.org/D35970
MFC after: 2 weeks

show more ...

routing: actually sort nexthops in nhgs by their index

Nexthops in the nexthop groups needs to be deterministically sorted
by some their property to simplify reporting cost when changing
large nex

routing: actually sort nexthops in nhgs by their index

Nexthops in the nexthop groups needs to be deterministically sorted
by some their property to simplify reporting cost when changing
large nexthop groups.

Fix reporting by actually sorting next hops by their indices (`wn_cmp_idx()`).
As calc_min_mpath_slots_fast() has an assumption that next hops are sorted
using their relative weight in the nexthop groups, it needs to be
addressed as well. The latter sorting is required to quickly determine the
layout of the next hops in the actual forwarding group. For example,
what's the best way to split the traffic between nhops with weights
19,31 and 47 if the maximum nexthop group width is 64?
It is worth mentioning that such sorting is only required during nexthop
group creation and is not used elsewhere. Lastly, normally all nexthop
are of the same weight. With that in mind, (a) use spare 32 bytes inside
`struct weightened_nexthop` to avoid another memory allocation and
(b) use insertion sort to sort the nexthop weights.

Reported by: thj
Tested by: Claudio Jeker<claudio.jeker@klarasystems.com>
Differential Revision: https://reviews.freebsd.org/D35599
MFC after: 2 weeks

show more ...

nhops: split nh_family into nh_upper_family and nh_neigh_family.

With IPv4 over IPv6 nexthops and IP->MPLS support, there is a need
to distingush "upper" e.g. traffic family and "neighbor" e.g. LLE

nhops: split nh_family into nh_upper_family and nh_neigh_family.

With IPv4 over IPv6 nexthops and IP->MPLS support, there is a need
to distingush "upper" e.g. traffic family and "neighbor" e.g. LLE/gateway
address family. Store them explicitly in the private part of the nexthop data.

While here, store nhop fibnum in nhop_prip datastructure to make it self-contained.

MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D33663

show more ...

Remove now-unused RT_GATEWAY* definitions.

They were used to simplify nexthop transition, hence not needed
anymore.

Use light-weight versions of routing lookup functions in ng_netflow.

Use recently-added combination of `fib[46]_lookup_rt()` which
returns rtentry & raw nexthop with `rt_get_inet[6]_plen()` which

Use light-weight versions of routing lookup functions in ng_netflow.

Use recently-added combination of `fib[46]_lookup_rt()` which
returns rtentry & raw nexthop with `rt_get_inet[6]_plen()` which
returns address/prefix length of prefix inside `rt`.

Add `nhop_select_func()` wrapper around inlined `nhop_select()` to
allow callers external to the routing subsystem select the proper
nexthop from the multipath group without including internal headers.

New calls does not require reference counting objects and reduce
the amount of copied/processed rtentry data.

Differential Revision: https://reviews.freebsd.org/D27675

show more ...

Introduce scalable route multipath.

This change is based on the nexthop objects landed in D24232.

The change introduces the concept of nexthop groups.
Each group contains the collection of nexthops

Introduce scalable route multipath.

This change is based on the nexthop objects landed in D24232.

The change introduces the concept of nexthop groups.
Each group contains the collection of nexthops with their
relative weights and a dataplane-optimized structure to enable
efficient nexthop selection.

Simular to the nexthops, nexthop groups are immutable. Dataplane part
gets compiled during group creation and is basically an array of
nexthop pointers, compiled w.r.t their weights.

With this change, `rt_nhop` field of `struct rtentry` contains either
nexthop or nexthop group. They are distinguished by the presense of
NHF_MULTIPATH flag.
All dataplane lookup functions returns pointer to the nexthop object,
leaving nexhop groups details inside routing subsystem.

User-visible changes:

The change is intended to be backward-compatible: all non-mpath operations
should work as before with ROUTE_MPATH and net.route.multipath=1.

All routes now comes with weight, default weight is 1, maximum is 2^24-1.

Current maximum multipath group width is statically set to 64.
This will become sysctl-tunable in the followup changes.

Using functionality:
* Recompile kernel with ROUTE_MPATH
* set net.route.multipath to 1

route add -6 2001:db8::/32 2001:db8::2 -weight 10
route add -6 2001:db8::/32 2001:db8::3 -weight 20

netstat -6On

Nexthop groups data

Internet6:
GrpIdx NhIdx Weight Slots Gateway Netif Refcnt
1 ------- ------- ------- --------------------------------------- --------- 1
13 10 1 2001:db8::2 vlan2
14 20 2 2001:db8::3 vlan2

Next steps:
* Land outbound hashing for locally-originated routes ( D26523 ).
* Fix net/bird multipath (net/frr seems to work fine)
* Add ROUTE_MPATH to GENERIC
* Set net.route.multipath=1 by default

Tested by: olivier
Reviewed by: glebius
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D26449

show more ...

net: clean up empty lines in .c and .h files

Use epoch(9) for rtentries to simplify control plane operations.

Currently the only reason of refcounting rtentries is the need to report
the rtable operation details immediately after the executio

Use epoch(9) for rtentries to simplify control plane operations.

Currently the only reason of refcounting rtentries is the need to report
the rtable operation details immediately after the execution.
Delaying rtentry reclamation allows to stop refcounting and simplify the code.
Additionally, this change allows to reimplement rib_lookup_info(), which
is used by some of the customers to get the matching prefix along
with nexthops, in more efficient way.

The change keeps per-vnet rtzone uma zone. It adds nh_vnet field to
nhop_priv to be able to reliably set curvnet even during vnet teardown.
Rest of the reference counting code will be removed in the D24867 .

Differential Revision: https://reviews.freebsd.org/D24866

show more ...

Remove an duplicate definition of nhops_dump_sysctl()

One of the source files included both nhop.h and shared.h, leading to this
clashing.

Tested with: mips-gcc cross toolchain

Introduce nexthop objects and new routing KPI.

This is the foundational change for the routing subsytem rearchitecture.
More details and goals are available in https://reviews.freebsd.org/D24141 .

Introduce nexthop objects and new routing KPI.

This is the foundational change for the routing subsytem rearchitecture.
More details and goals are available in https://reviews.freebsd.org/D24141 .

This patch introduces concept of nexthop objects and new nexthop-based
routing KPI.

Nexthops are objects, containing all necessary information for performing
the packet output decision. Output interface, mtu, flags, gw address goes
there. For most of the cases, these objects will serve the same role as
the struct rtentry is currently serving.
Typically there will be low tens of such objects for the router even with
multiple BGP full-views, as these objects will be shared between routing
entries. This allows to store more information in the nexthop.

New KPI:

struct nhop_object *fib4_lookup(uint32_t fibnum, struct in_addr dst,
uint32_t scopeid, uint32_t flags, uint32_t flowid);
struct nhop_object *fib6_lookup(uint32_t fibnum, const struct in6_addr *dst6,
uint32_t scopeid, uint32_t flags, uint32_t flowid);

These 2 function are intended to replace all all flavours of
<in_|in6_>rtalloc[1]<_ign><_fib>, mpath functions and the previous
fib[46]-generation functions.

Upon successful lookup, they return nexthop object which is guaranteed to
exist within current NET_EPOCH. If longer lifetime is desired, one can
specify NHR_REF as a flag and get a referenced version of the nexthop.
Reference semantic closely resembles rtentry one, allowing sed-style conversion.

Additionally, another 2 functions are introduced to support uRPF functionality
inside variety of our firewalls. Their primary goal is to hide the multipath
implementation details inside the routing subsystem, greatly simplifying
firewalls implementation:

int fib4_lookup_urpf(uint32_t fibnum, struct in_addr dst, uint32_t scopeid,
uint32_t flags, const struct ifnet *src_if);
int fib6_lookup_urpf(uint32_t fibnum, const struct in6_addr *dst6, uint32_t scopeid,
uint32_t flags, const struct ifnet *src_if);

All functions have a separate scopeid argument, paving way to eliminating IPv6 scope
embedding and allowing to support IPv4 link-locals in the future.

Structure changes:
* rtentry gets new 'rt_nhop' pointer, slightly growing the overall size.
* rib_head gets new 'rnh_preadd' callback pointer, slightly growing overall sz.

Old KPI:
During the transition state old and new KPI will coexists. As there are another 4-5
decent-sized conversion patches, it will probably take a couple of weeks.
To support both KPIs, fields not required by the new KPI (most of rtentry) has to be
kept, resulting in the temporary size increase.
Once conversion is finished, rtentry will notably shrink.

More details:
* architectural overview: https://reviews.freebsd.org/D24141
* list of the next changes: https://reviews.freebsd.org/D24232

Reviewed by: ae,glebius(initial version)
Differential Revision: https://reviews.freebsd.org/D24232

show more ...