OSPF DR og BDR: valget hører til interfacet

OSPF-roller hænger på interface, ikke på chassis. Den samme enhed kan være den udpegede router på sit LAN-segment og intet særligt på en tunnel, og de to fakta modsiger ikke hinanden. At læse rollen fra det forkerte interface er den mest almindelige grund til, at en hub ser fejlkonfigureret ud, når den opfører sig præcis som designet.

Den sammenligning, der betyder noget, er mellem roller på ét segment og roller på tværs af en router, og mellem hvad en backup gør, og hvad den ikke gør.

Ét valg per segment

RFC 2328 vælger en udpeget router og en backup-udpeget router for hvert broadcast- eller NBMA-netværk, ikke for en router og ikke for et område. Hvert interface, der deltager i et sådant netværk, kører sit eget valg med sin egen prioritet og sit eget nabosæt. Et chassis med tre sådanne interface kan holde tre forskellige roller på én gang, og derfor er det ufuldstændigt at sige, at hubben er DR, indtil segmentet er nævnt. Læs rollen fra det interfaces egen nabo-output.

To interface i samme område er stadig to valg. Medlemskab af et område smelter dem ikke sammen.

Hvad backuppen laver, mens den venter

En backup-udpeget router er fuldt naboskab med routerne på sit segment og holder sin database synkroniseret, så den kan overtage uden at der dannes et nyt naboskab. Det, den ikke gør, mens den virker som backup, er at skabe netværkets network-LSA, for den ejes af den udpegede router. Dens flooding-rolle er snævrere end den udpegede routers på nogle trin, hvilket ikke er det samme som at være tavs eller ledig. At behandle backuppen som en router, der intet gør indtil forfremmelse, giver nogle meget selvsikre og meget forkerte forklaringer.

Det nyttige spørgsmål er ikke, hvad backuppen afholder sig fra, men om segmentet kan levere de OSPF-pakker, modellen kræver. Hvis en deltager ikke kan udveksle dem med de andre, er valgresultatet et symptom på rækkevidde, ikke en årsag.

Hvilken model tunnelen faktisk bruger

Broadcast- og NBMA-netværk vælger; punkt-til-punkt- og punkt-til-multipunkt-netværk gør ikke, fordi der ikke er noget fælles segment at vælge på. I et hub-and-spoke-overlay afhænger den effektive model af, hvordan tunnelinterfacet er konfigureret, så læs det, før du fortolker nogen rolle. En tunnel, der opfører sig som et broadcast-segment, og en tunnel, der opfører sig som et sæt punkt-til-punkt-forbindelser, giver helt forskellig nabo-adfærd.

Hvis designet vil have, at hubben har den udpegede rolle, skal modellen og rækkevidden understøtte det sammen. En hub, der ikke kan udveksle de nødvendige pakker med hver deltager, bliver ikke en brugbar udpeget router, bare fordi dens prioritet er høj. Kontrollér nabotilstande og den underliggende levering først, og afgør derefter, om rollen er forkert eller blot uventet.

Berettigelse er per interface, og forrang er ikke automatisk

Prioritet sættes per interface, og en prioritet på nul fjerner det interface fra begge valg. Blandt berettigede deltagere afgøres vinderen af prioritet og derefter af router-ID, men en nyligt ankommet router med højere prioritet fortrænger ikke en eksisterende udpeget router. Den manglende forrang er tilsigtet, og den overrasker folk, der forventer, at den højeste prioritet vinder med det samme. Hvis en bestemt router skal have rollen, planlæg begivenhedernes rækkefølge i stedet for at antage, at en konfigurationsændring træder i kraft af sig selv.

At udelukke hver spoke uden at stille en anden berettiget deltager til rådighed betyder også, at der måske slet ikke er nogen backup.

Sammenlign de to forklaringer ærligt: en rolle læst fra det forkerte segment, eller et segment, hvis medlemmer ikke kan nå hinanden. Det første er et designspørgsmål, og det andet er et leveringsspørgsmål, og kun ét af dem repareres ved at redigere en prioritet.