Learning Byte 001: BGP Fundamentals

Introduction

BGP is often introduced through definitions, path attributes, and configuration commands. Those pieces matter, but they become easier to understand once the protocol can be observed moving a real route from one autonomous system to another.

This Learning Byte uses a four-router Cisco IOS topology as a reference while introducing the foundations of BGP. Each router belongs to a separate autonomous system, with AS 65001 representing the network under our control and the remaining routers representing external routing domains. The topology will become the foundation for the hands-on labs that follow later in the series.

The aim is not to cover every BGP feature in one article. Route origination, path selection, policy, aggregation, iBGP scaling, and multiprotocol BGP each deserve room of their own. This first lesson focuses on the protocol foundations needed before those topics can be explored in the lab: autonomous systems, neighbor relationships, session establishment, BGP messages, path information, and loop prevention.

Protocol behavior is grounded in the BGP-4 specification, while Cisco-specific terminology and defaults are identified as implementation details rather than universal properties of BGP.

What This Learning Byte Covers

This Learning Byte introduces the foundational behavior behind BGP using a four-router eBGP topology as a reference.

By the end of the article, the reader should be able to:

• Explain the role of BGP between autonomous systems
• Describe autonomous systems and the purpose of autonomous system numbers
• Distinguish eBGP from iBGP
• Describe how BGP peers communicate over TCP port 179
• Identify the primary BGP message types
• Recognize the six BGP neighbor states
• Explain how BGP advertises reachability together with path information
• Describe how AS_PATH records a route’s inter-AS path
• Explain how AS_PATH helps prevent inter-AS routing loops

This first lesson stays focused on foundational behavior. Route policy, advanced best-path manipulation, aggregation, iBGP scaling, and multiprotocol BGP will be handled separately later in the series.

Reference Topology

The examples throughout this series use four Cisco routers arranged in a diamond topology. Each router belongs to a separate private autonomous system, creating two possible paths between AS 65001 and AS 65003.

AS 65001 represents the network under our control, while the remaining autonomous systems represent external routing domains. This design gives later labs a simple way to observe eBGP peering, route propagation, multiple AS paths, loop prevention, and path selection.

No IGP is required for the initial topology because each eBGP neighbor is directly connected.

Why BGP Exists

An interior gateway protocol such as OSPF or EIGRP is designed to calculate reachability inside a single administrative domain. BGP solves a different problem: exchanging reachability information between autonomous systems that may be operated by different organizations and governed by different routing policies.

BGP does not attempt to build a complete map of every link in the network. Instead, it advertises destinations together with information about the path used to reach them. That path information allows each autonomous system to make policy decisions about which routes to accept, prefer, or advertise onward.

RFC 4271 describes BGP as an inter-autonomous system routing protocol whose primary function is to exchange network reachability information, including the list of autonomous systems that the information has traversed. That information is enough to support policy decisions and detect routing loops at the AS level.

This distinction is what makes BGP useful at the edge of a network. The shortest path is not always the preferred path. An organization may choose one provider over another because of cost, capacity, geography, contractual requirements, or traffic-engineering goals. BGP provides the attributes and policy controls needed to make those decisions.

In the reference topology, each router represents a separate autonomous system. The purpose is not to recreate the Internet, but to make BGP’s basic behavior visible: establish a session, advertise a prefix, carry path information across multiple ASes, and reject a route when its path would create a loop.

Autonomous Systems and AS Numbers

An autonomous system is a collection of networks and routers operated under a common administrative policy. To the rest of the Internet, that system presents a consistent view of which destinations it can reach and how external traffic should enter or leave its network.

Each autonomous system is identified by an autonomous system number, or ASN. BGP uses these numbers to identify neighboring routing domains and to record the path a route has taken between them.

The original BGP specification used a 16-bit ASN field, creating a numeric space from 0 through 65,535. As the number of participating networks grew, BGP was extended to support four-octet ASNs, expanding the available space to 32 bits. Modern BGP implementations can therefore use ASNs from both the original two-octet space and the extended four-octet space.

Public and Private ASNs

Public ASNs are globally unique and are assigned to organizations that need to exchange routes across the public Internet. IANA coordinates the global ASN space, while individual assignments are generally issued through the appropriate regional Internet registry.

Private ASNs do not need to be globally unique. They are commonly used in private BGP deployments, internal network designs, and lab environments.

