¿Cómo identificar las NIC que están conectadas al mismo conmutador desde una caja de Linux?


15

Configuración inicial

Como administrador de Linux, ha instalado una nueva caja de Linux con 6 NIC eth0 a eth5. La interfaz eth0 está configurada correctamente y todas las demás interfaces están activas actualmente pero sin dirección IP. Los chicos de la red simplemente han conectado cuatro cables a esta caja. Se utilizan dos cables LAN para conectar la caja a la red de producción y dos para conectar la caja a una red privada. Solo sabe que eth0 está conectado a la red de producción. Pero no sabe qué otra NIC está conectada al mismo conmutador, ya que hay diferentes generaciones de servidores y / o los chicos de la red usan las NIC incorrectas para sus conexiones.

Tarea en cuestión

Como esta configuración es típica para su infraestructura, desea automatizar la configuración de las interfaces de enlace. Ahora tiene la tarea de detectar qué NIC no están conectadas en absoluto y qué NIC están vinculadas al mismo conmutador para que puedan conectarse. Solo tiene acceso a los cuadros de Linux y no puede consultar los conmutadores.

Ideas

Detectar el estado del enlace es fácil:

ethtool $device | grep 'Link detected' | cut -d ':' -f 2

Pero, ¿cómo hacer coincidir los dispositivos que están conectados al mismo conmutador?

En HP-UX hay una herramienta para ese propósito llamada linkloop [1]. Falta la herramienta oficial de Linux (aunque hay un antiguo proyecto de SourceForce).

Las posibles soluciones que ya se me han ocurrido son:

  1. Escuche en todas las interfaces con tcpdump. Diseñe y envíe un paquete ICMP (difusión). Las interfaces que ven ese paquete deben estar conectadas al mismo conmutador. -> necesita sugerencias de herramientas simples que puedan usarse para eso. Me gustaría usar comandos de shell simples o Python para las secuencias de comandos.

  2. Intente hablar con una caja externa a través de un protocolo fácil (HTTP?) Y vea si hay una respuesta. -> Error propenso y dependiente de una caja externa.

¿Tiene más ideas o sugerencias sobre cómo resolver esta tarea?

Gracias de antemano por todos los comentarios!

[1] http://linux.die.net/man/1/linkloop


1
Esto REALMENTE huele a tarea - ¿Es este un problema real que enfrenta en un entorno de producción?
voretaq7

2
Problema real y molesto, podría agregar. Estoy fuera de la escuela durante mucho tiempo ...
Reiner Rottmann

Bien, la razón por la que pregunto es por la forma en que formuló la pregunta que me recordó el estilo de uno de mis libros de texto de redes :-)
voretaq7

Respuestas:


10

Es posible que los conmutadores ya le estén enviando la información que desea. Si son conmutadores Cisco, de manera predeterminada utilizarán un proceso llamado CDP (Cisco Discovery Protocol) que le proporcionará información sobre el conmutador donde está conectado.

Puede usar tcpdump para ver esta información con lo siguiente (sustituyendo la interfaz apropiada):

tcpdump -nn -v -i eth0 -s 1500 -c 1 'ether[20:2] == 0x2000'

La versión estándar de CDP es LLDP (protocolo de descubrimiento de capa de enlace). Algunos proveedores tendrán esto activado de forma predeterminada y otros desactivados, por lo que su kilometraje variará. Existen algunas implementaciones de LLDP para Linux, pero si desea algo similar a lo anterior, puede usar esto (configure LLDP en un conmutador Cisco y pruebe lo siguiente, que es más consistente con lo anterior):

tcpdump -nn -v -i eth0 -s 1500 -c 1 'ether proto 0x88cc'

Salvo eso, diría que una modificación de la opción 1 que proporcione podría funcionar, sin embargo, en lugar de enviar un ICMP de difusión, puede probar un ICMP normal (a un host que no esté en la tabla ARP) y capturar los paquetes ARP. Si la solicitud ARP se envía eth0 y la recibe en eth1 y eth3, entonces sabe que están en la misma VLAN. El comando más simple para eso es el siguiente:

tcpdump -i eth0 arp

1
En realidad, utilicé esta solución y escribí un pequeño script de Python que ejecuta tcpdumps como subprocesos en segundo plano y luego envío solicitudes arp y veo qué interfaz recibe los paquetes arp de los cuales src mac. Funciona pero con todos los tiempos de espera lleva algo de tiempo.
Reiner Rottmann

Supongo que estás hablando de los tiempos de espera de ping? Puede probar fping o nmap como opciones para reducir el tiempo de espera a menos de un segundo. Por ejemplo, "fping -c1 -t200 192.168.0.1" o "nmap -sP --max-retries = 1 --host-timeout = 200ms 192.168.0.1".
YLearn

3

Si el conmutador se comunicará con usted mediante LLDP, es posible que pueda ejecutar LLDP y encontrar más información allí.



1

¿Por qué no simplemente descargar y construir la linkloopherramienta? No es tan viejo ...

De lo contrario, usaría alguna herramienta que se transmitirá a través de la capa 2 y verificaría que la reciba a través de tcpdump.

Enviar un paquete ICMP de difusión es fácil ping -b 192.168.1.255


Intenté hacer esto, y falló aquí en 2016 en Ubuntu 14, así que YMMV.
Hack Saw
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.