🤝 BGP Peering Explained

🔍 What Is BGP Peering?

BGP peering is an agreement between two Autonomous Systems to interconnect their networks and exchange routing information directly via the Border Gateway Protocol, so that traffic destined for each other's networks (and typically each network's downstream customers) can flow between them without transiting a third party. Each side advertises its own routes — and the routes of any customers it provides transit to — but critically, does not advertise routes it learned from other peers or transit providers, since that would effectively make it a free transit provider for the peer.

This restriction is enforced through what's called a peer-to-peer export policy, sometimes summarized by the "no valley routing" principle in BGP route selection philosophy: traffic should only flow from customer to provider, provider to customer, or peer to peer — never peer to peer via a third network that would effectively be donating free transit. Understanding this constraint is fundamental to understanding what peering actually delivers, since it directly determines which destinations become reachable through a given peering session.

Peering exists as an alternative — usually a complement, not a full replacement — to buying IP transit from an upstream provider. Where transit gives you reachability to the entire internet routing table via a single paid relationship, peering gives you reachability to just one network's (and its customers') routes, typically at no cost, in exchange for reciprocal treatment. Most networks of meaningful size run a mix of both: transit for default, full-internet reachability, and peering to offload high-volume routes to specific networks directly.

The word "peer" implies rough parity between the two networks in question — comparable traffic volumes flowing in each direction — and this expectation of mutual benefit is precisely why most peering arrangements are settlement-free. Both networks save on transit costs for traffic that would otherwise need to flow through a paid upstream, and since the benefit is genuinely mutual, no money needs to change hands for the arrangement to make economic sense for both parties.

🎯 Why Peering Matters

Peering is one of the primary economic and technical forces that shapes how the internet's topology actually looks, and understanding it clarifies a lot about why certain networks are fast and cheap to reach while others aren't.

The most direct motivation is cost: every byte of traffic that flows over a peering session is a byte that doesn't need to be carried (and paid for) over a transit connection. For any network exchanging significant traffic with another specific network — a video streaming service and a large residential ISP, for example — establishing direct peering can save substantial money that would otherwise go toward transit bills, particularly as traffic volumes scale into the hundreds of gigabits per second seen at major exchange points.

Performance is the second major driver. A direct peering path is typically shorter (fewer hops), lower latency, and free of the congestion or additional cost pressure that can affect shared transit links. Content networks, cloud providers, and CDNs pursue aggressive peering strategies specifically because reducing the number of networks between their servers and end users directly improves the experience for those users — faster page loads, lower buffering, more responsive applications.

Peering also plays a structural role in internet resilience. A network with a rich mesh of peering relationships across many exchange points has more paths to reach the rest of the internet, meaning the failure or congestion of any single transit provider has a smaller overall impact. This diversity-through-peering is part of why major content and access networks invest heavily in peering infrastructure well beyond what pure cost savings alone would justify.

For smaller and mid-sized networks, peering is often the difference between being a purely "customer" network — entirely dependent on upstream transit providers for reachability and pricing — and having real leverage in the ecosystem. A network with an established peering presence at a major exchange point has more negotiating power with transit providers, since it has demonstrated it can reduce its transit dependency when the economics justify it.

⚙️ How Peering Actually Works

A peering relationship goes through a fairly consistent lifecycle from initial contact through an established, running BGP session.

Once established, the session typically requires little ongoing maintenance — route filters may need periodic updates as either network's customer base changes, but the underlying relationship tends to be stable for years once set up correctly.

🏗️ Architecture & Technical Detail

Peering sessions run as standard external BGP (eBGP) sessions between routers belonging to the two different Autonomous Systems, typically directly connected at Layer 2 — either via a dedicated cross-connect cable or a shared VLAN at an Internet Exchange Point. The BGP session itself works identically to any other eBGP session technically; what differs is the route policy applied to it.

The defining technical characteristic of a peering session's export policy is that it advertises only "local preference" routes — the AS's own address space and the address space of any customers it provides transit to — and explicitly withholds routes learned from its own transit providers or other peers. This is typically implemented via BGP communities that tag routes by their origin (customer, peer, or transit-learned) so that export filters can be written declaratively rather than needing to be manually maintained as an exhaustive prefix list.

On the import side, a peering session's filters are similarly restrictive: a network should only accept routes for prefixes that the peer legitimately originates or provides transit for, rejecting anything that looks like the peer is unexpectedly announcing third-party address space — a defense against both misconfiguration and the kind of route leaks that have caused major internet outages in the past.

Two connection topologies dominate in practice. Private peering uses a dedicated physical cross-connect between the two networks' routers, typically within the same data center or carrier-neutral facility, offering guaranteed bandwidth and the highest performance for high-volume relationships. Public peering uses a shared switching fabric at an Internet Exchange Point, where a single physical port lets a network establish BGP sessions with many peers present on the same exchange, dramatically reducing the marginal cost of adding each additional peer.

🔧 Step-by-Step: Setting Up a Peering Session

🔄 Flow: From Outreach to Live Traffic

This entire cycle can take anywhere from a few days (for an open-policy network at a shared exchange point) to several months (for a selective or restrictive peer requiring extensive negotiation and traffic history review).

💡 Practical Examples

A mid-sized regional ISP notices, via its transit provider's traffic reports, that a significant share of its outbound traffic goes to a specific large content network's address space. It checks that content network's PeeringDB entry, finds an open peering policy at a shared exchange point where both networks already have a presence, and establishes a settlement-free public peering session — immediately reducing transit costs for that traffic and improving latency for its customers.

A growing CDN company builds out peering relationships at dozens of exchange points across multiple continents, treating peering infrastructure as core to its performance strategy rather than purely a cost play — since delivering content over the shortest possible path directly to eyeball networks (ISPs serving residential customers) measurably improves page load times and reduces buffering for video traffic.

