AMS-IX Route Servers

AMS-IX offers networks connected to the Peering LAN the opportunity to peer via its route servers. Our route servers offer the peers the possibility of filtering based on IRRdb objects, as well as on predefined BGP communities. Therefore, peering with the route servers does not preclude peers of maintaining their peering policy.


Normally, you 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 the route server project is to facilitate the implementation of peering arrangements, and to lower the barrier of entry for new participants on the peering platform.

The route servers do not partake in the forwarding path, so they do not forward any traffic. Also, 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 setup to as many peers as possible on the AMS-IX network. With the large amount of connected parties on the AMS-IX platform, it can be a full-time task to manage all the BGP sessions. The goal of the route servers is to simplify this task. With just two BGP sessions, you can connect to all the networks on the route servers. When a new party connects to the route servers, you can automatically exchange prefixes (depending on your 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 connect 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
ASN: 62972
IPv6: 2001:504:38:1::A506:2972:1
Platform: BIRD
ASN: 62972
IPv6: 2001:504:38:1::A506:2972:2
Platform: BIRD
  • When peering with the route servers we mandate 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.


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 62972
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 62972
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:504:38:1::A506:2972:1 peer-group AMS-IX-RS-6
neighbor 2001:504:38:1::A506:2972:1 description
neighbor 2001:504:38:1::A506:2972:2 peer-group AMS-IX-RS-6
neighbor 2001:504:38:1::A506:2972: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:504:38:1::A506:2972:1 peer-group AMS-IX-RS-6
neighbor 2001:504:38:1::A506:2972: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 62972;
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;


Incoming Prefixes Sanitisation

The AMS-IX route servers only implement very basic incoming filters for prefixes received from members. We block RFC1918 ranges, bogon 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 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.

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.

The legacy filtering method is fully supported, but we encourage new and existing customers to use the new attributes when defining their policy. Please refer to the examples found below as to how to accomplish this.

We’re using AS1200 as the example aut-num object containing the example policies.

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

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

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

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

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

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

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

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

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

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


# Import from no-one
import-via: AS62972 from AS-ANY accept NOT ANY  

# Export to no-one
export-via: AS62972 to AS-ANY announce NOT ANY

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

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

BGP Community based filtering

We also offer customers the ability to filter outbound announcements by tagging them with the following predefined communities. 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.Currently supported locations for this feature are Hong Kong (AS58560) and Amsterdam (AS6777). 

  • 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 destination peers employing a 32-bit ASN, you can use the route target extended BGP community as follows:

  • 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  


- In cases where both IPv4 and IPv6 sessions exist with our route servers but only a IPv4 policy is described in your aut-num object, it is also applied for the IPv6 sessions.

- Multiple import/export and/or import-via/export-via statements for AS62972 are parsed sequentially. In case of duplicate policy specifications, the first attribute encountered is applied, per ambiguity resolution rules of RFC2622 §6.4. To avoid confusion and unnecessary complexity, we strongly suggest being as terse as possible.

- Should you announce anything more than your own AS, please use an appropriate AS-SET in the “announce” section of the export-via attribute. This helps with having an accurate route server object (see below) and with prefix validation checks for peers doing any.

- We currently support only the "ANY" keyword in the mp-filter section of the import-via attributes.

- Our route servers also support RFC5082 (GTSM). Should you wish to enable it for your peering sessions, please contact us.

- Although discouraged, you can use both filtering mechanisms simultaneously (IRRdb based and BGP community based).

AMS-IX route server objects

Relevant objects for participating peers in the Route Server project are grouped into these AS-SETs: AS-AMS-IX-CH-RS (list of connected peers), AS-AMS-IX-CH-RS-SETS (list of advertised AS-SETs), AS-AMS-IX-CH-RS-V6 (list of connected IPv6 peers) and AS-AMS-IX-CH-RS-SETS-V6 (list of advertised AS-SETs for IPv6 peers)

Max-Prefix Advisory

The route servers are announcing around 1078 IPv4 prefixes and 200 for IPv6. AMS-IX expects future prefix growth and therefore generally advises a max-prefix of 2000 for IPv4 and 1000 for IPv6. We recommend using the AMS-IX Looking Glass (members only) for more up-to-date information regarding 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.US.AMS-IX, and enable it in the configuration page of your respective connection (Connections -> Show -> Disable/Enable Peering with route-server). If you have any issues with that, please contact the AMS-IX NOC