Guía de gestión de dispositivos de red: SNMP, TFTP y syslog sin un NMS completo

Gestionar switches y routers sin un software costoso depende de tres protocolos ligeros. La combinación de sondeo SNMP a través del puerto UDP 161, transferencias de archivos TFTP bajo la norma RFC 1350 y la recopilación de syslog en el puerto UDP 514 proporciona visibilidad y recuperación completas. Ejecutar estas tareas desde una única utilidad cubre el trabajo diario sin la sobrecarga de una gran plataforma.

¿Qué hacen realmente SNMP, TFTP y syslog por usted?

Cada protocolo responde a una pregunta diferente sobre un dispositivo. Juntos cubren la mayor parte de lo que se hace en un switch o router entre instalaciones.

SNMP responde a "¿en qué estado se encuentra este dispositivo ahora mismo?" El Protocolo Simple de Administración de Red (SNMP) permite a un administrador leer valores de un dispositivo. Una solicitud get lee un único valor, como el tiempo de actividad o el recuento de errores de una interfaz. Un walk lee cada valor bajo una rama del árbol, uno tras otro. Cada valor tiene un identificador de objeto (OID), un número con puntos como 1.3.6.1.2.1.1.3 para sysUpTime. Una Base de Información de Gestión (MIB) es el archivo de texto que asigna nombres legibles por humanos a esos números.

TFTP responde a "¿cómo subo o descargo un archivo de este dispositivo?" El Protocolo de Transferencia de Archivos Trivial (TFTP), definido en la norma RFC 1350, transfiere archivos a través del puerto UDP 69 sin necesidad de inicio de sesión. La mayoría de los switches y routers gestionados pueden copiar su configuración activa en un servidor TFTP. También pueden descargar imágenes de firmware desde uno.

Syslog responde a "¿qué me ha estado diciendo este dispositivo?" Los dispositivos envían líneas de registro a un receptor a medida que ocurren los eventos. El formato actual es RFC 5424, y muchos equipos de red todavía envían el formato BSD más antiguo descrito en RFC 3164. Las trampas (traps) SNMP hacen el mismo trabajo para alertas estructuradas. Una trampa linkDown, por ejemplo, llega al puerto UDP 162 en el momento en que se cae un puerto.

Dónde encaja cada protocolo

Tarea	Protocolo	Transporte y puerto	Estándar	Seguridad integrada
Sondear el estado del dispositivo bajo demanda	SNMP get, getnext, getbulk	UDP 161	RFC 3416 (operaciones), RFC 3411 a 3418 (SNMPv3)	v2c: cadena de comunidad en texto plano. v3: autenticación y cifrado (RFC 3414, RFC 3826)
Recibir alertas estructuradas	Trampa o informe SNMP	UDP 162	RFC 3416	Coincide con la versión de SNMP en uso
Copia de seguridad de configs, restauración de configs, carga de firmware	TFTP	UDP 69, luego un puerto nuevo por transferencia	RFC 1350, opciones en RFC 2347 a 2349	Ninguna: sin autenticación, sin cifrado
Recopilar registros de dispositivos	Syslog	UDP 514, o TLS en TCP 6514	RFC 5424, RFC 5426, RFC 5425	UDP: ninguna. TLS: cifrado y autenticación de servidor

¿Qué necesita antes de empezar?

La configuración es ligera, pero cinco factores determinan si funciona desde el primer día.

• Una red de gestión. Ubique las interfaces de gestión de los dispositivos en una VLAN de gestión. Una VLAN es una red lógica independiente que funciona en los mismos switches físicos. Esto mantiene el tráfico de SNMP, TFTP y syslog alejado del tráfico de invitados y del personal.
• Un host de gestión fijo. Utilice un portátil o un jump host en esa VLAN con una dirección estática. Los dispositivos envían registros y traps a una dirección fija, por lo que una dirección cambiante interrumpe la recopilación de forma silenciosa.
• Credenciales. Cree un usuario SNMPv3 con autenticación y privacidad si su firmware lo admite. Si debe utilizar v2c, cambie la cadena de comunidad predeterminada y limítela a acceso de solo lectura desde su host de gestión.
• Sincronización horaria. Apunte cada dispositivo a la misma fuente NTP. Sin ella, las marcas de tiempo de syslog de diferentes dispositivos no se podrán alinear durante un fallo.
• Reglas de firewall. Permita UDP 161 desde su host a los dispositivos. Permita UDP 162 y UDP 514 desde los dispositivos a su host. TFTP necesita UDP 69 más los puertos de seguimiento que se detallan a continuación.

