Форматы кадров технологии Ethernet

Статья получилась довольно объёмная, рассмотренные темы - форматы Ethenet фреймов, границы размеров L3 Payload, эволюция размеров Ethernet заголовков, Jumbo Frame, Baby-Giant, и много чего задето вскользь. Что-то вы уже встречали в обзорной литературе по сетям передачи данных, но со многим, однозначно, не сталкивались, если глубоко не занимались изысканиями.

Начнём с рассмотрения форматов заголовков Ethernet фреймов в очереди их появления на свет.

Форматы Ehternet фреймов.

1) Ethernet II

Рис. 1

Preamble – последовательность бит, по сути, не являющаяся частью ETH заголовка определяющая начало Ethernet фрейма.

DA (Destination Address) – MAC адрес назначения, может быть юникастом, мультикастом, бродкастом.

SA (Source Address) – MAC адрес отправителя. Всегда юникаст.

E-TYPE (EtherType) – Идентифицирует L3 протокол (к примеру 0x0800 – Ipv4, 0x86DD – IPv6, 0x8100- указывает что фрейм тегирован заголовком 802.1q, и т.д. Список всех EtherType - standards.ieee.org/develop/regauth/ethertype/eth.txt)

Payload – L3 пакет размером от 46 до 1500 байт

FCS (Frame Check Sequences) – 4 байтное значение CRC используемое для выявления ошибок передачи. Вычисляется отправляющей стороной, и помещается в поле FCS. Принимающая сторона вычисляет данное значение самостоятельно и сравнивает с полученным.

Данный формат был создан в сотрудничестве 3-х компаний – DEC, Intel и Xerox. В связи с этим, стандарт также носит название DIX Ethernet standard . Данная версия стандарта была опубликована в 1982г (первая версия, Ehernet I – в 1980г. Различия в версиях небольшие, формат в целом остался неизменным). В 1997г. году данный стандарт был добавлен IEEE к стандарту 802.3, и на данный момент, подавляющее большинство пакетов в Ethernet сетях инкапсулированы согласно этого стандарта.

2) Ethernet_802.3/802.2 (802.3 with LLC header)

Рис. 2

Как вы понимаете, комитет IEEE не мог смотреть спокойно, как власть, деньги и женщины буквально ускользают из рук. Поэтому, занятый более насущными проблемами, за стандартизацию технологии Ethernet взялся с некоторым опозданием (в 1980 взялись за дело, в 1983 дали миру драфт, а в 1985 сам стандарт), но большим воодушевлением. Провозгласив инновации и оптимизацию своими главными принципами, комитет выдал следующий формат фрейма, который вы можете наблюдать на Рисунке 2.

Первым делом обращаем внимание на то, что “ненужное” поле E-TYPE преобразовано в поле Length, которое указывало на количество байт следующее за этим полем и до поля FCS. Теперь, понять у кого длинее можно было уже на втором уровне системы OSI. Жить стало лучше. Жить стало веселее.

Но, указатель на тип протокола 3его уровня был нужен, и IEEE дало миру следующую инновацию - два поля по 1 байту - Source Service Access Point(SSAP ) и Destination Service Access Point (DSAP ). Цель, таже самая, – идентифицировать вышестоящий протокол, но какова реализация! Теперь, благодаря наличию двух полей в рамках одной сессии пакет мог передаваться между разными протоколами, либо же один и тот же протокол мог по разному называться на двух концах одной сессии. А? Каково? Где ваше Сколково?

Замечание: В жизни же это мало пригодилось и SSAP/DSAP значения обычно совпадают. К примеру SAP для IP – 6, для STP - 42 (полный список значений - standards.ieee.org/develop/regauth/llc/public.html)

Не давая себе передышки, в IEEE зарезервировали по 1 биту в SSAP и DSAP. В SSAP под указание command или response пакета, в DSAP под указание группового или индивидуального адреса (см. Рис. 6). В Ethernet сетях эти вещи распространения не получили, но количество бит в полях SAP сократилось до 7, что оставило лишь 128 возможных номера под указание вышестоящего протокола. Запоминаем этот факт, к нему мы ещё вернёмся.

Было уже сложно остановиться в своём стремлении сделать лучший формат фрейма на земле, и в IEEE фрейм формате появляется 1 байтное поле Control . Отвечающее, не много, не мало, за Connection-less или же Connection-oriented соединение!

Выдохнув и осмотрев своё детище, в IEEE решили взять паузу.

Замечание : Рассматриваемые 3 поля - DSAP, SNAP и Control и являются LLC заголовком.

3) «Raw» 802.3

Рис. 3

Данный «недостандарт» явил в мир Novell. Это были лихие 80-ые, все выживали, как могли, и Novell не был исключением. Заполучив ещё в процессе разработки спецификации стандарта 802.3/802.2, и лёгким движением руки выкинув LLC заголовок, в Novell получили вполне себе неплохой фрейм формат (с возможность измерения длины на втором уровне!), но одним существенным недостатком – отсутствием возможности указания вышестоящего протокола. Но, как вы уже могли догадаться, работали там ребята не глупые, и по здравому размышлению выработали решение – «а обратим ка мы свои недостатки в свои же достоинства», и ограничили этот фрейм-формат исключительно IPX протоколом, который сами же и поддерживали. И задумка хорошая, и план был стратегически верный, но, как показала история, не фортануло.

4) 802.3 with SNAP Header.

Время шло. В комитет IEEE приходило осознание того, что номера протоколов и деньги кончаются. Благодарные пользователи засыпали редакцию письмами, где 3-х байтный LLC заголовок ставился в один ряд с такими великими инновациями человечества, как оборудование собаки 5ой ногой, или же с рукавом, который можно использовать для оптимизации женской анатомии. Выжидать дальше было нельзя, настало время заявить о себе миру повторно.

Рис. 4

