BGP and Internet Routing Basics for IT Teams

What BGP actually does

The internet is not one network. It is roughly a hundred thousand independent networks — carriers, clouds, universities, enterprises — each called an autonomous system, each making its own routing decisions. The Border Gateway Protocol is the language they use to tell each other, "here are the address blocks I can reach, and here is the path traffic takes to get there." Every time you load a page hosted three providers away, BGP is what stitched a route across those networks in advance.

Inside your building you run an interior protocol — OSPF, EIGRP, or static routes — and it optimizes for the shortest, fastest path because everything belongs to you. BGP is different in kind, not just scale. It is a path-vector protocol built for a world where networks do not trust each other, have competing commercial interests, and will not share internal detail. BGP does not pick the fastest route. It picks the route your policy and your neighbors' policies allow, then uses a deterministic tie-breaker to choose among what is left. That distinction — policy first, performance a distant second — explains most of what surprises teams when they first run it.

Why it matters: multi-homing and resilience

The practical reason a business touches BGP is multi-homing: connecting to two or more upstream providers at once so that no single carrier failure, and no single circuit, can take you off the internet. Without BGP, "two internet connections" usually means two providers each handing you their own address space; when one fails, every session bound to those addresses dies and clients have to reconnect. With BGP and your own addresses, both providers announce the same blocks, and if one path drops, traffic simply reconverges onto the other — often in tens of seconds, with established sessions surviving.

Figure: BGP turns thousands of independently run networks into one reachable whole — and multi-homing means more than one path into that mesh.

This is the backbone of the resilient global networks we build for organizations that cannot tolerate a regional carrier problem cutting off operations. It is also why BGP is worth understanding even if a provider runs it for you: the failure modes are unlike anything in your interior network.

ASNs and provider-independent addresses

Running your own BGP requires two things you have to obtain, not configure:

• An Autonomous System Number (ASN). This is your identity in the global routing table — the number other networks see as the origin of your routes. In the US you request one from ARIN, the regional internet registry. Modern ASNs are 32-bit values, so the old 16-bit pool running out was survivable, but the assignment process and justification still apply.
• Provider-independent (PI) address space. Addresses come in two flavors. Provider-aggregatable space is lent to you by a carrier and must be returned if you leave — you cannot announce it through a competitor, so it is useless for real multi-homing. Provider-independent space is allocated to you, and you can announce it through any provider. This is what makes carrier changes and dual-homing possible without renumbering every device.

Two practical constraints shape the design. The smallest IPv4 block most of the internet will accept globally is a /24 — 256 addresses — because networks filter anything more specific to keep the routing table manageable. For IPv6, a /48 is the common minimum. And IPv4 exhaustion means PI space now usually comes from the transfer market rather than a fresh allocation, which is a cost and lead-time item to plan for early.

How BGP picks a path

When several neighbors offer a route to the same destination, BGP walks a fixed decision list and takes the first tiebreaker that produces a winner. You do not need to memorize every vendor's exact order, but the top of the list is where all the useful control lives:

1. Local preference — a value you set to express outbound policy: "prefer provider A for these destinations." It is the primary lever for controlling which way your traffic leaves.
2. Shortest AS path — the fewest autonomous systems to traverse. This is BGP's idea of "distance," and note that it counts networks, not miles or milliseconds. A three-hop path over congested transit still beats a four-hop path over a clean one, as far as BGP is concerned.
3. Origin and MED — the multi-exit discriminator lets a neighbor hint which of its entry points you should use, giving limited influence over inbound traffic.
4. Tie-breakers — prefer external over internal routes, lowest interior metric to the exit, then stable identifiers like router ID to guarantee every router picks the same route deterministically.

The asymmetry worth internalizing: you have strong control over how traffic leaves your network (local preference) and only weak, advisory control over how it arrives (AS-path prepending and MED are hints other networks may ignore). Inbound traffic engineering is a negotiation, not a command.

When BGP goes wrong: leaks, hijacks, and RPKI

Because BGP is built on trust and accepts what neighbors announce, its worst incidents are misconfigurations and abuse that propagate globally in minutes.

• Route leaks happen when a network re-advertises routes it should have kept to itself — announcing its providers' routes to its other providers, for example — and suddenly a small regional network is in the path for a huge slice of traffic it cannot carry. High-profile leaks have degraded major cloud and content services for hours because one operator's filter was missing.
• Prefix hijacks happen when a network announces address space it does not own, attracting that traffic to itself. The classic case is a national ISP announcing a more-specific route for a popular service and, instead of blocking it locally, leaking it worldwide and blackholing the service for much of the internet. Hijacks can be accidental fat-finger errors or deliberate attempts to intercept or disrupt traffic.

The main defense in wide deployment today is RPKI — the Resource Public Key Infrastructure. You publish a signed Route Origin Authorization stating "ASN 64500 is authorized to originate this prefix," and networks that perform Route Origin Validation drop announcements that conflict. Adoption has crossed a real threshold: over half of routed address space now has ROAs, and most large transit providers now drop invalid routes. Two caveats keep it honest. RPKI validates the origin only, not the whole AS path, so it stops many hijacks but not sophisticated path forgery (emerging work like ASPA aims at that). And it only helps if both you and your upstreams participate. Publishing ROAs for your own prefixes and confirming your providers filter invalids is a short, high-value checklist item that our team treats as baseline network security hygiene for any BGP deployment.

When you actually need BGP — and when you don't

BGP is powerful and unforgiving, and plenty of organizations reach for it when a simpler design would serve them better. A quick decision guide:

• You probably need BGP if you require sessions to survive a carrier outage without reconnecting, you run your own public services or address space, you connect privately into multiple clouds, or you have contractual uptime that a single provider cannot underwrite.
• You probably do not need BGP if your traffic is mostly outbound web and SaaS, a brief reconnect during failover is acceptable, and you have no public-facing services anchored to fixed addresses. In that case, SD-WAN with two internet circuits and NAT gives you automatic, performance-aware failover — steering per application by real-time latency and loss — without an ASN, PI space, or the operational burden of participating in global routing.

The honest framing is that BGP buys address-level continuity and control at the cost of real complexity, while SD-WAN buys application-level resilience with far less overhead. Many mid-market networks are best served by SD-WAN today and grow into BGP only when public services or strict continuity requirements demand it. Either way, neither design is safe if it is invisible: per-path infrastructure monitoring with alerting on degradation — not just hard outages — is what turns a routing diagram into resilience you can trust.

Getting the routing layer right

BGP is not exotic, but it is genuinely different from the routing inside your walls, and small policy or filtering mistakes have outsized, public consequences. Whether you need full multi-homing with your own ASN and address space or a leaner SD-WAN design that fails over cleanly, the goal is the same: users never notice when a carrier has a bad day. intSignal designs, deploys, and operates both, complete with RPKI, sane filtering, and honest failover testing. Talk to our network team to review your internet edge and choose the routing model your business actually needs.