Using PeeringDB to set up your internet exchange peering

What is an internet exchange? An IX is nothing more than a shared subnet that all the members/customers connect to. So, each connected network connects one or more routers to the shared Ethernet network.

Once you start looking at connecting to one or more IXes, you’ll soon find that the larger ones have many members. Fortunately, most IXes have route servers. When you peer with the IX’s route server(s), you automatically peer with all other members who also peer with the route server(s). So that’s a good start. But typically, you’ll also want to peer with other networks that don’t peer with route servers. This involves sending out large numbers of emails to potential peering partners as outlined in the Peering Request Etiquette blog post. Then, if everything happens according to plan, you’ll get a message back that the other network also wants to peer with you, and peering can commence.

At that point, you’ll have to configure one or more routers with the right information to set up a BGP session towards your new peering partner’s router. It is of course perfectly possible to find the contact info of prospective peering partners on the website of the IX or IXes you’re connected to, and then exchange the BGP session details through email. However, in practice this is a lot of work because contact info on the IX websites is often incomplete, and the BGP peering session details in email are unstructured, so there’s a lot of copy/paste involved.

A better way to handle this is through PeeringDB.com.

PeeringDB is a website that has information about internet exchanges and the networks that connect to those IXes. For each network, there’s a lot of information that is relevant to prospective peering partners:

• Mostly inbound traffic (access ISP) or outbound traffic (content network)
• Numbers of IPv4 and IPv6 prefixes announced
• Geographic scope: global, regional or smaller
• (Sometimes) traffic levels
• At which IXes the network is present
• Peering policy: open, selective or restrictive, in the latter cases often with a description of the policy
• Contact information

And, once you’ve agreed to peer, for each IX there’s the AS number (yes, some networks use different AS numbers in different locations!) as well as their router’s IPv4 and IPv6 addresses.

So if a peering partner has their correct information filled in on PeeringDB, you can use the website to find all the information you need to configure your BGP sessions. Well, except for your BGP MD5 passwords. You find all this information on PeeringDB without registering an account, but obviously it’s a good idea to sign up and fill in your own information for others to find. Then, rather than list the relevant information in your peering request emails, you can simply list a link to your PeeringDB information.

However, searching PeeringDB for information and then copying that information to a router configuration in order to set up BGP is still inefficient and error-prone. A better way to do this is to retrieve the desired information directly from PeeringDB using SQL queries or API calls. Unfortunately, PeeringDB no longer supports querying the database using SQL, so it’s necessary to interact with the database through the PeeringDB REST API, which requires more steps to reach the same results.

Setting up a system that queries PeeringDB requires a good amount of work up front, but once that’s done, creating router configurations becomes much easier. As a service to the community, we plan on publishing more extensive information on how to generate router configurations based on the PeeringDB contents in the near future.

The PeeringDB website is very helpful to find information about potential peers, and then after peering has been arranged, obtain the peering details, but using the website still requires a lot of manual work. It’s also possible to use the PeeringDB API to automate some parts of this. Today, we present an example script to obtain a list of potential peers from PeeringDB.

The PeeringDB database can be queried using a REST API. REST allows a client to request information from a server over HTTP or HTTPS. The server then returns the requested information in JSON format.

Our example script is written in PHP. PHP is mostly a web scripting language, but it can also be used on the command line. Our script uses the CURL, the Client URL Library, to perform HTTPS requests. On Linux/Unix systems installing PHP and the CURL library is usually quite easy, and on macOS they are installed by default. Please download the script below and save it with the extension .php:

Download peerlist.php.txt script>>

Once downloaded, you can run the script as follows:

The script will then query PeeringDB to find out at which internet exchanges AS1200 is present. As AS1200 is the Autonomous System of AMS-IX, AS1200 is present at AMS-IX with two routers, so the script shows:

(Obviously you’ll want to use your own AS number—you do have your AS registered with PeeringDB, don’t you?)

The next step is for the script to obtain a list of all networks present at the internet exchanges found above. These are the potential peers, and it’s usually a long list. This is the relatively modest output for Phyxia, AS35627:

AS35627 has a presence at:

Potential peers:

The RS field indicates whether a network is connected to the route servers of the internet exchange, with 1 meaning yes and empty or 0 meaning no.

The script can also be run with the additional keyword csv, and then it will output a comma separated values file which can easily be imported into a database or spreadsheet. The output then looks like this:

This script should provide a simple example of how to interact with the PeeringDB API and it can provide a start for managing peering relationships. In our next blog post we’ll present a script that queries PeeringDB for AS numbers and IP addresses in order to generate router configurations to set up peering.

PART 2 >