Nell'era del cloud, qualcuno mi ha chiesto di recente perché continuo a usare il CCIE nella mia firma professionale. La risposta non è nostalgia: è che quando AWS cade, quando una migrazione ad Azure si blocca, quando una VPN IPsec tra due sedi non si alza, l'unico ingegnere che si presenta e lo risolve è quello che ha imparato a ventidue anni come si negozia un'adiacenza OSPF con un'interfaccia Frame Relay rotta. In questo articolo ti racconto tre aneddoti reali e perché il CCIE conta ancora nel 2026.
Ho iniziato con le reti a vent'anni. Mi sono certificato CCNA il primo anno, CCNP il secondo, e CCIE al quarto tentativo dopo un anno e mezzo di laboratorio casalingo con venti router di seconda mano in garage. Il CCIE di quell'epoca — il R&S di prima dell'era cloud — era un esame pratico di otto ore in un laboratorio reale dove ti davano un design di rete impossibile e dovevi farlo funzionare senza documentazione ufficiale. Il tasso di approvazione al primo tentativo era intorno al 4%. Oggi l'esame è diverso ma lo spirito è lo stesso: non si tratta di saper configurare, si tratta di capire perché funziona.
Cos'è veramente un CCIE
Voglio spiegare una cosa che spesso viene fraintesa. Un CCIE non è un corso dove ti insegnano delle cose. È un esame alla fine di un processo autodidatta di anni. Nessuno ti dice cosa devi studiare. C'è una lista ufficiale di argomenti — BGP, OSPF, EIGRP, MPLS, VPN, QoS, sicurezza di rete, multicast, IPv6, MPLS-VPN, servizi, voce — e devi montarti un laboratorio casalingo per praticarli fino a saperli configurare a occhi chiusi. L'esame non ti chiede teoria. Ti dà uno scenario concreto e devi farlo funzionare.
La differenza con altre certificazioni è che non puoi passare il CCIE a memoria. Puoi memorizzare i comandi e bocciare comunque. Quello che ti fa passare l'esame è aver passato centinaia di ore a debuggare lab in garage, aver trovato i bug strani, aver imparato a leggere un output show di quattrocento righe e individuare il problema in dieci secondi. Quella capacità è impossibile da simulare. Per questo il CCIE aveva — e continua ad avere — un prestigio particolare nel settore.
Oggi, nel 2026, molti dicono che il CCIE è obsoleto perché "tutto sta andando nel cloud" e "i router fisici stanno sparendo". Vediamo tre casi concreti in cui quell'opinione dimostra di non capire come funziona davvero un'infrastruttura moderna.
Caso 1: BGP rotto tra datacenter e AWS Direct Connect, un sabato pomeriggio
Azienda software di medie dimensioni con sede a Madrid. Infrastruttura ibrida: datacenter proprio a Madrid (database e sistemi legacy) e una VPC in AWS Ireland (nuovi microservizi). I due ambienti sono connessi via Direct Connect con BGP in mezzo. L'SLA con AWS dice 99,9% di disponibilità.
Un sabato pomeriggio di agosto, alle 17:30, il link Direct Connect inizia a perdere pacchetti in modo intermittente. Non cade del tutto — il traffico continua a passare — ma la latenza sale dai 15 ms abituali a picchi di 400 ms, e alcune sessioni TCP si rompono. Gli ingegneri di AWS aprono un caso di supporto e rispondono come sempre: "dal nostro lato non vediamo problemi, controllate il vostro dispositivo locale". Il dispositivo locale è un router Cisco ASR 1001-X gestito dall'azienda con supervisione remota.
Il direttore delle operazioni mi ha chiamato alle 18:15. Mi ha raccontato la situazione. Io ero a Alicante, il router era a Madrid. Nessuno sul posto. Ho chiesto accesso remoto via VPN e console seriale del router. Cinque minuti dopo ero dentro.
La prima cosa che ho guardato non è stato BGP. È stata la tabella degli errori di interfaccia sulla porta di uplink ad AWS. L'output è stato rivelatore: alcuni CRC errors e parecchi input errors che prima non c'erano. Non erano molti — circa 200 al minuto — ma sufficienti per rompere sessioni TCP ad alto throughput. Ipotesi immediata: qualcosa nel livello fisico sta iniziando a cedere. Il problema era che AWS sosteneva che dal loro lato era tutto a posto.
Poi ho guardato il BGP. La sessione era "Established" e i prefissi venivano annunciati correttamente. Ma guardando i contatori BGP, ho visto qualcosa di strano: il numero di "BGP updates received" da AWS stava crescendo molto più rapidamente del normale. Circa cinque volte più update al minuto rispetto alla media storica. Questo significava che AWS stava riannunciando i prefissi costantemente. Qualcosa dal loro lato della rete stava causando flapping di rotte.
In quel momento ho capito il pattern. Il problema non era mio né chiaramente di AWS — era un link fisico condiviso tra le due reti (il Direct Connect passa per la rete del provider locale, in questo caso un terzo operatore di trasporto ottico) che stava iniziando a cedere al livello 1. Gli errori CRC che vedevo sul mio router erano conseguenza di problemi fisici a monte. E i massicci BGP updates da AWS erano la reazione del loro sistema all'instabilità di quello stesso link.
Ho chiamato il supporto AWS. Ho chiesto loro specificamente di controllare i contatori di errori del livello fisico dal loro lato del Direct Connect. Dieci minuti dopo hanno confermato quello che vedevo io: errori CRC in crescita. Il problema è stato escalato all'operatore ottico, che ha identificato uno splice di fibra degradato in una scatola di giunzione in qualche punto tra Madrid e Dublino. L'hanno riparato quella notte.
Totale dell'incidente: tre ore di finestra parziale, senza perdita completa di servizio, e una diagnosi precisa che ha permesso di escalare direttamente al vero responsabile invece di perdere giorni con il supporto che gioca al ping-pong. L'azienda mi ha pagato una tariffa di intervento urgente di fine settimana. A buon mercato rispetto al costo di otto o dodici ore di servizio fuori uso.
La domanda è: si sarebbe potuto diagnosticare tutto questo senza capire BGP a fondo, senza saper leggere una tabella di contatori di interfaccia, senza avere l'intuito per sapere cosa cercare quando il supporto del provider non trova niente? Io credo di no. O almeno, non in tre ore.
Caso 2: MPLS intermittente che nessuno riusciva a diagnosticare
Multinazionale italiana con sedi a Milano, Roma, Torino e Catania. Tra le quattro sedi avevano una VPN MPLS contratta con uno dei grandi operatori italiani. Il servizio funzionava bene la maggior parte del tempo, ma ogni tot settimane — imprevedibile, senza pattern apparente — la sede di Catania perdeva connettività con le altre tre per quindici o venti minuti. Non si disconnetteva formalmente. Aveva semplicemente una perdita di pacchetti del 30-40% durante quel periodo e poi tornava alla normalità.
L'operatore italiano ha controllato la connessione varie volte. "Noi non vediamo nessun problema sulla nostra rete". I tecnici della multinazionale, che erano bravi ma non specialisti di operatori MPLS, hanno cambiato router locali, cavi, configurazione QoS. Niente. Il problema persisteva.
Mi hanno contattato tramite segnalazione. Sono andato a Milano, mi sono seduto con il team di rete e ho chiesto loro una cosa: catture continue di traffico sui router CE delle quattro sedi, registrando ogni dieci minuti i contatori di errori, TTL, pacchetti scartati e tasso di perdita. Quella che l'operatore italiano chiama la sua "rete privata" è in realtà un pezzo di Internet condivisa con routing MPLS sopra, e quando ci sono problemi sulla backbone, la perdita si manifesta asimmetricamente.
Due settimane dopo — quando il problema è riapparso — i contatori che avevo preparato hanno raccontato tutta la storia. Durante l'incidente, i pacchetti che partivano da Catania verso Milano uscivano con TTL 254 (normale) ma arrivavano a Milano con TTL 242. Significa che passavano per dodici router invece dei soliti quattro o cinque. Erano stati reinstradati per un percorso più lungo, probabilmente perché l'operatore aveva perso un link principale dell'MPLS e il backup IGP della sua rete passava per un percorso congestionato. Quella congestione non era sul percorso normale, quindi i tecnici dell'operatore, che guardavano i link attraverso i quali il traffico "doveva" passare, non vedevano niente di strano. Ma i pacchetti andavano da un'altra parte.
Con quella evidenza concreta — TTL anomalo, tassi di perdita correlati, orari coincidenti con le finestre di manutenzione interne dell'operatore — ho segnalato il caso direttamente al NOC dell'operatore con dati irrefutabili. Hanno ammesso il problema. Era una politica di re-routing che attivavano nei fine settimana durante le finestre di manutenzione e che causava quel sovraccarico. Hanno aggiustato la politica. Il problema è sparito.
La diagnosi tecnica qui non era complicata. Era questione di sapere cosa guardare. Il TTL dei pacchetti MPLS non è qualcosa che un operatore junior controlla. Ma per chi ha fatto lab di MPLS per anni e capisce come funzionano le reti sotto, è il primo indizio quando c'è una perdita asimmetrica inspiegabile.
Caso 3: migrazione di telefonia VoIP con 450 interni, senza downtime
Azienda di call center con sede a Alicante, 450 dipendenti, telefonia IP basata su un'infrastruttura Cisco Unified Communications Manager di sette anni. Il CEO ha deciso di migrare a una piattaforma moderna basata su 3CX per ridurre i costi. Il fornitore di 3CX offriva una migrazione chiavi in mano, ma con l'avviso che ci sarebbe stata una "finestra di cutover necessaria" di 4-6 ore durante la notte. Per un'azienda che opera 24 ore su 24 servendo clienti in tre fusi orari, questo non era accettabile.
Mi hanno assunto per progettare una migrazione senza downtime. La sfida tecnica era: spostare 450 interni da CUCM a 3CX, mantenendo i numeri di selezione interni, i gruppi di chiamata, le politiche di instradamento esterno e la capacità per un agente di fare una chiamata in qualsiasi momento durante la migrazione.
Il piano che ho progettato aveva quattro fasi:
- Fase 1 — Provisioning parallelo: nella settimana precedente, ho configurato il sistema 3CX con replica esatta di tutti gli interni, gruppi e politiche. Ogni agente avrebbe un nuovo account su 3CX ma nessuno l'avrebbe ancora usato.
- Fase 2 — Trunk doppio: ho negoziato con l'operatore SIP un periodo di 72 ore in cui i numeri esterni dell'azienda arrivassero contemporaneamente a entrambi i sistemi. Durante quelle 72 ore, i due sistemi avrebbero ricevuto le chiamate ma solo uno le avrebbe risposte secondo una logica di instradamento che io controllavo da un piccolo router di bordo personalizzato (una Raspberry Pi con Asterisk come SIP proxy).
- Fase 3 — Migrazione per gruppi: ho spostato gli agenti in blocchi di 20, durante la giornata lavorativa, senza interrompere il loro servizio. Ogni gruppo riceveva il nuovo telefono IP preconfigurato, la Raspberry rilevava automaticamente quale gruppo era cambiato, e da quel momento le chiamate per quegli agenti venivano instradate al nuovo 3CX. Gli agenti hanno continuato a rispondere alle chiamate durante il processo.
- Fase 4 — Spegnimento del vecchio CUCM: una volta migrati tutti i gruppi (sette giorni dopo l'inizio), ho spento il vecchio CUCM e ho reindirizzato tutto il traffico rimanente al 3CX. La finestra reale di downtime è stata di zero minuti.
Il trucco tecnico del progetto è stato il SIP proxy personalizzato, che ho scritto io stesso in Python su una Raspberry Pi 4. Quel proxy decideva in tempo reale, chiamata per chiamata, a quale sistema inviarla in base al range di interni che era stato migrato in quel momento. Costo dell'hardware: 120 €. Tempo di sviluppo dello script: due giorni. Valore per il cliente: quattro ore di downtime evitate nella notte più sensibile dell'anno (fine mese fiscale).
La differenza tra saper configurare e capire perché
I tre casi precedenti hanno qualcosa in comune: la diagnosi o la soluzione non erano in nessun manuale. Non c'era un documento ufficiale dove cercare "cosa fare quando il TTL MPLS scende in modo inaspettato" o "come migrare CUCM a 3CX senza downtime". La soluzione si costruiva applicando conoscenza fondamentale — di come funziona BGP sotto, di come si comporta MPLS in condizioni reali, di come negoziano le sessioni SIP — a un problema concreto.
È esattamente quello che insegna il CCIE. Non tecniche di configurazione (che cambiano ogni due anni e si possono imparare su YouTube), ma intuito strutturale. Come leggere la tabella di routing di un router e capire cosa succederà a un pacchetto specifico. Come sapere in quale momento si sta attivando il backup OSPF. Come pensare una rete da estremo a estremo quando hai quattro operatori diversi lungo il cammino.
Il cloud non elimina questi problemi. Li astrae un po', ma quando qualcosa va male, qualcuno deve capire cosa sta succedendo nel livello che il cliente non vede. Quel qualcuno è quasi sempre qualcuno con la formazione di un CCIE o equivalente, perché le altre persone — i buoni ingegneri cloud moderni — tendono ad avere una conoscenza profonda della loro piattaforma specifica ma poca visibilità su quello che succede fuori di essa. E i problemi che contano in un'infrastruttura aziendale succedono tra le piattaforme, non dentro di esse.
Cosa continuerà a contare nel 2030
Se dovessi prevedere quali competenze resteranno rilevanti tra cinque anni nel settore delle reti, la mia lista sarebbe:
- Capire i protocolli fondamentali (BGP, OSPF, IPv6, MPLS, TLS) abbastanza bene da debuggarli quando falliscono, anche in ambienti cloud dove sono astratti.
- Saper leggere i pacchetti. Wireshark è ancora lo strumento più utile dell'ingegnere di rete e continuerà a esserlo. Chi sa interpretare un pcap individua problemi che nessun altro vede.
- Capire il livello fisico. Quando i cavi e le fibre cedono, i sistemi cloud non te lo dicono chiaramente. Qualcuno deve capire che una perdita di pacchetti intermittente può essere uno splice di fibra degradato.
- Saper programmare a basso livello. I moderni ingegneri di rete scrivono script per automatizzare. Ma quelli che fanno davvero la differenza sanno scrivere un proxy SIP in Python, o un piccolo plugin per Wireshark, o un programma che fa il parsing dei log BGP in tempo reale. Quel tipo di codice non si impara in un corso — si impara risolvendo problemi.
- Avere la pazienza di leggere documentazione ufficiale. Gli RFC, le note tecniche di Cisco, le specifiche IEEE. I buoni ingegneri le leggono. I mediocri si limitano a cercare su Stack Overflow.
Conclusione
Conta ancora il CCIE nel 2026? La mia risposta onesta è: il titolo conta sempre meno (pochi clienti capiscono davvero cosa significa), ma le competenze che il CCIE ti obbliga a sviluppare contano più che mai. In un mondo in cui tutti usiamo piattaforme cloud che astraggono la rete, le persone che sanno diagnosticare cosa sta succedendo sotto quell'astrazione sono sempre più rare e più preziose. E quando qualcosa di critico fallisce — quando AWS è caduto in una zona, quando BGP negozia in modo strano, quando una migrazione di telefonia minaccia di fermare un call center — sono loro a salvare la giornata.
Io non uso il CCIE in firma per fare bella figura. Lo uso perché indica che a un certo punto ho dovuto imparare cosa c'è sotto le astrazioni. E nella mia esperienza, è un segnale di qualità che pochissimi possono simulare. Se stai per assumere qualcuno per un'infrastruttura critica, o se la tua rete ha problemi che nessuno capisce, cerca qualcuno che sia passato per quella scuola — con o senza il certificato ufficiale. Un sabato pomeriggio può fare la differenza tra tre ore di downtime e tre giorni.