А есть ли у кого "гибкие" решения для безлимитов?

Технические вопросы по UTM 5.0
Ответить
UserCP
Сообщения: 3
Зарегистрирован: Вс авг 23, 2009 06:02

А есть ли у кого "гибкие" решения для безлимитов?

Сообщение UserCP »

Всем Привет!

Имели неосторожность приобрести УТМ и сейчас ломаем голову, как быть... Ранее у нас стояла другая биллинговая система, где реализация шейпера скорости была по-настоящему динамической, а в УТМе нет такого.

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

Например, на тарифе Безлимитном 1Мбит когда загруженность канала слабая у абонентов полная скорость. Но вечером в часы пик, когда выходят много народу, то у безлимитов скорость трафика падает.

В утм подобной схемы нет и даже не предусмотрено. Может быть кто-нибудь придумал решение подобной проблемы? Поделитесь мыслями?


p.s. У нас раньше стояла другая биллинговая система - она позволяла делать динамический шейп по-настоящему динамическим. А именно:

одним из вариантов "борьбы" с безлимитами были следующие подходы:
- 1 - Групповая скорость шейпирования. То есть на группу тарифов можно было определить, например, 50 мегабит канал, а каждому из абонентов этой группы полагалось не более 512 кбит (например). Как только суммарно абоненты группы превосходили 50 мегабит, то каждому скорость урезалась до тех пор, чтобы суммарная скорость не превышала групповую - то есть 50 мбит.

- 2 - второе решение. Это подсчет "загруза" канала. А именно: если абонент в течение 15 минут скачивает 100% скорости трафика тарифного плана (это вычисляется по объему трафика), то ему скорость в следующие 20-30 минут режется на такое-то значение... После прохождения 20-30 мину скорость возращается обратно к 100% и так по кругу крутилось....


Но утм ни одной возможности не предусматривает к реализации. Может быть у кого-нибудь есть идеи, каким образом можно распределять безлимитные скорости? :?:

mikkey finn
Сообщения: 1612
Зарегистрирован: Пт ноя 10, 2006 15:23

Сообщение mikkey finn »

второе решается динашейпом.
первое - QoS или как его там...

UserCP
Сообщения: 3
Зарегистрирован: Вс авг 23, 2009 06:02

Сообщение UserCP »

mikkey finn писал(а):второе решается динашейпом.
первое - QoS или как его там...

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

Суть второго способа именно в том, чтобы задавать "объем трафика за период t-времени". Например, скаченный объем трафика 1 Гб за 1 час, это совершенно не то, что 1 Гб за месяц (расчетный период).


А QoS также не подходит, каким образом можно QoSом "нарезать трафик" в ситуации, когда как QoS оперирует от производительности внутренней сети (коммутаторов), которая 1 гигабит, а Интернет канала составляет только 120 мбит?
QoS будет приоритеризировать трафик исходя из возможностей коммутаторов (то есть 1 гбит), а не возможности магистрального интернет канала (120мбит).

AntonLemon
Сообщения: 55
Зарегистрирован: Вт авг 16, 2005 11:29

Сообщение AntonLemon »

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

Например у нас все реализовано на IPFW + TABLES + DUMMYNET

т.е. rfw закидывает пользователей (ипы) в определенные tables и уже файерволом мы нарезаем нужные скорости на группы пользователей.

Кроме того, ничего не мешает периодически генерить отчет по трафику пользователей и на основе него самых качальщиков загонять в дополнительные pipes. Естественно, все это происходит автоматически.

mikkey finn
Сообщения: 1612
Зарегистрирован: Пт ноя 10, 2006 15:23

Сообщение mikkey finn »

UserCP писал(а):
mikkey finn писал(а):второе решается динашейпом.
первое - QoS или как его там...

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

Суть второго способа именно в том, чтобы задавать "объем трафика за период t-времени". Например, скаченный объем трафика 1 Гб за 1 час, это совершенно не то, что 1 Гб за месяц (расчетный период).


А QoS также не подходит, каким образом можно QoSом "нарезать трафик" в ситуации, когда как QoS оперирует от производительности внутренней сети (коммутаторов), которая 1 гигабит, а Интернет канала составляет только 120 мбит?
QoS будет приоритеризировать трафик исходя из возможностей коммутаторов (то есть 1 гбит), а не возможности магистрального интернет канала (120мбит).
по поводу QoS - что мешает объяснить железке, что исходить надо из скорости 120 мбит?
По поводу дайнашейпа - ну сделайте расчетный период минимальным, только разгребать будете свои хитрые ограничения до полного посинения.

Postmaster
Сообщения: 24
Зарегистрирован: Чт авг 13, 2009 15:28

Re: А есть ли у кого "гибкие" решения для безлимит

Сообщение Postmaster »

UserCP писал(а):Всем Привет!

Имели неосторожность приобрести УТМ и сейчас ломаем голову, как быть... Ранее у нас стояла другая биллинговая система, где реализация шейпера скорости была по-настоящему динамической, а в УТМе нет такого.

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

Например, на тарифе Безлимитном 1Мбит когда загруженность канала слабая у абонентов полная скорость. Но вечером в часы пик, когда выходят много народу, то у безлимитов скорость трафика падает.

В утм подобной схемы нет и даже не предусмотрено. Может быть кто-нибудь придумал решение подобной проблемы? Поделитесь мыслями?


p.s. У нас раньше стояла другая биллинговая система - она позволяла делать динамический шейп по-настоящему динамическим. А именно:

одним из вариантов "борьбы" с безлимитами были следующие подходы:
- 1 - Групповая скорость шейпирования. То есть на группу тарифов можно было определить, например, 50 мегабит канал, а каждому из абонентов этой группы полагалось не более 512 кбит (например). Как только суммарно абоненты группы превосходили 50 мегабит, то каждому скорость урезалась до тех пор, чтобы суммарная скорость не превышала групповую - то есть 50 мбит.

- 2 - второе решение. Это подсчет "загруза" канала. А именно: если абонент в течение 15 минут скачивает 100% скорости трафика тарифного плана (это вычисляется по объему трафика), то ему скорость в следующие 20-30 минут режется на такое-то значение... После прохождения 20-30 мину скорость возращается обратно к 100% и так по кругу крутилось....


Но утм ни одной возможности не предусматривает к реализации. Может быть у кого-нибудь есть идеи, каким образом можно распределять безлимитные скорости? :?:
Коллега. а не Dyband-ли у вас был ? =)

UserCP
Сообщения: 3
Зарегистрирован: Вс авг 23, 2009 06:02

Re: А есть ли у кого "гибкие" решения для безлимит

Сообщение UserCP »

Postmaster писал(а):
UserCP писал(а):Всем Привет!

Имели неосторожность приобрести УТМ и сейчас ломаем голову, как быть... Ранее у нас стояла другая биллинговая система, где реализация шейпера скорости была по-настоящему динамической, а в УТМе нет такого.

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

Например, на тарифе Безлимитном 1Мбит когда загруженность канала слабая у абонентов полная скорость. Но вечером в часы пик, когда выходят много народу, то у безлимитов скорость трафика падает.

В утм подобной схемы нет и даже не предусмотрено. Может быть кто-нибудь придумал решение подобной проблемы? Поделитесь мыслями?


p.s. У нас раньше стояла другая биллинговая система - она позволяла делать динамический шейп по-настоящему динамическим. А именно:

одним из вариантов "борьбы" с безлимитами были следующие подходы:
- 1 - Групповая скорость шейпирования. То есть на группу тарифов можно было определить, например, 50 мегабит канал, а каждому из абонентов этой группы полагалось не более 512 кбит (например). Как только суммарно абоненты группы превосходили 50 мегабит, то каждому скорость урезалась до тех пор, чтобы суммарная скорость не превышала групповую - то есть 50 мбит.

- 2 - второе решение. Это подсчет "загруза" канала. А именно: если абонент в течение 15 минут скачивает 100% скорости трафика тарифного плана (это вычисляется по объему трафика), то ему скорость в следующие 20-30 минут режется на такое-то значение... После прохождения 20-30 мину скорость возращается обратно к 100% и так по кругу крутилось....


Но утм ни одной возможности не предусматривает к реализации. Может быть у кого-нибудь есть идеи, каким образом можно распределять безлимитные скорости? :?:
Коллега. а не Dyband-ли у вас был ? =)
У нас был Ideco Software биллинг. Они на софтварной платформе все и делали. Сейчас УТМ+Cisco... здесь и вопрос встал, ведь постоянно дисконнектить пппое подключения чтобы поменять скорость - совсем не айс...

Arti
Сообщения: 266
Зарегистрирован: Пн окт 01, 2007 02:44

Сообщение Arti »

Немного не в тему.... Просто интересно (сам я не член клуба любителей кошек), если циске при обновлении сесии скормить радиусом новые атрибуты с шейпом - что она с ними будет делать?

Oleg_121
Сообщения: 81
Зарегистрирован: Пн апр 14, 2008 21:09

Сообщение Oleg_121 »

К сожалению оба эти варианта не реализуемы на данном биллинге.
Для реализации динамического шейпирования по варианту 2- когда пользхователь начинает сидьно загружать канал скачкой и у него плавно падает скорость каждые 2 минуты- к модулю динамического шейпирования прикрутили самописный костыль. Каждые 2 минуты запускаем по крону нашу программу, она смотрит скоко выкачано за прошедшие 2 минуты юзером ( это делается правилом count в ipfw) , смотрим если (скорость/8*120)*0.3>значения count , то пользователь качает, скорость падает в два раза, если меньше то скорость не изменяется или если была уменьшина в 2 или более раз то возвращается обоатно к скорости начальной. Все сейчас сделанно для варианта 5-007 и FreeBSD на PERL. Раньше в форуме я описывал такую систему для 006.

Minime
Сообщения: 17
Зарегистрирован: Чт ноя 26, 2009 08:47

Сообщение Minime »

viewtopic.php?t=6580&highlight=

Может быть наведёт на какие то мысли. Там про реализацию на основе акцесс листов без дисконнектов...

Davion
Сообщения: 267
Зарегистрирован: Чт дек 01, 2005 13:36

Сообщение Davion »

ну или на микротике делать... там такие выкрутасы можно заворачивать...

Ответить