Nei due post precedenti sul modello EVPN ho illustrato i concetti e le idee fondamentali, focalizzando l’attenzione soprattutto sulle problematiche legate alla gestione dei collegamenti multi-homed e alla connettività di Livello 2. Però, come ricorderete, nei messaggi UPDATE BGP EVPN contenenti NLRI di tipo MAC/IP Advertisement, vi è la possibilità (opzionale !) di annunciare uno o più indirizzi IPv4/v6 associati all’indirizzo MAC (NOTA: ricordo che nel caso vi siano due o più indirizzi IP associati all’indirizzo MAC, ad esempio negli Host dual stack IPv4/IPv6, sono necessari più messaggi BGP EVPN con NLRI di tipo MAC/IP Advertisement, uno per ciascun indirizzo IP).
Questo aspetto del modello EVPN consente ulteriori ottimizzazioni, e gioca un ruolo molto importante nell’inter-vlan routing. Questo post sarà proprio focalizzato sull’integrazione L2/L3 nel modello EVPN.
 
PROXY ARP/ND
Uno degli aspetti interessanti del modello EVPN è che consente di ridurre il traffico broadcast sulla rete, in particolare il traffico dei messaggi ARP. I router PE, grazie alla conoscenza degli indirizzi IP associati agli indirizzi MAC, possono infatti svolgere la funzione di Proxy ARP (o Proxy ND nel caso di indirizzi IPv6), ossia rispondere direttamente ai messaggi ARP Request (o Neighbor Solicitation nel caso di indirizzi IPv6). Per semplicità considererò da qui in avanti solo la funzione Proxy ARP, essendo la funzione Proxy ND concettualmente identica.
Per capire bene il (semplice) funzionamento, farò riferimento alla figura seguente, dove è illustrato l’annuncio di tipo MAC/IP Advertisement da parte di PE2-1, con il quale viene annunciata la coppia <MAC-2; IP-2>.
 

 
Come faccia un PE ad apprendere un indirizzo IP associato a un indirizzo MAC l’ho spiegato nel post precedente (es. ARP/DHCP snooping, Gratuitous ARP, Reverse ARP, ecc.). Questo, seppur importante, è comunque un aspetto secondario.
Giusto per ricapitolare, questa è la sequenza degli eventi:

1. L’Host 2, non appena va online invia un qualche messaggio a CE2 per segnalare la sua presenza e CE2 lo propaga a PE2-1. Il tipo di messaggio dipende dal tipo di Hypervisor o dal tipo di sistema operativo utilizzato dall’Host. Solo per fare un paio di esempi, l’Hyper-V di Microsoft, non appena una macchina virtuale va online (o anche quando la macchina migra da un server fisico ad un altro), invia un messaggio GARP (Gratuitous ARP); il vCenter di VMware (almeno fino all’ESX 5.5) invia invece un messaggio RARP (Reverse ARP) (NOTA: curiosamente i messaggi RARP non contengono il proprio indirizzo di Livello 3, ma vengono utilizzati per richiederlo, come ad esempio avviene con il DHCP. Chi non lo avesse mai sentito nominare, visto che ormai il RARP è stato soppiantato da anni dal DHCP, può migliorare le proprie conoscenze storiche del Networking IP andandosi a guardare la RFC 903 del Giugno 1984 !).
2. Non appena PE2-1 apprende la presenza della coppia <MAC-2; IP-2>, genera un messaggio UPDATE BGP EVPN contenente un NLRI di tipo MAC/IP Advertisement, per annunciare agli altri PE che partecipano alla stessa EVI, la coppia <MAC-2; IP-2>.
3. Sulla tabella MAC-VRF degli altri PE che partecipano alla stessa EVI (nella figura PE1-1 e PE1-2) , oltre all’informazione sull’indirizzo MAC-2, verrà quindi memorizzata anche l’informazione sull’indirizzo IP-2 associato.

Si supponga ora che l’Host 1, che appartiene alla stessa VLAN dell’Host 2, voglia inviare a quest’ultimo un pacchetto IP. Come da copione classico, l’Host 1, non conoscendo l’indirizzo MAC, invia un messaggio ARP Request, che ricordo ha indirizzo MAC destinazione broadcast (= ffff.ffff.ffff). In una classica rete L2, o ad esempio anche nel servizio VPLS (che emula una rete L2 !), il messaggio ARP verrebbe propagato con il meccanismo del flooding a tutti i PE che partecipano alla stessa EVI. Nel modello EVPN però la propagazione del messaggio ARP Request può essere evitata, sfruttando proprio la conoscenza diffusa degli indirizzi IP associati agli indirizzi MAC (sincronizzazione MAC/IP).
Ritornando all’esempio, quando il messaggio ARP Request inviato dall’Host 1 arriva al router PE1-1, questo ha tutte le informazioni necessarie per rispondere, senza quindi il bisogno di propagare il messaggio ARP Request agli altri PE.
La figura seguente riassume la sequenza degli eventi.
 

 

