Reticux Day 1 — Why BGP Exists: Interdomain Routing, Policy and Autonomous Systems

at

Learning objective

By the end of this post, the reader should be able to explain why BGP is required between independently administered routing domains, distinguish reachability from policy, and build a minimal two-AS eBGP lab that exchanges only explicitly originated prefixes.


Why BGP Exists


1. Opening — the Internet cannot be routed as one giant IGP

Inside a small network, engineers can often define “best” as the path with the lowest metric. OSPF can calculate cost. IS-IS can calculate shortest paths. EIGRP can compare composite metrics. Those protocols work because a single administrative organization can agree on what the metric means and can operate the network under one routing policy.

The Internet has a different problem.

It is not one network under one operator. It is a collection of independently administered networks that may be customers, providers, peers, competitors, partners, cloud networks, content networks, universities, governments, enterprises, and access providers. Two organizations may both be able to reach the same destination and still disagree about which path should carry traffic. One path may be technically shorter but commercially unacceptable. Another may be longer but preferred because it is cheaper, contracted, more trusted, geographically controlled, or reserved for backup.

BGP exists for this environment. RFC 4271 defines BGP-4 as an inter-Autonomous System routing protocol whose primary function is to exchange network reachability information with other BGP systems. The reachability information carries path information that enables policy decisions and loop prevention.

The important idea is simple:

> BGP is not primarily a “find the numerically shortest route” protocol. It is a policy-controlled reachability exchange system between routing domains.

That distinction explains almost everything that follows in this series.

2. Concept and standards behaviour

2.1 What problem does BGP solve?

Suppose AS 64512 can reach 192.0.2.0/24, and AS 64513 can reach 198.51.100.0/24. If those organizations want to exchange traffic, they need a controlled way to tell each other:

  • which prefixes are reachable;
  • through which autonomous-system path;
  • which attributes describe the path;
  • which advertisements should be accepted;
  • which advertisements should be rejected;
  • which path should be preferred when several exist;
  • and when a previously reachable path must be withdrawn.

BGP provides that control-plane exchange.

2.2 BGP is a path-vector protocol

A distance-vector protocol tells a router something broadly equivalent to “this destination is N units away through me.” A link-state protocol distributes topology information and lets each router calculate a path.

BGP instead carries a path of autonomous systems in the AS_PATH attribute for ordinary inter-AS route propagation. This allows a receiving BGP speaker to see which autonomous systems a route has traversed and, critically, reject a route that already contains its own AS number.

That is a major loop-prevention mechanism for interdomain routing.

2.3 Reachability does not equal forwarding

A BGP speaker can learn that a prefix exists without being able to forward packets successfully to it. Successful forwarding depends on several layers:

  1. The BGP route must be accepted by policy.
  2. A path must become best or otherwise eligible for installation.
  3. The BGP next hop must be reachable.
  4. The route must be installed in the routing information base (RIB), subject to competition from other routing sources.
  5. The forwarding information base (FIB) must be programmed correctly.
  6. Interfaces, adjacency resolution, ACLs, firewalls, tunnels and downstream routing must permit actual packet delivery.

This is why later troubleshooting posts will repeatedly separate BGP control-plane evidence from data-plane evidence.

2.4 BGP is policy driven

Policy can be applied to routes as they enter or leave a router. Examples include:

  • permit only prefixes assigned to a customer;
  • reject private or bogon routes from an Internet peer;
  • prefer one provider for outbound traffic;
  • prepend the local ASN toward a backup provider;
  • attach communities for downstream treatment;
  • suppress a more-specific route under certain conditions;
  • reject routes whose origin fails an RPKI policy;
  • prevent a customer route from being re-advertised to another customer in an unsafe way.

The policy mechanism is vendor-specific; the underlying BGP attributes and protocol rules are standardized.

2.5 BGP is incremental

Once a BGP session is established and the initial routing information has been exchanged, BGP does not periodically resend the full table simply because a timer expires. Changes are communicated through incremental UPDATE messages and withdrawals. This is one reason BGP can operate with very large routing information sets, though scale still has substantial CPU, memory and convergence consequences.

2.6 BGP runs over TCP

BGP uses TCP as its transport, with TCP port 179 associated with BGP session establishment. BGP therefore relies on IP reachability and TCP mechanics rather than implementing its own reliable transport. Day 4 will examine this in depth.

3. Scenario — RETICUX Lab FND-001

Two independent lab networks need to exchange exactly one prefix each.

Engineering requirement

  • EDGE-A represents AS 64512.
  • EDGE-B represents AS 64513.
  • The routers are directly connected.
  • AS 64512 owns lab prefix 192.0.2.0/24.
  • AS 64513 owns lab prefix 198.51.100.0/24.
  • Each side must advertise only its own prefix.
  • No default route is used.

