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

 

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

Самым важным инструментом будет тестор, либо оптоволоконный измеритель, для проверки уровня и стабильности сигнала в линии. Очень пригодится ноутбук, желательно с какой-либо 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 – быстро помогут отыскать проблему.
В том случае, если проблема не решена – рекомендую посоветоваться с более опытными специалистами, почитать что пишут о подобных проблемах в сети Интренет и специализированных журналах.

 

Заключение

 

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

 

В хоте прокладки локальной сети стоит соблюдать правила:

1. Допустимый изгиб в ходе монтажа не менее 3÷4 диаметров

2. Следует избегать излишней нагрузки на кабели, обычно вызываемой их перекручиванием

3. Кабели горизонтальной системы должны использоваться в сочетании с коммутационным оборудованием и патч-кордами

4. Качество собранной кабельной системы в целом определяется по компоненту линии с наихудшими рабочими характеристиками

 

Чаще всего локальные сети построены на технологиях Ethernet или Wi-Fi. Следует отметить, что ранее использовались протоколы Frame Relay, Token ring, которые на сегодняшний день встречаются всё реже, их можно увидеть лишь в специализированных лабораториях, учебных заведениях и службах.

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

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

 

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

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

 

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

 

При диагностике необходимо отслеживать следующий параметр:

 

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

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

Так же нужно знать следующие программы для диагностики сети: NET DIAGS, ScanLink и уметь пользоваться такими приборами, как MICROSCANNER, PentaScanner+2-way Injector/Super Injector, CertiFiber, Fluke Networks OptiView Workgroup Analyzer, OptiView™ WGA.