News Fehler behoben: Facebook, WhatsApp und Instagram sind wieder online

[textract]

Klingt irgendwie als hätte da jemand STP abgeschaltet.

 

[Web-Schecki]

Eine urbane Legende, die von Facebook selber erfunden wurde und existiert, damit der Überwachungswahn des Verrückten auf seinem Zuckerberg, klein geredet werden kann.

Nein, das ist keine urbane Legende, sondern ein technischer Fakt - wenn bei der Beantwortung der Requests zu Facebook aus Europa irgendwelche Server in den USA beteiligt wären, dann wäre die Latenz so hoch, dass es praktisch unbenutzbar wäre.
Dass Daten unabhängig von einem einzelnen Request in die USA synchronisiert werden, ist völlig unbestritten.

Du darfst aber gerne glauben, dass Facebook in Europa noch funktionieren würde, wenn man in Kalifornien alles abschaltet oder in die Luft sprengt.

Das ist technisch eine vollkommen andere Frage. Aber ja, die Server könnten auch unabhängig von Kalifornien Requests beantworten. Wahrscheinlich würden nach einiger Zeit Probleme auftauchen, weil intern die Daten nicht synchronisiert werden können wie gewohnt, Queues volllaufen etc. Aber da kann ich als Außenstehender nur spekulieren. Mit Sicherheit wird aber der Ausfall eines einzelnen Rechenzentrums nicht weltweit alles lahmlegen.

Wenn du alle Postings lesen würdest wäre es sogar für dich verständlicher...

Ich habe tatsächlich alle Posts gelesen und ich verstehe es trotzdem nicht. Erleuchte mich. Was für Befehle und Ziele meinst du?

Er wollte nur davon ablenken das er das mit Kalifornien nicht versteht und das die dort lokal wieder auf die Server müssen.

Das ist erstmal wieder eine Unterstellung, mehr nicht. Kannst du sie auch belegen?
Seine Argumentation war, dass die Wiederherstellung der Routen weltweit koordiniert geschehen muss, was auch vollkommen nachvollziehbar ist - die Router in Kalifornien bringen uns in Europa erstmal nicht so viel.

dann wurde da echt ein Team hin geschickt um die Server neu zu starten.

Diese Aussage hier war technisch nicht korrekt - womöglich mussten zwar auch Server neugestartet werden, aber das allein hätte nichts gebracht. Aufgrund einzelner Server fällt auch nicht weltweit facebook aus. Der springende Punkt ist: Nur in Kalifornien irgendwas zu reparieren hätte eben auch nichts geholfen, siehe oben. Darauf ist @foo_1337 eingegangen. Nirgendwo hat er behauptet, man müsse nicht auch vor Ort am Problem arbeiten, im Gegenteil.

und bei google kannst du meines Wissens nach das halbe Internet lahm legen und du wirst immer noch auf deine Cloud zu greifen können, da die alles dreifach spiegeln und auf jedem Kontinent unabhängig voneinander erreichbar ist.

Soweit ich weiß läuft das tatsächlich alles über Kalifornien, das ist sogar bei google so, nur haben die mehrere ausfallsichere RZ.

Hier vergleichst du technisch absolut unfundiert google mit facebook. Du suggerierst, bei facebook würde nichts georedundant gespiegelt werden, sie wären nicht unabhängig auf den Kontinenten erreichbar und sie hätten nicht mehrere ausfallsicheren Rechenzentren. Kannst du das belegen?
Danach ging es los mit der bereits diskutierten Behauptung, bei traceroute würden mehrere Hops in Kalifornien auftauchen und es würde hin und hergehen, was schnell widerlegbarer Blödsinn ist. Damit hast du scheinbar versucht, die unklare Behauptung, alles würde über Kalifornien laufen, zu untermauern.
Ja, organisatorisch läuft sicherlich alles über Kalifornien. Technisch aber nicht. Das Problem bestand nicht nur in Kalifornien, sondern weltweit. Wenn in Kalifornien ein Router ausfällt, dann funktioniert facebook trotzdem, lediglich lokal kann es kurz Probleme geben.

 

