8. Multihoming NVEs - NVE Residing in ToR Switch

8. Multihoming NVEs - NVE Residing in ToR Switch (NVE multi-homed - NVE che risiede nello switch ToR)

In questa sezione, discutiamo lo scenario in cui i NVE risiedono negli switch ToR E i server (dove risiedono le VM) sono multi-homed a questi switch ToR. Il NVE multi-homed opera in modalità di ridondanza All-Active o Single-Active. Se i server sono single-homed agli switch ToR, allora lo scenario diventa simile a quello in cui il NVE risiede sull'hypervisor, come discusso nella Sezione 7, per quanto riguarda la funzionalità EVPN richiesta.

[RFC7432] definisce un insieme di route BGP, attributi e procedure per supportare il multi-homing. Descriviamo prima queste funzioni e procedure, poi discutiamo quali di queste sono impattate dall'incapsulamento VXLAN (o NVGRE) e quali modifiche sono richieste. Come si vedrà più avanti in questa sezione, l'unica procedura EVPN che è impattata dall'incapsulamento overlay non-MPLS (ad esempio, VXLAN o NVGRE) dove fornisce spazio per un ID piuttosto che uno stack di label, è quella del filtraggio split-horizon per ES multi-homed descritta nella Sezione 8.3.1.

8.1. EVPN Multihoming Features (Funzionalità di multi-homing EVPN)

In questa sezione, ricapitoleremo le funzionalità di multi-homing di EVPN per evidenziare le dipendenze di incapsulamento. La sezione descrive solo le funzionalità e funzioni ad alto livello. Per maggiori dettagli, il lettore deve fare riferimento a [RFC7432].

8.1.1. Multihomed ES Auto-Discovery (Auto-Discovery ES multi-homed)

I NVE EVPN (o PE) connessi allo stesso ES (ad esempio, lo stesso server tramite Link Aggregation Group (LAG)) possono scoprirsi automaticamente reciprocamente con configurazione minima o nulla attraverso lo scambio di route BGP.

8.1.2. Fast Convergence and Mass Withdrawal (Convergenza rapida e ritiro di massa)

EVPN definisce un meccanismo per segnalare in modo efficiente e rapido ai NVE remoti la necessità di aggiornare le loro tabelle di forwarding al verificarsi di un guasto di connettività a un ES (ad esempio, un guasto di link o porta). Questo viene fatto facendo in modo che ogni NVE pubblicizzi una route Ethernet A-D per ES per ogni segmento localmente collegato. Al verificarsi di un guasto di connettività al segmento collegato, il NVE ritira la route Ethernet A-D corrispondente. Questo attiva tutti i NVE che ricevono il ritiro ad aggiornare le loro adjacency di next-hop per tutti gli indirizzi MAC associati all'ES in questione. Se nessun altro NVE aveva pubblicizzato una route Ethernet A-D per lo stesso segmento, allora il NVE che ha ricevuto il ritiro invalida semplicemente le voci MAC per quel segmento. Altrimenti, il NVE aggiorna l'elenco di adjacency di next-hop di conseguenza.

8.1.3. Split-Horizon (Split-Horizon)

Se un server è multi-homed a due o più NVE (rappresentati da un ES ES1) e operante in modalità di ridondanza All-Active, invia un pacchetto BUM (cioè, Broadcast, Unknown unicast o Multicast) a uno di questi NVE, allora è importante garantire che il pacchetto non venga riportato al server tramite un altro NVE connesso a questo server. Il meccanismo di filtraggio sul NVE per prevenire tale loop e duplicazione di pacchetti è chiamato "filtraggio split-horizon".

8.1.4. Aliasing and Backup Path (Aliasing e percorso di backup)

Nel caso in cui una stazione sia multi-homed a più NVE, è possibile che solo un singolo NVE apprenda un insieme di indirizzi MAC associati al traffico trasmesso dalla stazione. Questo porta a una situazione in cui i NVE remoti ricevono route MAC Advertisement, per questi indirizzi, da un singolo NVE anche se più NVE sono connessi alla stazione multi-homed. Di conseguenza, i NVE remoti non sono in grado di bilanciare efficacemente il carico del traffico tra i NVE connessi all'ES multi-homed. Ad esempio, questo potrebbe essere il caso quando i NVE eseguono l'apprendimento del data-path sull'accesso e la funzione di bilanciamento del carico sulla stazione effettua l'hash del traffico da un dato indirizzo MAC sorgente a un singolo NVE. Un altro scenario in cui questo si verifica è quando i NVE si affidano all'apprendimento del control-plane sull'accesso (ad esempio, utilizzando ARP), poiché il traffico ARP verrà sottoposto a hash verso un singolo link nel LAG.

