Jump to content

    
Sign in to follow this  
Koluchiy

Формат Jumbo-кадра?

Recommended Posts

Здравствуйте, уважаемые гуру.

 

Чего-то не нашлось описание Jumbo-кадра.

Много о них говорится, но что это конкретно - непонятно.

 

Или это просто Ethernet-пакет с полем формата/длины > какого-то числа? (какого?)

 

В общем, если кто-нибудь знает, где понятие jumbo-кадра хоть как-то формализовано, ссылки велкам.

 

Заранее спасибо.

Share this post


Link to post
Share on other sites

Тогда как понять ситуацию.

 

По стандарту, когда поле "тип/размер" больше 1536 (если не путаю), то поле = тип.

Если Jumbo, то поле "тип/размер" явно больше 1536, соответсвтенно это тип.

 

Или тут есть некая вольная интерпретация стандарта?

Share this post


Link to post
Share on other sites
По стандарту, когда поле "тип/размер" больше 1536 (если не путаю), то поле = тип.

Может быть кадр типа Ethernet-II - там тип пакета, а может быть 802.3 - там длина.

Типы начинаются ЕМНИП с 0x0800 - IP.

На самом деле, когда работаешь напрямую контроллером - длина принятого/отправленого кадра находится в регистрах и контроллеру собственно по барабану что там находится. (У некоторых контроллеров флаг ставится что находится в этом поле - флаг или длина, по приему)

 

Сейчас обычно ходят Ethernet-II. Так что на 802.3 можно просто забить!

 

 

 

Share this post


Link to post
Share on other sites

Так всё-таки, что такое Jumbo-кадр?

Чему в этом случае равно поле тип/размер кадра?

 

Это пакет с нагрузкой любого протокола верхнего уровня (IP например) с большим размером пакета, или это самостоятельный тип пакета Ethernet (какой?).

Share this post


Link to post
Share on other sites
Так всё-таки, что такое Jumbo-кадр?

Это кадр с размером выше 1518 байт!

 

Чему в этом случае равно поле тип/размер кадра?

Это зависит от того что внутри кадра.

Но реально используется Ethernet II - так что там тип пакета.

 

 

Это пакет с нагрузкой любого протокола верхнего уровня (IP например)

да!

 

Share this post


Link to post
Share on other sites

Чем дальше в лес, тем интереснее.

 

Вот здесь вот: http://en.wikipedia.org/wiki/EtherType написано, что Jumbo - это (только) тип 0x8870 .

 

Еще там есть интересное:

The size of the payload of non-standard jumbo frames, typically ~9000 Bytes long, falls within the range used by EtherType; this conflict is resolved by substituting the special EtherType value 0x8870 when a length would otherwise be used.[2] The network stack can replace this special EtherType with the actual length of the packet on receive, or when bridging to non-Ethernet networks like FDDI.

 

Честно говоря, не совсем понял.

Типа, пакет передается с 0x8870 в поле тип/длина, и длина пакета = фактической длине?

Типа, сколько пришло до окончания кадра, столько пришло...

Share this post


Link to post
Share on other sites
Типа, пакет передается с 0x8870 в поле тип/длина, и длина пакета = фактической длине?

0x8870 используется если вы используете IEE802.3/IEE802.2 инкапсуляцию!

IMHO на нее можно забить!

 

А если вы используете Ethernet II (RFC894) там стоит тип! Он так и остается для IP - 0x0800.

в кадре Ethernet II информации о длине нет!

 

 

 

Share this post


Link to post
Share on other sites

не надо путать тип кадра и его длину. изначально в ethernet поле следующем за SRC_MAC передавали длину, но потом стали передавать тип данных, а чтобы сохранить обратную совместимость назвали поле length/type. есть весьма конкретный список типов нагрузки ethernet, там 0x0800, 0x0806, и так далее... но договорились что если длинна кадра меньше 0x0400 - то это указатель длины кадра.

что касается jumbo - тут настолько все просто что даже не верится. это обычный кадр у которого размер полезной нагрузки может быть до 9000 байт.

к примеру вам нужно передать 8192 байта данных по udp (для простоты). так вот если у ваш сетевой адаптер не позволяет передать jumbo кадр (или это опция отключена) то стек IP разбивает ваш кусок данных udp на фрагменты, равные по длине максимальному MTU адаптера, приписывает каждому фрагменту IP-header и отправляет. накладные расходы на IFG, DST_MAC, SRC_MAC, TYPE и 20 байт (еще CRC32надо тоже учитывать) на IP header накладываются на каждый кадр. (их будет 5 по 1514 байт и один 834 байт :) без CRC32)

Так если бы jumbo поддержка была выключена Стек IP создал бы один пакет размером 8234 байта (без CRC32) который бы отправлен был бы за один раз и его прием не потребовал бы не только сборки 6 фрагментов, но и тупо меньше физического времени (где то на 3%).

Share this post


Link to post
Share on other sites
поле следующем за SRC_MAC передавали длину, но потом стали передавать тип данных, а чтобы сохранить обратную совместимость назвали поле length/type.

Это не совсем так! Понято что есть древние форматы кадра, которые Novell со своим IPX использовал...

Но в современных сетях это два разных формата кадра.

802.3 и Ethernet II, у Ethernet II тип пакета и сразу данные, а у 802.3 после заголовка идет 802.2 LLC/SNAP header.

 

 

длинна кадра меньше 0x0400 - то это указатель длины кадра.

только 0x600, поэтому для 802.3 jumbo фреймов используется 0x8870

 

Еще вместо поля length/type может вообще стоять стоят 802.1q таг, а поле length/type идти за ним.

 

Share this post


Link to post
Share on other sites
0x8870 используется если вы используете IEE802.3/IEE802.2 инкапсуляцию!

IMHO на нее можно забить!

Я не могу забить, я должен передавать вообще весь трафик, который ко мне приходит.

Любого стандартного формата.

 

что касается jumbo - тут настолько все просто что даже не верится. это обычный кадр у которого размер полезной нагрузки может быть до 9000 байт.

То есть, Jumbo - это фрейм Ethernet-II, содержащий пакет верхнего уровня с большой длиной полезной нагрузки.

Тогда что такое тип 0x8870?

Share this post


Link to post
Share on other sites
Тогда что такое тип 0x8870?

Это значит что пакет 802.3 далее идет LLC/SNAP заголовок, но длину надо узнавать у адаптера

 

Для ethernet II все проще там вообще ничего не меняется, как был тип так и остается.

 

 

 

Share this post


Link to post
Share on other sites
А откуда узнает длину адаптер?

Адаптер берет длину по фактическим данным, он для этого заголовок вообще не анализирует - для него это обычные данные внутри пакета, заголовок смотрится потом для фильтров, например.

Все зависит от физического уровня. Но в общем там в кодирование есть старт кадра, конец кадра, idle...

 

 

Share this post


Link to post
Share on other sites

В общем, для себя я сделал вывод: надо находить начало кадра, конец кадра, самому считать его длину, а внутрь не лезть вообще :).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this