Перейти к содержимому
Калькуляторы

lessless

Пользователи
  • Публикации

    10
  • Зарегистрирован

  • Посещение

Все публикации пользователя lessless


  1. Это у вас фактически полисиер вышел. Причем - без урезания траффика пропорционально скорости для rate<ceil при оверкоммите (если все дочерние классы захотели траффика больше, чем рейт родительского) - резаться будет всем поровну Т.е. при наличии к примеру 5 качков по 50 мбит и 3 качков по 30 мбит и внешнем канале в 200 мбит - скорость между качками распределится поровну и будет составлять по 25 мбит. Благодаря фиксированному quantum' у. По поводу r2q - для скоростей от 4 мбит он должен быть равен 300 - при этом минимально возможный quantum получается где-то на 3.6 мбит, максимальный - на 150 мбит. звучит безвыходно :(
  2. Идиотизм, это же можно сделать дефолтным правилом. Ибо никаких пакетов, кроме пакетов, предназначеных 172.15.1.2, там не будет. Ага! Меня задним умом эта мысль накрыла. Ребята, все оказалось действительно просто с iptables classify iptables -t mangle -A POSTROUTING -m set --match-set uaix src -j CLASSIFY --set-class 1:1 tc class r dev ppp0 parent 1: classid 1:1 htb rate 512kbit burst 5k и трафик с юа-икса идет потоком в 60Кбайт Всем спасибо за предложения, полезные советы и варианты - особенно NiTr0 за доходчивые объяснения, Lynx10 - за работающее предложение и Deathman за интересное предложение на будущее ;) Когда перейдем на L3 свичи буду так же резать на исходящем в сторону клиента интерфейсе, точно так же без ifb - как заворачивать на него трафик так и не разобрался.
  3. Давай попробуем, оно по-всякому интересно. NiTr0, эх, Вы разрушаете все мои идеи - я только подумал, что соответствие есть и цепочка для VPN выглядит так eth0|||||||\=========================\ppp0 prerouting|/===========FORWARD=======/POSTROUTING 1)пакет пришел на eth0 2)принято решение о маршрутизации на клиентский ip через ppp0 3)пакет доставлен на интерфейс ppp0 для дальнейшей отправки и это и есть POSTROUTING :( т.е. iptables -t mangle -A POSTROUTING -d 172.15.1.2 -j CLASSIFY --set-class при ppp0---------Клиентский-ПК 172.15.1.1---172.151.1.2 отправит пакет в класс 1:2 существующий на ppp0 эх, а такой идеальный вариант выходил.
  4. Спасибо, это то, что нужно! Прошу помочь еще с пониманием такого: при шейпинге на pppX я не могу использовать классификацию iptables -t mangle -A POSTROUTING ..., т.к. это таблица FORWARD, правильно ? Вместо этого могу использовать фильтры tc выделяя нужный мне трафик в отдельный класс и этим решаю свою задачу? Это ведь пара-тройка тысяч правил на каждый интерфейс или есть возможность устроить их в одном месте а-ля в ipset?
  5. Если вы имеете ввиду заворот траффика с pppX в ifb - иптейблс не поможет, т.к. траффик попадет в ifb до того как попадет в prerouting Если вы заворачиваете уже исходящий траффик с eth (после маршрутизации) - то я вообще не вижу смысла в ifb, с тем же успехом можете шейпить на eth В свое время думали подобным заморачиваться, оптимальным вариантом оказалось гнать украину и мир по разным вланам, и соответственно на эти вланы вешать шейперы - но потом идея отпала ввиду отказа от разделения "украина-мир". я набросал пару схем, что бы четче выразить мысль вариант1 вариант2 Исходящий шейпится на на pppX Входящий разруливается с eth0 (nat) или по 2м ifb или через один ifb, но по разным классам в одной дисциплине, так же, как это сделано на pppX. NiTr0, вы предлагаете шейпить входящий на eth0? Я к тому-же понял, что фильтры tc очень сложно (невозможно) удалять, - пока получается только с корневой дисциплиной :) Может быть вообще делать для каждого pppX свой ifb ?
  6. Очень интересная задумка буду следить за развитием событий и помогу чем смогу. Желаю Вам успеха надеюсь на вклад в сообщество в виде работающего решения ;)
  7. точно так же как и без ipset, только в этом случае для классификации вместо параметров netfilter используются классификаторы модуля set или гибридная классификация netfilter+ipset ;)
  8. Здравствуйте! Помогите разобраться с темой: мы начинающий провайдер, но хотим сделать тарифы с более высокой скоростью в пириниг, чем в мир. Например мир 1 мбит, UA-iX 5 мбит. Поскольку я раньше больше был системным администратором, чем сетевым то начал изучать материал с самого начала и пришел к схеме iptables+ifb как самой оптимальной по настройке и производительности: 1) весь входящий трафик из пиринга заворачивается на ifb0 средствами iproute2 2) на ifb0 весит множество классов каждый из которых соответствует одному абоненту. Условно такого вида: tc class 1:1 - 172.15.1.2 tc qdisc parent 1:1 handle 2: htb rate 1mbit burst 15k 1:2 - 172.15.1.3 tc qdisc parent 1:2 handle 3: htb rate 1mbit burst 15k 3)когда трафик попадает на ifb0 iptables классифицирует траффик по точкам отправления и назначения iptables -t mangle -A POSTROUTING -o ifb0 -m set uaix src -d 172.15.1.2 -j CLASSIFY --set-class 1:1 заворачивая его в необходимый класс на ifb0! пока я пробую и у меня не срабатывает фильтр заворачивающий на eth0 tc filter add dev eth0 parent 1: protocol ip u32 match ip src 217.20.163.94/32 action mirred egress redirect dev ifb0 подскажите, такая схема вообще не будет работать или у нее все-же есть какие-то шансы ? ))