[bos9]

Правильно ли я понимаю, что в случае 802.1q тег влана пишется в L2 заголовок и не влияет на MTU, а в случае 802.1ad (q in q) inner тэг пишется в payload L2, т.е. увеличивает MTU до 1504 байт? Суть вопроса в изменении (не изменении) system mtu на транзитных свичах.

[bokl]

все правильно, надо менять

[Jazzy$]

Причем менять с запасом... 1536 или как РТК 9000...

[bda]

Причем менять с запасом... 1536 или как РТК 9000...

 

А зачем с запасом?

[Ivan_83]

Правильно ли я понимаю, что в случае 802.1q тег влана пишется в L2 заголовок и не влияет на MTU, а в случае 802.1ad (q in q) inner тэг пишется в payload L2, т.е. увеличивает MTU до 1504 байт? Суть вопроса в изменении (не изменении) system mtu на транзитных свичах.

В обоих случаях оно влияет на мту и пишется одинаково.

[bos9]

Правильно ли я понимаю, что в случае 802.1q тег влана пишется в L2 заголовок и не влияет на MTU, а в случае 802.1ad (q in q) inner тэг пишется в payload L2, т.е. увеличивает MTU до 1504 байт? Суть вопроса в изменении (не изменении) system mtu на транзитных свичах.

В обоих случаях оно влияет на мту и пишется одинаково.

 

тогда почему не возникает проблем при использовании mtu 1500 и 802.1q ?

[dignity]

видимо потому что, коммутатор источник знает о том, что пакет содержит 802.1q, и 1500 его MTU, как и у транзитников.

[bos9]

вот нашел:

"The 802.3ac standard increased the maximum frame length from 1518 to 1522 Bytes specifically, and exclusively, for VLAN tags. If a switch vendor adheres to this standard then VLAN tags can be viewed as part of the header (MTU stays as 1500) while QinQ tags require an increase of MTU (to 1504) to handle the inner tag." © http://groups.geni.net/geni/wiki/QinqResults

[Ivan_83]

тогда почему не возникает проблем при использовании mtu 1500 и 802.1q ?

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

[qwertzy]

тогда почему не возникает проблем при использовании mtu 1500 и 802.1q ?

Возникает, это зависит от коммутатора/конвертера.

Кстати принадлежность VLAN тега к L2 Header`у чистая условность, технически TPID поле тега не что иное как EtherType для пакета типа .1Q или QinQ, а EtherType идущий после тега является глубоким пейлоадом для тупого коммутатора/конвертера.

[s.lobanov]

Причем менять с запасом... 1536 или как РТК 9000...

А зачем с запасом?

 

Ну например старые циски требует ребут для смены mtu, лучше это сделать заранее, чем потом спешно посреди дня бутать кучу железа.

Бывают(крайне редко, но всё же) клиенты, которые просят l2/l3-vpn с повышенным mtu, они там поверх провайдерского vpn ещё свои тунели делают и чтобы не залезать на L4 и не править tcp mss, просят mtu побольше.

Да и самим может захотеться поднять mpls c кучей меток, а тут раз и по дороге какая-нибудь хрень с стоит с маленьким mtu.

[bos9]

Кстати принадлежность VLAN тега к L2 Header`у чистая условность, технически TPID поле тега не что иное как EtherType для пакета типа .1Q или QinQ, а EtherType идущий после тега является глубоким пейлоадом для тупого коммутатора/конвертера.

 

Все правильно, т.е. если при использовании q-in-q выставить поле TPID=0x8100 (чтобы транзитные коммутаторы его нормально скушали), то на транзите поля vlan ID (последние 2 байта 802.1q tag) и EtherType будут считаться уже как payload, отсюда необходимость увеличить MTU на транзите до 1504. Это, если на транзите нечто однозначно умеющее только 802.1q. А если транзит тоже умеет 802.1ad, то можно не парясь слать TPID=0x88a8 и тогда все теги будут восприняты транзитом, как часть L2 header и с MTU можно не мудрить.

Edited March 8, 2012 by bos9

[Ivan_83]

Читайте википедию с картинками :)

 

1. Тупые коммутаторы вообще не смотрят что внутри пакета, их интересует только мак от и мак куда. При этом они могут пересылать хоть джамбофреймы и QinQinQinQinQ - им пофик.

 

