tc shaper & vlan = багофича?

Что конкретно и как шейпится?

В соответствии с классами/дисциплинами на родительском устройстве.

Я правда пока не понял будет ли двойной шейпинг, если дисциплны есть и на vlan-интерфейсе и на родительском интерфейсе.

С одной стороны трафик vlan-а никаким местом не относится к «родительскому» интерфейсу.

ага, он всего лишь отправляется через него.

С одной стороны трафик vlan-а никаким местом не относится к «родительскому» интерфейсу.

false

То, что пакеты физически передаются через родительский интерфейс - это понятно.

Из двух логичных вариантов обработки трафика vlan-ов мы сейчас имеем наиболее хитрый вариант.

Судя по воплям о кривом шейпинге на vlan-интерфейсах времен ядер 2.6.Х, поведение этой багофичи похоже изменилось от бага к фиче.

post-factum Тестирование подтвердило двойной шейпинг!

Скорость ограничена по наименьшей скорости из двух шейперов и счетчики пакетов появляются во классах обоих устройств.

Интересная фича, логичная и которая судя по всему недокументированная.

Не просто логичная, а основательно логичная. Я даже удивляюсь, что кто-то в этом сомневается.

это было давно, но вдруг кому в поиске попадается. наступил на эти грабли. путем долгового наморщивания мозга и экспериментов понял, что так и должно быть, по логике работы и никакого доп. документирования поэтому не требует :-)

если на «корневом» интерфейсе настроен шейпер, то все пакеты идущие через этот интерфейс, попадут в этот «корневой» шейпер. нельзя в tc пустить пакеты «мимо шейпера». если мимо - то только шейперу в дефолтный класс. поскольку для «корневого» интерфейса все vlan - просто какие-то пакеты, (ну в заголовке езернета у них что-то лишнее написано - т.е. тег 802.1q) , то они тоже попадут в шейпер. если в фильтрах ничего про анализ езернет-заголовков не написано -пакеты в vlan попадут «корневому» шейперу в дефолтный класс. если описано - попадут в тот класс, в который отправит фильтр. практически у меня получилось, что если надо шейпить vlanы, то на «корневой» интерфейс шейпер вешать не надо.

угу. А как быть с native-vlan?

Я вижу 2 варианта.

1-й - тупой. Если на физическом интерфейсе несколько vlan, то использовать шейперы только на vlan, а на native не использовать. Так всё работает предсказуемо и понятно. Поскольку у меня сервер, с которого нуден шейпер, включен в мой же свитч, то такая конфигурация проблем не составляет (а тот vlan, который дальше должен выйти как native - просто уходит на порт свича, на котором switcpot access vlan XXX - вот от там и native).

2-й - честный, но возиться с ним не хочется... Логика должна быть такая: сколько vlan не разводи, а физический интерфейс всего один и общая скорость ограничена им. Разбиваем (в уме) эту скорость по разным vlan. Например: всего 100м, для native отводим 25, для vlan 10 - 25, для vlan 20 - 25, для vlan 30 - еще 25. Потом это разбиемние в уме превращаем в реальность. Для этого на native делаем шейпер с суммарной 100. В нем 3 класса для vlan с rate (и ceil) в каждом по 25м. И пишем фильтры, которые каждый vlan (по его тегу в заголовке езернет) положат в соотвествующий класс (вот тут у меня энтуазиазм пропадает, но в приципе делается). На логическом интерфейсе 3-го уровня для каждого vlan городим свой шейпер с макс. ограничением 25 и в него уже дочерние классы. Все 3 vlan займут вместе 75 - 25 останетися по native vlan, на котором тоже разводим классы и всё такое, но уже с учетом, что там будет макс. 25.

Теоретически, по моему, как-то так. Практически надо пробовать...