1. L’Host 1 invia un messaggio ARP Request con il quale richiede la conoscenza dell’indirizzo MAC associato all’indirizzo IP destinazione IP-2.
2. Il router PE1-1 intercetta il messaggio ARP Request e, poiché conosce già dalla tabella MAC-VRF l’associazione <MAC-2; IP-2>, risponde direttamente con un messaggio ARP Reply, facendo le veci del router PE2-1 (funzione Proxy ARP).
3. L’Host 1, analizzando il messaggio ARP Reply, impara l’associazione <MAC-2; IP-2> e quindi è in grado di inviare traffico IP all’Host 2. Si noti comunque che i pacchetti IP inviati dall’Host 1 all’Host 2, vengono commutati a Livello 2 e non a Livello 3 (come d’altra parte avviene in un classico segmento Ethernet).

Potrebbe accadere che l’Host 2 sia “silente”, ossia che non abbia ancora manifestato la sua presenza nel momento in cui l’Host 1 invia il messaggio ARP Request, oppure che sia rimasto in silenzio e che sia scaduta l’associazione <MAC-2; IP-2> sulla tabella ARP di PE2-1. In questo caso il router PE1-1 non ha informazioni sull’associazione <MAC-2; IP-2>, e quindi è obbligato a seguire il copione classico dell’ARP nelle reti L2, ossia invia il messaggio ARP Request a tutti i PE che partecipano alla stesa istanza EVI (flooding).
Per i più curiosi in cerca di approfondimenti sugli aspetti operativi del Proxy ARP/ND nel modello EVPN, consiglio la lettura di questo breve documento IETF .
 
INTEGRAZIONE DI ROUTING E BRIDGING
Il fatto che il modello EVPN preveda nei suoi annunci BGP EVPN la possibilità di annunciare la coppia <MAC; IP> di un Host, consente di integrare e ottimizzare le funzioni di routing e bridging. La funzione di bridging in realtà parte già ottimizzata da tutte le funzionalità già presenti nel modello EVPN. Per il traffico intra-VLAN (o anche, in modo equivalente, intra-subnet) quindi tutte le problematiche più importanti sono già risolte dal modello EVPN. Il problema è come rendere ottimale anche il trasporto del traffico inter-VLAN (inter-subnet).
Il modello EVPN affronta queste problematiche attraverso delle funzionalità che integrano il trasporto L2 (anche noto come bridging) e il trasporto L3 (anche noto come routing). L’insieme di queste funzionalità è noto come Integrated Routing and Bridging (IRB), ed è l’oggetto di un documento IETF ancora allo stato di draft: “Integrated Routing and Bridging in EVPN” (draft-ietf-bess-evpn-inter-subnet-forwarding-01; NOTA: bess non è il nome dell’autore del draft, ma un acronimo che sta per BGP Enabled ServiceS).
Le funzionalità IRB di EVPN sono utili anche perché consentono di integrare il modello EVPN con il classico modello L3VPN, e questo è molto utile per la fornitura di servizi cloud ai propri clienti. Per maggiore flessibilità e scalabilità, per ciascun cliente (tenant) è possibile definire più domini broadcast (o domini di bridging) all’interno di ciascuna EVI, e quindi associare una o più EVI a una singola istanza L3VPN (VRF).
Per il supporto di questo modello è necessario definire una interfaccia virtuale IRB, che faccia da “ponte” tra le funzioni di Livello 2 e Livello 3. Inoltre, ciascun dominio di bridging si mappa ad un’unica subnet IP nella VRF.
In generale, a ciascun tenant di un Data Center è assegnata una singola L3VPN VRF, ma possono essere associate più EVI e uno o più domini di bridging per ciascuna EVI. La figura seguente riporta un esempio di un tenant che ha 4 domini di bridging, uno, identificato dalla VLAN 10, associato all’istanza EVPN EVI-1 e tre, identificati dalle VLAN 21, 22, 23, associati all’istanza EVPN EVI-2. A ciascuno dei 4 domini di bridging viene associata una subnet IP e una interfaccia virtuale IRB, il cui indirizzo IP è parte della subnet IP associata, e viene utilizzato come default gateway per il traffico inter-vlan.
 

 
Ci sono due funzioni chiave per il supporto delle funzionalità EVPN IRB:

