LLM Networking with MikroTik
Jul 14, 2026
I’ve been refraining from saying ‘vibe networking’ or ‘vibkrotik’ or some other abomination, but it is true - I have been using LLMs to setup a few networks these last few months, and things have generally gone over swimmingly.
I’ve been a fan of MikroTik equipment for a while - the short story is that the equipment is reliable, inexpensive, and they cover a ton of networking use cases - IoT cell phone routers, regular routers, switches, point to point systems, etc.
One of the usual complaints about MikroTik has been its complex ui/configuration. In a sense, I don’t know if that’s true inasmuch as networking is complicated in itself - as in, it goes deeper than one thinks? Maybe there should be a iceberg-format meme about this. At the top you’d have “ip address”, and going deeper you’d see “the dude” and other you’ve-never-heard-of-them’s. mpls! igs! ospf!
The point I’m trying to make is yeah, networking can just be hard. I’ve been half-networking, amateur-ishly, for a while now - setting up networks for friends and friends’ offices, making cables, patching small panels etc. I almost certainly couldn’t pass an official “Certified Routing Engineer” cert - well, not without studying a lot (believe in yourself).
But you know, it hasn’t stopped me (and I suppose it shouldn’t?) from having fun and fixing people’s wifi (most people’s wifi problems can be categorized into… oh brother - I should make another post about this. Never use extenders.)
Where do LLMs fit in? Well, as elsewhere (in coding, etc.) they are a chaotic force multiplier - they definitely know how to configure MikroTiks and networking in general, but they also still get things wrong, go off-path, etc. As with coding, you can/should keep a tight leash, mis-trust and verify, but you can also make more progress faster ((remember the 2025 study that said that LLM speedups were not real - well…)).
And so these last few months I’ve been able to setup networks - small, for sure - and had a lot of fun giving claude code access to my devices and letting it do its thing. (As I discussed here, yes, I do mean dangerously-skip’ing-permissions).
I’ve compiled a short list of hopefully useful notes on this topic - in one case, I was migrating an existing network (a very small single-router-with-integrated-wifi to a router+switch+two wireless access points), while in two other cases the networks were net new.
In any case, here’s my list of LLM MikroTik tips and tricks:
even though mikrotiks can be configured over ssh, there’s a “death by a thousand cuts” that tends to happen when llms try to pipe text back and forth that way. the much better (ie more llm native) channel is to use the REST/JSON api.
as a generally-good-practice, I recommend disabling insecure services - the non secure api port, www, telnet and ftp
dump the entire config before any change, and dump it once you’re done. source version controlling those is great. having some automated backup tool (which I haven’t gotten around to build yet) would be the best
CAPsMAN is truly a huge wifi simplifier to setup multiple wireless access points - configuring it with llms is an absolute breeze
I often come back to the “trick” of asking multiple llms - antigravity, codex, opus and fable - to double check the config and come to a consensus to see if anything is missing or terribly wrong.
perhaps obvious, but before tearing down a network (when migrating to a mikrotik), take note of ssid’s, passwords, dhcp reservations
have a recovery runbook! take down the steps of what to do if you need to restore all of your devices’ configs from a good-known-place (hence, backing up your configs). run the runbook - an untested backup might as well be a file full of zeros.
as often is the case with llm’s, minimize the tasks and go step by step. yes, this is the “setup my network don’t make mistakes” joke - don’t do that. test after every config change. llms hallucinate!
very small thing, but it’s useful to setup ntp (time server) on all of the devices you’re configuring
also small, but for sanity’s sake, it’s good to give descriptive names/identify your devices - your router, switch, wireless access points. do the same for ports on a switch - it can be a bit of a pain to maintain as devices move around, but knowing which port connects to what comes in handy a lot.
make sure to update all of your devices so they’re running the same routeros version - llms also sometimes think they know how a command works but the syntax/options change over time - ask them to verify.
Oh, and finally!
I’ve been in situations (or maybe the LLM led me down this path..) where IP addresses are conflicting, you have multiple overlapping 192.168.88.x networks, and it’s generally a mess and hard to even connect to the router or switch, even if you’re physically connected to those devices over ethernet (which you should always be)
The best tool for this in my opinion is the L2 “MAC Telnet” ie a server that lets you telnet over the L2 (MAC-address) layer. It’s sort of the equivalent of using WinBox (which to my surprise is now cross-platform, and works quite well on Macs) - except that having an L2-layer telnet client allows your LLM to talk to your MikroTik devices. WinBox is a GUI software that LLMs can’t control.
For this, I deeply recommend MAC-Telnet - it will come in handy at the worst time ie when IP addresses don’t work! I/Claude just built a tiny Homebrew formula to make its installation easier, but you can also follow the original installation instructions - it’s the same code. I also made this small CLI just to make MAC-Telnet a bit more LLM-friendly to consume/use, but generally speaking, LLMs will figure out how to use a CLI tool by themselves. You don’t need an MCP server.
Have fun - and feel free to tell me I have it all wrong (it’s happened before). Bye!! xx