ошибка маршрутизации в 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

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

— Balázs Pozsár
источник

Я думаю, что это какое-то поведение по умолчанию, давайте посмотрим таблицу ARP тоже? Таблица arp другого конца может быть полезна здесь.

— SpacemanSpiff

Как вы это исправите? Помогает ли снова установить маршрут на конкретном хосте? Интересно, если вы каким-то образом получаете перенаправление ICMP, которое заставляет хост думать, что назначение является локальным.

— Пол

Похоже, ответ arp не возвращается. Можете ли вы tcpdump на хосте 172.16.0.59? Это гость? Проверьте сетевой трафик на хосте также.

— AndreasM

Можете ли вы опубликовать вывод ifconfig -a? У вас есть другие интерфейсы / IP-адреса, назначенные этому хосту?

— Халед

я обновил вопрос с ответами

— Balázs Pozsár

Ответы:

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

помогает.

— Balázs Pozsár
источник

к сожалению, вышесказанное, похоже, не помогает ..

— sivann

попробуйте сделать это для всех интерфейсов: найдите / proc / sys / net -name accept_redirects |, читая x; do echo -n 0> $ x; сделано, или, может быть, у вас есть другая ошибка

— Balázs Pozsár

Спасибо, я уже включил его для всех интерфейсов. IP-адреса взяты из туннелей IPSEC (у этого компьютера их сотни), и их всегда 5-10 (172.x), перечисленных в таблице arp в интерфейсе eth0, указанном с (неполным) HWaddress и отсутствующим HWtype. Те, кажется, истекают, и новые заменяют их, но иногда требуется перезагрузка.

— Сиванн

-1

172.16.XX Маска подсети по умолчанию - 255.255.0.0, вы изменили ее на 255.255.255.0. Итак, вещи хостов 172.16.0.x и 172.16.1.x находятся в разных подсетях. таким образом он попытается и МАРШРУТ это через шлюз по умолчанию.

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

Можете ли вы предоставить диаграмму. Если вы не можете нарисовать сеть, это не может быть исправлено (старые сетевые инженеры говорят мне ...).

Ура,

— Уникс Дворник
источник

Какое веб-приложение или облегченное настольное приложение вы бы порекомендовали для рисования сетевых диаграмм?

— Бельмин Фернандес

это не имеет ничего общего с тем, что обычно представляет собой маска по умолчанию. в любом случае, смотрите мой ответ выше.

— Balázs Pozsár

Спасибо за оценку вниз. Итак, почему вы думаете, что маршрутизатор генерирует перенаправления icmp.

— Unix Дворник

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

— Дворник Unix

Пожалуйста, прочитайте темы, связанные в принятом ответе. Проблема в том, что эта информация о маршрутизации не отбрасывается, даже если она должна быть. Это не проблема с маршрутизатором / шлюзом.

— Balázs Pozsár