Как найти проблему в локальной сети

Проектирование, создание и мониторинг сети

Вступление.

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

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

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

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

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

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

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

Самым важным фактором в качестве обслуживания сетей является вовремя поступающая информация о возникновении неполадок. В получении информации вовремя нам помогут — система мониторинга, например Nagios, она всегда сообщит нам на е-мэйл или через sms даже о том, что в принтере закончилась бумага, не говоря уже о потери связи с каким-либо оборудованием. Необходима квалифицированная техническая поддержка, принимающая и обязательно документирующая звонки пользователей. Роль технической поддержки очень важна, сотрудники службы должны уметь помогать пользователям в устранениии мелких неисправностей, должны сортировать заявки по адресам и предварительным симптомам.
Для отслеживания загрузки каналов обычно используется программный пакет Mrtg или . В аккуратных и четких графиках он подробно покажет загрузку каналов по любым указанным портам. Такая работа поможет вовремя отследить загруженность сети, при загрузке канала в 60%-75% стоит серьезно задуматься о изменении конфигурации сети и расширении каналов.

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

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

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

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

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

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

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

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

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

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

Уровень 5 — Сеансовый.
Упровляет сеансами передачи данных, восстанавливает аварийно оконченные. Этот же уровень преобразовывает доменные имена, удобные для людей, в реальные сетевые адреса.

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

Уровень 7 — Уровень приложений.
Служит прослойкой между сетью и компьютерными приложенинями. Обслуживает только прикладные процессы. Проверяет возможность ресурсов для работы приложений.

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

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

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

1. Неверно заданная тактовая частота на последовательных интерфейсах.
2. Не верно заданный номер vlan и тип порта.
4. Не правильное указание метода инкапсуляции.
5. Дублирование arp запросов и ответов.
6. Неисправность сетевого интерфейса.

И наконец, последний, сетевой уровень модели 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) биллинговую систему. Если проблема охватывает только один участок сети, проверьте оборудование обслуживающее его.

Проверим сетевой интерфейс пользователя, горит ли лампочка на интерфейсе, если нет – то физической связи нет, либо интерфейс отключен, или неисправен, попробуем попинговать с локальной консоли сначала локальный IP – 127.0.0.1, если ответов нет – то скорее всего сбой в сетевых службах клиента. Затем назначенный интерфейсу IP адрес, если откликов нет – то интерфейс или отключен, или неисправен.
При условии что лампочка на интерфейсе клиента горит, и подключение по локальной сети включено проверить наличие физической связи нам всегда поможет утилита arping эта программа выполняет эхозапрос на указанный MAC адрес, минуя arp кэш, так-же с помощью нее можно узнать IP адрес принадлежащий сетевой карте. Команда ping не всегда пригодня для проверки связи из-за использования фаерволов, запрещающих получение и отправку ICMP пакетов.

root@ziggurat:~$ ping 81.222.220.97
PING 81.222.220.97 (81.222.220.97): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
— 81.222.220.97 ping statistics —
2 packets transmitted, 0 packets received, 100% packet loss

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

ppro# arping -i fxp1 10.0.8.230
ARPING 10.0.8.230
60 bytes from 00:40:f4:b5:bd:d0 (10.0.8.230): index=0 time=13.767 msec
60 bytes from 00:40:f4:b5:bd:d0 (10.0.8.230): index=1 time=59.970 msec
^C
— 10.0.8.230 statistics —
2 packets transmitted, 2 packets received, 0% unanswered

ppro# ping 10.0.8.230
PING 10.0.8.230 (10.0.8.230): 56 data bytes
— 10.0.8.230 ping statistics —
3 packets transmitted, 0 packets received, 100% packet loss

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

