analoges sehe ich beim Mailserver, kaum Versuche via IPv6 was abladen zu wollen, fast durchgehend per IPv4;
Kan ich nicht bestätigen. Sowohl privat als auch geschäftlich wird Mail mittlerweile viel per IPv6 eingeliefert.
Versuchter Spam und Bots kommen per IPv4, aber die zählt man ja nicht ....
Hast du an dem Link, an welchem die Switches angebunden sind, mal einen Client angebunden und getestet, ob dieser eine Adresse erhält?
Hin- und Rückroute müssen sich ja darüber im Klaren sein, dass eine IX jetzt nicht mehr verfügbar ist. Das propagiert sich ja nicht in die vorherigen Router
Das muß sich in allen Routern propagieren. Man muß natürlich immer davon ausgehen, einen Link, Router oder einen IX oder Transit Link verlieren zu können. Dies das darf das IGP nicht in Probleme bringen.
Wenn mit den Announcements gespielt wird, hast du Recht, dann wird es gefährlich, wenn Links ausfallen, auf welchen diese spezifischen Announcements propagiert werden.
Idealerweise sollte hier eher mit Kosten, für den Weg nach aussen und AS Path prepending für den Rückweg gearbeitet werden, dann passiert hier auch nichts.
Allokierte Prefixe in den Announcements zu splitten, gehört sich nicht 
oder anderst herum, wenn wer Prefixes in der Global Routing Tabel verliert, weil Links ausfallen, dann ist das wie, wenn man kein Mitleid hat, wenn kein Backup vorhanden ist ...
H6G ich verlager unser Thema mal hier her, denke das ist in deinem Interesse.
Naja... https://twitter.com/zille3000/status/1139166129451126784
Ehe die davon Wind bekommen. Einmal war auch das Peering zu Facebook weg.
Dauert ewig, bis da wieder alles geht und der 1st Level Support weiß eh nicht, was Peering überhaupt ist.
Die wissen nichtmal, welche Tickets sie überhaupt erstellen müssten. Ist die Kundenleitung okay, kann der 1st Level nichts mehr machen.
Naja, nur weil Vodafone hier manche Probleme haben mag, kann man dies nicht verallgemeinern. BGP kümmert sich ums Umrouten. Wenn hier was schief geht, dann sind es Fehlkonfigurationen, welche im Vorfeld bereits vorhanden sind.
Decix hat aktuell 935 angebundene ISPs, wovon ein großteil auch an dem ein oder anderen großen europäischen IX angebunden ist, was just zu einem ruckeln und Umrouten führen würde - Netcup selbst ist, auf den ersten Blick an Decix, N-IX & VIX direkt angebunden, plus der Anexia, hier würde die Liste ein wenig unübersichtlich.
heist dann im Umkehrschluss, die waren zu faul das noch vor Weihnachten zu erledigen?
Man sollte wohl auch die aktiven Zertifikate berücksichtigen und nicht nur die FQDNS ...
Abgesehen davon sind auch die Domains ähnlich rückläufig gewesen und ohne zu wissen, um was es sich hier genau gehandelt hat, lässt sich kein wirkliches Urteil bilden.
Ohne genauere Daten ist dies schwer zu bewerten.
Ganz einfache Idee könnte, dass irgend ein größeres Hoster von Certbot auf arme.sh umgestiegen ist und hier plötzlich alte Zertifikate einfach ausgelaufen sind, welche im Zuwachs nicht wirklich aufgefallen sind.
CF weiß wo wir surfen (weil ja alle 1.1.1.1 für DNS benutzen) und "managen" all unseren Trafik.
Wie kommst du auf die Information, dass ja alle 1.1.1.1 als DNS Cache verwenden?
Halbes Internet Down geht auch via: AWS Down; DECIX Down etc. pp. Dafür braucht man nicht Cloudflare.
Decix würde zwar einen sehr markanten Impact haben, in diesem Ausmaß müsste hier aber viel passieren, dass hier ein 100% Totalverlust eintritt. Entsprechende ISPs sollten doch auch andere Uplinks - Transit oder Peering (Linx, Amsix, Swissix, VIX, etc) besitzen, um dies zu kompensieren. Der interessante Faktor wäre hier eher, wie sich der Traffic auf die ganzen anderen IX verteilt.
AWS hingegen hätte vermutlich einen massiven Impact auf Webservices.
Dem widerspricht aber diese Aussage.
Ich denke gesendet wurden diese vom Server, da in der Postausgangskontrolle von Netcup 200 Mails von gestern drin stehen.
Ok, ich seh schon, hier wird, mal wieder, nichts konstruktives draus.
mainziman in deiner Welt ist IPv6 gescheitert, dann wird das schon stimmen. IPv4 scheint ja perfekt umgesetzt zu sein, dann sei damit zufrieden.
schon mal versucht, SLAAC nur f. eine echte Teilmenge Deiner Broadcast-Domain zu definieren?
Hierfür ist SLAAC doch auch nie vorgesehen gewesen, nimm dhcpv6.
Das ist jetzt aber kein Fakt gewesen, wieso die Umsetzung von IPv6 schlecht sein soll.
ich habe nicht gesagt dass das schlecht ist, aber die Umsetzung des zu IPv4 erweiterten Adressraums ist schlecht;
Dann nenn doch bitte mal Fakten hierzu.
und das kann dann auch ein Rindviech, pardon dessen Ohrmarke in Form eines pingbaren GPS-Trackers sein
Und das ist schlecht weil?
Wenn dir NAT so gefällt, das kannste auch bei IPv6 machen .... 
Kurzum SSH will ich auf IPv4 auf meinen Servern dauerhaft closen, auch so zeimlich jeden anderen Port mit ausnahme HTTP, Mail und FTP.
Das ändert doch nichts am Problem ....
Setz auf Zertifikate oder MFA für den Login, das bringt dann auch was.
Frohes Neues!
Der Grund ist folgender: Man muss einfach ein DNS Server nehmen der schneller die Einträge aktualisiert als der DNS von Provider.
Die Google DNS Server halten sich eigentlich sehr genau an TTLs. Evtl. wird deine Domain vom Google Cache nur selten aufgelöst und ist daher bei deinen Tests einfach nicht im Cache vorhanden
halunke ich meinte nicht was theoretisch in einem RFC steht, sondern ein reales Vorkommen.
Abgesehen davon sorgt auch die Verwendung von "may" hier nicht dafür, dass ich die TTL ändern darf, sondern es überlassen wird, ob gecached wird, oder nicht - und das ist mal komplett was anderes.
aber nicht jeder Nameserver/Internet-Provider/Browser/etc. hält sich an die TTL, also solltest du keine Wunder erwarten
Gibts dazu eigentlich irgendwo etwas, das dies bestätigt? Wird immer wieder behauptet, aber ich konnte das noch nie beobachten.
Abgesehen davon wird dann auch versucht, dass zwei Scheduler versuchen CPU Ressourcen zu verteilen, wovon der zweite keine Ahnung hat.
Sendmail.
Nach wie vor.
Das kann ALLES!
Wenn man es kann.
Bei Sendmail geht es nicht um können. Man sollte berücksichtigen, dass Sendmail extrem schlecht gewartet und ultimativ veraltet ist ...
