Поиск и устранение проблем в компьютерных сетях

Обновлено: 07.07.2024

Поиск неисправностей в сети.

Анализ - определение значения критерия эффективности (или, что одно и то же, критерия оптимизации) системы для данного сочетания параметров сети.

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

Задача мониторинга решается программными и аппаратными измерителями, тестерами, сетевыми анализаторами и встроенными средствами мониторинга систем управления сетями и системами.

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

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

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

Обнаружение проблем в сетевом окружении.

Основные проблемы, которые могут возникать в сетевом окружении:

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

Поиск неисправностей в сети. Утилиты TCP/IP.

Windows XP предоставляет в ваше распоряжение широкий набор утилит для управления, конфигурирования и выявления неисправностей среды TCP/IP.

Ping - диагностическая утилита, которая проверяет возможность соединения с удаленным компьютером.

Pathping - усовершенствованная утилита ping, которая также отражает маршрут прохождения и предоставляет статистику потери пакетов на промежуточных маршрутизаторах.

Route - показывает и позволяет изменять конфигурацию локальной таблицу маршрутизации.

Tracert - отслеживает маршрут, по которому пакеты перемещаются на пути к пункту назначения.

Netstat - показывает текущую информацию сетевого соединения TCP/IP. Например, информацию о подключенном хосте и номера используемых портов.

Ipconfig - показывает текущую конфигурацию TCP/IP на локальном компьютере.

Hostname - показывает локально настроенное имя узла TCP/IP ..

Arp - показывает и позволяет изменять кэш протокола ARP (Address Resolution Protocol), где хранится информация о соответствии IP - адресов - MAC - адресам локальных узлов.

Nslookup - утилита командной строки - распознаватель для запросов DNS сервера.

Утилиты выполняются из командной строки.

Чтобы открыть окно командной строки нажмите кнопку Пуск и выберите последовательно команды Все программы -> Стандартные -> Командная строка.

Если не удается подключиться к другому компьютеру, могут иметь место неполадки с подключением или неполадки с именами.

Применение утилит ping и ipconfig.

Чтобы определить причину неполадок, попытайтесь выполнить обмен пакетами (утилита ping) с IP-адресом другого компьютера. Таким компьютером может быть компьютер, с которым вы пытаетесь соединиться, или основной шлюз.

Чтобы определить IP-адрес основного шлюза: наберите в командной строке ipconfig и нажмите клавишу ENTER. Если требуемая информация уходит с экрана, то для просмотра экранов по очереди введите ipconfig | more и нажмите клавишу ENTER. В отображаемых результатах найдите строку Основной шлюз и запишите соответствующий IP-адрес.

Чтобы выполнить обмен пакетами (ping) с другим компьютером: наберите в командной строке: ping адрес, где адрес представляет IP-адрес другого компьютера, и нажмите клавишу ENTER.

Если обмен пакетами выполнен успешно, появляется отклик, аналогичный следующему:

Ответ от число байт=32:
Ответ от : число байт=32 время=75мс TTL=28
Ответ от : число байт=32 время=87мс TTL=28

Если обмен пакетами выполнить не удается, появляется отклик, аналогичный следующему:

Ответ от число байт=32:
Превышен интервал ожидания.
Превышен интервал ожидания.

Утилита Ipconfig показывает текущую конфигурацию TCP/IP на локальном компьютере.
Ключи утилиты:

/release - освобождает полученный от DHCP IP - адрес.
/renew - получает от DHCP новый IP - адрес.
/all - показывает всю информацию о TCP/IP конфигурации.
/flushdns - очищает кэш локального распознавателя DNS.
/regsiterdns - обновляет адрес в DHCP и перерегистрирует его в DNS.
/displaydns - показывает содержание кэша распознавателя DNS.

Обычно говорят и пишут о проектировании и создании сети. О том, какое оборудование выбирать для строительства, как создавать узлы связи. На самом деле в развитии и обслуживании сети есть некоторые нюансы, о которых вспоминают слишком поздно. Необходимо помнить о техническом сопровождении и возможности поддерживать сеть в работоспособном состоянии, устранять неисправности в максимально короткие сроки. Знание способов устранения неисправностей поможет вам создать по-настоящему стабильную работу сети. Так же каждый администратор должен знать, когда приходит время совершенствовать и расширять сеть.
В этой статье я постораюсь наиболее понятно и полно описать многие проблемы возникающие после строительства локальных сетей, расскажу о многих ошибках, допускающихся в обслуживании ЛВС.

