vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

#206 Счет сравнялся - 2:2

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

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

Счет сравнялся - 2:2.

В начало обзора надо по всем канонам пускать самую интересную новость. Но минсвязи и прочие представители "кабинетной" части отрасли повода не дают. Последняя их инициатива по демонополизации рынка дальней связи вызывает легкую зевоту. Под 70% рынка МН/МГ ходит по IP, и зачем нужна в такой ситуации дополнительная конкуренция традиционной телефонии - сказать сложно.

Поэтому придется перейти к уже традиционной теме - "Стриму", деятельность которого (в цифрах) была показана "МТУ-Интел". Подробнее ситуацию разъяснил Артур Алекперов, начальник отдела рекламы и информации "МТУ-Интел".

К 1 сентября в Стриме было примерно 20 тысяч пользователей. К концу ноября их число возросло до 87 тысяч. Это если считать "скроссированных" абонентов. Контрактов было немногим больше, а именно около 93 тыс...
Т.е. в месяц подключалось более 30 тысяч. Величина феерическая, далеко выходящая за рамки "обычного" для отрасли. И кардинально меняющая этим фактом само понятие провайдинга в России.

Как удалось этого добиться? Узким местом был психологический барьер, который находится на границе 20 долларов абонентской платы (это результаты исследований). Цена, естественно не все. Велась агрессивная рекламная кампания, (ТВ, радио, метро, щиты, перетяжки, Интернет, ТВ-гайды). Число заходов на сайт Стрима поднималось до 50 тыс. в день. Сыграли свою роль ориентация на локомотивные группы (студенты, школьники, IT-специалисты) и развертывание дилерской сети (хотя она начала срабатывать с середины октября).
Вроде бы ничего необычного... На первый взгляд. Однако, тут дело в размахе, с которым велась реклама. Видеоролики по ТВ часто "долетали" и до Екатеринбурга. Такую компанию может себе позволить только весьма богатая фирма.

Проблем было достаточно, другое дело, что они не были фатальными. По нашей статистике на complain в октябре пришли жалобы примерно от 2% абонентов. Было две сложных недели в конце октября - начале ноября, в основном из-за некачественных модемов. Реально МГТС сегодня может подключать гораздо больше, чем мы (МТУ-Интел) им даем. Проблема в том, что абоненты должны быть обслужены. Неправильно, когда на АТС приходится заниматься индивидуальными настройками под абонентский модем. Это допустимо при малом количестве абонентов, но при десятках тысяч - совершенно нетехнологично... На самом деле мощности техподдержки с избытком хватает на обслуживание всех абонентов, и все было бы нормально если бы в 90% случаев получилось "включил и работает", как и должно быть.
Вообще, простота, с которой МТУ одномоментно увеличили количество подключений в 10 раз, просто поражает. Уровень проблем очень далек от критического - тем более при таких объемах.

Однако, нужно отметить интересную деталь. Резкий рост количества подключений оказался прямо связан со скоростью доступа. При снижении скорости до 160к резко упрощается настройка модема. Не нужно думать о качестве телефонной пары (да и о количестве цифровых линий в многопарнике то же, хотя и до определенного предела), даже считать трафик не надо.

Т.е. тут либо узкий "трехмодемный" канал и массовое подключение, или настоящая "широкополоска", но темпами "домашних сетей". Вопрос конкурентного преимущества сводится к старому "резать канал или считать трафик". Именно теперь видно, что навязанный рынку узкополосный анлимит вылился более чем в 60 тысяч подключенных за два месяца абонентов "Стрима-НЕО". Не пора ли домашним сетям менять правила игры? ;-)

Но вернемся к "Стриму" - надо подвести итоги. Как бы не хотелось сказать обратное, но "МТУ-Интел" нужно поздравить с очень красиво отыгранным очком в конкурентном противостоянии. Неожиданный и выдающийся результат, не имеющих пока аналогов в России.

На мой взгляд счет сравнялся - 2 : 2.

  • Сети +1 - Освоена технология, позволяющая подключать абонентов в обход монополии телефонной меди. Построена инфраструктура фактически на всей территории крупных городов (либо под нужды сетей была перестроены линии магистральных провайдеров).
  • Сети +1 - Доступ через ethernet стал (и продолжает оставаться) самым массовым среди других технологий выделенных подключений. Через него получают коннективити с интернет более сотни тысяч пользователей только в Москве.
  • Стрим +1 - ADSL стал по настоящему доступен частному пользователю. Как по стоимости подключения, так и использования.
  • Стрим +1 - Впервые в России был применено массовое, промышленное подключение на "анлимитный" тариф. В кратчайший срок была набрана абонентская база в 30% от рынка, более того, препятствия в росте до 50-60% фактически отсутствуют.

Чем ответят на такой вызов домашние сети? Есть опасения, что все останется по прежнему... До кризиса, который не заставит себя ждать. Пока остается время, надо обязательно использовать слабые стороны АДСЛ - и перенимать сильные приемы "МТУ-Интел" (не забывая, понятное дело, про уже привычные преимущества домашних сетей). Выходов не много, но они есть:

  • Массовое объединение в 30-40 альянсов (а лучше в 5-6, но то очевидно недостижимо), использование эффективных методов управления, консолидация финансов.
  • Разработка и быстрое внедрение сервисов, недоступных при использовании узкополосного АДСЛ (требующих широкого канала). Прежде всего потокового видео, игр, VoIP, и т.п. Сложно, к чему тут спорить. Но другого способа выживания просто нет.

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

 

  • Новые главы из книги Правосвязие - опыт практической юриспруденции в отрасли "связь" отдельно взятой страны.
  • В разделе 4isp.ru запущена рассылка новостей. Кроме этого, на складе (его состояние доступно в он-лайне партнерам) около 500 штук сетевых карт различных видов. Например - 1, 2, 3, 4, 5, 6, 7.
  • Свежие изображения сетевого оборудования в разделе Фотографии сетевого оборудования. Оптический медиаконвертор Rubytech, Cisco WGB-350.
  • Можно подвести итоги конкурса на определение устройства MAXShare (см. прошлый обзор). Это Line sharing device, некая грошовая альтернатива офисной АТС. Ставится в стык офисных линий, на них - кучу факсов, и рассылать с них спам. Письмо со ссылкой прислал Alexey G. Misurenko...

А туннели... Выводят на свет.

Не новость, что для прокладки коммуникаций под улицами сейчас часто используют направленное бурение. Для которого применяют специальные (и очень дорогие) установки. Однако, как выяснилось, можно обойтись и гораздо более простым инструментарием.

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

На фотосессии ниже подробно показан процесс бурения 20-ти метрового туннеля и протяжки в него пластиковой водопроводной трубы (стенки толщиной около 20-ти миллиметров). Возможно, такое решение придется по душе многим "Ethernet-провайдерам".

Тяните сильнее Глоблизация

 

На работу ушло 5 дней. Из них 2 дня - копание ямы, и 2 дня сверление, и 1 день установка 2 муфт и протяжка оптики. Использовался 8-ми киловаттный перфоратор.

Надо осбо отметить, что пробуренные 20 метров - то не рекорд технологии. В другом районе через проспект просверлили 34 метра. Почти месяц бурили, а потом неделю искали конец (он отклонился на 7 метров в сторону). Помогла собака - при начале сверления она подбегала к одному месту и начинала с лаем рыть землю.

Кроме бурения - еще фотографии установки муфты на многопарник и устройство для движения по "воздушкам".

Соединения Вело....

И еще немного фотографий того же автора:

 

Прислал Dima

Сервер доступа PPPoE на базе FreeBSD.

В очередной раз описывать для чего нужно pppoe, я думаю, уже давно нет необходимости. Поиск в интернете (да и на данном сайте) даст много полезной информации. Хотелось бы представить конкретный материал по организации PPPoE сервера под столь любимой провайдерами (и нами) операционной системой FreeBSD.

Теория вопроса.

Для правильного понимания обсуждаемого вопроса необходимо разобраться с основными понятиями изучаемого явления. PPPoE – это метод передачи PPP поверх Ethernet. Пакеты PPP инкапсулируются (включаются) в Ethernet фреймы.

Действующими лицами являются с одной стороны Access Concentrator (AC) – это сервер доступа, а с другой клиент PPPoE. Клиент и сервер должны быть соединены с использованием любых Ethernet устройств (повторители, коммутаторы).

Для именования сервера доступа используется Access Concentrator Name. В свою очередь, Access Concentrator может предоставлять некоторое количество PPPoE сервисов, называемых Service Name.

Парадигма PPPoE включает две стадии: Discovery stage и PPP Session stage.

Клиент, желающий установить PPPoE соединение, сначала должен пройти Discovery stage. При этом между ним и сервером передаются Ethernet фреймы с Ether_type=0x8863.

Наблюдать можно следующим образом:

# tcpdump –n –e -i fxp0 ether proto 0x8863

В свою очередь, Discovery stage подразделяется на: initiation, offer, request, and session confirmation.

Сначала клиент должен инициировать PPPoE сессию (initiation). Для этого он посылает специальный пакет Active Discovery Initiation (PADI). Данный пакет посылается на broadcast Ethernet адрес (ff:ff:ff:ff:ff:ff), что логично, так как клиент пока не знает адреса сервера доступа. Опционно пакет может содержать запрашиваемый клиентом Service Name (и только, хотя многие считают, что здесь может быть и Access Concentrator Name).

Сервер доступа отвечает пакетом Active Discovery Offer (PADO), в который включает свое название Access Concentrator Name и название предоставляемого сервиса Service Name. Данный пакет уже юникастовый и содержит мак адрес конкретного сервера.

Теперь клиент может выбрать нужное (Service Name и Access Concentrator Name) из возможно нескольких предложений (PADO пакетов) и ответить уже конкретному серверу пакетом Active Discovery Request (PADR).

Согласный на предоставление связи сервер посылает клиенту Active Discovery Session-confirmation (PADS) пакет, включающий уникальный идентификатор сессии (SID), необходимый для дальнейшего взаимодействия. На этом Discovery stage заканчивается и начинается PPP session stage.

PPP session stage начинается с использованием уже обозначенного идентификатора (SID) и Service Name и включает стандартные PPP процедуры: link control, network layer control, authentication. При этом согласуются различные параметры связи и, самое главное, происходит аутентификация.

На данном этапе (и далее, вплоть до отключения) между клиентом и сервером передаются Ethernet фреймы с Ether_type=0x8864.

Наблюдать можно следующим образом:

# tcpdump –n –e -i fxp0 ether proto 0x8864

В итоге устанавливается PPPoE соединение и передаются данные.

Для окончания соединения PPPoE клиент (или сервер, что реже) посылает пакет Active Discovery Terminate (PADT).

Типичный обмен пакетами между участниками PPPoE выглядит так (mac сервера s:s:s:s:s:s, mac клиента c:c:c:c:c:c):

подключение клиента

c:c:c:c:c:c ff:ff:ff:ff:ff:ff 8863 60: PPPoE PADI [Host-Uniq UTF8]
s:s:s:s:s:s c:c:c:c:c:c 8863 49: PPPoE PADO [AC-Name "Provider"] [Service-Name] [Host-Uniq UTF8] [AC-Cookie UTF8]

c:c:c:c:c:c s:s:s:s:s:s 8863 60: PPPoE PADR [Host-Uniq UTF8] [AC-Cookie UTF8] [AC-Name " Provider "]

s:s:s:s:s:s c:c:c:c:c:c 8863 49: PPPoE PADS [ses 0x15] [AC-Name " Provider "] [Service-Name] [Host-Uniq UTF8] [AC-Cookie UTF8]

обмен данными

отключение клиента

c:c:c:c:c:c s:s:s:s:s:s 8863 60: PPPoE PADT [ses 0x1a]

Более подробное описание PPPoE содержится в RFC 2516 (см. ссылки).

Pppoed.

Классическим решением является использование в качестве PPPoE сервера входящего в базовую систему демона pppoed. Это известный и хорошо описанный в handbookе подход, который мы несколько дополним (описанием серверной части и другими сведениями, надеюсь не только ошибками).

Ядро операционной системы сервера должно быть собрано с поддержкой NETGRAPH.

Готовим конфигурацию сервера pppoed:

/etc/ppp/ppp.conf

pppoe-in:
set login
allow mode direct
set mru 1492
set mtu 1492
set speed sync
set log Phase Chat LCP IPCP CCP tun command chap
enable lqr
enable chap
set timeout 0
set ifaddr 10.0.0.1 10.0.0.2-254

/etc/ppp/ppp.secret

USERNAME PASSWORD 10.0.0.2

И стартуем демона pppoed:

# /usr/libexec/pppoed -p SERVICE_NAME -d -a ACCESS_CONCENTRATOR_NAME -l pppoe-in -P /var/run/pppoed.pid fxp0

Данная конфигурация предполагает использование аутентификации chap и назначение клиенту конкретного IP адреса.

Если необходимо, чтобы сервер принимал соединения с любым установленным Service Name, необходимо запускать pppoed с опцией –p "*" .

Данные параметры запуска можно оформить в стартовой конфигурации /etc/rc.conf:

pppoed_enable="YES"
pppoed_provider="SERVICE_NAME"
pppoed_flags="-a ACCESS_CONCENTRATOR_NAME -l pppoe-in -P /var/run/pppoed.pid"
pppoed_interface="fxp0"

Для поддержки аутентификации клиентов через радиус сервер (например FreeRADIUS) необходимо несколько изменить конфигурацию.

Описываем параметры соединения с радиус сервером (или несколькими):

/etc/radius.conf

acct RADIUS_IP RADIUS_KEY
auth RADIUS_IP RADIUS_KEY

где RADIUS_IP – IP адрес, RADIUS_KEY – секретный ключ.

И добавляем необходимое в конфигурацию PPPoE:

/etc/ppp/ppp.conf

pppoe-in:
set login
allow mode direct
set mru 1492
set mtu 1492
set speed sync
set log Phase Chat LCP IPCP CCP tun command chap
enable lqr
enable chap
set timeout 0
accept dns
set radius /etc/radius.conf
set ifaddr 10.0.0.1 10.0.0.2-254

В случае использования FreeRADIUS клиент может быть описан следующим образом:

/usr/local/etc/raddb/users

...

USER Auth-Type = Local, Password = "PASSWORD"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Framed-IP-Address = 10.0.0.2,
Framed-IP-Netmask = 255.255.255.255

...

При этом файл /etc/ppp/ppp.secret уже не нужен и клиенту выдается IP адрес, описанный в радиусе.

В свою очередь, радиус может быть собран с поддержкой SQL сервера (например FreeRADIUS хорошо работает с MySQL) и можно получить довольно изящную конструкцию, описание которой к сожалению уже выходит за рамки данной заметки.

Для ведения отдельного журнала для pppoed желательно вписать в /etc/syslog.conf следующее:

!pppoed
*.* /var/log/pppoed.log

И, создав файл /var/log/pppoed.log, рестартовать syslogd.

Отдельный демон pppoed должен быть запущен на каждом интерфейсе, предоставляющем сервис PPPoE. Клиентские процессы будут выглядеть как отдельные ppp, использующие интерфейсы tun. Причем они независимы от pppoed и поддерживают свою работоспособность после его остановки (в описании так и сказано: pppoed запускает /usr/sbin/ppp -direct label ).

