LINUX.ORG.RU
ФорумAdmin

Шейпинг входящего трафика и НАТ

 , ,


0

3

2ой день долблюсь головой о стену. За каждым углом коварно поджидают грабли. Решил спросить у умных людей.

Итак, дано. Есть шлюз на Debian Wheezy. У шлюза, кроме всего прочего, есть внешний интерфейс eth2 и 2 внутренних влана eth1.10 и eth1.20.

В eth2 приходит 30 мбит от провайдера. На eth1.10 и eth1.20 100мбит локалки, которые активно общаются друг с другом и ходят в интернет через нат на этом самом шлюзе.

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

Очевидное решение - попытаться мягко ограничить на шлюзе входящую полосу и надеяться, что это будет работать.

Есть ньюанс. Условно говоря, eth1.10 - для випов и мажоров. eth1.20 - для плебеев. Соответственно, нужно приоретизировать входящий трафик в зависимости от его пункта назначения в локальной сети.

Из ньюанса вытекает, что я не могу шейпить входящий трафик на eth2, потому что qdisc, насколько я понимаю, работает до попадания пакета в PREROUTING, в котором происходит nat. Соответственно, в этот момент я еще не знаю, куда предназначается трафик (плюс, насколько я понял, ingress qdisc умеет только полисить. Методом дропа. Так что смысл теряется).

Из ньюанса так же вытекает, что я не могу шейпить трафик, выходящий из eth1.10 и eth1.20, потому что qdisc локальный для интерфейса, и я не могу сопоставить приоритеты на разных интерфейсах.

Не совсем понимаю, как работает IFB (в том смысле, каким путем трафик этот самый IFB покидает, и где на диаграмме netflow он оказывается), но судя по всему, я мог бы связать eth1.10 и eth1.20 через IFB. Мог бы. Если бы не одно но. На IFB, насколько я понял, нет нетфильтра. И он не видит нетфильтровские метки MARK. Можно только делать u32 match. Но у u32 match нет реверс матча. А поскольку локалки eth1.10 и eth1.20 общаются между собой на всех 100 мегабитах, мне внутренний трафик шейпить совсем не хочется, и нужно исключить из шейпера определенный диапазон адресов.

Куда попадают пакеты, прошедшие через IFB? (например, на этой диаграмме http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg)

Как обрабатывать эти пакеты в iptables? (скажем, гипотетически, если я повешу ifb0 на eth2 ingress qdisc, то какой интерфейс нужно будет использовать для правил iptables, чтобы обрабатывать входящий на eth2 трафик? -i ifb0?)

Как разрулить проблему с 2мя внутренними интерфейсами (или натом)?


Провайдер регулирует полосу дропом пакетов.

Што?

Устранить источник проблемы и не городить огород не предлагать?

BOOBLIK ★★ ()

ИМХО, вам нужно на eth1.10 и eth1.20 навешать ″egress redirect dev ifb0″ и на ifb0 навешивать шейперы. А, чтобы локальный трафик не попадал на ifb0, создайте фильтры с src-ip адресом: iptables, маркировка пакетов, tc (ingress) = не выходит ничего (комментарий)

Но, дропы пакетов нормально дело, не должны от этого соединения разрываться, вот если провайдер химичит и генерит RST-пакет...

mky ★★★★★ ()
Ответ на: комментарий от mky

Т.е. tc filter завершает просмотр цепочки фильтров после первого успешного матча?

Спасибо, попробую.

Алсо. Провайдер, вроде, ничего не химичит. У него стоит, судя по всему, фряха, и полоса ограничивается очередью dummynet'а со стандартными настройками.

infine ()
Ответ на: комментарий от infine

Да, мы же определили полосу (flowid) значит завершает. Чтобы к пакету применялись другие фильтры, нужны какие-то другие команды, допустим ″link″.

Я не знаю, почему ваши пользователи жалуются на обрывы связи, но потери пакетов — это обычное дело и tcp это отрабатывает, у меня вон один офис подключен по 10 Мбит (длинный кабель), у провайдера сеть 1 Гбит, фактически, получается аппаратный полисер на 10 Мбит. Сотрудники, конечно, не особо довольны скоростью, но закачки не обрываются, icq не отваливается. От того, что вы настроите шейпинг хуже стать не должно, но не факт, что это решит проблему обрывов.

mky ★★★★★ ()

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

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

Короче не поможет тебе

anonymous ()
Ответ на: комментарий от mky

Ну когда я спросил у ясеня, где моя любимая провайдера, что за фигня у нас происходит, он вытащил из кармана тезис про 30мбит и «посмотрите у себя». Я хочу посмотреть у себя, и либо произойдет чудо, и всё заработает, либо я смогу его ткнуть носом в то, что мы не превышали, товарищ инспектор, вот запись с регистратора.

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

Ну теоретически, если я буду шейпить трафик на шлюзе с потолком ниже того, что дает провайдер, TCP congestion control сделает свое черное дело до того, как провайдер возьмется за дроп пакетов. В идеале. Плюс я смогу самостоятельно настраивать приоритеты пользователей/портов/буферы/латенси/бурсты/ecn, а не дергать провайдера каждые 5 минут.

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

Это хорошо и замечательно, но вот трафик прошел через ifb0. Где он оказывается? Ядро видит его как входящий трафик из ifb0, и этот трафик заново проходит через conntrack/netfilter/чеготамеще (что как-то маловероятно, потому что тогда получится петля, когда он заново доползет до интерфейса, на котором висит редирект на ifb0). Или он попадает туда, откуда был взят (т.е. в самое начало цепочки после ingress qdisc, но до попадания в conntrack/netfilter, если он повешан на ingress qdisc, или в самый конец после egress qdisc того интерфейса, с которого он был снят, если наоборот)?

infine ()
Ответ на: комментарий от infine

Он попадает туда, куда бы попал пакет если бы не было перенаправления на ifb. Если перенаправления в egress, то после ifb пакет попадат в очередь интерфейса (driver queue), если в ingress, то в bridge check. Netfilter не считает, что этот трафик проходил через ifb0.

mky ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.