Názory k článku BFD - rychlé zjištění výpadku linky

Ano, BFD je protokol pro P2Plinky.

Ano, Ethernet je sbernice.

Ano, na Ethernet, tedy sbernici, lze pripojit pouze dva body a vytvorit tak P2P linku. Dokonce je to, dnes, ve veku switchu, velmi casty pripad zapojeni ethernetu. Na jednom segmentu pouze dva body ...

až na to, že podle tohoto článku je to protokol fungující na point-to-point linkách. Co z toho, když ethernet je sběrnicová topologie, nebo jakákoliv jiná sběrnicová topologie nebo NBMA?

Pro ethernet se dá na L2 použít třeba STP, pro PPP encapsulované p-t-p linky máme LCP echo a podobně. Ale na druhou stranu, každý takový protokol je pomoc, pokud dokáže detekovat výpadek linky rychleji než směrovací protokol a dá to vědět vyšší vrstvě, aby mohla zareagovat (třeba informovala routovacího démona).

No prave - aby bylo BFD "zbytecne" neb by jeho funkci zastaly routovaci protokoly, muselo by se u nich snizit casovani. Jenze, ony tam prave ty delsi casy, ktere tam jsou, nejsou jen tak pro nic za nic. Nemluve o tom, ze statefull routovaci protokol je uz (jak uz tady padlo) neco, co neni tak uplne nenarocne na zdroje - takze vyuzivat ho na pomerne primitivni vec - testovani pruchodnosti linky - je sice zcela v jeho moznostech, ale dalo by se na to s uspechem pouzit i neco daleko jednodussiho.

Ja nepolemizuji s tvrzenim, ze BFD funkcionalitu nelze ziskat i s pouzitim uz existujicich protokolu a mechanismu. Ja pouze tvrdim, ze v mnoha pripadech to bude neefektivni a proto prichod BFD vitam.

Bavme se o stateful routovacich protokolech. Ty tenhle problem resi - a kdyz se snizi casovani, je tim resitelny i vyse uvedeny problem.

Je sice pravda, ze RIP dela prave to, co rikate, ale podobnost je nedokonala - a stejne nedokonale by pak bylo pouziti RIPu pro naznaceny ucel. Preci jen, RIP je urcen pro resni jineho problemu. Kdybychom ho chteli pouzivat pro neco takovehleho (coz se v teto chvili, kdyz nic jineho neni, skutecne obcas deje) mame problem s tim, ze RIP je proste pomaly. Kdezto, predpokladam, novy protokol bude optimalizovany pro ten ucel, kvuli kteremu vznika. Krome toho, RIP nepocita s "jednosmernymi" vypadku - pokud vam z kabelu zustane funkcni jen jeden jeho smer, tak se prez nej sice skvele bude (od protejsiho routeru) sirit informace o tom, ze zrovna on je "ten nejlepsi", ale proto, ze v opacnem smeru data neprochazeji, budete smerovat veskery tok do "cerne diry". A prostredky RIPu na to rozhodne neprijdete.

Proste - RIP je pekna vec, ale preci jen na neco jineho. Separatni standardizovana metoda pro detekci pruchodnosti linky zatim chybi a mam dojem, ze bude shledana uzitecnou ...

... pana Satrapy si vazim jako odbornika pres Linux a TCP/IP, ale davat za priklad SONET, kdyz nam tady v CR je mnohem blizsi SDH ... ehm ehm ehm :-)

... ale jinak zajimavy clanek ;-)

Smerovaci protokoly (napr. RIP) takto funguji. Kdyz smerovac nedostane vcas informace od sousedniho smerovace a vypadek trva delsi dobu, vyhodnoti linku jako neprostupnou a upravi si smerovaci tabulky. Cekani, zda je vypadek vypadek dlouhodoby je nutny, jinak by smerovace casto menili smerovaci tabulky, provoz na siti by osciloval, pakety smerovaciho protokolu by prilis zatezovali sit a navic vypocet minimalno kostry site, ktery probiha na smerovacich pri kazdem prepoctu smerovacich tabulek je velmi narocny (casto je na to vyhrazen samostatny procesor). Na nejake rychle reakce na vypadek v nespokovanych sitich zapomente. (I prepinana sit konverguje pomerne pomalu).