En la era de la nube, alguien me preguntó hace poco por qué sigo usando el CCIE en mi firma profesional. La respuesta no es nostalgia: es que cuando AWS cae, cuando una migración a Azure se atasca, cuando una VPN IPsec entre dos sedes no levanta, el único ingeniero que aparece y lo arregla es el que entendió con veintidós años cómo se negocia una adyacencia OSPF con una interfaz Frame Relay rota. En este artículo te cuento tres anécdotas reales y por qué el CCIE sigue importando en 2026.
Empecé con redes con veinte años. Me certifiqué CCNA el primer año, CCNP al segundo, y CCIE en el cuarto intento después de un año y medio de laboratorio doméstico con veinte routers de segunda mano en el garaje. El CCIE de aquella época — el R&S de antes de la era cloud — era un examen práctico de ocho horas en un laboratorio real donde te ponían un diseño de red imposible y tenías que hacerlo funcionar sin documentación oficial. La tasa de aprobados en primer intento rondaba el 4%. Hoy el examen es distinto pero el espíritu es el mismo: no se trata de saber configurar, se trata de entender por qué funciona.
Qué es un CCIE realmente
Voy a explicar algo que se malinterpreta a menudo. Un CCIE no es un curso donde te enseñan cosas. Es un examen al final de un proceso autodidacta de años. Nadie te explica qué tienes que estudiar. Hay una lista oficial de objetivos — BGP, OSPF, EIGRP, MPLS, VPN, QoS, seguridad de red, multicast, IPv6, MPLS-VPN, servicios, voz — y tú tienes que montar un laboratorio casero para practicarlos hasta saber configurarlos con los ojos cerrados. El examen no te pregunta teoría. Te da un escenario concreto y tú lo tienes que hacer funcionar.
La diferencia con otras certificaciones es que no puedes aprobar el CCIE memorizando. Puedes memorizar los comandos y suspender igual. Lo que te aprueba el examen es haber pasado cientos de horas depurando labs en tu garaje, haber encontrado los bugs raros, haber aprendido a leer un show output de cuatrocientas líneas y detectar el problema en diez segundos. Esa habilidad es imposible de fingir. Por eso el CCIE tenía — y sigue teniendo — un prestigio particular en el sector.
Hoy, en 2026, mucha gente dice que el CCIE está obsoleto porque "todo se está yendo a la nube" y "los routers físicos desaparecen". Vamos a ver tres casos concretos donde esa opinión demuestra no entender cómo funciona realmente una infraestructura moderna.
Caso 1: BGP roto entre datacenter y AWS Direct Connect, un sábado por la tarde
Empresa mediana de software con sede en Madrid. Infraestructura híbrida: datacenter propio en Madrid (donde están las bases de datos y los sistemas heredados) y una VPC en AWS Ireland (donde están los nuevos microservicios). Los dos entornos están conectados vía Direct Connect con BGP de por medio. El acuerdo de niveles de servicio con AWS dice 99,9% de disponibilidad.
Un sábado por la tarde de agosto, a las 17:30, el enlace Direct Connect empieza a perder paquetes intermitentemente. No cae del todo — sigue pasando tráfico — pero la latencia sube de 15 ms habituales a picos de 400 ms, y algunas sesiones TCP se rompen. Los ingenieros de AWS abren un caso de soporte y responden lo de siempre: "desde nuestro lado no vemos problemas, revisa tu equipo local". El equipo local es un router Cisco ASR 1001-X gestionado por la empresa con supervisión remota.
El director de operaciones me llamó a las 18:15. Me contó la situación. Yo estaba en Alicante, el router estaba en Madrid. No había nadie in situ. Pedí acceso remoto vía VPN y consola serie del router. Cinco minutos después estaba dentro.
Lo primero que miré no fue el BGP. Fue la tabla de errores de interfaz en el puerto de uplink a AWS. El output fue revelador: unos cuantos CRC errors y bastantes input errors que antes no estaban. No eran muchos — unos 200 por minuto — pero eso es suficiente para romper sesiones TCP a alto throughput. La hipótesis inmediata fue: algo en la capa física está empezando a fallar. Pero el problema es que AWS afirmaba que del lado suyo todo estaba bien.
Entonces miré el BGP. La sesión estaba "Established" y los prefijos se anunciaban correctamente. Pero al revisar los contadores BGP, vi algo extraño: el número de "BGP updates received" desde AWS estaba creciendo mucho más rápido de lo normal. Aproximadamente cinco veces más updates por minuto que el promedio histórico. Eso significaba que AWS estaba reanunciando prefijos constantemente. Algo en su lado de la red estaba causando flapping de rutas.
En ese momento entendí el patrón. El problema no era ni mío ni claramente de AWS — era un enlace físico compartido entre ambas redes (el Direct Connect pasa por la red del proveedor local, en este caso un tercer operador de transporte óptico) que estaba empezando a fallar en la capa 1. Los errores CRC que yo veía en mi router eran consecuencia de problemas físicos aguas arriba. Y los BGP updates masivos desde AWS eran la reacción de su sistema a la inestabilidad de ese mismo enlace.
Llamé al soporte de AWS. Les pedí específicamente que revisaran los contadores de errores de capa física de su lado del Direct Connect. Diez minutos después confirmaron lo mismo que yo veía: errores CRC creciendo. El problema se escaló al operador óptico, que identificó un splice de fibra degradado en una caja de empalme en algún punto entre Madrid y Dublín. Lo repararon esa noche.
Total del incidente: tres horas de ventana parcial, sin pérdida de servicio completa, y un diagnóstico preciso que permitió escalar directamente al causante real en lugar de perder días con soporte jugando al ping-pong. La empresa me pagó una tarifa de intervención urgente de fin de semana. Barato si se compara con el coste de ocho o doce horas con el servicio caído.
La pregunta es: ¿se podría haber diagnosticado esto sin entender BGP a fondo, sin saber leer una tabla de contadores de interfaz, sin tener intuición sobre qué buscar cuando el soporte del proveedor no encuentra nada? Yo creo que no. O al menos, no en tres horas.
Caso 2: MPLS intermitente que nadie podía diagnosticar
Multinacional italiana con sedes en Milán, Roma, Turín y Catania. Entre las cuatro sedes tenían una VPN MPLS contratada con uno de los grandes operadores italianos. El servicio funcionaba bien la mayor parte del tiempo, pero cada cierto número de semanas — impredecible, sin patrón aparente — la sede de Catania perdía conectividad con las otras tres durante quince o veinte minutos. No se desconectaba formalmente. Simplemente pasaba a tener una pérdida de paquetes del 30-40% durante ese periodo y luego volvía a la normalidad.
El operador italiano revisó la conexión varias veces. "Nosotros no vemos ningún problema en nuestra red". Los técnicos de la multinacional, que eran buenos pero no especialistas en operadores MPLS, cambiaron routers locales, cambiaron cables, cambiaron configuración QoS. Nada. El problema persistía.
Me contactaron a través de una recomendación. Llegué a Milán, me senté con el equipo de redes y les pedí una cosa: capturas continuas de tráfico en los routers CE de las cuatro sedes, registrando cada diez minutos los contadores de errores, TTL, paquetes descartados y tasa de pérdida. Lo que el operador italiano llama su "red privada" es en realidad un pedazo de internet compartida con routing MPLS por encima, y cuando hay problemas en la backbone, la pérdida se manifiesta asimétricamente.
Dos semanas después — cuando el problema apareció otra vez — los contadores que yo había preparado contaron la historia completa. Durante el incidente, los paquetes que iban de Catania a Milán salían con TTL 254 (normal) pero llegaban a Milán con TTL 242. Eso significa que pasaban por doce routers en lugar de los cuatro o cinco habituales. Había reroutado por una ruta más larga, probablemente porque el operador había caído un enlace principal del MPLS y el backup IGP de su red se iba por un camino con congestión. Esa congestión no estaba en el path normal, así que los técnicos del operador, que miraban los enlaces por los que el tráfico "debía" ir, no veían nada raro. Pero los paquetes iban por otro lado.
Con esa evidencia concreta — TTL anómalo, tasas de pérdida correlacionadas, horario coincidente con ventanas de mantenimiento internas del operador — reporté el caso directamente al NOC del operador con datos irrefutables. Admitieron el problema. Era una política de re-routing que activaban los fines de semana durante ventanas de mantenimiento y que causaba esa sobrecarga. Ajustaron la política. El problema desapareció.
El diagnóstico técnico aquí no era complicado. Era cuestión de saber qué mirar. El TTL de los paquetes MPLS no es algo que un operador junior revise. Pero para alguien que ha hecho labs de MPLS durante años y entiende cómo funcionan las redes por debajo, es la primera pista cuando hay una pérdida asimétrica no explicable.
Caso 3: migración de telefonía VoIP con 450 extensiones, sin downtime
Empresa de call center con sede en Alicante, 450 empleados, telefonía IP basada en una infraestructura Cisco Unified Communications Manager de hace siete años. El CEO decidió migrar a una plataforma moderna basada en 3CX para reducir costes. El proveedor de 3CX ofrecía una migración llave en mano, pero con la advertencia de que habría "ventana de corte necesaria" de 4-6 horas durante la madrugada. Para una empresa que opera 24 horas atendiendo clientes en tres zonas horarias, eso no era aceptable.
Me contrataron para diseñar una migración sin downtime. El reto técnico era: mover 450 extensiones de CUCM a 3CX, manteniendo los números de marcación internos, los grupos de llamadas, las políticas de enrutamiento externas y la capacidad de que un agente pueda hacer una llamada en cualquier momento durante la migración.
El plan que diseñé tenía cuatro fases:
- Fase 1 — Provisioning paralelo: durante una semana previa, configuré el sistema 3CX con réplica exacta de todas las extensiones, grupos y políticas. Cada agente tendría una nueva cuenta en 3CX pero nadie la usaría todavía.
- Fase 2 — Trunk doble: negocié con el operador SIP un periodo de 72 horas en el que los números externos de la empresa llegaran simultáneamente a ambos sistemas. Durante esas 72 horas, los dos sistemas recibirían las llamadas pero solo uno las contestaría según una lógica de enrutamiento que yo controlaba desde un pequeño router de borde personalizado (una Raspberry Pi con Asterisk como SIP proxy).
- Fase 3 — Migración por grupos: moví a los agentes en bloques de 20, durante la jornada laboral, sin interrumpir su servicio. Cada grupo recibía su nuevo teléfono IP preconfigurado, la Raspberry detectaba automáticamente qué grupo había cambiado, y a partir de ese momento las llamadas para esos agentes se enrutaban al 3CX nuevo. Los agentes siguieron atendiendo llamadas durante el proceso.
- Fase 4 — Apagado del CUCM viejo: una vez migrados todos los grupos (siete días después del inicio), apagué el CUCM antiguo y redirigí todo el tráfico restante al 3CX. La ventana de downtime real fue de cero minutos.
El truco técnico del proyecto fue el SIP proxy personalizado, que hice yo mismo en Python sobre una Raspberry Pi 4. Ese proxy decidía en tiempo real, llamada por llamada, a qué sistema enviarla en función del rango de extensiones que estuviera migrado en ese momento. Coste del hardware: 120 €. Tiempo de desarrollo del script: dos días. Valor para el cliente: cuatro horas de downtime evitadas durante la madrugada más sensible del año (fin de mes fiscal).
La diferencia entre saber configurar y entender por qué
Los tres casos anteriores tienen algo en común: el diagnóstico o la solución no estaban en ningún manual. No había un documento oficial donde buscar "qué hacer cuando el TTL MPLS baja inesperadamente" o "cómo migrar CUCM a 3CX sin downtime". La solución se construía aplicando conocimiento fundamental — de cómo funciona BGP por debajo, de cómo se comporta MPLS en condiciones reales, de cómo negocian las sesiones SIP — a un problema concreto.
Eso es exactamente lo que enseña el CCIE. No técnicas de configuración (que cambian cada dos años y se pueden aprender con YouTube), sino intuición estructural. Cómo leer la tabla de rutas de un router y entender qué va a pasar con un paquete concreto. Cómo saber en qué momento se está activando el backup OSPF. Cómo pensar una red de extremo a extremo cuando tienes cuatro operadores distintos en el camino.
La nube no elimina esos problemas. Los abstrae un poco, pero cuando algo va mal, alguien tiene que entender qué está pasando en la capa que el cliente no ve. Ese alguien es casi siempre alguien con la formación de un CCIE o equivalente, porque las otras personas — los buenos ingenieros cloud modernos — suelen tener un conocimiento profundo de su plataforma concreta pero poca visibilidad sobre lo que ocurre fuera de ella. Y los problemas que importan en una infraestructura empresarial ocurren entre plataformas, no dentro de ellas.
Qué seguirá importando en 2030
Si tuviera que predecir qué habilidades seguirán siendo relevantes en cinco años en el sector de redes, mi lista sería la siguiente:
- Entender los protocolos fundamentales (BGP, OSPF, IPv6, MPLS, TLS) suficientemente bien como para depurarlos cuando fallan, incluso en entornos cloud donde están abstraídos.
- Saber leer paquetes. Wireshark sigue siendo la herramienta más útil del ingeniero de redes y lo seguirá siendo. La gente que sabe interpretar un pcap detecta problemas que nadie más detecta.
- Comprender la capa física. Cuando los cables y las fibras fallan, los sistemas cloud no te lo dicen claramente. Alguien tiene que entender que una pérdida de paquetes intermitente puede ser un splice de fibra degradado.
- Saber programar a bajo nivel. Los ingenieros de red modernos escriben scripts para automatizar cosas. Pero los que realmente marcan la diferencia saben escribir un proxy SIP en Python, o un pequeño plugin de Wireshark, o un programa que parsee logs BGP en tiempo real. Ese tipo de código no se aprende en un curso — se aprende resolviendo problemas.
- Tener paciencia para leer documentación oficial. Los RFCs, las notas técnicas de Cisco, las especificaciones IEEE. Los buenos ingenieros los leen. Los mediocres se limitan a buscar en Stack Overflow.
Conclusión
¿Sigue importando el CCIE en 2026? Mi respuesta honesta es: el título importa cada vez menos (pocos clientes entienden realmente qué significa), pero las habilidades que el CCIE te obliga a desarrollar importan más que nunca. En un mundo donde todos usamos plataformas cloud que abstraen la red, las personas que pueden diagnosticar qué está pasando debajo de esa abstracción son cada vez más raras y más valiosas. Y cuando algo crítico falla — cuando AWS está caído en una zona, cuando un BGP negocia raro, cuando una migración de telefonía amenaza con parar un call center — esas personas son las que salvan el día.
Yo no uso el CCIE como certificado en mi firma para presumir. Lo uso porque indica que en algún momento tuve que aprender lo que hay debajo de las abstracciones. Y en mi experiencia, esa es una señal de calidad que muy poca gente puede fingir. Si estás a punto de contratar a alguien para una infraestructura crítica, o si tu red está teniendo problemas que nadie entiende, busca a alguien que haya pasado por esa escuela — con o sin el certificado oficial. Un sábado por la tarde puede ser la diferencia entre tres horas de downtime y tres días.