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.
The route servers hold around 111K IPv4 prefixes and 52K 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:
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 111K for IPv4 and 52K for IPv6. However, we advise our members to configure a max-prefix of 139K for IPv4 and 63K for IPv6 due to the following reasons:
We recommend using the AMS-IX Looking Glass (members only) for more up-to-date information about announced prefixes.
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).
The AMS-IX Looking Glass will be implemented soon in Singapore.
AMS-IX Amsterdam Route Servers are MANRS (Mutually Agreed Norms for Routing Security) compliant.
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 133160
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 133160
neighbor AMS-IX-RS-6 version 4
neighbor AMS-IX-RS-6 transport connection-mode active
neighbor 80.249.208.255 peer-group AMS-IX-RS
neighbor 80.249.208.255 description rs1.ams-ix.net
neighbor 80.249.209.0 peer-group AMS-IX-RS
neighbor 80.249.209.0 description rs2.ams-ix.net
neighbor 2001:7f8:1::a500:133160:1 peer-group AMS-IX-RS-6
neighbor 2001:7f8:1::a500:133160:1 description rs1.ams-ix.net
neighbor 2001:7f8:1::a500:133160:2 peer-group AMS-IX-RS-6
neighbor 2001:7f8:1::a500:133160: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 80.249.208.255 peer-group AMS-IX-RS
neighbor 80.249.209.0 peer-group AMS-IX-RS
network 192.168.110.0 mask 255.255.255.0
network 192.168.111.0 mask 255.255.255.0
network 192.168.112.0 mask 255.255.255.0
exit-address-family
!
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:133160:1 peer-group AMS-IX-RS-6
neighbor 2001:7f8:1::a500:133160:2 peer-group AMS-IX-RS-6
network 2001:DB8:10::/64
network 2001:DB8:11::/64
network 2001:DB8:12::/64
exit-address-family
!
ip as-path access-list 12 permit ^$
!
ip prefix-list TO-RS seq 10 permit 192.168.110.0/24
ip prefix-list TO-RS seq 20 permit 192.168.111.0/24
ip prefix-list TO-RS seq 30 permit 192.168.112.0/24
!
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:
[edit]
user@junix# show protocols bgp
group IPV4-RS {
type external;
description "Route Servers";
family inet {
unicast;
}
export TO-RS;
peer-as 133160;
neighbor 80.249.208.255 {
description rs1.ams-ix.net;
}
neighbor 80.249.209.0 {
description rs2.ams-ix.net;
}
}
[edit]
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;
}
[edit]
user@junix# show policy-options prefix-list to-announce
10.25.1.0/24;
AMS-IX route server filtering.
All AMS-IX route servers in Singapore 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.
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.
As stated above, from July 2019 and onwards, our route servers in Singapore implement 3+1 peering modes of prefix filtering in the outbound direction.
Optionally, we can offer the following peering mode in case you really need an unfiltered BGP feed (e.g. for research purposes":
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.
Our configuration pipeline uses the following official IRR Databases in order to retrieve the RPSL objects and create route server prefix lists:
RIPE, ARIN, APNIC, AFRINIC, LACNIC, JPIRR, IDNIC
Complementary to the above list, we use the following unofficial IRR databases but with less priority:
NTT, LEVEL3, RADB
We encourage our members/customers to create their RPSL objects (AUT-NUM, AS-SET, ROUTE/ROUTE6) in one of the above IRR databases and always prefer official DBs instead of unofficial ones. As a side note, we would examine member/customer requests to expand the list of official DBs we support, in case of routing issues or public demand.
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: AS133160 from AS-ANY accept ANY
export-via: AS133160 to AS-ANY announce AS1200
[...]
2. ANY except
(Send and receive prefixes to/from any RS participant EXCEPT AS666):
[...]
import-via: AS133160 from AS-ANY EXCEPT AS666 accept ANY
export-via: AS133160 to AS-ANY EXCEPT AS666 announce AS1200
[...]
3. RESTRICTIVE
(Send and receive prefixes ONLY to/from AS15703):
[...]
import-via: AS133160 from AS15703 accept ANY
export-via: AS133160 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: AS133160 from AS-ANY EXCEPT AS1200:AS-CUSTOMERS accept ANY
export-via: AS133160 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: AS133160 from AS1200:AS-PEERS accept ANY
export-via: AS133160 to AS1200:AS-PEERS announce AS1200:AS-CUSTOMERS
[...]
6. RESTRICTIVE with NOT ANY
# Import from no-one
import-via: AS133160 from AS-ANY accept NOT ANY
# Export to no-one
export-via: AS133160 to AS-ANY announce NOT ANY
7. afi lists are also supported
(initially described in RFC4012), e.g.:
import-via: afi ipv4.unicast AS133160 from AS-ANY EXCEPT AS1200:AS-CUSTOMERS accept ANY
export-via: afi ipv4.unicast AS133160 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:
In this section, you will find information about BGP Community filtering and AS-PATH prepending.
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.
Currently, the mechanism is implemented to support the traditional BGP communities, the Extended BGP communities and the Large BGP communities.
Please note that AMS-IX is planning to drop the support for the Extended communities as their functionality is fully covered from the Large communities.
When you want to signal the Route-Server to filter prefixes for destination networks that have 16bit ASN, you can use either the traditional communities or the Extended communities. In case the destination network is a 32bit ASN, then you can use either the Extended communities or the Large communities.
To make the above easily understandable, we provide the table below that summarises the available options:
Source ASN and destination ASN | Legacy communities | Extended communities | Large communities |
16bit ASN to 16bit ASN | YES | YES | YES |
16bit ASN to 32bit ASN | NO | YES | YES |
32bit ASN to 16bit ASN | NO | YES | YES |
32bit ASN to 32bit ASN | NO | NO | YES |
Note that you have to use the appropriate route server AS number, based on the AMS-IX location you're peering in, with 133160 representing Singapore. All locations support this feature.
For traditional BGP communities, the offered options are:
For BGP Extended communities, you can use the offered options below:
For Large communities, the offered options are as below:
Note that if you want to advertise a specific prefix to a specific customer only, then you need to combine “133160:<peer-as>” and “0:133160” BGP communities.
As with the community-based filtering, AMS-IX peers have the ability to influence the prefix selection process of other members based on AS-Path pretending. The mechanism can be enabled either with the traditional 16bit BGP communities, or with the 32bit Large communities.
For the traditional 16bit communities, the prefix tagging must be as below:
The same result can be achieved by tagging prefixes with Large Communities as below:
Please note that in case you use your own ASN in the “<peer-as>” position then we prepend your prefix to all other AMS-IX members. However, if you use in the position of the ASN of another AMS-IX member, the route servers will prepend the prefix once, twice, or thrice towards that particular AMS-IX member only.
Dynamic per-AS Prefix Limits
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.
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 y | Coefficient x | Prefix Limit (yx < z) | ||
---|---|---|---|---|
y < 50 | 2 | 100 | ||
50 < y < 249 | 2 | 500 | ||
250 < y < 499 | 2 | 1000 | ||
500 < y < 999 | 2 | 2000 | ||
1000 < y < 2000 | 2 - 1,5 | next step of 1000 | ||
2000 < y < 10000 | 1,5 - 1,2 | next step of 1000 | ||
y > 10000 | 1,2 | next step of 1000 |
Examples | ||
---|---|---|
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,75 = 2625. 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 |
© 2024 - Amsterdam Internet Exchange Responsible Disclosure Policy Mailing list code of conduct General Terms and Conditions Privacy Policy Email Disclaimer Cookie policy
Trade register: 34128666