Да, есть банальное объяснение этой мистике. Если ваш 172.16.10.1 вообще ни на какие пинги не отвечает, то он просто дропает ICMP траффик.

Отвечает, в том и дело, рядом стоят компьютеры которым он прекрасно отвечает..

А чем эти компы отличаются от тех? Их айпи той же подсети? АДСЛ-модем не имеет правил на дроп для специфических сегментов?

Ну и в целом, только пинги не ходят ведь, да? Остальной траффик?

Компы ничем не отличаются, ну разве что, они конечно не братья-клоны, но с точки зрения адресации ничем не отличаются, сегмент один - 172.16.10.0/255.255.255.0. С тех компьютеров, с которых не ходят пинги и внутрисетевые ресурсы не доступны, tracert молчит как партизан.

Модем никаких правил для дрования иметь не должен, я на клиентах очищал таблицу маршрутов, откл/вкл сеть, клиент получал другой IP и все равно пинги и трафик не идет к 172.16.10.1.

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

И так, по порядку:

1) разобраться в топологии сети;

2) разобраться с сетевим оборудованием - забьіть что такое хабьі и вьікинуть их, т.к. минимально допустимьій уровень для современной локальной сети - неуправляемьій свич;
3) с теми 3-4 компами только с пингом проблемьі? проверить внимательно адреса, маски, гейт;
4) vpn какой?
5) по команде tracert понял, что рабочие станции под Windows... есть такая чудесная команда "netsh winsock reset catalog", что делает єто в поисковике найдете - обічно вьілечивает сетевой ступор (при условии, что проблем нет в предьідущих пунктах).

Спасибо за советы.. будем смотреть, завтра возьму свой 24-портовый, воткну заместо мелкого, кстати я по привычке написал "хаб", на самом деле конечно тупые неуправляемые свитчи D-Link. Штук 5 ил на площади, где достаточно одного 24-портового.

VPN честно говоря и не знаю какой, мне в головном офисе сказали "не трогай этот модем, это туннель реализованный по технологии VPN".. Кстати, как таковой топологии сети нет, это общая шина изображенная в ужасной вариации..

Если бы у вас была петля 2-го уровня ( A->B->C->A ), то ничего бы не пинговалось ;)

А вообще советы дельные. Остановить панику и проверять все.
С проблемных компов проверить мак шлюза, сверить его с маком который видят нормальные компы. Если проблемные компы мак невидят впринципе - думать топологию, если видят, но не мингуют - думать софт (файерволы антивирусы и пр.)

Проблема явно не софтовая, у меня тут было совпадение/неСовпадение я незнаю, также в бухгалтерии был недоступен 172.16.10.1, я залез под стол, отрыл мелкий хаб, вкл/выкл - заработало на одном компе, на втором так и не пингуется.. что-то с сетью мне кажется..

Говорю же - смотреть мак. Хаб неможет отличить арп от ицмп, соответственно если мы видим мак - значит арп пролетел и проблема не в хабе. Если мак невидно то видимо арп не пролетел и тогда можно думать на хаб.

Завтра посмотрю вывод команды arp -a на этих компьютерах.. Спасибо =)

а есть доступ к интерфейсу модема? если есть - пингани проблемную машинку

Доступ будет наверное только в мой выходной день. Итак, отписываюсь о результатах исследования. Команда netsh winsock reset catalog никакого результата не дает. Далее отчет с компьютера, с которого не ходят пинги:C:\Documents and Settings\User>arp -a

Интерфейс: 172.16.10.25 --- 0x50002
Адрес IP Физический адрес Тип
172.16.10.1 00-00-00-00-00-00 недопустимый
172.16.10.12 00-e0-4c-16-11-29 динамический, на соседнем компьютере вдруг нарисовалась такая же картинаC:\Documents and Settings\User>arp -a

