วิธีแก้ปัญหาเส้นทาง / พร็อกซี SNMP Traps (หรือ Netflow, UDP ทั่วไป, ฯลฯ ) สำหรับการตรวจสอบเครือข่าย?

ฉันกำลังใช้โซลูชันตรวจสอบเครือข่ายสำหรับเครือข่ายขนาดใหญ่มาก (ประมาณ 5,000 อุปกรณ์เครือข่าย) เราต้องการให้อุปกรณ์ทั้งหมดในเครือข่ายของเราส่ง SNMP traps ไปที่กล่องเดียว (ในทางเทคนิคนี่อาจจะเป็นกล่องคู่ HA) แล้วให้กล่องนั้นผ่านกับดัก SNMP ไปยังกล่องประมวลผลจริง สิ่งนี้จะช่วยให้เรามีกล่องด้านหลังหลายจุดที่จัดการกับกับดักและเพื่อกระจายโหลดระหว่างกล่องด้านหลังเหล่านั้น

คุณลักษณะสำคัญอย่างหนึ่งที่เราต้องการคือความสามารถในการส่งต่อกับดักไปยังกล่องเฉพาะโดยขึ้นอยู่กับแหล่งที่อยู่ของกับดัก ข้อเสนอแนะสำหรับวิธีที่ดีที่สุดในการจัดการกับเรื่องนี้?

ในสิ่งที่เราพิจารณาคือ:

• การใช้ snmptrapd เพื่อยอมรับกับดักและปล่อยให้มันผ่านไปยังสคริปต์ตัวจัดการ perl ที่เขียนขึ้นเองเพื่อเขียนกับดักใหม่และส่งไปยังกล่องประมวลผลที่เหมาะสม
• การใช้ซอฟต์แวร์สมดุลภาระบางอย่างที่ทำงานบนกล่อง Linux เพื่อจัดการสิ่งนี้ (มีปัญหาในการค้นหาโปรแกรมโหลดบาลานซ์จำนวนมากที่จะจัดการ UDP)
• การใช้เครื่องมือสร้างสมดุล (F5 เป็นต้น)
• การใช้ IPTables บนกล่อง Linux เพื่อจัดเส้นทางกับดัก SNMP ด้วย NATing

ขณะนี้เราได้ดำเนินการและกำลังทดสอบวิธีแก้ไขล่าสุดโดยมีกล่อง Linux พร้อม IPTables ที่กำหนดค่าให้รับกับดักและจากนั้นขึ้นอยู่กับที่อยู่ต้นทางของกับดักเขียนใหม่ด้วยปลายทาง nat (DNAT) เพื่อส่งแพ็กเก็ตไปยัง เซิร์ฟเวอร์ที่เหมาะสม ตัวอย่างเช่น:

# 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

สิ่งนี้ควรทำงานด้วยประสิทธิภาพที่ยอดเยี่ยมสำหรับการจัดเส้นทางกับดักพื้นฐาน แต่มันทำให้เรา จำกัด อย่างสมบูรณ์ในสิ่งที่เราสามารถทำได้และกรองด้วย IPTables ดังนั้นเราจึงกังวลเกี่ยวกับความยืดหยุ่นสำหรับอนาคต

คุณสมบัติอื่นที่เราต้องการจริงๆแต่ไม่ใช่ "ต้องมี" ก็คือความสามารถในการทำซ้ำหรือจำลองแพ็กเก็ต UDP ความสามารถในการใช้กับดักที่เข้ามาหนึ่งเส้นทางและกำหนดเส้นทางไปยังหลาย ๆ ปลายทางจะมีประโยชน์

มีใครลองวิธีแก้ปัญหาที่เป็นไปได้ข้างต้นสำหรับกับดัก SNMP (หรือ Netflow, UDP ทั่วไป, ฯลฯ ) ภาระการโหลด? หรือใครสามารถคิดวิธีอื่นในการแก้ปัญหานี้ได้บ้าง

ร่วมงานเพียงแค่แสดงให้ฉันเห็นsamplicator เครื่องมือนี้ดูเหมือนจะเป็นโซลูชั่นที่สมบูรณ์แบบที่ฉันกำลังมองหา จากเว็บไซต์ของเครื่องมือ:

โปรแกรมอย่างง่ายนี้รับฟังดาตาแกรม UDP บนพอร์ตเครือข่ายและส่งสำเนาดาตาแกรมเหล่านี้ไปยังชุดของปลายทาง อีกทางเลือกหนึ่งมันสามารถทำการสุ่มตัวอย่างคือแทนที่จะส่งต่อทุกแพ็กเก็ตส่งต่อเพียง 1 ใน N ตัวเลือกอื่นคือสามารถ "หลอก" ที่อยู่ IP แหล่งที่มาเพื่อให้สำเนาที่ปรากฏมาจากแหล่งต้นฉบับมากกว่าถ่ายทอด . ปัจจุบันรองรับเฉพาะ IPv4

