Saving transit costs with peering

If you do not have peering, your network pays transit fees to reach the Capital I Internet. Sometimes that is fine. The upstream takes the packet, carries it across its backbone, and hands it to someone else. The customer still gets where they are going, but that does not mean it is the best path.

A few customers streaming video or pulling game updates may not seem like much on their own. Add enough of that traffic together, and the transit port starts doing most of the work. At some point, you are either paying for more commit or looking at a larger port.

Peering makes more sense when the network you need is already sitting next door. If a cache or game server is at the same Internet exchange, sending that traffic to an upstream first feels wasteful. I want my router to learn that route locally and hand the packet off across the exchange. BGP is still making the decision, but now the packet has a local path instead of whatever upstream route BGP hands out.

The savings come from moving traffic off the upstream port. A few good peers can pull a lot of traffic away from transit during peak time. That does not mean your transit goes away. You still need it for the rest of the Internet, and you still need it when a peer has a problem or does not carry the route you need.

I usually think about peering by looking at what ASNs my traffic is going to. There are tools that can use NetFlow and sFlow data to tell you where your traffic goes. That is for another article. Which ASNs are using the most bandwidth? Which ones are already sitting on the local FD-IX fabric? If I bring up a session, how much traffic would move from transit to peering?

Peering has both cost and performance benefits. The value is in the traffic that actually moves across the exchange fabric. Customers notice latency when a game server, cache, or content network is farther away than it needs to be. FD-IX can reduce latency when the better path is across the fabric rather than through your upstream.