☰

¿Error de enrutamiento de Linux?

tag-icon • tag-icon linux routing arp ip-routing
¿Error de enrutamiento de Linux?

He estado luchando con este problema que no es fácilmente reproducible desde hace un tiempo. Estoy usando el kernel de Linux 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 kernel 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 a 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 172.16.0.59esaccesible desde esta LAN desde otras computadoras.

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

actualizar:responde a los comentarios a continuación:

  • no hay interfaces además de eth0 y lo
  • el requisito ARP no se puede ver en el otro extremo, pero así es como debería funcionar. El principal problema es que, en primer lugar, ni siquiera se debe enviar una solicitud ARP.
  • 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"

Respuesta1

De hecho, es un error del kernel de Linux, probablemente desde la versión 2.6.39. He publicado la pregunta en las listas lkml y netdev (consulte el hilo enhttps://lkml.org/lkml/2011/11/18/191), y se acaba de comentar en un hilo de netdev diferente enhttp://www.spinics.net/lists/netdev/msg179687.html

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

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

ayuda.

Respuesta2

La máscara de subred predeterminada de 172.16.XX es 255.255.0.0, la ha reconfigurado a 255.255.255.0. Entonces, los hosts 172.16.0.x y 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 puedes dibujar una red, no se puede arreglar (viejo proverbio de los ingenieros de redes... ¡por mí!).

Salud,

información relacionada