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 :doc:`configure logging `. For details regarding the ``rtt_getter_path`` option please see :doc:`RTT_GETTER`. - ``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 :doc:`GENERAL` 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 :doc:`GENERAL` 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. .. contents:: :local: YAML files inclusion and environment variables expansion ******************************************************** ARouteServer's ``general.yml`` and ``clients.yml`` configuration files can contain a custom directive (``!include ``) 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 :ref:`Building configurations for multiple route servers`. Example with environment variables expansion: **general.yml** .. code:: yaml cfg: router_id: "${ROUTER_ID}" rs_as: 999 passive: True gtsm: True filtering: [...] Example with file inclusion: **general-rs1.yml** .. code:: yaml cfg: router_id: "192.0.2.1" !include general-shared.yml **general-rs2.yml** .. code:: yaml cfg: router_id: "192.0.2.2" !include general-shared.yml **general-shared.yml** .. code:: yaml #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** .. code:: yaml 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: .. code:: 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** .. code:: yaml cfg: rs_as: 999 router_id: "192.0.2.2" passive: True gtsm: True **clients.yml** .. code:: yaml 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 :doc:`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** .. code:: yaml 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: .. code:: yaml 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 :ref:`.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** .. code:: yaml cfg: # ... communities: do_not_announce_to_peer: std: "0:peer_as" **clients.yml** .. code:: yaml 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 :ref:`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** .. code:: yaml 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** .. code:: yaml 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-config: 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: .. autoattribute:: pierky.arouteserver.builder.BIRDConfigBuilder.LOCAL_FILES_IDS - OpenBGPD: .. autoattribute:: pierky.arouteserver.builder.OpenBGPDConfigBuilder.LOCAL_FILES_IDS 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: .. code:: 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``: .. code-block:: console :emphasize-lines: 2, 16 $ 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``: .. code-block:: console :emphasize-lines: 10, 15, 22 $ 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: .. code:: 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: 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: .. autoattribute:: pierky.arouteserver.builder.BIRDConfigBuilder.HOOKS Functions with name ``hook_`` must then be implemented within *.local* configuration files, in turn included using the ``--use-local-files`` command line argument. Example: .. code-block:: console :emphasize-lines: 13, 21, 22 $ 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 :doc:`BIRD_HOOKS` page. An example (including functions' prototypes) is provided within the "examples/bird_hooks" directory (`also on GitHub `_). .. _custom_options: 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: .. code:: yaml 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: .. code:: yaml 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: 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 :ref:`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: .. include:: REJECT_REASON_COMMUNITIES.txt \* 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: .. code:: yaml 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 :ref:`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: .. code-block:: console $ 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 ...