[Beby 8]

Подскажите пожалуйста, где можно прочитать по каким признакам потроха Ethernet пакетов передаются одному из следующих протоколов IP (TCP/UDP), IPX/SPX, NetBEUI и т.п. Т.е. каков формат заголовка, расположенного в данных Ethernet Frame, по которому производиться выбор протокола обработчика этого Ethernet Frame: IP (TCP/UDP), IPX/SPX, NetBEUI ?

[xvr 12]

По полю Ethernet size/type (EtherType) в заголовке Ethernet пакета (сразу после MAC'ов отправителя и получателя)

Для IP это 0x0800, IPX - 0x8137 (см http://en.wikipedia.org/wiki/EtherType и http://standards.ieee.org/regauth/ethertype/eth.txt)

NetBEUI ходит поверх IP

[VslavX 0]

По полю Ethernet size/type (EtherType) в заголовке Ethernet пакета (сразу после MAC'ов отправителя и получателя)

Я вчера попытался ответить на вопрос - все знают про поле EtherType/длина. Но у меня вдруг возник встречный вопрос - фреймы бывают двух типов - Ethernet и 802.3, IP в них пакуется соответственно по RFC-894 и RFC-1042. Различаются типы пакетов именно по полю EtherType - больше 1500 - значит фрейм типа Ethernet, меньше 1500 - типа 802.3. А как быть с jumbo-фремами? У них-то длина до 9000. Или по 802.3 такие фреймы не стандартизованы? Не нашел я как-то четкого ответа :(.

[SFx 0]

А как быть с jumbo-фремами? У них-то длина до 9000. Или по 802.3 такие фреймы не стандартизованы? Не нашел я как-то четкого ответа :(.

Самый простой способо - возьмите гигабитные сетевухи и начните передасу jumbo кадров по ним, включив эту опцию. и все проснифайте c помощью Wireshark.

там и поймете в чем разница при разборе кадров.

[Beby 8]

Самый простой способо - возьмите гигабитные сетевухи и начните передачу jumbo кадров по ним, включив эту опцию. И все проснифайте с помощью Wireshark.

там и поймете в чем разница при разборе кадров.

 

Посещали меня и такие мысли... но где гарантия, что на "другом" стенде я не увижу какую-либо отличную картину. А вообще-то хочется определись еще до изготовления своей аппаратуры (на ПЛИС), понадобиться ли Soft-MC или нет - дабы потом не пришлось его прикручивать на коленках.

 

Да и возникает еще один вопрос - в IEEE 802.3 можно сказать описаны 4 разновидности Ethetner Frame:

1. с заголовком LLC.

2. с заголовком LLC/SNAP

3. с истолкованием поля L\T, как Type.

4. с истолкованием поля L\T, как Length.

 

Пока я не нашел правила, в каких случаях какой пакет будет генерироваться Windows/Unix системами.

Т.е. поддержку каких кадров и в каких случаях необходимо реализовать ?

 

Также для меня непонятна процедура анализа Ethetner Frame (с истолкованием поля L\T, как Length) в смысле: как определить какому высокоуровневому протоколу он принадлежит (IP, IPX, а может и еще к 1000 других зарегистрированных протоколов) ?

[VslavX 0]

Самый простой способо - возьмите гигабитные сетевухи и начните передасу jumbo кадров по ним, включив эту опцию. и все проснифайте c помощью Wireshark.

там и поймете в чем разница при разборе кадров.

Давно такое сделано. Jumbo виделись только в формате ethernet. Свой IP-стек понимает оба RFC-894/1042 и на гигабите c Jumbo успешно работает. Но то - практика, частный случай моих локальных сеток и ничего не доказывает. Поэтому стоит вопрос - бывают ли Джумбы типа 802.3 или нет.

P.S. Опции чтобы заставить Windows паковать исходящие IP-пакеты по RFC-1042 (802.3) я что-то не нашел, может подскажет кто? Тогда попробую посмотреть на Jumbo - вдруг новая упаковка и на них проявится.

[defunct 0]

А как быть с jumbo-фремами?

Забить на них. Может если все забьют так это зло исчезнет наконец.

 

The IEEE 802 standards committee does not recognize jumbo frames, as doing so would remove interoperability with other 802 protocols

 

Jumbo frames gained initial prominence when Alteon WebSystems introduced them in their ACEnic Gigabit Ethernet adapters.

Many other vendors also created proprietary implementations; however, they did not become part of the official IEEE 802.3 Ethernet standard.

 

Читать как: один дебил создал дерьмо (ограничение в 9KB по-другому назвать сложно), и много других дебилов пошло по его пути нарушая стандарт, но поскольку популяция дебилов небольшая, то стандарт под них менять не стали.

 

Поэтому стоит вопрос - бывают ли Джумбы типа 802.3 или нет.

802.3 органичение на размер фрейма 1518байт.

Разве это не отвечает на ваш вопрос?

[vvs157 0]

NetBEUI ходит поверх IP

Умеет ходить без IP - это самый первый Микрософтовский сетевой протокол. Через машрутизаторы не ходит.

[Beby 8]

Умеет ходить без IP - это самый первый Микрософтовский сетевой протокол. Через машрутизаторы не ходит.

Вот мне так тоже казалось, что если поставить на машинах с Windows 98 - XP протокол NetBEUI (и назначить копирование файлов через него), то копирование файлов происходит быстрее, чем через TCP/IP - а значить не может эмулироваться через IP. Но, к сожалению, это не даёт ответов на сформулированный мною выше вопрос:

Да и возникает еще один вопрос - в IEEE 802.3 можно сказать описаны 4 разновидности Ethetner Frame:

1. с заголовком LLC.

2. с заголовком LLC/SNAP

3. с истолкованием поля L\T, как Type (Ethernet II Frame / DIX Frame).

4. с истолкованием поля L\T, как Length (Ethernet Raw Frame / Ethernet Nowell Frame).

 

Пока я не нашел правила, в каких случаях какой пакет будет генерироваться Windows/Unix системами.

Т.е. поддержку каких кадров и в каких случаях необходимо реализовать ?

 

Также для меня непонятна процедура анализа Ethetner Frame (с истолкованием поля L\T, как Length) в смысле: как определить какому высокоуровневому протоколу он принадлежит (IP, IPX, а может и еще к 1000 других зарегистрированных протоколов) ?

Кто-нибудь чего-нибудь может ответить на эти вопросы ???!!

[VslavX 0]

Забить на них. Может если все забьют так это зло исчезнет наконец.

 

802.3 органичение на размер фрейма 1518байт.

Разве это не отвечает на ваш вопрос?

Не совсем. Jumbo - это "нестандарт". Вопрос в том это нестандарт только для ethernet или же еще могут случаться и в 802.3. По идее - не должны, но вдруг кто "встречал" такое?

А насчет "забить" и "дебилов" я бы не был так категоричен. Ограничение 1518 было принято в эпоху 10-мегабитных сетей, сейчас скорость выросла на 3 порядка, а характерные времена перевалки и обработки пакетов остались почти те же. У меня есть задачи, которые решаются только большими пакетами - на стандартных не удается достичь требуемой утилизации полосы для гигабитных каналов. Хорошо бы еще увеличить пакет, но при размерах более 10000 байт алгоритм CRC-32 становится менее эффективным, да и IP-датаграмма ограничена 64K.

Извиняюсь за оффтоп.

[defunct 0]

Вопрос в том это нестандарт только для ethernet или же еще могут случаться и в 802.3. По идее - не должны, но вдруг кто "встречал" такое?

Выражайтесь точнее, потому как вопрос

"нестандарт только для ethernet или же еще могут случаться и в 802.3"

звучит не точно в свете:

 

"Ethernet is standardized as IEEE 802.3."

 

В 802.3 невозможно случаться пакетам длиной больше 1518byte.

 

А насчет "забить" и "дебилов" я бы не был так категоричен. Ограничение 1518 было принято в эпоху 10-мегабитных сетей, сейчас скорость выросла на 3 порядка, а характерные времена перевалки и обработки пакетов остались почти те же.

"забить" - потому что нестандарт.

"дебилы" - потому что несмотря на "нестандарт" заложили ограничение в 9KB, а не в 64KB.

[xvr 12]

Умеет ходить без IP - это самый первый Микрософтовский сетевой протокол.

Угу, в девичестве он ходил поверх IEEE802.2 & IPX/SPX (используя NetBIOS). В связи с повсеместным отмиранием IPX/SPX его научили ходить поверх TCP/IP. Но и поверх IPX/SPX он до сих пор умеет ходить.

В любом случае это не отдельный протокол сетевого уровня, а 'нечто сверху' :rolleyes: