Determine qué interfaz está respondiendo a las respuestas snmp


8

Tengo un enrutador MX de Juniper que acepta solicitudes SNMP. El problema es que estoy enviando solicitudes UDP a una interfaz y está respondiendo en otra. La IP de destino es la que está asignada a lo0.1 pero el enrutador responde en lo0.0. Esto es problemático ya que la dirección IP para lo0.0 es la que se especifica en un firewall externo. ¿Hay alguna manera de definir qué interfaz necesita para responder a las solicitudes snmp?


¿Puede verificar si tiene habilitada la "selección de dirección predeterminada" (use 'show configuration system')?
Jordan Head

Tengo eso habilitado. Supongo que eliminar eso resolvería esto, pero no busco impactar en otra cosa que no sea SNMP idealmente.
Wild Bill

Eliminé mi comentario anterior y agregué este. ¿Qué tendría que cambiar con el firewall para que el tráfico de retorno esté bien en lo0.0, o es otra preocupación?
Jordan Head

1
Desafortunadamente, no pude encontrar nada que le permitiera ajustar la dirección de origen para consultas SNMP normales (las fuentes de captura siempre son ajustables) mientras tenía habilitada la "selección de dirección predeterminada".
Jordan Head

Cuando dice "la dirección IP para lo0.0 es lo que se especifica en un firewall externo", ¿quiere decir que la IP lo0.0 está duplicada en dos ubicaciones, tanto en su enrutador como en un firewall externo?
cpt_fink

Respuestas:


2

Junos no puede tener múltiples interfaces de bucle invertido en la misma instancia de enrutamiento, por lo que primero deberá habilitar snmp en las instancias de enrutamiento:

set snmp routing-instance-access

Obviamente, también necesitará una ruta dentro de su instancia de enrutamiento que devolverá el tráfico a su sondeo SNMP.


0

No siendo un experto en JunOS, pero en Cisco-land el snmp source-address x.x.x.xcomando solucionará su problema. Aquí está la documentación de JunOS que pude 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


Si entiendo el problema, está enviando SNMP get o camina a una dirección y recibe respuestas de otra. SNMP get! = Trap; Su respuesta habla de trampas. Me pregunto si este es un problema que podría resolverse sondeando un loopback diferente
Mike Pennington,

Esa fue la parte que me confundió, ¿cómo respondería un sistema SNMP (o cualquier sistema IP ...) a una solicitud con una dirección IP de origen diferente y esperaría que la conversación se completara correctamente?
cpt_fink

2
Entonces, la opción que ha configurado (selección de dirección predeterminada) tomará cualquier servicio del sistema (SNMP, NTP, lo que sea) y usará la dirección de bucle invertido como fuente, en lugar de la interfaz. A MENOS QUE establezca específicamente marcas de dirección de origen en cada servicio, la parte desafortunada es que esto es compatible SOLAMENTE con las trampas SNMP, no con las entradas / salidas. Incluso los pings a las interfaces tendrán una dirección de origen diferente si está habilitada, por lo que debe tener cuidado. Si se eliminara la selección de dirección predeterminada, la IP de la interfaz sería la fuente (esto es predeterminado).
Jordan Head

-1

El enrutador responderá a la dirección IP de origen del paquete SNMP, ¿verdad? Me imagino que buscaría en la tabla de enrutamiento la ruta a la subred del paquete fuente para determinar a dónde va la respuesta. Normalmente, esta sería la misma interfaz en la que recibió ese paquete. Siempre podría utilizar algún tipo de enrutamiento basado en políticas en el que podría forzar el tráfico enviado a [dirección de origen del paquete SNMP] fuera de la interfaz [lo que sea].

Espero que ayude.


44
PBR es una forma extraña de manejar un problema SNMP como este
Mike Pennington,

@ MikePennington No es un problema de SNMP. Es un problema de enrutamiento. ¿Derecha?
Ronnie Royston

2
suena como una encuesta o un problema de Juno para mí
Mike Pennington
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.