bogue de routage Linux?

9

Je lutte depuis longtemps avec ce problème difficile à reproduire. J'utilise le noyau Linux v3.1.0, et parfois le routage vers quelques adresses IP ne fonctionne pas. Ce qui semble se produire, c'est qu'au lieu d'envoyer le paquet à la passerelle, le noyau traite l'adresse de destination comme locale et essaie d'obtenir son adresse MAC via ARP.

Par exemple, maintenant mon adresse IP actuelle est 172.16.1.104/24, la passerelle est 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

Je peux cingler quelques adresses, mais pas 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

Lorsque j'essaie d'envoyer une requête ping à 172.16.0.59, je peux voir dans tcpdump qu'une demande ARP a été envoyée:

# 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

et / proc / net / arp a une entrée incomplète pour 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

Veuillez noter que 172.16.0.59 est accessible depuis ce LAN à partir d'autres ordinateurs.

Quelqu'un a-t-il une idée de ce qui se passe? Merci.

mise à jour: réponses aux commentaires ci-dessous:

  • il n'y a pas d'interfaces à part eth0 et lo
  • la demande ARP ne peut pas être vue à l'autre bout, mais c'est ainsi que cela devrait fonctionner. le principal problème est qu'une requête ARP ne doit même pas être envoyée en premier lieu
  • le problème persiste même si j'ajoute une route explicite avec la commande "route add -host 172.16.0.59 gw 172.16.1.254 dev eth0"
linux routing arp ip-routing Balázs Pozsár
la source
Je pense que c'est une sorte de comportement par défaut, voyons aussi la table ARP? La table arp de l'autre extrémité peut être utile ici.
SpacemanSpiff
Comment le corrigez-vous? Le fait de mettre un itinéraire spécifique à l'hôte le fait-il fonctionner à nouveau? Je me demande si vous obtenez en quelque sorte une redirection ICMP qui fait penser à l'hôte que la destination est locale.
Paul
Il semble que la réponse arp ne revienne pas. Pouvez-vous tcpdump sur l'hôte 172.16.0.59? Est-ce un invité VM? Vérifiez également le trafic réseau sur l'hôte.
AndreasM
Pouvez-vous poster la sortie de ifconfig -a? Avez-vous d'autres interfaces / IP attribuées à cet hôte?
Khaled
j'ai mis à jour la question avec les réponses
Balázs Pozsár

Réponses:

7

Il s'agit en effet d'un bug du noyau Linux, probablement depuis la version 2.6.39. J'ai posté la question sur les listes lkml et netdev (voir le fil sur https://lkml.org/lkml/2011/11/18/191 ), et elle vient d'être discutée dans un autre fil netdev sur http: // www .spinics.net / lists / netdev / msg179687.html

La solution actuelle consiste maintenant à redémarrer ou à vider toutes les routes et à attendre 10 minutes pour que les redirections icmp expirent. Pour éviter que cela ne se reproduise,

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

aide.

Balázs Pozsár
la source
malheureusement, ce qui précède ne semble pas aider ..
sivann
essayez de le faire pour toutes les interfaces: find / proc / sys / net -name accept_redirects | while read x; faire écho -n 0> $ x; fait ou vous avez peut-être un autre bug
Balázs Pozsár
Merci, je l'avais déjà activé pour toutes les interfaces. Les IP proviennent de tunnels IPSEC (cette machine en a des centaines) et il y en a toujours 5 à 10 (172.x) répertoriés dans le tableau arp de l'interface eth0 avec HWaddress (incomplète) et HWtype manquant. Ceux-ci semblent expirer, et de nouveaux prennent leur place, mais parfois un redémarrage est nécessaire.
sivann
-1

Le masque de sous-réseau par défaut 172.16.XX est 255.255.0.0, vous l'avez reconfiguré en 255.255.255.0. Ainsi, les éléments hôtes 172.16.0.x et 172.16.1.x se trouvent sur des sous-réseaux différents. ainsi, il essaiera de le ROUTER via la passerelle par défaut.

Changer votre masque de sous-réseau en 255.255.0.0 résoudra le problème.

Pouvez-vous fournir un diagramme. Si vous ne pouvez pas dessiner un réseau, il ne peut pas être réparé (vieux proverbe des ingénieurs réseau ... par moi!).

À votre santé,

Le concierge Unix
la source
Quelle application Web ou application de bureau légère recommanderiez-vous pour dessiner un diagramme de réseau?
Belmin Fernandez
cela n'a rien à voir avec le masque de réseau "par défaut". de toute façon, voir ma réponse ci-dessus.
Balázs Pozsár,
Merci pour la note. Alors, pourquoi pensez-vous que le routeur génère des redirections icmp.
The Unix Janitor
Le routeur génère des redirections, car cela signifie que l'hôte devrait utiliser une passerelle différente. Je pense que votre compréhension du problème est un bug. À moins que vous ne vouliez m'éduquer autrement
The Unix Janitor
Veuillez lire les discussions liées dans la réponse acceptée. Le problème est que ces informations de routage ne sont pas supprimées même si elles devraient l'être. Ce n'est pas un problème avec le routeur / passerelle.
Balázs Pozsár,