Table of Contents
The Peering Database
The Peering Database is a freely available, user-maintained database of networks which take part in the global Internet. It is considered the authoritative source of all information relating to network operators who participate in peering around the world.
The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centres, and other interconnection facilities, and is the first stop in making interconnection decisions.
In the early Internet (of the 1990s) there were few network operators and interconnect points around the world that interconnections were relatively straightforward to seek out and implement (in the author's experience anyway). In March 1999 there were 4640 ASNs in the Internet with only 800 providing transit. This compares with today's total exceeding 73000 ASNs and over 10000 ASNs providing transit, never mind that almost every country in the world now has at least one Internet Exchange Point if not a datacentre facilitating commercial interconnects.
In the 1990s, establishing new interconnects was achieved by attending major Internet operations meetings (NANOG, RIPE, AfNOG, APRICOT and so on), with network information passed on by word of mouth or email or even by letter!
With the rapid growth of the Internet in the late 1990s and early 2000s, there needed to be a more scalable way for a Network Operator to get their “peering information” out to the global Internet operations community. And hence the PeeringDB was born.
What is the Peering DB
The Peering DB is a repository of the important information that network operators need to determine whether an interconnection is feasible, makes commercial sense, makes technical sense, and is even technically feasible. While the Peering DB website has much more detailed information, the Peering Toolbox is highlighting the key points.
Here are some example entries to show what is possible. The first example (publicly accessible) is of LINX, the London Internet Exchange:
which shows a screen capture of what is available at their LON1 site, a scrollable list of the participants, how to contact LINX, etc.
The second example below shows that of a AWS (Amazon Web Services), one of the major content networks on the Internet:
This one shows the Public peering and Private peering facilities AWS is present at. So a potential peer can check which locations they share with AWS, and then contact them about peering. The page for AWS contains data about number of prefixes, traffic ratios, etc, plus the IP addressing used at the various public Internet connect points. All this is designed to make it easier for prospective peers to assess and reach out to AWS for peering.
And the final example shows Arelion, the operator of AS1299, one of the international transit carriers serving the global Internet:
again showing the type of data that are published in the PeeringDB.
Creating a PeeringDB Entry
The Peering Toolbox recommends (strongly) that any entity with their own AS Number and address space should create an entry in the Peering DB. There is no cost to doing so.
A tutorial on how to create an entry is currently beyond the scope of the Peering DB - but the best advice is to look at other PeeringDB entries and use what those entries have to guide what is needed for your own one.
Simply create an account, and populate it with the mandatory entries - and place as much information there as you possibly can. This should minimally be:
- Organisation name
- Organisation website
- IRR AS-set
- Network Type
- Number of IPv4 prefixes
- Number of IPv6 prefixes
- Traffic Levels
- Traffic Ratios (inbound to the network, or out from the network)
- Geographic Scope (ie what locations are served)
- Protocols supported (IPv4 and IPv6 are common)
- Peering Policy (Open, Selective, Restricted)
- Contact information (NOC, Policy/Admin, Technical)
- Public Peering Points (if applicable)
- Private Peering Facilities (if applicable)
Why a PeeringDB entry
Today very few network operators will considering peering with an entity that has no PeeringDB entry. In fact, many will make it a requirement before they will even respond to a peering request. Indeed, some operators will go as far as using information in the PeeringDB for configuring peering sessions with their peers, making it essential that the entries are kept up to date.
Therefore, the Peering Toolbox recommendation is that all Network Operators with their own Internet Resources and who wish to take part in the global peering community must create and maintain their PeeringDB entry.