MikroTik: разработчик настраивает сети через нейросети и делится приёмами
Разработчик Грег Садецкий (gregsadetsky) опубликовал в блоге пост о том, как последние несколько месяцев использует большие языковые модели для настройки сетей на оборудовании MikroTik, в одном случае мигрировал небольшую сеть с одного роутера со встроенным wifi на связку роутер+свитч+две точки доступа, в двух других строил сети с нуля. Он в шутку называет это «vibe networking» («сетевание на вайбах») или «vibkrotik», но сам подход описывает всерьёз: LLM выступают как силовой множитель, похожий на их роль в написании кода, заметно ускоряют работу, но регулярно ошибаются и уходят не туда, поэтому требуют постоянной проверки. Для части задач он давал Claude Code прямой доступ к своим устройствам в режиме без подтверждения каждого действия (dangerously-skip-permissions).
Из практических выводов автора: настраивать MikroTik через LLM лучше не по SSH (там текст в двустороннем обмене «умирает от тысячи порезов»), а через REST/JSON API, он куда естественнее для модели; стоит сразу отключать небезопасные сервисы (незащищённый порт API, www, telnet, ftp); перед любым изменением и после него нужно снимать полный дамп конфигурации и хранить его в системе контроля версий. Функция CAPsMAN сильно упрощает настройку сразу нескольких точек доступа wifi через LLM. Для проверки итоговой конфигурации автор просит несколько разных моделей, Antigravity, Codex, Opus и Fable, независимо свериться и прийти к общему мнению, не упущено ли что-то и нет ли грубых ошибок.
Перед разборкой старой сети важно заранее зафиксировать SSID, пароли и резервирования DHCP, а также держать проверенный (реально протестированный, а не только написанный) план восстановления конфигураций устройств из бэкапа, непроверенный бэкап автор сравнивает с файлом из одних нулей. Задачи для LLM нужно дробить и двигаться шаг за шагом, тестируя после каждого изменения, потому что модели галлюцинируют и могут придумать несуществующий синтаксис команды. Дополнительные мелочи: настроить NTP на всех устройствах, давать понятные имена устройствам и портам свитчей, следить, чтобы все устройства работали на одной версии RouterOS, синтаксис команд между версиями иногда меняется, и модель может этого не знать.
Отдельно автор разбирает ситуацию, когда IP-адреса конфликтуют и несколько сетей перекрываются в диапазоне 192.168.88.x, из-за чего трудно подключиться к роутеру или свитчу даже по прямому кабелю. Для такого случая он рекомендует MAC-Telnet, telnet поверх L2 (MAC-адресного) уровня, аналог WinBox (который, по его словам, неожиданно стал кроссплатформенным и хорошо работает на Mac), но в отличие от WinBox с графическим интерфейсом MAC-Telnet как консольный инструмент доступен для управления через LLM. Автор вместе с Claude собрал небольшую Homebrew-формулу для упрощённой установки MAC-Telnet и написал маленькую CLI-обвязку, чтобы инструмент было удобнее использовать модели, при этом отдельный MCP-сервер для этого не понадобился, LLM сама разобралась, как пользоваться обычным CLI.
Ключевые факты
- Разработчик несколько месяцев настраивает и мигрирует сети на оборудовании MikroTik с помощью LLM, в том числе давал Claude Code доступ к устройствам в режиме без подтверждения действий
- Ключевой совет: настраивать MikroTik через REST/JSON API, а не по SSH, так LLM меньше ошибается
- Перед изменениями и после, полный дамп конфигурации в систему контроля версий; конфигурацию проверяют сразу несколько моделей (Antigravity, Codex, Opus, Fable) для консенсуса
- Нужен протестированный план восстановления конфигураций из бэкапа и синхронная версия RouterOS на всех устройствах
- Для конфликтов IP-адресов и перекрывающихся подсетей 192.168.88.x автор рекомендует MAC-Telnet, L2-telnet, которым, в отличие от графического WinBox, может пользоваться LLM
Почему это важно
Настройка сетевого оборудования традиционно считается уделом сертифицированных инженеров, сама область признаётся сложной даже опытными пользователями MikroTik. Пост показывает, что LLM способны взять на себя заметную часть этой сложности, действуя как силовой множитель, так же, как это происходит в написании кода: ускоряют работу, но не заменяют проверку человеком.
Кому это важно
Материал полезен сетевым инженерам, системным администраторам и энтузиастам домашних лабораторий, которые работают с оборудованием MikroTik и рассматривают LLM как помощника в настройке. Также интересен более широкому кругу читателей, следящих за распространением «вайб-кодинга» и агентных практик за пределы разработки ПО, в инфраструктуру и сетевое администрирование.
Как это применить
Конкретные приёмы из поста: работать с MikroTik через REST/JSON API вместо SSH; отключать незащищённые сервисы (небезопасный порт API, www, telnet, ftp); снимать полный дамп конфигурации до и после изменений и версионировать его; использовать CAPsMAN для настройки нескольких точек доступа wifi; сверять итоговую конфигурацию несколькими разными LLM для консенсуса; фиксировать SSID, пароли и DHCP-резервирования перед разборкой старой сети; держать протестированный план восстановления из бэкапа; дробить задачи и тестировать после каждого шага; настраивать NTP; давать понятные имена устройствам и портам; синхронизировать версии RouterOS на всех устройствах; для конфликтов IP-адресов использовать MAC-Telnet как L2-канал, доступный LLM (в отличие от графического WinBox).
Можно ли доверять
Это личный опыт одного разработчика в его блоге, а не исследование или бенчмарк, выводы анекдотические и основаны на нескольких небольших сетях. Сам автор честно отмечает, что LLM регулярно ошибаются, «уходят не туда» и галлюцинируют синтаксис команд, поэтому весь материал построен вокруг темы проверки и перепроверки, а не слепого доверия модели.
Риски и подводные камни
Автор сам работал с реальными сетевыми устройствами через Claude Code в режиме без подтверждения каждого действия, при ошибке модели это может привести к потере связи с оборудованием или простою сети. Отдельно описан сценарий, когда конфликт IP-адресов и перекрывающиеся подсети делают устройства недоступными даже по прямому кабельному подключению. Непроверенный план восстановления конфигураций из бэкапа, по словам автора, по сути равносилен его отсутствию, то есть риск не в самих LLM, а в отсутствии дисциплины бэкапов, версионирования и пошагового тестирования вокруг них.
«Как это часто бывает с LLM, дроби задачи по минимуму и двигайся шаг за шагом... тестируй после каждого изменения конфигурации. LLM галлюцинируют!»
— Грег Садецкий, блог greg.technology