EVPN: l'evoluzione del servizio VPLS – Parte II

Nel post precedente sul modello EVPN ho illustrato i concetti e le idee fondamentali, focalizzando l’attenzione soprattutto alle problematiche legate alla gestione dei collegamenti multi-homed e alle loro (eleganti) soluzioni. Ho tralasciato molti dettagli di funzionamento, che in questo post cercherò almeno in parte di colmare.

In particolare, illustrerò quali sono i nuovi BGP NLRI dell’address-family EVPN (AFI/SAFI = 25/70), e le nuove BGP Extended Community introdotte. Poi farò vedere come viene eletto il Designated Forwarder e come viene trasportato il traffico, sia BUM che unicast. Infine illustrerò i principi generali del MAC mobility, ossia la possibilità che un indirizzo MAC si muova da un segmento Ethernet a un altro. Vi preannuncio che comunque le cose da dire sono ancora molte, per cui aspettatevi altri post sull’argomento.

DETERMINAZIONE DELL’ESI
Nel post precedente ho illustrato il ruolo fondamentale giocato dall’ESI nei collegamenti multi-homed. Ricordo che l’ESI è un identificativo dell’ES (Ethernet Segment), e come tale deve essere univoco all’interno della rete (non dell’istanza EVPN (EVI) !).
La RFC 7432 ha specificato per l’ESI una lunghezza di 10 byte, con un formato molto semplice riportato nella figura seguente (tratta direttamente dalla RFC 7432).

Il campo T identifica come può essere determinato dell’ESI. La RFC 7432 prevede una determinazione manuale, via configurazione, o una determinazione automatica. Per valori di ESI configurati manualmente, T = 0x00. Per valori di ESI determinati automaticamente, la RFC 7432 ha identificato ben 5 modalità diverse, identificate da T = 0x01, ..., T = 0x05. Non starò qui a illustrare tutte le 5 possibilità, farò solo vedere la prima, lasciando al lettore di “esplorare” le altre nella RFC 7432. Ma, faccio notare, non è un argomento di vitale importanza. Tanto, un ESI vale l’altro, purché sia verificata l’univocità su tutta la rete.

Quando T = 0x01, è previsto che i CE utilizzino nei loro collegamenti verso i PE, lo standard IEEE 802.1AX (LAG con LACP). Questo tipo di ESI indica un valore auto-generato, in cui i restanti 9 byte dell’ESI sono determinati dai parametri del protocollo LACP e così suddivisi (partendo dai byte più significativi):

• CE LACP System MAC address (6 byte).
• CE LACP Port Key (2 byte).
• Ultimo byte = 0x00.

Per quanto riguarda il CE, questo tratta i PE a cui è collegato come se fossero un unico switch. Questo consente ai CE di aggregare link che sono connessi a PE diversi senza ricorrere a MLAG.  Si noti che i due seguenti valori di ESI sono riservati:

• ESI = 0 : valore riservato ai collegamenti single-homed.
• ESI = 0xFF (ripetuto 10 volte) : valore definito nella RFC 7432 come MAX-ESI.

SERVIZI EVPN E ETHERNET TAG 

Nel post precedente ho introdotto, ma solo come terminologia, il concetto di Ethernet tag. Ricordo che l’Ethernet tag è un identificativo di un dominio broadcast (es. una VLAN). Una EVI consiste di uno o più domini broadcast. I valori di Ethernet tag assegnati ai domini broadcast di una data EVI, sono determinati dal tipo di servizio e assegnati dal Service Provider. L’Ethernet tag ha lunghezza di 32 bit, dei quali vengono utilizzati 12 o 24. Nel caso in cui l’identificativo sia di 12 bit, l’Ethernet tag viene anche chiamato VLAN ID (VID) e coincide con i classici valori di VLAN ID. I valori di Ethernet tag sono utilizzati solo negli annunci BGP EVPN.

Una EVI è costituita da uno o più domini di broadcast (VLAN). Una data VLAN può a sua volta essere rappresentata da più VID (su diversi PE). In tali casi, i PE che partecipano a quella VLAN per una determinata EVI, sono responsabili della traduzione dei VID da/verso i CE collegati localmente. Se una VLAN è rappresentata da un singolo VID su tutti i PE che partecipano a quella VLAN, per quella determinata EVI, allora viene meno la necessità della traduzione dei VID da parte dei PE. 

Un problema interessante a questo punto è il seguente: quale è la relazione tra i domini di broadcast (identificati ad esempio da VID), l’Ethernet tag e le MAC-VRF di ciascuna EVI ? In altre parole, quando un PE riceve un annuncio BGP EVPN contenente un dato valore di Ethernet tag, a fronte di questo annuncio il PE deve stabilire una relazione tra il valore dei VID lato CE e le EVI. Il tipo di relazione dipende dal tipo di servizio EVPN. Bene, il modello EVPN ha tre tipi di servizi a questo riguardo, che specificano quale sia questa relazione (riporto i nomi così come appaiono nella RFC 7432) e di cui voglio dare una breve descrizione:

