venerdì 14 luglio 2017

Il Livello 2: ne abbiamo realmente bisogno ? - Parte I

Dopo una lunga pausa dovuta a pressanti impegni di lavoro, ritorno a scrivere un post, il primo di una serie, e l'ultimo prima delle vacanze estive.

L'argomento riguarda il Livello 2, in particolare il Livello 2 Ethernet. Degli altri protocolli di Livello 2 non parlerò perché o obsoleti (vedi ATM e Frame Relay) o perché, anche se attualmente utilizzati, vi è poco da dire (es. PPP).

Perché scrivo un post su un argomento trito e ritrito, ormai arcinoto a tutti i networker ? La ragione è semplice, perché il Livello 2 Ethernet ha portato a tante storture e problemi che (secondo me, mi assumo qualsiasi responsabilità di quanto asserisco) si sarebbero potute evitare se il Livello 2 Ethernet avesse fatto realmente il Livello 2 secondo i canoni classici del modello di riferimento ISO/OSI, senza invadere il campo del Livello 3, con risultati a dir poco "mediocri". La mia personale opinione è che il mondo del networking sarebbe stato molto più semplice e lineare se di Ethernet avessimo utilizzato il Livello 1 (e si, perché Ethernet ha anche un suo Livello 1, che è stato il suo vero punto di forza) e il Livello 2 secondo i canoni classici dell'architettura ISO/OSI (NOTA: per chi volesse ripassare un po' di storia di Ethernet, consiglio questo link di Wikipedia).

Naturalmente, quando si fanno queste affermazioni è bene tornare un po' indietro nel tempo (d'altra parte, la storia è "maestra di vita") e ripercorrere il cammino che ha portato al concetto di bridge (o switch come si chiama oggi) e alla nascita delle reti Switched Ethernet. Tutto nasce con il mitico "cavo giallo" ... Ma prima di parlare del "cavo giallo" e della sua evoluzione verso il concetto di bridge/switch Ethernet, è bene fare un ripasso della teoria.

IL LIVELLO 2 SECONDO L'ARCHITETTURA ISO/OSI
Il Livello 1 dell'architettura ISO/OSI non ha bisogno di commenti: è l'insieme delle specifiche elettriche/ottiche/meccaniche, che consentono di trasmettere i singoli bit su un mezzo fisico.

Il Livello 2, anche noto come Data Link Layer, è invece un qualcosa di più complesso e da le "direttive" su come due dispositivi di rete, tra loro adiacenti, si scambiano blocchi di bit, che nel gergo del Livello 2 vengono chiamati "trame" (frame nella letteratura anglo-sassone). In particolare, al Livello 2 sono assegnate funzioni quali:
  • Come assemblare i blocchi di bit in trame ?
  • Come delimitare le trame ? In altre parole, come fa un dispositivo a capire dove finisce una trama e inizia la successiva ?
  • Come correggere eventuali errori di trasmissione dei bit nel caso di mezzi trasmissivi con BER (Bit Error Ratio) non nullo (ossia, tutti) ?
  • Come regolare il flusso della trasmissione fra sorgente e destinatario (controllo di flusso) ?
  • In trasmissione, come operare una qualche forma di accesso multiplo/multiplazione per l'accesso condiviso tra più utenti al canale fisico, che eviti collisioni tra pacchetti e interferenze in ricezione o sul canale ?
  • Come informare il Livello superiore (il Livello 3) sul tipo di protocollo trasportato nel payload ?
Tutto ciò consente di far apparire in ricezione, al livello superiore (il Livello 3), il mezzo fisico come una linea di trasmissione esente da errori. Si noti che tra le prerogative classiche del Livello 2 non vi è quella di instradare le trame, ossia di scegliere i percorsi ottimi su una rete ! Le trame di Livello 2 non sono soggette ad instradamento (secondo i canoni classici del modello ISO/OSI), sono i pacchetti di Livello 3 che sono soggetti ad instradamento su una rete. Infatti, qualcuno ha notato che nella definizione delle prerogative del Livello 2, non ho mai citato gli indirizzi MAC ? Semplice, perché un indirizzo serve solo se si hanno due o più dispositivi collegati alla stessa rete fisica, altrimenti è perfettamente inutile. Pensate ad esempio ad un collegamento Ethernet punto-punto, a cosa servirebbe in questo caso l'indirizzo MAC ? A niente. E così pure per altri protocolli di Livello 2. E qui entra sulla scena il mitico "cavo giallo", da cui tutto è partito !

