Nest: Forbid adding channels during reconfiguration
When a new channel is found during reconfiguration, do force restart
of the protocol, like with any other un-reconfigurable change.
The old behavior was that the new channel was added but remained in down
state, even if the protocol was up, so a manual protocol restart was
often necessary.
In the future this should be improved such that a reconfigurable
channel addition (e.g. direct) is accepted and channel is started,
while an un-reconfigurable addition forces protocol restart.
Fix crash during reconfiguration of OSPF config with vlinks. When vlink
is reconfigured, a generic iface-reconfiguration code is used, which in
one place supposes that it is running on a regular iface.
Maria Matejka [Wed, 21 Nov 2018 19:37:11 +0000 (20:37 +0100)]
Custom route attributes
For local route marking purposes, local custom route attributes may be
defined. These attributes are seamlessly stripped after export filter to
every real protocol like Kernel, BGP or OSPF, they however pass through
pipes. We currently allow at most 256 custom attributes.
This should be much faster than currently used bgp communities
for marking routes.
The old behavior was that enabling debugging did many nontrivial changes
in BIRD behavior. The patch changes it that these changes are generally
independent. Compiling with --enable-debug now just enables compile-time
debug macros, but do not automatically activate debug mode (-d) nor local
mode (-l). Debug mode with output to file (-D) do not force foreground
mode (-f), therefore there is no need for backgroud option (-b), which is
removed. Also fixes a bug when the default log target in -D mode was
stderr instead of given debug file.
Terminology cleanup: The import_control hook is now called preexport.
Once upon a time, far far away, there were the old Bird developers
discussing what direction of route flow shall be called import and
export. They decided to say "import to protocol" and "export to table"
when speaking about a protocol. When speaking about a table, they
spoke about "importing to table" and "exporting to protocol".
The latter terminology was adopted in configuration, then also the
bird CLI in commit ea2ae6dd0 started to use it (in year 2009). Now
it's 2018 and the terminology is the latter. Import is from protocol to
table, export is from table to protocol. Anyway, there was still an
import_control hook which executed right before route export.
One thing is funny. There are two commits in April 1999 with just two
minutes between them. The older announces the final settlement
on config terminology, the newer uses the other definition. Let's see
their commit messages as the git-log tool shows them (the newer first):
Changed syntax of attaching filters to protocols to hopefully the final
version:
EXPORT <filter-spec> for outbound routes (i.e., those announced
by BIRD to the rest of the world).
IMPORT <filter-spec> for inbound routes (i.e., those imported
by BIRD from the rest of the world).
where <filter-spec> is one of:
ALL pass all routes
NONE drop all routes
FILTER <name> use named filter
FILTER { <filter> } use explicitly defined filter
For all protocols, the default is IMPORT ALL, EXPORT NONE. This includes
the kernel protocol, so that you need to add EXPORT ALL to get the previous
configuration of kernel syncer (as usually, see doc/bird.conf.example for
a bird.conf example :)).
Let's say RIP to this almost 19-years-old inconsistency. For now, if you
import a route, it is always from protocol to table. If you export a
route, it is always from table to protocol.
Nest: Do not hard-reset interface when preferred address is changed
Modify protocols to use preferred address change notification instead on
depending on hard-reset of interfaces in that case, and remove hard-reset
in that case. This avoids issue when e.g. IPv6 protocol restarts
interface when IPv4 preferred address changed (as hard-reset is
unavoidable and common for whole iface).
The patch also fixes a bug when removing last address does not send
preferred address change notification.
The new MRT protocol is responsible for periodic RIB table dumps in the
MRT format (RFC 6396). Also the existing code for BGP4MP MRT dumps is
refactored and splitted between BGP to MRT protocols, will be more
integrated into MRT in the future.
Example:
protocol mrt {
table "*";
filename "%N_%F_%T.mrt";
period 60;
}
It is partially based on the old MRT code from Pavel Tvrdik.
This also includes Bison version check. Versions before 3.0 don't
support them in a reliable way and we don't promise to work with
versions older than 2.4.
BSD: Use MSG_DONTROUTE for unicast packets on FreeBSD
BSD systems cannot use SO_DONTROUTE, because it does not work properly
with multicast packets (perhaps it tries to find iface based on multicast
group address). But we can use MSG_DONTROUTE sendmsg() flag for unicast
packets. Works on FreeBSD, is ignored on OpenBSD and is broken on NetBSD
(i guess due to integrated routing table and ARP table).
Nest: Fix race condition during reconfiguration, part 2
If export filter is changed during reconfiguration and a route disappears
between reconfiguration and refeed (e.g., if the route is a static route
also removed during the reconfiguration), the route is not withdrawn.
The issue was fixed for regular channels by an earlier patch. This patch
fixes the issue for channels in RA_ACCEPTED mode (first-pass-the-filter),
used by BGP with 'secondary' option.
If export filter is changed during reconfiguration and a route disappears
between reconfiguration and refeed (e.g., if the route is a static route
also removed during the reconfiguration), the route is not withdrawn.
The patch fixes that by adding tx reconfiguration timestamp.
BGP: Use implicit-NULL label when announcing MPLS routes with local next-hop
We currently cannot assing local labels, but we can still be LSP egress
router. Therefore when we announce labeled route with local next-hop, we
should announce implicit-NULL label instead of rejecting it completely.
RFC 3107 was bit vague with regard to labeled withdrawals, RFC 8277
clarified that. The old code was incompatible with some implementations,
namely with Juniper.
Use ACCESS_RTE to guard **f_rte, use ACCESS_EATTRS to guard **f_eattrs.
Use f_rta_cow() before writing to rta or eattrs, use f_rte_cow() before
writing preference (stored in rte).
Do not access eattrs indirectly through (*f_rte)->attrs->eattrs, it is
way too slow. The cached pointer is faster.
Nest: Removing separate tmpa from route propagation
This is a fundamental change of an original (1999) concept of route
processing inside BIRD. During import/export, there was a temporary
ea_list created which was to be used instead of the another one inside
the route itself.
This led to some confusion, quirks, and strange filter code that handled
extended route attributes. Dropping it now.
The protocol interface has changed in an uniform way -- the
`struct ea_list *attrs` argument has been removed from store_tmp_attrs(),
import_control(), rt_notify() and get_route_info().
Do not initialize route metrics in import_control hook
During route export, the receiving protocol often initialized route
metrics to default value in its import_control hook before export filter
was executed. This is inconsistent with the expectation that an export
filter would process the same route as one in the routing table and it
breaks setting these metrics before (e.g. for static routes directly in
static protocol).
The patch removes the initialization of route metrics in import_control
hook, the default values are already handled in rt_notify hook called
after export filters.
The patch also changed the behavior of OSPF to keep metrics when a route
is reannounced between OSPF instances (to be consistent with other
protocols) and the behavior when both ospf_metric1 and ospf_metric2
are specified (to have more expected behavior).
Use full time precision to initialize random generator. The old
code was prone to initialize it to the same values in specific
circumstances (boot without RTC, multiple VMs starting at once).
When a Babel node restarts, it loses its sequence number, which can cause
its routes to be rejected by peers until the state is cleared out by other
nodes in the network (which can take on the order of minutes).
There are two ways to fix this: Having stable storage to keep the sequence
number across restarts, or picking a different router ID each time.
This implements the latter, by introducing a new option that will cause
BIRD to randomize a high 32 bits of router ID every time it starts up.
This avoids the problem at the cost of not having stable router IDs in
the network.
The router ID being assigned to routes was a uint, which discards the
upper 32 bits. This also has the nice side effect of echoing the wrong
router ID back to other routers.
The bgpmask literals can include expressions. This is OK but they have
to be interpreted as soon as the code is run, not in the time the code
is used as value.
This led to strange behavior like rewriting bgpmasks when they shan't
be rewritten:
function mask_generator(int as)
{
return [= * as * =];
}
function another()
bgpmask m1;
bgpmask m2;
{
m1 = mask_generator(10);
m2 = mask_generator(20);
if (m1 == m2) {
print("strange"); # this would happen
}
}
Moreover, sending this to CLI would cause stack overflow and knock down the
whole BIRD, as soon as there is at least one route to execute the given
filter on.
The magic match operator (~) inside the bgpmask literal would try to
resolve mmm, which points to the same bgpmask so it would resolve
itself, call the magic match operator and vice versa.
After this patch, the bgpmask literal will get resolved as soon as it's
assigned to mmm and it also will return a type error as bool is not
convertible to ASN in BIRD.
It was supposed to do tail-recursion in interpret() but it didn't
compile as such. Converting it to loop makes a significant filter
performance improvement for flat filters.
The two-letter instructions were quite messy but they could be easily
read from memory dumps. Now GDB (since 2012) supports pretty printing
enum values and GCC checks the switch construction for missing enum
values so we are converting the nice two-byte values to enums.
Anyway, the enum still keeps the old two-byte values to be able to read
the instruction codes even without GDB from plain memory dump.