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

Привет Хабр!

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

Случилось так, что однажды я устроился на должность начальника технического отдела в одном небольшом интернет-провайдере. Компания на тот момент испытывала некоторые проблемы технического характера, технаря найти не могли. В тот момент я как раз искал нормальную работу — за год до этого ушел с великого и могучего завода АвтоВАЗ (работал в Дирекции Информационных Систем) — кризис прижал, денег не давали. После — год работы учителем в школе (параллельно регистрировался как ИП), в общем крутился как мог. И находясь осенью в другом городе, от знакомого узнаю о том, что срочно нужен технарь. Пришел на собеседование без особой надежды, да и большого желания, и как оказалось — зря. После примерно 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 проект.
  • Третье. Ну и конечно же полноценная учетка на Хабре. А почему бы и нет?

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 82

    +5
    Красиво, емко, нужно — было приятно прочесть. Только один вопрос (пожалуйста, товарищи-Хабровчане, давайте без холиваров ну хоть в этот раз): почему D-Link, а не Cisco?
      +16
      Не заработали денег на Cisco еще :-)
        0
        А в домовых сетях бывает Cisco? На аксес левеле я обычно вижу Huawei или Dlink.
          0
          Бывает. Покупают б/у на ebay и ставят.
            0
            Dell ставим, Linksys ставим — по цене не сильно дороже Длинков, зато не записываешься в пожизненные бесплатные бетатестеры компании. Хуавей — очень неплохое железо, нет смысла сравнивать этих вендоров даже близко. ИМХО
              +2
              Да и у самой Циски есть относительно не дорогие коммутаторы. Но мать же вашу, сколько стоят оптические трансиверы для них (приличный стоит дороже коммутатора). Это же мрак. А D-Link-овские на сдачу отсыпают.
                0
                Трансиверы никто не запрещает использовать других вендоров, с ними проблем не очень много даже с относительно дешевыми. Фирменные на критичные узлы, на остальные что попроще. Основная проблема длинков — очень кривая прошивка, в которой даже задекларированные возможности работают не полностью. Из недавнего, попросили помочь с сеткой, небольшая совсем, 2 десятка коммутаторов D-Link DES-3200-26, прошивка 4.00.024 (это важно, на других ветках говорят проблем меньше). Извините, но это мрак мало того что DHCP snooping работает через раз (точнее раз из 5, пришлось городить костыль на access profile) так еще при использовании dhcp relay в связке с option 82 получаем не веселую картину, все вроди как работает, но при скачке напряжения сразу после поднятия свича, на него идет запрос на получение DHCP от абонентов, свич увидев такое счастье начинает флудить этими запросами на всю сеть, другие свичи радостно подхватывают эстафету и сеть ложится, почему так происходит выяснить не удалось, но всплывала проблема раз в неделю, железо тупо ложило само себя, пришлось выносить каждую свечку в отдельный вилан. И таких проблем море, если использовать хоть что-то сложнее банальных vlan в структуре сети.
                Если в небольшой сети время и желание заниматься регулярными перепрошивками свичей еще есть (ответ вендора: «вот в следующей починили — проверяйте», одно починили другое сломали.) то когда количество таких железяк переваливает за несколько сотен, даже не тысяч, заниматься с ними регулярным сексом уже не выходит. Так что экономия очень спорная, часто принимается решение поставить б/у циски и делы 10 летней давности привезенные с США, чем новенькие длинки за те же деньги и не иметь проблем с их обслуживанием, они просто работают.
            +3
            Cisco в домовых сетях на уровне доступа — это из области фантастики. Недопустимо дорого.
            DLink, Zyxel, и ещё куча других гораздо менее понятных брендов.
              +1
              Думаю, первый показатель — разница в цене. Когда идешь по пути постоянного расширения — деньги уходят на покупку очередных абонентов.
              Во-вторых, на тот момент именно этих коммутаторов во всей сети было больше.
              А мне, как программисту и человеку, ступившему в неизвестную ранее область, было вообще без разницы, на чем строить сеть — это решение сверху. И надо сказать, в тех.поддержке D-Link всегда внимательно относились к нашим вопросам. Однажды только была ситуация, выслали нам прошивку для DES 3526, а как оказалось, прошивка занимала больше отведенного ей места. Ночью обновили, а утром монтажники собирали по всем населенным пунктам трупы и везли в офис. Дело в том, что обычно ребята из D-Link'а вместе с файлом прошивки высылали текстовый файл, в котором указывали конкретные особенности этой прошивки — в тот раз они этого не сделали. А мы допустили оплошность, не проверив вручную на одном коммутаторе.
                +1
                «А мне, как программисту и человеку, ступившему в неизвестную ранее область, было вообще без разницы, на чем строить сеть — это решение сверху. „

                Здорово. Первичен должен быть выбор архитектуры с учетом тех сервисов, которые будут предоставляться сейчас и в перспктиве. От этого отталкиваются и ищут железо с нужным функционалом и разумной ценой. Послезавтра захотите IPTV какое-нибудь или другую допуслугу и вдруг окажется, что сеть для этого совершенно не готова. Ну хорошо, допустим не захотите никогда. Но в статье о подобных вещах вообще ни слова. Полностью отсутсвует ход мысли в духе — задача -> поиск решения -> выбор из альтернатив оптимального.
                  +1
                  Собственно я и пишу, что задачи, которые ставились — ставились не мной. Я лишь участвовал в разработке — что давали, с тем и работали.
                  IPTV работает.
                  +1
                  Охх. кто ж без тестов на паре сначала тестовых устройств, а потом на небольшой группе из продакшена такое вываливает сразу на всю сеть?
                    0
                    Каюсь. Изначально все так и было, постепенно поняли, что система налажена, сбросили задачу на Zabbix. И практически сразу обожглись. Благо, добра такого (3526) — единицы. Собственно, без прикрас об этом и написал — надеюсь на наших ошибках кто-то научится не расслабляться.
                      0
                      Нельзя полагаться на что либо.
                      В некоторых компаниях за нарушение регламента — увольнение по статье.
                        0
                        Это приходит с опытом. Регламент ввели несколько позже. До увольнений не доходило, но пару раз штрафы некоторым сотрудникам вкатывали. Небольшие, скорее для воспитания.
                          +1
                          Жаль что поздно догадались.
                          У меня обычно приход на новую работу ознаменуется написанием политик ИТ по компании, по процедурам ИТ отдела и подписанием их приказом по компании. с распространением по сотрудникам.
                          Соответственно все процедуры максимально документируются, рисуются SLA.
                          Но это да, приходит с опытом.
                            +1
                            Скажите, а откуда берётся скилл написания всего этого?
                            Я, вроде, неплохой инженер, но если бы встала такая задача — не знал бы даже, с какой стороны подойти.
                              +1
                              вначале — о себе.
                              Потом — как это делалось многими моими знакомыми
                              последний блок -как это делается в идеале по мировым практикам.

                              Много текста
                              Не скажу за всех, скажу за себя:
                              — развлекаться с компьютерами я начал еще с 7 лет.
                              и начинал с MS-DOS. сначала игры, потом в школе обьединил Lantastic (6х286 пк) с стоящей «на сервере» (1х486) Win3.11 for WG в одну сеть.
                              Потом вся линейка 9x, и рабочие станции NT с 2000й. потом в 2005 добавилась фря и линукса. Соответственно граблей было много от идиотских и разных до феерических и сложных, что приходилось дергать сертифицированных по данной технологии знакомых.

                              С доменом фактически столкнулся уже в прошлом году, пришлось много чего в компании переделывать в ИТ инфраструктуре, т.к. она фактически была заброшена и меня брали как раз на администратора- инженера, который будет тестить и внедрять новый функционал, т.к. до меня домен был только общей системой авторизации на рабочих станциях. Соответственно писалась документация по всему, что, где и как я настраивал, какие групповые политики, какие сервисы — буквально со скриншотами каждого шага настройки с описанием что, где, зачем и почему. Потом высчитывались временные интервалы SLA и зависимости — если упадет такой то сервис — время поднятия, если упадет такой-то сервер — какие сервисы это затронет и сколько будет заниматься восстановление из бекапа либо же развертыванияе с нуля/либо же перенос виртуалки. Причем оно реально выполнялось — т.е. мы знали, например, что полный бекап файлопомойки если её не разбить на части — выполняется больше 2х суток.

                              На последнем месте работы вообще полностью с нуля развернул за три месяца полную ИТ инфраструктуру офиса используя свои текущие знания, при этом практически с нуля изучая Cisco (недельные курсы icnd по маршрутизации в 2007 кажется, не считаются, забыл нафиг), и iSCSI NAS, с виртуализацией, новым доменом, новым почтовым сервером, IP телефонией, разнесением разного трафика по VLAN'ам, подсетям и настройками доступа.

                              Причем это всё было достаточно детально описано — где-то полторы недели тупо писал документацию по этому всему зоопарку и то, далеко не всё охватил.
                              — Скилл написания — В условиях СНГ, а как показывает мои знакомые — и не только в СНГ — лично полученные грабли — заболел админ и всё нафиг умерло — резервируем админа.
                              Провайдеру перебили оптику — покупаем у второго провайдера второй канал.
                              Перебили оба канала потому что они оба лежат в одном колодце — привет СНГ — проверяем чтобы оба канала интернета шли разными путями.
                              Местные энергетики передали привет от сгоревшей подстанции — покупаем второй ввод 220, если и там проблемы — тратимся на генератор.
                              Сгорел сервер/коммутатор/маршрутизатор/компьютер/ноутбук/модем/мультиплексор/конвертер — имеем 1 (2/3/пачку) в запасе.
                              Имеем 8 головый ксеон/16 гиг памяти, который занимается тупой раздачей файлов, а рядом стоят еще три старых ксеона — заводим виртуализацию, три железки ставятся под менее ресурсоемкие задачи/тестинг либо вообще отдаются в резерв, чтобы в случае выхода большого ксеона — быстро поднять эти виртуалки на них.
                              Освобождаем файловый сервер от много винтов — покупая большой и толстый NAS/SAN, куда складывается почтовые, файловые шары, базы данных.
                              Юзер лазит по социалкам в рабочее время — ставим ограничение на прокси — которая вместе с почтовым сервером прекрасно живут по небольшим виртуалкам.
                              Юзер ставит лишнее и не нужное п/о — применяем пистоны и групповые политики запрета запуска неподписанного п/о
                              и так далее.


                              А если по правильному и по умному —
                              Есть общие рекомендации по управлению бизнесом, ИТ и так далее — ключевое слово — «ITIL», по уровням надёжности ЦОД — «TIER», навскидку.

                              Есть рекомендации по построению инфраструктуры — те же доки от вендоров — Microsoft, Cisco, IBM, HP, Oracle, VmWare и других о том, как правильно строить соответствующую инфраструктуру виртуализации, систем резервного копирования, защиты периметра и внутренней сети, коммутаторов, каналов, систем хранения, кластеров, ЦОДов, облаков, конкретных систем, сервисов и услуг — собственно этому учат на курсах соответствующих направлений конкретных вендоров.

                              Это по хорошему и правильному —
                              Нравится Linux/Unix — изучаешь курсы и документацию LPI, Oracle, RedHat xBSD и соответствующую документацию
                              Нравится MIcrosoft — изучаешь Программирование на .Net/Active Directory/SQL/Sharepoint/Office/Azure и т.п. по идеологии данного вендора.

                              Нравятся базы данных — Mysq/Postgres/MS Sql/Oracle к Вашим услугам + хотя бы немного изучаешь ту ОС, под которой оно живет, т.к. это надо понимать как целостную платформу.

                              Нравятся сети — Cisco, Huawei, Nortel, D-Link, Linksys, VPN, маршрутизация — насколько я понимаю на данный момент — лучшие курсы по сетям де факто от Cisco — некоторые остальные вендоры сейчас по управлению своими железками стараются внедрить интерфейс управления в консоли, похожий на Cisco CLI.

                              — Соответственно в идеале и по правильному — это очень узкая специализация, на практике у нас пытаются экономить и хотят знаний побольше от одного, и чтобы платить поменьше. и это печально.
                                0
                                Да я сам CCNP/CCDP, так что как строится, скажем, сеть — примерно представляю. Техническая сторона вопросов особо не вызывает.
                                А вот политики компании, IT-отдела, регламенты и т.д… Такого обучения не встречал.
                                Буду копать в направлении ITIL.
                                Спасибо за ответ!
                                  0
                                  Да не было никакого обучения по написанию документации. Берешь и пишешь, формате мануала + приказа по компании. ЧТо если юзер оставляет документы не на сетевом диске а на локальной машине, винт умирает и документы профуканы — виноват юзер. дальше уже докладная руководству, что Вася пупкин приказ не выполнил и пролюбил контракт на миллион вместе с ноутом в поезде и блабла…
                0
                Чертовски приятно ощущать победу над хаосом. У меня альтернативная история, когда добавляется ещё один элемент, начальство с не очень логичными идеями. Когда стало понятно, что бессмысленно бороться с глупостью, была создана параллельная ситема, работающая система. Все были счастливы, у нас всё работало, а начальник думал что его методы приносят результат, ну и уволил нашего ведущего инженера. Не замедлительно «была нажата кнопка power», и опять все погрузилось в хаос.
                  0
                  И какие были последствия? Был ли найден компромисс?
                  Читал на Хабре статью, как один администратор завязал на себя всю voip-инфраструктуру и потом его никто не мог нормально заменить при увольнении(когда дело дошло до повышения ЗП).
                    –1
                    Работаем в хаосе)
                  +1
                  У вас есть отличный опыт построения сети интернет-провадера, в т.ч. опыт решения многих подводных камней этой области. Не думали ли вы организовать свой бизнес? Найти местность, куда не добрались еще крупные игроки рынка, оценить возможные доходы, оценить расходы на развертывание сети и подключение абонентов, собрать команду инженеров-единомышленников (возможно из места текущей работы) и стать игроком телеком-рынка.
                    0
                    «А мне, как программисту и человеку, ступившему в неизвестную ранее область, было вообще без разницы, на чем строить сеть — это решение сверху. „

                    Отличный опыт для самостоятельного бизнеса.
                      0
                      На это как минимум нужны деньги. Хотя были различные предложения, даже с выездом из страны. Отказываюсь.
                      0
                      Мне Ваша работа нравится. Можете ли Вы сообщить регион и уровень оплаты (можно в личные сообщения)?
                      Я так понял у Вас используется PPPoE? Но если есть привязка к порту может тогда обойтись DHCP — тогда подключение абонента ещё более ускорится.
                        0
                        зачем pppoe когда на каждого абонента свой vlan
                        Просто по мак адресу назначается ip через dhcp и всё.
                        В России такой способ подключения назвали IPoE
                          0
                          Ну да, это я и имел в виду. А что если у клиента несколько компьютеров (вот я во что только кабель провайдера (PPPOE) не пихаю — настраиваю разные компы. Каждый раз звонить провайдеру и просить поменять настройки на новый МАС?
                            0
                            решается установкой роутера ;)
                              0
                              Дя я понимаю, что я из того 0.0001% пользователей которые ежедневно пихают в кабель провайдера что попало…
                              0
                              А доблестная компания Комстар (ныне МТС) использует PPPoE, но при этом еще и привязку по MAC-адресу. Так что там двойной трындец. Уже 4-й роутер меняется. Просто перепрописываем MAC-и с первой железки уже несколько лет.

                              Но недавно пришлось купить (прости Господи) АПКШ-Континент, а у него, вот черт его так, нельзя перепрописать MAC на портах. Так вот смена привязки MAC-а к порту для юриков — тот еще писец…

                              Согласен что привязка к MAC-у — зло.
                                0
                                У нас юр.лица не привязаны по mac-адресам. vlan решает проблему.
                          +7
                          Т. е. притащил домой ноут с работы — воткнул, не работает? Надо звонить, объясняться, привязывать новый мак? А если это случилось ночью? Сколько времени я должен потратить, что бы оно заработало?
                          Говорите, кол-во обращений в техподдержку уменьшилось? Первый бы от вас сбежал как клиент. Нормальная схема только одна — пользователь подключил шнурок — все заработало. Порт девайса = то, что авторизует пользователя и только он.
                          Нормальный подход тут был бы с 82 опцией дхцп. Пользователь получил ип — знаем с какого порта, какой-бы ип не был получен, трафик посчитаем нужному абоненту. Пользователь не получил ип авторматом? Выставил вручную, еще что-то? Сеть у него не заработала.
                            +1
                            Когда врежутся в подъезде к вашему шлангу — посмотрим как запоёте.
                              +3
                              И чо будет в схеме автора? Что мешает врезавшемуся мак юзера использовать?
                                0
                                ничего. просто говорю что порт девайсе != авторизации.
                                к тому же, есть вероятность получить один мак на разных портах (пришел к соседу через стенку) = геморрой.
                                  +1
                                  Это замена авторизации, замена отжившим или уже изживающим себя пптп и пппое. Так большинство нормальных провайдеров сегодня работает. Часто вообще влан на пользователя + белый ип. «А мужики-то и не знают» ©
                                    0
                                    Белый ip дорого на каждого, либо у вас пока сеть маленькая. PrivateVLAN удобнее, но весь локальный траффик будет гоняться через маршрутизатор(ы), лучше ARP-proxy на коммутаторах доступа.
                                    0
                                    Если влан на юзера — никакой проблемы с одинаковыми маками для нормального железа (IVL, а не SVL реализация).
                                  0
                                  Да, и к слову. Если с моего шланга пентагон ломать не будут или едро в блогах поливать, что мне в итоге? Я больше заплачу? Неприятно, согласен. И? У вас помегабайтный тариф?
                                    0
                                    Ну, это «нериятно» могло быть на очень крупные суммы. Автор же не указывает в каком году всё это происходило. Так что это могло быть до пришествия анлимов.
                                  +1
                                  я так понял про эту опцию — коммутатор передаёт (dhcp-relay) DHCP-серверу запрос от клиента, добавив в него(запрос) параметры для опции 82?
                                    +1
                                    xgu.ru/wiki/%D0%9E%D0%BF%D1%86%D0%B8%D1%8F_82_DHCP

                                    опция протокола DHCP, использующаяся для того чтобы проинформировать DHCP-сервер о том, от какого DHCP-ретранслятора и через какой его порт был получен запрос. Применяется при решении задачи привязки IP-адреса к порту коммутатора
                                    0
                                    В нашей сети используется «несуществующая» технология IPoE (ниже объясню)
                                    Кстати, на Хабре были статьи, затрагивающие, в том числе, IPoE и DHCP Option 82, в частности, вот:
                                    habrahabr.ru/post/108453/

                                    Так вот, при подключении ранее незарегистрированного оборудования (мак не совпадает), клиент получает «левые» настройки и, при выходе в интернет, видит страничку с сообщением что оборудование незарегистрировано, код регистрации, наш телефон и краткую инструкцию, дополнительно выводятся текущие IP и MAC-адреса. Достаточно, например, позвонить и оставить заявку на перепривязку оборудования, назвав номер договора, фамилию и код регистрации. Естественно, если настройки прописаны вручную, то клиент странички не увидит.
                                    Часто спасает если кто-то переехал в квартиру где уже есть наш кабель или кому-то просто нужно подключить новый/роутер.
                                    Естественно, сеть поделена на сегменты, выдающиеся настройки разные, коды регистрации тоже. Так, переехав с одного сегмента в другой, старый клиент тоже будет получать страничку о необходимости регистрации и потребуется перепривязать мак в другой сегмент.
                                    В принципе, перепривязку оборудования тоже можно автоматизировать.
                                      +1
                                      В таких ситуациях нормальные люди покупают роутеры и подключают мобильные устройства через них…
                                      0
                                      Чем валить в кучу разрозненную инфу про поля биллинговой базы и прекрасное оборудование длинк можно было б сделать хотя б элементарный обзор, как без впн можно авторизовать, какие дизайны существуют и почему выбран именно тот, который описан (один из самых дурацких).
                                        0
                                        Потому что д-линк других вариантов не умеет. Вот и вся разгадка.
                                        0
                                        Good job
                                          0
                                          Спасибо, чертовски приятно слышать.
                                          +1
                                          У нас была в университете точно такая же история 4 года назад, когда пришлось фактически заново создавать сеть студенческого городка. Теперь все четко и красиво.
                                            0
                                            Единственное, не ясно как и кому продать сеть. Я бы продал небольшую в Одессе.
                                              0
                                              Это уже дело руководства, кому и как лучше продаться…
                                              +1
                                              Автор молодец — проект интересный и достаточно обширный по кругу решения задач.
                                              Комплекс п/о для таких вещей тоже должен неплохим получиться.
                                                0
                                                Было бы неплохо дополнить пост основными количественными показателями: сколько абонентов, сколько и каких девайсов и т.п.
                                                  0
                                                  Постараюсь ответить на Ваши вопросы в следующей статье.
                                                  0
                                                  Работаю администратором небольшого провайдера. У нас клиенты также подключаются по VPN (pptp). С коллегами не так давно обсуждали уход от pptp в сторону выдачи статического ip-адреса и привязки его к порту коммутатора. Нашли два приемлемых варианта: коммутаторы DLink c их ip-mac-port binding и HP V1910G c Arp-management (та же возможность привязки ip-mac-port). И по ценам очень приятно оказалось.
                                                    +1
                                                    Простите, а чем IPoE на основе dhcp relay с Option 82 + address binding не подошел? Привязывать маки какой смысл? Сегодня абонент воткнул в порт стационарник, завтра сгорела сетевая — поменял, послезавтра ноутбук, потом роутер или еще чего и каждый раз ему придется звонить вам, тратить свое и ваше время для изменения настроек (Это не говоря про некоторые чудо-роутеры, которые при каждом ребуте генерят себе новый мак). А так изолируем порты, поднимаем 82 опцию и все, абонент привязан к айпишке и пусть в порт втыкает что хочет, с другой айпишкой порт работать не будет, на другом порту эта айпишка работать не будет, никаких гемороев с привязками, воткнулся в порт и все заработало.
                                                      0
                                                      В нашем случае (десяток студенческих общежитий) такой фокус не пройдет — начнется содом и гоморра. В складчину половина этажа через подключение одного это самое нормальное что мы видели, когда оборудование было частично «тупым».
                                                        0
                                                        Простите, а кто им виноват, что студенты хотят шары.
                                                          0
                                                          И чем привязка по маку помешает? Ставим роутер и продолжаем раздавать интернет на пол общаги, заметьте с одного мака. При этом вы создадите себе не слабый геморрой с учетом всех маков, а банальная смена сгоревшего коммутатора будет требовать не тривиальных действий, при этом сменить мак для понимающего человека — дело 30 секунд, хотя может я чего не понимаю. Если не секрет какое ориентировочно количество абонентов в вашей сети?
                                                            0
                                                            В случае без привязки Вы даже не заметите, что на том конце провода сменился клиент.
                                                            Какой геморрой может быть, если биллинг строился с моделью жесткой связки клиент-порт-mac-ip?
                                                            Увы секрет =)
                                                              0
                                                              Смена коммутатора — наипростейшая задача. Чтобы заменить коммутатор — еще нужны основания. Это раз. У 45% оборудования уже сейчас установлено бесперебойное питание, случаи с заменами крайне редки — на 100 коммутаторов 1 меняем не чаще чем раз в полгода. Это два. Монтажник едет с распечаткой — кто в каком порту, поэтому переброс с одного коммутатора на другой проходит без проблем. Это три. Геморрой — это вам так кажется. На самом деле все прекрасно, главное правильно к вопросу подойти.
                                                                0
                                                                видимо Вы промахнулись веткой
                                                                  0
                                                                  Сорри. Когда увидел, было поздно )) Не привык еще.
                                                                  0
                                                                  В датацентре и в идеальных условиях именно так. И даже в описаном вами случаи идеальных условий 100 комутаторов 1 раз в пол года, 10 000 коммутаторов — это 100 в пол года или 16 в месяц, или же через день. Опять же на 100 коммутаторов ставить 45 упс, не проблема, на 10К уже вопрос, везде ли по городу его получится поставить и не придется извращаться с PoE. Монтаж едет с распечаткой это понятно, но при смене коммутатора меняется его мак, что тянет за собой перепривязку в биллинге минимум 20 абонентов, в случае vlan per user виланы последней мили тоже надо указать ручками (хоть до коммутатора они по gvrp дошли), вписать в нужные кольца STP и т.д. Когда мне кажется, я гуглю, а тут у меня более 50К юзеров (не столица и многоэтажки) и разрозненные сети из кучи вендоров и технологий авторизации и я знаю что говорю. Даже внедрение ERP систем не спасает от проблем, когда сгорает свич, например, в выкупленом сегменте сети, где просто нет данных кто в каком порту и монтажник вместо распечатки пол дня по проводам лазит и забивает базу, когда гроза выбивает целый квартал с железом, запитанным по PoE и протянутым по воздушке, про оставшиеся «медные» районы я не говорю. Очень завидую Вам, что все так просто и на автомате, но не у всех и не всегда именно так.
                                                                    0
                                                                    И даже в описаном вами случаи идеальных условий 100 комутаторов 1 раз в пол года, 10 000 коммутаторов — это 100 в пол года или 16 в месяц, или же через день. Опять же на 100 коммутаторов ставить 45 упс, не проблема, на 10К уже вопрос, везде ли по городу его получится поставить и не придется извращаться с PoE. Монтаж едет с распечаткой это понятно, но при смене коммутатора меняется его мак, что тянет за собой перепривязку в биллинге минимум 20 абонентов


                                                                    1. В-основном меняются DES 3200-10 на что-то 24-х портовое, а не по факту выгораний.
                                                                    2. Вы что-то путаете. Смена коммутатора — это смена коммутатора, и только. Кстати производится под абсолютно полным контролем — поле mac адрес в БД, где хранятся устройства — с атрибутом unique, и zabbix эту информацию проверяет. Есть система контроля оборудования — начиная от самописной веб-морды, с помощью которой производятся нужные операции и заканчивая триггерами в самой бд. Каждый чих пишется в лог:
                                                                    дата время: Такой-то сотрудник пометил порт у такого-то устройства (mac устройства), как сгоревший;
                                                                    дата время: Такой-то коммутатор отправлен со склада туда-то. Причина такая-то. Провел такой-то;
                                                                    дата время: такой-то коммутатор заменен на такой-то коммутатор. Причина такая-то. Провел такой-то;
                                                                    Зачем делать перепривязку 20 абонентов в биллинге?

                                                                      0
                                                                      1. У нас по факту выгоряний или сбоев в работе.
                                                                      2. Не путайте инвентаризацию с биллингом, у вас zabbix тарифные планы абонентам назначает, если да то скажите как? Предположим использована схема авторизации по IPoE как биллинг в вашем случае узнает что Иванов Иван Иванович теперь подключен к свичу в маком 00:00:00:00:00:07 а не 00:00:00:00:00:05? Заббикс вам только напишет что у коммутатора xxx.xxx.xxx.xxx сменился мак и занесет его в свою базу, автоматизировать перепривязку абонентов на основе мониторинга — пробовали, любая ошибка оператора в настройке IP свича становится плачевной, если у вас операторы не ошибаются, продайте нам пару этих роботов. Такой-то коммутатор отправлен со склада туда-то, ага именно так в идеальном мире с розовыми единорогами, а по практике выбило район приехала машина забрала 20 коммутаторов и уехала менять, а вот какой куда конкретно попадет загадка для всех. Ладно мы от темы поста отошли очень, предлагаю завершить офтоп.
                                                                        0
                                                                        Все же отвечу. Но продолжать действительно не будем. «Роботы» не ошибаются, как писал foxmuldercp, регламент, регламент и еще раз регламент. Проблемы с грозами — что-то ужасное. Хорошо, что пережили. Нет, действительно. Когда выдернули родное питание и заменили на альтернативное с аккумами проблемы с грозами исчезли. Есть же статистика. Заббикс вообще в этой ситуации не причем. Он только даст нам знать, что какой-то засранец выставил коммутатор без документирования. В биллинге есть ip коммутатора, порт абонента, mac абонента, ip абонента. Конфиги на коммутаторы улетают автоматом. И если будет нарушен цикл подготовки коммутатора — то конфиг он не получит. И работать никто не будет. Предварительный конфиг заливается еще в офисе, генерируем тоже скриптом, для единства конфигурации. Окончательный конфиг заливается автоматом, когда коммутатор появляется в сети. Привязки абонентов обновляются при перебросе абонента с порта на порт, при изменении mac-адреса абонента, при изменении ip-адреса абонента, при указании порта сгоревшим.
                                                                          0
                                                                          Все аналогично, и конфиг базовый залетает автоматом в момент первого включения на техплощадке и на месте почти все (кроме сложных структур STP) автоматизированно, только маки мы не контролируем, отдаем абоненту порт а что он туда втыкает — его личное дело. Вот интересно чисто для себя, зачем вам маки абонентов? Да и какой биллинг используете, я сейчас хочу уходить от UTM5 (сложно дорабатывать) и nodeny (нельзя выдавать динамический адрес) в своих сетях, вот подбираю решение, чтоб подошло для разных структур, если не затруднит — в личку, чтоб не захламлять тему.
                                                                  0
                                                                  Да и с привязкой, если человеку нужно — вы ничего не заметите, большинство роутеров прекрасно прошивается альтернативными прошивками, в базовом функционале которых есть смена мака на wan порту. Но тут кому что нравится. У меня в сетях были следующие этапы: авторизатор, привязка только мак, PPPoE (на нем 2 сети, обслуживающие много частного сектора до сих пор), IPoE (как Vlan per user так и Opt82+address binding) что выбрать очень зависит от структуры сети, железа в наличии и еще кучи факторов. Когда вся сеть строится исключительно по многоэтажкам, где есть техэтажи, есть возможность нормально поставить ящик со свичем и ups — это 1 вариант, когда это частный сектор, сеть чисто воздушка и низкие столбы, на которых даже ящик не повесить нормальный, не то что UPS поставить — это совсем другой вариант (питание по PoE, куча меди и гроза выжигает целые районы). У вашей схемы всего 1 минус, техподдержка задолбется при количестве абонентов более 2К.
                                                                    0
                                                                    pon решает проблемы частного сектора раз и навсегда. И что мешает дать служебный тарифный план абоненту в частном секторе и разместить ящик с коммутатором у него? Тут либо портянка медиаконвертеров в комплекте либо коммутатор с sfp-портами. Если вы пишите про мою схему, то у несколько десятков тысяч абонентов, проблемы у тех.поддержки исчезли, как только эту схему разработали, допилили и внедрили. Надо сказать, что пришлось не просто попотеть — в свое время отказался от всех шабашек и ушел с головой в работу.
                                                                      0
                                                                      Сейчас внедряем pon на последнюю милю, очень со скрипом идет, хорошо если за пару лет закончим. Ящик с коммутатором у абонента решение, но мы теряем доступ к нему 24х7, вот из практики: ящик на чердаке абонента, у абонента халявный интернет все счастливы и довольны, абонент как любой нормальный человек летом берет отпуск и укатывает на 2 недели отдыхать (телефон вне доступа), по закону Мерфи на второй день после отъезда что-то случается с коммутатором(не помню уже что), доступ к дому есть у бабушки-цербера, которая приходит кормить псину и про интернет знает, что это творение дьявола и крестится при любом упоминании, оставить сотню близлежащих абонентов на 2 недели вез сети (резервирование на этот сегмент еще не завели)? Экстренно на столбах делается какое-то подобие ящика, варится и ведется новая оптика и т.д. за срочность выходят затраты как заново перетянуть район — в этой сети этот ящик был последний, стоящий у абонента. У меня ни одна сеть, а несколько, с разным руководством и разными взглядами на развитие, где готовы развиваться и менять структуру, там тоже все гуд, а вот где руководствуются принципом, зачем вкладывать деньги если и так пока все работает, там печально. О чем мы спорим, тут разные ситуации, я просто говорю что не везде и не всегда все идеально, есть автоматизация и передовые решения, как говорится случаи разные бывают, за вашу сеть только рад, если у вас все хорошо и нет проблем.
                                                                      0
                                                                      Чем это её задолбают? Абонентов уже больше 2к и ничего 1.5 человека справляется
                                                                        0
                                                                        Заведите себе книгу жалоб и предложений онлайн без права модерирования ТП, узнаете много нового от абонентов которым нужно было срочно поменять железку у себя. Сам попал в ситуацию, когда пошел помочь знакомым с новым компьютером, а они подключены к сети, админа которой и руководство я не знаю. После 20 минут слушания музыки на номере СТП, а потом объяснения еще 15 минут что я хочу, зачем мне менять мак, называния всех реквизитов, контрольных слов и прочего автоматически записал всю компанию, ее руководство, админа и ТП к сексуальным меньшинствам и на все дальнейшие вопросы любых знакомых или знакомых-знакомых к какой сети подключиться в том районе, говорил к любой, кроме %company_name%
                                                                          0
                                                                          Все зависит от того, как организовать этот процесс. Уверяю Вас это можно сделать нормально.
                                                                            0
                                                                            Ок у вас полтора человека, вам позвонило 3 абонента, первые 2 попали к операторам 1 висит в очереди, при этом первые 2 абонента совсем «не в теме» и решение проблемы по телефону затягивается, третий которому срочно надо поменять mac (вот прямо сейчас) слушает музыку и матюкает вас и вашу ТП. И тут не проблема операторов, они могут быть профессионалы и лучшие люди в городе, не проблема первых 2х абонентов, они дозвонились и их проблему сейчас решают, а вот третий, который в теме, точно знает что ему надо, но вынужден висеть на линии, смотреть на часы и желать вам всевозможных кар, вопрос зачем, если этого можно избежать. Вот зачем вам мак абонента?
                                                                              0
                                                                              mac адрес нужен хотя бы тогда, когда в сети не используется vlan на абонента, а скажем, на 30-40 абонентов, и не используется option 82 (с которым у D-link есть проблемы, сами же сталкивались) и dhcp relay поднят на 3 уровне.
                                                                                +1
                                                                                Если сеть на D-link, то принято, уж очень криво работает с 82 опцией, но это костыль, исправляющий косяки вендора, во всех остальных случая контроль маков лишняя прослойка ИМХО.
                                                            +1
                                                            Как клиент я хочу сказать большое «фи» всем, кто привязывает абонента по MAC'у. А если я железки разные в сеть тыкаю? Дали порт, разрешили/дали IP, усё.
                                                              0
                                                              Пока что не встречал абонентов, у которых есть множество различных железок, и нет денег на роутер. И дело даже не в привязке к mac-адресу — это как надо себя не любить, чтобы не лениться лазить под стол, и кабель то в один компьютер тыкать, то хватать этот кабель и тащить его к другому компьютеру. А как же быть с планшетами и трубками? Сплошной геморрой.
                                                                +1
                                                                В жизни разное бывает. Иногда бывает проще отцепить кабель от рутера и воткнуть в новую железку. Или поменять местами сетевухи. В этих условиях отзваниваться оператору — геморрой и раздражение.

                                                            Only users with full accounts can post comments. Log in, please.