AMARCORD: DAL "CAVO GIALLO" ALLE RETI SWITCHED ETHERNET
Le prime reti LAN basate su Ethernet erano reti ad accesso multiplo, costituite da un unico bus costituito da un cavo coassiale (di colore giallo, da qui il nome di cavo giallo), chiuso elettricamente da due terminator alle estremità (semplici resistenze, niente di che preoccuparsi). Gli host della rete LAN venivano connessi al bus attraverso dei dispositivi dal nome curioso, noti come "attacchi a vampiro". Per la gestione delle collisioni era stato sviluppato il protocollo CSMA/CD. La velocità iniziale di Ethernet era all'inizio di 10 Mbit/s, con un throughput effettivo inferiore a causa delle collisioni. La figura seguente, dovuta alla penna di Bob Metcalfe, che insieme al suo assistente David Boggs può essere considerato senza ombre di dubbio alcuno "l'inventore" di Ethernet, riassume quanto accennato sopra.




















Per inviare una trama Ethernet da Host a Host, è necessario utilizzare degli indirizzi associati agli Host. E qui sono nati gli indirizzi MAC che tutti conosciamo, parte essenziale dell'incapsulamento Ethernet.

Con il passare degli anni e l'evolversi delle tecnologie, il cavo giallo fu sostituito dagli Hub (anche noti come multiport repeater), dispositivi "stupidi" costituiti da tante porte di accesso, il cui scopo era la ripetizione elettrica del segnale ricevuto su una porta, su tutte le porte rimanenti. Il collegamento Host-Hub avveniva attraverso i comuni e anche oggi utilizzati cavi "dritti", con connettori di tipo Rj45.

Il passo successivo (e il più deleterio), è stato l'introduzione dei Bridge, poi evoluti in Switch (NOTA: Bridge e Switch sono sinonimi, anche se uno Switch viene visto come un Bridge "più carrozzato", ossia con molte più porte; ma da un punto di vista funzionale sono identici). Le funzioni degli Switch sono ben note a tutti e non sto qui a ripeterle. L'idea di fondo, riassunta in breve, è che uno Switch "impara" sul piano dati la localizzazione degli Host e quindi memorizza queste informazioni in una tabella, da utilizzare alla bisogna per instradare trame Ethernet verso l'Host corretto. Ciascun Host è identificato da un indirizzo MAC, per cui la tabella di switching è costituita da tante associazioni <MAC, porta>. 

Gli Switch Ethernet non utilizzano alcun piano di controllo per imparare la localizzazione degli Host, ma fanno affidamento esclusivamente al piano dati. Ora questo però crea un problema: come reagisce uno Switch all'arrivo di una trama Ethernet con indirizzo MAC sconosciuto (ossia ancora non "imparato" dallo Switch) ? Bene, lo Switch utilizza la tecnica del flooding, ossia manda la trama su tutte le altre porte, nella speranza che l'indirizzo MAC destinazione venga raggiunto. Ricordo che nella stessa situazione un Router scarta i pacchetti. In ultima analisi la differenza tra Switch e Router è proprio questa:
  • Uno Switch fa affidamento sul piano dati per imparare la localizzazione degli Host, e quando non la conosce utilizza il meccanismo del flooding. Questo perché la logica è di tipo guesswork, non so dove sta la destinazione, suppongo esista, quindi invio la trama su tutte le porte nella speranza di raggiungere la destinazione.
  • 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 (li scarta per una ragione molto semplice, se non conosce la destinazione evidentemente la destinazione non esiste, perché se esistesse la avrebbe appresa dal piano di controllo).
Per il resto Switch e Router svolgono la stessa funzione: il forwarding di blocchi di informazione (trame Ethernet nel caso degli Switch e pacchetti nel caso dei Router). Per fare questo utilizzano ovviamente delle tabelle diverse, nel caso degli Switch costruite a partire dalla informazioni ricavate dal piano dati, nel caso dei Router a partire dalle informazioni ricevute dal piano di controllo.

