AMS-IX Route Servers

AMS-IX offers networks connected to the Peering LAN the opportunity to peer via its route servers. Our route servers offer the peers the possibility of filtering based on their IRRdb entries, as well as on predefined BGP communities. Therefore peering with the route servers does not eliminate the possibility of maintaining your peering policy.

Introduction

Normally, you 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 the route server project is to facilitate the implementation of peering arrangements, and to lower the barrier of entry for new participants on the peering platform.

The route servers do not partake in the forwarding path, so they do not forward any traffic. Also, peering with a route server does not mean that you must accept routes from all other route server participants.

Why would you use the route servers?

  • Let's make it easy
    Simplify the setup to as many peers as possible on the AMS-IX network. With the large amount of connected parties on the AMS-IX platform, it can be a full-time task to manage all the BGP sessions. The goal of the route servers is to simplify this task. With just two BGP sessions, you can connect to all the networks on the route servers. When a new party connects to the route servers, you can automatically exchange prefixes (depending on your filters).

  • Manage only your most important peers, let the route server do the rest
    You probably want to exchange as much traffic as possible through the exchange, but setting up a peering takes time and effort. So only set up peering sessions with your most important peers. Let the route server do the rest.

  • Send and receive routes from day one
    Once you connect to the route servers you will start exchanging routes immediately. The route servers are a good way to get started on the exchange.

  • Use it as a backup
    When your BGP session to a party becomes inactive, there is a possibility that you can still connect to them via the route servers. So the use of the route servers can lead to a more stable platform.

  • Maintain your peering policy
    The route server has built in filters that allow you to maintain your peering policies. For more information, please read the filtering topic.

Route server details

rs1.ams-ix.net
ASN: 6777
IPv4: 80.249.208.255
IPv6: 2001:7f8:1::a500:6777:1
Platform: BIRD
rs2.ams-ix.net
ASN: 6777
IPv4: 80.249.209.0
IPv6: 2001:7f8:1::a500:6777:2
Platform: BIRD
  • When peering with the route servers we mandate that routers are set up to connect to both route servers and advertise the same amount and length of prefixes for resilience.
  • Please note that the route servers are set to passive mode and will never initiate a BGP session. You should make sure that your equipment does so, i.e. connects to our TCP port 179 and that your inbound filtering/ACL rules permit established sessions with the route servers.

Deployment

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 6777
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 6777
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:6777:1 peer-group AMS-IX-RS-6
neighbor 2001:7f8:1::a500:6777:1 description rs1.ams-ix.net
neighbor 2001:7f8:1::a500:6777:2 peer-group AMS-IX-RS-6
neighbor 2001:7f8:1::a500:6777: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:6777:1 peer-group AMS-IX-RS-6
neighbor 2001:7f8:1::a500:6777: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 6777;
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;

Filtering

Incoming Prefixes Sanitisation

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.

Please note that apart from bogons prefixes, we DO NOT filter any other prefixes (e.g. prefixes with with mask longer than /25, /8 prefixes ... etc). AMS-IX is a transparent L2 platform, and we try to mimic this as much as possible in our route server offering. Therefore 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 prefixes smaller than /24 or perform IRR-based prefix filtering you are free to do so on your own router.

Outgoing Prefixes Filtering Among Route-Server Members

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 IRRdb, you instruct the route servers 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; a per-AS filtering scheme is 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 change 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.

IRRdb based Filtering

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 is fully supported, 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: 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

BGP Community based filtering

We also offer customers the ability to filter outbound announcements by tagging them with the following predefined communities. Note that you have to use the appropriate route server AS number, based on the AMS-IX location you're peering in, with 6777 representing Amsterdam.Currently supported locations for this feature are Hong Kong (AS58560) and Amsterdam (AS6777). 

  • 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 

For destination peers employing a 32-bit ASN, you can use the route target extended BGP community as follows:

  • do not announce a prefix to a certain peer: RT:0:peer-as 
  • announce a prefix to a certain peer: RT:6777:peer-as
  • do not announce a prefix to any peer: RT:0:6777  

Notes:

- In cases where both IPv4 and IPv6 sessions exist with our route servers but only a IPv4 policy is described in your aut-num object, it is also applied for the IPv6 sessions.

- Multiple import/export and/or import-via/export-via statements for AS6777 are parsed sequentially. In case of duplicate policy specifications, the first attribute encountered is applied, per ambiguity resolution rules of RFC2622 §6.4. To avoid confusion and unnecessary complexity, we strongly suggest being as terse as possible.

- Should you announce anything more than your own AS, please use an appropriate AS-SET in the “announce” section of the export-via attribute. This helps with having an accurate route server object (see below) and with prefix validation checks for peers doing any.

- We currently support only the "ANY" keyword in the mp-filter section of the import-via attributes.

- Our route servers also support RFC5082 (GTSM). Should you wish to enable it for your peering sessions, please contact us.

- Although discouraged, you can use both filtering mechanisms simultaneously (IRRdb based and BGP community based).

AMS-IX route server objects

Relevant objects for participating peers in the Route Server project are grouped into these AS-SETs: AS-AMS-IX-RS (list of connected peers), AS-AMS-IX-RS-SETS (list of advertised AS-SETs), AS-AMS-IX-RS-V6 (list of connected IPv6 peers) and AS-AMS-IX-RS-SETS-V6 (list of advertised AS-SETs for IPv6 peers)

Max-Prefix Advisory

The route servers are announcing around 180000 IPv4 prefixes and 25000 for IPv6. AMS-IX expects future prefix growth and therefore generally advises a max-prefix of 230000 for IPv4 and 30000 for IPv6. We recommend using the AMS-IX Looking Glass (members only) for more up-to-date information regarding announced prefixes.

Want to participate?

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). If you have any issues with that, please contact the AMS-IX NOC