มันสามารถใช้ในการกระจายเช่นแพ็คเก็ต Netflow กับดัก SNMP (แต่ไม่แจ้ง) หรือข้อความ Syslog ไปยังผู้รับหลาย

ฉันจะใช้การแก้ปัญหาด้วยตัวเองเพราะฉันไม่รู้ว่าคุณจะพบบางสิ่งที่เฉพาะเจาะจงตามที่คุณต้องการหรือไม่

ฉันจะใช้ภาษาระดับสูงเช่นทับทิมเพื่อใช้กฎความสมดุลและแม้กระทั่งกับดักฟัง ตัวอย่างเช่นการใช้ห้องสมุดนี้ ดูเหมือน ง่าย

ฟังกับดัก:

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

คุณควรเพิ่มตรรกะสมดุลในon_trap_defaultบล็อก

ส่งกับดัก:

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

เพื่อสร้าง daemon คุณสามารถใช้daemon-kit ruby gem

หากคุณทำให้มันง่ายและกำหนดวัตถุที่ดีคุณสามารถรักษาซอฟต์แวร์ด้วยความพยายามไม่มาก

ปัญหาหลักของคุณจะเป็นอย่างไรคุณจะรู้ไอพีที่แท้จริงของอุปกรณ์ที่คุณได้รับกับดักได้อย่างไร

หากคุณใช้ SNMP v1 คุณสามารถเอาไอพีออกจากส่วนหัวของกับดักได้ หากคุณใช้กับดัก v2 หรือ v3 คุณจะต้องเชื่อมโยง snmpengine id กับ ip ที่คุณดึงข้อมูลจากอุปกรณ์ก่อนหน้านี้ Engineid ไม่ใช่รายการปรับแต่งที่จำเป็นสำหรับการใช้งาน SNMP ส่วนใหญ่และด้วยเหตุนี้คุณจึงไม่สามารถเชื่อมั่นได้เพียงอย่างเดียว

ทางเลือกคือคุณสามารถใช้ ip ต้นทางจากส่วนหัวของแพ็กเก็ต udp แน่นอน, สิ่งนี้จะล้มเหลว, ถ้ากับดักของคุณถูกส่งผ่าน EMS / NMS อื่นหรือถ้าคุณมี NAT ระหว่างอุปกรณ์และแอปพลิเคชั่น mgmt ของคุณ

1. หากคุณไม่ต้องการสนับสนุน NAT / ส่งต่อกับดักจาก NMS อื่นเพียงแค่ทำสำเนาของแพ็คเก็ต udp และเส้นทางตาม IP

2. หากคุณต้องการสนับสนุนสิ่งนั้นคุณต้องแยกวิเคราะห์ SNMP trap และตรวจสอบรหัสเครื่องยนต์ตรงกับ v2 / v3 สำหรับ v1 คุณสามารถอ่านมันได้จากฟิลด์ตัวแทนที่อยู่ในส่วนหัว SNMP

แฮ็คที่ใช้ 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

[สมมติฐาน - กับดักทั้งหมดถูกส่งไปที่ 10.0.0.1 ซึ่งจะเปลี่ยนเส้นทางไปยัง 10.0.0.2, 10.0.0.3, 10.0.0.4]

ตราบใดที่คุณมีกับดัก snmp ยาวหนึ่งแพ็คเก็ต - นี้ควรกระจายโหลดอย่าง - ในกรณีนี้ใน 3 เครื่อง [แม้ว่าฉันยังไม่ได้ทดสอบ]

ฉันคิดว่าคำตอบจาก chmeee เป็นวิธีที่เหมาะสมที่จะไป กำจัด UDP และ SNMP ให้เร็วที่สุดเท่าที่จะทำได้เพราะพวกเขาน่ากลัวในการจัดการ

ตอนนี้ฉันกำลังสร้างระบบที่จะทำให้เหตุการณ์ทั้งหมด (รวมถึงกับดัก) ในคิว JMS และจากนั้นใช้สิ่งมหัศจรรย์ทั้งหมดของการส่งข้อความขององค์กรเพื่อทำโหลดบาลานซ์และ failover

ปัญหาหลักของคุณจะเป็นอย่างไรคุณจะรู้ไอพีที่แท้จริงของอุปกรณ์ที่คุณได้รับกับดักได้อย่างไร

ที่จะได้รับ IP ผู้ส่งต้นฉบับของคุณอาจจะพยายามที่จะแก้ไข snmptrapd กับแพทช์นี้ - https://sourceforge.net/p/net-snmp/patches/1320/#6afe

ซึ่งจะปรับเปลี่ยนเพย์โหลดดังนั้นส่วนหัวของ IP จะยังคงเหมือนเดิมดังนั้นจึงไม่เข้าสู่การกำหนดเส้นทางและ / หรือ NATting