nickp Posted April 29, 2011 Есть основной офис где расположены все сервера - назовем его офис А есть еще три филиала по городу - В, С, D Везде у нас стоят неуправляемые коммутаторы 3COM 10/100/1000 всего хостов в сети порядка 60 - сеть 192.168.0.0/24 все офисы подключены к провайдеру по оптике. Провайдер предоставляет услугу передачи данных - скорее всего запихивая все наши точки в отдельный vlan - но это только мои догадки. все работало идеально. В один прекрасный момент офис В перестал видеть А - даже пинги не ходили, хотя МАК-адреса определялись. Звоню провайдеру - говорят что у них все в порядке, что наши МАКи они видят, что проблемма у нас. В офисе А подключаю свой бук вместо провайдерского медиаконвертера - пингую свои сервера - все ОК. Включаю медик обратно. Еду в офис В - подключаюсь там прямо к медиаконвертеру- пингую сервера расположенные в офисе А (или компы в офисах C,D) - "превышен интервал ожидания" запускаю Ping .... -t после пары минут такого превышения интервала пинги пошли, связь заработала, сетевые ресурсы доступны. делаю на буке arp -a -d, связь снова прерывается на пару минут, потом снова пинги пошли и снова сетевые ресуры доступны. провел точно такой же тест в двух других офисах C, D в сторону офиса А - там все идеально, даже arp -a -d не вызывает потери ни одного пакета. звоню провайдеру озвучиваю ситуацию. В результате приезжают их специалисты в А и в В - подключаются свои буки к медиаконверетрам - прописывают в них статически IP ищ моей подсети запускают на обоих буках пинги в друг друга - все идеально работает. Даже arp -a -d не вызывает потерь пакетов. На этом они и удаляются сообщая что проблемма у нас. Пробовал менять коммутаторы на другие - ничего не меняется. Пока решил проблемму так: в офисе В на каждом ПК открыл несколько cmd окошек и запустил в каждом ping ... -t до серверов из А. Пока пинги идут все работает, если пинг на любом ПК остановить, то буквально через минуту на этом ПК связи нет, а все остальные (где идут пинги) продолжают работать. озвучил провайдеру проблемму с потерями пакетов после arp -a -d, мне радостно сообщили что сеть длинная (через полгорода, хотя другие офисы еще дальше) и поэтому при первом пинговании могут быть задержки. Но ведь раньше то все работало. куда копать и где искать решение проблемы ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zoro Posted April 29, 2011 много маков- и вообще дизайн не правильный... Каждый офис-своя подсеть... ставите в каждом офисе микротик rb750G одна подсеть для маршрутизации которая ходит в сети провайдера.... Плюсы- 1) траблшутинг 2) возможность шифрации трафика(безопасность)... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
yurski Posted April 29, 2011 Рискну предположить, что бродкасты переполнили АРП-таблицы у провайдера... Нельзя так делать, делите на подсети. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
DelSt Posted April 29, 2011 Рискну предположить, что бродкасты переполнили АРП-таблицы у провайдера... Нельзя так делать, делите на подсети. Судя по описанию, у автора l2vpn. Т.е. ARP table у провайдера нет. p.s. Согласен с zoro - сеть каждого офиса - своя подсеть. Отдельная подсеть - то что бегает через провайдера. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zoro Posted April 29, 2011 Рискну предположить, что бродкасты переполнили АРП-таблицы у провайдера... Нельзя так делать, делите на подсети. если L2 тунель то все маки офисной сети- проходят через все коммутаторы... а если там DES-3028 или из похожих :)... то возможен конфликт- совпадение маков... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nickp Posted April 30, 2011 В офисе А 49 хостов в офисе В - 3 хоста в офисе С - 2 хоста В офисе D - 6 хостов ради трех ПК ставить в офисе роутер и делать отдельную подсеть думаю нецелесообразно. Тем более что два других офиса (C, D) работают нормально) Как раз изначаль (более года назад) у нас в каждой точке был заведен интернет и стояла cisco 600 которая через инет поднимала Vpn-туннель до cisco 1700 в офисе А. Потом провайдер предожил сулуг передачи данных - все кошки убрали - завели везде оптику от провайдера включили в свои коммутаторы, переделали все на одну подсеть и с тех пор работаем. А тут уже третий день какая-то ж..па. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Дегтярев Илья Posted April 30, 2011 Воткнитесь ноутом в свитч офиса B и посмотрите количество бегающего броадкаста. У оператора скорее всего он зарезан килобит до 100 и периодически полезный ARP теряется. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
-Ars- Posted April 30, 2011 (edited) Может и впрямь конфликт МАС-ов? Винды нигде не переставляли, когда проблема началась? А то мне очень напоминает классический глюк с ХР и сетевыми карточками SIS-900... Хотя, не, херню спорол-с, с буком же тоже проблема... Edited April 30, 2011 by -Ars- Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
yurski Posted April 30, 2011 (edited) Воткнитесь ноутом в свитч офиса B и посмотрите количество бегающего броадкаста. У оператора скорее всего он зарезан килобит до 100 и периодически полезный ARP теряется. Или еще чудесатее - одна сетевуха периодически с ума сходит. В установке пограничного маршрутизатора в каждом офисе нет ничего "нецелесообразного", это как чистка зубов. Edited April 30, 2011 by yurski Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
mukca Posted May 3, 2011 (edited) может там у вас сетевушка есть какая нибудь глючная. или горелая или еще чего.. или колечко... железо провайдера ченибуть фильтрует а тех поддержка и не вкурсе... а может у провайдера в этом районе в сети косяк какойнибутть Edited May 3, 2011 by mukca Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nickp Posted May 4, 2011 Может и впрямь конфликт МАС-ов? Винды нигде не переставляли, когда проблема началась? А то мне очень напоминает классический глюк с ХР и сетевыми карточками SIS-900... Хотя, не, херню спорол-с, с буком же тоже проблема... сеть передачи данных работает уже давно. в последнее время никаких новых устройств в сети не добавляли, ОС нигде не переставляли может там у вас сетевушка есть какая нибудь глючная. или горелая или еще чего.. или колечко... железо провайдера ченибуть фильтрует а тех поддержка и не вкурсе... а может у провайдера в этом районе в сети косяк какойнибутть глючную сетевушку я исключаю, так как своим рабочим буком со всех сторон проверяю связь, подключаюясь напрямую в кабель провайдера - везде симптомы одинаковые. вот я и склоняюсь к мысли что у провайдера в сети какой-то косяк, так как несмотря на все мои просьбы с их сотрудником проехать по их точкам размещения оборудования и проверить в каждой из них связь получаю отказ Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sdy_moscow Posted May 4, 2011 (edited) Выкинуть не управляемое железо, поставить нормальные коммутаторы (хотя бы в офисе А) и поглядеть таблицы маков, возможно у Вас вирусня флудит. Кстати - как выглядит arp -a когда нет связи? есть ли там связка ип-мак? Edited May 4, 2011 by sdy_moscow Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
yurski Posted May 4, 2011 сеть передачи данных работает уже давно. в последнее время никаких новых устройств в сети не добавляли, ОС нигде не переставляли глючную сетевушку я исключаю, так как своим рабочим буком со всех сторон проверяю связь, подключаюясь напрямую в кабель провайдера - везде симптомы одинаковые. вот я и склоняюсь к мысли что у провайдера в сети какой-то косяк, так как несмотря на все мои просьбы с их сотрудником проехать по их точкам размещения оборудования и проверить в каждой из них связь получаю отказ Если порт блокируется (даже автоматически), то при отключении "штормящей" подсети он моментально не заработает, так что проверка ноутом - не показатель отсутствия проблемы. Что можно проверить на промежуточных узлах провайдера (если это не цепочка неуправляемых коммутаторов)? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nickp Posted May 4, 2011 (edited) Выкинуть не управляемое железо, поставить нормальные коммутаторы (хотя бы в офисе А) и поглядеть таблицы маков, возможно у Вас вирусня флудит. Кстати - как выглядит arp -a когда нет связи? есть ли там связка ип-мак? в офисе В при подключении компа или бука arp -a ничего не выводит, тоже самое сразу после arp -a -d если запустить ping до серверов в А то сначала отображается 192.168.0.100 00-00-00-00-00-00 потом через какое-то время (через 10-15 потерь пакетов) отображается МАС адрес, но пинги при этом все еще не проходят. Еще чуть попозже отображается и МАС и пинги начинают идти. При этом в офисе В даже разыне ПК подключенные через коммутатор могут один видеть МАС и пинговаться, второй видеть МАС и не пинговаться, третий не видет МАС и не пинговаться. Через некоторое время все начинают работать, но при условии что на всех ПК запущен Ping ... -t после чистки arp -a -d - связь теряется только на компе где чистили табличку Что можно проверить на промежуточных узлах провайдера (если это не цепочка неуправляемых коммутаторов)? А ничего нельзя проверить. Со стороны офиса А проверяли с ближайшего коммутатора: в сторону А связь есть, в сторону В - нет, со стороны офиса В так же с ближайшего коммутатора в сторону В - связь есть, в сторону А - нет. Дальше проверять провайдер не дает ссылаясь на то что там магистральыне каналы по которым работают многие абоненты и поэтому там он технически вытащить наш vlan и вывести на отдельный порт для проверки с бука не может Если порт блокируется (даже автоматически), то при отключении "штормящей" подсети он моментально не заработает, так что проверка ноутом - не показатель отсутствия проблемы. Вряд ли порт блокируется, потому как тогда бы пропадала связь на всех ПК в офисе В, а если пинги из В в А идут то связь есть. Связь теряется только на тех ПК где либо перегружаю ПК либо перевтыкаю UTP либо чищу arp -a -d Edited May 4, 2011 by nickp Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Saab95 Posted May 4, 2011 Значит надо забить на L2 и делать каналы между офисами по L3 а дальше уже разрулите как вам надо, тогда никаких потерь странных не будет - все у вас на виду. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
xcme Posted May 8, 2011 Забить это не выход. Но на неуправляемой сети мониторить конечно сложно. Wireshark аномалий не кажет никаких? Если отключать офисы/компы небольшими группами что нибудь меняется? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
dsk Posted May 8, 2011 (edited) ... При этом в офисе В даже разыне ПК подключенные через коммутатор могут один видеть МАС и пинговаться, второй видеть МАС и не пинговаться, третий не видет МАС и не пинговаться. ... Проверяется легко и просто, со стороны 0.100 (или что там у вас) включается прослушивание трафика, одновременно на точке B чистятся арп таблицы, также запускается прослушивание и далее пинг. Наблюдаете за количеством arp who-has и arp reply, считаете сколько их на одном конце и на другом, результаты предъявляете провайдеру, при необходимости тоже самое воспроизводите их техникам. Эксперимент лучше провести в двух частях. Ч.1 это на сети как есть, Ч.2 это при включении тестовых компов напрямую в провйдерское оборудование, без своего хлама. Edited May 8, 2011 by dsk Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