Per mitigare questo problema, EVPN introduce il concetto di "Aliasing". Questo si riferisce alla capacità di un NVE di segnalare che ha raggiungibilità a un dato ES localmente collegato, anche quando non ha appreso alcun indirizzo MAC da quel segmento. La route Ethernet A-D per EVI viene utilizzata a tale scopo. I NVE remoti che ricevono route MAC Advertisement con ESI non nulli dovrebbero considerare l'indirizzo MAC come raggiungibile tramite tutti i NVE che pubblicizzano raggiungibilità al segmento rilevante utilizzando route Ethernet A-D con lo stesso ESI e con il flag Single-Active azzerato.

Backup Path è una funzione strettamente correlata, sebbene si applichi al caso in cui la modalità di ridondanza è Single-Active. In questo caso, il NVE segnala che ha raggiungibilità a un dato ES localmente collegato utilizzando anche la route Ethernet A-D. I NVE remoti che ricevono le route MAC Advertisement, con ESI non nullo, dovrebbero considerare l'indirizzo MAC come raggiungibile tramite il NVE pubblicizzante. Inoltre, i NVE remoti dovrebbero installare un percorso di backup, per detta MAC, verso il NVE che aveva pubblicizzato raggiungibilità al segmento rilevante utilizzando una route Ethernet A-D con lo stesso ESI e con il flag Single-Active impostato.

8.1.5. DF Election (Elezione DF)

Se un host è multi-homed a due o più NVE su un ES operante in modalità di ridondanza All-Active, allora, per un dato EVI, solo uno di questi NVE, denominato "Designated Forwarder" (DF) è responsabile dell'invio di frame broadcast, multicast e, se configurato per quell'EVI, unknown unicast.

Questo è richiesto al fine di prevenire la consegna duplicata di frame multi-destinazione a un host o VM multi-homed, nel caso di ridondanza All-Active.

Nei NVE dove frame etichettati come IEEE 802.1Q [IEEE.802.1Q] sono ricevuti dagli host, l'elezione DF dovrebbe essere eseguita sulla base dei VID degli host secondo la Sezione 8.5 di [RFC7432]. Inoltre, i PE multi-homing di un dato ES POSSONO eseguire l'elezione DF utilizzando ID configurati come VNI, EVI, VID normalizzati, ecc., purché gli ID siano configurati in modo coerente tra i PE multi-homing.

Nei GW dove frame incapsulati VXLAN sono ricevuti, l'elezione DF viene eseguita sui VNI. Ancora una volta, si presume che, per un dato segmento Ethernet, i VNI siano univoci e coerenti (ad esempio, non esistono VNI duplicati).

8.2. Impact on EVPN BGP Routes and Attributes (Impatto sulle route e attributi BGP EVPN)

Poiché il multi-homing è supportato in questo scenario, l'intero insieme di route BGP e attributi definiti in [RFC7432] viene utilizzato. L'impostazione del campo Ethernet Tag nelle route MAC Advertisement, Ethernet A-D per EVI e IMET segue quella della Sezione 5.1.3. Inoltre, l'impostazione del campo VNI nelle route MAC Advertisement e Ethernet A-D per EVI segue quella della Sezione 5.1.3.

8.3. Impact on EVPN Procedures (Impatto sulle procedure EVPN)

Due casi devono essere esaminati qui, a seconda che i NVE operino in modalità di ridondanza Single-Active o All-Active.

Primo, consideriamo il caso della modalità di ridondanza Single-Active, dove gli host sono multi-homed a un insieme di NVE; tuttavia, solo un singolo NVE è attivo in un dato momento per un dato VNI. In questo caso, l'Aliasing non è richiesto, e il filtraggio split-horizon potrebbe non essere richiesto, ma altre funzioni come auto-discovery ES multi-homed, convergenza rapida e ritiro di massa, Backup Path ed elezione DF sono necessarie.

Secondo, consideriamo il caso della modalità di ridondanza All-Active. In questo caso, di tutte le funzionalità di multi-homing EVPN elencate nella Sezione 8.1, l'uso dell'incapsulamento VXLAN o NVGRE impatta le funzionalità split-horizon e Aliasing, poiché queste due si basano sul livello client MPLS. Dato che questo livello client MPLS è assente con questi tipi di incapsulamenti, sono necessarie procedure e meccanismi alternativi per fornire le funzioni richieste. Questi sono discussi in dettaglio di seguito.

8.3.1. Split Horizon (Split-Horizon)