Интерфейс: 172.16.10.136 --- 0x2
Адрес IP Физический адрес Тип
172.16.10.1 00-00-00-00-00-00 недопустимый
172.16.10.2 00-e0-52-a7-9a-a5 динамический
172.16.10.12 00-e0-4c-16-11-29 динамический
172.16.10.25 70-71-bc-0b-c9-d9 динамический а вчера все работало. В то же время из-под ssh с линукс-хоста все хосты в сети прекрасно видно:# arp
Address HWtype HWaddress Flags Mask Iface
172.16.10.1 ether 00:15:c7:5f:d6:0e C eth1
172.16.10.15 ether 00:1c:c0:0a:0f:26 C eth1
172.16.10.10 ether 00:1c:c0:5a:21:e1 C eth1
172.16.10.14 ether 00:1c:c0:5a:33:1f C eth1
172.16.10.25 ether 70:71:bc:0b:c9:d9 C eth1
172.16.10.136 ether 70:71:bc:0b:ca:11 C eth1
172.16.10.11 ether 00:1c:c0:5a:22:4c C eth1
172.16.10.12 ether 00:e0:4c:16:11:29 C eth1
172.16.10.19 ether 00:19:66:2c:4e:a1 C eth1
172.16.10.13 ether 00:50:ba:53:49:aa C eth1
172.16.10.16 ether 00:1c:c0:0a:0f:18 C eth1


# ping 172.16.10.1
PING 172.16.10.1 (172.16.10.1) 56(84) bytes of data.
64 bytes from 172.16.10.1: icmp_seq=1 ttl=255 time=10.0 ms
64 bytes from 172.16.10.1: icmp_seq=2 ttl=255 time=10.2 ms
64 bytes from 172.16.10.1: icmp_seq=3 ttl=255 time=10.9 ms
64 bytes from 172.16.10.1: icmp_seq=4 ttl=255 time=10.7 ms
64 bytes from 172.16.10.1: icmp_seq=5 ttl=255 time=9.92 ms
64 bytes from 172.16.10.1: icmp_seq=6 ttl=255 time=10.6 ms
64 bytes from 172.16.10.1: icmp_seq=7 ttl=255 time=10.7 ms
64 bytes from 172.16.10.1: icmp_seq=8 ttl=255 time=12.1 ms
64 bytes from 172.16.10.1: icmp_seq=9 ttl=255 time=9.99 ms
64 bytes from 172.16.10.1: icmp_seq=10 ttl=255 time=14.6 ms
64 bytes from 172.16.10.1: icmp_seq=11 ttl=255 time=9.71 ms
64 bytes from 172.16.10.1: icmp_seq=12 ttl=255 time=10.3 ms
64 bytes from 172.16.10.1: icmp_seq=13 ttl=255 time=10.9 ms
64 bytes from 172.16.10.1: icmp_seq=14 ttl=255 time=10.8 ms
64 bytes from 172.16.10.1: icmp_seq=15 ttl=255 time=10.4 ms
64 bytes from 172.16.10.1: icmp_seq=16 ttl=255 time=10.2 ms
64 bytes from 172.16.10.1: icmp_seq=17 ttl=255 time=10.8 ms
64 bytes from 172.16.10.1: icmp_seq=18 ttl=255 time=11.5 ms
64 bytes from 172.16.10.1: icmp_seq=19 ttl=255 time=10.1 ms
^C
--- 172.16.10.1 ping statistics ---
19 packets transmitted, 19 received, 0% packet loss, time 18028ms
rtt min/avg/max/mdev = 9.715/10.808/14.685/1.084 msПроверил настройки, выдаваемые DHCP-сервером компьютерам, все правильно, задал статически - картинка та же..

