В качестве вводных, имеется довольно крупная сеть на базе решения Cisco, эксплуатируемая уже более 10 лет и состоящая из: 1 348 зданий и сооружений; 10 030 разнотипных точек доступа производства, начиная с откровенного старья AIR-LAP1131G, AIR-LAP1041N (около 88% от общего числа), заканчивая вполне себе неплохими CAP1602I, CAP2602I, CAP1702I, AP1832I; WISM1, WISM2, WLC 8540. За более чем 10 лет эксплуатации кабельные линии стали приходить в негодность в результате различных перепланировок и капремонтов. Большое количество точек доступа и инжекторов питания стало выходить из строя, что вкупе с тенденцией роста потребления трафика привело к постоянным жалобам на качество сервиса. С учетом сроков и возможностей бюджета решено, что на первом этапе модернизации будут подвергнуты сети в 589 зданиях, решение о дальнейшей модернизации будет принято после анализа последствий текущей модернизации.  Сформулированы следующие задачи: замена вышедших из строя и устаревших точек доступа новыми и современными; обеспечение покрытия дополнительных зданий и помещений; замена коммутаторов доступа и инжекторов питания на PoE коммутаторы; реконструкция существующих кабельных линий связи и формирование новых от активного оборудования до точек доступа. С учетом сроков поставки, первое, что мы должны сделать - это заказать точки доступа. Как определить какое количество точек доступа потребуется, правильно - провести радиоразведку при помощи Ekahau. Объехать все 589 объектов с учетом расстояний нереально, в связи с чем принято решение обследовать часть сооружений разных типов планировки и размещения, городские, в крупных населенных пунктах и в небольших селах, результаты экстраполировать на все объекты.  Cказано - сделано, написаны инструкции  для наших выездных инженеров и в кратчайшие сроки обследовано 89 зданий и сооружений, полученные данные немедленно загружены в Qlik и подвергнуты всестороннему анализу. Рассматривалась общая площадь помещений, количество пользователей и текущее количество точек доступа. В результате получили, что для организации сети на 589 объектах потребуется 8014 точек доступа (забегая немного вперед, скажу, что погрешность нашей экстраполяции не превысила 1% :). И так необходимое количество мы вычислили, осталось выбрать какие точки доступа будем закупать. Имея обширный опыт организации беспроводных сетей мы в свое время обратили внимание на достаточно неплохое решение для организации небольших сетей на базе связки Mikrotik cAP AC + CRS328-24P-4S+RM в качестве PoE коммутатора и CapsMan. Перспективы управлять 589 CapsMan нас не сильно смущала, благо есть опыт написания “Мониторилки точек доступа”, Ansible нам также знаком не понаслышке. Однако наш старый и добрый партнер, компания Cisco, сделала такое предложение, от которого не смог бы отказаться сам дон Корлеоне :). Итак заказываем у Cisco точки доступа и пока они едут идем дальше … В первую очередь приняли решение, что все точки доступа имеющиеся на объекте демонтируются и заменяются на новые AIR-AP1815I-R, это облегчит логистику и пусконаладку нашим монтажникам. Демонтируемые точки доступа, а их ни много ни мало 4175 штук, решено использовать в дальнейшем в качестве ЗИП, для оставшихся объектов. Также решили, что для каждого объекта необходим радиопроект в том же Ekahau иначе гарантировать покрытие невозможно, однако для качественного проектирования  необходимы качественные исходные данные. К тому времени решили, что монтажом будет заниматься подрядчик, вот его то и решено было привлечь для сбора исходных данных. Для обмена информацией тяжелыми данными с подрядчиком предложено свободно распространяемое приложение Nextcloud, для консолидации информации и контроля за ходом работ предложен Google Sheets, теперь поехали…. :) Несмотря на кажущуюся сложность схема получилась простой и логичной. Подрядчик выезжает на объект и попутно фотографирует планы БТИ на которых указывает помещения в которых появилась потребность в сети или выявлены проблемы в покрытии, результат выкладывает в заранее подготовленную папку в облаке. В свою очередь мы готовим схему расстановки точек доступа, также кладем в облако. Пока точки доступа едут, монтажники  занимаются протяжкой кабельных линий. Но самое интересное начинается по мере поставки коммутаторов и точек доступа, за этим мы и собрались написать эту статью, так как на просторах Интернета аналогичных решений мы не нашли и захотелось поделиться реализацией вдруг кому поможет. Используем строго OpenSource: Graphite + Graphana — мониторинг состояния точек доступа; SQLite — хранение данных; Python и BASH —  скрипты; Telegram bot — проверка состояния точек. Как уже отмечалось перечень объектов и количество точек доступа мы выложили в Google Sheets вот ее итоговый вид: Все сходства наименований с реальными объектами вымышлены и не имеют ничего общего с реальностью :)  Первое, что нужно сделать — собрать исходные данные, делаем это bash скриптом для опроса контроллеров WLC по SNMP: В итоге имеем 4 файла, которые пишем в базу SQLite: Далее получаем данные из Google Sheets и пишем базу данных SQLite, процесс хорошо описан здесь, текст скрипта: Далее переименовываем точки доступа скриптом: Таким образом монтажники заполняют MAC адреса установленных точек доступа, при этом каждая точка доступа имеет свой hostname - наименование и номер, в соответствии со схемой расстановки. Скрипт на основании МАС адресов точек доступа, указанных монтажниками, переименовывает точки доступа. Вопрос конечно можно было попытаться решить административным путем, наказывая за ошибки и несоответствия рублем, но мы нашли более интересное решение. А именно telegram.bot, обратившись к которому с запросом содержащим “код объекта” можно было получить статус всех точек доступа на объекте, для этого используем библиотеку telebot, текст скрипта: Пример работы бота: none - говорит о том, что точка доступа не найдена ботом, возможно точка доступа не ассоциирована с контроллером или есть ошибка в MAC адресе; 100 - говорит о том, что параметр eth0 speed точки доступа равен 100Mbps;  1000 - говорит о том, что параметр eth0 speed точки доступа равен 1000Mbps. С учетом того, что точки доступа подключаются к PoE коммутатору с гиговыми портами, монтажники должны были самостоятельно добиваться параметра eth0 speed = 1000Mbps без нашего участия. Таким образом был исключен сценарий, в котором нам пришлось бы долго и нудно выяснять почему точка доступа с MAC адресом 1 не наблюдается на контроллере или почему точка доступа  с MAC адресом 2 наблюдается на контроллере, при этом не понятно на каком объекте она стоит. А также исключены “терки” вида: Мы: почему точка доступа 1 переименована как точка доступа 2? Монтажник: ну так вы же переименовываете не мы; Мы: тогда, что за точка ассоциировалась на контроллере, МАС адреса нет в таблице; Монтажник: не знаем это не наша зона ответственности, все МАС адреса мы внесли в таблицу. В общем кто хоть раз организовывал монтажные работы понимает о чем идет речь. Для того чтобы уложиться в сроки мы были вынуждены разрешить монтажникам удлинять кабельные линии при помощи соединителей, таких: или при необходимости таких: Эта вынужденная мера оправданная ограниченностью сроков и бюджетов оказалось неплохой идеей, но принесло нам дополнительные проблемы. Из за наличия соединений в кабельных линиях параметр eth0 speed на некоторых точках доступа постоянно флапал между значениями 100 и 1000, при этом в логах PoE коммутатора можно было встретить сообщения вида: detected poe-out status: current_too_low. Понятно, что со временем деградация таких кабельных линий может привести к невозможности предоставления сервиса.  Как же не допустить приемку таких кабельных линий? Ответ нашелся довольно быстро с использованием свободного ПО Graphite. Хотелось бы обратить внимание на один нюанс. По умолчанию Graphite запоминает метрики только за последние 6 часов. Исправим это в файле конфигурации: nano /path/to/graphite/configs/storage-schemas.conf[carbon] pattern = ^carbon. retentions = 60s:90d [default1minfor_1day] pattern = .* retentions = 1m:7d,5m:30d,30m:90d,24h:1y Важно: Если были уже добавлены объекты, к ним это не примениться. Необходимо изменить это во всех wcp файлах: Далее пишем параметр eth0 speed получаемый с точек доступа отчетами каждые 5 минут в Graphite простым скриптом: Вот пример поведения точки доступа, видно, что интерфейс систематически меняет параметр speed, а иногда и совсем отваливается: Полученные данные за 6 дней усредняем скриптом : И пишем в таблицу: Путем опытного наблюдения за поведением уже смонтированных точек доступа, а их на момент написания статьи более 7500, приняли, что линии связи на которых точки доступа имеют средний параметр eth0 speed ниже 970, требуют реконструкции. Начиная от переобжимки RJ45 разъемов и заканчивая при необходимости заменой кабеля. Количество таких проблемных линий на момент написания статьи составило более 10% от числа наблюдаемых точек доступа. Задача монтажников до нового года обеспечить на 100% кабельных линиях средний eth0 speed не ниже 970. Надеюсь статья окажется полезной, вопросы пишите в комментарии ...