ppro# arp -a
—net (10.0.8.0) at ff:ff:ff:ff:ff:ff on fxp1 permanent [ethernet]
1254-ESENINA-20-1 (10.0.8.3) at (incomplete) on fxp1 [ethernet]
1258-LUN-65 (10.0.8.20) at (incomplete) on fxp1 [ethernet]
1252-ESENINA-20-1 (10.0.8.22) at 00:00:17:00:02:c8 on fxp1 [ethernet]
1256-ESENINA-20-1 (10.0.8.29) at (incomplete) on fxp1 [ethernet]
1254-RUDN-45 (10.0.8.117) at 4c:00:10:61:0e:5a on fxp1 [ethernet]
1240-PR.ALL-6 (10.0.8.134) at 00:50:fc:51:f6:f5 on fxp1 [ethernet]
1247-PR.ALL-6 (10.0.8.142) at 00:04:e2:23:ae:7d on fxp1 [ethernet]
1245-PR.ALL-6 (10.0.8.147) at 00:0c:6e:82:58:7b on fxp1 [ethernet]
1242-XUD-54 (10.0.8.150) at 00:13:d4:66:87:ca on fxp1 [ethernet]
1295-PR.ALL-7 (10.0.8.154) at 00:14:78:29:49:02 on fxp1 [ethernet]
1230-PR.ALL-7 (10.0.8.165) at 00:c0:9f:0c:44:00 on fxp1 [ethernet]
1231-SIREN-8 (10.0.8.184) at 00:30:84:89:ac:7b on fxp1 [ethernet]
1234-ESENINA-15-1 (10.0.8.3) at (incomplete) on fxp1 [ethernet]

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

My traceroute [v0.69]
ppro.ru (0.0.0.0)(tos=0x0 psize=64 bitpattern=0x00) Tue Mar 21 10:39:55 2006
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 81.222.223.85 0.0% 79 2.8 2.5 1.2 6.3 0.8
2. 217.170.94.241 0.0% 79 2.5 3.1 1.8 12.3 1.4
3. vl101.RT001-201.eltel.net 0.0% 78 3.0 3.1 1.5 4.5 0.7
4. ge-0-1-0-102.rt008-001.spb.retn. 11.5% 78 3.7 3.7 1.8 14.0 1.7
5. ge-1-0-0.RT033-001.spb.retn.net 0.0% 78 4.0 3.2 1.9 5.2 0.7
6. so-5-0-0.RT503-001.msk.retn.net 0.0% 78 13.6 14.8 13.3 19.2 1.2
7. GW-Yandex.retn.net 0.0% 78 14.8 15.6 14.1 26.7 1.5
8. ya.ru 0.0% 78 14.9 15.9 14.6 18.1 0.8

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

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

mini# tcpdump -i rl1 host 81.222.220.193
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rl1, link-type EN10MB (Ethernet), capture size 96 bytes
07:00:15.451059 arp who-has 81.222.220.1 tell 81.222.220.193
07:00:15.457213 arp reply 81.222.220.1 is-at 00:f5:c3:b7:00:d0
07:00:15.467228 arp who-has 81.222.220.1 tell 81.222.220.193
07:00:15.467245 arp reply 81.222.220.1 is-at 00:f5:c3:b7:00:d0
07:00:15.467267 arp who-has 81.222.220.1 tell 81.222.220.193
07:00:15.467398 arp reply 81.222.220.1 is-at 00:f5:c3:b7:00:d0

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

traceroute to 10.60.93.10 (10.60.93.10), 64 hops max, 40 byte packets
1 core.cwn.ru (81.9.48.1) 0.357 ms 0.304 ms 0.362 ms
2 m10.hix.ru (81.9.48.14) 1.361 ms 1.346 ms 1.367 ms
3 utech-gw.hix.ru (81.9.48.246) 0.733 ms 0.721 ms 0.866 ms
4 ryazanka.hix.ru (81.9.48.245) 2.324 ms 1.680 ms 1.990 ms
5 utech-gw.hix.ru (81.9.48.246) 0.887 ms 2.742 ms 2.015 ms

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

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

mini# tcpdump -i rl2 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on rl2, link-type EN10MB (Ethernet), capture size 96 bytes
08:00:38.074261 arp who-has 192.168.1.68 tell 192.168.1.88
08:00:38.074265 arp who-has 192.168.1.68 tell 192.168.1.88
08:00:38.074310 arp reply 192.168.1.68 is-at 00:11:d8:9b:87:11
08:00:38.074316 arp reply 192.168.1.68 is-at 00:11:d8:9b:87:11
08:00:38.074355 arp who-has 81.222.234.33 tell 81.222.234.49
08:00:38.074380 arp reply 81.222.234.33 is-at 00:40:f4:b7:c3:70
08:00:38.074586 arp who-has 81.222.234.33 tell 81.222.234.49
08:00:38.074607 arp reply 81.222.234.33 is-at 00:40:f4:b7:c3:70
08:00:38.075080 arp who-has 194.16.107.61 tell 194.16.107.41
08:00:38.075090 arp who-has 194.16.107.61 tell 194.16.107.41
08:00:38.075130 arp reply 194.16.107.61 is-at 00:14:78:28:be:44
08:00:38.075140 arp reply 194.16.107.61 is-at 00:14:78:28:be:44

