Quali sono i nuovi scenari nella gestione delle reti informatiche? E quali invece i punti fermi?

La comunità di esperti del mondo accademico e dei centri di ricerca è costantemente attiva nella discussione e nell’elaborazione di soluzioni a vantaggio dei propri utenti, che siano singoli studenti o gruppi di ricerca internazionali. Il workshop GARR è uno degli appuntamenti annuali in cui questa comunità si incontra e si confronta di persona sui temi di maggiore attualità. Nell’edizione dello scorso ottobre a Roma, sono stati molti gli spunti che hanno riguardato il futuro della rete.

Tra questi, ha destato particolare interesse quello sulla rete IP presentato da Marco Marletta, network engineer di GARR. Lo abbiamo incontrato per sapere qualcosa in più su un modello, quello di rete a pacchetto IP/MPLS, che, nonostante i grandi cambiamenti in atto, rimane valido e continuerà probabilmente ad essere un modello di riferimento ancora per molto.

In che direzione sta andando la rete?

La naturale evoluzione delle tecnologie e la moltiplicazione delle direttrici di traffico, dovute anche all’aumento dei data centre e dei servizi in cloud, hanno portato ad un’esplosione della complessità della rete che è necessario governare in maniera differente da come abbiamo fatto in passato. Già rispetto a venti anni fa la rete GARR è profondamente cambiata. Nel 2000 la capillarità era piuttosto limitata: i PoP erano limitati a 16 poli più importanti, ora sono circa un centinaio.

Per quanto riguarda il livello IP della rete, che si sovrappone alla rete fisica, il cambiamento più grande è stato il passaggio da una topologia geografica ad una topologia gerarchica. Azione che è stata resa possibile passando da una rete basata su circuiti noleggiati da un operatore ad una rete di cui siamo proprietari delle fibre ottiche.

Puoi spiegare meglio cosa comporta questa trasformazione?

Nella topologia geografica ogni punto della rete era collegato al suo punto più vicino. In questo modo per raggiungere una destinazione era necessario attraversare ogni PoP situato lungo il percorso. In caso di guasto in un punto qualsiasi del percorso, la destinazione era tagliata fuori e, di conseguenza, tutte le altre direttrici che transitavano per quel PoP. In caso di upgrade, allo stesso modo, era necessario adeguare tutti i PoP e non soltanto quelli iniziali e finali.

Da quando si è potuto contare sulla fibra ottica di proprietà è stato possibile costruire la dorsale di rete sulla base delle direttrici di traffico secondo il reale uso. In questo modo il modello è passato ad uno schema gerarchico: un core (costituito dai nodi principali a Milano, Bologna e Roma), un secondo livello di nodi ad elevato traffico e un terzo livello con i nodi secondari. La rete così configurata ha permesso di rendere ogni PoP indipendente dagli altri e per ogni nodo avere almeno un paio di vie alternative da usare in caso di guasti. Anche gli aggiornamenti sono così ottimizzati dal punto di vista organizzativo e finanziario perché si interviene solo là dove realmente serve.

Come è possibile migliorare la rete che già esiste?

Ci siamo interrogati su quali modelli e quali tecnologie adottare e siamo partiti da alcuni requisiti. Non ci preoccupa molto la capacità della rete che oggi è ampiamente adeguata, anche se lavoriamo lo stesso per ampliarla in futuro in termini di velocità e capillarità. Quello che vogliamo fare ora è usare al massimo tutti i link a disposizione, ottimizzando il traffico seguendo le strade più scariche in ogni momento. Vorremmo aumentare la ridondanza e concentrare in maniera efficiente l’enorme numero di collegamenti che abbiamo. Uno dei nostri principali obiettivi inoltre è ridurre di molto i consumi energetici e gli spazi che occupano le macchine. Sono due elementi che hanno un impatto notevole per gli enti che ospitano un nostro punto di presenza.

Come gestire una rete che aumenta la sua complessità?

Abbiamo bisogno di nuovi strumenti per il monitoraggio (telemetria, syslog monitoring), funzionalità di traffic engineering più evolute e una maggiore automazione sia per le operazioni quotidiane che per il provisioning dei servizi e per l’upgrade di release. Per fare ciò è necessario effettuare un cambio di paradigma importante.

Come si raggiunge questo obiettivo?

Siamo ripartiti dalla base: dalla teoria della commutazione.
Lo studio delle comunicazioni telefoniche ci ha fatto ripensare a come venivano realizzate le matrici di commutazione, dove c’è sempre un’interconnessione fisica tra apparati che mettono in comunicazione un certo numero di entrate e di uscite. Realizzando topologie a più stadi si riesce a tenere sotto controllo il numero di crossconnessioni.

Il modello topologico della rete IP MPLS GARR

Noi abbiamo un vantaggio perché possiamo contare sulla commutazione a pacchetto. Ad esempio, possiamo considerare la topologia CLOS, che presenta uno stadio intermedio (chiamato spine) tra ingressi e uscite, che ci porta alcuni vantaggi come l’oversubscription ovvero un numero di uscite inferiore agli ingressi, oppure il load balancing che in condizioni normali permette di sfruttare tutti i collegamenti in maniera efficiente. In questo caso, infatti, non si avrebbe solo un link primario e un backup ma più percorsi disponibili contemporaneamente. Il vantaggio è evidente in caso di guasto visto che la rete aumenta la sua resilienza.

All’inizio, questa topologia era pensata per i data centre dove ci sono moltissimi apparati che devono parlare l’uno con l’altro. Se all’interno di un data centre ce la possiamo cavare con cavi di pochi metri, su scala geografica un link può attraversare molti apparati ed essere lungo centinaia di km e ciò ha un impatto notevole in termini di costi e di fattibilità.

Come avete introdotto questi concetti nel progetto della nuova rete IP?

Stiamo andando verso una specializzazione dell’apparato che è in grado di fare al meglio solo alcune funzioni. Nella nuova idea di rete abbiamo previsto tre tipologie di apparato: spine, leaf e edge.

Gli apparati spine realizzano lo stadio di commutazione perché hanno molte porte ad alta velocità ma non hanno bisogno di collegare gli utenti. Sono gli apparati usati nel core della rete. Gli apparati che realizzano lo stadio di ingresso della rete sono i cosiddetti leaf che consentono l’interconnessione degli utenti alla rete. Sono quelli dove inizia il servizio ed hanno tutte le funzionalità avanzate per fare questo (accounting di traffico, passive monitoring, filtering, policing, QoS, VPN, bridging, gestione delle ridondanze locali). Infine, ci sono gli apparati edge che gestiscono le interconnessioni verso l’esterno. Funzionalmente sono simili alle leaf ma necessitano di molta più memoria e di un numero maggiore di porte ad alta velocità.

Sul modello topologico viene poi calata l’architettura dei servizi (L2 da utente verso data centre, L2 da utente verso utente, L3 IP e L3VPN). Tutte le modalità di accesso per gli utenti rimarranno possibili. L’obiettivo è fare in modo che ogni utente abbia almeno un doppio collegamento ad un nodo leaf. Il modello è molto flessibile e permette tante diverse possibilità per la gestione del doppio accesso.

Quali saranno i servizi nuovi?

Tra le nuove possibilità c’è il meccanismo dell’EVPN per fare il multihoming, che può diventare addirittura all-active, ovvero si possono avere più di due link tutti contemporaneamente utilizzabili.

Un altro servizio nuovo su cui stiamo facendo sperimentazione è il Data centre Interconnect, ovvero la possibilità di collegare due data centre attraverso la rete IP. Solitamente è richiesta la connessione di tipo VXLAN, quindi la possibilità di fare Layer2 stretching su rete WAN.

Per realizzarlo abbiamo pensato a due opzioni principali. La prima è una semplicissima L3VPN sulla rete WAN e si crea un overlay attraverso il meccanismo VPN. Richiede uno sforzo del gestore del data centre, che deve realizzare da solo l’overlay mediante VXLAN end-to-end fra i data centre. La seconda alternativa è una catena (“stitching”) di collegamenti EVPN, realizzati su VXLAN nel data centre e su MPLS nella WAN. L’analisi continua e cercheremo anche di approfondire ulteriori soluzioni.

In quali altre applicazioni possono esserci vantaggi?

Penso che il modello su cui stiamo lavorando potrà avere un impatto decisivo per le reti metropolitane. Utilizzare apparati più piccoli permette di diffonderli quasi ovunque. Ad esempio, a Firenze e Venezia stiamo valutando la possibilità di sostituire gli apparati gestiti direttamente da GARR passando da L2 Ethernet a L3 con vere funzionalità di leaf. Questo ci permetterà immediatamente di evitare topologie L2 gestite con protocolli di tipo spanning-tree, e cambia profondamente l’architettura dei servizi perché potranno essere erogati direttamente sulle leaf invece che essere trasportati sul primo router disponibile. Questo meccanismo, in futuro, potrebbe essere esteso ad altre MAN non gestite direttamente da GARR.

Qual è un messaggio per gli utenti della rete GARR?

Il messaggio è in qualche modo tranquillizzante: GARR ha già pensato al prossimo collegamento degli utenti. Inoltre avremo nuove applicazioni e nuovi servizi, resi possibili dall’integrazione con strumenti di automazione, analitica e provisioning. L’affidabilità della rete è per noi un valore assoluto: la direzione che stiamo seguendo è quella di utilizzare apparati più semplici investendo sulla moltiplicazione di link e di apparati invece che sulla ridondanza del nodo. Assisteremo quindi anche ad un cambio fisico sulla rete di prossima generazione: sarà infatti più semplice e sostenibile aggiungere apparati piuttosto che prevedere grandi apparati espandibili.