OSPF DR kaj BDR: la elekto apartenas al la interfaco

La roloj de OSPF aliĝas al interfacoj, ne al la korpo. La sama aparato povas esti la nomumita enkursigilo en sia LAN-segmento kaj nenio speciala en tunelo, kaj tiuj du faktoj ne kontraŭdiras unu la alian. Legi la rolon el la malĝusta interfaco estas la plej ofta kialo, kial hubo ŝajnas mise agordita dum ĝi funkcias ĝuste tiel, kiel ĝi estis projektita.

La komparo, kiu gravas, estas inter roloj en unu segmento kaj roloj trans enkursigilo, kaj inter tio, kion faras rezervo kaj kion ĝi ne faras.

Unu elekto por segmento

RFC 2328 elektas nomumitan enkursigilon kaj rezervan nomumitan enkursigilon por ĉiu broadcast aŭ NBMA reto, ne por enkursigilo kaj ne por areo. Ĉiu interfaco partoprenanta en tia reto faras sian propran elekton kun propra prioritato kaj propra najbara aro. Korpo kun tri tiaj interfacoj povas teni tri malsamajn rolojn samtempe, tial diri, ke la hubo estas la DR, estas nekompleta ĝis la segmento estas nomata. Legu la rolon el la propra najbara eligilo de tiu interfaco.

Du interfacoj en la sama areo estas ankoraŭ du elektoj. Aniĝo al areo ne kunfandas ilin.

Kion la rezervo faras dum ĝi atendas

Rezerva nomumita enkursigilo estas plene najbara al la enkursigiloj en sia segmento kaj tenas sian datumbazon sinkronigita, por ke ĝi povu transpreni sen formiĝo de nova najbareco. Kion ĝi ne faras dum ĝi agas kiel rezervo, estas generi la network-LSA de tiu reto, ĉar tiun posedas la nomumita enkursigilo. Ĝia rolo en inundo estas pli mallarĝa ol tiu de la nomumita enkursigilo ĉe kelkaj paŝoj, kio ne samas kiel silenti aŭ senokupiĝi. Trakti la rezervon kiel enkursigilon, kiu faras nenion ĝis antaŭenigo, produktas tre memfidajn kaj tre malĝustajn klarigojn.

La utila demando ne estas, de kio la rezervo sindetenas, sed ĉu la segmento povas liveri la OSPF-paketojn, kiujn la modelo postulas. Se partoprenanto ne povas interŝanĝi ilin kun la aliaj, la elekta rezulto estas simptomo de atingeblo, ne kaŭzo.

Kiun modelon la tunelo efektive uzas

Broadcast kaj NBMA retoj elektas; point-to-point kaj point-to-multipoint retoj ne elektas, ĉar mankas komuna segmento por elekti. En hub-and-spoke tavolo la efektiva modelo dependas de tio, kiel la tunela interfaco estas agordita, do legu ĝin antaŭ ol interpreti ajnan rolon. Tunelo, kiu kondutas kiel broadcast-segmento, kaj tunelo, kiu kondutas kiel aro de point-to-point ligoj, produktas tute malsaman najbaran konduton.

Se la projekto volas, ke la hubo tenu la nomumitan rolon, la modelo kaj la atingeblo devas subteni tion kune. Hubo, kiu ne povas interŝanĝi la bezonatajn paketojn kun ĉiu partoprenanto, ne fariĝos utila nomumita enkursigilo nur ĉar ĝia prioritato estas alta. Kontrolu unue la najbarajn statojn kaj la suban liveradon, poste decidu, ĉu la rolo estas malĝusta aŭ nur neatendita.

Rajtigo estas laŭ interfaco, kaj antaŭeco ne estas aŭtomata

Prioritato estas agordata laŭ interfaco, kaj prioritato de nulo forigas tiun interfacon el ambaŭ elektoj. Inter rajtigitaj partoprenantoj la venkanto estas decidata per prioritato kaj poste per enkursigila ID, sed ĵus alveninta enkursigilo kun pli alta prioritato ne delokigas ekzistantan nomumitan enkursigilon. Tiu manko de antaŭeco estas intenca, kaj ĝi surprizas homojn, kiuj atendas, ke la plej alta prioritato venku tuj. Se difinita enkursigilo devas teni la rolon, planu la ordon de la eventoj anstataŭ supozi, ke agorda ŝanĝo efikiĝas per si mem.

Elfermi ĉiun spoke sen provizi alian rajtigitan partoprenanton ankaŭ signifas, ke eble tute ne estas rezervo.

Komparu la du klarigojn honeste: rolon legitan el la malĝusta segmento, aŭ segmenton, kies membroj ne povas atingi unu la alian. La unua estas demando pri projektado kaj la dua demando pri liverado, kaj nur unu el ili ripariĝas per redakto de prioritato.