v1.10.0

• 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 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. 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.

• 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 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 and issue #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 ou tbound 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.