nickp Опубликовано 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, мне радостно сообщили что сеть длинная (через полгорода, хотя другие офисы еще дальше) и поэтому при первом пинговании могут быть задержки. Но ведь раньше то все работало. куда копать и где искать решение проблемы ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zoro Опубликовано 29 апреля, 2011 много маков- и вообще дизайн не правильный... Каждый офис-своя подсеть... ставите в каждом офисе микротик rb750G одна подсеть для маршрутизации которая ходит в сети провайдера.... Плюсы- 1) траблшутинг 2) возможность шифрации трафика(безопасность)... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yurski Опубликовано 29 апреля, 2011 Рискну предположить, что бродкасты переполнили АРП-таблицы у провайдера... Нельзя так делать, делите на подсети. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DelSt Опубликовано 29 апреля, 2011 Рискну предположить, что бродкасты переполнили АРП-таблицы у провайдера... Нельзя так делать, делите на подсети. Судя по описанию, у автора l2vpn. Т.е. ARP table у провайдера нет. p.s. Согласен с zoro - сеть каждого офиса - своя подсеть. Отдельная подсеть - то что бегает через провайдера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zoro Опубликовано 29 апреля, 2011 Рискну предположить, что бродкасты переполнили АРП-таблицы у провайдера... Нельзя так делать, делите на подсети. если L2 тунель то все маки офисной сети- проходят через все коммутаторы... а если там DES-3028 или из похожих :)... то возможен конфликт- совпадение маков... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nickp Опубликовано 30 апреля, 2011 В офисе А 49 хостов в офисе В - 3 хоста в офисе С - 2 хоста В офисе D - 6 хостов ради трех ПК ставить в офисе роутер и делать отдельную подсеть думаю нецелесообразно. Тем более что два других офиса (C, D) работают нормально) Как раз изначаль (более года назад) у нас в каждой точке был заведен интернет и стояла cisco 600 которая через инет поднимала Vpn-туннель до cisco 1700 в офисе А. Потом провайдер предожил сулуг передачи данных - все кошки убрали - завели везде оптику от провайдера включили в свои коммутаторы, переделали все на одну подсеть и с тех пор работаем. А тут уже третий день какая-то ж..па. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 30 апреля, 2011 Воткнитесь ноутом в свитч офиса B и посмотрите количество бегающего броадкаста. У оператора скорее всего он зарезан килобит до 100 и периодически полезный ARP теряется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
-Ars- Опубликовано 30 апреля, 2011 (изменено) Может и впрямь конфликт МАС-ов? Винды нигде не переставляли, когда проблема началась? А то мне очень напоминает классический глюк с ХР и сетевыми карточками SIS-900... Хотя, не, херню спорол-с, с буком же тоже проблема... Изменено 30 апреля, 2011 пользователем -Ars- Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yurski Опубликовано 30 апреля, 2011 (изменено) Воткнитесь ноутом в свитч офиса B и посмотрите количество бегающего броадкаста. У оператора скорее всего он зарезан килобит до 100 и периодически полезный ARP теряется. Или еще чудесатее - одна сетевуха периодически с ума сходит. В установке пограничного маршрутизатора в каждом офисе нет ничего "нецелесообразного", это как чистка зубов. Изменено 30 апреля, 2011 пользователем yurski Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mukca Опубликовано 3 мая, 2011 (изменено) может там у вас сетевушка есть какая нибудь глючная. или горелая или еще чего.. или колечко... железо провайдера ченибуть фильтрует а тех поддержка и не вкурсе... а может у провайдера в этом районе в сети косяк какойнибутть Изменено 3 мая, 2011 пользователем mukca Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nickp Опубликовано 4 мая, 2011 Может и впрямь конфликт МАС-ов? Винды нигде не переставляли, когда проблема началась? А то мне очень напоминает классический глюк с ХР и сетевыми карточками SIS-900... Хотя, не, херню спорол-с, с буком же тоже проблема... сеть передачи данных работает уже давно. в последнее время никаких новых устройств в сети не добавляли, ОС нигде не переставляли может там у вас сетевушка есть какая нибудь глючная. или горелая или еще чего.. или колечко... железо провайдера ченибуть фильтрует а тех поддержка и не вкурсе... а может у провайдера в этом районе в сети косяк какойнибутть глючную сетевушку я исключаю, так как своим рабочим буком со всех сторон проверяю связь, подключаюясь напрямую в кабель провайдера - везде симптомы одинаковые. вот я и склоняюсь к мысли что у провайдера в сети какой-то косяк, так как несмотря на все мои просьбы с их сотрудником проехать по их точкам размещения оборудования и проверить в каждой из них связь получаю отказ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sdy_moscow Опубликовано 4 мая, 2011 (изменено) Выкинуть не управляемое железо, поставить нормальные коммутаторы (хотя бы в офисе А) и поглядеть таблицы маков, возможно у Вас вирусня флудит. Кстати - как выглядит arp -a когда нет связи? есть ли там связка ип-мак? Изменено 4 мая, 2011 пользователем sdy_moscow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yurski Опубликовано 4 мая, 2011 сеть передачи данных работает уже давно. в последнее время никаких новых устройств в сети не добавляли, ОС нигде не переставляли глючную сетевушку я исключаю, так как своим рабочим буком со всех сторон проверяю связь, подключаюясь напрямую в кабель провайдера - везде симптомы одинаковые. вот я и склоняюсь к мысли что у провайдера в сети какой-то косяк, так как несмотря на все мои просьбы с их сотрудником проехать по их точкам размещения оборудования и проверить в каждой из них связь получаю отказ Если порт блокируется (даже автоматически), то при отключении "штормящей" подсети он моментально не заработает, так что проверка ноутом - не показатель отсутствия проблемы. Что можно проверить на промежуточных узлах провайдера (если это не цепочка неуправляемых коммутаторов)? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nickp Опубликовано 4 мая, 2011 (изменено) Выкинуть не управляемое железо, поставить нормальные коммутаторы (хотя бы в офисе А) и поглядеть таблицы маков, возможно у Вас вирусня флудит. Кстати - как выглядит 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 Изменено 4 мая, 2011 пользователем nickp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 4 мая, 2011 Значит надо забить на L2 и делать каналы между офисами по L3 а дальше уже разрулите как вам надо, тогда никаких потерь странных не будет - все у вас на виду. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 8 мая, 2011 Забить это не выход. Но на неуправляемой сети мониторить конечно сложно. Wireshark аномалий не кажет никаких? Если отключать офисы/компы небольшими группами что нибудь меняется? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 8 мая, 2011 (изменено) ... При этом в офисе В даже разыне ПК подключенные через коммутатор могут один видеть МАС и пинговаться, второй видеть МАС и не пинговаться, третий не видет МАС и не пинговаться. ... Проверяется легко и просто, со стороны 0.100 (или что там у вас) включается прослушивание трафика, одновременно на точке B чистятся арп таблицы, также запускается прослушивание и далее пинг. Наблюдаете за количеством arp who-has и arp reply, считаете сколько их на одном конце и на другом, результаты предъявляете провайдеру, при необходимости тоже самое воспроизводите их техникам. Эксперимент лучше провести в двух частях. Ч.1 это на сети как есть, Ч.2 это при включении тестовых компов напрямую в провйдерское оборудование, без своего хлама. Изменено 8 мая, 2011 пользователем dsk Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
