Configuration

Program configuration

ARouteServer needs the following files to read its own configuration and to determine the policies to be implemented in the route server:

arouteserver.yml: the main ARouteServer configuration file; it contains options and paths to other files (templates, cache directory, external tools…). By default, ARouteServer looks for this file in ~/arouteserver and /etc/arouteserver. This path can be changed using the --cfg command line argument. See its default content on GitHub.

The logging_config_file parameter here included can be used to configure logging.

For details regarding the rtt_getter_path option please see RTT getter program for RTT-based actions.
general.yml: this is the most important configuration file, where the route server’s options and policies are configured. By default, it is located in the same directory of the main configuration file; its path can be set with the cfg_general option in arouteserver.yml. See its default content on GitHub.

An automatically generated reStructuredText version of the file with all its options and comments can be found in the Route server configuration - options and features page.
clients.yml: the list of route server’s clients and their options and policies. By default, it is located in the same directory of the main configuration file; its path can be set with the cfg_clients option in arouteserver.yml. See its default content on GitHub.
bogons.yml: the list of bogon prefixes automatically discarded by the route server. By default, it is located in the same directory of the main configuration file; its path can be set with the cfg_bogons option in arouteserver.yml. See its default content on GitHub.

The arouteserver setup command can be used to setup the environment where ARouteServer is executed and to install the aforementioned files in the proper places.

Route server’s configuration

Route server’s general configuration and policies are outlined in the general.yml file.

Configuration details and options can be found within the distributed general and clients configuration files on GitHub or in the Route server configuration - options and features page.

A Docker-based playground is available to experiment with the settings in a virtual IXP environment.

Details about some particular topics are reported below.

YAML files inclusion and environment variables expansion 

ARouteServer’s general.yml and clients.yml configuration files can contain a custom directive (!include <filepath>) that can be used to include other files. Moreover, environment variables (${VAR_NAME}) are expanded when the configuration files are loaded. This can be useful, for example, when the same configuration is shared by two route servers that differ only in their router ID.

Hint

For an alternative way to build configurations for multiple router servers, all running on the same BGP daemon but with just different router IDs, see Building configurations for multiple route servers.

Example with environment variables expansion:

general.yml

cfg:
  router_id: "${ROUTER_ID}"
  rs_as: 999
  passive: True
  gtsm: True
  filtering:
    [...]

Example with file inclusion:

general-rs1.yml

cfg:
  router_id: "192.0.2.1"
  !include general-shared.yml

general-rs2.yml

cfg:
  router_id: "192.0.2.2"
  !include general-shared.yml

general-shared.yml

#cfg:
# keep the indentation level of the line where
# the !include statement is placed
  rs_as: 999
  passive: True
  gtsm: True
  filtering:
    [...]

Building configurations for multiple route servers 

A single execution of ARouteServer can be used to generate configurations for multiple route servers, all for the same BGP daemon and with the same characteristics. This helps to reduce the time needed to gather all the external information needed to build the configuration, like IRR objects, RPKI data, and so on, and to guarantee that all the router servers will behave exactly in the same way, on top of a shared set of input records.

It can be accomplished by setting the router_id in the general.yml file with a list of router IDs instead of just a single one.

general.yml

cfg:
  rs_as: 999
  router_id: ["192.0.2.2", "192.0.2.3"]
  # ...

In this way, when arouteserver is executed, the path of the file that is passed via the -o / --output argument is used as the root name for the various files that the tool will create, one for each value of router_id, where the router ID is appended to the base name of the file provided.

Example:

arouteserver bird --ip-ver 4 --output /etc/bird/bird.cfg

Using the example YAML file above, when this command is executed, the following files will be generated:

/etc/bird/bird-192.0.2.2.cfg, with the configuration for router ID 192.0.2.2;
/etc/bird/bird-192.0.2.3.cfg, with the same configuration above, but for router ID 192.0.2.3;
/etc/bird/bird.cfg, with the following text, just for reference:

Configuration for router_id 192.0.2.2: /etc/bird/bird-192.0.2.2.cfg
Configuration for router_id 192.0.2.3: /etc/bird/bird-192.0.2.3.cfg

If stdout is used as the output, then a comment string will be used to separate the two configurations generated by the tool.

When multiple configurations are desired for route servers that run on different BGP daemons, setting a list of router IDs in general.yml would not work. In this situation, the suggestion is to tune the cache_expiry settings in the arouteserver.yml file, so that once the external objects are gathered by the first execution of the program, they can be re-used for the following ones, if performed within a reasonable amount of time. More info on the comments of arouteserver.yml on GitHub.

