[Nallien]

вкратце обрисую проблему. предположим имеем 200 мбит зарубежки, и 300 мбит национального канала. суммарно 500 мбит

 

шейпинг осуществляется на линукс-коробке, с помощью tc и маркировки пакетов.

 

к примеру существует глобальный класс на весь интерфейс - описывающий его локальною скорость в 800 мбит 1:0

у этого класса 1:0 есть два (упрощенно) дочерних класса - 1:200 и 1:300, первый - для зарубежного трафика, второй для национального.

 

в данный момент классы пользователей по умолчанию создаются как дочерние класса 1:200, затем проверяется попадание трафика в национальные префиксы сетей, если какой-то из адресов совпадает - на пакеты ставится метка, и они обрабатываются классом 1:300, если же не попадают - обрабатываются родительским 1:200

 

на примере - у пользователя скорость 2 мбита зарубежки и 10 мбит национального трафика. при коннекте ему создается свой собственный class, qdisc и filter, описывающий скорость в 2 мбита, и дополнительно проверяется - не является ли трафик национальным, если является - пакетам ставится метка, которую обрабатывает класс 1:300.

 

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

 

если свалить все в один класс 1:500 с ограничением в 500 мбит - не феншуй, может забиваться как зарубежка так и националка, приводя к потерям, задержкам и жалобам.

 

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

 

буду признателен за любую подсказку в верном направлении.

[vitalyb]

разделяйте тип трафика не "вверху", а "внизу". Т.е. 1:0 -> куча абонентов. Конкретный абонент с rate 10 имеет два подкласса, первый rate 2 ceil 2, второй rate 8 ceil 10.

[Nallien]

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

 

может я чего не понимаю - распишу как вижу.

 

если все абоненты будут иметь в парентах 1:0, как описать этот 1:0? логичным представляется как указываем локальной скорости - тобишь 800 мбит. но в таком случае если все кинуться качать с зарубежки, оч быстро забьют 200 мбит, так как шейпер буде считать что таем всего 800 мбит, тобишь еще 600 свободно. если 1:0 описать как 500 мбит (суммарная скорость) - будет точно так же. если описать как 200 мбит - не будет использоваться реальная пропускная способность канала.

 

а без правильного описания 1:0 - шейпер вообще не сможет нормально работать.... поправьте если не прав.

Изменено 27 октября, 2010 пользователем Nallien

[vitalyb]

что-то я ничего не понял. то 500, то 800 и почему всё утилизироваться не будет? Расскажите чего вы добиться хотите?

[Nallien]

500 - это суммарная полоса, тоесть 200 + 300, 800 - ну пусть 1000 - чтоб легче - это скорость локального шейпера\интерфеса.

 

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

 

и все было бы просто, если бы не было этих двух разных каналов в одном. тоесть мне нужно каким-то образом определять что есть национальный трафик, а что нет, и на основе этого выдавать 10 мбит клиенту. зачем? клиентов физиков много, скорость на этом тарифе не гарантирована никак, задача разделить имеющиеся 200+300 мбит максимально поровну, ну и конечно же динамически.

 

до этого были тарифы с фиксированной зарубежкой (4 и 8 мбита) и на них было до 100 мбит национального трафика. решалось просто - создавалось два класса - один на зарубежку со скоростью 200 мбит, второй на националку - 300 мбит.

 

вот для более легкого представления:

 

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

 

сейчас же нужно дать до 10 мбит и зарубежки и националки одновременно...

 

в случае если неправильно описать рутовый класс - будет бардак. но вот тут и проблема о которой и писалось выше.

Изменено 27 октября, 2010 пользователем Nallien

[Lynx10]

подход неправильный как по мне!

у нас реализировано так:

на брас где терминируются абоненты приходят по БГП префиксы Украины - метятся соответственным реалмом - для того чтобы их можна було отличить!

на юзера подымается класс который имеет общую скорость например 10мбит

от него 3 субкласса - мир, Украина, локалка

а потом фильтрами заганяем Украину в клас Украины, локалку в локалку - а всё остальное в мир!

всЁ!

 

[Nallien]

что подход неправильный сейчас - это конечно,потому тут и ищу ответ. пока он устраивал - он был правильным.

 

вы создаете один класс 10 мбит на юзверя, в него три дочерних по направлениям, а фильтры на эти дочерние класы по каким признакам вешаете? предположим что по реалмам (я так понимаю что-то типа tc filter add dev eth parent $uid:0 route to <realm>), но при этом все равно как решается вопрос распределения общей полосы между абонентами?

 

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

 

если не сложно - сбросьте простой пример, я какой-то ключевой фишки просто не вижу :(

[Lynx10]

что подход неправильный сейчас - это конечно,потому тут и ищу ответ. пока он устраивал - он был правильным.

 

вы создаете один класс 10 мбит на юзверя, в него три дочерних по направлениям, а фильтры на эти дочерние класы по каким признакам вешаете?

предположим что по реалмам (я так понимаю что-то типа tc filter add dev eth parent $uid:0 route to <realm>),

риалм - это Украина, по подсетям - их пару - это локалка, всё остальное - мир!

 

но при этом все равно как решается вопрос распределения общей полосы между абонентами?

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

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

 

но мы всем даём гарантированную полосу - и ни у кого ничего не отнимаем! Когда то страдали такой ерундой - но тогда мы решили это дело по другому - таких абонентом которые хотели чего то там негарнатированного и дешёвого - заганяли их в виртуальный ifb интерфейс (их было несколько - для разных тарифных планов) - который понятно был ограничен какойто полосой - которая подбиралась имперически и там навешивали на них всякие класы и всякое барахло а могли и ничего не навешивать - хто сумел выгрезть больше - то и его !

 

Почему ifb? да потому что ты их туда закрутил и они у тебя не путаются под ногами и не пересекаются с теми кому надо гарантированные полосы!

если не сложно - сбросьте простой пример, я какой-то ключевой фишки просто не вижу :(

Изменено 27 октября, 2010 пользователем Lynx10

[Nallien]

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

 

по прежнему ожидаю интересных мыслей. должно оно как-то просто решаться... а то пока только по дурацки выходит - вешать 2 мбита зарубежки + 8 националки, чтобы типа 10 получить, но и при таком раскладе - невозможно получить правильную балансировку, так как невозможно описать общий класс националки, а если быть точнее - невозможно дочерние классы пользователя заставить при этом быть дочерними классами глобального класса националки :(

 

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

Изменено 27 октября, 2010 пользователем Nallien

[nuclearcat]

Flow-classifier + DRR вешаете на каждый канал, которые и делят на каждого пользователя свою очередь

 

Будет эдакий монструозный SFQ (но с постоянным хешем по dst ip пользователя)

 

http://www.fredprod.com/cgi-bin/man/man2html?8+tc-drr

 

[Nallien]

Flow-classifier + DRR вешаете на каждый канал, которые и делят на каждого пользователя свою очередь

 

Будет эдакий монструозный SFQ (но с постоянным хешем по dst ip пользователя)

 

http://www.fredprod.com/cgi-bin/man/man2html?8+tc-drr

хм... пока еще полностью в ман не вник, но разве с ДРР не та же проблема? ведь не описав отдельно скорость по двум направлениям - шейпер же не будет правильно работать? он же не будет знать где потолок...

[photon]

По-моему, будет значительно проще все это дело реализовать на двух машинах: на первой делаем обычную нарезку полос с классификацией по IP пользователя (u32 hashing filters или flow), а на второй делаем классификацию и шейпинг по странам (с помощью модуля geoip для iptables).

Изменено 28 октября, 2010 пользователем photon

[nuclearcat]

Flow-classifier + DRR вешаете на каждый канал, которые и делят на каждого пользователя свою очередь

 

Будет эдакий монструозный SFQ (но с постоянным хешем по dst ip пользователя)

 

http://www.fredprod.com/cgi-bin/man/man2html?8+tc-drr

хм... пока еще полностью в ман не вник, но разве с ДРР не та же проблема? ведь не описав отдельно скорость по двум направлениям - шейпер же не будет правильно работать? он же не будет знать где потолок...

Родителем поставить HTB с предопределенной полосой

[photon]

Flow-classifier + DRR вешаете на каждый канал, которые и делят на каждого пользователя свою очередь

Родителем поставить HTB с предопределенной полосой

Ужас какой...

Изменено 28 октября, 2010 пользователем photon

[nuclearcat]

Flow-classifier + DRR вешаете на каждый канал, которые и делят на каждого пользователя свою очередь

Родителем поставить HTB с предопределенной полосой

Ужас какой...

Очень информативный пост.

В чем же ужас?

[photon]

Очень информативный пост.

В чем же ужас?

В некоторой нестандартности и сложности управления такими правилами, которой можно избежать, если разнести функции по разным машинам. Намного проще за обычным шейпером с классификацией по юзерским IP поставить дополнительную машину, которая шейпит в зависимости от географического положения. Абсолютно не важно, в каких пропорциях трафик будет распределяться между иностранными и российскими IP у каждого пользователя в отдельности, важно создать распределение 500 мбит на 200 и 300.

Изменено 28 октября, 2010 пользователем photon

[Nallien]

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

 

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

 

возможно есть еще варианты?

[vitalyb]

По идее можно полисингом - filter action police может иметь общий полисер на произвольное кол-во фильтров, пакет может попадать под несколько фильтров, полисится несколькими полисерами, в том числе резделяемыми. Даже на разных интерфейсах.

 

Развивая идею, по идее, кроме шейпинга по абонентам, можно полисить 200 и 300 мбит по типу трафика. Т.е. будет не один фильтр на абонента, а последовательно три (или один, но с тремя action) - полисим мир (на всех) drop/continue, полисим точку обмена (на всех) drop/continue, классифицируем трафик (индивидуально) flowid. Может проще тоже пойдет - 2 фильтра полисим, 3 - хештаблица как обычно, уже без разделения мир/точка обмена.

 

Приблизительно такие извращения...

[photon]

По идее можно полисингом - filter action police может иметь общий полисер на произвольное кол-во фильтров, пакет может попадать под несколько фильтров, полисится несколькими полисерами, в том числе резделяемыми. Даже на разных интерфейсах.

С полисингом есть проблема в том, что там нужно делать классификацию только средствами tc, т.к. входящий трафик сразу попадает в очередь ingress, и уже после этого идет на netfilter и далее. С помощью tc будет трудно отделить зарубежный трафик от российского, т.к. придется составлять списки подсетей вручную. С другой стороны, iptables можно непосредственно вызывать из filter policy. Может из этого что-то и получится.

Изменено 29 октября, 2010 пользователем photon

[vitalyb]

photon

Исходящий трафик тоже можно полисить. Но схема всеравно кривая, будет страдать "честность" деления доступной полосы. С двумя серверами (или если через ifb крутить?) с шейпингом красивей - даже можно попробовать разделить доступную полосу между абонентами честно - первым шейпером дается 10 одного и 10 другого, вторым - просто 10.