Configurar SNMP debería ser sencillo y no dar problemas, pero algunas veces es posible que tengamos que investigar la razón por la que los traps no llegan al servidor de SNMP de la compañía. A continuación les comparto algunos comandos útiles para intentar solucionar el problema o al menos identificar una posible causa.

Verificar la configuración de SNMP

El siguiente comando les mostrará la configuración actual del ESXi. Tenemos que asegurarnos que esté correcto.

esxcli system snmp get

¿A qué me refiero que esté “correcto“?

  1. La Comunidad de SNMP esté bien escrita.
  2. La Dirección IP del servidor SNMP (Target) sea correcta.
  3. Verificar que el puerto configurado sea el que está escuchando el servidor SNMP (normalmente 161 o 162).

Ejemplo de salida del comando get:

SNMPv2

esxcli system snmp get
Authentication:
Communities:
Enable: true
Engineid: 00000063000000a100000000
Hwsrc: indications
Largestorage: true
Loglevel: info
Notraps:
Port: 161
Privacy:
Remoteusers:
Syscontact:
Syslocation:
Targets: snmp.ps.com@161 public
Users:
V3targets:

SNMPv3

esxcli system snmp get
Authentication: MD5
Communities:
Enable: true
Engineid: 00000063000000a100000000
Hwsrc: indications
Largestorage: true
Loglevel: info
Notraps:
Port: 161
Privacy: AES128
Remoteusers:
Syscontact:
Syslocation:
Targets:
Users: pablo/4144ebf493e341de4dbc6b95d556fc1d/395f7ab166dc1b4852a6eb55ae093315/priv
V3targets: snmp.ps.com@161 pablo priv trap

Habilitar logs en modo debug

Algunas veces, y especialmente relacionadas al tema de esta entrada de mi blog, es necesario revisar los logs de snmp (en /var/run/log/syslog.log) para entender qué sucede con el servivio de SNMP o su configuración. Solamente corremos este comando:

esxcli system snmp set -l debug

Posteriormente podríamos correr este otro comando para filtrar todo lo de snmp en el log:

egrep -i snmp /var/run/log/syslog.log

Y apartir de ahí podemos analizar qué sucede revisando cada línea.

Determinar cuándo inició el servicio de SNMP en syslog.log

Después de correr el commando --enable true para habilitar el servicio de snmp, es posible que tengamos que revisar el syslog.log para ver qué sucedió. Y una parte importante de revisar ese log es saber en qué momento el servicio inició para enfocar nuestros esfuerzos de revisión de logs posterior a esa fecha y hora en que habilitamos el servicio.

egrep "Starting snmpd" /var/run/log/syslog.log -A4
....
2020-07-27T21:59:43Z root: Starting snmpd
2020-07-27T21:59:43Z root: snmpd setting up resource reservations.
2020-07-27T21:59:44Z root: snmpd opening firewall port(s) for notifications.
2020-07-27T21:59:44Z root: snmpd Mounted /var/spool/snmp ramdisk size 1
2020-07-27T21:59:44Z root: snmpd watchdog for snmpd started.
...

Para hacer un tipo de refrescamiento (refresh) al servicio podemos ejecutar el comando --enable con false y luego true. Y posteriormente revisar el syslog.log para ver si snmpd inició, o tambien ejecutar un status sobre el servicio de snmpd, de la siguiente forma:

esxcli system snmp set --enable false
esxcli system snmp set --enable true
/etc/init.d/snmpd status

Debuggear la conexión de red de SNMP

Con tcpdump-uw podemos fácilmente verificar si existe algún time out de snmp en la red debido a algún puerto bloqueado por ejemplo:

$ tcpdump-uw -i vmk0 -Tsnmp udp and port 161
listening on vmk0, link-type EN10MB (Ethernet), capture size 262144 bytes
...
22:01:52.040286 IP mrm-esx.eng.vmware.com.51465 > prmh-lab-net3-dhcp232-234.eng.vmware.com.snmp: F=r U= E= C= GetRequest(14)

Para saber si la regla de Firewall de ESXi está permitida podemos correr este comando:

esxcli network firewall ruleset rule list | grep snmp
snmp Inbound UDP Dst 161 161

Puede suceder que si utilizamos un puerto personalizado para SNMP, este no esté abierto en el ESXi. Y para solucionarlo podriamos cambiar el puerto en el Firewall solamente.

Enviar un Trap de Prueba

Suele ser muy útil enviar un Trap de SNMP hacia el servidor de SNMP luego de asegurarnos que la configuración de SNMP está bien en el ESXi, con el propósito de saber si los traps llegan bien al servidor SNMP. De no ser así, puede que exista algún elemento aún en el medio de la comunicación evitando que los traps lleguen como otro Firewall, o algún problema de configuración del software de SNMP en el servidor.

Para enviar un trap de prueba basta con ejecutar este comando:

esxcli system snmp test

Si todo salió bien con el comando, observaremos este mensaje luego de correrlo:

Comments: There is 1 target configured, send warmStart requested, test completed normally.

Y en syslog.log veremos un mensaje como el siguiente:

2020-07-27T22:32:18Z snmpd: snmpd: Sending warmStart notification at operator request
2020-07-27T22:32:18Z snmpd: snmpd: GetTOD:tod->secs=1595889138,tod->nsecs=790731000
2020-07-27T22:32:18Z snmpd: snmpd: SendToIpTransport: sendto(fd=5, length=152) rc = 152
2020-07-27T22:32:18Z snmpd: snmpd: Sr_send_trap_ctx: trap pdu sent to '192.168.0.51:161' size=152 bytes

Además, con tcpdump-uw podemos ver el paquete salir también de esta forma:

tcpdump-uw -v -i vmk0 -s 1514 port 161
tcpdump-uw: listening on vmk0, link-type EN10MB (Ethernet), capture size 1514 bytes
22:40:19.154297 IP (tos 0x0, ttl 64, id 44494, offset 0, flags [none], proto UDP (17), length 180)
esxi-1.ps.com.38350 > snmp.ps.com.snmp: { SNMPv3 { F=ap } { USM B=5 T=2435 U="pablo" } { ScopedPDU [!scoped PDU]5a_48_7a_e1_2d_9d_3e_d5_87_17_4c_40_70_6d_c1_ed_ef_ca_2e_3a_52_46_c8_70_47_c4_2e_29_10_46_29_e0_6c_54_1b_6a_4c_c3_15_4e_f1_95_63_f9_1e_07_b6_c2_ab_4d_c7_20_85_31_47_42_fa_08_07_eb_dc_9d_c5_84_f0_9c_8c_89_49_8a_72_be_4a} }

El siguiente KB tiene más información acerca del comando “test” para snmp en ESXi: Debugging with the esxcli system snmp test command

Commands snmp tcpdump-uw troubleshoot vSphere