A small number of values and subranges within the broader public spaces are reserved for documentation, compatibility, or other special purposes. The IANA ASN registry is the authoritative reference when validating a specific ASN.

RFC 6996 reserves the two private ranges shown above. Private ASNs are generally removed from the AS_PATH before routes are advertised to the global Internet.

This lab uses AS 65001 through AS 65004. AS 65001 represents the routing domain under our control, while the other private ASNs represent external networks.

eBGP and iBGP Session Types

BGP sessions are classified according to the autonomous systems of the two peers:

• External BGP (eBGP): the peers belong to different autonomous systems.
• Internal BGP (iBGP): the peers belong to the same autonomous system.

The message types and underlying TCP transport are the same in both cases, but the rules used to advertise and process routes differ.

RFC 4271 defines an external peer as a BGP speaker in a different autonomous system and an internal peer as a BGP speaker in the same autonomous system. The transport and message types are the same in both cases; the important differences appear in how routes are propagated and interpreted.

In the reference topology, every planned BGP session is eBGP because each directly connected router belongs to a different AS.That keeps the first exercise focused on inter-AS behavior: establishing peers, advertising prefixes, watching the AS_PATH grow, and observing how BGP prevents a route from returning to its originating AS.

iBGP solves a different problem. It carries BGP reachability and policy information across routers inside the same autonomous system. It does not replace an IGP, because the BGP speakers and advertised next hops still need underlying IP reachability.

One iBGP rule is especially important: a route learned from one iBGP peer is not advertised to another iBGP peer by default. That behavior creates a full-mesh requirement unless route reflectors or confederations are introduced. Those topics deserve a separate lab and will be covered later in the series.

Cisco note: IOS uses a default administrative distance of 20 for eBGP routes and 200 for iBGP routes. Administrative distance is a local Cisco preference value, not part of the BGP protocol itself.

How BGP Neighbors Communicate

BGP peers do not discover one another automatically. Each neighbor is configured explicitly by IP address, and the routers must already have IP reachability to one another before a BGP session can form.

BGP uses TCP port 179 for transport. TCP provides sequencing, acknowledgments, retransmission, and reliable delivery, allowing BGP to focus on exchanging routing information rather than implementing those functions itself.

A directly connected eBGP session usually relies on the connected route between the two peers. A multihop session requires an existing route to the neighbor address, whether that route comes from a static route, an IGP, or another source.

The important sequence is:

1. The routers establish a TCP connection.
2. BGP exchanges session parameters.
3. The peers confirm the session.
4. Routing updates can be exchanged.

A successful ping to the neighbor proves IP reachability, but it does not prove that BGP is operational. TCP port 179 must also be reachable, the configured neighbor addresses must match, and both routers must agree on the expected autonomous system numbers.

BGP Message Types

Once the TCP connection is established, BGP uses a small set of message types to negotiate the session, exchange routes, maintain reachability, and report errors.

RFC 4271 defines the first four messages as part of base BGP-4. Route Refresh was added through a later extension and is negotiated as a BGP capability.

Type	Message	Purpose
1	OPEN	Starts the BGP session and exchanges parameters such as the BGP version, ASN, hold time, BGP identifier, and supported capabilities
2	UPDATE	Advertises new routes, replaces existing routes, or withdraws routes that are no longer reachable
3	NOTIFICATION	Reports an error or administrative shutdown condition and closes the BGP session
4	KEEPALIVE	Confirms that the peer remains reachable and prevents the negotiated hold timer from expiring
5	ROUTE-REFRESH	Requests that a peer resend routing information after a policy change without resetting the session

How the Messages Fit Together

The initial exchange ties the BGP message types directly to the session state machine:

1. The peers establish a TCP connection.
2. Each router sends an OPEN message and enters the OpenSent state.
3. Each router validates the received OPEN parameters, including the BGP version, peer ASN, hold time, BGP identifier, and negotiated capabilities.
4. If the OPEN message is acceptable, the router sends a KEEPALIVE and enters the OpenConfirm state.
5. When a valid KEEPALIVE is received, the session enters the Established state.
6. Only after reaching Established can the peers exchange UPDATE messages containing route advertisements or withdrawals.

If the received session parameters are invalid, the router can send a NOTIFICATION message and close the connection instead of continuing toward Established.

After the session is established, KEEPALIVE messages are sent often enough to prevent the negotiated hold timer from expiring. Valid UPDATE messages also reset the hold timer, so a separate KEEPALIVE is not required whenever routing updates are already being exchanged.

An UPDATE message can advertise reachable prefixes, replace previously advertised routes, or withdraw routes that are no longer available. BGP does not periodically resend its entire routing table. After the initial exchange, routing changes are communicated incrementally.

The next section examines each BGP neighbor state in detail, including the transitions that occur before a session reaches Established.

BGP Neighbor States

BGP uses a finite state machine to track the progress of each neighbor relationship. The six states describe what the router is currently attempting and help identify where session establishment is failing.

A successful session generally progresses through:

Idle → Connect → OpenSent → OpenConfirm → Established

If the TCP connection fails, the session may move between Connect and Active while BGP retries. Reaching Established confirms that the BGP session is operational, but it does not guarantee that routes are being advertised correctly or that end-to-end forwarding works.

BGP as a Path-Vector Protocol

BGP is commonly described as a path-vector routing protocol. Rather than building a complete map of the network, BGP advertises reachable prefixes together with information about the path used to reach them.

That path information is carried in attributes attached to each route. The most recognizable is AS_PATH, which records the autonomous systems a route has crossed. Other attributes describe details such as the route’s origin, next hop, preference, and policy markings.

This makes BGP fundamentally different from an interior gateway protocol. OSPF builds a link-state database and calculates the shortest path through a known topology. BGP does not know every internal link between the source and destination. It selects among advertised paths using route attributes and locally defined policy.

A BGP route can be viewed as two related pieces of information:

• NLRI: the destination prefix being advertised
• Path attributes: information describing how that prefix can be reached

RFC 4271 defines a route as a set of destinations paired with the attributes of a path to those destinations. The destination is carried as Network Layer Reachability Information, while the associated path information is carried in the same BGP UPDATE message.

In practical terms, BGP does not simply say:

10.1.1.1/32 is reachable.

It says something closer to:

10.1.1.1/32 is reachable through this next hop, originated in this manner, and has crossed these autonomous systems.

That additional context is what allows BGP to support policy-based routing decisions across independently managed networks.

In the reference topology, R3 can potentially learn a prefix originated by AS 65001 through either AS 65002 or AS 65004. Each route can therefore describe the same destination with a different AS_PATH. Later labs will use this behavior to observe how BGP retains candidate paths and selects a best route.

AS Numbers in the Path

ASNs do more than identify BGP peers. When a route crosses an external BGP boundary, the advertising router adds its local ASN to the route’s AS_PATH attribute. As the route moves between autonomous systems, that path grows into a record of the ASes it has traversed.

For example, a route originating in AS 65001 and reaching AS 65003 through AS 65002 would carry the following path when viewed from AS 65003:

65002 65001

65002 65001

The leftmost ASN identifies the neighboring AS that most recently advertised the route, while the rightmost ASN normally identifies the originating AS. This path information gives BGP visibility into a route’s interdomain journey and forms the basis of its primary loop-prevention mechanism. When a BGP speaker receives a route containing its own ASN in the AS_PATH, it rejects the route rather than accepting it back into the autonomous system.

From Theory to Lab

BGP has a lot of terminology to get through before the configuration starts making sense. This first Learning Byte intentionally stayed on the theory side: autonomous systems, neighbor relationships, session establishment, message types, and the path information BGP carries with a route.

The next step is to stop reading about that behavior and watch it happen. The next Learning Byte will build the four-router topology, establish the eBGP sessions, originate a small number of test prefixes, and follow those routes through the network. From there, later labs can change one variable at a time and use the resulting behavior to work through the BGP topics covered in ENCOR, ENARSI, RFCs, and other study material.

References

• RFC 4271 — A Border Gateway Protocol 4 (BGP-4) — Primary reference for BGP protocol behavior, messages, neighbor states, and path attributes.
• RFC 6793 — BGP Support for Four-Octet AS Number Space — Reference for 32-bit ASNs.
• RFC 6996 — Autonomous System (AS) Reservation for Private Use — Reference for private ASN ranges.
• IANA Autonomous System Numbers Registry — Authoritative ASN allocation and reservation reference.
• Cisco Press — CCNP/CCIE Enterprise ENCOR 350-401 and ENARSI 300-410 Official Cert Guides — Study references used to organize and reinforce the BGP concepts covered.