LINUX.ORG.RU
Форум — Admin  

Ethernet bridge + ToS


0

0
Обрисую упрощённую ситуацию: имеется бридж между eth1 и eth0, eth0 — внешний интерфейс, причём скорость на eth0 намного ниже, чем на eth1 (eth1 - 100 mbps, eth0 - 192-2048 kbps).

На самом устройстве генерируется трафик с ToS=0x10 (minimum delay), который идёт на eth0, а так же идёт транзитный трафик с eth1 на eth0.

Собственно описание проблемы: т.к. ширина канала на eth0 меньше, чем на eth1, то надо сперва пропускать трафик с ToS=0x10, причём даже в том случае, если простой трафик вообще встанет. Для трафика, генерируемого на устройстве, с этим проблем нет — он всегда уходит первый. Но в транзитном трафике тоже есть пакеты с ToS=0x10, и они обрабатываются с меньшим приоритетом, чем локально сгенерированные пакеты. Возможно, даже с тем же приоритетом, что и остальной транзитный трафик, для которого ToS не установлен.

Это криво настроенная конфигурация или особенность бриджа?

★★★★★
← UPS APC - вопросы
[LDAP] PostFix + Dovecot + LDAP man →
Бридж ничего кроме ethernet фреймов не видит, ToS -- заголовок IP. Ня?

Или между окончаниями бриджа поднимать маршрутизацию и разруливать QoS на L3, или CoS городить, если конечно бридж .1p поддерживает.
as33 ★☆☆
()
Ответ на: комментарий от as33
Смысл не в том, кто что видит. Есть интерфейс eth0, на который поступают как локально сгенерированные пакеты, так и пакеты, пришедшие из бриджа. Надо, чтобы они обрабатывались одинаково. Т.е. есть пакет1-0x10-локальный, пакет2-0x10-транзитный и пакет3-0x0-транзитный, надо, чтобы первыми ушли пакеты с 0x10. Сейчас же получается, что первым уходит только пакет1-0x10-локальный.

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

roy ★★★★★
() автор топика

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

dr-yay ★★
()
Ответ на: комментарий от roy
Если eth0 -- маршрутизируемый IP интерфейс, то делай на нем взвешенную очередь по ToS средствами TC, никаких проблем.
as33 ★☆☆
()
Ответ на: комментарий от as33
Может вы тогда подскажете, чем обусловлено различное прохождение локально-сгенерированных пакетов и пакетов, полученных из бриджа?
roy ★★★★★
() автор топика
Ответ на: комментарий от roy
Транзитные пакеты попадают сначала в очередь PreRouting и далее по цепочке, а локальный трафик сразу в Forward и соответственно в Output попадает раньше. Это если я правильно понимаю кухню, могу заблуждаться.
as33 ★☆☆
()
Ответ на: комментарий от as33
А что за взвешенная очередь? Посмотрел lartc.org, не вижу. Нашёл Weighted Round Robin, но по-моему это не то, да и документации по ней нет практически. Может попробовать PRIO использовать на eth0 интерфейсе?
roy ★★★★★
() автор топика
Ответ на: комментарий от as33
>Транзитные пакеты попадают сначала в очередь PreRouting и далее по цепочке, а локальный трафик сразу в Forward и соответственно в Output попадает раньше. Это если я правильно понимаю кухню, могу заблуждаться.

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

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

Как видно по рисунку, и локальные пакеты, и маршрутизируемые, и бриджевые должны на равных собираться в исходящей очереди. Если оно работает иначе — скорее всего это баг.
nnz ★★★★
()
Ответ на: комментарий от roy
Я ж говорю — на этой диаграмме показаны все варианты.

Тот путь, который идет строго в пределах link layer, и есть бриджевание. И там показано, что он сходится с потоком маршрутизации и они вместе вливаются в egress.
nnz ★★★★
()
Ответ на: комментарий от nnz
Точно. В первый раз не посмотрел ссылку, т.к. подумал, что там только netfilter. Извиняюсь, спасибо за линк.
roy ★★★★★
() автор топика
Ответ на: комментарий от roy
лять. ты в шейпере своем просто приоритетно обрабатывай пакеты с TOS NoDelay, остальные в общую очередь. Или ты не этого хочешь? тогда извини, я не понял значит, чего ты хочешь, я думал, чтоб пакеты с ноу делей проходили раньше остальных, даже в ущерб им.
val-amart ★★★★★
()
Ответ на: комментарий от val-amart
Ты правильно понял, чего я хочу. Понятно, что у одной задачи может быть несколько вариантов решения. Меня же прежде всего интересует, почему не работает текущая схема. Пока из этого обсуждения эта причина так и не найдена, а если её найти, то можно найти и оптимальное решение.

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

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

roy ★★★★★
() автор топика
Ответ на: комментарий от roy
а что, в линуксе нельзя в файрволле/шейпере просто включать нужный тос для маркированного трафика?
я просто опенбсдшник...
val-amart ★★★★★
()
Ответ на: комментарий от val-amart
Можно, но нужный ToS уже стоит... и даже правильно обрабатывается в одном случае...
roy ★★★★★
() автор топика
Обновление: если бриджа нет, т.е. пакеты с eth1 на eth0 приходят в режиме маршрутизации, то ToS обрабатывается нормально. Т.е. дело в том, каким образом пакеты поступают на устройство. Но в чём причина такого поведения пока непонятно.
roy ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← UPS APC - вопросы
Admin
[LDAP] PostFix + Dovecot + LDAP man →