What is BGP?

The Border Gateway Protocol (or BGP according to abbreviationfinder) is the routing protocol used on the Internet that connects autonomous systems (AS) with each other. These autonomous systems are usually formed by Internet service providers. BGP is commonly referred to as Exterior Gateway Protocol (EGP) and path vector protocol and uses both strategic and technical-metric criteria for routing decisions, although in practice business aspects are usually taken into account. Within autonomous systems, Interior Gateway Protocols (IGP) such as: B. OSPF used.

Protocol Description

BGP is described in RFC 1163. In the currently used version 4 it is described in RFC 4271. The BGP routers use TCP port 179.

In 1991, the Border Gateway Protocol (version 3) MIB was published in RFC 1269. This MIB enables the management of devices using SNMP that support the BGP protocol as the Autonomous System Routing Protocol.

In February 1998, BGPv4 was provided with so-called multiprotocol extensions in RFC 2283. The current version can be found in RFC 4760. This means that BGPv4 is no longer purely IPv4-specific, but also supports routing with other network layer protocols. Among other things The exchange of MPLS labels is also possible; this was a prerequisite for the use of BGP/MPLS IP VPNs (RFC 4364).

Scope

EBGP

BGP, the only exterior gateway protocol currently in use, is a protocol for routing between autonomous systems (AS). This use is referred to as External BGP (EBGP).

Route Server

At Internet exchanges, for example the German DE-CIX, many autonomous systems come together for the purpose of peering. In order to avoid the need for a large number of BGP connections, including full meshing, so-called route servers are usually offered there. The border routers that connect to the connected networks send their routes to the routing server, i.e. the route reflector, from which all other routers can obtain these routes again. This allows a network to be easily connected to almost all connected networks.

IBGP

BGP can also be applied within an autonomous system. Typically this is done to propagate the routes learned by EBGP routers within its own autonomous system. Although it would also be possible to transmit the BGP attributes (see below) using an IGP, they are not designed for this. This usage is called Internal BGP (IBGP). All IBGP routers that exchange routes together use the same AS number of their own AS if BGP confederations (see below) are not used.

Full meshing

When used within an autonomous system, BGP connections must be established between all routers of the AS so that a complete mesh is created. If an autonomous system contains n routers, this results in�2−�2BGP connections. Due to the resulting scaling problems, a so-called route reflector (RR) is used in larger networks. This eliminates the need for full meshing of the IBGP routers; Instead, they establish a BGP connection to one or, for redundancy reasons, to several route reflectors.

The reason for the need for complete meshing is that IBGP itself does not pass on BGP information received from neighboring BGP routers within an autonomous system to other IBGP routers (“ split-horizon principle”). This is to avoid routing loops.

Route Reflector

In order to solve the problem of the large number of BGP sessions that occur with a complete mesh, one or more BGP routers can be configured as route reflectors in an AS for redundancy reasons. So each EBGP router only sends the routes learned via EBGP via IBGP to a specific BGP peer, the route reflector, which collects them and in turn distributes them via IBGP to the other BGP routers in the AS. Since each BGP router now only needs to maintain a single BGP connection to its route reflector, there are only n connections in total.

A single route reflector represents a single point of failure. To ensure reliability, several of these routers can be connected together as a cluster. The IBGP routers must establish a connection to each of the cluster routers. With n routers and m route reflectors, this results in n m connections.

Route reflectors can be routers that are provided in the network specifically for this task or are located in the data path as a normal router and perform route reflector functionality.

Confederation

Through confederation, an autonomous system (AS) can in turn be divided into autonomous systems (sub-AS). These sub-AS receive different private AS numbers (ASN), for which the range 64512–65535 (16-bit AS number range) or 4200000000–4294967294 (32-bit AS number range) is reserved and free is available. No registration is required to use these AS numbers, e.g. B. at the RIPE NCC. The AS numbers from these private areas are not forwarded to other EBGP routers by EBGP routers with public AS numbers. Different AS numbers are used within the AS, but only the external AS number is presented via a public EBGP router. EBGP is used for route exchange between the sub-AS. On the one hand, the use of Confederation can simplify the management of large ASes and, on the other hand, the connection complexity can be reduced by fully meshing all IBGP routers.

