Falcon class Route Servers

As of September 2015, AMS-IX is offering another pair of route servers to customers.
As of October 2017, AMS-IX has also backported all features discussed below in the Legacy route servers.
Any comments or feedback is invaluable to us so we can improve, so please fire away!

The main goal behind the service is threefold:

1. Provide more information about prefixes announced to peers

Any prefixes not filtered (explained in 2.), will be tagged using standard BGP
communities given in the parentheses.  Prefixes announced by the new route servers
will be tagged according to the criteria shown below:

a. Prefix has ROA status: VALID (6777:65012)
b. Prefix has ROA status: INVALID (6777:65022)
c. Prefix has ROA status: UNKNOWN (6777:65023)
d. Prefix is present in an AS's announced AS/AS-SET (6777:65011)
e. Prefix is not present in an AS's announced AS/AS-SET (6777:65021)

2. Offer more control with regards to prefixes announced to peers

Customers will be able to choose between four options in the AMS-IX customer portal 
applicable to announcements received via the Falcon class Route Servers:

a. No filtering applied to announced prefixes
b. Filter prefixes not present in an AS's announced AS/AS-SET
c. Filter prefixes with ROA status: INVALID
d. Filter prefixes with ROA status: INVALID as well as prefixes not
present in an AS's announced AS/AS-SET, i.e. do both b. and c. (this is
the default option)

NOTE: ROAs are validated against RPKI validators. For more information, please refer to Q8 below.

3. Provide a BGP community filtering mechanism to peers

Route server peers will be 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 we offer the following options:

  • 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


  • AS-Path prepending can be done via the Falcon class Route Servers by tagging prefixes:

a. using 6777:65501, to prepend the advertising peer customer AS once towards all other peers
b. using 6777:65502, to prepend the advertising peer customer AS twice towards all other peers
c. using 6777:65503, to prepend the advertising peer customer AS thrice towards all other peers

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


A summary of all the distinct features can be found in the table below:

Feature support Legacy Route Servers Falcon Route Servers
BGP Community based routing policies Yes (As of 20160426) Yes
IRRdb based routing policies Yes Yes (As of 20160113)
Outbound Routing Policies Yes Yes
Inbound Routing Policies Yes No
RPKI prefix validation Yes (As of 20171020) Yes
RPKI prefix filtering (optional) Yes (As of 20171020) Yes
IRRdb prefix validation Yes (As of 20171020) Yes
IRRdb prefix filtering (optional) Yes (As of 20171020) Yes
RFC5082 support Yes Yes
MD5 Authentication Yes Yes
my.ams-ix.net peering activation Yes Yes
Dynamic per-AS prefix limits Yes Yes
AS Path prepending Yes (As of 20171020) Yes


Option 1: In the AMS-IX Customer Portal, you will find a new
button just under "peering with Legacy route-servers”
named “peering with Falcon class route-servers” for
both IPv4 and IPv6. Pressing it will display the available options.
As soon as you have finished with the selection, peering
should be enabled within 60 minutes.

Option 2: Contact AMS-IX NOC and
request for peering to be activated.

Should you choose option 2, please specify which filtering
option would you prefer, 2a, 2b, 2c or 2d.


Hostname IPv4 Address IPv6 address AS number
rs3.ams-ix.net 2001:7f8:1::a500:6777:3 6777
rs4.ams-ix.net 2001:7f8:1::a500:6777:4 6777


Q1: Is a Looking Glass service being offered for the "Falcon" class Route Servers?
A1: Yes, you can use the Customer Portal to reach it, under Options > Looking Glass.

Q2: Are the "Falcon" class Route Servers available in all AMS-IX exchanges?
A2: The service is currently only available for the Amsterdam platform.
Depending on customer interest, it is possible to offer it in our other exchanges as well.

Q3: What methods can I use to describe our AS routing policy?
A3: As of January 13th, 2016, "Falcon" class Route Servers offer both IRRdb based routing policy description, as well as a standard BGP community mechanism to influence outbound routing policies:

Please see here for more details about using BGP communities

Please see here for more details about using IRRdb based routing policies


  • 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 also influence inbound (route server to customer edge router) announcements, before reaching the customer edge router, thus potentially affecting the BGP decision process.
  • Customers can use peering-set class semantics to use distinct routing policies if they peer with both Legacy and Falcon Class route servers. For instance: 
    remarks: AMS-IX Legacy route servers
    import-via: AS6777 at from AS-ANY EXCEPT AS1200:PEERS accept ANY
    import-via: AS6777 at from AS-ANY EXCEPT AS1200:PEERS accept ANY
    remarks: AMS-IX Falcon class route servers import-via: AS6777 at from AS-ANY EXCEPT AS1200:CUSTOMERS accept ANY
    import-via: AS6777 at from AS-ANY EXCEPT AS1200:CUSTOMERS accept ANY
    A similar approach  can be used for export-via and IPv6 statements (using IPv6 addresses).
  • Customers not using peering-set class semantics will have the same policy applied in both Legacy and Falcon class route servers.

Q4: Should I peer with the Legacy route servers or the "Falcon" class ones?
A4: As of 20171020, we strongly encourage you to only peer with the Legacy route servers, as they offer identical functionality
to the Falcon class ones. The Falcon class route servers will be either decommissioned, or converted to run the configuration
run on the Legacy route servers before 20171020, depending on customer demand.

The only requirement is to ensure you're peering with both members of a set (if you're peering with
rs1 you have to have a session with rs2, and if you're peering with rs3 you have to have a session
with rs4), as true redundancy is achieved only if both members of a set carry the exact same prefixes.

Q5: We are using "announce ANY" instead of "announce AS/AS-SET" for our export attributes.
How is AMS-IX determining whether our announcements can be resolved
as route objects with our AS as an origin (that is, validate via an IRRdb)?

A5: We consider the "ANY" keyword equivalent to "advertising AS", as there is no other
way to provide meaningful information about such announcements. Should that not reflect
your AS's routing policy, please update your export attribute with an appropriate AS-SET.

Q6: Why not just "backport" the RPKI/IRRdb validation features to your Legacy Route Servers
instead of providing another set?

A6: After customer demand, we did backport all features on 20171020.

Q7: Are 32-bit ASNs supported when specifying BGP communities for routing policies?
A7: Yes. You can use the "route target" BGP extended communities to specify the communities
you wish.

Q8: How are you validating prefixes via RPKI? 
A8: We are running a standard RIPE NCC RPKI validator , using the following Trust anchors:

  • APNIC (from AFRINIC RPKI Root)
  • APNIC (from ARIN RPKI Root)
  • APNIC (from IANA RPKI Root)
  • APNIC (from LACNIC RPKI Root)
  • AfriNIC (RPKI Root)
  • LACNIC (RPKI Root)
  • RIPE NCC (RPKI Root)
  • ARIN (from ARIN RPKI Root)

Q9: Why did you name the route servers "Falcon"?
A9: Falcon is a BIRD species :)

Q10: We are peering with both route server sets. Can I specify a separate routing policy for each?
A10: Yes, although see Q4.

Q11: Are you open to feature requests?
A11: Always. Should you have any ideas, please let us know!