А самое интересное произошло после. Я поднимаюсь к себе в кабинет, чтобы написать этот пост, открываю Welinux, а мне фиг, нет инета. Я пробую пинговать linux-шлюз 172.16.10.2, не пингует, для эксперимента пробую пинговать 172.16.10.1 - не пингует, смотрю вывод arp - такие же нулевые мак-адреса, помеченные как "недопустимый" для обоих адресов. После этого включаю/выключаю сетевое соединение, как только компьютер получил адрес - я запускаю arp -a, тут корпоративный касперский отчитывается, что cmd.exe выполнила какую то недопустимую операцию и удаляет ее, помещает в карантин, из которого я без корпоративного пароля ее и восстановить то не могу. Что-то меня все эти внезапные глюки нашей сети совсем не радуют..

Ну так что, какие результаты?!

Пока никаких, я бы отписался уже =) В планах на февраль закупить 3 24-портовых свитча с парой гигабитных портов на каждом и перетянуть сеть, сделав ее более прозрачной и простой. Зато выявлена закономерность: чем больше компьютеров включено, тем больше вероятности вот такой вот ошибки, недоступности. Мне друг сказал, что мелкие свитчи D-link, какие у нас сейчас стоят, 5-типортовые в основном при глюках порта могут устраивать arp-срач в сеть, и если на порту 172.16.10.1 стоит какой то файрвол, то он может нас блокировать из-за этих вот неверных arp..

Сейчас пошел загрузился с диска Arch Linux, включил DHCP, адрес получил, пингует все, кроме 172.16.10.1. Какая то проблема с сетью получается..

Дожили.. и я уже без внутрисети, не идет и все пинг, а задаю статикой адреса - меня шлюз по роутам на 172.16.10.1 гонит.. уууу..

Железо у нас все еще в стадии "заказывается", а я заметил странную закономерность. Когда я утром прихожу и "прозапас" перезапускаю ADSL-модем, то пинги как не шли так и не идут, но.. после перезапуска сетевых карточек на клиентах пинги начинают ходить и внутрисеть работает. То же самое с моим линукс-компьютером, пинга нет.. перезапуск сети - пинг есть.. Что бы это значило, непонимаю..

Всем снова привет!
В общем ситуация решена так или иначе. Методом тестов/проб/и/ошибок я пришел к выводу, что скорее всего проблема со стороны провайдера, адрес 172.16.10.1 находился в нашем броадкасте, то есть всяк мог пойти на него напрямую и видимо его это не устраивало и он начинал блокировать хосты в сети. Просмотр ARP-запросов в сети показал, что он отвечает на запросы когда ему вздумается, а если уже не ответил - хост игнорируется довольно долго.

В итоге было принято решение изолировать броадкаст сети от этого адреса, иными словами - занатить мою сеть от него. Были проведены подготовительные работы по исправлению конфигов, созданию их новый версий. После этого я вставил 3ю сетевую карточку, кинул кабель, заменил конфиги и проверил работу. Работа пошла после устранения пары ошибок при смене конфигурации, далее прокинут кабель уже был в кабельканале, закреплено, опечатано. =) В общем что это дало.. Это дало то, что с адресом 172.16.10.1 общается сейчас только мой линуксШлюз, который имеет адрес 172.16.10.2. Клиенты сети ходят во внутреннюю Сеть организации только через NAT этого линуксШлюза. Уже работаем третью неделю - падений не было. В принципе решение не такое как хотелось бы, но оно более классическое. ЛинуксШлюз сейчас выступает в роли рулевого между 3мя направлениями: локальнаяСеть, корпоративнаяСеть, Интернет. Все что идет из локально сети так или иначе идет через свой NAT. Допилил еще и по другим вопросам. Сейчас линуксШлюз выдается всем как шлюз, DNS, DHCP-сервер.

Тьфу-тьфу-тьфу.. будем надеяться и верить, потому что у такой организации сети есть один мелкий недостаток, если линуксШлюз не достучится до 172.16.10.1 - полянут все. Но, с другой стороны, тогда можно твердо заявить, что проблема у провайдера. Вот такие дела, ставлю <�Решено> =)