Learning Byte 001: BGP Foundations and First eBGP Peering

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 starts with a four-router Cisco IOS XE lab in which every router belongs to a separate autonomous system. AS 65001 represents the network under our control, while the remaining routers represent external routing domains. From that perspective, the lab builds each eBGP relationship, advertises loopback prefixes, follows the resulting AS paths, and verifies what reaches the BGP table and the routing table.

The aim is not to cover every BGP feature in one article. Route policy, best-path manipulation, aggregation, iBGP scaling, and multiprotocol BGP each deserve room of their own. This first lesson focuses on the protocol foundations that make those later topics possible: how peers establish a session, how reachability is advertised, how path information is carried, and how BGP prevents a route from looping back into its originating autonomous system.

The configuration examples in this article use Cisco IOS XE. Protocol behavior is grounded in the BGP-4 specification, while Cisco-specific syntax, output, and defaults are treated as implementation details rather than universal properties of BGP.

What This Learning Byte Covers

This Learning Byte builds and verifies a four-router eBGP topology using Cisco IOS. The lab is viewed from AS 65001, which represents the network under our control, while AS 65002 through AS 65004 represent external routing domains.

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

• Explain the role of BGP between autonomous systems
• 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 path attributes travel with advertised prefixes
• Describe how AS_PATH helps prevent inter-AS routing loops
• Configure directly connected eBGP neighbors on Cisco IOS
• Advertise loopback prefixes with the BGP network statement
• Verify neighbor state, learned prefixes, next hops, and AS paths
• Distinguish control-plane success from end-to-end forwarding success
• Troubleshoot common BGP session and route-advertisement failures

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.

Lab Topology

The lab uses four Cisco routers arranged in a diamond topology. Each router belongs to a separate private autonomous system, creating four directly connected eBGP sessions.

AS 65001 represents the network under our control. The remaining autonomous systems represent external networks that exchange routing information with their directly connected peers.

The topology provides two paths between AS 65001 and AS 65003. This allows the same destination to appear with more than one AS path, giving us a clean way to observe route propagation, AS_PATH growth, loop prevention, and basic route selection. The first objective is simply to establish each eBGP session and advertise the loopback prefixes. Later sections will use the resulting routes to examine path attributes, loop prevention, route selection, and forwarding behavior.

No interior routing protocol is required for this lab. Each BGP neighbor is directly connected, and the loopback prefixes will be introduced into BGP with network statements.

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 this lab, 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 should not remain in the AS_PATH when 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 this lab, every 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.

RFC 4271 specifies TCP as BGP’s transport protocol and states that BGP listens on TCP port 179.

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.

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.

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

References: RFC 4271, RFC 6793, RFC 6996, and the IANA Autonomous System Numbers registry.

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.

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 lab, R3 can learn the R1 loopback through either AS 65002 or AS 65004. Both routes describe reachability to the same prefix, but each carries a different path. BGP keeps those paths separate, compares their attributes, and selects the route that best matches the local decision process.