Отказ от ответственности: я разработчик, а не системный администратор, будьте осторожны.
Там, где я работаю, у нас периодически возникают проблемы с сетью. Иногда DNS не работает, но доступ к серверам может быть выполнен через IP, иногда доступ через IP не удается. Насколько мы можем судить, ничего не было изменено на серверах, брандмауэрах, управляемых коммутаторах и т. Д. Кроме того, к сожалению, сбои не вызывают проблем у всех пользователей все время, но, насколько мы можем судить, все пользователи были проблемы в какой-то момент.
Наш внутренний системный администратор в данный момент недоступен, поэтому разработчики должны попытаться что-то выяснить.
Итак, учитывая, что я почти ничего не понимаю, с чего мне начать?
Обновить
Я пробовал комбинацию tracrt / ping, и похоже, что это внутренняя проблема. Внешний вид кажется довольно последовательным, но внутренние биты оказываются нестабильными.
Traceroute до интернет-сайта, о котором вы знаете, будет работать. например, google.com. Затем запустите постоянный пинг для 3 целей: вашего маршрутизатора, шлюза по умолчанию маршрутизатора и google.com.
Это должно, по крайней мере, сказать вам, теряете ли вы какие-либо пакеты по пути или проблема в вашем Интернете или внутренней сети.
После этого отправьте ответ, если / когда вы получите следующий ответ.
Похоже, что-то где-то разрывает соединения.
Лучшим советом будет выследить вашего системного администратора, вот почему он / она там ...
Похоже, у вас либо плохой интерфейс на коммутаторе / сервере, либо мошеннический источник трафика в сети. Без возможности захвата некоторого связанного трафика или просмотра статистики интерфейса, фактическое отслеживание любого из них было бы невозможным. Добавляли ли вы в последнее время какие-либо новые устройства? Особенно в моем личном списке подозрительных устройств: сетевых устройств, серверов, подключенных более чем к одной сети, принтеров.
Однако системный администратор-одиночка, который ушел в отпуск и покинул магазин без видимости в сети, - это очень плохая ситуация. Некоторые вещи, которые стоит обсудить, когда он / она вернется:
Я был единственным сетевым администратором многомиллионной компании более 7 лет (теперь у меня есть миньоны =) и почти все это время дежурил 24 часа в сутки, 7 дней в неделю, 365 дней в году, и могу сказать, что если вы сделал себя единственным человеком, который может делать определенные вещи, можете быть уверены, что вы воля вызываться всякий раз, когда это нужно делать.
Единственное, на что вы можете положиться на 100%, - это вероятность того, что все, что может сломаться, когда вы единственный, кто может это исправить, это то, что абсолютно гарантированно сломается, когда вы уезжаете в отпуск.
Без доступа к вашим коммутаторам ваши возможности немного ограничены в поиске сетевых проблем. Я бы начал с проверки интерфейсов на серверах; ищите потерянные пакеты или коллизии. Вы также можете использовать Wireshark или tcpdump, чтобы посмотреть фактический трафик и увидеть, что происходит, когда ваши DNS-серверы не разговаривают, но все это более эффективно выполняется, когда вы можете отслеживать вещи со стороны сети, а не со стороны сервера. если ты действительно необходимо, вы можете сбросить пароли на переключателях, но будьте готовы столкнуться с гневом вашего админа, когда он вернется ...
Изолируйте проблему:
Лучшее, что вы можете, - это попытаться изолировать проблему. Если у вас несколько коммутаторов, возникают ли проблемы с машинами, подключенными только к одному из коммутаторов? Если это происходит со всеми коммутаторами и не является чисто проблемой DNS, я бы посмотрел на маршрутизатор или соединение между коммутаторами и маршрутизатором. Возможно, это может быть какая-то проблема, похожая на широковещательный шторм, но я думаю, что это менее вероятно, и вы, вероятно, не собираетесь ее исправлять, если это так. Как уже упоминалось, ошибки tcpdump / wirehark и интерфейса также могут помочь в этом процессе.
Цикл питания все (Рискованно):
Второй рискованно вариант - просто выключить и выключить все или по очереди, чтобы посмотреть, решит ли проблема. Я говорю, что это рискованно, потому что при большом количестве сетевого оборудования есть работающая конфигурация и сохраненная конфигурация. Если администратор забыл зафиксировать текущую конфигурацию в конфигурации запуска в последний раз, когда они что-то сделали, у вас, вероятно, возникнут проблемы после перезагрузки.