помилка маршрутизації Linux?

Я з певного часу боровся з цим не легко відтворюваним питанням. Я використовую linux ядро ​​v3.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

При спробі ping 172.16.0.59 я можу побачити в tcpdump, що ARP-req був надісланий:

# 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 є доступним з цієї локальної мережі з інших комп'ютерів.

Хтось має уявлення про те, що відбувається? Дякую.

оновлення: відповіді на коментарі нижче:

• немає інтерфейсів, крім eth0 та lo
• ARP req не можна побачити на іншому кінці, але саме так воно має працювати. головна проблема полягає в тому, що запит ARP навіть не повинен надсилатися спочатку
• проблема зберігається, навіть якщо я додаю явний маршрут із командою "route add -host 172.16.0.59 gw 172.16.1.254 dev eth0"

Це справді помилка ядра Linux, ймовірно, починаючи з версії 2.6.39. Я опублікував це запитання до списків lkml та netdev (див. Нитку за адресою https://lkml.org/lkml/2011/11/18/191 ), і це саме було обговорено в іншій темі netdev за адресою http: // www .spinics.net / списки / netdev / msg179687.html

Поточне рішення тепер - або перезавантаження, або обмивання всіх маршрутів і зачекайте 10 хвилин, поки закінчується перенаправлення icmp. Щоб це не повторилося,

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

допомагає.

172.16.XX маска підмережі за замовчуванням - 255.255.0.0, ви налаштували її на 255.255.255.0. Тож речі хостів 172.16.0.x та 172.16.1.x знаходяться в різних підмережах. таким чином він спробує прокласти його через шлюз за замовчуванням.

Зміна маски підмережі на 255.255.0.0 вирішить проблему.

Чи можете ви надати схему. Якщо ви не можете намалювати мережу, вона не може бути виправлена ​​(старе прислів'я мережевих інженерів ... мною!).

Ура,