in

Ethernet-фрейм и IP-пакет: разбор полётов

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

Скилловый райдер твоего нового работодателя вполне может содержать пункт насчёт взаимодействия между уровнями модели OSI или стека TCP/IP. А тут мы как раз собрали всю информацию воедино. Хорошо же!

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

Кадр Ethernet (канальный уровень)

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

Фрейм (Frame — кадр, битовая цепочка) — пакет канального уровня, минимальная «упаковка» информации, передаваемой по сети. Как выглядит один фрейм Ethernet согласно спецификации IEEE802.3:

Преамбула (8 байт) — Специальный маркер начала пакета. Если точнее, то первые семь представляют собой код 10101010, а последний байт – код 10101011. Последний байт и есть признак начала кадра или SFD – Start of Frame Delimiter.

Заголовок (14 байт) — содержит MAC-адреса источника и приемника (по 6 байт) и двухбайтное поле длины (L — Length) или типа (T-type) сетевого протокола (в зависимости от типа фрейма). То есть поле управления содержит информацию о длине поля данных. Оно может также определять тип используемого протокола.

Данные (от 46 до 1500 байт) — содержимое этого поля зависит от типа фрейма. Это поле обычно называют Payload — полезная нагрузка.

Концевик (4 байта) — оно же поле контрольной суммы (FCS – Frame Check Sequence), которое содержит в себе циклическую контрольную сумму пакета (CRC) и служит для проверки правильности передачи пакета. Фреймы, не удовлетворяющие данной спецификации, считаются ошибочными. По типу ошибки (сочетание реальной длины, контрольной суммы и преамбулы) возможна локализация источника неисправности с точностью до функционального узла канала.

Стандарт предполагает, что преамбула может уменьшаться при прохождении пакета через различные сетевые устройства, поэтому она не учитывается. Максимальная длина кадра равна 1518 байтам (12144 бита, то есть 1214,4 мкс для Ethernet, 121,44 мкс для Fast Ethernet). Это важно для выбора размера буферной памяти сетевого оборудования и для оценки общей загруженности сети.

Отдельно стоит упомянуть про Ethernet II 802.1Q. В нём есть дополнительное 4-байтовое поле — тег. Он нужен для определения VLAN и маркировки трафика в QoS. Подробнее об этом мы писали тут.

Определение кадра в потоке

А как вообще понять, где заканчивается один кадр и начинается другой? Методов определения кадра в потоке несколько. Самый простой — в начало каждого кадра указать его длину в байтах. Есть и минус — в случае коллизии (одновременная передача нескольких устройств) на сети длина может искажаться и последовательность чтения будет нарушена.

В более современных протоколах используется метод вставки битов (например, в протоколе РРР). Перед начало и концом каждого кадра добавляется 01111110.

Что касается классического Ethernet, то здесь используется, описанная выше, преамбула — последовательность данных, которая передаётся перед началом каждого кадра (8 байт), первые 7 байт — 10101010, последний байт (который ознаменует конец начала кадра) — 10101011

Если кадр был отброшен

Если кадр был отброшен получателем, то существуют методы повторной отправки:

  • Остановка и ожидание — отправитель шлёт один кадр и ожидает подтверждение. Если оно получено, то отправляет следуюзий
  • Скользящее окно — передаёт сразу несколько кадров и не ждет подтверждения. Получатель подтверждает пачку кадров и тогда снова идёт новая «пачка» кадров.

Мультиплексирование — еще одна непосредственная задача канального уровня. Для этого используется специальный подуровень LLC — он позволяет передавать данных разных типов сетевых протоколов (IP, ARP, ICMP), но структура 802.3 with LLC header кадра немного другая за счет этих самых LLC-заголовков (DSAP, SNAP и Control)

Кадры ходят по коммутаторам (свитчам) благодаря таблице коммутации на основе мак-адресов (ARP-таблица).

Каждый узел в сети имеет уникальный номер, который называется МАС-адресом (MAC address) или адресом узла. Этот номер состоит из 48 битов (6 байтов), присваивается сетевому интерфейсу во время изготовления устройства и программируется в процессе инициализации

Если коммутатор не в курсе, что подключено к его портам (новый, только что включили), то он анализирует все кадры, которые приходят на порты, еще точнее — анализирует заголовки канального уровня — адрес отправителя и получателя

Про Fast Ethernet

Сразу определимся с терминологией. Ethernet — технология передачи данных. Fast Ethernet — это набор стандартов для передачи данных по сети по технологии Ethernet. Fast Ethernet – спецификация IEЕЕ 802.3u официально принятая 26 октября 1995 года определяет стандарт протокола канального уровня для сетей работающих при использовании как медного, так и волоконно-оптического кабеля со скоростью 100Мб/с.

Формат кадров у Fast Ethernet аналогичный. Единственное различие в том, что в в FE (кадр 802.3) используется длина поля данных (L — Length), в классическом Ethernet (кадр Ethernet-II)- тип данных (T-Type), но в любом случае сейчас ни Ethernet, ни Fast Ethernet не используют поля L/T вообще — это считается рудиментом и служит служит лишь для согласования с программным обеспечением, обрабатывающим кадры (то есть с протоколами)

