v1.14.1

• Fix: import limit is not set if PeeringDB records are not found.

  For clients not configured with a specific max-prefix value, when a PeeringDB record was not found the value from the general limit was not used to build the import limit configuration. The tool was expected to fallback to the general_limit_ipv4 value instead.

  See also GitHub issue #105 105

v1.14.0

• New: Add support for BIRD 2.0.9 (also included into the integration testing suite).

• Improvement (OpenBGPD): improve readability of the configurations.

  A better formatting of the output configuration allows a better readability. Also, wherever possible, extended communities are removed using wildcard matching, allowing a more compact configuration.

  See also GitHub issue #97 and #99.

• Improvement (Docker image): use bgpq4 version 1.4.

  The Docker image was using version 1.2.

• Improvement (Docker image): PyPy3-based image added.

  The Docker images based on PyPy3 will have tags in the form latest-pypy3 and <version>-pypy3 (like 1.14.0-pypy3).

• Improvements: drop dependencies on libraries needed for Python 2 compatibility.

  Also, tests are now performed using Python 3.6, 3.8 and 3.9 too.

v1.13.1

• Fix: avoid running bgpq4 using the -3 option.

  It seems that the -3 CLI option has been dropped in bgpq4 and is no longer supported (it was added as a way to not break compatibility with bgpq3 syntax).

  See also GitHub issue #95.

• Fix (OpenBGPD): syntax error when prepend functionalities were configured with 'std' communities only and 32bit ASN clients were present.

  See also GitHub issue #98.

• Improvement: better explaination of when error messages can be ignored.

  See also GitHub issue #96.

v1.13.0

• New (OpenBGPD): use the expires attribute of ROAs from rpki-client format.

  In OpenBGPD configurations (starting with 7.2), the expires attribute of ROAs gathered from JSON feeds that contain it is passed on into the configuration of the roa-set.

  See also GitHub issue #92.

v1.12.0

• New: add the --merge-file option to the ixf-member-export command, to include user-created content into the IX-F Member Export JSON file.

  For more details on how it works please check the documentation.

  See also GitHub issue #89.

• Improvement: in the ixf-member-export command, the value of IXP ID can now be set via the --ixp-id in addition to the existing --ixp_id option.

  In the future, the --ixp_id version of the option will be dropped. A warning message will be shown when the deprecated version of that command line argument is used.

• Improvement: ask for 16bit placeholder ASN in configure when the route-server is on a 32bit ASN.

  When the configure command is used to generate the policy for a route-server running on a 32bit ASN, a prompt asks the operator which 16bit placeholder ASN should be used to setup the BGP communities. So far, the fixed value 65534 was used.

  See also GitHub issue #88.

• Improvement (OpenBGPD): use as-set to configure the list of "never via route server" ASNs.

  This change reduces the size of the configuration and hopefully makes the filter processing faster.

  See also GitHub issue #90.

• Fix: when the route-server ASN was a 32bit value, the Euro-IX Large BGP Communities automatically configured via configure were using the 16bit placeholder ASN.

  When the configure command was used to build the genera.yml policy for route-servers running on 32bit ASNs, the Large BGP Communities used to map route reject causes to Euro-IX codes were using the 16bit placeholder ASN instead of the actual route-server's 32bit ASN.

v1.11.1

• Fix: better error handling for clients configured with no IP address.

  When a client was mistakenly configured with no IP addresses, the program raised an unhandled exception, instead of providing a good feedback to the user.

  See also GitHub issue #87.

v1.11.0

• New: add support for OpenBGPD 7.2, also added to the integration testing suite (portable edition only).

• Improvement: better handling of IRRd query failures.

  Multiple hosts can now be configured as servers used for the IRR queries performed via bgpq3/bgpq4. In case of timeout or failure, the next host in the list is used.
  A timeout of 2 minutes is used by default. These settings can be modified in the arouteserver.yml file.

  See also GitHub issue #85

v1.10.1

• Fix: the HTML representation of RPKI validation custom communities was broken.

  After adding custom RPKI validation communities implemented as part of v1.10.0 the route server configuration textual representation file hada small cosmetic problem.

  See also GitHub issue #83.

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.

v1.9.0

• New: Add support for OpenBGPD 7.1, also added to the integration testing suite (portable edition only).

• Improvement: provide hint on how to change URL for external IRR DB data sources.

  See also GitHub issue #77.

• Fix (OpenBGPD only): RFC8097 communities were not added after BGP Origin Validation.

  The BGP Prefix Origin Validation State Extended Communities were not added when RPKI OV was performed. INVALID routes were still dropped when the route server was configured to do so (those routes are internally marked using locally-meaningful communities).

• Improvement: RPKI ROAs files are checked for stale data.

  The JSON files fetched from validating caches are now checked to detect stale data (rpki-client and OctoRPKI formats include this information) and they are ignored if the data they contain is no longer valid. In this case, the next URL in the rpki_roas.ripe_rpki_validator_url list is used.

  By default, files whose content is older than 21600 seconds (6 hours) are ignored; it's possible to change this option via the newly introduced rpki_roas.ignore_cache_files_older_than setting.

  Where available (rpki-client format only at this time), also the VRP expiration time is checked.

  As a consequence of this, the default ARouteServer cache expiration time for RPKI ROAs JSON files has been reduced to 60 minutes, to avoid caching ROAs that would turn out being expired at the next use of their cached copy.

• Improvement: new order for the default URLs of the RPKI JSON files.

  Since the RIPE NCC RPKI Validator is now in EoL, the URL of the JSON file that points to rpki-validator.ripe.net has been moved as the last resort option for rpki_roas.ripe_rpki_validator_url.
  The one exposed in the rpki-client dashboard has been added.

  Please note: this change only affects the default configuration file that ships with ARouteServer and is not be automatically reflected in existing configurations that route-servers operators are already using. If you wish this setup to be reflected in your configuration, please update your general.yml file accordingly.