Topology

192.0.2.0/24                               198.51.100.0/24
   Lo10                                          Lo10
    |                                             |
+--------+  Gi0/0 203.0.113.1/30   203.0.113.2/30 Gi0/0 +--------+
| EDGE-A |----------------------------------------------| EDGE-B |
|AS64512 |                 eBGP                         |AS64513 |
+--------+                                              +--------+

Success criteria

  • The BGP session reaches Established.
  • EDGE-A learns 198.51.100.0/24 through AS 64513.
  • EDGE-B learns 192.0.2.0/24 through AS 64512.
  • End-to-end ICMP succeeds between the loopback prefixes when sourced appropriately.
  • No unrelated prefix is advertised.

4. Prerequisites

  • Cisco IOS XE 17.18.x target release.
  • Two virtual routers with at least two Layer-3 interfaces each, or one interface plus a loopback.
  • IPv4 unicast routing enabled.
  • Direct IP reachability across 203.0.113.0/30.
  • No ACL blocking TCP/179 or ICMP for the lab.
  • Independent management access is recommended before BGP policy changes.

5. Baseline configuration

EDGE-A — AS 64512

hostname EDGE-A
!
interface GigabitEthernet0/0
 description eBGP-to-EDGE-B
 ip address 203.0.113.1 255.255.255.252
 no shutdown
!
interface Loopback10
 description Prefix-originated-by-AS64512
 ip address 192.0.2.1 255.255.255.0
!
router bgp 64512
 bgp log-neighbor-changes
 neighbor 203.0.113.2 remote-as 64513
 address-family ipv4
  network 192.0.2.0 mask 255.255.255.0
  neighbor 203.0.113.2 activate
 exit-address-family

EDGE-B — AS 64513

hostname EDGE-B
!
interface GigabitEthernet0/0
 description eBGP-to-EDGE-A
 ip address 203.0.113.2 255.255.255.252
 no shutdown
!
interface Loopback10
 description Prefix-originated-by-AS64513
 ip address 198.51.100.1 255.255.255.0
!
router bgp 64513
 bgp log-neighbor-changes
 neighbor 203.0.113.1 remote-as 64512
 address-family ipv4
  network 198.51.100.0 mask 255.255.255.0
  neighbor 203.0.113.1 activate
 exit-address-family

Why the network statement matters

On Cisco IOS XE, the BGP network statement does not create the underlying IP route. The matching route must exist in the local routing table for BGP to originate it under the expected conditions. In this lab, each loopback interface creates the connected /24 route required for the corresponding network statement.

This is an important production lesson: BGP route origination is not the same operation as creating reachability.

6. Verification before modification

Check IP reachability

On EDGE-A:

ping 203.0.113.2

On EDGE-B:

ping 203.0.113.1

This proves the directly connected transport path is reachable before troubleshooting BGP itself.

Check BGP session state

show ip bgp summary

Expected result:

  • the neighbor is listed with the configured remote AS;
  • the session is established rather than showing an FSM state such as Idle or Active;
  • the prefix count is non-zero after exchange.

Inspect the learned prefix

On EDGE-A:

show ip bgp 198.51.100.0 255.255.255.0
show ip route 198.51.100.0 255.255.255.0

On EDGE-B:

show ip bgp 192.0.2.0 255.255.255.0
show ip route 192.0.2.0 255.255.255.0

The first command examines BGP path information. The second checks whether the selected path was installed in the IP routing table.

Forwarding test

From EDGE-A:

ping 198.51.100.1 source 192.0.2.1

From EDGE-B:

ping 192.0.2.1 source 198.51.100.1

A BGP session in Established state is not enough; the traffic test validates the forwarding path.

7. Controlled modification — withdraw reachability by removing the origin

The purpose of this modification is to demonstrate that BGP advertises reachability that exists in the control plane; it does not manufacture the route simply because a network command is present.

On EDGE-A, shut Loopback10:

configure terminal
interface Loopback10
 shutdown
end

Expected control-plane result

The connected route for 192.0.2.0/24 disappears. The BGP process can no longer satisfy the route-origination condition for that exact network statement, so the prefix should be withdrawn from EDGE-B.

Expected data-plane result

Traffic from EDGE-B to 192.0.2.1 fails because the destination is no longer available and the BGP route is withdrawn.

Monitoring signal

show ip route 192.0.2.0 255.255.255.0
show ip bgp 192.0.2.0 255.255.255.0
show ip bgp neighbors 203.0.113.1

8. Fault injection

Illustrative lab — not a real incident.

Lab name

FND-001-ORIGIN-MISSING

Fault

Remove the local route while leaving the BGP network statement in configuration.

Initial symptom

The BGP session remains established, but the remote router no longer learns the prefix.

Why this fault matters

