error de enrutamiento de Linux?

He estado luchando con este problema no fácilmente reproducible desde hace un tiempo. Estoy usando Linux kernel v3.1.0, y a veces el enrutamiento a algunas direcciones IP no funciona. Lo que parece suceder es que, en lugar de enviar el paquete a la puerta de enlace, el núcleo trata la dirección de destino como local e intenta obtener su dirección MAC a través de ARP.

Por ejemplo, ahora mi dirección IP actual es 172.16.1.104/24, la puerta de enlace es 172.16.1.254:

# ifconfig eth0 eth0      Link encap:Ethernet  HWaddr 00:1B:63:97:FC:DC
          inet addr:172.16.1.104  Bcast:172.16.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:230772 errors:0 dropped:0 overruns:0 frame:0
          TX packets:171013 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:191879370 (182.9 Mb)  TX bytes:47173253 (44.9 Mb)
          Interrupt:17

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.1.254    0.0.0.0         UG    0      0        0 eth0
172.16.1.0      0.0.0.0         255.255.255.0   U     1      0        0 eth0

Puedo hacer ping a algunas direcciones, pero no 172.16.0.59:

# ping -c1 172.16.1.254
PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.383 ms

--- 172.16.1.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.383/0.383/0.383/0.000 ms
root@pozsybook:~# ping -c1 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=5.54 ms

--- 172.16.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.545/5.545/5.545/0.000 ms
root@pozsybook:~# ping -c1 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=62 time=7.92 ms

--- 172.16.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.925/7.925/7.925/0.000 ms
root@pozsybook:~# ping -c1 172.16.0.59
PING 172.16.0.59 (172.16.0.59) 56(84) bytes of data.
From 172.16.1.104 icmp_seq=1 Destination Host Unreachable

--- 172.16.0.59 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Al intentar hacer ping a 172.16.0.59, puedo ver en tcpdump que se envió una solicitud ARP:

# tcpdump -n -i eth0|grep ARP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:25:16.671217 ARP, Request who-has 172.16.0.59 tell 172.16.1.104, length 28

y / proc / net / arp tiene una entrada incompleta para 172.16.0.59:

# grep 172.16.0.59 /proc/net/arp
172.16.0.59      0x1         0x0         00:00:00:00:00:00     *        eth0

Tenga en cuenta que se puede acceder a 172.16.0.59 desde esta LAN desde otras computadoras.

¿Alguien tiene alguna idea de lo que está pasando? Gracias.

actualización: respuestas a los comentarios a continuación:

no hay interfaces además de eth0 y lo
la solicitud de ARP no se puede ver en el otro extremo, pero así es como debería funcionar. El problema principal es que una solicitud ARP ni siquiera debería enviarse en primer lugar
el problema persiste incluso si agrego una ruta explícita con el comando "route add -host 172.16.0.59 gw 172.16.1.254 dev eth0"

— Balázs Pozsár
fuente

Estoy pensando que este es un tipo de comportamiento predeterminado, ¿vamos a ver también la tabla ARP? La tabla arp del otro extremo puede ser útil aquí.

— SpacemanSpiff

Como lo arreglas? ¿Poner una ruta específica de host hace que vuelva a funcionar? Me pregunto si de alguna manera está recibiendo una redirección ICMP que hace que el host piense que el destino es local.

— Paul

Parece que la respuesta arp no regresará. ¿Puedes tcpdump en el host 172.16.0.59? ¿Es este un invitado vm? Compruebe el tráfico de red en el host también.

— AndreasM

¿Puedes publicar la salida de ifconfig -a? ¿Tiene otras interfaces / IP asignadas a este host?

— Khaled

He actualizado la pregunta con las respuestas

— Balázs Pozsár

Respuestas:

De hecho, es un error del kernel de Linux, probablemente desde la versión 2.6.39. Publiqué la pregunta en las listas lkml y netdev (vea el hilo en https://lkml.org/lkml/2011/11/18/191 ), y acabo de discutirlo en un hilo diferente de netdev en http: // www .spinics.net / lists / netdev / msg179687.html

La solución actual ahora es reiniciar o eliminar todas las rutas y esperar 10 minutos para que caduquen las redirecciones de icmp. Para evitar que vuelva a suceder,

echo 0 >/proc/sys/net/ipv4/conf/eth0/accept_redirects

ayuda

— Balázs Pozsár
fuente

desafortunadamente, lo anterior no parece ayudar ..

— sivann

intente hacerlo para todas las interfaces: find / proc / sys / net -name accept_redirects | mientras lee x; do echo -n 0> $ x; hecho o tal vez tienes otro error

— Balázs Pozsár

Gracias, ya lo había habilitado para todas las interfaces. Las IP son de túneles IPSEC (esta máquina tiene cientos de tendencias) y siempre hay 5-10 de ellos (172.x) listados en la tabla arp en la interfaz eth0 listada con HWaddress (incompleto) y HWtype faltante. Parecen caducar, y los nuevos toman su lugar, pero a veces se requiere reiniciar.

— sivann

-1

172.16.XX la máscara de subred predeterminada es 255.255.0.0, la ha reconfigurado a 255.255.255.0. Por lo tanto, los hosts 172.16.0.xy 172.16.1.x están en subredes diferentes. por lo tanto, intentará ENRUTARLO a través de la puerta de enlace predeterminada.

Cambiar su máscara de subred a 255.255.0.0 resolverá el problema.

¿Puedes proporcionar un diagrama? Si no puede dibujar una red, no se puede arreglar (antiguo proverbio de ingenieros de red ... ¡por mí!).

Salud,

— El conserje de Unix
fuente

¿Qué aplicación web o aplicación de escritorio ligera recomendaría para dibujar diagramas de red?

— Belmin Fernández el

no tiene nada que ver con lo que suele ser la máscara de red "predeterminada". de todos modos, mira mi respuesta arriba.

— Balázs Pozsár

Gracias por la rebaja. Entonces, ¿por qué crees que el enrutador está generando redirecciones icmp?

— El conserje de Unix el

El enrutador está generando redireccionamientos, porque considera que el host debería estar usando una puerta de enlace diferente. Creo que tu comprensión del problema es un error. A menos que quieras educarme de otra manera

— El Conserje de Unix

Por favor, lea los hilos vinculados en la respuesta aceptada. El problema es que esta información de enrutamiento no se descarta aunque deberían serlo. No es un problema con el enrutador / puerta de enlace.

— Balázs Pozsár