BGP Basics for Network Admins: How the Internet Really Routes

Border Gateway Protocol (BGP) is the routing protocol of the internet. Every ISP, cloud provider and content network uses it to tell the rest of the world which IP prefixes it can reach. For many network admins, BGP stays invisible until the day the business buys a second internet circuit, gets its own address block or connects to a cloud provider. Then it suddenly matters a great deal. This guide covers BGP basics the practical way: what makes BGP different from an IGP, how eBGP and iBGP behave, which path attributes drive decisions, how the best-path algorithm works, and how to build a safe dual-ISP configuration on Cisco IOS.

What BGP is and why it is different

BGP version 4 is defined in RFC 4271. It is a path-vector protocol: instead of advertising a cost, each route carries a list of the autonomous systems it has passed through. An autonomous system (AS) is a network under a single administrative routing policy, identified by an AS number (ASN). If a router sees its own ASN in an incoming AS path, it rejects the route. That is how BGP prevents loops across thousands of independent networks.

Compared with an interior protocol such as OSPF, BGP has a very different personality:

• It runs over TCP port 179. Neighbors (peers) are configured explicitly; there is no automatic discovery.
• It is policy-driven, not speed-driven. BGP does not care about bandwidth or latency by default. It chooses paths based on attributes you can manipulate to express business intent.
• It scales to enormous tables. The full IPv4 internet table is on the order of a million prefixes, far beyond what any IGP is meant to carry.
• It converges deliberately. BGP is stable and conservative rather than fast. Timers and dampening favor stability over instant reaction.

If OSPF is new to you as well, read OSPF fundamentals first. In real networks, the IGP and BGP work together: the IGP provides reachability inside your network, and BGP carries external and policy-rich routes on top of it.

AS numbers

Original ASNs were 16-bit values (1 to 65535). Because they ran short, 32-bit ASNs were introduced (now RFC 6793), raising the range to over four billion. Some ranges are reserved:

Public ASNs are assigned by regional internet registries such as ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC. The examples in this article use documentation ASNs and documentation address blocks from RFC 5737.

BGP sessions, messages and neighbor states

A BGP session is a TCP connection between two configured peers. Once it is up, BGP exchanges four core message types:

• OPEN starts the session and negotiates the ASN, hold time, router ID and capabilities such as 32-bit ASNs and address families.
• UPDATE advertises new routes with their attributes or withdraws routes that are no longer reachable.
• KEEPALIVE keeps the session alive. Cisco defaults to a 60-second keepalive and a 180-second hold time.
• NOTIFICATION reports an error and closes the session.

A fifth type, ROUTE-REFRESH (RFC 2918), lets a router ask a peer to resend its routes so new inbound policy can be applied without tearing the session down.

In show ip bgp summary, an established neighbor shows a number (prefixes received) in the State/PfxRcd column. Anything else, such as Idle or Active, means the session is down.

eBGP vs iBGP

The same protocol behaves differently depending on whether the peer is in another AS or in yours.

The iBGP split-horizon rule is the one that surprises people. Because the AS path does not change inside an AS, BGP cannot use it to detect internal loops, so a route learned from one iBGP peer is never passed to another iBGP peer. The classic consequence is that iBGP requires a full mesh of sessions. With n routers, that means n(n-1)/2 sessions, which becomes unmanageable quickly. Larger networks solve this with route reflectors (RFC 4456) or, less commonly, confederations (RFC 5065).

BGP path attributes

Every BGP route carries attributes. They fall into four categories defined by the standard, plus one Cisco-specific value:

A simple rule of thumb helps here: you control outbound traffic with LOCAL_PREF (and weight on a single router), and you influence inbound traffic with AS_PATH prepending, MED and communities. Inbound influence is always a request, because the other networks make the final decision.

The BGP best-path selection order

When BGP has several paths to the same prefix, it compares them step by step and stops at the first difference. The Cisco IOS order is:

1. Ignore paths whose NEXT_HOP is unreachable.
2. Prefer the highest weight.
3. Prefer the highest LOCAL_PREF.
4. Prefer paths originated locally by this router (network, aggregate or redistribution).
5. Prefer the shortest AS_PATH.
6. Prefer the lowest ORIGIN type: IGP, then EGP, then incomplete.
7. Prefer the lowest MED (by default compared only between paths from the same neighboring AS).
8. Prefer eBGP over iBGP paths.
9. Prefer the path with the lowest IGP metric to the next hop.
10. If multipath is configured, install equal paths in the routing table.
11. For eBGP paths, prefer the oldest (most stable) path.
12. Prefer the path from the neighbor with the lowest BGP router ID.
13. Prefer the shortest cluster list (route reflection).
14. Prefer the path from the lowest neighbor address.

A popular mnemonic for the first steps is “We Love Oranges AS Oranges Mean Pure Refreshment”: Weight, Local preference, Originated, AS path, Origin, MED, Paths (eBGP over iBGP), Router ID. Other vendors follow the same logic but may skip weight or differ in tie-breakers, so check your platform’s documentation.

A practical dual-ISP configuration on Cisco IOS

Here is the most common reason a small or mid-sized business runs BGP: one edge router, two ISPs, and its own /24. In this example your network is AS 64496 with prefix 203.0.113.0/24. ISP-A is AS 64500 and ISP-B is AS 64510. The goal is to send outbound traffic through ISP-A, keep ISP-B as a working backup, and accept only a default route from each provider instead of the full table.

ip route 203.0.113.0 255.255.255.0 Null0 254
!
ip prefix-list OUR-PREFIXES seq 10 permit 203.0.113.0/24
ip prefix-list DEFAULT-ONLY seq 10 permit 0.0.0.0/0
!
route-map ISP-A-IN permit 10
 match ip address prefix-list DEFAULT-ONLY
 set local-preference 200
!
route-map ISP-B-IN permit 10
 match ip address prefix-list DEFAULT-ONLY
 set local-preference 100
!
route-map ISP-A-OUT permit 10
 match ip address prefix-list OUR-PREFIXES
!
route-map ISP-B-OUT permit 10
 match ip address prefix-list OUR-PREFIXES
 set as-path prepend 64496 64496 64496
!
router bgp 64496
 bgp router-id 192.0.2.2
 bgp log-neighbor-changes
 neighbor 192.0.2.1 remote-as 64500
 neighbor 192.0.2.1 description ISP-A
 neighbor 192.0.2.1 password Use-A-Long-Secret-1
 neighbor 198.51.100.1 remote-as 64510
 neighbor 198.51.100.1 description ISP-B
 neighbor 198.51.100.1 password Use-A-Long-Secret-2
 !
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
  neighbor 192.0.2.1 activate
  neighbor 192.0.2.1 route-map ISP-A-IN in
  neighbor 192.0.2.1 route-map ISP-A-OUT out
  neighbor 192.0.2.1 maximum-prefix 10
  neighbor 198.51.100.1 activate
  neighbor 198.51.100.1 route-map ISP-B-IN in
  neighbor 198.51.100.1 route-map ISP-B-OUT out
  neighbor 198.51.100.1 maximum-prefix 10
 exit-address-family

What each piece does:

• The Null0 static route exists because the BGP network command only advertises a prefix that matches a route in the routing table exactly. Pointing the aggregate at Null0 keeps the /24 advertised and stable even if internal subnets change, while more specific routes still forward real traffic.
• Outbound route-maps with a prefix-list guarantee you only ever advertise your own prefix. Without them, a router that learns routes from ISP-A could re-advertise them to ISP-B and turn your office into a transit network. That mistake has caused real internet outages.
• LOCAL_PREF 200 on ISP-A makes it the preferred exit for outbound traffic across your AS.
• AS_PATH prepending toward ISP-B makes the path through ISP-B look longer to the rest of the internet, so most inbound traffic arrives through ISP-A. It is a strong hint, not a guarantee.
• maximum-prefix protects the router if a provider accidentally sends far more routes than agreed.
• The password enables TCP MD5 authentication (RFC 2385) on the session. Agree on the secret with each ISP.

Activating each neighbor explicitly under the address family works regardless of whether your IOS release enables IPv4 unicast for new neighbors by default. Also note that some platforms implement RFC 8212 and will not exchange eBGP routes until a policy is applied. Classic IOS does not enforce that, so the filtering above is your responsibility.

Default route, partial routes or the full table?