[AAS]

Klingt irgendwie als hätte da jemand STP abgeschaltet.

BGP-Fehlkonfiguration, Alptraum jedes Datacenterbetreibers.
War eigentlich sofort klar.

Ergänzung (5. Oktober 2021)

Ist doch schön, wie komfortabel DNS ist. Man stelle sich vor, man würde hardcodierte IPs verwenden

Informier dich wie BGP funktioniert, da hätte dir auch die IPs nicht weitergeholfen,
weil zu den IPs keine Routen existieren.

 

[KitKat::new()]

wenn bei der Beantwortung der Requests zu Facebook aus Europa irgendwelche Server in den USA beteiligt wären, dann wäre die Latenz so hoch, dass es praktisch unbenutzbar wäre.

gerade mal Facebook angesurft - bei mir dauern einige Requests durchaus 200-3000ms (ca. 10-20 stück).
Andere gehen in 9ms durch.

 

[foo_1337]

gerade mal Facebook angesurft - bei mir dauern einige Requests durchaus 200-3000ms (ca. 10-20 stück).
Andere gehen in 9ms durch.

Und welche sind das? Und von was sprichst du jetzt? TTFB oder die totale Zeit des Requests? Wie groß war, falls es ein GET war die Payload? Hostname dahin? Was sagt ein (tcp)traceroute dahin? Wie gesagt, da schlägt normalerweise* nichts von dir direkt nach USA durch. Das wäre aus Webapp sicht total dämlich, das zu tun.
Und wie schon oft geschrieben: Natürlich landen deine Daten in den USA. Und nicht nur da Aber eben nicht direkt via deines Clients, sondern schön via Message Queues, Replizierungen etc. Das ganze ist sehr komplex, aber sorgt halt dafür, dass du selbst eine niedrige Latenz hast, da du alles geolokal geserved bekommst.

*Falls hier was ausfällt, ist das natürlich als failback so.

Ergänzung (5. Oktober 2021)

Klingt irgendwie als hätte da jemand STP abgeschaltet.

Facebook und viele andere moderne Rechenzentren nutzen längst kein STP mehr. Das wurde durch Leaf & Spine obsolet und das ist auch gut so
Mit dem Problem hier hätte das aber ohnehin nichts zu tun, da es ein BGP Problem war. STP ist rein Layer 2 und auf eine Location beschränkt.

 

[Erzherzog]

Diese Aussage hier war technisch nicht korrekt - womöglich mussten zwar auch Server neugestartet werden, aber das allein hätte nichts gebracht.

Was genau soll daran "technisch" nicht korrekt sein? Das ist einfach nur eine Aussage. Ich habe nirgends von einer Komplettlösung gesprochen. Du hast surreale Vorstellungen und implizierst ich sei Techniker und hätte das Problem gelöst. Ich habe dagegen nur Medienberichte zitiert, was du gesehen hättest, wenn du es tatsächlich gelesen hättest.

Nirgendwo hat er behauptet, man müsse nicht auch vor Ort am Problem arbeiten, im Gegenteil.

Er hat gemeint es ist gar nichts aus Kalifornien. Merkst eigentlich selber das du mir andersrum den gleichen Unsinn unterstellst?

Nein, das ist keine urbane Legende, sondern ein technischer Fakt - wenn bei der Beantwortung der Requests zu Facebook aus Europa irgendwelche Server in den USA beteiligt wären, dann wäre die Latenz so hoch, dass es praktisch unbenutzbar wäre.

Du weist aber schon wie Netzwerke konfiguriert werden wenn die Routen down sind? Das wird natürlich zentral gesteuert und dann ausgerollt. Genauso wie aus Kalifornien die Data Center angesteuert werden.

