Blog

Every other routing protocol on the CCNP ENCOR blueprint answers the same question: which path to a destination is fastest? BGP answers a different one. BGP decides which path a network is willing to use, and which paths it is willing to tell other people about. That shift — from metric to policy — is the single idea that makes BGP feel alien to engineers who are fluent in OSPF and EIGRP, and it explains almost every design decision inside the protocol.

This is the first of four posts covering BGP for the CCNP ENCOR 350-401 v1.2 exam. The blueprint item is narrow — “Configure and verify eBGP between directly connected neighbors (best path selection algorithm and neighbor relationships)” — but that wording assumes a working mental model of autonomous systems, of how eBGP differs from iBGP, and of what BGP is actually for. This post builds that model. Later posts cover neighbor relationships and the finite state machine, route advertisement and path attributes, and the best path selection algorithm.

What BGP Is For

BGP is the routing protocol of the public internet. There is exactly one of these, and every organization that connects to more than one provider ends up running it. Its job is not to find a fast path across a network under one administration — that is an IGP’s job. Its job is to exchange reachability information between administrations that do not trust each other, do not share a common metric, and have commercial reasons to prefer some paths over others.

Three consequences follow immediately, and all three explain behaviour that otherwise looks like a bug:

• BGP is slow on purpose. Default timers are a 60-second keepalive and a 180-second hold time, and the advertisement interval between eBGP peers defaults to 30 seconds. A protocol carrying a million routes across the public internet cannot afford to reconverge on every flap.
• BGP prefers stability to optimality. It will keep using an established path rather than churn to a marginally better one, and mechanisms such as route dampening exist purely to punish instability.
• BGP does not care about bandwidth or delay. Nothing in the best path algorithm considers link speed. A 100 Mbps path with a shorter AS_PATH beats a 10 Gbps path with a longer one, every time, unless policy says otherwise.

BGP Compared to an IGP

The row that matters most for the exam is loop prevention. An IGP prevents loops by understanding the topology. BGP has no topology view at all — it sees a list of autonomous systems a route has traversed, and it discards any route whose list already contains its own AS number. That is the entire mechanism, and it is why the protocol is called a path vector.

Autonomous Systems

An autonomous system is a collection of IP prefixes under a single, clearly defined routing policy, identified by a number. “Single routing policy” is the operative phrase: an AS is not defined by ownership or geography but by the fact that, from the outside, it behaves as one consistent routing entity.

AS Number Ranges

Two-byte AS numbers ran out, so RFC 6793 extended the field to four bytes. The two ranges worth memorizing are the private ones, 64512–65534 and 4200000000–4294967294, because those are what enterprises use internally and what appears in almost every lab.

Four-byte ASNs are often written in asdot notation, as high.low. AS 65536 is 1.0, and AS 65546 is 1.10. IOS accepts both formats, and the display format is controlled globally:

router bgp 1.10
 bgp asnotation dot

When a 4-byte-capable router peers with one that only understands 2-byte ASNs, the old router sees AS 23456 (AS_TRANS) as a placeholder, while the real 4-byte path travels in a separate optional transitive attribute. This is invisible in a modern lab but explains stray 23456 entries in real-world path output.

When an Enterprise Actually Needs BGP

BGP is not the default answer for enterprise routing, and proposing it where it is not needed is a design error. It is warranted when:

• Multihoming to two or more ISPs with a need to influence which provider is used inbound and outbound. This is the classic case and requires a public ASN and provider-independent address space.
• Connecting to an MPLS L3VPN, where BGP is the CE-to-PE protocol the carrier requires.
• DMVPN and SD-WAN overlays at scale, where BGP’s scaling properties and policy control beat an IGP.
• Data centre fabrics, where eBGP is now commonly run all the way to the leaf as the underlay protocol.

A single-homed site with one default route to one provider does not need BGP, and adding it buys complexity with no benefit.

eBGP and iBGP

BGP runs in two modes that use identical packets and an identical state machine, but obey different rules. Which mode a session uses is determined entirely by whether the two routers’ AS numbers match.

• eBGP (external) — the remote-as differs from the local AS.
• iBGP (internal) — the remote-as is the same as the local AS.

The Rules That Differ

Two rows in that table cause most real-world trouble, and both are worth stating plainly.

The iBGP Split-Horizon Rule

A route learned from one iBGP peer is never advertised to another iBGP peer. This is BGP’s only loop-prevention mechanism inside an AS, and it exists because the AS_PATH does not change on internal sessions — so a route circulating internally would never accumulate an AS number to detect the loop.

The consequence is immediate and severe: iBGP peers must be fully meshed. Every iBGP speaker needs a session with every other iBGP speaker, because no router will relay on its behalf. The session count grows as:

