Determinar qual interface está respondendo às respostas snmp


8

Eu tenho um roteador Juniper MX que aceita solicitações SNMP. O problema é que estou enviando solicitações UDP para uma interface e está respondendo em outra. O IP de destino é aquele atribuído a lo0.1, mas o roteador está respondendo em lo0.0. Isso é problemático, pois o endereço IP para lo0.0 é o que é especificado em um firewall externo. Existe uma maneira de definir qual interface precisa responder às solicitações snmp?


Você pode verificar se a "seleção de endereço padrão" está ativada (use 'show configuration system')?
Jordan Head

Eu tenho isso ativado. A remoção que resolveria isso, acredito, mas não pretendo afetar nada além do SNMP, idealmente.
Wild Bill

Excluiu meu comentário antigo, adicionando este. O que teria que mudar com o firewall para que o tráfego de retorno fosse bom em lo0.0, ou é outra preocupação?
Jordan Head

11
Infelizmente, não encontrei nada que permitisse ajustar o endereço de origem para consultas SNMP normais (as fontes de interceptação são sempre ajustáveis) enquanto a "seleção de endereço padrão" está ativada.
Jordan Head

Quando você diz "o endereço IP do lo0.0 é o especificado em um firewall externo", o IP lo0.0 é duplicado em dois locais, tanto no roteador quanto em um firewall externo?
Cpt_fink

Respostas:


2

Os Junos não podem ter várias interfaces de loopback na mesma instância de roteamento; portanto, você deve ativar o snmp nas instâncias de roteamento primeiro:

set snmp routing-instance-access

Obviamente, você também precisará de uma rota dentro da sua instância de roteamento que retorne o tráfego de volta ao seu pesquisador SNMP.


0

Não sendo um especialista em JunOS, mas no território da Cisco, o snmp source-address x.x.x.xcomando resolveria seu problema. Aqui está a documentação do JunOS que eu consegui localizar:

Syntax
source-address address;
Hierarchy Level
[edit snmp trap-options]

http://www.juniper.net/techpubs/en_US/junos14.2/topics/reference/configuration-statement/source-address-edit-snmp.html


se eu entendo o problema, ele está enviando SNMP get ou caminha para um endereço e recebe respostas de outro. SNMP get! = Trap; sua resposta fala sobre armadilhas. Pergunto-me se este é um problema que poderia ser resolvido por emissão de um auto-retorno diferente
Mike Pennington

Essa foi a parte que me confundiu, como um sistema SNMP (ou qualquer sistema IP ...) responderia a uma solicitação com um endereço IP de origem diferente e esperaria que a conversa fosse concluída corretamente?
Cpt_fink 6/05/15

2
Portanto, a opção que ele configurou (seleção de endereço padrão) aceita qualquer serviço do sistema (SNMP, NTP, qualquer que seja) e usa o endereço de loopback como fonte, em vez da interface. A menos que você defina especificamente sinalizadores de endereço de origem em cada serviço, a parte lamentável é que isso é suportado APENAS pelas armadilhas SNMP, e não pelas capturas / caminhadas. Mesmo pings para interfaces terão um endereço de origem diferente se isso estiver ativado, portanto, você deve ter cuidado. Se a seleção de endereço padrão fosse removida, o IP da interface seria a fonte (esse é o padrão).
Jordan Head

-1

O roteador responderá ao endereço IP de origem do pacote SNMP, certo? Eu imagino que você procuraria na tabela de roteamento a rota para a sub-rede do pacote de origem para determinar para onde vai a resposta. Normalmente, essa seria a mesma interface em que ele recebeu esse pacote. Você sempre pode acessar algum tipo de roteamento baseado em diretivas, em que pode forçar o tráfego desejado para [endereço de origem do pacote SNMP] para fora da interface [o que for].

Espero que ajude.


4
PBR é uma maneira bizarra para lidar com um problema de SNMP como esta
Mike Pennington

@ MikePennington Não é um problema SNMP. É um problema de roteamento. Direita?
Ronnie Royston

2
soa como uma sondagem ou um problema de Juno para mim
Mike Pennington
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.