1. Sincronizzazione delle associazioni <MAC; IP>: questa avviene, come più volte detto, attraverso l’utilizzo degli annunci BGP EVPN con NLRI di tipo MAC/IP Advertisement. Alla ricezione di questi annunci, un PE installa nella tabella MAC-VRF associata a una EVI la coppia <MAC; Next-Hop>, e nella VRF della L3VPN associata l’indirizzo IP.
2. Sincronizzazione dei Default Gateway: questa avviene sempre attraverso annunci BGP EVPN con NLRI di tipo MAC/IP Advertisement, dove la coppia <MAC; IP> annunciata corrisponde rispettivamente agli indirizzi MAC e IP dell’interfaccia IRB (per i lettori familiari con l’ambiente Cisco, credo tutti, questa altro non è che la classica “interfaccia VLAN”). Alla ricezione di questi annunci, un PE crea un forwarding state per il routing dei pacchetti IP, incapsulati in trame Ethernet con MAC destinazione il MAC dell’interfaccia IRB (che altro non è che il MAC del default gateway). Il PE esegue anche la funzione di Proxy ARP/ND per il default gateway (ossia, risponde ai messaggi ARP Request degli Host, che richiedono l’indirizzo MAC corrispondente all’indirizzo IP del default gateway).

 
SINCRONIZZAZIONE DEI DEFAULT GATEWAY
Come noto, la comunicazione tra VLAN (inter-VLAN routing) avviene a Livello 3, definendo una interfaccia virtuale (interfaccia VLAN nella terminologia Cisco, interfaccia IRB (Integrated Routing and Bridging) nella documentazione Juniper e in molti documenti ufficiali IETF), il cui indirizzo IP funge da Default Gateway per gli Host delle VLAN coinvolte. Nel modello EVPN il funzionamento è analogo, solo che bisogna fare attenzione ad evitare una sorta di effetto trombooning, che rende il routing non ottimale.
L’importanza della sincronizzazione dei default gateway può essere apprezzata vedendo cosa accade senza di questa. Si consideri l’esempio nella figura seguente, dove l’Host H3, appartenente alla VLAN 10 e attestato a CE3, voglia scambiare traffico IP con l’Host H2, appartenente alla VLAN 20. Gli Host H2 e H3 sono connessi rispettivamente a CE2 e CE3, entrambi connessi a PE2.
 

 
La funzione di default gateway è assegnata al router PE1, dove è configurata una interfaccia IRB con indirizzo IP = IP-DG e indirizzo MAC = MAC-DG. Il router PE1 genera un messaggio BGP EVPN con NLRI di tipo MAC/IP Advertisement per annunciare la coppia <MAC-DG; IP-DG>. PE2 riceve l’annuncio e inserisce nella MAC-VRF associata all’istanza EVPN EVI-10, l’informazione <MAC-DG; Next-Hop = PE1>. Si noti che per PE2 questo è un normale annuncio di una generica coppia <MAC; IP>; PE2 è totalmente ignaro che la coppia <MAC; IP> identifica un default gateway. Ora, questa è la sequenza degli eventi che accade quando H3 invia un pacchetto IP a H2:

1. H3 invia un messaggio ARP Request a PE3 (via CE3) per chiedere l’indirizzo MAC corrispondente all’indirizzo IP del default gateway (= IP-DG).
2. PE3 intercetta il messaggio ARP Request e risponde direttamente (funzione di Proxy ARP) inviando a H3 un ARP Reply. H3 apprende così l’indirizzo MAC del default gateway (= MAC-DG).
3. H3 invia un pacchetto IP con indirizzo IP destinazione di H2 (= IP-2) e indirizzo IP sorgente il proprio (= IP-3). Il pacchetto IP viene incapsulato in una trama Ethernet con indirizzo MAC sorgente di H3 (= MAC-3) e indirizzo MAC destinazione del default gateway (= MAC-DG).
4. PE2 invia la trama Ethernet, incapsulata con le opportune etichette MPLS, al Next-Hop PE1.
5. PE1, dopo l’operazione di label pop, riceve la trama Ethernet con indirizzo MAC destinazione MAC-DG. Questo significa che deve eseguire un lookup a livello IP, per inoltrare il pacchetto verso l’indirizzo IP destinazione (= IP-2), ossia, in altre parole PE1 esegue l’operazione di inter-vlan routing.
6. Il pacchetto viene quindi inoltrato, via routing IP classico, all’Host destinazione H2 (in realtà, come mostrerò nel seguito, il routing IP non è tanto classico; nella figura ho omesso gli indirizzi MAC utilizzati, poiché dipendono dalla modalità di inter-vlan routing scelta, simmetrica o asimmetrica).

