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

Способы шейпирования трафика RADIUS-атрибуты для Cisco и внешние скрипты под Linux и FreeBSD

Это сколько же надо туда напихать?! Вроде как у радиуса пакет до 4Кб.
Я уже на сотне префиксов обломался. А по интерфейсу оно фильтровать не умеет ;(
Сотня префиксов?! Не понял, каких именно префиксов и в каких случаях их может столько набежать?
Added ability to receive link action from AAA in auth reply. It allows AAA to select bundle/repeater configuration for specific user or session.

Added global traffic filters support to reduce auth reply size. 'set global filter ...' commands.

Да, действительно, работает. Только-что проверил на подопытной машинке, все тип-топ.
Думаю, плясать нужно от этого. Описывать разные темплейты бандлов с разными глобальными фильтрами, пользователя загонять в тот или иной темплейт в зависимости от тарифа.
Снова не догоняю.. Зачем нужна куча разных темплейтов?? Что мешает передавать радиусу "персональные" mpd-limit (в зависимости от тарифа)?
Added ability to include other local or remote config files. 'load ...' command able to accept configuration file path/URI as first argument.

А эта штука позволит фильтры хранить в одном месте и при необходимости их обновлять. Смущает только необходимость перезапуска mpd при изменении списка префиксов. Перечитывать конфиг он вроде до сих пор не научился. Поэтому я и предпочитаю работать с пайпами и таблицами в ipfw.

Тоже неплохая штука. Пока не требуется, проверять не стал. А вот заморачиваться с ipfw только из-за того, что мпд не умеет reload, совсем не хочу.

У вас чтО, фильтры меняются два раза в неделю? ИМХО, раз в полгода глубокой ночью провести "регламентные работы" с перезагрузкой мпд ну никак не повредит бизнесу..

Изменено пользователем AlKov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Думаю смысл понятен.

Вместо red можно юзать и htb например

RED -- это бесклассовая дисциплина для предотвращения переполнения очереди, она не обладает возможностями ограничения трафика согласно заданной полосе пропускания. Ее можно использовать только в качестве краевой (leaf qdisc). HTB -- это совершенно другое, это классовая дисциплина, позволяющая строить деревья из token bucket. Близкими ей по смыслу являются дисциплины CBQ и HFSC.
Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

RED -- это бесклассовая дисциплина для предотвращения переполнения очереди...

Очепятался. Имелось ввиду sfq

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сотня префиксов?! Не понял, каких именно префиксов и в каких случаях их может столько набежать?
Да даже вот например: http://www.krs-ix.ru/members

mpd-limit для всех этих сеток в радиусовский пакет не влезет

 

У вас чтО, фильтры меняются два раза в неделю? ИМХО, раз в полгода глубокой ночью провести "регламентные работы" с перезагрузкой мпд ну никак не повредит бизнесу..
Да, несколько раз в неделю могут меняться.

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Было бы толковое руководство с описанием хотя бы основных граблей

А что хотелось бы видеть в таком руководстве? Хотя бы приблизительно?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Было бы толковое руководство с описанием хотя бы основных граблей
А что хотелось бы видеть в таком руководстве? Хотя бы приблизительно?

Разжевывать досконально смысла нет - люди в основном более-менее грамотные. Что-то типа "ставится система

Для заточки под высокопроизводительный маршрутизатор надо изменить значения тут, тут и тут

бла-бла-бла"

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

Потому как (особенно в неродной системе) знание что и где надо сразу подкрутить и подлатать позволяет избежать многих часов деградации или отсутствия сервиса, что важно.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сотня префиксов?! Не понял, каких именно префиксов и в каких случаях их может столько набежать?
Да даже вот например: http://www.krs-ix.ru/members

mpd-limit для всех этих сеток в радиусовский пакет не влезет

Так у вас куча подсетей "сидит" на одном ng* интерфейсе? А что мешает "объединить" их той же маской (более "широкой", например)? Или каждой из подсетей необходим свой персональный лимит?
У вас чтО, фильтры меняются два раза в неделю? ИМХО, раз в полгода глубокой ночью провести "регламентные работы" с перезагрузкой мпд ну никак не повредит бизнесу..
Да, несколько раз в неделю могут меняться.

Ну тогда да.. Как вариант, до перезагрузки мпд можно рулить лимитами с помощью ngctl, но не уверен, подойдет ли это вам, да и фильтры вообще вряд ли возможно чем-либо изменить без рестарта..

У меня все проще - подсетей всего лишь 3 (более мелкие, например 172.16.0.0/16, 172.17.0.0/16 и т.д. в фильтре объединены маской /12), каждому юзеру свой ng* со своим одним персональным mpd-limit. Т.е. совсем не те масштабы и не те задачи..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Linux,

accel-pptpd либо pppoe (можно даже на одном и том же железе одновременно,

pppd, пропатченный для подсчета трафика по разным направлениям (http://abills.net.ua/wiki/doku.php?id=abills:docs:linux:lepppd:ru)

шейпинг через tc (htb, sfq)

Вопрос как в accel-pptpd понаправлениям считать )

Для меня задача сугубо теоретическая, но очень интересно.

Статью у Асмодея читал.

А при чем тут accel-pptpd? патч накладывается на pppd. точнее, на ядерный модуль ppp_generic. а чем туннелирование делается - не важно - хоть оригинальный pptpd, хоть accel. более того, у меня на этих же серверах запущен pppoe. и точно так же pppd, запущенный для pppoe-сессии считает трафик с разделением.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Linux

по 8к статических хешированных правил tc для всех возможных /19 айпи адресов в сети на каждый из 2-х интерфейсов (вход-исход)

~300м трафика

load average: 0.28, 0.62, 0.80

И не к чему плодить линейные правила.

Какие интересно показатели по прерываниям ?

 

Мои:

load average: 0.01, 0.01, 0.00

Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 74.8%id, 0.0%wa, 0.5%hi, 24.7%si, 0.0%st

 

tc class: 6345

bogomips: 6400.40 x 2 core

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2stmp: трафик не указываешь и характеристики машинки, azlozello тоже не пишет у него может вобще 1.5 ГГц пенек ;) Данные вобщем подтверждаю у меня при 3к хешированных правил и 100 Мбит трафика, згрузка на Intel Dual Core 6700 примерно такая же как у тебя, т.е. выше 0.01 редко поднимается, сервер только шейпит и фильтрует в режиме моста. Думаю еще ipt_netflow повесить, пусть считает, а то простаивает железо :)

 

