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

Шейпинг для FreeBSD+ipfw+Dummynet выкладываю утилиту для генерации правил из биллинга

 

1) ipfw table $NEW add $IP; ipfw table $OLD delete $IP ;

 

2) бред

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


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

1) ipfw table $NEW add $IP; ipfw table $OLD delete $IP ;

2) бред

По первому понятно, что более элегантно юзеров перемещать, чем грохать и заполнять таблицы заново.

По второму вопросу, может чего проглядел, но в примерах скрипты в кроне и в каждом скрипте есть конфигурация пайпов с номерами и параметрами из внешней БД. Из чего я понял (сорри, не силен я программировании) что пайпы грохаются и создаются периодически, по крону. И таким образом поддерживается динамическое количество и качетство пайпов в зависимости от состяния сетки тарифов и скоростей. Или я совсем не так понял код? Пайпы и их конфигурация статичны и меняется только размещение юзеров в таблицах которые решают куда какого юзера завернуть?

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


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

 

Изучайте матчасть. Пайпы динамические и обрабатываются самим dummynet, Вы их раз создали при старте на все свои скорости и больше туда не лезете. Все операции с юзерами только по таблицам. Что там написали безумные скриптописатели, я не читал. "многабукав".

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


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

Изучайте матчасть. Пайпы динамические и обрабатываются самим dummynet, Вы их раз создали при старте на все свои скорости и больше туда не лезете. Все операции с юзерами только по таблицам. Что там написали безумные скриптописатели, я не читал. "многабукав".

Спасибо, значит мои первоначальные мысли насчет статичной конфигурации пайпов верны. Все манипуляции только с ipfw table, если меняется сетка тарифов - перегружается шейпер, тянет новые параметры из базы, создает (один раз при старте) новую конфигурацию пайпов и правил заворота в них трафика, заполняет ipfw tables и работает дальше. Во время работы меняется только содержимое ipfw tables. Спасибо за направление идеи.

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

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


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

 

Если меняется сетка тарифов - можно менять скорости на существующих трубах "на лету", это незаметно. И можно добавлять новые трубы тоже на лету, и прям сразу прибивать к ним таблицы. Ничего перезагружать не нужно. На случай перезагрузки у Вас должен быть скрипт в rc.d, который тянет из биллинга текущее состояние таблиц.

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


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

если прямо очень необходимо делать pipe/queue flush (вместо смены "на лету"), то более правильно это будет сделать сначала удалив правила, направляющие пакеты в пайпы, а затем, лучше с небольшой задержкой, уже сами пайпы. Тогда пакеты, задерживаемые в пайпах не потеряются, только порядок прохождения будет нарушен - сначала к dstIP прилетят те, которые прошли на wirespeed, а следом задержанные в пайпах.

Если же flush'ить пайпы, но правила, направляющие в них трафик оставлять на месте, то можно поиметь различные фееричные эффекты, попробуйте на столе ))

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

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


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

если прямо очень необходимо делать pipe/queue flush (вместо смены "на лету"), то более правильно это будет сделать сначала удалив правила, направляющие пакеты в пайпы, а затем, лучше с небольшой задержкой, уже сами пайпы. Тогда пакеты, задерживаемые в пайпах не потеряются, только порядок прохождения будет нарушен - сначала к dstIP прилетят те, которые прошли на wirespeed, а следом задержанные в пайпах.

Если же flush'ить пайпы, но правила, направляющие в них трафик оставлять на месте, то можно поиметь различные фееричные эффекты, попробуйте на столе ))

бред.

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

если уж надо удалить - добавить skipto для пропуска трафика минуя удаляемое правило, а потом удалить правило, скажем, через секунду, чтобы пакеты вышли.

 

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

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


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

нет, почему, абненты замечают.. Скорость то меняется... ;)

 

