Skip to main content

Go on, blame the network!

| Carmine Piccolo, Mario Maiorino | Osservatorio della rete

Articolo letto 249 volte

Sviluppo di un’infrastruttura scalabile, sicura e resiliente per il futuro delle rete dell’Università Federico II di Napoli

“Go on, blame the network!”. Comunque vada, è sempre colpa della rete! Negli ultimi anni, è divenuto un mantra che accompagna i direttori tecnici delle aree reti del CSI (Centro di Ateneo per i Servizi Informativi) dell’Università degli Studi di Napoli Federico II. In accordo con la richiesta del management dell’Ateneo di avere, nell’anno dell’ottocentesimo anniversario della prima università laica in Europa, una rete che, confrontandosi con gli attuali e futuri bisogni, potesse ritenersi stabile, robusta e scalabile, ci siamo interrogati su quali interventi infrastrutturali e logici potessero migliorare e far evolvere la rete dell’università.

La rete di ateneo in numeri

Il progetto evolutivo ha avuto una durata di tre anni. La prima fase prevedeva la migrazione dell’anello metropolitano di ateneo (con collegamenti P2P su dark fibre e una banda massima di 10 Gbps) verso un’infrastruttura incentrata su tecnologia DWDM. La nuova infrastruttura doveva essere scalabile in modo da permettere di ampliarne la capacità con successivi interventi, rendendo così il progetto economicamente più sostenibile nel tempo.

La rete della Federico II, definita durante il workshop GARR come “rete universitaria regionale” copre, al netto della provincia sannita, punti in tutta la regione campana collezionando numeri da medio service provider come i 75.000 punti rete, i 25.000 utenti giornalieri o una media di 2 milioni di sessioni al secondo negli orari d’ufficio.

L’impronta della nuova infrastruttura DWDM è basata su 5 PoP (Point of Presence) situati nell’area metropolitana a cui afferiscono, collegate in dark fibre, tutte le sedi dell’ateneo. Negli step successivi, si è puntato ad ampliare la banda arrivando ad una capacità di 200 Gbps complessivi di cui 100 dedicati all’infrastruttura dell’anello metropolitano e i rimanenti 100 dedicati ai collegamenti client dell’utenza “tributaria”.

La nuova infrastruttura, definita in un case study su contesto europeo come “The biggest Campus Lan and DWDM of the EU”, oltre ad assicurare la realizzazione su via protetta dei link primari garantendo la completa trasparenza per l’utenza finale, anche in caso di possibili tagli fibra, permette inoltre un’immediata gestione dei guasti mediante gli strumenti di misura integrati nel sistema delle tratte in dark fibre, capaci di inviare segnalazioni in tempo reale.

L’anello WDM dell’Università Federico II di Napoli

L’anello WDM dell’Università Federico II di Napoli

Ulteriori peculiarità sono la possibilità di realizzare circuiti on demand da dedicare alle nuove utenze, riprogrammando i circuiti, come successo in occasione dello spostamento della sede napoletana del CINECA e non ultima la possibilità che la soluzione scali ulteriormente fino ad una banda di 400 Gbps per singolo ramo in vista di evoluzioni future.

In ultima analisi, la struttura originaria ad anello è stata “sporcata” attraverso l’introduzione di un link diretto nord-sud tra i due PoP principali di Monte Sant’Angelo e della sede storica al fine di aumentare l’efficienza e la ridondanza nell’utilizzo della rete da parte dell’utenza dell’ateneo.

Il passaggio da una topologia routed legacy a una spine-leaf elimina un livello di rete e permette di aumentare la velocità della rete di circa un 30%

Accanto ad una infrastruttura di rete che evolve in capacità e prestazioni, non poteva non essere rivista l’intera concezione di cybersecurity a supporto della rete e dei sistemi di ateneo. Le sfide a cui si intendeva rispondere erano sostanzialmente tre: aumento della visibilità, della capacità di controllo e della segregazione del traffico di rete da e verso Internet ma soprattutto, vista la vastità della rete, anche quello interno all’ateneo stesso.

