Я надеялся, что кто-нибудь сможет посмотреть на это и сообщить мне, что я упустил. У меня 4 машины, и по какой-то причине только одна из них может разговаривать с тремя другими через свой частный IP-адрес (на eth1).
4 машины:
mach01 10.176.193.17
mach02 10.176.193.92
mach03 10.176.193.27
mach04 10.176.195.9
Все машины - это Debian lenny. С mach02 я могу без проблем пинговать остальные 3 машины, а с других машин я могу пинговать mach02. Однако из mach01, mach03 и mach04 я могу пинговать только mach02.
Результат "iptables --list" на всех машинах:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Поэтому я не верю, что проблема в брандмауэре. Таблицы маршрутизации для eth1 на всех машинах:
10.176.192.0 * 255.255.224.0 U 0 0 0 eth1
10.191.192.0 10.176.192.1 255.255.192.0 UG 0 0 0 eth1
10.176.0.0 10.176.192.1 255.248.0.0 UG 0 0 0 eth1
Так что это тоже выглядит нормально. По какой-то причине запросы ARP не выполняются с mach03 куда угодно, кроме mach02, и аналогично для других машин.
mach03$ arping -c 1 -I eth1 10.176.193.17
ARPING 10.176.193.17
--- 10.176.193.17 statistics ---
1 packets transmitted, 0 packets received, 100% unanswered
Я не вижу причин, по которым ARP может так потерпеть неудачу, и у меня закончились идеи и места для поиска. Есть ли идеи у кого-нибудь еще с большим опытом в устранении неполадок в сети?
Спасибо
РЕДАКТИРОВАТЬ
После попытки выполнить эхо-запрос mach01 от mach03, в кэше ARP находится следующее:
$ arp -a
? (10.176.193.17) at <incomplete> on eth1
? (67.23.45.1) at 00:00:0C:07:AC:01 [ether] on eth0
И наоборот (от mach03 до mach01):
? (10.176.193.92) at 40:40:FA:77:D7:94 [ether] on eth1
? (10.176.193.27) at <incomplete> on eth1
? (67.23.45.1) at 00:00:0C:07:AC:01 [ether] on eth0
И еще подробности по eth1:
$ ip addr show dev eth1
3: eth1: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 40:40:16:e0:f3:dd brd ff:ff:ff:ff:ff:ff
inet 10.176.193.17/19 brd 10.176.223.255 scope global eth1
inet6 fe80::4240:16ff:fee0:f3dd/64 scope link
valid_lft forever preferred_lft forever
Ну, вы обесценили брандмауэр, так что
Единственное, что я могу придумать с моими крайне ограниченными знаниями в области сетевых технологий:
Работает ли 'arping' с 01.03.04 по 02, или они обновляют свой кэш arp благодаря входящим широковещательным пакетам с 02?
Прежде всего, выберите две машины, которые не могут общаться друг с другом, и сначала устраните их. Выберите один из двух, который не может разговаривать с другим, и мы воспользуемся этим.
Ваша таблица маршрутизации выглядит странно, у вас установлен флаг шлюза для двух маршрутов, второй из которых перекрывается с вашим исходным сетевым маршрутом. Вы почему-то устанавливали статические маршруты?
Прежде всего, очистите таблицу маршрутизации:
# ip route flush table all
Во-вторых, добавьте обратно в маршрут для подсети LAN только
# ip route add 10.176.192.0/19 dev eth0
Эти машины по-прежнему недоступны?
Если это не сработает, вставьте вывод
# ip addr
# brctl show
Я предполагаю, что какое-то программное обеспечение VPN / программное обеспечение виртуализации / вы или ваш коллега неправильно изменили свои маршруты.
Вы копировали / вставляли эту информацию или пытались ее ввести? У вас есть «193» в вашей сети, за исключением того, что одна машина показывает 195. Затем вы показываете 192 в ваших таблицах маршрутизации.
Это немного странно, для начала я бы попытался запустить tcpdump на mach01, mach02 и mach03, чтобы увидеть, получают ли mach01 и mach02 запрос ARP от mach03, когда вы пытаетесь пинговать mach01, отвечает ли он (для mach03) или нет и т. Д.
Знаете ли вы, что между хостами может быть прозрачный брандмауэр? Это могло бы объяснить то, что вы видите.
Какая топология сети? много ли переключений между хостами или только один? Что за переключатель?
Не могли бы вы вставить полную таблицу маршрутизации хоста с одного из хостов? Возможно, существует более конкретный маршрут для другого интерфейса.
Кроме того, не могли бы вы опубликовать вывод команды 'arp -a' сразу после одной из неудачных попыток 'arping'? Это должно показать неполную запись для IP-адреса, который вы пытались настроить на [eth1], и подтвердит, что маршрутизация вашего хоста настроена правильно.
Оказывается, я обнаружил проблему с сетью Rackspace Cloud Server. Проблема была передана на эскалацию и решена.
Хочу поблагодарить всех, кто откликнулся.