Hong Kong

Hong Kong

  • Exchange
  • Services
  • Technical
  • About
23.47 Gb/s
70.92 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 63K IPv4 prefixes and 25K 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 60K for IPv4 and 25K for IPv6. However, we advise our members to configure a max-prefix of 90K for IPv4 and 40K 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 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 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 Hong Kong 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 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.

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


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

2. ANY except

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

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


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

import-via: AS58560 from AS15703 accept ANY 
export-via: AS58560 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: AS58560 from AS-ANY EXCEPT AS1200:AS-CUSTOMERS accept ANY
export-via: AS58560 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: AS58560 from AS1200:AS-PEERS accept ANY
export-via: AS58560 to AS1200:AS-PEERS announce AS1200:AS-CUSTOMERS 


# Import from no-one

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

# Export to no-one

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

7. afi lists are also supported

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

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

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.

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

The offered options are:

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

We also offer customers the ability to filter outbound announcements by tagging them with the following predefined communities. 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:58560:peer-as
  • Do not announce a prefix to any peer: RT:0:58560

AS-Path prepending can be done via the Route Servers by tagging prefixes using the following communities:

  • Using 58560:65501, to prepend the advertising peer customer AS once towards all other peers
  • Using 58560:65502, to prepend the advertising peer customer AS twice towards all other peers
  • Using 58560:65503, to prepend the advertising peer customer AS thrice towards all other peers

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 - 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,35 = 2025. 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?