There is an IP table for every ROA table, holding special records
combining all known ROAs for every top-prefix.
The ROA digestor is now an IP digestor, running over the auxiliary
table.
In future, this and rtable's data structures should be probably merged
but it isn't a good idea to do now. The used data structure is similar
to rtable -- an array of pointers to linked lists.
Feed is lockless, as with all tables.
Full export (receiving updates) is not supported yet but we don't have
any method how to use it anyway. Gonna implement it later.
We have now better methods how to measure overall performance
and this obsolete protocol has basically rotten away. If anybody
needs its features, feel free to revive it in future.
Allow to explicitly configure the source IP address for RPKI-To-Router
sessions. Predictable source addresses are useful for minimizing the
holes to be poked in ACLs.
Changed from 'source address' to 'local address' by committer.
Allow to define both nexthop and interface using iproute2-like syntax,
e.g.: route 10.0.0.0/16 via 10.1.0.1 dev "eth0";
Now we can avoid to use link-local scope hack (e.g. 10.1.0.1%eth0)
for cases where both nexthop and interface have to be defined.
Thanks to Marcin Saklak for the suggestion.
The UDP logging had to be substantially rewritten due to a different
logging backend and reconfiguration mechanisms.
Conflicts:
doc/bird.sgml
sysdep/unix/config.Y
sysdep/unix/io.c
sysdep/unix/log.c
sysdep/unix/unix.h
Implement BGP Send hold timer according to draft-ietf-idr-bgp-sendholdtimer.
The Send hold timer drops the session if the neighbor is sending keepalives,
but does not receive our messages, causing the TCP connection to stall.
Some BGP capabilities change the BGP behavior in a significant way, so if
the configuration depends on it, it is better to not establish BGP
session when the capability is not available.
Add several BGP option to require individual BGP capabilities during
session negotiation.
Add a new protocol offering route aggregation.
User can specify list of route attributes in the configuration file and
run route aggregation on the export side of the pipe protocol. Routes are
sorted and for every group of equivalent routes new route is created and
exported to the routing table. It is also possible to specify filter
which will run for every route before aggregation.
Furthermore, it will be possible to set attributes of new routes
according to attributes of the aggregated routes.
This is a work in progress.
Original work by Igor Putovny, subsequent cleanups and finalization by
Maria Matejka.
This is a split-commit of the neighboring aggregator branch
with a bit improved lvalue handling, to have easier merge into v3.
This merge was particularly difficult. I finally resorted to delete the
symbol scope active flag altogether and replace its usage by other
means.
Also I had to update custom route attribute registration to fit
both the scope updates in v2 and the data model in v3.