In the graphic, AS100 and AS200 represent public autonomous systems (AS) that exchange routes via EBGP. AS100 is divided by confederation into two private autonomous systems AS65050 and AS65100. The two private AS also exchange their routes with each other via EBGP. A BGP router is configured as a route reflector (RR) within both private ASes. All other BGP routers within a private AS exchange their routes with each other using the route reflector via IBGP.

Loopback addresses

Unlike EBGP connections, which typically terminate on physical router interfaces, IBGP connections are defined between router loopback addresses. This is intended to avoid that if a physical router interface is deactivated/failure, the IBGP connection is aborted, although the router could switch this over to an alternative interface if appropriate redundancy was provided within the autonomous system. However, since the loopback addresses cannot yet be propagated as a route without an existing IBGP connection, an underlying Interior Gateway Protocol (IGP) such as e.g. B. OSPF required. This means that an IGP router process is also configured on each IBGP router. Since each IBGP router has at least two physical NICs, the IGP will know several possible paths between the loopback addresses. If a physical network interface of an IBGP router fails, an alternative path is propagated via IGP. As long as at least one physical interface is reachable, the loopback address configured on the router is also reachable and the IBGP connection can be rerouted within the AS without interruption.

Without loopback addresses, the IBGP routers would be tied to each other on physical interfaces. If such an interface were to fail, the connection would be interrupted and consistent distribution of routes within an autonomous system would no longer be ensured, even if the internal network infrastructure was implemented redundantly.

Protocol overview

The direct connections between neighboring routers are specified manually. Routers that want to exchange routing information with each other via BGP first establish a TCP connection over which the BGP messages are then sent. This connection is called a BGP session (“session”).

BGP protocol

Bit offset 0-15 16-23 24-31
0 Marker (16 bytes)
32
64
96
128 Message Length Message type
Message
  • Marker: All bits of the first 16 bytes are set to “1” for compatibility reasons.
  • Message Length: Total size of the BGP message
  • Message Type: Type of BGP message
1 = Open RFC 4271
2 = Update RFC 4271
3 = Notification RFC 4271
4 = KeepAlive RFC 4271
5 = ROUTE REFRESH RFC 2918
  • Message: During a route update, the routes that were added or deleted are indicated in this area.

Types of BGP messages

BGP uses four different types of messages in the protocol:

OPEN
Only sent at the start of a connection and must be responded to with a KEEPALIVE message. The parameters BGP version, AS number, hold timer, BGP identifier and optional parameters are sent with the OPEN message. The route information is then exchanged between the routers.

UPDATE
Notifies a path change. Multiple paths can be added and multiple paths removed at the same time per UPDATE message. UPDATE messages are the core of BGP.

NOTIFICATION
Terminates a connection and indicates error or status codes. All paths that were received over this terminated connection must now be deleted. A BGP update would then spread the word that this route is no longer available.

KEEPALIVE
Confirms the OPEN request. To regularly check whether the connected router is still online or whether the connection has been interrupted and the paths via the connected router have therefore become invalid. The routers that have just established a BGP session send each other a KEEPALIVE message at regular intervals. This only consists of the message header. The Hold Time attribute of an OPEN message specifies the maximum time during which a BGP router expects a KEEPALIVE message from the session’s BGP partner. If no KEEPALIVE message arrives within the hold time, the BGP session is ended with a NOTIFICATION.

Connection status with BGP

The graphic shows the different states of a BGP connection. In practice, it is important to know that no routing entries are exchanged when the status Active is displayed in a router configuration. This status means that a connection is being attempted. Only when the established status has been achieved is there a functioning connection between the BGP routers.

More detailed description

The core of BGP is the UPDATE message, which BGP routers use to inform each other of the existence of new routes ( announcement ) or the removal of existing routes ( withdrawal ). The recipient of an UPDATE message decides based on their routing guidelines (“policies”) whether they change their routing (and then have to send UPDATE messages themselves), simply forward the message (e.g. via IBGP) or simply ignore it.

Attributes

