Solusi untuk rute / proxy SNMP Traps (atau Netflow, UDP generik, dll) untuk pemantauan jaringan?


15

Saya menerapkan solusi pemantauan jaringan untuk jaringan yang sangat besar (sekitar 5000 perangkat jaringan). Kami ingin semua perangkat di jaringan kami mengirim perangkap SNMP ke satu kotak (secara teknis ini mungkin akan menjadi sepasang HA kotak) dan kemudian memiliki kotak yang meneruskan perangkap SNMP ke kotak pemrosesan nyata. Ini akan memungkinkan kami untuk memiliki beberapa kotak back-end yang menangani jebakan, dan untuk mendistribusikan beban di antara kotak-kotak ujung itu.

Salah satu fitur utama yang kita butuhkan adalah kemampuan untuk meneruskan jebakan ke kotak tertentu tergantung pada alamat sumber perangkap. Ada saran untuk cara terbaik untuk menangani ini?

Di antara hal-hal yang kami pertimbangkan adalah:

  • Menggunakan snmptrapd untuk menerima jebakan, dan membuatnya meneruskannya ke skrip perl handler yang ditulis khusus untuk menulis ulang jebakan dan mengirimkannya ke kotak pemrosesan yang tepat
  • Menggunakan beberapa jenis perangkat lunak load balancing yang berjalan pada kotak Linux untuk menangani ini (mengalami kesulitan menemukan banyak program load balancing yang akan menangani UDP)
  • Menggunakan Load Balancing Appliance (F5, dll)
  • Menggunakan IPTables pada kotak Linux untuk merutekan perangkap SNMP dengan NATing

Kami saat ini telah mengimplementasikan dan sedang menguji solusi terakhir, dengan kotak Linux dengan IPTable yang dikonfigurasikan untuk menerima jebakan, dan kemudian tergantung pada alamat sumber jebakan, tulis ulang dengan tujuan nat (DNAT) sehingga paket dikirim ke server yang tepat. Sebagai contoh:

# 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

Ini harus bekerja dengan efisiensi yang sangat baik untuk routing perangkap dasar, tetapi membuat kita benar-benar terbatas pada apa yang kita bisa mach dan filter dengan IPTable, jadi kami khawatir tentang fleksibilitas untuk masa depan.

Fitur lain yang benar - benar kita sukai, tetapi bukan "harus dimiliki" adalah kemampuan untuk menduplikasi atau mencerminkan paket UDP. Mampu mengambil satu jebakan masuk dan mengarahkannya ke berbagai tujuan akan sangat berguna.

Adakah yang pernah mencoba salah satu solusi yang mungkin di atas untuk perangkap SNMP (atau Netflow, UDP umum, dll) penyeimbangan beban? Atau adakah yang bisa memikirkan alternatif lain untuk menyelesaikan ini?

Jawaban:


4

Seorang rekan kerja baru saja menunjukkan kepada saya samplicator . Alat ini terlihat seperti solusi sempurna yang saya cari. Dari situs web alat:

Program sederhana ini mendengarkan datagram UDP pada port jaringan, dan mengirimkan salinan datagram ini ke sejumlah tujuan. Secara opsional, ia dapat melakukan pengambilan sampel, yaitu alih-alih meneruskan setiap paket, meneruskan hanya 1 dalam N. Opsi lain adalah ia dapat "menipu" alamat sumber IP, sehingga salinan tampaknya berasal dari sumber asli, bukan dari relai. . Saat ini hanya mendukung IPv4.

Ini dapat digunakan untuk mendistribusikan misalnya paket Netflow, perangkap SNMP (tetapi tidak menginformasikan), atau pesan Syslog ke beberapa penerima.


3

Saya akan menerapkan solusi sendiri, karena saya tidak tahu apakah Anda akan menemukan sesuatu yang spesifik seperti yang Anda inginkan.

Saya akan menggunakan bahasa tingkat tinggi seperti ruby ​​untuk menerapkan aturan keseimbangan dan bahkan pendengar perangkap. Misalnya, menggunakan perpustakaan ini sepertinya mudah .

Dengarkan perangkap:

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

Anda harus menambahkan logika keseimbangan di on_trap_defaultblok.

Kirim perangkap:

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

Untuk membangun daemon, Anda bisa menggunakan permata ruby daemon-kit .

Jika Anda tetap sederhana dan mendefinisikan objek yang baik, Anda dapat memelihara perangkat lunak tanpa banyak usaha.


Saya menghargai jawabannya, tetapi jujur ​​jika saya membangun sesuatu sendiri, itu akan didasarkan pada snmptrapd Net-SNMP, dan diterapkan di Perl, karena snmptrapd memiliki dukungan bawaan untuk menerima jebakan dan memanggil modul Perl untuk menanganinya. Itu membuatnya lebih sederhana dan jauh lebih baik didukung (kami memiliki selusin orang yang dapat menangani Perl dasar, dan satu orang yang (hampir) bermain-main dengan Ruby).
Christopher Cashell

1

Masalah utama Anda adalah, bagaimana Anda tahu ip sebenarnya dari perangkat tempat Anda menerima jebakan?

Jika Anda menggunakan SNMP v1, Anda bisa mendapatkan ip dari header jebakan. Jika Anda menggunakan perangkap v2 atau v3, Anda harus mengkorelasikan snmpengine id ke ip yang sebelumnya Anda ambil dari perangkat. Engineid biasanya bukan item konfigurasi wajib untuk sebagian besar implementasi SNMP, dan karenanya Anda tidak dapat sepenuhnya bergantung pada itu saja.

Fallback adalah bahwa Anda dapat menggunakan ip sumber dari header paket udp. Tentu, ini akan gagal, jika perangkap Anda dialihkan melalui EMS / NMS lain atau jika Anda memiliki NAT antara perangkat dan aplikasi mgmt Anda.

  1. Jika Anda tidak perlu mendukung NAT / forwarded traps dari NMS lain, maka cukup buat salinan paket udp, dan rutekan berdasarkan ip

  2. Jika Anda perlu mendukung itu, Anda harus mengurai perangkap SNMP dan memeriksa kecocokan id mesin untuk v2 / v3, untuk v1 Anda dapat membacanya dari bidang alamat agen di header SNMP.


0

satu lagi peretas berbasis 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

[asumsi - semua perangkap dikirim ke 10.0.0.1, yang kemudian mengarahkan mereka ke 10.0.0.2, 10.0.0.3, 10.0.0.4]

selama Anda memiliki perangkap snmp satu paket - panjang - ini akan menyebarkan beban dengan baik - dalam hal ini di 3 mesin. [Meskipun saya belum mengujinya].


Sebenarnya, kami sangat tidak ingin muatannya menyebar secara acak. Kami ingin semua jebakan dari subnet yang diberikan untuk mengenai mesin yang sama sehingga kami dapat menghubungkan peristiwa ke situs tertentu. Saat ini aturan IPTables saya menetapkan tujuan DNAT berdasarkan sumber perangkap.
Christopher Cashell

@Christopher Cashell - maka sebagai alternatif untuk solusi Anda, Anda dapat menggunakan modul netfilter u32 ke server tujuan 'hash' berdasarkan alamat ip src. mis. ambil 2 bit terakhir dari alamat ip src dan sebarkan load ke 4 snmp 'konsumen'. netfilter.org/documentation/HOWTO/…
pQd

@Christopher Cashell stearns.org/doc/iptables-u32.v0.1.html adalah tutorial yang bagus untuk pertandingan u32. secara alternatif - lihat proyek "linux virtual server" - mereka dapat melakukan load balancing untuk paket udp berdasarkan pada ip src / dst juga.
pQd

0

Saya pikir jawaban dari chmeee adalah cara yang tepat untuk pergi. Singkirkan UDP dan SNMP di awal proses yang Anda bisa, mereka mengerikan untuk dikelola.

Saya sekarang sedang membangun sistem yang akan menempatkan semua acara (termasuk perangkap) pada antrian JMS dan kemudian menggunakan semua keajaiban perpesanan perusahaan untuk melakukan load balancing dan failover.


Saya pikir Anda salah paham. . . Saya tidak mencoba membangun sistem pemantauan penuh, hanya sebuah router perangkap SNMP. Kami memiliki 5.000 perangkat jaringan dan ratusan ribu port yang kami pantau di sini. Tidak mungkin saya menemukan kembali roda itu. . . hanya berusaha membuat alat yang kita miliki berfungsi lebih baik.
Christopher Cashell

Saya mengerti Anda benar, mungkin Anda tidak mengerti saya;) JMS digunakan sebagai transportasi karena broker modern memiliki semua fitur failover, persisten, dan balancing yang bagus. Anda dapat POST ke URL, mengirim email, SOAP, apa pun yang berfungsi. UDP tidak pernah dibangun agar dapat diandalkan atau dapat diseimbangkan karena tidak memiliki konsep aliran data atau kontrol aliran. Anda hanya akan kacau dalam jangka panjang mencoba membuat UDP melakukan apa yang tidak dirancang untuk dilakukan.
Aleksandar Ivanisevic

Saya menghargai saran ini, tetapi saya benar-benar tidak memiliki niat atau minat untuk membangun sistem pemantauan jaringan tingkat perusahaan saya sendiri. Ada banyak dari mereka sudah tersedia, dan menerapkan satu dengan set fitur dan skalabilitas yang kami butuhkan akan membutuhkan tim selusin programmer untuk 2-4 tahun. Itu tidak layak atau tidak diinginkan. Itu membuat saya berinteraksi dengan sistem yang ada, dan itu membuat saya berurusan dengan banyak SNMP atas UDP.
Christopher Cashell

0

Masalah utama Anda adalah, bagaimana Anda tahu ip sebenarnya dari perangkat tempat Anda menerima jebakan?

Untuk mendapatkan IP pengirim asli, Anda dapat mencoba menambal snmptrapd dengan tambalan ini - https://sourceforge.net/p/net-snmp/patches/1320/#6afe .

Itu memodifikasi payload, sehingga header IP akan tetap utuh, sehingga mereka tidak masuk ke routing dan / atau NATting Anda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.