10. Data-Center Interconnections (DCIs) (Interconnessioni tra data center)

Per i DCI, vengono considerati i seguenti due scenari principali quando si collegano data center che eseguono evpn-overlay (come descritto qui) su una rete core MPLS/IP:

Scenario 1: DCI utilizzando GW
Scenario 2: DCI utilizzando ASBR

Le seguenti due sottosezioni descrivono le operazioni per ciascuno di questi scenari.

10.1. DCI Using GWs (DCI utilizzando gateway)

Questo è lo scenario tipico per interconnettere data center su WAN. In questo scenario, le route EVPN vengono terminate e processate in ogni GW e le route MAC/IP vengono sempre ri-annunciate dal DC al WAN ma dal WAN al DC, non vengono ri-annunciate se vengono utilizzati indirizzi MAC sconosciuti (e indirizzo IP predefinito) negli NVE. In questo scenario, ogni GW mantiene una MAC-VRF (e/o IP-VRF) per ogni EVI. Il vantaggio principale di questo approccio è che gli NVE non hanno bisogno di mantenere indirizzi MAC e IP da data center remoti quando vengono utilizzate route IP predefinite e route MAC sconosciute; cioè, devono solo mantenere route locali al proprio DC. Quando vengono utilizzate route IP predefinite e route MAC sconosciute, tutti i pacchetti IP e MAC sconosciuti dagli NVE vengono inoltrati ai GW dove vengono mantenute tutte le route MAC e IP VPN. Questo approccio riduce significativamente le dimensioni di MAC-VRF e IP-VRF negli NVE. Inoltre, risulta in un tempo di convergenza più veloce in caso di guasto di link o NVE in uno scenario di rete multihomed o ridondanza del dispositivo, perché le route BGP relative al guasto (come il messaggio di ritiro di massa) non devono essere propagate fino agli NVE remoti nei DC remoti. Questo approccio è descritto in dettaglio nella sezione 3.4 di [DCI-EVPN-OVERLAY].

10.2. DCI Using ASBRs (DCI utilizzando ASBR)

Questo approccio può essere considerato come l'opposto del primo approccio. Favorisce la semplificazione nei dispositivi DCI rispetto agli NVE in modo tale che tabelle MAC-VRF (e IP-VRF) più grandi debbano essere mantenute sugli NVE; mentre i dispositivi DCI non hanno bisogno di mantenere tabelle di forwarding MAC (e IP). Inoltre, i dispositivi DCI non hanno bisogno di terminare e processare route relative al multihoming ma piuttosto di inoltrare questi messaggi per l'instaurazione di un Label Switched Path (LSP) end-to-end. In altre parole, i dispositivi DCI in questo approccio operano in modo simile agli ASBR per l'opzione B inter-AS (vedere sezione 10 di [RFC4364]). Questo richiede l'uso di VNI assegnati localmente proprio come le label VPN MPLS assegnate downstream dove, per tutti gli scopi pratici, i VNI funzionano come label VPN a 24 bit. Questo approccio è ugualmente applicabile ai data center (o reti Carrier Ethernet) con incapsulamento MPLS.

Nell'opzione B inter-AS, quando ASBR riceve una route EVPN dal suo DC tramite internal BGP (iBGP) e la ri-annuncia ad altri ASBR, ri-annuncia la route EVPN riscrivendo il BGP next hop su se stesso, perdendo così l'identità del PE che ha originato l'annuncio. Questa riscrittura del BGP next hop impatta negativamente la route di ritiro di massa EVPN (Ethernet A-D per ES) e la sua procedura. Tuttavia, non impatta il meccanismo/procedura di Aliasing EVPN perché quando le route di Aliasing (Ethernet A-D per EVI) vengono annunciate, il PE ricevente risolve prima un indirizzo MAC per un dato EVI nel suo corrispondente <ES, EVI>, e, successivamente, risolve il <ES, EVI> in più percorsi (e i loro next hop associati) tramite i quali il <ES, EVI> è raggiungibile. Poiché sia le route di Aliasing che MAC vengono annunciate su base per-EVI e usano lo stesso RD e RT (per EVI), il PE ricevente può associarle insieme su base per-percorso-BGP (ad esempio, per PE di origine). Così, può eseguire una risoluzione di route ricorsiva, ad esempio, un MAC è raggiungibile tramite un <ES, EVI> che, a sua volta, è raggiungibile tramite un insieme di percorsi BGP; quindi, il MAC è raggiungibile tramite l'insieme di percorsi BGP. A causa della base per-EVI, l'associazione delle route MAC e della route di Aliasing corrispondente è fissa e determinata dallo stesso RD e RT; non c'è ambiguità quando il BGP next hop per queste route viene riscritto mentre queste route passano attraverso gli ASBR. Cioè, il PE ricevente può ricevere più route di Aliasing per lo stesso EVI da un singolo next hop (un singolo ASBR), e può comunque creare più percorsi verso quel <ES, EVI>.

