[atnog] BFD

Rene Avi rene.avi at nextlayer.at
Thu Jan 17 15:02:12 CET 2019


Hallo Dominic, 

Von: <atnog-bounces at atnog.at> im Auftrag von Dominic Schallert <ds at schallert.com>
Datum: Montag, 14. Jänner 2019 um 16:24
An: "atnog at atnog.at" <atnog at atnog.at>
Betreff: [atnog] BFD

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

Bei wirklichem directly connected bevorzugt wir LACP (fast) mit check von jedem Link und lassen BFD wegem mangelnden added benefit vs. complexity.

2) Interoperability-Probleme mit unterschiedlichen Routern

Wir hatten letztens einen Bug (Huawei Ethernet Transportinfrastruktur eines Sublieferanten) wo BFD Echo packets undirektional dropped wurde, async ging und immer wieder Control-Plane-Policies issues.

3) Kosten für Lizenzierung —> auf Cisco ASR eine AIS/AES Lizenz erfoderlich
4) Vielleicht Historisch bedingt?

Sicher auch, wir stellen alte BGP-Session derzeit nicht aktiv um.

Bieten die etwas größeren Transits hier in AT (Anexia, Nextlayer, A1, T-Mobile, etc.) ihren Kunden BFD optional an?

Wir machen BFD auf Anfrage durch den Kunden oder wenn es offensichtlich sinnvoll ist (keine link loss Information durch das Transportnetz dazwischen, ..) und wenn die BGP timer tuning nicht schnell genug für die Anforderungen des Kunden ist. Extra Kosten gibt es sicher keine dafür. Erzeugt ja auch keine (bis auf das bisserl CPU).

An IXPs haben wir relativ selten echte Transport Probleme am IX selbst, mit den großen Peers ebenfalls nicht, tendenziell bei peers mit crappy remote backhaul/router; würden aber sicher bei einer weiteren Verbreitung von BFD mit machen (via RR (draft) macht das inhärent Sinn, aber auch direkt). 

lG, /Rene


-------------- 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/20190117/19a69e63/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4556 bytes
Desc: not available
URL: <http://atnog.at/pipermail/atnog/attachments/20190117/19a69e63/attachment.p7s>


More information about the atnog mailing list