A route in BGP has several attributes. The most important ones are explained below.

  • The AS Pathdescribes which autonomous systems can be used to achieve the specified goal (a CIDR prefix). The autonomous systems are identified by their AS number (ASN). There may not be a loop in the AS path; However, it is permitted for an AS to register several times in a row and thus artificially lengthen the AS path in order to make the route available but unattractive ( AS Path Prepending ).
  • The IGP metricdescribes the cost through one’s own network to reach the exit point to the next AS on the AS path.
  • The Multi-Exit Discriminator(MED) is used to prioritize different parallel connections to the same neighboring AS, with the smallest value being preferred. This attribute is used between EBGP peers.
  • Communitiesare routing tags that can be used to mark routing changes (UPDATE messages) or transmitted prefixes to other BGP peers. A BGP community is a 32-bit value that can be used as a filter criteria by other BGP routers. In addition to standard communities, so-called extended communities12345:12345 can be used freely in the notation or as a decimal number.
  • Local Preference determines a preferred path from several paths within the same AS using the higher value. If there are several routes with AS paths of the same length for the same destination prefix, then you can prefer certain routes using Local Preference ; see section “Path selection”.
  • Next Hopis the specification of the IP address of the next hop router to a prefix. The next-hop router is the gateway router that connects its own AS to the next AS on the AS path.
  • Weightis a local attribute (proprietary); see section “Path selection”.
  • Originindicates the source of a prefix: IGP, EGP, or Incomplete.

Path selection

It often happens that a router is given different routes to the same destination. The selection of the route he ultimately chooses is known as the BGP Path Selection Process. The network operator can control and influence the path selection in the router by choosing appropriate rules in the router.

Basically, the BGP path selection process follows the following rules:

  1. The path with the largest Weightvalue is preferred (Cisco proprietary ).
  2. If the Weightvalue is the same, the value with the greatest Local Preference is preferred.
  3. If the Local Preferencevalues ​​are equal, the path generated by BGP on this router is preferred.
  4. If no path has been generated on this router, prefer the path with the shortest AS_PATH attribute.
  5. If all AS_PATH attributes are the same length, prefer the lowest origin type ( IGPis lower than EGP, EGP is lower than Incomplete )
  6. If all origin types are the same, prefer the path with the lowest MED attribute.
  7. If all paths have the same MED value, prefer external paths over internal paths.
  8. If all paths still have the same priority, prefer the path to the closest IGP neighbor.
  9. If all paths are the same, prefer the path with the lowest IP address of the BGP peer based on the router ID.

Interaction of IBGP with the IGP

In order for a router to be able to forward a packet to another network to which it has no direct connection, there is usually an interaction between IBGP and the IGP (the intradomain routing protocol, for example OSPF, IS-IS, EIGRP / IGRP, RIP ), which is needed to forward packets to the corresponding gateway router. The BGP attribute Next Hop is used for this purpose.

Example: A router R 1 in AS1 is supposed to forward a packet to the destination address 10.1.2.3. He previously found out from an IBGP update message that the target network 10.0.0.0/8can be reached via the neighboring AS 4711. However, R 1 has no direct connection to AS4711; This connection only exists on another router R 2 (gateway router). However, through the BGP Next Hop attribute, R 1 knows the IP address of R 2. Only based on the information from the IGP, R 1 knows the shortest path within AS1 to R 2 and therefore knows to which neighboring router R x it has to send the packet so that it arrives at the gateway router R 2, which finally sends it to AS4711 can forward.

Providing reachability information for the IBGP protocol through an IGP protocol is also necessary to establish IBGP sessions between IBGP routers that are not immediately adjacent or to BGP route reflectors.

Special features of BGP

Routing loops

BGP is a path vector protocol. Its functionality is closely linked to distance vector algorithms and protocols such as: B. Routing Information Protocol (RIP), but the problem of routing loops that occurs there is effectively prevented. A routing loop occurs when an IP packet passes the same AS several times on its way through the Internet. A BGP router, when sending routing information (UPDATE), tells the communication partner not only that it can reach a specific section of the Internet, but also the complete list of all autonomous systems (AS-Path) that handle IP packets up to must happen in this section (its own AS comes first, the target AS comes last). If the communication partner now notices that the AS to which it belongs is already in this list, it discards the message and thus avoids the creation of a routing loop.

Route Aggregation

With BGP, each router can combine common routes, in contrast to e.g. B. with OSPF, on whose routers a routing summary can only be performed on the area border routers.

Link state