Tuttavia, quando l'indirizzo BGP next-hop corrispondente al PE di origine viene riscritto, l'associazione tra la route di ritiro di massa (Ethernet A-D per ES) e le sue route MAC corrispondenti non può essere fatta in base ai loro RD e RT perché il RD per la route di ritiro di massa è diverso da quello per le route MAC. Pertanto, la funzionalità necessaria negli ASBR e nei PE riceventi dipende dal fatto che la route di ritiro di massa venga originata e se ci sia necessità di gestire l'ambiguità di risoluzione della route per questa route. Le seguenti due sottosezioni descrivono la funzionalità necessaria dagli ASBR e dai PE riceventi a seconda che gli NVE risiedano negli hypervisor o negli switch ToR.

10.2.1. ASBR Functionality with Single-Homing NVEs (Funzionalità ASBR con NVE single-homing)

Quando gli NVE risiedono negli hypervisor come descritto nella sezione 7.1, non c'è multihoming; quindi, non c'è necessità per l'NVE di origine di inviare route Ethernet A-D per ES o Ethernet A-D per EVI. Tuttavia, come notato nella sezione 7, al fine di consentire a un NVE di ingresso single-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 single-homing dovrebbe essere in grado di ricevere e processare route Ethernet A-D per ES ed Ethernet A-D per EVI. La gestione di queste route è descritta nella sezione successiva.

10.2.2. ASBR Functionality with Multihoming NVEs (Funzionalità ASBR con NVE multihoming)

Quando gli NVE risiedono negli switch ToR e operano in modalità di ridondanza multihoming, c'è necessità, come descritto nella sezione 8, per l'NVE multihoming di origine di inviare route Ethernet A-D per ES (utilizzate per il ritiro di massa) e route Ethernet A-D per EVI (utilizzate per l'Aliasing). Come descritto sopra, la riscrittura del BGP next hop da parte degli ASBR crea ambiguità quando le route Ethernet A-D per ES vengono ricevute dall'NVE remoto in un AS diverso perché l'NVE ricevente non può associare quella route con le route MAC/IP di quell'ES annunciate dallo stesso NVE di origine. Questa ambiguità inibisce la funzione di ritiro di massa per ES dall'NVE ricevente in un AS diverso.

Come esempio, consideriamo uno scenario in cui un CE è multihomed a PE1 e PE2, dove questi PE sono connessi tramite ASBR1 e poi ASBR2 al PE3 remoto. Inoltre, consideriamo che PE1 riceve M1 da CE1 ma non PE2. Pertanto, PE1 annuncia Ethernet A-D per ES1, Ethernet A-D per EVI1 e M1; mentre PE2 annuncia solo Ethernet A-D per ES1 ed Ethernet A-D per EVI1. ASBR1 riceve tutti questi cinque annunci e li passa ad ASBR2 (con se stesso come BGP next hop). ASBR2, a sua volta, li passa al PE3 remoto, con se stesso come BGP next hop. PE3 riceve queste cinque route dove tutte hanno lo stesso BGP next hop (cioè ASBR2). Inoltre, le due route Ethernet A-D per ES ricevute da PE3 hanno le stesse informazioni, cioè stesso ESI e stesso BGP next hop. Sebbene entrambe queste route siano mantenute dal processo BGP in PE3 (perché hanno RD diversi e, quindi, sono trattate come route BGP diverse), le informazioni di solo una di esse vengono utilizzate nella tabella di routing L2 (L2 RIB).

                  PE1
                 /   \
                CE     ASBR1---ASBR2---PE3
                 \   /
                  PE2

                Figura 3: Opzione B inter-AS

Ora, quando l'AC tra PE2 e il CE fallisce e PE2 invia un ritiro Network Layer Reachability Information (NLRI) per la route Ethernet A-D per ES, e questo ritiro viene propagato e ricevuto da PE3, il processo BGP in PE3 rimuove la route BGP corrispondente; tuttavia, non rimuove le informazioni associate (vale a dire ESI e BGP next hop) dalla tabella di routing L2 (L2 RIB) perché ha ancora l'altra route Ethernet A-D per ES (originata da PE1) con le stesse informazioni. Ecco perché il meccanismo di ritiro di massa non funziona quando si fa DCI con l'opzione B inter-AS. Tuttavia, come descritto in precedenza, la funzione di Aliasing funziona e così anche il "ritiro di massa per EVI" (che è associato al ritiro della route EVPN associata all'Aliasing, cioè route Ethernet A-D per EVI).

