OSPF DR og BDR: valget tilhører grensesnittet

OSPF-roller henger på grensesnitt, ikke på kabinettet. Samme enhet kan være den utpekte ruteren på sitt LAN-segment og ikke noe spesielt i en tunnel, og de to fakta motsier ikke hverandre. Å lese rollen fra feil grensesnitt er den vanligste grunnen til at en hub ser feilkonfigurert ut mens den oppfører seg nøyaktig som designet.

Sammenligningen som betyr noe, er mellom roller på ett segment og roller på tvers av en ruter, og mellom hva en reserve gjør og hva den ikke gjør.

Ett valg per segment

RFC 2328 velger en utpekt ruter og en utpekt reserveruter for hvert broadcast- eller NBMA-nett, ikke for en ruter og ikke for et område. Hvert grensesnitt som deltar i et slikt nett, kjører sitt eget valg med sin egen prioritet og sitt eget nabosett. Et kabinett med tre slike grensesnitt kan ha tre ulike roller samtidig, derfor er det ufullstendig å si at huben er DR før segmentet er navngitt. Les rollen fra det grensesnittets egen nabo-utskrift.

To grensesnitt i samme område er fortsatt to valg. Medlemskap i et område smelter dem ikke sammen.

Hva reserven gjør mens den venter

En utpekt reserveruter er fullt naboskap med ruterne på sitt segment og holder databasen sin synkronisert slik at den kan overta uten at et nytt naboskap dannes. Det den ikke gjør i rollen som reserve, er å generere nettets network-LSA, fordi den eies av den utpekte ruteren. Flomrollen er smalere enn den utpekte ruterens på noen trinn, noe som ikke er det samme som å være taus eller ledig. Å behandle reserven som en ruter som ikke gjør noe før forfremmelse gir noen svært selvsikre og svært gale forklaringer.

Det nyttige spørsmålet er ikke hva reserven avstår fra, men om segmentet kan levere OSPF-pakkene modellen krever. Hvis en deltaker ikke kan utveksle dem med de andre, er valgresultatet et symptom på tilgjengelighet, ikke en årsak.

Hvilken modell tunnelen faktisk bruker

Broadcast- og NBMA-nett velger; punkt-til-punkt- og punkt-til-multipunkt-nett gjør det ikke, fordi det ikke finnes noe felles segment å velge på. I et hub-and-spoke-overlegg avhenger den effektive modellen av hvordan tunnelgrensesnittet er konfigurert, så les det før du tolker noen rolle. En tunnel som oppfører seg som et broadcast-segment, og en tunnel som oppfører seg som et sett punkt-til-punkt-lenker, gir helt forskjellig naboatferd.

Hvis designet vil at huben skal ha den utpekte rollen, må modellen og tilgjengeligheten støtte det sammen. En hub som ikke kan utveksle de nødvendige pakkene med hver deltaker, blir ikke en nyttig utpekt ruter bare fordi prioriteten er høy. Kontroller nabotilstander og den underliggende leveringen først, og avgjør deretter om rollen er feil eller bare uventet.

Kvalifisering er per grensesnitt, og forrang er ikke automatisk

Prioritet settes per grensesnitt, og en prioritet på null fjerner grensesnittet fra begge valgene. Blant kvalifiserte deltakere avgjøres vinneren av prioritet og deretter av ruter-ID, men en nyankommet ruter med høyere prioritet fortrenger ikke en eksisterende utpekt ruter. Den manglende forrangen er tilsiktet, og den overrasker folk som forventer at høyest prioritet vinner med en gang. Hvis en bestemt ruter skal ha rollen, planlegg hendelsesforløpet i stedet for å anta at en konfigurasjonsendring trer i kraft av seg selv.

Å utelukke hver spoke uten å tilby en annen kvalifisert deltaker betyr også at det kanskje ikke finnes noen reserve i det hele tatt.

Sammenlign de to forklaringene ærlig: en rolle lest fra feil segment, eller et segment der medlemmene ikke når hverandre. Det første er et designspørsmål og det andre et leveringsspørsmål, og bare ett av dem repareres ved å redigere en prioritet.