Администрирование_в_информационных_системах_Беленькая_М_Н_

При обнаружении коллизии станцией или коммутатором, посылается «пробка» (JAM), которая представляет собой нестандартизированный 32-битный фрейм. Часто это просто сигнал тактовой частоты 10 МГц. Если он посылается слишком рано, то уничтожается (затирается) часть заголовка фрейма, и адрес источника или получателя искажается. Коммутаторы, обнаружив коллизию на одном из портов, разошлют пробку всем остальным портам, чтобы коллизия стала известна станциям.

В современных коммутируемых сетях с топологией кабельной системы типа «звезда» коллизия обнаруживается нодой сети при одновременном сигнале на пинах пары приема (RC) и пинах пары передачи (TR). Если коммутатор обнаруживает такую коллизию на своем порту, то распознает ее как локальную. Если такая коллизия обнаруживается на порту рабочей станции, то передача фрейма прерывается, и он передается как короткий фрейм до 64 байт с неправильной контрольной суммой (FCS). Он настолько короткий, что заголовок не передается целиком, а пробка занимает четыре последних байта. Коммутатор распознает этот фрейм как удаленную коллизию. Практически все коллизии в современных Ethernet-сетях воспринимаются как удаленные. Все это необходимо понимать администратору системы при анализе Ethernet-сети.

Коллизии не являются ошибкой, они обязательны в сетях с конкурентным методом доступа. Вопрос только в их количестве. По рекомендациям компаний-производителей диагностических средств существует специальный вид проверки на ошибки длительностью в одну минуту [51]. Рассмотрим ее подробнее.

Проверка Ethernet «1 минута» предполагает следующий анализ:

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

—процент средней утилизации (использования) канала (на сколько процентов в единицу времени загружен канал) должен быть до 40%. При этом необходимо следить, чтобы не было долговременных всплесков утилизации более 60%. В противном случае администратору системы следует принимать меры по сегментации сети;

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

—широковещательный трафик (Broadcast) не может составлять более 5—10% пропускной способности канала.

При правильной работе ошибок не должно быть обнаружено.

Теперь рассмотрим основные ошибки, которые могут произойти в сетях Ethernet [51, 65]. К ним относятся поздняя коллизия, короткий фрейм, неверная контрольная сумма (FCS), «болтовня» (Jabber), «карлики» (Runts), «привидения» (Ghosts), ошибки выравнивания.

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

впоследних четырех байтах содержится пробка. Так как коллизия происходит после того, как 64-ый байт был передан, то автоматически фрейм повторно не передается. Вместо этого протокол верхнего уровня (например, TCP или SPX) должен среагировать на то, что данные отсутствуют, и послать запрос на повторную передачу данных.

Как правило, поздняя коллизия вызвана дефектным сетевым оборудованием.

Короткий фрейм — это фрейм длиной менее 64 байт (после 8-байтной преамбулы) с правильной контрольной суммой (последовательностью FCS). Наиболее вероятная причина появления коротких фреймов — неисправная сетевая плата или неправильно сконфигурированный сетевой драйвер.

Неверная контрольная сумма (FCS). Когда фрейм данных пересылается от одного сетевого устройства к другому, передающая станция вычисляет контрольную последовательность фрейма (FCSили CRC-контрольную сумму) и добавляет ее

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

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

Карлики (Runts). Многие анализаторы протоколов и сетевых мониторов подсчитывают фреймы-карлики. К сожалению, термин Runt не стандартизирован, и его определение имеет разные значения в различных продуктах. Runt может быть любым типом фрейма, который короче, чем разрешенный минимум в Ethernet (48 байт), включая локальные удаленные коллизии или коллизии на этапе передачи преамбулы с хорошей или плохой FCS.

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

Ghosts являются «коварными» ошибками, так как они не распознаются программными анализаторами протоколов (как и коллизии на этапе передачи преамбулы). Некоторые типы шума воспринимаются нодами как получение фреймов. На самом деле никакой информации не передается. Различные сетевые интерфейсы будут реагировать на это по-разному. Не существует стандартов реагирования на шумы в сегментах сети. Коммутаторы будут иногда передавать эти сигналы в другие сегменты сети.

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

Обычно причиной появления ghosts являются электротехнические проблемы.

Болтовня (Jabber) определяется как длинный фрейм (long frame), длиннее 1518 байт. Длинный фрейм может иметь правильную или неправильную контрольную последовательность. Длинные фреймы с неправильной контрольной последовательностью обычно называют Jabber. Обнаружение длинных фреймов с правильной контрольной последовательностью указывает чаще всего на некорректность работы сетевого драйвера. Ошибки типа Jabber свидетельствуют об неисправности активного оборудования или наличии внешних помех.

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

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

8.7.Диагностика ошибок

âсреде протоколов TCP/IP

Основные проблемы протоколов TCP/IP обычно связаны с неправильной адресацией и настройками [51, 65]. При поиске ошибок на компьютере, где используется набор протоколов TCP/IP и операционная система Microsoft, АС может легко увидеть настройки TCP/IP, используя следующие команды:

—Winipcfg — для компьютеров с операционной системой Windows 9x;

—Ipconfig/all — для компьютеров с операционной системой Windows NT.

Рассмотрим подробнее основные проблемы адресации [8, 51, 65].

Неправильный IP-адрес. В сети TCP/IP все компьютеры и сетевые устройства должны иметь уникальный IP-адрес [14, 9]. Когда компьютеры сконфигурированы так, что в сети встречается дублирующий адрес, то они не могут в ней взаимодействовать. При появлении в сети двух станций с одинаковыми IP-адресами их отслеживание может быть довольно затруднительным. Тестирующее устройство может помочь предоставлением списка IP-адресов и соответствующих им MAC-адресов, но затем поиск неисправностей переходит в утомительное занятие — «сходить» к нужной рабочей станции и посмотреть настройки сети.

Некоторые операционные системы, такие как Microsoft Windows 9x и Windows NT, сами определяют дублирование адреса при включении компьютера и отключают набор протоколов TCP/IP на этом компьютере, пока эта проблема не разрешится.

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

Неверная маска подсети. Маска подсети используется станцией, чтобы определить, принадлежит ли адрес получателя к локальному сегменту сети или к удаленному. Если получатель находится в локальном сегменте, станция пытается отыскать MAC-адрес отправителя с помощью широковещательной рассылки, используя протокол ARP (Address Resolution Protocol) [9]. Если получатель находится в удаленном сегменте, то станция использует внутреннюю таблицу маршрутизации, чтобы определить, на какой маршрутизатор следует передать пакет для доставки.

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

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

Неверный адрес шлюза. Станция, работающая c протоколами TCP/IP, определяет, где находится получатель — в локальном или в удаленном сегменте. Если получатель находится

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

Проблема разрешенных имен. Пользователи предпочитают использовать в качестве имен хостов символьные, а не цифровые имена. Если со станции можно определить с помощью утилиты Рing IP-адреса, но нельзя соединиться (или «пинговать» те же компьютеры по их именам), необходимо проверить, что DNS-сервера в настройках протоколов TCP/IP корректны для этой сети. Система доменных имен (DNS — Domain Name System) — это главный механизм, использующийся

всетях TCP/IP для преобразования имен сетевых устройств в их IP-адреса [8, 9].

По рекомендациям компаний-производителей диагностических средств существует специальный вид быстрой проверки «1 минута» на ошибки TCP/IP. Рассмотрим ее подробнее.

При быстрой проверке TCP/IP администратор системы должен произвести ниже перечисленные действия [51, 65].

1.Составить список устройств, работающих как хосты.

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

3.Проверить по списку мосты/коммутаторы, работающие по протоколу STA-Spanning Tree.

4.Проверить правильность именования подсетей. Для большинства сетей обычно задается только одна подсеть. Если их несколько, необходимо понять причину их появления. Обычно это свидетельство того, что в сети есть неправильно сконфигурированные IP-устройства.

5.Проверить по списку устройства, предоставляющие сервисы DNS, BOOTP, DHCP. Убедиться, что они правильно сконфигурированы.

Проверить устройства, управляемые по SNMP протоколу и

работающие SNMP-агенты.

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

При правильной работе ошибок вообще не должно быть обнаружено.

8.8. Предупреждение ошибок в среде протоколов TCP/IP

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

Рассмотрим такие мероприятия, как администрирование IP-адресов и документирование конфигурации хоста и сетевых устройств [51, 65].

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

тору системы для получения нового IP-адреса. В некоторых случаях необходимо использовать DHCP-сервер (Dynamic Host Configuration Protocol), для того чтобы IP-адреса автоматически присваивались сетевым устройствам из пула IP-адресов [9]. Таким образом, проблема дублирования IP-адресов будет полностью исключена. Создание DHCP-серверов в последних версиях сетевых операционных систем занимает незначительное время.

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

Документирование конфигурации хоста и сетевых устройств.

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

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

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

8.9.Решения проблем

âсреде протоколов TCP/IP

8.9.1.Проблемы установления соединения

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

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

—хост не имеет каких-либо аппаратных проблем;

—все необходимые кабели присутствуют и корректно подключены;

—все необходимые драйверы сетевых адаптеров установлены и при их установке не зафиксировано ошибок;

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

—нет ошибок на MAC-уровне.

Необходимо проверить документацию сети и убедиться в том, что:

—хост верно сконфигурирован и имеет верный IP-адрес;

—предоставленный IP-адрес подходит под данную маску подсети;

—нет другой станции, использующей тот же адрес;

—адреса маршрутизатора по умолчанию и шлюза корректны и правильно сконфигурированы;

—адрес DNS-сервера корректен и правильно сконфигурирован, т. е. проблемы локальны;

—DNS-сервер загружен и выбранный хост доступен из этого соединения (проблемы глобальны).

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

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

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

8.9.2. Проблемы конфигурации IP,

дублируемого IP-адреса и некорректной маски подсети

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

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

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