Client-level options inheritance 

Clients, which are configured in the clients.yml file, inherit most of their options from those provided in the general.yml file, unless their own configuration sets more specific values.

Options that are inherited by clients and that can be overwritten by their configuration are highlighted in the general.yml template file that is distributed with the project.

Example:

general.yml

cfg:
  rs_as: 999
  router_id: "192.0.2.2"
  passive: True
  gtsm: True

clients.yml

clients:
  - asn: 11
    ip: "192.0.2.11"
  - asn: 22
    ip: "192.0.2.22"
    passive: False
  - asn: 33
    ip: "192.0.2.33"
    cfg:
      passive: False
      gtsm: False

In this scenario, the route server’s configuration will look like this:

a passive session with GTSM enabled toward AS11 client;
an active session with GTSM enabled toward AS22 client;
an active session with GTSM disabled toward AS33 client.

IRRDBs-based filtering 

The filtering.irrdb section of the configuration files allows to use IRRDBs information to filter or to tag routes entering the route server. Information are acquired using the external program bgpq4 or bgpq3: installations details on Installation page.

One or more AS-SETs can be used to gather information about authorized origin ASNs and prefixes that a client can announce to the route server. AS-SETs can be set in the clients.yml file on a two levels basis:

within the asns section, one or more AS-SETs can be given for each ASN of the clients configured in the rest of the file;
for each client, one or more AS-SETs can be configured in the cfg.filtering.irrdb section.

To gather information from the IRRDBs, at first the script uses the AS-SETs provided in the client-level configuration; if no AS-SETs are provided there, it looks to the ASN configuration. If no AS-SETs are found in both the client and the ASN configuration, if the cfg.filtering.irrdb.peering_db option is set to True the AS-SET from PeeringDB is used (“IRR Record” field). The ASN’s autnum object will be used in any case.

Example:

clients.yml

asns:
  AS22:
    as_sets:
      - "AS-AS22MAIN"
  AS33:
    as_sets:
      - "AS-AS33GLOBAL"
clients:
  - asn: 11
    ip: "192.0.2.11"
    cfg:
      filtering:
        irrdb:
          as_sets:
            - "AS-AS11NETS"
  - asn: 22
    ip: "192.0.2.22"
  - asn: 33
    ip: "192.0.2.33"
    cfg:
      filtering:
        irrdb:
          as_sets:
            - "AS-AS33CUSTOMERS"
  - asn: 44
    ip: "192.0.2.44"

With this configuration, the following values will be used to run the bgpq4/bgpq3 program:

AS-AS11NETS will be used for 192.0.2.11 (it’s configured at client-level for that client);
AS-AS22MAIN for the 192.0.2.22 client (it’s inherited from the asns-level configuration of AS22, client’s AS);
AS-AS33CUSTOMERS for the 192.0.2.33 client (the asns-level configuration is ignored because a more specific one is given at client-level);
AS44 for the 192.0.2.44 client, because no AS-SETs are given at any level. In this case, if the cfg.filtering.irrdb.peering_db was set to True, the AS-SET from PeeringDB would be used.

Optionally, the source that must be used to expand the AS macro can be prepended, followed by two colon characters: RIPE::AS-FOO, RADB::AS64496:AS-FOO.

Use RPKI ROAs as if they were route objects 

If the filtering.irrdb.use_rpki_roas_as_route_objects option is enabled, RPKI ROAs are used as if they were route objects to validate routes whose origin ASN is already authorized by a client’s AS-SET but whose prefix is not. A lookup into the ROA table is made on the basis of the route origin ASN and, if a covering ROA is found, the route is validated. In this case, if the filtering.irrdb.tag_as_set general option is True the prefix_validated_via_rpki_roas informative community is added to the route.

Please refer to ROAs sources in order to configure the source that should be used to gather RPKI ROAs.

Use ARIN Whois database to accept routes 

Warning

Please note that the ARIN Advisory Counsel recommended the ARIN Board of Trustees to deprecate the “ARIN AS Origins” feature in the ARIN WHOIS database. See https://www.arin.net/participate/policy/drafts/2021_8/ and also https://github.com/pierky/arouteserver/issues/116. Consequently, this feature will be removed in future releases of ARouteServer, and starting from v1.19.0 a warning message will be logged during the route server config generation process if it is enabled.

