[Sergey_Taurus]

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

 

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

Как я понимаю, всякие безлимитные тарифы по нормальному делаются на самих 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хх каталистах, это то что я ищу? Какая железка (из кошек) на это способна и есть ли где примеры таких конфигураций - чтобы шейпер был не на брасе, а на граничном роутере. Софтовые решения пока что не рассматриваю.

 

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

[Andrei]

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

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

[D^2]

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

microflow (UBRL) есть на sup32, sup720, rsp720.

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

 

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

[Ilya Evseev]

Софтовые решения пока что не рассматриваю.

Софтовое решение - http://sources.homelink.ru/shaping/ :)

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

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

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

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

Edited May 18, 2010 by Ilya Evseev

[Sergey_Taurus]

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

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

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

 

[Sergey_Taurus]

Софтовые решения пока что не рассматриваю.

Софтовое решение - http://sources.homelink.ru/shaping/ :)

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

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

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

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

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

[Andrei]

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

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

[Sergey_Taurus]

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

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

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

Edited May 19, 2010 by Sergey_Taurus

[Giga-Byte]

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

 

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

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

 

 

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

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

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

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

[Lynx10]

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

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

[Andrei]

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

В 1м посте вы писали:

абоненты терминируются на сторонних брасах

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

[Giga-Byte]

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

В 1м посте вы писали:

абоненты терминируются на сторонних брасах

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

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

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

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

[Sergey_Taurus]

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

[Andrei]

мне нужно просто понять как на примерах это реализуется у "взрослых" провайдеров. Слышал что такое делают на 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 из соответствующих сеток будет выдаваться соответствующая полоса.

[s.lobanov]

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

[Giga-Byte]

Пока вижу только бюджетное решение в виде бриджа+шейпера на FreeBSD с обвязкой всего этого самописными скриптами для совместной работы с билингом. Для наших "детских" потоков (менее 100мбит внешки на настоящий момент) данное решение я думаю будет экономически оправдано и технически (на беглый взгляд) вполне реализуемо.

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

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

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

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

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

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

 

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

 

 

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

[Ivan Rostovikov]

и все таки, как называются Ваши брасы ? откройте тайну...

[mikevlz]

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

[jab]

 

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

 

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

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

[photon]

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

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

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

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

 

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

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

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

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

 

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

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

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

Edited May 20, 2010 by photon

[Giga-Byte]

jab, photon, кому как.

[jab]

 

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

[Sergey_Taurus]

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

[Sergey_Taurus]

мне нужно просто понять как на примерах это реализуется у "взрослых" провайдеров. Слышал что такое делают на 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 May 21, 2010 by Sergey_Taurus

[Andrei]

Допустим нужно:

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