Cómo cambia el plan según el modelo de gestión de su proveedor

Las plataformas gestionadas en la nube guardan la configuración en su nube, por lo que la copia de seguridad TFTP es menos importante en esos casos. SNMP y syslog le siguen ofreciendo una visión local del comportamiento del dispositivo.

Proveedor	Modelo de gestión	Dónde reside la configuración	Qué sigue haciendo una herramienta local
Cisco Meraki	Panel de control en la nube de Meraki	Panel de control de Meraki	Recibe syslog, realiza sondeo SNMP si está habilitado en el panel de control
HPE Aruba	CLI en switches AOS-S y AOS-CX, o Aruba Central	En el switch, duplicada en Central si se utiliza	Sondeo SNMP, syslog, copia de configuración TFTP
Ruckus	CLI en switches ICX, o controlador Ruckus y gestión en la nube	En el switch	Sondeo SNMP, syslog, copia de configuración TFTP
Juniper Mist	Nube de Mist gestionando switches Junos EX	Nube de Mist	Sondeo SNMP y syslog desde Junos
Ubiquiti UniFi	Aplicación UniFi Network	Copias de seguridad de la aplicación UniFi Network	Syslog remoto, SNMP si está habilitado
Cambium	cnMaestro, o gestión local en switches cnMatrix	cnMaestro o el switch	Sondeo SNMP y syslog
Extreme	CLI en Switch Engine (EXOS), o ExtremeCloud IQ	En el switch	Sondeo SNMP, syslog, copia de configuración TFTP
Fortinet	GUI o CLI de FortiGate y FortiSwitch, o FortiManager	En el dispositivo	Sondeo SNMP, syslog, copia de seguridad de configuración TFTP desde la CLI

Los switches Cisco Catalyst que ejecutan IOS o IOS XE quedan fuera del modelo Meraki. Su configuración reside en el switch y se copia a un servidor TFTP desde la CLI.

¿Cómo se configuran el sondeo SNMP, las copias de seguridad TFTP y un receptor syslog?

Netforge Network Multi-Tool integra un cliente SNMP, un servidor TFTP y un receptor syslog. Una sola instalación en su host de gestión cubre los tres pasos siguientes. Los mismos pasos funcionan con herramientas independientes si ya las está ejecutando.

Paso 1: ejecutar un SNMP walk sin un navegador MIB

No necesita un navegador MIB para obtener respuestas útiles. Una MIB solo traduce números en nombres. Realice un walk en la rama numérica correcta y los valores hablarán por sí mismos. Comience con estas cuatro ramas estándar:

• 1.3.6.1.2.1.1 (grupo de sistema). Devuelve sysDescr (cadena de modelo y firmware), sysUpTime, sysName y sysLocation. Definido en RFC 3418.
• 1.3.6.1.2.1.2.2 (ifTable). Devuelve descripciones de interfaz, estado operativo, errores y contadores de tráfico de 32 bits. Definido en RFC 2863.
• 1.3.6.1.2.1.31.1.1 (ifXTable). Devuelve contadores de alta capacidad de 64 bits y los alias de interfaz que introdujo como descripciones de puerto.
• 1.3.6.1.4.1 (rama de empresa privada). Devuelve valores específicos del fabricante bajo los números de empresa asignados por la IANA. El número de Cisco, por ejemplo, es el 9.

En Netforge, introduzca la dirección del dispositivo, sus credenciales SNMP y un OID inicial, y luego ejecute un walk. Cada resultado se lee como un OID, un tipo y un valor. Un STRING bajo sysDescr se lee como texto plano. Un valor de Timeticks bajo sysUpTime cuenta centésimas de segundo desde que se inició el agente.

