------
- New: add support for custom BGP communities to track rejected routes.
A new section of the general.yml file (``reject_cause_map``) allows to configure custom BGP communities for each reject reason (the list can be found on the `Reject reasons <https://arouteserver.readthedocs.io/en/latest/CONFIG.html#reject-reasons>`__ paragraph of on the doc site).
When this is implemented along with ``reject_policy`` set to ``tag`` or ``tag_and_reject``, ad-hoc custom BGP communities can be used to describe why a route was rejected by the route server.
- New: add support for custom BGP communities to internally track the outcome of BGP Origin Validation (or the lack of it).
3 new BGP communities are introduced to track the outcome of BGP Origin Validation (if enabled): ``rpki_bgp_origin_validation_valid``, ``rpki_bgp_origin_validation_unknown`` and ``rpki_bgp_origin_validation_invalid``. These communities can be used to classify routes depending on the their validation state using custom values, in addition to `RFC8097 communities <https://datatracker.ietf.org/doc/html/rfc8097>`__. They are not announced to clients, but rather they are meant to be used only internally within the route server, just to make it easier the integration with external tools, like looking glasses.
An additional fourth BGP community is also introduced, to classify routes for which BGP Origin Validation has not been performed: ``rpki_bgp_origin_validation_not_performed``. When configured, this community is added when BOV is not enabled, or when it is not performed for some specific reasons (only blackhole route processing at the moment). Contrary to the 3 previous ones, this community is announced to the clients.
See also `GitHub issue 78 <https://github.com/pierky/arouteserver/issues/78>`_.
- New: Euro-IX Large BGP Communities are included into the policy generated by the ``configure`` command.
This feature leverages the new ``reject_cause_map`` option commented above.
The general.yml file generated by the ``configure`` command now includes a mapping between internal reject codes and the communities proposed in the `Euro-IX Large BGP Community standard <https://www.euro-ix.net/en/forixps/large-bgp-communities/>`__ document.
Please note: to make the policies generated by ``configure`` consistent between BIRD and OpenBGPD, the ``reject_policy`` option for the latter is now set to ``tag`` (so rejected routes are kept in OpenBGPD but are still not advertised to the route server clients).
In addition to this, some of the BGP communities set by the ``configure`` command have been changed in order to match those suggested in the Euro-IX document above.
- New: ``check-config`` command, to verify configuration files (general.yml and clients.yml).
This command can be used to verify that the content of the two main configuration files is valid, without building the configurations.
See also `GitHub PR 82 <https://github.com/pierky/arouteserver/pull/82>`_ and `issue 79 <https://github.com/pierky/arouteserver/issues/79>`_.
- Improvement (OpenBGPD): informational extended BGP communities are now scrubbed from outbound routes.
Certain informational extended BGP communities that need dynamic values (like the one used to track the reject code of a route that is discarded when ``reject_policy`` is set to ``tag``) were not scrubbed from outbound routes, because of lack of wildcard matching in OpenBGPD. Since this feature was recently added to the BGP speaker, they are now removed.
- Fix (OpenBGPD): make behaviour of ``rpki_bgp_origin_validation.reject_invalid`` consistent with BIRD.
Contrary to what ``reject_invalid: False`` might seem doing, the actual behaviour it is designed for is to still prevent the propagation of INVALID routes when RPKI BOV is enabled. When it's set to ``True`` (the default value) the BGP daemons are configured to immediately drop INVALID routes in the inbound filters; when it's set to ``False`` those routes are accepted but not propagated to clients, they are blocked in the outbound filters: basically they are just kept internally within the route server to allow analysis and troubleshooting.
While the BIRD implementation of ``reject_invalid: False`` was working fine, a bug was found in the OpenBGPD one that prevented those routes from being blocked in the outbound direction, letting them to be propagated to clients.