О строительстве.

Для того, чтобы сеть работала на нас, а не мы на нее я рекомендую придерживаться некоторых правил.

1. Использовать для строительства только новое, качественное и проверенное в работе оборудование.
2. Придерживаться стандартов и норм строительства сети.
3. Делать что-либо продуманно, ни в коем случае не торопиться с какими-либо выводами и решениями.
4. Документировать каждый поступок.

Интвентаризация и документация.

Во время постройки сети, не надо расслабляться, стоит заняться документированием оборудования и программ, работающих для нас. Для создания полной переписи следует использовать электроныые базы данных. В электронном виде информация выглядит проще, поиск необходимого по нескольким параметрам осуществляется быстрее даже в самых простых электронных таблицах. Большинство знакомых мне провайдеров предпочитают хранить ревизии в единой базе данных и использовать веб интерфейс, для более удобной работы с базой данных.
Сразу надо сделать перепись всего оборудования, если это управляемое оборудование, на которое можно зайти удаленно, не забывайте указывать логины и пароли, для того, чтобы сотрудники технического отдела и поддержки всегда могли проверить работоспособность оборудования, помните про физические адреса (MAC), а также – территориальное место нахождения, очень трудно узнавать серийный номер коммутатора, если он находится на большом расстояние от вас и в труднодоступном месте.
Не забудьте сделать отдельный список оборудования, с серийным номером, производителем, датой покупки и датой окончания гарантии, так же данных о продавце оборудования. В случае возникновения гарантийных ситуаций вы всегда сможете быстро сдать оборудование в гарантийный сервисцентр, обязательно сохраняйте все документы на оборудование.
Советую присваивать каждой единице своё уникальное имя под которым она будет числиться во всех списках, для удобства эксплуатации. Например если если это свитч – то сокращение sw идеально для него подойдет, потом уникальный порядковый номер и краткие сведения о его месторасположении. Для удобства обслуживания сети рекомендую использовать подобные имена в обратных и прямых зонах DNS, в IP адресах можно запутаться.
После изменения любых настроек необходимо проверить точность настроек и внести изменения в соответствующий список.
Во многих сетях до сих пор используются PC роутеры, а так же есть почтовые сервера, хостинги, биллинги, DNS сервера. Для всех служебных компьютеров необходимы отдельные журналы, в которых должен вестись учет используемой конфигурации, имеющихся там пользователей, установленных программ, параметры сборки. Подобного рода данные помогут любому администратору разобраться с тонкостями работы компьютера.
Рекомендую так же задокументировать сетевую адресацию и клиентское оборудование.
Документация проблем в сети, а так же биография каждого пользователя помогут системному администратору быстро определить многие неисправности случившиеся как от износа оборудования, так и по вине недобросовестности пользователей. Пользователь должен обязательно заявлять какое оборудование он применяет для пользования сетью, сведения о конечном оборудовании должны сохраниться. Например некоторые виды роутеров-принтсерверов со встроенными arp-proxy, никак не отключается, но вот пользователям находящимся с таким оборудованием в одном пространстве будет не комфортно.
В том случае, если вы занимаетесь обслуживанием компьтерных залов с локальной сетью в работе вам поможет полная инвентаризация клиентского оборудования, все данные о конфигурации каждого компьютера: сведения о типе и мощности процессора, материнской плате, объем/производитель жесткого диска и плат памяти, операционная система.
Для крупных локальных сетей окажется кстати карта местности с нанесенными на нее маршрутами. Перед подключением здания лучше сделать проект разводки даже в том случае, если вы не собираетесь ни с кем его согласовывать. В таком проекте будут иметься данные о расположении оборудования, типах используемого кабеля, данные о источнике питания оборудования. Обязательны к указанию места и способы крепления кабеля. Расположение локальных узлов связи.
Да, на подготовку проекта у вас затратится много времени, но в будущем обслуживание полностью задокументированной сети не будет приносить неприятных сюрпризов.
Для того, что бы избежать в дальнейшем проблем с потерей информации продумайте backup систему (например Basics), в противном случае вы можете лишиться очень ценных и не восстановимых данных.

Мониторинг сети.

Устранение неисправностей.

Поиск и анализ неисправностей.

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

1. Идентификационный номер, удобен для создания картотеки и баз данных.
2. Информация о пользователе сообщившем о проблеме в работе, его имя, фамилия, отчество, идентификационный номер в сети, либо номер договора, время обращения в техническую службу.
3. Эти сведения собирают сотрудники технической поддержки. Необходимо проверить обращался ли человек с проблемами ранее, если да, то указать id проблемы и краткое описание. Место возникновения неисправности, какие-либо изменения в структуре сети, настроек или замены оборудования.
4. И в завершении категория в которой указывается то, что было сделано для устранения неисправности, устранена она или нет.

При поиске неполадки самым важным является информация. Человека, заявляющего о вознихших у него проблемах нужно распросить максимально подробно, нужно узнать о всех фактах предшествовавших проблеме, не изменялись ли какие-либо настройки, или оборудование со стороны клиента, а так же со стороны администрации сети. После приема заявки и сбора информации и выяснениния всех подробностей проблемы, возможности повторения проблемы, если проблема устранилась, составим список возможных причин неполадок.
Роль модели OSI при устранении неполадок.

Действовать будем по принципам работы Ethernet технологии основанной на эталонной модели OSI. Немного напомню вам о уровнях эталонной модели OSI:

Три первых уровня модели OSI определяют функции непосредственно передачи данных. От них зависит физическая доставка сигнала по сети. Последние 4 управляют передачей данных на уровне хост машин.

Уровень 1 – Физический.
Отвечает за наличие сигнала в линии, передачу двоичного сигнала. Описывает природу среды передачи данных. Наличие напряжения на оборудовани, радиочастоты, уровень затухания светого сигнала в оптоволокне и прочие подобные аспекты.
Уровень 2 – Канальный.
Доступ к среде передачи данных. Второй уровень обеспечевает передачу фрэймов (кадров). Фрэймы это блоки данных, разделнные для удобства и стабильности передачи на отрезки. На канальном уровне данным передаваемым на физическом уровне назначается начало и конец, указывается последовательность данных.

Уровень 3 – Сетевой.
Этот уровень пользуется возможностями, предоставляемыми ему уровнем 2. Занимается обработкой адресов и выполняет маршрутизирование между разными сетями.

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

Уровень 6 – Уровень представлений.
Уровень 6 устанавливает взаимопонимание между компьютерами, на этом уровне решаются такие задачи как перекодировка передаваемой информации.

Неполадки со связью чаще всего возникают в среде передачи данных, по этой причине искать неисправности мы будем именно на трех первых уровнях модели OSI.
На физическом уровне могут возникать такие неисправности как отсутствие сигнала в линии по следующим наиболее распростроненным причинам:

1. Обрыв кабеля.
2. Плохой контакт в месте подсоединения кабеля.
3. Неправильный задел кабеля в разъем.
4. Неподсоединение кабеля.
5. Подключение кабеля не к тому порту.
6. Отсутсвие питания на оборудовании.
7. Замыкание контактов кабеля.
8. Неисправность сетевого интерфейса.

Следующие ошибки и неполадки следует искать на канальном уровне модели OSI:

И наконец, последний, сетевой уровень модели OSI, на котором мы будем искать ошибки и неполадки:

1. Неправильное указание IP сети.
2. Неверный IP адрес сетевого интерфейса.
3. Ошибочное указание маски подсети.
5. Неправильный адрес DNS сервера.
6. Неверная маршрутизация.
7. Задание неправильного номера АС для протокола IGRP.
8. Невыполнение активизации работы протокола маршрутизации.
9. Активизация неверного протокола маршрутизации.

На более высоких уровнях могут случаться ошибки администрирования, приводящие к отказу сети:

1. В случае использования DHCP сервера – ошибка в его конфигурации и указание неверное физического адреса пользователя.
2. Неправильное конфигурирование фаерволов.
3. Нерабочий DNS сервер.

Методика решения проблем.

При решении задачи поиска и устранения неполадок нужно иметь поэтапную методику, работа будет эффективнее если есть такая методика.

1. Получение подробной информации о возникшей проблеме. Четкое определение и полное описание.
2. Определение наиболее вероятных причин возникновения проблемы. Включая данные о когда-либо возникавших проблемах подобного рода, в том же сегменте сети, с тем же абонентом. Расстановка причин по приоритетности.
3. На третьем этапе составляется план действий по решению проблемы основанный на данных полученных на втором этапе.
4. Реализация плана действий должна происходить строго его придерживаясь. В противном случае можно совершить еще больше поломок и не неэффективно потратить время. После выполнения каждого шага следует проверять устраненена ли проблема, или нет.
5. Проверка результатов выполнения процедур устранения неполадок. Убедимся в том, что проблема исчерпана и сеть работает должным образом.
6. В том случае, если проблема не устранена – стоит пересмотреть действия выполненные на третьем и четвертом этапе.

Подробнее о проблемах возникающих с передачей данных.

Для поиска неисправностей в сети нам потребуется некоторый инструментарий программы и журнал неполадок, они облегчат нам поиск многих неисправностей, особенно если наш пользователь не имеет достаточного количества знаний для того, чтобы составить четкую картину неполадки и проверить самостоятельно правильность настройки своего оборудования.
Самым важным инструментом будет тестор, либо оптоволоконный измеритель, для проверки уровня и стабильности сигнала в линии. Очень пригодится ноутбук, желательно с какой-либо Linix/Unix системой, под такие операционные системы существует огромное количество программ для работы с сетью, а так же сами программы.
Если проблема является масштабной, надо выяснить территориальное местонахождение проблемы, для этого нам пригодится карта сети. В случаеотказа всей сети нам надо поторопиться и проверить работу центрального узла и наличии связи с провайдером услуг. Проверить работу сервисов (DNS, DHCP) биллинговую систему. Если проблема охватывает только один участок сети, проверьте оборудование обслуживающее его.

В случае, если команда ping сообщает от том, что хост недоступен – это говорит о том, что на порт не приходит соответствующего физического адреса, а следовательно проблему стоит искать на физическом уровне.

Совет, если заносить в /etc/hosts или локальный DNS сервер данные о клиентах, в соответсвии с их IP дресами – можно быстро и легко проверить наличие связи с тем, или иным сегментом. Перед тем, как искать интересующий нас MAC обновим таблицу маков arp -d, иначе можем увидеть устаревшую информацию.

Попросим клиента разрешить эхо-запрос на его фаерволе, и проверим канал на потери утилитой mtr выставив интервал приблизительно в 0.01 секунды и размер пакетов в 1024 байта. Связь может отсутсвовать из-за физических потерь.

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

Передача пакетов есть, но интернета все равно нет. Проверим роутинг, попросим клиента выполнить команду tracert или traceroute и послушаем траффик с интерфейса клиента утилитой tcpdump:

Из такого листинга мы увидим что компьютер клиента не может найти физический адрес компьютера с которым пытается соединиться, а чаще всего компьютер клиента обращается к своему шлюзу. Таким методом очень просто узнать, насколько верны настройки у клиента, и исправна ли сетевая карта и есть ли поблизости какие – либо arp-proxy.
В случае правильности всех настроек такой листинг больше всего похож на нерабоспособный сетевой интерфейс.
Traceroute же покажет связь до шлюза и далее.

На данном листинге явно показана петля в маршрутизации. Проверяем свои шлюзы.

При использовании некачественного оборудования, могут возникать такие симптомы как низкая скорость, потери. Системы мониторинга постоянно сообщают о недоступности почти всего оборудования, через несколько секунд связь восстанавливается. Tcpdump показывает удвоенные, а то и утроенные arp-запросы/ответы. Картина у нас будет следующей:

Теория

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

Поиск и устранение неисправностей

Семь шагов поиска неисправности в сети

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

Распознавание симптомов.
Уточнение симптомов.
Составление списка возможных неисправных функций.
Локализация неисправной функции.
Локализация неисправного компонента.
Анализ ошибок.
Изменение архитектуры.

Распознавание симптомов

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

Уточнение симптомов

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

Что вы не можете сделать?
Вы могли это сделать раньше?
Это касается только вас, или происходит с другими тоже?
Это когда-нибудь работало?
Что-то изменилось недавно?

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

Составление списка возможных источников неисправностей

На первом этапе было положено начало поиску и устранению неисправностей, на втором этапе был рассмотрен общий характер ошибок. Теперь стоит провести мозговой штурм на предмет того, какова может быть причина неисправности. Во-первых, нам нужна диагностика не исправности сети, а для этого стоит выяснить, что является источником. В целях устранения неполадок ИТ-систем следует определить главное направление для исследования каждого случаю поломки или выхода из строя сервиса.

Следующий список причин неисправностей может влиять на работу инфраструктуры по той или иной причине:

электропитание;
контроль окружающей среды;
сеть;
серверы;
безопасность.

Все они очень широкие, и являются сутью третьего шага. Мозговой штурм направлен на поиск неисправности и того, какое направление может быть ее причиной, а также исключение маловероятных и тупиковых версий. Отметание таких направлений сужает круг поиска до разумных границ и в итоге приводит к правильному общему направлению. Когда специалист идет в неправильном направлении и устраняет ошибку, не связанную с проблемой, это называют «спуском в кроличью дыру». Иногда поиск и устранение простых неисправностей в работе оборудования может предотвратить множество ошибок.

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

Локализация неисправной функции

Запуск трассировки на адрес сервера показывает успешные передачу пакетов до коммутатора, к которому непосредственно подключается сервер. Этот коммутатор является последним звеном, после которого все пакеты теряются. На основании этого исследования мы предполагаем, что в сети орудует злоумышленник.

Локализация неисправного компонента

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

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

Анализ ошибок

На этом последнем шаге мы исправляем ошибку и документируем процесс. В случае нашего сервера, установив порт в правильную сеть VLAN, мы восстановили сетевое подключение, и пользователи снова смогут получить доступ к серверу. После устранения неисправности необходимо проверить, что корпоративные сервисы вернулись к нормальной работе. Важно спросить коллегу, кто изначально сообщал об ошибке, о том, устранена ли первоначальная ошибка. И только после подтверждения можно
считать проблему решенной. Мы задаем вопросы коллегам касательно пути поиска неисправности и как можно подробнее документируем процесс. Документируя ошибку, мы позволяем будущим техническим специалистам исправлять ту же проблему гораздо быстрее, если они снова ее обнаружат.

Согласно моей методике поиска неисправностей при регистрации ошибки необходимо ответить на следующие вопросы:

Что было не так?
Какие симптомы мы увидели?
В чем была причина?
Как мы можем предотвратить это снова?

Документация о неисправности может выглядеть примерно так:

«Сетевой кабель подключен к серверу СЕРВЕР №1 с одной стороны и порт коммутатора №16 с другой стороны. Кабель был подключен в неправильный порт коммутатора. Порт был сконфигурирован в неправильной сети VLAN, тем самым нарушая сетевую топологию. Сервер был включен и имел корректную сетевую индикацию, но пакеты от сервера по сети не ходили. Порт коммутатора функционировал (индикация подключения была корректной), но назначение VLAN-порта не соответствовало нашей документации.

Техник указал некорректный номер порта при смене номера VLAN для другого хоста и случайно отключил наш сервер. Возврат порта коммутатора обратно на серверный VLAN восстановил соединение».

Создание методологии предотвращения повторных ошибок может быть непростой задачей, требующей обширных знаний и смекалки. Сочетание обучения, наставничества, хорошей документации и процессов управления изменениями может помешать ошибке снова повториться. Даже неформальный обмен знаниями в ИТ-команде лучше, чем ничего.

Во время еженедельной встречи полезно быстро повторить алгоритм поиска неисправности по следующим пунктам:

Что произошло.
С чем столкнулись во время устранения неполадки.
Как мы исправили ошибки.

Перед тем, как обращаться к провайдеру, необходимо разобраться - а всё ли хорошо в доме. Без этой проверки есть риск превратиться в мальчика, который постоянно кричал ~~"у меня потери пакетов"~~ "волки".

Моральное устаревание диагностических инструментов

В современном мире диагностика, увы не очень показательна. Во-первых, потому, что она базируется на протоколах 40-летней давности (RFC 792 - от 1981-го года) и превращается в лупу в эпоху электронных микроскопов. А во-вторых, у этих протоколов есть большие проблемы в части безопасности. Если какой-то маршрутизатор полностью отвечает RFC 792, то его можно элементарно атаковать с помощью DDoS атаки (чем хакеры в нулевых и баловались). Поэтому, даже эти протоколы работают плохо благодаря закрученным гайкам.

Прямым следствием этих ограничений является типичный сценарий решения сетевых проблем:

Пользователь обращается к провайдеру и говорит, что с сайтом А у него проблемы и плохая связь. Провайдер обычно ~~всегда~~ говорит: у нас всё хорошо, проблемы у сайта.

Когда пользователь обращается в поддержку сайта, то ему там говорят то же самое – у нас всё хорошо, обратитесь к провайдеру.

В итоге, проблема конечно же не решается.

Ниже мы всё-таки попробуем определиться, где именно проблема.

К сожалению для статьи, и к счастью для автора, у автора всё в порядке с интернетом. Потому, примеров «смотрите – слева всё плохо, а справа всё хорошо» практически не будет. Но, где возможно – я всё-таки попробую что-нибудь сломать для наглядности.

Маршруты интернета

В первой части статьи я рассказывал, что трафик ходит по маршрутам. Их два : BGP и IP. Один поверх другого. BGP - определяет маршрут через физические маршрутизаторы, а IP - уже логическая составляющая пути. На этом этапе диагностика затруднена тем, что :

Вводная по BGP это TTTLDR.

Благодаря таким технологиям, как AnyCast, IP 11.22.33.44 на маршруте может физически находиться в любом месте, и в двух+ местах одновременно : AnyCast позволяет указать, что за этот IP отвечает сервер в Нью-Йорке и в Москве. При пинге этого IP вы не можете однозначно утверждать, что вы пингуете именно Московский сервер.

Так же есть MPLS и иное туннелирование. Разобрать маршруты тоннелей, простыми инструментами не получится.

Пакет "туда" и пакет "обратно" может пойти разными путями.

Пакет "туда" может пойти по нескольким путям в разное время. Инструментов для диагностики ECMP на домашних OS немного, они сложнее простого tracert, а иногда, стоят дорого.

Будем работать с тем что есть. А есть у нас команда traceroute.

На windows она выполняется из Пуск/cmd и ввести tracert. Так же есть графическая утилита WinMTR. Она дает больше полезной информации и, в некоторых случаях, будем пользоваться ей.

Можно не запускать cmd и там выполнять команды, а делать это windows-style:

Пуск/выполнить cmd /k tracert -d что-нибудь

Ключевые правила диагностики:

Если вы не можете продемонстрировать и повторить проблему, то никто не сможет.

Данные нужно собирать за несколько временных периодов – как минимум, за период, когда проблем нет, и за период, когда проблемы есть.

Как быстро определить, что всё приемлемо

Автор использует универсальную метрику «Пинг на 1000 километров». Он считается следующим образом:

Определяете, где находится сервер.

На Яндекс.картах измеряете расстояние от вас до сервера.

Выполняете команду ping до нужного вам хоста. Если получается не больше, чем 20 миллисекунд на 1000 километров, то у вас с инпут-лагом не должно быть никаких проблем.

Автор находится в

1000 км от Москвы. Его пинги выглядят следующим образом:

На расстояниях до 200 км данное правило, кстати, не будет выполняться, ввиду того, что скорость работы оборудования вносит бОльшую лепту. На таких расстояниях пинг должен быть в рамках 5-6 миллисекунд. Если больше – у вас проблема.

Как читать PING

Соединение до домашнего роутера

1 1 ms 1 ms <1 ms 192.168.88.1

Первый IP адрес в результатах tracert скорее всего и будет IP-адресом вашего роутера.

Так же можно сделать вывод, что автор любитель Mikrotik.

Пинг, обычно, отправляет пакеты размером 64 байта, что показывает скорее физические качества канала– нет ли плохого кабеля по пути.

Как уже говорилось ранее – диагностика работает только в сравнении. Ниже - два примера пинга.

С сервера, который подключен к роутеру кабелем.

А это с компьютера, который подключен к той же сети, но по wi-fi.

Какие выводы можно здесь сделать:

WIFI вносит свою лепту. Во-первых, у нас появился Джиттер (видим, что время пинга скачет). Во-вторых, пинг стал немного хуже.

И вот подтверждение моих слов - тест участка компьютер-домашний роутер.

Пакеты, даже не выходя в интернет, иногда проходят плохо. Без потерь, но задержки присутствуют.

Чтоб запустить "длинный ping" - необходимо ввести команду ping -t . В этом случае ping будет продолжаться пока вы не нажмете Control+C

Видим, что при приеме больших объемов информации скорость падает существенно меньше, чем при передаче.

Одна из причин – мощность антенны в точке доступа выше, чем у ноутбука. Ноутбук работает на аккумуляторе и не подключен к сети. Аккумулятор - почти севший и windows находится в режиме «Best battery life»

Вот тот же самый тест, но с подключенным блоком питания.

Видно, что прием стал гораздо лучше, и передача тоже улучшилась. 200мс пинг при передаче отсутствует.

Что в этой ситуации можно настроить:

Мощность передатчика на точке доступа.

Мощность передатчика на ноутбуке.

В первых тестах мощность передатчика ноутбука была выкручена на максимум. Ниже – выкручена на минимум:

Как видно, появились потери, и пинг стал гораздо хуже, даже при работе от блока питания.

Стоит помнить, что Wi-Fi это диалог. Если точка доступа «кричит», а компьютер «шепчет», то точка может плохо слышать компьютер, хотя палочки будут показывать, что всё хорошо.

Если вы везде выставите мощность на максимум, то могут начать страдать ваш Smart TV и телефон, подключенный к той же сети – компьютер будет их «перекрикивать». Ноутбук будет меньше работать от батарей. Мощность всегда нужно выбирать исходя из условий, и ставить минимальную мощность, которая дает вам приемлемый результат. Мощность с запасом ставить не рекомендуется.

Факторы, влияющие на Wi-Fi

Здесь опустим исключительно программные факторы вроде beacons, размеры пакетов, 80 мегагерц и прочее – про них можно написать еще десяток страниц. Приведу только ключевые физические факторы и факторы окружения.

Частоты : «2.4» в городах – всегда хуже 5 гигагерц. При возможности выбирайте 5.

При выборе канала – проведите анализ спектра, когда «соседи дома». Точки обычно позволяют сканировать эфир. Выберите канал, который не занят и у которого меньше всего соседей. При выборе канала старайтесь выбирать как можно меньший канал. 5-й канал бьет «дальше», чем 159-й.

Ищем частоту, вокруг которой либо самая слабая передача - Signal Quality самый плохой, либо вообще на этой частоте ничего нет.

У ноутбуков антенна встроена в экран. Антенна точки и устройства должны находиться в одной плоскости. Если у вас экран стоит вертикально, то и антенны на роутере должны стоять вертикально, а не так, как обычно показывается на рекламных материалах:

Плохая ориентация антенн :

Правильная ориентация антенн.

Вокруг и над антенной, в радиусе 40-50 сантиметров по горизонту НЕ ДОЛЖНО быть металла и стен. Т.е. – на столе/полке роутер ставить – неизбежное зло, с которым придется смириться. А вот возле стены – плохо. Популярные гипсокартонные стены содержат в себе металлические направляющие каждые 40 сантиметров.

Работающие микроволновки – злейшие враги Wi-Fi в тот момент, когда в них готовят.

Конспект

Найти IP-адрес домашнего роутера.

Запустить длинный пинг до роутера. Замерить потери и скорость.

Запустить спидтест и параллельно длинный пинг.

Сравнить результаты. Если ухудшения показателей пинга нет, то у вас соединение до роутера - быстрее чем канал в интернет, и в целом, дома всё хорошо.

Выбрать частоту и незанятый канал.

По возможности, убрать точку от стен.

Правильно ориентировать антенны. Кстати, запустив длинный "пинг", и покрутив антенны - можно найти оптимальный вариант, но не забывайте, что цифры достоверные только когда вы НЕ КАСАЕТЕСЬ антенн.

Выбрать минимальную мощность передатчика, дающую максимальную скорость в локальной сети.

Перед тем, как приступить к диагностике подключения к Интернету, проверьте для начала вашу локальную сеть. Многие ошибки подключения к Всемирной паутине на самом деле являются проблемами локальной сети (LAN).

Если вы спросите у системного администратора крупной компании, с какой основной сетевой проблемой он сталкивался, то как это ни парадоксально, самым популярным ответом станет отключенный сетевой кабель. Действительно, если внешний кабель, подключенный к роутеру или DSL-модему не подключен к порту, выйти в Интернет не получится. Очень часто неполадки возникают после уборки помещения пылесосом. В этом случае вы знаете что делать.

Кроме того, если выше беспроводное соединение не работает, проверьте, что ваш компьютер подключается к правильной точке доступа. Если устройство пытается подключиться к старой сети Wi-Fi, соединение установить не удастся.

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

Если в домашней сети вы используете только беспроводные подключения, убедитесь, что ваши точки доступа работают. Отличным инструментом для этого станет приложение Network Analyzer Pro для Android или iOS. Хотя оно предназначено для специалистов, приложение является очень простым в использовании и позволяет просматривать активные беспроводные сети. В Windows 10 можно воспользоваться приложением WiFi Analyzer, доступным в Магазине Windows.

Если вы все проверили, но беспроводное подключение не позволяет вам выйти в Интернет, тогда попробуйте использовать прямое подключение через Ethernet кабель.

Если вы можете получить доступ к веб-панели администрирования администратора, то самое время проверить подключение к Интернету.

Проверьте подключение к Интернету

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

Если ничего не произошло, попробуйте отключить роутер на минуту. По-прежнему ничего?

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

В противном случае, вы можете создать заявку на вызов сотрудника компании-провайдера. Причиной “дисконекта” может быть разрыв кабеля в подъезде или на магистральной линии. Физические проблемы часто являются причиной сетевых проблем.

Только будьте готовы подождать. Очень редкой провайдеры реагируют оперативно.

Теперь предположим, что доступ к Интернету восстановлен, но он работает медленно и нестабильно. Во-первых, давайте проверим пропускную способность сети, за которую вы платите деньги. Лучшим сайтом для проверки текущей текущей скорости является Speedtest. Этот сайт управляется сетевой компанией Ookla. Тест показывает скорость скачивания, скорость загрузки и пинг до ближайшего сервера теста.

Ping - это сетевая утилита, которая измеряет время в миллисекундах (мс) между вашим компьютером и тестовым сервером. Чем ниже ваш пинг, тем лучше. Если ваш пинг выше 50 мс - у вас имеется проблема.

Тест Google Internet Speed стал результатом партнерства между Google и измерительной лабораторией (M-Lab) и доступен в англоязычном поиске Google (введите запрос "check internet speed" на английской версии поисковика). В дополнение к скорости этот тест измеряет задержки сети. Задержка - это показатель того, как быстро вы получаете ответ от сервера. Низкое время отклика важно для приложений реального времени, таких как видеозвонки и онлайн-игры. Задержка измеряется в мс (миллисекунды) и похожа на ping, но является показателем постоянных задержек между вашей системой и серверами.

Некоторые виды подключений, в частности dial-up и спутниковые соединения, всегда вызывают отображение больших значений пинга и задержек. Вы ничего не можете с этим поделать - эти технологии просто не способны на это. С практической точки зрения, это означает, например, онлайн-игры и видеоконференции могут работать нестабильно с данными видами Интернет-соединения.

У Интернет-провайдером также есть свои собственные тесты производительности. Вообще говоря, эти тесты покажут вам максимальную скорость. Ничего удивительного! В реальном мире провайдеры обычно переоценивают свои возможности и не обеспечивают заявленную пропускную способность.

Тем не менее, в разное время показатели пропускной способности могут заметно отличаться. Это связано с тем, что пропускная способность кабельного интернета распределяется между пользователями в одном и том же сегменте кабеля. Таким образом, если с утра фиксируется высокая скорость Интернета, то вечером она может падать, потому что другие пользователи начинают смотреть Youtube, играть в онлайн-игры и т.д. Даже при низком пинге и быстрой пропускной способности ваше соединение может все еще быть не таким качественным. Это потому, что пинг, латентность и пропускная способность не дают полную картину. Вы можете потерять пакеты или страдать от фазового дрожания цифрового сигнала данных.

Джиттер или задержка пакетов - это интервал времени, который требуется для того, чтобы интернет-пакеты поступали в вашу систему. Так, например, если вы пинговали сайт один раз, для отправки ответа потребовалась 1 миллисекунда, а пинг следующего пакета составил 10 миллисекунд, то у вас наблюдается ужасный случай джиттера. Иногда джиттер настолько плох, что пакеты теряются.

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

Вы можете проверить, есть ли у вас джиттер, используя тест DSLReport Jitter. Этот тест измеряет уровень джиттера путем пингования сайтов со всего мира из вашей системы. Если вы уровень джиттера велик, то ваше Интернет-соединение, скорее всего, страдает от перегруженности сети где-то вверху по линии.

В идеале вам нужна нулевая потеря пакетов, но обычный пользователь Интернета может спокойно жить с 1 или 2 процентами потери. Если вы постоянно наблюдаете джиттер, поменяйте своего Интернет-провайдера.

Вы также можете попытаться снизить уровень дрожания цифрового сигнала: обновите прошивку роутера, попытайтесь отключить дополнительное оборудование в сети, чтобы найти источник искажений. Неправильно работающее сетевое оборудование может серьезно замедлить работу любой локальной сети.

Все еще не решили проблему? Вызовите специалиста или при наличии специальных знаний, попробуйте устранить неполадки самостоятельно с помощью мощных инструментов, таких как WireShark, Logic Monitor или Spiceworks Network Monitor. Помните, что любая сетевая проблема может быть исправлена при наличии определенного опыта.

Читайте также: