Форум системных администраторов
IT => Networks => Тема начата: Sharp22 от 26 января 2011, 16:31:29
-
Есть проблема, которую не могу решить уже несколько недель.
Итак
1. локальная офисная сеть 2 свича по 24 порта
2 DC на Win2003 он же файл серевер, DNS, DHCP
3 резервный DC он же сервер приложений и локальный веб сервер,
4 linux шлюз к провайдеру он же почтовый и внешний веб,
5 около 50 рабочих станций Win XP.
6 сетка wi-fi . защищенная естественно, 3 точки доступа
Периодически отваливаются от сетки сервера. Причем и win и linux .. не имеет значения. Время отвала от нескольких секунд то пары минут. Выглядит так ... с рабочей станции нет пинга на один из серверов , но в это же время с нее другие пингуются нормально. И в это же время сервер нормально пингуется с других станций. Сеть может несколько дней работать без проблем, потом пол дня сплошние отвалы и вопли пользователей.
На всех станция есть Касперский. Его отключение и отключение DIS фильтра в сетевом соединении ничего не дало
Замена свича , ближайшего к серверам ничего не дало
Проблема проявляется в обеих частях офиса , то есть за обоими свичами.
dcdiag и netdiag ничего криминального не кажут.
Куда копать уже и не знаю... дайте идею..
-
... с рабочей станции нет пинга на один из серверов , но в это же время с нее другие пингуются нормально. И в это же время сервер нормально пингуется с других станций.
что то непонятно
а с сервера клиенты пингуются? если с других клиентов эти сервера пингуются, а с этого нет, то может проблема в этом клиенте, с которого не пингуются? ???
-
Выглядит так ... с рабочей станции нет пинга на один из серверов , но в это же время с нее другие пингуются нормально. И в это же время сервер нормально пингуется с других станций.
То есть клиент перестает видеть именно сервер?
IP-адреса случайно не пересекаются в сети? Через wi-fi IP-адреса как выдаются?
-
С драверами и их настройками на серврере и клиентах поэкспериментируйте. Я тут недавно офигел от всякого, процитирую себя же:
б..ь сегодня майкрософт такой майкрософт, просто е...ся... На 2003 постоянно system log is corrupted. Торможу службу event log, после перезагрузки удаляю лог целиком - некоторое время все нормуль, потом те же лыжи. Чекаю диск с ливцд - всё пучком. Повторяю операцию - грабли вскоре на месте. Начинаю гуглить - первая или вторая ссылка гугла (sic!) в настройках адаптера принудительно выставьте full duplex. Ну что ж, делаю так - и чо всё пучком шурупит уже полдня. Чота я не понимаю в этой жизни :(
И до сих пор работает, только влёт. От оно чё, Михалыч...
-
На 2003 постоянно system log is corrupted
Какое это имеет отношение к "отваливанию" сети? :)
-
На 2003 постоянно system log is corrupted
Какое это имеет отношение к "отваливанию" сети? :)
Хороший вопрос, Сирёжа! Но это крайний пример, когда сетевой интерфейс влияет на всякое разное. А уж на "отваливание" сети он вроде как вполне может иметь прямое отношение ;) Я не гарантирую, но так, даю направление мысли тэксказать!
-
Выглядит так ... с рабочей станции нет пинга на один из серверов , но в это же время с нее другие пингуются нормально. И в это же время сервер нормально пингуется с других станций.
То есть клиент перестает видеть именно сервер?
IP-адреса случайно не пересекаются в сети? Через wi-fi IP-адреса как выдаются?
Адреса выдаются DHCP на DC и в том числе для wi-fi. Сообщений о конфликтах адресов я не наблюдал и пользователи молчат. Для них это выглядит как отвалившейся сетевой диск. Во многих случаях они вообще не замечают временного отвала... Ну если файл по сетке не открыт.
Действительно резонно предположить что дело не в серверах а в клиентах,.. но там обычная XP , которая обновляется через WSUS.
-
Все же на свич сильно похоже. А можно топологию нарисовать?
-
Все же на свич сильно похоже. А можно топологию нарисовать?
свич , ближайщий с серверам менял. Топология простая ... два свича связанных каналом 1 г.б (сечас переключил на 100 m b) Сервера подключены к одному из них. Пользователи равномерно распределены по портам. Wi-Fi три точки подключены к свичам и покрывают офис и одновременно служат свичами для сетевых принтеров (5 штук).
-
Sharp22, давай чтобы было проще всем
dcdiag с двух серверов в студию
эвенты на серверах есть какие с ошибками?
какие адреса кому выделяются на DHCP
-
Пользователи равномерно распределены по портам
По портам обоих свичей?
-
Пользователи равномерно распределены по портам
По портам обоих свичей?
Да.. приблизительно пополам. Завтра отключу wi-fi от сетки....понаблюдаю что из этого выйдет. Переживут юзера денек без wi-fi. И логи по dcdiag то же уже завтра.
-
По портам обоих свичей?
Ну если бы было кольцо, то такой эффект был бы постоянно...
-
Если бы не линух, я бы еще на вирусы подумал, а так, что-то колдунство какое-то.
ipconfig /all еще бы посмотреть с серверов.
-
Если бы не линух, я бы еще на вирусы подумал, а так, что-то колдунство какое-то.
А причем тут Линух на шлюзе? Вирусы не только из интернетов появляются.
-
Fray, ну автор говорит, что отваливаются все серверы и линух в том числе, насколько я понял.
-
отваливаются все серверы и линух в том числе, насколько я понял.
Перечитал стартпост. Да, точно...
-
Если бы не линух, я бы еще на вирусы подумал, а так, что-то колдунство какое-то.
ipconfig /all еще бы посмотреть с серверов.
Линух то чем не угодил. да вроде как и Касперский стоит.
Ещё вопрос. При отключении Linux сервера, он снаружи виден, как веб-сервер? Сайт отсается на месте?
Если да - то рыть в сторону DHCP и роутинга.
-
Я бы смотрел на линк между свитчами и коммуникационное железо. Свитчи управляемые? Соединение между свитчами витой парой? Если да, то сколько метров?
-
Линк между свитчами витая пара метров 50. Ранее работал на 1 гб , сейчас переключил на 100 мб. Железки не управляемые , старые железки.
Отчет dcdiag c DC:
Domain Controller Diagnosis
Performing initial setup:
Done gathering initial info.
Doing initial required tests
Testing server: Default-First-Site-Name\SRV-DC-1
Starting test: Connectivity
......................... SRV-DC-1 passed test Connectivity
Doing primary tests
Testing server: Default-First-Site-Name\SRV-DC-1
Starting test: Replications
......................... SRV-DC-1 passed test Replications
Starting test: NCSecDesc
......................... SRV-DC-1 passed test NCSecDesc
Starting test: NetLogons
......................... SRV-DC-1 passed test NetLogons
Starting test: Advertising
......................... SRV-DC-1 passed test Advertising
Starting test: KnowsOfRoleHolders
......................... SRV-DC-1 passed test KnowsOfRoleHolders
Starting test: RidManager
......................... SRV-DC-1 passed test RidManager
Starting test: MachineAccount
......................... SRV-DC-1 passed test MachineAccount
Starting test: Services
NtFrs Service is stopped on [SRV-DC-1]
......................... SRV-DC-1 failed test Services
Starting test: ObjectsReplicated
......................... SRV-DC-1 passed test ObjectsReplicated
Starting test: frssysvol
......................... SRV-DC-1 passed test frssysvol
Starting test: frsevent
......................... SRV-DC-1 passed test frsevent
Starting test: kccevent
......................... SRV-DC-1 passed test kccevent
Starting test: systemlog
......................... SRV-DC-1 passed test systemlog
Starting test: VerifyReferences
......................... SRV-DC-1 passed test VerifyReferences
Running partition tests on : ForestDnsZones
Starting test: CrossRefValidation
......................... ForestDnsZones passed test CrossRefValidation
Starting test: CheckSDRefDom
......................... ForestDnsZones passed test CheckSDRefDom
Running partition tests on : DomainDnsZones
Starting test: CrossRefValidation
......................... DomainDnsZones passed test CrossRefValidation
Starting test: CheckSDRefDom
......................... DomainDnsZones passed test CheckSDRefDom
Running partition tests on : Schema
Starting test: CrossRefValidation
......................... Schema passed test CrossRefValidation
Starting test: CheckSDRefDom
......................... Schema passed test CheckSDRefDom
Running partition tests on : Configuration
Starting test: CrossRefValidation
......................... Configuration passed test CrossRefValidation
Starting test: CheckSDRefDom
......................... Configuration passed test CheckSDRefDom
Running partition tests on : office
Starting test: CrossRefValidation
......................... office passed test CrossRefValidation
Starting test: CheckSDRefDom
......................... office passed test CheckSDRefDom
Running enterprise tests on : office.xxxxxxxx.spb.ru
Starting test: Intersite
......................... office.xxxxxxxx.spb.ru passed test Intersite
Starting test: FsmoCheck
......................... office.xxxxxxxx.spb.ru passed test FsmoCheck
=============
Не вижу в нем криминала.
Посмотрел логи DHCP так же вроде все штатно.. Сервера прописаны статическими адресами и находятся вне диапзона раздачи DHCP
Сегодня с утра сетка работает без сбоев.... понаблюдал пару часов , потом отключил от сетки все точки доступа wi-fi и снова пару часов без проблем.... Но такое было уже не раз.... потом снова могут начаться чудеса..... ((((
-
У вас все компьютеры в "спокойные дни" работали?
-
У вас все компьютеры в "спокойные дни" работали?
Когда юзеров в офисе много, то и вероятность жалоб больше. Но бывали дни , когда офис почти полон , а все работает нормально. Сегодня средняя заполненность в офисе , но сбоев пока нет.
-
эвенты на серверах есть какие с ошибками?
-
эвенты на серверах есть какие с ошибками?
На DC логи практически чистые... Отвалился было источник точного времени... пофиксил... думаю что это не критично
На резервном DC в логах приложений проскакивает ошибка что "Windows не может получить доступ к файлу GPT.INI" , что на мой взгляд и не удивительно при отваливающимся основном DC. Мне кажется что это скорее следствие , а не причина. Надо сказать что и ранее проскакивали такие ошибки , но сейчас они явно участились. Но что интересно, судя по этим ошибкам, похоже проблема с доступом к серверам существует и ночью, когда компы юзеров выключены. Остается только сами сервера и инфраструктура... Собственно поэтому сетку wi-fi сегодня и отрубил..... Пока все работает....
-
Собственно поэтому сетку wi-fi сегодня и отрубил..... Пока все работает....
А на wi-fi точках своего dhcp точно нет? :)
-
Собственно поэтому сетку wi-fi сегодня и отрубил..... Пока все работает....
А на wi-fi точках своего dhcp точно нет? :)
Есть , но естественно отключен на всех трех... Точки D-Link (wan-lan-wifi) Как роутер не используются , только lan и wi-fi.
-
Есть , но естественно отключен на всех трех
Я бы на всякий случай проверил... Что-то у меня мысля только в ту сторону идет :)
-
Есть , но естественно отключен на всех трех
Я бы на всякий случай проверил... Что-то у меня мысля только в ту сторону идет :)
То что отключено..... (установлено disable в web морде ) это 100%. Но D-Link это особая песня, поэтому пока просто физически отключил все три точки.
-
Проблемный сервер один? Или пропадают пинги не только до него, а и до других девайсов?
-
Проблемный сервер один? Или пропадают пинги не только до него, а и до других девайсов?
Нет , проблема не на одном сервере.... с другими серверами так же проблема. Я все больше склоняюсь к мысли что проблема на уровне ARP протокола... Именно там кешируются IP и MAC адреса. Только некорректным кешем я могу объяснить что сервер одновременно с одних машин доступен, а с других нет. Но пока проверить не версию не получается ... второй день сеть работает нормально.... ждемс )))
-
тогда врубаем session monitor на порты проблемных серверов, включаем вайршарк и ждем результатов.
-
Все... разобрался с причинах сбоев сети. Yes!!! :tease: Итак причиной был телефон одного из сотрудников, который был подключен по wi-fi к локальной сети. Механизм сбоя видимо следующий. Телефон отвечал на широковещательные запросы протокола ARP и его MAC попадал в кеш arp рабочих станций. Во всяком случае , при просмотре кеша во время сбоя там оказывался MAC адрес телефона , который соответствовал ip сервера. После очистки кеша все вставало на место, до следующего глюка. Самое прикольное что у меня точно такой же телефон и так же подключен к сетке и проблем с ним нет. Вот такие дела.... поосторожнее надо с телефонами сотрудников !! Два месяца потраченных нервов и куча времени.
-
Во всяком случае , при просмотре кеша во время сбоя там оказывался MAC адрес телефона , который соответствовал ip сервера
Значит за этим mac-адресом зарезервирован этот ip. Настройки DHCP проверить не желаете?
-
Во всяком случае , при просмотре кеша во время сбоя там оказывался MAC адрес телефона , который соответствовал ip сервера
Значит за этим mac-адресом зарезервирован этот ip. Настройки DHCP проверить не желаете?
Ага .. и таких ip штук пять... или шесть )) Эти ip принадлежат серверам , прописаны статически и находятся вне зоны раздачи DHCP. Да и с какого перепугу DHCP будет вмешиваться в arp кеш. У телефона кстати так же был прописан статический ip.
Да и ... тему с начала прочитать не желаете ?
-
Да и ... тему с начала прочитать не желаете ?
Перечитал раза 3. Упоминания про то, что "У телефона кстати так же был прописан статический ip", не увидел, зато увидел следующее: Адреса выдаются DHCP на DC и в том числе для wi-fi
Да и с какого перепугу DHCP будет вмешиваться в arp кеш.
В arp-кэш он не вмешивается, а вот выдать адрес, который используется другим устройством, может. Ну, а если у вас в сети окажется более одного ус-тва с одним и тем же ip то, что поизойдет, когда компьютеры ,будут по arp-протоколу запрашивать mac для такого IP-адреса?
ЗЫ Кстати, вспомнил, что доводилось как-то наблюдать похожую картину, которая проявлялась немного по другому: компьютеры в сети медленно, но верно, один за другим стали рапортовать о том, что такой адрес уже используется в сети. Оказалось, что у всех у них был "отравлен" arp кэш. Виновником оказался простенький маршрутизаторе D-Link (DI-804HV, если память мне не врет), через который сеть выпускали в интернет. Он банально перегревался (жаркое лето, некондиционируемое помещение) и начинал флудить, в результате со временем arp-кэш компьютеров принимал такой вид: <любой_IP> - <mac-адрес D-Link'а>.
Upd.
-
В arp-кэш он не вмешивается, а вот выдать адрес, который используется другим устройством, может. Ну, а если у вас в сети окажется более одного ус-тва с одним и тем же ip то, что поизойдет, когда компьютеры ,будут по arp-протоколу запрашивать mac для такого IP-адреса?
Если DHCP выдает адрес который уже используется, то это не DHCP , а полная фигня. ))) DHCP как раз и нужен что бы отработать подобные коллизии и раздавать свободные адреса .
Что касается телефона, то там OS Android и что ему взбрело так странно работать с ARP я пока сказать не могу. Тем более что телефон не мой и копаться в его настройках я права не имею. Пока только запретил пользователю включать на нем wi-fi в офисе.
-
Если DHCP выдает адрес который уже используется, то это не DHCP , а полная фигня. ))) DHCP как раз и нужен что бы отработать подобные коллизии и раздавать свободные адреса .
Для чего он нужен - понятно. Впрочем, так же, как и то, что при определенных настройках dhcp может выдать адрес, который уже присвоен другому устройству. Например, если рассмотреть такую ситуацию: имеется dhcp, настроенный для раздачи адресов в определенном диапазоне, а так же имеется некое устройство со статичским адресом, который принадлежит этому диапазону. К нессчастью, это устройство со статическим адресом переодически оказывается выключенным. Может ли dhcp выдать адрес в аренду, который совпадет с этим статическим адресом?
-
Если DHCP выдает адрес который уже используется, то это не DHCP , а полная фигня. ))) DHCP как раз и нужен что бы отработать подобные коллизии и раздавать свободные адреса .
К нессчастью, это устройство со статическим адресом переодически оказывается выключенным. Может ли dhcp выдать адрес в аренду, который совпадет с этим статическим адресом?
ППКС
-
Может ли dhcp выдать адрес в аренду, который совпадет с этим статическим адресом?
Можно видимо придумать много различных ситуаций, в которых видны ошибки админа. )))
DHCP выдать такой IP может, но при этом должен запуститься механизм разрешения конфликтов IP адресов, который в свою очередь, должен привести к временному исключению этого IP из пула адресов выдаваемых в аренду. Так что это не проблема DHCP , а проблема администрирования сетки. Я для себя вывел три правила и пока они меня не подводили.
1.Юзер не должен иметь возможности самостоятельно изменять сетевые настройки .
2. Естественно не нужно назначать статичеcкие IP из диапазона раздачи DHCP.
3. Использовать резервирование адресов в DHCP для серверов, принтеров и прочих подобных устройств.
Я допускаю, что в моей ситуации механизм разрешения конфликтов IP мог давать сбои со стороны телефонного Android и провоцировать чехарду с кэшем ARP, но настройки DHCP тут совсем не причем.