Соответствующая конфигурация клиента pppoe на базе FreeBSD может выглядеть так:

/etc/ppp.conf

Provider:
set device PPPoE:fxp0
set mru 1492
set mtu 1492
set authname USERNAME
set authkey PASSWORD
set log Phase tun command # you can add more detailed logging if you wish
set dial
set login
add default HISADDR

Запуск процесса установления соединения выполняется так:

/usr/sbin/ppp -quiet -ddial -nat Provider

Или интерактивно через ppp:

# ppp
# ppp>
# ppp> show physical
# ppp> dial Provider
# ppp> show physical

Что можно записать в стартовую конфигурацию:

/etc/rc.conf

ppp_enable="YES"
ppp_mode="ddial"
ppp_nat="NO"
ppp_profile="Provider"

Кроме того, можно установить требуемый Service Name, вписав его следующим образом:

set device PPPoE:fxp0:SERVICE_NAME

В этом случае клиент будет требовать указанный сервис PPPoE.

Клиентскую поддержку на Windows 95, 98, NT может осуществить пакет RASPPPOE (ищите в интернете) а Windows XP вообще содержит встроенную поддержку PPPoE.

А теперь необходимо сделать важное замечание: в природе существуют нестандартные клиенты PPPoE. Выражается это в том, что они используют не совместимые с RFC 2516 пакеты Ethernet (0x3C12 вместо 0x8863 на этапе discovery и 0x3C13 вместо 0x8864 на этапе ppp session). И все бы ничего (в смысле ну и … с ними), но pppoed поддерживает и таких клиентов. Причем поддерживает по полной программе, а именно: переходит в состояние совместимости с нестандартным оборудованием, да так в нем и остается. И после этого уже стандартные клиенты не могут подключиться к данному сменившему "ориентацию" серверу. Индикатором в данном случае может служить sysctl net.graph.nonstandard_pppoe. В обычном состоянии данный параметр равен 0, а в нестандартном 1. Думаю, что с неожиданным отказом казалось бы отлаженного сервера PPPoE сталкивались многие "счастливые владельцы" pppoedов.

До появления FreeBSD 4.10 кроме физического отключения нестандартных клиентов можно было разве только фильтровать Ethernet фреймы от них с помощью ipfw2. Но теперь достаточно установить net.graph.nonstandard_pppoe в -1 и ничто не изменит состояние вашего сервера !

Возможные опасения насчет проблем с mss/mtu, присущих многим туннельным решениям, можно отбросить – при наличии в конфигурации строки "set MTU 1492" ppp будет автоматически выравнивать MSS.

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

Mpd.

С недавних пор в замечательную программу MPD ввели поддержку PPPoE, причем включая серверный вариант. Теперь на ее базе можно построить практически любой сервер доступа: ppp, pptp, pppoe.

Устанавливать MPD лучше из портов (предварительно их обновив).

Ориентировочная конфигурация сервера MPD может выглядеть следующим образом:

/usr/local/mpd/mpd.conf

default:
load pppoe0
load pppoe1

pppoe0: new -i ng0 pppoe0 pppoe0
set ipcp ranges 10.0.0.1/32 10.0.0.2/32
load pppoe_standart
pppoe1:
new -i ng1 pppoe1 pppoe1
set ipcp ranges 10.0.0.1/32 10.0.0.3/32
load pppoe_standart

pppoe_standart:
set bundle no multilink
set bundle enable compression
set bundle accept encryption
set bundle max-logins 1
set iface idle 0
set iface disable on-demand
set iface disable proxy-arp
set iface enable tcpmssfix
set iface mtu 1500
set link mtu 1500
set link no pap chap
set link enable chap
set link keep-alive 60 180
set ipcp yes vjcomp
set ipcp no vjcomp
set link max-redial -1
set link mtu 1492
set ccp yes mpp-e40
set ccp yes mpp-e128
set ccp yes mpp-stateless
set pppoe iface vlan1
set pppoe service SERVICE_NAME
set pppoe disable originate
set pppoe enable incoming

