Normally, you would need to maintain separate BGP sessions to each of your peers' routers. With a route server you can replace all or a subset of these sessions with one session towards each route server.

The goal of AMS-IX's Route Server Project is to facilitate the implementation of peering arrangements. We aim to lower the barrier of entry for new participants on the peering platform.

The route servers do not participate in the forwarding path, so they do not forward any traffic. And peering with a route server does not mean that you must accept routes from all other route server participants.

• Let's make it easy
  Simplify the needed configuration to reach as many networks as possible on the AMS-IX platform by configuring just two BGP sessions. With the large amount of connected parties, it can be a full-time task to manage separate BGP sessions. In addition, whenever a new party connects to the route servers, you will be able to automatically exchange prefixes with it (depending on yours/their filters).
• Manage only your most important peers, let the route server do the rest
  You probably want to exchange as much traffic as possible through the exchange, but setting up a peering takes time and effort. So only set up peering sessions with your most important peers - let the route server do the rest!
• Send and receive routes from day one
  Once you are connected to the route servers you will start exchanging routes immediately. The route servers are a good way to get started on the exchange.
  
• Use it as a backup
  When your BGP session to a party becomes inactive, there is a possibility that you can still connect to them via the route servers. So the use of the route servers can lead to a more stable platform.
• Maintain your peering policy
  The route server has built in filters that allow you to maintain your peering policies. For more information, please read the filtering topic.

• AMS-IX Route Servers support BGP roles (RFC9234) for Route leak detection and prevention by default. We have configured our role as “rs_server” (or RS) and BGP sessions with “rs_client” (or RS-Client) role are expected from the other side. However, this attribute is an optional one and BGP sessions that do not support RFC9234 are still being accepted.
• When peering with the route servers, it is mandatory that routers are set up to connect to both route servers and advertise the same amount and length of prefixes for resilience.
• Please note that the route servers are set to passive mode and will never initiate a BGP session. You should make sure that your equipment does so, i.e. connects to our TCP port 179 and that your inbound filtering/ACL rules permit established sessions with the route servers.

The route servers hold around 8K IPv4 prefixes and 1K IPv6 prefixes in the master table. These prefixes are the best routes that Bird’s BGP algorithm has selected among all received routes from all the established BGP feeds. But the number of prefixes that each member receives from the route servers varies and depends of the following factors:

• Your peering policy that is expressed in RPSL format in the IRR database.
• The peering policy of other AMS-IX members in which they can decide to announce prefixes via AMS-IX route servers to specific peers.

With the current peering policies and convergence of BGP algorithm, we observe that the average amount of prefixes being received by our members is around 7K for IPv4 and 650 for IPv6. However, we advise our members to configure a max-prefix of 10K for IPv4 and 1500 for IPv6 due to the following reasons:

• We calculate the limit based on the maximum number of valid prefixes that exist in the master table and can be potentially provided to a singe BGP feed.
• AMS-IX expects future prefix growth as a result of a dynamic platform where more and more networks get connected. Thus, we raise the limit by 25% in order accommodate this growth.

We recommend using the AMS-IX Looking Glass for more up-to-date information about announced prefixes.

Many unique ASNs participate in the route server project, representing tens of thousands of prefixes. For more information about who is participating, see the Connected Parties page.

If you would like to peer with the AMS-IX route servers, please login to our customer portal, and enable it in the configuration page of your respective connection (Connections -> Show -> Disable/Enable Peering with route-server).

Below is a similar example for Juniper routers:

All AMS-IX route servers in the Bangkok perform basic incoming prefix filtering to all member/customer BGP sessions that are being established (optionally) with our Route Servers. The basic prefix filtering consists of blocking RFC 1918 ranges, bogon and Martian prefixes and the default route. We base our list on Team CYMRU's BOGON List.

We do not monitor or control which prefixes participants announce to each other, just as we do not filter your bilateral sessions. If you wish to filter out more specifics or perform IRR-based prefix filtering, you are free to do so on your own router.

Please note that, specifically for the Amsterdam route servers, apart from bogon prefixes, we also filter by default "ROA status: INVALID" prefixes, as well as prefixes not announced in AS/AS-SETs part of aut-num export statements, as discussed below.

The AMS-IX route servers implement outgoing filtering based on policies defined by the route server participants. This filtering is applied on outgoing advertisements. By defining your policy using an IRRdb supporting RPSL, you instruct the route servers to send your prefixes to other participants (export policy), or from which participants you wish to receive prefixes (import policy). Therefore participating in the route server project does not necessarily mean that you would be obliged to send/receive prefixes for all connected participants; filtering schemes are available.

The filters are solely derived from your IRRdb objects, which use RPSL as a description language. There are three different options you can use: ANY, ANY except and RESTRICTIVE, to define your filtering needs.

In order to pick up the change in member's peering policy, AMS-IX route-servers periodically detect policy changes every hour starting at midnight Amsterdam time. If you wish to have your filters updated right away or encounter any problems, please contact the AMS-IX NOC. We can apply new configuration for the route-server to reflect your new policy.

As stated above, our route servers in Bangkok implement 3+1 peering modes of prefix filtering in the outbound direction.

• Peering mode 'Filtering based on both IRRDB and RPKI data':
  This is the default option when a new BGP session is established with the AMS-IX route servers. By selecting this peering mode, the route servers are configured automatically to apply IIRDB based filtering (explanation is provided below) and RPKI based filtering (explanation provided below). In case you already have a session with the NL route servers and this option is not the selected one, we recommend you to switch your peering mode to the default one.
• Peering mode 'Filtering based on IRRDB data':
  By selecting this option, Route Server outgoing prefixes extended filtering is based on IRRDB filtering only (explanation below). In summary, the prefixes that are being blocked are the ones that are not present in AS’s announced AS/AS-SET. We strongly recommend to make sure that your IRRDB objects are correctly updated and described in the RIPE database when having this option enabled (and the default one)
• Peering mode 'Filtering based on RPKI data':
  By selecting this option, Route Server outgoing prefixes extended filtering is based on RPKI filtering. In summary, the prefixes that are being blocked are the ones with ROA status 'INVALID'. We strongly recommend to make sure that your IRRDB ROAs are correctly updated in the RIPE database when having this option enabled (and the default one).

Optionally, we can offer the following peering mode in case you really need an unfiltered BGP feed (e.g. for research purposes":

• Peering mode 'Just tagging':
  By selecting this not recommended option, no filtering is applied to announced prefixes. That functionality is helpful for research institutes who want to receive all information or organisations who want to apply their own BGP policies. However, any prefixes that are not filtered will be tagged by using standard BGP communities based on the following criteria (communities are given in the parentheses).
  • Prefix with ROA status: VALID (150388:65012)
  • Prefix with ROA status: INVALID (150388:65022)
  • Prefix with ROA status: UNKNOWN (150388:65023)
  • Prefix present in AS’s announced AS/AS-SET (150388:65011)
  • Prefix not present in AS’s announced AS/AS-SET (150388:65021)

Our route servers generate their configuration based on a IRRDB parser script. The script supports most of the IETF snijders-rpsl-via draft extensions to the RPSL and the 'import-via' and 'export-via' attributes defined therein. Using these attributes, we allow for ASN32 aut-num objects in expressions and promote more elegant policy definitions regarding route servers.

Our configuration pipeline uses the following official IRR Databases in order to retrieve the RPSL objects and create route server prefix lists:

• RIPE, ARIN, APNIC, AFRINIC, LACNIC, JPIRR, IDNIC

Complementary to the above list, we use the following unofficial IRR databases but with less priority:

• NTT, LEVEL3, RADB

We encourage our members/customers to create their RPSL objects (AUT-NUM, AS-SET, ROUTE/ROUTE6) in one of the above IRR databases and always prefer official DBs instead of unofficial ones. As a side note, we would examine member/customer requests to expand the list of official DBs we support, in case of routing issues or public demand.

You can use the following examples to update your peering policy to support the 'import-via' and 'export-via' attributes and make sure that you are fully compatible with AMS-IX route servers (we’re using AS1200 as the example aut-num object).

1. ANY
(Send and receive prefixes to/from any RS participant):

2. ANY EXCEPT
(Send and receive prefixes to/from any RS participant EXCEPT AS666):

3. RESTRICTIVE
(Send and receive prefixes ONLY to/from AS15703):

AS-SETs also work in all cases:

4. ANY EXCEPT using AS-SETs
(Send and receive prefixes to/from any RS participant EXCEPT ASes/AS-SETs included in AS1200:CUSTOMERS):

5. RESTRICTIVE using AS-SETs
(Send and receive prefixes ONLY to/from AS's/AS-SETs contained in AS-SET AS1200:CUSTOMERS):

6. RESTRICTIVE with NOT ANY

# Import from no-one

# Export to no-one

7. afi lists are also supported
(initially described in RFC4012), e.g.:

Relevant objects for participating peers in the Route Server project are grouped into these AS-SETs

• AS-AMS-IX-RS (list of connected peers)
• AS-AMS-IX-RS-SETS (List of advertised AS-SETs)
  
• AS-AMS-IX-RS-V6 (List of connected IPv6 peers)
• AS-AMS-IX-RS-SETS-V6 (List of advertised AS-SETs for IPv6 peers)
• RS-AMS-IX-ISP-LANS (List of all AMS-IX peering LAN ranges)
  
• AS-AMS-IX-SET (List of all route server ASNs)

Provide a BGP community filtering mechanism to peers.

Route server peers are able to manipulate outbound routing policies via an in-band mechanism using BGP communities, instead of relying on “import/import-via”, “export/export-via” RPSL attributes. The downside to this method is that peers won’t be able to control inbound policies.

Currently, the mechanism is implemented to support Standard and Large BGP communities.

Please note that AMS-IX Route Servers do not provide support for BGP Extended communities, as per draft-spaghetti-grow-bcp-ext-comms. We do allow though our members to tag prefixes with Extended communities that target functionalities towards other members.

When you want to signal the Route-Server to filter prefixes for destination networks that have 16bit ASN, you can use either the traditional communities or the Large communities. In case the destination network is a 32bit ASN, then you can use Large communities only.

For traditional/Standard BGP communities, the offered options are:

• Do not announce a prefix to a certain peer: 0 <peer-as>
• Announce a prefix to a certain peer: 150388: <peer-as>
• Do not announce a prefix to any peer: 0:150388
• Announce a prefix to all peers: 150388:150388

For Large communities, the offered options are as below:

• Do not announce a certain prefix to peer-as: 150388:0: <peer-as>
• Announce a certain prefix to a certain peer: 150388:1: <peer-as>
• Do not announce a certain prefix to any peer: 150388:0:0 <peer-as>

Note that if you want to advertise a specific prefix to a specific customer only, then you need to combine “150388: <peer-as> ” and “0:150388” BGP communities.

As with the community-based filtering, AMS-IX peers have the ability to influence the prefix selection process of other members based on AS-Path pretending. The mechanism can be enabled either with the traditional 16bit BGP communities, or with the 32bit Large communities.

For the traditional 16bit communities, the prefix tagging must be as below:

• using 150388:65501, to prepend customer’s ASN once towards all other peers
• using 150388:65502, to prepend customer’s ASN twice towards all other peers
• using 150388:65503, to prepend customer’s ASN thrice towards all other peers

The same result can be achieved by tagging prefixes with Large Communities as below:

• using 150388:101:<peer-as> , to prepend customer’s ASN once towards all other peers
• using 150388:102:<peer-as> , to prepend customer’s ASN twice towards all other peers
• using 150388:103:<peer-as> , to prepend customer’s ASN thrice towards all other peers

Please note that in case you use your own ASN in the “” position then we prepend your prefix to all other AMS-IX members. However, if you use in the position of the ASN of another AMS-IX member, the route servers will prepend the prefix once, twice, or thrice towards that particular AMS-IX member only.

Route leaks are a problem. Either due to fat fingers, software bugs, or even malicious intent, route leaks are a fact of BGP life. A simple way to deal with the issue is using prefix limits.

Setting a static (fixed) limit to prevent customers from advertising more prefixes than intended does not really work for a route server service as the customer advertising the most prefixes has to be taken as the standard from which the limit is derived.

That leaves all the other customers with a wide margin in which they can freely leak routes; e.g. if the limit was set to 15,000, a customer advertising only one prefix could leak 14,999 more before being hitting the limit.

Adding insult to injury, this also has a cascading effect. Other route server peers having set a prefix limit for the session with the route servers, would potentially shut down the session, as they are now seeing thousands of additional prefixes.

Since late October 2013, AMS-IX is applying prefix limits specific to the AS connecting to the route server service. For instance, peers advertising only a couple of prefixes will have a maximum prefix limit of 100. Peers advertising thousands of prefixes will be calculated based on an proportional coefficient.

For examples and a breakdown of the formula used, see the FAQ below.

Fluctuations in advertisements are normal and expected. As long as these are within reason, our limits will adapt accordingly (hence 'dynamic').