0% del curso completado
Enfoques de gestión de red: device, cloud, controller, automation e IaC (5.3)
📋 En esta lección
Todo el curso has gestionado la red equipo a equipo por SSH — el enfoque clásico. Aquí lo pones en perspectiva: sus límites a escala, y las cuatro evoluciones que conviven con él — gestión cloud, controladores, automatización e Infraestructura como Código. Es el mapa conceptual del resto del módulo: cada lección siguiente profundiza una de estas piezas.
Enfoque 1: device-by-device — el clásico
Lo que llevas haciendo desde el Módulo 3: SSH al equipo, comandos, write memory, siguiente equipo. Cada dispositivo es una isla con su configuración local, y tú eres el bus de integración.
Sus virtudes explican su supervivencia: cero dependencias (funciona con la red rota — la consola siempre está), granularidad total, y es la base de todo lo demás (los controladores y la automatización hablan CLI/API con los equipos por ti — sin entender la CLI no puedes depurar lo que la automatización hace).
Sus límites, la aritmética de la escala: cambiar la VLAN de voz en 200 switches = 200 sesiones × posibilidad de error humano en cada una. Sin fuente única de verdad ("¿qué versión de la ACL tiene este equipo?"), deriva de configuración garantizada (cada isla evoluciona distinto), y el conocimiento vive en cabezas, no en sistemas.
⚡ El examen (5.3) pide comparar enfoques, no elegir bandos
Ninguna organización real es 100% un enfoque: el device-by-device sobrevive para diagnóstico y emergencias en las redes más automatizadas del mundo. Lo que se evalúa es saber qué aporta y qué cuesta cada modelo.
Enfoque 2: gestión cloud
El panel único en la nube que ya viste en WiFi (9.2, estilo Meraki), extendido a switching y seguridad: los equipos llaman a casa, descargan configuración y reportan telemetría; tú administras flotas desde un navegador.
Aporta: cero infraestructura de gestión propia, multi-sede natural (200 tiendas, un panel), onboarding zero-touch (el equipo se configura solo al conectarse), actualizaciones y visibilidad centralizadas. Cuesta: licencias recurrentes, dependencia del fabricante (lock-in), y la gestión — no el servicio — depende de Internet. El matiz de la 9.2 aplica igual: plano de control en la nube, datos locales.
Enfoque 3: controladores (SDN)
La idea que cambió el paradigma: separar el plano de control del plano de datos. En la red clásica, cada equipo decide (su STP, su OSPF — planos de control distribuidos) y conmuta (plano de datos). Con SDN (Software-Defined Networking), un controlador centraliza las decisiones y los equipos ejecutan.
Sus dos interfaces, vocabulario de examen:
- Southbound (hacia abajo): cómo el controlador habla con los equipos — NETCONF/RESTCONF, OpenFlow, o la propia CLI/SNMP.
- Northbound (hacia arriba): cómo hablan contigo y con tus scripts — la API REST (próxima lección) donde expresas intención ("estas dos VLANs no se ven") y el controlador la traduce a configuración en cada equipo.
El representante empresarial: Cisco Catalyst Center (ex DNA Center) — diseño, políticas, aprovisionamiento y assurance (telemetría y diagnóstico continuo) para campus. El detalle en la lección 11.5.
Aporta: intención en vez de comandos, coherencia garantizada (la política se compila igual para todos), visión global (el controlador ve toda la topología — decisiones imposibles equipo a equipo). Cuesta: el controlador como pieza crítica (se redunda), curva de adopción, y otra capa que entender cuando algo falla.
Enfoque 4: automatización
Scripts y herramientas que ejecutan por ti las tareas repetitivas contra CLI o API: el backup nocturno de 200 configs (8.6), el cambio de ACL en 50 routers, la auditoría de "¿quién tiene aún SNMP v2c?". Herramientas: Ansible (lección 11.4), Python con Netmiko/Nornir, o las APIs de los controladores.
La diferencia con el enfoque 3: la automatización ejecuta más rápido lo que tú defines paso a paso; el controlador abstrae — le das el qué y decide el cómo. Conviven: se automatiza contra controladores también.
Aporta: velocidad, repetibilidad, eliminación del error de tecleo, escala lineal (50 equipos cuestan lo que 5). Cuesta: el error también escala (un playbook equivocado rompe 200 equipos en un minuto — por eso los pilotos y los --check), y exige disciplina de desarrollo.
Enfoque 5: IaC — Infraestructura como Código
La culminación filosófica: la configuración deseada vive en archivos versionados (Git), y la realidad se hace converger hacia ellos. No "ejecuto cambios" sino "declaro el estado final" — la herramienta calcula la diferencia y la aplica.
El giro mental es profundo:
- La fuente de verdad es el repositorio, no los equipos: ¿qué hay configurado? — se lee en Git, no en 200
show run. - Cambiar = commit + revisión + merge: cada cambio con autor, motivo, diff y aprobación (el pull request como control de cambios).
- Rollback = volver al commit anterior. La vuelta atrás deja de ser artesanía.
- La deriva se detecta y corrige: si alguien toca a mano un equipo, la comparación estado-real vs estado-declarado lo delata (y la herramienta lo revierte).
Es el modelo con que se gestionan las nubes (Terraform y familia) aplicado a la red — y hacia donde converge la profesión. Ansible en modo declarativo (11.4) es tu primera puerta.
El mapa completo
| Enfoque | Tú expresas… | Fuente de verdad | Escala | Riesgo característico |
|---|---|---|---|---|
| Device-by-device | Comandos, equipo a equipo | Cada equipo | Decenas | Error humano × N; deriva |
| Cloud | Configuración en un panel | La nube del fabricante | Miles, multi-sede | Lock-in; cuota |
| Controller/SDN | Intención/políticas | El controlador | Miles | El controlador como pieza crítica |
| Automatización | Tareas/playbooks | Tus scripts (ojalá en Git) | Cientos+ | El error también escala |
| IaC | Estado deseado declarado | El repositorio Git | Cualquiera | Disciplina exigida |
Relación con otros conceptos
- El device-by-device es los Módulos 3-10 enteros; la gestión cloud, la arquitectura de la 9.2 generalizada.
- Las APIs northbound (REST/JSON) son la próxima lección; Ansible y el modo declarativo, la 11.4; SDN y Catalyst Center a fondo, la 11.5.
- Los backups versionados de la 8.6 eran IaC embrionario — de "guardar lo que hay" a "declarar lo que debe haber".
- La IA operativa (11.6-11.8) se monta sobre estos cimientos: sin APIs ni telemetría centralizada, no hay IA que operar.
Resumen
Cinco enfoques que conviven: device-by-device (SSH equipo a equipo — granular, sin dependencias, imprescindible para depurar; no escala: error × N y deriva), cloud (panel único del fabricante, zero-touch, multi-sede; licencias y lock-in — control en la nube, datos locales), controller/SDN (plano de control centralizado: expresas intención por la API northbound, el controlador configura equipos por la southbound — coherencia y visión global; Catalyst Center como referente), automatización (Ansible/Python ejecutando tus tareas a escala — y tus errores también: pilotos y check), e IaC (el estado deseado declarado y versionado en Git como fuente de verdad: cambio = commit revisado, rollback = commit anterior, deriva detectada). El examen: comparar qué aporta y qué cuesta cada uno.