ISPs typically offer three options. A default route only is the lightest and works well with a single edge router, as in the example above. Partial routes (the provider’s own and customer prefixes, plus a default) let you send traffic for those destinations over the most direct provider without much memory cost. The full table gives the most precise outbound path selection, but it demands a router with enough memory and CPU for every internet prefix plus room to grow, and it gives you more to monitor. For most small and mid-sized businesses, default-only or partial routes deliver nearly all of the resilience with a fraction of the operational load.

Verifying and troubleshooting BGP

show ip bgp summary
show ip bgp
show ip bgp 0.0.0.0
show ip bgp neighbors 192.0.2.1
show ip bgp neighbors 192.0.2.1 advertised-routes
show ip bgp neighbors 192.0.2.1 routes
show ip route bgp

Most BGP problems fall into a few buckets:

• Session stuck in Idle or Active: no IP reachability to the peer, wrong neighbor address or remote-as, TCP 179 blocked by an ACL or firewall, MD5 password mismatch, or a loopback-to-loopback peering missing update-source (and ebgp-multihop for eBGP).
• Session up, no routes received: inbound route-map or prefix-list too strict, the ISP is not sending what you expected, or the address family is not activated.
• Route received but not best: walk the best-path order. Often an unreachable next hop or an unexpected LOCAL_PREF.
• Prefix not reaching the internet: check advertised-routes, confirm the Null0 route exists, and confirm the ISP has your prefix in its filters and in its IRR records.

External looking glasses and public route collectors let you see how the rest of the internet sees your prefix, which is the only real proof that inbound traffic engineering works. Pair that with the layered approach from the network troubleshooting methodology guide: prove TCP 179 works before you debug policy.

RPKI and routing security

BGP was designed on trust. Any AS can announce any prefix, and its neighbors will believe it unless they filter. Route leaks and hijacks, whether accidental or malicious, have repeatedly redirected or blackholed traffic for major services. Several layers of protection now exist, and even small networks should understand them.

Resource Public Key Infrastructure (RPKI)

RPKI lets the holder of an address block publish a cryptographically signed Route Origin Authorization (ROA) stating which AS may originate that prefix and up to what prefix length. Routers then perform Route Origin Validation (RFC 6811), classifying each announcement as:

• Valid: a ROA exists and the origin AS and prefix length match.
• Invalid: a ROA exists but the origin AS or length does not match. Most large networks now drop these.
• NotFound: no ROA covers the prefix.

Routers usually do not process RPKI data themselves. A separate validator downloads and checks the signed objects, and routers fetch the results using the RPKI-to-Router protocol (RFC 8210). If you hold your own address space, the most valuable step is simple: create ROAs for your prefixes in your RIR portal and keep the maximum length tight. That way networks that validate will reject anyone else announcing your space.

Other good hygiene

• Filter what you send: only your own prefixes, every time.
• Filter what you receive: no bogons, no prefixes longer than /24 for IPv4 or /48 for IPv6, and never your own prefix coming back from outside.
• Use maximum-prefix limits and session authentication.
• Keep IRR (Internet Routing Registry) objects accurate so your providers can build filters automatically.
• Review the community-driven MANRS (Mutually Agreed Norms for Routing Security) actions as a checklist.

Routing security also belongs in your broader edge protection plan, alongside the controls in the firewall hardening checklist. And if you advertise IPv6 too, the same principles apply; the IPv6 for network admins guide covers the addressing side.

Key takeaways

• BGP-4 (RFC 4271) is a path-vector protocol running over TCP 179, built for policy and scale rather than speed.
• eBGP (AD 20) connects different autonomous systems; iBGP (AD 200) distributes external routes inside one AS and needs a full mesh or route reflectors.
• Use LOCAL_PREF to control outbound traffic; use AS_PATH prepending, MED and communities to influence inbound traffic.
• Learn the best-path order: weight, LOCAL_PREF, locally originated, AS_PATH, origin, MED, eBGP over iBGP, IGP metric, then tie-breakers.
• Always filter outbound advertisements to your own prefixes and set maximum-prefix limits.
• Create RPKI ROAs for any address space you hold, and filter what you accept from peers.

Adding a second ISP or moving to your own address space is a project where small mistakes have public consequences. If you want help designing and validating a resilient internet edge, the Small Business Network Setup service covers dual-ISP design end to end, and Firewall & Security Hardening locks down the edge around it. For anything else, contact us.