sessions = n(n − 1) / 2

  4 routers  →   6 sessions
 10 routers  →  45 sessions
 20 routers  → 190 sessions
 50 routers  → 1,225 sessions

This is the scaling problem that route reflectors and confederations exist to solve. Both are beyond the ENCOR blueprint, but knowing why they exist is what makes the full-mesh rule memorable rather than arbitrary.

The iBGP Next-Hop Problem

When a router advertises a route over iBGP, it does not change the NEXT_HOP. A route learned from an external peer therefore keeps that external peer’s address as its next hop as it travels across the internal network — and internal routers usually have no route to an address on a provider’s link.

The symptom is distinctive: the prefix appears in show bgp ipv4 unicast but is marked inaccessible and never enters the routing table. The standard fix is next-hop-self on the router with the external session, which rewrites the next hop to its own address as it advertises internally. This is covered in detail in post 3.

How BGP Stores Routes

BGP does not keep a single table. It keeps three, and understanding the split makes troubleshooting output far easier to read.

Viewing the Adj-RIB-In with received-routes requires soft reconfiguration inbound to be configured, because otherwise the router discards filtered routes rather than storing them. Without it, that command returns nothing and the output looks misleadingly like the peer is sending nothing at all:

router bgp 65001
 address-family ipv4 unicast
  neighbor 192.0.2.2 soft-reconfiguration inbound

Only the single best path per prefix from the Loc-RIB is offered to the routing table, and only that path is advertised onward. BGP may know ten paths to a prefix; nine of them are invisible to the RIB.

A Minimal eBGP Configuration

The topology used throughout this series: R1 in AS 65001 peering with R2 in AS 65002 across a directly connected link.

          10.1.1.0/24                         10.2.2.0/24
               |                                   |
          +---------+   192.0.2.0/30    +---------+
          |   R1    |-------------------|   R2    |
          | AS 65001|  .1          .2   | AS 65002|
          +---------+                   +---------+

R1:

interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.252
 no shutdown
!
interface Loopback0
 ip address 10.1.1.1 255.255.255.0
!
router bgp 65001
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 192.0.2.2 remote-as 65002
 !
 address-family ipv4 unicast
  network 10.1.1.0 mask 255.255.255.0
  neighbor 192.0.2.2 activate
 exit-address-family

R2:

interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.252
 no shutdown
!
interface Loopback0
 ip address 10.2.2.2 255.255.255.0
!
router bgp 65002
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 neighbor 192.0.2.1 remote-as 65001
 !
 address-family ipv4 unicast
  network 10.2.2.0 mask 255.255.255.0
  neighbor 192.0.2.1 activate
 exit-address-family

Four details in that configuration deserve comment:

• bgp router-id is set explicitly. Without it the router picks the highest loopback address, or the highest active interface address if no loopback exists — and it will change if that interface goes down, resetting sessions. Always set it statically.
• neighbor ... activate is required. Defining a neighbor at the top level only creates the session; it must be activated per address family before any prefixes are exchanged. On IOS, IPv4 unicast is activated automatically unless no bgp default ipv4-unicast is configured, but writing it explicitly is the habit that transfers to IPv6 and VPNv4.
• network does not enable BGP on an interface. Unlike OSPF or EIGRP, the statement means “advertise this exact prefix if it already exists in the routing table.” The mask must match exactly.
• bgp log-neighbor-changes is on by default in modern IOS-XE, but is worth confirming — session transitions are the single most useful BGP log message.

Verification

R1# show bgp ipv4 unicast summary

BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 3, main routing table version 3
2 network entries using 496 bytes of memory
2 path entries using 272 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.0.2.2       4 65002      12      12        3    0    0 00:07:41        1

How to read the last column, which is the most useful field in BGP:

That Active means “failing to connect” rather than “actively working” is a favourite exam trap.

R1# show bgp ipv4 unicast

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.1.1.0/24      0.0.0.0                  0         32768 i
 *>  10.2.2.0/24      192.0.2.2                0             0 65002 i

Reading the status codes in the left margin:

• * — the path is valid: its next hop is reachable.
• > — the path is the best path, and is the one offered to the RIB and advertised onward.
• i in the first column (not the last) — learned from an iBGP peer.
• The trailing i is the origin code: i = IGP (from a network statement), e = EGP (obsolete), ? = incomplete (redistributed).
• Weight 32768 marks a locally originated route. Weight is Cisco-proprietary and never leaves the router.

Other commands worth knowing at this stage:

show bgp ipv4 unicast neighbors 192.0.2.2       ! full session detail, timers, capabilities
show bgp ipv4 unicast 10.2.2.0/24              ! every path for one prefix, and why one won
show ip route bgp                              ! what actually made it into the RIB
show tcp brief                                 ! confirm the TCP 179 session exists
clear bgp ipv4 unicast * soft                  ! reapply policy without tearing sessions down