Si prefiere la línea de comandos, snmpwalk de Net-SNMP realiza el mismo trabajo:

snmpwalk -v3 -l authPriv -u <user> -a SHA -A <auth-passphrase> -x AES -X <priv-passphrase> <switch-address> 1.3.6.1.2.1.1

Empiece por algo acotado. Un walk desde la raíz en un switch principal grande puede devolver decenas de miles de filas y agotar el tiempo de espera. Realice el walk en una rama, encuentre lo que necesita y luego use un get para ese OID único la próxima vez.

Lea el tráfico de los contadores de 64 bits. Un contador de octetos de 32 bits se reinicia al llegar a unos 4,29 mil millones de bytes. En un enlace de 1 Gbps a velocidad de línea, ese reinicio ocurre aproximadamente cada 34 segundos. El RFC 2863 requiere contadores de octetos de 64 bits en interfaces con velocidades superiores a 20 Mbps exactamente por esta razón.

Paso 2: ejecutar un servidor TFTP para copias de seguridad de configuración del switch

Inicie el servidor TFTP en Netforge, elija una carpeta raíz y permita la escritura de archivos. Luego, envíe la configuración desde el dispositivo a su host. El comando varía según el fabricante:

• Cisco IOS e IOS XE: copy running-config tftp: solicita la dirección del servidor y un nombre de archivo.
• HPE Aruba AOS-S: copy running-config tftp seguido de la dirección del servidor y el nombre de archivo.
• Extreme Switch Engine (EXOS): tftp put con la dirección del servidor y los detalles del archivo.
• Fortinet FortiGate: execute backup config tftp seguido de un nombre de archivo y la dirección del servidor.

Consulte la referencia de comandos de su fabricante para conocer la sintaxis exacta de su versión de firmware. Nombre cada archivo con el nombre de host y la fecha, para que una restauración nunca cargue la configuración del switch equivocado. Mueva las copias de seguridad finalizadas fuera del host TFTP a un almacenamiento protegido.

Las cargas de firmware funcionan de la misma manera a la inversa. Las imágenes de más de unos 32 MB pueden fallar en servidores limitados a bloques de 512 bytes. El contador de bloques de 16 bits se agota con ese tamaño. La opción blocksize en el RFC 2348 elimina el límite cuando ambos extremos la admiten.

Apague el servidor TFTP cuando termine. TFTP no tiene autenticación, por lo que un servidor siempre encendido es un punto de entrega de archivos abierto en su red de gestión.

Paso 3: ejecutar un receptor de syslog y de trampas SNMP

Apunte el host de registro de cada dispositivo a la dirección de su host de gestión. Luego, establezca un umbral de gravedad. Las gravedades de syslog van de 0 (Emergencia) a 7 (Depuración). Enviar de 0 a 5 (Aviso) captura fallos y cambios de estado sin inundar al receptor. Aumente un dispositivo a Depuración solo mientras realiza el seguimiento de un fallo específico.

Añada su host como destino de trampas SNMP con las mismas credenciales que utiliza para el sondeo. Active las notificaciones estándar de SNMPv2-MIB e IF-MIB: coldStart, linkDown, linkUp y authenticationFailure. Utilice informs en lugar de traps si el dispositivo los admite. Un inform espera una confirmación, por lo que una alerta perdida se vuelve a enviar.

El receptor de syslog de Netforge muestra los registros y las trampas en la misma herramienta que utiliza para el sondeo y la transferencia de archivos. Esto elimina la necesidad de ejecutar Kiwi Syslog Server junto con Tftpd64 y un explorador MIB independiente.

Caso práctico: un hotel de 200 habitaciones restablece un switch averiado

Situación. Un hotel de 200 habitaciones gestionaba 14 switches: dos de núcleo y 12 de acceso. Un problema eléctrico averió un switch de acceso que daba servicio a dos plantas de huéspedes. No existía ninguna copia de seguridad de la configuración. El ingeniero tuvo que reconstruir las VLAN y los ajustes de los puertos a partir de fotos y de memoria, lo que le llevó una jornada laboral completa.