2. Коммутаторы которые понимают только 802.1q смотрят не только на маки, но и на ether_type, в котором для тэгированного трафика TPID=0x8100

 

3. Коммутаторы метро эзернет или просто чуть более продвинутые умеют настраивать TPID который обозначает тэгированый трафик, TPID=0x88a8 - просто число, можно поставить другое. Можно сделать внутренний и внешний тэг TPID=0x8100 - что собственно многие и делают.

Коммутатор, как правило смотрит только внешний тэг и мак куда для принятия решения о форвадинге пакета.

 

Внутрь пакета коммутатор лезет если:

- есть ацл на то указывающие

- это л3 коммутатор и дст мак указывает на мак л3 интерфейса в самом коммутаторе, при этом влан тэг допускает пропуск трафика и ацл не запрещает.

 

1500 байт - это типа принятый размер данных в эзернет пакете, сам эзернет пакет всегда больше, тк содержит:

- мак от (6 байт);

- мак куда (6 байт);

- тип содержимого (2 байта) (либо длину данных если значение меньше 0x0600=1536, если 0x0004 то ETHERTYPE_8023 и ещё есть пара специфичных вещей);

- данные....

- CRC (4 байта) - обычно их не видно, тк оно аппаратно везде обрабатывается.

 

6 + 6 + 2 = 14 заголовок

+ 1500 = 1514 заголовок+данные

+ 4 = 1518 полный фрейм

 

При тегировании:

TPID = ether type encap

Было: [dmac] [smac] [ether_type] [payload]

Стало: [dmac] [smac] [TPID] [PCP/CFI/VID] [ether_type] [payload]

Добавилось 4 байта:

- 2 байта - TPID, записался вместо ether_type, чтобы было ясно что пакет тэгирован;

- 2 байта - VID + PCP + CFI.

= итого пакет теперь весит 1522 байта.

 

Завернём его ещё раз в тэг (QinQ):

Было: [dmac] [smac] [TPID] [PCP/CFI/VID] [ether_type] [payload]

Стало: [dmac] [smac] [M:TPID] [M:PCP/CFI/VID] [TPID] [PCP/CFI/VID] [ether_type] [payload]

(M: - внешний тэг, типа метро).

+ ещё 4 байта

итого 1526 байт.

 

Современное железо, если не тянет джамбофреймы то имеет мту 1536, те можно ещё два раза завернуть пакет и останется 2 байта.

[dmvy]

а какие коммутаторы умеют форвардить на L3 qinq трафик? ведь MTU относится к полезной нагрузке (ip, т.е. L3 уровень). сколько бы меток не было даже роутер их сбросит и навесит в соответствии с исходящим интерфейсом. а для передачи по L2 сети достаточно включить джумбо пакеты, кторые умеют все современные коммутаторы.

[dmvy]

кстати, 802.1q - это по сути ether_type 0x8100, но с условием, что дальше идет тэг влана. затем надо qiniq, снова пишем тип кадра 0x8100. L2 инкапсуляция заканчивается: можно писать, что дальше идет ip 0x0800 и как раз отсюда начинает считаться MTU.

[s.lobanov]

а какие коммутаторы умеют форвардить на L3 qinq трафик?

 

Например, huawei s9300

[bos9]

Современное железо, если не тянет джамбофреймы то имеет мту 1536, те можно ещё два раза завернуть пакет и останется 2 байта.

 

По-моему вы спутали мту и максимальную длину фрейма.

А суть таки в тех 2-ух байтах, что идут вслед за полем [smac]. От их значения зависит, что будет воспринято как часть L2 header, а что уже payload.

[zi_rus]

По-моему вы спутали мту и максимальную длину фрейма.

а я вот, честно говоря, не могу разобраться какие мту как считаются

System MTU - это глобальная настройка коммутатора, максимальный размер фреймов, от ДСТ_МАК до CRC?

МТУ на порту - то же самое только переопределяет глобальный параметр на конкретном порту?

ip mtu на L3-интерфейсе (или не только L3?)- фактически максимальный размер полезной нагрузки payload в кадре

 

если я что-то упустил, можно это уточнить?

[Ivan_83]

По-моему вы спутали мту и максимальную длину фрейма.

Maximum Transmission Unit (MTU) of a communications protocol of a layer is the size (in bytes) of the largest protocol data unit that the layer can pass onwards.

Подразумевается что столько данных можно передать в протоколе к которому данный интерфейс даёт доступ/реализует.

Если вы поставите в компе мту 1510 то у вас IP пакеты будут такого размера.

Максимальный мту как раз и высчитывается из максимальной длинны фрейма, но на практике пользуются стандартными значениями мту.

 

System MTU - это глобальная настройка коммутатора, максимальный размер фреймов, от ДСТ_МАК до CRC?

ether_type забыли, после него идёт пейлоад.

 

ip mtu на L3-интерфейсе (или не только L3?)- фактически максимальный размер полезной нагрузки payload в кадре

Да, примерно так. На л3 считается вместе с ип заголовком, потому пинг 1500 не пройдёт если выставить не фрагментировать на интерфейсе с мту 1500 - банально не хватит места под ип и ицмп заголовок.

[zi_rus]

ether_type забыли, после него идёт пейлоад.

я про него ничего не говорил, просто от и до

 

ок, про ip мту больше не говорим, это настройка для интерфейсов третьего уровня, пусть в нашем эксперименте он всегда 1500

на коммутаторе настроили мту 1518 - будет ходить только нетегированный трафик

мту 1522 - tag и untag трафик ходит

мту 1526 - ходит все, в том числе q-n-q

 

я ничего не упускаю?

[Ivan_83]

кстати, 802.1q - это по сути ether_type 0x8100, но с условием, что дальше идет тэг влана. затем надо qiniq, снова пишем тип кадра 0x8100. L2 инкапсуляция заканчивается: можно писать, что дальше идет ip 0x0800 и как раз отсюда начинает считаться MTU

Свич (и человек) не отличит мусор от "тэг влана", потому всё что будет у пакета с типом 0x8100 (или другим определённым для свича) будет считаться тэгом/приоритетонм/флагом каноничности.

Типа для метроезернета внешний тэг не 0x8100 а 0x88a8, просто так там принято :)

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

Например есть прова сетка в которой можно только PPPoE, а хочется с соседом локалку, и между абонентами пппое пакеты не фильтруются: берём и заворачиваем пакеты в тэг с номером пппое (там их два, в тот который пролезет/понравится) вместо 0x8100 и наслаждаемся локалкой. (завернуть в влан с кустомным TPID можно на коммутаторах где это настраивается или на патченой ng_vlan во фре, которая скоро будет в основной ветке - там оно из коробки позволяет задавать TPID)

МТУ - это то, сколько данных можно послать через интерфейс так чтобы оно дошло или просто сколько интерфейс физически может отправить.

В случае л2 интерфейса (эзернет сетевуха) мту будет уменьшатся если наворотить туда QinQ кучу или MPLS.

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

 

на коммутаторе настроили мту 1518 - будет ходить только нетегированный трафикмту 1522 - tag и untag трафик ходитмту 1526 - ходит все, в том числе q-n-qя ничего не упускаю?

Вроде так.

Только тэгированный трафик можно пускать хоть на 1400, просто пейлоад меньше будет :)

[zi_rus]

Только тэгированный трафик можно пускать хоть на 1400, просто пейлоад меньше будет

поэтому я и сказал, что ip mtu мы сделали 1500, для порядка

 

В случае л2 интерфейса (эзернет сетевуха) мту будет уменьшатся если наворотить туда QinQ кучу или MPLS.

может правильней сказать, что нам _придется_ уменьшать мту полезной нагрузки при увеличении кол-ва служебной информации и неизменности L2 mtu на транзитных коммутаторах

Edited March 9, 2012 by zi_rus

[dmvy]

еще раз повторюсь, MTU - это параметр ip-интерфейса и его имеет смысл увеличивать лишь в том, случае, если производится инкапсуляция в ip-заголовок. например gre. хотите сделать L2VPN поверх ip-сети, значит нужно произвести инкапсуляцию полного кадра ethernet в ip без фраментации, вот для этого и увеличиваем на всей трассе MTU.

 

даже, если используете на сети qinq или mpls, то на ip-интерфейсе не нужно увеличивать MTU.

L2: frame size

L3: MTU

[bos9]

прийдется стенд собрать: два свича с q-n-q, между ними суровый онли 802.1q свич и ping -s 1472 -M do

[Ivan_83]

MTU - это параметр ip-интерфейса

МТУ это в принципе параметр, такой же как и: грузоподъёмность (человека/лебёдки/крана/авто).