błąd routingu linux?

Od dłuższego czasu zmagam się z tym trudnym do odtworzenia problemem. Używam jądra Linuksa w wersji 3.1.0 i czasami routing do kilku adresów IP nie działa. Wydaje się, że zdarza się, że zamiast wysyłać pakiet do bramy, jądro traktuje adres docelowy jako lokalny i próbuje uzyskać adres MAC za pośrednictwem ARP.

Na przykład teraz mój obecny adres IP to 172.16.1.104/24, brama to 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

Mogę pingować kilka adresów, ale nie 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

Podczas próby pingowania 172.16.0.59 widzę w tcpdump, że zostało wysłane żądanie 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

i / proc / net / arp ma niepełny wpis dla 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

Należy pamiętać, że 172.16.0.59 jest dostępny z tej sieci LAN z innych komputerów.

Czy ktoś ma pojęcie o tym, co się dzieje? Dzięki.

aktualizacja: odpowiedzi na poniższe komentarze:

• nie ma interfejsów oprócz eth0 i lo
• wymagania ARP nie są widoczne na drugim końcu, ale tak powinno działać. głównym problemem jest to, że wymagania ARP nie powinny być nawet wysyłane w pierwszej kolejności
• problem utrzymuje się, nawet jeśli dodam wyraźną trasę za pomocą polecenia „route add -host 172.16.0.59 gw 172.16.1.254 dev eth0”

Jest to rzeczywiście błąd jądra systemu Linux, prawdopodobnie od wersji 2.6.39. Wysłałem pytanie do list lkml i netdev (patrz wątek na https://lkml.org/lkml/2011/11/18/191 ), a zostało to omówione w innym wątku netdev na http: // www .spinics.net / list / netdev / msg179687.html

Obecne rozwiązanie polega na ponownym uruchomieniu komputera lub opróżnieniu wszystkich tras i odczekaniu 10 minut na wygaśnięcie przekierowań icmp. Aby zapobiec ponownemu wystąpieniu,

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

pomaga

172.16.XX domyślna maska ​​podsieci to 255.255.0.0, ponownie skonfigurowano ją na 255.255.255.0. Więc hosty rzeczy 172.16.0.x i 172.16.1.x znajdują się w różnych podsieciach. dlatego spróbuje ZROUTOWAĆ go przez bramę domyślną.

Zmiana maski podsieci na 255.255.0.0 rozwiąże problem.

Czy możesz podać schemat? Jeśli nie możesz narysować sieci, nie można tego naprawić (przysłowie starych inżynierów sieci ... przeze mnie!).

Twoje zdrowie,