BGP (Border Gateway Protocol)

BGP gets called the glue of the Internet, and that's pretty accurate. It's how independent networks (autonomous systems, each with its own ASN) tell each other which addresses they can reach. It's also the protocol that made the Internet possible and a lot of my troubleshooting sessions much longer.

The thing worth getting early: BGP isn't trying to find the fastest path. It's a policy protocol. It picks paths based on rules you (and everyone else) set. Once that clicks, a lot of its behavior stops seeming strange.

The basics

BGP is a path-vector protocol. Every route carries the list of ASNs it passed through (the AS path), which is how loops get prevented and one of the ways paths get compared. OSPF and friends handle routing inside your network; BGP handles routing between networks.

What you actually use it for

If you run a hosting network or a small ISP, BGP ends up doing a few different jobs:

Transit: buying a connection to the rest of the Internet from an upstream, and announcing your prefixes (and your customers') through them.
Peering: swapping routes directly with other networks, often at an Internet exchange, to save money and shorten paths.
Traffic engineering: nudging traffic onto the links you'd rather it use.
Redundancy: having more than one upstream, so losing one doesn't take you offline.

A basic multihomed setup

Here's a simple Cisco-style config with two upstreams, announcing two /24s summarized as a /23:

router bgp 65001
  bgp log-neighbor-changes
  neighbor 192.0.2.1 remote-as 65002
  neighbor 192.0.2.1 description Upstream Provider 1
  neighbor 203.0.113.1 remote-as 65003
  neighbor 203.0.113.1 description Upstream Provider 2
  network 198.51.100.0 mask 255.255.255.0
  network 198.51.101.0 mask 255.255.255.0
  aggregate-address 198.51.100.0 255.255.254.0 summary-only

Two upstreams for redundancy and some ability to balance traffic.
The network statements announce the two /24s. These only work if a matching route actually exists in the routing table. That catches a lot of people the first time.
The aggregate rolls them into one /23 so you're adding one route to the global table instead of two. Be nice to everyone else's routers.

Policy examples

Prefer one upstream for outbound traffic by raising local preference on routes learned from it:

route-map SET-LOCAL-PREF permit 10
  set local-preference 200
router bgp 65001
  neighbor 192.0.2.1 route-map SET-LOCAL-PREF in

Higher local-pref wins, so routes from 192.0.2.1 become the preferred exit.

Only announce what's yours. This is the filter I'd never skip. Put an outbound prefix list on every upstream so the only thing you can ever send them is your own space:

ip prefix-list MY-PREFIXES permit 198.51.100.0/23
ip prefix-list MY-PREFIXES permit 198.51.100.0/24
ip prefix-list MY-PREFIXES permit 198.51.101.0/24
router bgp 65001
  neighbor 192.0.2.1 prefix-list MY-PREFIXES out
  neighbor 203.0.113.1 prefix-list MY-PREFIXES out

Without it, a mistake (or a redistribution you forgot about) can turn you into a transit path for one upstream's routes through the other. That's a route leak, and it's the kind of thing that gets you on mailing lists for the wrong reasons. Inbound, do the opposite: drop bogons and your own prefixes coming back at you.

Make a path less attractive for inbound traffic with AS-path prepending:

route-map AS-PREPEND permit 10
  set as-path prepend 65001 65001
router bgp 65001
  neighbor 203.0.113.1 route-map AS-PREPEND out

Prepending is a nudge, not a guarantee. Other networks have their own local-pref settings, and those beat AS-path length every time. A couple of prepends usually does what it's going to do; adding ten more mostly just looks silly.

Peering and IXPs

At an Internet exchange you can peer with lots of networks over one port. Traffic goes more directly, latency usually drops, and you send less over paid transit. The config itself is the easy part:

router bgp 65001
  neighbor 198.51.100.2 remote-as 65005
  neighbor 198.51.100.2 description Peering at IXP

The real work is filtering what you accept (use the IXP's route servers and IRR data), having a peering policy written down, and keeping an eye on session stability.

Communities

Communities are tags you stick on routes so policy can act on them later. A few are well-known:

NO-EXPORT: don't send this outside the neighboring AS.
NO-ADVERTISE: don't send this to anybody.
Provider-defined communities: most upstreams publish their own. Things like "prepend toward this region" or "blackhole this /32." Read your upstream's community docs. They're often the easiest traffic-engineering tool you have.

route-map TAG-COMMUNITY permit 10
  set community no-export
router bgp 65001
  neighbor 192.0.2.1 send-community
  neighbor 192.0.2.1 route-map TAG-COMMUNITY out

On Cisco, don't forget send-community. Otherwise you're setting the tag and then quietly not sending it.

Troubleshooting

The commands I start with:

show ip bgp summary — is the session up, and how many prefixes am I getting?
show ip bgp — the BGP table itself.
show ip bgp neighbors <ip> advertised-routes — what am I actually sending?
show ip bgp neighbors <ip> — all the details about a session.

Things I check, in rough order:

Session won't come up: can I reach the neighbor, is TCP 179 allowed, do the ASNs match on both sides, is there a password mismatch?
Session's up but routes are wrong: look at what I'm advertising and what filters are applied, both mine and theirs.
Slow failover: BGP's default timers are slow. BFD helps a lot here.

Looking glasses and public route collectors are great for seeing what the rest of the Internet thinks of your prefixes.

Things I wouldn't skip

Filter everything, in both directions. Never run a BGP session without filters.
Drop bogons: private, reserved, and unallocated space shouldn't come in or go out.
Set up RPKI: create ROAs for your prefixes and validate origins on what you receive. It's not that hard anymore.
Set max-prefix limits on sessions so one neighbor's mistake doesn't flood you.
Write down your policies: your ASNs, what each session is for, and why each route-map exists.

There's more BGP in the ISP and hosting networks page, and I'll keep adding notes on traffic engineering and security as I go.

Last Modified: October 12, 2026, 11:46 am