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 networking. 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.

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, and mis-trust/keep-verifying, but you can also make more progress faster.

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.

I’ve compiled a short list of maybe/hopefully useful notes for myself - 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, if useful, here’s Greg’s 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. the much better (ie more llm native) channel is to use the REST/JSON api.
  • I recommend disabling insecure services - the non secure api port, www, telnet and ftp
  • dump the entire config before any change, and dump it again after. 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 - 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
  • having a recovery runbook helps! take down the steps of what to do if you need to restore all of your devices’ configs from a good-known-place. 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 one by one. 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 devices you’re configuring
  • also small, but for sanity’s sake, it’s good to name/identify your devices - your router, switch, wireless access points, and use descriptive names. 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 do change - 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 all over, you have 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 answer 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. Having a L2 telnet client allows your LLM to talk to your mikrotik - WinBox is a gui 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.

Have fun - and feel free to tell me I have it all wrong. Bye!! xx