• VLAN-based Service Interface: in questo servizio, vi è una coincidenza 1:1 tra EVI e domini broadcast (VLAN). Le MAC-VRF di ciascuna EVI hanno quindi una singola tabella di bridging corrispondente a quella determinata VLAN. Se la VLAN è rappresentata da più VID (ad esempio, un VID diverso per ogni segmento Ethernet per PE), ogni PE ha bisogno di eseguire la traduzione tra i VID (VLAN rewrite) utilizzati per le trame destinate ai suoi Ethernet Segment. Il valore di Ethernet tag presente nei vari annunci BGP EVPN, per questo servizio, viene impostato a 0.
• VLAN Bundle Service Interface: in questo servizio, a ogni EVI sono associati più domini broadcast. Le MAC-VRF di ciascuna EVI hanno comunque una unica tabella di bridging corrispondente a tutte le VLAN che identificano i domini di broadcast. Ciò implica che gli indirizzi MAC devono essere univoci in tutte le VLAN per quella EVI. In questo servizio ogni VLAN è rappresentata da un VID univoco, ciò significa che la traduzione di VID non è ammessa. Anche per questo servizio, il valore di Ethernet tag presente nei vari annunci BGP EVPN viene impostato a 0. Un caso particolare di questo servizio è il Port-based Service Interface, dove tutte le VLAN definite su una particolare porta, sono parte della medesima EVI.
• VLAN-aware Bundle Service Interface: come il servizio precedente, a ogni EVI sono associati più domini broadcast. La differenza è però che le MAC-VRF di ciascuna EVI hanno più tabelle di bridging, una per ciascuna VLAN (ed è quindi possibile la sovrapposizione di indirizzi MAC tra le VLAN). Il traffico BUM viene inviato in questo caso ai soli CE di un determinato dominio broadcast. I VID per ciascuna VLAN possono essere identici su tutti i PE o possono essere diversi. In quest’ultimo caso è necessario implementare sui PE una funzione di VLAN rewrite. Per questo servizio, il valore di Ethernet tag presente nei vari annunci BGP EVPN viene impostato dal Service Provider. Come nel servizio precedente, un caso particolare di questo servizio è il Port-Based VLAN-aware Service Interface, dove tutte le VLAN definite su una particolare porta sono parte della medesima EVI, ma ciascuna VLAN ha la sua unica tabella di bridging.

La figura sotto, tratta da una presentazione di Alcatel-Lucent, riassume le caratteristiche dei tre servizi.

LA NUOVA ADDRESS-FAMILY BGP EVPN (AFI/SAFI = 25/70)

Come più volte detto, uno degli aspetti più innovativi del modello EVPN, è che il MAC learning remoto avviene sul piano di controllo, utilizzando annunci BGP. Per questo è stata definita una nuova address-family BGP, caratterizzata dai codici AFI/SAFI = 25/70.

Il formato generale della nuova EVPN NLRI è del classico tipo TLV (Type-Length-Value) ed è riportato nella figura seguente, dove il campo Route Type rappresenta il tipo di codifica presente nel campo Route Type Specific, il campo Length la lunghezza in byte del campo successivo, e infine il campo Route Type Specific la codifica vera e propria del NLRI.

La RFC 7432 ha definito 4 tipi diversi di NLRI, riportati nella tabella seguente. Del secondo tipo abbiamo dato ampiamente conto nel post precedente. Degli altri, finora non abbiamo mai parlato del terzo. Sarà trattato nella sezione sotto, sul trasporto del traffico BUM. Piuttosto che dare per ciascun tipo il formato e il significato dei vari campi, preferisco riassumere in una tabella i campi più importanti e soprattutto l’utilizzo (in parte già visto nel post precedente). I lettori più curiosi possono far riferimento alla RFC 7432 per il formato completo.

In tutti i tipi di NLRI è inoltre presente un valore di Route Distinguisher (RD), il cui formato e significato è identico a quello delle L3VPN, ossia è un valore che serve a distinguere eventuali NLRI identiche, ma generate da Clienti diversi. Si noti che la RFC 7432 impone per il RD il formato “IP-PE : valore”, dove “IP-PE” è un indirizzo IP del PE (tipicamente una interfaccia di Loopback) e “valore” è un numero arbitrario assegnato dall’amministratore del servizio.

LE NUOVE EXTENDED COMMUNITY

Il modello EVPN utilizza delle nuove BGP Extended Community, alcune delle quali già citate nel post precedente. Anche qui, piuttosto che dare per ciascuna nuova Extended Community il formato e il significato dei vari campi, preferisco riassumere in una tabella l’utilizzo (in parte già visto nel post precedente) e a quali EVPN NLRI vanno associate. 

Su alcune di cui finora non abbiamo ancora visto l’utilizzo (ad esempio MAC mobility e Default Gateway), torneremo a tempo debito. Per ora è sufficiente sapere che esistono.

Oltre a queste nuove Extended Community, vi è poi il classico Route Target, utilizzato allo stesso modo e con le stesse identiche regole del servizio L3VPN e dell’auto-discovery via BGP nel servizio VPLS.

