Determina quale interfaccia risponde alle risposte snmp


8

Ho un router Juniper MX che accetta richieste SNMP. Il problema è che sto inviando richieste UDP a un'interfaccia e sta rispondendo su un'altra. L'IP di destinazione è quello assegnato a lo0.1 ma il router risponde su lo0.0. Ciò è problematico in quanto l'indirizzo IP per lo0.0 è ciò che viene specificato su un firewall esterno. C'è un modo per definire quale interfaccia deve rispondere alle richieste snmp?


Puoi verificare se hai abilitato "selezione indirizzo predefinito" (usa "mostra sistema di configurazione")?
Jordan Head,

L'ho abilitato. Rimozione che risolverà questo credo, ma non sto cercando di avere un impatto idealmente diverso da SNMP.
Wild Bill

Ho eliminato il mio vecchio commento, aggiungendo questo. Cosa dovrebbe cambiare con il firewall in modo che il traffico di ritorno sia corretto su lo0.0 o è un'altra preoccupazione?
Jordan Head,

1
Sfortunatamente, non sono riuscito a trovare nulla che ti permettesse di regolare l'indirizzo di origine per le normali query SNMP (le origini trap sono sempre regolabili) pur avendo abilitato la "selezione dell'indirizzo predefinito".
Jordan Head

Quando si dice "l'indirizzo IP per lo0.0 è ciò che è specificato su un firewall esterno", si intende che l'IP lo0.0 è duplicato in due posizioni, sia sul router che su un firewall esterno?
cpt_fink

Risposte:


2

Junos non può avere più interfacce di loopback nella stessa istanza di routing, quindi dovrai prima abilitare snmp nelle istanze di routing:

set snmp routing-instance-access

Ovviamente avrai anche bisogno di un percorso all'interno della tua istanza di routing che riporti il ​​traffico di ritorno al tuo poller SNMP.


0

Non essendo un esperto JunOS, ma in Cisco-Land il snmp source-address x.x.x.xcomando avrebbe risolto il problema. Ecco la documentazione JunOS che sono stato in grado di individuare:

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 capisco il problema, sta inviando SNMP get o cammina verso un indirizzo e riceve risposte da un altro. SNMP get! = Trap; la tua risposta parla di trappole. Mi chiedo se questo sia un problema che potrebbe essere risolto tramite il polling di un diverso loopback
Mike Pennington,

Questa è stata la parte che mi ha confuso, come avrebbe potuto un sistema SNMP (o qualsiasi sistema IP ...) rispondere a una richiesta con un indirizzo IP di origine diverso e aspettarsi che la conversazione si completasse correttamente?
cpt_fink

2
Quindi l'opzione che ha configurato (default-address-selection) prenderà qualsiasi servizio di sistema (SNMP, NTP, qualunque cosa) e utilizzerà l'indirizzo Loopback come sorgente, anziché l'interfaccia. A MENO CHE, in ogni servizio imposti in modo specifico flag di indirizzo di origine, la parte sfortunata è che questo è supportato SOLO da trap SNMP, non da get / walk. Anche i ping alle interfacce avranno un indirizzo di origine diverso se questo è abilitato, quindi devi stare attento. Se la selezione dell'indirizzo predefinito fosse rimossa, l'IP dell'interfaccia sarebbe l'origine (questa è l'impostazione predefinita).
Jordan Head,

-1

Il router risponderà all'indirizzo IP di origine del pacchetto SNMP, giusto? Immagino che dovresti cercare nella tabella di routing il percorso verso la sottorete del pacchetto sorgente per determinare dove va la risposta. Normalmente, questa sarebbe la stessa interfaccia su cui ha ricevuto quel pacchetto. È sempre possibile eseguire un tipo di routing basato su criteri in cui è possibile forzare il traffico designato a [indirizzo di origine del pacchetto SNMP] fuori dall'interfaccia [qualunque sia].

Spero che aiuti.


4
PBR è un modo bizzarro per gestire un problema SNMP come questo
Mike Pennington,

@MikePennington Non è un problema SNMP. È un problema di routing. Giusto?
Ronnie Royston,

2
sembra un sondaggio o il problema di Giunone per me
Mike Pennington,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.