Why I Think Every Network Engineer Should Understand BGP

I have spent over a decade working with enterprise and service provider networks, and if there is one protocol that consistently separates competent network engineers from exceptional ones, it is BGP. The Border Gateway Protocol is not just another routing protocol. It is the routing protocol that makes the global internet function. Every time you load a webpage, stream a video, or send an email, BGP is quietly working behind the scenes, determining how your traffic traverses dozens of interconnected networks to reach its destination.

In this BGP tutorial, I want to break down everything you need to know about the protocol — from the foundational concepts to practical configuration and security considerations. Whether you are studying for a certification or managing production networks, understanding BGP is non-negotiable in 2026.

What Is BGP and Why Does It Matter?

BGP, or the Border Gateway Protocol, is a path-vector routing protocol used to exchange routing information between autonomous systems (ASes) on the internet. While interior gateway protocols like OSPF and EIGRP handle routing within a single organization’s network, BGP handles routing between organizations. It is the glue that connects ISPs, cloud providers, enterprises, and content delivery networks into the unified system we call the internet.

Here is the fundamental problem BGP solves: the internet is not one network. It is a collection of roughly 75,000 autonomous systems, each independently operated. These networks need a way to tell each other which IP address blocks they own and how to reach them. BGP is that mechanism.

Some key characteristics that define BGP:

• Path-vector protocol: BGP does not just know the next hop. It knows the entire AS-path to a destination, which helps prevent routing loops.
• Policy-driven: Unlike most IGPs that optimize for shortest path, BGP lets administrators apply complex routing policies based on business relationships.
• Incremental updates: After the initial full table exchange, BGP only sends changes, making it efficient even with 900,000+ routes in the global table.
• TCP-based: BGP runs over TCP port 179, providing reliable delivery without needing to build reliability into the protocol itself.

How the Internet Uses BGP: Autonomous Systems and Path Selection

To understand BGP routing, you first need to understand autonomous systems. An autonomous system is a collection of IP networks and routers under the control of a single organization that presents a common routing policy to the internet. Each AS is identified by a unique Autonomous System Number (ASN), assigned by regional internet registries like ARIN, RIPE NCC, or APNIC.

When I configure BGP on a router, I am essentially telling it: “Here are the networks we own, and here are the neighbors we peer with.” The router then advertises those networks to its BGP neighbors, who propagate the information further. Over time, every BGP-speaking router on the internet builds a table of reachable prefixes and the AS-paths to reach them.

The BGP Decision Process

When a BGP router receives multiple paths to the same destination, it uses a well-defined decision process to select the best one. This is where BGP gets interesting — and where policy comes into play. The decision process evaluates paths in this order:

1. Highest weight (Cisco-specific, local to the router)
2. Highest local preference (shared within the AS)
3. Locally originated routes preferred
4. Shortest AS-path
5. Lowest origin type (IGP < EGP < Incomplete)
6. Lowest MED (Multi-Exit Discriminator)
7. eBGP over iBGP
8. Lowest IGP metric to the next hop
9. Oldest route (for stability)
10. Lowest router ID

I always tell junior engineers to memorize this order. It is the backbone of BGP troubleshooting. When traffic is not taking the path you expect, walking through this decision process step by step will almost always reveal why.

iBGP vs eBGP: Two Sides of the Same Protocol

BGP operates in two distinct modes, and confusing them is a common source of misconfiguration.

External BGP (eBGP)

eBGP is used between routers in different autonomous systems. This is the “classic” BGP use case — peering between ISPs, between an enterprise and its upstream provider, or at internet exchange points. eBGP peers are typically directly connected, and the default TTL for eBGP sessions is 1 (though multihop configurations are possible).

When a route is learned via eBGP, the router modifies the AS-path by prepending its own ASN before advertising the route further. This is the core loop-prevention mechanism: if a router sees its own ASN in the AS-path, it rejects the route.

Internal BGP (iBGP)

iBGP is used between routers within the same autonomous system. This is where things get tricky. iBGP has a critical rule: routes learned from one iBGP peer are not advertised to another iBGP peer. This rule prevents loops within the AS, but it means you need either a full mesh of iBGP sessions or a mechanism like route reflectors or confederations to scale.

In my experience, route reflectors are by far the most common solution. A route reflector is an iBGP peer that relaxes the iBGP split-horizon rule and reflects routes from one client to another. In a typical service provider network, you might have two or three route reflectors serving hundreds of PE routers.

BGP Attributes: The Levers of Traffic Engineering

BGP attributes are the metadata attached to each route, and they are the primary tools for traffic engineering. Let me walk through the ones I use most frequently.

AS-Path

The AS-path is a list of every autonomous system a route has traversed. Beyond loop prevention, it is a powerful traffic engineering tool. By artificially prepending your ASN multiple times (AS-path prepending), you can make a path appear longer and therefore less preferred. I use this regularly to influence inbound traffic — if I want traffic to prefer one upstream link over another, I prepend the AS-path on the less-preferred link.

Local Preference

Local preference is shared among all iBGP peers in an AS and defaults to 100. Higher values are preferred. This is the primary tool for influencing outbound traffic engineering. For example, if your organization has two ISP uplinks and you want to prefer ISP-A for outbound traffic, you set a higher local preference on routes learned from ISP-A.

Multi-Exit Discriminator (MED)

MED is a suggestion to an external neighbor about which entry point into your AS they should prefer. Unlike local preference, MED is communicated between ASes. The catch is that MED comparison only happens between routes received from the same neighboring AS by default, and many providers simply ignore MED from their customers. I have learned to never rely on MED as a sole traffic engineering mechanism.

Communities

BGP communities are tags attached to routes that signal intent to other routers. Standard communities are 32-bit values typically written as ASN:value. For instance, many ISPs use well-known community values like no-export (do not advertise outside the AS) or no-advertise (do not advertise to any peer). Extended and large communities expand on this concept and are increasingly used in modern networks for fine-grained policy control.

Basic Cisco BGP Configuration Example

Let me walk through a practical BGP configuration on a Cisco IOS-XE router. This example sets up eBGP peering with two upstream providers and uses local preference for basic traffic engineering.

! Define our BGP process with our ASN
router bgp 65001

 ! Router ID - use a loopback address for stability
 bgp router-id 10.0.0.1

 ! Neighbor definitions for two upstream providers
 neighbor 203.0.113.1 remote-as 64500
 neighbor 203.0.113.1 description ISP-Alpha-Primary
 neighbor 198.51.100.1 remote-as 64501
 neighbor 198.51.100.1 description ISP-Beta-Secondary

 ! Address family configuration
 address-family ipv4 unicast

  ! Advertise our network
  network 192.0.2.0 mask 255.255.255.0

  ! Apply route maps to influence path selection
  neighbor 203.0.113.1 route-map PREFER-ISP-ALPHA in
  neighbor 198.51.100.1 route-map SET-ISP-BETA in

 exit-address-family

! Route map to set higher local preference for ISP-Alpha
route-map PREFER-ISP-ALPHA permit 10
 set local-preference 200

! Route map for ISP-Beta with default local preference
route-map SET-ISP-BETA permit 10
 set local-preference 100

This configuration tells our router to prefer routes learned from ISP-Alpha (local preference 200) over ISP-Beta (local preference 100) for all outbound traffic. For inbound traffic engineering, you would use AS-path prepending or communities in the outbound route maps — but that is a topic for another post.

Here is a quick verification command to confirm your BGP sessions are established:

show bgp ipv4 unicast summary

Neighbor        V   AS   MsgRcvd  MsgSent  TblVer  Up/Down  State/PfxRcd
203.0.113.1     4   64500  14523    13847   94502   3d02h    125000
198.51.100.1    4   64501  12984    12576   94502   3d02h    122000

Both neighbors show prefix counts instead of a state keyword, which tells me the sessions are established and exchanging routes. If you see states like Idle, Active, or OpenSent, you have a connectivity or configuration problem to debug.

BGP Security: Route Hijacking and RPKI

Here is the uncomfortable truth about BGP: it was designed in an era when the internet was a small, trusted community. BGP has no built-in mechanism to verify that an AS is authorized to advertise a particular prefix. This means any network can, intentionally or accidentally, announce routes for IP space it does not own — and the rest of the internet may believe it.

Route Hijacking

A BGP route hijack occurs when an AS originates a route for address space it is not authorized to announce. If the hijacked route is more specific (a longer prefix) than the legitimate announcement, routers everywhere will prefer it because longest-match wins. This can redirect traffic through the attacker’s network, enabling interception, blackholing, or man-in-the-middle attacks.

Resource Public Key Infrastructure (RPKI)

RPKI is the industry’s primary answer to BGP origin validation. It works through two components:

• Route Origin Authorizations (ROAs): Signed objects created by address space holders that declare which ASN is authorized to originate a specific prefix and the maximum prefix length allowed.
• Route Origin Validation (ROV): The process by which BGP routers check received routes against published ROAs. Routes are classified as Valid, Invalid, or NotFound.

As of March 2026, RPKI adoption has grown significantly. Major cloud providers, tier-1 ISPs, and content networks now perform ROV, and the percentage of prefixes covered by ROAs has crossed the 55% mark globally. I strongly recommend that every organization create ROAs for their address space — even if you are not yet performing validation yourself, you benefit from others validating your routes.

Enabling RPKI validation on a Cisco router looks something like this:

! Configure the RPKI cache server
router bgp 65001
 bgp rpki server tcp 10.0.0.50 port 8282 refresh 600

 address-family ipv4 unicast

  ! Drop routes that fail RPKI validation
  neighbor 203.0.113.1 route-map RPKI-FILTER in

route-map RPKI-FILTER deny 10
 match rpki invalid
route-map RPKI-FILTER permit 20

Other Security Measures

Beyond RPKI, there are additional layers of defense I always implement:

• Prefix filtering: Use IRR (Internet Routing Registry) data to build prefix lists that only accept expected routes from each neighbor.
• Maximum prefix limits: Configure a maximum number of prefixes you will accept from a peer. If the peer suddenly advertises 500,000 routes when you expect 100, the session tears down automatically.
• BGP TTL security (GTSM): Set the TTL to 255 and require received packets to have a TTL of 254 or higher, preventing spoofed BGP packets from remote attackers.
• TCP-AO or MD5 authentication: Authenticate BGP sessions to prevent session hijacking. TCP-AO is the modern replacement for the older MD5 option.

Famous BGP Incidents: Lessons From the Real World

Nothing illustrates why BGP security matters like real-world incidents. Here are a few that I reference whenever someone questions why we invest in BGP security controls.

The Pakistan YouTube Hijack (2008)

When Pakistan Telecom attempted to block YouTube domestically by announcing a more-specific route for YouTube’s IP space, the announcement leaked to upstream providers and propagated globally. YouTube was effectively taken offline worldwide for several hours. This incident is a textbook example of how a localized action can have catastrophic global consequences when BGP lacks origin validation.

The Google Outage via Nigerian ISP (2018)

A small Nigerian ISP accidentally leaked BGP routes that redirected Google traffic through China Telecom’s network. The incident caused significant latency and packet loss for Google services for over an hour. It demonstrated that even the largest tech companies are not immune to the fragility of BGP.

The Rostelecom Hijack (2020)

Russian telecom provider Rostelecom briefly hijacked prefixes belonging to major CDNs and cloud providers, including Akamai, Cloudflare, and Amazon. Whether intentional or accidental, the incident rerouted traffic for some of the internet’s most heavily used services through Russian infrastructure.

The Meta/Facebook Outage (2021)

In October 2021, Facebook (now Meta) suffered a massive outage when a configuration change caused all of their BGP routes to be withdrawn. Every Facebook, Instagram, and WhatsApp service disappeared from the internet simultaneously because no BGP router anywhere knew how to reach Meta’s networks. The outage lasted roughly six hours and cost the company an estimated $100 million in revenue. This remains one of the most vivid demonstrations of BGP’s critical role: withdraw the routes, and you simply cease to exist on the internet.

Why Network Engineers Need to Understand BGP in 2026

If you are working in networking today, here is why BGP expertise is more relevant than ever:

• Multi-cloud networking: Organizations routinely peer with AWS, Azure, and GCP via BGP. Understanding BGP attributes and policy is essential for optimizing cloud connectivity.
• SD-WAN underlay: Many SD-WAN solutions rely on BGP for transport-layer routing. Troubleshooting overlay issues often requires understanding the BGP underlay.
• Segment Routing and SRv6: Modern traffic engineering frameworks like Segment Routing use BGP as a primary distribution mechanism for prefix SIDs and SRv6 locators.
• DDoS mitigation: BGP-based techniques like remotely triggered blackhole (RTBH) filtering and BGP Flowspec are frontline tools for mitigating volumetric DDoS attacks.
• Career advancement: BGP knowledge is a requirement for senior network roles. Every CCIE, JNCIE, and comparable certification tests it extensively.

Getting Started: My Recommendations

If you are new to BGP, here is the learning path I recommend:

1. Build a lab: Use GNS3, EVE-NG, or Containerlab to set up a multi-AS topology. Nothing beats hands-on practice for understanding BGP behavior.
2. Start with eBGP basics: Configure simple peering between two ASes, advertise prefixes, and verify route exchange.
3. Add iBGP: Introduce multiple routers within an AS and work through the full-mesh requirement and route reflectors.
4. Experiment with attributes: Manipulate local preference, AS-path prepending, and MED to see how they affect the best-path decision.
5. Study real-world data: Tools like BGPStream, RIPE RIS, and the RouteViews project let you observe live BGP data from the global routing table.
6. Implement RPKI: Set up a local RPKI validator and practice origin validation in your lab environment.

Wrapping Up

BGP is often called the “duct tape” of the internet, and I think that undersells it. It is more like the highway system — an engineered infrastructure that routes traffic between independent jurisdictions according to policy, economics, and technical constraints. It is imperfect and sometimes fragile, but it has scaled from a few hundred networks in the early 1990s to the vast interconnected system we rely on today.

Understanding BGP is not optional for anyone serious about networking. The protocol’s concepts — autonomous systems, path selection, policy-based routing, and security validation — are foundational to how the modern internet operates. Whether you are configuring a simple eBGP peering session or designing a multi-region traffic engineering strategy, the principles are the same.

I will be following up this post with a deeper look at BGP traffic engineering techniques and advanced RPKI deployment. If you have questions or want to see a specific BGP topic covered, drop a comment below.

Sarah Chen is a senior network engineer and contributor to IGNA Online. She specializes in service provider architectures, routing protocol design, and network security.