La segmentazione è uno dei driver progettuali principali di SD-Access: separa il traffico in domini logici indipendenti dalla topologia fisica e dall’indirizzamento IP. In ENSLD il tema non è “come si configura”, ma “quale livello di segmentazione scegliere in un determinato scenario e perché”. SD-Access lavora su due livelli complementari: la macro-segmentazione con le Virtual Network e la micro-segmentazione con gli Scalable Group Tag.
Macro-segmentazione: Virtual Network e VRF
Una Virtual Network (VN) crea un dominio di routing completamente isolato all’interno del campus fabric. Sul piano dati ogni VN è trasportata da un VXLAN Virtual Network Identifier (VNI), mentre sul piano di controllo LISP e sui fabric edge/border node la VN è istanziata come una VRF. L’isolamento è totale: due VN diverse non comunicano a livello di routing.
Il punto di design cruciale è che il traffico inter-VN deve uscire dal fabric e attraversare un punto di enforcement esterno: un firewall (scelta preferita quando serve ispezione) oppure un fusion router che esegue VRF leaking via route-target. Sull’esame, “IoT deve restare separato dai dispositivi corporate, ma un server condiviso serve entrambi” è lo scenario tipico che richiede un firewall o fusion router tra le VN.
Le VN sono lo strumento giusto per separare macro-gruppi organizzativi: Corporate, Guest, IoT, OT/building management. Sono relativamente poche e costose in termini di stato (una VRF per VN su ogni fabric node), quindi non vanno usate per distinguere ruoli fine-grained.
Micro-segmentazione: SGT e Cisco TrustSec
All’interno di una stessa VN, la separazione fine si ottiene con Cisco TrustSec e gli Scalable Group Tag (SGT). Un SGT è un identificativo a 16 bit che rappresenta un ruolo (Employee, Contractor, HVAC, Camera), non una subnet o un IP. Le policy si esprimono come SGACL in una matrice sorgente-destinazione: “Employees possono raggiungere Servers; Contractors no”. Poiché la policy è agganciata al ruolo e non all’indirizzo, resta valida indipendentemente da dove si connette l’utente e da quale IP riceve.
In SD-Access l’SGT viaggia direttamente dentro l’header VXLAN (VXLAN-GPO, Group Policy Option), quindi tag della VN (VNI) e tag del gruppo (SGT) sono trasportati insieme end-to-end nel fabric.
Il ciclo TrustSec: classification, propagation, enforcement
- Classification: al momento dell’accesso il dispositivo viene autenticato (802.1X, MAB o Web Auth) e riceve un SGT. L’assegnazione può essere dinamica (da ISE) o statica (IP-to-SGT, subnet-to-SGT).
- Propagation: il binding IP-SGT si diffonde tramite inline tagging (nell’header, hardware-dependent) oppure via SXP (SGT Exchange Protocol) su TCP quando un hop non supporta l’inline tagging.
- Enforcement: le SGACL vengono applicate sul fabric node di destinazione, oppure la policy è delegata a un firewall che consuma l’SGT.
Il ruolo di Cisco ISE
Cisco ISE è il cuore del policy plane. Svolge la classification dinamica (assegna l’SGT in base a identità, posture, profiling), ospita la matrice SGACL e la distribuisce ai network device via RADIUS/CoA. Propaga i binding IP-SGT tramite SXP e condivide il contesto con firewall e altri sistemi via pxGrid. Catalyst Center (DNA Center) è l’orchestratore che integra ISE nel fabric e spinge VN e policy sui device.
Policy-based vs segmentazione basata su subnet e ACL
| Criterio | SGT / policy-based (TrustSec) | Subnet + ACL tradizionale |
|---|---|---|
| Base della policy | Ruolo/gruppo, indipendente da IP | Indirizzo IP e subnet |
| Scalabilità | Alta: matrice N×N di gruppi | Bassa: ACL crescono con subnet/host |
| Manutenzione al cambio IP/sede | Nessuna: il ruolo segue l’utente | Riscrittura ACL |
| Dipendenza dalla topologia | Disaccoppiata | Forte (dipende dall’indirizzamento) |
| Punto di enforcement | Distribuito (fabric node) o firewall | ACL su ogni SVI/interfaccia |
La regola di design: VN per separare i domini, SGT per separare i ruoli dentro un dominio. Le ACL classiche restano appropriate solo dove non c’è supporto TrustSec o per scenari statici e semplici.
Trappole tipiche d’esame
- Serve isolamento completo tra IoT e Corporate con routing separato → Virtual Network (VRF), non SGT. Gli SGT non isolano il routing: segmentano dentro la stessa VN.
- Comunicazione tra due VN diverse → firewall o fusion router (VRF leaking). Non esiste inter-VN “nativo” nel fabric.
- Un hop non supporta l’inline tagging dell’SGT → usare SXP per propagare i binding IP-SGT; non abbandonare TrustSec.
- La policy deve seguire l’utente indipendentemente da IP/sede → SGT/SGACL, perché la policy basata su subnet si romperebbe a ogni cambio di indirizzo.
- Chi assegna dinamicamente l’SGT e ospita la SGACL matrix → Cisco ISE (non Catalyst Center, che è l’orchestratore; non il border node, che è solo enforcement/gateway).