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 (this is
the default if no other option has been selected)
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 (that is, do both b. and c.)
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:
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
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|
|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|
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
remarks: AMS-IX Legacy route servers import-via: AS6777 188.8.131.52 at 184.108.40.206 from AS-ANY EXCEPT AS1200:PEERS accept ANYA similar approach can be used for export-via and IPv6 statements (using IPv6 addresses).
import-via: AS6777 220.127.116.11 at 18.104.22.168 from AS-ANY EXCEPT AS1200:PEERS accept ANY
remarks: AMS-IX Falcon class route servers import-via: AS6777 22.214.171.124 at 126.96.36.199 from AS-ANY EXCEPT AS1200:CUSTOMERS accept ANY
import-via: AS6777 188.8.131.52 at 184.108.40.206 from AS-ANY EXCEPT AS1200:CUSTOMERS accept ANY
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.
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.
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
Q8: How are you validating prefixes via RPKI?
A8: We are running a standard RIPE NCC RPKI validator , using the following Trust anchors:
Q9: Why did you name the route servers "Falcon"?
A9: Falcon is a BIRD species :)
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!