[Comm] Well... i've found a bug?.. 8021q?

[Comm] Well... i've found a bug?.. 8021q?

[Dmytro O. Redchuk]

Добрый день.

Прошу прощения -- кросспост.

Вопрос такой.

Делаю из двухпортового линукса коммутатор (brctl addbr и далее).

Сквозь него пингаю нечто.

На обеих портах этого коммутатора навешиваю HTB.

Всё работает.

Всё работает, *если сквозь коммутатор ходят untagged packets*.

Если я, ничего не меняя на коммутаторе, начинаю пингать мечеными пакетами,
то всё точно так же работает (пингается, то есть -- коммутатор на физических
интерфейсах замечательно пропускает vlan'ы), кроме HTB -- у HTB все пакеты
аккуратно падают в default class. То есть, фильтры типа
  tc filter add dev <dev> protocol ip parent 1:0 prio 100  u32 match
ip dst <dst> flowid <flowid>
просто не срабатывают.

Если пишу offset, то ничего не меняется, да и не должно, вроде (смещения должны
отсчитываться от начала пакета IP).

REORDER_HDR тоже ни на что не влияет (да и тоже не должен).

((Mmm... Somewhere over there... 8021q?))

Куда-то повесить багу?

ps. Пробовал на Desktop 4.1 и Debian Lenny, но, чесгря, думаю, что
проблема где-то ниже.

pps. LARTC mailing list давно молчит? На #lartc тоже давно застой? Или
не туда смотрю?

ppps. Спасибо за внимание :-)

-- 
Dmytro O. Redchuk

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

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]

On Tue, Jan 13, 2009 at 04:59:05PM +0200, Dmytro O. Redchuk wrote:
> Вопрос такой.
> 
> Делаю из двухпортового линукса коммутатор (brctl addbr и далее).
> 
> Сквозь него пингаю нечто.
> 
> На обеих портах этого коммутатора навешиваю HTB.
> 
> Всё работает.
> 
> Всё работает, *если сквозь коммутатор ходят untagged packets*.
> 
> Если я, ничего не меняя на коммутаторе, начинаю пингать мечеными пакетами,
> то всё точно так же работает (пингается, то есть -- коммутатор на физических
> интерфейсах замечательно пропускает vlan'ы), кроме HTB -- у HTB все пакеты
> аккуратно падают в default class. То есть, фильтры типа
>   tc filter add dev <dev> protocol ip parent 1:0 prio 100  u32 match
> ip dst <dst> flowid <flowid>
> просто не срабатывают.
> 
> Если пишу offset, то ничего не меняется, да и не должно, вроде (смещения должны
> отсчитываться от начала пакета IP).

Однако в данной ситуации, скорее всего, получается, что смещения
считаются от заголовка 802.1Q VLAN, поскольку передача пакетов в
модуль bridge выполняется раньше, чем обработка модулем 8021q (по
крайней мере, для случая, когда сетевой контроллер не умеет аппаратно
обрабатывать теги VLAN).  Видимо, для обработки подобных пакетов
придётся писать

  tc filter add dev <dev> protocol 802.1Q ...

и составлять u32 match руками с учётом лишних 4 байт 802.1Q перед
заголовком IP (в которых надо ещё проверять как минимум протокол).

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Dmytro O. Redchuk]

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

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

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

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

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

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

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

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

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

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

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

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

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

-- 
Dmytro O. Redchuk

Re: [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