Qué se hizo. El responsable de TI configuró un host de gestión con TFTP, SNMP y syslog en una sola herramienta. La configuración de cada switch se descargaba a TFTP semanalmente y antes de cada cambio. Un barrido SNMP mensual del grupo de sistemas registraba cada modelo y versión de firmware. Los 14 switches enviaban syslog y trampas al mismo receptor.

Resultado. Cuando falló un segundo switch de acceso, el repuesto que llegó era del mismo modelo. El ingeniero cargó la configuración de la semana anterior desde el servidor TFTP. Los huéspedes de esas plantas volvieron a estar conectados en menos de una hora, frente a un día entero la primera vez. Los equipos de los hoteles que gestionan redes de WiFi para huéspedes a gran escala se enfrentan al mismo patrón en cada propiedad: consulte Hoteles.

¿Cómo comprobar que funciona?

Pruebe cada protocolo con un resultado conocido antes de confiar en él.

• SNMP. Obtenga sysUpTime dos veces, con un minuto de diferencia. El valor debería aumentar en unas 6.000 centésimas de segundo. Confirme que sysName coincide con el hostname que espera.
• Copia de seguridad TFTP. Abra el archivo guardado y léalo. Una configuración de Cisco IOS termina con la línea end, por lo que un archivo truncado se detecta de inmediato. Compare el tamaño del archivo con la copia de seguridad anterior.
• Restauración TFTP. Restaure una copia de seguridad en un switch de repuesto o de laboratorio. Una copia de seguridad que nunca ha restaurado es una esperanza, no un plan de recuperación.
• Syslog y trampas. Cierre y vuelva a activar un puerto que no esté en uso. Debería ver una trampa linkDown y otra linkUp, además de las líneas de syslog correspondientes. Sus marcas de tiempo deberían coincidir al segundo si NTP está funcionando.
• Cobertura. Confirme que cada dispositivo de su inventario ha enviado al menos una línea de registro en las últimas 24 horas. Un dispositivo silencioso suele ser un dispositivo mal configurado.

¿Qué puede fallar y cómo solucionarlo?

La mayoría de los fallos se deben a firewalls, credenciales o interfaces de origen. Esta tabla asocia los síntomas comunes con sus soluciones.

Síntoma	Causa probable	Solución
La solicitud SNMP agota el tiempo de espera	La lista de acceso del dispositivo bloquea su host, o el puerto UDP 161 está filtrado	Añada su host a la lista de acceso SNMP y abra el puerto UDP 161
SNMPv3 falla con un error de autenticación	Disparidad en el algoritmo de autenticación o de privacidad	Haga coincidir los ajustes de SHA y AES en ambos extremos, vuelva a introducir las contraseñas
El walk devuelve datos del sistema pero nada bajo la rama enterprise	El control de acceso basado en vistas (RFC 3415) limita lo que su usuario puede ver	Amplíe la vista SNMP para su usuario de solo lectura
La transferencia TFTP se inicia y luego se detiene	El cortafuegos o NAT bloquea el puerto de seguimiento desde el que responde el servidor	Permita el rango de puertos de transferencia del servidor o mantenga TFTP dentro de una sola VLAN
Escritura TFTP rechazada	El servidor no creará nuevos archivos o los permisos de carpeta bloquean las escrituras	Permita la creación de archivos en el servidor y verifique los permisos de las carpetas
El firmware grande falla a mitad de camino	Se alcanzó el límite de bloques de 512 bytes a unos 32 MB	Habilite la opción blocksize o use la carga SCP o HTTP del fabricante
No llega ningún syslog	El dispositivo envía desde una interfaz diferente o el cortafuegos del host bloquea UDP 514	Configure la interfaz de origen de registro y permita UDP 514 entrante
Los registros aparecen desordenados	Los dispositivos no están sincronizados con NTP	Configure la misma fuente NTP en cada dispositivo
Los gráficos de la interfaz se aplanan o dan saltos	Desbordamiento del contador de 32 bits	Realice un sondeo de ifHCInOctets e ifHCOutOctets desde ifXTable

¿Cuánto cuesta y qué se obtiene a cambio?

