Cómo configurar el enrutamiento interno entre interfaces virtuales y la interfaz Ethernet real (Linux)

Cómo configurar el enrutamiento interno entre interfaces virtuales y la interfaz Ethernet real (Linux)

Tengo una caja de Linux con una interfaz Ethernet real (a diferencia de la virtual, también conocida como alias) que puedo usar (eth0 se usa para otros fines; no puedo usarla ni puedo agregar más NIC). Di que es eth1

Necesito controlar algunos objetos/entidades a través de SNMP, así que configuro una interfaz Ethernet virtual para cada objeto, con su dirección MAC adecuada. Hago esto por (ejemplo para vif1):

ip -family inet link add link eth1 name vif1 address <the MAC addr> type macvlan
ip link set vif1 up multicast on
ip route del default dev vif1 table main /* enable the pings/TFTP going out! */
ip route add default via 192.168.1.1 table main proto static metric /* restore orig */

eth1,vif1,vif2,... todos obtienen direcciones IP de un único servidor DHCP (remoto). Todas estas direcciones IP están, por supuesto, en la misma subred IP, digamos 10.11.1.0/24

Problema: el ping desde la máquina Linux al servidor DHCP (digamos 10.11.1.1) funciona. ping desde la máquina del servidor DHCP a eth1 IP o cualquier IP vif#X funciona, PERO (elproblema, supongo...) sólo eth1 responde a los paquetes ICMP (verificados por los contadores ifconfig y por el rastreo de Wirehark). Este problema provoca la imposibilidad de conectarse a los agentes SNMP asociados con las direcciones IP de las interfaces vif.

Supongo que necesito configurar el enrutamiento interno para que los paquetes IP lleguen a su destino vif#X. Intenté agregar una regla de IP, con una nueva tabla de enrutamiento de IP, pero probablemente no la configuré (la nueva tabla) correctamente... ¿Alguien puede decirme cómo (y preferiblemente también por qué) hacer esto?

La caja de Linux ejecuta Ubuntu9.04 y el servidor DHCP ejecuta Windows XP SP3

Respuesta1

Finalmente lo resolvió: es un problema relacionado con ARP.

  1. El servidor DHCP asigna una dirección IP a la dirección MAC de la interfaz virtual y establece este par en la tabla ARP local del servidor.
  2. La caja de Linux vincula la nueva dirección IP a la interfaz virtual que la solicitó.
  3. Los PING funcionan en ambos sentidos:
  4. Al hacer pingdeLinux al servidor, sale por la interfaz real (que está en la misma subred IP)
  5. Al hacer ping desde el servidoraLinux, nuevamente la interfaz real responde asíparececomo si todo estuviera bien...

PERO

Cuando el servidor envía paquetes IP (en mi caso, mensajes SNMP) utiliza la dirección MAC de la interfaz virtual. Cuando llega a la caja de Linux, el kernel simplemente descarta estos fotogramas, ya que no sabe cómo reenviarlos; La ejecución de Wireshark muestra estos mensajes ya que normalmente la interfaz se pone en modo promiscuo

Para que los mensajes SNMP lleguen al agente SNMP que está vinculado a la interfaz virtual, el paquete IP debe tener ladirección MAC de la interfaz real(Creo que sólo entonces el kernel realiza el enrutamiento VLAN, según la dirección IP...)

La forma de lograrlo es enviar unARP gratuitosolicitud desde la interfaz real de la caja de Linux al servidor, indicando que la dirección IP recién asignada (a una de las interfaces virtuales...) es "propiedad" de la dirección MAC de la interfaz real. Esto actualiza la tabla ARP del servidor correctamente.

Por cierto, esto también explica por qué funciona esperar un tiempo antes de iniciar el tráfico SNMP: la entrada de la tabla ARP del servidor ha caducado, por lo que el servidor envía una solicitud ARP que es respondida.correctamentepor elinterfaz real

Respuesta2

¿Por qué no configuras un dispositivo puente? brctl addbr bridgeAgregue la IP y la MAC del dispositivo físico a ese puente, mueva el dispositivo (sin IP) al puente y luego conecte también sus VIF al puente.

información relacionada