¿Solución para enrutar / proxy SNMP Traps (o Netflow, UDP genérico, etc.) para el monitoreo de la red?

Estoy implementando una solución de monitoreo de red para una red muy grande (aproximadamente 5000 dispositivos de red). Nos gustaría que todos los dispositivos de nuestra red envíen trampas SNMP a una sola caja (técnicamente, esto probablemente sea un par de cajas HA) y luego que esa caja pase las trampas SNMP a las cajas de procesamiento reales. Esto nos permitirá tener múltiples trampas de manejo de cajas de back-end y distribuir la carga entre esas cajas de back-end.

Una característica clave que necesitamos es la capacidad de reenviar las trampas a un cuadro específico dependiendo de la dirección de origen de la trampa. ¿Alguna sugerencia sobre la mejor manera de manejar esto?

Entre las cosas que hemos considerado están:

• Usar snmptrapd para aceptar las trampas y hacer que las pase a un script de controlador perl escrito personalizado para reescribir la trampa y enviarla al cuadro de procesamiento adecuado
• Usar algún tipo de software de equilibrio de carga que se ejecute en una caja de Linux para manejar esto (teniendo algunas dificultades para encontrar muchos programas de equilibrio de carga que manejen UDP)
• Uso de un dispositivo de equilibrio de carga (F5, etc.)
• Uso de IPTables en un cuadro de Linux para enrutar las trampas SNMP con NATing

Actualmente hemos implementado y estamos probando la última solución, con una caja de Linux con IPTables configuradas para recibir las trampas, y luego, dependiendo de la dirección de origen de la trampa, reescribirla con un destino nat (DNAT) para que el paquete se envíe a El servidor adecuado. Por ejemplo:

# Range: 10.0.0.0/19       Site: abc01    Destination: foo01
iptables -t nat -A PREROUTING -p udp --dport 162 -s 10.0.0.0/19 -j DNAT --to-destination 10.1.2.3
# Range: 10.0.33.0/21       Site: abc01    Destination: foo01
iptables -t nat -A PREROUTING -p udp --dport 162 -s 10.0.33.0/21 -j DNAT --to-destination 10.1.2.3
# Range: 10.1.0.0/16       Site: xyz01    Destination: bar01
iptables -t nat -A PREROUTING -p udp --dport 162 -s 10.1.0.0/16 -j DNAT --to-destination 10.3.2.1

Esto debería funcionar con una excelente eficiencia para el enrutamiento de trampa básico, pero nos deja completamente limitados a lo que podemos mecanizar y filtrar con IPTables, por lo que nos preocupa la flexibilidad para el futuro.

Otra característica que realmente nos gustaría , pero que no es "imprescindible", es la capacidad de duplicar o duplicar los paquetes UDP. Sería muy útil poder tomar una trampa entrante y dirigirla a múltiples destinos.

¿Alguien ha intentado alguna de las posibles soluciones anteriores para el equilibrio de carga de trampas SNMP (o Netflow, UDP general, etc.)? ¿O alguien puede pensar en alguna otra alternativa para resolver esto?

Un compañero de trabajo me mostró una muestra . Esta herramienta parece ser una solución perfecta para lo que estaba buscando. Desde el sitio web de la herramienta:

Este sencillo programa escucha datagramas UDP en un puerto de red y envía copias de estos datagramas a un conjunto de destinos. Opcionalmente, puede realizar un muestreo, es decir, en lugar de reenviar cada paquete, reenviar solo 1 en N. Otra opción es que puede "falsificar" la dirección de origen IP, de modo que las copias parecen provenir de la fuente original, en lugar del relé . Actualmente solo es compatible con IPv4.

Se puede usar para distribuir, por ejemplo, paquetes de Netflow, trampas SNMP (pero no informa) o mensajes de Syslog a múltiples receptores.

Yo mismo implementaría la solución, ya que no sé si encontrarás algo tan específico como quieras.

Usaría un lenguaje de alto nivel como ruby ​​para implementar las reglas de equilibrio e incluso el oyente trampa. Por ejemplo, usar estas bibliotecas parece fácil .

Escucha las trampas:

m = SNMP::TrapListener.new(:Port => 1062, :Community => 'public') do |manager|
  manager.on_trap_default { |trap| p trap }
end
m.join

Debe agregar la lógica de equilibrio en el on_trap_defaultbloque.

Enviar trampas:

Manager.open(:Version => :SNMPv1) do |snmp|
  snmp.trap_v1(
    "enterprises.9",
    "10.1.2.3",
    :enterpriseSpecific,
    42,
    12345,
    [VarBind.new("1.3.6.1.2.3.4", Integer.new(1))])
end

Para construir el demonio, puedes usar la gema de rubí del kit de demonio .

Si lo mantiene simple y define buenos objetos, puede mantener el software sin mucho esfuerzo.

Su principal problema será: ¿cómo sabe la IP real del dispositivo del que recibe las trampas?

Si está utilizando SNMP v1, puede quitar la ip del encabezado de la trampa. Si está utilizando trampas v2 o v3, deberá correlacionar la identificación del snmpengine con la ip que ha obtenido previamente del dispositivo. Engineid generalmente no es un elemento de configuración obligatorio para la mayoría de las implementaciones de SNMP y, por lo tanto, no puede confiar completamente en eso solo.

El inconveniente es que puede usar la ip de origen desde el encabezado del paquete udp. Por supuesto, esto fallará si su trampa se enruta a través de otro EMS / NMS o si tiene un NAT entre el dispositivo y su aplicación de gestión.

1. Si no necesita admitir trampas NAT / reenviadas de otro NMS, simplemente haga una copia del paquete udp y enrute según la IP

2. Si necesita admitir eso, debe analizar la captura SNMP y verificar la coincidencia de id del motor para v2 / v3, para v1 puede leerlo en el campo de dirección del agente en el encabezado SNMP.

un truco más basado en netfilter:

iptables -t nat -A PREROUTING -d 10.0.0.1 -p udp --dport 162 -m random --average 33 -j DNAT --to-destination 10.0.0.2:162
iptables -t nat -A PREROUTING -d 10.0.0.1 -p udp --dport 162 -m random --average 33 -j DNAT --to-destination 10.0.0.3:162
# everything else goes to other consumer
iptables -t nat -A PREROUTING -d 10.0.0.1 -p udp --dport 162 -j DNAT --to-destination 10.0.0.4:162

[suposición: todas las trampas se envían a 10.0.0.1, que luego las redirige a 10.0.0.2, 10.0.0.3, 10.0.0.4]

siempre que tenga trampas snmp de un paquete de largo, esto debería distribuir la carga muy bien, en este caso en 3 máquinas. [aunque no lo he probado].

Creo que la respuesta de chmeee es el camino correcto. Deshágase de UDP y SNMP lo antes posible en el proceso, son horribles de administrar.

Ahora estoy construyendo un sistema que colocará todos los eventos (incluidas las trampas) en una cola JMS y luego usará todas las maravillas de la mensajería empresarial para realizar el equilibrio de carga y la conmutación por error.

Su principal problema será: ¿cómo sabe la IP real del dispositivo del que recibe las trampas?

Para obtener la IP del remitente original, puede intentar parchear el snmptrapd con este parche: https://sourceforge.net/p/net-snmp/patches/1320/#6afe .

Eso modifica la carga útil, por lo que los encabezados IP se mantendrán intactos, para que no entren en su enrutamiento y / o NATting.