Peering Request Etiquette

At home, we pay an ISP to transport our packets to and from the rest of the world. Most organizations do the same. But once a network gets to a certain size, it starts making sense to peer. Peering means that two networks make a direct connection, and exchange the traffic going from A to B and from B to A (including A’s and B’s customers) directly rather than paying an ISP to transport those packets. Typically, no money changes hands in a peering relationship. This is known as settlement-free or “sender keeps all” interconnection. In many parts of the world, there are Internet Exchanges (IXes) that help people who want to peer connect to each other. Basically, an IX is simply a big Ethernet switch. All the IX members/customers connect a router to this switch and can now talk to the routers of all the other members.

Physically connecting to the Internet Exchange is the easy part. Once you’ve done that, you need to ask all of the other IX members if they want to peer with you. Usually, Internet Exchanges maintain a list of members/customers with contact information, so you can email peering requests to potential peers. Sometimes the member list includes information on a member’s peering policy. If the IX member list doesn’t have this information, have a look at PeeringDB.com. Most networks that peer have their info in PeeringDB.

As a rule of thumb, smaller networks want to peer with everyone, but bigger networks only want to peer with other big networks. Why peer with a bunch of small networks when you can peer with their ISP instead? And if those small networks really want to interconnect, they can always pay for the privilege and become customers.

Peering policies tend to boil down to “open”, “selective” and “restrictive”. Large networks often have their peering policy written down in detail and published on their website and usually qualify as “restricted”. I’m sure the lawyers like it if all peering requests are evaluated based on fixed, published criteria. “Open” speaks for itself, and “selective” can mean pretty much anything. If there is a published policy, have a look and see if you obviously disqualify. If not, send a peering request.

The goal of the peering request is to make it as easy for the other party to say “yes” as possible. So all the relevant information that they need to decide whether they want to peer with you needs to be in there, but nothing more. If the engineer at your intended peering partner network gets five peering requests and has ten minutes available, you want your email to be the one that has all the information so it’s possible to set up a new peering connection in a few minutes.

A medium-sized network can easily peer with 200 networks over a single, big IX. Multiply that by five or ten or more exchanges, and you’ll realize that the management of all this peering quickly becomes more work than the actual BGP configuration that allows the routers in two neighboring networks to exchange traffic. Key to this management is the autonomous system number.

So when emailing peering requests, always use a subject line like this: “Peering request from Me (AS65500) to You (AS64999)”.

Your AS number comes first for the benefit of your future peer, and their AS number is also in the subject line so when they email you back, you immediately know the AS you’re dealing with, and it makes searching through your email or ticket system for previous interactions a lot easier. It’s good practice to keep a spreadsheet of who you emailed and when to make sure you don’t miss any potential peers and don’t send any duplicate messages.

Your message must explain who you are and why peering with you is a good idea. That can add up to five to ten lines of text. Make sure that nothing critical is in this text; a lot of people will skim it or even skip it completely.

If you have an important point to make, do so on a separate line. But don’t make every sentence its own paragraph. Figure out where you and your prospective new peer share locations and say something like “It looks like we’re both connected to DE-CIX and Equinix Palo Alto.” Last but not least, list all the pertinent information:

 

Don’t use any fancy ASCII art formatting, that just gets in the way of the copy/paste. Remember that you’ll be peering with lots of foreign networks, so make sure phone numbers are in international format and are ready to be dialed as shown. It’s helpful to list both the number of prefixes you’re sending as well as the maximum prefix setting you want the other side to use. This way, you know when you are about to go over that number that you need to contact all your peers and ask them to increase their max prefixes setting.

If you’re present at a lot of Internet Exchanges, the list of IP addresses can get rather long. In those cases, it can be better to simply refer to your PeeringDB URL. In any event, make sure your information in PeeringDB is up to date, as some people may attempt to use it preferentially over copying/pasting information from your message. (It’s possible to get bulk access to PeeringDB and then use scripts to automatically generate router configuration information based on the PeeringDB records.)

After sending your message, don’t expect an answer right away. Many peering managers like to save up a bunch of peering requests and then deal with all of them in one setting. So even if everything is proceeding it may be a few days before you get an answer. However, in many, many cases there will simply never be an answer, for a variety of reasons. Make sure your peering contact email works; you wouldn’t believe how often peering requests bounce.

When someone agrees to peer, they may or may not set up their end before mailing back a response. So when configuring your end, the BGP sessions may or may not come up. I always like to mail back the output of “show ip bgp summary” for the AS number in question. If the sessions didn’t come up, this allows the other side to see if I used the correct IP addresses. If the sessions did come up, they can see if the number of prefixes I get is what they expect. If sessions didn’t come up, double check to see if you overlooked the other side asking to use MD5 security.

Happy peering!