BGP is the protocol that makes the internet's routing work, and districts usually meet it in one of two ways: their ISP hands them a default route and they never think about it, or they buy a second ISP and discover that failover requires announcing their own address space.
The second case is where BGP earns its complexity.
When you actually need it
| Situation | BGP? |
|---|---|
| One ISP, provider-assigned addresses | No — static default is fine |
| Two ISPs, provider-assigned addresses | Maybe — NAT-based failover can work |
| Two ISPs, your own address block | Yes |
| Multiple campuses with private WAN | Not necessarily — static or IGP |
| Anycast DNS across sites | Yes |
The decisive question is addressing: if your public block belongs to you (provider-independent, PI), you must announce it yourself, and that means BGP.
The vocabulary, minimally
| Term | Meaning |
|---|---|
| AS | Autonomous system — your network's number |
| eBGP | BGP between you and your ISP |
| Prefix | The network you announce |
| AS path | The list of ASes a route traversed |
| Local preference | Your outbound preference (higher wins) |
| MED | A hint to your ISP about inbound preference |
Outbound and inbound are separate problems, and this is the part that surprises people: you control which ISP you use for outbound traffic, but inbound traffic follows the path the internet chooses, influenced only by what you announce and how specifically.
The four filters
An edge router without filters is a liability.
- Prefix filter outbound — announce only your block, never a default, never a more-specific you did not intend.
- Prefix filter inbound — accept only your ISP's expected routes; reject bogons and any prefix longer than /24.
- AS-path filter inbound — reject routes containing your own AS (loop prevention).
- Max-prefix limit — shut the session if the ISP sends an implausible number of routes, which is what a leak looks like.
A misconfigured announcement can black-hole a region
Announcing a prefix you do not own, or announcing a more-specific that attracts traffic you cannot carry, is how networks take down their neighbors. Filters are not optional politeness; they are the safety interlock.
Outbound and inbound, separately
Outbound (which ISP your packets leave through):
local-preference 200 via ISP-A
local-preference 100 via ISP-B
Higher local preference wins, regardless of AS path length. This is deterministic and entirely under your control.
Inbound (which ISP the internet uses to reach you):
- Announce a more-specific via the preferred ISP (e.g.
/24via A,/23aggregate via both). - Use MED as a hint — but it only travels one AS, and providers often ignore it.
- Use AS-path prepending to make one path look longer.
None of these are guarantees. Inbound traffic engineering is influence, not control.
Worked example: dual-homed district
203.0.113.0/24 (PI space), ISP-A on a 1 Gbps fiber, ISP-B on 500 Mbps.
| Setting | ISP-A | ISP-B |
|---|---|---|
| Session | eBGP, AS 64500 ↔ 65001 | eBGP, AS 64500 ↔ 65002 |
| Announced | 203.0.113.0/24 |
203.0.113.0/24 |
| Local preference | 200 | 100 |
| Prepending | none | 3× on outbound announcements |
Outbound: everything leaves via A. If A fails, the session drops and B takes over in seconds.
Inbound: both providers carry the /24; traffic that arrives via B still works because the return path is symmetric at the edge (the router knows both).
Test it: shut the A session and confirm that traffic still reaches the block from an external looking glass, then confirm internal users can reach the internet.
What breaks in production
- Announcing a more-specific that the ISP filters, so the intended inbound path never appears.
- No max-prefix limit, so a provider leak fills the table and the router falls over.
- Asymmetric return after a partial failure, which breaks stateful firewalls at the edge.
- Forgetting to announce the block from both providers after a change, so half the internet cannot reach you.
- Using BGP for internal routing without understanding it, then wondering why a flapping link causes a campus-wide reconvergence.
Checklist
- You know whether your public addressing is PI or provider-assigned.
- Inbound and outbound policies are documented separately.
- Prefix, AS-path, and max-prefix filters are in place on every session.
- The failover has been tested from outside the network.
- Bogon and default-route filters are applied inbound.
- Someone monitors session state, not just "internet works."
Next
BGP is the plumbing. Continue with What SD-WAN Actually Solves, which is mostly about policy over mixed links.