Using PeeringDB to set up your internet exchange peering – Part 1

When networks exchange traffic without having a customer-provider relationship, this is called peering. We’ve talked about peering in previous Noction blog posts, such as Peering Request Etiquette, What should your peering policy look like? and Where do networks interconnect? As explained in that last blog post, there’s private and public peering. Private peering happens over a direct interconnect between the two networks involved and public peering happens over an internet exchange (IX).

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.

PART 2 >