Passa al contenuto principale

7. Single-Homing NVEs - NVE Residing in Hypervisor (NVE a singolo homing - NVE residente nell'hypervisor)

7. Single-Homing NVEs - NVE Residing in Hypervisor (NVE a singolo homing - NVE residente nell'hypervisor)

Quando un NVE e i suoi host/VM sono co-locati nello stesso dispositivo fisico, ad esempio, quando risiedono in un server, i collegamenti tra loro sono virtuali e tipicamente condividono lo stesso destino. Cioè, gli host/VM in questione tipicamente non sono multihomed o, se lo sono, il multihoming è una questione puramente locale al server che ospita la VM e gli NVE, e non deve essere "visibile" ad altri NVE residenti su altri server. Quindi, non richiede alcun meccanismo di protocollo specifico. Il caso più comune di ciò è quando l'NVE risiede sull'hypervisor.

Nelle sottosezioni che seguono, discuteremo l'impatto sulle procedure EVPN per il caso in cui l'NVE risieda sull'hypervisor e venga utilizzato l'incapsulamento VXLAN (o NVGRE).

7.1. Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE Encapsulations (Impatto sulle route e attributi BGP EVPN per incapsulamenti VXLAN/NVGRE)

Negli scenari in cui diversi gruppi di data center si trovano sotto diversi domini amministrativi, e questi data center sono connessi tramite uno o più provider core backbone come descritto in [RFC7365], l'RD deve essere un valore univoco per EVI o per NVE come descritto in [RFC7432]. In altre parole, ogni volta che c'è più di un dominio amministrativo per VNI globale, deve essere utilizzato un RD univoco; o, ogni volta che il valore VNI ha significato locale, deve essere utilizzato un RD univoco. Pertanto, si raccomanda di utilizzare un RD univoco come descritto in [RFC7432] in ogni momento.

Quando gli NVE risiedono sull'hypervisor, le route e gli attributi BGP EVPN associati al multihoming non sono più necessari. Questo riduce le route e gli attributi richiesti al seguente sottoinsieme di quattro su un totale di otto elencati nella Sezione 7 di [RFC7432]:

  • MAC/IP Advertisement Route
  • Inclusive Multicast Ethernet Tag Route
  • MAC Mobility Extended Community
  • Default Gateway Extended Community

Tuttavia, come notato nella Sezione 8.6 di [RFC7432], per consentire a un NVE di ingresso a singolo homing di sfruttare la convergenza rapida, l'Aliasing e il Backup Path quando interagisce con NVE di uscita multihomed collegati a un dato ES, l'NVE di ingresso a singolo homing dovrebbe essere in grado di ricevere e processare route che sono Ethernet A-D per ES ed Ethernet A-D per EVI.

7.2. Impact on EVPN Procedures for VXLAN/NVGRE Encapsulations (Impatto sulle procedure EVPN per incapsulamenti VXLAN/NVGRE)

Quando gli NVE risiedono sugli hypervisor, le procedure EVPN associate al multihoming non sono più necessarie. Questo limita le procedure sull'NVE al seguente sottoinsieme:

  1. Apprendimento locale degli indirizzi MAC ricevuti dalle VM secondo la Sezione 10.1 di [RFC7432].

  2. Pubblicizzazione degli indirizzi MAC appresi localmente in BGP utilizzando le route MAC/IP Advertisement.

  3. Esecuzione dell'apprendimento remoto utilizzando BGP secondo la Sezione 9.2 di [RFC7432].

  4. Scoperta di altri NVE e costruzione dei tunnel multicast utilizzando le route IMET.

  5. Gestione degli eventi di mobilità degli indirizzi MAC secondo le procedure della Sezione 15 in [RFC7432].

Tuttavia, come notato nella Sezione 8.6 di [RFC7432], per consentire a un NVE di ingresso a singolo homing di sfruttare la convergenza rapida, l'Aliasing e il Backup Path quando interagisce con NVE di uscita multihomed collegati a un dato ES, un NVE di ingresso a singolo homing dovrebbe implementare l'elaborazione del nodo di ingresso delle route che sono Ethernet A-D per ES ed Ethernet A-D per EVI come definito nelle Sezioni 8.2 ("Fast Convergence") e 8.4 ("Aliasing and Backup Path") di [RFC7432].