А так да. Проблем с вариантом ipfw table 1 delete 1.1.1.1 ; ipfw table 1 add 1.1.1.1 22 (у меня tablearg (потому таблица одна и сначала удаляем старое, потом новое пишем) есть только то, что иногда появляется

 

http://www.freebsd.org/cgi/query-pr.cgi?pr=127209

http://www.freebsd.org/cgi/query-pr.cgi?pr=143474

http://www.freebsd.org/cgi/query-pr.cgi?pr=144269

 

Это на 7 ветке. на 6 не замечено. 8 пока не пускал в продакшн.

 

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

 

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


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

В моём сценарии шейпинга обновление сделано так:

- SQL-таблица содержит только IP-адреса и скорости, её заполняет костыль для биллинга,

- костыль на шлюзе читает её и составляет список скоростей,

- по списку скоростей создаются отсутствующие ipfw pipe, существующие не трогаются,

- каждому pipe соответствует своя таблица, исходно пустая,

- для каждого IP-адреса по скорости определяется номер таблицы,

- таблицы из сценария синхронизируются в таблицы ipfw: добавляются новые IP, удаляются исчезнувшие.

 

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

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


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

А так да. Проблем с вариантом ipfw table 1 delete 1.1.1.1 ; ipfw table 1 add 1.1.1.1 22 (у меня tablearg (потому таблица одна и сначала удаляем старое, потом новое пишем) есть только то, что иногда появляется
У меня в сценарии ipfw table flush не используется, таблица синхронизируется поэлементно.

См. ipfw_table_sync в functions.pm.

 

Изменение же самих пайпов, путем задания новых параметров (например при смене скорости в тарифе, к приеру суточной, типа ночью быстрее)противопоказаний не выявило.
Главное не удалять pipe-правила на лету, иначе при больших нагрузках будет kernel trap:

http://freebsd.rambler.ru/bsdmail/freebsd-...7/msg01566.html

Сценарий либо перенастраивает скорость у существующих,

либо добавляет новые, если существующих не хватает (появилась новая скорость и т.д.)

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


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

Всем привет.

 

Начал ставить эту всю эту чудо-систему. Есть сервер HP DL320 с набортными карточками BCM5713.

 

Создаю бридж следующим скриптом (синтаксис - по хэндбуку):

 

ifconfig bridge0 create

sleep 2 # Иначе следующая команда не может повесить айпишник на бридж-интерфейс который поднимается секунду-две

ifconfig bridge0 inet 192.168.0.55/24

ifconfig bridge0 addm bge0 addm bge1 up

ifconfig bge0 up

ifconfig bge1 up

 

В итоге, бридж создается, айпишник навешивается. Пакеты сквозь сервер ходят, сам сервер не пингуется и не отзывается по SSH до тех пор, пока с самого сервера что-то не пропинговать. Далее, отзывается со стороны одного интерфейса (bge1 например), но может не отзываться со второго (например bge0), далее - вариации с точностью до наоборот.

 

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

У всех так или я просто не умею готовить бриджи? :) Поставить третью карточку может быть и выход, но есть спортивный интерес (в хэндбуке как раз рекомендовано вешать адрес на бридж-интерфейс), и карточку ставить некуда - слоты все заняты. Делать из сервера роутер вместо бриджа тоже хочется в последнюю очередь.

 

В виртуальной среде (VMWare 6.2) все работает нормально. На практике и реальном железе - как-то вот так... В чем может быть проблема?

 

Заранее спасибо за ответы.

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

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


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

Все спасибо, вопрос снят :) Видимо, повышенная солнечная активность - сегодня все работает нормально :)

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


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

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

 

]если уж надо удалить - добавить skipto для пропуска трафика минуя удаляемое правило, а потом удалить правило, скажем, через секунду, чтобы пакеты вышли
ну да, именно так. Мне почему-то показалось что рецепт со skipto уже кто-то привёл выше
Изменено пользователем umike

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


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

Всем привет.

 

Небольшой вопрос по теме. Установил у себя сие чудо. Работает нормально. При переброске юзера из одной трубы в другую (при смене тарифа, включении ночного режима и т.п.), старая труба висит параллельно с новой. Т.е. в системе остается старая динамическая труба, которая потом спустя неопределенный таймаут удаляется. Для целей мониторинга неудобно, графики рисуют несовсем реальную картину.

 

Вопрос: чему равен дефолтный таймаут динамического pipe и где его можно подкрутить, чтобы при отсутствии трафика труба удалялась быстрее, не занимая ресурсов и не портя отчетность :)

 

Заранее спасибо за ответы.

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


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

Что за отчётность имеется в виду?

Всё, что нужно, уже есть в SQL-таблице adaptive_shapers.

Сценарий на шлюзе просто выталкивает её в ipfw table и ipfw pipe.

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


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

Что за отчётность имеется в виду?

Всё, что нужно, уже есть в SQL-таблице adaptive_shapers.

Сценарий на шлюзе просто выталкивает её в ipfw table и ipfw pipe.

У меня не используется Ваше решение. Отчестность - это сторонний скрипт который распарсивает вывод ipfw pipe show.

Проблема в том что в выводе очень много "мертвых"пайпов, которые не отражают реальной картины.

Если ли где-то параметр (например где-то в sysctl), который определяет таймаут после которого пайп, в который больше не поступает траффик, удаляется?

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

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


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

Вот вам еще один вариант реализации подобного шейпер-генератора.

 

На входе имеем 2 правила в ipfw:

 

pipe tablearg ip from any to table($table_in) in via $ext_iface
pipe tablearg ip from table($table_out) to any out via $ext_iface

 

Текстовый файл с описанием шейперов:

 

192.168.0.2/32  1000
192.168.0.3/32  1000
192.168.0.4/32  2000 shaper0
192.168.0.5/32  2000 shaper0

 

И скрипт, синхронизирующий состояние IPFW с конфигом: sync_shapers.pl.

Без flush'а, и вносящий только изменения в конфиге, по возможности не затрагивая остальные шейперы.

 

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

 

Конфиг время от времени генирируется на биллинге и заливается на сервер.

Состоит из 3 столбцов: ip speed [shaper_name].

Третий столбец - имя шейпера. Для группы IP адресов с одним именем создается отдельный шейпер.

 

Так, для данного примера будут созданы шейперы:

 

pipe 1000 config bw 1000Kbit/s mask dst-ip 0xffffffff
pipe 1001 config bw 1000Kbit/s mask src-ip 0xffffffff
pipe 1002 config bw 2000Kbit/s
pipe 1003 config bw 2000Kbit/s

 

А в таблицах будут IP адреса:

table_in:
192.168.0.2/32 1000
192.168.0.3/32 1000
192.168.0.4/32 1002
192.168.0.5/32 1002
table_out:
192.168.0.2/32 1001
192.168.0.3/32 1001
192.168.0.4/32 1003
192.168.0.5/32 1003

 

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

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

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


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

Join the conversation

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

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

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

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

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

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

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