☰

Ошибка маршрутизации Linux?

tag-icon • tag-icon linux routing arp ip-routing
Ошибка маршрутизации 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:

# 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-запрос не виден на другом конце, но именно так это и должно работать. Основная проблема в том, что ARP-запрос вообще не должен отправляться.
  • проблема сохраняется, даже если я добавляю явный маршрут с помощью команды «route add -host 172.16.0.59 gw 172.16.1.254 dev eth0»

решение1

Это действительно ошибка ядра 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

помогает.

решение2

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

Изменение маски подсети на 255.255.0.0 решит проблему.

Можете ли вы предоставить схему. Если вы не можете нарисовать сеть, ее нельзя починить (старая поговорка сетевых инженеров... мной!).

Ваше здоровье,

Связанный контент