# CDN Peering for ISP Operators ### From Transit Customer to Network Peer `codeandcore` · David Egwell · 2026 --- > **How to read this document** > Each section builds on the previous one. Read it front to back the first time. > The analogy comes first, the technical detail follows, the config comes last. > Nothing is skipped. Nothing assumes you already know. --- ## Part I — Why CDNs Exist and Why You Should Care ### The Warehouse Analogy Imagine you run a chain of supermarkets across Uganda. Your customers want Coca-Cola. You could order every bottle from the factory in Nairobi for every single customer every single time — but that would be absurd. Instead, you keep Coca-Cola in your warehouse. Customers get it instantly and you don't pay freight on every individual bottle. CDNs are that warehouse, but for internet content. YouTube lives on Google's servers in data centres in the United States and Europe. Without a CDN, every time one of your subscribers presses play on a video, the bits travel: subscriber → your network → your transit provider → undersea cable → Europe → YouTube server → Europe → undersea cable → your transit provider → your network → subscriber. Every byte of that video crosses expensive international transit links twice. A CDN solves this by caching popular content as close to your subscribers as physically possible — ideally inside your own data centre, or at a nearby exchange point. The bits travel: subscriber → your network → CDN cache (50 metres away) → subscriber. Instant. Free. ### Why This Is Your Problem as an ISP You pay for transit by the megabit. International transit is expensive — typically $5–30 per Mbps/month depending on your contracts and your geography. If 70% of your traffic is Netflix, YouTube, Facebook video, and TikTok (which it almost certainly is), then 70% of your transit bill is paying to carry the same popular videos over and over again across expensive international links. CDN peering turns that 70% from a cost centre into a zero-cost delivery path. A medium-sized ISP that has established CDN peering relationships can reduce its transit bill by 50–70% compared to buying all traffic from a single upstream provider. That is not a marginal gain. That is a fundamental shift in your unit economics. ### What Your DNS Analytics Tells You This is why the DNS analytics platform you just built is directly connected to this topic. When you run VIZ-13 (Provider Traffic Table) after 30 days of data, you will see something like: | Provider | % of traffic | |---|---| | Google (YouTube + Search + CDN) | 45% | | Meta (Facebook + Instagram + WhatsApp) | 18% | | Netflix | 12% | | Akamai | 8% | | Cloudflare | 6% | | Everything else | 11% | That table is your peering priority list. You go after Google first. Then Meta. Then Netflix. Then Akamai and Cloudflare. In that order. --- ## Part II — The Global CDN Landscape ### Tier 1: Hyperscalers (Own the Backbone) These companies built their own global fibre networks. They do not buy transit from anyone for traffic between their own facilities. They peer with ISPs aggressively because it reduces their own costs and improves their product quality. --- **Google — AS15169** Google operates one of the largest private networks on earth. Its fibre connects data centres across four continents. The Google Global Cache (GGC) program is Google's most important tool for ISP relationships — they will put physical servers inside your data centre, for free, if you carry enough traffic. What Google delivers to your subscribers: - YouTube video (typically 30–50% of total ISP traffic globally) - Google Search - Google Play app downloads and updates - Android OS updates - Chrome browser updates - Google Maps tile data - Google Fonts (loaded by millions of websites) - Workspace (Gmail, Drive, Docs) Peering ASN: 15169 GGC embedded cache program: `peering.google.com` → Embedded Cache --- **Meta — AS32934** Meta operates a similarly large private network. Their traffic profile is different from Google — heavy on video (Reels, Instagram Stories) and messaging media (WhatsApp images, videos, voice notes). What Meta delivers: - Facebook Feed and video - Instagram feed, Stories, Reels - WhatsApp media (images, videos, voice notes, documents) - Messenger calls and media - Facebook Gaming Peering ASN: 32934 Embedded cache program: available at larger ISPs — contact via `peering.fb.com` --- **Netflix — AS2906 (Open Connect)** Netflix built a dedicated CDN called Open Connect specifically to distribute its video library. Netflix is responsible for 10–25% of downstream internet traffic globally during peak hours. They have one of the most generous embedded cache programs of any company. Netflix Open Connect Appliances (OCAs) are physical servers Netflix ships to your data centre. Netflix staff manage them remotely. You provide rack space, power, and a network port. Netflix fills the appliances with the most popular content for your region every night. During peak hours, the vast majority of your subscribers' Netflix traffic never touches the internet — it comes from the box in your rack. Peering ASN: 2906 OCA program: `openconnect.netflix.com` — apply online, threshold ~1 Gbps sustained --- **Microsoft — AS8075** Microsoft's CDN carries Windows Update, Xbox game downloads, Teams video, OneDrive sync, and Azure CDN traffic for thousands of SaaS companies. Microsoft peers extensively and also works with Akamai for edge delivery. What Microsoft delivers: - Windows Update (can be massive on Patch Tuesday) - Xbox game downloads (individual titles can be 100GB+) - Microsoft Teams video and media - OneDrive sync - Azure CDN (countless SaaS applications) - Office 365 / Microsoft 365 Peering ASN: 8075 --- **Amazon CloudFront — AS16509** Amazon operates CloudFront as the CDN layer on top of AWS. Half the internet's infrastructure runs on AWS — S3 buckets, EC2-hosted apps, Lambda functions — and CloudFront sits in front of all of it. If your subscribers use SaaS apps, e-commerce sites, or stream from Amazon Prime Video, you are touching CloudFront. What Amazon delivers: - Amazon Prime Video - AWS S3 static assets for thousands of websites - CloudFront-accelerated web applications - API Gateway endpoints - Twitch (owned by Amazon) Peering ASN: 16509 --- ### Tier 2: Pure-Play CDNs These companies exist solely to deliver other companies' content. They have no consumer products of their own. Their business is being fast and cheap. --- **Akamai — AS20940** Akamai is the oldest large CDN, founded in 1998. It operates more than 300,000 edge servers in 4,000 locations globally. Almost every large enterprise — banks, airlines, governments, media companies — uses Akamai to protect and accelerate their websites. Akamai's model is different from Google or Netflix. They will call you. When you are large enough to matter to them, their peering team reaches out. Akamai also now owns Linode (cloud compute) and operates as both a CDN and a cloud provider. Peering: Akamai maintains an open peering policy. Contact `peering@akamai.com`. Peering ASN: 20940 --- **Cloudflare — AS13335** Cloudflare is unique. It started as a security and DDoS mitigation company and became one of the largest networks on the internet. Today it operates in more than 300 cities globally, including many African cities. Cloudflare is relevant to you for multiple reasons: 1. A significant fraction of the internet now sits behind Cloudflare (DNS, CDN, WAF) 2. Cloudflare operates the `1.1.1.1` public resolver — your subscribers may use it 3. Cloudflare has a dedicated ISP peering program with generous terms 4. Cloudflare's Bandwidth Alliance means zero cost for traffic exchanged with peers Peering: fully self-serve at `peering.cloudflare.com` Peering ASN: 13335 --- **Fastly — AS54113** Fastly is popular with developers and media companies. It powers real-time content delivery for companies like GitHub, Spotify, New York Times, and Twitch's CDN layer. Fastly's differentiator is its ability to purge cached content globally in under 150 milliseconds — critical for news sites and live content. Peering: open, contact `peering@fastly.com` Peering ASN: 54113 --- **Limelight / Edgio — AS22822** Limelight (now rebranded as Edgio) specialises in video streaming delivery. If your subscribers watch sports streaming, live events, or use video-heavy platforms, Limelight is the CDN behind many of them. Peering: open peering policy, `peering@limelight.com` --- **Bunny CDN — AS44477** A newer but fast-growing CDN with aggressive pricing and an expanding global network. Growing in popularity with smaller publishers and SaaS companies. Worth watching as its footprint in Africa expands. --- ### CDN Presence in East Africa | CDN | Raxio (Uganda) | KIXP (Kenya) | Teraco (SA) | |---|---|---|---| | Google GGC | Yes | Yes | Yes | | Meta | Yes | Yes | Yes | | Netflix OCA | Evaluated | Yes | Yes | | Cloudflare | Yes | Yes | Yes | | Akamai | KIXP/Teraco primarily | Yes | Yes | | Amazon CloudFront | Via IXP | Yes | Yes | | Microsoft | Via IXP | Yes | Yes | | Fastly | Via IXP | Via IXP | Yes | Raxio Namanve is Uganda's most important interconnection point. UIXP is hosted there. Every CDN relationship you build starts at Raxio. --- ## Part III — Prerequisites: What You Need Before You Can Peer Before you can establish a single BGP session with a CDN, you need three things. Without all three, you cannot peer. This is not negotiable. ### 1. An Autonomous System Number (ASN) An ASN is your identity on the global internet. It is the number that tells every router in the world "this network belongs to Sprint Uganda." Without an ASN, you cannot run BGP, which means you cannot peer with anyone. ASNs are issued by Regional Internet Registries (RIRs). For Africa, that is AFRINIC. ``` AFRINIC: afrinic.net Process: 1. Become an AFRINIC member (requires proof of operating a network) 2. Submit an ASN request — justify why you need routing autonomy 3. Pay the annual membership fee 4. Receive a 32-bit ASN (format: 4-byte number, e.g. AS394000) Timeline: typically 2–6 weeks Cost: AFRINIC membership starts at approximately $1,500/year for smaller ISPs ``` If SprintUG already has an ASN, note it here: ________________ --- ### 2. Provider Independent (PI) IP Address Space Your IP addresses must be yours, not assigned to you by your upstream provider. If your current IPs are from your transit provider, they will be withdrawn the day you leave that provider. PI space is assigned directly to you by AFRINIC and belongs to you regardless of which transit providers you use. You need PI space for two reasons: - You can announce it from multiple transit providers (multihoming) - CDNs and IXPs accept your routes because they are stable and verifiable ``` Apply to AFRINIC for: - IPv4: minimum /22 (1,024 addresses) for ISP allocation - IPv6: minimum /32 (65,536 /48 subnets) — get this, it is free and future-proof Requirements: - Active AFRINIC membership - Documentation showing planned use of addresses - Proof of existing network infrastructure ``` --- ### 3. IXP Membership (UIXP for Uganda) The Uganda Internet Exchange Point is the neutral ground where you and the CDNs meet. Both parties connect to the same switching fabric. You establish BGP sessions across that fabric. Traffic flows directly. ``` UIXP Membership: Website: uixp.ug Location: Raxio Data Centre, Namanve, Kampala Requirements: - Own ASN - Own PI IP space - Physical port connection at Raxio - UIXP membership application Port speeds: 1G, 10G Cost: contact UIXP — typically modest annual membership fee + port charge ``` Your MX204 at Raxio gets a dedicated port connected to the UIXP switching fabric. UIXP assigns you a peering IP address in their range (e.g. 196.49.1.x/24). That IP is your address on the exchange — every CDN on the exchange will use it to establish a BGP session with you. --- ## Part IV — The Four Connection Models ### Model 1 — Transit (Default, Worst Economics) ``` Your Subscriber │ ▼ Your Router (MX204) │ ▼ ← You pay transit rate for EVERY BYTE here Your Upstream Transit Provider │ ▼ Their backbone network │ ▼ CDN Origin Server (Europe / USA) │ ▼ ← Same path, same cost, coming back Your Subscriber ``` This is what you have if you do nothing. Every byte of YouTube, Netflix, and Instagram crosses your international transit link twice and you pay for all of it. **Cost:** Full transit rate on all CDN traffic. Typically the most expensive option. **Latency:** Highest. London is 100ms+ from Kampala. **Complexity:** Lowest. This requires no action from you. **Use case:** Starting point only. Acceptable for a new ISP. Unacceptable at scale. --- ### Model 2 — IXP Peering (Best First Step) ``` Your Subscriber │ ▼ Your Router (MX204 at Raxio) │ ▼ IXP switching fabric (microseconds) │ CDN Edge Router (also at Raxio) │ ▼ CDN's own backbone (free, their problem) CDN Origin ``` At the IXP, you and the CDN are physically connected to the same switch. You establish a BGP session. You announce your prefixes to them. They announce their CDN prefixes to you. Traffic flows directly — no transit provider in the middle, no international link, no cost per byte. **Cost:** IXP port fee (fixed, modest) + zero per-bit cost for peered traffic **Latency:** Lowest possible — the CDN cache is in the same building **Complexity:** Moderate — requires ASN, PI space, BGP configuration **Use case:** This is your standard operating model for all major CDNs #### BGP Configuration on MX204 for IXP Peering ```junos /* ============================================================ UIXP Peering Configuration — SprintUG MX204 at Raxio Replace x.x with your actual UIXP-assigned peering IPs ============================================================ */ /* Step 1: Define your IXP-facing interface */ interfaces { xe-0/0/2 { /* port connected to UIXP fabric */ description "UIXP-PEERING-FABRIC"; unit 0 { family inet { address 196.49.1.YOUR-IP/24; /* assigned by UIXP */ } } } } /* Step 2: Define the community tags you will use */ policy-options { community UIXP-PEER members "YOUR-ASN:100"; community TRANSIT members "YOUR-ASN:200"; community INTERNAL members "YOUR-ASN:300"; } /* Step 3: Import policy — what you accept from IXP peers */ policy-options { policy-statement UIXP-IMPORT { /* Accept peer routes, tag them, set high local-pref */ term accept-peer-prefixes { from { protocol bgp; /* Only accept routes within reasonable prefix lengths */ route-filter 0.0.0.0/0 prefix-length-range /8-/24; } then { community add UIXP-PEER; local-preference 200; /* prefer IXP over transit (default 100) */ accept; } } /* Never accept a default route from a peer */ term reject-default { from { route-filter 0.0.0.0/0 exact; } then reject; } term reject-rest { then reject; } } /* Export policy — what you announce to IXP peers */ policy-statement UIXP-EXPORT { /* Only announce your own prefixes — never transit others */ term announce-your-space { from { protocol [ direct static ]; route-filter YOUR-PREFIX/XX exact; /* your PI block */ } then { community add INTERNAL; accept; } } term reject-everything-else { then reject; } } } /* Step 4: BGP peer group for IXP */ protocols { bgp { group UIXP-PEERS { type external; import UIXP-IMPORT; export UIXP-EXPORT; hold-time 90; /* Google (AS15169) */ neighbor 196.49.1.GOOGLE-IP { description "Google-UIXP-AS15169"; peer-as 15169; } /* Meta (AS32934) */ neighbor 196.49.1.META-IP { description "Meta-UIXP-AS32934"; peer-as 32934; } /* Cloudflare (AS13335) */ neighbor 196.49.1.CF-IP { description "Cloudflare-UIXP-AS13335"; peer-as 13335; } /* Netflix Open Connect (AS2906) */ neighbor 196.49.1.NETFLIX-IP { description "Netflix-OCA-AS2906"; peer-as 2906; } /* Amazon CloudFront (AS16509) */ neighbor 196.49.1.AWS-IP { description "Amazon-UIXP-AS16509"; peer-as 16509; } /* Akamai (AS20940) */ neighbor 196.49.1.AKAMAI-IP { description "Akamai-UIXP-AS20940"; peer-as 20940; } } } } ``` #### Verifying Your Peering Sessions ```bash # Check BGP session state — look for "Established" show bgp summary # Example expected output: # Peer AS State In/Out Pfx Rcvd # 196.49.1.x 15169 Establ 0/0 45000 # 196.49.1.x 32934 Establ 0/0 12000 # 196.49.1.x 13335 Establ 0/0 8000 # Check prefixes received from Google show route receive-protocol bgp 196.49.1.GOOGLE-IP # Trace a YouTube IP to confirm it routes via IXP, not transit traceroute 216.58.x.x routing-instance default # Check where YouTube.com resolves to show route 216.58.x.x detail | match "Local Preference" # Should show local-preference 200 (IXP) not 100 (transit) ``` --- ### Model 3 — Private Network Interconnect / PNI When your traffic with a specific CDN grows large enough (typically 1–5 Gbps sustained), you negotiate a dedicated cross-connect. This is a physical fibre patch cable running from your cage at Raxio to the CDN's cage at Raxio. No shared switch in the middle. ``` Your MX204 (SFP-10G-LR) ←── dedicated fibre ──→ Google/Meta/Netflix Edge Router ``` Benefits over IXP: - Dedicated bandwidth — no contention with other IXP participants - Lower latency — one fewer switching hop - No IXP port fee for this traffic - More direct relationship with the CDN's peering team ``` How to request a PNI: 1. Establish IXP peering first and grow the traffic 2. Email the CDN's peering team: Google: peering-request@google.com Meta: peering@fb.com Netflix: noc@netflix.com (for OCA) / peering@netflix.com Cloudflare: peering@cloudflare.com (or use peering.cloudflare.com portal) Akamai: peering@akamai.com 3. Include: your ASN, your traffic volume with them, your location (Raxio) 4. DC operator (Raxio) provisions the cross-connect between your cages Cost: DC cross-connect fee (typically $50–200/month) + zero per-bit cost ``` #### MX204 Config for a PNI ```junos /* PNI — Google direct cross-connect at Raxio */ /* Using xe-0/0/3 for the PNI port */ interfaces { xe-0/0/3 { description "PNI-GOOGLE-RAXIO-10G"; unit 0 { family inet { /* /30 assigned by Google for this link */ address 100.64.x.x/30; } } } } protocols { bgp { group PNI-GOOGLE { type external; peer-as 15169; import PNI-GOOGLE-IMPORT; export PNI-EXPORT; neighbor 100.64.x.x { description "Google-PNI-Raxio-Direct"; /* Higher local-pref than IXP so PNI is always preferred */ /* when both paths exist */ } } } } policy-options { policy-statement PNI-GOOGLE-IMPORT { term accept-google { from { protocol bgp; } then { community add UIXP-PEER; /* reuse same community */ local-preference 300; /* PNI > IXP (200) > Transit (100) */ accept; } } term reject-default { from { route-filter 0.0.0.0/0 exact; } then reject; } term reject-rest { then reject; } } policy-statement PNI-EXPORT { term announce-own { from { protocol [ direct static ]; route-filter YOUR-PREFIX/XX exact; } then accept; } term reject { then reject; } } } ``` --- ### Model 4 — Embedded Cache (Best Economics) The CDN places its own hardware inside your data centre. Your subscribers hit a cache that is physically sitting in your rack. The content never touches any external network link. ``` Your Subscriber │ ▼ Your Core Network │ ▼ CDN Cache Server (in YOUR data centre, in YOUR rack) │ ▼ (cache hit) — content delivered, never left your building Your Subscriber ``` For cache misses (content not yet cached), the appliance fetches from the CDN origin over your existing internet link and caches it for subsequent requests. #### Google Global Cache (GGC) GGC is Google's embedded cache program. Google provides the hardware (or software image for virtualised deployments). You provide: - 1U of rack space - Power (200–300W typically) - 1× 10G port on your network - BGP session to your core router What gets cached: YouTube video, Google Play downloads, Android OTA updates, Chrome downloads, Google Fonts, some Google Search assets. ``` Apply at: peering.google.com → "Embedded Cache Program" Application requires: - ASN - Evidence of traffic volume (traffic graphs, MRTG, etc.) - Data centre details (Raxio address, rack number) - Network diagram showing where GGC connects - Contact for Google NOC to reach during deployment Traffic threshold: approximately 500 Mbps sustained YouTube traffic Timeline after approval: 4–12 weeks for hardware shipping and installation ``` Once installed, GGC announces a /32 or small prefix into your network via BGP. Your recursive resolver (BIND9 on your home servers, later your ISP resolvers) automatically resolves YouTube CDN hostnames (`rr*.googlevideo.com`) to the local GGC IP, making all YouTube traffic local. #### Netflix Open Connect Appliance (OCA) Netflix OCA is arguably the most impactful embedded cache program in the world. Netflix accounts for 10–25% of all downstream internet traffic during peak hours globally. An OCA in your rack means that traffic never hits your transit link. Netflix ships physical appliances — high-density servers with tens of terabytes of SSD storage. Each night, Netflix's software fills the appliance with the most popular content for your region and subscriber base. By 6pm the following evening, 95%+ of your subscribers' Netflix traffic will serve from local cache. ``` Apply at: openconnect.netflix.com Netflix evaluates: - Your subscriber count and estimated Netflix viewership - Your network topology - Data centre quality (power, cooling, physical security) - Your ability to provide 1–10G connectivity to the appliance Traffic threshold: approximately 1 Gbps sustained Netflix traffic Hardware: Netflix ships the appliance. You rack it, cable it, power it. Management: Netflix NOC manages the software remotely. Cost to you: zero. Netflix pays for the hardware, software, and remote management. ``` #### Embedded Cache BGP (same pattern for GGC and OCA) ```junos /* Embedded cache connects to your network on a dedicated VLAN or port */ interfaces { xe-0/0/4 { description "GGC-EMBEDDED-CACHE"; unit 0 { family inet { address 10.254.1.1/30; /* link between your router and the GGC box */ } } } xe-0/0/5 { description "NETFLIX-OCA-CACHE"; unit 0 { family inet { address 10.254.2.1/30; } } } } protocols { bgp { group EMBEDDED-CACHES { type external; import CACHE-IMPORT; export CACHE-EXPORT; /* GGC announces its serving IP — typically a /32 */ neighbor 10.254.1.2 { description "Google-GGC-Cache"; peer-as 15169; } /* OCA announces Netflix serving prefixes */ neighbor 10.254.2.2 { description "Netflix-OCA-Cache"; peer-as 2906; } } } } policy-options { policy-statement CACHE-IMPORT { term accept-cache-routes { from { protocol bgp; } then { local-preference 400; /* highest priority — always prefer local cache */ accept; } } term reject-rest { then reject; } } policy-statement CACHE-EXPORT { /* Caches only need to know your subscriber prefixes to serve them */ term announce-subscriber-space { from { protocol [ direct static ]; route-filter YOUR-SUBSCRIBER-BLOCK/XX orlonger; } then accept; } term reject { then reject; } } } ``` --- ## Part V — Local Preference: The Traffic Engineering Tool Local preference is the BGP attribute that controls how your routers choose between multiple paths to the same destination. Higher local-pref wins. This is how you enforce the priority order of your peering relationships. ``` Local Preference hierarchy (your design): 400 Embedded cache (GGC, Netflix OCA) — in your building, free 300 PNI (private cross-connect at Raxio) — direct, dedicated 200 IXP peering (UIXP) — shared exchange, still free 100 Transit (default) — paid, last resort ``` When Google announces the YouTube CDN prefix to you via all four paths, your MX204 will automatically prefer the embedded GGC cache (400) over the PNI (300) over the IXP session (200) over your transit provider (100). You configure this once in your import policies and it works automatically as you add more peering relationships. ```junos /* Summary of local-pref assignments in your import policies */ /* Transit import — set lowest preference */ policy-statement TRANSIT-IMPORT { term set-lp { then { local-preference 100; accept; } } } /* IXP import — set medium preference */ policy-statement UIXP-IMPORT { term set-lp { then { local-preference 200; accept; } } } /* PNI import — set high preference */ policy-statement PNI-IMPORT { term set-lp { then { local-preference 300; accept; } } } /* Embedded cache import — set highest preference */ policy-statement CACHE-IMPORT { term set-lp { then { local-preference 400; accept; } } } ``` --- ## Part VI — How to Read a Looking Glass Before you call a CDN's peering team, you need to understand where your traffic is going. A Looking Glass is a web interface that lets you run BGP queries against a network operator's routers. Major CDN looking glasses: ``` Google: toolbox.googleapps.com/apps/dig/ Cloudflare: radar.cloudflare.com Hurricane Electric: lg.he.net (very useful for BGP path analysis) RIPE: atlas.ripe.net ``` Use Hurricane Electric's BGP toolkit at `bgp.he.net`: - Look up your own ASN to see what prefixes you are announcing - Look up a CDN's ASN to see their prefix list - Check your BGP path to a CDN to understand how traffic currently flows ```bash # On your MX204, check how a specific CDN prefix is being reached show route 216.58.0.0/16 /* a Google prefix */ show route 157.240.0.0/16 /* a Meta prefix */ show route 23.246.0.0/18 /* a Netflix prefix */ # After peering is established, the output should show: # * = IXP peer or PNI, not transit # local-preference should be 200 or higher ``` --- ## Part VII — Peering Contact Directory When you are ready to establish peering, these are the first contacts: | CDN | Peering Portal | Peering Email | Notes | |---|---|---|---| | Google | peering.google.com | peering@google.com | GGC via embedded cache form | | Meta | peering.fb.com | peering@fb.com | Also handles Instagram/WhatsApp | | Netflix | openconnect.netflix.com | peering@netflix.com | OCA application separate from peering | | Cloudflare | peering.cloudflare.com | peering@cloudflare.com | Self-serve portal — fastest setup | | Akamai | — | peering@akamai.com | They usually initiate contact | | Amazon | — | aws-peering@amazon.com | Also via AWS peering policy page | | Fastly | — | peering@fastly.com | Very responsive | | Microsoft | — | mspeering@microsoft.com | | | UIXP | uixp.ug | info@uixp.ug | Kampala, hosted at Raxio | | KIXP | kixp.ke | noc@kixp.ke | Nairobi, for future expansion | | AFRINIC | afrinic.net | hostmaster@afrinic.net | ASN and PI space requests | --- ## Part VIII — Your Action Plan ### Phase 0 — Confirm prerequisites (this week) ``` □ Confirm SprintUG has an active ASN from AFRINIC If not: apply immediately — this takes weeks and blocks everything else □ Confirm SprintUG has PI IP space from AFRINIC If not: apply alongside ASN application □ Confirm physical port is available on MX204 at Raxio for UIXP fabric The BOM you reviewed has 8× 10G SFP ports — allocate one for UIXP ``` ### Phase 1 — IXP Peering (first 30 days after MX204 installation) ``` □ Apply for UIXP membership at uixp.ug □ Cable xe-0/0/2 (or your designated port) to UIXP fabric at Raxio □ Receive UIXP peering IP assignment □ Configure BGP peer group UIXP-PEERS with import/export policies □ Establish sessions with (in order): 1. Cloudflare (AS13335) — fastest to set up, self-serve portal 2. Google (AS15169) — largest traffic reduction 3. Meta (AS32934) — second largest 4. Netflix (AS2906) — third largest 5. Amazon (AS16509) 6. Akamai (AS20940) □ Verify each session: show bgp summary — all should show "Established" □ Verify traffic is shifting: MRTG/traffic graphs should show transit decreasing ``` ### Phase 2 — Embedded Caches (60–90 days) ``` □ Run DNS analytics for 30 days to build traffic evidence □ Export VIZ-13 provider table as evidence for cache applications □ Apply to Google GGC embedded cache program □ Apply to Netflix OCA program □ When hardware arrives: □ Rack in Raxio cage □ Cable to MX204 (xe-0/0/4 and xe-0/0/5 per the config above) □ Configure BGP sessions in EMBEDDED-CACHES peer group □ Verify local-preference 400 is working □ Monitor cache hit rate (Google and Netflix both provide dashboards) ``` ### Phase 3 — PNI Negotiations (6–12 months) ``` □ After 6 months of IXP peering, review traffic graphs □ Identify which CDN has the most traffic volume □ Email that CDN's peering team with: - Your ASN - 6-month traffic graphs showing sustained volume - Confirmation you are at Raxio - Request for PNI cross-connect □ DC operator provisions cross-connect between cages □ Configure PNI BGP group with local-preference 300 ``` ### Phase 4 — Multi-PoP Expansion (12+ months) ``` □ Extend to KIXP (Nairobi) when SprintTZ or a Kenyan presence is established □ Replicate UIXP peering config at Airtel House MX204 - Airtel House may not have UIXP — use inter-PoP MPLS to route IXP-learned routes from Raxio to Airtel House subscribers □ Evaluate Teraco Johannesburg for South Africa/Egypt reach ``` --- ## Part IX — How Your DNS Analytics Feeds This Your DNS analytics platform becomes your peering intelligence tool. **Before a peering call:** Query your `dns_daily_stats` joined with `domain_categories` to produce a table showing traffic volume by provider over the last 30 days. This is your evidence that you have enough traffic to justify peering. CDN peering teams respond faster when you arrive with data. **After peering:** Add a `peering_path` column to `domain_categories` that marks each provider as `transit`, `ixp`, `pni`, or `cache`. Then your VIZ-13 report shows not just how much traffic each CDN carries, but whether that traffic is free or paid. Your transit bill reduction becomes directly measurable. **The closed loop:** ``` DNS analytics identifies top CDN by traffic ↓ You apply for peering / embedded cache ↓ Peering established — traffic shifts from transit to free path ↓ DNS analytics confirms traffic shifted (same volume, zero transit cost) ↓ You identify next CDN to approach ↓ repeat ``` --- ## Summary | Model | Cost | Latency | Complexity | When to use | |---|---|---|---|---| | Transit | High (per-Mbps) | Highest | None | New network only | | IXP Peering | Port fee only | Low | Moderate (BGP config) | Always — first step | | PNI | Cross-connect fee | Lowest | Moderate (BGP + DC ops) | When volume justifies it | | Embedded Cache | Zero | Near-zero | High (hardware + BGP) | When CDN approves you | The goal is to move as much traffic as possible from Transit → IXP → Embedded Cache. Every megabit that moves left along that table costs you less money and delivers faster content to your subscribers. Your MX204s at Raxio and Airtel House are already the right hardware for this. Your BIND9 + PostgreSQL analytics platform is already the right intelligence tool. The only thing left is executing the peering relationships. ---