Я уже давно борюсь с этой трудно воспроизводимой проблемой. Я использую ядро Linux версии 3.1.0, и иногда маршрутизация на несколько IP-адресов не работает. Похоже, что вместо отправки пакета на шлюз ядро обрабатывает адрес назначения как локальный и пытается получить его MAC-адрес через ARP.
Например, теперь мой текущий IP-адрес 172.16.1.104/24, шлюз - 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
Я могу пропинговать несколько адресов, но не 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
При попытке выполнить эхо-запрос 172.16.0.59 я вижу в tcpdump, что был отправлен запрос 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
а в / proc / net / arp есть неполная запись для 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
Обратите внимание, что 172.16.0.59 является доступный из этой локальной сети с других компьютеров.
Кто-нибудь знает, что происходит? Спасибо.
Обновить: ответы на комментарии ниже:
Это действительно ошибка ядра Linux, вероятно, начиная с версии 2.6.39. Я разместил вопрос в списках lkml и netdev (см. Ветку на https://lkml.org/lkml/2011/11/18/191), и это только что обсуждалось в другой ветке netdev на http://www.spinics.net/lists/netdev/msg179687.html
Текущее решение теперь - либо перезагрузка, либо очистка всех маршрутов и ожидание 10 минут, пока истечет срок действия перенаправления icmp. Чтобы это не повторилось,
echo 0 >/proc/sys/net/ipv4/conf/eth0/accept_redirects
помогает.
Маска подсети 172.16.X.X по умолчанию - 255.255.0.0, вы перенастроили ее на 255.255.255.0. Таким образом, хосты 172.16.0.x и 172.16.1.x находятся в разных подсетях. таким образом, он попытается МАРШРУТИЗИРОВАТЬ его через шлюз по умолчанию.
Изменение маски подсети на 255.255.0.0 решит проблему.
Вы можете представить схему. Если вы не можете нарисовать сеть, это не исправить (старая пословица сетевых инженеров ... мною!).
Привет,