Ohio Ix


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.

Prefix propagation and Max-Prefix Advisory

The route servers hold around 255K IPv4 prefixes and 55K 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 filtering mode that you selected and sanitizes the prefixes being announced to you (by default we apply the “default” mode to your BGP feed).
  • 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 with “default” filtering option is around 100K for IPv4 and 19K for IPv6. However, we advise our members to configure a max-prefix of 320K for IPv4 and 80K 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).

Need support to enable peering with route server?


Manrs Rgb Vertical Logo Dark

AMS-IX 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 6777
 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 6777
 neighbor AMS-IX-RS-6 version 4
 neighbor AMS-IX-RS-6  transport connection-mode active
 neighbor peer-group AMS-IX-RS
 neighbor description rs1.ams-ix.net
 neighbor peer-group AMS-IX-RS
 neighbor description rs2.ams-ix.net
 neighbor 2001:7f8:1::a500:6777:1 peer-group AMS-IX-RS-6
 neighbor 2001:7f8:1::a500:6777:1 description rs1.ams-ix.net
 neighbor 2001:7f8:1::a500:6777:2 peer-group AMS-IX-RS-6
 neighbor 2001:7f8:1::a500:6777:2 description rs2.ams-ix.net
 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:6777:1 peer-group AMS-IX-RS-6
 neighbor 2001:7f8:1::a500:6777: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 6777;
    neighbor {
        description rs1.ams-ix.net;
    neighbor {
        description rs2.ams-ix.net;


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 Amsterdam perform basic and extended 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.

Outgoing prefixes filtering among route-server members

The extended prefix filtering offers 3+1 peering modes and the customer is able to select the desired one through the my.ams-ix.net portal.

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 object described by 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, connecting with the route servers 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 a new configuration for the route-server to reflect your new policy.

Please check the list of these supported IRRDBs.

Would you like to have your filters updated right away or do you encounter any problems?


The 3+1 peering modes of route servers

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

IRRDB based Filtering

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.

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: AS6777 from AS-ANY accept ANY
export-via: AS6777 to AS-ANY announce AS1200

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

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

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

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

AS-SETs also work in all cases:

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

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

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

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


# Import from no-one

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

# Export to no-one

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

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

import-via: afi ipv4.unicast AS6777 from AS-ANY EXCEPT AS1200:AS-CUSTOMERS accept ANY
export-via: afi ipv4.unicast AS6777 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-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)

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 ASNYESYESYES
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 6777 representing Amsterdam. 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: 6777: <peer-as>
  • Do not announce a prefix to any peer: 0:6777
  • Announce a prefix to all peers: 6777:6777

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:6777: <peer-as>
  • Do not announce a prefix to any peer: RT:0:6777

For Large communities, the offered options are as below:

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

Note that if you want to advertise a specific prefix to a specific customer only, then you need to combine “6777: <peer-as>” and “0:6777” BGP 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 6777:65501, to prepend customer’s ASN once towards all other peers
  • using 6777:65502, to prepend customer’s ASN twice towards all other peers
  • using 6777: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 6777:101:<peer-as>, to prepend customer’s ASN once towards all other peers
  • using 6777:102:<peer-as>, to prepend customer’s ASN twice towards all other peers
  • using 6777: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 behavior 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: What is the prefix limit set for my AS?

Assuming you have member credentials, you can see your prefix limits here.

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 < 502100
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