What Is BGP? Border Gateway Protocol — The Complete Guide

Border Gateway Protocol (BGP) is the routing protocol that holds the Internet together. Every time a packet crosses from one provider's network to another — from your ISP to a content network, from a data center to a cloud region — BGP decided the path it took. Think of it as the postal service of the Internet: it does not carry the packets itself, but it tells every network how to reach every other network.

This guide is the starting point for everything BGP on this site. It explains what BGP is and why it exists, how sessions and route advertisement work, how the best-path algorithm thinks, and how operators use BGP for traffic engineering, scaling, and security. Every major subtopic links to a deeper article, so you can read this page top to bottom and branch out wherever you need more detail.

What Is BGP and Why Does It Exist?

BGP is a path-vector routing protocol used to exchange routing and reachability information between autonomous systems — the independently operated networks that make up the Internet. Instead of measuring link cost the way interior protocols do, BGP records the list of autonomous systems a route has traveled through (the AS path) and applies policy on top of it. The AS path doubles as loop prevention: if a router sees its own AS number in a received path, it rejects the route.

That design is what lets tens of thousands of independent networks, each with its own commercial interests, agree on how traffic should flow — without sharing any internal topology with each other.

Autonomous Systems and AS Numbers

An autonomous system (AS) is a network under a single administrative control — an ISP, a large enterprise, a cloud provider — identified by an AS number (ASN). Like IP addresses, ASNs come in public and private ranges: public ASNs are globally unique and appear on the Internet, while private ASNs are reserved for internal arrangements such as a customer connecting to a single provider. The full breakdown of the ranges, including 4-byte ASNs, is in BGP private and public AS ranges, and there is a step-by-step guide to configuring BGP with private AS numbers.

IGP vs BGP: Two Different Jobs

BGP does not replace OSPF, IS-IS, or EIGRP — it does a different job. Interior gateway protocols (IGPs) give routers inside one network reachability to each other; BGP carries the routes that represent services and customers. Three differences matter most, and they are unpacked in IGP vs BGP explained:

• Scale. The full Internet routing table carries roughly a million IPv4 prefixes. A well-designed IGP starts struggling at a few tens of thousands. BGP is the most scalable routing protocol we have.
• Policy. BGP can steer traffic in both directions using attributes such as local preference, AS path, and communities. IGPs mostly follow bandwidth-based metrics and can only influence outbound traffic.
• Multiprotocol. Through MP-BGP, one protocol carries IPv4, IPv6, VPN, and EVPN reachability side by side. IGPs stay in the IPv4/IPv6 unicast lane.

In practice the two work as a team: the IGP provides the underlay (infrastructure reachability), and BGP provides the service layer on top. For a protocol-by-protocol comparison, see the OSPF vs EIGRP vs BGP cheat sheet and the scalability-focused IS-IS vs BGP comparison.

How BGP Works

A TCP Session on Port 179

Unlike most routing protocols, BGP does not discover neighbors and does not use its own transport. Two routers form an explicit, point-to-point session over TCP port 179. Running on TCP gives BGP reliable, ordered delivery — retransmission, error checking, and congestion control come for free — which matters when the updates being exchanged shape routing for the whole Internet. The reasoning behind the port choice and its security implications are covered in what port BGP uses and why, and there is a practical companion on configuring BGP ports. One operational consequence to remember: if a firewall or ACL blocks TCP 179 between two peers, the session will never establish.

Neighbors and the BGP State Machine

A BGP neighbor (or peer) is simply another router you have configured a session with — matching IP addresses, matching expectations about AS numbers, and optionally authentication. Before any routes move, the session walks through the states of the BGP finite state machine:

1. Idle — the starting point; BGP is ready but nothing has happened yet.
2. Connect — BGP initiates the TCP three-way handshake. If it completes, an OPEN message is sent.
3. Active — the connect attempt timed out and BGP is retrying the TCP connection.
4. OpenSent — the OPEN message has been sent; the router waits for the reply.
5. OpenConfirm — both sides have exchanged OPEN messages and agreed to peer.
6. Established — the session is up and the routers exchange routes and keepalives.

A session bouncing between Idle, Connect, and Active is the classic sign of a reachability or configuration problem. Each state is explained in more depth in the quick guide to BGP neighbors. During session setup each router also identifies itself with a router ID — a small detail with real operational impact, covered in choosing the right BGP router ID.

Route Advertisement and Filtering

Once a session is Established, each router advertises routes to its neighbor: the destination prefix plus the attributes that describe the path. Each BGP router keeps a table of the destinations it knows, advertises its own best routes, and learns routes from its peers — this constant exchange is what keeps the Internet's map current. The mechanics, including conditional advertisement (advertising a route only when certain conditions hold), are covered in BGP route advertisement.

Just as important as what you advertise is what you accept. Operators filter routes in both directions to protect themselves from faulty or malicious announcements — using BGP prefix lists to match on destinations, and community values to group and filter routes as a unit. If you have never configured any of this, the step-by-step BGP configuration guide walks through a first working setup.

eBGP vs iBGP

BGP has one protocol but two personalities. External BGP (eBGP) runs between routers in different autonomous systems — it is how your network talks to your providers, customers, and peers. Internal BGP (iBGP) runs between routers inside the same AS — it is how BGP routes learned at one edge of your network reach the other edge. The full comparison lives in eBGP vs iBGP; the essentials are these:

• Loop prevention differs. eBGP prepends the AS number at every AS boundary, so a router can spot and reject its own AS in the path. iBGP does not change the AS path inside the AS, so it needs a different rule: a route learned from one iBGP peer is never re-advertised to another iBGP peer. That rule — BGP's version of split horizon, contrasted with distance-vector techniques in split horizon vs route poisoning — is exactly why iBGP traditionally requires a full mesh of sessions, while eBGP does not.
• Next-hop handling differs. When a route crosses an eBGP session the next hop is updated; over iBGP it is left unchanged by default. That default regularly breaks reachability inside the AS, which is why the next-hop-self knob exists — the trade-offs are explained in next-hop-self vs next-hop unchanged.
• Peering assumptions differ. eBGP peers are normally directly connected; when they are not — say, loopback-to-loopback peering across several hops — you need eBGP multihop.

Two edge-case features round this out, both common in provider networks: when two customer sites reuse the same AS number across an MPLS VPN, the AS-path loop check would normally reject the routes. The allowas-in feature relaxes the check on the receiving side, and AS override rewrites the customer AS on the provider side.

How BGP Chooses the Best Path

A BGP router often learns the same prefix from several neighbors, and by default it must pick exactly one best path. It does not compare bandwidth or delay — it compares attributes, in a strict order, and the first tie-breaker that differs decides. On Cisco routers the sequence starts like this:

1. Highest weight — Cisco-proprietary, significant only on the local router.
2. Highest local preference — shared across the whole AS; the main tool for choosing exit points.
3. Locally originated routes — prefer routes this router injected itself.
4. Shortest AS path — fewer autonomous systems wins.
5. Lowest origin code — IGP-originated beats incomplete.
6. Lowest MED — the neighboring AS's hint about its preferred entry point.
7. eBGP over iBGP, then the path with the lowest IGP metric to the next hop, and finally tie-breakers such as the oldest path and lowest router ID.

The condensed version of this list, with the logic behind each step, is in the BGP path selection quick guide. In day-to-day work, the first two steps do most of the heavy lifting, and they are easy to confuse:

• Weight is local to one router, is checked first, and the highest value wins. It never leaves the box, which makes it ideal for router-specific tweaks and testing. Start with understanding BGP weight.
• Local preference is carried to every router in the AS (default 100, highest wins) and steers where outbound traffic exits the network as a matter of policy. The side-by-side comparison is in BGP weight vs local preference.

MED (Multi-Exit Discriminator) points the other way: it is how your AS tells a directly connected neighbor which of several entry points into your network you would prefer, with the lowest value winning. It is useful when you connect to the same neighbor in multiple locations with different capacities — and easy to misuse, as the BGP MED attribute guide explains. A related but distinct attribute, AIGP, lets networks under one administration carry an accumulated IGP metric across AS boundaries. And when you genuinely want more than one best path — for load sharing across equal candidates — BGP multipath relaxes the single-winner rule.

Traffic Engineering with BGP

Path selection is also the lever you pull to engineer traffic. The direction determines the tool: outbound traffic is yours to control with local preference and weight, but inbound traffic is decided by other networks — so all you can do is influence their selection process.

The most common inbound technique is AS path prepending: when advertising a prefix over the link you want as backup, you add your own AS number to the path several extra times, making that path look longer so the remote AS prefers the other one. It works — until it doesn't. If the upstream network has already set a higher local preference on the path you are trying to demote, your prepending is invisible to its decision, because local preference is compared before AS path length. Excessive prepending also gets filtered by many networks and enlarges your exposure to prefix hijacks, so use it in moderation.

When prepending cannot express your intent, BGP communities usually can. A community is a tag carried with a route; providers publish lists of action communities that let customers request behavior on the provider side — lower the local preference, prepend on their edge, or blackhole a prefix — without any manual coordination. Between local preference, MED, prepending, and communities, you can shape almost any traffic pattern. Building these policies hands-on is the fastest way to internalize them, and Russ White's BGP Zero to Hero course does exactly that, from first session to full policy design.

Scaling BGP Inside an AS

Remember the iBGP rule: routes learned from one iBGP peer are not passed to another. The textbook fix is a full mesh of iBGP sessions, but a full mesh grows as n(n−1)/2 — at 50 routers that is already 1,225 sessions. Real networks scale iBGP with one of two tools.

Route reflectors (RRs) are the dominant answer. A route reflector is an iBGP router allowed to break the rule in a controlled way: it reflects routes between its clients, so every router only needs sessions to the reflectors instead of to everyone. Reflectors and their clients form clusters, and running multiple route reflectors removes the single point of failure. How clusters, cluster IDs, and redundancy fit together is covered in BGP route reflector clusters, and the design trade-off against a mesh is weighed in route reflectors vs full mesh. One caveat: because the reflector picks the best path from its own viewpoint, clients can end up with suboptimal exits — the problem that BGP Optimal Route Reflection (ORR) was designed to solve.

Confederations take the other approach: split one large AS into several sub-ASes that run eBGP-like sessions between them, while still appearing as a single AS to the outside. They appear mostly in older or very large service provider designs. The concept is introduced in BGP confederation fundamentals, with a practical follow-up on configuring BGP confederation on Cisco routers.

BGP Beyond the Internet: MP-BGP, VPNs, and Peering

Classic BGP carried only IPv4 unicast routes. MP-BGP (Multiprotocol BGP), defined in RFC 4760, extends the protocol with address family identifiers (AFI/SAFI) so a single session can carry more than 15 different kinds of reachability in parallel: IPv4 and IPv6, unicast and multicast, MPLS L3 VPN (VPNv4), and EVPN — where BGP even carries MAC addresses between data center switches. This is why BGP long ago outgrew "the Internet protocol" label: it is the control plane of MPLS VPNs, data center fabrics, and countless overlay technologies. The full picture, including the SAFI registry, is in what is MP-BGP.

Two operational details are worth pulling out. First, address families are negotiated in the OPEN message when the session comes up — activating a new family later (say, adding VPNv4 with address-family vpnv4 and neighbor x.x.x.x activate) resets the session, so plan for a maintenance window. Second, VPN families rely on extended communities such as route targets, which is why the neighbor x.x.x.x send-community extended knob matters. A close relative, BGP Labeled Unicast (BGP-LU), attaches MPLS labels directly to prefixes and is a staple of seamless MPLS designs.

On the Internet side, most organizations meet BGP through multihoming — connecting to two or more providers so that one failure does not take the business offline. Content and access networks also interconnect directly at Internet exchange points, either through bilateral or multilateral peering; at large exchanges, a BGP route server plays a role similar to a route reflector, letting hundreds of members peer through one session instead of hundreds.

BGP Security

BGP was designed on an assumption of trust, and that assumption is its biggest weakness. In a BGP hijack, an attacker announces prefixes — or forges a shorter AS path to them — and pulls traffic toward their own network to intercept or drop it. Defenses are layered: strict route filtering at every boundary, session monitoring, RPKI to cryptographically validate which AS may originate a prefix, and ASPA (Autonomous System Provider Authorization) to validate the provider relationships in the path itself.

BGP is also part of the defense toolkit. BGP Flowspec distributes fine-grained filtering rules — matching on ports, protocols, and packet properties — to every edge router in seconds, which makes it a powerful weapon against DDoS attacks. Its blunter cousin, remotely triggered blackholing (RTBH), uses a trigger route to drop all traffic to a victim prefix at the network edge before it can saturate links.

Advanced BGP: A Quick Tour

A few more topics show up as networks and expectations grow. Each gets a short introduction here and a full article behind the link:

• BGP-LS (Link State) exports the IGP's topology database through BGP, giving central controllers and path computation engines a live view of the network — the foundation of modern traffic-engineering automation.
• BGP PIC (Prefix Independent Convergence) pre-installs backup paths so that when a link or neighbor fails, traffic switches over in a time that does not depend on how many prefixes are affected — crucial when a table holds hundreds of thousands of routes.
• BGP graceful restart lets a router keep forwarding traffic while its BGP process restarts, so a control-plane hiccup does not become a data-plane outage.

Troubleshooting BGP

Most BGP problems fall into three buckets, all covered in depth in BGP troubleshooting: most common errors:

• Sessions that will not establish. Usually a configuration mismatch — wrong neighbor IP or AS number, missing route to the peer, or TCP 179 blocked by a firewall. The state machine tells the story: stuck in Active means the TCP connection is not completing. show ip bgp summary and show ip bgp neighbors are the first two commands to reach for.
• Route flapping. A route that keeps switching between up and down destabilizes far more than one session, because every change ripples to every peer. Faulty hardware, unstable links, and misconfigured filters are the usual suspects — the diagnosis workflow is in what is BGP flapping.
• Routes that arrive but do not work. A RIB failure means BGP learned a route but could not install it in the routing table; an invalid next hop has a similar effect. Check the next hop, the attributes, and whether at least one neighbor is actually advertising the prefix.

For problems visible from the outside — "is the world seeing my prefix the way I intended?" — external looking-glass and BGP lookup tools show your announcements from other networks' perspectives, which is also your early-warning system for hijacks.

Where to Go Next: A BGP Learning Path

BGP rewards structured learning: each layer builds on the previous one. A path that works for most engineers:

1. Fundamentals — this guide, then the BGP fundamentals refresher to make sure the basics are solid.
2. Hands-on — configure sessions, advertise prefixes, and break things in a lab until the state machine and best-path logic feel natural.
3. Policy and design — attributes, filtering, route reflectors, and traffic engineering on real topologies.
4. Service provider topics — MP-BGP, VPNs, and Internet-scale operations.

To go deeper on your own, there is a curated list of the best BGP books and a roundup of free BGP learning resources; if a job interview is on the horizon, the top 30 BGP interview questions make a solid self-test.

And when you are ready to learn BGP systematically — from the first neighbor statement to service provider design — the Self-Paced BGP Training covers the entire journey in one place, at your own pace.