BGP peering strategy: five patterns we implement for Tier-1 ISPs

Most ISPs we start working with have the same problem: they stood up peering a decade ago, the internet rearranged itself around them, and nobody owns the question of whether that peering posture still makes sense. Transit bills grow every year. Latency on customer-critical paths doesn't move. Route churn shows up in weekly outage postmortems and nobody can trace it back to a single change.

We aren't going to pretend there's one right peering strategy. There isn't. But after enough engagements, we've seen the same five structural patterns save real money and move real latency numbers. This post is the playbook — or at least the framing we walk into a network with.

Pattern 1: Prefer settlement-free peering where prefix reach justifies it

This sounds obvious and everyone nods along until you actually look at their traffic matrix. In practice most Tier-2 and mid-market ISPs are buying transit to reach networks they could directly peer with for free at their nearest IX. The reason is almost never technical — it's that nobody keeps the peering database current, nobody has time to chase LOAs, and the transit circuit is already paid for this quarter.

What we do on day one: pull sFlow or NetFlow from the edge, aggregate by origin AS over a 14-day window, and rank destinations by bits-per-second delivered through paid transit. Then cross-reference that list against the AS-set of every IX the ISP currently has a port on, plus the content providers whose POPs are reachable directly from the carrier's region. The gap — networks the ISP could peer with (at an existing IX, through a direct cross-connect, or by onboarding onto a CDN's PNI program) but currently isn't — is usually a double-digit percentage of total wholesale spend.

On a recent engagement with a Tier-2 transit provider in Africa, that audit was the hinge of the whole project. Their dominant cost line wasn't local transit — it was submarine-cable capacity to Europe, used to backhaul traffic that, piece by piece, could be peered closer to source. After a rebuilt peering posture (more direct content-provider sessions on the European side, more aggressive use of existing IX ports, and the deprecation of some paid paths that had outlived their purpose) we took roughly 60% off their total submarine-link bill. The traffic didn't stop; it just stopped travelling through the most expensive pipe in their topology.

The playbook from there isn't glamorous. It's a peering-request spreadsheet, a week of LOA chasing, and turning sessions up one at a time. The win is that every new peer moves measurable traffic off transit within days, so the business case justifies itself before the quarter ends.

Pattern 2: Let route-servers do the heavy lifting — but verify what they're giving you

Route-servers at big IXs (AMS-IX, DE-CIX, LINX, etc.) simplify peering from an operational standpoint: one session, hundreds of routes. The catch is that you inherit whatever the route-server's filtering policy happens to be, and that policy varies across IXs in ways that matter.

The failure mode we see most often: an ISP accepts the route-server session, trusts that the IX is doing strict RPKI + IRR filtering, and then discovers six months later that a leaked prefix blackholed a chunk of their customer traffic. Some route-servers do strict RPKI ROV. Some do best-effort. Some do neither. Read the actual docs for the IX you're on. If you can't find them in five minutes, that's your answer.

Our default posture: accept route-server sessions, but always add a second filter layer on ingress — an IRR-derived prefix list generated nightly, RPKI validation enforced via validation-state invalid reject, and a max-prefix limit that triggers an alert, not a session reset. The filter layer is redundant with what the route-server does when it's working. The whole point is what happens when the route-server's filtering silently stops working.

Pattern 3: Split your IX ports into "flow" and "peering-only"

Here's a thing we only learned the hard way. When you have a 100G port at an IX carrying both a route-server session (with thousands of prefixes) and a direct BGP session to a hyperscaler (carrying, say, five prefixes but 80% of your bits), any incident on that port is an incident that affects both relationships simultaneously. The blast radius is everything.

The fix is boring and expensive: dedicate separate physical ports to high-volume direct peers and keep the route-server traffic isolated. Hyperscalers in particular: give them their own port, run LAG if you need capacity, and you'll thank yourself the first time a route-server session flaps and your biggest CDN origin doesn't notice.

The cost analysis we present to clients: the incremental port cost is usually 15–25% of the total IX budget. The reduction in incident minutes on customer-critical traffic, combined with how much easier it makes capacity planning, consistently pays back within a year.

Pattern 4: Use local-pref aggressively but document like your on-call depends on it

Everyone learns local-preference on day one and thinks of it as a simple preference knob. It isn't, once your policy grows past five communities. We've walked into networks where the local-pref matrix had 40+ possible values, three people understood half of them, nobody understood all of them, and half the communities had been added for a customer that left two years ago.

We're not going to tell you to simplify your local-pref policy. Sometimes it really does need to be complex — for example if you're running a mixed transit/peering edge with customer route tagging. But we will tell you to document the policy in one place that's version-controlled, treat it as operational infrastructure, and run an automated test that reads the policy file and compares it against what's actually programmed on the routers.

The concrete shape: a single YAML file in the network team's git repo, one community per line with a plain-English purpose and the local-pref value it maps to, a CI job that parses the router config nightly and diffs against the YAML. When the diff drifts, someone gets paged. This has saved more 2am incidents than anything else we recommend.

Pattern 5: Monitor the routes you don't have, not just the ones you do

Most ISPs we see are monitoring their BGP table for what's in it — prefix count, session flaps, path length distributions. That's table stakes. The interesting signal is in the routes you should have but don't.

A concrete example from an engagement: a customer noticed that monthly traffic volume from a major content provider was quietly dropping over a few months. Not a huge number in isolation, and the kind of content traffic that's supposed to grow, not shrink. The cause turned out to be a peering session with a regional CDN node that had silently degraded — the session was up, but the CDN had de-prioritized the peer's prefixes for capacity reasons on their side, and the traffic was invisibly routing back through paid transit. Nothing in the ISP's monitoring flagged it because all their alerts were "session down" or "prefix flap" style. None of them were "expected traffic volume through this peer has dropped below threshold".

What we added: a traffic-matrix monitor that aggregates bits-per-second per (source-peer, destination-prefix-aggregate) on a rolling 7-day baseline, and fires an alert when any cell drops below 60% of its baseline for more than 6 hours. This is the kind of thing that's trivial to build on top of any existing flow-collector stack, but it's very rare that we walk into a network that has it.

What this adds up to

None of these five patterns is a secret. Nobody on the other side of an engagement hears them and thinks "we hadn't considered that". The reason they aren't already in place isn't ignorance — it's that small network teams have finite hours, and BGP strategy work is the kind of thing that never makes it to the top of the sprint because nothing is technically broken today.

Our job on a network consulting engagement is to come in, do the boring but high-leverage work of rebuilding the peering posture against current traffic and current IX options, document the new policy so your team can run it without us, and leave the monitoring in place that will tell you when the next drift starts.

If any of this sounds familiar — transit bills creeping up, peering posture from five years ago, nobody owning the question of whether it still makes sense — get in touch. We'll take a look.