El coste real de la gestión de dispositivos es el tiempo del ingeniero y el tiempo de inactividad, no el software. Compare los tres enfoques comunes en los ejes que impulsan ambos.

Enfoque	Herramientas a instalar	Protocolos cubiertos	Diseñado para	Adecuado para
Software gratuito para un solo propósito	Tres: Tftpd64, Kiwi Syslog Server, un navegador MIB	TFTP y syslog, trampas SNMP a través de Kiwi, sondeo SNMP a través del navegador	Tareas ad hoc, una herramienta por trabajo	Un ingeniero que ya domine las tres
Multiherramienta ligera (Netforge Network Multi-Tool)	Una	SNMP get y walk, servidor TFTP, receptor de syslog y trampas	Sondeo bajo demanda, transferencias y registros en vivo	Pequeñas instalaciones, trabajo de campo de MSP, sitios únicos
NMS completo	Una plataforma más una base de datos y un servidor	SNMP, syslog, trampas, además de descubrimiento, gráficos y enrutamiento de alertas	Monitorización continua e historial de tendencias a largo plazo	Instalaciones grandes o multisitio con equipos de guardia

Cuándo se necesita un NMS completo

Una herramienta ligera lee el estado cuando se le solicita. Un NMS completo vigila continuamente y recuerda. Cambie a un NMS completo cuando ocurra una de estas situaciones:

• Necesita semanas de historial de interfaz para la planificación de capacidad.
• Las alertas deben avisar a un ingeniero de guardia a las 3 de la mañana sin que nadie esté mirando una pantalla.
• Su instalación abarca docenas de ubicaciones, como estaciones en una red ferroviaria. Consulte Trenes.
• Los auditores esperan informes automatizados en lugar de archivos exportados a mano.

Por debajo de esa línea, un NMS completo añade un servidor, una base de datos y un mantenimiento para funciones que no utilizará.

Caso práctico: una cadena minorista de 40 tiendas encuentra fallos de enlace ocultos

Situación. Un MSP daba soporte a una cadena de 40 tiendas. Cada tienda contaba con un cortafuegos Fortinet FortiGate y dos switches. Los equipos de las tiendas informaban de que los terminales de tarjetas se desconectaban varias veces a la semana. Las visitas de los ingenieros no revelaban nada, porque el fallo se había solucionado antes de que llegara alguien.

Qué se hizo. El MSP apuntó el syslog y los traps SNMP de los 120 dispositivos a un único receptor a través de la VPN sitio a sitio existente. Cada switch envió traps linkDown y linkUp. El equipo revisó el receptor a diario durante dos semanas.

Resultado. Los registros mostraron repetidas fluctuaciones de enlace (link flaps) en los puertos de uplink de tres tiendas, coincidiendo con las horas de caída reportadas. El personal de la tienda reemplazó tres latiguillos defectuosos bajo guía remota. El MSP detuvo las visitas reactivas para ese fallo, y las tres tiendas no reportaron más caídas de terminales. Más información sobre cómo las redes de retail gestionan sus infraestructuras: Retail.

Cumplimiento y manejo de datos

Los registros de dispositivos tienen un peso importante en materia de cumplimiento. PCI-DSS exige que se cambien los valores predeterminados del proveedor, y la versión 3.2.1 nombra explícitamente las cadenas de comunidad SNMP. El requisito 10.5.1 de PCI-DSS versión 4.0 solicita conservar los registros de auditoría durante al menos 12 meses, con tres meses disponibles de inmediato. El control 8.15 del Anexo A de la norma ISO 27001 cubre el registro de eventos (logging).

Las líneas de syslog pueden contener direcciones IP y MAC, que pueden considerarse datos personales bajo el GDPR. Establezca un período de retención y restrinja quién puede leer los archivos del receptor. Esto es especialmente importante en entornos regulados: consulte Healthcare.

Dónde encaja Purple

Purple es independiente del hardware. Nuestro Guest WiFi funciona como una capa en la nube sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet, en más de 80.000 sedes activas (datos de Purple). Unos switches sanos y bien documentados en la base facilitan la ejecución de cualquier servicio superpuesto. El Netforge Network Multi-Tool brinda a sus ingenieros la vista a nivel de dispositivo para mantenerlos en ese estado.

