All Amsterdam Route servers perform basic and extended prefix filtering to all the 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.
The extended prefix filtering is divided in 4 peering modes and the customer is able to select the desired one through the my.ams-ix.net portal. We explain the functionality of these modes in the next section.
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 object described by 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, connecting with the route servers 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.
As stated above, as from October 2017 all the route servers in Netherlands implement 4 peering modes of prefix filtering in the inbound directions.
Peering mode "Filtering based on both IRRdb and RPKI data":
This is the default option when a new BGP session is established with the AMS-IX route servers. By selecting this peering mode, the route servers are configured automatically to apply IIRdb based filtering (explanation is provided below) and RPKI based filtering (explanation provided below). In case you have already a session with the NL route servers and this option is not the selected one, we recommend you switch your peering mode to the default one.
Peering mode “Filtering based on IRRdb data”:
By selecting this option, extended filtering on members/customer’s incoming prefixes is based on IRRdb filtering (explanation below). In summary, the prefixes that are being blocked are the ones that are not present in AS’s announced AS/AS-SET. We strongly recommend you when having this option enabled (and the default one) to make sure that your IRRdb objects are correctly updated and described in the RIPE database.
Peering mode “Filtering based on RPKI data”:
By selecting this option, extended filtering on members/customer’s incoming prefixes is based on RPKI filtering. In summary, the prefixes that are being blocked are the ones with ROA status “INVALID”. We strongly recommend you when having this option enabled (and the default one) to make sure that your IRRdb ROAs are correctly updated in the RIPE database.
Peering mode “Just tagging”:
By selecting this not recommended option, no filtering is applied to announced prefixes. That functionality is helpful for research institutes who want to receive all information or organizations who want to apply their own BGP policies. However, any prefixes that are not filtered will be tagged by using standard BGP communities based on the following criteria (communities are given in the parentheses):
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. You can use the following examples to update your peering policy to support the "import-via" and "export-via" attributes and make sure that you are fully compatible with AMS-IX route servers (we’re using AS1200 as the example aut-num object).
1. ANY (Send and receive prefixes to/from any RS participant):
import-via: AS6777 from AS-ANY accept ANY
export-via: AS6777 to AS-ANY announce AS1200
2. ANY except (Send and receive prefixes to/from any RS participant EXCEPT AS666):
import-via: AS6777 from AS-ANY EXCEPT AS666 accept ANY
export-via: AS6777 to AS-ANY EXCEPT AS666 announce AS1200
3. RESTRICTIVE (Send and receive prefixes ONLY to/from AS15703):
import-via: AS6777 from AS15703 accept ANY
export-via: AS6777 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: AS6777 from AS-ANY EXCEPT AS1200:AS-CUSTOMERS accept ANY
export-via: AS6777 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: AS6777 from AS1200:AS-PEERS accept ANY
export-via: AS6777 to AS1200:AS-PEERS announce AS1200:AS-CUSTOMERS
6. RESTRICTIVE with NOT ANY
# Import from no-one
import-via: AS6777 from AS-ANY accept NOT ANY
# Export to no-one
export-via: AS6777 to AS-ANY announce NOT ANY
7. afi lists are also supported (initially described in RFC4012), e.g.:
import-via: afi ipv4.unicast AS6777 from AS-ANY EXCEPT AS1200:AS-CUSTOMERS accept ANY
export-via: afi ipv4.unicast AS6777 to AS-ANY EXCEPT AS1200:AS-CUSTOMERS announce ANY
Relevant objects for participating peers in the Route Server project are grouped into these AS-SETs: