Stesso iESI all’interno di un sito, unico tra siti: cucitura Junos

Due coppie di gateway servono due data center, e qualcuno deve decidere quanti valori interconnect ESI servono al progetto. La risposta è uno per gruppo di gateway, non uno per fabric e non uno per gateway. Sbagliarlo produce un fabric che sembra configurato ed elegge il forwarder sbagliato, oppure unisce due siti che dovevano restare distinti. La regola e le sue eccezioni meritano di essere scritte accanto all’elenco delle gateway.

Due ambiti, due regole

All’interno di un sito, le gateway interconnect ridondanti agiscono come un unico endpoint multihomed, quindi condividono un solo interconnect ESI. I loro peer devono vedere un solo membro logico invece di due indipendenti. È tutto il senso del valore condiviso.

Tra siti, ogni gruppo di gateway riceve il proprio valore. Due data center che condividono un identificatore diventano un solo gruppo multihomed nel piano di controllo, cosa che di solito non è ciò che intende un progetto di cucitura su una WAN. Due siti in un solo gruppo ereditano anche i reciproci modi di guasto.

All’interno di un sito: un’identità per il gruppo

Date alla coppia lo stesso valore su entrambi i peer, nello stesso contesto di servizio, e registratelo nell’inventario degli identificatori della rete invece che in un thread di chat. Una discrepanza tra i due membri è il modo di guasto che produce un gruppo di un solo membro e nessun allarme evidente. Confrontate entrambi i membri prima di credere a una sessione funzionante.

Il modello supportato è all-active. La stessa referenza esclude il funzionamento single-active, gli identificatori LACP derivati automaticamente e le opzioni source-bmac per questa identità di cucitura, quindi un progetto che ne ha presupposto una va rivisto prima ancora di scegliere l’identificatore. Quel vincolo è un dato di progetto, non una nota a piè di pagina.

Tra siti: valori diversi, o una fusione deliberata

Un valore unico per sito tiene separati i due gruppi di gateway. Se l’intenzione è davvero estendere un gruppo multihomed tra siti, quella è un’altra architettura con le sue conseguenze su latenza, guasti e inoltro, e va decisa come architettura, non come scelta di identificatore. Chiedete quella decisione per iscritto prima della finestra di manutenzione.

Scrivete la distinzione prevista nel piano, così che un ingegnere successivo che copia un modello di sito funzionante non ne importi anche l’identificatore.

L’istruzione peer fa parte dell’identità

Ogni gateway del gruppo elenca i propri peer locali per indirizzo di loopback, e quella relazione vive a livello globale dell’EVPN invece che dentro un singolo MAC-VRF. Metterla nella gerarchia sbagliata è un modo comune di produrre una configurazione che si conferma ma non forma mai il gruppo. Leggete la gerarchia di riferimento una volta, poi attenetevi a essa.

Anche il nome dell’istruzione si è spostato. Juniper ha rinominato l’istruzione interconnect peer-gateways nella 24.2R1 e ha ripristinato la forma specifica per l’interconnect dei data center nella 24.4R1. Uno snippet preso dalla versione intermedia può quindi usare un nome che la versione distribuita non accetta, o viceversa. Registrate la versione da cui proviene lo snippet accanto allo snippet stesso.

Cosa non fa la condivisione di un iESI

Non definisce per voi i route target, le VNI né l’istanza EVPN locale. Restano configurazione separata che deve concordare su entrambi i lati, e un identificatore che corrisponde mentre un route target non corrisponde produce un gruppo che si forma e non trasporta nulla. Confrontate entrambi i lati di quelle impostazioni nella stessa passata.

Non dimostra nemmeno la raggiungibilità dei peer o l’elezione del designated forwarder. Provate l’unicast e il comportamento broadcast e multicast richiesto nel caso normale, poi ripetete con una gateway rimossa, così che il membro superstite porti il gruppo da solo.

È quella seconda esecuzione a dimostrare che il gruppo è reale.

Conservate l’appartenenza osservata e il contesto di servizio con i risultati dei test. Una successiva modifica dell’identificatore potrà allora essere riesaminata come cambiamento di multihoming, che è ciò che è, e non come correzione cosmetica di una stringa. I risultati sono l’unica prova che l’identificatore fa ciò che dice lo schema.