OSPF DR og BDR: valet høyrer til grensesnittet

OSPF-roller heng på grensesnitt, ikkje på kabinettet. Same eininga kan vere den utpeikte ruteren på sitt LAN-segment og ikkje noko spesielt i ein tunnel, og dei to fakta motseler ikkje kvarandre. Å lese rolla frå feil grensesnitt er den vanlegaste grunnen til at ein hub ser feilkonfigurert ut medan han oppfører seg nøyaktig som designa.

Samanlikninga som betyr noko, er mellom roller på eitt segment og roller på tvers av ein ruter, og mellom kva ein reserve gjer og kva han ikkje gjer.

Eitt val per segment

RFC 2328 vel ein utpeikt ruter og ein utpeikt reserveruter for kvart broadcast- eller NBMA-nett, ikkje for ein ruter og ikkje for eit område. Kvart grensesnitt som deltek i eit slikt nett, køyrer sitt eige val med si eiga prioritet og sitt eige nabosett. Eit kabinett med tre slike grensesnitt kan ha tre ulike roller samstundes, difor er det ufullstendig å seie at huben er DR før segmentet er namngitt. Les rolla frå det grensesnittet si eiga nabo-utskrift.

To grensesnitt i same område er framleis to val. Medlemskap i eit område smeltar dei ikkje saman.

Kva reserven gjer medan han ventar

Ein utpeikt reserveruter er fullt naboskap med ruterane på sitt segment og held databasen sin synkronisert slik at han kan overta utan at eit nytt naboskap vert danna. Det han ikkje gjer i rolla som reserve, er å generere nettets network-LSA, fordi den er eigd av den utpeikte ruteren. Flomrolla er smalare enn den utpeikte ruterens på nokre trinn, noko som ikkje er det same som å vere taus eller ledig. Å handsame reserven som ein ruter som ikkje gjer noko før forfremjing gir nokre svært sjølvsikre og svært gale forklaringar.

Det nyttige spørsmålet er ikkje kva reserven avstår frå, men om segmentet kan levere OSPF-pakkane modellen krev. Viss ein deltakar ikkje kan utveksle dei med dei andre, er valresultatet eit symptom på tilgjenge, ikkje ei årsak.

Kva modell tunnelen faktisk brukar

Broadcast- og NBMA-nett vel; punkt-til-punkt- og punkt-til-multipunkt-nett gjer det ikkje, fordi det finst ikkje noko felles segment å velje på. I eit hub-and-spoke-overlegg er den effektive modellen avhengig av korleis tunnelgrensesnittet er konfigurert, så les det før du tolkar noka rolle. Ein tunnel som oppfører seg som eit broadcast-segment, og ein tunnel som oppfører seg som eit sett punkt-til-punkt-lenkjer, gir heilt ulik naboåtferd.

Viss designet vil at huben skal ha den utpeikte rolla, må modellen og tilgangen støtte det saman. Ein hub som ikkje kan utveksle dei naudsynte pakkane med kvar deltakar, vert ikkje ein nyttig utpeikt ruter berre fordi prioriteten er høg. Kontroller nabotilstandar og den underliggjande leveringa fyrst, og avgjer deretter om rolla er feil eller berre uventa.

Kvalifisering er per grensesnitt, og forrang er ikkje automatisk

Prioritet vert sett per grensesnitt, og ein prioritet på null fjernar grensesnittet frå begge vala. Blant kvalifiserte deltakarar vert vinnaren avgjord av prioritet og deretter av ruter-ID, men ein nyankomen ruter med høgare prioritet fortrengjer ikkje ein eksisterande utpeikt ruter. Den manglande forrangen er tilsikta, og han overraskar folk som ventar at høgst prioritet vinn med ein gong. Viss ein bestemt ruter skal ha rolla, planlegg hendingsforløpet i staden for å gå ut frå at ei konfigurasjonsendring trer i kraft av seg sjølv.

Å utelukke kvar spoke utan å tilby ein annan kvalifisert deltakar betyr også at det kanskje ikkje finst nokon reserve i det heile.

Samanlikn dei to forklaringane ærleg: ei rolle lesen frå feil segment, eller eit segment der medlemmane ikkje når kvarandre. Det fyrste er eit designspørsmål og det andre eit leveringsspørsmål, og berre eitt av dei vert reparert ved å redigere ein prioritet.