bug di routing linux?

Ho lottato con questo problema non facilmente riproducibile da un po 'di tempo. Sto usando il kernel Linux v3.1.0, e talvolta il routing a pochi indirizzi IP non funziona. Ciò che sembra accadere è che invece di inviare il pacchetto al gateway, il kernel considera l'indirizzo di destinazione come locale e cerca di ottenere il suo indirizzo MAC tramite ARP.

Ad esempio, ora il mio attuale indirizzo IP è 172.16.1.104/24, il gateway è 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

Posso eseguire il ping di alcuni indirizzi, ma non 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

Quando provo a eseguire il ping 172.16.0.59, in tcpdump posso vedere che è stato inviato un req 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

e / proc / net / arp ha una voce incompleta per 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

Si noti che 172.16.0.59 è accessibile da questa LAN da altri computer.

Qualcuno ha idea di cosa sta succedendo? Grazie.

aggiornamento: risposte ai commenti qui sotto:

non ci sono interfacce oltre a eth0 e lo
il req ARP non può essere visto dall'altra parte, ma è così che dovrebbe funzionare. il problema principale è che un req ARP non dovrebbe nemmeno essere inviato al primo posto
il problema persiste anche se aggiungo una route esplicita con il comando "route add -host 172.16.0.59 gw 172.16.1.254 dev eth0"

— Balázs Pozsár
fonte

Sto pensando che questo sia un tipo di comportamento predefinito, vediamo anche la tabella ARP? La tabella arp dell'altra estremità può essere utile qui.

— SpacemanSpiff

Come lo risolvi? Inserendo un percorso specifico per l'host lo fa funzionare di nuovo? Mi chiedo se stai ricevendo in qualche modo un reindirizzamento ICMP che fa pensare all'host che la destinazione sia locale.

— Paul,

Sembra che la risposta arp non stia tornando. Puoi tcpdump sull'host 172.16.0.59? È un ospite di VM? Controlla anche il traffico di rete sull'host.

— AndreasM,

Potete per favore pubblicare l'output di ifconfig -a? Hai altre interfacce / IP assegnati a questo host?

— Khaled,

ho aggiornato la domanda con le risposte

— Balázs Pozsár,

Risposte:

È davvero un bug del kernel Linux, probabilmente dalla versione 2.6.39. Ho pubblicato la domanda nelle liste di lkml e netdev (vedere il thread su https://lkml.org/lkml/2011/11/18/191 ), ed è stata appena discussa in un diverso thread di netdev su http: // www .spinics.net / lists / netdev / msg179687.html

La soluzione attuale ora è un riavvio o per svuotare tutte le rotte e attendere 10 minuti affinché i reindirizzamenti icmp scadano. Per evitare che accada di nuovo,

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

aiuta.

— Balázs Pozsár
fonte

sfortunatamente quanto sopra non sembra aiutare ..

— sivann,

prova a farlo per tutte le interfacce: find / proc / sys / net -name accept_redirects | mentre leggi x; do echo -n 0> $ x; fatto o forse hai un altro bug

— Balázs Pozsár,

Grazie, l'avevo già abilitato per tutte le interfacce. Gli IP provengono da tunnel IPSEC (questa macchina ne ha centinaia di centinaia) e ce ne sono sempre 5-10 (172.x) elencati nella tabella arp nell'interfaccia eth0 elencata con (incomplete) HWaddress e HWtype mancante. Quelli sembrano scadere e ne prendono posto di nuovi, ma a volte è necessario un riavvio.

— sivann,

-1

La maschera di sottorete predefinita 172.16.XX è 255.255.0.0, è stata riconfigurata in 255.255.255.0. Quindi le cose host 172.16.0.xe 172.16.1.x sono su sottoreti diverse. così proverà e ROUTE attraverso il gateway predefinito.

La modifica della maschera di sottorete su 255.255.0.0 risolverà il problema.

Puoi fornire un diagramma. Se non riesci a disegnare una rete, non può essere risolto (vecchio proverbio ingegneri di rete ... da me!).

Saluti,

— Il bidello Unix
fonte

Quale app Web o app desktop leggera consiglieresti per disegnare un diagramma di rete?

— Belmin Fernandez,

non ha nulla a che fare con ciò che di solito è la maschera di rete "predefinita". comunque, vedi la mia risposta sopra.

— Balázs Pozsár,

Grazie per il voto basso. Quindi, perché pensi che il router stia generando reindirizzamenti icmp.

— Unix Janitor,

Il router sta generando reindirizzamenti, perché cose che l'host dovrebbe usare un gateway diverso. Penso che la tua comprensione del problema sia un bug. A meno che tu non voglia educarmi diversamente

— The Unix Janitor

Si prega di leggere i thread collegati nella risposta accettata. Il problema è che queste informazioni di routing non vengono eliminate anche se dovrebbero esserlo. Non è un problema con il router / gateway.

— Balázs Pozsár,