DETERMINAZIONE DEL DESIGNATED FORWARDER

Nel post precedente sul modello EVPN è stato evidenziato il ruolo chiave, nei collegamenti multi-homed, giocato dai Designated Forwarder (DF), che ricordiamo, sono quei PE multi-homed responsabili di inviare ai CE il traffico BUM. L’elezione di un DF è essenziale per risolvere problemi come ad esempio la duplicazione delle trame BUM e del ritorno del traffico BUM nei CE che lo hanno generato (Split Horizon).

L’elezione del DF avviene a valle della scoperta dei PE che sono multi-homed allo stesso ES. Per distribuire la funzione di DF tra i PE di un ES, la RFC 7432 definisce una procedura di default denominata service carving, che consente di eleggere un DF per ciascuna coppia <ES, VLAN> nel caso dei servizi VLAN-based, e per ciascuna coppia <ES, VLAN bundle> per i servizi VLAN bundle e VLAN-aware bundle. Con il metodo del service carving è quindi possibile l’elezione di più DF per ES, consentendo così di eseguire un Load Balancing per il traffico BUM destinato ai CE di un ES.

La procedura di service carving è basata sui seguenti passi:

• Quando un PE multi-homed scopre (via configurazione manuale o attraverso un qualche meccanismo di autosensing tipo quello descritto sopra nella sezione “Determinazione dell’ESI”, basato sui parametri del protocollo LACP) il valore di ESI dell’ES a cui è (fisicamente) connesso, invia un annuncio BGP EVPN con NLRI di tipo Ethernet Segment (tipo 4), con associata una ES-import Extended Community. Il valore di ES-import è costituito da 6 dei 9 byte utili dell’ESI.
• Il PE fa quindi partire un timer, la cui durata è di 3 sec (default), per consentire la ricezione degli annunci BGP EVPN con NLRI di tipo Ethernet Segment da parte degli altri PE multi-homed allo stesso ES. Questo timer è identico per tutti i altri PE multi-homed allo stesso ES.
• Allo scadere del timer, ciascun PE crea una lista ordinata in senso crescente, degli indirizzi IP contenuti negli annunci di tipo Ethernet Segment (incluso il proprio) nel campo Originating Router’s IP address (tipicamente una interfaccia di Loopback).

A ciascun PE viene quindi associato un numero intero sequenziale a partire dal valore 0, dove il valore nullo corrisponde al all’indirizzo IP numericamente più basso. Questi valori servono a determinare quale PE è il DF per ciascuna coppia <ES, VLAN> o <ES, VLAN bundle>, con il seguente algoritmo (N è il numero di PE multi-homed):

• Nel caso di servizi VLAN-based il DF è il PE che ha il numero definito dall’operazione “V mod N”, dove V è il VID (NOTA: ricordo a chi non è avvezzo alle notazioni matematiche, che l’operazione “V mod N” corrisponde al banale resto della divisione tra V ed N; ad esempio “11 mod 3” = 2, “14 mod 2” = 0, ecc.).
• Nel caso invece di servizi VLAN bundle e VLAN-aware bundle, dove a ciascuna EVI corrispondono più VID, l’operazione da eseguire è identica, prendendo come valore di V il minimo VID.

La procedura sembra a prima vista un po’ contorta, ma è in realtà molto semplice. Per smitizzarne la complessità la illustrerò con un esempio. Supponiamo un CE multi-homed a due PE, PE1 e PE2, che hanno rispettivamente Originating Router’s IP address 1.1.1.1 e 2.2.2.2. Ciascun collegamento fisico sia ripartito in due collegamenti logici, uno porta la VLAN 100 e l’altro le tre VLAN 101,102 e 103. I due collegamenti logici sono associati sui due PE a due diverse EVI, EVI-1 e EVI-2. Si noti che l’ES è unico e identificato da un comune ESI. Il tutto è riassunto nella figura seguente.

Il servizio della EVI-1 è di tipo VLAN-based mentre il servizio della EVI-2 è di tipo VLAN bundle (o VLAN-aware bundle, fa lo stesso). Il primo passo da eseguire, a valle della scoperta da parte di un PE di quali sono gli altri PE multi-homed, è l’associazione del numero intero sequenziale. Poiché l’indirizzo 1.1.1.1 è (numericamente) più basso dell’indirizzo 2.2.2.2, il PE1 ha associato il valore 0 e il PE2 il valore 1. Per determinare il DF per la EVI-1, ossia per la coppia <ES, VID = 100>, si esegue l’operazione “100 mod 2”, che da come risultato 0 (ossia, il resto della divisione tra 100 e 2). Ne consegue che il PE1 è il DF per l’EVI-1, poiché ha associato il numero intero sequenziale 0. Per determinare il DF per l’EVI-2 si esegue la stessa operazione, prendendo come valore di riferimento per il VID il minimo tra tutti VID associati all’EVI-2, ossia 101 = min [101, 102, 103]. L’operazione “V mod N” = “101 mod 2” da come risultato 1, e quindi il DF per l’EVI-2 è il PE2. “Elementare Watson”, avrebbe detto Sherlock Holmes !