Preguntas frecuentes

¿Necesito un NMS completo para gestionar un puñado de switches?

No. Para un solo sitio o una infraestructura pequeña, el sondeo SNMP, los respaldos TFTP y un receptor syslog cubren la mayor parte de la gestión diaria. Un NMS completo compensa su coste cuando necesita monitorización continua, semanas de historial de tendencias, localización automatizada para ingenieros de guardia o gestión en docenas de sitios. Por debajo de ese umbral, añade un servidor, una base de datos y gastos de mantenimiento para funciones que no llegará a utilizar.

¿Puedo hacer un SNMP walk sin un navegador MIB?

Sí. Una MIB solo traduce OID numéricos a nombres, por lo que puede recorrer las ramas numéricas directamente. Comience con 1.3.6.1.2.1.1 para el modelo, firmware y tiempo de actividad, y con 1.3.6.1.2.1.31.1.1 para los nombres de interfaz y contadores de tráfico de 64 bits. El Netforge Network Multi-Tool realiza operaciones get y walk desde un OID inicial. El comando snmpwalk de Net-SNMP hace lo mismo desde la línea de comandos.

¿Es seguro TFTP para respaldar configuraciones de switches?

Sí, si lo mantiene acotado. TFTP no tiene autenticación ni cifrado según el RFC 1350, por lo que cualquiera en la ruta de red puede leer una configuración en tránsito. Ejecute el servidor TFTP únicamente en una VLAN de gestión y solo durante un proceso de respaldo o restauración. Mueva los archivos terminados a un almacenamiento protegido. En aquellos casos en que su proveedor admita SCP o SFTP, utilícelos para los respaldos programados.

¿Funcionará esto con mi hardware Cisco, Aruba o Fortinet existente?

Sí. SNMP, TFTP y syslog son estándares abiertos compatibles con Cisco IOS, HPE Aruba AOS-S y AOS-CX, Ruckus ICX, Extreme Switch Engine y Fortinet FortiGate. Las plataformas gestionadas en la nube como Cisco Meraki, Juniper Mist y Ubiquiti UniFi mantienen la configuración en su nube. En estas plataformas, se utiliza SNMP y syslog a nivel local y se realiza una copia de seguridad de la configuración a través de la propia plataforma del fabricante.

¿Puede una sola herramienta sustituir a Tftpd64 y Kiwi Syslog Server?

Sí. El Netforge Network Multi-Tool incluye un servidor TFTP, un receptor de syslog y trampas SNMP, así como funciones SNMP get y walk en una sola aplicación. Esto sustituye a Tftpd64 para las transferencias de archivos y a Kiwi Syslog Server para los registros, y elimina la necesidad de contar con un navegador MIB independiente. Si necesita almacenamiento de registros a largo plazo o enrutamiento automatizado de alertas, combínelo con una plataforma de registros o con un NMS completo.

¿Están los registros de los dispositivos sujetos a PCI-DSS y GDPR?

Sí, en la mayoría de los establecimientos. El requisito 10.5.1 de la versión 4.0 de PCI-DSS exige que los registros de auditoría se conserven durante al menos 12 meses, con tres meses de disponibilidad inmediata para los sistemas que entren dentro del alcance. Las líneas de syslog pueden incluir direcciones IP y MAC, que pueden considerarse datos personales en virtud de GDPR. Defina un periodo de retención, restrinja el acceso a los archivos de registro y documente ambos aspectos.

¿Cuánto tiempo se tarda en realizar la configuración para una infraestructura pequeña?

La mayor parte del esfuerzo se centra en la configuración del propio dispositivo más que en la herramienta en sí. Configurar un host de registro, un destino de trampas y un usuario de SNMPv3 lleva unos minutos por conmutador desde la CLI. Para un sitio de 14 conmutadores, calcule una tarde, incluyendo las reglas de firewall y la verificación. Las tareas de NTP y la VLAN de gestión, si no están ya implementadas, suelen llevar más tiempo que la propia configuración de la herramienta.