Use clear ... soft rather than a hard clear. A hard clear bgp * tears down every session and, against a full internet table, causes a multi-minute outage.

Worked Examples

Example 1 — Reading an AS_PATH

     Network          Next Hop            Metric LocPrf Weight Path
 *>  203.0.113.0/24   192.0.2.2                              0 65002 65010 65020 i

The path is read right to left in chronological order, left to right in proximity. The prefix originated in AS 65020, passed through 65010, then 65002, and reached this router from 65002. The leftmost AS is always the neighbouring AS that sent it; the rightmost is the origin.

AS_PATH length here is 3. If a competing path showed 65003 i, that path has a length of 1 and would win the AS_PATH comparison — regardless of the bandwidth of either path.

Example 2 — Why a Loop Cannot Form

AS 65001 advertises 10.1.1.0/24 to AS 65002, which advertises it to AS 65003, which happens to also peer with AS 65001:

Advertised by 65001 to 65002 :  AS_PATH = 65001
Advertised by 65002 to 65003 :  AS_PATH = 65002 65001
Advertised by 65003 to 65001 :  AS_PATH = 65003 65002 65001
                                                        ^
R1 in AS 65001 sees its own AS number in the path → the route is silently discarded.

This check happens on receipt, before any policy is evaluated, and it is the whole of BGP’s inter-AS loop prevention. It is also why allowas-in exists as a deliberate override for hub-and-spoke MPLS designs where the same AS legitimately appears twice.

Example 3 — Counting iBGP Sessions

An AS has 6 routers that must all run iBGP, with no route reflectors:

n(n − 1) / 2  =  6 × 5 / 2  =  15 sessions

Each router configures 5 neighbor statements.
Adding a 7th router requires touching all 6 existing routers.

The operational cost is not really the session count — it is that adding one router is a change on every other router, which is what makes the full mesh unworkable past about a dozen devices.

Lab Exercises

These labs run on CML, EVE-NG, GNS3, or physical gear, using IOSv, CSR1000v, or Catalyst 8000v images. Attempt each task before opening the answer.

Lab 1 — First eBGP Session

Topology: R1 (AS 65001, Gi0/0 = 192.0.2.1/30, Lo0 = 10.1.1.1/24) connected to R2 (AS 65002, Gi0/0 = 192.0.2.2/30, Lo0 = 10.2.2.2/24).

Tasks:

1. Configure eBGP between R1 and R2 with explicit router-IDs.
2. Advertise each router’s loopback network into BGP using the network statement.
3. Verify the session reaches Established and that each router receives one prefix.
4. Confirm the administrative distance of the learned route, and explain the value observed.
5. Ping from R1’s loopback to R2’s loopback and explain why the source must be specified.

! R1
interface Loopback0
 ip address 10.1.1.1 255.255.255.0
interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.252
 no shutdown
router bgp 65001
 bgp router-id 1.1.1.1
 neighbor 192.0.2.2 remote-as 65002
 address-family ipv4 unicast
  network 10.1.1.0 mask 255.255.255.0
  neighbor 192.0.2.2 activate

! R2 — mirror image
router bgp 65002
 bgp router-id 2.2.2.2
 neighbor 192.0.2.1 remote-as 65001
 address-family ipv4 unicast
  network 10.2.2.0 mask 255.255.255.0
  neighbor 192.0.2.1 activate

! Task 3
show bgp ipv4 unicast summary        ! State/PfxRcd should show 1
show bgp ipv4 unicast

! Task 4
R1# show ip route 10.2.2.0
Routing entry for 10.2.2.0/24
  Known via "bgp 65001", distance 20, metric 0

R1# ping 10.2.2.2 source Loopback0

Lab 2 — Observing the AS_PATH

Topology: extend Lab 1 with R3 in AS 65003, connected to R2 on 198.51.100.0/30. R3 advertises Lo0 = 10.3.3.3/24.

Tasks:

1. Configure eBGP between R2 and R3 and advertise R3’s loopback.
2. From R1, display the AS_PATH for 10.3.3.0/24 and state the origin AS.
3. Explain why R1 can see R3’s prefix even though R1 and R3 have no session.
4. On R3, examine the AS_PATH for 10.1.1.0/24 and predict its contents before checking.
5. Configure neighbor 192.0.2.2 route-map PREPEND out on R1 to prepend AS 65001 three extra times, and observe the effect on R3.

! R3
router bgp 65003
 bgp router-id 3.3.3.3
 neighbor 198.51.100.1 remote-as 65002
 address-family ipv4 unicast
  network 10.3.3.0 mask 255.255.255.0
  neighbor 198.51.100.1 activate

