[kapa]

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

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

как одно мешает другому?

 

 

Аппаратный BSR это не это только управление локальными или интернет сервисами, это еще и мощный QoS для различных групп тарифов и абонентов, это еще и отказ от обсчета трафика по столь любимому пионернетами netflow, а к переходу к модели через raduis accounting, это в конце концов снижение стоимости обслуживания/владения,в отличии от армии писюков в кол-ве 4-10штук.

Чем этот QoS лучше того, что я могу сделать на ipfw и тех же 3627, 3028?

И чем для абонента radius accounting лучше netflow?

Изменено 14 мая, 2010 пользователем kapa

[jab]

Чем этот QoS лучше того, что я могу сделать на ipfw и тех же 3627, 3028?

И чем для абонента radius accounting лучше netflow?

Тем, что не дадут детализацию, а пошлют в СОРМ. Меньше знаешь - крепче спишь. :-)

[shicoy]

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

1) Netflow это не подсчет трафика, а статистика и анализ. Radius Accouting специально создавался для именно таких целей. При больших объемах Netflow тупо не эффективен.

 

2) Я не знаю что вы можете сделать на ipfw, мне это не интересно, мы не обсуждаем тут возможности ядра/BSR. Могу только заметить, что используя нормальное железо у вас/нас появляется возможность рулить сервисами и т.п. через связку Billing-Radius-BSR, т.е. некая унифицированная схема.

 

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

Изменено 14 мая, 2010 пользователем shicoy

[shicoy]

Напомню цель дискусии:

1) Выдать абонентам диначический белый IP в схеме IPoE

2) Использовать максимально эффективно выданый пул белых IP

3) Решить вопрос с предоставлением абоненту услуг IPTV и экономии магистрального канала до абонента

 

[Rivia]

А мог бы кто пояснить с чего вдруг тут упоминавшийся отказ от NAT вызовет рост трафика на аплинках в том плане, что я не понимаю где здесь собственно NAT, если доступ в интернет по vpn с выдачей паблика сразу на интерфейс пользователю?

[Lynx10]

Меня пока больше волнует какой вариант выбрать:

1) Большие плоские сегменты на 4к абонентов в каждом с включением Private Vlan (Traffic Segmentation) и выдачей реальных IP

2) Схема vlan-per-user с терминированием клиентских вланов на BSR и доп. затратами на магистральные каналы до узлов агрегации

3) Либо оставить как есть, а способом отказа от тунелей будет создание One-to-One NAT (IP real = IP local) в момент события IP detection или DHCPreq.

первое дешевле второе дороже - но выглядит очень хорошо, третье - как-то вообще никак!

 

jab, откуда сейчас отдаёшь мультикаст?

видел у некоторых провайдеров с пппое стоят прокси которые превращают мультик в юникаст по http.

костыль бесподобный.

У меня сейчас unicast. На IPoE Малтикаст буду гнать со стримера прям в ядро в ISM VLAN бриджом сквозь рутера и агрегацию до access. Никакого multicast routing и прочих PIM-SM/PIM-DM, голый L2 + IGMP Snooping.

а что стримите и что в качестве стримера ?

Изменено 14 мая, 2010 пользователем Lynx10

[Lynx10]

здесь ещё получается запас по внутренней полосе(между пользователями), ведь весь трафик идёт через центр(брас), сколько там внешней полосы мало колебёт :)

зачем гонять локалку через брас, когда она отлично может бегать между теми же 3627 по 10Гбит?

потому что так получается неконтролируемый трафик - а всё что неконтролируемое и в придачу нахаляву - есть нехорошо

[kapa]

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

1) Netflow это не подсчет трафика, а статистика и анализ. Radius Accouting специально создавался для именно таких целей. При больших объемах Netflow тупо не эффективен.

Я так и не увидел пока чем netflow "тупо не эффективен".

 

2) Я не знаю что вы можете сделать на ipfw, мне это не интересно, мы не обсуждаем тут возможности ядра/BSR. Могу только заметить, что используя нормальное железо у вас/нас появляется возможность рулить сервисами и т.п. через связку Billing-Radius-BSR, т.е. некая унифицированная схема.

"рулить сервисами и т.п. через связку Billing-Radius-BSR" - самоцель?

 

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

Жаль, что Вам ничего интереснее "пропить" в голову не приходит.

 

вот, например, на это разницу потратьте:

2) Использовать максимально эффективно выданый пул белых IP

3) Решить вопрос с предоставлением абоненту услуг IPTV и экономии магистрального канала до абонента

 

здесь ещё получается запас по внутренней полосе(между пользователями), ведь весь трафик идёт через центр(брас), сколько там внешней полосы мало колебёт :)

зачем гонять локалку через брас, когда она отлично может бегать между теми же 3627 по 10Гбит?

потому что так получается неконтролируемый трафик - а всё что неконтролируемое и в придачу нахаляву - есть нехорошо

почему неконтролируемый?

насколько мне нужно - я контролирую. и мне хватает тех же 3526, 3028, 3627...

 

конкретнее про нехорошесть можно?

[jab]

а что стримите и что в качестве стримера ?

h.264 пачкой писюков под vlc

 

[Дятел]

Для меня возможность сэкономить 20% аплинка в час пик оправдывает экономически практически любые танцы с NAT'ом.

какой у вас на планете дорогой аплинк.....

[jab]

какой у вас на планете дорогой аплинк.....

Сам аплинк дешевый, расширять дорого.

[Lynx10]

почему неконтролируемый?

насколько мне нужно - я контролирую. и мне хватает тех же 3526, 3028, 3627...

 

конкретнее про нехорошесть можно?

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

 

в случае браса он будет контрролируемый полностью - тоесть мало того что можна задать ПРОИЗВОЛЬНУЮ скорость гибко и без проблем так можна фильтровать и делать что угодно

а вот со свичами так просто не выйдет - конечно изврщаться можно - но будет напорядок сложнее и свичи должны быть как миниму соответствены

 

 

 

а что стримите и что в качестве стримера ?

h.264 пачкой писюков под vlc

ооо

а под какой осью vlc ? ;) - ненависный линукс ;) ??

ну не суть в том

 

1 не падает ? и как решаете падения

2 контент - сат ? FTA ? карточки какие?

[jab]

ооо

а под какой осью vlc ? ;) - ненависный линукс ;) ??

ну не суть в том

 

1 не падает ? и как решаете падения

2 контент - сат ? FTA ? карточки какие?

Линукс, падает. Пофиг, смотрящие зомбоящик не заслуживают жалости.

 

Стоит малтифид на кучу каких-то DVB карточек... SS2 и еще какие-то вперемешку. Давно туда не заглядывал.

[Lynx10]

ооо

а под какой осью vlc ? ;) - ненависный линукс ;) ??

ну не суть в том

 

1 не падает ? и как решаете падения

2 контент - сат ? FTA ? карточки какие?

Линукс, падает. Пофиг, смотрящие зомбоящик не заслуживают жалости.

 

Стоит малтифид на кучу каких-то DVB карточек... SS2 и еще какие-то вперемешку. Давно туда не заглядывал.

понятно

аналогично

и те же яйца

[kapa]

почему неконтролируемый?

насколько мне нужно - я контролирую. и мне хватает тех же 3526, 3028, 3627...

 

конкретнее про нехорошесть можно?

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

 

в случае браса он будет контрролируемый полностью - тоесть мало того что можна задать ПРОИЗВОЛЬНУЮ скорость гибко и без проблем так можна фильтровать и делать что угодно

а вот со свичами так просто не выйдет - конечно изврщаться можно - но будет напорядок сложнее и свичи должны быть как миниму соответствены

это всё общие слова: "часть проблем", "не гибко"...

я даже 1000Мбит даю абонентам. Правда, тогда они немного доплачивают.

 

я конкретных проблем пока тут не услышал, которые возникают и которые я не смогу решить.

ведь я сеть строю не для того чтоб "делать что угодно". что угодно нужно на стендах делать.

 

в случае браса он у вас до браса будет неконтролируемый или опять свичи должны быть "соответственны"?

[shicoy]

Управление локальным трафиком на уровне доступа-агрегации L2 должно сводится к защите от атак (Storm Control, DHCP IP Snooping, ARP Spoofing, CoS). Это умеют делать все железки.

Управление локальным трафиком на уровне BRS это скорость/QoS (не принципиально), это управление доступом к локальным сервисам (если необходимо, например пользоваться локальным торрентом/DC различным халявщикам на низких тарифах), ну и самое главное управление всеми процессами в сети на одном оборудовании по унифицированной (читай независимой от вендора коммутаторов доступа) схеме.

Если вам эти пункты не принципиальны, я рад за вас, значит у вас идеальные абоненты, идеальный ARPU и вообще все хорошо :)

[s.lobanov]

shicoy

 

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

 

А рулить доступом независимо от вендора совсем не сложно, лишь бы набор фич на доступе был примерно одинаковым, если вы знакомы с ООП, то как это реализуется, становится очевидно.

Изменено 14 мая, 2010 пользователем s.lobanov

[kapa]

shicoy

 

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

я могу это сделать и без браса.

[Lynx10]

shicoy

 

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

я могу это сделать и без браса.

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

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

интересно что осталось что вы не можете извратно сделать ;) ?

Изменено 14 мая, 2010 пользователем Lynx10

[kapa]

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

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

я пока кроме анальных аргументов от Вас ничего не услышал

 

 

[s.lobanov]

>я пока кроме анальных аргументов от Вас ничего не услышал

 

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

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

[kapa]

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

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

всё равно не понимаю что я делаю не так:

маки никуда не вбиваю. после создания пользователя в биллинге для автоматической генерации всех правил нужно только узнать номер порта от монтажника/ТП.

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

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

 

сложностей с учётом тоже не наблюдаю.

 

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

[jdemon]

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

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

всё равно не понимаю что я делаю не так:

маки никуда не вбиваю. после создания пользователя в биллинге для автоматической генерации всех правил нужно только узнать номер порта от монтажника/ТП.

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

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

 

сложностей с учётом тоже не наблюдаю.

 

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

Эт что за биллинг такой?

[shicoy]

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

Вот не будет этакого гуру админа который писал костыли к биллингу, который знает что и как и где, и чего? Все искать нового гуру админа который полгода будет втыкать чего тут наворочено и еще полгода переписывать под себя?

[kapa]

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

Вот не будет этакого гуру админа который писал костыли к биллингу, который знает что и как и где, и чего? Все искать нового гуру админа который полгода будет втыкать чего тут наворочено и еще полгода переписывать под себя?

админы тоже зарезервированы, все настройки задокументированы и забекаплены.

да и не уходят от нас обычно.... :)