Permalink
Fetching contributors…
Cannot retrieve contributors at this time
1019 lines (945 sloc) 35.9 KB
# This is the reference route server policy definition file
# distributed with ARouteServer.
#
# -------------------------------------------------------------------
# DO NOT EDIT THIS FILE
# -------------------------------------------------------------------
#
# This file should be only used as a guide where comments about
# options and settings can be found. Do not edit this file but rather
# make a copy of it or, even better, use the 'arouteserver configure'
# command to build your own version of the 'general.yml' file.
cfg:
# The route server AS number.
rs_as: 999
# The route server's router ID.
router_id: "192.0.2.2"
# Prepend the route server's AS number to the AS_PATH of routes
# that it announces to clients.
# https://tools.ietf.org/html/rfc7947#section-2.2.2.1
#
# Can be overwritten on a client-by-client basis.
#
# Default: False
prepend_rs_as: False
# Path-hiding mitigation technique: if True, enable path
# hiding mitigation.
# (https://tools.ietf.org/html/rfc7947#section-2.3.1)
#
# BIRD: the "secondary" option is used.
# "Usually, if an export filter rejects a selected route, no
# other route is propagated for that network. This option
# allows to try the next route in order until one that is
# accepted is found or all routes for that network are rejected."
# (http://bird.network.cz/?get_doc&f=bird-6.html#bgp-secondary)
#
# OpenBGPD: not implemented in ARouteServer. Single RIB only.
#
# Default: True
path_hiding: True
# Configure passive sessions.
#
# Can be overwritten on a client-by-client basis.
#
# Default: True
passive: True
# Use GTSM (Generalized TTL Security Mechanism).
# https://tools.ietf.org/html/rfc5082
#
# Can be overwritten on a client-by-client basis.
#
# Default: False
gtsm: False
# Use ADD-PATH (RFC7911).
# The route server will be configure as "able to send multiple
# paths to its peer".
#
# OpenBGPD: not supported.
#
# Can be overwritten on a client-by-client basis.
#
# Default: False
add_path: False
filtering:
# NEXT_HOP checks
#
next_hop:
# The 'policy' option can be set using the following values:
# - 'strict': "check that the BGP NEXT_HOP attribute for BGP
# routes received from a route server client matches the
# interface address of the client."
# - 'same-as': permit next-hop rewriting for the same AS; this
# "allows an organization with multiple connections into an
# IXP configured with different IP addresses to direct traffic
# off the IXP infrastructure through any of their connections
# for traffic engineering or other purposes."
# In this mode, all the IP addresses of clients that fall
# under the same ASN will be allowed. This is limited to the
# IP addresses of known clients configured in the 'clients.yml'
# file.
# - 'authorized_addresses': check that the BGP NEXT_HOP attribute
# for routes received from a route server client matches one
# of the IP addresses reported in the client-specific
# 'authorized_addresses_list' option.
# This allows a route server client to announce routes whose
# NEXT_HOP attribute is the IP address of a non-client router.
# The 'authorized_addresses_list' option must be configured
# in the 'clients.yml' file for those clients that have
# 'policy' set to 'authorized_addresses'.
#
# https://tools.ietf.org/html/rfc7948#section-4.8
#
# Can be overwritten on a client-by-client basis.
#
# Default: strict
policy: "strict"
# Min and max prefix length for IPv4 and IPv6 prefixes accepted
# by the route server. Boundaries are inclusive.
#
# Can be overwritten on a client-by-client basis.
#
# Default: 8-24 for IPv4, 12-48 for IPv6
ipv4_pref_len:
min: 8
max: 24
ipv6_pref_len:
min: 12
max: 48
# List of prefixes that are unconditionally rejected.
# For example: local networks.
#
# A list of prefixes is expected to be found here, like the one
# reported in the 'bogons.yml' file.
#
# Default: none
global_black_list_pref:
#- prefix: "192.0.2.0"
# length: 24
# comment: "Local network"
# Max length of AS_PATH attribute.
#
# Can be overwritten on a client-by-client basis.
#
# Default: 32
max_as_path_len: 32
# Reject routes that carry private/invalid AS numbers in
# their AS_PATH.
# http://mailman.nanog.org/pipermail/nanog/2016-June/086078.html
#
# Can be overwritten on a client-by-client basis.
#
# Default: True
reject_invalid_as_in_as_path: True
transit_free:
# Transit-free networks' ASNs should appear in AS_PATH only
# in the left-most position.
# If a policy is given here, it is applied to routes whose
# AS_PATH contains one of the following ASN in any position
# different from the first:
#
# - 'reject': the route is discarded.
# - 'warning': a warning is logged.
#
# OpenBGPD: used only if action is 'reject'.
#
# Default: none
#action: "reject"
# Comma separated list of ASNs which are considered
# transit-free. Used only if an 'action' is provided above.
asns: >
174, 209, 286, 701, 1239, 1299, 2828, 2914,
3257, 3320, 3356, 3549, 5511, 6453, 6461,
6762, 6830, 7018, 12956
irrdb:
# With regards of the following two options, if no AS-SET
# is given in the clients configuration file for the
# specific client nor for its AS, then only the ASN
# of the announcing client is expanded and used to gather
# authorized origin ASNs and prefixes.
# If the 'peering_db' option below within this section is set
# to True, ARouteServer acquires the AS-SET of the client ASN
# from PeeringDB.
#
# More details on the Configuration page on ReadTheDocs:
# https://arouteserver.readthedocs.io/en/latest/CONFIG.html
# Accept only routes whose origin ASN is registered in
# the expanded AS-SET of the announcing client.
#
# Can be overwritten on a client-by-client basis.
#
# Default: True
enforce_origin_in_as_set: True
# Accept only prefixes which are present in the expanded
# AS-SET of the announcing client.
#
# Can be overwritten on a client-by-client basis.
#
# Default: True
enforce_prefix_in_as_set: True
# By default, only prefixes that have a strict correspondence
# in the route-set obtained by expading the AS-SET are
# allowed.
# If this is set to True, more specific prefixes that don't
# have a strict correspondence with but that are covered by a
# prefix from the route-set are accepted as well.
#
# Default: False
allow_longer_prefixes: False
# Tag routes whose prefix is (not) present in a client's AS-SET.
# If a client's 'enforce_[origin|prefix]in_as_set' is True
# then unauthorized routes are rejected and not tagged
# (unless they match a client-level 'white_list_route' entry).
# BGP communities used to tag these routes are:
# - '[origin|prefix]_(not_)present_in_as_set'
# - 'prefix_validated_via_rpki_roas'
# - 'prefix_validated_via_arin_whois_db_dump'
# - 'prefix_validated_via_registrobr_whois_db_dump'
# - 'route_validated_via_white_list' (only for routes validated
# solely because of a client-level 'white_list_route' entry)
#
# Default: True
tag_as_set: True
# If this option is set to True and no AS-SETs are given for
# a client nor for its ASN then ARouteServer tries to acquire
# the AS-SET from PeeringDB.
# Please note that data quality in PeeringDB has large
# variations; setting this option to True could lead to
# unwanted and unpredictable behaviours.
#
# Default: False
peering_db: False
use_rpki_roas_as_route_objects:
# With regards of prefix validation, when this option is
# enabled ARouteServer uses RPKI ROAs as if they were route
# objects.
# Routes whose origin ASN is authorized by a client's AS-SET
# but whose prefix has not a corresponding route object will
# be accepted if a covering ROA exists for that origin
# ASN. In this case, if 'tag_as_set' is True, these routes
# are tagged with the 'prefix_validated_via_rpki_roas'
# community.
# Set this to True to enable this feature.
#
# When enabled, the 'rpki_roas' section must be configured in
# order to set the method used to gather RPKI ROAs.
#
# Default: False
enabled: False
use_arin_bulk_whois_data:
# Similarly to the 'use_rpki_roas_as_route_objects' option,
# this one allows to back IRR filters up by using "Origin AS"
# data from an ARIN bulk Whois database dump. It is a dump
# of the whole ARIN Whois database that contains all the
# prefixes for which one or more authorized origin ASNs
# have been set by the resource holder.
# Routes whose origin ASN is authorized by a client's AS-SET
# but whose prefix has not a corresponding route object will
# be accepted if an entry exists in this database for that
# origin ASN.
# In this case, if 'tag_as_set' is True, these routes
# are tagged with the
# 'prefix_validated_via_arin_whois_db_dump' community.
#
# The setting of the 'allow_longer_prefixes' option will be
# honored.
#
# See also:
# https://mailman.nanog.org/pipermail/nanog/2017-December/093525.html
# Set this to True to enable this feature.
#
# Default: False
enabled: False
# The source of the data must be set here.
#
# It can be an 'http://' or 'https://' URL or a local file
# path. The file must be in JSON format, accordingly to the
# following schema:
#
# {
# "json_schema": "0.0.2",
# "source": "ARIN-WHOIS",
# "whois_records": {
# "v4": [{"originas": "ASxxx", "prefix": "w.x.y.z/l"}],
# "v6": [{"originas": "ASxxx", "prefix": "a:b:c:d::/l"}]
# }
# }
#
# Optionally it can be compressed in BZ2 format. In that
# case the filename must end with the ".bz2" extension.
#
# The following script can be used to convert the original
# XML file provided by ARIN into the expected JSON format:
#
# https://github.com/NLNOG/arin-whois-bulk-parser
#
# Default: URL of the dump parsed and published by NLNOG.
source: "http://irrexplorer.nlnog.net/static/dumps/arin-whois-originas.json.bz2"
use_registrobr_bulk_whois_data:
# Similarly to the 'use_arin_bulk_whois_data' option,
# this one allows to back IRR filters up by using "Registro.br"
# data from the NIC.BR Whois database.
# In this case, if 'tag_as_set' is True, these routes
# are tagged with the
# 'prefix_validated_via_registrobr_whois_db_dump' community.
#
# The setting of the 'allow_longer_prefixes' option will be
# honored.
# Set this to True to enable this feature.
#
# Default: False
enabled: False
# The source of the data must be set here.
#
# It can be an 'http://', 'https://', 'ftp://' URL or a local
# file path. The file must be in CSV format, with '|' as a
# field separator, accordingly to the following schema:
#
# ASxxx|Organization|OrgID|w.x.y.z/l|a:b:c:d::/l|...
#
# Default: URL of the dump published by Registro.br.
source: "ftp://ftp.registro.br/pub/numeracao/origin/nicbr-asn-blk-latest.txt"
rpki_bgp_origin_validation:
# Enable BGP Prefix Origin Validation for routes received from
# clients.
# https://tools.ietf.org/html/rfc6811
#
# When enabled, the 'rpki_roas' section must be configured in
# order to set the method used to gather RPKI ROAs.
#
# Default: False
enabled: False
# If 'reject_invalid' is True, when an INVALID route is received
# the route server rejects it.
# If it is False, INVALID routes are accepted and tagged with
# RFC8097 BGP communities for further internal processing or
# to be used by external custom functions implemented in .local
# files.
# INVALID routes are not announced to clients.
#
# OpenBGPD: RFC8097 BGP communities tagging not yet implemented
#
# Can be overwritten on a client-by-client basis.
#
# Default: True
reject_invalid: True
max_prefix:
# Dynamically adjust max-prefix limit of each client on the
# basis of the following criteria, in priority order:
#
# - client's 'limit_ipv[4|6]' configuration statement, if
# given;
# - client's ASN PeeringDB record, if enabled by the
# 'peering_db' option;
# - general limit set in 'general_limit_ipv[4|6]', if given.
#
# In the end, if no limit is found for a given AF or if
# it is 0, no max-prefix limit is configured fot the
# specific client.
# If 'action' is not given, no max-prefix enforcement
# will be implemented.
#
# Action to be taken when the limit is hit by clients:
# - 'shutdown': the BGP session is disabled.
# - 'restart': the BGP session is restarted.
# - 'block': new routes are discarded.
# - 'warning': log a warning message.
#
# OpenBGPD: used only if action is 'shutdown' or 'restart'.
#
# Can be overwritten on a client-by-client basis.
#
# Default: none
#action: "shutdown"
# OpenBGPD only: for the 'restart' action, sessions will be
# restarted after 'restart_after' minutes.
#restart_after: 15
peering_db:
# Used to set client's max-pref limit if 'limit_ipv[4|6]'
# option is not given for the specific client.
# If 'enabled' is True and client's max-pref limit is not
# set, ARouteServer fetches the limits from PeeringDB.
#
# Can be overwritten on a client-by-client basis.
#
# Default: True
enabled: True
# The following section can be used to accommodate cases of
# networks that fill the PeeringDB records using their exact
# route announcement count rather than a recommendation on
# what others should configure as max-prefix limit.
#
# The value that will be used is given by:
# (<PeeringDB value> + <absolute>) * (1 + <relative> / 100)
#
# Can be overwritten on a client-by-client basis.
increment:
# Absolute increment in terms of number of prefixes.
#
# Default: 100
absolute: 100
# Relative increment in terms of percentage.
#
# Default: 15
relative: 15
# Used to set client's max-pref limit if 'limit_ipv[4|6]'
# option is not given for the specific client and if the
# PeeringDB option is disabled or a PeeringDB record can't
# be found.
#
# Default: 170000 for IPv4 and 12000 for IPv6
#general_limit_ipv4: 170000
#general_limit_ipv6: 12000
reject_policy:
# The route server can be configured to immediately discard the
# routes that are considered to be rejected or to keep them and
# tag them with a BGP community that describes the cause for
# which they are considered so. These routes are not propagated
# to other clients anyway, but they can be used for analysis,
# statistics or reports.
# A numeric value is used to identify the reason that led to
# consider them as invalid; this identifier is used in the last
# part of the 'reject_cause' BGP community, that is finally
# attached to the route.
# The LOCAL_PREF attribute is also set to a value lower than the
# default one, to avoid invalid routes to be preferred over
# valid ones even in cases where path-hiding mitigation is not
# enabled.
#
# If 'policy' is set to 'reject', invalid routes are
# immediately discarded as they enter the route server.
# If it is set to 'tag', they are tagged as described above
# (and not propagated anyway to other clients). In this case,
# the 'reject_cause' BGP community must be also set.
#
# Can be overwritten on a client-by-client basis.
#
# Default: reject
policy: "reject"
rpki_roas:
# This section is used to configure how RPKI ROAs are gathered
# when 'filtering.irrdb.use_rpki_roas_as_route_objects' or
# 'filtering.rpki_bgp_origin_validation' are enabled.
# The source used to gather RPKI ROAs.
#
# Can be one of the following options:
# - 'rtrlib': ROAs are loaded using the external program
# rtrllib (https://github.com/rtrlib/bird-rtrlib-cli).
# The name of the table where send the ROAs to is 'RPKI'.
# - 'ripe-rpki-validator-cache': ROAs are fetched via
# HTTP from the RIPE RPKI Validator cache
# (http://localcert.ripe.net:8088/export.json by default).
#
# Please note that this method is far from guaranteeing
# that a cryptographically validated dataset is retrieved
# from a trusted cache, unless the URL of a local, trusted
# instance of RPKI Validator is provided below in the
# 'ripe_rpki_validator_url' option.
#
# OpenBGPD: only the 'ripe-rpki-validator-cache' source
# is currently supported.
#
# Default: ripe-rpki-validator-cache
source: "ripe-rpki-validator-cache"
# RIPE RPKI Validator URL.
# Meaningful only when 'source' is 'ripe-rpki-validator-cache'.
# It can be an 'http://' or 'https://' URL or the path of a
# local file.
#
# Default: http://localcert.ripe.net:8088/export.json
ripe_rpki_validator_url: "http://localcert.ripe.net:8088/export.json"
# When using the 'ripe-rpki-validator-cache' source, only the
# following Trust Anchors will be taken into account.
#
# Values must be taken among those published in the RIPE RPKI
# Validator Configured Trust Anchors page:
# http://localcert.ripe.net:8088/trust-anchors
#
# Before enabling the 'ARIN RPKI Root', please consider the
# following URLs:
#
# http://lists.arin.net/pipermail/arin-ppml/2017-January/031231.html
#
# https://www.arin.net/resources/rpki/rpa.pdf
#
# Default: APNIC, AfriNIC, LACNIC and RIPE NCC.
allowed_trust_anchors:
- "APNIC from AFRINIC RPKI Root"
- "APNIC from ARIN RPKI Root"
- "APNIC from IANA RPKI Root"
- "APNIC from LACNIC RPKI Root"
- "APNIC from RIPE RPKI Root"
- "AfriNIC RPKI Root"
- "LACNIC RPKI Root"
- "RIPE NCC RPKI Root"
#- "ARIN RPKI Root"
blackhole_filtering:
# Destination-based blackholing policy: if a policy is given,
# accept prefixes of any length if they are tagged with the
# 'blackholing' BGP community and if they are "covered by an
# equal or shorter prefix that the neighboring network is
# authorized to advertise."
# (https://tools.ietf.org/html/rfc7999#section-3.3).
# How to treat prefixes subject to blackhole filtering.
#
# If no policy is provided here then blackhole filtering is
# not implemented in the route server.
#
# Options:
# - 'propagate-unchanged': the route is accepted and propagated
# to clients unchanged. If missing, the BLACKHOLE well-known
# community 65535:666 is added. Other local 'blackholing'
# communities are scrubbed.
# It's up to the receiving client to accept the route and to
# discard traffic toward its prefix.
# - 'rewrite-next-hop': same behaviour of 'propagate-unchanged'
# option; in addition, the route server rewrites the NEXT_HOP
# attribute of the advertised route with the address of the
# blackhole next-hop (BN). BN should have a unique MAC
# address determined by ARP/NDP used to filter L2 frames
# entering clients ports on the basis of their destination
# MAC address.
#
# OpenBGPD: there is an issue that prevents the 'rewrite-next-hop'
# option to work for IPv6 on versions prior to OpenBSD 6.1.
# https://github.com/pierky/arouteserver/issues/3
#
# Default: none
#policy_ipv4:
#policy_ipv6:
# IP addresses of BN used for 'rewrite-next-hop' option:
#
# Default: none
#rewrite_next_hop_ipv4: "192.0.2.66"
#rewrite_next_hop_ipv6: "2001:db8::66"
# How tagged routes should be propagated to clients.
# This configuration statement works together with the same
# client-level 'blackhole_filtering.announce_to_client' option.
# If here 'announce_to_client' is True, tagged routes
# are announced to clients unless they have their
# 'announce_to_client' option explicitly set to False.
# If here 'announce_to_client' is False, tagged routes
# are announced to clients only if they have the
# 'announce_to_client' option explicitly set to True.
#
# Can be overwritten on a client-by-client basis.
#
# Default: True
announce_to_client: True
# Automatically add the NO_EXPORT well-known community to
# tagged routes before announcing them to clients.
#add_noexport: True
graceful_shutdown:
# Graceful BGP session shutdown (gshut) can be configured here.
# When 'enabled' is True, the route server processes the routes
# that are tagged with the GRACEFUL_SHUTDOWN BGP community
# (65535:0) accordingly to draft-ietf-grow-bgp-gshut, that is
# it lowers their LOCAL_PREF to the value set in 'local_pref'.
# (https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-11)
# Enable processing of GRACEFUL_SHUTDOWN BGP community.
#
# If 'enabled' is False in the general.yml configuration then
# routes tagged with the GRACEFUL_SHUTDOWN BGP community are
# treated transparently; the gshut community is not stripped
# off.
#
# If 'enabled' is True in the general.yml configuration but
# False on a specific client configuration then routes tagged
# with the GRACEFUL_SHUTDOWN BGP community received from that
# client will be treated as if the gshut community was missing
# and the community stripped off.
#
# OpenBGPD: GRACEFUL_SHUTDOWN BGP community is not implemented
# on versions prior to 6.2.
# Can be overwritten on a client-by-client basis.
#
# Default: False
enabled: False
# Value used to set the new LOCAL_PREF attribute of routes
# processed accordingly to gshut.
# Meaningful only when 'enabled' is True.
#
# Default: 0
local_pref: 0
rfc1997_wellknown_communities:
# RFC1997 well-known communities (NO_EXPORT and NO_ADVERTISE)
# can be locally interpreted or passed through the route server,
# depending on the policy that a route server operator decides
# to implement.
# This section allows to configure this policy.
# The policy used to process routes tagged with NO_EXPORT or
# NO_ADVERTISE that are received from clients.
#
# Options:
# - 'rfc1997': routes are processed accordingly to RFC1997;
# - 'pass': routes are propagated to other clients with the
# NO_EXPORT/NO_ADVERTISE communities unaltered.
#
# Default: pass
policy: "pass"
# Thresholds used for actions that are performed on the basis
# of clients RTT, triggered using RTT-based BGP communities.
#
# Used only if one or more of those BGP communities are set.
#
# The value in the last part of the community identifies the
# threshold for which the action is requested; only values from
# the 'rtt_thresholds' are taken into account and actually used
# to understand if the desired action should be performed.
#
# Lower-than actions are inclusive, higher-than are exclusive.
#
# Some examples (based on the default values below):
#
# - 15, lower-than: action is performed for peers with RTT <= 15
# - 30, higher-than: action is performed for peers with RTT > 30
# - 1000, not in 'rtt_thresholds', action not performed
# - 0, not in 'rtt_thresholds', action not performed
#
# The values must be provided in ascending order.
rtt_thresholds: 5, 10, 15, 20, 30, 50, 100, 200, 500
communities:
# For each community name below, Standard, Large and Extended
# BGP Communities can be provided in the 'std', 'lrg' and 'ext'
# statements respectively.
# Communities values must be given using the following formats:
# - 'std': 'x:x'
# - 'lrg': 'x:x:x'
# - 'ext': '[rt|ro]:x:x'
#
# The 'rs_as' macro is replaced with the route server ASN given
# in 'cfg.rs_as'.
# The 'peer_as' macro, where allowed, is replaced with the ASN
# of the client the route is announced to.
# The 'dyn_val' macro, where allowed, is replaced with a
# numeric value that is significant to the function the BGP
# community is responsible for.
#
# OpenBGPD: large communities are not supported on versions prior
# to OpenBSD 6.1, so they are not taken into account when
# building the configuration. If supported by the release of
# OpenBGPD running on the route server, enable them by setting
# the configuration target version to a value greater than or
# equal to "6.1" (--target-version command line argument).
# Moreover, ext communities that use the 'peer_as' macro or the
# 'dyn_val' macro can't be scrubbed from outbound routes
# (routes announced by the route server to the clients) because
# of lack of wildcard
# matching.
# Prefix/origin AS present in client's AS-SET.
#
# If 'tag_as_set' = True, prefixes that are (not) part of an
# AS-SET or whose origin ASN is (not) part of an AS-SET are
# tagged with the following BGP communities, provided that they
# are set below.
#
# The following communities are scrubbed from inbound routes.
#
# The 'rs_as' macro can be used here.
prefix_present_in_as_set:
#std:
#lrg:
#ext:
prefix_not_present_in_as_set:
#std:
#lrg:
#ext:
origin_present_in_as_set:
#std:
#lrg:
#ext:
origin_not_present_in_as_set:
#std:
#lrg:
#ext:
prefix_validated_via_rpki_roas:
#std:
#lrg:
#ext:
prefix_validated_via_arin_whois_db_dump:
#std:
#lrg:
#ext:
prefix_validated_via_registrobr_whois_db_dump:
#std:
#lrg:
#ext:
route_validated_via_white_list:
#std:
#lrg:
#ext:
# Blackhole filtering.
#
# If a policy is given in 'blackhole_filtering', it is applied to
# routes tagged with one of the following communities:
# - the BLACKHOLE well-known community 65535:666, that is always
# implemented if a 'blackhole_filtering' policy is given
# (https://tools.ietf.org/html/rfc7999#section-5)
# - one of the following 'blackholing' Standard, Large or
# Extended BGP communities.
#
# The following community is scrubbed from outbound routes.
#
# The 'rs_as' macro can be used here.
blackholing:
#std:
#lrg:
#ext:
# Control communities.
#
# Routes that are tagged with the following community are not
# announced to any client, unless they are also tagged with the
# 'announce_to_peer' communities: in this case, such routes are
# announced only to the clients whose ASN matches the value given
# in the 'announce_to_peer' communities.
#
# The following community is scrubbed from outbound routes.
#
# The 'rs_as' macro can be used here.
do_not_announce_to_any:
#std:
#lrg:
#ext:
# Routes that are tagged with the following community are not
# announced to clients whose ASN matches the value given in the
# community itself.
# If a route is tagged with the two conflicting communities
# 'do_not_announce_to_peer' and 'announce_to_peer', the route
# is not advertised to the peer.
#
# The following community is scrubbed from outbound routes.
#
# The 'rs_as' macro can be used here.
# The 'peer_as' macro must appear in the last part of values.
do_not_announce_to_peer:
#std:
#lrg:
#ext:
# Routes that are tagged with the following community are
# announced to clients whose ASN matches the value given in the
# community itself even if they are tagged with the
# 'do_not_announce_to_any' community.
# If a route is tagged with the two conflicting communities
# 'do_not_announce_to_peer' and 'announce_to_peer', the route
# is not advertised to the peer.
#
# The following community is scrubbed from outbound routes.
#
# The 'rs_as' macro can be used here.
# The 'peer_as' macro must appear in the last part of values.
announce_to_peer:
#std:
#lrg:
#ext:
# Routes that are tagged with the following community are not
# announced to clients that have a RTT lower/higher than the
# value of the threshold identified by the last part of the
# community.
#
# The following communities are scrubbed from outbound routes.
#
# The 'rs_as' macro can be used here.
# The 'dyn_val' macro must appear in the last part of values.
# The 'dyn_val' macro must contain a value from the
# 'rtt_thresholds' list that identifies the RTT value for
# which the action is requested.
do_not_announce_to_peers_with_rtt_lower_than:
#std:
#lrg:
#ext:
do_not_announce_to_peers_with_rtt_higher_than:
#std:
#lrg:
#ext:
# Routes that are tagged with the following community are
# announced to clients that have a RTT lower/higher than the
# value of the threshold identified by the last part of the
# community, even if they are tagged with the
# 'do_not_announce_to_any' community.
# If a route is also tagged with the 'do_not_announce_to_peer'
# community it is not advertised to the client even if it
# matches the RTT criterion.
#
# The following communities are scrubbed from outbound routes.
#
# The 'rs_as' macro can be used here.
# The 'dyn_val' macro must appear in the last part of values.
# The 'dyn_val' macro must contain a value from the
# 'rtt_thresholds' list that identifies the RTT value for
# which the action is requested.
announce_to_peers_with_rtt_lower_than:
#std:
#lrg:
#ext:
announce_to_peers_with_rtt_higher_than:
#std:
#lrg:
#ext:
# Prepending communities.
#
# The 3 "flavors" of prepending actions (to_peer, rtt
# based and to_any) are applied in the following order:
# - prepend_x_to_peer
# - prepend_x_to_peers_with_rtt_higher_than (RTTs in desc order)
# - prepend_x_to_peers_with_rtt_lower_than (RTTs in asc order)
# - prepend_x_to_any
# (x is always in the ascending order: once, twice, thrice).
#
# For example, if a route is tagged with both a
# 'prepend_x_to_any' and a 'prepend_x_to_peer' community, only
# the latter will be considered when announcing to the clients
# whose ASN match the one given in its value.
# Routes that are tagged with the following communities are
# propagated to all the clients with an AS_PATH prepended once,
# twice or thrice with the announcing client's ASN.
#
# The following communities are scrubbed from outbound routes.
#
# The 'rs_as' macro can be used here.
prepend_once_to_any:
#std:
#lrg:
#ext:
prepend_twice_to_any:
#std:
#lrg:
#ext:
prepend_thrice_to_any:
#std:
#lrg:
#ext:
# Routes that are tagged with the following communities are
# propagated to the clients whose ASN matches the one given in
# the community with an AS_PATH prepended once, twice or thrice
# with the announcing client's ASN.
#
# The following communities are scrubbed from outbound routes.
#
# The 'rs_as' macro can be used here.
# The 'peer_as' macro must appear in the last part of values.
prepend_once_to_peer:
#std:
#lrg:
#ext:
prepend_twice_to_peer:
#std:
#lrg:
#ext:
prepend_thrice_to_peer:
#std:
#lrg:
#ext:
# Routes that are tagged with the following communities are
# propagated to clients having a RTT lower/higher than the value
# of the threshold identified by the last part of the community
# with an AS_PATH prepended once, twice or thrice with the
# announcing client's ASN.
#
# The following communities are scrubbed from outbound routes.
# The 'peer_as' macro must appear in the last part of values.
#
# The 'rs_as' macro can be used here.
# The 'dyn_val' macro must appear in the last part of values.
# The 'dyn_val' macro must contain a value from the
# 'rtt_thresholds' list that identifies the RTT value for
# which the action is requested.
prepend_once_to_peers_with_rtt_lower_than:
#std:
#lrg:
#ext:
prepend_twice_to_peers_with_rtt_lower_than:
#std:
#lrg:
#ext:
prepend_thrice_to_peers_with_rtt_lower_than:
#std:
#lrg:
#ext:
prepend_once_to_peers_with_rtt_higher_than:
#std:
#lrg:
#ext:
prepend_twice_to_peers_with_rtt_higher_than:
#std:
#lrg:
#ext:
prepend_thrice_to_peers_with_rtt_higher_than:
#std:
#lrg:
#ext:
# Routes that are tagged with the following communities are
# propagated to other clients before the NO_EXPORT (65535:65281)
# and/or the NO_ADVERTISE (65535:65282) well-known communities
# are added.
# When 'rfc1997_wellknown_communities.enabled' is set to 'pass'
# this behaviour can be obtained by announcing routes to the
# route server after tagging them with RFC1997 NO_EXPORT or
# NO_ADVERTISE.
#
# The following communities are scrubbed from outbound routes.
#
# The 'rs_as' macro can be used here.
add_noexport_to_any:
#std:
#lrg:
#ext:
add_noadvertise_to_any:
#std:
#lrg:
#ext:
#
# The 'rs_as' macro can be used here.
# The 'peer_as' macro must appear in the last part of values.
add_noexport_to_peer:
#std:
#lrg:
#ext:
add_noadvertise_to_peer:
#std:
#lrg:
#ext:
# This BGP community is used when the 'reject_policy' option is
# set to 'tag'. It is used to track the code of the reason that
# led the route to be considered as invalid.
#
# The following community is scrubbed from inbound routes.
#
# The 'rs_as' macro can be used here.
# The 'dyn_val' macro must appear in the last part of values.
reject_cause:
#std:
#lrg:
#ext:
# This BGP community is used when the 'reject_policy' option is
# set to 'tag'. If configured, it is used to track the ASN
# of the peer that announced the invalid route to the route
# server.
#
# The following community is scrubbed from inbound routes.
#
# The 'rs_as' macro can be used here.
# The 'dyn_val' macro must appear in the last part of values.
rejected_route_announced_by:
#std:
#lrg:
#ext:
#custom_communities:
# Custom BGP communities can be added to routes that enter the
# route server from clients.
# Each client can be configured with a set of custom communities
# that are added to the routes it announces to the route
# server; these communities will be then propagated to other
# clients as the routes leave the server.
#
# The name of a custom BGP community can't be the same of any
# built-in community.
#
# The 'rs_as' macro can be used here.
#
#custom_community1_name:
# #std:
# #lrg:
# #ext:
#custom_community2_name:
# #std:
# #lrg:
# #ext: