jab Опубликовано 21 мая, 2010 · Жалоба 1) ipfw table $NEW add $IP; ipfw table $OLD delete $IP ; 2) бред Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey_Taurus Опубликовано 21 мая, 2010 · Жалоба 1) ipfw table $NEW add $IP; ipfw table $OLD delete $IP ;2) бред По первому понятно, что более элегантно юзеров перемещать, чем грохать и заполнять таблицы заново.По второму вопросу, может чего проглядел, но в примерах скрипты в кроне и в каждом скрипте есть конфигурация пайпов с номерами и параметрами из внешней БД. Из чего я понял (сорри, не силен я программировании) что пайпы грохаются и создаются периодически, по крону. И таким образом поддерживается динамическое количество и качетство пайпов в зависимости от состяния сетки тарифов и скоростей. Или я совсем не так понял код? Пайпы и их конфигурация статичны и меняется только размещение юзеров в таблицах которые решают куда какого юзера завернуть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 21 мая, 2010 · Жалоба Изучайте матчасть. Пайпы динамические и обрабатываются самим dummynet, Вы их раз создали при старте на все свои скорости и больше туда не лезете. Все операции с юзерами только по таблицам. Что там написали безумные скриптописатели, я не читал. "многабукав". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey_Taurus Опубликовано 21 мая, 2010 (изменено) · Жалоба Изучайте матчасть. Пайпы динамические и обрабатываются самим dummynet, Вы их раз создали при старте на все свои скорости и больше туда не лезете. Все операции с юзерами только по таблицам. Что там написали безумные скриптописатели, я не читал. "многабукав". Спасибо, значит мои первоначальные мысли насчет статичной конфигурации пайпов верны. Все манипуляции только с ipfw table, если меняется сетка тарифов - перегружается шейпер, тянет новые параметры из базы, создает (один раз при старте) новую конфигурацию пайпов и правил заворота в них трафика, заполняет ipfw tables и работает дальше. Во время работы меняется только содержимое ipfw tables. Спасибо за направление идеи. Изменено 21 мая, 2010 пользователем Sergey_Taurus Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 21 мая, 2010 · Жалоба Если меняется сетка тарифов - можно менять скорости на существующих трубах "на лету", это незаметно. И можно добавлять новые трубы тоже на лету, и прям сразу прибивать к ним таблицы. Ничего перезагружать не нужно. На случай перезагрузки у Вас должен быть скрипт в rc.d, который тянет из биллинга текущее состояние таблиц. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 21 мая, 2010 (изменено) · Жалоба если прямо очень необходимо делать pipe/queue flush (вместо смены "на лету"), то более правильно это будет сделать сначала удалив правила, направляющие пакеты в пайпы, а затем, лучше с небольшой задержкой, уже сами пайпы. Тогда пакеты, задерживаемые в пайпах не потеряются, только порядок прохождения будет нарушен - сначала к dstIP прилетят те, которые прошли на wirespeed, а следом задержанные в пайпах. Если же flush'ить пайпы, но правила, направляющие в них трафик оставлять на месте, то можно поиметь различные фееричные эффекты, попробуйте на столе )) Изменено 21 мая, 2010 пользователем umike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 21 мая, 2010 · Жалоба если прямо очень необходимо делать pipe/queue flush (вместо смены "на лету"), то более правильно это будет сделать сначала удалив правила, направляющие пакеты в пайпы, а затем, лучше с небольшой задержкой, уже сами пайпы. Тогда пакеты, задерживаемые в пайпах не потеряются, только порядок прохождения будет нарушен - сначала к dstIP прилетят те, которые прошли на wirespeed, а следом задержанные в пайпах.Если же flush'ить пайпы, но правила, направляющие в них трафик оставлять на месте, то можно поиметь различные фееричные эффекты, попробуйте на столе )) бред.не надо удалять правила, заворачивающие трафик в дамминет, попробуйте какнить вечерком на высоконагруженом шейпере. если уж надо удалить - добавить skipto для пропуска трафика минуя удаляемое правило, а потом удалить правило, скажем, через секунду, чтобы пакеты вышли. поддерживаю jab, смену конфигруации трубы на лету никто не замечает, ни роутер ни мониторинг ни абоненты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 21 мая, 2010 · Жалоба нет, почему, абненты замечают.. Скорость то меняется... ;) А так да. Проблем с вариантом 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 пока не пускал в продакшн. Изменение же самих пайпов, путем задания новых параметров (например при смене скорости в тарифе, к приеру суточной, типа ночью быстрее)противопоказаний не выявило. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 21 мая, 2010 · Жалоба В моём сценарии шейпинга обновление сделано так: - SQL-таблица содержит только IP-адреса и скорости, её заполняет костыль для биллинга, - костыль на шлюзе читает её и составляет список скоростей, - по списку скоростей создаются отсутствующие ipfw pipe, существующие не трогаются, - каждому pipe соответствует своя таблица, исходно пустая, - для каждого IP-адреса по скорости определяется номер таблицы, - таблицы из сценария синхронизируются в таблицы ipfw: добавляются новые IP, удаляются исчезнувшие. То есть на входе сценария должны быть только SQL-таблица, номер правила файрволла, базовые номера пайпов и таблиц (в общем, смотрите файл options). Сами правила, пайпы и таблицы сценарий создаст (если их нет) и будет обновлять (когда они есть) полностью автоматически. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 21 мая, 2010 · Жалоба А так да. Проблем с вариантом 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 Сценарий либо перенастраивает скорость у существующих, либо добавляет новые, если существующих не хватает (появилась новая скорость и т.д.) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey_Taurus Опубликовано 24 мая, 2010 (изменено) · Жалоба Всем привет. Начал ставить эту всю эту чудо-систему. Есть сервер 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) все работает нормально. На практике и реальном железе - как-то вот так... В чем может быть проблема? Заранее спасибо за ответы. Изменено 24 мая, 2010 пользователем Sergey_Taurus Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Slad Опубликовано 25 мая, 2010 · Жалоба allow ip from any to any mac-type 0x0806 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey_Taurus Опубликовано 25 мая, 2010 · Жалоба Все спасибо, вопрос снят :) Видимо, повышенная солнечная активность - сегодня все работает нормально :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 25 мая, 2010 (изменено) · Жалоба бред. не надо удалять правила, заворачивающие трафик в дамминет, попробуйте какнить вечерком на высоконагруженом шейпере. как категорично. В свою очередь предлагаю попробовать flush pipe/queue без предварительного удаления правил даже на шейпере с мизерной нагрузкой. ]если уж надо удалить - добавить skipto для пропуска трафика минуя удаляемое правило, а потом удалить правило, скажем, через секунду, чтобы пакеты вышли ну да, именно так. Мне почему-то показалось что рецепт со skipto уже кто-то привёл выше Изменено 25 мая, 2010 пользователем umike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey_Taurus Опубликовано 3 июля, 2010 · Жалоба Всем привет. Небольшой вопрос по теме. Установил у себя сие чудо. Работает нормально. При переброске юзера из одной трубы в другую (при смене тарифа, включении ночного режима и т.п.), старая труба висит параллельно с новой. Т.е. в системе остается старая динамическая труба, которая потом спустя неопределенный таймаут удаляется. Для целей мониторинга неудобно, графики рисуют несовсем реальную картину. Вопрос: чему равен дефолтный таймаут динамического pipe и где его можно подкрутить, чтобы при отсутствии трафика труба удалялась быстрее, не занимая ресурсов и не портя отчетность :) Заранее спасибо за ответы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 3 июля, 2010 · Жалоба Что за отчётность имеется в виду? Всё, что нужно, уже есть в SQL-таблице adaptive_shapers. Сценарий на шлюзе просто выталкивает её в ipfw table и ipfw pipe. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey_Taurus Опубликовано 3 июля, 2010 (изменено) · Жалоба Что за отчётность имеется в виду?Всё, что нужно, уже есть в SQL-таблице adaptive_shapers. Сценарий на шлюзе просто выталкивает её в ipfw table и ipfw pipe. У меня не используется Ваше решение. Отчестность - это сторонний скрипт который распарсивает вывод ipfw pipe show.Проблема в том что в выводе очень много "мертвых"пайпов, которые не отражают реальной картины. Если ли где-то параметр (например где-то в sysctl), который определяет таймаут после которого пайп, в который больше не поступает траффик, удаляется? Изменено 3 июля, 2010 пользователем Sergey_Taurus Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 7 июля, 2010 (изменено) · Жалоба Вот вам еще один вариант реализации подобного шейпер-генератора. На входе имеем 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 Вариант сильно упрощенный, для относительно небольшого количества шейперов. Изменено 7 июля, 2010 пользователем littlesavage Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...