Different link speeds are not taken into account. The routes are mainly selected based on length ( AS Path ) and strategic aspects.

Hop length

The number of (BGP) routers (“ hops ”) is not taken into account by BGP as a decision criterion when selecting the best path to the destination – only the number of autonomous systems is important (apart from the IGP metric attribute ).

Problems with BGP

General

BGP inherently has a number of weaknesses that can arise in a minimal configuration. However, the weaknesses are usually compensated for by the fact that the prioritization of paths is subject to routing policies that the respective network operator controls.

Growth of routing tables

Since each BGP router has route information from other, especially neighboring BGP routers, each BGP router builds up a database for the routes to all reachable autonomous systems. The size of the table with the route information in December 2016 was around 650,000 entries in around 56,000 autonomous systems.

IPv4 End of 2005 April 2011 April 2012 May 2014 June 2015 December 2016
Routing entries 170,000 360,000 411,000 500,000 557,973 646,157
Autonomous systems 26,000 37,000 40,900 47,010 50,921 56,158

The growth of routing tables can be counteracted to a certain extent by route aggregation.

When developing IPv6, the problem of routing table growth in IPv4 was also taken into account. When using IPv6, significantly fewer routing entries are to be expected. Currently, not all Internet providers use IPv6 and therefore the following statistics cannot be directly compared with the table above about IPv4 routing entries.

IPv6 April 2012 June 2015 December 2016
Routing entries 8,500 22,014 34,789
Autonomous systems 5,100 8,251 12,666

Load distribution

By default, BGP does not have any load balancing methods. Only one possible route is always selected. However, there are proprietary extensions that allow load balancing configuration. In contrast to e.g. B. OSPF load distribution on differently weighted connections.

Security

In its basic configuration, a BGP router is vulnerable to spoofing attacks that allow attackers to manipulate routes. By using authentication with a password individually defined between the BGP peers (based on MD5 hashes), data exchange between the BGP routers can be secured. Although this makes spoofing attacks much more difficult, it is particularly dependent on the security of MD5, which is now no longer considered secure by crypto experts.

Furthermore, due to the point-to-point nature of BGP router relationships, the permitted BGP peers can be restricted to the permitted partners using packet filter lists.

In addition, various other security mechanisms have been and are being proposed for BGP; However, even if the proposed methods were used across the board, it would be almost impossible to completely prevent attacks that intend to redirect traffic flows.

Route Flap

Route flaps are caused by routes that fluctuate back and forth, are advertised and withdrawn again and again over long periods of time. As a countermeasure, modern BGP implementations offer a procedure called route flap damping, which, however, can lead to undesirably long delays in the propagation of route changes under certain conditions.

Update Bursts

Update bursts are large amounts of UPDATE messages that occur suddenly, often to uncorrelated destinations.

Special Events

YouTube Block

In February 2008, a court order forced Pakistan Telecom to block YouTube traffic in Pakistan. Technically, this was implemented by feeding an incorrect route to YouTube’s network into IBGP. However, due to a configuration error, this incorrect route was not only used in Pakistan, but was also mistakenly distributed to other Internet providers via EBGP, which led to YouTube being blocked for several hours, particularly in Asia.

Misconfigured BGP router

In February 2009, a Czech BGP router was forwarding too long AS paths to public BGP routers. Some BGP routers had problems processing these long AS paths, resulting in disruptions to Internet traffic. Administrators can counteract such a problem by configuring to limit the maximum length of the accepted AS path.

Revolution in Egypt 2011

During the revolution in Egypt in January 2011, around 3,500 routes from all Egyptian Internet providers were withdrawn via BGP in just a few minutes, cutting off almost all of Egypt from the Internet. Cell phone services and social networks were also no longer accessible. This appears to be the first case in the history of the Internet in which an entire country was closed off from the Internet for political reasons.

Software error

The BGP Path Attribute can take the value 255. This is available for development. Back in 2010, an experiment with this flag led to crashes in some routers. In a new attempt at the end of 2018, incorrectly implemented routers were found again.

Facebook, Instagram and Whatsapp

On October 4, 2021, all Facebook, Instagram and Whatsapp services were unavailable worldwide for approximately 6 hours. This was due to a misconfiguration of Facebook’s self-hosted BGP routers.

What is BGP