Nell'ultimo post prima della vacanze, diviso in due parti che potete trovare qui e qui, ho lanciato un messaggio un po' provocatorio circa l'utilizzo di Ethernet come strumento di forwarding del traffico, secondo me una prassi che ha creato e crea tanti problemi e di cui si poteva fare a meno. Il forwarding, secondo i canoni classici del modello di riferimento ISO/OSI, come ho ampiamente argomentato nel post precedente, dovrebbe essere svolto dal Livello 3 (oggi sostanzialmente il protocollo IP) e non dal Livello 2.
La modalità che si è scelta per il forwarding di Livello 2, ossia quella di "imitare" il funzionamento del famoso cavo giallo, ha poi introdotto molte problematiche, la cui soluzione ha richiesto l'introduzione di strumenti come il protocollo Spanning Tree, di cui ho illustrato le limitazioni nel post precedente. Limitazioni di cui il mondo del networking è ormai più che consapevole, tanto che come ho argomentato nel post precedente, il protocollo STP è tecnologicamente "defunto". Ma non illudiamoci, rimarrà ancora sul campo per molti anni. D'altra parte anche tecnologie dichiarate da anni "defunte", come ad esempio ATM e Frame Relay, sono ancora presenti nelle reti in produzione.
Io credo sia giunto il momento di liberarsi dalla "sindrome del cavo giallo" e rimettere le cose al loro posto. Come illustrerò, non è una mia fissazione, molti stanno già andando in questa direzione.
ARP O NON ARP ?
Partendo dalla periferia della rete, il primo segmento dove si incontrano gli indirizzi MAC e dove il forwarding avviene proprio sulla base di un indirizzo MAC, è il collegamento Host-Switch. Tutti conosciamo come funziona il meccanismo del routing diretto/indiretto, del default-gateway, ecc. . E tutti conosciamo il ruolo fondamentale del protocollo ARP (o ND nel caso di traffico IPv6). Quello che accade, come noto, è che lo switch che riceve una trama Ethernet, esegue il forwarding (ammesso che già conosca la "localizzazione" dell'indirizzo MAC destinazione) consultando la tabella CAM, utilizzando l'entry corrispondente all'indirizzo MAC destinazione.
Tutto chiaro, ma se ci pensate un attimo qui si sfiora un po' il ridicolo. E si perché da più di 15 anni molti modelli di switch sono multilayer, ossia sono in grado di eseguire il forwarding anche a Livello 3 (ricordate il vecchio Cisco Catalyst 3550 dei primi anni 2000 ?). Oggi ad esempio, tutti gli switch dei moderni Data Center sono multilayer, anzi, direi che assomigliano più a dei router che a degli switch tradizionali. Perché quindi eseguire il forwarding a Livello 2 e non direttamente a Livello 3 ? Perché a suo tempo è stato sviluppato un Hardware per velocizzare la commutazione L2 e non si è utilizzato direttamente il L3 engine ? Mistero.
Però affinché questo ragionamento stia in piedi, è necessario proporre una qualche soluzione alternativa a quella classica che utilizza ARP o ND. Solo che fare a meno completamente del protocollo ARP o ND non è semplice perché gli odierni Sistemi Operativi ancora ragionano nel modo classico e quindi loro incapsulano comunque i pacchetti IP in trame Ethernet. Far cambiare la testa a chi progetta il Networking dei Sistemi Operativi è impresa titanica, per cui lasciamoli stare, facciamogli credere che tutto funzioni come sempre. Come però ?
La soluzione utilizza ancora il protocollo ARP (o ND), anche se non in modo convenzionale. L'idea è abbastanza semplice. Pensate un attimo a questo modo di procedere:
ROUTING DIRETTO = ROUTING INDIRETTO
Vediamo ora come potrebbe funzionare il piano dati. Supponiamo dapprima il caso di routing diretto, ossia intra-subnet, ad esempio l'Host 1 invia un pacchetto IP all'Host 2, entrambi parte della subnet IP 10.1.1.0/29.
Come da prassi, l'Host 1 invia un messaggio ARP request per risolvere l'indirizzo IP destinazione (target) 10.1.1.2. Lo switch risponde immediatamente con un ARP Reply fornendo come MAC il MAC AMG. Lo switch svolge quindi una funzione di ARP proxy, e non propaga a nessuno l'ARP Request. A dire il vero questa procedura si potrebbe risparmiare poiché l'Host conosce già l'indirizzo AMG via GARP Reply (vedi sezione precedente) ma voglio essere il meno invasivo possibile lato Host, ossia lasciamo il funzionamento degli Host intatto (anche se non ottimale).
A questo punto, come da funzionamento attuale degli Host, l'Host 1 incapsula il pacchetto IP con indirizzi IP sorgente e destinazione rispettivamente 10.1.1.1 e 10.1.1.2, in una trama Ethernet con MAC sorgente l'indirizzo MAC della scheda NIC dell'Host 1 e MAC destinazione il MAC AMG. La trama Ethernet arriva allo switch, che sulla base dell'indirizzo MAC AMG capisce che deve effettuare un lookup sulla propria FIB. Su quest'ultima trova che l'indirizzo IP 10.1.1.2 è raggiungibile attraverso la porta 2. Purtroppo il pacchetto va incapsulato in una nuova trama Ethernet, che avrà come indirizzo MAC sorgente l'indirizzo AMG e MAC destinazione l'indirizzo MAC dell'Host 2, appreso in precedenza via GARP. Il tutto è riassunto nelle due figure seguenti.
Cosa cambia nel caso di routing indiretto, ad esempio nel caso di un pacchetto inviato dall'Host 1 all'Host 2 o verso un indirizzo IP esterno ? Assolutamente niente, il procedimento è assolutamente identico (da qui il titolo di questa sezione). Con questo diabolico ma banale "trucchetto", parlare di routing diretto (ossia, intra-subnet) o indiretto (ossia, inter-subnet) è inutile. E se ci fate caso non serve più nemmeno il concetto di default gateway. E nemmeno il protocollo ARP nella sua versione "classica". E a dirla tutta non ci sarebbe nemmeno bisogno degli indirizzi MAC, che sto utilizzando solo perché sto utilizzando il protocollo ARP per non dar fastidio al funzionamento "classico" degli Host. Ma non ci vuole molto a capire che non utilizzando il protocollo ARP, ma un altro protocollo tipo ES-IS per annunciare gli indirizzi IP degli Host, degli indirizzi MAC si può tranquillamente fare a meno, sarebbe sufficiente incapsulare i pacchetti IP non in trame Ethernet, ma utilizzando ad esempio un protocollo tipo PPP. O estremizzando, in un ambiente IP(v4/v6)-only, non servirebbe nemmeno l'incapsulamento di Livello 2 !
Fantascienza ? Nemmeno per sogno. Questo modo di procedere esiste già, qualcuno un po' più "smart" lo ha già implementato. Ad esempio, Microsoft Hyper-V Network Virtualization, Juniper Contrail e Nuage VSP utilizzano questo trucco nell'Overlay Virtual Networking. Ho trattato in questo post la modalità L3-only di Juniper Contrail che fa esattamente quanto ho riportato sopra. Anche Cisco ha implementato una modalità simile nei suoi nuovi Nexus 9k.
E CON LE VLAN COME LA METTIAMO ?
Le VLAN sono lo strumento principe utilizzato nelle reti Switched Ethernet per implementare la segmentazione degli Host (o, come fa chic oggi, per implementare la multi-tenancy). Le VLAN altro non sono l'equivalente di quelle che nel Livello 3 vengono chiamate VPN (Virtual Private network). VLAN o VPN, il servizio è esattamente identico, creare una rete privata (virtuale) tra un gruppo di Host.
Pensando un attimo al funzionamento delle L3VPN basate sul modello BGP/MPLS, anche la modalità di implementazione, se non identica è però concettualmente simile. Dal lato delle VLAN, c'è una etichetta a identificare la rete privata, il VLAN Tag (12 bit), dal lato L3VPN c'è una etichetta MPLS (service label). Nel caso di utilizzo di VXLAN, a identificare la rete privata è una etichetta, il VNI (24 bit). La differenza, non sostanziale, è che i VLAN tag e i VNI hanno significato globale e quindi vanno configurati manualmente, mentre le etichette MPLS sono locali ai router e sono scelte arbitrariamente da ciascun router (e quindi non vanno configurate manualmente).
Come creare l'equivalente di una VLAN su una rete L3-only, o anche su un singolo dispositivo solo L3 come quello descritto nella sezione precedente è presto detto, basta utilizzare il concetto di VRF (VPN Routing and Forwarding), ben noto a chi conosce il funzionamento delle L3VPN (NOTA: in realtà nel caso di singolo dispositivo è sufficiente implementare il concetto di VRF-lite, già da tempo implementato nei router).
Non voglio qui rifarvi tutta la teoria delle L3VPN, mi basta solo mettere in evidenza che creare delle reti private su una rete Switched Ethernet (VLAN) è equivalente, dal punto di vista del servizio, a creare delle L3VPN su una rete L3-only.
Qualcuno potrebbe obiettare che creare una VLAN su una rete Switched Ethernet sia molto più semplice che realizzare una L3VPN su una rete L3-only. Dipende dai punti di vista, siamo sicuri che configurare una rete Switched Ethernet sia più semplice che configurare una rete L3-only per un servizio L3VPN ? Con le tecniche emergenti di Network Automation io credo che non ci siano grosse differenze. Anche se è vero che realizzare una L3VPN è leggermente più complesso che attivare una VLAN. Ma i vantaggi che ne derivano ripagano certamente il maggiore sforzo di configurazione.
E comunque c'è una scappatoia, ancora però agli albori, la possibilità di realizzare un servizio concettualmente identico a una VLAN, utilizzando l'estensione VXLAN-GPE, dove GPE = Generic Protocol Extension. Questa estensione dell'incapsulamento VXLAN, ancora allo stato draft, ridefinisce l'intestazione VXLAN, che ricordo è di 8 byte, nel seguente modo (la figura è tratta dal draft corrente: https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-04):
La novità principale è il campo Next Protocol, il cui valore indica il tipo di payload trasportato. Nel caso dello standard VXLAN originale l'unico payload possibile è una trama Ethernet, mentre nel caso dell'estensione VXLAN-GPE sono possibili vari payload, identificati per l'appunto dai valori del campo Next Protocol. Solo per curiosità vi riporto i valori specificati nel draft:
0x1 = IPv4 ; 0x2 = IPv6 ; 0x3 = Ethernet ; 0x4 = NSH ; 0x5 = MPLS
(NOTA: NSH = Network Service Header è uno standard emergente per realizzare il Service Function Chaining in un ambiente NFV (Network Function Virtualization). Maggiori informazioni su questo draft IETF)
Morale della favola, con l'estensione VXLAN-GPE è possibile trasportare direttamente pacchetti IP e quindi realizzare reti private senza far intervenire indirizzi MAC. Naturalmente rimane il problema del piano di controllo, che ho trattato ampiamente in vari post passati.
Infine, c'è un aspetto da non sottovalutare, e riguarda l'inter-VLAN routing. Mettere in comunicazione due VLAN richiede comunque l'intervento del Livello 3. Come noto bisogna configurare per ciascuna VLAN una interfaccia virtuale (interfacce IRB o VLAN o BDI, ecc. chiamatele come volete, ogni vendor hai i suoi nomignoli) e assegnare a questa un indirizzo IP appartenente alla subnet IP con cui viene numerata la VLAN. Nel caso di un dispositivo L3-only tutto questo non serve, è sufficiente inserire le due subnet IP nella stessa VRF e tutto "magicamente" funziona.
E qui finisce la prima parte di questo post. Nella seconda affronterò il tema della mobilità degli Host in un ambiente L3-only e possibili architetture di reti ISP L3-only (o meglio, IP-only).
ARP O NON ARP ?
Partendo dalla periferia della rete, il primo segmento dove si incontrano gli indirizzi MAC e dove il forwarding avviene proprio sulla base di un indirizzo MAC, è il collegamento Host-Switch. Tutti conosciamo come funziona il meccanismo del routing diretto/indiretto, del default-gateway, ecc. . E tutti conosciamo il ruolo fondamentale del protocollo ARP (o ND nel caso di traffico IPv6). Quello che accade, come noto, è che lo switch che riceve una trama Ethernet, esegue il forwarding (ammesso che già conosca la "localizzazione" dell'indirizzo MAC destinazione) consultando la tabella CAM, utilizzando l'entry corrispondente all'indirizzo MAC destinazione.
Tutto chiaro, ma se ci pensate un attimo qui si sfiora un po' il ridicolo. E si perché da più di 15 anni molti modelli di switch sono multilayer, ossia sono in grado di eseguire il forwarding anche a Livello 3 (ricordate il vecchio Cisco Catalyst 3550 dei primi anni 2000 ?). Oggi ad esempio, tutti gli switch dei moderni Data Center sono multilayer, anzi, direi che assomigliano più a dei router che a degli switch tradizionali. Perché quindi eseguire il forwarding a Livello 2 e non direttamente a Livello 3 ? Perché a suo tempo è stato sviluppato un Hardware per velocizzare la commutazione L2 e non si è utilizzato direttamente il L3 engine ? Mistero.
Però affinché questo ragionamento stia in piedi, è necessario proporre una qualche soluzione alternativa a quella classica che utilizza ARP o ND. Solo che fare a meno completamente del protocollo ARP o ND non è semplice perché gli odierni Sistemi Operativi ancora ragionano nel modo classico e quindi loro incapsulano comunque i pacchetti IP in trame Ethernet. Far cambiare la testa a chi progetta il Networking dei Sistemi Operativi è impresa titanica, per cui lasciamoli stare, facciamogli credere che tutto funzioni come sempre. Come però ?
La soluzione utilizza ancora il protocollo ARP (o ND), anche se non in modo convenzionale. L'idea è abbastanza semplice. Pensate un attimo a questo modo di procedere:
- Ogni switch impara in qualche modo la "localizzazione" degli indirizzi IP degli Host connessi. Ossia, invece di fare MAC learning, fa IP learning. Come ? Bene, senza scomodare un nuovo protocollo, è sufficiente un classico Gratuitous ARP (GARP), come ad esempio fa Microsoft con il suo Hyper-V. Faccio notare che questo modo di procedere è profondamente diverso dal MAC learning: il MAC learning classico avviene sul piano dati, il meccanismo di IP learning che sto proponendo avviene sul piano di controllo. E pensare, per chi di voi fosse familiare con i vecchi protocolli OSI, che c'era un protocollo che faceva tutto ciò, l'ES-IS (che ovviamente annunciava un indirizzo OSI e non un indirizzo IP, ma il concetto è identico). Solo che è nato sotto l'ente di standardizzazione sbagliato !
- Supponiamo che ogni switch abbia un indirizzo MAC fittizio (talvolta detto Anycast MAC Gateway, AMG), e sia abilitato a rispondere a ciascun messaggio ARP Request con un messaggio ARP Reply che associ all'indirizzo IP target il MAC AMG. Il significato dell'indirizzo AMG per lo switch è il seguente: quando ricevi una trama Ethernet con MAC destinazione l'indirizzo AMG, esegui un forwarding di Livello 3.
- Una volta imparata la "localizzazione" dell'indirizzo IP di un Host, lo switch crea nella sua Tabella di Forwarding IP (FIB) una riga del tipo: <Host Route (/32 o /128) ; porta>, simile all'associazione <MAC ; porta> creata dagli switch L2.
- Infine, lo switch redistribuisce tramite un normalissimo protocollo di routing (es. BGP), l'Host Route, se necessario aggregando più indirizzi IP in unico annuncio (cosa, come noto, non possibile con gli indirizzi MAC). Come Next-Hop è sufficiente un indirizzo IP associato allo switch, indirizzo IP che già oggi anche gli switch L2 hanno per il management da remoto.
ROUTING DIRETTO = ROUTING INDIRETTO
Vediamo ora come potrebbe funzionare il piano dati. Supponiamo dapprima il caso di routing diretto, ossia intra-subnet, ad esempio l'Host 1 invia un pacchetto IP all'Host 2, entrambi parte della subnet IP 10.1.1.0/29.
Come da prassi, l'Host 1 invia un messaggio ARP request per risolvere l'indirizzo IP destinazione (target) 10.1.1.2. Lo switch risponde immediatamente con un ARP Reply fornendo come MAC il MAC AMG. Lo switch svolge quindi una funzione di ARP proxy, e non propaga a nessuno l'ARP Request. A dire il vero questa procedura si potrebbe risparmiare poiché l'Host conosce già l'indirizzo AMG via GARP Reply (vedi sezione precedente) ma voglio essere il meno invasivo possibile lato Host, ossia lasciamo il funzionamento degli Host intatto (anche se non ottimale).
A questo punto, come da funzionamento attuale degli Host, l'Host 1 incapsula il pacchetto IP con indirizzi IP sorgente e destinazione rispettivamente 10.1.1.1 e 10.1.1.2, in una trama Ethernet con MAC sorgente l'indirizzo MAC della scheda NIC dell'Host 1 e MAC destinazione il MAC AMG. La trama Ethernet arriva allo switch, che sulla base dell'indirizzo MAC AMG capisce che deve effettuare un lookup sulla propria FIB. Su quest'ultima trova che l'indirizzo IP 10.1.1.2 è raggiungibile attraverso la porta 2. Purtroppo il pacchetto va incapsulato in una nuova trama Ethernet, che avrà come indirizzo MAC sorgente l'indirizzo AMG e MAC destinazione l'indirizzo MAC dell'Host 2, appreso in precedenza via GARP. Il tutto è riassunto nelle due figure seguenti.
Cosa cambia nel caso di routing indiretto, ad esempio nel caso di un pacchetto inviato dall'Host 1 all'Host 2 o verso un indirizzo IP esterno ? Assolutamente niente, il procedimento è assolutamente identico (da qui il titolo di questa sezione). Con questo diabolico ma banale "trucchetto", parlare di routing diretto (ossia, intra-subnet) o indiretto (ossia, inter-subnet) è inutile. E se ci fate caso non serve più nemmeno il concetto di default gateway. E nemmeno il protocollo ARP nella sua versione "classica". E a dirla tutta non ci sarebbe nemmeno bisogno degli indirizzi MAC, che sto utilizzando solo perché sto utilizzando il protocollo ARP per non dar fastidio al funzionamento "classico" degli Host. Ma non ci vuole molto a capire che non utilizzando il protocollo ARP, ma un altro protocollo tipo ES-IS per annunciare gli indirizzi IP degli Host, degli indirizzi MAC si può tranquillamente fare a meno, sarebbe sufficiente incapsulare i pacchetti IP non in trame Ethernet, ma utilizzando ad esempio un protocollo tipo PPP. O estremizzando, in un ambiente IP(v4/v6)-only, non servirebbe nemmeno l'incapsulamento di Livello 2 !
Fantascienza ? Nemmeno per sogno. Questo modo di procedere esiste già, qualcuno un po' più "smart" lo ha già implementato. Ad esempio, Microsoft Hyper-V Network Virtualization, Juniper Contrail e Nuage VSP utilizzano questo trucco nell'Overlay Virtual Networking. Ho trattato in questo post la modalità L3-only di Juniper Contrail che fa esattamente quanto ho riportato sopra. Anche Cisco ha implementato una modalità simile nei suoi nuovi Nexus 9k.
E CON LE VLAN COME LA METTIAMO ?
Le VLAN sono lo strumento principe utilizzato nelle reti Switched Ethernet per implementare la segmentazione degli Host (o, come fa chic oggi, per implementare la multi-tenancy). Le VLAN altro non sono l'equivalente di quelle che nel Livello 3 vengono chiamate VPN (Virtual Private network). VLAN o VPN, il servizio è esattamente identico, creare una rete privata (virtuale) tra un gruppo di Host.
Pensando un attimo al funzionamento delle L3VPN basate sul modello BGP/MPLS, anche la modalità di implementazione, se non identica è però concettualmente simile. Dal lato delle VLAN, c'è una etichetta a identificare la rete privata, il VLAN Tag (12 bit), dal lato L3VPN c'è una etichetta MPLS (service label). Nel caso di utilizzo di VXLAN, a identificare la rete privata è una etichetta, il VNI (24 bit). La differenza, non sostanziale, è che i VLAN tag e i VNI hanno significato globale e quindi vanno configurati manualmente, mentre le etichette MPLS sono locali ai router e sono scelte arbitrariamente da ciascun router (e quindi non vanno configurate manualmente).
Come creare l'equivalente di una VLAN su una rete L3-only, o anche su un singolo dispositivo solo L3 come quello descritto nella sezione precedente è presto detto, basta utilizzare il concetto di VRF (VPN Routing and Forwarding), ben noto a chi conosce il funzionamento delle L3VPN (NOTA: in realtà nel caso di singolo dispositivo è sufficiente implementare il concetto di VRF-lite, già da tempo implementato nei router).
Non voglio qui rifarvi tutta la teoria delle L3VPN, mi basta solo mettere in evidenza che creare delle reti private su una rete Switched Ethernet (VLAN) è equivalente, dal punto di vista del servizio, a creare delle L3VPN su una rete L3-only.
Qualcuno potrebbe obiettare che creare una VLAN su una rete Switched Ethernet sia molto più semplice che realizzare una L3VPN su una rete L3-only. Dipende dai punti di vista, siamo sicuri che configurare una rete Switched Ethernet sia più semplice che configurare una rete L3-only per un servizio L3VPN ? Con le tecniche emergenti di Network Automation io credo che non ci siano grosse differenze. Anche se è vero che realizzare una L3VPN è leggermente più complesso che attivare una VLAN. Ma i vantaggi che ne derivano ripagano certamente il maggiore sforzo di configurazione.
E comunque c'è una scappatoia, ancora però agli albori, la possibilità di realizzare un servizio concettualmente identico a una VLAN, utilizzando l'estensione VXLAN-GPE, dove GPE = Generic Protocol Extension. Questa estensione dell'incapsulamento VXLAN, ancora allo stato draft, ridefinisce l'intestazione VXLAN, che ricordo è di 8 byte, nel seguente modo (la figura è tratta dal draft corrente: https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-04):
La novità principale è il campo Next Protocol, il cui valore indica il tipo di payload trasportato. Nel caso dello standard VXLAN originale l'unico payload possibile è una trama Ethernet, mentre nel caso dell'estensione VXLAN-GPE sono possibili vari payload, identificati per l'appunto dai valori del campo Next Protocol. Solo per curiosità vi riporto i valori specificati nel draft:
0x1 = IPv4 ; 0x2 = IPv6 ; 0x3 = Ethernet ; 0x4 = NSH ; 0x5 = MPLS
(NOTA: NSH = Network Service Header è uno standard emergente per realizzare il Service Function Chaining in un ambiente NFV (Network Function Virtualization). Maggiori informazioni su questo draft IETF)
Morale della favola, con l'estensione VXLAN-GPE è possibile trasportare direttamente pacchetti IP e quindi realizzare reti private senza far intervenire indirizzi MAC. Naturalmente rimane il problema del piano di controllo, che ho trattato ampiamente in vari post passati.
Infine, c'è un aspetto da non sottovalutare, e riguarda l'inter-VLAN routing. Mettere in comunicazione due VLAN richiede comunque l'intervento del Livello 3. Come noto bisogna configurare per ciascuna VLAN una interfaccia virtuale (interfacce IRB o VLAN o BDI, ecc. chiamatele come volete, ogni vendor hai i suoi nomignoli) e assegnare a questa un indirizzo IP appartenente alla subnet IP con cui viene numerata la VLAN. Nel caso di un dispositivo L3-only tutto questo non serve, è sufficiente inserire le due subnet IP nella stessa VRF e tutto "magicamente" funziona.
E qui finisce la prima parte di questo post. Nella seconda affronterò il tema della mobilità degli Host in un ambiente L3-only e possibili architetture di reti ISP L3-only (o meglio, IP-only).
Nessun commento:
Posta un commento