AMS-IX Route Servers
AMS-IX offers its members connected to the Peering LAN the opportunity to peer via its route servers. We operate two route servers: rs1.ams-ix.net and rs2.ams-ix.net, based on OpenBGPd. Both offer the peers the possibility of filtering based on their IRRdb entries. 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 it does 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 300+ members 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 members 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
|
|
|||||||||||||||||
- We encourage members to peer with both route servers for resilience.
Deployment
Below follows a sample configurations 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-6 peer-group
neighbor AMS-IX-RS-6 remote-as 6777
neighbor AMS-IX-RS-6 version 4
neighbor 195.69.144.255 peer-group AMS-IX-RS
neighbor 195.69.144.255 description Rs1.ams-ix.net
neighbor 195.69.145.0 peer-group AMS-IX-RS
neighbor 195.69.145.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 195.69.144.255 peer-group AMS-IX-RS
neighbor 195.69.145.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" 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]
niels@junix# show protocols bgp
group IPV4-RS {
type external;
description "Route Servers";
family inet {
unicast;
}
export TO-RS;
peer-as 6777;
neighbor 195.69.144.255 {
description Rs1.ams-ix.net;
}
neighbor 195.69.145.0 {
description Rs2.ams-ix.net;
}
}
[edit]
niels@junix# show policy-options policy-statement TO-RS
term unicast-export {
from {
rib inet.0;
prefix-list to-announce;
}
then {
community add rs;
accept;
}
}
term end {
then reject;
}
[edit]
niels@junix# show policy-options prefix-list to-announce
10.25.1.0/24;
Filtering
Participating with the route server project does not mean that you have to send your routes to all participants - you can filter on an AS basis. The filters are 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.
Our previous Quagga route servers were only capable of filtering based on attached communities, which did not provide a lot of flexibility in choosing one's desired peers. While moving to OpenBGPD, we switched to IRRdb-based filtering, which provides more flexibility with regard to imported and exported routes, as well as the possibility of asymmetric filtering. Please read the following chapter on IRRdb-based filtering for your configuration options.
IRRdb-Based Filtering
ANY
Send and receive prefixes to/from any RS participant:
aut-num: AS1200
descr: Amsterdam Internet Exchange (AMS-IX)
[...]
import: from AS6777 accept ANY
export: to AS6777 action community .= { 6777:6777 }; announce AS1200
[...]
ANY except
Send and receive prefixes to/from any RS participant EXCEPT AS1103 & AS12859:
aut-num: AS1200
descr: Amsterdam Internet Exchange (AMS-IX)
[...]
import: from AS6777 accept ANY AND NOT <^[AS1103 AS12859]>
export: to AS6777 action community .= { 6777:6777, 6777:1103, 6777:12859 };
announce AS1200
[...]
RESTRICTIVE
Send and receive prefixes ONLY to/from AS15703 :
aut-num: AS1200
descr: Amsterdam Internet Exchange (AMS-IX)
[...]
import: from AS6777 accept <^AS15703>
export: to AS6777 action community .= { 6777:15703 }; announce AS1200
[...]
Of course also AS-SETs can be used in the import/export rules. All ASes participating in the Route Server peering are grouped into the AS-SET: AS-AMS-IX-RS.
Currently these iRRdbs are supported. The filters will be updated multiple times a day, at 12 and 6 o'clock AM and PM. If you wish to have your filters updated right away or your filters haven't been incorporated correclty, please contact the AMS-IX NOC.
Want to participate?
Presently 192 (out of 334) unique ASNs participate in the route server project, representing over 23,000 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 contact the AMS-IX NOC by email (noc [AT] ams-ix [DOT] net).