BGP Tools for the DFZ (2)

In the last post in this series, I looked at the whois database to make certain the registration information for a particular domain name is correct. Now it’s time to dig a little deeper into the DFZ to see what we can find. To put this series in the widest context possible, we will begin by assuming we don’t actually know the Autonomous System number associated with the domain name we’re looking for—which means we will need to somehow find out which AS number belongs to the organization who’s routes we are trying to understand better. The best place to start in our quest for an AS number that matches a domain name is peeringdb. The front page of peeringdb looks like this—

As the front page says, peeringdb primarily exists to facilitate peering among providers. Assume you find you are a large college, and you find you have a lot of traffic heading to LinkedIn—that, in fact, this traffic is consuming a large amount of your transit traffic through your upstream provider. You would really like to offload this traffic in some way directly to LinkedIn, so you can stop paying the transit costs to this particular network. But how many places does this operator peer, and what are their policies towards new peering? This is where peeringdb is useful; for any given organization, given the organization keeps their peering information up to date, you can discover something about the organization itself and their peering policies.

Typing linkedin into the search retrieves the following result—

LinkedIn is a network, rather than a facility or an exchange, so it only shows up in the one place in the peeringdb database. Clicking on the link brings us to this page—

There are several important pieces of information about LinkedIn on this page.

If you click on the link at the top left of the table, peeringdb will redirect you to another page that provides just a little more information about the operator—in this case, the mailing address. There is a list names by which the operator may also be known, normally useful in the case of acquisitions and mergers, as well as in cases where companies may just happen to have multiple common names. The third piece of information is one that’s going to be really handy in our search through other DFZ tools, the AS number.

Information about the type of operator is included—LinkedIn is classified as a content provider, which means LinkedIn primarily focuses on providing content to users, rather than on interconnecting other networks. Other options here might be an exchange or transit or edge, for instance. The traffic flow for LinkedIn is classified as heavily outbound, which is true of most content providers. Users tend to send small requests which result in large responses from the provider (think of the request for a video file as the classical example of this situation). The geographic scope is reported as global, which means LinkedIn maintains peering throughout the world (not in just one region). LinkedIn originates 20 prefixes, including IPv4 and IPv6, but no multicast.

Finally, peeringdb reports LinkedIn’s peering policy. LinkedIn, as it turns out, has an open peering policy, which means the operator will peer with any other type of provider—transit, exchange, end user, last mile, or other content providers. For our college situation, this means that it’s not “out of bounds” to contact the administrators at LinkedIn to ask about peering. The operator does not have any ratio requirement—but what does this mean? Some providers will only peer with another operator if the traffic inbound to the peer is within a certain ratio of the traffic outbound (or the other way around). If the ratio gets too high, then the provider is going to want to negotiate some form of financial settlement, because you’re using their network more than they’re using yours. After all, providers still have a network to pay for… LinkedIn does, however, prefer to peer in multiple locations, which is an advantage in steering traffic closer to the actual users who use their service.

This is a fair amount of information in a single place—and a good place to start in pulling the tangled thread of the DFZ apart. In our next post, we’ll start looking at what we can find out based on the AS number we just discovered.

Note: throughout this series, I’m going to be using the LinkedIn AS number and routes, as well as the AS numbers of other public companies for illustration. I’m deviating from my normal practice of using addresses and AS numbers reserved for documentation in order to make it possible for readers to perform the same actions and get something like the same results. Do not use these addresses or AS numbers in your network!