за доли секунд компьютеры запрашивают по несколько раз мак-адреса других устройств, с которыми хотят связаться… и получают несколько ответов, сеть в одном физическом пространстве с таким комутатором работать не будет.
Таким свойством обладает обычно оборудование производства компании Dlink, а именно DES тысячной серии, чаще всего свитчи становятся неисправными из-за статического напряжения после гроз. Как найти такой свитч в сети? Давайте посмотрим на карту сети и высяним где территориально находятся устройства запрашивающие адреса и получающие такие двойные ответы. Неисправный свитч находится вблизи от того копьютера – к которому повторные ответы идут с наименьшим количеством времени. Разница в одну единицу – практически идеальна. Так же известен такой вид сетевой атаки, как arp-спуффинг такой шторм из запросов и ответов, нарушитель спокойствивия ищется так же как и дупящий свитч. Связь может отсутсвовать из-за сетевых атак, и загруженного канала. Утилиты tcpdump и mrtg – быстро помогут отыскать проблему.
В том случае, если проблема не решена – рекомендую посоветоваться с более опытными специалистами, почитать что пишут о подобных проблемах в сети Интренет и специализированных журналах.

Взято здесь

Время на прочтение
6 мин

Количество просмотров 69K

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

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

Автор приложит все усилия, чтобы статьи оставались объективными и не превращались в рекламу GFN.RU.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как читать PING

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

В первую очередь, нужно определить IP адрес вашего домашнего роутера. Для этого необходимо ввести команду: cmd /k tracert -d ya.ru

Tracing route to ya.ru [87.250.250.242] over a maximum of 30 hops:

1 1 ms 1 ms <1 ms 192.168.88.1

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

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

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

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

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

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

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

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

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

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

Теперь, немножко нагрузим канал с помощью https://www.speedtest.net/ и параллельно запустим длинный ping.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для анализа спектра можно использовать программу WiFiInfoView : https://www.nirsoft.net/utils/wifiinformationview.html

Далее идем в эту статью : Wikipedia List of WLan channels

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

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

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

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

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

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

Конспект

Домашний маршрутизатор:

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

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

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

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

Wifi:

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

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

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

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

Как находить проблемы с интернетом и кто виноват ч.1 — inception

РАЗРЫВЫ СОЕДИНЕНИЯ

Разрывы могут быть вызваны теми же самыми причинами, которые препятствуют установлению соединения (они перечислены в предыдущей статье). Действия, описанные далее, подразумевают, что соединение работало корректно до того, как возникла проблема, и уже были предприняты следующие меры и установлены следующие факты:

• выполнена холодная перезагрузка проблемной рабочей станции (горячая перезагрузка не обнуляет состояние адаптерных карт). То же касается применения всех необходимых программных исправлений, если они были загружены, но не установлены. Кроме того, некоторым устройствам Plug-n-Play для полной установки требуется двукратная, а то и трехкратная перезагрузка;

• сбои в аппаратной части отсутствуют;

• сетевые кабели правильно подключены и функционируют должным образом;

• сетевая карта не отключена, в подсети назначаются нужные динамические (посредством DHCP) или статические адреса. Отчеты операционной системы о состоянии сетевой карты не содержат аномальных значений, в частности, число отправленных и полученных пакетов отлично от нуля (если хоть одно из этих значений нулевое, значит, надо разобраться, в чем причина);

• в последнее время ни на самой рабочей станции, ни на сервере не производилось никаких изменений в службах, конфигурации, программном или аппаратном обеспечении;

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

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

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

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

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

• некачественные кабели;

• пограничное состояние или некорректная работа сетевой карты рабочей станции либо порта в сетевом коммутаторе или концентраторе;

• ошибки или чрезмерный трафик в локальном коллизионном домене;

• несоответствие настроек дуплексного режима передачи;

• шум от электрического оборудования и других внешних источников.

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

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

Потенциальными проблемами в широковещательном домене следует заняться только после того, как установлено надежное соединение на уровне MAC. Типичный пример такого сбоя — невозможность создать стабильное логическое подключение через мост. К разрыву связи станции с серверами и маршрутизаторами в том же широковещательном домене могут приводить и проблемы на сетевом уровне:

• плохо работающий или неисправный порт для каскадирования (uplink port), находящийся в любом месте маршрута. Как правило, это следствие использования плохого кабеля;

• проблемы со связующим деревом в сети — возможно, также из-за плохого кабеля;

• широковещательный шторм или чрезмерный трафик другого типа в широковещательном домене (причем вовсе не обязательно, что этот трафик наблюдается на локальном порту);

• несоответствия в настройках дуплексного режима на каком-то участке маршрута;

• дублирующиеся IP-адреса;

• некорректное объявление маршрутов рабочей станцией или сервером.

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

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

• неустойчивая маршрутизация вследствие пограничного состояния порта или канала на каком-то участке за пределами широковещательного домена. Возможная причина — плохой кабель;

• чрезмерный трафик для низкоскоростного локального или глобального канала. Возможно, трафик отвергается, либо буфер переполнен;

• время отклика на запросы Ping и функции Trace Route варьируется;

• сервер или служба испытывают перегрузку.

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

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

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

МЕДЛЕННАЯ РАБОТА СЕТИ

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

Приводимые далее процедуры подразумевают, что до возникновения проблемы сетевое соединение функционировало корректно и вы уже проделали следующее:

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

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

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

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

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

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

• плохие кабели;

• пограничное состояние или некорректная работа сетевой карты рабочей станции либо порта на сетевом коммутаторе или концентраторе;

• ошибки или чрезмерный трафик в локальном коллизионном домене;

• несоответствие настроек дуплексного режима;

• шум от электрического оборудования и других внешних источников.

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

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

Проблемы с широковещательным доменом необходимо исключить только после того, как установлено надежное соединение на уровне MAC. Типичный пример такого сбоя — невозможность организовать стабильное логическое соединение через мост. К той же категории относятся и проблемы на сетевом уровне, которые могут препятствовать связи с серверами и маршрутизаторами, входящими в тот же широковещательный домен:

• порт для каскадирования (uplink port), расположенный в любом месте маршрута, неисправен. Как правило, это следствие использования плохого кабеля;

• проблемы со связующим деревом в сети — опять-таки из-за плохого кабеля;

• широковещательный шторм или чрезмерный трафик другого типа в широковещательном домене, причем не только на локальном порту;

• несоответствия в настройках дуплексного режима между двумя портами вдоль маршрута;

• повторяющиеся IP-адреса;

• рабочая станция или сервер некорректно объявляют маршруты.

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

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

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

• неустойчивая маршрутизация по вине пограничного состояния порта или линии на каком-то участке за пределами широковещательного домена. Возможная причина — плохой кабель;

• чрезмерный трафик по низкоскоростному локальному или глобальному соединению — возможно, трафик отвергается, либо буфер переполнен;

• варьируется время отклика на запросы Ping и функции Trace Route;

• перегружены соответствующие сервер или служба.

Отправка запросов Ping и трассировка маршрута посредством Trace Route позволяют найти точку, с которой следует начинать диагностирование медленной работы сети. Если проблема то появляется, то исчезает или ее трудно уловить, необходимо запустить тесты на непрерывное выполнение. Когда какой-то удаленный узел вызывает подозрение, процесс диагностирования можно ускорить, воспользовавшись системой управления сетью, чтобы опросить «скомпрометированное» сетевое устройство, а также устройство, находящееся перед ним. Одно из них укажет на определенные ошибки или чрезмерный уровень использования.

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

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

Игорь Панов — региональный менеджер по продукции и поддержке партнеров Fluke Networks в России и СНГ. С ним можно связаться по адресу: igor.panov@flukenetworks.com.