CDN Peering for ISP Operators
from transit customer to network peer

Why CDNs Exist and Why You Should Care

Objective: understand why CDN peering is an economic and engineering priority for any growing ISP.

Learning Focus: before protocol detail, learn the cost path of each byte and how DNS analytics reveals your highest-value peering targets.

The Warehouse Analogy

CDNs are local warehouses for internet content. Without local caching, every popular video crosses expensive international transit links repeatedly. With a nearby cache, those bits travel only across your local network fabric.

Why This Is an ISP Problem

If most subscriber demand is video and social media, most transit spending is paying to move repeated content over long-distance links. Peering and embedded caches convert that recurring cost into local delivery paths.

The Global CDN Landscape

Objective: identify the major CDN ecosystems, their ASNs, and why each matters in ISP traffic engineering.

Learning Focus: classify providers into hyperscalers versus pure-play CDNs, then map that to your local peering plan.

Tier 1 Hyperscalers

Tier 2 Pure-Play CDNs

East Africa Presence Snapshot

Prerequisites Before You Can Peer

Objective: establish the non-negotiable requirements needed for any real peering deployment.

Learning Focus: peering is blocked without routing identity, owned address space, and exchange presence.

1. ASN (AFRINIC)

You need your own autonomous system number to run external BGP sessions and present an independent routing identity.

2. PI Address Space

Your prefixes must be yours so they can be announced from multiple providers and remain valid across transit changes.

3. IXP Membership (UIXP)

The exchange is where you physically meet peers. Your router gets an IXP-facing peering IP and forms BGP sessions over the shared fabric.

1) AFRINIC ASN issued
2) AFRINIC PI IPv4/IPv6 space assigned
3) UIXP membership approved
4) Port at Raxio connected to UIXP fabric
5) Peering IP assigned on exchange subnet

The Four Connection Models

Objective: understand transit, IXP peering, PNI, and embedded cache as a progressive optimization path.

Learning Focus: choose the right model for each traffic volume stage while preserving operational clarity.

Model 1 - Transit

Default state, highest per-bit cost, longest path, lowest operational effort.

Model 2 - IXP Peering

Best first move. Low latency and no per-byte transit charges for exchanged traffic.

Model 3 - PNI

Dedicated private cross-connect for sustained high-volume bilateral traffic.

Model 4 - Embedded Cache

Best economics. Content served from hardware in your own facility, minimizing external transport dependency.

BGP Configuration on MX204 for IXP Peering

interfaces {
    xe-0/0/2 {
        description "UIXP-PEERING-FABRIC";
        unit 0 { family inet { address 196.49.1.YOUR-IP/24; } }
    }
}

policy-options {
    community UIXP-PEER members "YOUR-ASN:100";
    community TRANSIT members "YOUR-ASN:200";
    community INTERNAL members "YOUR-ASN:300";

    policy-statement UIXP-IMPORT {
        term accept-peer-prefixes {
            from {
                protocol bgp;
                route-filter 0.0.0.0/0 prefix-length-range /8-/24;
            }
            then {
                community add UIXP-PEER;
                local-preference 200;
                accept;
            }
        }
        term reject-default {
            from { route-filter 0.0.0.0/0 exact; }
            then reject;
        }
        term reject-rest { then reject; }
    }

    policy-statement UIXP-EXPORT {
        term announce-your-space {
            from {
                protocol [ direct static ];
                route-filter YOUR-PREFIX/XX exact;
            }
            then { community add INTERNAL; accept; }
        }
        term reject-everything-else { then reject; }
    }
}

protocols {
    bgp {
        group UIXP-PEERS {
            type external;
            import UIXP-IMPORT;
            export UIXP-EXPORT;
            hold-time 90;
            neighbor 196.49.1.GOOGLE-IP { peer-as 15169; }
            neighbor 196.49.1.META-IP { peer-as 32934; }
            neighbor 196.49.1.CF-IP { peer-as 13335; }
            neighbor 196.49.1.NETFLIX-IP { peer-as 2906; }
            neighbor 196.49.1.AWS-IP { peer-as 16509; }
            neighbor 196.49.1.AKAMAI-IP { peer-as 20940; }
        }
    }
}

Verification Commands

show bgp summary
show route receive-protocol bgp 196.49.1.GOOGLE-IP
traceroute 216.58.x.x routing-instance default
show route 216.58.x.x detail | match "Local Preference"

Local Preference as Traffic Engineering Control

Objective: enforce deterministic path preference between cache, PNI, IXP, and transit routes.

Learning Focus: local-pref is the core lever that converts architecture intent into router behavior.

400  Embedded Cache
300  PNI
200  IXP Peering
100  Transit

With this hierarchy, identical destination prefixes learned through multiple channels are always pulled toward the cheapest and closest path first.

How to Read a Looking Glass

Objective: validate where traffic is currently going before and after peering activation.

Learning Focus: learn to prove route path and local-pref outcomes with evidence, not assumptions.

Google: toolbox.googleapps.com/apps/dig/
Cloudflare: radar.cloudflare.com
Hurricane Electric: lg.he.net and bgp.he.net
RIPE Atlas: atlas.ripe.net

show route 216.58.0.0/16
show route 157.240.0.0/16
show route 23.246.0.0/18

Peering Contact Directory

Objective: keep a verified contact table for rapid peering outreach and escalation.

Learning Focus: execution speed improves when commercial and technical contacts are standardized in one operator-facing reference.

Your Action Plan

Objective: execute peering in phased milestones with measurable outcomes and low operational risk.

Learning Focus: sequence matters: prerequisites, IXP sessions, embedded caches, PNI growth, then multi-PoP expansion.

Phase 0 - Prerequisites

[ ] ASN active
[ ] PI space assigned
[ ] UIXP-capable MX204 port reserved

Phase 1 - IXP (first 30 days)

1) Cloudflare
2) Google
3) Meta
4) Netflix
5) Amazon
6) Akamai

Phase 2 - Embedded Caches (60-90 days)

Use 30-day provider traffic evidence from DNS analytics to support GGC and OCA applications, then deploy dedicated BGP sessions with cache local-pref at 400.

Phase 3 - PNI (6-12 months)

When sustained bilateral traffic is high, request dedicated cross-connects at Raxio and assign PNI local-pref above IXP.

Phase 4 - Multi-PoP (12+ months)

Extend peering footprint to additional exchanges and propagate route policy across sites with consistent local-pref behavior.

How DNS Analytics Feeds Peering Decisions

Objective: convert analytics output into a repeatable peering optimization loop.

Learning Focus: treat analytics as an operations control system, not a reporting artifact.

DNS analytics identifies top CDN by traffic
-> apply for peering or embedded cache
-> establish session and shift path from transit
-> verify local-pref and traffic movement
-> confirm transit reduction in analytics
-> repeat for next provider