Ethernet bridge + ToS

Бридж ничего кроме ethernet фреймов не видит, ToS -- заголовок IP. Ня?

Или между окончаниями бриджа поднимать маршрутизацию и разруливать QoS на L3, или CoS городить, если конечно бридж .1p поддерживает.

Смысл не в том, кто что видит. Есть интерфейс eth0, на который поступают как локально сгенерированные пакеты, так и пакеты, пришедшие из бриджа. Надо, чтобы они обрабатывались одинаково. Т.е. есть пакет1-0x10-локальный, пакет2-0x10-транзитный и пакет3-0x0-транзитный, надо, чтобы первыми ушли пакеты с 0x10. Сейчас же получается, что первым уходит только пакет1-0x10-локальный.

На счёт маршрутизации на окончаниях бриджа не понял. На счёт CoS думал, но с этим в линухе не всё так просто (http://www.linux.org.ru/view-message.jsp?msgid=3797799).

надобен роутер, иначе вопрос получается бредоват

Если eth0 -- маршрутизируемый IP интерфейс, то делай на нем взвешенную очередь по ToS средствами TC, никаких проблем.

Может вы тогда подскажете, чем обусловлено различное прохождение локально-сгенерированных пакетов и пакетов, полученных из бриджа?

Транзитные пакеты попадают сначала в очередь PreRouting и далее по цепочке, а локальный трафик сразу в Forward и соответственно в Output попадает раньше. Это если я правильно понимаю кухню, могу заблуждаться.

А что за взвешенная очередь? Посмотрел lartc.org, не вижу. Нашёл Weighted Round Robin, но по-моему это не то, да и документации по ней нет практически. Может попробовать PRIO использовать на eth0 интерфейсе?

>Транзитные пакеты попадают сначала в очередь PreRouting и далее по цепочке, а локальный трафик сразу в Forward и соответственно в Output попадает раньше. Это если я правильно понимаю кухню, могу заблуждаться.

Чтобы не сомневаться
http://jengelh.medozas.de/images/nf-packet-flow.png

Рисовал один из разработчиков iptables :)

Как видно по рисунку, и локальные пакеты, и маршрутизируемые, и бриджевые должны на равных собираться в исходящей очереди. Если оно работает иначе — скорее всего это баг.

Может быть дело в том, что у меня не маршрутизация, а бриджевание?

Я ж говорю — на этой диаграмме показаны все варианты.

Тот путь, который идет строго в пределах link layer, и есть бриджевание. И там показано, что он сходится с потоком маршрутизации и они вместе вливаются в egress.

Точно. В первый раз не посмотрел ссылку, т.к. подумал, что там только netfilter. Извиняюсь, спасибо за линк.

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

Можно, но он мне не нужен.

лять. ты в шейпере своем просто приоритетно обрабатывай пакеты с TOS NoDelay, остальные в общую очередь. Или ты не этого хочешь? тогда извини, я не понял значит, чего ты хочешь, я думал, чтоб пакеты с ноу делей проходили раньше остальных, даже в ущерб им.

Ты правильно понял, чего я хочу. Понятно, что у одной задачи может быть несколько вариантов решения. Меня же прежде всего интересует, почему не работает текущая схема. Пока из этого обсуждения эта причина так и не найдена, а если её найти, то можно найти и оптимальное решение.

Согласись, что просто установка ToS бита выглядит более заманчиво, чем включение шейпера? И ToS работает корректно в одном случае, но не работает в другом. Так зачем сразу от него так отказываться?

В любом случае спасибо за совет, его тоже буду пробовать, благо уже понедельник.

а что, в линуксе нельзя в файрволле/шейпере просто включать нужный тос для маркированного трафика?
я просто опенбсдшник...

Можно, но нужный ToS уже стоит... и даже правильно обрабатывается в одном случае...

Обновление: если бриджа нет, т.е. пакеты с eth1 на eth0 приходят в режиме маршрутизации, то ToS обрабатывается нормально. Т.е. дело в том, каким образом пакеты поступают на устройство. Но в чём причина такого поведения пока непонятно.