ETHERNET A-D PER ES E ETHERNET A-D PER EVI

Una volta che ciascun PE ha scoperto gli altri PE multi-homed allo stesso ES, attraverso gli annunci BGP EVPN di tipo Ethernet Segment (tipo 4) e il filtraggio attraverso l’ES-import, ed eletti i DF per ciascun ES, la fase successiva nella sequenza di startup del modello EVPN, è l’annuncio degli ES. Questa fase è fondamentale per risolvere i problemi del possibile ritorno delle trame BUM sul CE che le ha generate, della convergenza veloce e dell’aliasing.

L’annuncio degli ES avviene attraverso NLRI di tipo Ethernet A-D (tipo 1). Il modello EVPN utilizza due tipi di Ethernet A-D: Ethernet A-D per ES e Ethernet A-D per EVI.

L’Ethernet A-D per ES viene sempre annunciato da ciascun PE di un ES multi-homed e contiene come informazioni:

• Il valore dell’ESI.
• La ESI-label Extended Community utilizzata nel meccanismo dello Split Horizon, che, ricordo dal precedente post, consente di evitare il possibile ritorno delle trame BUM sul CE che le ha generate. Questa Extended Community contiene anche la flag che definisce la modalità di funzionamento dell’ES: flag = 0 se la modalità è active-active, flag = 1 se la modalità è single-active.
• Uno o più Route Target, uno per ciascuna EVI alle quali appartiene l’ES.

La figura seguente riporta un esempio di annuncio di Ethernet A-D per ES.

Gli annunci di tipo Ethernet A-D per ES vengono utilizzati per implementare il meccanismo dello Split Horizon e per la convergenza veloce. Per l’aliasing e il Backup Path, vengono utilizzati annunci sempre di tipo Ethernet A-D (quindi sempre di tipo 1), ma con una struttura diversa. Questi annunci, detti Ethernet A-D per EVI sono opzionali ma, almeno nelle implementazioni che ho visto finora, vengono comunque sempre inviati. In realtà, nel caso di ESI = 0 (ossia, collegamenti single-homed), non sono necessari.

L’Ethernet A-D per EVI contiene come informazioni:

• Il valore dell’ESI.
• Una etichetta MPLS utilizzata per l’aliasing (aliasing label). L’utilizzo di questa etichetta è stato specificato nel post precedente.
• Il Route Target dell’EVI.

La figura seguente riporta un esempio di annuncio di Ethernet A-D per EVI.

Quando un router PE “impara” da un CE multi-homed un indirizzo MAC, questo come più volte detto nel post precedente, invia un annuncio BGP EVPN del tipo MAC/IP Advertisement (tipo 2), che include l’indirizzo MAC, l’indirizzo IP associato (se noto), una etichetta MPLS e il valore di ESI che identifica l’ES da dove l’indirizzo MAC è stato appreso. Un PE remoto correla questo valore di ESI con quello presente nei due annunci Ethernet A-D (per ES e per EVI) e può così determinare l’insieme dei PE multi-homed, ai quali può trasmettere le trame Ethernet (incapsulate in qualche modo) dirette all’indirizzo MAC. Quando il PE remoto invia le trame Ethernet, utilizzando come Next-Hop il PE che inviato l’annuncio di tipo MAC/IP Advertisement, incapsula le trame in un pacchetto MPLS utilizzando come etichetta interna (service label) l’etichetta associata all’annuncio MAC/IP Advertisement. Quando invece il PE remoto invia le trame Ethernet utilizzando come Next-Hop un PE che inviato gli annunci di tipo Ethernet A-D con il medesimo valore di ESI dell’annuncio MAC/IP Advertisement, utilizza l’aliasing label (a meno che il PE remoto non abbia ricevuto anche lui un MAC/IP Advertisement che annuncia lo stesso indirizzo MAC, nel qual caso utilizza anche lui la service label contenuta nell’annuncio).

TRASPORTO DEL TRAFFICO BUM

Nelle reti di Livello 2 il traffico BUM viene inoltrato attraverso un classico meccanismo di flooding, senza distinzione alcuna tra traffico multi-destinazione (multicast e broadcast) e traffico unicast ma diretto verso un indirizzo MAC sconosciuto.

Il modello EVPN introduce per la prima volta una distinzione tra traffico multi-destinazione (le lettere B e M dell’acronimo BUM) e il traffico diretto verso un indirizzo MAC sconosciuto (la lettera U dell’acronimo BUM). Infatti, mentre il traffico multi-destinazione segue il classico meccanismo del flooding, il traffico diretto verso un indirizzo MAC sconosciuto può seguire o no il classico meccanismo del flooding. La RFC 7432 a questo proposito è molto chiara. Nella sezione 12 “Processing of Unknown Unicast Packets”, così recita:

The procedures in this document do not require the PEs to flood unknown unicast traffic to other PEs. If PEs learn CE MAC addresses via a control-plane protocol, the PEs can then distribute MAC addresses via BGP, and all unicast MAC addresses will be learned prior to traffic to those destinations. However, if a destination MAC address of a received packet is not known by the PE, the PE may have to flood the packet. 

Traduciamo, per essere più chiari. La prima parte dice che la RFC 7432 non richiede tassativamente di utilizzare il meccanismo del flooding per le trame con MAC destinazione ignoto (NOTA: questo concetto non è nuovo nelle reti L2, è stato introdotto da Cisco nel suo protocollo proprietario OTV, Overlay Transport Virtualization, per l’interconnessione di Data Center). Poi dice che se i PE fossero in grado di “imparare” dai CE gli indirizzi MAC attraverso un meccanismo del piano di controllo (es. ARP/DHCP snooping, o qualche diavoleria tipo protocollo di routing, che annunci gli indirizzi MAC raggiungibili dai CE), i PE possono distribuire la conoscenza degli indirizzi MAC (unicast) via BGP, prima che il traffico fluisca verso questi indirizzi MAC, ossia prima ancora che i MAC vengano appresi sul piano dati. Fermi tutti, ma questo non è lo stesso identico ragionamento che avviene a Livello 3, dove un PE “impara” dal piano di controllo via routing PE-CE (statico o dinamico) i prefissi raggiungibili dai CE, e quindi li annuncia agli altri PE via BGP ? Ebbene si, è esattamente lo stesso identico ragionamento. Allora vuol dire che tutti gli “esegeti” (NOTA: chiedo perdono per la forzatura nell'utilizzo di questa parola, che letteralmente significa "commentatore, interprete, critico di testi letterari, giuridici o sacri") delle reti Switched Ethernet, ossia tutti quelli che per anni ci hanno riempito la testa che le flat networks (basate sul flooding e non sui protocolli di routing) erano la soluzione di tutti i problemi del networking, sono stati folgorati sulla via di Damasco e ci hanno ripensato ? Lascio a voi la conclusione.

La seconda parte dice che comunque in assenza di MAC learning PE-CE sul piano di controllo, i PE possono (= may) utilizzare il flooding. Si noti comunque che quanto detto riguarda solo il trasporto PE-PE. Il flooding a livello locale, ossia sulle interfacce lato CE, può comunque avvenire (e di solito avviene, lato CE il PE si comporta infatti come un classico L2 switch).

Bene, ciò premesso, come viene veicolato il traffico BUM nel modello EVPN ? A ben vedere, questo traffico origina da un particolare PE ed è diretto a tutti i PE della stessa EVI. Suona familiare ? Ebbene si, è lo stesso problema che si deve affrontare nel servizio L3VPN multicast o nell’inoltro del traffico BUM nelle VPLS. Per cui possono essere riciclate le stesse tecniche. I PE di una stessa EVI possono utilizzare come P-tunnel, LSP MPLS di tipo P2MP o MP2MP (trattati ampiamente in post precedenti) oppure Ingress Replication. 

La segnalazione di quale tipo di meccanismo utilizzare avviene attraverso annunci BGP EVPN del tipo Inclusive Multicast Ethernet Tag Route (tipo 3), i quali, oltre ai campi del NLRI (molto semplici, vedi la tabella sopra) contengono (obbligatoriamente) il nuovo attributo BGP PMSI Tunnel, esattamente identico a quello utilizzato nel modello NG-MVPN (vedi post precedente sull’argomento). Tra l’altro, lo stesso attributo è stato introdotto anche per il servizio VPLS che utilizza il BGP come protocollo di auto-discovery (vedi la recente RFC 7117 - Multicast in Virtual Private LAN Service (VPLS)), Febbraio 2014, per ottimizzare il flooding delle trame BUM.

Si noti che anche per il modello EVPN, per evitare loop interni del traffico, vale la regola dello Split Horizon utilizzata nel servizio VPLS, ossia che il traffico BUM ricevuto da un PE, non viene mai inoltrato agli altri PE della stessa EVI (NOTA: questa regola non ha niente a che vedere con la regola dello Split Horizon vista nel post precedente, tanto che la RFC 7432, per evitare confusione la indica come Split Horizon Forwarding).

Nel caso di P-tunnel di tipo Ingress Replication, ad oggi il metodo ancora preferito nelle implementazioni “primitive” del modello EVPN grazie alla sua semplicità, vengono utilizzati normali LSP MPLS di tipo P2P tra il PE di origine e tutti gli altri PE della stessa EVI. Le etichette MPLS da utilizzare vengono segnalate utilizzando il campo MPLS Label presente nell’attributo PMSI Tunnel. Queste etichette sono da considerarsi come downstream allocated, ossia devono essere utilizzate dal PE origine del traffico BUM come service label, per inviare il traffico BUM agli altri PE della stessa EVI. Per chiarire meglio concetto, illustrerò come avviene in questo caso la segnalazione e come avviene il trasporto del trasporto del traffico, ossia piano di controllo e piano dati.

La figura seguente illustra come avviene la segnalazione.

Per motivi di spazio ho evidenziato il solo annuncio EVPN generato da PE1-1. Ma ciascun PE di ciascuna istanza EVI, genera un annuncio simile. Come si può notare, l’annuncio contiene l’attributo PMSI Tunnel che definisce il tipo di P-tunnel da utilizzare (nell’esempio Ingress Replication) e ho evidenziato anche il valore di una etichetta MPLS (NOTA: il PMSI Tunnel contiene anche altri due campi, qui non evidenziati perché di minore importanza).

A questo punto vediamo il piano dati, illustrato nella figura seguente. Nella figura, le etichette segnalate dai router PEX-Y nel PMSI Tunnel sono indicate con LXY. Inoltre, nella figura compare anche la ESI-label annunciata da PE1-2 (= L12-SH) per lo Split Horizon.

Quando PE1-1 riceve una trama Ethernet con MAC destinazione BUM, replica la trama verso tutti i PE della stessa EVI (nella figura gli altri 3 PE). A ciascuna trama viene dapprima aggiunta, dove applicabile, la ESI-label (nella figura alla sola trama diretta verso PE1-2, poiché PE1-1 e PE1-2 fanno parte dello stesso ES e PE1-2 è il DF dell’ES), quindi la service label annunciata dai PE remoti attraverso l’attributo PMSI Tunnel e infine la PSN label, ossia l’etichetta MPLS per il trasporto PE-PE (indicata nella figura genericamente come PSN).

Qualora si utilizzino come P-tunnel i più efficienti LSP MPLS di tipo multipoint (P2MP o MP2MP), la segnalazione segue le logiche già viste nei post precedenti sui LSP MPLS di tipo multipoint. In questo caso l’etichetta MPLS presente nell’attributo PMSI Tunnel non viene utilizzata poiché la demultiplazione sui PE che ricevono il traffico, avviene sulla base dell’etichetta più esterna (per questo ricordo che in questa applicazione non è ammesso il Penultimate Hop Popping). Solo nel caso di aggregazione di più EVI su un singolo P-tunnel, allora viene utilizzata l’etichetta presente nell’attributo PMSI Tunnel per demultiplare a valle l’appartenenza alla particolare EVI all’interno del (singolo) P-tunnel (e il Penultimate Hop Popping è ammesso). L’ etichetta annunciata nell’attributo PMSI Tunnel è da considerarsi in questo caso come upstream allocated, ossia segnalata e utilizzata dai PE che originano il traffico.

Come quasi sempre accade nel mondo delle tecnologie (non solo quelle del networking !) vi è sempre un compromesso nell’utilizzo di metodi differenti. Nel caso del trasporto del traffico BUM, la scelta del tipo di P-tunnel non si sottrae a questa regola. Infatti, l’utilizzo di LSP MPLS di tipo multipoint, se da un lato ottimizza l’uso della banda (replica dei pacchetti MPLS solo nei punti di diramazione degli alberi utilizzati), dall’altro ha lo svantaggio di richiedere degli stati aggiuntivi sui router interni alla rete IP/MPLS (router P), per la replica dei pacchetti sui punti di diramazione. E questo aspetto potrebbe creare problemi di scalabilità considerato l’elevato numero di LSP MPLS multipoint che potrebbero essere necessari (senza aggregazione, uno per EVI). Questo non accade nel caso di Ingress Replication, dove non sono necessari stati aggiuntivi perché non esistono punti di diramazione. Per contro lo svantaggio è che la replica dei pacchetti MPLS avviene a partire dal PE di ingresso, con conseguente spreco di banda.

TRASPORTO DEL TRAFFICO UNICAST

Gli aspetti fondamentali sulla segnalazione di indirizzi MAC unicast via annunci BGP EVPN sono già stati trattati, ma voglio in questa sezione, per maggiore chiarezza, fare un riepilogo complessivo, sul quale poi innestare come avviene il trasporto del traffico unicast, quando gli indirizzi MAC sono già stati appresi.

Quando un router PE “impara” (sul piano dati o con qualche meccanismo del piano di controllo) un nuovo indirizzo MAC da un CE, sul suo attachment circuit (AC) associato a una particolare EVI, aggiunge alla sua MAC table locale (o MAC-VRF) un nuovo entry del tipo <MAC; AC>. Il PE crea quindi un annuncio BGP EVPN del tipo MAC/IP Advertisement (tipo 2), che invia (direttamente o, come più sovente accade, con l’ausilio di Route Reflector), a tutti gli altri PE della stessa EVI (NOTA: in realtà, a meno di non implementare meccanismi di BGP route-target filtering sui Route Reflector, l’annuncio viene ricevuto da tutti i PE, i quali mediante il classico filtraggio basato sui Route Target provvedono o meno ad accettarlo). Questo è essenzialmente il processo di MAC learning remoto via BGP, già descritto nel post precedente sul modello EVPN, che è la novità principale introdotta dal modello EVPN.

Come già descritto nell’ultima sezione del post precedente sul modello EVPN, gli annunci BGP EVPN di tipo MAC/IP Advertisement includono le seguenti informazioni:

• L’indirizzo MAC da annunciare.
• L’Ethernet Tag, o VLAN ID, al quale l’indirizzo MAC appartiene.
• L’ESI del segmento Ethernet dal quale l’indirizzo MAC è stato appreso (fondamentale per applicare l’aliasing).
• Una etichetta MPLS che svolge il ruolo di service label.

L’inclusione dell’ESI nell’annuncio, oltre a essere fondamentale per l’aliasing, ha anche un ruolo nell’ottimizzazione del forwarding locale delle trame Ethernet. Infatti, quando un PE riceve un annuncio MAC/IP Advertisement da un altro PE multi-homed allo stesso ES, installa un forwarding entry nella MAC-VRF associata all’EVI che ha come Next-Hop la sua interfaccia locale sull’ES (e non l’indirizzo IP del PE remoto !). Il risultato è che la connettività locale è sempre preferita rispetto alla connettività via backbone, ottimizzando così il forwarding delle trame Ethernet verso i CE. Questo nell’ipotesi che il PE non abbia già “imparato” localmente l’indirizzo MAC, perché in questo caso il PE ha già un forwarding entry con Next-Hop la sua interfaccia locale, e di conseguenza ignora l’annuncio MAC/IP Advertisement.

Quando un PE inizialmente “impara” il solo indirizzo MAC, invia l’annuncio BGP EVPN di tipo MAC/IP Advertisement solo con queste informazioni. Qualora successivamente il PE “imparasse” con qualche “trucco” (es. ARP snooping) anche l’indirizzo IP associato all’indirizzo MAC e sul PE sia stata configurata una interfaccia IRB per la VLAN (interfaccia Integrated Routing and Bridging, spesso anche chiamata interfaccia VLAN), allora il PE invia un secondo annuncio MAC/IP Advertisement aggiungendo informazioni di livello 3 come l’indirizzo IP e il Default Gateway. Illustrerò nel prossimo post sul modello EVPN, i vantaggi che si ottengono dalla possibilità introdotta nel modello, di poter annunciare sia indirizzi MAC che indirizzi IP associati e Default Gateway.

Infine, per concludere questo breve “riassunto” del MAC learning sul piano di controllo, si noti che quando un indirizzo MAC scade (ebbene si, anche qui c’è il MAC aging !), l’entry corrispondente sulla MAC-VRF viene cancellato e l’indirizzo MAC ritirato attraverso un ritiro dell’annuncio BGP EVPN MAC/IP Advertisement inviato in precedenza. L’annuncio e il ritiro di un indirizzo MAC sono particolarmente importanti nel caso di MAC mobility, ossia quando un indirizzo MAC si muove da un ES a un altro. Illustrerò i principi che regolano la MAC mobility nella prossima sezione.

La figura seguente riassume quanto detto sulla segnalazione di un nuovo indirizzo MAC appreso da PE1-1 dal CE1 (indirizzo MAC-1). Ho anche evidenziato nella figura l’annuncio BGP EVPN di tipo Ethernet A-D per EVI, già visto sopra, e che ci servirà per capire meglio la funzionalità di aliasing sul piano dati.

La figura seguente riporta invece il piano dati. Nella figura sono evidenziate due trame Ethernet generate da Host attestati a CE2 e inviate da questo a PE2-1. Le due trame hanno identico MAC destinazione MAC-1, noto a PE2-1 attraverso l’annuncio MAC/IP Advertisement inviato da PE1-1. Nella propria MAC-VRF, PE2-1 ha come Next-Hop sia PE1-1 che PE1-2, quest’ultimo grazie all’annuncio BGP EVPN Ethernet A-D per EVI. PE2-1 ha così la possibilità di bilanciare il traffico tra i due Next-Hop. Quando sceglie di inoltrare una trama utilizzando come Next-Hop PE1-1, la incapsula con la service label annunciata da PE1-1 attraverso l’annuncio MAC/IP Advertisement, mentre quando sceglie di inoltrare una trama utilizzando come Next-Hop PE1-2, la incapsula con l’aliasing label annunciata da PE1-2 attraverso l’annuncio Ethernet A-D per EVI. In entrambi i casi viene poi aggiunta come top label, la PSN label, ossia l’etichetta MPLS che consente di trasportare i pacchetti MPLS tra il PE d’ingresso (PE2-1) e i PE di uscita (PE1-1 e PE1-2). 

Per completare il quadro della situazione, manca un piccolo tassello, che comunque non riguarda il modello EVPN, ma è un aspetto generale del load balancing: con quale criterio PE2-1 sceglie il Next-Hop ? Bene, qui le possibilità sono molte, ci si può affidare semplicemente agli indirizzi MAC, oppure, se possibile, andare in profondità sul pacchetto trasportato. Ad esempio, se questo fosse un semplice pacchetto TCP/IP, come hash key per il load balancing si potrebbero utilizzare tutti o parte dei seguenti campi: indirizzo IP sorgente, indirizzo IP destinazione, porta TCP sorgente, porta TCP destinazione, ecc. .

MOBILITÀ DEGLI INDIRIZZI MAC (MAC MOBILITY)

Nelle applicazioni attuali nei moderni Data Center, è pratica comune muovere le macchine virtuali (VM, Virtual Machine) da un segmento Ethernet a un altro. Questo comporta che un indirizzo MAC annunciato in precedenza da un PE, venga anche annunciato dal (o dai) PE del nuovo segmento Ethernet. Se non gestito correttamente, questo processo può portare a perdita di traffico, qualora trame Ethernet dirette all’indirizzo MAC che ha cambiato ES, vengano instradate verso il PE “vecchio”.

Per consentire a tutti i PE di una stessa EVI di “localizzare” correttamente gli indirizzi MAC “in movimento”, deve accadere che:

• I PE dell’ES dove è “approdato” il MAC, ne annuncino la presenza, tramite annunci BGP EVPN di tipo MAC/IP Advertisement.
• Tutti gli annunci BGP EVPN di tipo MAC/IP Advertisement inviati dal o dai PE da dove era raggiungibile in precedenza l’indirizzo MAC, devono essere eliminati da tutti gli altri PE della EVI.

Quando il o i PE dell’ES originale utilizzano, per apprendere gli indirizzi MAC, il MAC learning sul piano dati, questi PE non sono in grado accorgersi che l’indirizzo MAC ha “traslocato” in un altro ES. Il segnale per il ritiro degli indirizzi MAC in questo caso, può avvenire a partire dalla ricezione da almeno uno dei PE del nuovo ES, del nuovo annuncio MAC/IP Advertisement. Viceversa, qualora l’apprendimento dei MAC avvenga sul piano di controllo o management, a fare da segnale per il ritiro può essere la ricezione da un CE, di un annuncio che ritiri un indirizzo MAC, a causa dello spostamento su un altro ES.

Per gestire correttamente situazioni transitorie che si potrebbero verificare a causa di rapidi e continui spostamenti di un indirizzo MAC tra due o più ES, negli annunci BGP EVPN di tipo MAC/IP Advertisement viene aggiunto l’attributo MAC Mobility Extended Community. Questo attributo contiene un numero di sequenza, che viene incrementato di una unità ogniqualvolta un PE invia un annuncio BGP EVPN di tipo MAC/IP Advertisement (NOTA: in realtà nel primo annuncio l’attributo non viene inserito, e ciò corrisponde di default a un numero di sequenza nullo). Quando un PE riceve un annuncio di tipo MAC/IP Advertisement con numero di sequenza più elevato di quello già in memoria, sostituisce quello presente in memoria con quello ricevuto con il numero di sequenza maggiore.

La figura seguente mostra un esempio di utilizzo dell’attributo MAC Mobility Extended Community. Nella figura si ipotizza che l’indirizzo MAC-1 si sia già mosso una volta da Ovest verso Est e che sia ritornato ad Ovest. PE1-1, una volta appreso di nuovo l’indirizzo MAC-1 (via MAC learning sul piano dati o di controllo), invia a tutti i PE della stessa EVI un annuncio MAC/IP Advertisement con l’attributo MAC Mobility Extended Community avente il numero di sequenza posto a 2.

La figura seguente mostra invece cosa avviene dopo un nuovo spostamento dell’indirizzo MAC-1 da Ovest verso Est (fase 1 nella figura). Il router PE2-1, una volta accortosi (sempre via MAC learning sul piano dati o di controllo) della presenza di MAC-1 sul proprio ES, genera un nuovo annuncio di tipo MAC/IP Advertisement con numero di sequenza 3 (ossia, uno in più del valore del numero di sequenza ricevuto), che viene inviato a tutti i PE dell’EVI (fase 2 nella figura). Quando PE1-1 riceve questo nuovo annuncio con numero di sequenza maggiore, esegue due operazioni:

• Sostituisce l’annuncio corrente dell’indirizzo MAC con quello più aggiornato (numero di sequenza maggiore).
• Ritira l’annuncio inviato in precedenza con numero di sequenza 2 (fase 3 nella figura).

CONCLUSIONI

In questo post ho illustrato molti dettagli di funzionamento del modello EVPN introdotto in un post precedente. Finora però mi sono limitato a trattare gli aspetti legati al Livello 2, ossia di annuncio degli indirizzi MAC, del trasporto del traffico BUM e unicast noto, della mobilità degli indirizzi MAC, oltre che alle problematiche della gestione dei collegamenti multi-homed e le soluzioni ai problemi principali.

Il modello EVPN ha però un’altra formidabile freccia nel suo arco, l’integrazione con il Livello 3 (questo grazie alla possibilità offerta dagli annunci BGP EVPN di tipo MAC/IP Advertisement, di trasportare anche informazioni su un indirizzo IP associato all’indirizzo MAC). E questo è uno degli aspetti più interessanti del modello EVPN che tratterò nei post successivi.

Ricordo infine quanto detto nelle conclusioni del post precedente sul modello EVPN, questo non sta solo nelle slide, nei documenti IETF o nelle chiacchiere del sottoscritto, ma è già implementato in varie piattaforme commerciali (es. Cisco ASR 9k, Nexus 7k/9k, Juniper MX/EX, Alcatel-Lucent 7750 SR).