Two similarly-sized enterprise networks that exchange substantial business-to-business traffic (a large SaaS provider and one of its major enterprise customers, for instance) establish a private peering cross-connect specifically for that traffic, bypassing the public internet entirely for improved reliability, security, and predictable performance for their integration.

🎯 Real-World Use Cases

• Content delivery optimization — CDNs and streaming platforms peering directly with eyeball ISPs to shorten delivery paths.
• Transit cost reduction — any network offloading high-volume routes from paid transit to settlement-free peering.
• Enterprise-to-enterprise private connectivity — dedicated peering for business partners exchanging significant B2B traffic.
• Regional internet resilience — local ISPs peering at regional exchange points to keep local traffic local rather than routing it internationally.
• Cloud provider interconnection — cloud platforms peering with major networks to reduce egress costs and latency for customer traffic.

✅ Advantages

• Reduces or eliminates transit costs for traffic exchanged with the peer.
• Typically improves latency and reduces hop count compared to a transit path.
• Increases path diversity and resilience against transit provider issues.
• Builds negotiating leverage with transit providers by demonstrating reduced dependency.
• Settlement-free arrangements require no ongoing billing relationship to maintain.

⚠️ Disadvantages & Risks

• Only provides reachability to the peer's own network and customers, not the full internet.
• Selective or restrictive peers may reject smaller networks regardless of technical merit.
• Each session adds operational overhead: filter maintenance, monitoring, and troubleshooting.
• Misconfigured peering filters can cause route leaks with significant real-world impact.
• Private peering cross-connects have fixed capacity that must be upgraded as traffic grows.

🏆 Best Practices

• Maintain an accurate, up-to-date PeeringDB profile, since it's the primary discovery mechanism prospective peers use.
• Build explicit prefix filters from IRR route objects rather than accepting a peer's full announced table by default.
• Tag routes with BGP communities by origin (customer/peer/transit) to keep export policy declarative and maintainable.
• Monitor peering session traffic and route counts continuously, alerting on unexpected changes.
• Document each peering relationship's contact details, session parameters, and agreed scope for future troubleshooting.

🔒 Security Considerations

• Apply strict import filters based on the peer's legitimate address space to prevent accepting leaked or hijacked routes.
• Adopt RPKI Route Origin Validation to automatically reject routes with invalid origin ASNs on peering sessions.
• Use BGP session authentication (MD5 or TCP-AO) to reduce the risk of session hijacking on shared exchange fabrics.
• Rate-limit or cap the maximum number of prefixes accepted from any single peering session to contain the blast radius of a misconfiguration.

⚡ Performance Considerations

• Private peering cross-connects offer dedicated, predictable bandwidth unaffected by other exchange participants' traffic.
• Public peering at a shared exchange can encounter congestion during peak periods if the exchange fabric itself is under-provisioned.
• Peering paths are typically shorter than transit paths to the same destination, directly reducing latency.
• Monitor individual peering session utilization to know when to upgrade capacity or add additional interconnects.

❌ Common Problems

🔧 Troubleshooting

Session not establishing: Verify both sides are using the correct peer IP addresses and ASNs, and confirm there's no firewall or ACL blocking TCP port 179 between the interconnect addresses.

Unexpectedly large route count received: Check the peer's export policy for a misconfiguration, and verify your own import filters are correctly scoped to only the peer's legitimate address space.

Peering session up but traffic not shifting: Check local preference and route selection on your own router — a route learned via peering needs to be preferred over an equally specific route learned via transit for traffic to actually shift.

Frequent session flaps: Investigate the physical layer first (cross-connect or exchange port), then check for MTU mismatches or BGP timer misconfigurations between the two sides.

✅ Implementation Checklist

Use this checklist when planning, negotiating, or auditing a peering relationship, whether it's your first session or your fiftieth.

💡 Expert Tips

• Prioritize peering with networks where you already see significant transit traffic — use your transit provider's traffic reports or a flow analysis tool to identify these candidates before cold outreach.
• When negotiating with a selective peer, come prepared with concrete traffic volume data and geographic presence details, since vague requests are the most common reason for rejection.
• Consider route servers at exchange points for initial connectivity to many peers with a single BGP session, then move high-volume relationships to dedicated bilateral sessions as they grow.

❌ Beginner Mistakes

• Believing peering replaces the need for transit entirely, when in reality it only covers the peer's own address space.
• Accepting a peer's full route announcement without filters, risking a route leak if the peer misconfigures their side.
• Reaching out to restrictive or selective peers without first checking whether your network meets their published minimum requirements.
• Forgetting to update peering filters as a network's customer base (and therefore legitimate announced prefixes) changes over time.

📊 Comparison Tables

Public vs Private Peering

Peering vs Transit

📋 Feature Table

📚 Key Terms Glossary

❓ FAQs

📋 Conclusion

BGP peering is the mechanism that lets networks bypass paid transit for the traffic they exchange most, trading a bit of operational overhead for meaningfully lower costs, better performance, and greater routing resilience. Understanding the distinction between what peering does and doesn't provide — direct reachability to a peer's own network, not full internet transit — is the key to using it effectively as part of a broader routing strategy.

Whether you're evaluating your first peering session or optimizing an existing peering portfolio, the fundamentals here apply directly. Dig deeper into the surrounding topics with ToolsNovaHub's guides on Transit vs Peering, Internet Exchange Points, and BGP Communities, and use the ASN Lookup tool to research any network's routing footprint before reaching out.

If you're pursuing your first peering relationship, the practical starting point is simple: get your PeeringDB profile in order, identify a handful of networks you already exchange significant traffic with, and start with an open-policy peer at a shared exchange point where onboarding friction is lowest.