Hier vergleichst du technisch absolut unfundiert google mit facebook. Du suggerierst, bei facebook würde nichts georedundant gespiegelt werden, sie wären nicht unabhängig auf den Kontinenten erreichbar und sie hätten nicht mehrere ausfallsicheren Rechenzentren. Kannst du das belegen?

Das ist nicht meine Behauptung. Pech für dich. Technisch unfundiert ist höchstens das du nicht verstehst warum ich Facebook und google verglichen habe. Denen ist das nachweislich nicht passiert.

Übrigens, es wird nicht besser wenn du sogar noch offensichtlich darstellst das du gar nicht weist was technisch gestern gemacht wurde. Du weist (vielleicht) was passiert ist, aber was gemacht wurde steht sogar auf bild.de besser erklärt als du das kannst. Und lass es doch hier einfach nur Unterstellungen und persönliche Attacken zu fahren, mehr machst du doch auch nicht. Ich bin nicht dein Admin und wie ich zu meinen Aussagen gekommen bin habe ich mit Quelle belegt.

 

[foo_1337]

Er hat gemeint es ist gar nichts aus Kalifornien.

Ah ja. Wo denn?

Ergänzung (5. Oktober 2021)

aber was gemacht wurde steht sogar auf bild.de

Oh je. Auf ein neues. Kann man unkommentiert so stehen lassen, denn es sagt alles aus.

 

[KitKat::new()]

Und welche sind das? Und von was sprichst du jetzt? TTFB oder die totale Zeit des Requests? Wie groß war, falls es ein GET war die Payload? Hostname dahin? Was sagt ein (tcp)traceroute dahin? Wie gesagt, da schlägt normalerweise* nichts von dir direkt nach USA durch. Das wäre aus Webapp sicht total dämlich, das zu tun.

Warum wäre es dämlich?
Nicht alle Daten müssen sofort da sein.
Groesse: wenige kb
TTFB

hosts sind facebook.com (ajax, graphql), scontent-frt3-1.xx.fbcdn.net, content-frx5-1.xx.fbcdn.net, static.xx.fbcdn.net und andere

 

[foo_1337]

hosts sind facebook.com (ajax, graphql), scontent-frt3-1.xx.fbcdn.net, content-frx5-1.xx.fbcdn.net und andere

Liegt alles lokal bzw. in deiner Nähe. Es wäre dämlich, unnötige und langsame Abhängigkeiten zu schaffen, die nicht sein müssen. Schau dir mal an, was Facebook (und andere) für Efforts treiben, damit die Daten eben so schnell wie möglich bei dir sind. Wieso sollte man dann so blöd sein und einzelne Requests über potentiell congested übersee Links jagen, wenn es nicht sein muss?
Aber vielleicht habe ich da auch einfach eine andere Blickweise, da ich aus einem Bereich komme, bei dem die Kunden dafür bezahlen, dass die Latenz zum Enduser so niedrig wie möglich ist und jegliche erdenkliche Maßnahme dafür getroffen wird

 

[KitKat::new()]

Wieso sollte man dann so blöd sein und einzelne Requests über potentiell congested übersee Links jagen, wenn es nicht sein muss?

aber mit den Latenzen ist durchaus übersee möglich und unbenutzbar ist FB deswegen wohl nicht

static.xx.fbcdn.net

löst nach Los Angeles auf

 

[Gamefaq]

Ist alles nicht so Schlimm. Es gibt ein Leben nach Facebook, WhatsApp und Instgramm.
Und das Leben ist schön. Endlich mal wieder analog mit dem Nachbarn klönen.

Da sieht man mal wieder was passiert wenn es ein Monopol gibt weil alles einer Firma gehört. Ohne die Konkurrenz von Twitter hätte keiner gewusst was los ist weil eine telefonische Anfrage der Redaktionen nicht möglich ist und die Mail Ein/Ausgangsserver ja auch vom Ausfall betroffen waren.

Passend dazu fällt mir das ein:

 

[cryoman]

