Solução para encaminhamento / proxy SNMP Traps (ou Netflow, UDP genérico, etc) para monitoramento de rede?

Question

Estou implementando uma solução de monitoramento de rede para uma rede muito grande (aproximadamente 5000 dispositivos de rede). Gostaríamos de ter todos os dispositivos em nossa rede enviando traps SNMP para uma única caixa (tecnicamente, isso provavelmente será um par de caixas HA) e então ter essa caixa passando os traps SNMP para as caixas de processamento reais. Isso nos permitirá ter várias caixas de back-end manipulando traps e distribuir a carga entre essas caixas de back-end.

Um recurso importante que precisamos é a capacidade de encaminhar as armadilhas para uma caixa específica, dependendo do endereço de origem da armadilha. Alguma sugestão para a melhor maneira de lidar com isso?

Entre as coisas que consideramos são:

• Usando o snmptrapd para aceitar as armadilhas e tê-los passar para um costume roteiro manipulador perl escrito para reescrever a armadilha e enviá-lo para o caixa de processamento adequada
• Usando algum tipo de software de balanceamento de carga rodando em uma caixa Linux para lidar com isso (tendo alguma dificuldade em encontrar muita carga programas de balanceamento que manipularão o UDP)
• Usando um dispositivo de balanceamento de carga (F5, etc)
• Usando o IPTables em uma caixa do Linux para rotear o Traps SNMP com NATing

Atualmente implementamos e estamos testando a última solução, com uma caixa do Linux com o IPTables configurado para receber as armadilhas e, dependendo do endereço de origem da armadilha, reescrevê-la com um destino nat (DNAT) para que o pacote é enviado para o servidor adequado. Por exemplo:

# 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

Isso deve funcionar com excelente eficiência para o roteamento básico de armadilhas, mas nos deixa completamente limitados ao que podemos usar e filtrar com o IPTables, por isso estamos preocupados com a flexibilidade para o futuro.

Outro recurso que gostaríamos de realmente , mas não é exatamente um "must have", é a capacidade de duplicar ou espelhar os pacotes UDP. Ser capaz de pegar uma armadilha de entrada e rotea-la para vários destinos seria muito útil.

Alguém já tentou alguma das possíveis soluções acima para o balanceamento de carga de traps SNMP (ou Netflow, UDP geral, etc)? Ou alguém pode pensar em outras alternativas para resolver isso?

    

Answer 1

Um colega de trabalho acabou de me mostrar o samplicator . Esta ferramenta parece ser uma solução perfeita para o que eu estava procurando. No site da ferramenta:

This simple program listens for UDP datagrams on a network port, and sends copies of these datagrams on to a set of destinations. Optionally, it can perform sampling, i.e. rather than forwarding every packet, forward only 1 in N. Another option is that it can "spoof" the IP source address, so that the copies appear to come from the original source, rather than the relay. Currently only supports IPv4.

It can been used to distribute e.g. Netflow packets, SNMP traps (but not informs), or Syslog messages to multiple receivers.

    

Answer 2

Eu mesmo implementaria a solução, pois não sei se você encontrará algo tão específico quanto você quiser.

Eu usaria uma linguagem de alto nível como o ruby para implementar as regras de equilíbrio e até mesmo o ouvinte de traps. Por exemplo, usando essas bibliotecas parece fácil .

Ouça as armadilhas:

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

Você deve adicionar a lógica de saldo no bloco on_trap_default .

Enviar armadilhas:

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

Para criar o daemon, você pode usar o daemon-kit ruby gem.

Se você mantiver a simplicidade e definir bons objetos, poderá manter o software sem muito esforço.

    

Answer 3

O seu principal problema será, como você sabe o ip atual do dispositivo do qual você está recebendo as armadilhas?

Se você estiver usando o SNMP v1, você pode obter o ip do cabeçalho do trap. Se você estiver usando v2 ou v3 traps, será necessário correlacionar o id do snmpengine ao ip que você buscou anteriormente no dispositivo. O Engineid normalmente não é um item de configuração obrigatório para a maioria das implementações do SNMP e, portanto, você não pode depender totalmente disso sozinho.

O recuo é que você pode usar o ip de origem do cabeçalho do pacote udp. É claro que isso falhará se a armadilha for roteada por outro EMS / NMS ou se você tiver um NAT entre o dispositivo e seu aplicativo mgmt.

1. Se você não precisar suportar traps NAT / encaminhados de outros NMS, faça uma cópia do pacote udp e faça o roteamento baseado no ip

2. Se você precisar dar suporte a isso, será necessário analisar a interceptação SNMP e verificar a correspondência de ID do mecanismo para v2 / v3; para v1, você poderá lê-la no campo de endereço do agente no cabeçalho SNMP.

Answer 4

mais um hack baseado no 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

[suposição - todas as armadilhas são enviadas para 10.0.0.1, que as redirecionam para 10.0.0.2, 10.0.0.3, 10.0.0.4]

contanto que você tenha snmp traps de um pacote - isso deve distribuir muito bem - neste caso, em três máquinas. [embora eu não tenha testado].

    

Answer 5

Acho que a resposta da chmeee é o caminho certo a seguir. Livrar-se do UDP e SNMP, no início do processo, você pode, eles são horríveis para gerenciar.

Agora estou construindo um sistema que colocará todos os eventos (incluindo traps) em uma fila JMS e, em seguida, usará todas as maravilhas do sistema de mensagens corporativo para fazer balanceamento de carga e failover.

    

Answer 6

Your main problem is going to be, how do you know the actual ip of the device you are receiving the traps from?

Para obter o IP do remetente original, você pode tentar corrigir o snmptrapd com esse patch - link .

Isso modifica a carga útil, portanto, os cabeçalhos de IP serão mantidos intactos, para que eles não entrem em seu roteamento e / ou NAT.