И в помощь страждущим от нехватки номеров протоколов (их всего могло быть 128 – мы упоминали), IEEE вводит новый стандарт фрейма Ethernet SNAP (Рис. 4). Основное нововведение - добавление 5-ти байтного поля Subnetwork Access Protocol (SNAP), которое в свою очередь состоит из двух частей – 3х байтного поля Organizationally Unique Identifier (OUI) и 2х байтного Protocol ID (PID) - Рис. 5.

Рис. 5

OUI или же vendor code – позволяет идентифицировать пропиетарные протоколы указанием вендора. К примеру, если вы отловите WireShark`ом пакет PVST+, то в поле OUI увидите код 0x00000c, который является идентификатором Cisco Systems (Рис. 6).

Рис. 6

Замечание: Встретить пакет с инкапсуляцией в формат фрейма 802.3 SNAP довольно легко и сейчас – это все протоколы семейства STP, протоколы CDP, VTP, DTP.

Поле PID это, по сути, то же поле EtherType из DIX Ethernet II - 2 байта под указание протокола вышестоящего уровня. Так как ранее, для этого использовались DSAP и SSAP поля LLC заголовка, то для указания того, что тип вышестоящего протокола нужно смотреть в поле SNAP, поля DSAP и SSAP принимают фиксированное значение 0xAA (также видно на Рис. 6)

Замечание: При использовании для переноса IP пакетов формата фрейма LLC/SNAP, IP MTU снижается с 1500 до 1497 и 1492 байт соответственно.

По заголовкам в формате фрейма в принципе всё. Хотел бы обратить внимание на ещё один момент в формате фрейма – размер payload. Откуда взялся этот диапазон - от 46 до 1500 байт?

Размер L3 Payload.

Откуда взялось нижнее ограничение, знает, пожалуй, каждый, кто хотя бы читал первый курикулум CCNA. Данное ограничение является следствием ограничения в размер фрейма в 64 байта (64 байта – 14 байт L2 заголовок - 4 байта FCS = 46 байт) накладываемого методом CSMA/CD – время требуемое на передачу 64 байт сетевым интерфейсом является необходимым и достаточным для определения коллизии в среде Ethernet.
Замечание: В современных сетях, где возникновение коллизий исключено, данное ограничение уже не актуально, но требование сохраняется. Это не единственный «аппендикс» оставшийся с тех времен, но о них поговорим в другой статье.

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

Задержка при передаче – чем больше фрейм, тем дольше длится передача. Для ранних сетей, где Collision домен не ограничивался портом, и все станции должны были ждать завершения передачи, это было серьёзной проблемой.
Чем больше фрейм, тем больше вероятность того что фрейм при передаче будет поврежден, что приведет к необходимости повторной передачи, и все устройства в collision домене будут вынуждены опять ожидать.
Ограничения, накладываемые памятью используемой под интерфейс буферы – на тот момент (1979г) увеличение буферов значительно удорожало стоимость интерфейса.
Ограничение, вносимое полем Length/Type – в стандарте закреплено, что все значения выше 1536 (от 05-DD до 05-FF.) указывают на EtherType, соответственно длина должна быть меньше 05-DC. (У меня правда есть подозрение, что это скорее следствие, чем предпосылка, но вроде инфа от разработчиков стандарта 802.3)

Итого, в стандарте 802.3 размер фрейма ограничивался 1518 байтами сверху, а payload 1500 байтами (отсюда и дефолтный размер MTU для Ethernet интерфейса).

Замечание: Фреймы меньше 64 байт называются Runts, фреймы больше 1518 байт называются Giants. Просмотреть кол-во таких фреймов полученных на интерфейсе можно командой show interface gigabitEthernet module/number и show interface gigabitEthernet module/number counters errors. Причём до IOS 12.1(19) в счётчики шли как фреймы с неверным, так и верным CRS (хотя вторые не всегда дропались – зависит от платформы и условий). А вот начиная с 12.1.(19) отображаются в этих счётчиках только те runt и giant фреймы, которые имеют неверный CRS, фреймы меньше 64 байт, но с верным CRS (причина возникновения обычно связана с детегированием 802.1Q или источником фреймов, а не проблемами физического уровня) с этой версии попадают в счётчик Undersize, дропаются они, или же форвардятся дальше, зависит от платформы.

Эволюция размеров Ethernet заголовков.

С развитием технологий и спецификаций линейки IEEE 802 претерпевал изменения и размер фрейма. Основные дальнейшее изменения размера фрейма (не MTU!):

802.3AC - увеличивает максимальный размер фрейма до 1522 – добавляется Q-tag – несущий информацию о 802.1Q (VLAN tag) и 802.1p (биты под COS)
802.1AD - увеличивает максимальный размер фрейма до 1526, поддержка QinQ
802.1AH (MIM) – Provider Bridge Backbone Mac in Mac + 30 байт к размеру фрейма
MPLS – увеличиваем размер фрейма на стек меток 1518 + n*4, где n – количество меток в стеке.
802.1AE – Mac Security, к стандартным полям добавляются поля Security Tag и Message Authentication Code + 68 байт к размеру фрейма.

Все эти фреймы увеличенного размера группируются под одни именем – Baby-Giant frames. Негласное верхнее ограничение по размерам для Baby-Giant – это 1600 байт. Современные сетевые интерфейсы будут форвардить эти фреймы, зачастую, даже без изменения значения HW MTU.

Отдельно обратим внимание на спецификации 802.3AS - увеличивает максимальный размер фрейма до 2000 (но сохраняет размер MTU в 1500 байт!). Увеличение приходится на заголовок и трейлер. Изначально увеличение планировалось на 128 байт – для нативной поддержки стандартом 802.3 вышеперечисленных расширений, но в итоге сошлись на 2х тысячах, видимо, чтобы два раза не собираться (или как говорят в IEEE – this frame size will support encapsulation requirements of the foreseeable future). Стандарт утвержден в 2006 году, но кроме как на презентациях IEEE, я его не встречал. Если у кого есть что добавить здесь (и не только здесь) – добро пожаловать в комменты. В целом тенденция увеличения размера фрейма при сохранении размера PAYLOAD, порождает у меня в голове смутные сомнения в правильности выбранного направления движения.

Замечание: Немного в стороне от перечисленного обосновался FCoE фрейм – размер фрейма до 2500 байт, зачастую, эти фреймы называются mini-jumbo. Для их саппорта необходимо включать поддержку jumbo-frame.

И последний «бастард» Ethernet это Jumbo Frame (хотя если перевести Jumbo, то вырисовывается скорее Ходор – отсылка к Game of Thrones). Под это описание попадают все фреймы превосходящие размером стандарт в 1518 байт, за исключением рассмотренных выше. Jumbo пакеты никак не отражены в спецификациях 802.3 и поэтому реализация остаётся на совести каждого конкретного вендора. Тем не менее, Jumbo фреймы существуют столько же, сколько существует Ethernet. Определено это следующим:

Выгода соотношения Payload к заголовкам. Чем больше это соотношение, тем эффективней мы можем использовать линии связи. Конечно здесь разрыв будет не такой как в сравнении с использованием пакетов в 64 байт и 1518 байт для TCP сессий. Но свои 3-8 процентов, в зависимости от типа трафика выиграть можно.
Значительно меньшее количество заголовков генерирует меньшую нагрузку на Forwading Engine, также и на сервисные Engine. К примеру, frame rate для 10G линка загруженного фреймами по 1500 байт равен 812 744 фреймов в секунду, а тот же линк загруженный Jumbo фреймами в 9000 байт генерирует фрейм рейт всего лишь в 138 587 фрейм в секунду. На рисунке 7 приведены график из отчёта Alteon Networks (ссылка будет внизу статьи) утилизации CPU и гигабитного линка, в зависимости от типа используемого размера фрейма.
Увеличение TCP Throughput при изменении размера MTU -

В сетях Ethernet на канальном уровне используются кадры 4-х различных форматов. Это связано с длительной историей развития технологии Ethernet, насчитывающей период существования до принятия стандартов IEEE 802, когда подуровень LLC не выделялся из общего протокола и, соответственно, заголовок LLC не применялся.

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

Ниже приводится описание всех четырех типов кадров Ethernet (здесь под кадром понимается весь набор полей, которые относятся к канальному уровню, то есть поля MAC и LLC уровней). Один и тот же тип кадра может иметь разные названия, поэтому ниже для каждого типа кадра приведено по нескольку наиболее употребительных названий:

кадр 802.3/LLC (кадр 802.3/802.2 или кадр Novell 802.2);

кадр Raw 802.3 (или кадр Novell 802.3);

кадр Ethernet DIX (или кадр Ethernet II);

кадр Ethernet SNAP.

Форматы всех этих четырех типов кадров Ethernet приведены на рис. 10.3.

Кадр 802.3/LLC

Заголовок кадра 802.3/LLC является результатом объединения полей заголовков кадров, определенных в стандартах IEEE 802.3 и 802.2.

Стандарт 802.3 определяет восемь полей заголовка (рис. 10.3; поле преамбулы и начальный ограничитель кадра на рисунке не показаны).

Поле преамбулы (Preamble) состоит из семи синхронизирующих байт 10101010. При манчестерском кодировании эта комбинация представляется в физической среде периодическим волновым сигналом с частотой 5 МГц.

Начальный ограничитель кадра (Start-of-frame-delimiter, SFD) состоит из одного байта 10101011. Появление этой комбинации бит является указанием на то, что следующий байт - это первый байт заголовка кадра.

Адрес назначения (Destination Address, DA) может быть длиной 2 или 6 байт. На практике всегда используются адреса из 6 байт.

Адрес источника (Source Address, SA) - это 2- или 6-байтовое поле, содержащее адрес узла - отправителя кадра. Первый бит адреса всегда имеет значение 0.

Длина (Length, L) - 2-байтовое поле, которое определяет длину поля данных в кадре.

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

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

Поле контрольной суммы (Frame Check Sequence, PCS) состоит из 4 байт, содержащих контрольную сумму. Это значение вычисляется по алгоритму CRC-32.

Кадр 802.3 является кадром МАС-подуровня, поэтому в соответствии со стандартом 802.2 в его поле данных вкладывается кадр подуровня LLC с удаленными флагами начала и конца кадра. Формат кадра LLC был описан выше. Так как кадр LLC имеет заголовок длиной 3 (в режиме LLC1) или 4 байт (в режиме LLC2), то максимальный размер поля данных уменьшается до 1497 или 1496 байт.

Рисунок 10.3. Форматы кадров Ethernet

Кадр Raw 802.3, называемый также кадром Novell 802.3, представлен на рис. 10.3. Из рисунка видно, что это кадр подуровня MAC стандарта 802.3, но без вложенного кадра подуровня LLC. Компания Novell долгое время не использовала служебные поля кадра LLC в своей операционной системе NetWare из-за отсутствия необходимости идентифицировать тип информации, вложенной в поле данных, - там всегда находился пакет протокола IPX, долгое время бывшего единственным протоколом сетевого уровня в ОС NetWare.

Кадр Ethernet DIX/Ethernet II

Кадр Ethernet DIX, называемый также кадром Ethernet II, имеет структуру (см. рис. 10.3), совпадающую со структурой кадра Raw 802.3. Однако 2-байтовое поле Длина(L) кадра Raw 802.3 в кадре Ethernet DIX используется в качестве поля типа протокола. Это поле, теперь получившее название Туре (Т) или EtherType, предназначено для тех же целей, что и поля DSAP и SSAP кадра LLC - для указания типа протокола верхнего уровня, вложившего свой пакет в поле данных этого кадра.

Кадр Ethernet SNAP

Для устранения разнобоя в кодировках типов протоколов, сообщения которых вложены в поле данных кадров Ethernet, комитетом 802.2 была проведена работа по дальнейшей стандартизации кадров Ethernet. В результате появился кадр Ethernet SNAP (SNAP - Subnetwork Access Protocol, протокол доступа к подсетям). Кадр Ethernet SNAP (см. рис. 10.3) представляет собой расширение кадра 802.3/LLC за счет введения дополнительного заголовка протокола SNAP, состоящего из двух полей: OUI и Туре. Поле Туре состоит из 2-х байт и повторяет по формату и назначению поле Туре кадра Ethernet II (то есть в нем используются те же значения кодов протоколов). Поле OUI (Organizationally Unique Identifier) определяет идентификатор организации, которая контролирует коды протоколов в поле Туре. С помощью заголовка SNAP достигнута совместимость с кодами протоколов в кадрах Ethernet II, а также создана универсальная схема кодирования протоколов. Коды протоколов для технологий 802 контролирует IEEE, которая имеет OUI, равный 000000. Если в будущем потребуются другие коды протоколов для какой-либо новой технологии, для этого достаточно указать другой идентификатор организации, назначающей эти коды, а старые значения кодов останутся в силе (в сочетании с другим идентификатором OUI).

Аппаратный

Аппаратн

Сетевой адрес

получателя

назначения

источника

отправителя

получате

(Target Internet

Заголовок кадра Ethernet

Поле данных кадра Ethernet (ARP-запрос)

Рисунок 6 - Широковещательная передача ARP-запроса компьютером A

Аппаратный

Аппаратн

Сетевой адрес

получателя

назначения

источника

отправителя

получате

(Target Internet

Заголовок кадра Ethernet

Поле данных кадра Ethernet (ARP-ответ)

Рисунок 7 - ARP-ответа компьютера B

2.2.2 Работа ARP протокола в случае, когда отправитель и получатель расположены в разных сетях

Пусть компьютер A с именем Vito и компьютер B с именем Maxx так же, как и в первом случае, находятся в одной сети класса C 192.168.0.0, не разделенной на подсети, но компьютер B подключен и к внешней сети и помимо своих обычных функций выполняет функции шлюза (маршрутизатора). Компьютер A хочет обратиться через внешнюю сеть к некоторому компьютеру C с IP-адресом 195.5.27.10, т.е. получатель находится в другой сети. На рисунке 8 приведена соответствующая иллюстрация.

Компьютер C (получатель)

IP-адрес: 195.5.27.10

Компьютер

Vito(отправи

MAC-адрес:00-02-44-63-D3-87 MAC-адрес: 00-80-48-B7-BD-

IP-адрес: 192.168.0.147
	IP-адрес: 192.168.0.145

Компь ютер B

ARP-запрос

Рисунок 8 - Расположение отправителя и получателя в разных сетях

При обращении компьютера A к компьютеру C, например, при вводе на компьютере A команды ping –n 1 195.5.27.10 , компьютер A действует следующим образом.

Сначала компьютер A определяет, в какой сети – локальной или удаленной – находится компьютер C. Для этого он “накладывает” стандартную маску подсети класса C 255.255.255.0 на свой IP-адрес 192.168.0.147 и получает результат 192.168.0.0.

Затем он “накладывает” ту же маску на IP-адрес компьютера-получателя 195.5.27.10 и получает результат 195.5.27.0. Т.к. результаты этих двух операций различны, компьютер A делает вывод о том, что компьютер C находится в другой сети и передачу данных нужно выполнить через шлюз (компьютер B).

Затем компьютер A должен послать кадр Ethernet с эхо-запросом, указав в заголовке вложенного в этот кадр пакета ICMP IP-адрес компьютера-получателя 195.5.27.10, а в заголовке кадра Ethernet – MAC-адрес шлюза, т.е. компьютера B (а не

MAC-адрес компьютера-получателя ), т.к. сначала кадр по сети Ethernet должен достигнуть шлюза. Следовательно, компьютер A должен знать MAC-адрес шлюза, но в настройках TCP/IP компьютера указывается не MAC-адрес, а IP-адрес шлюза. Если компьютер A недавно обращался к шлюзу, то MAC-адрес шлюза может находиться в таблице ARP компьютера A. Если же компьютер A после начальной загрузки еще не обращался к шлюзу или обращался к нему давно и соответствующая динамическая запись соответствия “IP-адрес – MAC-адрес” уже удалена, то таблица ARP компьютера A не будет содержать MAC-адреса шлюза (если только он не введен туда администратором вручную). В этом случае компьютер A должен выяснить MAC-адрес шлюза с помощью протокола ARP.

Процесс выяснения компьютером A MAC-адреса шлюза (компьютера B) описан выше. После определения MAC-адреса шлюза компьютер A посылает эхо-запрос компьютеру C. Этот эхо-запрос поступает на компьютер B, который, выполняя функцию маршрутизатора, направляет эхо-запрос компьютеру C через внешнюю сеть.

При передаче данных от отправителя получателю, находящемуся в удаленной сети, в заголовке IP-пакета указывается IP-адрес получателя, а в заголовке кадра Ethernet указывается MAC-адрес не получателя, а MAC-адрес шлюза, через который

должны быть переданы данные. Аналогично, при поступлении на отправитель (компьютер А) ответных данных от получателя (компьютера C) через шлюз (компьютер В) в поле MAC-адреса источника заголовка кадра Ethernet указывается MAC-адрес не компьютера C, а MAC-адрес шлюза (компьютера В), а в поле IP-адреса источника заголовка IP-пакета указывается IP-адрес не шлюза В, а IP-адрес компьютера C.

2.2.3 Использование протокола ARP для проверки наличия в сети дублированного IP-адреса

Кроме установления соответствия между MAC-адресам и IP-адресом, протокол ARP выполняет еще одну важную функцию. При включении (загрузке) компьютера и при изменении его IP-адреса протокол ARP позволяет определить, имеются ли в локальной сети компьютеры с одинаковыми IP-адресами. Для этого при загрузке компьютера и после изменения его IP-адреса компьютер посылает ARP-запрос, в котором в качестве получателя пакета (полесетевой адрес получателя ) указывает свой собственный IP-адрес.

Такой ARP-запрос называется самообращенным (от слова gratuitous – “беспричинным”, т.е. не вызванным необходимостью последующей передачи данных, или “безвозмездным”, т.е. не требующим ответа). Компьютер, пославший самообращенный ARP-запрос, не ждет на него ответа. Если ответа на самообращенный ARP-запрос не поступает, значит, такого же IP-адреса, как у данного компьютера, в локальной сети больше нет. Если же какой-либо компьютер локальной сети отвечает на самообращенный ARP-запрос своим MAC-адресом, значит, в локальной сети уже есть компьютер с таким IP-адресом. В этом случае на экране компьютера, пославшего самообращенный ARP-запрос, и на экране компьютера, ответившего на этот запрос, выводятся сообщения об ошибке - “Конфликт IP-адреса с другой системой в сети”.

2.3 Протокол ICMP

Протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol) входит с состав стека TCP/IP. Протокол ICMP используется для тестирования доступности узлов сети и представляет собой эхо-протокол (на посланный запрос должен быть получен ответ). ICMP протокол работает с двумя типами сообщений: эхо-запрос и эхо-ответ . Компьютер или маршрутизатор посылают по сети эхо-запрос, в котором указывают IP-адрес узла, доступность которого нужно проверить. Компьютер (маршрутизатор), который получает эхо-запрос, формирует и отправляет эхо-ответ и возвращает сообщение узлу - отправителю запроса. В запросе могут содержаться некоторые данные (контрольная сумма), которые должны быть возвращены в ответе. Так как эхо-запрос и эхо-ответ передаются по сети внутри IPпакетов (см. рис. 9), то их успешная доставка означает нормальное функционирование всей транспортной системы интерсети.

Рисунок 9 - Инкапсуляция (вложение) ICMP-сообщения в IP-датаграмму

Для отправки эхо-запросов и приема эхо-ответов используется утилита (программа)ping .

2.4 Протокол DHCP

Основным назначением DHCP является динамическое назначение IP-адресов. Однако, кроме динамического, DHCP может поддерживать и более простые способы ручного и автоматического статического назначения адресов.

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

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

DHCP обеспечивает надежный и простой способ конфигурации сети TCP/IP, гарантируя отсутствие конфликтов адресов за счет централизованного управления их распределением. Администратор управляет процессом назначения адресов с помощью параметра "продолжительности аренды" (lease duration), которая определяет, как долго компьютер может использовать назначенный IP-адрес, перед тем как снова запросить его от сервера DHCP в аренду.

Протокол DHCP использует модель клиент-сервер. Во время старта системы DHCP - клиент, находится в состоянии "инициализации" и посылает широковещательное сообщение discover (обнаружить) для поиска в сети DHCPсервера. DHCP-сервер, получив это сообщение, отвечает на него сообщением offer (предложение), которое содержит IP-адрес и конфигурационную информацию. DHCP - клиент, получив предложение от DHCP-сервера, переходит в состояние "запрос" и отправляет сообщение request (запрос) DHCP-серверу. DHCP-сервер посылает сообщение DHCP-acknowledgment (подтверждение), содержащее тот же IP-адрес, который уже был послан ранее на стадии исследования, а также параметр аренды для

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

Рисунок 10 - Формат DHCP пакета

Использование протокола DHCP кроме своих достоинств имеет ряд недостатков. Во-первых, это проблема согласования информационной адресной базы в службах DHCP и DNS (система доменных имен). DNS служит для преобразования символьных имен в IP-адреса, если IP-адреса, будут, динамически изменятся сервером DHCP, то эти изменения необходимо также динамически вносить в базу данных сервера DNS. Хотя протокол динамического взаимодействия между службами DNS и DHCP уже реализован некоторыми фирмами (так называемая служба Dynamic DNS), стандарт на него пока не принят.

Во-вторых, нестабильность IP-адресов усложняет процесс управления сетью. Системы управления, основанные на протоколе SNMP, разработаны с расчетом на статичность IP-адресов.

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

Для работы с протоколом DHCP в ОС “Windows” используется команда ipconfig , которая служит для отображения всех текущих параметров сети TCP/IP и обновления параметров DHCP и DNS. При вызове командыipconfig можно использовать ряд параметров, например:

/all - вывод полной конфигурации TCP/IP для всех адаптеров. Без этого параметра командаipconfig выводит только IP-адреса, маску подсети и основной шлюз для каждого адаптера.

Как и на производстве, кадры в сети Ethernet решают все. Они служат вместилищем для всех высокоуровневых пакетов, поэтому, чтобы понять друг друга, отправитель и получатель должны использовать один и тот же тип кадров Ethernet. К счастью (или к сожалению), кадры могут быть всего четырех разных форматов, и к тому же не сильно отличающихся друг от друга. Более того, базовых форматов кадров существует всего два (в английской терминологии их называют "raw formats") - Ethernet_II и Ethernet_802.3, причем они отличаются назначением всего одного поля.

Современные компьютерные сети гетерогенны по своей природе, а сетевые протоколы третьего уровня используют зачастую разные типы кадров Ethernet. Так, в старых версиях NetWare 3.х компании Novell базовым форматом по умолчанию является Ethernet_802.3, а не 802.2 или SNAP, как это предусмотрено стандартами IEEE, причем, кроме нее, этот формат больше никто не применяет. С выходом NetWare 4.х протоколы IPX/SPX используют по умолчанию стандартные кадры Ethernet_802.2, а с планируемым переводом IntranetWare на протоколы TCP/IP эта сетевая ОС будет, возможно, работать по умолчанию с кадрами Ethernet_SNAP, так как именно этот формат применяется в новейших реализациях TCP/IP. Вообще говоря, пакеты протоколов IPX/SPX могут передаваться с помощью кадров любых типов, поэтому - а также потому, что тип Ethernet_802.3 используется исключительно Novell, - в этом уроке мы будем рассматривать кадры Ethernet преимущественно с точки зрения сетей NetWare.

ETHERNET II

Несмотря на то что мы привычно называем стандарт 802.3 именем Ethernet, это не совсем правильно, так как последнее название является торговой маркой Xerox, Intel и Digital, чья технология послужила прототипом этого столь популярного стандарта. Формат Ethernet_II соответствует оригинальному формату кадров Ethernet и имеет следующий вид.

Как и всякий кадр, Ethernet_II начинается с семибайтной преамбулы, состоящей из чередующихся единиц и нулей, и однобайтного начального ограничителя кадра, в котором два младших бита равны 112, а не 102, как остальные биты в преамбуле и ограничителе. Однако, если быть более точным, в Ethernet_II преамбула не разделяется на собственно преамбулу и начальный ограничитель кадра - и это является одним из отличий Ethernet от IEEE 802.3, хотя весьма несущественным, можно сказать, схоластическим, тем более что очень часто преамбула вообще рассматривается как часть физического механизма синхронизации передающей и принимающей стороны, а не как часть кадра (поэтому на рисунках мы не будет обозначать преамбулу и начальный ограничитель).

Собственно заголовок кадра состоит из шестибайтного поля адреса получателя (Destination Address), шестибайтного поля адреса отправителя (Source Address) и двухбайтного поля типа протокола (Frame Type) (см. Рисунок 1). При передаче каждого байта адреса младшие биты (крайние справа) передаются первыми. В адресе получателя первый передаваемый бит (бит 0 байта 0) указывает тип адреса - обычный или групповой. Таким образом, нечетный первый байт адреса получателя означает, что кадр предназначен группе станций. Разновидностью многоадресной передачи является широковещательная передача. В этом случае все биты адреса получателя задаются равными 1.

Рисунок 1.

Базовые пакеты Ethernet II и IEEE 802.3 имеют одинаковую структуру. Их различие - в назначении 13-го и 14-го байтов: поля типа протокола и длины кадра соответственно. Совместное использование разных форматов кадров в одном сегменте Ethernet возможно благодаря тому, что тип протокола характеризуется числом, большим 0x05FE.

Однако поле адреса отправителя должно содержать адрес конкретной станции-отправителя.

В случае обычных адресов первые три байта служат для идентификации производителя сетевой платы, а последние три байта составляют уникальный номер конкретной платы. Так, первые три байта адреса популярных сетевых плат производства 3Com выражаются следующим числом - 02608С в шестнадцатеричной системе счисления (далее для обозначения чисел в шестнадцатеричной системе счисления мы будем использовать обозначение 0x, т. е. идентификатор 3Com будет иметь вид 0x02608C). Адрес получателя называется также физическим или MAC-адресом.

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

Поле типа протокола идентифицирует высокоуровневый протокол, такой как IP, AppleTalk и т. д., контейнером для пакета которого служит кадр. Ниже мы приводим значения поля типа протокола для некоторых распространенных сетевых протоколов:

Network System

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

В отличие от служебных полей, поле данных имеет переменную длину, причем оно не может быть короче 46 байт и длиннее 1500 байт. Таким образом, общая длина кадра без учета преамбулы и начального ограничителя кадра находится в диапазоне от 64 до 1518 байт. В случае, когда реальный объем передаваемых данных меньше 46 байт (например, для эмуляции терминала часто передается всего один символ, вводимый с клавиатуры), поле данных дополняется до минимального размера заполнителем. Байт заполнения может вставляться, даже если объем передаваемых данных более 46 байт. По предложению Novell, в случае нечетного количества байт драйвер сетевой платы добавляет еще один. Это сделано потому, что некоторые старые маршрутизаторы не понимают кадры нечетной длины.

Последнее поле в кадре - это четырехбайтное поле контрольной последовательности кадра (Frame Check Sequence, FCS). Значение этого поля вычисляется на основе содержимого заголовка и данных (вместе с заполнителем, но без учета преамбулы и ограничителя) с помощью 32-разрядного циклического избыточного кода (Cyclic Redundancy Code, CRC-32) по следующей формуле (в двоичной системе счисления):

контрольная последовательность = MOD(данные/полином)

В Ethernet порождающим полиномом служит многочлен x 32 +x 26 +x 23 +x 23 +x 22 +x 16 +x 12 +x 11 +x 10 +x 8 +x 7 +x 5 +x 4 +x 2 +x+1. Данный код позволяет обнаружить 99,999999977% всех ошибок в сообщениях длиной до 64 байт! Таким образом, вероятность того, что принимающая станция воспримет испорченный кадр как целый, практически равна нулю.

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

БАЗОВЫЙ ФОРМАТ КАДРА 802.3

Определяемый спецификацией 802.3 формат кадра практически идентичен своему предшественнику за исключением того, что поле типа протокола имеет смысл длины кадра. На первый взгляд это неизбежно должно привести к путанице, когда кадры Ethernet_II и Ethernet_802.3 передаются между станциями в одном сегменте. Однако на практике эти кадры не представляет труда отличить друг от друга. Как мы уже говорили, длина поля данных не превышает 1500 байт, поэтому, в соответствии с принятыми соглашениями, тип высокоуровневого протокола задается большим, чем 0х05FE (1518 в шестнадцатеричной системе счисления - полная длина кадра), благо двухбайтное поле может принимать 65 536 разных значений. Таким образом, если значение поля между адресом отправителя и данными меньше или равно 1518, то это кадр 802.3, в противном случае - это кадр Ethernet_II.

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

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

управления каналом (Logical Link Control, LLC) - верхний подуровень канального уровня. Таким образом, согласно требованиям стандарта, поле данных должно содержать заголовок LLC. В ранних версиях NetWare компания Novell проигнорировала этот заголовок и стала помещать пакеты IPX/SPX непосредственно за полем длины кадра, и поле данных начиналось так же, как и обычный заголовок IPX, с двух байтов, состоящих из единиц (число 0xFFFF). Иными словами, Novell использовала кадры просто в качестве контейнера.

В принципе применение базового формата кадра 802.3 без служебной информации верхнего подуровня канального уровня позволяет Novell несколько сократить накладные расходы в расчете на кадр. Однако выигрыш невелик, а в гетерогенной среде применение нестандартного формата ведет к проигрышу, так как маршрутизатор или сетевая плата вынуждены проверять дополнительные поля для определения типа пакета. Это послужило одним из побудительных мотивов, почему начиная с версии 4.0 Novell перешла по умолчанию на стандартный формат Ethernet_802.2. Другой причиной было то, что использование базовых кадров Ethernet_802.3 делало невозможным применение таких опций защиты, как подпись пакетов, из-за того, что поле контрольной суммы пакета было фиксированным и равным 0хFFFF, чтобы кадр Ethernet_802.3 можно было отличить от других типов кадров.

ДВА СТАНДАРТНЫХ ФОРМАТА

Спецификации IEEE предусматривают всего два стандартных формата - 802.2 и 802.2 SNAP, причем второй является естественным расширением первого. Как уже говорилось, стандартный кадр должен содержать в поле данных служебную информацию логического управления каналом, а именно однобайтное поле точки доступа к сервису для получателя (Destination Service Access Point, DSAP), однобайтное поле точки доступа к сервису для отправителя (Source Service Access Point, SSAP) и однобайтное управляющее поле (см. Рисунок 2). Назначением номеров точек доступа к сервису (Service Access Point, SAP) занимается IEEE, и он выделил следующие номера:

Поля DSAP и SSAP служат для определения вышележащего протокола и, как правило, содержат одно и то же значение. Управляющее поле обычно задается равным 0x03 (в соответствии с протоколом LLC это означает, что соединение на канальном уровне не устанавливается).

Протокол доступа к подсети (Sub-Network Access Protocol, SNAP) был разработан с целью увеличения числа поддерживаемых протоколов, так как однобайтные поля SAP позволяют поддерживать не более 256 протоколов. Формат Ethernet_SNAP предусматривает дополнительное пятибайтное поле для идентификации протокола (Protocol Identification, PI) внутри поля данных, причем значения двух последних байтов этого поля совпадают со значениями поля протокола в Ethernet_II в случае, если кадры содержат пакеты одного и того же высокоуровневого протокола, например они равны 0x8137 для NetWare.

АЛГОРИТМ ОПРЕДЕЛЕНИЯ ФОРМАТА КАДРА

Отличить один формат кадра Ethernet от другого не представляет большого труда, и сделать это можно с помощью следующего простого алгоритма (см. Рисунок 3). Сначала драйвер должен проверить значение поля типа протокола/длины кадра (13-й и 14-й байты в заголовке). Если записанное там значение превышает 0x05FE (максимально возможная длина кадра), то это кадр Ethernet_II.

(1x1)

Рисунок 3.

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

Если нет, следует продолжить проверку. Если первые два байта равны 0xFFFF, то это формат Ethernet_802.3 для NetWare 3.х. В противном случае это стандартный формат кадра 802.2, и нам остается только выяснить, какой из двух - обычный (Ethernet_802.2) или расширенный (Ether-net_SNAP). В случае Ethernet_SNAP значение первого, впрочем, как и второго, байта в поле данных равняется 0xAA. (Значение третьего байта равняется 0x03, но это проверять излишне.)

ЗА КАДРОМ

Разные протоколы используют разные форматы кадров (см. Таблицу 1). Однако число последних не так уж велико, и их несложно отличить один от другого. К тому же протокол TCP/IP выдвигается на доминирующую позицию не только в глобальных, но и в локальных сетях, поэтому даже Novell решила отказаться от своего протокола IPX/SPX в пользу TCP/IP в следующей версии NetWare. Это означает, что в большинстве случаев администратору сети не придется беспокоиться о том, какой формат кадров Ethernet используется. Однако, как показывает опыт, унаследованные технологии живут довольно долго, так что знание форматов кадров может представлять не только теоретический, но и практический интерес.

ТАБЛИЦА 1 - ПРОТОКОЛЫ И СООТВЕТСТВУЮЩИЕ ТИПЫ КАДРОВ

Стандарт на технологию Ethernet, описанный в документе 802.3, дает описание единственного формата кадра МАС-уровня. Так как в кадр МАС-уровня должен вкладываться кадр уровня LLC, описанный в документе 802.2, то по стандартам IEEE в сети Ethernet может использоваться только единственный вариант кадра канального уровня, образованный комбинацией заголовков МАС и LLC подуровней. Тем не менее, на практике в сетях Ethernet на канальном уровне используются заголовки 4-х типов. Это связано с длительной историей развития технологии Ethernet до принятия стандартов IEEE 802, когда подуровень LLC не выделялся из общего протокола и, соответственно, заголовок LLC не применялся. Затем, после принятия стандартов IEEE и появления двух несовместимых форматов кадров канального уровня, была сделана попытка приведения этих форматов к некоторому общему знаменателю, что привело еще к одному варианту кадра.

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

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

Кадр 802.3/LLC (или кадр Novell 802.2)

Кадр Raw 802.3 (или кадр Novell 802.3)

Кадр Ethernet DIX (или кадр Ethernet II)

Кадр Ethernet SNAP

Заголовок кадра 802.3/LLC является результатом объединения полей заголовков кадров, определенных в стандартах 802.3 и 802.2.

Стандарт 802.3 определяет восемь полей заголовка:

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

Начальный ограничитель кадра состоит из одного байта с набором битов 10101011. Появление этой комбинации является указанием на предстоящий прием кадра.

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

Адрес отправителя - 2-х или 6-ти байтовое поле, содержащее адрес станции отправителя. Первый бит - всегда имеет значение 0.

Двухбайтовое поле длины определяет длину поля данных в кадре.

Поле данных может содержать от 0 до 1500 байт. Но если длина поля меньше 46 байт, то используется следующее поле - поле заполнения, чтобы дополнить кадр до минимально допустимой длины.

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

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

Кадр 802.3 является кадром MAС-подуровня, в соответствии со стандартом 802.2 в его поле данных вкладывается кадр подуровня LLC с удаленными флагами начала и конца кадра. Формат кадра LLC был описан выше.

Результирующий кадр 802.3/LLC изображен в левой части рисунка 4. Так как кадр LLC имеет заголовок длиной 3 байта, то максимальный размер поля данных уменьшается до 1497 байт.

Рис. 4

Справа на этом рисунке приведен кадр, который называют кадром Raw 802.3 (то есть "грубый" вариант 802.3) или же кадром Novell 802.3. Из рисунка видно, что это кадр MAC-подуровня стандарта 802.3, но без вложенного кадра подуровня LLC. Компания Novell долгое время не использовала служебные поля кадра LLC в своей операционной системе NetWare из-за отсутствия необходимости идентифицировать тип информации, вложенной в поле данных - там всегда находился пакет протокола IPX, долгое время бывшего единственным протоколом сетевого уровня в ОС NetWare.

Теперь, когда необходимость идентификации протокола верхнего уровня появилась, компания Novell стала использовать возможность инкапсуляции в кадр MAC-подуровня кадра LLC, то есть использовать стандартные кадры 802.3/LLC. Такой кадр компания обозначает теперь в своих операционных системах как кадр 802.2, хотя он является комбинацией заголовков 802.3 и 802.2.

Кадр стандарта Ethernet DIX, называемый также кадром Ethernet II, похож на кадр Raw 802.3 тем, что он также не использует заголовки подуровня LLC, но отличается тем, что на месте поля длины в нем определено поле типа протокола (поле Type). Это поле предназначено для тех же целей, что и поля DSAP и SSAP кадра LLC - для указания типа протокола верхнего уровня, вложившего свой пакет в поле данных этого кадра. Для кодирования типа протокола используются значения, превышающие значение максимальной длины поля данных, равное 1500, поэтому кадры Ethernet II и 802.3 легко различимы.

Еще одним популярным форматом кадра является кадр Ethernet SNAP (SNAP - SubNetwork Access Protocol, протокол доступа к подсетям). Кадр Ethernet SNAP определен в стандарте 802.2H и представляет собой расширение кадра 802.3 путем введения дополнительного поля идентификатора организации, которое может использоваться для ограничения доступа к сети компьютеров других организаций.

В таблице 2 приведены данные о том, какие типы кадров Ethernet обычно поддерживают реализации популярных протоколов сетевого уровня.

Таблица 2

Спецификации физической среды Ethernet

Исторически первые сети технологии Ethernet были созданы на коаксиальном кабеле диаметром 0.5 дюйма. В дальнейшем были определены и другие спецификации физического уровня для стандарта Ethernet, позволяющие использовать различные среды передачи данных в качестве общей шины. Метод доступа CSMA/CD и все временные параметры Ethernet остаются одними и теми же для любой спецификации физической среды.

Физические спецификации технологии Ethernet на сегодняшний день включают следующие среды передачи данных:

10Base-5 - коаксиальный кабель диаметром 0.5 дюйма, называемый "толстым" коаксиалом. Имеет волновое сопротивление 50 Ом. Максимальная длина сегмента - 500 метров (без повторителей).
10Base-2 - коаксиальный кабель диаметром 0.25 дюйма, называемый "тонким" коаксиалом. Имеет волновое сопротивление 50 Ом. Максимальная длина сегмента - 185 метров (без повторителей).
10Base-T - кабель на основе неэкранированной витой пары (Unshielded Twisted Pair, UTP). Образует звездообразную топологию с концентратором. Расстояние между концентратором и конечным узлом - не более 100 м.
10Base-F - оптоволоконный кабель. Топология аналогична стандарту на витой паре. Имеется несколько вариантов этой спецификации - FOIRL, 10Base-FL, 10Base-FB.

Число 10 обозначает битовую скорость передачи данных этих стандартов - 10 Мб/с, а слово Base - метод передачи на одной базовой частоте 10 МГц (в отличие от стандартов, использующих несколько несущих частот, которые называются broadband - широкополосными).

Стандарт 10Base-5

Стандарт 10Base-5 соответствует экспериментальной сети Ethernet фирмы Xerox и может считаться классическим Ethernet"ом. Он использует в качестве среды передачи данных коаксиальный кабель с диаметром центрального медного провода 2,17 мм и внешним диаметром около 10 мм ("толстый" Ethernet).

Кабель используется как моноканал для всех станций. Сегмент кабеля имеет максимальную длину 500 м (без повторителей) и должен иметь на концах согласующие терминаторы сопротивлением 50 Ом, поглощающие распространяющиеся по кабелю сигналы и препятствующие возникновению отраженных сигналов.

Различные компоненты сети, выполненной на толстом коаксиале, показаны на рисунке 5.

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

Трансивер соединяется с сетевым адаптером интерфейсным кабелем AUI (Attachment Unit Interface) длиной до 50 м, состоящим из 4 витых пар (адаптер должен иметь разъем AUI). Допускается подключение к одному сегменту не более 100 трансиверов, причем расстояние между подключениями трансиверов не должно быть меньше 2.5 м.

Рис. 5

Трансивер - это часть сетевого адаптера, которая выполняет следующие функции:

прием и передача данных с кабеля на кабель,

определение коллизий на кабеле,

электрическая развязка между кабелем и остальной частью адаптера,

защита кабеля от некорректной работы адаптера.

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

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

К достоинствам стандарта 10Base-5 относятся:

хорошая защищенность кабеля от внешних воздействий,

сравнительно большое расстояние между узлами,

возможность простого перемещения рабочей станции в пределах длины кабеля AUI.