Hier noch mal von Cloudflare sehr schön erklärt ...... also wer von Fach ist.
Ich bin nicht so der große Netzwerker. 🙈 .... Naja, den Montag gestern, wird Fratzbook jedenfalls nicht so schnell vergessen . . . 😂😂😂 .... nur so viel, es fing nach einem "Update" an . . 😱 😂

Understanding How Facebook Disappeared from the Internet​

https://blog.cloudflare.com/october-2021-facebook-outage/


Greetz & stay frosty! ^^

 

[foo_1337]

static.xx.fbcdn.net
löst nach Los Angeles auf

Nope. Es ist ein CNAME auf scontent.xx.fbcdn.net. Und der löst hier (DTAG, aber eigener resolver) auf 185.60.216.19 auf: Latenz:

% ping 185.60.216.19 PING 185.60.216.19 (185.60.216.19): 56 data bytes 64 bytes from 185.60.216.19: icmp_seq=0 ttl=56 time=5.859 ms 64 bytes from 185.60.216.19: icmp_seq=1 ttl=56 time=6.029 ms
-> Lokal.

Nutze ich den Cloudflare DNS, welcher geolocation nicht so recht kann, zeigt der A Record auf 31.13.92.14. Und auch das:
% ping 31.13.92.14 PING 31.13.92.14 (31.13.92.14): 56 data bytes 64 bytes from 31.13.92.14: icmp_seq=0 ttl=56 time=6.573 ms 64 bytes from 31.13.92.14: icmp_seq=1 ttl=56 time=7.118 ms

Nehmen wir noch nen anderen ISP aus D:
$ host static.xx.fbcdn.net static.xx.fbcdn.net is an alias for scontent.xx.fbcdn.net. scontent.xx.fbcdn.net has address 157.240.20.19 scontent.xx.fbcdn.net has IPv6 address 2a03:2880:f01c:8012:face:b00c:0:3 $ ping 157.240.20.19 PING 157.240.20.19 (157.240.20.19) 56(84) bytes of data. 64 bytes from 157.240.20.19: icmp_seq=1 ttl=252 time=1.38 ms 64 bytes from 157.240.20.19: icmp_seq=2 ttl=252 time=1.39 ms

Und auch von der DTAG via v6:
16 bytes from 2a03:2880:f02d:12:face:b00c:0:3, icmp_seq=0 hlim=56 time=6.765 ms 16 bytes from 2a03:2880:f02d:12:face:b00c:0:3, icmp_seq=1 hlim=56 time=6.137 ms 16 bytes from 2a03:2880:f02d:12:face:b00c:0:3, icmp_seq=2 hlim=56 time=6.283 ms

aber mit den Latenzen ist durchaus übersee möglich und unbenutzbar ist FB deswegen wohl nicht

Natürlich ist es nicht unbenutzbar. Aber man will ja die Experience so gut wie möglich machen. Wenn es danach ginge, bräuchten wir ja keine globalen CDN. Und ich wäre arbeitslos. Und das würde wohl wirklich niemand wollen, denn sonst würde ich noch öfter hier rumhängen und dumme Kommentare schreiben

Ergänzung (5. Oktober 2021)

Ich bin nicht so der große Netzwerker. 🙈

Wenn du Fragen hast - feel free!

 

[AAS]

Und welche sind das? Und von was sprichst du jetzt? TTFB oder die totale Zeit des Requests? Wie groß war, falls es ein GET war die Payload? Hostname dahin? Was sagt ein (tcp)traceroute dahin? Wie gesagt, da schlägt normalerweise* nichts von dir direkt nach USA durch. Das wäre aus Webapp sicht total dämlich, das zu tun.
Und wie schon oft geschrieben: Natürlich landen deine Daten in den USA. Und nicht nur da Aber eben nicht direkt via deines Clients, sondern schön via Message Queues, Replizierungen etc. Das ganze ist sehr komplex, aber sorgt halt dafür, dass du selbst eine niedrige Latenz hast, da du alles geolokal geserved bekommst.

*Falls hier was ausfällt, ist das natürlich als failback so.

Top Erklärung. CDN ist bei so Mega-Diensten manchmal auch noch ein Thema, aber ich denke, das meinst du mit etc.

 

[Salamimander]

DNS Geolocation war mein größtes Problem beim einrichten des Hyperlocal, konnte es aber final lösen. (Betraf netflix sowie IPv6.. Wurde mit unbound als hyperlocal unbenutzbar)

Edit: Falls auch mal wer darüber stolpert:

module-config: "subnetcache validator iterator"
#ECS Support
client-subnet-zone: "."
client-subnet-always-forward: yes
send-client-subnet: 0.0.0.0/0
send-client-subnet: ::0/64

Das ist alles.. Kleine Änderung, großer Erfolg

 

[Web-Schecki]

Was genau soll daran "technisch" nicht korrekt sein?

Ein Serverneustart behebt das grundlegende Problem nicht. Umgekehrt, wenn das grundlegende Problem behoben ist, dann kann man die Server, bei denen das nötig ist, auch wieder aus der Ferne neustarten.

Ich habe dagegen nur Medienberichte zitiert

Wenn die Bild es so darstellt, als sei ein Serverneustart vor Ort nötig gewesen, um das grundlegende Problem zu beheben, dann ist das nunmal nicht korrekt.
Dass du diesen Bild-Blödsinn zitierst und andere als naiv bezeichnest - genau mein Humor...

Du weist aber schon wie Netzwerke konfiguriert werden wenn die Routen down sind? Das wird natürlich zentral gesteuert und dann ausgerollt. Genauso wie aus Kalifornien die Data Center angesteuert werden.

Was hat das damit zutun, dass Requests lokal beantwortet werden und nicht aus Kalifornien?

...

Du hast Recht, mit asynchronen Requests etc. könnte man da sicher hohe Latenzen zum Teil auch ganz gut verbergen, aber es wird im Normalfall trotzdem nicht gemacht, weil es ineffizient und teuer wäre und ab einer gewissen Nutzerzahl auch nicht mehr funktioniert. Alle genannten Adressen erreiche ich übrigens in 13ms, also da ist auch (bei mir) nichts in Kalifornien involviert.

 

[KitKat::new()]

-> Lokal.

hab einen IP locator genutzt - weniger zuverlässig als man denkt
https://tools.keycdn.com/geo?host=2a03:2880:f0ff:c:face:b00c:0:3

 

[foo_1337]

hab einen IP locator genutzt - weniger zuverlässig als man denkt
https://tools.keycdn.com/geo?host=2a03:2880:f0ff:c:face:b00c:0:3

Naja, das ist aber leicht erklärbar: BGP Anycast. Die selbe IP kann mittlerweile weltweit eingesetzt werden. Das Target ist aber jeweils ein anderes. Kannst du mit der genannten IP sehr gut mit diversen Looking Glass auf der Welt nachvollziehen. Prominente Beispiele sind hierfür z.B. auch die Resolver 8.8.8.8 oder 1.1.1.1, die weltweit die selbe IP haben aber hunderte verschiedene Nodes antworten werden.
Keycdn benutzt halt hier lediglich die ARIN informationen, was in solchen Fällen nicht hilfreich ist.

 

[Tritom73]

Lieber Gott, gib uns unser täglich Facebook und Co. denn ohne spüren wir unsre grosse Verzweiflung ;-)

 

[markox]

Dafür gibts Alternativen, die ähnlich funktionieren: Matrix (eher neuer) und XMPP (wurde früher viel benutzt).

Nachteil: Verbreitung

Meinetwegen auch das. Was die Verbreitung angeht braucht es einfach einen großen Vorreiter wie Google der damit anfängt und vorlegt wie so etwas aussehen kann. Beziehungsweise doch erst noch mal einen großen Branchenverband der sich auf ein gemeinsames Standard-Protokoll einigt und dieses zusammen voran treibt.