Peering vs Transit: Making the Right Connectivity Decision

Every network connected to the public internet must exchange traffic with other networks. Two mechanisms make this possible: transit, where a customer pays an upstream provider to carry traffic to the entire internet; and peering, where two networks directly exchange traffic destined for each other's address space, typically without payment. The choice — and the balance — between these two approaches has significant implications for cost, latency, resilience, and control.

IP Transit: The Full-Table Solution

An IP Transit provider sells access to the global routing table. The customer advertises its own prefixes to the transit provider and receives a full BGP table (approximately 950,000+ IPv4 prefixes and 200,000+ IPv6 prefixes as of 2026) in return. The transit provider is responsible for reaching every other AS on the internet, using its own peering and transit relationships to do so.

Transit pricing is typically expressed per Mbps/month at a committed data rate (CDR), with burst capacity available at the same or a higher rate. Pricing has declined dramatically over the past decade — 1G transit in major European markets now commonly trades below €2/Mbps/month — but transit remains a non-trivial operational expense at scale.

Peering: Direct Exchange

In a peering arrangement, two ASes agree to exchange only the traffic that originates within — or is destined for — each other's networks (and, in the case of transit-free peering, their respective customer cones). No money changes hands in settlement-free peering (SFP), and neither party provides transit to the other's upstream routes.

Settlement-Free vs. Paid Peering

• Settlement-Free Peering (SFP): Both parties judge the traffic ratio and mutual benefit to be sufficiently balanced that no payment is necessary. Common between networks of similar size or with strong mutual traffic interest.
• Paid Peering: One party pays the other, typically when the traffic ratio is heavily skewed (e.g., a large CDN sending far more traffic to an ISP than it receives). Also used when a content network cannot qualify for SFP under the transit provider's peering policy.
• Partial Transit: A hybrid — one network sells transit to a subset of routes (e.g., only European prefixes) at a lower price than full transit. Useful for networks that have peering for Tier-1 relationships but want lower-cost partial coverage for certain regions.

Internet Exchange Points (IXPs)

An Internet Exchange Point is a shared switching fabric where member networks exchange traffic via BGP sessions over a shared Layer-2 infrastructure (typically a VLAN on high-density Ethernet switches). The economic proposition is compelling: a single port at an IXP can support peering sessions with hundreds or thousands of other member networks, dramatically reducing the cost per peering relationship compared to private interconnects (PNIs).

Major European IXPs — DE-CIX Frankfurt, AMS-IX, LINX, Sofia's BIX — collectively see aggregate throughput of multiple terabits per second daily. Membership fees are modest (typically a few hundred to a few thousand euros per month for a 10G or 100G port), making IXP peering extremely cost-effective for traffic that would otherwise traverse paid transit.

Route Optimisation: Combining Peering and Transit

Most networks of meaningful scale use both peering and transit. The standard approach is to prefer peering routes over transit routes via BGP local-preference: routes learned from peers (via the IXP route server or direct EBGP sessions) receive a higher local-pref than routes received from transit providers. This ensures that when a peering path exists, it is used — keeping traffic off the more expensive transit circuits.

! BGP local-preference example (Juniper JunOS)
! Prefer peering routes (local-pref 150) over transit (local-pref 100)

policy-statement PREFER-PEERS {
  term peer-routes {
    from {
      protocol bgp;
      community PEER-COMMUNITY;
    }
    then {
      local-preference 150;
      accept;
    }
  }
  term transit-routes {
    from protocol bgp;
    then {
      local-preference 100;
      accept;
    }
  }
}

Decision Framework

• Peer when: you have significant traffic exchange with a specific network, the IXP port cost is lower than the equivalent transit cost for that traffic volume, or you need improved latency by keeping traffic local
• Buy transit when: you do not yet have sufficient traffic volume to justify peering, you need connectivity to destinations with no IXP presence, or your network is too small to meet the peering policy thresholds of the networks you want to reach
• Dual-home transit: always purchase transit from at least two independent providers to ensure resilience — a single transit outage will otherwise black-hole your entire network
• Monitor your traffic matrix: regularly review which destinations consume the most transit bandwidth; those are the peering candidates with the clearest ROI

Summary

Transit provides universal reachability but at a recurring cost. Peering reduces transit spend and often improves latency, but requires bilateral relationship management and a sufficient traffic profile to be economically worthwhile. A mature network will combine both: transit as the safety net of last resort, and an expanding peering matrix — anchored at well-connected IXPs — to carry as much traffic as possible off the transit bill.