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