[atnog] BFD

[Mario Rosic]

Hallo Dominik,

BFD könnte überall dort nützlich sein, wo nicht automatisch alamiert wird sobald sich auf einem Interface z.B. CRC oder PCS Fehler häufen - und leider haben das nur ganz wenige Netzwerke. LACP ist selbst auf "fast" nicht gut genug, um Packet Loss zu entdecken, den die Server (und die Kunden) jedoch sehr wohl spüren werden.

Leider verliert BFD viel an Nützlichkeit, sobald man eine LAG verwendet: Der Standard spezifiziert nicht, wie mit LAGs umzugehen ist und bei vielen Implementierungen werden die BFD Pakete nur auf einen einzigen Port der LAG gehasht und nur dieser wird überwacht. Deswegen fristet das normale BFD in den meisten Netzwerken ein Nischendasein.

Doch seit Kurzem gibts Micro-BFD. Damit wird bei einem LAG jedes Interface einzeln gemonitort. Bei Packet Loss fällt das defekte Interface aus dem LAG und alles läuft weiter ohne dass die Sysadmins oder Kunden was merken - oder aber das defekte Interface gibt sich durch den Interface Flap als defekt zu erkennen, womit die Fehlersuche stark beschleunigt werden kann. Außerdem kann man bei manchen Implementierungen festlegen, dass nur nachdem Micro-BFD 60 Sekunden lang ohne Packet Loss auf dem Interface gelaufen ist, das Interface wieder ins LAG aufgenommen werden soll. Das (und https://tools.ietf.org/html/rfc5837 ) ist der Stoff aus dem Netzwerkadminträume gemacht sind. :)

Leider hab ichs bei meinem Router-Hersteller nicht geschafft, Micro-BFD konstant so problemfrei zu betreiben wie LACP: Der Hersteller hat aktuell noch zu viele Bugs in der Implementierung bzw. für mich verhält es sich noch zu unzuverlässig beim Testen, als dass ich das ausrollen wollen würde. Dauert wohl noch ein paar Firmware-Releases, bis das anständig läuft.

Liebe Grüße
Mario







On 14.01.19 16:24, Dominic Schallert wrote:
> Liebe ATNog Gemeinde,
>
> verwendet hier eigentlich jemand BFD für Transit- oder Peering-Sessions? So wie ich BFD verstehe, wäre das ja eine gute Sache, nur verwendet es kaum wer. Warum eigentlich? Mögliche Gründe die mir einfallen sind:
>
> 1) Nicht notwendig da beide Router directly connected
> 2) Interoperability-Probleme mit unterschiedlichen Routern
> 3) Kosten für Lizenzierung —> auf Cisco ASR eine AIS/AES Lizenz erfoderlich
> 4) Vielleicht Historisch bedingt?
>
> Bieten die etwas größeren Transits hier in AT (Anexia, Nextlayer, A1, T-Mobile, etc.) ihren Kunden BFD optional an?
>
> Es gibt aktuell übrigens auch ein Proposal für BFD bei IXP Routeservern:  https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/
>
>
> LG
> Dominic
>
>
>
> *schallert​.com e.U.* | Hauptstraße 35b, 6800 Feldkirch, Austria
>  
> FN: 440372g  | UID: ATU66209211 | Gerichtsstand: Feldkirch
>  
> Tel.: +43 680 146 1947 | Fax: +43 134 242 642 616
>
> www.schallert.com <http://www.schallert.com>  | office at schallert.com <mailto:office at schallert.com>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20190114/3909f43c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_email.png
Type: image/png
Size: 2753 bytes
Desc: not available
URL: <http://atnog.at/pipermail/atnog/attachments/20190114/3909f43c/attachment-0001.png>