BFD - rychlé zjištění výpadku linky

Jednou z nejvýznamnějších předností Internetu je, že se dokáže vypořádat s nespolehlivostí sítě. K tomu je ale třeba, aby byl výpadek přenosové trasy pokud možno co nejrychleji zjištěn. Některé technologie (jako třeba SONET) to dovedou zjistit velmi rychle, u jiných (jako třeba Ethernet) trvá odhalení výpadku delší dobu.

Zkratka BFD označuje Bidirectional Forwarding Detection, a jak název napovídá, cílem je rychle ověřit obousměrnou komunikaci mezi dvojicí partnerů. Při jeho návrhu se autoři snažili naplnit především následující požadavky:

  • rychlá detekce výpadků,
  • jednoduchý protokol (aby byl implementovatelný v hardwaru) s nízkou režií,
  • nezávislost na přenosovém systému.

Základní myšlenka je velmi jednoduchá: dva partneři naváží BFD seanci a v jejím rámci si periodicky posílají zprávy. Jestliže po určitou dobu nedorazí od protějšku odpověď, lze linku považovat za přerušenou (a ohlásit to nahoru, aby směrovací algoritmus zareagoval a našel vhodnou alternativu).

Ve skutečnosti je věc o chlup složitější, ale skutečně ne o mnoho. BFD může pracovat v jednom ze dvou režimů:

Asynchronní režim

V něm pracuje tak, jak bylo popsáno výše. Oba účastníci nezávisle na sobě posílají protějšku v určitých intervalech BFD pakety. Výpadek linky poznají podle toho, že pakety přestanou přicházet. V odesílaných zprávách navíc prostřednictvím příznaku „slyším tě“ informují protějšek, zda i ve směru od něj je vše v pořádku. Účastníci tedy zároveň mají zpětnou vazbu, zda jsou jejich BFD zprávy doručovány. Díky tomu lze detekovat i jednosměrné selhání.

Režim na žádost

Tento režim je určen pro případy, kdy partneři mají i jinou možnost, jak ověřit funkčnost spoje (například na základě běžného provozu, který jím prochází). V tom případě se oba mohou dohodnout o přechodu do režimu na žádost, kdy výměna BFD zpráv ustane. Pouze v případě, kdy některý z účastníků pojme podezření, že se spojem není něco v pořádku, a potřebuje ověřit jeho funkčnost, začne vysílat BFD pakety, na které mu protějšek odpoví. Jakmile se tak stane, je linka ověřena a BFD opět umlkne.

K oběma režimům lze navíc přidat funkci ozvěny (echo), při níž protější stroj posílá zpět data, která v BFD zprávách přijal. V takovém případě je ověření provozuschopnosti linky rychlejší, což znamená, že lze snížit frekvenci testovacích paketů (ovšem na druhou stranu jich je dvojnásobek - na každý je třeba odpovědět). Ozvěna má smysl především v asynchronním režimu.

Kýžené jednoduchosti dosahuje BFD především tím, že stanovilo pevný formát zprávy. Veškeré funkce jsou realizovány vhodnou kombinací nastavení jejich položek. Například navázání BFD seance, které je oficiálně prohlašováno za three-way handshake, vypadá takto: Alespoň jeden z partnerů musí při zahájení sehrát aktivní roli. Začne svému protějšku posílat BFD pakety, pro začátek s malou frekvencí. Jeho protějšek, je-li připraven, v reakci na přicházející BFD pakety začne vysílat své vlastní, v nichž nastaví příznak „slyším tě“. Když ty dorazí k iniciátorovi, také on do svých paketů vloží příznak „slyším tě“, čímž oba partneři vědí, že BFD prochází oběma směry a seance je navázána. Následně mohou přejít na (vyšší) provozní frekvenci testovacích zpráv, případně se dohodnout na režimu na žádost či zapnout ozvěnu. To vše prostřednictvím voleb v běžných BFD paketech.

CIF16

Hlavní výhodou BFD je, že nezávisí na přenosovém mechanismu. Můžete je použít k testování ethernetového spoje mezi dvěma sousedními stroji, nebo ověřovat funkčnost tunelu či MPLS trasy. Mezi stejnými dvěma stroji může probíhat několik nezávislých BFD seancí pro různé úrovně komunikace. BFD může (a mělo by) být implementováno nezávisle na řídicí rovině, čili na směrovacích mechanismech, kterým pak poskytuje cenné (protože rychlé) informace. Zkrátka jednoduchý, nenáročný a univerzální pomocník.

Největší zápor BFD spočívá v tom, že dosud není hotovo. Zatím se nachází ve fázi návrhu a IETF momentálně zvažuje založení nové pracovní skupiny, která by měla na starosti jeho vývoj. Jak už to tak bývá, tato nevýhoda není na překážku implementacím. Vzhledem k tomu, že BFD je společným dítkem Juniper Networks a Cisco Systems, jdou tyto dvě společnosti v čele implementačních snah. Juniper jej zařadil do JunOSu od verze 6.1, u Cisca se pravděpodobně dočkáme v dohledné době.

Anketa

Považujete BFD za užitečný mechanismus?

7 názorů Vstoupit do diskuse
poslední názor přidán 10. 6. 2004 1:55

Čtěte dále