Similarly to the previous option, filtering.irrdb.use_arin_bulk_whois_data allows to support IRR-based filters with additional data. Records from the ARIN Whois database are used to accept those routes whose origin ASN is authorized by the client’s AS-SET but whose prefix has not a registered route object. In this case, a lookup into the ARIN Whois database is made on the basis of the origin ASN and if a covering entry is found the route is accepted.

The ARIN Whois database can be obtained by signing an agreement with ARIN. It must be then converted into the appropriate JSON format that ARouteServer expects to find; the arin-whois-bulk-parser script can be used for this purpose.

Further details can be found in this message appeared on the NANOG mailing list.

White lists 

In addition to prefixes and ASNs gathered as said above, white lists can be configured at client level to manually enter prefixes and origin ASNs that will be treated as if they were included within clients’ AS-SET.

If the filtering.irrdb.tag_as_set general option is also set to True, routes that fail the basic IRR filters but that are accepted solely because they match a white list entry are tagged with the prefix_not_present_in_as_set and origin_not_present_in_as_set informational communities.

Example:

clients:
  - asn: 11
    ip: "192.0.2.11"
    cfg:
      filtering:
        irrdb:
          as_sets:
            - "AS-AS11NETS"
          white_list_route:
            - prefix: "203.0.113.0"
              length: 24
              asn: 65534

This configuration allows to authorize routes for 203.0.113.0/24{24-32} with origin ASN 65534 received from the client.

RPKI 

ROAs sources 

A couple of methods can be used to acquire RPKI data (ROAs):

the builtin method based on RIPE RPKI Validator format JSON export file (also generated by other validators like Routinator, rpki-client, OctoRPKI): the URL of a local and trusted instance of a RPKI validator should be provided to ensure that a trusted dataset is used. By default, the URLs of some public instances are used.
RTR protocol (only on BIRD and OpenBGPD >= 6.9):
- BIRD 1.6.x: the rtrlib suite: rtrlib and bird-rtrlib-cli.
- BIRD v2/v3: the built-in RTR protocol implementation.
- OpenBGPD >= 6.9: the built-in RTR protocol implementation.
One or more trusted local validating caches should be used to get and validate ROAs before pushing them to BIRD or OpenBGPD. Extensive information on RPKI and how to setup validating caches can be found on https://rpki.readthedocs.io/. For BIRD v2/v3 and OpenBGPD, an example of how to configure the RTR protocol and use it with ARouteServer can be found in the examples/rpki_rtr directory (also on GitHub).

The configuration of ROAs source can be done within the rpki_roas section of the general.yml file.

Origin validation 

RPKI-based validation of routes can be configured using the general filtering.rpki_bgp_origin_validation section. RFC8097 BGP extended communities are used to mark routes on the basis of their validity state. Depending on the reject_invalid configuration, INVALID routes can be rejected before entering the route server or accepted for further processing by external tools or functions provided within .local files. INVALID routes are not propagated to clients.

BGP Communities 

BGP communities can be used for many features in the configurations built using ARouteServer: blackhole filtering, AS_PATH prepending, announcement control, various informative purposes (valid origin ASN, valid prefix, …) and more. All these communities are referenced by name (or tag) in the configuration files and their real values are reported only once, in the communities section of the general.yml file. For each community, values can be set for any of the three formats: standard (RFC1997), extended (RFC4360/RFC5668) and large (RFC8092).

Mapping of 32bit ASNs to 16bit ASNs 

To allow clients to use announcement control standard BGP communities (like do not announce to $PEER) with 32bit ASN clients, it’s possible to associate a private 16bit ASN to the 32bit ASN of the client. In this way the 32bit ASN client can be represented by the 16bit ASN from the mapping when those communities are used.

Example:

general.yml

cfg:
  # ...
 communities:
   do_not_announce_to_peer:
     std: "0:peer_as"

clients.yml

clients:
  - asn: 197000
    ip:
    - "192.0.2.33"
    16bit_mapped_asn: 64512

In the example above, the client with ASN 197000 (32 bit) is mapped to the private ASN 64512 via the 16bit_mapped_asn option. The do not announce to $PEER standard BGP community 0:64512 can be used by other clients to suppress the announcements of their routes towards the client with ASN 197000.

Please note that the 16bit ASN from 16bit_mapped_asn can be used only in standard BGP communities and not in extended or large communities.

Route server operators who generate their clients.yml file starting from the Euro-IX JSON file can use the --merge-from-custom-file option to keep track of the private ASN assigned to each client, and get it automatically added to the output file. See Create clients.yml file from Euro-IX member list JSON file.

