Pull to refresh

Сказ о том, как мы абонентов к портам привязывали

Reading time 7 min
Views 35K
Привет Хабр!

Расскажу и я свою историю.

Случилось так, что однажды я устроился на должность начальника технического отдела в одном небольшом интернет-провайдере. Компания на тот момент испытывала некоторые проблемы технического характера, технаря найти не могли. В тот момент я как раз искал нормальную работу — за год до этого ушел с великого и могучего завода АвтоВАЗ (работал в Дирекции Информационных Систем) — кризис прижал, денег не давали. После — год работы учителем в школе (параллельно регистрировался как ИП), в общем крутился как мог. И находясь осенью в другом городе, от знакомого узнаю о том, что срочно нужен технарь. Пришел на собеседование без особой надежды, да и большого желания, и как оказалось — зря. После примерно 10-минутной беседы директор попросил выйти сегодня же. И я вышел.

Как там говорится, то все присказка была?

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

Первое, что происходит при слиянии двух провайдеров — перенос абонентской базы купленного провайдера (назову его «Б») в базу купившего (пусть будет «А»). Задача решается достаточно быстро — анализируем обе базы данных, делаем правильные запросы, перетаскиваем нужную информацию в нужный биллинг. Штампуем новые инструкции по подключению. Юридические вопросы не рассматриваю, это не задача технического отдела. Всё, монтажники работой обеспечены.

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

В компании «А» трудится, и довольно давно, системный администратор. Все как положено — борода присутствует, linux везде и всюду. Собственно, с ним мы и начали нашу разработку. Изначально планы были туманными и лично у меня не вырисовывались во что-либо четкое и понятное. Были задачи — «нарисовать сеть» и поставить под наблюдение, а также навести порядок в информации об абонентах, ибо последние с заполненным полем ФИО «Мишаня» или «Нужный человек» недопустимы.

В качестве системы мониторинга у нас (компания «Б») стоял старый добрый Friendly Pinger. Понятное дело, в сети из 10 железок Pinger еще сгодится, но никак не в сети провайдера, насчитывающей сотни устройств. Все железо было передано под наблюдение Zabbix'у. А вот визуальная часть была перенесена на карту, для этого мы использовали:

  • Quantum GIS — геоинформационная система,
  • Карты openstreetmap — подложка,
  • БД postgreSQL + расширение PostGIS — хранит устройства и связи.

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

Следующим шагом стало приведение в порядок адресов абонентов. Девочкам было дано четкое указание, которое они также четко не выполняли — писать адреса полностью и без грамматических ошибок. Параллельно задались вопросом использование КЛАДРа в качестве базы данных адресов. Но когда сопоставили адреса из паспортов абонентов с записями КЛАДРа, решили что не стоит. Т.к. поле адреса в существующем биллинге (UTM) было одним текстовым полем, то отследить, что вводят девчата не представлялось возможным. Пара скриптов, выборка всех адресов из БД, удаление лишних пробелов, деление адреса по запятой с пробелом показали нам все проблемные места. Все адреса, в которых использовались сокращения, ошибки и прочие проблемы были устранены. Так мы получили список населенных пунктов, улиц и домов. Было бы не логично не закинуть эту информацию в базу данных. Сказано — сделано. 3 таблицы, city, street и house были заполнены информацией и теперь можно было реализовать механизм выбора адреса абонента с возможностью дополнять эти таблицы доверенными лицами. В комплекте с другими задачами было решено создать новый интерфейс для добавления и редактирования абонентов. А к старому закрыть доступ. Задача заняло какое-то время, параллельно всплывали новые кривые адреса, все это было устранено. И в один прекрасный день проблема с кривыми адресами исчезла. И возникла другая — теперь надо было привести в порядок адреса оборудования. С этой задачей мы тоже справились достаточно быстро.

Так, в таблице абонентов и таблице устройств появилось новое поле — house_id, по которому мы получали адрес вплоть до дома. И это был серьезный шаг вперед. Стоит сказать, что параллельно с разработкой шла и модернизация сети — все известные медные перекидки были заменены на оптику, все коммутаторы заменены на коммутаторы одного производителя. Мы выбрали D-Link и не жалеем об этом.

В процессе работы с картами писались и скрипты для Zabbix'а — если устройство вдруг переставало работать, запускался скрипт, который устанавливал определенный статус устройству в БД, а соответственно изменялось и визуальное отображение устройства на карте. Все прекрасно, Zabbix работает, директора глядя на карту в браузере видят что в сети происходит — загрузку каналов, где есть проблемы с электричеством, ну и так далее (кстати, «краснота» на карте однажды стала одним из аргументов установки бесперебойного питания).

А мы тем временем шли дальше. Есть абоненты с house_id, есть устройства с house_id.

Значит:

  • Первое: Туманно можем посчитать, сколько абонентов на каждом коммутаторе (если устройств в доме несколько, то пока не можем);
  • Второе: Для абонентов, у которых house_id совпадает с house_id коммутатора, запросом в БД можем получить координаты устройства и соответственно показать дом абонента на карте.

Сделано. Проверяем… Ага, а что это у нас абонентов с house_id 337 — 7 человек, а устройства такого нет… Непорядок, задачу монтажникам — узнать, что в этом доме установлено. Точно, есть там коммутатор, неуправляемый, медью подключен. Нарисовали, поправили. Проверили все такие места, нашли новые устройства, нанесли на карту. Покатались с навигатором — дорисовали недостающие дома.

Проблема. Нельзя отследить — работает неуправляемый коммутатор или нет. Идем по другому пути — под наблюдение порт управляемого коммутатора, с которого неуправляемый подключен. Ага, хотя бы так. Работает. Zabbix реагирует, ругается даже. И на карте видно. Директора довольны. Мы тоже.

Ну вот, все устройства нанесены, новые сразу добавляются в БД ответственным админом. Вполне себе рабочая схема, но чего-то не хватает. Абоненты на vpn-подключении, постоянные проблемы с настройкой, монтажники тратят время, call-центр тратит время на объяснение абонентам, как им на свежеустановленной системе заново настроить подключение. Не все роутеры поддерживают pptp. Так, а почему бы не перенести авторизацию на коммутатор… Сначала идея кажется нереальной, но чем больше над этим работаем, тем яснее становится решение. Что мы знаем об абоненте? mac-адрес, на его основе выдается прописанный в биллинге ip-адрес. С этим ip-адресом абонент выходит в локалку и стучится на vpn-сервер, где далее проверяется соответствие ip-адреса, логина и пароля.

На фоне всех этих событий приводим все коммутаторы к одинаковой конфигурации, дробим сеть на сегменты (тема отдельной статьи), инструментарий для работы с абонентами растет, туда же переносится система ведения заявок от абонентов, скрипты для работы с оборудованием, и т.д. и т.п. На всех коммутаторах включаем отправку событий на сервер, начинаем следить за mac-адресами. Развиваем это направление. Определяем, что не все связи указаны верно — этот вот коммутатор подключен не с 26-го, а с 27-го порта. А вот этот абонентский mac всплывает на нескольких устройствах на абонентских портах, пишем скрипт анализа топологии сети. Работа нудная, кропотливая. На выходе получаем информацию — в каком порту какого устройства фактически подключен абонент. Заносим в БД, продолжаем анализ. Некоторые абоненты ручками прописали локальный ip-адрес, mac отследить не удалось. Вычислили, с каждым таким абонентом работали индивидуально. Закрыли и эту проблему — кому-то mac сменили, кто-то на автомат поставил. Все. Красота. Знаем какой абонент где подключен. Знаем все виланы. Каждому порту управляемого коммутатора соответствует один абонент. Добавляем в формы дополнительные поля — выбор устройства и порта. Начинаем тестировать impb (ip-mac-port binding), возникают некоторые проблемы, связываемся с поддержкой D-Link'а, решаем вместе. Добиваемся стабильности. Запускаем. Оттачиваем. Пользуемся.

Система работает уже полгода, за это время она претерпела некоторые изменения. Сейчас она работает так: при изменении устройства/порта абонента происходит создание нового конфига impb для коммутатора, с которого абонент перекидывается, и после привязки к новому устройству/порту — создается новый конфиг и для этого устройства. Папка с конфигами находится под наблюдением. Если изменился файл конфига — он автоматом заливается в коммутатор. На практике это выглядит так: монтажник звонит в тех.поддержку, просит привязать абонента к такому-то порту такого-то устройства и называет mac-адрес. Сотрудники поддержки вбивают информацию, щелкают сохранить. В течении пары секунд после этого включается порт и создается запись impb, которая хранит в себе mac-адрес, ip-адрес (назначенный абоненту) и номер порта. Таким образом, даже зная mac-адрес абонента не удастся подключиться с ним в любом другом месте. А свободные порты — выключаются. Схема работает, абонентов потихоньку переводим. Им нравится.

Вот в принципе и всё. У нас получилось уйти от авторизации на серверах. И мы чувствуем разницу. Количество заявок на ремонт уменьшилось в разы. Время подключения абонента сократилось на пять минут точно (учитывая время синхронизации между vpn-сервером и биллингом). Также решилась проблема с совместимостью оборудования — теперь не ограничиваем абонентов в выборе роутеров — пользуйтесь чем хотите. Специально не стал приводить никаких кусков кода, попытавшись объединить в одной статье достаточно широкие аспекты и показать путь, по которому мы шли. Надеюсь, что получилось.

Подводя итог своего повествования, хочу прокомментировать, зачем пишу на Хабр.

  • Первое. Хочется поделиться наработками и идеями, которые были реализованы у нас. Возможно кто-то сэкономит кучу времени, прочитав эту статью.
  • Второе. Я люблю компанию, в которой работаю и мне действительно нравится то, чем я занимаюсь. С другой стороны, зная себя, понимаю, что скоро, когда все будет дописано — не смогу сидеть и просиживать штаны — надо двигаться дальше. И скорее всего, следующее место работы будет не интернет-провайдер. Поэтому хотел бы привлечь к разработке единомышленников. В данный момент занимаемся разработкой инструмента для документирования сети (муфты, оптика). На базе того, что уже сделано — работы осталось не так много. Система позволит документировать не только оптику, но скажем и трубопровод, или что-то аналогичное. Возможно, общими усилиями мы получим достойный и нужный open source проект.
  • Третье. Ну и конечно же полноценная учетка на Хабре. А почему бы и нет?
Tags:
Hubs:
+75
Comments 82
Comments Comments 82

Articles