В Ethernet-сетях переход с технологии доступа PPP на IPoE вызывает у операторов боль. Даже среди таких продвинутых компаний как пользователи «Гидры» :) внедрили IPoE не более 50%, хотя почти все заявляют, что планируют это сделать.
В чем же причины такой медлительности? Ведь, безусловно, IPoE — более удобная для абонента технология. Подключение новых абонентов проще, помнить пароли не нужно, при нарушении связи соединение не разрывается — казалось бы, одни удобства. |
На поверку оказывается, что все не так гладко. Для оператора такой переход — большие затраты:
Но это еще не все. После внедрения IPoE оператор начинает дополнительно нести затраты на поддержание абонентских привязок и MAC-адресов в актуальном состоянии. Замена сгоревших коммутаторов превращается в целое мероприятие: любой перепутанный монтажником порт приводит к перерыву связи у абонента. Не становится IPoE панацеей и для абонентов: теперь при смене MAC-адреса или переезде приходится обращаться в техподдержку.
Выгоды миграции на IPoE в свете этих проблем не выглядят очевидными. Поэтому операторы и не спешат с ней. Тем не менее, есть способы упростить переход на технологию IPoE и ее эксплуатацию с помощью нехитрых программных решений.
Портал аутентификации — это веб-форма, на которой абонент должен ввести логин и пароль от своего личного кабинета. Если они верны, то новые реквизиты записываются в базу данных для идентифицированного абонента.
Когда мы начали делать решение для автоматизации IPoE-сетей в Гидре, то быстро поняли, что простая идея приводит к не такому простому решению.
Во-первых, нужна аутентификационная БД, в которой хранится актуальная информация:
Во-вторых, понадобится отдельная база данных для хранения сетевых реквизитов абонента, которые передает коммутатор в DHCP Option 82.
В-третьих, необходимо наладить сбор сетевых реквизитов. Они поступают с коммутатора на DHCP-сервер, который должен сохранять их в БД сетевых реквизитов вместе с выданным абоненту IP-адресом.
В-четвёртых, необходим BRAS с настроенными сервисами. Один из сервисов — для неидентифицированных абонентов — должен выдаваться всем, кто:
Если этот сервис подключен, все HTTP-запросы абонента перенаправляются на портал. Когда логин и пароль на портале введены, из БД сетевых реквизитов по IP-адресу абонента извлекается последний набор реквизитов и записывается в аутентификационную БД как актуальный.
Насколько необходимо учитывать MAC-адреса? Многие операторы считают достаточным работать только с привязками к портам. Это упрощает жизнь абоненту, позволяя ему подключать к сети любое устройство без дополнительных запросов пароля. В то же время замена коммутатора и переезд (ситуации 4 и 5 ниже) станет сложнее, так как привязка становится единственным идентификатором абонента и при ее изменении невозможно отследить, что с ним произошло. Кроме того, в некоторых конфигурациях сети без ограничений доступа по MAC-адресу возможны злоупотребления со стороны абонентов.
Задача на первый взгляд выглядит крайне трудоемкой: требуется узнать, к какому порту какого коммутатора подключен каждый абонент, и сохранить эту привязку в базе данных.
К счастью, для этого вовсе не обязательно обходить все чердаки. Постепенный перевод сегментов сети на IPoE можно организовать с помощью портала и небольшой доработки ситуации «переезд»: для этого в аутентификационной БД коммутатору достаточно добавить признак перевода. Все абоненты, у которых ещё нет актуальной привязки и MAC-адреса и они вышли в сеть с коммутатора с включённым признаком перевода, перенаправляются на портал.
Перевод — разовая операция, которая создаст абоненту минимум неудобств и в то же время актуализирует карту сети. Ее можно и нужно проводить постепенно, чтобы «размазать» нагрузку на службу техподдержки и отработать процесс перехода.
Первое знакомство нового абонента с оператором в IPoE-сети не всегда происходит гладко. Заранее выяснить MAC-адрес затруднительно, а поиск и бронирование свободного порта на коммутаторе вручную — трудозатратная операция. (Да-да, нам встречались операторы, у которых есть специальные сотрудники для поиска свободных портов. К сожалению, не удалось выяснить, как называется эта должность в штатном расписании.)
Такое планирование усложняет и замедляет бизнес-процесс подключения, приводит к лишним затратам, а главное, совершенно бесполезно, потому что может быть полностью автоматизировано.
Продвинутые операторы подключают новых абонентов прямо «с колес», на следующий день или даже в день поступления заявки. Для этого их монтажники всегда имеют при себе запас оборудования и расходников, заявки поступают к ним по телефону или через мобильное приложение, а портал аутентификации автоматизирует первичную привязку к коммутатору и сохранение MAC-адреса.
Даже во многих крупных сетях, которые уже используют IPoE, проблема безболезненной замены абонентских устройств до сих пор не решена. Клиент, купивший, например, новый WiFi-маршрутизатор, сталкивается с отсутствием доступа в сеть из-за смены MAC-адреса. Не понимая, что происходит, он начинает паниковать и, если повезет, звонит в техподдержку своего оператора, а если нет — конкуренту.
Как это должно выглядеть? При замене оборудования абонент перенаправляется на портал, где подтверждает свои данные, после чего MAC-адрес его оборудования в аутентификационной БД обновляется. Безопасность не нарушается, но в то же время и абонент доволен. Нагрузка на службу техподдержки оператора снижается. На сети из 100 тысяч абонентов, по нашим оценкам, экономия может составлять до 1,5 тысяч обращений в месяц.
В классической IPoE-сети при замене коммутатора, к которому подключены абоненты, очень важно сохранить привязки абонентов к портам неизменными, иначе абоненты потеряют доступ в сеть.
На помощь снова приходит портал. В аутентификационной БД для коммутатора хранится признак замены, который выставляется технической службой оператора вручную перед выездом сотрудника. Все абоненты, вышедшие в сеть с такого коммутатора с «чужого» порта, подтверждают свои данные на портале, и их привязка к порту обновляется.
Таким образом, монтажник может при замене коммутатора подключать абонентов в любой порт. Замена упрощается — теперь не обязательно распечатывать карты привязки абонентов к портам перед выездом. На больших сетях, имеющих десятки тысяч коммутаторов, каждый год заменяют тысячи устройств — автоматизация этого процесса дает ощутимый экономический эффект.
Некоторые операторы разрешают своим абонентам «мигрировать» по сети, подключаясь из одной точки в другую. Эта ситуация встречается реже предыдущих, но с помощью портала она разрешается фактически бесплатно. Алгоритм тот же, что и с заменой коммутатора, но в отличие от нее, перепривязка абонентов через портал разрешается не обязательно в пределах одного коммутатора.
В качестве БД аутентификации используется сама Гидра: она уже умеет хранить всю необходимую информацию о коммутаторах и их портах, абонентском оборудовании и его сетевых адресах.
Сам IPoE портал — это несколько HTML-страничек со встроенными формами, которые отправляют POST-запросы на сервер.
В качестве сервера используется разработанное нами ESB-приложение. Сервер интегрирован с БД сетевых реквизитов, с аутентификационной БД и с RADIUS-агентом hard. Его бизнес-логика обрабатывает все описанные выше ситуации. Для каждой из них в конфигурационном файле сервера настраивается его поведение. Некоторые из ситуаций (например, замену коммутатора) можно отрабатывать в «прозрачном» режиме, не требуя дополнительной аутентификации от абонента.
Без автоматизации внедрение технологии IPoE — большие трудозатраты, а ее эксплуатация — постоянная головная боль. Мы предполагаем, что это важная причина, по которой до сих пор большинство операторов используют PPP, а их клиенты терпят связанные с этим неудобства.