BGP Training Course for Beginners

The Border Gateway Protocol (BGP) is the routing protocol used to exchange routing information between autonomous systems (AS). An autonomous system is simply a group of routers that work under the same administrative control, and BGP is the protocol that allows these systems to share routing information with each other. In simple terms, BGP looks at the Internet as a large collection of autonomous systems.

You will often hear BGP described as a path vector routing protocol because it relies on the AS path as part of its decision process. The AS path is a list of autonomous systems that a route has passed through. BGP uses this information not only to make routing decisions but also to prevent routing loops and to show the path a prefix takes to reach its destination.

Most commonly, BGP is used by service providers for inter-AS routing, but it is also deployed in large enterprise networks. Compared to interior gateway protocols (IGPs) like OSPF or EIGRP, BGP is more scalable and gives administrators greater control over routing decisions through policies.

As always, if you find this post helpful, press the ‘clap’ button. It means a lot to me and helps me know you enjoy this type of content. If I get enough claps for this series, I’ll make sure to write more on this specific topic.

If you are an enterprise and need to connect to another enterprise, you would typically use BGP to exchange routes. The same applies when connecting to cloud providers like AWS, Azure, or Google Cloud. In these cases, BGP is the standard way to exchange routes between your network and the cloud provider.

How does BGP work?

Unlike an IGP, BGP does not use a metric to decide the best path. In fact, BGP does not care about the shortest path at all. Instead, it relies on a set of attributes to determine which path to use.

If you look at the Internet as a whole, it is massive, so BGP needs to be highly scalable. For example, at home or work, you are assigned a public IP address by your ISP. That IP must be reachable from anywhere on the Internet. To make this happen, your ISP advertises its aggregated prefix to neighbouring autonomous systems, which then advertise it to their neighbours, and the process continues until the route is known across the Internet.

BGP uses TCP as the transport protocol on port 179. Two BGP-speaking routers form a TCP connection between one another. The routers then exchange messages to open and confirm the connection parameters (more on this later). BGP routers exchange Network Layer Reachability Information (NLRI). This contains the full paths that a route must take in order to reach the destination network. The paths are known as BGP AS numbers. This information helps in the construction of a graph of ASs that are loop-free.

Any two BGP-speaking routers that form a TCP connection to exchange BGP routing information are "peers" or "neighbours". BGP peers initially exchange the full BGP routing tables. After this, the peers send incremental updates. BGP peers also use keepalive messages, which ensure that the connection between the BGP peers is alive. Notification packets go out in response to errors or special conditions. (We will cover this in more detail in the next part)

BGP in a Nutshell

Path vector protocol
Advertises and learns routes scattered around the Internet
BGP has a robust best-path algorithm and uses path attributes for route selection
Form neighbourships with other BGP routers using TCP port 179
Uses Autonomous System (AS) numbers for routing decisions
Capable of scaling to handle thousands of routes
Offers mechanisms for loop prevention
Supports both IPv4 and IPv6
Can be configured for internal (iBGP) and external (eBGP) neighbours
Provides route aggregation and filtering capabilities
BGP advertised prefix/mask is known as NLRI (Network Layer Reachability Information)

💡

in BGP, NLRI (Network Layer Reachability Information) is a routing update which consists of prefix, prefix-length and BGP Path Attributes.

Some Differences Between IGP and BGP

IGP is designed for routing within a single Autonomous System; BGP is for routing between Autonomous Systems.
IGP routing decisions are based on metrics; BGP decisions are based on multiple path attributes.
IGP generally has faster convergence than BGP.
IGP advertises all routes by default, while BGP advertises the best path only.
IGP is optimized for smaller networks; BGP scales across the Internet.
IGP can discover neighbours dynamically whereas in BGP we need to statically define each neighbour
BGP neighbours don't need to be connected directly
IGP uses link-state or advanced distance vector protocols; BGP is a path vector protocol.

Autonomous System

An autonomous system (AS) is a collection of IP routing prefixes under the control of one or more network providers on behalf of a single administrative entity. Initially, AS numbers were defined as 16-bit integers, which allowed for a maximum of 65,536 numbers. However, the IANA has begun to also assign 32-bit AS numbers ranging from 0 to 4,294,967,295.

ASNs 64,512 to 65,534 of the original 16-bit AS range, and 4,200,000,000 to 4,294,967,294 of the 32-bit range are reserved for Private Use. So, if you want to run BGP internally, you could pick one of the AS numbers from this private range.

💡

Please note that the Private AS numbers shouldn't be advertised on the Internet. They are purely for internal use.

eBGP and iBGP

When learning BGP, you'll hear two distinct types, eBGP (External BGP) and iBGP (Internal BGP). Both play critical roles, but they operate in different contexts and have specific purposes.

eBGP

Purpose - eBGP is used for routing between different Autonomous Systems (ASes).
Peering Relationships: In eBGP, routers form peering sessions with routers in other ASes, enabling them to exchange routing information across the Internet and big enterprise networks.
Path Selection - eBGP focuses on determining the best path to reach networks in other ASes, using various path attributes like AS Path, Next-Hop, and others.

iBGP

Purpose - iBGP is used within a single Autonomous System. It's essential for propagating routes learned from eBGP peers throughout the AS.
Peering Relationships - iBGP routers form peering sessions with other routers within the same AS. These sessions can be direct or facilitated through route reflectors to scale.
Path Selection - While iBGP also uses path attributes for decision-making, its primary role is to ensure that external routes are available throughout the AS, not necessarily to select the best internal path.

The ultimate goal is to receive routes from your eBGP neighbours and advertise them throughout your own AS via iBGP neighbours. If you own public IP addresses and have your own AS, you would also advertise these to your eBGP peers. The power of BGP lies in the use of Path Attributes. As we've mentioned before, BGP features a robust best-path selection algorithm. You have tremendous control over selecting the best path for both inbound and outbound traffic. When a BGP router advertises routes to its peer, it includes those path attributes, which can be adjusted to influence the choice of the best path. We'll dive into this in more detail in a later section of this course.

A Very Simple Example

In this straightforward example, we have an enterprise connected to the Internet through two different Internet Service Providers (ISPs). The company's network is represented as Autonomous System 100 (AS 100), and it is peering with AS 200 and AS 300, which are the ISPs.

Here's how the setup works.

The two routers within AS 100 establish an eBGP session with each ISP's router. This is how the enterprise receives internet routes from the ISPs.
Inside AS 100, the enterprise routers also establish an iBGP (Internal BGP) session with each other. This internal session is crucial as it allows the enterprise to share the routes learned from both ISPs throughout its own network.
With this configuration, the enterprise can now compare and choose the best paths. For example, it can decide to use ISP 1 (AS 200) for certain outbound traffic and ISP 2 (AS 300) for inbound traffic, or vice versa.
The enterprise also advertises its own routes to both ISPs. This means that it informs both AS 200 and AS 300 about the IP addresses it owns, allowing both inbound and outbound traffic to be routed to and from the Internet.

eBGP AS_Path Behaviour and Loop Prevention

The 'AS_Path' attribute is essentially a breadcrumb trail that marks the route's journey across different Autonomous Systems (AS). Each time a route is advertised to a new AS, the AS number through which it has passed is added to this list. Think of the 'AS_Path' as a list of AS numbers that a route has traversed.

Let's use our example diagram to explain. The route for 8.8.0.0/16 originates at AS 100. As it moves to AS 200, the 'AS_Path' is set to '100' by the router in AS 100 because that's where it came from.

When the router in AS 200 sends this route to its eBGP neighbour in AS 300, it adds its own AS number to the list. Therefore, by the time the route reaches a router in AS 300, the 'AS_Path' reads '200 100'. It's important to note the order here, the latest AS number is added to the left, making the oldest AS number sit at the far right.

In AS 300, the first router to receive the route shares it with its iBGP peers without adding its AS number to 'AS_Path'. However, when this route is advertised to an eBGP peer, the router includes its own AS number. So, when the route arrives at AS 400, the 'AS_Path' has evolved to '300 200 100'.

If for some reason, the router at AS 400 tries to send this route back to AS 200, the router in AS 200 will drop /discard the route upon seeing its own AS number in the 'AS_Path'. This is how eBGP's loop prevention mechanism works, ensuring routes don't circulate indefinitely among ASes.

iBGP Loop Prevention

As we've seen in the previous section, BGP routers check the AS-path attribute of incoming routes and reject/discard routes that contain their own AS number.

But, how about iBGP sessions? Well, the iBGP loop prevention mechanism says that "if an iBGP router receives a route, it is not allowed to advertise the same route to another iBGP peer"

Let's consider the given example. Suppose R1 receives a route to 8.8.0.0/16 from an eBGP neighbour. R1 will then advertise this route to its iBGP peers, R2 and R3, within AS 100. Once R2 and R3 receive this route, they adhere to the iBGP loop prevention rule, which dictates they cannot send this same route to any other iBGP peers.

So, in our scenario, R2, upon receiving the route, will not advertise it back to R3, and likewise, R3 will not send it to R2. This rule is essential because it ensures that within the same AS, routers do not create routing loops by repeatedly advertising the same route amongst themselves.

iBGP Full Mesh

RFC 4271 states that all BGP routers within a single AS must be fully meshed to provide a complete loop-free routing table and prevent traffic blackholing. Let's look at another example to understand what's this 'blackholing' all about.

In the given scenario, traffic blackholing occurs due to a lack of route information on Router B within AS 100. Here’s how it unfolds.

The router in AS 100 advertises the prefix 8.8.0.0/16 to Router A via eBGP.
Router A knows about this route and shares it with Router C using its iBGP session.
Router C, now aware of the route to 8.8.0.0/16, advertises this prefix to its eBGP peer in AS 200.

Now, if AS 200 sends traffic destined for 8.8.0.0/16 to Router C.

Router C receives the traffic and needs to forward it to Router A, which advertises the route. It checks its routing table and sees that the next hop to reach Router A is through Router B.
Router C forwards the traffic to Router B, expecting that Router B will then send it to Router A. But here's the problem, Router B does not have any information about the 8.8.0.0/16 prefix because it has no iBGP session with Router A or Router C; hence, it never learned the route.

As a result, Router B drops the traffic because it has nowhere to send it. This is the traffic blackholing issue in iBGP, which occurs when a router is supposed to forward traffic to a destination it has no route to. To prevent this, an iBGP full mesh is required, or alternatively, route reflectors or confederations can be used to ensure all routers within the AS have all the necessary routing information.