[survivor]

Доброго дня!

 

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

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

На форуме есть много похожих обсуждений, но (почему я решил завести новую) они все сводятся к умным тарифам, где юзер ВНУТРИ своего канала получает прижим одного и лучший AL для другого сервиса. С этим все ясно, попробовал, работает. Но хочется другого. Как клиент использует свою полосу - его проблемы.

Хочется ГЛОБАЛЬНЫХ ограничений. Это позволит создать (не расширяя аплинка) комфортный интернет, где каждый может в ЧНН получить весь свой канал для критичного по времени доставки траффика (ютуб и соц сети) или если хватает в этот момент для аплинка - качать на ВСЕЙ скорости своего тарифа торренты, а если не хватает - ну и фиг с торрентом (из практики, у большинства 100500 файлов на закачке - когда что и скачается, то и посмотрим).

 

Тут я вижу две сложности (так как SCE не может делить траффик в процентном соотношении):

1) значит нужно менее важные сервисы прижимать в ЧНН. Но прижимать нужно не всегда, а в global controller'е я не нашел как привязать календарь. Для per-subscriber ограничений все понятно - для package'а привязываем календарь, для него же создаем time-based rule для которого нужному сервису даем нужный per-subscriber BWC. А как для global?

2) если две SCE? Траффик не обязательно точно равномерно поделится между ними, как в этом случае определить границу прижима? Допустим я хочу дать p2p только 100Мbps, это по 50 на SCE? А что если все торрент-качальщики окажутся на одной SCE? Им будет выделено не 100, а 50!

 

P.S.

То что я хочу похоже на Subscriberless mode, но там:

When the SCE is working in subscriberless mode, the bandwidth is fairly shared between the individual sessions but not between the subscribers.

А я не хочу чтобы один клиент душил другого, я хочу чтобы даже высокоприоритетный траффик равномерно делился между ними. А то, один кто смотрит ютуб HD, задушит несколько других, кто хотел просто ютуб. Если уж нет места на аплинке - пусть все смотрят SD :)

Изменено 23 января, 2013 пользователем survivor

[survivor]

Я пока вижу только одно решение проблем - на SCE только лишь красить траффик, а уже настроить QoS где-нибудь дальше в сети, в одной точке. Тут и acl'ы с time-range'ами помогут и priority можно поставить в процентах.

Но, хочется все на SCE сделать....

[survivor]

насчет календаря вопрос снимается, нашел :)

 

а как насчет второго вопроса? если две SCE - как ограничить сервис, если его использование между SCE может (и скорее всего будет) неравномерно?

Похоже никак. SCE друг про друга то не знают.

[snark]

насчет календаря вопрос снимается, нашел :)

Раз нашли, что за ширину GC отвечает только default календарь, значит найдете и то, как работает AL применительно к общей полосе ;)

[survivor]

значит найдете и то, как работает AL применительно к общей полосе

а подсказать - жаба душит? ;)

 

Кстати, "different rate-limit per time-frame" вчера ни хера не отработал. Но я сделал по другому: для default package'а сделал правило P2P - ему не ограничил скорость, но для него сделал дочернее правило T2, где привязал per-subscriber BWC у которого global controller с постоянным ограничением в 100 мегабит (на всех subscriber'ов). И в этом случае можно выбрать для BWC любой нужный мне календарь. Я как-то не правильно понимаю time-frame для global controller'ов?

 

Вы главный вопрос пропустили - как быть если несколько SCE? Ведь абоненты по ним не равномерно (по типу поглощаемого траффика) расположатся... Вот тут похоже решения нет.

[snark]

подсказать - жаба душит? ;)

Говорил же - легкие уже не те, ссылки давать ;)

Из того что что тут помню, а тут не помню:

AL работает внутри пакаджа, но когда начинается "перегруз", то AL начинает работать и внутри GC. Чтобы вызвать "перегруз" необходимо выставить на GC скорость заведомо меньшую, чем нагрузка на канал в ЧНН, т.е. если у Вас есть 1Гбит и по вечерам он загружен на 100% - поставьте скорость GC в 900 Мбит - это вызовет у SCE панику "а-а-а! скорость на максимуме - уже надо что-то решать!" и она начнет "душить" трафик с низким AL в пользу трафика с более высоким AL. AL - это то как быстро BWC получит CIR на основании AL, а раз AL высокий - надо пытаться обеспечить ему CIR даже рамках fair usage вызванных перегрузом.

 

 

"different rate-limit per time-frame" вчера ни хера не отработал

Календарь какой был? Если не default - попробуйте в нем указать время и этот же календарь указать в пакадже.

 

 

как быть если несколько SCE

На кошкиндом.ком все расписано же. Если щас сделать "summon Дятел", то он скажет то же самое ;)

И да, 2-х SCE и 76-го кота у мну нету (смайлик "печалька"), поэтому ни проверить ни чего-то точное сказать не смогу.

[survivor]

AL работает внутри пакаджа, но когда начинается "перегруз", то AL начинает работать и внутри GC

 

еще раз перечитал Using the Service Configuration Editor: Traffic Control Буду благодарен если покажете там это.

 

Календарь какой был

я все делал на дефолтном

 

На кошкиндом.ком все расписано же

лучше сразу б на гугл послали :)

КАК что-то сделать не прошу объяснять (почитаю мануалы) и собирать у себя на своем оборудовании никого не прошу (у вас же время не резиновое наверное), вопрос о том с какой стороны к проблеме зайти. Направление, так сказать, куда копать.

Каскадирование SCE может помочь? Или тупиковое направление?

 

summon Дятел

че-то я не догоняю :)

[snark]

В Traffic Processing Overview есть картинко:

 

 

illustrates the maximum available bandwidth (Admitted Information Rate [AIR]) ranges between the CIR and the PIR. The actual consumed bandwidth is always less than the AIR.

 

The BWC has a third parameter that controls how the AIR is determined at different congestion conditions. When the network is not congested the system allows the PIR and when the network is highly congested the system provides the CIR. In between these two extremes' date=' a third parameter—Assurance Level (AL)—determines the AIR. The AL controls how fast the AIR would decrease from the PIR to the CIR as congestion builds, or increase from the CIR to the PIR as congestion decreases. A higher AL ensures a higher AIR compared to a similar BWC with a lower AL.

 

The BWC ensures that even when the network is congested (PIR-congestion) at least the CIR is granted. Similarly, the BWC ensures that even when there is little traffic associated with a BWC the PIR is not exceeded.[/quote']

 

Congestion может быть, как в рамках Primary (Total) BWC (юзер выжирает свой канал на 146%), так и на GC (все юзеры выжирают канал на 146%).

[survivor]

Но в вашей цитате же не сказано, что при congestion'е на GC будут учитываться AL тех BWC которые привязаны к данному GC! Этого не сказано!

Вы это имеете ввиду: когда забивка, есть какие-то BWC, у которых выставлен данный GC, и у этих BWC разные AL. Одни BWC победят других для данного GC.

Хотелось бы это где-то в мануале прочитать. А то создается впечатление, что везде имеется ввиду congestion на Primary BWC.

Ту цитату, что вы привели я понимаю так: есть CIR, который дается всегда, есть PIR, до которого может вырасти траффик (абонента!), и есть AIR, который получает абонент, при congestion'е. Можно управлять какому траффику дать какой AIR установкой AL для BWC. Ну это все понятно, только это не отвечает на поставленную задачу ГЛОБАЛЬНОЙ приоритезации сервиса.

 

Вообще сильно не хватает AL между GC, при congestion'е на aggregate линке.

Изменено 24 января, 2013 пользователем survivor

[snark]

Я в общих словах сказал что и как (при этом это работает) и Ваше дело прислушаться ко мне или рыть доки в поисках доказательств ;)

[survivor]

snark спасибо, я вам верю :)

Вы точно уверены (из личной практики), что это так работает? Потому как я проводил эксперимент и он показал, что AL для BWC клали МПХ на congestion на GC. Если уверены, возможно я тогда ошибся и попробую еще раз.

 

или рыть доки в поисках доказательств

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

[snark]

У меня на GC как раз и выставлена скорость _меньше_ реальной скорости канала - это позволяет SCE определить что начался congestion и действовать.

Скорость, чтобы понять что нужно ставить, лучше смотреть на выходе из SCE а не на входе в нее. Почему так - ХЗ, но скорее всего это из за того что она понимает, что скорость на входе она контролировать не может (азы шейпинга, ага) и стремится гарантировать его на выходе.

[survivor]

Ok, загнал конфиг в SCE, жду результата :)

[survivor]

Хе-хе :))) работает :)

snark спасибо :)

 

может в первый раз не получилось, потому что я использовал sub-BWC от Primary BWC, а не extra-BWC как сейчас?

[snark]

Вот из личной переписки на этом форуме:

 

Чтобы CIR и AL начали нормально отрбатывать в GC - крайне желательно указать его скорость, т.е. если у тя канал 500 Мбит - напиши в GC 450 - это приведет к "перегрузу", когда трафик начнет приближаться к "потолку" и в SCE начнется тот самый congestion, который и будет стараться обеспечивать скорость (CIR) и приоритет (AL) не только для конкретного юзера - для этого есть BWC, а глобально, в рамках GC.

 

Короче ... Для GC:

Unlimited = я *** его знает сколько у тя мегабитов

ХХХ Мбит/с = ок, будем стараться держать сервис на уровне

Походу примерно как то так, IMHO.

Да, вчера видел как SCE во время Congestion зарезает P2P :)

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

Ну. Реально 1250 Мбит/с, я первый раз указывал 1200, не было эффекта. Указал 1150 - увидел. Прикольно, HTTP рванул - P2P резко упал. Послежу за этим эффектом.

Чуть выше я как раз об этом и писал ;)

 

 

может в первый раз не получилось, потому что я использовал sub-BWC от Primary BWC, а не extra-BWC как сейчас?

Монопенисуально sub BWC это или extra BWC - они только определяют полосу, которую сможет использовать юзер ;)

SCE все равно будет стремится обеспечить fair usage, вот только ей надо сказать когда у нее congestion начинается. Волне возможно, что она увидит network congestion, когда обе ее 2-шки будут забиты под завязку, а может и не увидит - ХЗ.

Изменено 24 января, 2013 пользователем snark

[Dushes]

http://it-sketch.blogspot.ru/2011/11/blog-post.html

[survivor]

Dushes

хорошо написано, жаль я пару месяцев назад на эту статью не попал :)

 

Кстати, тема глобального ограничения например P2P при использовании нескольких SCE так и осталась не раскрытой ;) что здесь на форуме, что в этой статье...

 

2) если две SCE? Траффик не обязательно точно равномерно поделится между ними, как в этом случае определить границу прижима? Допустим я хочу дать p2p только 100Мbps, это по 50 на SCE? А что если все торрент-качальщики окажутся на одной SCE? Им будет выделено не 100, а 50!

[joesm]

Какая проблема с несколькими SCE? Линки, на которых стоят SCE, объединяются в LAG. С каждой стороны LAG ставятся подходящие параметры балансировки.

[survivor]

LAG - это link aggregation?

[joesm]

он самый

[survivor]

Да, поднять etherchannel можно между двумя свичами (лайнкартами), в один свич (лайнкарту) пихаем все subscriber интерфейсы всех SCE, в другой свич (лайнкарту) пихаем internet порты. На одном свиче настраивам load-balancing src-ip на другом dst-ip. Один и тот же поток пройдет через одну и ту же SCE. Это все понятно. Как это поможет здесь:

 

2) если две SCE? Траффик не обязательно точно равномерно поделится между ними, как в этом случае определить границу прижима? Допустим я хочу дать p2p только 100Мbps, это по 50 на SCE? А что если все торрент-качальщики окажутся на одной SCE? Им будет выделено не 100, а 50!

[kapa]

Да, поднять etherchannel можно между двумя свичами (лайнкартами), в один свич (лайнкарту) пихаем все subscriber интерфейсы всех SCE, в другой свич (лайнкарту) пихаем internet порты. На одном свиче настраивам load-balancing src-ip на другом dst-ip. Один и тот же поток пройдет через одну и ту же SCE.

 

Это если у всех абонентов по одному IP. А если несколько?

[Spinaker]

Вообще сильно не хватает AL между GC, при congestion'е на aggregate линке.

aggregative-global-controller network-side 0 cir 110000 pir 440000 al 5 parent -1 name "AGG-UNLIM-NET"

aggregative-global-controller network-side 0 link 0 cir 50000 pir 200000 al 5

aggregative-global-controller network-side 0 link 1 cir 62500 pir 250000 al 5

aggregative-global-controller subscriber-side 0 cir 107500 pir 430000 al 5 parent -1 name "AGG-UNLIM-SUB"

aggregative-global-controller subscriber-side 0 link 0 cir 50000 pir 200000 al 5

aggregative-global-controller subscriber-side 0 link 1 cir 62500 pir 250000 al 5

 

параметр al - разве не для этого?

[Иванов Денис]

Чтобы CIR и AL начали нормально отрбатывать в GC - крайне желательно указать его скорость, т.е. если у тя канал 500 Мбит - напиши в GC 450 - это приведет к "перегрузу", когда трафик начнет приближаться к "потолку" и в SCE начнется тот самый congestion, который и будет стараться обеспечивать скорость (CIR) и приоритет (AL) не только для конкретного юзера - для этого есть BWC, а глобально, в рамках GC.

Коллеги, добрый вечер!

 

Решили попробовать установить SCE2020 на резервный гигабитный канал, чтобы "прижимать" на нём торрент на уровне GC.

Сначала попробовали "прижать" P2P на уровне Package'ей - работает. Но на уровне GC что-то не так. Видимо я что-то неправильно понял. :(

 

Установили GC PIR в 950 Мбит, добавили BWC для P2P service и связали их с единственными имеющимися package'ами: Default Package и Unknown Subscriber Package.

 

Решили протестировать:

Уменьшили все PIR'ы и CIR'ы, затем "завернули" часть трафика на используемый канал, чтобы спровоцировать congestion.

 

Как только нагрузка канала достигает значения GC PIR (95 Мбит), то SCE вообще перестаёт пропускать трафик. Как так? :)

[Иванов Денис]

Чтобы CIR и AL начали нормально отрбатывать в GC - крайне желательно указать его скорость, т.е. если у тя канал 500 Мбит - напиши в GC 450 - это приведет к "перегрузу", когда трафик начнет приближаться к "потолку" и в SCE начнется тот самый congestion, который и будет стараться обеспечивать скорость (CIR) и приоритет (AL) не только для конкретного юзера - для этого есть BWC, а глобально, в рамках GC.

Как только нагрузка канала достигает значения GC PIR (95 Мбит), то SCE вообще перестаёт пропускать трафик. Как так? :)

Прошу прощения! Перестаёт пропускать не весь трафик, а весь кроме трафика подписчиков с Default Package.

У подписчиков с Default Package даже торрент "прижимается". Но не понятно как именно: на уровне GC или на уровне Package'а. (в данный момент выясняю)