Custom BGP Communities 

Custom, locally significant BGP communities can also be used for informational purposes, for example to keep track of the geographical origin of a route or the nature of the relation with the announcing route server client.

Custom communities are declared once in the general.yml configuration file and then are referenced by clients definitions in the clients.yml file.

Example:

general.yml

cfg:
  rs_as: 6777
  router_id: "80.249.208.255"
custom_communities:
  colo_digitalrealty_ams01:
    std: "65501:1"
    lrg: "6777:65501:1"
  colo_equinix_am3:
    std: "65501:2"
    lrg: "6777:65501:2"
  colo_evoswitch:
    std: "65501:3"
    lrg: "6777:65501:3"
  member_type_peering:
    std: "65502:1"
    lrg: "6777:65502:1"
  member_type_probono:
    std: "65502:2"
    lrg: "6777:65502:2"

clients.yml

clients:
  - asn: 112
    ip: "192.0.2.112"
    cfg:
      attach_custom_communities:
      - "colo_digitalrealty_ams01"
      - "member_type_probono"
  - asn: 22
    ip: "192.0.2.22"
    passive: False
    cfg:
      attach_custom_communities:
      - "colo_equinix_am3"
      - "member_type_peering"
  - asn: 33
    ip: "192.0.2.33"
    cfg:
      attach_custom_communities:
      - "colo_evoswitch"
      - "member_type_peering"

Customization 

Site-specific custom configuration files 

Local configuration files can be used to load static site-specific snippets of configuration into the BGP daemon, bypassing the dynamic ARouteServer configuration building mechanisms. These files can be used to configure, for example, neighborship with peers which are not route server members or that require custom settings, or to customize the BGP daemon logging levels and targets.

Local files inclusion can be enabled by a command line argument, --use-local-files: there are some fixed points in the configuration files generated by ARouteServer where local files can be included:

BIRD:

BIRDConfigBuilder.LOCAL_FILES_IDS = ['logging', 'header', 'header4', 'header6', 'footer', 'footer4', 'footer6', 'client', 'client4', 'client6']
OpenBGPD:

OpenBGPDConfigBuilder.LOCAL_FILES_IDS = ['logging', 'header', 'pre-irrdb', 'post-irrdb', 'pre-clients', 'post-clients', 'client', 'pre-filters', 'post-filters', 'footer']

To determine in which point of the configuration file the local files identified by the labels above are inserted, please refer to the template files of each BGP speaker (you can search for include_local_file):

BIRD: see main.j2, header.j2, clients.j2 and rpki.j2.
OpenBGPD: see main.j2, header.j2, filters.j2, rpki.j2, clients.j2, irrdb.j2.

One or more of these labels must be used as the argument’s value in order to enable the relative inclusion points. For each enabled label, an include statement is added to the generated configuration in the point identified by the label itself. To modify the base directory, the --local-files-dir command line option can be used.

These files must be present on the host running the route server.

Example, BIRD, file name “footer4.local” in “/etc/bird” directory:

protocol bgp RouteCollector {
  local as 999;
  neighbor 192.0.2.99 as 65535;
  rs client;
  secondary;

  import none;
  export all;
}

Example, OpenBGPD, header and post-clients:

$ arouteserver openbgpd --use-local-files header post-clients
include "/etc/bgpd/header.local"

AS 999
router-id 192.0.2.2

[...]

group "clients" {

        neighbor 192.0.2.11 {
                [...]
        }
}

include "/etc/bgpd/post-clients.local"

[...]

In the example above, the header and post-clients inclusion points are enabled and allow to insert two include statements into the generated configuration: one at the start of the file and one between clients declaration and filters.

Example, OpenBGPD, client and footer:

$ arouteserver openbgpd --use-local-files client footer --local-files-dir /etc/
AS 999
router-id 192.0.2.2

[...]

group "clients" {

        neighbor 192.0.2.11 {
                include "/etc/client.local"
                [...]
        }

        neighbor 192.0.2.22 {
                include "/etc/client.local"
                [...]
        }
}

[...]

include "/etc/footer.local"

The example above uses the client label, that is used to add an include statement into every neighbor configuration. Also, the base directory is set to /etc/.

Logging configuration of the BGP daemon 

The logging label has a special meaning: when it’s used in the --local-files-dir option, the default logging settings of the BGP speaker are omitted, and they are replaced by the include statement.

To determine the default logging configuration, please refer to the template files:

BIRD: see header.j2
OpenBGPD: see header.j2