Come si può notare, vi è un effetto trombooning in azione, poiché il pacchetto IP ricevuto da PE2, raggiunge H2 passando per PE1 e quindi ritornando a PE2. Non molto efficiente per la verità.
La sincronizzazione dei default gateway presente nel modello EVPN, consente di risolvere il problema, distribuendo su tutti i PE che partecipano all’EVI, la funzione di default gateway. Ciò significa che ciascun PE che partecipa ad una determinata EVI, può svolgere la funzione di default gateway.
Ci sono due modi per sincronizzare i default gateway, uno statico e uno dinamico. Nella modalità statica, si configura su ciascun PE che partecipa all’EVI, una interfaccia IRB con identico indirizzo MAC e identico indirizzo IP, per ciascuna VLAN che fa parte dell’EVI. Per questo la modalità statica viene talvolta chiamata Distributed IP Anycast Gateway. Si noti che in questo caso la sincronizzazione è automatica, nel senso che non vi è bisogno per ciascun PE di annunciarsi agli altri PE come default gateway attraverso dei messaggi BGP EVPN. Per questo i costruttori, per evitare l’annuncio automatico (inutile) della coppia <MAC-DG; IP-DG> via annunci BGP EVPN, mettono a disposizione dei comandi di configurazione (es. nel JUNOS il comando “[edit routing-instances NOME-EVI] set protocols evpn default-gateway do-not-advertise”).
 
 
 
Nella modalità dinamica è prevista la possibilità di utilizzare indirizzi MAC e/o IP dei default gateway, diversi da PE a PE, per la stessa subnet IP. La sincronizzazione avviene attraverso annunci BGP EVPN con NLRI di tipo MAC/IP Advertisement, che contengono l’Extended Community Default Gateway (l’unica di cui non avevo ancora spiegato l’utilizzo). In un certo senso ciò che avviene è una sorta di aliasing del default gateway, ossia è come se il default gateway fosse virtualmente unico, con unico indirizzo IP e MAC, anche se in realtà non è vero. Si noti comunque, che è possibile utilizzare tranquillamente lo stesso indirizzo MAC, per tutte le subnet IP (come d’altra parte è anche possibile nell’inter-vlan routing tradizionale).
Quale tra le due soluzioni è preferibile ? La best practice corrente, benché la soluzione dinamica dia maggiori gradi di libertà, suggerisce di utilizzare la prima. Questo perché avere un unico IP e MAC semplifica le configurazioni, poiché consente di assegnare a tutti gli Host dello stesso segmento LAN lo stesso default gateway, riduce l’overhead del piano di controllo poiché non vi è bisogno del default gateway aliasing, e minimizza il tempo di ripristino nel caso di fuori servizio di un PE. Per quanto riguarda invece la mobilità degli Host, entrambi i metodi sono equivalenti.
La funzione Distributed IP Anycast Gateway non è peculiare del modello EVPN, ma è stata introdotto anche in altre tecnologie di tipo proprietario (vedi ad esempio la funzionalità di Virtual ARP introdotta da Arista).
 
INTER-VLAN ROUTING: MODALITÀ DI FORWARDING
A questo punto, risolto il nodo del default gateway, manca un solo tassello per completare il quadro, ossia vedere come avviene l’inter-vlan routing. E qui ci sono due modalità alternative, asimmetrica e simmetrica. Gli aggettivi asimmetrico/simmetrico si riferiscono a come avviene il lookup per il forwarding del traffico inter-subnet nei due PE di ingresso e uscita.
Nella modalità asimmetrica, il forwarding avviene con un doppio lookup sul PE di ingresso e un singolo lookup sul PE di uscita (da qui l’aggettivo asimmetrico). Sul PE di ingresso, il primo lookup è di tipo L2 e viene effettuato sulla tabella MAC-VRF, mentre il secondo è un lookup L3 sulla VRF. Sul PE di uscita invece il singolo lookup è di tipo L2 e viene effettuato sulla tabella MAC-VRF. Il percorso dei pacchetti IP e i lookup per l’instradamento sono schematizzati nella figura seguente.
 
 
Nella modalità simmetrica, il forwarding avviene con un doppio lookup sia sul PE di ingresso che su quello di uscita (da qui l’aggettivo simmetrico). Sul PE di ingresso, il primo lookup è di tipo L2 e viene effettuato sulla tabella MAC-VRF, mentre il secondo è un lookup L3 sulla VRF associata. Sul PE di uscita, viceversa, il primo lookup è di tipo L3 e il secondo di tipo L2. Il percorso dei pacchetti IP e i lookup per l’instradamento sono schematizzati nella figura seguente.
 
 
 
