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.
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.
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 , 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: AS24193 from AS-ANY accept ANY
export-via: AS24193 to AS-ANY announce AS1200
2. ANY except (Send and receive prefixes to/from any RS participant EXCEPT AS666):
import-via: AS24193 from AS-ANY EXCEPT AS666 accept ANY
export-via: AS24193 to AS-ANY EXCEPT AS666 announce AS1200
3. RESTRICTIVE (Send and receive prefixes ONLY to/from AS15703):
import-via: AS24193 from AS15703 accept ANY
export-via: AS24193 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: AS24193 from AS-ANY EXCEPT AS1200:AS-CUSTOMERS accept ANY
export-via: AS24193 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: AS24193 from AS1200:AS-PEERS accept ANY
export-via: AS24193 to AS1200:AS-PEERS announce AS1200:AS-CUSTOMERS
6. RESTRICTIVE with NOT ANY
# Import from no-one
import-via: AS24193 from AS-ANY accept NOT ANY
# Export to no-one
export-via: AS24193 to AS-ANY announce NOT ANY
7. afi lists are also supported (initially described in RFC4012), e.g.:
import-via: afi ipv4.unicast AS24193 from AS-ANY EXCEPT AS1200:AS-CUSTOMERS accept ANY
export-via: afi ipv4.unicast AS24193 to AS-ANY EXCEPT AS1200:AS-CUSTOMERS announce ANY