[atnog] VIX Outage

Fri Dec 18 14:13:07 CET 2020

Danke für die Info! Wir verwenden BFD mittlerweile zu allen unseren Transits. Bei IXP Peerings wird BFD aber mW. bisher kaum bis garnicht eingesetzt. Alleine schon da es eine Zeit lang grobe Probleme zwischen den BFD-Implementierungen auf unterschiedlichen Routing-Plattformen von Cisco/Juniper/Nokia/Huawei gab.

Wie alles im Leben hat aber auch BFD div. Nachteile in operativen Betrieb. Z.B. schnell mal was umpatchen geht mit BFD nicht mehr, da die BGP-Session sofort einen teardown hinlegt, was aber ja auch gewollt ist wenn das Forwarding zwischen beiden Routern weg ist ;-) Man muss also vorher entweder die BFD-Session manuell shutten oder das fall-over-bfd beim BGP Neighbor kurzzeitig rausnehmen.

lg
Dominic

> Am 18.12.2020 um 13:24 schrieb Alexander Terczka <alex at mail.at>:
> 
> 
> 
> Aus meiner Sicht war das heutige Problem eher ein Problem der Payload und kein BGP Thema an sich.
> Ich habe in etwa 35% packet loss zu peers und 10% DUPs gesehen. D.h. alle BGP Sessions
> die diesen Packetloss überlebt haben, haben zu payload packet loss geführt. Nicht alle BGP Sessions
> gingen down.
> 
> Das Thema könnte also sein, BGP mit BFD abzusichern. Wie seht Ihr das ?
> 
> lg
> AlexT
> 
> 
>> On 18.12.20 13:14, Dominic Schallert wrote:
>> Spannend, Danke! Mich würde interessieren, welche Konfigurationswerte für BGP Dampening real wirklich Sinn machen. Kenne selber einige ISPs die ihr Dampening sehr strikt konfiguriert haben. Die Default Werte unter Cisco (1000, 15, 750, 2000, 60) finde ich persönlich aber etwas harsch. Ist hier relativ gut erklärt > https://ccieblog.co.uk/bgp/bgp-dampening 
>> 
>> Lg
>> 
>> 
>>> Am 18.12.2020 um 13:02 schrieb Klaus Darilion <klaus.darilion at nic.at>:
>>> 
>>> Wenn wir bei RcodeZero Tests oder Wartungen machen, dann sind wir eigentlich nicht zimperlicht und BGP Sessions werden oft restartet - mir ist dabei aber noch aufgefallen, dass wir dadurch ein Dampening irgendwo ausgelöst hätten.
>>>  
>>> lg
>>>  
>>> Von: atnog <atnog-bounces at atnog.at> Im Auftrag von Dominic Schallert
>>> Gesendet: Freitag, 18. Dezember 2020 12:55
>>> An: Johannes Wagner <j.wagner at netplanet.at>
>>> Cc: atnog at atnog.at
>>> Betreff: Re: [atnog] VIX Outage
>>>  
>>> Hi Johannes,
>>>  
>>> Du meinst Route dampening?  Mein letzter Stand war, dass es mittlerweile nicht mehr so verbreitet und auch heute auch nicht mehr wirklich Best Practice ist. Route dampening wurde ja damals zu einer Zeit eingeführt, als flapping insb. hinsichtlich CPU power auf Routern noch ein echtes Problem war. Mit modernen Routern ist das aber normalerweise nicht mehr so das Problem.
>>>  
>>> Frage in die Runde - verwendet hier jemand BGP dampening und ja mit welchen Parametern (penalty, supress limit, reuse limit, etc.)? Sehen eure Parameter zu Transits/Downstreams/Peers anders aus? Gibt es vielleicht bessere Alternativen zu bgp dampening?
>>>  
>>> Lg
>>>  
>>> 
>>> 
>>> Am 18.12.2020 um 12:41 schrieb Johannes Wagner <j.wagner at netplanet.at>:
>>>  
>>> Hallo,
>>>  
>>> es war ja nicht „ein Ausfall“ das waren viele Flaps und ich schätze nicht jeder hat das in der Config berücksichtigt.
>>>  
>>> Liebe Grüße Johannes Wagner
>>>  
>>> Von: atnog <atnog-bounces at atnog.at> im Auftrag von Dominic Schallert <ds at schallert.com>
>>> Gesendet: Freitag, Dezember 18, 2020 12:36
>>> An: atnog at atnog.at
>>> Betreff: [atnog] VIX Outage 
>>>  
>>> Hallo Liste, 
>>>  
>>> der VIX hatte offenbar kurz vor 12h00 einen gröberen Holperer. Es hat praktisch alle ISPs in AT betroffen. Hier in Vorarlberg waren zeitweise Magenta, A1 und weitere de-fakto komplett offline. Wobei es wohl primär an den Umschaltzeiten (z.B. BGP ohne BFD?) gelegen haben dürfte, da ich schon davon ausgehe, dass es entsprechende Backup-Leitungen gibt.
>>>  
>>> Ich denke man sollte sich an dieser Stelle schon mal die Frage stellen dürfen wie es sein kann, dass eine Störung an einem zentralen Punkt in AT praktisch alle ISPs in Österreich dermaßen runter ziehen kann?
>>>  
>>> <PastedGraphic-2.png>
>>>  
>>> Lg
>> 
>> 
>> 
>> _______________________________________________
>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://atnog.at/pipermail/atnog/attachments/20201218/36d3facd/attachment-0001.htm>