Edge Cache and CDN Platform  ·  View 21 of 29  ·  6 · Operations

Traffic Steering Controls

Four ways to move traffic, from the whole PoP down to one node, with how fast each works and what it leaves behind.

Editable source SVG draw.io All views
Moves Mechanism Takes effect Tail Pulled by Withdraw a PoP Every property at one PoP BGP withdraw all 4 classes ~30 s BGP convergence In-flight flows break drain first pop-guard · on-call Withdraw a class Properties in a class 1 of 4 prefixes BGP withdraw one prefix ~30 s Same, for one class On-call DNS override One property PowerDNS answer other class address TTL 60 s Resolvers ignore TTL hours On-call + owner Drain a node One node's flows Katran weight 0 Seconds None consistent hash Automation Traffic Steering — Four Controls, Bluntest to Finest One steering intent object compiles into BGP and DNS, so the two mechanisms cannot disagree about where a property belongs. v 1.0 · owner Network Engineering · date 2026-09

Decisions

  • Anycast is the only automatic mechanism. DNS steering is manual and per property, used when anycast is too blunt, for example to move one property's traffic off a PoP that is near its ceiling.
  • Properties are spread across four anycast prefix classes. Withdrawing one class at one PoP moves about a quarter of that PoP's traffic within BGP's own convergence time, without depending on resolvers honouring a DNS TTL.
  • Both mechanisms are compiled from one steering intent per property. On-call never edits DNS and BGP separately, so the two cannot disagree about where a property belongs.

The tail

  • A DNS change has an unbounded tail: some resolvers keep old answers for hours. Nothing time-critical relies on DNS, and a DNS move is always paired with keeping the old address serving until its traffic has decayed.

Omitted

  • Traffic engineering between transit providers through BGP communities is network-team practice and not drawn here.