0% del curso completado
SNMP y NTP en la operación de red (5.4)
📋 En esta lección
Dos protocolos sin glamour que sostienen la operación diaria: NTP mantiene los relojes sincronizados (sin él, correlacionar logs es arqueología) y SNMP alimenta la monitorización (sin él, te enteras de los problemas por los usuarios). Aquí aprendes cómo funcionan, cómo se configuran en IOS y los matices de versiones y seguridad que importan.
NTP: una sola hora para toda la red
El problema
Una avería a las 03:12. El log del switch dice 03:12, el del router 11:47, el del firewall 1993. Reconstruir la secuencia de eventos — quién falló primero, qué fue causa y qué consecuencia — es imposible. Y hay más: los certificados TLS validan fechas, Kerberos rechaza desfases de minutos, y los sistemas de ficheros y backups dependen de timestamps coherentes.
NTP (Network Time Protocol, UDP 123) sincroniza los relojes de todos los dispositivos contra fuentes de referencia, compensando la latencia del camino, con precisión de milisegundos en LAN.
Stratum: la jerarquía de la confianza
NTP organiza las fuentes por stratum — la distancia a un reloj de referencia:
- Stratum 0: el reloj físico (atómico, GPS) — no habla NTP, alimenta a…
- Stratum 1: servidores conectados directamente a un stratum 0.
- Stratum 2: sincronizados contra stratum 1 — típico servidor NTP corporativo… y así hasta 15; stratum 16 = no sincronizado (inválido).
El diseño estándar de empresa: uno o dos equipos internos sincronizan contra fuentes externas (pool.ntp.org, el NTP del proveedor, o un GPS propio), y todo lo demás sincroniza contra ellos — jerarquía interna, poco tráfico al exterior, y una sola fuente de verdad.
Configurar NTP en IOS
! Cliente (lo normal en cada switch/router):
R1(config)# ntp server 10.1.30.20 ← el NTP corporativo
R1(config)# ntp server 10.1.30.21 ← y su respaldo
R1(config)# clock timezone CET 1
R1(config)# clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
! El router como servidor NTP para el resto (en el equipo que mira a Internet):
R1(config)# ntp master 3 ← se ofrece como stratum 3
Los comandos de zona horaria no cambian la sincronización (NTP trabaja en UTC) — cambian cómo se muestran los timestamps. Con service timestamps log datetime msec localtime show-timezone, los logs quedan con hora legible y precisa — el complemento natural de la próxima lección (syslog).
Verificación
R1# show ntp status
Clock is synchronized, stratum 3, reference is 10.1.30.20
nominal freq is 250.0000 Hz, actual freq is 249.9998 Hz, precision is 2**10
R1# show ntp associations
address ref clock st when poll reach delay offset disp
*~10.1.30.20 185.51.192.10 2 35 64 377 1.2 0.31 0.8
+~10.1.30.21 185.51.192.11 2 41 64 377 1.4 0.45 0.9
show ntp status — la respuesta binaria: synchronized o no, y a qué stratum. En associations, el * marca la fuente elegida (el + las candidatas válidas) y reach 377 (octal: los últimos 8 sondeos respondidos) indica comunicación estable; un reach de 0 delata el servidor inalcanzable (¿UDP 123 filtrado?). La sincronización inicial tarda minutos — paciencia antes de declarar avería.
SNMP: los datos de la monitorización
El modelo
SNMP (Simple Network Management Protocol) expone el estado interno de cada dispositivo a los sistemas de monitorización (Zabbix, LibreNMS, PRTG, SolarWinds…). Tres piezas:
- Agente — corre en el dispositivo (el switch, el router).
- NMS/Manager — el sistema que pregunta y almacena (y del que salen las gráficas).
- MIB — el catálogo jerárquico de variables consultables (OIDs): tráfico por interfaz, CPU, temperatura, estado de puertos… Cada dato tiene su OID numérico universal.
Dos flujos complementarios:
- Polling (GET): el NMS pregunta periódicamente (UDP 161 del agente) — así se construyen las gráficas históricas.
- Traps / informs (el agente avisa): ante un evento (interfaz caída, umbral superado), el agente notifica al NMS (UDP 162) sin esperar al siguiente poll. Los informs son traps con acuse de recibo.
Y en teoría, SET — escribir configuración por SNMP: en la práctica se deshabilita casi siempre (riesgo alto, beneficio bajo; la configuración moderna va por SSH/APIs — Módulo 11).
Versiones: la decisión de seguridad
| Versión | Autenticación | Cifrado | Veredicto |
|---|---|---|---|
| v1 | Community string en claro | No | Museo |
| v2c | Community string en claro | No | Aún común — solo para lecturas y con cautela |
| v3 | Usuarios con auth real (SHA) | Sí (AES) | El estándar correcto |
La community string de v1/v2c es una contraseña compartida que viaja en texto plano — cualquiera con un sniffer la ve y con ella lee (o escribe, si es la community RW) el estado del dispositivo. SNMPv3 introduce usuarios, autenticación criptográfica y cifrado (modo priv = authPriv, el completo).
Configurar en IOS
! v2c de solo lectura (el mínimo aceptable, restringido por ACL):
R1(config)# access-list 10 permit host 10.1.30.30
R1(config)# snmp-server community S0loLectura RO 10
R1(config)# snmp-server location CPD Madrid - Rack 3
R1(config)# snmp-server contact equipo-redes@empresa.local
! v3 authPriv (lo correcto):
R1(config)# snmp-server group MONITOR v3 priv
R1(config)# snmp-server user zabbix MONITOR v3 auth sha Auth-Pass-123 priv aes 128 Priv-Pass-456
! Traps hacia el NMS:
R1(config)# snmp-server host 10.1.30.30 version 3 priv zabbix
R1(config)# snmp-server enable traps snmp linkdown linkup
Reglas profesionales: nunca las communities por defecto ("public"/"private" — el primer intento de cualquier escáner), RO salvo necesidad demostrada, ACL que limite quién pregunta, y v3 en todo equipo que lo soporte.
R1# show snmp ← contadores: ¿llegan consultas? ¿salen traps?
R1# show snmp user ← usuarios v3 definidos
Cómo se complementan
La monitorización madura junta las piezas de estas dos lecciones y la siguiente: SNMP da las métricas (la gráfica que muestra el uplink saturándose antes de que nadie llame), los traps dan la alarma inmediata, syslog (lección 8.5) da el relato detallado de cada equipo — y NTP hace que los tres cuenten la misma historia en el mismo orden. Sin NTP, el resto pierde la mitad de su valor.
Relación con otros conceptos
- Los puertos UDP 123, 161 y 162 amplían el catálogo de la lección 1.6.
- Los timestamps que NTP hace fiables son los de los logs que ya usas desde la lección 5.11 — y el syslog centralizado de la 8.5.
- Las ACLs que restringen SNMP y NTP son las de 10.4-10.5; el endurecimiento general de gestión, la 10.2.
- Las gráficas de SNMP son la materia prima del troubleshooting proactivo del Módulo 12 — y de la IA de operaciones de la lección 11.6.
Resumen
NTP (UDP 123) sincroniza toda la red contra una jerarquía de stratum (1 = pegado al reloj de referencia; 16 = inválido): diseño estándar — dos fuentes internas contra el exterior, todo lo demás contra ellas (ntp server, opcionalmente ntp master); zona horaria aparte (clock timezone, solo presentación); verifica con show ntp status (¿synchronized?) y associations (el * y el reach 377). SNMP expone métricas (agente → OIDs de la MIB) al NMS por polling (UDP 161) y avisa por traps (UDP 162): v2c viaja en claro (solo RO + ACL, jamás "public"), v3 authPriv es el estándar (usuarios, SHA, AES). Juntos — métricas, alarmas y relojes comunes — son la diferencia entre operar una red y adivinarla.