• Platform
  • Services
  • Technical
  • About
10.33 Gb/s
67.46 Gb/s

AMS-IX Route Servers

AMS-IX Route Servers

AMS-IX offers networks connected to the Peering LAN the opportunity to peer via its route servers. On our route servers, peers can filter based on IRRDB objects, as well as on predefined BGP communities. Therefore, members/customers can peer with the route servers while maintaining their own peering policy.


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.

Why would you use the route servers?

  • 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.

Route server details

Route Server 1Route Server 2
  • 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.

Max-Prefix Advisory

The route servers hold around 111K IPv4 prefixes and 52K 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 111K for IPv4 and 52K for IPv6. However, we advise our members to configure a max-prefix of 139K for IPv4 and 63K 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 (members only) for more up-to-date information about announced prefixes.

Want to participate?

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 My.AMS-IX, and enable it in the configuration page of your respective connection (Connections -> Show -> Disable/Enable Peering with route-server).

Manrs Rgb Vertical Logo Dark

AMS-IX Amsterdam Route Servers are MANRS (Mutually Agreed Norms for Routing Security) compliant.

> Read more

Deployment guidelines

Below follows a sample configuration for Cisco routers to announce a prefix to the route servers:

router bgp your-asn
 bgp always-compare-med
 no bgp enforce-first-as
 bgp log-neighbor-changes
 neighbor AMS-IX-RS peer-group
 neighbor AMS-IX-RS remote-as 133160
 neighbor AMS-IX-RS version 4
 neighbor AMS-IX-RS  transport connection-mode active
 neighbor AMS-IX-RS-6 peer-group
 neighbor AMS-IX-RS-6 remote-as 133160
 neighbor AMS-IX-RS-6 version 4
 neighbor AMS-IX-RS-6  transport connection-mode active
 neighbor peer-group AMS-IX-RS
 neighbor description
 neighbor peer-group AMS-IX-RS
 neighbor description
 neighbor 2001:7f8:1::a500:133160:1 peer-group AMS-IX-RS-6
 neighbor 2001:7f8:1::a500:133160:1 description
 neighbor 2001:7f8:1::a500:133160:2 peer-group AMS-IX-RS-6
 neighbor 2001:7f8:1::a500:133160:2 description
 address-family ipv4
 no neighbor AMS-IX-RS-6 activate
 neighbor AMS-IX-RS activate
 neighbor AMS-IX-RS next-hop-self
 neighbor AMS-IX-RS soft-reconfiguration inbound
 neighbor AMS-IX-RS route-map TO-RS out
 no auto-summary
 no synchronization
 neighbor peer-group AMS-IX-RS
 neighbor peer-group AMS-IX-RS
 network mask
 network mask
 network mask
 address-family ipv6
 neighbor AMS-IX-RS-6 activate
 neighbor AMS-IX-RS-6 next-hop-self
 neighbor AMS-IX-RS-6 soft-reconfiguration inbound
 neighbor AMS-IX-RS-6 route-map TO-RS out
 neighbor 2001:7f8:1::a500:133160:1 peer-group AMS-IX-RS-6
 neighbor 2001:7f8:1::a500:133160:2 peer-group AMS-IX-RS-6
 network 2001:DB8:10::/64
 network 2001:DB8:11::/64
 network 2001:DB8:12::/64
ip as-path access-list 12 permit ^$
ip prefix-list TO-RS seq 10 permit
ip prefix-list TO-RS seq 20 permit
ip prefix-list TO-RS seq 30 permit
ipv6 prefix-list TO-RS seq 10 permit 2001:DB8:10::/64
ipv6 prefix-list TO-RS seq 20 permit 2001:DB8:11::/64
ipv6 prefix-list TO-RS seq 30 permit 2001:DB8:12::/64
route-map TO-RS permit 10
 match ip address prefix-list TO-RS

Note that for recent IOS versions (e.g. 12.0(26)S and 12.2(25)S and up, where this has become the - hidden - default) you will have to specify "no bgp enforce-first-as (IOS, IOS-XE) / bgp enforce-first-as disable (IOS-XR)" as the route server does not insert its own ASN into the AS_path of relayed prefix announcements. Zebra and Quagga suffer from the same problem since somewhere in 0.91.

Below is a similar example for Juniper routers:

user@junix# show protocols bgp
group IPV4-RS {
    type external;
    description "Route Servers";
    family inet {
    export TO-RS;
    peer-as 133160;
    neighbor {
    neighbor {
user@junix# show policy-options policy-statement TO-RS
term unicast-export {
    from {
        rib inet.0;
        prefix-list to-announce;
    then accept;
term end {
    then reject;
user@junix# show policy-options prefix-list to-announce;

Route Server Filtering

AMS-IX route server filtering.

Incoming prefixes sanitisation

All AMS-IX route servers in Singapore 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.

Outgoing prefixes filtering among route-server members

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 lands/amsterdam">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.

Please check the list of these supported IRRdbs.

The 3+1 peering modes of route servers

As stated above, from July 2019 and onwards, our route servers in Singapore 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 (133160:65012)
    • Prefix with ROA status: INVALID (133160:65022)
    • Prefix with ROA status: UNKNOWN (133160:65023)
    • Prefix present in AS’s announced AS/AS-SET (133160:65011)
    • Prefix not present in AS’s announced AS/AS-SET (133160:65021)

IRRDB based Filtering

Our route servers generate their configuration based on a IRRDB parser script. The script supports most of the lank" rel="noreferrer noopener">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:


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


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):

import-via: AS133160 from AS-ANY accept ANY 
export-via: AS133160 to AS-ANY announce AS1200 

2. ANY except

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

import-via: AS133160 from AS-ANY EXCEPT AS666 accept ANY
export-via: AS133160 to AS-ANY EXCEPT AS666 announce AS1200 


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

import-via: AS133160 from AS15703 accept ANY 
export-via: AS133160 to AS15703 announce AS1200 

AS-SETs also work in all cases:

using AS-SETs

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

import-via: AS133160 from AS-ANY EXCEPT AS1200:AS-CUSTOMERS accept ANY
export-via: AS133160 to AS-ANY EXCEPT AS1200:CUSTOMERS announce AS1200:CUSTOMERS 


(Send and receive prefixes ONLY to/from ASes/AS-SETs contained in AS-SET AS1200:CUSTOMERS):

import-via: AS133160 from AS1200:AS-PEERS accept ANY
export-via: AS133160 to AS1200:AS-PEERS announce AS1200:AS-CUSTOMERS 


# Import from no-one

import-via: AS133160 from AS-ANY accept NOT ANY

# Export to no-one

export-via: AS133160 to AS-ANY announce NOT ANY

7. afi lists are also supported

(initially described in RFC4012), e.g.:

import-via: afi ipv4.unicast AS133160 from AS-ANY EXCEPT AS1200:AS-CUSTOMERS accept ANY
export-via: afi ipv4.unicast AS133160 to AS-ANY EXCEPT AS1200:AS-CUSTOMERS announce ANY

AMS-IX route server objects

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

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

BGP Traffic Engineering

In this section, you will find information about BGP Community filtering and AS-PATH prepending.

BGP Community filtering

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 the traditional BGP communities, the Extended BGP communities and the Large BGP communities.

Please note that AMS-IX is planning to drop the support for the Extended communities as their functionality is fully covered from the Large communities.

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 Extended communities. In case the destination network is a 32bit ASN, then you can use either the Extended communities or the Large communities.

To make the above easily understandable, we provide the table below that summarises the available options:

Source ASN and destination ASNLegacy communitiesExtended communitiesLarge communities
16bit ASN to 16bit ASN


16bit ASN to 32bit ASNNOYESYES
32bit ASN to 16bit ASNYESYESYES
32bit ASN to 32bit ASNNONOYES

Note that you have to use the appropriate route server AS number, based on the AMS-IX location you're peering in, with 133160 representing Singapore. All locations support this feature.

For traditional 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: 133160: <peer-as>
  • Do not announce a prefix to any peer: 0:133160
  • Announce a prefix to all peers: 133160:133160

For BGP Extended communities, you can use the offered options below:

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

For Large communities, the offered options are as below:

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

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

AS-PATH prepending

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 133160:65501, to prepend customer’s ASN once towards all other peers
  • using 133160:65502, to prepend customer’s ASN twice towards all other peers
  • using 133160: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 133160:101:<peer-as>, to prepend customer’s ASN once towards all other peers
  • using 133160:102:<peer-as>, to prepend customer’s ASN twice towards all other peers
  • using 133160: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 “<peer-as>” 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.

Additional Notes

  • IRRDB policies work only on the AS level, whereas BGP communities work on the prefix level.
  • IRRDB policies are parsed and applied hourly, whereas BGP communities are effective immediately, being in-band.
  • BGP communities can only influence outbound (customer edge router to route server) announcements, whereas IRRDB policies can be used to influence inbound (route server to customer edge router) announcements, before reaching the customer edge router, thus potentially affecting the BGP decision process.
  • Path hiding should not be a problem, as we are employing the BIRD 'secondary' configuration option.
  • Note that validity of the IRRDB/RPKI based information provided is not guaranteed in any way.
    Please consider carefully whether your AMS-IX facing router should solely rely on information exchanged to and from the route servers.

Dynamic per-AS Prefix Limits

Dynamic per-AS Prefix Limits

Problem: route leaks

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.

Enter dynamic per-AS 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').


Q: I'm concerned that the limits for my AS are not big enough!

We hate to tear down sessions for no good reason, so rest assured that the limits are sufficiently relaxed. A 2 month lead period in which we were observing peer behaviour and fine-tuned the algorithm ensured this as much as possible.

That being said, we value the stability of the service above everything else, so peers suddenly advertising thousands of prefixes when historically they have been advertising only a handful *will* hit the limit. In such cases, please contact us and we will be happy to reactivate the sessions.

Q: I'm still concerned about the sanity of the limits, though.

We can also set a static limit for you, please contact us and state the limit you wish.

Q: Why not use IRRDB objects/RPKI to contain announcements?

AMS-IX specifically wants to ensure that the route server service is as stable as possible. Having peers announce unexpectedly large amounts of prefixes wreaks havoc as it tears down sessions for considerable amounts of peers causing CPU churn to all parties involved. This is a different matter compared to the *type* of prefixes advertised.

IRRDB data is prone to inconsistencies and even more importantly, their usage is mostly limited to the western world. AS's from other regions of the world generally disregard IRRs.

Q: Can you give me examples of how this works?

Please consult the tables below:

Announced Prefixes yCoefficient xPrefix Limit (yx < z)
y < 50
50 < y < 2492500
250 < y < 49921000
500 < y < 99922000
1000 < y < 20002 - 1,5next step of 1000
2000 < y < 100001,5 - 1,2next step of 1000
y > 100001,2next step of 1000
25 Announced Prefixes x 2 = 50. Limit set to 100
51 Announced Prefixes x 2 = 102. Limit set to 500
300 Announced Prefixes x 2 = 600. Limit set to 1000
900 Announced Prefixes x 2 = 1800. Limit set to 2000
1500 Announced Prefixes x 1,75 = 2625. Limit set to 3000
9000 Announced Prefixes x 1,22 = 10980. Limit set to 11000
15000 Announced Prefixes x 1,2 = 18000. Limit set to 19000

Subscribe to our newsletter

Got a question?