BGP for ISPs: A Plain-English Introduction (and Why You Need an ASN)

The internet is not one network — it is tens of thousands of independently operated networks, each called an Autonomous System, that agree to exchange reachability information with one another. The Border Gateway Protocol (BGP) is the only language they share. When you load a page hosted three continents away, BGP is what told the routers between you and that server, hop by hop and network by network, which direction to send the packets. For an ISP, BGP is the difference between renting your connectivity from one upstream and genuinely participating in the global routing system on your own terms.

Most small operators start out single-homed: one upstream provider hands them a chunk of address space and a default route, and that is the whole story. It works until it doesn't — the upstream has an outage, raises prices, or you want to add a second provider for resilience and find you cannot, because every customer is numbered out of address space you do not own. The moment you want real independence, multihoming, or direct peering, you need three things: your own Autonomous System Number (ASN), your own provider-independent (PI) IP space, and a working understanding of how BGP makes decisions. This article covers all three at a level deep enough to design from.

What “reachability” and “path-vector” really mean

Interior protocols like OSPF and IS-IS compute shortest paths inside a single network using link metrics — they care about topology and cost. BGP is fundamentally different. It is a path-vector protocol: instead of advertising a metric, each network advertises a prefix (a block of addresses) along with the full list of ASNs the route has traversed to reach you — the AS_PATH. When network A tells network B “I can reach 203.0.113.0/24, and the path is A,” B re-advertises it to C as “path B,A,” and so on. By the time a prefix has propagated across the internet, its AS_PATH is a literal breadcrumb trail of every network it passed through.

This design solves two problems at once. First, loop prevention: if a router ever sees its own ASN already in the AS_PATH of an incoming advertisement, it discards the route — a loop is impossible by construction. Second, policy: because the path is visible, every operator can make business-driven decisions rather than purely technical ones. BGP does not pick the fastest route or the lowest-latency route. It picks the route that satisfies your policy first and, all else being equal, the shortest AS_PATH. That distinction trips up newcomers constantly — BGP optimizes for control and stability, not speed.

Why your own ASN and PI address space change everything

An ASN is your network's identity number in the global routing system; PI address space is IP space allocated to you by a Regional Internet Registry rather than loaned by an upstream. Owning both is the structural change that turns a reseller into an operator. With provider-assigned space, switching upstreams means renumbering every customer — a project measured in months and outages. With your own space, you announce the same prefixes to any provider you like and switch transit with a configuration change, not a forklift.

You obtain an ASN and an address allocation from your Regional Internet Registry — APNIC, RIPE NCC, ARIN, LACNIC, or AFRINIC depending on geography — typically as a member or through a sponsoring LIR. IPv4 allocations are now scarce and waitlisted almost everywhere, which is one more reason to deploy IPv6 from day one; see our guide on IP address planning for an ISP.

Multihoming basics: the safe defaults

Multihoming means connecting to two or more upstreams so that one failure does not take you offline. The mechanics are straightforward; the discipline is everything. You announce your prefixes to both providers and accept routes from both. If you do nothing else, traffic will balance unpredictably and — far more dangerously — you risk becoming a transit path between your two upstreams, where their traffic flows through your network because you accidentally re-advertised one provider's routes to the other.

The safe baseline: announce only your own prefixes outbound, and tag them so each upstream knows they originate with you. For inbound steering, the common tools are AS_PATH prepending (making one path artificially longer so it is less preferred), local-preference for your own outbound choices, and BGP communities your upstreams publish to let you signal intent like “depref this advertisement.” For a deeper treatment of those signalling tools, see BGP communities and route filtering. The key mental model: outbound traffic you control with local-preference inside your own network; inbound traffic you can only influence, because the remote network ultimately decides which path it prefers.

Inbound and outbound filtering — where most incidents start

BGP is built on trust, and that trust is regularly abused or fumbled. The two filters that prevent most self-inflicted disasters are simple to state and easy to forget. Outbound filtering: advertise only prefixes you are authorized to originate. A missing outbound filter is how a small network accidentally announces the whole internet back to its upstream and blackholes traffic for thousands — the classic route leak. Inbound filtering: reject anything you should never accept — bogons (private and reserved ranges), default routes you did not ask for, prefixes longer than the global maximum, and your own prefixes coming back at you.

Maximum-prefix limits are a cheap safety net: configure each session to shut down automatically if a peer suddenly sends far more routes than expected, which contains the damage when an upstream itself leaks. Many operators also build prefix-lists from registered route objects in an Internet Routing Registry (IRR), so the filter is generated from documented ownership rather than hand-maintained. The recurring lesson from real outages is the same: the network that caused the leak usually had no outbound filter, and the networks that propagated it had no inbound filter.

How BGP fails in production

BGP rarely fails by crashing — it fails by doing exactly what it was told, at scale. Route leaks propagate someone's mistake across the planet in seconds. Prefix hijacks, accidental or malicious, announce address space that is not yours and pull other people's traffic toward you. Flapping sessions — links that bounce up and down — trigger repeated reconvergence and, without dampening, churn the table. A full transit feed carries roughly a million IPv4 routes today, so an undersized edge router can exhaust memory or CPU when you take full tables from multiple peers; many operators take a default route plus selected routes instead of full tables until the hardware justifies it.

The other quiet failure mode is convergence time. BGP is deliberately slow to react — timers and best-path recomputation mean a failure can take tens of seconds to fully reroute unless you pair BGP with faster failure detection such as BFD. Designing for this means understanding that BGP gives you policy and reachability, not sub-second protection on its own.

RPKI and being a good internet citizen

Because BGP trusts what it is told, the community has built validation layers, and using them is now table stakes. RPKI (Resource Public Key Infrastructure) lets you cryptographically sign a Route Origin Authorization (ROA) stating which ASN is allowed to originate your prefixes. Networks that validate ROAs will reject advertisements that fail — so a hijack of your space from the wrong origin gets dropped before it spreads. Creating ROAs for your prefixes and validating incoming routes against RPKI is one of the highest-impact, lowest-cost things an operator can do.

Good citizenship extends beyond RPKI: register your routes in an IRR so peers can build accurate filters, keep your contact details current so people can reach you during an incident, and consider the MANRS (Mutually Agreed Norms for Routing Security) actions as a checklist — filtering, anti-spoofing, coordination, and validation. A misconfigured BGP network does not just hurt itself; it can disrupt strangers on the far side of the world, and the routing community has long institutional memory for the networks that repeatedly leak.

Common mistakes

• No outbound prefix filter — the single most common cause of route leaks; never trust “announce only what is configured.”
• Taking full tables on undersized hardware — start with a default route plus partial routes if memory is tight.
• Forgetting maximum-prefix limits — without them, an upstream's leak becomes your outage too.
• Treating inbound traffic like outbound — you influence inbound, you control outbound; expecting symmetric control leads to frustration.
• Skipping RPKI — unsigned prefixes are easier to hijack and mark you as a laggard to validating peers.
• Renumbering avoidance too late — get PI space before you have thousands of customers, not after.

The takeaway

You do not need BGP to light up your first customers, and a single-homed network with a default route is a perfectly honest place to start. But the day you want resilience, cost control, and a seat at the table — multiple upstreams, peering at an exchange, the ability to switch providers without touching a single customer — BGP and your own ASN are the threshold you cross. Get the fundamentals right from the beginning: announce only your space, filter ruthlessly in both directions, set maximum-prefix limits, and sign your routes with RPKI. Once you own your ASN and address space, the natural next steps are deciding where to send traffic and who to peer with; our guide on peering vs transit and what an IXP is pick up exactly there.