Architetture di rete per edifici e campus: core, distribution, access e criteri di scalabilità

Mar 11, 2026 | Networking (Rete Dati), Architetture di rete (building e campus)

Progettare una rete per un edificio o per un campus significa costruire l’infrastruttura che dovrà sostenere utenti, server, Wi-Fi, fonia IP, videosorveglianza, controllo accessi, sistemi IoT, apparati di building e servizi digitali nel loro insieme. In questo contesto la parola “campus” non indica soltanto grandi complessi universitari o direzionali: nelle guide tecniche ufficiali di Cisco il campus LAN può andare da un sito molto piccolo con un solo switch fino a una struttura multi-building distribuita, mentre HPE Aruba distingue chiaramente tra architetture a due livelli e a tre livelli in base a scala, cablaggi, punti di aggregazione e crescita prevista.

L’errore più frequente è partire dagli apparati invece che dall’architettura. Una rete ben progettata nasce prima dalla lettura del contesto reale: quanti armadi di piano esistono, dove convergono le dorsali, quanta fibra è disponibile tra i building, quanti utenti e dispositivi devono essere serviti, quale continuità operativa è richiesta, quali servizi devono rimanere attivi anche durante un guasto, quanta crescita è ragionevole attendersi nei prossimi anni. Le guide campus più serie insistono proprio su questo punto: non esiste un modello unico valido per tutti, perché topologia, disponibilità, compliance, capacità e tolleranza al rischio cambiano da sito a sito.

Per tenere insieme complessità, crescita e affidabilità, il riferimento classico resta il modello gerarchico a livelli. Cisco continua a descrivere il campus secondo la logica access, distribution e core, mentre HPE Aruba parla di access, aggregation e core, con la stessa sostanza architetturale: un bordo dove si connettono utenti e dispositivi, un livello di aggregazione e controllo, e una dorsale centrale che unisce i blocchi dell’infrastruttura. Questo schema non è un vezzo teorico; serve a distribuire funzioni, isolare i guasti, semplificare le modifiche e impedire che l’intera rete diventi un unico dominio difficile da far crescere e ancora più difficile da mantenere.

Il livello di accesso è il punto in cui la rete incontra il mondo reale. Qui arrivano PC, telefoni IP, access point, telecamere, lettori di badge, sensori e apparati di campo. È il livello che assorbe la densità delle porte, il PoE, le esigenze di edge security, l’onboarding dei dispositivi e la varietà operativa degli ambienti. Nella documentazione Cisco sull’architettura secure campus, l’access layer è descritto come il punto in cui utenti e dispositivi si collegano alla rete aziendale e in cui cominciano anche le prime funzioni di identificazione, enforcement e visibilità. Questo significa che il bordo non va trattato come una semplice distribuzione di porte, ma come la zona in cui l’architettura incontra i requisiti concreti del sito.

Il livello di distribution, o aggregation, è il vero punto di controllo del campus. È qui che la rete raccoglie gli switch di accesso, separa i domini di traffico, applica policy, stabilisce i confini tra accesso e backbone, gestisce il routing verso il resto dell’infrastruttura e crea un punto ordinato di demarcazione tecnica. Cisco attribuisce al distribution layer il ruolo di boundary di policy e di summarization del control plane, mentre HPE Aruba lo colloca come livello di aggregazione nei campus a tre livelli, soprattutto quando la crescita rende insufficiente un collapsed core. In termini progettuali, significa che molte decisioni decisive — segmentazione, instradamento, ridondanza locale, servizi di building block — devono vivere qui, non disperdersi in modo casuale nell’intera rete.

Il core, al contrario, deve rimanere semplice. È un punto che spesso viene tradito nei progetti mediocri, dove il core diventa un luogo in cui si accumulano servizi, eccezioni, connessioni utente e logiche nate altrove. La documentazione Cisco è molto netta: il core è la parte più semplice ma più critica del campus, deve offrire un insieme limitato di servizi, lavorare in modalità altamente disponibile, evitare policy complesse e non ospitare connessioni dirette di utenti o server. Il suo compito è unire i blocchi del campus e fornire backbone connectivity con ridondanza adeguata, tempi di recupero rapidi e possibilità di manutenzione senza interrompere le applicazioni. Questa semplicità non è riduzione funzionale; è disciplina architetturale.

Da qui nasce la prima grande decisione progettuale: due livelli o tre livelli. L’architettura a due livelli, spesso chiamata collapsed core, unisce di fatto core e distribution nello stesso blocco ridondato. HPE Aruba la considera adatta a edifici piccoli o medi con pochi wiring closet, oppure a contesti in cui la fibra di tutti gli armadi converge in un unico punto. In questa logica gli switch di accesso si collegano a una coppia centrale ridondata che eroga servizi Layer 2 e Layer 3. Quando il sito è compatto, i punti di aggregazione sono pochi e la crescita è contenuta, il modello a due livelli può offrire buona resilienza e minore complessità.

L’architettura a tre livelli diventa invece la scelta corretta quando la rete cresce in numero di utenti, edifici, punti di aggregazione e traffico inter-building. HPE Aruba la raccomanda per reti grandi con migliaia di utenti o quando il layout fisico non si presta a un two-tier; Cisco spiega che una core layer separata riduce la complessità complessiva, migliora fault isolation e rende più efficace la scalabilità del campus man mano che aumentano i distribution block e la distanza geografica tra le aree. In altre parole, il terzo livello non serve a “fare più enterprise” sulla carta: serve quando l’infrastruttura ha smesso di essere un unico edificio semplice e ha bisogno di un backbone vero.

