Вопрос по tc

[Роман Погосян]

Немного не в тему. Но надеюсь простят.

Столкнулся с проблемой большого количества правил в iptables. Количество правил -j MARK.

Хотелось бы сделать по человечески через xtables только вот с tc никак не подружусь.

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

К примеру

если пихнуть х.х.х.2 и х.х.х.3 в фильтрами в класс с лимитом в 10 мбит, то при равной нагрузкой каждый получить около 5 мбит.

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

т.е.

Если класс с лимитом в 10 мбит то каждый айпишник который в этот класс попадед получал бы 10 мбит ?

[DemonidZe]

мне тоже интересно , ищу чем это можно реализовать но пока не нашел .  может кто знает варианты решения этой задачи ? с iptables щас впроди все нормально помог ipsec , а вот для tc аналога пока не нашел.

Відредаговано 25 лютого, 2013 DemonidZe

[DarkSpider]

Сам решения пока не нашел. Подсказал Kayot -  тыц.

Единственная проблема - только симметричные скорости входного/выходного канала.

Ну и еще одна проблема, актуальная для меня, - каждый IP шейпится в отдельности.

Если скрипт не пригодится - можете посмотреть логику его работы - надеюсь поможет.

У меня работает на ура.

[KaYot]

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

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

[dummy]

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

 

Это понятно, у меня так же. Но вопрос ставится: как реализовать управление скоростью абонентов не кучей правил -j MARK, а чем-то более изящным, типа ipset

Я присоединяюсь к теме - мне тоже очень интересен вопрос.

[DemonidZe]

Сам решения пока не нашел. Подсказал Kayot -  тыц.

Единственная проблема - только симметричные скорости входного/выходного канала.

Ну и еще одна проблема, актуальная для меня, - каждый IP шейпится в отдельности.

Если скрипт не пригодится - можете посмотреть логику его работы - надеюсь поможет.

У меня работает на ура.

вариант интересный только я не понял к чему там ipset , как я понял скрип просто берет значения из базы собирает все ип и скорость и генерирует правила для tc через u32

[DarkSpider]

Скрипт умеет работать и через iptables/ipset, так и через u32.

Я использую u32.

Все работает нормально.

Я использую шейпинг на входящую скорость, а на исход делаю полисинг (у меня НАТ).

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

[KaYot]

 

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

 

Это понятно, у меня так же. Но вопрос ставится: как реализовать управление скоростью абонентов не кучей правил -j MARK, а чем-то более изящным, типа ipset

Я присоединяюсь к теме - мне тоже очень интересен вопрос.

Дык не нужны там никакие марки и ipset'ы, задача сводится к созданию правильного batch-конфига для tc или использованию скрипта берущего данные из базы(sc).

[Роман Погосян]

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