Мне вот интересно, когда change/replace нормально заработает на всех командах, а то на некоторых спотыкается, а на некоторых тупо дублирует :( По крайней мере в CentOS. Может это надо iproute2 обновить?

Изменено пользователем SokolovS

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да даже вот например: http://www.krs-ix.ru/members

mpd-limit для всех этих сеток в радиусовский пакет не влезет

mpd-table и через ipfw

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

у меня в потолке было 850 сессий, трафика 57М, 20kpps. Шейп на ngcar, ос 6.4
Неплохо! У меня пока выше 300 сессий не поднималось. Шейп аналогичный (на ng_car), mpd 5.2, FreeBSD 6.3 (amd64)

Скармливаю радиусу такую конструкцию для mpd

mpd-filter +="1#1=nomatch dst net 172.16.0.0/12", 
mpd-filter +="1#2=nomatch dst net 192.33.48.0/23", 
mpd-filter +="2#1=nomatch src net 172.16.0.0/12", 
mpd-filter +="2#2=nomatch src net 192.33.48.0/23", 
mpd-limit +="in#1#Ext=flt1 shape 512000 96000 pass", 
mpd-limit +="in#2#Loc=all shape 384000 72000 pass", 
mpd-limit +="out#1#Ext=flt2 shape 512000 96000 pass", 
mpd-limit +="out#2#Loc=all rate-limit 4000000 750000 1500000 pass", 
mpd-input-acct +="Ext", 
mpd-output-acct +="Ext"

Фильтры только для того, чтобы mpd отдавал радиусу только "внешний" трафик.

Пока всё жужжит очень красиво, тьфу-тьфу-тьфу! :-)

А на линуксах подобные навороты для подсчета на РРРоЕ можно наколдовать?

http://abills.net.ua/wiki/doku.php/abills:...linux:lepppd:ru

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2stmp: трафик не указываешь и характеристики машинки, azlozello тоже не пишет у него может вобще 1.5 ГГц пенек ;) Данные вобщем подтверждаю у меня при 3к хешированных правил и 100 Мбит трафика, згрузка на Intel Dual Core 6700 примерно такая же как у тебя, т.е. выше 0.01 редко поднимается, сервер только шейпит и фильтрует в режиме моста. Думаю еще ipt_netflow повесить, пусть считает, а то простаивает железо :)

трафик ~200Мбит, производительность я указал,

схема таже bridge с шейпингом, ipt_netflow пробовал вешать загрузка увеличивается не значительно (~5-8% по si).

 

Больше интересует загрузка по прерываниям si, а не load average.

 

насчет правил с выбором по хеш таблицам:

 

azlozello пишет: tc filter add dev eth0 protocol ip parent 14: prio 8 u32 ht 2:a0: ht 3:00: match ip dst 10.0.0.0/32 flowid 14:1000

 

по моим експериментам, такой способ хеширования конечно дает выигрыш в сравнениях, но выбор ключа - все равно линейный поиск,

только хеш хешей дает 2 сравнения для 2 октетов IP адреса:

 

tc filter add dev eth0 protocol ip parent 14: prio 8 u32 ht $hh:$hl: match ip dst 10.0.$h.$l/32 flowid 14:$i

смысл думаю понятен,

но хеш таблиц в этом случае требуется: 1+256

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

хэш таблицы можно и простым скриптецом наколбасить, на основе октетов ip-адреса, так что особо сложного в делании хэш таблицы для хэш таблиц (прямо таки рекурсия какая то :)) нет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, скриптец в общем обычный, один раз загенерил и забыл.

Всё работает на change/replace и сбоев я не замечал.

 

2stmp лично у меня на машине крутится шейпер (16к правил), биллинг, sflow анализатор, DHCP, apache, mysql, bind и т.д. + ipset, потому load average несколько больше.

Машинка 2-х процессорная, но как мы знаем в процессорных прерываниях (для трафика) участвуют только 2 ядра (т.к. 2 сетевые).

Трафик порядка 300-400мб.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всё работает на change/replace и сбоев я не замечал.

А на каком ядре и какой системе?

У меня как и у sokolovS, на CentOS 5.3, change/replace просто дублирует правило вместо замены, причем оно то работает, но напрягает как то.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Причем на обычных правилах с u32 все вроде нормально, не дублирует при change/replace, но вот например на правилах ветвления отрабатывает так как пишет micros. Я даже где то про это уже писал и приводил правила на которых работает не правильно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, у меня, по-моему до добавления хэш-таблиц обычные u32 норм удалялись. после добавления оных - идет дублирование при replace

Интересно, в ядрах постарше есть такая проблема?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.