Про Jumbo Frame

Максимальная длина данных в кадре ethernet — 1500 байт. Но есть стандарт, который позволяет отправлять кадр большего размера — до 9000 байт. Речь про Jumbo Frame.

Jumbo‑кадр — ethernet‑кадр, в котором поле данных может занимать от 1500 байт до 16 000 байт. Правилом хорошего тона считается передача до 9000 байт данных, так как от превышения этого размера страдает проверка контрольной суммы пакета (CRC).

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

Важно: все устройства, которые передают сверхдлинный кадр должны его поддерживать. Даже промежуточные устройства, которые участвуют в передаче фрейма от устройства А до устройства Б

IP-пакет (сетевой уровень)

Поднимаемся на ступеньку выше по модели OSI (либо по стеку TCP/IP, если удобно). Зачем вообще нужен сетевой уровень, если на канальном уровне тоже можно передавать данные? Технологии канального уровня довольно различны по своему строению — гарантия доставки, адресация, формат и максимальный размер кадра (MTU).

Также на канальном уровне довольно сложно проектировать глобальные сети (для локальных — вполне себе ок). Чтобы утрясти все эти различия и был придуман сетевой уровень (в т.ч. фрагментация — для согласования размера кадра)

Для начала определимся, что:

  • IP (internet protocol — протокол) — маршрутизируемый сетевой протокол, протокол сетевого уровня семейства («стека») TCP/IP. IPv4 описан в RFC 791 (сентябрь 1981 года).
  • IP — основной протокол стека TCP/IP, он решает вопросы доставки сообщений между узлами составной сети.
  • На уровне этого протокола (третий уровень сетевой модели OSI) не даётся гарантий надёжной доставки пакета до адресата. Гарантию безошибочной доставки пакетов дают протоколы более высокого уровня сетевой модели OSI, например, протокол транспортный протокол TCP

Что же касается структуры IP-пакета, то тут немного посложней, чем с кадрами. Вообще пакет протокола IP состоит из заголовка и поля данных. Максимальная длина пакета 65 535 байт.

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

Версия / Version (4 бита) — определяет версию протокола (IPv4 или IPv6)

Длина заголовка / Internet Header Length или IHL (4 бита) — занимает 4 бита и указывает значение длины заголовка, измеренное в 32-битовых словах. Это поле нужно для того, чтобы маршрутизатор или конечный узел понимали: где заканчивается заголовок и начинаются данные.

Обычный заголовок без дополнительных опций равен 160 бит или 20 байт. Наибольший заголовок занимает 60 октетов. Может применяться совместно с полем «Параметры».

Тип обслуживания, тип сервиса / Type of Service (8 бит) -занимает один байт и задает приоритетность пакета и вид критерия выбора маршрута. Первые три бита этого поля образуют подполе приоритета пакета (Precedence).

Приоритет может иметь значения от самого низкого — 0 (нормальный пакет) до самого высокого — 7 (пакет управляющей информации) . Маршрутизаторы и компьютеры могут принимать во внимание приоритет пакета и обрабатывать более важные пакеты в первую очередь.

На данный момент это поле раздроблено на две части:

  • DSCP — Differentiated Services Code Point (6 бит) — разделяет трафик на классы обслуживания
  • ECN — Explicit Congestion Notification (2 бита) — указатель перегрузки. Нужен в момент, когда трафика передаётся больше, чем пропускная способность сети

Размер пакета, длина пакета, общая длина / Total Length (16 бит) — Определяет суммарный размер IP-пакета, включая заголовок, параметры и данные. При передаче по сетям различного типа длина пакета выбирается с учетом максимальной длины пакета протокола нижнего уровня, несущего IP- пакеты. Если это кадры Ethernet, то выбираются пакеты с максимальной длиной в 1500 байт, умещающиеся в поле данных кадра Ethernet.

Идентификатор / Identification (16 бит) — Используется для определения корректной последовательности фрагментов IP-пакета при его сборке, т.е. чтобы принимающая сторона понимала, как из полученных кусочков правильно собрать пакет, когда он фрагментируется. Все фрагменты должны иметь одинаковое значение этого поля.

Флаги / Flags (3 бита) — Используется для контроля фрагментации IP-пакета.

  • Нулевой бит зарезервирован и должен быть всегда равен нулю
  • Если значение первого бита (DF — Do not Fragment, df-bit) равно нулю, то можно фрагментировать. Если единица — маршрутизатору запрещено это делать. Если пакет с таким флагом больше, чем MTU следующей пересылки, то этот пакет будет отброшен, а отправителю посылается ICMP ошибка «фрагментация необходима, однако установлен бит не фрагментировать» (fragmentation needed but don’t fragment bit set).
  • Второй бит (MF — More Fragments) — говорит о том, что данный пакет является промежуточным (не последним) фрагментом, если значение равно единице

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

Смещение фрагмента / Fragment Offset (13 бит) — указывает на смещение данных фрагмента IP-пакета относительно оригинала. Применяется для разделения, в зависимости от размера, больших IP-пакетов на более мелкие, а также их сбора в обратном порядке. Т.е. это поле говорит узлу или маршрутизатору на сколько байт нужно выполнять смещение от нуля

Время жизни / Time to live, TTL (8 бит) — определяет количество узлов, которые может пройти IP-пакет. Наиболее часто используется значение 64. Изначально измерялся в секундах, но сейчас TTL – это значение, которое определяет число транзитных узлов и задается источником передачи. А дело вот в чем.

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

Протокол, идентификатор протокола верхнего уровня / Protocol (8 бит) — указывает, какому протоколу верхнего уровня принадлежит информация, размещенная в поле данных пакета (например, ICMP, TCP, UDP, ESP или GRE).

Например, если внутри IP-пакета будет передаваться UDP-дейтаграмма, то в поле протокол будет записано значение 17 или 00010001 в двоичной системе счисления, а для протокола TCP используется десятичное число 6, в двоичной системе счисления 00000110

Контрольная сумма заголовка / Header Checksum (16 бит) — осуществляет проверку на соответствия принадлежности к IP-пакету. Поскольку некоторые поля заголовка меняют свое значение в процессе передачи пакета по сети (например, время жизни), контрольная сумма проверяется и повторно рассчитывается при каждой обработке IP- заголовка

Напомним, что сам протокол IP не имеет механизма проверки целостности данных, поскольку поле «Контрольная сумма заголовка» не учитывает поле данных при проверке. Если значение контрольной суммы, которую посчитал узел отличается от контрольной суммы, которая записана в пакете, то он просто отбрасывается.

IP-адрес источника (отправителя) /  Source IP Address (32 бита) — идентифицирует IP-адрес отправителя. Поле не изменяется при передаче пакета по сети, для передачи пакетов без различного рода фильтраций трафика, это поле нужно только конечному узлу, когда маршрутизаторы принимают решение о том, куда отправить пакет, они смотрят лишь только на поле IP-адрес назначения. Обрабатывается на канальном уровне.

IP-адрес получателя / Destination IP Address (32 бита) — идентифицирует IP-адрес получателя. В процессе маршрута не должен изменятся. Обрабатываются на канальном уровне.

Опции, параметры /  IP Options (32 бита) — определяет свойство пакета. Является необязательным и используется обычно только при отладке сети.

Данные. Непосредственно данные. Максимально возможный размер поля данных в IP пакете — 65515 байт.

Как всё это работает?

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

Маршрутизатор получает (восстанавливает) поток битов ->  Определяет с каким типом протокола канального уровня будет работать -> (Если это Ethernet-порт) определяет границу кадра (в т.ч. преамбулы) и снимает заголовок кадра, считает контрольную сумму -> Видит, что внутри IP-пакет — > Отправляет его на обработку модулю IP -> Снятие заголовков IP, разбор поля, поиск интерфейса для дальнейшей передачи ->  Формирование временных заголовков, из склейка с данными для отправки на выходной интерфейс.

Допустим, с помощью команды Ping вы пытаетесь пропинговать узел Yandex.ru. Этим занимается протокол ICMP сетевого уровня. Данные 4 и 5 уровней инкапсулируются (упаковываются) в IP-пакет.

Открыть изображение в полный рост

К IP-пакету из сетевого уровня на канальном уровне добавляется заголовок и концевик. Обратите внимание, что в нашем случае мак-адрес получателя указан OLT (у вас будет также, если подключение по PON). Напомним, что протокол ARP работает только внутри локальной сети.

В MPLS сети промежуточный узел может и не иметь маршрута к отправителю пакета, поэтому вместо того что бы слать ICMP сообщение отправителю напрямую, оно инкапсулируется с тем же стеком меток (label stack), что и исходный пакет, и отправляется по его же пути следования.

Достигая Egress LSR (конечного MPLS маршрутизатора для данного LSP – за ним уже IP сеть без меток), который знает ip маршруты к узлу отправителя, ICMP сообщение Fragmentation Needed «разворачивается» им, инкапсулируется необходимыми заголовками и отправляется назад в MPLS сеть к отправителю оригинального пакета

https://habr.com/ru/post/226807/

В локальной сети это бы происходило так: коммутатор проверяет из заголовка адрес получателя. Если он есть в ARP-таблице — кадр уходит в этот порт. Если его нет, направляется широковещательный запрос «чей это IP» во все порты коммутатора.

Хост, который откликнулся еще раз сравнивает мак-адрес получателя со своим и если всё ок, то заголовки второго уровня отбрасываются. Далее сравнивается IP-адрес. Если и он верен, то заголовки сетевого уровня тоже отбрасываются — дальше данные передаются вышестоящему протоколу (ICMP)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *