[atnog] VIX Outage

[Rene Avi]

Hallo Fritz, 

vorweg, das war der erste Ausfall vom VIX (abseits von single-port-issues) seit vielen Jahren. Es gibt wenig Infrastruktur die so eine Verfügbarkeit liefert und neue, diesen Fehler verhindernde HW ist am Weg habe ich verstanden. 

Der Verkehr hatte bis auf Ausnahmen ja genug Ersatzpfade und Kapazitäten sei es über andere IXes, PNIs oder notfalls Upstreams sobald die Erkennung, Umschaltzeit auf alternative Routen inkl. Netzstabilisierung (forwarding-plane-updates) abgeschlossen ist. Die standard BGP hold-time-values stammen aus den 90ern, BFD hat(te) seine eigenen challenges (multi-vendor, async/echo, RS-usage (hallo Arnold!), ..), die alternativen Pfade stehen vielleicht mangels bgp-add-path oder dgl. nicht überall sofort bereit, manche vermuten in ein BGP-flap-dampening gefallen zu sein, ..

IMHO war die Störung bedingt durch die holprigen Umschaltungen und nicht durch fehlende Redundanz.

Cheers, /Rene

Am 21.12.20, 10:22 schrieb "atnog im Auftrag von Thomas Fritz" <atnog-bounces at atnog.at im Auftrag von thomas.fritz at rheintal-ix.net>:

    Hallo!

    Vielen Dank für die Offenheit und den Einblick in die Ursache des Problems.

    Das eigentliche Problem aber, das sich heute offenbarte, war meiner Meinung nach nicht die unglücklich herbeigeführten Störung an der Switching Plattform des VIX.

    Ich finde die Tatsache, dass diese Störung solche Auswirkungen bei zahlreichen Kunden der national tätigen Access-Providern hatte, viel bedenklicher.
    Es wäre den Internetkunden in Österreich zu wünschen, dass dieser Zwischenfall die entsprechenden Verantwortlichen zu einem Überdenken ihrer Peering Policy anregt.

    Ein zweiter Aspekt drängt sich mir auch noch auf:
    Wenn der VIX im Zuge der Netz- und Informationssystemsicherheits-Verordnung vom Büro für ebendiese Sicherheit des Bundeskanzleramts richtigerweise als "wesentlicher Dienst" eingestuft wird,
    wieso wird dann dort nicht gesehen, dass es doch auch nach einer Redundanz für einen solchen wesentlichen Dienst verlangt?

    Beste Grüsse,
    Thomas Fritz
    Rheintal IX


    > On 18.12.2020, at 17:41, Christian Panigl, UniVie/ACOnet/VIX <Christian.Panigl at UniVie.ac.at> wrote:
    > 
    > Liebe ATNOG Mitglieder,
    > 
    > eine Fehleranalyse betreffend die Probleme am VIX heute Mittag (im Zeitraum ca
    > 11:45-12:00) ging ja bereits an die VIX-Teilnehmerliste.
    > 
    > Kurz gesagt, diese Störung, ausgelöst durch ein Zusammentreffen unglücklicher
    > (Konfigurations-)Umstände, hat zu Packetloss und auch zu BGP-Resets am VIX geführt.
    > 
    > Mit und ohne Flapdamping können solche Situationen leider zu schlechtem
    > Konvergenzverhalten führen und damit die Nutzung funktionierender
    > Alternativpfade stark verzögern oder sogar verhindern.
    > 
    > BFD wäre sicher einen Blick wert, allerdings ist die Frage, wie gut das in einem
    > multilateralen Peering-Setup überhaupt funktioniert / funktionieren kann,
    > abgesehen von der Vendor-Kompatibilität.
    > 
    > Ich möchte mich an dieser Stelle nochmal für die entstandenen Unannehmlichkeiten
    > entschuldigen und hoffe, dass wir mit der neuen Switch-Plattform am VIX im
    > nächsten Jahr auch gegen solche rare "Unfälle" noch besser gerüstet sind.
    > 
    > Die besten Wünsche für einen geruhsamen Jahresausklang, Gesundheit und
    > Zuversicht für 2021!
    > 
    > Liebe Grüße
    > Christian Panigl
    > 
    > -- 
    > 
    > Christian Panigl
    > Abteilungsleiter ACOnet & Vienna Internet eXchange
    > 
    > T: +43 1 4277 14032
    > 
    > www.ACO.net  |  www.VIX.at
    > 
    > Team/Office: +43 1 4277 14030
    > 
    > Zentraler Informatikdienst
    > http://zid.univie.ac.at
    > 
    > Universität Wien
    > Universitätsstraße 7
    > 1010 Wien
    > 
    > -- 
    > _______________________________________________
    > atnog mailing list
    > atnog at atnog.at
    > https://atnog.at/mailman/listinfo/atnog

    _______________________________________________
    atnog mailing list
    atnog at atnog.at
    https://atnog.at/mailman/listinfo/atnog
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5308 bytes
Desc: not available
URL: <http://atnog.at/pipermail/atnog/attachments/20201221/b13ec24c/attachment.p7s>