OSPF DR en BDR: de verkiezing hoort bij de interface

OSPF-rollen hangen aan interfaces, niet aan de behuizing. Hetzelfde apparaat kan op zijn LAN-segment de aangewezen router zijn en op een tunnel niets bijzonders, en die twee feiten spreken elkaar niet tegen. De rol van de verkeerde interface aflezen is de meest voorkomende reden dat een hub verkeerd geconfigureerd lijkt terwijl hij precies werkt zoals ontworpen.

De vergelijking die ertoe doet, is die tussen rollen op één segment en rollen over een router heen, en tussen wat een reserve doet en wat hij niet doet.

Eén verkiezing per segment

RFC 2328 kiest een aangewezen router en een reserve-aangewezen router voor elk broadcast- of NBMA-netwerk, niet voor een router en niet voor een gebied. Elke interface die aan zo’n netwerk deelneemt, houdt zijn eigen verkiezing met zijn eigen prioriteit en zijn eigen burenset. Een behuizing met drie zulke interfaces kan drie verschillende rollen tegelijk hebben, daarom is zeggen dat de hub de DR is onvolledig tot het segment genoemd wordt. Lees de rol uit de burenuitvoer van die interface zelf.

Twee interfaces in hetzelfde gebied zijn nog steeds twee verkiezingen. Lidmaatschap van een gebied voegt ze niet samen.

Wat de reserve doet terwijl hij wacht

Een reserve-aangewezen router is volledig naburig met de routers op zijn segment en houdt zijn database gesynchroniseerd zodat hij kan overnemen zonder dat een nieuwe nabuurschap ontstaat. Wat hij als reserve niet doet, is de network-LSA van dat netwerk genereren, want die is van de aangewezen router. Zijn floodrol is bij sommige stappen smaller dan die van de aangewezen router, wat niet hetzelfde is als zwijgen of nietsdoen. De reserve behandelen als een router die niets doet tot hij wordt gepromoveerd, levert zeer stellige en zeer onjuiste verklaringen op.

De nuttige vraag is niet waar de reserve zich van onthoudt, maar of het segment de OSPF-pakketten kan leveren die het model vereist. Als een deelnemer ze niet met de anderen kan uitwisselen, is de uitslag van de verkiezing een symptoom van bereikbaarheid, niet een oorzaak.

Welk model de tunnel feitelijk gebruikt

Broadcast- en NBMA-netwerken kiezen; punt-tot-punt- en punt-tot-multipunt-netwerken doen dat niet, omdat er geen gedeeld segment is om op te kiezen. In een hub-and-spoke-overlay hangt het effectieve model af van hoe de tunnelinterface is geconfigureerd, dus lees die voordat je een rol interpreteert. Een tunnel die zich als een broadcast-segment gedraagt en een tunnel die zich als een reeks punt-tot-punt-verbindingen gedraagt, geven volstrekt ander burengedrag.

Wil het ontwerp dat de hub de aangewezen rol heeft, dan moeten het model en de bereikbaarheid dat samen ondersteunen. Een hub die de vereiste pakketten niet met elke deelnemer kan uitwisselen, wordt niet opeens een nuttige aangewezen router omdat zijn prioriteit hoog is. Controleer eerst buurstatus en de onderliggende levering, en beslis daarna of de rol fout is of alleen onverwacht.

Geschiktheid is per interface, en voorrang is niet automatisch

Prioriteit wordt per interface ingesteld, en een prioriteit van nul haalt die interface uit beide verkiezingen. Onder geschikte deelnemers beslist de prioriteit en daarna het router-ID over de winnaar, maar een nieuw aangekomen router met hogere prioriteit verdringt geen bestaande aangewezen router. Dat gebrek aan voorrang is opzettelijk, en het verrast mensen die verwachten dat de hoogste prioriteit meteen wint. Moet een bepaalde router de rol hebben, plan dan de volgorde van gebeurtenissen in plaats van aan te nemen dat een configuratiewijziging vanzelf ingaat.

Elke spoke uitsluiten zonder een andere geschikte deelnemer te bieden, betekent ook dat er misschien helemaal geen reserve is.

Vergelijk de twee verklaringen eerlijk: een rol die van het verkeerde segment is gelezen, of een segment waarvan de leden elkaar niet kunnen bereiken. Het eerste is een ontwerpvraag en het tweede een leveringsvraag, en slechts één van beide wordt gerepareerd door een prioriteit te bewerken.