CDN
Cloudflare bietet als "Content delivery network" (CDN) im Internet "Webspeicher" für Webseiten an. Webseitenbetreiber weltweit geben Teile ihrer Seiten an Anbieter wie Cloudflare weiter. Cloudflare wiederum speichert diesen "Content" auf ihrer verteilten Serverstruktur.
Beim Öffnen von Webseiten werden die Dateien von dem Browser per URL direkt vom CDN - Anbieter abgerufen, ähnlich wie bei den eingebetteten YouTube-Videos.
Mit der Kombination aus Netzwerk und Server steht dem CDN - Anbieter die Möglichkeit zur Verfügung, sehr viele Anfragen problemlos bedienen zu können.
Über die gleiche Infrastruktur bietet Cloudflare auch angrenzende Services, wie die Internet-Namensauflösung, an. Cloudflare betreibt dazu den DNS-Resolver 1.1.1.1.
BGP-Routing
Zur Vernetzung der Cloudflare-Rechenzentren untereinander nutzt Cloudflare eigene Datenleitungen. Innerhalb dieses Cloudflare-Netzwerkes erfolgt das Routing via iBGP. Die Abkürzung "iBGP" steht für internal BGP und bedeutet, dass alle Router sich innerhalb einer administrativen Einheit, einer AS, befinden.
An vielen Übergabestellen koppelt Cloudflare sein internes Netz mit dem Internet. Dort erfolgt der Routenaustausch per eBGP. Die Abkürzung "eBGP" steht für external BGP und bedeutet eine Verbindung verschiedener AS und damit die Verbindung von Firmen untereinander.
Cloudflare teilt (propagiert) seine IP-Adressen per eBGP dem Internet mit und der Traffic gelangt so zu Cloudflare. Dann leitet Cloudflare den Traffic intern via iBGP zu den Zielservern weiter.
Wird durch Änderung des internen Cloudflare-Routings der Traffic lediglich zu einer bestimmten Stelle geleitet, kann es zu einer Störung durch Überlastung kommen. Und genau das passierte am 17. Juli 2020.
Störung Cloudflare am 17.07.2020
Die Cloudflare-Router in Atlanta sollten nach einer normalen Leitungsstörung so angepasst werden, dass weniger Traffic nach Atlanta geroutet wird. Das Routing sollte also "schlecht" gemacht werden. Dadurch werden andere Serverstandorte bevorzugt und das Rechenzentrum mit der gestörten Leitung wird entlastet.
Die resultierenden Konfigurationszeilen des für diesen Einsatz bewährten Juniper-Routers sah laut Cloudflare so aus:
from {
prefix-list 6-SITE-LOCAL;
}
then {
local-preference 200;
community add SITE-LOCAL-ROUTE;
community add ATL01;
community add NORTH-AMERICA;
accept;
}Nun entfernte Cloudflare den obersten Präfixlisten-Eintrag, der auf die lokalen Datacenter-Routen filterte.
In Folge traf alles, was in der Präfix-Liste unter "then" steht, auf alle, wirklich auf alle BGP-Routen zu: "local-preference 200".
Die "local-preference" als zweitwichtigster BGP Paramter liegt standardmäßig bei 100 und wird allen iBGP-Routern (transitive) übermittelt.
Der höhere Wert gewinnt und damit kannten alle Cloudflare-Router alle Routingeinträge mit der hohen Präferenz aus Atlanta und überfluten das Datacenter in Atlanta fortan mit Traffic.
Das war zu viel, worauf hin weltweit 50% der Cloudflare-Services für ca. 30 Minuten gestört waren.
Richtig wäre gewesen, den Eintrag "local-preference 200" aus der Route-policy zu entfernen. Damit wären die lokalen IP-Adressbereiche für andere Cloudflare-Router zwar weiterhin sichtbar, aus Routingsicht aber nur "normal" (Preference 100) interessant.
(Anycast: Gäbe es die gleichen IP-Netze bei Cloudflare mehrmals, so würde sich der Traffic gerecht zwischen den Datacentern aufgeteilt haben.)
An dieser Stelle sage ich "Danke!" an Cloudflare für ihre offene Fehlerkommunikation!
In unseren BGP-Workshops und Seminaren greifen wir gerne solche Beispielen mit auf, um die praktischen Auswirkungen anschaulich darzustellen.
Comments