As you can see in the next example, the default logging settings are omitted and replaced with the include statement for logging.local.

Example, BIRD, logging being used:

router id 192.0.2.123;
define rs_as = 65500;

include "/etc/bird/logging.local";

timeformat base         iso long;
timeformat log          iso long;
timeformat protocol     iso long;
timeformat route        iso long;

BIRD hooks 

In BIRD, hook functions can also be used to tweak the configuration generated by ARouteServer. Hooks are enabled by the --use-hooks command line argument, that accepts one or more of the following hook IDs:

BIRDConfigBuilder.HOOKS = ['pre_receive_from_client', 'post_receive_from_client', 'pre_announce_to_client', 'post_announce_to_client', 'route_can_be_announced_to', 'announce_rpki_invalid_to_client', 'scrub_communities_in', 'scrub_communities_out', 'apply_blackhole_filtering_policy']

Functions with name hook_<HOOK_ID> must then be implemented within .local configuration files, in turn included using the --use-local-files command line argument.

Example:

$ arouteserver bird --ip-ver 4 --use-local-files header --use-hooks pre_receive_from_client
router id 192.0.2.2;
define rs_as = 999;

log "/var/log/bird.log" all;
log syslog all;
debug protocols all;

protocol device {};

table master sorted;

include "/etc/bird/header.local";

[...]

