LLM Networking with MikroTik: Automating RouterOS via Natural Language

What Happened: The Core Concept

A developer recently wired up a system that lets you manage a MikroTik router by typing plain English. No memorizing the RouterOS CLI syntax for queue trees or firewall rules. The system takes a natural language prompt, generates the exact RouterOS commands, executes them against a real device via SSH, captures the output, and then feeds any errors back to the LLM for automatic correction. It is a tight, self-healing loop.

The workflow is straightforward in concept:

1. Prompt: You describe the networking goal (e.g., "limit the guest Wi-Fi subnet to 5 Mbps total download").
2. Generation: An LLM translates that intent into a sequence of /queue simple or /ip firewall commands.
3. Execution: A Python script pushes those commands to the router over SSH and captures the raw console output.
4. Validation & Repair: The output is parsed. If the router throws an error, the error text is sent back to the LLM with a request to fix the commands.
5. Verification: A final "read-only" command (like /queue simple print) is generated and run to confirm the configuration stuck.

This isn't a theoretical demo. The source project used a real MikroTik hAP ac² and successfully configured complex features like QoS queues and firewall address lists through this loop. You can read the original walkthrough here.

Why It Matters for Engineers and FDEs

For network engineers, this isn't about replacing CLI mastery—it's about collapsing the gap between intent and implementation. You think "isolate this IoT VLAN," and the system drafts the 15 lines of config while you focus on architecture.

For Forward Deployed Engineers (FDEs), the implications are even more tactical. An FDE often lands on a customer site with deep product knowledge but surface-level knowledge of the customer’s specific network hardware. If you're deploying an on-premise appliance that needs to shape traffic or open specific ports, being blocked by unfamiliar syntax is a time sink. An LLM networking agent can be the adapter that translates your deployment playbook into the customer's native hardware language.

This directly impacts the metrics FDEs live by. As we discussed in Metrics an FDE Actually Owns, time-to-value (TTV) is paramount. If you can reduce a network provisioning step from a 30-minute CLI slog to a 2-minute prompt, you accelerate the entire deployment. This isn't just a convenience; it's a competitive moat during the on-site crunch.

How to Build It: Architecture and Workflow

Before diving into code, let's visualize the self-correcting loop. The system is a state machine that cycles between generation, execution, and repair until the router returns success.

The magic is in the error-repair loop. RouterOS has notoriously terse error messages. The LLM's ability to interpret "no such argument (rate)" and realize it should have used max-limit instead is where this system shines.

A Practical Walkthrough

Let's break down the components you need to replicate this. The original project uses Python, but the principles are language-agnostic.

1. The System Prompt (The Secret Sauce)

The LLM doesn't magically know RouterOS. You must prime it with a rigorous system prompt. This prompt must be opinionated and defensive:

• Forbid dangerous commands: Explicitly ban /system reset-configuration, /file remove, and unguarded /ip firewall filter set rules that could lock you out.
• Enforce safe mode: Instruct the LLM to wrap generated scripts in a safe-mode pattern where possible, or at least generate a rollback command.
• Define the output contract: The LLM must output a strict JSON object with a commands array and a verification_command string.

Here’s a sanitized snippet of what that prompt enforces:

{
  "commands": [
    "/queue simple add name=guest-limit target=192.168.88.0/24 max-limit=5M/5M"
  ],
  "verification_command": "/queue simple print detail where name=guest-limit"
}

This structured output is critical. It prevents parsing nightmares when extracting the script from the LLM's response.

2. The Execution Layer

You need a robust SSH wrapper. The paramiko library in Python is the standard choice. Key implementation details:

• Invoke the shell: Don't just execute a single command. Invoke an interactive shell so you can send multiple lines and read the cumulative output.
• Non-blocking reads: RouterOS can be chatty. Loop reads until you get the prompt back (usually [admin@MikroTik] >).
• Escape characters: Strip ANSI color codes from the output before feeding it back to the LLM. Clean data prevents hallucination spirals.

3. The Self-Correction Loop

This is the state machine from the diagram above. The Python script acts as the orchestrator:

1. Call the LLM with the user prompt.
2. Parse the JSON.
3. Push the commands list to the router.
4. If the output contains failure or bad command name, construct a new prompt: "The RouterOS command failed with error: [error text]. Fix the JSON."
5. Feed this back to the LLM. Repeat until success or a max-retry limit (3 is a good number).
6. Run verification_command and return the proof.

This pattern of AI agent self-repair is powerful beyond networking. If you've built systems like a Gmail AI Triage Agent, you know that error handling is what separates a brittle demo from a reliable tool.

4. A Local, Private Agent

A key design choice in the reference project was running the LLM locally via Ollama (using a model like Llama 3). For network engineers, this is non-negotiable. You cannot send your firewall configurations to a public API. Running a local model keeps your network topology private and avoids latency. If you need a lightweight local setup, the principles are similar to training a generative model on a tight GPU budget—optimization is everything.

A Balanced Take: Strengths and Gotchas

Let's be honest about where this works and where it stumbles.

Where It Wins:

• QoS and Simple Queues: Syntax is repetitive and parameter-heavy. LLMs nail this.
• Address Lists: Adding/removing IPs from firewall groups is a chore. Natural language makes it instant.
• Bulk changes: "Add these 20 MAC addresses to a filter rule" is a 10-second prompt instead of a script.
• Cross-vendor translation: An FDE who knows Cisco can prompt "create a MikroTik equivalent of this Cisco ACL" and get a solid first draft.

The Gotchas:

• Hallucination is dangerous: An LLM might invent a parameter that doesn't exist. The self-repair loop catches syntax errors, but it won't catch a logically valid but semantically wrong rule that opens a security hole. Always review the generated script.
• Stateful awareness: The LLM doesn't know the current state of your router unless you feed it a full /export. Without context, it might create conflicting rules or fail to edit an existing item by its correct .id.
• Token costs and speed: Local models avoid API costs but run slower on consumer hardware. Waiting 30 seconds for a queue tree is fine for lab work, but frustrating during a production outage.
• Safe mode isn't foolproof: RouterOS safe mode rolls back changes if the SSH session drops, but a malicious or accidental /quit in the generated script defeats it.

FAQ

Can I use this with Cloud Hosted Routers (CHR)? Yes. The SSH connection is standard. Just ensure your CHR accepts SSH connections from the host running the LLM agent. Latency might increase slightly, but the self-repair loop handles timeouts gracefully.

Does it support RouterOS v6 and v7? The LLM's accuracy depends on its training data. Most models know v6 syntax well. For v7 (which introduced new routing and wireguard syntax), you must explicitly state the version in your system prompt to avoid generating deprecated commands.

What's the minimum hardware for a local LLM? For a 7B-8B parameter model quantized to 4-bit, you can run this on a machine with 16GB of RAM and a modern CPU. A dedicated GPU like an RTX 3060 (12GB) makes it interactive-speed.

Is this replacing network engineers? No. It's a force multiplier. You still need deep knowledge to validate the generated configs, understand network architecture, and handle edge cases the LLM misses. It handles the typing; you handle the thinking. For FDEs, it's a way to maintain velocity across diverse environments, similar to how building a RAG chatbot over your PDFs augments your memory, not replaces it.