네트워크 모니터링을 위해 SNMP 트랩 (또는 Netflow, 일반 UDP 등)을 라우팅 / 프록시하기위한 솔루션?

매우 큰 네트워크 (약 5000 개의 네트워크 장치)에 대한 네트워크 모니터링 솔루션을 구현하고 있습니다. 네트워크의 모든 장치가 SNMP 트랩을 단일 상자 (기술적으로이 상자는 HA 상자 일 것임)로 전송 한 다음 해당 상자가 SNMP 트랩을 실제 처리 상자로 전달하도록하고 싶습니다. 이를 통해 트랩을 처리하는 백엔드 박스를 여러 개 보유하고 백엔드 박스간에 부하를 분산시킬 수 있습니다.

필요한 주요 기능 중 하나는 트랩의 소스 주소에 따라 트랩을 특정 상자로 전달하는 기능입니다. 이것을 처리하는 가장 좋은 방법에 대한 제안 사항이 있습니까?

고려한 사항은 다음과 같습니다.

• snmptrapd를 사용하여 트랩을 승인하고 사용자 정의 작성된 Perl 핸들러 스크립트로 전달하여 트랩을 다시 작성하고 적절한 처리 상자로 보내도록하십시오.
• Linux 박스에서 실행되는 일종의로드 밸런싱 소프트웨어를 사용하여이를 처리 (UDP를 처리 할 많은로드 밸런싱 프로그램을 찾는 데 어려움이 있음)
• 부하 분산 장치 (F5 등) 사용
• Linux 상자에서 IPTables를 사용하여 NAT를 사용하여 SNMP 트랩 라우팅

우리는 현재 트랩을 수신하도록 구성된 IPTables가있는 Linux 상자를 사용하여 마지막 솔루션을 구현하고 테스트 한 다음 트랩의 소스 주소에 따라 대상 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

이것은 기본적인 트랩 라우팅을위한 탁월한 효율성으로 작동해야하지만 IPTable을 사용하여 필터링 및 필터링 할 수있는 기능으로 완전히 제한되므로 미래의 유연성에 대해 우려하고 있습니다.

우리가 정말로 원 하지만 "필수 사항"이 아닌 다른 기능 은 UDP 패킷을 복제하거나 미러링하는 기능입니다. 하나의 수신 트랩을 가져 와서 여러 대상으로 라우팅 할 수 있으면 매우 유용합니다.

SNMP 트랩 (또는 Netflow, 일반 UDP 등)로드 밸런싱에 대해 위의 가능한 솔루션을 시도한 사람이 있습니까? 아니면 누구든지 이것을 해결할 다른 대안을 생각할 수 있습니까?

동료가 방금 samplicator를 보여주었습니다 . 이 도구는 내가 찾던 완벽한 솔루션에 불과합니다. 도구 웹 사이트에서 :

이 간단한 프로그램은 네트워크 포트에서 UDP 데이터 그램을 수신하고이 데이터 그램의 사본을 대상 세트로 보냅니다. 선택적으로 샘플링을 수행 할 수 있습니다. 즉, 모든 패킷을 전달하지 않고 N에서 1 만 전달합니다. 또 다른 옵션은 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-kit ruby gem을 사용할 수 있습니다 .

간단하게 유지하고 좋은 객체를 정의하면 별다른 노력없이 소프트웨어를 유지할 수 있습니다.

주요 문제는 트랩을받는 장치의 실제 IP를 어떻게 알 수 있습니까?

SNMP v1을 사용하는 경우 트랩 헤더에서 ip를 가져올 수 있습니다. v2 또는 v3 트랩을 사용하는 경우 snmpengine ID를 이전에 장치에서 가져온 IP와 상관시켜야합니다. Engineid는 일반적으로 대부분의 SNMP 구현을위한 필수 구성 항목이 아니기 때문에이를 전적으로 의존 할 수는 없습니다.

폴백은 udp 패킷 헤더에서 소스 ip를 사용할 수 있다는 것입니다. 트랩이 다른 EMS / NMS를 통해 라우팅되거나 장치와 mgmt 응용 프로그램간에 NAT가있는 경우에는 물론 실패합니다.

1. 다른 NMS에서 NAT / 전달 된 트랩을 지원할 필요가없는 경우, udp 패킷의 사본을 만들고 IP를 기반으로 라우팅하십시오.

2. 이를 지원해야하는 경우 SNMP 트랩을 구문 분석하고 v2 / v3의 엔진 ID 일치를 확인해야합니다. v1의 경우 SNMP 헤더의 에이전트 주소 필드에서 읽을 수 있습니다.

넷 필터 기반 핵 하나 더 :

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 큐에 넣은 다음 엔터프라이즈 메시징의 모든 경이로움을 사용하여로드 밸런싱 및 페일 오버를 수행하는 시스템을 구축하고 있습니다.

주요 문제는 트랩을받는 장치의 실제 IP를 어떻게 알 수 있습니까?

원래 발신자의 IP를 얻으려면 https://sourceforge.net/p/net-snmp/patches/1320/#6afe 패치로 snmptrapd를 패치 하십시오 .

이는 페이로드를 수정하여 IP 헤더가 그대로 유지되므로 라우팅 및 / 또는 NAT에 들어 가지 않습니다.