Подписаться на рассылку

Автоматизируем учет адресов и привязок в IPoE-сетях

Дмитрий Коплович, 29 марта 2016

Почему до сих пор не все перешли на IPoE?

В Ethernet-сетях переход с технологии доступа PPP на IPoE вызывает у операторов боль. Даже среди таких продвинутых компаний как пользователи «Гидры» :) внедрили IPoE не более 50%, хотя почти все заявляют, что планируют это сделать.

В чем же причины такой медлительности? Ведь, безусловно, IPoE — более удобная для абонента технология. Подключение новых абонентов проще, помнить пароли не нужно, при нарушении связи соединение не разрывается — казалось бы, одни удобства.

52936398c2eac67fea30aec0f7cdd899

На поверку оказывается, что все не так гладко. Для оператора такой переход — большие затраты:

Но это еще не все. После внедрения IPoE оператор начинает дополнительно нести затраты на поддержание абонентских привязок и MAC-адресов в актуальном состоянии. Замена сгоревших коммутаторов превращается в целое мероприятие: любой перепутанный монтажником порт приводит к перерыву связи у абонента. Не становится IPoE панацеей и для абонентов: теперь при смене MAC-адреса или переезде приходится обращаться в техподдержку.

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

Идея

Соответствие между абонентом и его сетевыми реквизитами — MAC-адресом, адресом коммутатора доступа и номером порта на коммутаторе — устанавливается путем перенаправления «неизвестного» абонента на портал аутентификации.

zveropolis

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

Реализация

Когда мы начали делать решение для автоматизации IPoE-сетей в Гидре, то быстро поняли, что простая идея приводит к не такому простому решению.

Во-первых, нужна аутентификационная БД, в которой хранится актуальная информация:

Во-вторых, понадобится отдельная база данных для хранения сетевых реквизитов абонента, которые передает коммутатор в DHCP Option 82.

В-третьих, необходимо наладить сбор сетевых реквизитов. Они поступают с коммутатора на DHCP-сервер, который должен сохранять их в БД сетевых реквизитов вместе с выданным абоненту IP-адресом.

В-четвёртых, необходим BRAS с настроенными сервисами. Один из сервисов — для неидентифицированных абонентов — должен выдаваться всем, кто:

Если этот сервис подключен, все HTTP-запросы абонента перенаправляются на портал. Когда логин и пароль на портале введены, из БД сетевых реквизитов по IP-адресу абонента извлекается последний набор реквизитов и записывается в аутентификационную БД как актуальный.

Насколько необходимо учитывать MAC-адреса? Многие операторы считают достаточным работать только с привязками к портам. Это упрощает жизнь абоненту, позволяя ему подключать к сети любое устройство без дополнительных запросов пароля. В то же время замена коммутатора и переезд (ситуации 4 и 5 ниже) станет сложнее, так как привязка становится единственным идентификатором абонента и при ее изменении невозможно отследить, что с ним произошло. Кроме того, в некоторых конфигурациях сети без ограничений доступа по MAC-адресу возможны злоупотребления со стороны абонентов.

Ситуация 1. Миграция с PPP на IPoE

ipoe-scheme-03-sign

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

К счастью, для этого вовсе не обязательно обходить все чердаки. Постепенный перевод сегментов сети на IPoE можно организовать с помощью портала и небольшой доработки ситуации «переезд»: для этого в аутентификационной БД коммутатору достаточно добавить признак перевода. Все абоненты, у которых ещё нет актуальной привязки и MAC-адреса и они вышли в сеть с коммутатора с включённым признаком перевода, перенаправляются на портал.

Перевод — разовая операция, которая создаст абоненту минимум неудобств и в то же время актуализирует карту сети. Ее можно и нужно проводить постепенно, чтобы «размазать» нагрузку на службу техподдержки и отработать процесс перехода.

Ситуация 2. Подключение нового абонента

ipoe-scheme-00-sign

Первое знакомство нового абонента с оператором в IPoE-сети не всегда происходит гладко. Заранее выяснить MAC-адрес затруднительно, а поиск и бронирование свободного порта на коммутаторе вручную — трудозатратная операция. (Да-да, нам встречались операторы, у которых есть специальные сотрудники для поиска свободных портов. К сожалению, не удалось выяснить, как называется эта должность в штатном расписании.)

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

Продвинутые операторы подключают новых абонентов прямо «с колес», на следующий день или даже в день поступления заявки. Для этого их монтажники всегда имеют при себе запас оборудования и расходников, заявки поступают к ним по телефону или через мобильное приложение, а портал аутентификации автоматизирует первичную привязку к коммутатору и сохранение MAC-адреса.

Ситуация 3. Замена абонентского оборудования

ipoe-scheme-01-sign

Даже во многих крупных сетях, которые уже используют IPoE, проблема безболезненной замены абонентских устройств до сих пор не решена. Клиент, купивший, например, новый WiFi-маршрутизатор, сталкивается с отсутствием доступа в сеть из-за смены MAC-адреса. Не понимая, что происходит, он начинает паниковать и, если повезет, звонит в техподдержку своего оператора, а если нет — конкуренту.

Как это должно выглядеть? При замене оборудования абонент перенаправляется на портал, где подтверждает свои данные, после чего MAC-адрес его оборудования в аутентификационной БД обновляется. Безопасность не нарушается, но в то же время и абонент доволен. Нагрузка на службу техподдержки оператора снижается. На сети из 100 тысяч абонентов, по нашим оценкам, экономия может составлять до 1,5 тысяч обращений в месяц.

Ситуация 4. Замена коммутатора доступа

ipoe-scheme-02-sign

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

На помощь снова приходит портал. В аутентификационной БД для коммутатора хранится признак замены, который выставляется технической службой оператора вручную перед выездом сотрудника. Все абоненты, вышедшие в сеть с такого коммутатора с «чужого» порта, подтверждают свои данные на портале, и их привязка к порту обновляется.

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

Ситуация 5. Переезд абонента

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

Как это сделано в Гидре

В качестве БД аутентификации используется сама Гидра: она уже умеет хранить всю необходимую информацию о коммутаторах и их портах, абонентском оборудовании и его сетевых адресах.

Сам IPoE портал — это несколько HTML-страничек со встроенными формами, которые отправляют POST-запросы на сервер.

В качестве сервера используется разработанное нами ESB-приложение. Сервер интегрирован с БД сетевых реквизитов, с аутентификационной БД и с RADIUS-агентом hard. Его бизнес-логика обрабатывает все описанные выше ситуации. Для каждой из них в конфигурационном файле сервера настраивается его поведение. Некоторые из ситуаций (например, замену коммутатора) можно отрабатывать в «прозрачном» режиме, не требуя дополнительной аутентификации от абонента.

Выводы

Без автоматизации внедрение технологии IPoE — большие трудозатраты, а ее эксплуатация — постоянная головная боль. Мы предполагаем, что это важная причина, по которой до сих пор большинство операторов используют PPP, а их клиенты терпят связанные с этим неудобства.

К счастью, все эти недостатки устранимы с помощью самостоятельно разработанных скриптов, если у вас Гидры все еще нет :) или нашего IPoE-портала, если Гидра есть.
Комментариев: 0
КОММЕНТАРИИ К СТАТЬЕ

АВТОРИЗУЙТЕСЬ И ОСТАВЬТЕ КОММЕНТАРИЙ

ИЛИ

↑ К НАЧАЛУ СТАТЬИ