! R2 adds
router bgp 65002
 neighbor 198.51.100.2 remote-as 65003
 address-family ipv4 unicast
  neighbor 198.51.100.2 activate

! Task 2 — on R1
R1# show bgp ipv4 unicast 10.3.3.0/24
  65002 65003
    192.0.2.2 from 192.0.2.2 (2.2.2.2)
      Origin IGP, localpref 100, valid, external, best

! Task 5
route-map PREPEND permit 10
 set as-path prepend 65001 65001 65001
router bgp 65001
 address-family ipv4 unicast
  neighbor 192.0.2.2 route-map PREPEND out
!
clear bgp ipv4 unicast * soft out

! On R3, the path becomes:
!   65002 65001 65001 65001 65001

Lab 3 — iBGP Split Horizon

Topology: R1, R2, and R3 all in AS 65001, connected in a line (R1–R2–R3), with an IGP already providing reachability between loopbacks. R1 has an eBGP session to R4 in AS 65004, from which it learns 203.0.113.0/24.

Tasks:

1. Configure iBGP sessions R1–R2 and R2–R3 only, using loopbacks as the source.
2. Verify R2 receives 203.0.113.0/24 from R1.
3. Check whether R3 receives it, and explain the result.
4. Fix the problem in the way ENCOR expects, and verify.
5. State how many sessions a full mesh of these three routers requires.

! R1
router bgp 65001
 neighbor 2.2.2.2 remote-as 65001
 neighbor 2.2.2.2 update-source Loopback0
 address-family ipv4 unicast
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 next-hop-self

! R2
router bgp 65001
 neighbor 1.1.1.1 remote-as 65001
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 3.3.3.3 remote-as 65001
 neighbor 3.3.3.3 update-source Loopback0
 address-family ipv4 unicast
  neighbor 1.1.1.1 activate
  neighbor 3.3.3.3 activate

! Task 4 — add the missing session to complete the mesh
! R1
router bgp 65001
 neighbor 3.3.3.3 remote-as 65001
 neighbor 3.3.3.3 update-source Loopback0
 address-family ipv4 unicast
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 next-hop-self
! R3 — mirror toward 1.1.1.1

Lab 4 — Private ASNs and AS_PATH Loop Prevention

Topology: R1 (AS 65001) — R2 (AS 65002) — R3 (AS 65001). Note that R1 and R3 deliberately share an AS number.

Tasks:

1. Configure eBGP on both links and advertise 10.1.1.0/24 from R1.
2. Verify R2 receives the prefix.
3. Check whether R3 receives it, and explain precisely why.
4. Apply the override that allows R3 to accept it, and describe the risk.

! Task 4 — on R3
router bgp 65001
 address-family ipv4 unicast
  neighbor 198.51.100.1 allowas-in 1

R3# clear bgp ipv4 unicast * soft in
R3# show bgp ipv4 unicast 10.1.1.0/24
  65002 65001
    198.51.100.1 from 198.51.100.1 ... valid, external, best

Common Mistakes and Exam Traps

• Active is a failure state, not a healthy one. It means the router is repeatedly failing to establish TCP.
• The network statement is not like an IGP’s. It advertises a prefix that already exists in the RIB; the mask must match exactly. network 10.1.0.0 mask 255.255.0.0 advertises nothing unless a 10.1.0.0/16 route exists.
• eBGP AD is 20, iBGP AD is 200. The asymmetry is deliberate and frequently tested.
• iBGP never re-advertises between iBGP peers, hence the full mesh.
• iBGP does not change the next hop, which is why next-hop-self exists.
• AS_PATH loop checking happens on receipt, before policy.
• BGP ignores bandwidth entirely. A longer AS_PATH loses even on a much faster link.
• Weight is Cisco-proprietary and never advertised. It is local to one router.
• Always set the router-ID statically, or an interface failure can reset sessions.
• Use soft clears. clear bgp * against a real table is an outage.

Check Your Understanding

Ten questions on the material in Part 1. Each answer is explained as you go, so a wrong answer is worth as much as a right one.

Time's up

Summary

BGP is a path vector protocol that exchanges reachability between autonomous systems, chooses paths by policy rather than metric, and prevents loops by discarding any route whose AS_PATH already contains the local AS. eBGP sessions run between different AS numbers, have an administrative distance of 20, a default TTL of 1, and rewrite both AS_PATH and NEXT_HOP. iBGP sessions run within one AS, have an administrative distance of 200, change neither attribute, and never re-advertise between internal peers — which forces a full mesh and creates the next-hop problem that next-hop-self solves.

The next post covers how a session is actually built: TCP port 179, the finite state machine from Idle to Established, the five message types, the timers, and how to troubleshoot an adjacency that will not come up.