Jump to content
Калькуляторы

Посоветуйте идею и железку-шейпер

Здравствуйте, коллеги.

 

Для начала большая просьба с целью повышения образованности:

Как я понимаю, всякие безлимитные тарифы по нормальному делаются на самих BRASах путем присоединения полисиров\шейперов непосредственно к ppp-интерфейсам. Таким образом (совместно с RADIUS сервером) в зависимости от состояния счета абонента при его подключении ему на интерфейс можно выдать верхнюю скорость (или даже несколько "порогов" для разного типа трафика - внешнего\внутреннего) для безлимитных тарифов. Кто пользуется таким решением, пожалуйста откликнитесь в личку для обмена опытом или подскажите доки\статьи по которым можно получить хотя бы общее представление об идее. Конкретная реализация не требуется, мне нужно просто понять как на примерах это реализуется у "взрослых" провайдеров. Слышал что такое делают на 72хх, 76хх, ASR\ESR цисках и им подобных.

 

А теперь, собственно, сам вопрос:

Реальная задача у меня немного другая: абоненты терминируются на сторонних брасах (шейпить что-то на них нереально), есть теоретически возможность поставить дополнительный граничный маршрутизатор, который должен обеспечить примерно тоже самое что описано выше, но при условии что трафик проходит транзитом, ppp-соединений на нём не будет. Как я понимаю, тут нужен хитрый QoS. Мне нужно (в простом варианте) чтобы каждый хост при прохождении через данный маршрутизатор шейпилась до определенного верхнего уровня, допустим 512к, причем в индивидуальном порядке, допустим 192.168.0.100 получает свою "трубу" до 512к, 192.168.0.101 - свою и т.д., т.е. реализовать анлимы. Разумеется, конфигурация должна быть динамическая, чтобы можно было выгрузить список хостов, которые относятся к определенному тарифу - до 512к, до 1024к и т.п., идеально - в форме нескольких ACL по количеству типов анлим-тарифов. Создать статичный QoS не проблема, но прописывать туда тысячи классов (для каждого абонента свой) и потом их "на лету" менять... Чувствую, что пытаюсь изобрести велосипед... Коллеги, подскажите пожалуйста направление или откликнитесь в личку для пары-тройки наводящих вопросов-ответов. Где-то видел упоминание про microflow на 65хх каталистах, это то что я ищу? Какая железка (из кошек) на это способна и есть ли где примеры таких конфигураций - чтобы шейпер был не на брасе, а на граничном роутере. Софтовые решения пока что не рассматриваю.

 

Заранее большое спасибо за отклики.

Share this post


Link to post
Share on other sites

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

Терминируйте абонентов своим BRAS-ом и там же шейпите, выдавая через радиус атрибуты BRASу - самая прямая схема, имхо.

Share this post


Link to post
Share on other sites
Где-то видел упоминание про microflow на 65хх каталистах, это то что я ищу? Какая железка (из кошек) на это способна и есть ли где примеры таких конфигураций - чтобы шейпер был не на брасе, а на граничном роутере.
microflow (UBRL) есть на sup32, sup720, rsp720.

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

 

кроме этого есть еще "шейпящий бридж" - Cisco SCE2020. на этом форуме про него довольно много писали.

Share this post


Link to post
Share on other sites
Софтовые решения пока что не рассматриваю.
Софтовое решение - http://sources.homelink.ru/shaping/ :)

Пропускная способность - 240kpps и 1100mbps, cpu e7300 загружен на 55%.

Сетевые - встроенные, не Интел ;-)

Дополнительно считает netflow, ловит спамеров и держит ACL для клиентов.

За всё удовольствие от силы $800.

Edited by Ilya Evseev

Share this post


Link to post
Share on other sites
абоненты терминируются на сторонних брасах (шейпить что-то на них нереально), есть теоретически возможность поставить дополнительный граничный маршрутизатор
Терминируйте абонентов своим BRAS-ом и там же шейпите, выдавая через радиус атрибуты BRASу - самая прямая схема, имхо.

БРАСы ничего такого не умеют, поэтому нужно что-то "сбоку".

 

Share this post


Link to post
Share on other sites
Софтовые решения пока что не рассматриваю.
Софтовое решение - http://sources.homelink.ru/shaping/ :)

Пропускная способность - 240kpps и 1100mbps, cpu e7300 загружен на 55%.

Сетевые - встроенные, не Интел ;-)

Дополнительно считает netflow, ловит спамеров и держит ACL для клиентов.

За всё удовольствие от силы $800.

Спасибо, погляжу. Вполне возможно что буду рассматривать как временное (все мы знаем иронию этого слова :) ) решение до момента наступления лучших времен.

Share this post


Link to post
Share on other sites

БРАСы ничего такого не умеют, поэтому нужно что-то "сбоку".

Вот ведь блин... А как же у меня работает несколько лет? :)

Share this post


Link to post
Share on other sites
БРАСы ничего такого не умеют, поэтому нужно что-то "сбоку".
Вот ведь блин... А как же у меня работает несколько лет? :)

Еше раз, у меня стоят БРАСы которые поддерживают ограниченный набор RADIUS атрибутов. Функционала шейпирования динамически создаваемых pppoe интерфейсов, к сожалению, нет. Т.е. называть их БРАСами можно с большой натяжкой.
Edited by Sergey_Taurus

Share this post


Link to post
Share on other sites

В вашем случае, смотря какой трафик, поставил бы два бриджа на писюках между бордерами и брасами, завёл их в lacp или ещё какой протокол балансировки на l2 (в случае если умрёт один из писюков), потому что исходники Linux/FreeBSD открыты, немного знать Си и можно очень мощную и гибкую систему сворганить.

 

Конечно, придется это всё поддерживать...

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

 

 

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

схема то может быть и простой и прямой, но смотря на чем брас, сколько трафика

операция эта дорогостоящая а иногда и нестабильная.

Share this post


Link to post
Share on other sites

1 Сколько трафика ?

2 на чём брасы ?

Share this post


Link to post
Share on other sites
Еше раз, у меня стоят БРАСы которые поддерживают ограниченный набор RADIUS атрибутов. Функционала шейпирования динамически создаваемых pppoe интерфейсов, к сожалению, нет. Т.е. называть их БРАСами можно с большой натяжкой.
В 1м посте вы писали:
абоненты терминируются на сторонних брасах
из чего я понял, что брасы есть, но они не ваши. Потому и посоветовал поставить свои с поддержкой всех нужных вам радиус-атрибутов.

Share this post


Link to post
Share on other sites
Еше раз, у меня стоят БРАСы которые поддерживают ограниченный набор RADIUS атрибутов. Функционала шейпирования динамически создаваемых pppoe интерфейсов, к сожалению, нет. Т.е. называть их БРАСами можно с большой натяжкой.
В 1м посте вы писали:
абоненты терминируются на сторонних брасах
из чего я понял, что брасы есть, но они не ваши. Потому и посоветовал поставить свои с поддержкой всех нужных вам радиус-атрибутов.

это похоже вы не понимаете.

брасы купили, черт возьми, отдали за них деньги

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

Share this post


Link to post
Share on other sites

Ок, сорри за мб неточные формулировки. БРАСы наши, куплены давно, железяки, не циски, да и не брасы-то в нормальном понимании этого слова. Так, умеют более-менее терминировать PPPoE соединения, никаких "вкусностей" через радиус на них передать нельзя - не умеют они ничего такого. Максимум - нарезать статичные классы для QoS в виде дикого размера статичной конфой, которую менять автоматически просто нереально. Согласен, "дизайн" никакой и "БРАСы" тоже. Но тут вопрос "почему так" не сильно ко мне, надо как-то дальше ехать со всем этим, причем с безлимитками. Пока вижу только бюджетное решение в виде бриджа+шейпера на FreeBSD с обвязкой всего этого самописными скриптами для совместной работы с билингом. Для наших "детских" потоков (менее 100мбит внешки на настоящий момент) данное решение я думаю будет экономически оправдано и технически (на беглый взгляд) вполне реализуемо.

Share this post


Link to post
Share on other sites
мне нужно просто понять как на примерах это реализуется у "взрослых" провайдеров. Слышал что такое делают на 72хх, 76хх, ASR\ESR цисках и им подобных.
На цисках и делают. Из радиуса передают атрибуты для полосы, например так (для полосы 128К/128К):

Cisco-AVPair lcp:interface-config#1=rate-limit output 128000 24000 48000 conform-action transmit exceed-action drop
Cisco-AVPair lcp:interface-config#2=rate-limit input 128000 24000 48000 conform-action transmit exceed-action drop

 

при прохождении через данный маршрутизатор шейпилась до определенного верхнего уровня, допустим 512к, причем в индивидуальном порядке, допустим 192.168.0.100 получает свою "трубу" до 512к, 192.168.0.101 - свою и т.д.
Возможный вариант: для абонентов с полосой 512К выдавать адреса 192.168.0.ххх, для абонентов с полосой 1М выдавать адреса 192.168.1.ххх и т.д., а на машрутизаторе (или том же каталисте) создать 1 раз правила, по которым для каждого ip из соответствующих сеток будет выдаваться соответствующая полоса.

Share this post


Link to post
Share on other sites

На ваших скоростях действительно проще всё сделать софтово без непонятных железок со слабеньким функционалом

Share this post


Link to post
Share on other sites
Пока вижу только бюджетное решение в виде бриджа+шейпера на FreeBSD с обвязкой всего этого самописными скриптами для совместной работы с билингом. Для наших "детских" потоков (менее 100мбит внешки на настоящий момент) данное решение я думаю будет экономически оправдано и технически (на беглый взгляд) вполне реализуемо.
предлагаю делать сразу по уму - писать демоны управления скоростями, например на Си

это предоставит возможность:

-сразу опредлелить причину ошибки в коде - если будет, а не гадать почему скрипт не сработал

-правильно вести логи системы разных уровней логирования

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

-возможно при правильной построеной архитектуре демона даст +1 к ЧСВ, и уже при обращениях абонента на счет скорости либо её отсутсвия не проверять как сработали скрипты, т.е. доверять демону.

 

крон, перл и баш - фтопку.

 

 

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

Share this post


Link to post
Share on other sites

А вы поищите, он тут уже жаловался... Там то-ли телесины какие-то L3, то-ли еще чота такое...

Share this post


Link to post
Share on other sites

 

рапиры небось ?

 

предлагаю делать сразу по уму - писать демоны управления скоростями, например на Си

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

Share this post


Link to post
Share on other sites
предлагаю делать сразу по уму - писать демоны управления скоростями, например на Си

это предоставит возможность:

-сразу опредлелить причину ошибки в коде - если будет, а не гадать почему скрипт не сработал

Т.е. предлагается работать с ядром напрямую, минуя ipfw или tc? Фактически это равносильно их частичному переписыванию с радикальным упрощением парсера правил. Это займет очень много времени. Гораздо труднее найти ошибку в коде на C, т.к. язык довольно низкоуровневый и нужно управлять памятью руками.

 

-правильно вести логи системы разных уровней логирования
Вы так говорите, как будто динамические языки не имеют средств работы с syslog. Имеют:

http://perldoc.perl.org/Sys/Syslog.html

http://docs.python.org/library/syslog.html

 

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

-возможно при правильной построеной архитектуре демона даст +1 к ЧСВ, и уже при обращениях абонента на счет скорости либо её отсутсвия не проверять как сработали скрипты, т.е. доверять демону.

Ковыряние в 90 строках скрипта на перле предлагается заменить ковырянием в 9000 строках кода на C. И все это ради горстки юзеров. Проще всего сделать на FreeBSD с таблицами, как обычно все и поступают.
Edited by photon

Share this post


Link to post
Share on other sites

 

Сишный программер - один на миллион, перловый - один на 100к. Разница - порядок.

Share this post


Link to post
Share on other sites

Спасибо за советы, коллеги. БРАСы действительно телесины, AR770S. Вполне себе ничего работают за свои деньги - терминируют PPPoE юзеров до 1G half-duplex одна железка, только функционала в плане передачи Радиус атрибутов не имеют. Появились несколько вопросов по решению FreeBSD+ipfw+dummynet, продолжу в этой теме: http://forum.nag.ru/forum/index.php?showto...st&p=504571

Share this post


Link to post
Share on other sites
мне нужно просто понять как на примерах это реализуется у "взрослых" провайдеров. Слышал что такое делают на 72хх, 76хх, ASR\ESR цисках и им подобных.
На цисках и делают. Из радиуса передают атрибуты для полосы, например так (для полосы 128К/128К):

Cisco-AVPair lcp:interface-config#1=rate-limit output 128000 24000 48000 conform-action transmit exceed-action drop
Cisco-AVPair lcp:interface-config#2=rate-limit input 128000 24000 48000 conform-action transmit exceed-action drop

Спасибо за пример. С этим понятно, динамический pppoe\pptp интерфейс с верхними лимитами без деления трафика на свой\чужой. Я я вот не могу понять как DSLщики и прочие операторы реализуют деление на внешний и внутренный потоки, предоставляя допустим 512к\512к на внешку и 8м\8м на ресурсы в свойе сети и p2p обмен. Схема такая же, только на интерфей вешается не команды лимитов, а какоя-то QoS полиси в класах которой описаны 2 диапазона? Или как-то по-другому?

 

Возможный вариант: для абонентов с полосой 512К выдавать адреса 192.168.0.ххх, для абонентов с полосой 1М выдавать адреса 192.168.1.ххх и т.д., а на машрутизаторе (или том же каталисте) создать 1 раз правила, по которым для каждого ip из соответствующих сеток будет выдаваться соответствующая полоса.
Интересный вариант. Я так понимаю, это будет делаться средствами QoS. Как-то давно пробовал думатьь в этом направлении, но создать конфигурацию для выделения отдельной полосы каждому (а потом еще заворачивания всего этого в общую полосу) абоненту не смог. Не могли бы Вы в крадце подсказать направление (или примерный конфиг QoS) для такой задачи? Допустим нужно:

1) Абонентам из диапазона 10.1.0.0\16 выдать полосу 256к\256к

2) Абонентам из диапазона 10.1.0.0\16 выдать полосу 512к\512к

3) После чего, запихать всех в общую полосу (заранее известной емкости). Цель понятна - канал фиксированной емкости, сейлы хотят продать воздух и дать "до 256к" и "до 512к" только в хорошую погоду. При плохой погоде - равноценное распределение в пределах доступной емкости. Т.е. у каждого идивидуальный пайп с фиксированной верхней полкой, плюс все индивидуальные пайпы завернуты в один большой общий, тоже фиксированной ёмкости. На FreeBSD как такое реализовать я вижу. На циске (роутере) - к сожалению нет. Тут где-то говорили что вложенные динамические классы (на каждого юзера свой) есть только в 65хх каталистах с их microflow. Или я не вижу каких-то скрытых фич обычных циско роутеров?

 

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

Edited by Sergey_Taurus

Share this post


Link to post
Share on other sites
Допустим нужно:

1) Абонентам из диапазона 10.1.0.0\16 выдать полосу 256к\256к

2) Абонентам из диапазона 10.1.0.0\16 выдать полосу 512к\512к

3) После чего, запихать всех в общую полосу (заранее известной емкости).

У вас указаны одинаковые подсетки 10.1.0.0\16.

Если предположить, что

1) Абонентам из диапазона 10.1.1.0\24 выдать полосу 256к\256к

2) Абонентам из диапазона 10.1.2.0\24 выдать полосу 512к\512к

то 1 раз трудоемко создать конструкцию вида:

access-list 2001 permit ip any host 10.1.1.1
access-list 2002 permit ip any host 10.1.1.2
...
access-list 2254 permit ip any host 10.1.1.254

access-list 3001 permit ip any host 10.1.2.1
access-list 3002 permit ip any host 10.1.2.2
...
access-list 3254 permit ip any host 10.1.2.254

class-map match-all 2001
  match access-group 2001
class-map match-all 2002
  match access-group 2002
...
class-map match-all 2254
  match access-group 2254

class-map match-all 3001
  match access-group 3001
class-map match-all 3002
  match access-group 3002
...
class-map match-all 3254
  match access-group 3254
policy-map unlim
  class 2001
   police 256000 16000 24000 conform-action transmit  exceed-action drop
   ...
  class 2254
   police 256000 16000 24000 conform-action transmit  exceed-action drop
  class 3001
   police 512000 32000 48000 conform-action transmit  exceed-action drop
   ...
  class 3254
   police 512000 32000 48000 conform-action transmit  exceed-action drop

 

и потом навесить ее на соотв.интерейс в сторону клиентов, что-то типа вот этого:

interface Ethernet 0.0
service-policy output unlim

 

 

Я я вот не могу понять как DSLщики и прочие операторы реализуют деление на внешний и внутренный потоки, предоставляя допустим 512к\512к на внешку и 8м\8м на ресурсы в свойе сети и p2p обмен. Схема такая же, только на интерфей вешается не команды лимитов, а какоя-то QoS полиси в класах которой описаны 2 диапазона? Или как-то по-другому?
Видел на форуме такое решение, но сам его не пробовал:

 

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

В зависимости от тарифа выдается на логин радиусом avpair вида:

 

cisco-avpair=lcp:interface-config=rate-limit input access-group 2557 512000 32000 48000 conform-action transmit exceed-action drop

cisco-avpair=lcp:interface-config=rate-limit output access-group 2567 512000 32000 48000 conform-action transmit exceed-action drop

 

где 2557 и 2567 это списки доступа на cisco:

 

access-list 2557 deny ip any [сеть с серверами] wildcard

access-list 2557 permit ip any any

 

access-list 2567 deny ip [сеть с серверами] wildcard any

access-list 2567 permit ip any any

 

Эта конструкция дает полную скорость на сервера перечисленные в ([сеть с серверами] wildcard),

а остальной трафик режется согласно 512000 32000 48000

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this