Обнаружение различных кадров Ethernet


12

Как можно различить разные пакеты в протоколе Ethernet? Он не имеет поля / области "длины", как это делают протоколы более высокого уровня.

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

Выполняется ли логическое разделение с использованием поля протокола EtherType? (т.е. получение длины пакета с использованием типа протокола более высокого уровня, который имеет поле длины в своих заголовках).

Разве физическое различие заключается просто в непередаче электрических сигналов? (Насколько мне известно, высокие / низкие электрические сигналы представляют 0/1 бит).

Ответы:


14

Хотя YTTI ответил, есть некоторые важные детали, которые могут вас заинтересовать ...

Как можно различить разные пакеты в протоколе Ethernet? Он не имеет поля / области "длины", как это делают протоколы более высокого уровня.

На самом деле Ethernet имеет несколько инкапсуляций:

  • Ethernet II (обычно используется для IP, как указано в [RFC 894], является наиболее распространенной инкапсуляцией): не имеет поля длины , вместо этого используется поле типа ...
       +----+----+------+------+-----+
       | DA | SA | Type | Data | FCS |
       +----+----+------+------+-----+
                 ^^^^^^^^

       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Type    Protocol Type           (2 bytes: >= 0x0600 or 1536 decimal)  <---
       Data    Protocol Data           (46 - 1500 bytes)
       FCS     Frame Checksum          (4 bytes)
  • 802.2 LLC Ethernet: имеет поле длины
       +----+----+------+------+------+------+-----+
       | DA | SA | Len  | LLC  | SNAP | Data | FCS |
       +----+----+------+------+------+------+-----+
                 ^^^^^^^^

       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
       LLC     802.2 LLC Header        (3 bytes)
       SNAP                            (5 bytes)
       Data    Protocol Data           (46 - 1492 bytes)
       FCS     Frame Checksum          (4 bytes)

Независимо от наличия поля длины 802.2 вы всегда можете обнаружить конец кадра Ethernet на проводе, ища 96-битный межкадровый разрыв .

Выполняется ли логическое разделение с использованием поля протокола EtherType? (т.е. получение длины пакета с использованием типа протокола более высокого уровня, который имеет поле длины в своих заголовках).

Под логическим разделением я предполагаю, что вы имеете в виду разделение между различными протоколами, передаваемыми внутри Ethernet, таково различие между IPv4, IPv6 или, возможно, кадрами Spanning-Tree.

  • Ethernet II обычно использует поле Тип
  • 802.2 LLC Ethernet обычно использует пятибайтовое расширение 802.2 Ethernet SNAP . Протоколы декодируются только с расширением SNAP, когда байты 802.2 DSAP / SSAP равны 0xAAAA.

Разве физическое различие заключается просто в непередаче электрических сигналов? (Насколько мне известно, высокие / низкие электрические сигналы представляют 0/1 бит)

Проще говоря, да, между кадрами Ethernet существует 96-битный разрыв; однако обратите внимание, что Ethernet использует кодировку 8b / 10b (FastEthernet) и кодировку 64b / 66b (GigabitEthernet), поэтому технически некорректно говорить «непередача электрических сигналов», поскольку 8b / 10b не имеет « молчаливое состояние.


Для любопытных я также ссылаюсь на оригинальную спецификацию Ethernet версии 2 .


7

Ethernet имеет преамбулу и начальный разделитель кадров в начале и в конце, он имеет «IFG» или межкадровый промежуток. Они используются для определения начала и конца кадра.


Это разделение в физическом или логическом объеме? Однако что, если поле данных протокола будет содержать информацию / символы / сигналы, которые совпадают с начальным / конечным разделителями?
Отражение

1
Разрыв в буквальном смысле просто так, нет риска найти его в полезной нагрузке. Однако в каком-то другом, не относящемся к Ethernet контексте это вызывает беспокойство и может быть устранено путем проверки того, что некоторые символы никогда не используются для кодирования данных, а только для передачи сигналов, однако это уменьшило бы эффективность, тратя впустую некоторые символы на «бесполезные» данные.
2011 г.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.