There were some confusion about validity and usage of pflags, which
caused incorrect usage after some flags from (now removed) protocol-
specific area were moved to pflags.

We state that pflags:

 - Are secondary data used by protocol-specific hooks
 - Can be changed on an existing route (in contrast to copy-on-write
   for primary data)
 - Are irrelevant for propagation (not propagated when changed)
 - Are specific to a routing table (not propagated by pipe)

The patch did these fixes:

 - Do not compare pflags in rte_same(), as they may keep cached values
   like BGP_REF_STALE, causing spurious propagation.

 - Initialize pflags to zero in rte_get_temp(), avoid initialization in
   protocol code, fixing at least two forgotten initializations (krt
   and one case in babel).

 - Improve documentation about pflags

Toke Høiland-Jørgensen authored 2 years ago and Ondřej Zajíček committed 2 years ago

The seqno request retransmission handling was tracking the destination
that a forwarded request was being sent to and always retransmitting to
that same destination. This is unnecessary because we only need to
retransmit requests we originate ourselves, not those we forward on
behalf of others; in fact retransmitting on behalf of others can lead to
exponential multiplication of requests, which would be bad.

So rework the seqno request tracking so that instead of storing the
destination of a request, we just track whether it was a request that we
forwarded on behalf of another node, or if it was a request we originated
ourselves. Forwarded requests are not retransmitted, they are only used
for duplicate suppression, and for triggering an update when satisfied.
If we end up originating a request that we previously forwarded, we
"upgrade" the old request and restart the retransmit counter.

One complication with this is that requests sent in response to unfeasible
updates (section 3.8.2.2 of the RFC) have to be sent as unicast to a
particular peer. However, we don't really need to retransmit those as
there's no starvation when sending such a request; so we just change
such requests to be one-off unicast requests that are not subject to
retransmission or duplicate suppression. This is the same behaviour as
babeld has for such requests.

Minor changes from committer.

Alexander Chernikov authored 2 years ago and Ondřej Zajíček committed 2 years ago

Minor changes from committer.

Alexander Chernikov authored 2 years ago and Ondřej Zajíček committed 2 years ago

Minor changes from committer.

Use symlinks to linux/netlink* to avoid limitations of our buildsystem.

FreeBSD 13.0 added some safechecks for syscalls, rejecting sockaddrs that
are too small, later versions loosen up the check.

Thanks Johannes Moos for the suggestion.

When there is a continuos stream of CLI commands, cli_get_command()
always returns 1 (there is a new command). Anyway, the socket receive
buffer was reset only when there was no command at all, leading to a
strange behavior: after a while, the CLI receive buffer came to its end,
then read() was called with zero size buffer, it returned 0 which was
interpreted as EOF.

The patch fixes that by resetting the buffer position after each command
and moving remaining data at the beginning of buffer.

Thanks to Maria Matejka for examining the bug and for the original bugfix.

The import table does not work reliably together with re-evaluation of
routes due to recursive next hops or flowspec validation. We will at
least document that here, as import tables are completely redesigned and
this issue is fixed in BIRD 3.x branch.

Alexander V. Chernikov authored 2 years ago and Ondřej Zajíček committed 2 years ago

Netlink support was added to FreeBSD recently. It is not as full-featured
as its Linux counterpart yet, however the added subset is enough to make
a routing daemon work. Specifically, it supports multiple tables,
multipath, nexthops and nexthops groups. No MPLS support yet.

The attached change adds 'bsd-netlink’ sysconf target, allowing to build
both netlink & rtsock versions on FreeBSD.

The effective keepalive time now scales relative to the negotiated
hold time, to maintain proportion between the keepalive time and the
hold time. This avoids issues when both keepalive and hold times
were configured, the hold time was negotiated to a smaller value,
but the keepalive time stayed the same.

Add new options 'min hold time' and 'min keepalive time', which reject
session attempts with too small hold time.

Improve validation of config options an their documentation.

Thanks to Alexander Zubkov and Sergei Goriunov for suggestions.

When filtered routes (enabled by 'import keep filtered' option) are
updated, they trigger announcements by rte_announce(). For regular
channels (e.g. type RA_OPTIMAL or RA_ANY) such announcement is just
ignored, but in case of RA_ACCEPTED (BGP peer with 'secondary' option)
it just reannounces the old (and still valid) best route.

The patch ensures that such no-change is ignored even for these channels.

It is unnnecessary and takes too much time

While it does not directly change BIRD state, it can trigger reading
arbitrary files and eating significant memory.

BIRD keeps a previous (old) configuration for the purpose of undo. The
existing code frees it after a new configuration is successfully parsed
during reconfiguration. That causes memory usage spikes as there are
temporarily three configurations (old, current, and new). The patch
changes it to free the old one before parsing the new one (as user
already requested a new config). The disadvantage is that undo is
not available after failed reconfiguration.

This commit uses bird-tools in version
f35e8bce829f4bff61ec7eb07ec9c67aa867bc9a

Memory unmapping causes slow address space fragmentation, leading in
extreme cases to failing to allocate pages at all. Removing this problem
by keeping all the pages allocated to us, yet calling madvise() to let
kernel dispose of them.

This adds a little complexity and overhead as we have to keep the
pointers to the free pages, therefore to hold e.g. 1 GB of 4K pages with
8B pointers, we have to store 2 MB of data.

Define scope for anonymous filters, and also explicitly distinguish block
scopes and function/filter scopes instead of using anonymous / named
distinction.

Anonymous filters forgot to push scope, so variables for them were in
fact defined in the top scope and therefore they shared a frame. This got
broken after rework of variables, which assumed that there is a named
scope for every function/filter.

While onlink flag is meaningful only with explicit next hops, it can be
defined also on direct routes. Parse it also in this case to avoid
periodic updates of the same route.

Thanks to Marcin Saklak for the bugreport.

Add BGP channel option 'next hop prefer global' that modifies BGP
recursive next hop resolution to use global next hop IPv6 address instead
of link-local next hop IPv6 address for immediate next hop of received
routes.

It is useful to distinguish whehter channel config returned from
channel_config_get() was allocated new, or existing from template.
Caller may want to initialize new ones.

Add some supportive functions for f_tree and EC. These functions are used
by L3VPN code.

 - When next hop is reset to local IP, we should remove BGP label stack,
   as it is related to original next hop

 - BGP next hop or immediate next hop from one VRF should not be passed
   to another VRF, as they are different IP namespaces

In principle, the channel list is a list of parent struct proto and can
contain general structures of type struct channel, That is useful e.g.
for adding MPLS channels to BGP.

Changes in commit eb937358 broke setting of channel preference for alien
routes learned during scan. The preference was set only for async routes.
Move common attribute processing part of functions krt_learn_async() and
krt_learn_async() to a separate function to have only one place for such
changes.

This reverts commit 2c137591.

In some specific configurations, it was possible to send BIRD into an
infinite loop of recursive next hop resolution. This was caused by route
priority inversion.

To prevent priority inversions affecting other next hops, we simply
refuse to resolve any next hop if the best route for the matching prefix
is recursive or any other route with the same preference is recursive.

Next hop resolution doesn't change route priority, therefore it is
perfectly OK to resolve BGP next hops e.g. by an OSPF route, yet if the
same (or covering) prefix is also announced by iBGP, by retraction of
the OSPF route we would get a possible priority inversion.