Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

lug-bg: RE: lug-bg: Драйвъри за мрежови платки с поддръжка на MTU>1500


  • Subject: lug-bg: RE: lug-bg: Драйвъри за мрежови платки с поддръжка на MTU>1500
  • From: "Georgi Sinapov" <georgi.sinapov@xxxxxxxxxx>
  • Date: Fri, 17 Dec 2004 07:53:29 +0200
  • Thread-topic: lug-bg: Драйвъри за мрежови платки с поддръжка на MTU>1500

> > Не виждам и това какво общо има с темата VLAN. И не виждам никакво
> > нарушение с Ethernet технологията. Според мен нещо бъркаш IEEE
> > стандартите един с друг, но това е друга тема, далеч от 802.1q... Да не
> > задълбаваме.
> >
> > >2. С въвеждането на VLAN's се появява едно именно "скрито" MTO от 1504,
> > >   което важи *само* за пакети с VLAN header.  Все пак НЕ МОЖЕШ да
> > >   изпратиш нормален Ethernet пакет без VLAN header, който пакет да е
> > >   по-голям от 1500 байта, защото виж точка 1.
> >
> > Също невярно. VLAN стандарта не въвежда никакво MTU (нито скрито, нито
> > явно). Прочети документа по стандарта и ще видиш, че 802.1q въвежда ново
> > поле в ethernet хедъра: VLAN Frame Header = Frame Header + 4 и не отдава
> > значение на стойността на MTU. Имаш 4 байта за VLAN-ID. При наличие на
> > бриджиращи рутери с тунели помежду им и т.н. може да се дефинира и
> > по-малък Frame Header и пак да има VLAN (макар това малко да усложнява
> > технологията и да товари в фрагментиране ако на краищата има големи MTU
> > стойности).
> 
> всъщност да ifconfig ще покаже стойността на payload-a, а не и
> допълнителните
> полета. От 68 до 12000 байта за payload би трябвало да е окай (над 12к
> става
> супер неефективно за среда като етернет). 1500 mtu (говоря за payload-а) е
> препоръчително за съвместимост (предполагам, че по-високите стойности са
> дошли като нова мода от гигабитовия етер). Отделно към тези 1500 имаме 14
> байта за ethernet хедъра, 4 байта за 802.1q VLAN тагове и 4 байта за CRC
> контролни суми. Не всички (цискнята, джунипер, юникси) използват всичко от
> това и може би се получава малко объркване.

Виждам, че всички твърдите, че сте чели dot1q спецификацията, но нещо грешно я цитирате:)
Допълнителният служебен трафик (overhead) за tagged frames е 4 октета, но не се използва изцяло за VLAN IDs. Адаптираното описание на хедъра за Ethernet frames от глава 9.3 на IEEE std 802.1q-1998 е както следва:

0                   1                   2                   3   
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Protocol Type          |  UP |F|      VLAN ID          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
| TAG Protocol Identifier (TPID)|    TAG Control Info (TCI)     |
           2 octets                         2 octets

0-15 - 802.1q TAG Protocol Type (0х8100)
16-18 - user_priority. Обикновено производителите го реферират като CoS поле, аналогия на Layer 3 ToS.
19 - CFI (Canonical Format Indicator).
20-31 - VLAN ID -> 2^12 = 4096 максимално възможни виртуални мрежи.

Best e-gards,
Georgi Sinapov
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================



 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.