OSPF DR și BDR: alegerea aparține interfeței

Rolurile OSPF se leagă de interfețe, nu de șasiu. Același echipament poate fi routerul desemnat în segmentul său LAN și nimic special într-un tunel, iar aceste două fapte nu se contrazic. Citirea rolului de la interfața greșită este cel mai frecvent motiv pentru care un hub pare configurat greșit în timp ce se comportă exact cum a fost proiectat.

Comparația care contează este între rolurile dintr-un segment și rolurile de-a lungul unui router, și între ce face o rezervă și ce nu face.

O alegere pe segment

RFC 2328 alege un router desemnat și un router desemnat de rezervă pentru fiecare rețea broadcast sau NBMA, nu pentru un router și nu pentru o zonă. Fiecare interfață care participă la o astfel de rețea își ține propria alegere cu propria prioritate și propriul set de vecini. Un șasiu cu trei astfel de interfețe poate avea trei roluri diferite simultan, de aceea afirmația că hub-ul este DR este incompletă până când segmentul nu este numit. Citește rolul din ieșirea de vecini a acelei interfețe.

Două interfețe în aceeași zonă sunt tot două alegeri. Apartenența la zonă nu le contopește.

Ce face rezerva cât timp așteaptă

Un router desemnat de rezervă este complet adiacent cu routerele din segmentul său și își ține baza de date sincronizată ca să poată prelua fără să se formeze o adiacență nouă. Ce nu face în rolul de rezervă este să genereze network-LSA a acelei rețele, pentru că aceasta aparține routerului desemnat. Rolul său de inundare este mai îngust decât al routerului desemnat la unii pași, ceea ce nu este același lucru cu a tăcea sau a sta inactiv. Tratarea rezervei ca un router care nu face nimic până la promovare produce explicații foarte sigure și foarte greșite.

Întrebarea utilă nu este de la ce se abține rezerva, ci dacă segmentul poate livra pachetele OSPF pe care le cere modelul. Dacă un participant nu le poate schimba cu ceilalți, rezultatul alegerii este un simptom al accesibilității, nu o cauză.

Ce model folosește de fapt tunelul

Rețelele broadcast și NBMA aleg; rețelele punct-la-punct și punct-la-multipunct nu, pentru că nu există un segment comun pe care să aleagă. Într-o suprapunere hub-and-spoke modelul efectiv depinde de modul în care este configurată interfața tunelului, așa că citește-o înainte de a interpreta orice rol. Un tunel care se comportă ca un segment broadcast și un tunel care se comportă ca un set de legături punct-la-punct produc un comportament al vecinilor complet diferit.

Dacă proiectul vrea ca hub-ul să aibă rolul desemnat, modelul și accesibilitatea trebuie să îl susțină împreună. Un hub care nu poate schimba pachetele necesare cu fiecare participant nu devine un router desemnat util doar pentru că prioritatea sa este mare. Verifică mai întâi stările vecinilor și livrarea de bază, apoi decide dacă rolul este greșit sau doar neașteptat.

Eligibilitatea este pe interfață, iar preempțiunea nu este automată

Prioritatea se setează pe interfață, iar o prioritate de zero scoate acea interfață din ambele alegeri. Între participanții eligibili câștigătorul este decis de prioritate și apoi de ID-ul de router, dar un router nou sosit cu prioritate mai mare nu îl înlătură pe un router desemnat existent. Această lipsă de preempțiune este intenționată și îi surprinde pe cei care se așteaptă ca prioritatea cea mai mare să câștige imediat. Dacă un anumit router trebuie să aibă rolul, planifică ordinea evenimentelor în loc să presupui că o modificare de configurație se aplică singură.

Excluderea fiecărui spoke fără a oferi alt participant eligibil înseamnă și că s-ar putea să nu existe deloc rezervă.

Compară cele două explicații cu onestitate: un rol citit din segmentul greșit sau un segment ai cărui membri nu se pot atinge. Prima este o chestiune de proiectare și a doua o chestiune de livrare, și doar una dintre ele se repară editând o prioritate.