Dopo una prima fase di analisi e pianificazione, in cui sono stati evidenziati i principali punti di debolezza e sofferenza dell’architettura legacy, si è deciso di passare da un modello routed a un modello spine-leaf che prevede la presenza di una coppia di firewall in ogni PoP, adatti a gestire il traffico generato dallo specifico nodo, su cui terminare tutto il traffico di rete e gestire l’inter-vlan routing. Il funzionamento nativo del firewall in questa configurazione, per definizione, limita fortemente gli attacchi laterali oltre a protegge da quelli esterni.

Come completamento logico del progetto, l’intera rete si aggrega, per accedere ad Internet, su uno stretched cluster geografico, i cui nodi sono situati presso MSA e Centro storico, sede rispettivamente del PoP GARR di Monte S. Angelo (NA1) e PoP GARR di Monte di Dio (NA2). Entrambi i nodi del cluster gestiscono due VDOM (Virtual Domain), uno attivo e relativo all’area di competenza e l’altro dormiente per l’atra zona. I due nodi sono sincronizzati tra loro attraverso un link DWDM metropolitano layer2 in via protetta.

Il modello spine-leaf della rete dell’Università Federico II di Napoli

Il modello “spine-leaf” della rete dell’Università Federico II di Napoli

Questa configurazione offre un effettivo sistema di disaster recovey caratterizzato da un automatismo indirizzato a garantire la business continuity delle attività dell’ateneo anche sfruttando il doppio link di uscita (primario e backup) verso il PoP GARR di Monte S. Angelo e quello verso il PoP GARR di Monte di Dio. In caso di fault di un uno dei due nodi, il sistema convoglia automaticamente il funzionamento della rete, spostando il layer2 sul nodo che resta attivo, con un tempo di convergenza che è annoverabile nell’ordine di qualche decina di secondi (tempo legato al refresh delle ARP table) quasi impercettibile per l’utenza.

Il passaggio da una topologia routed legacy a una spine-leaf elimina un livello di rete e permette di aumentare la velocità della rete di circa un 30%. L’utilizzo di Next Generation Firewall su tutti i PoP, oltre ad aggiungere la capacità di operare analisi sul traffico da e verso la rete metropolitana, fino al livello 7 dello stack protocollare, ha permesso di implementare un secondo livello di sicurezza all’interno della rete di ateneo. La possibilità di gestire, controllare e ispezionare, su ogni PoP sia la connettività verso l’anello metropolitano che quella intra-nodo, permette una maggior profondità e precisione nell’isolare le minacce informatiche direttamente sul nascere e nel punto più prossimo alla generazione del traffico.

In termini di controllo, l’uso di analizzatori del traffico di rete dedicati ed una infrastruttura SIEM, ha offerto la possibilità di analizzare, e filtrare, l’enorme quantità di traffico internet/intranet generato e ottenere visibilità sulla postura di sicurezza dell’intera rete di Ateneo e dei suoi utenti.

Il completamento del progetto triennale ha certamente restituito all’ateneo federiciano una rete con una banda disponibile aumentata di un ordine di grandezza, stabile e ridondata in ogni sua componente e con una elevata capacità di gestione dei guasti. Da un punto di vista della cyber security la rete presenta due livelli di sicurezza (front-end e back-end) ed una gestione dell’accesso alla rete GARR attraverso un cluster geografico di firewall che permette di applicare meccanismi di business continuity all’intera infrastruttura di rete. Questo tipo di infrastruttura, per quanto detto, consente di applicare i controlli di sicurezza, di filtraggio e di protezione nel punto più vicino all’utenza e, allo stesso tempo ottimizza il carico, distribuendo in più punti il lavoro necessario ad ispezionare il traffico generato dalle decine di migliaia di utenti che quotidianamente frequentano i vari campus e sedi dell’ateneo.

Ti è piaciuto questo articolo? Faccelo sapere!
Dai un voto da 1 a 5, ne terremo conto per scrivere i prossimi articoli.

Voto attuale:

L'evoluzione della Rete FED2 - C.Piccolo, M.Maiorino - Workshop GARR 2024

Ultimi articoli in rubrica