OSPF DR och BDR: valet tillhör gränssnittet

OSPF-roller hänger på gränssnitt, inte på chassit. Samma enhet kan vara den utsedda routern på sitt LAN-segment och inget särskilt i en tunnel, och de två fakta motsäger inte varandra. Att läsa rollen från fel gränssnitt är den vanligaste orsaken till att en hubb ser felkonfigurerad ut medan den beter sig exakt som designad.

Jämförelsen som betyder något är mellan roller på ett segment och roller över en router, och mellan vad en reserv gör och vad den inte gör.

Ett val per segment

RFC 2328 väljer en utsedd router och en utsedd reservrouter för varje broadcast- eller NBMA-nät, inte för en router och inte för ett område. Varje gränssnitt som deltar i ett sådant nät kör sitt eget val med sin egen prioritet och sin egen nabomängd. Ett chassi med tre sådana gränssnitt kan ha tre olika roller samtidigt, därför är det ofullständigt att säga att hubben är DR innan segmentet är namngivet. Läs rollen från det gränssnittets egen nabo-utskrift.

Två gränssnitt i samma område är fortfarande två val. Medlemskap i ett område smälter inte samman dem.

Vad reserven gör medan den väntar

En utsedd reservrouter är fullt granne med routrarna på sitt segment och håller sin databas synkroniserad så att den kan ta över utan att ett nytt grannskap bildas. Det den inte gör i reservrollen är att skapa nätets network-LSA, eftersom den ägs av den utsedda routern. Dess flödesroll är smalare än den utsedda routerns i vissa steg, vilket inte är samma sak som att vara tyst eller overksam. Att behandla reserven som en router som inte gör något före befordran ger några mycket självsäkra och mycket felaktiga förklaringar.

Den användbara frågan är inte vad reserven avstår från, utan om segmentet kan leverera de OSPF-paket som modellen kräver. Om en deltagare inte kan utbyta dem med de andra är valresultatet ett symptom på nåbarhet, inte en orsak.

Vilken modell tunneln faktiskt använder

Broadcast- och NBMA-nät väljer; punkt-till-punkt- och punkt-till-multipunktnät gör det inte, eftersom det inte finns något delat segment att välja på. I ett hub-and-spoke-overlay beror den effektiva modellen på hur tunnelgränssnittet är konfigurerat, så läs det innan du tolkar någon roll. En tunnel som beter sig som ett broadcast-segment och en tunnel som beter sig som en mängd punkt-till-punkt-länkar ger helt olika grannebeteende.

Om designen vill att hubben ska ha den utsedda rollen måste modellen och nåbarheten stödja det tillsammans. En hubb som inte kan utbyta de nödvändiga paketen med varje deltagare blir inte en användbar utsedd router bara för att prioriteten är hög. Kontrollera först nabostatus och den underliggande leveransen, avgör sedan om rollen är fel eller bara oväntad.

Behörighet är per gränssnitt, och företräde är inte automatiskt

Prioritet sätts per gränssnitt, och prioritet noll tar bort gränssnittet från båda valen. Bland behöriga deltagare avgörs vinnaren av prioritet och sedan av router-ID, men en nyankommen router med högre prioritet tränger inte undan en befintlig utsedd router. Det uteblivna företrädet är avsiktligt och överraskar dem som förväntar sig att högsta prioritet vinner direkt. Om en viss router ska ha rollen, planera händelseordningen i stället för att anta att en konfigurationsändring träder i kraft av sig själv.

Att utesluta varje spoke utan att erbjuda en annan behörig deltagare innebär också att det kanske inte finns någon reserv alls.

Jämför de två förklaringarna ärligt: en roll läst från fel segment, eller ett segment vars medlemmar inte når varandra. Det första är en designfråga och det andra en leveransfråga, och bara en av dem repareras genom att redigera en prioritet.