OHIO IX offers networks connected to the Peering LAN the opportunity to peer via its route servers. Our route servers add informational BGP communities for IRRDB and RPKI status, and accept traffic engineering BGP communities to control propagation.
Introduction
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 OHIO 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.
Why would you use the route servers?
- Let’s make it easy
Simplify the needed configuration to reach as many networks as possible on the OHIO IX platform by configuring just two BGP sessions. With the large amount of connected parties, it can be a full-time task to manage separate BGP sessions. In addition, whenever a new party connects to the route servers, you will be able to automatically exchange prefixes with it (depending on your/their 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 are connected 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
| Route Server 1 | Route Server 2 | |
|---|---|---|
| Name | rs01.ohioix.net | rs02.ohioix.net |
| ASN | 23169 | 23169 |
| IPv4 | 206.53.204.1 | 206.53.204.2 |
| IPv6 | 2001:504:64:100::1 | 2001:504:64:100::2 |
| Platform | Bird2 | Bird2 |
- When peering with the route servers, it is expected 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.
Prefix propagation and Max-Prefix Advisory
The route servers hold around 100,000 IPv4 prefixes and 50,000 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:
- Your peering policy that is expressed in RPSL format in the IRR database.
- The peering policy of other OHIO IX members in which they can decide to announce prefixes via OHIO IX route servers to specific peers.
We recommend using the OHIO IX Looking Glass (members only) for more up-to-date information about announced prefixes.
Further, for each IPv4 and IPv6 BGP session configurd on our route servers we apply and inbound max-prefix setting to prevent the spread of route leaks or accidental de-aggregation. Members can view our currently-configured max-prefix setting for their network within the OHIO IX IXPManager Portal.
MANRS Compliance
OHIO IX Route Servers are MANRS (Mutually Agreed Norms for Routing Security) compliant.
Route Server Filtering
The OHIO IX route servers validate all recieved prefixes against several checks before propogating them onto other networks.
Prefix sanitization
All OHIO IX route servers perform basic and extended prefix filtering to all member/customer BGP sessions that are being established (optionally) with our Route Servers. The basic prefix filtering consists of blocking the following:
- RFC 1918 ranges
- Reserved and private ASNs
- Paths that include national and international transit network ASNs
- Default route
- Too specific (longer than IPv4 /24 or IPv6 /48)
The OHIO IX route servers add informational BGP communities to all received prefixes, even if they are filtered from output. Members can use the OHIO IX Looking Glass to see which BGP informational communities are applied.
Outgoing prefixes filtering
The route servers are configured automatically to apply IIRDB based filtering (explanation is provided below) and RPKI based filtering (explanation provided below). Note that validity of the IRRDB/RPKI based information provided is not guaranteed in any way.
IRRDB based Filtering
Our route servers generate their configuration based on a IRRDB parser script based on the member’s AS-SET as specified in PeeringDB and/or the on boarding questionnaire. In addition to the AS-SET object to query, we also configure a list of which IRR sources to query. For most networks, we query the ARIN and RADB databases, however combination of sources can be used, including RIR’s (ARIN, RIPE, APNIC, AFRINIC, LACNIC), major etworks (LEVEL3, NTTCOM), or Third Party (ALTDB, RADB). Members can see which AS-SETS and IRRDB’s are used to configure their IRRDB filtering by logging into OHIO IX’s IXPManager [[URL]]. Further, we accept more-specifics of IRRDB Valid prefixes by default, but this can be changed on a per-connection level. To request an update to your configuration, please contact support@ohioix.net.
RPKI ROA Filtering
Our route servers also compare prefixes against RPKI ROA databases. We use two different RPKI ROA validation implementations: rki-client/stayrtr, and routinator, to validated ROA information.
Informational BGP Communities
All prefixes are tagged with informational communities which can be viewed in the OHIO IX Looking Glass:
| COMMUNITY MEAINING | LONG COMMUNITY |
| PREFIX_LEN_TOO_LONG | 23169:1101:1 |
| PREFIX_LEN_TOO_SHORT | 23169:1101:2 |
| BOGON | 23169:1101:3 |
| BOGON_ASN | 23169:1101:4 |
| AS_PATH_TOO_LONG | 23169:1101:5 |
| AS_PATH_TOO_SHORT | 23169:1101:6 |
| FIRST_AS_NOT_PEER_AS | 23169:1101:7 |
| NEXT_HOP_NOT_PEER_IP | 23169:1101:8 |
| IRRDB_PREFIX_FILTERED | 23169:1101:9 |
| IRRDB_ORIGIN_AS_FILTERED | 23169:1101:10 |
| PREFIX_NOT_IN_ORIGIN_AS | 23169:1101:11 |
| RPKI_UNKNOWN | 23169:1101:12 |
| RPKI_INVALID | 23169:1101:13 |
| TRANSIT_FREE_ASN | 23169:1101:14 |
| TOO_MANY_COMMUNITIES | 23169:1101:15 |
| RPKI_VALID | 23169:1000:1 |
| RPKI_UNKNOWN | 23169:1000:2 |
| RPKI_NOT_CHECKED | 23169:1000:3 |
| IRRDB_VALID | 23169:1001:1 |
| IRRDB_NOT_CHECKED | 23169:1001:2 |
| IRRDB_MORE_SPECIFIC | 23169:1001:3 |
| IRRDB_FILTERED_LOOSE | 23169:1001:1000 |
| IRRDB_FILTERED_STRICT | 23169:1001:1001 |
| IRRDB_PREFIX_EMPTY | 23169:1001:1002 |
OHIO IX route server objects
For networks that wish to filter the prefixes learned from the OHIO IX Route Servers, we use the ARIN::AS-OHIOIX-PUBLIC AS-SET
BGP Traffic Engineering
In this section, you will find information about BGP Community filtering and AS-PATH prepending.
Route server peers are able to manipulate outbound routing policies via an in-band mechanism using BGP communities.
Currently, the mechanism is implemented to support the traditional BGP communities (32-bit) and Large BGP communities (96-bit)
Standard Traffic Engineering Communities
| Description | Community |
|---|---|
| Prevent announcement of a prefix to a peer | 0:peer-as |
| Announce a route to a certain peer | 23169:peer-as |
| Prevent announcement of a prefix to all peers | 0:2169 |
| Announce a route to all peers | 23169:23169 |
The community for announcing a route to all peers (23169:23169) is the default behaviour and so there is no need to tag routes with this.
Example #1: if a member wishes to instruct the IXP route server (with AS64500) to distribute a particular prefix only to AS64496 and AS64503, the prefix should be tagged with communities: 0:23169 23169:64496 23169:64503 (i.e. announce to no one except…).
Example #2: for a member to to announce a prefix to all IXP route server participants, excluding AS64497, the prefix should be tagged with only community 0:64497.
Large Traffic Engineering Communities
If you enabled support for BGP large communities, then the following large communities can be used:
| Description | Community |
|---|---|
| Prevent announcement of a prefix to a peer | 23169:0:peer-as |
| Announce a route to a certain peer | 23169:1:peer-as |
| Prevent announcement of a prefix to all peers | 23169:0:0 |
| Announce a route to all peers | 23169:1:0 |
If your route server is configured to support large communities, then you should advise your members to use these over standard 16-bit communities as a large number of networks now have a 32-bit ASN. You should also advise them not to mix standard 16-bit communities and large communities – please choose one or the other.
Lastly, with BGP large communities, AS path prepending control is also available by default using the following large BGP communities:
| Description | Community |
|---|---|
| Prepend to peer AS once | 23169:101:peer-as |
| Prepend to peer AS twice | 23169:102:peer-as |
| Prepend to peer AS three times | 23169:103:peer-as |
RFC1997 Passthru
RFC1997 defines some well-known communities including NO_EXPORT (0xFFFFFF01 / 65535:65281) and NO_ADVERTISE and states that they have global significance and their operations shall be implemented in any community-attribute-aware BGP speaker.
According to RFC7947, it is a matter of local policy whether these well-known communities are interpreted or passed through
The OHIO IX route servers are configured pass through these well known BGP communities.