Questo modo di operare degli Switch è alla radice di tutti "mali" che vedremo in futuro. Perché a qualcuno a un certo punto è venuta la brillante idea di utilizzare degli Switch Ethernet per costruire delle vere e proprie reti, chiamate per l'appunto reti Switched Ethernet, che sono normalissime reti dove i nodi sono costituiti da Switch Ethernet, interconnessi tra loro con collegamenti Ethernet punto-punto. Proprio a causa del meccanismo del flooding, si possono verificare facilmente dei loop e dei broadcast storm, che possono mettere in ginocchio in pochi secondi anche reti di grandi dimensioni. 

Ed è a questo punto che entra in gioco Radia Perlman e il suo Spanning Tree Protocol (STP) ...

IL PROTOCOLLO STP
Tra le prime cose che un bravo Networker impara agli inizi della sua carriera, vi è sicuramente il protocollo STP e tutte le innumerevoli varianti. Non è lo scopo di questo post ricordare come funziona, la letteratura sull'argomento è virtualmente infinita. Voglio solo mettere in evidenza a cosa serve e alcuni suoi lati "oscuri".

Il protocollo STP può essere visto come l'equivalente, nelle reti Switched Ethernet, dei protocolli di routing delle reti di Livello 3. Serve a instradare le trame Ethernet da un punto all'altro della rete, faccio notare, contravvenendo alle prerogative che il modello ISO/OSI assegna la Livello 2 (l'instradamento non fa parte di queste prerogative, come visto nella sezione precedente), evitando loop del traffico sul piano dati (bridging loop) e broadcast storm. In un certo senso, grazie al protocollo STP, le reti Switched Ethernet (che sono reti di Livello 2) hanno invaso il campo delle normali reti IP, appropriandosi delle funzioni di instradamento, in contrasto con i canoni tradizionali del modello ISO/OSI.

Il protocollo STP ha poi alcuni lati "oscuri", di cui ne ricordo quattro che riassumo brevemente:
  • Funziona mettendo in blocco alcune porte degli Switch, di fatto riducendo la banda disponibile (bisectional bandwidth). Basti pensare al caso elementare di due soli Switch, collegati con due cavi (cross !). Per evitare bridging loop, una delle due porte dello Switch non root-bridge viene posta dal protocollo STP nello stato blocking, quindi dei due collegamenti ne viene utilizzato soltanto uno, dimezzando di fatto la banda disponibile. Se in luogo dei due Switch avessimo avuto due Router, questo non sarebbe accaduto, lasciando disponibile tutta la banda. Se volete un esempio un po' più complesso, che mette ancor più in evidenza quanto sia "tafazziano" il protocollo STP, guardate le due figure seguenti, che mostrano una topologia Leaf-and-Spine con due inter-Spine link (normalmente non necessari nelle IP Fabric dei moderni Data Center). Su un totale di 18 link fisici, il protocollo STP ne blocca ben 13. A conti fatti quindi, il 72% circa della banda (e degli investimenti necessari per realizzarla) non viene utilizzata ! 




























  • I percorsi non sono ottimali. Infatti, il protocollo STP per instradare il traffico utilizza un albero con radice il root bridge; questo implica che per inviare traffico tra due Switch foglia, il traffico deve risalire una parte, se non tutto l'albero. Se ad esempio i due Switch fossero ai lati estremi dell'albero, il traffico verrebbe instradato facendo transito sul root bridge, quando quasi sicuramente esistono percorsi più diretti, ma non utilizzabili a causa del blocco delle porte.
  • Il protocollo non prevede funzionalità di Load Balancing (ovvio, considerato il punto precedente). Per questo, per distribuire il traffico più equamente sui vari link sono state sviluppate alcune varianti del protocollo come PVST/PVST+ (Per VLAN STP), MSTP (Multiple STP), ecc. .
  • I tempi di convergenza lasciano un po' a desiderare. Anche la versione RSTP (Rapid STP) non riesce a raggiungere, se non in casi particolari, la velocità di convergenza di un protocollo di routing ben configurato. 
Morale della favola, il protocollo STP, necessario per evitare bridging loop e broadcast storm, ha varie lacune che lo rendono molto meno efficiente di un classico protocollo di routing tradizionale.

A questo punto è lecito chiedersi: perché sono nate le reti Switched Ethernet ? Non sarebbe stato meglio lasciare il compito di instradare il traffico alla sua sede naturale, ossia al Livello 3 ? E' quello che mi sono sempre chiesto, ma qualcuno a suo tempo ha preferito una strada diversa, sviluppare un protocollo per risolvere un problema che non sarebbe mai dovuto esistere, e questo ha cambiato la storia del Networking degli ultimi 30 anni, ... e non necessariamente in meglio.

"STP IS DEAD, LONG LIFE TO STP"
Ad un certo punto, molti Networker si sono resi che il protocollo STP aveva molti difetti, e che era da eliminare quanto prima dalle reti. La stessa Radia Perlman è stata costretta a riconoscerlo e ha avuto una sorta di pentimento, che ha reso pubblico in un video che mostrerò nella seconda parte di questo post. E così sono state sviluppate molte funzionalità che ne rendono superfluo l'utilizzo. Solo per citarne alcune:
  • LAG (Link Aggregation Group), anche nota come EtherChannel, Port Channel, Link Bonding, ecc. : è una funzionalità ben nota che consente di aggregare due o più link tra due Switch e farli apparire agli Switch come un unico link virtuale, la cui banda complessiva è la somma delle bande dei singoli link.
  • MC-LAG (Multi Chassis Link Aggregation Group), nel linguaggio Cisco nota come vPC (virtual Port Channel); qualcuno utilizza il semplice acronimo MLAG : è una estensione della funzionalità LAG che consente a un dispositivo (Host, Switch) dual-homed a due Switch, di vedere i due Switch come un unico Switch virtuale e i due link aggregati in LAG (vedi figura seguente).














  • L2MP (Layer 2 MultiPath) : architettura tipicamente utilizzata in ambito Data Center, che sostituisce il protocollo STP con un piano di controllo basato su protocolli concettualmente simili ai classici protocolli di routing. Sono stati sviluppati a questo proposito due protocolli alternativi, che hanno però avuto scarso successo:
    • TRILL (TRansparent Interconnection of Lots of Links): è un protocollo basato su IS-IS, che è divenuto standard IETF, che ha dedicato all’argomento varie RFC. TRILL è stato (ed è) utilizzato, in realtà in modo un po’ personalizzato, da Cisco con la sua funzionalità FabricPath e da Brocade VCS (Virtual Cluster Switching). Entrambe queste implementazioni sono però incompatibili con la versione standard di TRILL. Altri vendor che hanno prodotti basati su TRILL sono HP (switch serie 5700, 5900, 5920, 5930, 7900, 11900, 12500, 12900), Huawei (switch Cloud Engine 5800, 6800, 7800, and 12800), Enterasys / Extreme Networks (switch della serie S).
    • SPB (Shortest Path Bridging): è un protocollo anche questo basato su IS-IS, standardizzato in ambito IEEE (IEEE 802.1aq). Ha due versioni leggermente differenti: SPBM basata sul concetto di MAC-in-MAC e SPBV che riutilizza i VLAN tagSPB è fortemente supportato da Avaya e Alcatel-Lucent. Rispetto a TRILL si è dimostrato più interoperabile, ma in fin dei conti, come TRILL, non ha avuto grande successo.
In conclusione, il protocollo STP è giunto finalmente al capolinea, anche se è ancora ampiamente utilizzato in reti in produzione e quindi ce lo dovremo sopportare ancora a lungo (non io però, perché solo a sentirne parlare mi fa venire l'orticaria !!!). Nei Data Center è per fortuna ormai veramente scomparso (messaggio a chi ancora lo utilizza: migrate il più presto possibile a IP Fabric, altrimenti siete dal lato sbagliato della storia ...).

E qui concludo questa prima parte del post. Arrivederci alla prossima, dove approfondirò alcune differenze tra routing e bridging

Nessun commento:

Posta un commento