Итак, очередная неприятная непонятность. После некоторой борьбы с запросами от роутера (DLINK-824) "ICMP redirect" отрубил от него внешние интерфейсы серверов, которые могли в Инет напрямую при необходимости смотреть (пожертвовал своим удобством). Теперь роутер бомбит только точку доступа в Инет, но, пока, фиг с ним.
А вот что не фиг. Сейчас два сервера смотрят внешними интерфейсами друг на друга. И никого там больше быть не может. Но куда же без чудес... Начал чудесатить ping. А именно:
1. С сервера А пингуем внутренний (локальная сеть) интерфейс сервера Б. Отклик есть.
2. С сервера А пингуем внешний (уже чисто кластерный) интерфейс сервера Б. Отклик есть.
3. С сервера Б пингуем внутренний (локальная сеть) интерфейс сервера А. Отклик есть.
4. 2. С сервера Б пингуем внешний (уже чисто кластерный) интерфейс сервера А. Индейское национальное жилище. Причем tcpdump, повешенный на внешний интерфейс сервера A, показывает, что icmp_request'ы приходят. Но вот ответов на них не порождается никаких. Полный молчок.
Первым делом проверил межсетевой экран. Криминала нет. Более того, вбил первым правилом -A INPUT -j ACCEPT и соответственно OUTPUT тоже не под запретом стоит. Серверу наплевать на это, не хочет отвечать, хоть убейся...
Может подскажете, где собака могла зарыться...
-------------------------------------------
Очень похоже, что сервер А наелся таки ICMP redirect'ов... А именно - в arp-таблицах живет неубиенно адрес нагадившего роутера:
192.168.41.1 (incomplete) eth1
Причем эта CENSORED там появляется сразу, стоит только к этому интерфейсу обратиться... В результате имеем:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
23:07:48.218335 IP 192.168.41.6 > 192.168.41.4: ICMP echo request, id 50204, seq 1, length 64
23:07:48.219519 ARP, Request who-has 192.168.41.1 tell 192.168.41.4, length 28
23:07:49.218358 IP 192.168.41.6 > 192.168.41.4: ICMP echo request, id 50204, seq 2, length 64
23:07:49.219378 ARP, Request who-has 192.168.41.1 tell 192.168.41.4, length 28
Система начинает искать этот роутер (192.168.41.1), успешно его не находит. После чего ничего и не отправляет запросившему.
Как эту заразу вычистить?
--------------------------------------------
Зараза вычислена и вычищена. Собака зарылась в не совсем привычном поведении дефолтных правил, добавляемых в дополнительные таблицы маршрутизации по ip rule. К сожалению описания этой фичи (или баги, не знаю) в "советах - делай так" я не встречал. Потому и плясал на грабле ничего не понимая...
