Re: [Sysadmins] [Comm] [sisyphus] Well... i've found a bug?.. 8021q?

Re: [Sysadmins] [Comm] [sisyphus] Well... i've found a bug?.. 8021q?

[Alexander Volkov]

On 2009-01-14 10:46:18 +0200, Dmytro O. Redchuk wrote:
DOR> 2009/1/13 Sergey Vlasov <vsu@altlinux.ru>:
DOR> > On Tue, Jan 13, 2009 at 04:59:05PM +0200, Dmytro O. Redchuk wrote:
DOR> >> Вопрос такой.
DOR> [...]

DOR> > Однако в данной ситуации, скорее всего, получается, что смещения
DOR> > считаются от заголовка 802.1Q VLAN, поскольку передача пакетов в
DOR> > модуль bridge выполняется раньше, чем обработка модулем 8021q (по
DOR> > крайней мере, для случая, когда сетевой контроллер не умеет аппаратно
DOR> > обрабатывать теги VLAN).  Видимо, для обработки подобных пакетов
DOR> > придётся писать
DOR> >
DOR> >  tc filter add dev <dev> protocol 802.1Q ...
DOR> Как я понял, в этой ситуации "классификатор" видит не-ip, поэтому фильтр
DOR> не срабатывает (если писать "protocol ip", как у меня).

DOR> То есть дело не в смещении, а в протоколе.

DOR> О порядке следования я не знал, спасибо,
DOR> да и вообще спасибо огромное за подсказку.

DOR> > и составлять u32 match руками с учётом лишних 4 байт 802.1Q перед
DOR> > заголовком IP (в которых надо ещё проверять как минимум протокол).
DOR> Сейчас пока кажется, что в строке создания фильтра достаточно заменить
DOR> "protocol ip" на "protocol 802.1q".

DOR> ( http://securepoint.com/lists/html/LARTC/2007-05/msg00167.html )

DOR> То есть достатоно указать протокол правильно,
DOR> а со смещением проблем не будет. Похоже :-)

DOR> > В случае, если контроллер умеет обрабатывать VLAN аппаратно (драйвер
DOR> > ставит флаг NETIF_F_HW_VLAN_RX), во-первых, обычно такая обработка
DOR> > включается только при создании хотя бы одного vlan-интерфейса через
DOR> > vconfig, во-вторых, пакеты с соответствующими тегами в этом случае
DOR> > уйдут в vlan-интерфейс вместо bridge (хотя можно организовать ещё один
DOR> > мост и между vlan-интерфейсами, только это плохо согласуется со
DOR> > стандартным способом работы STP), а пакеты с неизвестными тегами,
DOR> > похоже, не будут обрабатываться вообще (за исключением передачи в
DOR> > программы, прослушивающие все сетевые пакеты).
DOR> Нет, нужен именно один коммутатор и при этом должно быть безразлично,
DOR> какие теги там есть. (Шейперу безразлично, а мне известно, конечно).

DOR> Спасибо еще раз.

DOR> Буду тестировать.

DOR> ps. Иногда проскакивает вопрос о стабильности чего-то на чём-то, но я его,
DOR> почему-то, обычно замечаю поздновато. У меня на двухпортовом коммутаторе
DOR> шейпится /19, проблем никаких. Два физических процессора, сетевые адаптеры --
DOR> Intel 82546EB, гигабитный линк, ~150 мег трафика. Посмотрел -- сегодня в аккурат
DOR> год аптайма (почему не больше -- уже никто не помнит, то ли меняли питание,
DOR> то ли вообще всего год от инсталляции). Если кому-то это интересно.

DOR> pps. А шейпер на коммутаторе, который шейпит тегированный трафик, позволит
DOR> шейпить "больше одного подключения к Сети", при этом отпадают и мысли о разных
DOR> IMQ, IFB и т.п. Если это кому-то интересно :-)
DOR> Стабильность?.. Ну, пока меня устраивает и стабильность, и производительность.
DOR> Надо тестировать, конечно.

DOR> ppps. Это кому-то интересно? Когда-то я спрашивал (в "сисадминсах", кажется),
DOR> "кто как шейпит кучу народу", но показалось, что никто и никак ;-)
DOR> Но ведь кто-то же и как-то, но все молчат :-)
Ясен пень, интересно. В сисадминсах и место, я бы и искал сначала там же.

--
 Regards, Alexander

Re: [Sysadmins] [Comm] [sisyphus] Well... i've found a bug?.. 8021q?

[Dmytro O. Redchuk]

Добрый день.

Короче, если у вас есть шейпер на бридже на линуксе
(скажем, бридж на двух физических интерфейсах), который
шейпит untagged пакеты, и по какой-то причине вам нужно, чтобы
он как-то начал шейпить уже tagged -- то в конфигураторе
шейпера ничего не нужно менять, кроме "ip" на "802.1q"
(ну, вот вроде как промежуточный результат):

[Не бага, даже совсем наоборот. И всё работает, похоже, замечательно.]

Грубо говоря, в (строку пишу по памяти):
tc filter add dev <dev> parent <prnt> prio <pri> protocol ip \
   u32 match ip dst <IP> flowid <flow>

"protocol ip" надо заменить на "protocol 802.1q" и при этом не нужно
больше ничего менять (все смещения считаются правильно и т.п.).

Проверил на своей конфигурации (пара-тройка хешей от корня, на кучу /30 и /29
в пределах своих /19, и пинг в одном из классов) --- результаты тестов
пока убедительные.

Если же, скажем, вы мазохист, и хотите, чтобы шейпер одинаково шейпил
с меткой и без, вы можете навесить два фильтра -- с "protocol ip" и
"protocol 802.1q" -- которые будут отбрасывать в разные хеши, которые...

Но это уже -- разве что для лабы ;-)

ps. Это всё об "агрегирующем шейпере" -- я в своей конкретной ситуации
хочу обойтись без IMQ, IFB etc..

2009/1/14 Alexander Volkov <vaa@altlinux.org>:
> On 2009-01-14 10:46:18 +0200, Dmytro O. Redchuk wrote:
> DOR> 2009/1/13 Sergey Vlasov <vsu@altlinux.ru>:
> DOR> > On Tue, Jan 13, 2009 at 04:59:05PM +0200, Dmytro O. Redchuk wrote:
> DOR> >> Вопрос такой.
> DOR> [...]
> DOR> ppps. Это кому-то интересно? Когда-то я спрашивал (в "сисадминсах", кажется),
> DOR> "кто как шейпит кучу народу", но показалось, что никто и никак ;-)
> DOR> Но ведь кто-то же и как-то, но все молчат :-)
> Ясен пень, интересно. В сисадминсах и место, я бы и искал сначала там же.
>
> --
>  Regards, Alexander

-- 
Dmytro O. Redchuk