Stuff that matters

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

---

Вступление.

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

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

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

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

---

Взято здесь