In EVPN, un'etichetta MPLS viene utilizzata per il filtraggio split-horizon per supportare il multi-homing All-Active dove un NVE di ingresso aggiunge un'etichetta corrispondente al sito di origine (aka un'etichetta ESI) quando incapsula il pacchetto. Il NVE di uscita controlla l'etichetta ESI quando tenta di inoltrare un frame multi-destinazione verso un'interfaccia, e se l'etichetta corrisponde allo stesso identificatore di sito (ESI) associato a quell'interfaccia, il pacchetto viene eliminato. Questo previene il verificarsi di loop di forwarding.

Poiché gli incapsulamenti VXLAN e NVGRE non includono l'etichetta ESI, devono essere escogitati altri mezzi per eseguire la funzione di filtraggio split-horizon per questi incapsulamenti. Il seguente approccio è raccomandato per il filtraggio split-horizon quando viene utilizzato l'incapsulamento VXLAN (o NVGRE).

Ogni NVE tiene traccia degli indirizzi IP associati agli altri NVE con cui ha ES multi-homed condivisi. Quando il NVE riceve un frame multi-destinazione dalla rete overlay, esamina l'indirizzo IP sorgente nell'header del tunnel (che corrisponde al NVE di ingresso) e filtra il frame su tutte le interfacce locali connesse agli ES che sono condivisi con il NVE di ingresso. Con questo approccio, è richiesto che il NVE di ingresso esegua la replica localmente a tutti i segmenti Ethernet direttamente collegati (indipendentemente dallo stato di elezione DF) per tutto il traffico inondato in ingresso dalle interfacce di accesso (cioè, dagli host). Questo approccio è denominato "Local Bias", e ha il vantaggio che solo un singolo indirizzo IP deve essere utilizzato per NVE per il filtraggio split-horizon, invece di richiedere un indirizzo IP per segmento Ethernet per NVE.

Al fine di consentire il corretto funzionamento del filtraggio split-horizon tra lo stesso gruppo di dispositivi PE multi-homing, un mix di dispositivi PE con incapsulamenti MPLS over GRE che eseguono le procedure da [RFC7432] per il filtraggio split-horizon da un lato e incapsulamento VXLAN/NVGRE che esegue procedure di local-bias dall'altro su un dato segmento Ethernet NON DEVE essere configurato.

8.3.2. Aliasing and Backup Path (Aliasing e percorso di backup)

Le procedure di Aliasing e Backup Path per l'incapsulamento VXLAN/NVGRE sono molto simili a quelle per MPLS. Nel caso di MPLS, la route Ethernet A-D per EVI viene utilizzata per l'Aliasing quando l'ES corrispondente opera in multi-homing All-Active, e la stessa route viene utilizzata per Backup Path quando l'ES corrispondente opera in multi-homing Single-Active. Nel caso di VXLAN/NVGRE, la stessa route viene utilizzata per l'Aliasing e il Backup Path con la differenza che i campi Ethernet Tag e VNI nella route Ethernet A-D per EVI sono impostati come descritto nella Sezione 5.1.3.

8.3.3. Unknown Unicast Traffic Designation (Designazione del traffico unicast sconosciuto)

In EVPN, quando un PE di ingresso utilizza la replica di ingresso per inondare il traffico unicast sconosciuto ai PE di uscita, il PE di ingresso utilizza un'etichetta MPLS EVPN diversa (da quella utilizzata per il traffico unicast noto) per identificare tale traffico BUM. I PE di uscita utilizzano questa etichetta per identificare tale traffico BUM e, quindi, applicare il filtraggio DF per i siti multi-homed All-Active. In assenza di una designazione del traffico unicast sconosciuto e in presenza dell'abilitazione dell'inondazione di unicast sconosciuto, ci può essere traffico duplicato transitorio verso i siti multi-homed All-Active nella seguente condizione: l'indirizzo MAC dell'host è appreso dai PE di uscita e pubblicizzato al PE di ingresso; tuttavia, il MAC Advertisement non è stato ricevuto o elaborato dal PE di ingresso, risultando nell'indirizzo MAC dell'host essere sconosciuto sul PE di ingresso ma noto sui PE di uscita. Pertanto, quando un pacchetto destinato a quell'indirizzo MAC dell'host arriva sul PE di ingresso, lo inonda tramite replica di ingresso a tutti i PE di uscita, e poiché sono noti ai PE di uscita, più copie vengono inviate al sito multi-homed All-Active. Si noti che tale duplicazione di pacchetti transitoria si verifica solo quando a) l'host di destinazione è multi-homed tramite modalità di ridondanza All-Active, b) l'inondazione di unicast sconosciuto è abilitata nella rete, c) viene utilizzata la replica di ingresso, e d) il traffico per l'host di destinazione è arrivato sul PE di ingresso prima che apprenda l'indirizzo MAC dell'host tramite pubblicità BGP EVPN. Se si desidera evitare il verificarsi di tale duplicazione di pacchetti transitoria (per quanto bassa possa essere la probabilità), allora l'incapsulamento VXLAN-GPE deve essere utilizzato tra questi PE e il PE di ingresso deve impostare il BUM Traffic Bit (B bit) [VXLAN-GPE] per indicare che questo è un traffico BUM replicato in ingresso.