Nell'esempio sopra, PE3 riceve due route di Aliasing con lo stesso BGP next hop (ASBR2) ma RD diversi. Una delle route di Aliasing ha lo stesso RD della route MAC annunciata (M1). PE3 segue la procedura di risoluzione della route specificata in [RFC7432] al momento della ricezione delle due route di Aliasing; cioè, risolve M1 in <ES, EVI1>, e, successivamente, risolve <ES, EVI1> in una lista di percorsi BGP con due percorsi insieme ai corrispondenti VNI/label MPLS (uno associato a PE1 e l'altro associato a PE2). Si noti che anche se entrambi i percorsi sono annunciati dallo stesso BGP next hop (ASRB2), il PE3 ricevente può gestirli correttamente. Pertanto, M1 è raggiungibile tramite due percorsi. Questo crea due LSP end-to-end, da PE3 a PE1 e da PE3 a PE2, per M1 tale che quando PE3 vuole inoltrare traffico destinato a M1, può bilanciare il carico tra i due LSP. Sebbene la risoluzione della route per le route di Aliasing con lo stesso BGP next hop non sia esplicitamente menzionata in [RFC7432], questa è l'operazione prevista; quindi, viene elaborata qui.

Quando l'AC tra PE2 e il CE fallisce e PE2 invia il ritiro NLRI per le route Ethernet A-D per EVI, e questi ritiri vengono propagati e ricevuti da PE3, PE3 rimuove la route di Aliasing e aggiorna la lista dei percorsi; cioè, rimuove il percorso corrispondente a PE2. Pertanto, tutte le route MAC corrispondenti per quell'<ES, EVI> che puntano a quella lista di percorsi avranno ora la lista di percorsi aggiornata con un singolo percorso associato a PE1. Questa azione può essere considerata come il ritiro di massa a livello per-EVI. Il ritiro di massa a livello per-EVI ha un tempo di convergenza più lungo rispetto al ritiro di massa a livello per-ES; tuttavia, è molto più veloce del tempo di convergenza quando il ritiro viene effettuato su base per-MAC.

Se un PE viene disconnesso da un dato ES, allora, oltre a ritirare le sue route Ethernet A-D per ES precedentemente annunciate, DEVE anche ritirare le sue route Ethernet A-D per EVI precedentemente annunciate per quell'ES. Per un PE remoto che è separato dal PE che effettua il ritiro da uno o più ASBR dell'opzione B inter-AS EVPN, il ritiro delle route Ethernet A-D per ES non è azionabile. Tuttavia, un PE remoto è in grado di correlare una route Ethernet A-D per EVI precedentemente annunciata con qualsiasi route MAC/IP Advertisement anch'essa annunciata dal PE che effettua il ritiro per quell'<ES, EVI, BD>. Quindi, quando riceve il ritiro di una route Ethernet A-D per EVI, DOVREBBE rimuovere il PE che effettua il ritiro come next hop per tutti gli indirizzi MAC associati a quell'<ES, EVI, BD>.

Nell'esempio precedente, quando l'AC tra PE2 e il CE fallisce, PE2 ritirerà le sue route Ethernet A-D per ES e per EVI. Quando PE3 riceve il ritiro di una route Ethernet A-D per EVI, rimuove PE2 come next hop valido per tutti gli indirizzi MAC associati al corrispondente <ES, EVI, BD>. Pertanto, tutti i next hop MAC per quell'<ES, EVI, BD> avranno ora un singolo next hop, ovvero l'LSP verso PE1.

In sintesi, si può vedere che la funzionalità di Aliasing (e Backup Path) dovrebbe funzionare così com'è per l'opzione B inter-AS senza richiedere funzionalità aggiuntive negli ASBR o nei PE. Tuttavia, la funzionalità di ritiro di massa torna dalla modalità per-ES alla modalità per-EVI per l'opzione B inter-AS. Cioè, i PE che ricevono una route di ritiro di massa dallo stesso AS agiscono sulla route Ethernet A-D per ES; mentre i PE che ricevono route di ritiro di massa da AS diversi agiscono sulla route Ethernet A-D per EVI.