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

15

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?

Christopher Cashell
fuente

Respuestas:

4

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.

Christopher Cashell
fuente
3

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.

chmeee
fuente
Agradezco la respuesta, pero sinceramente, si construyo algo yo mismo, se basará en el snmptrapd de Net-SNMP y se implementará en Perl, ya que snmptrapd tiene soporte incorporado para aceptar trampas y llamar a los módulos de Perl para manejarlas. Eso lo mantiene más simple y mucho mejor soportado (tenemos una docena de tipos que pueden manejar Perl básico, y un tipo que (apenas) juega con Ruby).
Christopher Cashell
1

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.


fuente
0

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].

pQd
fuente
En realidad, no queremos que la carga se distribuya al azar. Queremos que todas las trampas de una subred determinada lleguen a la misma máquina para poder correlacionar eventos con sitios específicos. En este momento, mis reglas de IPTables establecen el destino DNAT en función del origen de la trampa.
Christopher Cashell
@Christopher Cashell: luego, como alternativa, a su solución, puede usar el módulo netfilter u32 para 'hash' del servidor de destino basado en la dirección IP de src. por ejemplo, tome los últimos 2 bits de la dirección IP de src y distribuya la carga a 4 'consumidores' snmp netfilter.org/documentation/HOWTO/…
pQd
@Christopher Cashell stearns.org/doc/iptables-u32.v0.1.html es un buen tutorial para el partido u32. alternativamente, mire el proyecto del "servidor virtual de Linux": también pueden hacer un equilibrio de carga para los paquetes udp basados ​​en src / dst ip.
pQd
0

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.

Aleksandar Ivanisevic
fuente
Creo que estás malentendido. . . No estoy tratando de construir un sistema de monitoreo completo, solo un enrutador de trampa SNMP. Tenemos 5000 dispositivos de red y cientos de miles de puertos que estamos monitoreando aquí. No hay forma de reinventar esa rueda. . . solo tratando de hacer que las herramientas que tenemos funcionen mejor.
Christopher Cashell
Te entendí bien, probablemente no me entendiste;) JMS se usa como transporte porque los corredores modernos tienen todas esas características agradables de conmutación por error, persistencia y equilibrio. Puedes PUBLICAR en una URL, enviar un correo electrónico, SOAP, lo que funcione. UDP nunca fue construido para ser confiable o equilibrable ya que no tiene un concepto de flujo de datos o control de flujo. A la larga, solo tendrás que tratar de hacer que UDP haga lo que no fue diseñado para hacer.
Aleksandar Ivanisevic
Agradezco la sugerencia, pero realmente no tengo absolutamente ninguna intención o interés en construir mi propio sistema de monitoreo de red a nivel empresarial. Ya hay muchos disponibles, y la implementación de uno con el conjunto de características y la escalabilidad que requerimos necesitaría un equipo de una docena de programadores durante 2-4 años. No es factible ni deseable. Eso me deja interactuar con los sistemas existentes, y eso me deja lidiar con muchos SNMP sobre UDP.
Christopher Cashell
0

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.

Pik Master
fuente