PIANO DI CONTROLLO L2/L3 INTEGRATO
Prima di vedere i dettagli sul funzionamento delle modalità di forwarding asimmetrica e simmetrica, è necessario fare maggiore luce sul funzionamento del piano di controllo nell’integrazione L2/L3. Ciò che dirò spiega le funzioni logiche del piano di controllo, le implementazioni dei vari costruttori potrebbero differire leggermente, ma i concetti rimangono validi.
Quando un PE apprende (via GARP, RARP, ecc.) un’associazione <MAC; IP> da un CE parte di una EVI, questo esegue sul piano di controllo due azioni:

1. Il PE installa nella tabella MAC-VRF associata alla EVI, la coppia <MAC; Porta> e nella VRF IP associata, una Host route IP (/32 in IPv4, /128 in IPv6) che ha come Next-Hop l’interfaccia IRB associata alla MAC-VRF e come protocollo EVPN.
2. Il PE annuncia ai PE remoti l’associazione <MAC; IP>, attraverso un annuncio BGP EVPN con NLRI di tipo 2 (MAC/IP Advertisement). Questo annuncio contiene due Route-Target (RT), uno corrispondente alla EVI e l’altro alla VRF IP. Inoltre, nei campi “MPLS Label1” e “MPLS Label2” sono contenute due etichette MPLS, la prima è la EVPN label (service label per il servizio L2VPN via modello EVPN) e la seconda la L3VPN label (service label per il servizio L3VPN).

I PE remoti, alla ricezione dell’annuncio BGP EVPN, installano l’informazione sull’indirizzo MAC nella tabella MAC-VRF associata alla EVI e l’indirizzo IP nella VRF IP, come Host route. Il Next-Hop è l’indirizzo IP del PE remoto che invia l’annuncio (NOTA: i Next-Hop potrebbero essere più di uno nel caso di CE multi-homed). Quali altre informazioni vengono installate nella VRF IP, dipende dal tipo di forwarding (asimmetrico o simmetrico).
Solo a titolo di esempio, queste sono le informazioni memorizzate nella VRF IP sul PE locale (PE21), che apprende l’Host route 10.1.1.2, in un router Juniper:
 
tt@PE21> show route 10.1.1.2
IPVPN-1.inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.1.2/32   *[EVPN/7] 00:03:35
                     > via irb.10
 
Queste sono invece le informazioni relative alla stessa Host route, memorizzate nella VRF IP di un PE remoto (PE11):
 