A common beginner assumption is that “the neighbor is up, therefore BGP should advertise the configured network.” The missing evidence is the local route used to satisfy origination.

9. Step-by-step troubleshooting

``text show ip bgp summary ``

``text show ip route 192.0.2.0 255.255.255.0 ``

``text show ip bgp 192.0.2.0 255.255.255.0 ``

``text show running-config | section router bgp ``

``text show ip bgp neighbors 203.0.113.2 advertised-routes ``

  1. Confirm that the BGP neighbor remains established.
  2. Check whether the local route exists.
  3. Check whether BGP has the prefix locally.
  4. Inspect the exact network statement.
  5. Check what is being advertised to the neighbor.
  6. Prove the smallest root cause: the required local route is absent.
  7. Restore the source of the route rather than resetting the BGP session unnecessarily.

10. Root cause and correction

Root cause

Loopback10 was shut down, removing 192.0.2.0/24 from the local RIB. The BGP network statement remained configured, but its origination condition was no longer met.

Correction

configure terminal
interface Loopback10
 no shutdown
end

Why the correction works

The connected route returns to the RIB. BGP can again originate the matching prefix and advertise it to the external peer.

11. Post-fix verification

On EDGE-A:

show ip interface brief | include Loopback10
show ip route 192.0.2.0 255.255.255.0
show ip bgp 192.0.2.0 255.255.255.0
show ip bgp neighbors 203.0.113.2 advertised-routes

On EDGE-B:

show ip bgp 192.0.2.0 255.255.255.0
show ip route 192.0.2.0 255.255.255.0
ping 192.0.2.1 source 198.51.100.1

Observe the session for several minutes in the lab and confirm that no unexpected resets occur.

12. Rollback

If the controlled modification itself causes an unexpected lab problem, restore the loopback:

configure terminal
interface Loopback10
 no shutdown
end

If experimenting with BGP policy on a remote environment, maintain independent management access so a routing mistake cannot lock out the operator.

Preserve before/after outputs of:

show ip bgp summary
show ip bgp
show ip route
show logging

13. Production lessons

Design lesson

BGP should be introduced because administrative policy and interdomain reachability require it, not merely because it is considered an “advanced” routing protocol.

Change-management lesson

Separate transport/session changes from route-origination and policy changes. If too many variables change at once, fault isolation becomes much harder.

Monitoring lesson

Track both session state and prefix state. A session can remain healthy while required routes disappear.

Security lesson

A working BGP session does not mean every learned route should be trusted. Production eBGP requires explicit import/export policy, ownership validation and containment controls covered later in the series.

Scale lesson

BGP’s incremental update model supports large routing systems, but route count, path count, policy complexity and churn all affect CPU, memory and convergence.

14. Knowledge check

Q1

Two ISP links are available. One path has fewer AS hops, but the business contract requires outbound traffic to use the other provider unless it fails. Why is BGP appropriate?

Answer: Because BGP supports policy-based path selection. The “preferred” route can be determined by administrative policy rather than a single shortest-path metric.

Q2

A BGP neighbor is Established, but a locally configured network is not visible on the peer. What should you verify before resetting the session?

Answer: Verify that the exact route required for origination exists in the local routing table, then check the local BGP table and advertised routes.

Q3

A route is visible in the BGP table but traffic still fails. Name two layers to check next.

Answer: Check next-hop reachability/RIB installation and then FIB/data-plane forwarding, including interfaces and policy devices in the path.

15. Sources

  1. RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)*, RFC Editor.
  2. Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x: Configuring a Basic BGP Network*.
  3. Cisco — *IP Routing Configuration Guide: Connecting to a Service Provider Using External BGP*.
  4. Cisco — *BGP Command Reference: show ip bgp / show ip bgp neighbors / show ip bgp summary*.

Accessed: 2026-08-11.



#BGP #Cisco #NetworkEngineering #Routing #CCNP #InternetRouting #RETICUX

Read more
Labels:
Subscribe to: Posts (Atom)

Featured Post

Day 41 — BGP Confederations: Sub-AS Design, External View and Migration

1. Opening Confederations are another way to scale BGP inside a large administrative domain. They divide the domain into member autonomous systems while presenting a single confederation identifier to external peers. They are powerful, but their operational model is more complex than simply 'using private ASNs inside.' The engineering goal is not to memorize another BGP command. It is to understand what information each speaker is allowed to propagate, what path information can be hidden, and what failure domain is created by the chosen control-plane architecture . 2. Concept and standards behavior RFC 5065 defines AS_CONFED_SEQUENCE and AS_CONFED_SET and how member-AS relationships are represented. Confederation external sessions have eBGP-like properties inside the confederation, while the confederation is presented externally as one AS. Modern guidance must also account for the fact that RFC 9774 prohibits new origination of AS_SET/AS_CONFED_SET in ordinary aggregation c...