Un altro nodo progettuale riguarda il confine tra Layer 2 e Layer 3. Le architetture campus moderne convivono ancora con accessi Layer 2 tradizionali, ma i vendor principali spingono sempre di più verso uplink ridondati e routed, soprattutto dove si cerca maggiore resilienza dell’underlay. Aruba indica esplicitamente i redundant, routed links come configurazione preferita tra switch e osserva che le organizzazioni orientate a topologie overlay dovrebbero muoversi verso Layer 3 access con routing portato all’edge. Cisco, nel descrivere l’access-distribution block, distingue fra modelli multi-tier tradizionali, routed access e virtual switch, sottolineando che la stessa topologia fisica può cambiare molto a seconda di dove si collocano i confini Layer 2 e Layer 3. La decisione, quindi, non va presa per moda: va presa in funzione di fault domain, mobilità dei servizi, semplicità operativa e strategia di crescita.

Quando si progetta un edificio singolo, la tentazione di mantenere una rete molto piatta è forte. Si vedono ancora troppi siti con VLAN estese senza criterio, trunk che attraversano aree che non dovrebbero condividere lo stesso dominio Layer 2, gateway messi dove capita, policy distribuite in modo incoerente, e uplink dimensionati più per convenienza iniziale che per carichi reali. Il problema di queste scelte è che funzionano finché il sito rimane piccolo, statico e tollerante al disordine. Appena arrivano nuove aree, access point più esigenti, videosorveglianza diffusa, segmentazione guest/IoT, collegamenti tra edifici o richieste di disponibilità più alta, la rete comincia a costare in cambiamento, non solo in apparati. Le architetture modulari servono proprio a evitare che ogni nuova esigenza obblighi a ridiscutere tutta la rete.

La modularità è infatti uno dei concetti più utili da recuperare. Cisco la descrive come un principio strutturale che permette isolamento dei guasti, aggiornamenti più controllati e sostituzione ordinata dei blocchi quando un modulo non offre più capacità o funzioni sufficienti. Questo è decisivo nei campus dove la rete non serve solo utenti office, ma anche Wi-Fi ad alta densità, sicurezza fisica, building systems, server locali, edge compute e interconnessioni verso data center o WAN. In un’architettura modulare ogni blocco ha un ruolo chiaro e il resto dell’infrastruttura non deve conoscere ogni dettaglio interno di quel blocco per continuare a funzionare correttamente.

Anche la capacità va letta correttamente. Scalabilità non significa soltanto “aggiungere porte”; significa evitare che il numero di interconnessioni, le dipendenze tra i livelli e il traffico est-ovest interno facciano esplodere la complessità. Cisco mostra chiaramente che l’aggiunta di un core separato riduce la complessità delle interconnessioni e rende più ordinata la crescita, mentre Aruba collega il passaggio al three-tier proprio all’aumento dei building aggregation point e del traffico cross-campus. Questo porta a una regola pratica molto utile: quando la crescita della rete comincia a moltiplicare eccezioni, tronchi speciali, patch logiche, domini estesi e dipendenze incrociate, il problema non è più l’apparato che manca, ma l’architettura che va riallineata.

Una buona architettura campus deve poi tenere insieme rete cablata, wireless e servizi. Cisco nelle sue guide più recenti tratta il campus come fondazione wired e wireless insieme, non come due mondi separati. Questo è un punto molto importante anche nei progetti di edificio: gli access point non sono un “di più” appeso alla LAN, ma un elemento che influenza densità di porte, budget PoE, uplink, segmentazione, autenticazione, policy e servizi di sicurezza. Lo stesso vale per telecamere, controllo accessi, dispositivi IoT e sistemi di supervisione. L’architettura di rete funziona davvero quando viene letta come tessuto comune di tutti questi sistemi, non come semplice supporto dati per gli utenti office.

Per questo, nella progettazione reale, i criteri decisivi sono meno “commerciali” di quanto sembri. Conta dove mettere i confini tra i livelli. Conta se il core debba essere collassato o separato. Conta quanta ridondanza serva davvero e in quali punti. Conta la scelta di accesso Layer 2 o Layer 3. Conta la collocazione di gateway, policy e servizi. Conta la qualità della dorsale ottica tra building e tra armadi. Conta la capacità di documentare il disegno in modo leggibile, perché una rete che esiste solo nella testa di chi l’ha messa in piedi è già una rete fragile.

Il risultato cercato non è una rete “ricca di funzionalità”, ma una rete ordinata. Ordinata nei ruoli, nei percorsi, nei domini di traffico, nei margini di crescita, nei punti di aggregazione, nelle responsabilità operative. È questa ordinarietà che rende una rete di edificio o campus davvero scalabile: non la possibilità astratta di aggiungere apparati, ma la capacità di crescere senza perdere leggibilità, senza moltiplicare il rischio e senza trasformare ogni espansione in una correzione strutturale. Le architetture core, distribution e access continuano a restare attuali proprio per questo: danno una forma stabile alla crescita.

Chi progetta una rete campus con serietà, quindi, non parte dal numero di switch né dal marchio, ma dal rapporto tra edificio, utenti, servizi, dorsali, livelli di disponibilità e traiettoria di sviluppo. Il compito dell’architettura è trasformare tutto questo in un impianto tecnico che resti chiaro oggi e sostenibile domani. Quando questa trasformazione è fatta bene, la rete smette di essere un insieme di apparati collegati tra loro e diventa davvero infrastruttura.

Link interni in approfondimento: