[Ivan Rostovikov]

>На ifb0 создано дерево...

А чем тогда ifb0 лучше физического "восходящего интерфейса" например eth0. Ведь наверняка весь нелокальный трафик поднимается в ядро через него. Там и строить деревья... Зачем ifb ?

 

>оставить tc ingress policy

Мне по особым причинам необходимо фильтровать по меткам iptables. А они ставятся уже после ingress.

 

>tc filter u32 hash

При удалении 1-го фильтра удаляются сразу все. Неподходит в случае с NAS.

 

 

[Max P]

да я про себя спрашивал :) у меня фильтры удаляются по одиночке и аккуратно, вот думаю ingress как то более аккуратнее сделать, дабы скорость более ровно шла

[voron]

2Max P

Для более ровной скорости ifb + нормальная qdisc.

[Max P]

понятно, значит таки придется раскурить эту связку :)

[Ivan Rostovikov]

>у меня фильтры удаляются по одиночке и аккуратно

Как Вы это делаете ? Можно пример ?

 

[azlozello]

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

Почему нельзя повлиять? Опция ecn в RED что тогда делает как не заставляет источник понизить скорость?

Может я не так понял? :)

 

Например есть трафик промаркированный DSCP в 3 разных класса + нулевой.

Как наиболее разумно пропустить через входящий интерфейс этот трафик в соответствии с метками и обрезать общий канал например до 500мбит?

С исходящим то всё понятно. Но непонятно как это сделать с входящим.

Изменено 23 октября, 2009 пользователем azlozello

[photon]

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

Почему нельзя повлиять? Опция ecn в RED что тогда делает как не заставляет источник понизить скорость?

Может я не так понял? :)

ECN -- это уведомление о перегрузке (переполнении приемного буфера). RED -- это дисциплина для предотвращения переполнения очереди, а не для шейпинга. Нельзя вносить задержки контролируемой величины не отправляя пакеты, почему это неочевидно?

 

Max P

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

[azlozello]

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

Почему нельзя повлиять? Опция ecn в RED что тогда делает как не заставляет источник понизить скорость?

Может я не так понял? :)

ECN -- это уведомление о перегрузке (переполнении приемного буфера). RED -- это дисциплина для предотвращения переполнения очереди, а не для шейпинга. Нельзя вносить задержки контролируемой величины не отправляя пакеты, почему это неочевидно?

Задача RED заключается в том, чтобы сообщить отправителю о возможности перегрузки, и отправитель должен адаптироваться к этой ситуации.

Маршрутизатор осуществляет пометку пакетов с помощью бита-флага СЕ. Отправитель должен реагировать на этот флаг так, как если бы произошла потеря пакета. Это и есть механизм ECN "Explicit Congestion Notification".

Но так как это не получило широкого распространения то и работает это далеко не во всех случаях.

Изменено 23 октября, 2009 пользователем azlozello

[nuclearcat]

ECN -- это уведомление о перегрузке (переполнении приемного буфера). RED -- это дисциплина для предотвращения переполнения очереди, а не для шейпинга. Нельзя вносить задержки контролируемой величины не отправляя пакеты, почему это неочевидно?

 

Max P

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

Траффик не копируется, используется ссылка на skb. Проверил по профайлеру - ifb даже не в первых 20 функциях по расходу "ресурсов".

[Max P]

>у меня фильтры удаляются по одиночке и аккуратно

Как Вы это делаете ? Можно пример ?

кусок из скрипта:

del() {
    $tc filter del dev ${DEV} parent 1:0 protocol ip prio 10 handle $handle:${LASTNUM_CLIENT_IP}:${ID} u32
    checkexit $? "Error delete tc filter ${ID}"
    $tc class del dev ${DEV} classid ${ID}
    checkexit $? "Error delete tc class ${ID}"
    $tc filter del dev ${DEV} parent ffff: protocol ip prio 50 handle 800::${ID} u32
    checkexit $? "Error delete ingress tc filter ${ID}"
}

вот как то так, а переменные вычисляются примерно так:

ALASTNUM_CLIENT_IP=$(echo $IP|awk -F "." '{print $4}')
LASTNUM_CLIENT_IP=$(echo "obase=16; ${ALASTNUM_CLIENT_IP}"|bc )

IID=$(($IID+6))
ID=$(echo "obase=16; ${IID}"|bc )

handle=$(echo $2|awk -F "." '{print $2}')
handle=$(echo "obase=16; $handle"|bc)

ID - просто идентификатор передающийся из биллинга, номер правила таксказать, дальше сами дофантазируете? )

[Max P]

Траффик не копируется, используется ссылка на skb. Проверил по профайлеру - ifb даже не в первых 20 функциях по расходу "ресурсов".

отлично, значит всё таки попробую на нём организовать нормальный аплоад юзерам

[azlozello]

>у меня фильтры удаляются по одиночке и аккуратно

Как Вы это делаете ? Можно пример ?

кусок из скрипта:

А не лучше ли до фантазировать с использованием хешей если вдруг клиентов много?

Изменено 24 октября, 2009 пользователем azlozello

[Max P]

вообще то там именно они и есть ;) смотрите внимательнее ;)

[azlozello]

del как бы не совпадает с логикой хешей :)

не лучше бы использовать change?

[photon]

Да, при использовании хэширования фильтры лучше не удалять, а менять на блокирующие:

tc filter change dev eth0 protocol all parent 1: prio 10 u32 ht $HT:$KEY: match ip src 172.16.0.1 police mtu 1 drop

tc filter change dev eth1 protocol all parent 1: prio 10 u32 ht $HT:$KEY: match ip dst 172.16.0.1 police mtu 1 drop

Изменено 24 октября, 2009 пользователем photon

[Max P]

всмысле не совпадает? а чего в этом особенного то?

[photon]

В данном случае ключи не пересчитываются, имеют фиксированный размер и задаются вручную на основе октетов IP-адреса. Поэтому от удаления или неудаления фильтров лучше действительно не станет. А вот блокировать юзеров с помощью хэширующих фильтров tc более выгодно. Если машина работает только как шейпер, то благодаря этому на ней можно не использовать iptables вообще, что весьма SMP-friendly.

[voron]

можно не использовать iptables вообще, что весьма SMP-friendly

Зачастую применяемая корневая qdisc HTB тоже не SMP-friendly, судя по http://vger.kernel.org/netconf2009_slides/...rouer_final.pdf

[Max P]

В данном случае ключи не пересчитываются, имеют фиксированный размер и задаются вручную на основе октетов IP-адреса. Поэтому от удаления или неудаления фильтров лучше действительно не станет. А вот блокировать юзеров с помощью хэширующих фильтров tc более выгодно. Если машина работает только как шейпер, то благодаря этому на ней можно не использовать iptables вообще, что весьма SMP-friendly.

у меня ключи не пересчитываются, задаются фиксированно, там кстати вложенные таблицы, 10.хх.уу., я просто не могу заранее сказать попадет айпи в этот класс или вообще не попадет в фильтры (сидит по трафику) и всё нормально работает

[morffej]

помогите настроить firewall на Ubiquiti NanoStation2

[photon]

Зачастую применяемая корневая qdisc HTB тоже не SMP-friendly, судя по http://vger.kernel.org/netconf2009_slides/...rouer_final.pdf

Ну это надо более детально проверять, там же только какой-то намек делается на то, что шейпинг портит масштабируемость. Не думаю, что c HTB совсем уж плохо, как в ALTQ.

Изменено 26 октября, 2009 пользователем photon

[heap]

Тема старовата, но я так понял решения адекватного не нашлось, если есть много префиксов, для которых нужно отмаркировать пакетики для парсинга на ifb? Не встречалось ли решения задействовать ipset в фильтрах iproute2?

[alex_001]

Тема старовата, но я так понял решения адекватного не нашлось, если есть много префиксов, для которых нужно отмаркировать пакетики для парсинга на ifb? Не встречалось ли решения задействовать ipset в фильтрах iproute2?

Доделываю патчик для ipset - позволяет приделывать tag к записи(аналог tablearg freebsd). Только под iphash на данный момент (другого мне не надо просто). Осталось сделать target'ы a'la SET_CLASSIFY , SET_MARK , как заработает - выложу патчик потестить.

[NiTr0]

Пока решений все еще нет?

[Supremum]

У меня решение есть...

Но не на IFB, а на IMQ

 

моя задача - ограничивать вх,исх,суммарную полосу для каждого IP идивидуально

всего - около 3000 IP.

Кроме этих - есть трафик, который не нужно тормозить.

 

если загонять все фильтры tc в одну линию, последовательно, то при мало-мальском трафике неслабый комп быстро тухнет...

 

разбиваю весь массив IP на N групп. (N подбирается по загрузке проца)

в N ipset-ах держу iphash-ы этих групп пользователей

в iptables-ах по -m set разбрасываю вх и исх пакеты по N IMQ устройствам, на которых уже нарисованы очереди и фильтры для соответствующего сета.

Все прекрасно работат. X9650 @ 3.00GHz тащит 500Мбит.

 

Одно расстраивает... IMQ, похоже, приказал долго жЫть...

 

PS. Он же делет и НАТ.

разброс пакетов с iptables идет в цепочке mangle:

PREROUTING -i lan+ для исходящего в интернет потока

POSTROUTING -o lan+ для входящего из интерент потока

 

интерфейсы с именами lan - внутренние, без НАТ, соответственно

интерфейсы wan - внешние, NAT

 

Изменено 17 февраля, 2011 пользователем Supremum