Ошибки в работе программного и аппаратного обеспечения сети обычно оказывают непосредственное и значительное влияние на производительность сети, так как время, затрачиваемое на ликвидацию последствий ошибок, является потерянным для выполнения нормальных операций.
2.4.1. Типичные ошибки в кадрах
2.4.1.1. Ошибки в кадрах, связанные с коллизиями
Ниже приведены типичные ошибки, вызванные коллизиями, для кадров протокола Ethernet:
2.4.1.2. Диагностика коллизий
Средняя интенсивность коллизий в нормально работающей сети должна быть меньше 5%. Большие всплески (более 20%) могут быть индикатором кабельных проблем.
Если интенсивность коллизий больше 10%, то уже нужно проводить исследование сети.
Рекомендуется следующий порядок исследования:
Решение проблем, связанных с коллизиями является достаточно сложной задачей, так как результаты наблюдений зависят от точки подключения сетевого анализатора (с точностью до нескольких меторов). Поэтому необходимо делать много измерений в различных точках.
В сети Ethernet на основе коаксиального кабеля в качестве причин коллизий могут выступать:
Причинами коллизий в сети Ethernet на витой паре могут быть:
2.4.1.3. Ошибки кадров Ethernet, связанные с длиной и неправильной контрольной суммой
2.4.1.4. Ошибки кадров Ethernet в стандарте RMON
Стандарт RMON определяет следующие типы ошибок кадров Ethernet:
etherStatsCRCAlignErrors - общее число полученных пакетов, которые имели длину (исключая преамбулу) между 64 и 1518 байтами, не содержали целое число байт (alignmenterror) или имели неверную контрольную сумму (FCSerror).
etherStatsUndersizePkts - общее число пакетов, которые имели длину, меньше, чем 64 байта, но были правильно сформированы.
etherStatsOversizePkts - общее число полученных пакетов, которые имели длину больше, чем 1518 байт, но были тем не менее правильно сформированы.
etherStatsFragments - общее число полученных пакетов, которые не состояли из целого числа байт или имели неверную контрольную сумму, и имели к тому же длину, меньшую, чем 64 байта.
etherStatsJabbers - общее число полученных пакетов, которые не состояли из целого числа байт или имели неверную контрольную сумму, и имели к тому же длину, большую, чем 1518 байт.
etherStatsCollisions - наилучщая оценка числа коллизий на данном сегменте Ethernet.
2.4.2. Типичные ошибки при работе протоколов
Кроме явных ошибок в работе сети, проявляющихся в появлении кадров с некорректными значениями полей, существуют ошибочные ситуации, являющиеся следствием несогласованной установки параметров протоколов в разных узлах или портах сети. Ввиду большого количества протоколов, применяемых в локальных сетях на различных уровнях стека, а также большого количества их параметров, невозможно описать все встречающиеся на практике ситуации рассогласования. Ниже приводятся только некоторые из них.
Другой причиной некорректной работы протоколов может быть несогласованность протоколов разного уровня в одном и том же узле, например, протоколов FDDI и IPX, разработанные в расчете на различные интерфейсы межуровневого взаимодействия в стеке, FDDI - а интерфейс NDIS, а IPX - на интерфейс ODI. Необходимо отметить, что само по себе использование различных интерфейсов между аналогичными протоколами в разных узлах сети не препятствует их нормальному взаимодействию, так как обмениваются данными по сети соответствующие протоколы, а не интерфейсы (рис. 2.16).
Рис. 2.16. Использование различных интерфейсов между протоколами соседних уровней
2.4.2.1. Несоответствие форматов кадров Ethernet
Ethernet - одна из самых старых технологий локальных сетей, имеющая длительную историю развития, в которую внесли свой вклад различиные компании и организации. В результате этого существует несколько модификаций даже такого основополагающего строительного блока протокола, как формат кадра. Использование различных форматов кадров может привести к полному отсутствию взаимодействия между узлами.
Всего имеется четыре популярных стандарта формата кадра Ethernet:
Кадр стандарта EthernetDIX, называемый также кадром EthernetII, разработан компаниями Digital, Xerox и Intel (первые буквы названия компаний и дали название этому варианту Ethernet) при создании первых сетей Ethernet. Всего было выпущено две версии фирменного стандарта Ethernet, поэтому последняя, вторая версия этого стандарта также иногда указывается при обозначении варианта протокола Ethernet и соответственно его формата кадра. Часто в литературе именно этот вариант формата кадра называют кадром Ethernet, оставляя для международного стандарта технологии EthernetIEEE 802.3 обозначение 802.3.
Кадр стандарта EthernetDIX имеет следующий формат:
| Preambule -Преамбула (8) | Destination -Адрес назначения (6) | Source - Адрес источника (6) | Type - Тип (2) | Data - Данные (46-1500) | Frame Check Sequence (FCS) - Контрольая сумма (4) |
Поля Destination и Source содержат 6-ти байтные МАС-адреса узла назначения и источника, а поле Type - двухбайтный идентификатор протокола верхнего уровня, который поместил свои данные в поле данных Data. Для поля Type существуют стандартные значения числовых идентификаторов для всех популярных протоколов, используемых в локальных сетях. Например, протокол IP имеет числовой идентификатор 0800 и т.п. Эти значения можно найти в постоянно обновляемом RFC ( например, в RFC 1700), в котором уазаны все конкретные числовые значения, применяемые в протоколах сети Internet.
В стандарте IEEEEthernet 802.3 определен формат кадра Ethernet, близкий к формату EthernetDIX, но имеющий некоторые отличия:
| Preambule -Преам- була (8) | Destination -Адрес назначения (6) | Source - Адрес источника (6) | Length - Длина (2) | DSAP - Точка входа сервиса назначения (1) | SSAP - Точка входа сервиса источника (1) | Control - Управ- ление (1) | Data - Данные (46-1497) | FrameCheck Sequence (FCS) - Контрольная сумма (4) |
Одно из принципиальных отличий заключается в том, что вместо поля Type в нем используется поле Length (Длина), также имеющее размер в 2 байта, но содержащее длину поля данных в байтах.
Поле Type встандарте 802.3 замененодвумядополнительнымиполями - DSAP (Destination Service Access Point) и SSAP (Source Service Access Point). Поле DSAP указывает сервис (протокол), которому предназначаются данные, а поле SSAP обозначают сервис (протокол), который отправил эти данные. Назначение этих полей то же, что и поля Type, но наличие двух полей позволяет организовать передачу данных между протоколами разного типа (правда, на практике это свойство никогда не используется). Однобайтовый формат полей SAP не позволил использовать в них те же числовые обозначения идентификаторов протоколов, которые прижились для кадров EthernetDIX, поэтому каждый протокол верхнего уровня имеет сейчас два идентификатора - один используется при инкапсуляции пакета протокола в кадр EthernetDIX, а второй - при инкапсуляции в кадр Ethernet 802.3.
Еще одним отличием кадра IEEE 802.3 является однобайтовое поле Control (Управление), которое предназначено для реализации режима работы с установлением соединенения. В поле Control должны помещаться номера кадров квитанций подтверждения доставки данных, необходимые для отработки процедур восстановления утерянных или искаженных кадров. На практике большинство операционных систем не использует этих возможностей кадра 802.3, ограничиваясь работой в дейтаграммном режиме (при этом значение поля Control всегда равно 03).
Так как стандарт IEEE делит канальный уровень на два подуровня - MAC и LLC, то иногда кадр Ethernet 802.3 также представляют как композиции двух кадров. Кадр МАС-уровня включает поля преамбулы, адресов назначения и источника, поле длины и поле контрольной суммы, а кадр LLC содержит поля DSAP, SSAP, Control и поле данных (которое из-за введения новых трех однобайтовых полей имеет максимальную длину на 3 байта меньше).
Кадр Novell 802.3, который также называют кадром Raw 802.3 (то есть "грубый" или "очищенный" вариант стандарта 802.3) представляет собой кадр МАС-уровня без полей уровня LLC:
| Preambule -Преамбула (8) | Destination -Адрес назначения (6) | Source - Адрес источника (6) | Length - Длина (2) | Data - Данные (46-1500) | Frame Check Sequence (FCS) - Контрольная сумма (4) |
Этот тип кадра длительное время успешно применялся компанией Novell в ее сетях NetWare. Отсутствие поля типа протокола верхнего уровня не создавало трудностей, так как в сетях Novell долгое время использовался только один протокол сетевого уровня - протокол IPX. В дальнейшем при переходе к многопротокольным сетям компания Novell стала использовать в качестве основного стандартный кадр IEEE 802.3 (который в документации Novell называется кадром 802.2 - номер стандарта на подуровень LLC).
Кадр EthernetSNAP (SubNetworkAccessProtocol) активно используется в сетях TCP/IP для достижения совместимости числовых идентификаторов протоколов с теми, которые используются в кадре EthernetDIX. Кадр EthernetSNAP определен в стандарте 802.2H и представляет собой расширение кадра IEEE 802.3 путем введения двух дополнительных полей: 3-х байтового поля OUI (OrganizationUnitIdentifier) и двухбайтового поля Type. Поле Type имеет тот же формат и то же назначение, что и поле Type кадра EthernetDIX. Поэтому числовые значения идентификаторов протоколов, помещаемые в это поле кадра EthernetSNAP, совпадают со значениями, используемыми в кадрах EthernetDIX, и в этом весь смысл введения дополнительных полей заголовка SNAP. В поле OUI указывается код организации, которая определеяет стандартные значения для поля Type. Для протокола Ethernet такой организацией является комитет IEEE 802.3, и его код равен 00 00 00. Наличие поля OUI позволяет использовать заголовок SNAP не только для протокола Ethernet, но и для других протоколов, которые контролируются другими организациями.
Если оборудование или операционная система настроены на поддержку какого-то одного формата кадра Ethernet, то они могут не найти взаимопонимания с другим узлом, который в свою очередь поддерживает также один формат кадра Ethernet, но другого типа. Результатом попыток взаимодействия таких узлов будет отбрасывание поступающих кадров, так как неверная интерпретация формата приведет к неверной контрольной сумме кадра.
Многие современные операционные системы и коммуникационное оборудование умеют одновременно работать с различными типами кадров, распознавая их автоматически. Распознавание идет по значению 2-х байтового поля, расположенного за адресом источника. Это поле может быть полем Type или Length. Числовые идентификаторы протоколов выбраны так, что значение поля Type будет всегда больше 1500, в то время как поле Length всегда содержит значение меньше или равное 1500. Дальнейшее отделение кадров EthernetSNAP от IEEE 802.3 проводится на основании значения полей DSAP и SSAP. Если присутствует заголовок SNAP, то поля DSAP и SSAP всегда содержат вполне определенный числовой идентификатор, зарезервированный за протоколом SNAP.
Автоматическое распознавание типа кадра избавляет пользователей сети от неприятных проблем, однако та же ОС или маршрутизатор могут быть настроены на поддержку только одного типа протоколов, и в этом случае проблема несовместимости может проявляться.
Сетевые анализаторы и средства мониторинга умеют автоматически различать форматы кадров Ethernet. Для задания условий захвата кадров, содержащих пакеты определенных протоколов верхнего уровня, анализаторы позволяют пользоваться как числовыми идентификаторами этих протоколов для полей SAP (DSAP и SSAP), так и числовыми идентификаторами для поля Type (имеющим также название EtherType).
В сетях TokenRing и FDDI всегда используются кадры стандартного формата, поэтому в этих сетях не возникают проблемы, связанные с несовместимостью форматов кадров.
2.4.2.2. Потери пакетов и квитанций
Регулярные потери пакетов или кадров могут иметь очень тяжелые последствия для локальных сетей, так как протоколы нижнего уровня (канальные протоколы) рассчитаны на качественные кабельные каналы связи и работают поэтому в дейтаграммном режиме, оставляя работу по восстановлению потерянных пакетов протоколам верхнего уровня.
К значительному снижению производительности могут приводить также потери служебных сообщений - квитанций подтверждения доставки, сообщений типа keepalive и т.п. Обычно протоколы более чувствительны к подобным потерям и даже разовые ситуации подобного рода могут вызывать серьезные последствия. Это легко объясняется особым значением для протокола служебной информации.
Примером может служить протокол NCP в режиме burstmode, когда положительная квитанция посылается не на каждый пакет, а на целую пачку пакетов. Если пакеты из этой пачки с пользовательскими данными дошли благополучно, а квитанция по доставке по каким-то причинам была искажена и тем самым отброшена передающим узлом, то этот узел по истечении тайм-аута повторно пошлет большую порцию информации, содержащейся в данной пачке. Повторные передачи пакетов могут существенно снизить полезную пропускную способность сети.
2.4.2.3. Несоответствие разных способов маршрутизации в составной сети
Маршрутные таблицы, используемые маршрутизаторами для продвижения пакетов определенного сетевого протокола, всегда имеют одинаковую структуру, однако способ их получения может быть разным - ручной, по протоколу RIP, по протоколу OSPF или же еще по какому-нибудь другому протоколу динамического обмена информацией. Если в разных частях составной сети используются различные протоколы обмена маршрутной информации, то это может приводить к несогласованной работе маршрутизаторов и, следовательно, к отсутствию достижимости некоторых сетей для пользователей.
Каждый протокол обмена маршрутной информации использует свой формат служебных сообщений для распространения своих знаний о топологии сети. Поэтому, если не предпринимать дополнительных мер, то части сети, использующие разные протоколы маршрутизации, вообще не смогут автоматически взаимодействовать.
Для обеспечения совместимости протоколов маршрутизации разработаны специальные протоколы, которые передают маршрутные данные между различными частями сети в унифицированном формате. К таким протоколам относятся протокол EGP (ExteriorgatewayProtocol) и его более поздняя модификация BGP (BorderGatewayProtocol), разработанные и применяемые в сети Internet. Они могут переносить знания о сетях между протоколами RIP, OSPF, NLSP, IS-IS и другими.
Однако, только применение протоколов типа EGP или BGP не решает проблем работы гетерогенной в отношении протоколов маршрутизации сети. Знания о какой-либо сети могут поступить от разных частей сети, и, соответственно, от разных протоколов. В таких случаях для устойчивой работы сети нужно отдавать приоритет более надежно работающим в условиях изменения топологии протоколам типа "состояние связей", таких как OSPF, NLSP и IS-IS. Многие маршрутизаторы позволяют задавать приоритеты одних протоколов маршрутизации перед другими.
Для того, чтобы администратор мог "подправлять" таблицы маршрутизации, полученные автоматическим способом, наивысший приоритет обычно отдается маршрутам, заданным вручную. Однако, такие маршруты могут быть и причиной недостижимости некоторых сетей, так как вероятность внесения человеком ошибки всегда существует, причем она быстро повышается при увеличении размера сети. Использовании в сети масок неравной длины - также типичная причина недостижимости подсетей в результате недостаточно всестороннего анализа возможных маршрутов в сети.
В сетях TCP/IP ошибочные ситуации, фиксируемые маршрутизатором при невозможности передать пакет в сеть назначения, сообщаются конечному узлу служебным протоколом ICMP, пакеты которого обязательно нужно анализировать в больших сетях, использующих маршрутизаторы.
2.4.2.4. Несуществующий адрес и дублирование адресов
Отправка пакета по несуществующему адресу естественно не может привести к нормальному взаимодействию узлов в сети. Несуществующие адреса могут появиться в сети только в том случае, когда они хранятся постоянно в базе данных стека протоколов (например, в базе службы DNS стека TCP/IP или службы NDS сетей NetWarе). При этом может наступить момент, когда хранящийся адрес устареет и не будет соответствовать действительности.
В случае, когда адреса изучаются динамически, путем анализа пакетов служебного протокола, подобного SAP, использование несществующего адреса практически исключается, так как информация об адресе только что поступила от узла, которому этот адрес присвоен.
Серьезные проблемы в сети создает дублирование адресов, то есть наличие в сети двух узлов с одним и тем же адресом. Такая ситуация чаще всего приводит к недостижимости обоих узлов с одинаковым адресом, или же к нарушению нормальной работы всей сети, если дублируются не адреса узлов, а адреса сетей (IP или IPX). Проблема дублирования адресов характерна в большей степени для адресов верхних уровней, начиная с сетевого, где адреса назначаются администратором и поэтому могут повторяться в результате человеческих ошибок. Адреса канального уровня (МАС-адреса) присваиваются сетевым адаптерам, портам маршрутизаторов и агентам SNMP-управления компаниями-производителями, поэтому их дублирование маловероятно (только в случае переназначения адреса, что возможно путем его программирования).
Для обнаружения повторяющихся адресов в сетях необходимо использовать анализатор протоколов, настроив его на захват пакетов с определеным адресом сети и/или узла. Некоторые протоколы локальных сетей используют специальную процедуру для проверки дублирования адресов на канальном уровне (например, TokenRing, FDDI).
2.4.2.5. Превышение значений тайм-аута и несогласованные значения тайм-аутов
Тайм-ауты - очень важные параметры многих протоколов, так как их непредвиденное превышение обычно приводит к серьезным последствиям. Например, превышение тайм-аута может привести к разрыву логического соединения между сервером и клиентом, или же к ненужным повторным передачам данных, которые и так уже благополучно дошли до получателя. Разрыв логического соединения приводит к большим временным потерям, а значит и к значительному снижению пропускной способности сети, так как процедура установления соединения может включать обмен сотнями пакетов, передающих аутентификационную и другую служебную информацию.
Наиболее чувствительным к превышению тайм-аута протоклом канального уровня является протокол SDLC стека SNA компании IBM. Из-за этого к территориальным сетям, передающим трафик SDLC, предъявляются повышенные требования к величине и стабильности времени реакции.
Однако, не только протокол SDLC чувствителен к временным задержкам передачи пакетов. Многие протоколы, работающие в режиме логического соединения, обладают таким свойством. Например, протокол TCP следит за целостностью логического соединения путем установки специального таймера, который устанавливается при прибытии очередного TCP-сообщения. Если таймер истекает раньше, то сессия TCP разрывается, что приводит к разрыву сессии протокола прикладного уровня, например, FTP. Так как протокол FTP не обладает свойством продолжения передачи файла с прерванного места после разрыва и повторного установления соединения, то разрывы сессии TCP могут приводить к тому, что файл объемом в несколько мегабайт, который был передан почти полностью, придется передавать заново. Подобная ситуация иногда встречается в сети Internet, когда загруженность FTP-сервера или маршрутизаторов приводит к значительным задержкам отправки очередного TCP-сообщения. Для предотвращения разрывов в протоколе TCP предусмотрена возможность генерации пакетов keepalive в то время, когда отсутствуют пользовательские данные для передачи, однако этот режим является опциональным и не все реализации стека TCP/IP его поддерживают.
В локальных сетях превышение тайм-аута наблюдается гораздо реже, чем в глобальных, но при большой загрузке сети может также иметь место.
Нестабильный характер проявления ошибок истечения тайм-аутов затрудняет диагностику, так как ошибка проявляется в случайных потерях связи пользователей с серверами и может наблюдаться только в периоды большой нагрузки сети, никак не проявляя себя в остальное время.
К аналогичным последствиям приводят несогласованные значения тайм-аутов у взаимодействующих узлов или коммуникационных устройств. Примером такой несогласованности могут служить разные значения тайм-аута у пограничных маршрутизаторов при спуфинге широковещательного трафика. Другим примером может быть различный период обновления базы маршрутной информации у маршрутизаторов.
Назад | Содержание | Вперед