OSPF DR e BDR: l’elezione appartiene all’interfaccia

I ruoli OSPF si legano alle interfacce, non allo chassis. Lo stesso dispositivo può essere il router designato sul proprio segmento LAN e nulla di speciale su un tunnel, e questi due fatti non si contraddicono. Leggere il ruolo dall’interfaccia sbagliata è la ragione più comune per cui un concentratore sembra mal configurato mentre si comporta esattamente come progettato.

Il confronto che conta è tra i ruoli su un segmento e i ruoli attraverso un router, e tra ciò che fa un backup e ciò che non fa.

Un’elezione per segmento

RFC 2328 elegge un router designato e un router designato di backup per ogni rete broadcast o NBMA, non per un router e non per un’area. Ogni interfaccia che partecipa a una rete simile svolge la propria elezione con la propria priorità e il proprio insieme di vicini. Uno chassis con tre interfacce così può tenere tre ruoli diversi contemporaneamente, per questo dire che il concentratore è il DR resta incompleto finché non si nomina il segmento. Leggi il ruolo dall’output dei vicini di quella stessa interfaccia.

Due interfacce nella stessa area sono ancora due elezioni. L’appartenenza all’area non le fonde.

Che cosa fa il backup mentre aspetta

Un router designato di backup è completamente adiacente ai router del suo segmento e mantiene il proprio database sincronizzato per poter subentrare senza che si formi una nuova adiacenza. Ciò che non fa mentre agisce da backup è originare la network-LSA di quella rete, perché la possiede il router designato. Il suo ruolo di flooding è più stretto di quello del router designato in alcuni passaggi, il che non equivale a restare in silenzio o inattivo. Trattare il backup come un router che non fa nulla fino alla promozione produce spiegazioni molto sicure e molto sbagliate.

La domanda utile non è da cosa si astiene il backup, ma se il segmento può consegnare i pacchetti OSPF che il modello richiede. Se un partecipante non può scambiarli con gli altri, il risultato dell’elezione è un sintomo di raggiungibilità, non una causa.

Quale modello usa davvero il tunnel

Le reti broadcast e NBMA eleggono; le reti punto a punto e punto a multipunto no, perché non c’è un segmento condiviso su cui eleggere. In una sovrapposizione hub-and-spoke il modello effettivo dipende da come è configurata l’interfaccia del tunnel, quindi leggila prima di interpretare qualsiasi ruolo. Un tunnel che si comporta come un segmento broadcast e un tunnel che si comporta come un insieme di collegamenti punto a punto producono un comportamento dei vicini del tutto diverso.

Se il progetto vuole che il concentratore tenga il ruolo designato, il modello e la raggiungibilità devono sostenerlo insieme. Un concentratore che non può scambiare i pacchetti necessari con ogni partecipante non diventerà un router designato utile solo perché la sua priorità è alta. Controlla prima gli stati dei vicini e la consegna sottostante, poi decidi se il ruolo è sbagliato o solo inatteso.

L’eleggibilità è per interfaccia, e la preemption non è automatica

La priorità si imposta per interfaccia, e una priorità di zero esclude quell’interfaccia da entrambe le elezioni. Tra i partecipanti eleggibili il vincitore è deciso dalla priorità e poi dall’ID del router, ma un router appena arrivato con priorità più alta non scalza un router designato esistente. Questa assenza di preemption è deliberata, e sorprende chi si aspetta che la priorità più alta vinca subito. Se un router specifico deve tenere il ruolo, pianifica l’ordine degli eventi invece di dare per scontato che una modifica di configurazione abbia effetto da sola.

Escludere ogni spoke senza fornire un altro partecipante eleggibile significa anche che potrebbe non esserci alcun backup.

Confronta le due spiegazioni con onestà: un ruolo letto dal segmento sbagliato, o un segmento i cui membri non riescono a raggiungersi. La prima è una questione di progetto e la seconda una questione di consegna, e solo una delle due si risolve modificando una priorità.