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”
Myślę, że to jest jakieś domyślne zachowanie, zobaczmy też tabelę ARP? Przydaje się tutaj tablica arp drugiego końca.
—
SpacemanSpiff
Jak to naprawić? Czy umieszczenie trasy konkretnego hosta powoduje, że znów działa? Zastanawiam się, czy w jakiś sposób otrzymujesz przekierowanie ICMP, które sprawia, że host myśli, że miejsce docelowe jest lokalne.
—
Paul,
Wygląda na to, że odpowiedź arp nie wraca. Czy możesz tcpdump na hoście 172.16.0.59? Czy to gość vm? Sprawdź także ruch sieciowy na hoście.
—
AndreasM,
Czy możesz opublikować wynik
—
Khaled
ifconfig -a? Czy masz inne interfejsy / adresy IP przypisane do tego hosta?
zaktualizowałem pytanie o odpowiedzi
—
Balázs Pozsár,