Шейпер на VLAN

Да нет никаких проблем с VLAN интерфейсами. У меня все нормально работает.

Вот к примеру пишу самое простое:

#IF=eth1
IF=vlan12
RATE=500
CEIL=1000

tc qdisc add dev ${IF} root handle 1: htb default 20
tc class add dev ${IF} parent 1: classid 1:1 htb rate ${RATE}kbit ceil ${CEIL}kbit

tc class add dev ${IF} parent 1:1 classid 1:10 htb rate 200kbit ceil ${RATE}kbit prio 1
tc class add dev ${IF} parent 1:1 classid 1:20 htb rate 200kbit ceil ${RATE}kbit prio 2

tc qdisc add dev ${IF} parent 1:10 handle 10: pfifo
tc qdisc add dev ${IF} parent 1:20 handle 20: sfq perturb 10

tc filter add dev ${IF} parent 1:0 protocol ip prio 1 u32 match ip protocol 6 0xff flowid 1:10

Типа весь TCP трафик пускать через 10, а по дефолту 20.
На eth1 работает (оба счетчика показывают значения), а на vlan:

tc -s -d qdisc ls dev vlan12

qdisc htb 1: root r2q 10 default 20 direct_packets_stat 0 ver 3.17
Sent 2161027 bytes 5720 pkt (dropped 0, overlimits 2975 requeues 0)
rate 0bit 0pps backlog 0b 22p requeues 0
qdisc pfifo 10: parent 1:10 limit 1p
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 20: parent 1:20 limit 127p quantum 1518b flows 127/1024 perturb 10sec
Sent 2161027 bytes 5720 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 26966b 22p requeues 0

в qdick 10 - пусто все идет по default. И так с любым фильтром, хоть по IP хоть по порту, и даже маркированным через iptables.

> Может ли шейпер (tc + htb) работать на vlan?

Присоединяюсь к вопросу.
Фильтрами на базе match ip пользоваться не могу в силу особенностей роутинга, а с фильтрами на базе mark (handlde 123 fw) ситуацию подтверждаю. Даже не понимаю, что именно режеться.

Пока обошёл усложнённой фильтрацией при маркировке в mangle, повесив классы на саму сетевуху, на которой поднят вилан. Работает.

Gentoo Linux 2.6.24

Так и есть! Перебросил инет не на VLAN, а на физическую сетевуху (воткнул) - те же правила заработали! Вот теперь думаю - либо что-то не то в VLAN-ах, либо надо втыкать вторую сетевуху на постоянку, либо смотреть в сторону всяких извратов типа IMQ.

Есть подозрение, что поля приоритетов в пакетах используются самим аппаратным маршрутизатором (поддерживающим QoS и 802.1), в которую воткнут VLAN с роутера, по этому все пометки "херятся", но пока ни где не могу найти подтверждения в доках.

Если верить документации, значения mark в таблесах не выходят за пределы системы. И не имеют никакого отношения к DSCP и CoS. Это локальная маркировка в пределах одного хоста.

Так что, вряд ли. Тем более, что, судя по первому сообщению, фильтры на основе IP адресов тоже не пашут.

Кстати, была также проблема с tc + htb на bond'ах. Там вообще ад какой-то был.

Пришлось делить полосу на две равные части, немного повышать цифры, и вешать на обе сетевухи, участвующие в bond'е. За счёт использования round-robin при выборе интерфейса для отсылки пакета, схема вполне даже работает.

> Да нет никаких проблем с VLAN интерфейсами. У меня все нормально работает.
> zhiltsov * (*) (04.08.2008 13:00:41)

Не могли бы рассказать поподробнее, с примерами?
Какая система, ядро, iproute2 какой версии?

Пример правила, если не сложно.

> Если верить документации, значения mark в таблесах не выходят за пределы системы.

А мож херятся приоритеты? "Маркеры приоритетов включаются в VLAN теги. 802.1Q стандарт определяет VLANs и VLAN теги. Этот стандарт на самом деле резервирует три бита в VLAN пакете, которые используются для записи кода приоритетности." По этому все и идет в default?

Вроде бы опрелились уже.

Проблема не в том, что mark не работает, а в том, что не работают фильтры по mark, висящие на вилане.

Ещё раз.

Есть роутер.
Есть сетевуха с тремя виланами.
Есть маркировка пакетов средствами iptables/mangle/MARK.
Есть фильтрация по mark с раскидыванием по классам на интерфейсе.

Если фильтрация и классы висят на vlanM, творятся чудеса.
Если фильтрация и классы висят на ethN (на которой по прежнему имеются те же три вилана, сама сетевуха (ethN) в роутинге не участвует, на ней даже IP адреса нет), траффик, уходящий через vlanM, замечательно шейпиться.

*определились

*шейпи_тся_

В общем поставил вторую сетевуху eth2, вывел ее в свич, сделал там VLAN+untagged и повесил шейпер на eth2 - все работает. С родным VLAN - не работает. Правила те же.

> В общем поставил вторую сетевуху eth2, вывел ее в свич,

Халявщик. :)
А у меня в датацентре стоит, один юнит. Хер что вставишь, хер куда выведешь.

> Халявщик. :)

А че делать, задачу решать-то надо! :) Хорошо-бы конечно все-таки разобраться почему на vlan-ах затык...

#IF=eth1 IF=vlan12

А интерфейс часом не так должен выглядеть: IF=eth1.12 ?

таки может и правда в дистрибутиве проблема? гента как ни как, может драйвера шибко "пропатченые"

>А интерфейс часом не так должен выглядеть: IF=eth1.12 ?

это алиасы, дурашка :)

>это алиасы, дурашка :)

это имя устройства http://www.opennet.ru/base/net/tale_linux_vlan.txt.html там же кстати и о проблемах использования различных имен :)

> Подскажи пожалуйста, всезнающий All! Может ли шейпер (tc + htb) работать на vlan?

Дистрибутив, ядро, название интерфейсов?

> таки может и правда в дистрибутиве проблема? гента как ни как

Кстати, да, быть может. iptraf тоже траффик на виланах не кажет, реальные интерфесы подавай.

Я оказвается обманул, несмотря на то что роутер у меня весь в vlan (там всего один eth используется). но шейпинг сделан на IMQ интерфесах. (это кстати может помочь человеку в датацентре :) )

Но несколько лет назад у меня точно был шейпинг (CBQ) на vlan и работал он замечательно.

А сейчас у меня на VLAN интерфейсах ESFQ:

#tc -s -d qdisc show dev vlan255

qdisc esfq 8002: quantum 1514b limit 128p flows 128/1024 hash: dst

Sent 19020227771380 bytes 2602326221 pkt (dropped 94, overlimits 0 requeues 10)

rate 0bit 0pps backlog 0b 0p requeues 10