BGP Explained — How the Internet's Routing Protocol Works

Every time you load a website, packets cross several networks run by different companies, and something has to tell each of them where to send the traffic next. Inside a company that is the job of an interior protocol such as OSPF or EIGRP. Between companies, it is BGP. This guide explains how BGP works from first principles, with the configuration, the best-path rules, the incidents that taught the industry its lessons, and an honest look at how much of it you need for CCNA. This page is about the exterior, policy-driven side of routing; for the interior link-state protocol that most CCNA candidates must configure, read OSPF explained.

What is BGP and why does the internet need it?

The internet is not one network; it is tens of thousands of independently run networks (ISPs, cloud providers, enterprises, universities) that agree to exchange traffic. BGP-4, specified in RFC 4271, is the protocol they use to tell each other which IP prefixes they can reach. Multiprotocol BGP (RFC 4760) extends it to carry IPv6 and other address families, which is how the same protocol carries both IPv4 and IPv6 routes.

BGP is different from the protocols you meet first in three ways:

• Path vector, not distance vector or link state. A BGP route is a prefix plus the ordered list of autonomous systems it has passed through (the AS_PATH). A router that sees its own AS in the path rejects the route, which is how BGP prevents loops without a topology map.
• Policy first, speed second. BGP does not look for the fastest path. Businesses decide which neighbor to prefer for commercial and technical reasons, and BGP attributes let them express that.
• Built for scale and stability. It sends incremental updates only when something changes, rides on TCP for reliability, and is designed to carry the global routing table, which is roughly a million IPv4 prefixes plus hundreds of thousands of IPv6 prefixes (the numbers keep growing).

Neighbors are configured manually; BGP does not discover them with multicast hellos as OSPF does. Two routers become BGP peers (neighbors) only when both sides are configured to expect the other and a TCP connection on port 179 succeeds. See our TCP vs UDP guide for why that transport choice matters.

What are autonomous systems and ASNs?

An autonomous system (AS) is a collection of IP prefixes and routers under one administrative control with a single, clearly defined routing policy toward the outside. Each AS has an autonomous system number (ASN). ASNs were originally 16 bits; because those ran short, 32-bit ASNs were introduced (RFC 6793). Public ASNs are allocated by the regional internet registries from blocks managed by IANA, and the IANA AS Numbers registry is the authoritative list.

The rest of the 32-bit space is public or reserved according to the IANA registry; consult it for current allocations rather than relying on a table. Private ASNs are used by customers that peer with a single provider or in labs and internal networks, and the provider normally strips them before advertising to the internet. This article's examples use the documentation ASNs 64496 and 64497 so they cannot collide with a real network. ASNs are written in asplain (a single decimal number) or asdot notation (high.low); Cisco IOS accepts both.

What is the difference between eBGP and iBGP?

The last row is the single most important iBGP rule. Inside an AS the AS_PATH is unchanged, so BGP cannot see a loop; instead it forbids re-advertising iBGP-learned routes to other iBGP peers. The consequence is that every iBGP router must peer with every other (a full mesh, with n(n-1)/2 sessions), or you use route reflectors (RFC 4456) or confederations to avoid the mesh. A second consequence is that iBGP depends on an IGP: BGP carries the external prefixes, and OSPF or another IGP provides the internal reachability to the next hops. If a route is in the BGP table but unusable, the first thing to check is whether the next hop is reachable.

What are the BGP messages and timers?

BGP uses five messages: OPEN, UPDATE, KEEPALIVE, NOTIFICATION and ROUTE-REFRESH. On Cisco IOS the keepalive is 60 seconds and the hold time is 180 seconds by default.

On Cisco IOS the defaults are a keepalive of 60 seconds and a hold time of 180 seconds; peers negotiate the lower of the two hold times, and a session drops if nothing is heard within it. RFC 4271 suggests a 90-second hold time, so check your vendor's defaults. Unlike RIP, BGP does not resend its table periodically: after the initial exchange, only changes are sent.

What are the BGP neighbor states?

BGP uses a finite state machine, and exam questions and troubleshooting both rely on knowing it:

The classic exam trap: Active does not mean working. It means the router is still trying to connect. Only Established means routes can be exchanged.

What are BGP path attributes?

Attributes are the metadata attached to each prefix, and they are BGP's way of making policy decisions. Attributes fall into four categories:

• AS_PATH: the ordered list of ASNs the route crossed. Shorter is preferred; also the loop-prevention mechanism. AS-path prepending (adding your own ASN repeatedly) makes a path look longer to influence inbound traffic.
• NEXT_HOP: the IP address to forward to. Changes at eBGP boundaries; must be reachable.
• ORIGIN: how the route entered BGP: IGP (network statement), EGP, or incomplete (redistributed).
• LOCAL_PREF: shared inside an AS to choose the preferred exit. Higher wins; Cisco default is 100.
• MED: a hint sent to a neighboring AS about the preferred entry point. Lower wins, and it is normally compared only between paths from the same neighboring AS.
• COMMUNITY: tags for grouping routes so policies can act on them.
• Weight: a Cisco-proprietary, router-local value. Higher wins and it is never advertised.

How does BGP choose the best path?

When a router has more than one valid path to the same prefix, it runs a fixed decision process and installs one best path. On Cisco IOS it prefers the highest Weight, then the highest Local Preference, then locally originated routes, then the shortest AS_PATH, the lowest origin type, the lowest MED, eBGP over iBGP and the lowest IGP metric to the next hop, before falling back to tie-breakers such as the lowest router ID. Weight is Cisco-specific and is not in RFC 4271. In short, the early rules express policy you control and the later rules judge path quality. The full order (from Cisco's best-path documentation) is:

Standard BGP (RFC 4271) describes a similar process but without Weight: degree of preference (Local Preference), shortest AS_PATH, lowest origin, lowest MED, eBGP over iBGP, lowest IGP cost to the next hop, then lowest BGP identifier and lowest peer address. Other vendors add their own attributes or tie-breakers, so treat the order above as the Cisco IOS order. The memory aid is to remember that the early rules are about policy you control (weight, local preference, origination) and the later ones are about path quality and tie-breaking. The step most often examined is the first few: Weight beats Local Preference, which beats AS_PATH length, even if that means a longer path wins.

Check yourself

How do you configure and verify BGP on Cisco IOS?

Enable BGP with router bgp <ASN>, define each peer with neighbor <ip> remote-as <ASN>, activate it in the address family, and advertise prefixes with network; then check the session with show ip bgp summary. Example topology: two routers, R1 in AS 64496 and R2 in AS 64497, share the link 203.0.113.0/30 (R1 is .1, R2 is .2). R1 advertises 198.51.100.0/24 and R2 advertises 192.0.2.0/24 (all documentation ranges). This is R1:

R1(config)# router bgp 64496
R1(config-router)# bgp router-id 1.1.1.1
R1(config-router)# neighbor 203.0.113.2 remote-as 64497
R1(config-router)# address-family ipv4 unicast
R1(config-router-af)# neighbor 203.0.113.2 activate
R1(config-router-af)# network 198.51.100.0 mask 255.255.255.0

R2 mirrors it with router bgp 64497, neighbor 203.0.113.1 remote-as 64496 and its own network statement. Three details matter. remote-as defines the relationship: a different ASN means eBGP, the same ASN means iBGP. The network statement does not enable BGP on an interface the way it does in OSPF; it tells BGP to advertise a prefix, and the exact prefix and mask must already exist in the routing table. And on iBGP sessions between loopbacks you will usually add neighbor x.x.x.x update-source Loopback0 and, for routes learned from eBGP, neighbor x.x.x.x next-hop-self.

Verify with the summary first:

R1# show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 64496
Neighbor        V    AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down  State/PfxRcd
203.0.113.2     4 64497      15      16      3   0    0 00:10:02          1

R1# show ip bgp
   Network          Next Hop        Metric LocPrf Weight Path
*> 192.0.2.0/24     203.0.113.2          0             0 64497 i
*> 198.51.100.0/24  0.0.0.0              0         32768 i

(Output is illustrative and abbreviated.) In the summary, a number in the State/PfxRcd column means the session is Established and shows how many prefixes were received; a word such as Idle or Active means it is not up. In the table, * means valid and > marks the best path; the i at the end of the path is the origin code (IGP), and Weight 32768 is the default for locally originated routes. Other useful commands are show ip bgp neighbors (state, timers, capabilities, error history), show ip route bgp and clear ip bgp * soft to re-apply policy without dropping sessions.

The usual reasons a session will not establish, in order of likelihood:

• No IP reachability to the neighbor address, or the neighbor address configured on only one side.
• Wrong remote-as on either side (the OPEN message is rejected).
• TCP 179 blocked by an access list or firewall.
• eBGP neighbors that are not directly connected without ebgp-multihop (default TTL 1).
• Loopback peering without update-source, so the source address does not match what the neighbor expects.
• Authentication (MD5 password) mismatch.

What do real-world BGP incidents teach?

BGP is built on trust: by default a router believes what its neighbor announces. That makes mistakes, and attacks, propagate quickly. Two incidents are well documented and worth knowing as concepts.

• The 2008 YouTube hijack. In February 2008 Pakistan Telecom originated a more-specific prefix for part of YouTube's address space, apparently to block the site locally. The announcement leaked to the wider internet through an upstream provider, and because routers prefer the longest matching prefix, traffic for YouTube was drawn toward Pakistan for about two hours. The RIPE NCC published an analysis of the event (linked below). Lesson: a more-specific prefix wins, and providers must filter what customers are allowed to announce.
• The October 2021 Facebook outage. Facebook's own engineering write-up (linked below) explains that a configuration change during backbone maintenance disconnected its data centers, and its DNS servers, designed to withdraw their BGP advertisements when they cannot reach the data centers, did so. With the routes to the DNS servers withdrawn, the company's domains stopped resolving and its services were unreachable for hours. Lesson: BGP and DNS dependencies matter, and out-of-band access to your own routers is essential.

The common thread is that BGP does not check whether an announcement is legitimate. Withdrawing a route is as powerful as adding one.

How is BGP secured?

BGP has no built-in check that an announcement is legitimate, so security is layered: prefix filters, maximum-prefix limits, session protection and RPKI origin validation.

Because BGP trusts announcements, operators layer protections on top. RFC 7454 (BGP Operations and Security) documents the baseline practices; the important ones are:

• Prefix filtering: accept from each customer only the prefixes they are entitled to announce, and do not announce what you should not (for example your own private ranges, or other providers' routes).
• Maximum-prefix limits: shut or warn on a session if a peer suddenly sends far more routes than expected.
• Session protection: TCP MD5 or TCP-AO authentication and limiting who can reach TCP 179, plus TTL-based protection for directly connected eBGP.
• Origin validation (RPKI): signed Route Origin Authorizations let routers check that an AS is authorized to originate a prefix (RFC 6811). It protects against accidental origin mistakes but does not validate the entire path.
• Default policy: RFC 8212 says an eBGP session with no configured policy should accept and advertise nothing, so a new session cannot leak by accident. Some platforms implement this by default; check yours.

BGP vs OSPF vs EIGRP: how do they compare?

BGP is the exterior, policy-based path-vector protocol used between autonomous systems (AD 20 for eBGP, 200 for iBGP), while OSPF and EIGRP are interior protocols that pick the lowest-cost path inside one organization. They are used together, not as alternatives.

They are complementary, not competing. A typical enterprise runs an IGP internally and BGP at the edge to the ISPs, and the IGP and BGP are connected through redistribution or network statements. Large data centers also use BGP internally; see how that fits the spine-leaf fabric underlay. For the older protocol on this list, read about RIP.

Is BGP on the CCNA and Network+ exams?

Only lightly: BGP is a concept-level topic on both exams and is not a CCNA configuration objective in the topics we reviewed. Confirm against the current objectives.

Honest answer: only lightly. Cisco CCNA 200-301 concentrates its routing objectives on static routing, reading the routing table, administrative distance, metric and longest-prefix match, and OSPFv2; BGP configuration is not one of them in the exam topics we reviewed. You can reasonably meet BGP as a distractor, as the answer to “which protocol exchanges routes between autonomous systems”, or in an administrative distance table (eBGP 20, iBGP 200). Where BGP is examined in depth is CCNP Enterprise (the ENCOR core exam and the ENARSI concentration), and in real work at an ISP, a cloud provider or any multi-homed network. CompTIA Network+ N10-009 expects you to recognize BGP as the dynamic routing protocol used between autonomous systems, as part of its routing coverage. Exam blueprints change, so verify on the official CCNA exam topics and the CompTIA Network+ page.

Do not skip BGP entirely if you want a networking career, but for CCNA focus your time where the points are:

• OSPF first: read our OSPF guide, then HSRP and Spanning Tree.
• Know the one-line BGP facts: path vector, TCP 179, between autonomous systems, eBGP 20 and iBGP 200.
• See the full domain map in the CCNA exam guide and the CCNA cheat sheet.

BGP practice questions with answers

Try each one before opening the answer. For exam-style routing scenarios, use the CCNA practice exam or the CCNA practice questions.

Frequently asked questions

How we wrote and checked this

CertSharp is a practice-exam provider, so we have a commercial interest in exam preparation. This guide was built from RFC 4271 and the related RFCs, the Cisco best-path documentation, and the RIPE NCC and Meta engineering write-ups linked below. The configuration follows Cisco IOS syntax from vendor documentation and the show output is illustrative, not captured from production equipment. Last reviewed on October 18, 2026. Exam objectives change, so confirm them on the Cisco and CompTIA pages.

Sources and further reading

• RFC 4271: A Border Gateway Protocol 4 (BGP-4)
• RFC 4760: Multiprotocol Extensions for BGP-4
• RFC 7454: BGP Operations and Security
• RFC 6793: BGP Support for Four-Octet AS Numbers
• RFC 6996: Autonomous System (AS) Reservation for Private Use
• RFC 4456: BGP Route Reflection
• RFC 6811: BGP Prefix Origin Validation
• RFC 8212: Default External BGP Route Propagation Behavior without Policies
• IANA: Autonomous System (AS) Numbers registry
• Cisco: Select BGP Best-path Algorithm
• RIPE NCC: YouTube Hijacking, a RIPE NCC RIS Case Study
• Engineering at Meta: More details about the October 4 outage
• Cisco Learning Network: CCNA 200-301 exam topics