В шуме дождя
И призрачном свете молний
Тихо сгорел свитч
©FriedricH
Жара, затишье, отпуска. Единственное развлечение - миграция Мастерхоста из под заботливого крыла Транстелекома, судя по пресс-релизу - на все четыре стороны. Достаточно для главной новости недели, все же почти треть трафика рунета сосредоточена на этой площадке...
Попробуем заглянуть под крышку айсберга.
Чем были плохи для Мастерхоста эксклюзивные условия Транстелекома, сказать сложно. Но легкая тень разногласий чувствовалась давно. На таком фоне порой достаточно небольшого вмешательства одного человека - недоброжелателя, что бы переполнить чашу терпения...
Маршрутизация еще явно не успела принять окончательный вид, надо подождать несколько дней. Но уже видно, что прямой пир со стороны Транстелекома сохраняется.
3 94 ms 93 ms 94 ms EBG11-F400.108.transtelecom.net [217.150.39.122]
4 32 ms 31 ms 31 ms MasterLan-gw02.transtelecom.net [217.150.45.113]
5 36 ms 35 ms 35 ms 217.16.20.19
В то же время появился прямой маршрут со стороны РТКомма:
3 msk-dsr0-ge0-3-0-0.rt-comm.ru (217.106.7.194) 0.741 ms 0.833 ms 0.792 ms
4 msk-dsr0-eltel.c.rt-comm.ru (213.24.141.158) 0.841 ms 0.942 ms 0.943 ms
5 GW-MasterHost-1-9.retn.net (81.222.8.54) 1.726 ms 1.954 ms 1.580 ms
Фактически, Мастерхост встал за RETN. Пиринговая политика которого кардинальным образом изменилась:
Из листа MSK-IX:
В связи с модернизацией сети RETN и изменениями среди участников проекта, мы вынуждены прекратить обмен трафиком через MSK-IX. Восстановление пиринговых связей будет производится осенью и только в порядке Private Peers через прямые физические линки с операторами...
Почему RETN?
Есть мощная конспирологическая версия "питерской руки", которая идет по связке РТКомм - Комет - акционеры на каймановых островах (Питерские) - Петерстар - RETN, и приводит к входу Мастерхоста в РТКомовско-Кометовский картель. Да и технические нюансы совершенно прямо и недвусмысленно указывают на близкую дружбу RETN и РТКомма. У них два стыка в Москве и Питере, где РТКомм дает очень хорошие цены.
Но слишком это сложно, и невыгодно Мастерхосту. Так что более вероятно наиболее простое объяснение - RETN предложил наилучшие условия по включению. Тем более что им придется на некоторое время существенно изменить свою пиринговую политику "под" Мастерхост. Для этого нужен мощный, но относительно самостоятельный и "компактный" оператор.
В подтверждение этой версии известно, что RETN, во-первых, ведет самостоятельную пиринговую политику на Западных линиях, во-вторых не берет в качестве транспорта на запад оптику РТКомма (доказательство - последний пожар, который RETN не почувствовал). И в-третьих, в цепочке собственников есть еще часть RETN - Элтел - Hostway...
Значит ли это, что Мастерхост отказался от модели "заработка на контенте"? Не думаю. Просто он слишком сильно вырос, что бы продавать эксклюзив одному оператору. Следующий уровень - фактически крупного carrier'а, хоть и без магистралей, но хост-площадка вполне может заменить пару Российских губерний...
Тут условия игры сложнее - с крупными операторами надо меняться трафиком, мелким - продавать, и по возможности ни у кого не покупать. Поэтому можно ждать "обменных" пиров с Транстелекомом, РТКоммом, Голден-телекомом, и им подобными... И продажу трафика всем желающим по прямым маршрутам.
Таким образом, крупный хостер перестал быть хоть и невольной, но "большой дубинкой" в политике операторских групп. Стал полностью самостоятельным игроком этого рынка. Ну а сама информационная "заметность" перехода Мастерхоста показывает значение генератора контента для Российских carrier'ов.
Осталось отметить главное. А именно, как изменятся условия для клиентов хостинга... И в такой ситуации можно видеть только заметное улучшение. Маршруты в среднем сократятся, пиринговые войны станут невозможными. А ведь только эти моменты, пожалуй, омрачали почти двухлетнее пребывание nag.ru на одном из серверов Мастерхоста. Все остальное - вполне достойного уровня... Если не брать во внимание сегодняшний переходный процесс смены маршрутов (надеюсь, он не затянется надолго). :-)
Попытка принять сигнал РЕН ТВ с нового спутника "Экспресс АМ2" в центре Екатеринбурга. Он находится в точке 80 град. ВД. Видно, что пакет со спутника просто теряется в помехах.
Слева - помеха (3520-3524 МГц), посередине - полосатая черта - метка частоты 3525 МГц, справа помеха (3528-3531 МГц). Предположительный источник помех - релейки "Ростелекома".
Прислал Alexandr Volkov
Несколько ссылок. Для начала - капкан для работников ЖЭКа. Причем, вполне возможно, смертельный.
Рекламны ролик Корбины. Длинный, на флеше. Все бы ничего - но на мой взгляд сценариста надо увольнять без выходного пособия. Единственное долгосрочное впечатление, которое внушает данное произведение - Корбина как-то связана с проблемами, кабелями, и отбойными молотками. Действие затянуто, логика неочевидна...
Россиян заставят забыть о привычных телевизорах. Для реалистов - после слов "Согласно одной из федеральных программ, к 2010 г. Россия целиком перейдет на цифровое телевидение" далее можно и не читать.
Впрочем, надо иметь в виду, что смена формата вещания - самое лучшее время для выхода на рынок TVoIP.
Вот тут еще один опус на схожую тему. К 2008 году Мининформсвязи России планирует полностью завершить телефонизацию всех населенных пунктов страны. Что забавно - при нынешних темпах развития сотовой и спутниковой связи (а особенно падения цен на данные услуги), в такую новость вполне можно в это поверить.
Только вот при чем тут Мининформсвязи? Разве что в том, что мало мешали операторам работать...
Словарь терминов связи. Размер коллекции внушает.
Статьи по изготовлению переходников для pcmcia карт модемов и сетевых. Хотя при нынешних ценах на оборудование не очень актуально, но... Умельцы продолжают работать, и это, не смотря ни на что, радует.
Немного географии. Цены на АДСЛ, которые предлагает филиал Ленсвязь ОАО "СЗТ". Примерно от 2 рублей за мегабайт. На мой взгляд, для Северо-запада очень дорого...
И в приморье.... Подключение не дешевое, 4000-5000 тысяч рублей. Трафик менее 1,7 рублей за мегабайт...
Вот и попробуй разберись в Связьинвестовской тарифной политике. :-)
Итоги финансово-хозяйственной деятельности ОАО "Сибирьтелеком" за 1 полугодие 2005 года (РСБУ). Скучно, читать на ночь вместо снотворного.
Обновление в разделах невелики (лето - мало писем):
После неудачной прошивки WRT54G v.1.1 , v2.0, v.2.2 (другие не пробовал) (сбой сети, отключение питания эл. сети, прошивка не той версии устройства не родной firmware и.т.д.) ) бывает так, что попасть на девайс не представляется возможным даже после жесткого ресета. (IP 192.168.1.1). Но не нужно спешить выбрасывать устройство, его можно очень легко восстановить.
Лично мне нравится OpenWRT http://www.openwrt.org
$ cd /home/mca/firmware
$ ls
$ OpenWRT_b3.bin
$ tftp 192.168.1.1
>tftp bin
>put OpenWRT_b3.bin
После перепрошивки устройство перезагрузится. В случае OpenWRT заходим telnet 192.168.1.1, в случае с родной прошивкой либо Sveasoft, HyperWRT и т.д. http://192.168.1.1
PS. Неуверен, сработает ли на устройствах v3.0
Надеюсь эта информация окажется кому-нибудь полезной
Прислал Александр, г. Красноярск.
Молнии
Прислал DK, г.Курск
BNC-хаб
Восьмипортовый BNC-хаб в очень большом институте СО РАН г. Новосибирска.
Прислал Bokhan Artem
На фотографии изображен магистральный узел сети "Westnet" города Новосибирска, размещенный на крыше пятиэтажки. Видно свитч (сверху), чёрную дугу - это П270 и самопальные грозозащиты из которых выходит витая пара синего цвета. К пользователям отвод сделан кабелем белого цвета, заземление опущено в щиток, питание 220В по обычному антенному кабелю, видно в центре кадра (идет внатяг).
Прислал Щекин Павел
Узел одного из крупных Екатеринбургских провайдеров.
Два сервера
Отладочный комплекс и узел связи:
Прислал Тегин В.Ю.
3.5. Сигнализация.
3.5.1. RSVP.
4. Автоматизация.
4.1. Cisco QoS manager.
4.2. Cisco AutoQoS.
3.5. Сигнализация.
3.5.1. RSVP.
Протокол RSVP определен IETF в качестве сигнального протокола для архитектуры IntServ. Данный протокол позволяет конечным системам произвести запрос резервирования ресурсов по доступному маршрутизируемому пути в сети и повлиять на обработку своих потоков.
Процесс резервирования разбивается на несколько этапов:
1. Отправитель данных посылает управляющее сообщение RSVP PATH по пути предполагаемого распространения данных.
2. Все маршрутизаторы (поддерживающие RSVP) заменяют IP адрес отправителя на свой и отправляют измененное PATH сообщение дальше.
3. Получатели отвечают на PATH сообщением RSVP RESV, в котором описываются требования к сетевой среде (резервирование ресурсов). RSVP RESV идут от получателя к отправителю в противоположном направлении по отношению к маршруту RSVP PATH.
4. RSVP маршрутизаторы, получающие RESV, определяют возможность их выполнения. Если ресурсов хватает, то пакет передается дальше, если нет – отказ.
5. Отправитель, получив в итоге RESV, считает процедуру резервирования состоявшейся. Отметим, что реальное резервирование осуществляется сообщениями RESV.
Протокол RSVP является только средством сигнализации, обеспечением QoS занимаются другие механизмы.
4. Автоматизация.
4.1. Cisco QoS Policy manager.
Cisco QoS Policy manager является инструментом конфигурирования QoS. Предоставляет возможность централизованного управления политикой QoS.
4.2. Cisco AutoQoS.
Упрощает конфигурирование QoS. Заключается в:
1. Автоматический сбор информации о трафике для всех протоколов (а значит и приложений), используя NBAR, DSCP. Запускается AutoDiscovery для профилирования трафика:
Включение на интерфейсе
interface FastEthernet0/0
auto discovery qos
Просмотр
# sh auto discovery qos
2. Автоматическое генерирование параметров QoS (политик) и их применение:
interface FastEthernet0/0
auto qos
Просмотр
# sh auto qos
Приложения.
Модульный интерфейс.
Структура модульного интерфейса (Command Line Interface CLI QoS) при использовании классовой политики:
!описание класса class-map CLASS
! критерии по которым классифицируется пакет
match access-group
match input-interface
match ip dscp
match ip rtp
match protocol
match mpls experimental
match not
!описание политики
policy-map POLICY
! входящий в политику класс (классов может быть несколько)
class CLASS
! police – ограничитель (аналог CAR), МАКСИМАЛЬНАЯ полоса,
! предоставляемая классу
police bps burst-normal burst-max conform-action ACTION exceed-action ACTION violate-action ACTION
! шейпер
shape average – шейпер (максимум того, что может получить очередь)
shape peak – шейпер (максимум того, что может получить очередь)
! priority – приоритетный трафик (PQ в LLQ), ГАРАНТИРОВАННАЯ полоса
! абсолютное значение
priority BANDWIDTH-KBPS
! в процентах от полосы, определенной на интерфейсе
priority percent PERCENTAGE
! bandwidth – МИНИМАЛЬНАЯ полоса (CBWFQ), превышение допустимо в
! случае наличия резервов
! абсолютное значение
bandwidth kbps
! в процентах от полосы, определенной на интерфейсе
bandwidth percent
queue-limit NUMBER-OF-PACKETS– максимальное число пакетов, которое поддеоживается очередью класса (означает tail-drop)
random-detect – включение RED
fair-queue number-of-queues – WFQ только для класса по умолчанию
! дополнительно можно произвести маркировку
set cos COS-VALUE
set ip dscp IP-DSCP-VALUE
set ip precedence
set qos-group QOS-GROUP-VALUE
set mpls experimental VALUE
! применение политики к интерфейсу
interface INTERFACE
service-policy output POLICY
Иерархические политики.
Пример 1.
Внутри базового ограниченного класса организуются полосы для подклассов трафика.
class-map tcp
match
class-map telnet
match
class-map ftp
match
! определяем подклассы по 1 мбит
policy-map telnet-ftp
class telnet
rate-limit 1000000
class ftp
rate-limit 1000000
! определяем базовый класс 10 мбит
policy-map tcp-hier
class tcp
rate-limit 10000000
service-policy telnet-ftp
interface X
service-policy tcp-hier
Пример 2.
Ограничение клиентов. Общий канал делится на двух клиентов. Один получает 128 кбит, другой - 512 кбит. Трафик каждого дополнительно разбивается на полосы в определенной пропорции.
policy-map client1-classes
class gold
bandwidth percent 50
class silver
bandwidth percent 25
class bronze
bandwidth percent 10
policy-map client2-classes
class gold
bandwidth percent 30
class silver
bandwidth percent 10
class bronze
bandwidth percent 5
policy-map clients-policy
class client1
shape average 128000
service-policy client1-classes
class client2
shape peak 512000
service-policy client2-classes
interface FastEthernet0/0
service-policy output clients-policy
Автор статьи Эдуард Афонцев
