BGP and Your Brand’s Bottom Line

This blog is the third installment of a 5-part blog series about the Border Gateway Protocol (BGP). You can download the full series in The Comprehensive Guide to BGP, or view individual installments below.

Part 1: Happy Birthday to BGP, a Pillar of the Modern Internet

Part 2: X-Raying BGP

Part 4: How BGP Routing Really Works

Part 5: Vulnerabilities of BGP

The concept of the Internet as we know it today can be traced back to the early 90s. Up until then, the Internet was reserved to noncommercial and research activities, and commercial uses were strictly forbidden. Things changed rapidly in the 90s with the increasing pressure of the community and newborn regional ISPs such as PSInet, UUNET, and CERFnet, which started to interconnect each other networks via Commercial Internet Exchanges (CIX, pronounced kicks) to bypass the commercial interdiction set by the backbone. Commercial limitations were finally removed in 1995, with the decommission of the NSFNET and the official birth of the modern Internet.

24 years (and a dot-com bubble burst) later, Internet still works on the very same foundations. A limited number of companies (e.g. CenturyLink, AT&T, Verizon) are offering transit via their worldwide backbone to a much larger number of companies. Among them, we have eyeball networks such as most of national telcos (e.g. Telecom Italia, British Telecom), regional providers (e.g. Apuacom), and CDNs (e.g. Comcast, Sky), all aiming at providing the best performances to end users – even if from different perspectives – via their interconnections, often established on Internet eXchange Points (IXPs).

Differently from the last few decades, new big players (e.g. Google, Facebook, Netflix) recently joined this interconnection game with enough resources to mine their own foundation. These players decided to play on their own by creating their own worldwide infrastructure, interconnecting directly to as many AS’s as possible and offering direct access to their content, thus totally bypassing third-party backbones.

Up to date, the scenario is composed by about 65k AS’s, mostly regional, interconnected to each other via BGP and each enforcing its role via a specific set of import/export filter policies. Among these 70k AS’s, only about twenty of them can reach the whole Internet destinations without purchasing transit from any other AS, forming the so-called Tier-1 club.

Image courtesy of Wikipedia

Economic Relationships and BGP

The Internet is a complex system made of interconnected AS’s, each with its own role, market, and resources. Nevertheless, it is possible to roughly categorize the type of relationships existing between AS’s in two broad categories, each identified by a BGP import/export filter policy.

The first relationship is provider-to-customer (p2c), or customer-to-provider (c2p), where one of the two AS’s is providing transit to the whole Internet for the other AS. This type of relationship is often on a contract basis involving a fee paid by the customer to the provider, and it is established via private facilities.

To fulfill its role, the provider announces to the customer every route required to reach the whole Internet. Depending on the agreement, this could consist of a single default route (0.0.0.0/0 in IPv4 and ::/0 in IPv6) or of a full routing table, which as of today consists of about 750k subnets in IPv4 and about 80k subnets in IPv6. On the other side, the customer will announce to the provider only its own routes and the routes received from its customers to allow the provider to use their interconnection to reach those destinations.

The second relationship is peer-to-peer (p2p), where the two AS’s decide to announce to each other the networks which each AS can reach without using any transit connection or any other p2p relationship. One of the main reasons behind these relationships is to keep traffic local as much as possible via public or private facilities, thus avoiding extra delays introduced by the transit connection which potentially can route the traffic via another country.

This type of relationship is typically settlement-free and established on IXPs and known as public peering. However, this is not always the case. Depending on the agreement made by the two AS’s, p2p relationships can also involve a fee (paid peering) and/or can be established in private facilities (private peering). According to PCH survey, only very few p2p relationships are paid or private peering, and most of them are not formalized in any written document. Moreover, during the last year most AS’s exploit route-server on IXPs to establish p2p relationships among them (multi-lateral peering).

R_oute server schema, courtesy of_ FranceIX.net

Route servers are basically the eBGP alter-egos of iBGP route reflectors. Usually they are software solutions that IXPs offer to their participants to easily interconnect to each other with a single BGP session. They run on the peering LAN of the IXP and accept BGP sessions only from BGP speakers located in the very same peering LAN of the IXP.

Once a network is announced to the route server, that route is propagated to every AS connected to the route server without modifying the NEXT_HOP attribute as in every other regular BGP session. This way, the receiver will see the original NEXT_HOP attribute announced and will be able to route its packets directly via the NEXT_HOP indicated and present on the peering LAN of the IXP. Each AS connected to the route server has also the possibility to control how announced networks are re-advertised towards other peers using operational BGP communities.

In any case, AS’s involved in any p2p relationship will act each other as a customer of the other. In other words, each AS will announce to the other peer only its own routes and the routes received from its customers to avoid becoming a transit for the other peer.

These economic relationships were firstly introduced by Lixin Gao in 2001, and still stand for today Internet. Whenever one AS violates the above relationships with malformed or even missing filters, we have route leaks, which are defined as “the propagation of routing announcements beyond their intended scope.” One of the last leaks, which caused a ripple effect across the Internet, was extensively described in one of our recent blogs.

BGP route monitoring is a key component of Catchpoint’s Network Experience solution. Visit our product page to learn more about finding and fixing BGP issues fast with Catchpoint, and download our ebook, The Comprehensive Guide to BGP.