filter receive_from_AS3333_1 {
        if !(source = RTS_BGP ) then
                reject "source != RTS_BGP - REJECTING ", net;

        if !hook_pre_receive_from_client(3333, 192.0.2.11, "AS3333_1") then
                reject "hook_pre_receive_from_client returned false - REJECTING ", net;

        scrub_communities_in();

[...]

Details about hook functions can be found in the BIRD hooks specifications page.

An example (including functions’ prototypes) is provided within the “examples/bird_hooks” directory (also on GitHub).

Client custom options 

BGP speakers can also be configured using custom options defined on a client basis.

In the client YAML definition file, the custom_options key can be set inside the cfg section to define custom lines of configuration that are eventually added to the configuration file generated by ARouteServer, on a client-by-client basis.

The expected format follows:

clients:
- ... # client definition here
  cfg:
    custom_options:
      bird | openbgpd:
        ipv4 | ipv6 | any:
          protocol | channel | client:
            config_lines:
            - "BGP-speaker specific line of config 1"
            - "BGP-speaker specific line of config 2"

These custom lines of configuration are pulled into the final output file on an BGP-speaker and Address-Family basis: when the target BGP speaker is BIRD, only the custom_options.bird section is considered, and similarly for custom_options.openbgpd when OpenBGPD is used. The custom lines of configuration from the ipv4 or ipv6 sub-sections are applied only to the IPv4 or IPv6 session of the client to which they belong, while the lines from the any sub-section are always applied. For BIRD, two levels exist, protocol and channel: the former is used on BIRD 1.6 and BIRD 2 configurations, the latter only on BIRD 2 (depending on which BIRD config stanza the custom lines are desired to be added to, protocol-level of channel-level). For OpenBGPD, only the client level exists.

An example follows:

clients:
- asn: 123
  ip:
  - "192.0.2.11"
  - "fe80::123:456"
  cfg:
    custom_options:
      bird:
        any:
          protocol:
            config_lines:
            - interface "eth0";
        ipv6:
          channel:
            config_lines:
            - extended next hop on;
      openbgpd:
        any:
          client:
            config_lines:
            - holdtime 30

In the example above, we can see that for the AS123 client the BIRD 2 route-server will be configured to use eth0 for both the IPv4 and IPv6 sessions; Extended Next-Hop will be enabled on the IPv6 session; the OpenBGPD configuration for that client will have a holdtime of 30 seconds for both the IPv4 and IPv6 sessions.

Warning

ARouteServer functionalities may be adversely affected by the usage of custom options; the tool does not check the content of the custom_options section, so if options that contradict or overlap with those used by ARouteServer are set, the output configuration may not reflect the expected results. Please double check the settings provided here and test them carefully before releasing them in production.

Reject policy and invalid routes tracking 

Invalid routes, that is those routes that failed the validation process, can be simply discarded as they enter the route server (default behaviour) or, optionally, they can be kept for troubleshooting purposes, analysis or statistic reporting (for example using a looking glass).

The reject_policy configuration option can be set to tag in order to have invalid routes tagged with a user-configurable BGP Community (reject_reason) whose purpose is to keep track of the reason for which they are considered to be invalid. These routes are also set with a low local-pref value (1) and tagged with a control BGP Community that prevents them from being exported to clients. If configured, the rejected_route_announced_by community is used to track the ASN of the client that announced the invalid route to the route server.

The goal of this feature is to allow the deployment of route collectors that can be used to further process invalid routes announced by clients. These route collectors can be configured using site-specific .local files. The InvalidRoutesReporter is an example of this kind of route collector.

The reason that led the server to reject the route is identified using a numeric value in the last part of the BGP Community; the list of reject reasons follow:

Reject reasons 

ID

Reason

0

Special meaning: the route must be treated as rejected. *

1

Invalid AS_PATH length

2

Prefix is bogon

3

Prefix is in global blacklist

4

Invalid AFI

5

Invalid NEXT_HOP

6

Invalid left-most ASN

7

Invalid ASN in AS_PATH

8

Transit-free ASN in AS_PATH

9

Origin ASN not in IRRDB AS-SETs

10

IPv6 prefix not in global unicast space

11

Prefix is in client blacklist

12

Prefix not in IRRDB AS-SETs

13

Invalid prefix length

14

RPKI INVALID route

15

Never via route-servers ASN in AS_PATH

65535

Unknown

* This is not really a reject reason code, it only means that the route must be treated as rejected and must not be propagated to clients.

On BIRD, it’s also possible to configure the reject_policy using the tag_and_reject value: doing this, the reject_reason and optionally the rejected_route_announced_by BGP communities are still attached to the invalid routes, but then they are rejected by BIRD. Since the BIRD-specific import keep filtered on configuration statement is used, those routes remain available within the BIRD daemon and can be seen using BIRD-specific commands like show route filtered all.

Additional custom BGP communities to track reject reasons 

When the reject policy is set to tag (or tag_and_reject), in addition to the reject_reason community some custom BGP communities can be configured for each reject code of those implemented in ARouteServer (see the list above).

This can be done using the reject_cause_map option:

cfg:
  # ...
  communities:
    # ...
    reject_cause_map:
      1:
        lrg: rs_as:1101:5
      2:
        lrg: rs_as:1101:3

When a route that doesn’t pass the inbound validation process is received, the communities corresponding to the reject code that led to its refusal are attached to the route itself.

In the example above, routes towards bogon IP prefixes (reject code 2) are tagged with the large BGP community rs_as:1101:3 (in addition to the community configured in reject_reason).

This option is leveraged by the configure command to automatically generate policies (general.yml files) that use the Euro-IX Large BGP Communities to track the discard reasons.

Caveats and limitations 

Not all features offered by ARouteServer are supported by both BIRD and OpenBGPD. The following list of limitations is based on the currently supported versions of BIRD and OpenBGPD.

IRR filtering of routes whose AS_PATH ends with an AS_SET
- BIRD: routes are rejected by the IRR filters.
- OpenBGPD: if the last non-aggregated AS in the AS_PATH is included in the list of ASNs generated from the IRR records, the routes pass the IRR filters.
  
  More details on GitHub PR56 (commit a65934a).
BIRD
- Multihop sessions are only supported on configurations for which path hiding mitigation is turned off.
  
  More details on GitHub PR61.
OpenBGPD
- ADD-PATH is not supported by OpenBGPD.
- For max-prefix filtering, only the shutdown and the restart actions are supported by OpenBGPD. Restart is configured with a 15 minutes timer.
- The Site of Origin Extended BGP communities in the range 65535:* are reserved for internal reasons.

A list of all the features and their support level among the BGP speakers is maintained on the Supported BGP speakers and features section of this documentation.

Depending on the features that are enabled in the general.yml and clients.yml files, compatibility issues may arise; in this case, ARouteServer logs one or more errors, which can be then acknowledged and ignored using the --ignore-issues command line option:

$ arouteserver openbgpd
ARouteServer 2017-03-23 21:39:45,955 ERROR Compatibility issue ID 'path_hiding'. The 'path_hiding'
general configuration parameter is set to True, but the configuration generated by ARouteServer for
OpenBGPD does not support path-hiding mitigation techniques.
ARouteServer 2017-03-23 21:39:45,955 ERROR One or more compatibility issues have been found.

Please check the errors reported above for more details.
To ignore those errors, use the '--ignore-issues' command line argument and list the IDs of the
issues you want to ignore.
$ arouteserver openbgpd --ignore-issues path_hiding
AS 999
router-id 192.0.2.2

fib-update no
log updates
...