vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

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

Дата публикации: 03.03.2006
Количество просмотров: 16500

На острове необитаемом
Тропинки все оттаяли
В. Высоцкий

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

В канун 8-го марта лучше всего продолжить техническую тему. Это хоть как-то должно отвлечь от предпраздничной суеты. Тем более, весна стартовала, и сезон 2006 года по массовому развешиванию и закапыванию оптоволокна можно считать открытым. Скоро неба в городах станет меньше, интернета - больше.

Нет вопроса важнее, чем продажа основной услуги, доступа в сеть и Сеть. А так как "проклятые и благословенные" анлимиты начинают накатывать на Россию (ту, что за пределами МКАД), разбирать этот узел противоречий ничуть не приятнее, чем клубок гадюк.

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

Собственно, на дешевом трафике может "выжить" два варианта тарифов – это $XX за YYYk или $XX за YYGb. При разумном соотношении они вполне конкурентны, и давно соседствуют в прайсах московских сетей.

Причем возникает забавная, и не слишком очевидная неприятность. В широкополосных анлимитах практически исчезает ограничительный фактор, позволяющий продавать дифференцированную услугу. Одним из первых это осознал British Telecom, который не смог придумать ничего лучшего, как ввести в тарифных планах ограничение по трафику. Это в стране давно победивших "анлимитов"! Им даже пришлось приспособить к словам 2GB monthly usage guide ссылку на внушительную трафикорасчетную шпаргалку – вот как жизнь заставила.

Можно предположить следующее объяснение ситуации. В период набора абонентской базы при серьезной конкуренции между операторами идет "соревнование каналов". Ведь неофиты "все равно не качают" – и цифра в прайсе получает чисто рекламное значение. Появляются тарифы на 512к, 750к, 1м, и наконец 2м. Более того, часто скорость на серфинге (по http портам) не режется вообще. Разрыв между обещаниями и надеждами оператора (заложенными в стоимость) может достигать нескольких порядков.

Первое время такой метод дает великолепные результаты. Однако проходит год, два, и пользователи обзаводятся "тяжелыми" он-лайн привычками, "ослами", ftp, и прочее. Заодно понимают, что реальной разницы между 512к и 2м нет, работает одинаково. И оператор видит, что даже через 512к можно "высосать" столько, что мало не покажется даже при самых либеральных магистральных ценах.

В отечественных сетях процесс пойдет быстрее. Если xDSL операторы Европы были связаны необходимостью апгрейдов оборудования, качеством медных линий, и т.п., то Езернетчики не ограничены (в техническом плане) ничем вообще. Думаю, не пройдет и года – можно будет видеть в клиентских прайсах строчку на "10 мегабит анлимит". С другой стороны, для пользователей в Сети уже готово немало "тяжелых" сервисов.

Что делать? Полосу уже не сузить, тарифы обратного действия не имеют. Сейчас ладно, нужно лишь успеть на высоком ARPU построить fiber до дома, эта задача приоритетна, и ради нее можно многим жертвовать. Но в будущем чем загонять абонентов на более дорогие тарифные планы?

Выходит, что пока трафик необходимо считать (и жестко, до байта). Завтра – давать полосу. А послезавтра опять придется ограничивать трафик (считать без детализаций и особой точности). Куда податься...

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

Внутренний трафик, естественно, не учитывается. Более 500 мегабит не прыгает только потому, что далее сеть ограничена 6-ю или 7-ю 100-мегабитными линиями до групп домов. А вот отсутствие падений ниже 250 мегабит просто кричит о необходимости кардинального расширения каналов.
В другой сети (скоро будет отчет) собирается кластер из 8-ми ПК на 36 Тб дискового пространства. То же не сильно дешевое удовольствие.

С таким раскладом становится актуальным ядро на 10G... И это все для удовлетворения абонентской жажды халявы. Без увеличения ARPU, лишь в пользу весьма условного "конкурентного преимущества". А как ограничивать услугу для эффективной продажи – не понятно.

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

Поэтому хотелось бы подробнее остановиться именно на подсчете мегабайтов. Тем более что для немосковских провайдеров это куда более актуально в настоящий момент. Когда еще анлимиты придут, а работать надо уже сегодня.

Способы подсчета трафика.

Сейчас есть две популярные парадигмы, способные поделить сети (конечно в техническом пане) на два мира. Разговаривающих на разных языках, оперирующих разными терминами.
Первый – терминирование туннелей (PPPoE, VPN, PPtP, L2TP, и т.п.) по информации из "радиуса" с дальнейшим сбором данных в нем же, и передачей в биллинг.
Второй – подсчет пакетов при маршрутизации с помощью NetFlow (IP-accounting, S-Flow), передача их в коллектор и биллинг. Оба пути обладают внушающим уважение перечнем достоинств и недостатков.

Достоинства туннелей (наиболее часто используется PPPoE)

     

  • Наличие серьезного телекоммуникационного софта, типа SSG. Это очень важное качество для быстрого запуска масштабных проектов.
  • Хорошо знаком операторам "старой школы" – не нужно перестраивать биллинг, переучивать людей, менять железо.
  • Точность и гибкость в продаже услуг.
  • Абонент не привязан к порту, и может получать услугу в любом месте сети.
  • Экономное использование IP-адресов (выдача из динамического пула).

Недостатки:

     

  • Низкая производительность терминирования туннелей.
  • Нужно настраивать софт на клиентском компьютере.
  • Как правило, никак не контролируется локальный трафик (тот, что за пределом туннеля), так как не хватает производительности.
  • Трудно обеспечивать QoS внутри туннелей. Кроме того, сети с туннелями поверх неуправляемого оборудования непригодны для мультикастовых рассылок.
  • Не подходит для подключения корпоративных клиентов (им нужен как минимум отдельный VLan).

Достоинства подсчета через NetFlow.

     

  • Высокая по сравнению с туннелями производительность, особенно на "тяжелом" контенте (фильм – по сути один Flow). При грамотном использовании агрегации и кеширования фловов можно без труда обсчитывать как минимум несколько гигабит.
  • Статистика совпадает с аплинком (если покупается трафик, а не полоса – почти наверняка при подсчете использовался NetFlow).
  • Так как протокол низкоуровневый, он имеет тенденцию к "аппаратизации", т.е. возможно использование специальных модулей либо коммутаторов, типа Cisco ME 6524 за $24k или HP 9304M.
  • Практически отсутствует настройка программного обеспечения на стороне абонента.

Недостатки:

     

  • Нет готового программного обеспечения, взаимодействие биллинга и системы авторизации фактически приходится создавать с нуля.
  • Абонент не мобилен, подсчет привязан к IP, и фактически – порту пользователя.
  • Неэкономное использование блока IP адресов.
  • Для контроля абонента необходима сеть на управляемом оборудовании как минимум с MAC-секьюрити на абонентском порту.
  • Ограничение доступа и изменение условий предоставления услуг происходит не в момент авторизации, а по мере срабатывания биллинга, т.е. раз в 20-30 минут (как правило).

Что выбирать, вопрос сложный и неоднозначный. В принципе, любая технология позволяет решать все жизненные задачи - с использованием того или иного количества "костылей".
Но на мой взгляд, для сетей более перспективен NetFlow (или его аналоги). И дело не в балансе достоинств и недостатков. Просто туннели (PPP, VPN) идейно противоречат "корпоративным" технологиям. А домашние сети – дитя Enterprise, а никак не ISP.

Успехи корпоративного сектора в дешевом, стремительном продавливании своих "сильных" сторон. Коммутаторы, умеющие выставлять приоритеты и минимально фильтровать трафик, стоят уже менее $300-400. Это невероятно, сказочно дешево по сравнению с операторскими технологиями.

Более того. На туннелях естественный инструмент принуждения абонента – ограничение полосы пропускания. Тут QoS не нужен, он даже вреден. Если пользователь хочет больше, он платит за более толстый канал. Но все коммуникации Ethernet-провайдеров построены на принципиально, идейно отличной парадигме. Оборудование и топология "заточены" под скорости и QoS.

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

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

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

А значит, эту тему придется продолжить позже. В планах рассказ о работе IPTV в сети разделенной Vlan'ами, и на наиболее простом и дешевом оборудовании, а так же способе блокировки доступа до части ресурсов без использования ACL.

Жалко, что домашние сети начиналась с неуправляемых хабов и коаксиальных репитеров. Если бы они стартовали сейчас - SNMP Counters (в дополнение к NetFlow) был бы вполне естественен, ведь клиенты xDSL платят за весь трафик (или за всю полосу), считая это вполне нормальным и естественным.

К сожалению, Ethernet-провайдеров, промышленно использующих SNMP Counters, очень мало. Сказывается предыстория. Поэтому внедрение технологии может столкнуться с большими маркетинговыми трудностями (объяснять пользователям новый способ учета очень сложно).

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

Разное.

Воздушки в Бангоке Типичный столб на Walking street Патайя

Прислал IG

 


Немного ссылок. Незаконные тарелки мешают самолетам. Просто шедевр беспредела чиновников в деле борьбы с радиосетями. Впрочем, эффект будет только если нескольких провайдеров обвинят в таране Ту-134 ГЗ МГУ, и подрыве Водовзводной башни...

Довольно интересный случай применения отечественной разработки VoD для раздачи видео в домашней сети. Хотя в основе, на сколько я понимаю, обычные avi с обычного ftp.
Если кому-то интересен софт - найти его создателей можно тут.
А тут собраны ссылки на большинство существующих систем IPTV (но уже западных).

Суд обнаружил в законе "О связи" неконституционные положения. Забавно, но к практике отношение имеет слабое.

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

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

 


Весна!

Весна

Прислал Денис А. Перминов, системный администратор ООО "Интерра"

 


Обновление в разделах

Методика переделки коммутатора D-Link DES-1008 в коммутатор с изолированными портами

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

Общий вид железки:

Вид снизу:

Переделке поддаются восьмипортовые коммутаторы с аппаратной версией H1,H2 и H3. Другие версии H/W и с другим количеством портов не исследовались на возможность переделки.

Общий вид на плату коммутатора:

Как видно из рисунка чип имеет маркировку DL1008, хотя на самом деле это чип компании IC+ IP178C. Описание чипа можно посмотреть на http://www.icplus.com.tw/pp-IP178C.html даташит на него здесь В данном документе написано что сей девайс умеет делать port based VLAN.

Переделка заключается в отпаивании резистора R12 номиналом 4,7 Ком от общего провода и подачи на него вместо земли напряжения питания. R12 находится около светодиода 6-го порта (см.рис):

Аккуратно отпаиваем резистор R12, потом один его вывод паяем на площадку которая находится дальше от светодиода (она соединена с 79 ногой чипа). Второй конец R12 висит в воздухе. На вывод висящий в воздухе паяем отрезок гибкого провода длинной 5 См. Можно взять обычный резистор МЛТ-0,125 номиналом 4,7 Ком и сделать как показано на фото внизу:

Второй конец провода паяем на конденсатор С62 (это фильтрующий по питанию 2,5 В ) как показано на фото внизу:

На этом переделка закончена. Собираем коммутатор. Теперь порт 1 становится uplink портом. В документации на чип написано что uplink портом должен быть 7-й порт, но плата разведена так, что 7-й порт чипа это 1-й порт по надписи на корпусе.

Теперь сетевые устройства включенные в порты со 2 по 8 не могут слать друг другу пакеты, для них доступен только 1-й порт.

Фирма D-Link предлагает подобную переделку в своих сервисных центрах за 290 руб. с сохранением гарантии на устройство. См. здесь

При самостоятельной переделке гарантия теряется.

Автор Харламов Сергей, ЗАО "ЭР-Телеком", г.Пермь

Анонс

 

  • Зарисовки по сети Диван-ТВ;
  • Магистральная дедовщина;
  • Коммуникации Тайланда, много фотографий;
  • Первая протяжка П-296;
  • Абонентский вынос в Новосибирске, сращивание кабеля, система городского оповещения и другие зарисовки узлов разных провайдеров. Вечная тема (много фотографий гарантировано);
  • Традиционный пункт - ссылки на интересные места Сети. Присылайте письма - они очень нужны для обзоров. Обязательно сообщайте, нужна ли Ваша подпись, ссылка, или лучше обойтись без нее;
  • В "ужастиках" - мышка из города Валуйки.

Долгострой:

  • Послегрозовой ремонт управляемых коммутаторов (надеюсь дойдут руки);
  • Не все Vlan'ы одинаково полезны;
  • Публичный проект сети в небольшом городе (именно они выходят на первый, авангардный план интернатизации России, в мегаполисах "уже все давно ясно"). Т.е. еженедельные отчеты о строительстве и работе "с нуля".
От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/reviews/15567/tak-na-skolko-gigabayt-etot-anlimit-.html

Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться