Perché un design gerarchico
Il campus enterprise moderno non si progetta come una rete piatta ma per livelli funzionali con responsabilità nette. La metodologia di design Cisco Enterprise Campus organizza gli switch in tre strati — access, distribution e core — dove ogni livello espone un’interfaccia stabile verso quello adiacente. Il vantaggio non è estetico: modularità significa poter dimensionare, sostituire o replicare un blocco senza ridisegnare l’intera topologia.
I tre driver che l’esame ENSLD chiede sempre di collegare al modello gerarchico sono scalabilità, fault isolation e troubleshooting deterministico. Se un problema è confinato a un blocco (una switch block di access-distribution), il dominio di guasto resta piccolo e il percorso del traffico è prevedibile.
I tre livelli
Access layer
È il punto di attacco per endpoint: PC, IP phone, access point, telecamere. Qui si concentrano le feature edge: port security, DHCP snooping, Dynamic ARP Inspection, 802.1X per la network access control, PoE, QoS marking/trust boundary. È il livello ad alta densità di porte e basso costo per porta. Non deve fare routing di transito complesso: la sua intelligenza è di sicurezza e classificazione, non di forwarding L3 esteso.
Distribution layer
È il cuore delle policy e il punto di aggregazione. Qui vivono la summarization delle route, il filtraggio (ACL, route-map), il boundary tra L2 e L3, la ridondanza FHRP (HSRP/VRRP/GLBP) e la terminazione delle VLAN. In un design moderno il distribution è routed: si preferisce spostare il confine L3 verso l’access (routed access) oppure usare uplink L3 tra access e distribution per eliminare lo spanning-tree come meccanismo di convergenza, affidandosi invece a IGP fast convergence.
Core layer
È il backbone ad alta velocità che interconnette i distribution block, il data center block e il WAN/edge block. Il suo unico compito è switchare pacchetti il più velocemente possibile: niente ACL pesanti, niente policy, nessuna manipolazione che aumenti la latenza. Deve essere ridondato e con convergenza rapida.
| Livello | Funzione primaria | Cosa NON deve fare |
|---|---|---|
| Access | Connettività endpoint, security edge, QoS trust | Route di transito, policy complesse |
| Distribution | Aggregazione, policy, summarization, FHRP | Terminare endpoint direttamente |
| Core | Trasporto veloce inter-block | ACL/QoS complesse, terminare access |
Collapsed core (two-tier)
In sedi piccole o medie un core dedicato è sovradimensionato. Si adotta allora il collapsed core, dove le funzioni di core e distribution convivono sullo stesso apparato (tipicamente una coppia ridondata). Restano due livelli fisici: access e un livello combinato distribution/core.
Il collapsed core è indicato quando c’è un solo distribution block o pochissimi, la crescita prevista è contenuta e il budget è un vincolo. Il limite è di scalabilità: aggiungere molti distribution block su un collapsed core crea un collo di bottiglia e complica il fault isolation, perché policy e trasporto veloce condividono lo stesso piano.
Come scegliere
- Three-tier quando ci sono più distribution block (più edifici/piani, data center, WAN), traffico elevato, crescita attesa: il core separato disaccoppia i block e mantiene il forwarding pulito.
- Collapsed core per single-building/campus contenuti dove separare il core non porta valore.
La regola pratica dell’esame: il core dedicato si giustifica quando il numero di distribution block rende l’interconnessione diretta un full-mesh ingestibile (troppi link, troppi peering). Con N distribution block, un core li interconnette con collegamenti lineari invece di mesh.
Trappole tipiche d’esame
- Scenario: sede singola con un solo distribution block e budget limitato → risposta: collapsed core (two-tier). Non proporre un core dedicato: aggiunge costo senza beneficio di isolamento.
- Scenario: si aggiungono nuovi edifici/distribution block e servono percorsi prevedibili → risposta: three-tier con core dedicato. Il core disaccoppia i block ed evita il full-mesh tra distribution.
- Scenario: la domanda chiede dove applicare ACL, summarization e QoS policy → risposta: distribution layer. Il core resta “veloce e stupido”; l’access gestisce solo il trust boundary edge.
- Scenario: convergenza lenta imputata allo spanning-tree sugli uplink access-distribution → risposta: routed access / uplink L3 con IGP, eliminando STP come meccanismo di convergenza.
- Scenario: viene proposto di collegare gli switch di access direttamente al core saltando il distribution → risposta: errato. Si perde l’aggregazione delle policy e la summarization, degradando fault isolation e scalabilità.