/usr/local/mpd/mpd.links

pppoe0:
set link type pppoe
pppoe1:
set link type pppoe

/usr/local/mpd/mpd.secret
USERNAME PASSWORD 10.0.0.2

Для поддержки радиус сервера в mpd.conf нужно дописать:

set radius server RADIUS_IP RADIUS_SECRET 1812 1813
set radius timeout 10
set radius retries 3
set bundle enable radius-auth
set ipcp yes radius-ip

Запуск в режиме демона делается так:

# mpd -b

Конфигурация клиента PPPoE на базе MPD может быть такой:

/usr/local/etc/mpd/mpd.conf

default:
load PPPoE
PPPoE: new -i ng0 PPPoE PPPoE
# set iface addrs 1.1.1.1 2.2.2.2
set iface route default
set iface disable on-demand
set iface idle 0
set bundle disable multilink
set bundle authname USER_NAME
set bundle password PASSWORD
set link no acfcomp protocomp
set link disable pap chap
set link accept chap
set link mtu 1492
set link keep-alive 10 60
set ipcp yes vjcomp
set ipcp ranges 0.0.0.0/0 0.0.0.0/0
open iface

/usr/local/etc/mpd/mpd.links

PPPoE:
set link type pppoe
set pppoe iface rl0
set pppoe service ""
set pppoe disable incoming
set pppoe enable originate

Запуск клиента делается также, как и сервера.

В отличие от pppoed, mpd использует интерфейсы ng. Можно отметить действительно низкую ресурсоемкость. Все остальное еще необходимо тщательно проверять перед запуском в эксплуатацию. Например, к PPPoE серверу на базе mpd не смогли подключиться рабочие станции windows 2000 с установленным RasPPPoE. Выяснилось, что не проходит этап согласования MRU. После долгих поисков был найден патч, написанный Глебом Смирновым, решающий данную проблему. Думаю, что будут и другие "открытия", ведь поддержка pppoe введена в mpd совсем недавно.

OpenBSD pppoed.

К моменту написания данной заметки в Интернете промелькнули сообщения о якобы возможной сборке pppoed от OpenBSD на FreeBSD. Однако мои личные попытки сделать подобное не увенчались успехом.

Заключение.

Главной целью этой заметки являлось желание показать, что сервер доступа PPPoE вполне можно организовать на базе FreeBSD, а не только Cisco или Linux. Надеюсь на конструктивные отклики и замечания, которые будут обязательно учтены и в новой редакции доступны на данном сайте.

Ссылки.

http://www.faqs.org/rfcs/rfc2516.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pppoe.html
http://renaud.waldura.com/doc/freebsd/pppoe/
http://www.ruhr.de/home/nathan/FreeBSD/tdsl-freebsd.html

Прислал Эдуард Афонцев

Анонс

 

  • Правосвязие. Операторы и проектная документация. IV.. Продолжение статьи из цикла "о легализации" домашних сетей Антона Богатова.

 

  • Compact Flash роутер на FreeBSD;
  • Готовь сани летом - обзор грозозащит;
  • АДСЛ имени Связьинвеста (собрано почти 100 городов России);
  • Серверная над входной дверью.
  • Тестирование HomePNA3;
  • Зарисовки узлов разных провайдеров. Вечная тема (много фотографий гарантировано);
  • Традиционный пункт - ссылки на интересные места Сети. Присылайте письма - они очень нужны для обзоров. Обязательно сообщайте, нужна ли Ваша подпись, ссылка, или лучше обойтись без нее;
  • В "ужастиках" - немного задержанная серия "игры с огнем";
От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/reviews/16706/schet-sravnyalsya-2-2.html

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

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

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