[Nag]

#262. Так на сколько гигабайт этот анлимит?

[GreeNGO]

NAG писал:

"Недостатки:

Низкая производительность терминирования туннелей.

Нужно настраивать софт на клиентском компьютере.

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

Трудно обеспечивать QoS и мультикаст.

Не подходит для подключения корпоративных клиентов (им нужен как минимум отдельный VLan)."

 

1. Хотя и сомнительно - пропустим.

2. Согласен. А техники за что хлеб жуют ?

3. Что значит за пределом туннеля ? Внутрисеточные баталии а-ля КС?

4. А причем тут вообще мультикаст и качество обслуживания ? Если они воообще для другого применяются ? Ничего не путаете ?

Обясните мне - вы типа виде по туннелю точка-точка собираетесь в мультикаст группах гонять ? Бред какой то.

5. Хм..интерсно, как раз с подключением корпоративщиков проблем не было. И именно по ПППоЕ. И Влан им находили.

 

Уважаемые, может будем продумывать статьи - прежде чем голословно утверждать ?

В прошлый раз ерунда про IP TV... В этот раз тоже какие то странности :(

[Nag]

3. Что значит за пределом туннеля ? Внутрисеточные баталии а-ля КС?

4. А причем тут вообще мультикаст и качество обслуживания ? Если они воообще для другого применяются ? Ничего не путаете ?  

Обясните мне - вы типа виде по туннелю точка-точка собираетесь в мультикаст группах гонять ? Бред какой то.

5. Хм..интерсно, как раз с подключением корпоративщиков проблем не было. И именно по ПППоЕ. И Влан им находили.  

 

3. За пределом туннеля - все что душе пользователя угодно. :-)

Если вы какой-то учет и организацию обеспечиваете - то уж никак не средствами туннелей. Т.е. нужен костыль.

4. Вообще, мультикаст - это камень в парадигму "облака", когда туннель накладывается на неуправляемую сеть. А если не облако - то часть услуг пойдет мимо ррр. Наверно, это надо сказать яснее будет.

Ну а QoS внутри туннеля то же обеспечивать не слишком просто.

5. Корпоративщик, которые берет РРР - это какой-то пионер, в общем не серьезно совершенно. ;-) А если вы выдаете виланы - значит требуется не ррр учет, а как-то по другому - т.е. костыль под технологию.

 

Следующий! :-)

[Гoсть]

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

 

-------------------------------------------------------------------------------------------

 

Изложу свое видение с технологической точки зрения. Буду краток, не так

много времени как хотелось бы.

 

На сегодня науке известно всего 4-ре основные концепции учета трафика по

выделенным линиям. В терминах Cisco, это:

 

1. IP Accounting

Даже писать ничего не хочу. Считай что этого уже нет.

 

2. BGP Policy Accounting

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

с определенным AS PATH. Использовать можно только в случае отсутствия

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

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

через который видно много роутеров "потребителей". Учет ведется фактически

только в исходящей очереди интерфейса. На скорость сильно не влияет.

Промышленных внедрений мне не известно.

 

3. Netflow

Версии 1 и 5 позволяют сливать с роутера детализованную статистику. Версии

8 и 9 могут агрегировать фловы прямо на роутере или сливать только самплы.

Учет ведется во входящей очереди интерфейса. Довольно значительно влияет на

загрузку роутера. Полоса потока сливания может достигать 10% а то и больше

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

Поток UDP без подтверждения, попросту говоря это флуд. Требует хорошего

коллектора и надежной связи с ним. Учет ведется с третьего уровня - IP.

Далеко не весь трафик оказывается зафиксирован. Могут возникать проблемы

с хранением и оперированием больших обьемов накапливаемой таким образом

информации. Мое мнение - годится только для контроля внешнего трафика

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

секюрити, СОРМ и тд. Либо в небольших сетях. Кстати, кроме Cisco его

поддерживает и Juniper, но по-моему больше никто.

В качестве коллекторов обычно используют Flow-Tools, cFlowD, NeTraMet

и Cisco Netflow Collector (указано по возрастанию). Мы используем NeTraMet

в силу очень многих причин (все остальное тоже пробовали). Написать

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

не проблема, задачи просто не стояло.

Используется на сетях ТрансТелеком (по крайне мере региональных) для

расчетов с конечным потребителем. Впрочем это не лечится, ребята так и

не выросли из под стола.

 

4. SNMP Counters

На интерфейсах любых роутеров и управляемых свичей имеются стандартизованные

счетчики, которые периодически централизовано опрашиваются. В SNMP версии 1

они 32-х битные, в 2-й версии - 64-bits. Никаких принципиальных проблем с

ними нет. На VLAN сабинтерфейсах циско-роутера счетчики есть аж с 12.1.5T.

Фактически никак не влияет на загрузку, как сети так и оборудования.

Особенных требований к серверной части также нет. Учет ведется со второго

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

обмен (ARP, STP, CDP), это как-бы минус. Зато убиваем сразу двух зайцев -

оперативный мониторинг сети плюс аккаунтинг одновременно. У нас это все

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

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

в сутки загружается в базу в биллинг. Графики и чарты рисуются по этим же

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

Используется на сетях РТКомм и Эквант, и много других noname операторов.

Обычно все используют вот это -- http://soft.risp.ru/netmond/. Можно также порыться на www.caida.org.

 

Резуме:

Лучше всего в штатном режиме в продакшене использовать последний метод.

Расхождения между Netflow и SNMP иногда достигают 20%, SNMP показывает

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

себе дармовой "биллинг" каптурящий трафик с уровня IP на писюге. Приходится

обьяснять это людям.

[MrBear]

Резуме:

Лучше всего в штатном режиме в продакшене использовать последний метод. Расхождения между Netflow и SNMP иногда достигают 20%, SNMP показывает обьективно больше. Что не всегда нравится тем клиентам, которые понаставили себе дармовой "биллинг" каптурящий трафик с уровня IP на писюге. Приходится обьяснять это людям.

 

SNMP хорош для магистралов, которые не выделяют разные типы трафика по источнику. Кроме того, даже однократное переполнение и сброс snmp-буфера до получения данных биллингом приводят к ощутимым потерям учета. А расхождения с РС-рутерами клиентов под win32 бывают и при IP-аккаунтинге, и при Нетфлоу, это совсем другая тема.

[Nag]

Гoсть, не вижу базовых противоречий в этом тексте по отношению к обзору. :-)

Только два момента:

1. SNMP СОВЕРШЕННО непригоден для учета дорого трафика. Продавать с него "по 3-5 рублей за мегабайт" - проще сразу застрелиться.

Так что вывод - или про будущее, или не про сети. :-)

2. На рутере можно регко настроить кеш для нетфлова. ;-) И он будет переповторять данные пока не кончится кеш. ;-) Так что потери и сравнение с флудом - это все больше от кривых рук.

[edo]

Расхождения между Netflow и SNMP иногда достигают 20%, SNMP показывает  

обьективно больше.

дело не в заголовках l2?

[LostSoul]

1. SNMP СОВЕРШЕННО непригоден для учета дорого трафика. Продавать с него "по 3-5 рублей за мегабайт" - проще сразу застрелиться.  

Так что вывод - или про будущее, или не про сети. :-)

А почему собственно, если он весь по одной цене? Для сети без туннелей, точнее способа нет, чем snmp.

[UglyAdmin]

Ага.

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

[LostSoul]

Ага.

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

ARP запросы к услуге отношение имеет, нехай считает.

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

[kaa]

дело не в заголовках l2?

в них самых, проверяли

[Horgi]

Гoсть[/b2. На рутере можно регко настроить кеш для нетфлова. ;-) И он будет переповторять данные пока не кончится кеш. ;-) Так что потери и сравнение с флудом - это все больше от кривых рук.

бред.

Но опонент то же не совсем прав, до гигабитных апстримов нф без потерь сделать можно, нужно просто следить за отсутствием коллизионности линков до коллектора. Дорого это только, 72/g1 будет под 100% ходить при отсутствии прочих фичь.

В ттк сделано наиболее прогрессивно, по гнездовой схеме, с разделением на тарифные зоны. ИМХО, с новой сеткой и ее скоростями у них начнуться проблемы. Но там были хорошие технари, наверное что-ть придумают, если в результате кровавой резни выжвут. ;) главное что бы маркетологи их на самплед не толкнули.

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

про коннективити вне тунеля долго смеялся, port protect спасет отца русского эзернета. А acl тех, кто заложился на pptp.

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

[Horgi]

дело не в заголовках l2?

в них самых, проверяли

снять счетчик по пакетам * на оверхед и вычесть, религия не позволяет? ;)

[kaa]

снять счетчик по пакетам * на оверхед и вычесть, религия не позволяет? ;)

Религия не позволяет это делать РТКому-Сибирь :), они скрупулезно нам подсчитывают L2 заголовки, которые генерятся на нашем порту :)

20 % прям из воздуха - не плохо :)

[Horgi]

снять счетчик по пакетам * на оверхед и вычесть, религия не позволяет? ;)

Религия не позволяет это делать РТКому-Сибирь :), они скрупулезно нам подсчитывают L2 заголовки, которые генерятся на нашем порту :)

20 % прям из воздуха - не плохо :)

20% это вы загнули, урежте осетра, не атм же... ;)

А так верю, но вы наверное такой договор подписали? Аргументируйте переход на другого провайдера на сэкономленные 10%, предложите решить. Думаю они поймут.

[Nag]

1. SNMP СОВЕРШЕННО непригоден для учета дорого трафика. Продавать с него "по 3-5 рублей за мегабайт" - проще сразу застрелиться.  

Так что вывод - или про будущее, или не про сети. :-)

А почему собственно, если он весь по одной цене? Для сети без туннелей, точнее способа нет, чем snmp.

 

Без детализации с большими ценами это покупать в розницу будут только при полном отсутствии альтернативы. К тому же в езернете от флуда соседа защиты почти нет. Если это по рублю за гиг - не страшно. А если по 3 рубля за мег - то нафик, нафик.

[kaa]

20% это вы загнули, урежте осетра, не атм же... ;)  

Ну если только чуть чуть :)

Длина l2 заголовка 20 байт, на пакетах в 64 байта это 30%

:)

[Nag]

снять счетчик по пакетам * на оверхед и вычесть, религия не позволяет? ;)

 

Да, очень прогрессивная технология. ;-)

Очень точная, и споров не вызывает...

И после этого бревна в глазу докапываться до "соломинки" нетфлова?

 

Нельзя SNMP для ПОДСЧТЕТА использовать. Можно только для ОГРАНИЧЕНИЯ и ОЦЕНКИ чего-то не слишком ценного.

[Гoсть]

Nag,

так-так, вот ты уже и сам подбираешься к персональному PPP акаунтингу ;)

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

[Nag]

Гoсть[/b2. На рутере можно регко настроить кеш для нетфлова. ;-) И он будет переповторять данные пока не кончится кеш. ;-) Так что потери и сравнение с флудом - это все больше от кривых рук.

бред.

Но опонент то же не совсем прав, до гигабитных апстримов нф без потерь сделать можно, нужно просто следить за отсутствием коллизионности линков до коллектора. Дорого это только, 72/g1 будет под 100% ходить при отсутствии прочих фичь..

 

Для кого-то бред, у кого-то работает без проблем, по крайней мере 20-30 терабайт в месяц считается на жалкой 75-ке, совместно с рутингом, бгп и прочими фичами. :-) Поток на коллектор - порядка 2%, что-то типа мегабита, с редкими прыжками до 10%. Это реальность, то что можно "посмотреть" сейчас.

Не вижу никаких проблем в увеличении потока по крайней мере раз в 10, а это при самых скромных ценах 30-50 тысяч абонентов. А реальнее около 100 тысяч. Потребности на сегодня и завтра закрывает с большим запасом, столько на один рутер все равно не "упадет".

[Nag]

Nag,

так-так, вот ты уже и сам подбираешься к персональному PPP акаунтингу ;)

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

 

В огороде бузина, а в киеве дядька. :-)

Никак по другому это заявление прокомментировать не могу.

[Horgi]

снять счетчик по пакетам * на оверхед и вычесть, религия не позволяет? ;)

 

Да, очень прогрессивная технология. ;-)

Очень точная, и споров не вызывает...

И после этого бревна в глазу докапываться до "соломинки" нетфлова?

 

Нельзя SNMP для ПОДСЧТЕТА использовать. Можно только для ОГРАНИЧЕНИЯ и ОЦЕНКИ чего-то не слишком ценного.

не понял какие возражения, кроме истеричных выкриков из зала? ;)

-

НФ не плохая технология, но дорогая, практически не масштабируемая (после 1Г на узел) и не развивающаяся. Тупик, как и помянутый ссг

Для вас это похоже вновь изобретенная религия. :(

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

[Horgi]

= дубль, скип.

[Horgi]

Гoсть[/b2. На рутере можно регко настроить кеш для нетфлова. ;-) И он будет переповторять данные пока не кончится кеш. ;-) Так что потери и сравнение с флудом - это все больше от кривых рук.

бред.

Но опонент то же не совсем прав, до гигабитных апстримов нф без потерь сделать можно, нужно просто следить за отсутствием коллизионности линков до коллектора. Дорого это только, 72/g1 будет под 100% ходить при отсутствии прочих фичь..

 

Для кого-то бред, у кого-то работает без проблем, по крайней мере 20-30 терабайт в месяц считается на жалкой 75-ке, совместно с рутингом, бгп и прочими фичами. :-) Поток на коллектор - порядка 2%, что-то типа мегабита, с редкими прыжками до 10%. Это реальность, то что можно "посмотреть" сейчас.

Не вижу никаких проблем в увеличении потока по крайней мере раз в 10, а это при самых скромных ценах 30-50 тысяч абонентов. А реальнее около 100 тысяч. Потребности на сегодня и завтра закрывает с большим запасом, столько на один рутер все равно не "упадет".

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

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

[Sonne]

Вы забываете, что трафик в скором времени вобще потеряет значение как таковой.

 

Идеология нормально сети по некоторым представлением выглядит так:

 

устройство Ethernet акцесс -> Коммутатор Q-in-Q (агрегация в доме) -> Ядро на одном из метро техзнологий ( агрегация квартал/город) -> BRAS

 

По сути клиенты идут персональным VLAN до BRAS которые считает УСЛУГИ.

 

Какой сымсл считать трафик если минута телефонного звонка стоит одно, серфинг в интернете другое, а просмотр видеофильма с локального сервера третье?

 

Цена вопроса BRASа по Джуниперу 150 тысяч за 15 тыс абонентов. Т.е. 10$ на абонента за возможность считать все. Агрегированная полоса 10 портов по 1 гбиту. Никаких Netflow, SNMP и прочее. У тех же жуниперов две приблуды - собственная система подсчета и костыль-переходник на радиус для любителей тунелей.

 

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

 

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

 

Все остальное баловство. PPTP, PPoE полубаловство, спасает от воровства денег клиента, но не спасает от проблем общего доступа Ethernet.