Soluzione per instradare / proxy trap SNMP (o Netflow, UDP generico, ecc.) Per il monitoraggio della rete?

Sto implementando una soluzione di monitoraggio della rete per una rete molto grande (circa 5000 dispositivi di rete). Vorremmo avere tutti i dispositivi sulla nostra rete che inviano trap SNMP a una singola scatola (tecnicamente questa sarà probabilmente una coppia di scatole HA) e quindi fare in modo che quella scatola passi le trap SNMP alle scatole di elaborazione reali. Questo ci consentirà di avere più scatole back-end che gestiscono trappole e di distribuire il carico tra quelle scatole back-end.

Una caratteristica chiave di cui abbiamo bisogno è la possibilità di inoltrare le trap a una casella specifica in base all'indirizzo di origine della trap. Qualche suggerimento per il modo migliore di gestirlo?

Tra le cose che abbiamo considerato sono:

• Utilizzo di snmptrapd per accettare le trap e farle passare a uno script di gestore perl scritto personalizzato per riscrivere la trap e inviarla alla casella di elaborazione appropriata
• Utilizzando una sorta di software di bilanciamento del carico in esecuzione su una scatola Linux per gestire questo (avendo qualche difficoltà a trovare molti programmi di bilanciamento del carico che gestiranno UDP)
• Utilizzo di un dispositivo di bilanciamento del carico (F5, ecc.)
• Utilizzo di IPTables su un box Linux per instradare le trap SNMP con NATing

Al momento abbiamo implementato e stiamo testando l'ultima soluzione, con una scatola Linux con IPTables configurata per ricevere le trap, quindi, a seconda dell'indirizzo di origine della trap, riscriverla con un nat nat (DNAT) in modo che il pacchetto venga inviato a il server corretto. Per esempio:

# 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

Questo dovrebbe funzionare con un'eccellente efficienza per il routing delle trap di base, ma ci lascia completamente limitati a ciò che possiamo manipolare e filtrare con IPTables, quindi siamo preoccupati per la flessibilità per il futuro.

Un'altra caratteristica che vorremmo davvero , ma non è assolutamente un "must have" è la possibilità di duplicare o duplicare i pacchetti UDP. Essere in grado di prendere una trappola in arrivo e instradarla verso più destinazioni sarebbe molto utile.

Qualcuno ha provato una delle possibili soluzioni sopra per il bilanciamento del carico di trap SNMP (o Netflow, UDP generale, ecc.)? O qualcuno può pensare ad altre alternative per risolvere questo?

Un collega mi ha appena mostrato un campionatore . Questo strumento sembra essere quasi una soluzione perfetta quello che stavo cercando. Dal sito Web dello strumento:

Questo semplice programma ascolta i datagrammi UDP su una porta di rete e invia copie di questi datagrammi a una serie di destinazioni. Facoltativamente, può eseguire il campionamento, ovvero anziché inoltrare ogni pacchetto, inoltrare solo 1 in N. Un'altra opzione è che può "falsificare" l'indirizzo IP di origine, in modo che le copie sembrino provenire dalla fonte originale, piuttosto che dal relè . Attualmente supporta solo IPv4.

Può essere utilizzato per distribuire ad es. Pacchetti Netflow, trap SNMP (ma non informa) o messaggi Syslog a più ricevitori.

Vorrei implementare la soluzione da solo, poiché non so se troverai qualcosa di specifico come desideri.

Userei un linguaggio di alto livello come ruby ​​per attuare le regole di equilibrio e persino l'ascoltatore di trappole. Ad esempio, l'utilizzo di queste librerie sembra facile .

Ascolta le trappole:

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

È necessario aggiungere la logica di bilanciamento nel on_trap_defaultblocco.

Invia trap:

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

Per costruire il demone potresti usare la gemma rubino del kit demone .

Se lo mantieni semplice e definisci buoni oggetti, puoi mantenere il software senza troppi sforzi.

Il tuo problema principale sarà: come fai a sapere l'ip effettivo del dispositivo da cui stai ricevendo le trap?

Se si utilizza SNMP v1, è possibile estrarre l'ip dall'intestazione della trap. Se si utilizzano trap v2 o v3, sarà necessario correlare l'id snmpengine all'ip che è stato precedentemente recuperato dal dispositivo. Engineid non è in genere un elemento di configurazione obbligatorio per la maggior parte delle implementazioni SNMP, quindi non puoi fare affidamento solo su di esso da solo.

Il fallback è che puoi usare l'ip sorgente dall'intestazione del pacchetto udp. Ovviamente, questo fallirà, se la tua trap viene instradata attraverso un altro EMS / NMS o se hai un NAT tra il dispositivo e la tua applicazione mgmt.

1. Se non hai bisogno di supportare trap NAT / forwarded da altri NMS, crea una copia del pacchetto udp e instrada in base all'ip

2. Se è necessario supportarlo, è necessario analizzare la trap SNMP e verificare la corrispondenza dell'ID motore per v2 / v3, per v1 è possibile leggerlo dal campo dell'indirizzo agente nell'intestazione SNMP.

un altro hack basato su 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

[presupposto: tutte le trap vengono inviate a 10.0.0.1, che quindi le reindirizza a 10.0.0.2, 10.0.0.3, 10.0.0.4]

fintanto che hai trappole snmp di un pacchetto - questo dovrebbe diffondere il carico in modo corretto - in questo caso su 3 macchine. [anche se non l'ho provato].

Penso che la risposta di Chmeee sia la strada giusta da percorrere. Sbarazzarsi di UDP e SNMP il più presto possibile, sono orribili da gestire.

Sto costruendo un sistema che inserirà tutti gli eventi (comprese le trap) su una coda JMS e quindi utilizzerà tutte le meraviglie della messaggistica aziendale per eseguire il bilanciamento del carico e il failover.

Il tuo problema principale sarà: come fai a sapere l'ip effettivo del dispositivo da cui stai ricevendo le trap?

Per ottenere l'IP del mittente originale, potresti provare a patchare snmptrapd con questa patch - https://sourceforge.net/p/net-snmp/patches/1320/#6afe .

Ciò modifica il payload, quindi le intestazioni IP rimarranno intatte, in modo che non entrino nel tuo routing e / o NATting.