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"
fuente
ifconfig -a
? ¿Tiene otras interfaces / IP asignadas a este host?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,
ayuda
fuente
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,
fuente