LLMs emerge as practical force multiplier for MikroTik network setup

The author, a self-described networking hobbyist, has spent recent months using LLMs—chiefly Claude—to configure MikroTik equipment, a brand known for reliability and broad networking use cases (routers, switches, wireless systems) but also notorious for a complex configuration interface. Rather than using SSH, the author found the REST/JSON API to be far more effective for LLM-guided setup. The author completed three projects: one migration of a single-router-plus-integrated-WiFi setup to a router-plus-switch-plus-two-wireless-access-points configuration, and two entirely new networks.

Key practical recommendations emerged from this experience. First, disable insecure services (non-secure API port, HTTP, telnet, FTP) and always dump the entire config before and after changes, storing it in version control. For wireless setups, CAPsMAN (a MikroTik centralized access-point manager) is described as "a huge wifi simplifier" and "an absolute breeze" to configure with LLMs. The author employs consensus-checking: asking multiple LLMs (Claude, Codex, Opus, and Fable) to review and double-check configurations to catch errors or omissions. When migrating networks, note SSIDs, passwords, and DHCP reservations beforehand. Crucially, test after every config change—LLMs hallucinate—and maintain a tested recovery runbook with steps to restore from backups. Ensure all devices run the same RouterOS version, since syntax and command options drift across versions. Small but useful touches include setting up NTP (time server) on all devices and assigning descriptive names to devices and switch ports.

The most critical recommendation addresses the worst-case scenario: when IP addresses conflict or overlap (e.g., multiple overlapping 192.168.88.x networks), even a physically connected ethernet device may be unreachable. The author's solution is MAC-Telnet, a Layer 2 telnet server that allows connection via MAC address rather than IP. This is especially valuable for LLM-driven recovery because WinBox (MikroTik's GUI tool) is not LLM-controllable, whereas a CLI tool like MAC-Telnet lets Claude or other models interact with the device autonomously. The author has simplified installation via a Homebrew formula and created a small CLI wrapper to make MAC-Telnet more accessible to LLMs. The author stresses that this tool becomes invaluable "at the worst time"—when conventional IP-based access has failed.

The article reflects a broader trend in which LLMs are being applied to infrastructure and DevOps tasks—domains where precision and domain knowledge have historically been gatekeepers. The author's experience shows both the promise and the peril: LLMs can cut through the steepness of MikroTik's learning curve (complex CLI, many protocols, numerous configuration states) and let semi-skilled operators move faster. However, the author is clear-eyed about the cost—LLMs "still get things wrong, go off-path," and the operator must maintain a tight leash through testing, backups, and version control.

A key insight is the choice of API channel: the author found REST/JSON access far more effective than SSH text piping, suggesting that when LLMs work best with infrastructure, they do so when the interface is structured and machine-readable rather than unstructured terminal output. The emphasis on consensus (asking multiple LLMs to verify a config) and on Layer 2 recovery tools (MAC-Telnet) reflects a mature operational mindset—the author is not claiming LLMs replace expertise, but rather that they accelerate progress for someone who already understands the basics and maintains disciplined practices.

No comments yet. Be the first to share your thoughts!