4 votos

Las solicitudes de Arp con IP de origen extraña quedan sin respuesta

Estoy teniendo un servidor con problemas de conectividad de red que supongo que vienen de problemas con el manejo del protocolo arp.

Digamos que la topología de la red es la siguiente:

  • red 192.168.106.0, máscara de red 255.255.255.0
  • router en 192.168.106.1
  • "servidor de problemas" en 192.168.106.2
  • otro servidor en 192.168.106.3

Ahora, supongamos que el "servidor problemático" puede estar en silencio en la red durante períodos lo suficientemente largos como para que su entrada arp en el router expire.

Cuando alguien de fuera de esta red intenta conectarse al "servidor problemático", todos los intentos se agotan. Las conexiones desde dentro de la red al "servidor problemático" tienen éxito.

Si el propio "servidor problemático" intenta conectarse a alguna otra dirección fuera de la red, la conexión tiene éxito -- y después de esto, también las conexiones desde fuera de la red al "servidor problemático" tienen éxito durante un tiempo. Además, las conexiones desde el "servidor problemático" a "otro servidor" son correctas.

Mirando el tráfico arp en el caso en el que el "servidor problemático" ha estado en silencio durante mucho tiempo, puedo ver peticiones arp en la red para la dirección del "servidor problemático", pero la dirección "tell" en estas es la dirección de la red (192.168.106.0) en lugar de la dirección del router (192.168.106.1) -- y esto es lo que asumo que es la razón de este problema: por alguna razón el router tiene una dirección de respuesta equivocada en sus peticiones arp.

El "otro servidor" sigue siendo alcanzable, pero ahí asumo que la razón es que frecuentemente hace conexiones a fuera de la red local, y así evita que su entrada arp en el router expire.

¿Algún comentario o sugerencia?

Los servidores en cuestión funcionan con Linux (¿CentOS 5.x?), y se ejecutan como VMs dentro de VMWare ESXi (¿5.0?) (comprobaré/completaré los detalles de la versión cuando vuelva al trabajo el lunes). La marca/modelo del router me es desconocida.

Respuestas a las preguntas, otras conclusiones

Disculpas por haber tardado en devolver esto.

Desgraciadamente, mi visibilidad del lado de la red (cualquier cosa más allá de la propia plataforma VMWare) es muy limitada.

Basado en los paquetes de solicitud arp del router, es un producto Juniper (adivinando por la dirección MAC del solicitante).

Esta es una red pequeña, así que considera la topología como un router, un switch y un único servidor VMWare que aloja varias máquinas virtuales.

En cuanto al origen de las extrañas peticiones arp, tiene que ser la puerta de enlace de la red: sólo aparecen cuando intento conectarme a la máquina "problemática" desde fuera de la red, y cesan cuando el intento se agota o se cancela. Una rareza menor es que la dirección MAC en estas solicitudes no es la misma que se ve para el router en la tabla arp del servidor después de establecer una conexión saliente. Sin embargo, tanto la dirección MAC presente en estas solicitudes "extrañas" como la dirección MAC mostrada en la tabla arp del servidor tienen una OUI asignada por Juniper.

Luego, un hallazgo posiblemente relacionado; parece que Linux no responde a las solicitudes arp donde la dirección "tell" es la dirección de red, mientras que Windows (Vista al menos) sí lo hace. Esto no pude probarlo en el entorno real del problema, sino con mis propios juguetes en casa.

Además, parece que no estoy completamente solo con este problema; se puede encontrar una experiencia similar aquí: alpacapowered.wordpress.com

0 votos

¿Qué tipo de router, y cómo es su configuración?

1 votos

Por favor, publica una descripción de la topología de la red. Me parece que es un problema de ARP relacionado con VMWare. Busca en la KB de VMware, por ejemplo en esto: kb.vmware.com/selfservice/

0 votos

Sí, necesito conocer el router/ver la configuración. Sin embargo, eso no suena bien. ¿Cómo son las conversaciones ARP de otras máquinas con el router?

1voto

Juha Laiho Puntos 131

Hoy se ha producido un interesante cambio de situación.

Al final, las cosas se redujeron a dos cosas:

El router Juniper, o en realidad un sistema de cortafuegos en clúster, había perdido de alguna manera la sincronización de la configuración entre las partes del clúster. Como resultado, no todas las partes del clúster FW tenían la configuración actualizada, y esto dio lugar a que las peticiones arp fueran erróneas (sí, las malas peticiones arp se originaron en el router/firewall).

La aplicación de gestión del cortafuegos también se comportó mal, tratando de introducir una configuración distinta a la actual y correcta en al menos una parte del clúster del cortafuegos.

No tengo los detalles de lo que se hizo para el propio firewall, ni para la aplicación de gestión, pero el resultado final es que ahora la dirección "tell" en las peticiones arp es la dirección IP del router (.1 de la descripción original), en lugar de la dirección de red (.0).

Y a estas peticiones arp ("who-has ... tell ... .1") el servidor Linux responde tal y como debería, y las conexiones entrantes funcionan perfectamente, incluso mucho después de que se haya perdido cualquier rastro de la dirección del servidor en la caché arp de los routers.

0voto

Mike Puntos 1

Me encontré con el mismo problema. Resultó que alguien había establecido el valor de manage-ip a la dirección de subred:

Cluster:name(M)-> get config | inc aggregate10.200 set interface aggregate10.200 ip x.x.x.x.225/28 ... set interface aggregate10.200 manage-ip x.x.x.224 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Para arreglar:

unset interface aggregate10.200 manage-ip

En nuestro caso se trataba de un error de configuración.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: