Hi everyone, welcome to our course on BGP, also known as the Border Gateway Protocol. My goal is to make BGP easy to understand by using simple examples that everyone can understand and follow. I'll steer clear of any confusing terms, so let's dive right in.
I'm going to start with the assumption that you have a basic understanding of Networking and internal routing protocols like OSPF. While it's not essential, this knowledge will come in handy when we explore specific examples.
But why? There are 100s of tutorials out there.
Why another BGP tutorial when there are so many out there, some of which are written by people much smarter than me and explore BGP in great detail? Here's my reason - I want to offer a simple, text-based study guide that's easy to understand. I'm someone who prefers reading to watching videos, and I think there's value in a written guide. You might find this guide useful if,
- You want to learn BGP
- You know BGP but need a quick refresher without watching long video tutorials.
- You're commuting and want to read about BGP without needing to watch videos on your small screen
- You need to review BGP concepts quickly for an interview.
- You're working on setting up a BGP lab and looking for a guide that's clear and simple.
Suresh Vina
Why Do We Need BGP?
If you're diving into your CCNA or CCNP studies, you've likely encountered static routes and then moved on to dynamic routing protocols like EIGRP or OSPF. You've seen how these dynamic protocols automatically learn routes, making them a more practical choice over static routing.
So, now that you're stepping into the world of BGP, you might be asking yourself, "Why do we need BGP? Can't we just stick with OSPF?" I remember having the same question when I was studying. Let me try to clarify this with a simple analogy.
Comparing OSPF/EIGRP to BGP is a bit like comparing a small car to a big truck. Sure, small cars are great. They're designed to efficiently transport people or small goods from point A to point B. On the other hand, trucks are meant for hauling goods over long distances.
Now, think about it, would you use a small car to transport tons of goods? Technically, you could, but it would require hundreds of trips, and cars aren't really designed for that kind of task. OSPF/EIGRP is like the car – fast, efficient, and dynamic for small-scale transportation. BGP, in contrast, is like the truck, it might not be the fastest, but it's built to handle a massive amount of routes, making it essential for the vast network landscape of the Internet.
How does BGP work?
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 ensures 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)
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.
Suresh Vina
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.
Suresh Vina
References
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html
