Nella prima parte di questo post, a dire il vero un po' "provocatorio", ho cercato di illustrare alcune mie idee (non solo mie per la verità, ma anche di altri networker, molto più illustri del sottoscritto) sull'opportunità di utilizzare il Livello 2 nelle reti IP, in particolare di utilizzare le reti Switched Ethernet. Prima di leggere questa seconda parte, vi invito quindi a leggere la prima parte, che trovate a questo link.
L'evoluzione "storica" l'ho mostrata nella prima parte di questo post. In questa seconda parte cercherò di approfondire alcuni argomenti.
IL "PENTIMENTO" DI RADIA PERLMAN
Radia Perlman, come noto, è considerata come colei che "inventato" il concetto di Ethernet Bridging, e come colei che ha "inventato" il protocollo STP. Però la stessa Radia Perlman è la persona che guidato in IETF il team che prodotto il TRILL (vedi prima parte del post), il cui obiettivo è quello di rimpiazzare il protocollo STP con un protocollo con caratteristiche simili a quelle di un protocollo di routing tradizionale.
Tutto questo perché a un certo punto, anche Radia Perlman si è resa conto di tutti i problemi indotti dall'introduzione del concetto di Ethernet Bridging. Il suo "pentimento" è riassunto in un suo intervento su GoogleTalk, che potete trovare qui. Oggetto del suo intervento, dal titolo "Routing without tears; Bridging without danger", era una introduzione al protocollo TRILL. Al minuto 16.45 della presentazione, Radia ha presentato una slide (la 32) dal titolo "What's wrong with bridges ?" nella quale parla proprio dei problemi creati dall'introduzione del concetto di Ethernet Bridging. Cerco di riassumerne il contenuto con parole mie e commenti extra (NOTA: i titoli in Inglese sono quelli riportati nella slide):
- Suboptimal routing: già discusso nella prima parte di questo post. Il protocollo STP utilizza criteri alquanto discutibili nella scelta dei percorsi.
- Traffic Concentration: la distribuzione del traffico sui vari link tende a concentrarsi sui pochi link attivi (ricordo che con STP attivo, la maggior parte dei link non viene utilizzata).
- Temporary loops real dangerous (no hop count, exponential proliferation): i protocolli di Livello 2 (tutti !) non hanno un Hop Count (o TTL, nei pacchetti IPv4; Hop Count è la terminologia utilizzata in IPv6, e comunque TTL e Hop Count sono utilizzati allo stesso identico modo). Quindi non hanno la possibilità di mitigare l'effetto dei loop, producendo effetti deleteri come i Broadcast Storm nelle reti Switched Ethernet.
- Fragile: if lose packets (congestion ?), turn on port: vedi il punto "Impatto della congestione di rete" nella prossima sezione.
Aggiungo altri punti, a cura del sottoscritto:
- Gli indirizzi MAC non hanno alcun significato topologico, come invece lo hanno gli indirizzi IP. Con gli indirizzi IP è possibile applicare il concetto ben noto di "Prefix summarization", vitale per la scalabilità dell'intera Internet. Gli indirizzi MAC sono invece sparsi a caso sulla rete e non hanno possibilità di essere aggregati (si parla spesso di indirizzamento flat).
- I protocolli di Livello 2 (tutti !) non supportano la frammentazione, men che meno il meccanismo di Path MTU Discovery, rendendo impossibile il forwarding su segmenti di rete con MTU non sufficientemente grandi.
- I protocolli di Livello 2 (tutti !) non hanno un protocollo tipo ICMP per lo scambio di messaggi di errore.
D'altra parte, tutto questo è in linea con la logica della definizione del Livello 2 secondo il modello di comunicazione ISO/OSI (vedi post precedente).
Questi problemi si aggiungono a quelli già esposti nella prima del post, per cui viene spontaneo chiedersi: perché sono stati introdotti i Bridge Ethernet ? Cosa è andato storto ? Radia Perlman ha una spiegazione anche per questo, i più curiosi possono ripercorrere l'evoluzione storica che ha portato all'introduzione dei Bridge/Switch nel seguito del suo video.
(ALTRE) DIFFERENZE TRA ROUTING E BRIDGING
Nella prima parte del post ho messo in evidenza una differenza fondamentale tra bridging e routing: un Bridge (o Switch) fa affidamento sul piano dati per imparare la localizzazione degli Host, e quando non la conosce utilizza il meccanismo del flooding, ossia una logica è di tipo guesswork; per contro un Router impara la localizzazione degli Host attraverso un piano di controllo (un protocollo di routing !) e quando non conosce una destinazione scarta i pacchetti. In breve, routing è “forwarding based on presumption of knowledge”, bridging è “forwarding by guessing”.
Benché fondamentale per le sue implicazioni, non è questa l'unica differenza tra bridging e routing. Di seguito ne riporto altre, alcune delle quali citate sopra e riportate per completezza (NOTA: l'elenco non è volutamente esaustivo):
E ALLORA, COSA NE FACCIAMO DEL LIVELLO 2 ?
E' giunto il momento di tirare le conclusioni (anche se a me verrebbe voglia di tirare le orecchie a qualcuno ...), e rispondere alla domanda posta nel titolo del post: abbiamo veramente bisogno del Livello 2 ?
Iniziamo dai collegamenti punto-punto, che oggi utilizzano vari standard di Livello 2. I protocolli più utilizzati sono PPP e Ethernet (non considero più ATM e Frame Relay poiché ormai sono considerate tecnologie obsolete, anche se l'installato è ancora notevole). La prima domanda da porsi è la seguente: cosa serve del Livello 2 in un collegamento punto-punto ? Cerchiamo di fare un'analisi puntuale:
Nei collegamenti multipunto, es. LAN Ethernet, è possibile, anche se non indispensabile, utilizzare anche indirizzi di Livello 2. Dico che non è indispensabile poiché ogni Host, nel nuovo mondo Internet, ha un suo indirizzo IP, per cui perché non utilizzare direttamente questo per la comunicazione tra Host, levandosi così di torno anche un protocollo come l'ARP ? Il mondo del networking molti anni fa ha scelto una strada diversa, ma non per questo si può dire che abbia scelto la via più semplice. Tutti gli altri campi citati sopra per i collegamenti punto-punto possono essere tranquillamente utilizzati, quindi, in conclusione, Livello 2 si, ma con giudizio ...
Ciò che invece andrebbe accuratamente evitato è l'utilizzo delle reti Switched Ethernet, che creano molti problemi e disottimizzazioni, che ho evidenziato in questo post (parte prima e seconda). Vedo con piacere che il mondo del networking, soprattutto a livello di Data Center sta recependo queste idee, per cui sono fiducioso in un futuro in cui il Livello 2 tornerà ai suoi compiti originali, tra i quali non rientra il forwarding delle trame.
Però qui nasce un ultimo fondamentale problema: è possibile utilizzare per il forwarding il solo indirizzo IP (v4/v6) ? è possibile realizzare reti scalabili L3-only ? La mia risposta personale è, si è possibile, ed è possibile farlo in modo poco invasivo, riutilizzando molto del macchinario esistente. Ma di questo parlerò in un post successivo, dopo le vacanze estive.
CONCLUSIONI
Fin da quando ho iniziato a occuparmi di Networking IP (circa 20 anni fa, agli albori della mia quarta vita professionale), un tarlo mi è sempre roso dentro: perché un banale PC, un server, oggi anche tablet e smartphone, in generale, un Host, deve avere due indirizzi, un indirizzo MAC e uno IP ? Non ne basterebbe uno solo ? D'altra parte in una rete IP, un Host deve comunicare con un altro Host, e questi, sono individuabili tramite un classico indirizzo IP. Un po' come avveniva nel vecchio mondo telefonico, dove gli utenti erano (e sono) individuati da un numero telefonico (non mi risulta che gli utenti siano individuati da due numeri, come avviene per gli Host in una rete IP). E negli anni la convinzione che dell'indirizzo MAC si potesse fare a meno si è rafforzata sempre di più. L'introduzione delle reti Switched Ethernet ha poi creato in me un ulteriore dubbio: perché utilizzare questo tipo di reti, quando le reti IP svolgono lo stesso lavoro in modo molto più egregio ? E così mi è venuto un sospetto, non è che qualcuno ha voluto guidare le nostre menti magari facendoci una sorta di lavaggio del cervello per vendere più apparati, per farli cambiare con più frequenza, quindi aumentando il loro business ? Sono io che la penso in modo sbagliato ? A dire il vero ho trovato qualcuno che ha le mie stesse idee, leggetevi questo post di Mark Burgess (non è un networker, ma una specie di genio dell'informatica), segnalatomi dal mio amico Ivan Pepelnjak, che è un altro che la pensa come me (o io che la penso come lui ? su questo argomento ci siamo scambiati delle opinioni nel lontano 2010, e non ho indagato da quanto tempo lui aveva le mie stesse convinzioni).
Dimenticavo ... Buone Vacanze e arrivederci a Settembre.
(ALTRE) DIFFERENZE TRA ROUTING E BRIDGING
Nella prima parte del post ho messo in evidenza una differenza fondamentale tra bridging e routing: un Bridge (o Switch) fa affidamento sul piano dati per imparare la localizzazione degli Host, e quando non la conosce utilizza il meccanismo del flooding, ossia una logica è di tipo guesswork; per contro un Router impara la localizzazione degli Host attraverso un piano di controllo (un protocollo di routing !) e quando non conosce una destinazione scarta i pacchetti. In breve, routing è “forwarding based on presumption of knowledge”, bridging è “forwarding by guessing”.
Benché fondamentale per le sue implicazioni, non è questa l'unica differenza tra bridging e routing. Di seguito ne riporto altre, alcune delle quali citate sopra e riportate per completezza (NOTA: l'elenco non è volutamente esaustivo):
- Ambito di validità degli indirizzi: gli indirizzi IP come noto hanno validità globale, mentre gli indirizzi MAC hanno validità locale. Qualcuno ha provato in passato, anche recente (vedi questo articolo), a introdurre il concetto di Internet flat, ossia utilizzare gli indirizzi MAC a livello globale, con il successo che tutti conosciamo (Internet utilizza ancora e utilizzerà per sempre indirizzi IPv4/v6).
- Loop detection: vedi sezione precedente.
- Frammentazione delle unità informative (pacchetti, trame): vedi sezione precedente.
- Traffico Multicast/Broadcast: un Router blocca di default i pacchetti con indirizzo IP destinazione multicast o broadcast, a meno che, nel caso di traffico multicast, non venga abilitato un protocollo di routing multicast (es. PIM in tutte le sue varianti). Un Bridge, poiché deve emulare il "cavo giallo", inoltra il traffico Broadcast/Multicast su tutte le sue porte (o sulle porte di una stessa VLAN). Lo stesso fa, come detto sopra, per il traffico con destinazione ignota, tanto che spesso si utilizza l'acronimo BUM per tutti i tre tipi di traffico: Broadcast, Unknwon unicast, Multicast.
- Indirizzi: gli indirizzi di Livello 3 vanno configurati manualmente e di solito includono informazioni di tipo topologico (es. in un piano di numerazione ben fatto, tutti gli indirizzi di un'area OSPF appartengono a subnet IP, tutte parte di una stesso prefisso più grande), mentre gli indirizzi MAC sono di solito codificati in Hardware (indirizzi BIA, Burn In Addresses), anche se vi è la possibilità di configurarli manualmente.
- Scalabilità: concetto che può essere riassunto brevemente in "gli indirizzi IP sono aggregabili, gli indirizzi MAC no". In un certo senso, utilizzare solo indirizzi MAC equivale a utilizzare, in una rete IP, tutti indirizzi di tipo host route (/32 in IPv4, /128 in IPv6), assegnati casualmente senza possibilità alcuna di aggregazione. Vi lascio immaginare cosa sarebbe successo se Internet avesse utilizzato questo approccio.
- Costo: un Bridge solo L2 costa di solito meno di un Router. Le ragioni sono molteplici, tra cui: l'Hardware utilizzato per il forwarding nei Bridge è meno complesso, e quindi meno costoso, rispetto all'Hardware utilizzato per il forwarding dei pacchetti IP. I primi utilizzano, per il lookup degli indirizzi MAC, semplici memorie CAM (Content Addressable Memory), i secondi utilizzano più costose e complesse memorie TCAM (Ternary CAM), con logiche aggiuntive per il longest-match-prefix. Inoltre, i Router implementano complesse funzioni di filtraggio del traffico (es. ACL Cisco, Firewall Filter nel Junos, ecc.) e di QoS, che richiedono TCAM più complesse e costose.
- Configurazione: gli Switch, nella loro incarnazione più semplice non hanno bisogno di configurazione, o solo di una configurazione minimale. Sono semplicemente plug-and-play (o plug-and-pray, quando la rete cresce in consistenza ?). Ma questo è solo un mito, la realtà come sappiamo è ben diversa, basta introdurre delle VLAN che lo scenario cambia completamente. Infatti, realizzare una VLAN richiede la definizione di un VLAN ID, di una opportuna configurazione delle porte access per l'assegnazione alla particolare VLAN, e come minimo un fine tuning del protocollo STP. Ed ecco qua che gli Switch non sono più plug-and-play. Per contro i Router hanno sempre bisogno di una configurazione manuale, ad esempio per assegnare gli indirizzi IP alle interfacce e introdurre un mimino di routing (statico, dinamico).
- Load Balancing: il load balancing è un qualcosa di insito in qualsiasi Router. Bisogna solo fare attenzione ad alcuni aspetti come ad esempio, se avviene di default (es. Cisco) o va abilitato via configurazione (es. Juniper), se è di tipo per pacchetto (obsoleto) o per flusso, ed in quest'ultimo caso su quali parametri si basa la scelta del percorso (es. IP sorgente/destinazione, tipo di protocollo di trasporto, porte, ecc.), su quanti percorsi equicosto è possibile distribuire il traffico, ecc. . Per contro, un Bridge può eseguire load balancing solo su collegamenti aggregati (LAG, MC-LAG). Nelle reti Switched Ethernet, come noto, per evitare forwarding loops non esistono percorsi ridondati, e quindi il load balancing è impossibile (aspetto già citato nella prima parte del post).
- Sicurezza: il filtraggio dei pacchetti è per un Router ordinaria amministrazione, e consente al progettista della rete di segmentarla in "zone" logicamente separate. Alcuni Switch di ultima generazione hanno funzioni simili (port ACL), al prezzo di un aumento delle complessità di configurazione e troubleshooting, che diventano paragonabili a quelle dei Router.
- Troubleshooting: su una rete Switched Ethernet è impossibile eseguire operazioni di troubleshooting dagli Host, una rete di Livello 2 è progettata per essere invisibile agli occhi degli Host. Per contro, un una rete di Livello 3, come arcinoto, consente agli Host di "tracciare" i percorsi verso ciascuna destinazione, consentendo così un primo punto di partenza per eseguire procedure di troubleshooting.
- Mobilità degli Host: il fatto che uno Switch utilizza il piano dati per "imparare" un MAC, rende le reti Switched Ethernet abbastanza adatte a gestire la mobilità di un Host. E' sufficiente infatti che l'Host in mobilità, una volta connesso al nuovo Switch, emetta una trama broadcast, ad esempio un gratuitous ARP, che tutti gli Switch possono aggiornare le loro tabelle di forwarding (CAM tables). Nelle reti IP la mobilità può essere gestita, ma bisogna adottare particolari accorgimenti (che illustrerò in un post successivo) e fare affidamento sulla velocità degli annunci dei protocolli di routing, poiché sono proprio questi a disseminare l'informazione sulla nuova posizione. E poi bisogna anche gestire il fatto che un Host muovendosi va a finire in una LAN diversa, che ha quindi una numerazione IP diversa dalla LAN originale.
- Impatto della congestione di rete: quando uno Switch va in overload, fino al punto da fermare l'invio delle BPDU del protocollo STP, gli Switch remoti potrebbero sbloccare le loro porte, con conseguente possibilità (quasi certezza) di forwarding loop e conseguenti broadcast storm che bloccano per intero il funzionamento della rete. Per contro, se un router non invia più i messaggi del protocollo di routing, in particolare i messaggi Hello, gli altri Router mettono l'adiacenza con il router congestionato nello stato down, ricalcolano la topologia della rete (nell'ipotesi di utilizzo di protocolli link-state come OSPF o IS-IS) e cercano di "aggiustare" il problema. Potrebbero non riuscirci, ma almeno non aggravano il problema.
- Ampiezza di propagazione di un fuori servizio: una rete Switched Ethernet è un singolo fault domain, ossia, un fuori servizio in un punto della rete può avere impatto su tutto il resto della rete. Nelle reti di Livello 3 un fault domain è semplicemente una singola subnet IP. Nelle reti ad architettura gerarchica (multiarea) poi, un fuori servizio in un'area non ha impatto alcuno sulle altre aree, aumentando così la stabilità della rete.
E ALLORA, COSA NE FACCIAMO DEL LIVELLO 2 ?
E' giunto il momento di tirare le conclusioni (anche se a me verrebbe voglia di tirare le orecchie a qualcuno ...), e rispondere alla domanda posta nel titolo del post: abbiamo veramente bisogno del Livello 2 ?
Iniziamo dai collegamenti punto-punto, che oggi utilizzano vari standard di Livello 2. I protocolli più utilizzati sono PPP e Ethernet (non considero più ATM e Frame Relay poiché ormai sono considerate tecnologie obsolete, anche se l'installato è ancora notevole). La prima domanda da porsi è la seguente: cosa serve del Livello 2 in un collegamento punto-punto ? Cerchiamo di fare un'analisi puntuale:
- Indirizzi sorgente/destinazione: ovviamente non servono. D'altra parte il PPP non prevede alcun tipo di indirizzamento. Ne segue che gli indirizzi MAC, in un collegamento Ethernet punto-punto, sono completamente inutili. E questo genera un interessante quesito: perché nei collegamenti Ethernet punto-punto si utilizzano comunque ? La ragione è solo storica, perché l'IEEE, che come noto cura lo standard Ethernet, ha sempre voluto mantenere lo standard compatibile con l'Ethernet originale; e poiché questo era basato sul "cavo giallo" e quindi gli indirizzi MAC lì erano sicuramente necessari, per estensione sono rimasti.
- Tipo payload trasportato (IPv4/v6, MPLS, altro ?): è sicuramente utile. Nello scenario attuale la stragrande maggioranza dei payload o sono IP (v4/v6) o MPLS, "tutto il resto è noia". In reti IP che non utilizzano MPLS, la differenza tra un pacchetto IPv4 e uno IPv6 può essere facilmente gestita guardando i primi 4 bit dell'intestazione. Però se la rete IP utilizza come protocollo di routing IS-IS, i messaggi IS-IS sono della famiglia OSI (quindi né IP né MPLS), e quindi avere la possibilità di un incapsulamento che preveda il tipo di payload trasportato, aggiunge notevole flessibilità alla rete.
- Delimitazione delle trame L2: un qualche metodo di delimitazione delle trame serve sempre. PPP utilizza ad esempio i due byte in configurazione fissa 0x7E (detti flag di inizio e e fine trama). Ehternet utilizza invece un silenzio nella trasmissione (IFG, InterFrame Gap), che è pari al tempo di trasmissione di 96 bit alla velocità fisica (es., per un collegamento a 10 Gbit/s, IFG = 9,6 ns).
- Checksum: potrebbe essere evitata, demandando il controllo di errore al Livello 4 (ricordo che sia il TCP che l'UDP hanno questa possibilità), ma tutti i protocolli di Livello 2, seguendo il modello di riferimento ISO/OSI ne sono dotati.
- Partizione logica del collegamento: questo è un aspetto interessante, presente in molti protocolli di Livello 2. E' la possibilità di partizionare logicamente un collegamento fisico punto-punto in due o più collegamenti logici punto-punto. Nel caso di Ethernet, ciò viene realizzato utilizzando la struttura di trama IEEE 802.1Q, che ha 12 bit (VLAN tag) per la segmentazione. Anche ATM e Frame Relay hanno questa possibilità, ma non il PPP.
Nei collegamenti multipunto, es. LAN Ethernet, è possibile, anche se non indispensabile, utilizzare anche indirizzi di Livello 2. Dico che non è indispensabile poiché ogni Host, nel nuovo mondo Internet, ha un suo indirizzo IP, per cui perché non utilizzare direttamente questo per la comunicazione tra Host, levandosi così di torno anche un protocollo come l'ARP ? Il mondo del networking molti anni fa ha scelto una strada diversa, ma non per questo si può dire che abbia scelto la via più semplice. Tutti gli altri campi citati sopra per i collegamenti punto-punto possono essere tranquillamente utilizzati, quindi, in conclusione, Livello 2 si, ma con giudizio ...
Ciò che invece andrebbe accuratamente evitato è l'utilizzo delle reti Switched Ethernet, che creano molti problemi e disottimizzazioni, che ho evidenziato in questo post (parte prima e seconda). Vedo con piacere che il mondo del networking, soprattutto a livello di Data Center sta recependo queste idee, per cui sono fiducioso in un futuro in cui il Livello 2 tornerà ai suoi compiti originali, tra i quali non rientra il forwarding delle trame.
Però qui nasce un ultimo fondamentale problema: è possibile utilizzare per il forwarding il solo indirizzo IP (v4/v6) ? è possibile realizzare reti scalabili L3-only ? La mia risposta personale è, si è possibile, ed è possibile farlo in modo poco invasivo, riutilizzando molto del macchinario esistente. Ma di questo parlerò in un post successivo, dopo le vacanze estive.
CONCLUSIONI
Fin da quando ho iniziato a occuparmi di Networking IP (circa 20 anni fa, agli albori della mia quarta vita professionale), un tarlo mi è sempre roso dentro: perché un banale PC, un server, oggi anche tablet e smartphone, in generale, un Host, deve avere due indirizzi, un indirizzo MAC e uno IP ? Non ne basterebbe uno solo ? D'altra parte in una rete IP, un Host deve comunicare con un altro Host, e questi, sono individuabili tramite un classico indirizzo IP. Un po' come avveniva nel vecchio mondo telefonico, dove gli utenti erano (e sono) individuati da un numero telefonico (non mi risulta che gli utenti siano individuati da due numeri, come avviene per gli Host in una rete IP). E negli anni la convinzione che dell'indirizzo MAC si potesse fare a meno si è rafforzata sempre di più. L'introduzione delle reti Switched Ethernet ha poi creato in me un ulteriore dubbio: perché utilizzare questo tipo di reti, quando le reti IP svolgono lo stesso lavoro in modo molto più egregio ? E così mi è venuto un sospetto, non è che qualcuno ha voluto guidare le nostre menti magari facendoci una sorta di lavaggio del cervello per vendere più apparati, per farli cambiare con più frequenza, quindi aumentando il loro business ? Sono io che la penso in modo sbagliato ? A dire il vero ho trovato qualcuno che ha le mie stesse idee, leggetevi questo post di Mark Burgess (non è un networker, ma una specie di genio dell'informatica), segnalatomi dal mio amico Ivan Pepelnjak, che è un altro che la pensa come me (o io che la penso come lui ? su questo argomento ci siamo scambiati delle opinioni nel lontano 2010, e non ho indagato da quanto tempo lui aveva le mie stesse convinzioni).
Dimenticavo ... Buone Vacanze e arrivederci a Settembre.
Hi there mates, good article and pleasant arguments commented at this
RispondiEliminaplace, I am genuinely enjoying by these.