Vlákno názorů k článku BFD - rychlé zjištění výpadku linky od Dan Lukes - No prave - aby bylo BFD "zbytecne" neb...

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 ...

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).