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?
fuente
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.
Si no necesita admitir trampas NAT / reenviadas de otro NMS, simplemente haga una copia del paquete udp y enrute según la IP
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
un truco más basado en netfilter:
[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].
fuente
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.
fuente
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.
fuente