tt@PE11> show route 10.1.1.2
IPVPN-1.inet.0: 24 destinations, 24 routes (24 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.1.2/32   *[EVPN/7] 00:4:16
                     > to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-21
                        to 10.11.1.1 via xe-1/2/0.0, label-switched-path from-11-to-22
 
In alcune implementazioni (es. Juniper), per annunciare l’Host route i PE inviano anche i classici annunci MP-BGP L3VPN (NOTA: questo avviene perché nel JUNOS l’esportazione dei prefissi dalle VRF è automatica, a differenza dell’IOS Cisco, dove l’esportazione avviene solo a fronte di comandi di redistribuzione, a meno che il protocollo di routing PE-CE non sia eBGP). Ricordo che questi sono annunci dell’address-family VPN-IPv4/v6 (AFI/SAFI = 1/128 nel caso di VPN-IPv4, AFI/SAFI = 2/128 nel caso di VPN-IPv6). A questo annunci viene associato un classico Route-Target (RT), che consente ai PE remoti di importarlo nelle VRF del tenant. In questa implementazione, alle VRF IP dei PE remoti arrivano due annunci, entrambi BGP, della stessa Host route. Il primo annuncio via MP-BGP L3VPN classico, il secondo annuncio via BGP EVPN. Quale dei due viene utilizzato ? Attenzione che il processo di selezione BGP in questo caso non vale, ossia non è il processo BGP che sceglie il best-path tra i due annunci (i quali è vero che sono entrambi BGP, ma di due address-family diverse).
Ora, non resta da vedere che tipo di informazioni sono memorizzate nelle VRF IP remote e come queste informazioni vengono utilizzate per il forwarding asimmetrico e simmetrico. In ultima analisi, la differenza tra il forwarding simmetrico e asimmetrico dipende proprio dalle informazioni utilizzate.
 
INTER-VLAN ROUTING: FORWARDING DI TIPO ASIMMETRICO
La chiave del funzionamento del forwarding di tipo asimmetrico, sono le informazioni memorizzate nelle VRF IP dei PE remoti, alla ricezione di un annuncio BGP EVPN di tipo 2 (MAC/IP Advertisement). Oltre alle informazioni classiche, il PE che riceve un annuncio BGP EVPN, installa nella VRF IP anche il MAC dell’Host remoto e la EVPN label MPLS associata (ossia, l’etichetta contenuta nel campo “MPLS Label1”). Queste informazioni aggiuntive, consentono sul piano dati di eliminare sul PE di uscita il lookup a Livello 3.
Vediamo in dettaglio il funzionamento del piano dati. Supponiamo che un Host H1 della VLAN 10, attestato attraverso un CE1 al router PE1, voglia inviare un pacchetto IP a un Host H2 della VLAN 20, attestato a PE2 attraverso un CE2 (NOTA: gli Host non sono necessariamente Host fisici, ma potrebbero essere macchine virtuali create su un server; così come i CE non sono necessariamente macchine fisiche, ma potrebbero essere ad esempio, degli switch virtuali definiti in un Hypervisor di un server (tipici esempi, Cisco Nexus 1000v, Open vSwitch, VMware NSX, ecc.)). Su PE1 viene configurata una interfaccia IRB, supponiamo IRB.10, associata alla VLAN 10, il cui indirizzo IP svolge la funzione di default gateway. Questa interfaccia, sempre via configurazione, viene associata alla VRF IP.
L’Host H1 invia il pacchetto IP incapsulato, come da copione classico, in una trama Ethernet con MAC sorgente il proprio MAC (= MAC-1) e MAC destinazione l’indirizzo MAC del default gateway (= MAC-DG), che altro non è che l’indirizzo MAC associato all’interfaccia IRB.10. Come H1 abbia appreso l’indirizzo MAC-DG è anche questo un classico, utilizza il protocollo ARP, con PE1 che eventualmente svolge la funzione di Proxy ARP.
La trama Ethernet viene intercettata dal PE, che esegue un primo lookup sulla tabella MAC-VRF associata alla EVI. Poiché l’interfaccia di uscita risulta essere l’interfaccia (virtuale) IRB.10, viene effettuato un secondo lookup sulla VRF IP. Le informazioni per l’inoltro, contenute nella VRF IP in corrispondenza dell’indirizzo IP destinazione (IP-2), sono il Next-Hop (= PE2), il MAC dell’Host H2 (= MAC-2) e la EVPN label associata a MAC-2 (= L2).
A questo punto, PE1 incapsula il pacchetto IP originale in una trama Ethernet con MAC sorgente MAC-1, MAC destinazione MAC-2 e incapsula la trama con due etichette MPLS (un classico anche questo): la più interna è la EVPN label, la più esterna è la PSN label del LSP MPLS che congiunge PE1 a PE2. Il pacchetto MPLS così formato arriva a PE2 con la sola EVPN label (a causa del Penultimate Hop Popping MPLS), e la EVPN label viene utilizzata da PE2, come da funzionamento del modello EVPN, per effettuare un lookup sulla tabella MAC-VRF associata alla VLAN 20. Quest’ultimo lookup consente di individuare l’interfaccia uscente. Così, tolta la EVPN label, la trama Ethernet risultante viene inviata direttamente a CE2 e quindi ad H2 e il gioco è fatto. Il tutto è riassunto nella figura seguente.
 
 
 
Si noti che in funzione di come viene scelta la EVPN label, l’ultimo lookup potrebbe addirittura essere evitato. Ad esempio, se PE2 scegliesse una EVPN label unica per tutti i MAC raggiungibili da CE2, a valle dell’operazione di Label Pop, la trama Ethernet potrebbe essere direttamente inviata a CE2 senza eseguire alcun lookup sulla tabella MAC-VRF di PE2.
Vorrei farvi notare che l’aspetto chiave del forwarding asimmetrico è che le informazioni per il forwarding contenute nella VRF IP su PE1, sono esattamente quelle dell’annuncio BGP EVPN inviato da PE2 a PE1 (solo la L3VPN label non viene utilizzata).
Nelle implementazioni come quella Juniper, che annunciano le Host route anche attraverso annunci classici L3VPN, le informazioni di questo secondo annuncio non vengono utilizzate, per cui questo annuncio, per risparmiare un po’ di memoria, può essere anche filtrato (ossia, scartato attraverso un filtro sul PE1 !). Attenzione però a come scrivere il filtro, perché bisogna fare in modo che altri annunci L3VPN possano essere accettati (ad esempio un eventuale annuncio di una default-route per raggiungere un Internet Gateway). Dovrei lasciarvelo come esercizio, ma visto che sto scrivendo questo post durante le vacanze natalizie, mi sento più buono del solito. Il trucco è semplice, basta aggiungere agli annunci L3VPN classici che volete filtrare, un secondo RT fittizio, e quindi configurare dei filtri che scartino gli annunci che contengono questo RT fittizio. Gli annunci L3VPN che non devono essere scartati conterranno il solo RT della L3VPN, e quindi non verranno scartati.  
 
INTER-VLAN ROUTING: FORWARDING DI TIPO SIMMETRICO
Anche qui, la chiave del funzionamento del forwarding di tipo simmetrico, sono le informazioni memorizzate nelle VRF IP dei PE remoti, alla ricezione di un annuncio BGP EVPN di tipo 2 (MAC/IP Advertisement). Nel forwarding di tipo simmetrico, il PE che riceve un annuncio BGP EVPN, installa nella VRF IP le informazioni classiche di tipo L3VPN: la L3VPN label MPLS associata (ossia, l’etichetta contenuta nel campo “MPLS Label2”) e il BGP Next-Hop. 
Vediamo in dettaglio il funzionamento del piano dati. Riprendiamo per semplicità lo stesso esempio visto nella sezione precedente sul forwarding asimmetrico. La prima parte del piano dati è identica a quella vista per il forwarding asimmetrico, ossia, l’Host H1 invia il pacchetto IP incapsulato, come da copione classico, in una trama Ethernet con MAC sorgente il proprio MAC (= MAC-1) e MAC destinazione l’indirizzo MAC del default gateway (= MAC-DG). 
La trama Ethernet viene intercettata dal PE, che esegue un primo lookup sulla tabella MAC-VRF associata alla EVI. Poiché l’interfaccia di uscita risulta essere l’interfaccia (virtuale) IRB.10, viene effettuato un secondo lookup sulla VRF IP. Le informazioni per l’inoltro, contenute nella VRF IP in corrispondenza dell’indirizzo IP destinazione (IP-2), sono il BGP Next-Hop (= PE2), e la L3VPN label associata a MAC-2 (= L3).
A questo punto, PE1 incapsula il pacchetto IP originale in un pacchetto con due etichette MPLS (e non in una trama Ethernet come nel caso del forwarding asimmetrico !): la più interna è la L3VPN label, la più esterna è la PSN label del LSP MPLS che congiunge PE1 a PE2. Il pacchetto MPLS così formato arriva a PE2 con la sola L3VPN label (a causa del Penultimate Hop Popping MPLS), e la L3VPN label viene utilizzata da PE2, come da funzionamento classico del modello L3VPN, per effettuare un lookup sulla VRF IP associata. Ora, il risultato del lookup è l’interfaccia IRB.20 associata alla VLAN 20. Questo significa che per portare a destinazione il pacchetto IP è necessario un secondo lookup sulla tabella MAC-VRF associata alla VLAN 20. Quest’ultimo lookup consente di individuare l’interfaccia uscente. Il pacchetto IP verrà quindi incapsulato in una trama Ethernet con MAC sorgente pari all’indirizzo MAC del default gateway della VLAN 20 e MAC destinazione MAC-2 (ossia, l’indirizzo MAC di H2). La trama Ethernet risultante viene inviata direttamente a CE2 e quindi ad H2 e il gioco è fatto. Il tutto è riassunto nella figura seguente.
 
 
 
INTER-VLAN ROUTING DI TIPO ASIMMETRICO E SIMMETRICO: CONFRONTO
L’inter-vlan routing di tipo simmetrico e asimmetrico è oggi applicato quasi esclusivamente congiuntamente alle VXLAN. Come ho già citato più volte, una delle maggiori applicazioni del modello EVPN è di fare da piano di controllo per le VXLAN, per le quali, nativamente non è stato specificato alcun piano di controllo (vedi RFC 7348), o meglio, il lavoro del piano di controllo è svolto dal piano dati (il classico MAC learning) !
Per cui rimando il confronto tra le due modalità di forwarding in un prossimo post in cui tratterò diffusamente l’integrazione VXLAN/EVPN. Però sono sicuro che il lettore astuto e attento, dalla lettura delle due sezioni precedenti, una idea dei vantaggi/svantaggi delle due modalità sicuramente se la sarà fatta.
 
EVPN: UN PIANO DI CONTROLLO PER TUTTE LE STAGIONI ...
Per chiudere questa trilogia sul modello EVPN, vorrei mettere in evidenza una delle sue proprietà più importanti. Il modello EVPN può essere applicato in modo nativo, come evoluzione del servizio VPLS, che consente di emulare un servizio di LAN Ethernet su scala geografica.
Ma può essere integrato anche con altri standard. L’idea di fondo è sempre la stessa: la netta separazione tra piano di controllo e piano dati. Il piano di controllo EVPN è quello che abbiamo ampiamente spiegato, basato sul BGP e in particolare sugli annunci di tipo EVPN (AFI/SAFI = 25/70) e su alcune nuove Extended Community. Il piano dati che ho utilizzato finora è basato su MPLS. Ma in realtà potrebbe essere completamente diverso e basato su altri standard.
Attualmente ci sono due standard e una proposta allo stato draft, che hanno in comune il piano di controllo EVPN:

1. RFC 7432: piano dati MPLS.
2. RFC 7623: piano dati MAC-in-MAC, anche noto come PBB (Provider Backbone Bridge), definito dallo standard IEEE 802.1ah.
3. draft-ietf-bess-evpn-overlay: piano dati generico utilizzato nelle Overlay Virtual Network. In particolare il documento tratta l’integrazione di EVPN con i due standard più utilizzati, VXLAN e NVGRE (si noti che tra i due, è il primo che sta godendo del maggior supporto da parte di tutti i costruttori e produttori di software di virtualizzazione).

 
 
Da un punto di vista puramente pratico, personalmente non sono a conoscenza di importanti applicazioni pratiche dell’integrazione di EVPN con il PBB. Questa integrazione è molto spinta da Cisco, ma realizzazioni importanti sul campo ancora non si vedono (se qualcuno ha informazioni contrarie, avrei piacere che me le segnalasse al mio indirizzo e-mail Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.).
L’applicazione più interessante del modello EVPN è senza dubbio l’integrazione con il piano dati VXLAN. Oggi tutti i maggiori costruttori di apparati supportano l’integrazione EVPN/VXLAN (Cisco, Juniper, Alcatel, ecc.). Per questo, anche perché lo considero di importanza rilevante in ambito Data Center, tratterò questo aspetto diffusamente nei prossimi post.
 
CONCLUSIONI
Con questo post ho concluso una trilogia sugli aspetti fondamentali del nuovo modello EVPN. Ora su EVPN sapete tutto quello che c’è da sapere. Se avete nelle vostre reti implementato un servizio VPLS, il mio consiglio è di migrarlo, se possibile, verso il modello EVPN. Ma come ho detto poco sopra, l’applicazione più interessante del modello EVPN è senza dubbio l’integrazione con il piano dati VXLAN (e questo è alternativo all’utilizzo di un piano dati basato su MPLS, VXLAN viaggia su reti IP senza bisogno di MPLS).
Il modello EVPN mi intriga perché lo ritengo molto ben fatto, ma mi rimane un dubbio che mi porto appresso e mi angoscia da 20 anni (ossia, da quando ho iniziato a occuparmi delle reti IP): ma non sarebbe più semplice, oggi che IP è diventato un protocollo multiservizio, avere reti puramente IP, senza indirizzi MAC ? Perché un Host deve avere due indirizzi, uno MAC e uno IP ? Non sarebbe stato sufficiente un solo indirizzo (magari IPv6, così non avremmo nemmeno avuto la rogna del NAT) ? Pensateci un attimo, no ARP, no Spanning Tree, no Broadcast Storm, ecc. ecc. (e a dirla tutta, no VPLS e no EVPN !). La nostra vita sarebbe stata un po’ più semplice, per contro Cisco, Juniper e compagnia allegra avrebbero venduto molti meno apparati !!! E allora mi cresce ancor di più il dubbio: non è che siano stati i costruttori a darci delle idee tali che loro potessero venderci più roba ? (d’altra parte, in ultima analisi fanno il loro mestiere, fare più soldi possibile). Però attenzione, molti illuminati networkers si stanno ponendo lo stesso dilemma e qualche nuova startup, più creativa dei vendor tradizionali e senza gli stessi pregiudizi, sta proponendo architetture di Data Center L3-only (sentito mai parlare di Cumulus Network, di Juniper Contrail ?). C’è spazio per ampie discussioni future, nel frattempo vi consiglio di leggervi questo illuminante e stupendo post di Mark Burgess, dove troverete, parafrasando Dan Brown nel suo libro “Angeli e Demoni”, il “cammino dell’illuminazione”.
Arrivederci al prossimo post: l’evoluzione del piano di controllo delle VXLAN (con qualche piccolo lab, se riesco).