I've been a long-time fan of Mikrotik. I even ran an ISP on it a fair while ago. I have a couple of archived GitHub projects if they are useful to anyone:
- Router OS Diff - Can diff two configs and give you the commands needed to bring the existing config up to date with the desired config. It's certainly not perfect, but a starting point of anyone needs something like this. [1]
- Netbox Routeros – A netbox plugin for updating the config of RouterOS devices directly from the Netbox interface. [2]
It has been many years since I touched these, but perhaps they will be of interest to someone.
Aside from that, I have had excellent experience with Mikroik. Everywhere from in-datacenter to it running in an off-grid hut on a mountainside. I've even heard reports of people finding rain streaming through a CRS and it just happily ticking along.
MikroTik recently updated their documentation site from an Atlassian Confluence Wiki to much more AI-friendly Docusaurus here: https://manual.mikrotik.com/
Any page can be easily converted into Markdown by appending .md to the URL. I mention this because in my experience, the agent is much more accurate when it has access to the docs.
It’s interesting to observe and build LLM-driven solutions in Networking.
The biggest challenges that most of us networking people have are around velocity (how fast we can build and scale networks) and how effectively we can operate them (avoid defects, fix them fast when something breaks).
LLMs are great in both areas. AI helps with deployment challenges by speeding up tooling development and the creation of workflows on orchestration platforms. A manual process step today, say - reserving an IP address in an IP DB — is automated the next day instead of on a backlog for years. This post is an example of that (config-gen/config-deploy).
Operations use-cases are more interesting, IMO, and address the “too many signals” problems that we face. Network substrate telemetry, overlay telemetry, service host metrics, service metrics, customer metrics, recent change data, prior alarms - the list goes on. Being a network operator is not for the faint of heart and is under-mentioned on high stress job lists. AI makes AMAZINGLY good network operations triage agents, since they are able to immediately process so many signals.
Nuance. LLMs are just going to report that they cant SSH to an endpoint, after delivering your vibeconfig, and throw it back to you to resolve connectivity. Your velocity with LLMs will stall at break fix every time.
>AI makes AMAZINGLY good network operations triage agents, since they are able to immediately process so many signals.
I have seen a lot of tokens spent on solutions that could have just been grafana.
I'm a network engineer at a F500 and am no stranger to automation. We use a lot of Ansible and Terraform to manage both on-prem and AWS network infrastructure. Lots of Juniper and Cloudflare products, and we use NetCM, Netbox, Prometheus, and Grafana. But we've been playing with agents since late 2024, and our team has come a long way since then.
It was already easy enough and straightforward to deploy a network because we had built so many CLI tools to handle what we needed, but it still required a bit of a human touch to validate outputs and feed those to different tools. Thanks to skills with helper scripts, we're pretty close to one click deployments these days. So much of our maintenances or operations can even be handled from our phones. We can just tell an agent that there's a new version, or AMI, and we can reliably trust them to safely update the fleet from end to end without causing service disruptions. When customers need updates made, agents draft the PRs and I just review, and they deploy after I approve.
I would argue that most of what makes this possible though isn't LLMs themselves, but having invested in robust network design, consistent standards (snowflake setups or configs will cause you problems), proper observability, and detailed docs/runbooks. While I have my doubts that someone will ever be able to vibe code that knowledge and experience, you can certainly use agents to amplify an already strong engineering foundation.
>While I have my doubts that someone will ever be able to vibe code that knowledge and experience, you can certainly use agents to amplify an already strong engineering foundation.
I would expect LLMs to be especially excellent at configuring Mikrotik stuff, given MT publishes markdown reference docs for LLM ingestion, the full config without secrets can be dumped to one text file, and their cli commands are very stable between versions.
I switched recently to OpenWrt from MT, which code agents are also good at. I'd wager most issues are going to be related to the user not specifying what they want clearly enough. The translation from network concepts to RouterOS config is pretty 'fat-free', so there's not much room for hallucinations beyond syntax errors, which can be verified via the API.
Yes! Recently connected two disparate systems (ubiquiti and mimrotik) using their exposed API’s and a Claude session so that systems I have on either environment could talk to each other. I am not a network engineer so it was liberating to get my gear working together. That said it’s a work in progress and just today I noticed something weird that one of my computers can’t access Minecraft servers while the rest of my network can
Probably a routing issue. Shot in the dark would be that one of these routers is NATing traffic, and the other router doesn’t have a route to that NAT’d range.
Vendor terminology is often different (tagged VLANs vs trunking, etc.) but, in general, it is close enough that an experienced person can figure it out with a bit of googling. I've built networks with Cisco, Mikrotik, Aruba/HP, custom Linux routers, and others. Mikrotik VLANs are a bit weird, for sure.
In today's world, is generally easy to get things to communicate. It's not 30 years ago and nobody is running DECnet, Appletalk, or IPX.
The important thing you need to do is specify which Mikrotik version you're using; apparently the syntax for some things changed between 6 and 7.
It does pretty well, but you need to iterate. I was trying to get it to disallow internet access for non-DHCP clients, and in the end there were so many limits to what was possible that it wasn't worth it. But it did it, and when I was testing I found them.
So like everything for best results you need to know what you're doing so you can test effectively...but it saves you from learning the syntax etc.
LLMs as tech support is such a game changer. I have a fun complicated home network with a Mikrotik and a NAS and my desktop and laptop plus various radios and Raspis, and there's no way I could configure the extremely complicated RouterOS on my Mikrotik without AI. The speed is also helpful. Previously if my network went down I would have to wait until the next weekend to fix it because it would take me all day. Now I can get things back up in an hour or less.
I want something similar to this but for Ubiquiti. I don’t need anything fancy, just something that audits my home config and tell me if I’m doing something stupid, dangerous, or both.
Same. Recently Ubiquiti has been putting more and more into the local API, so this should be getting easier to do. The Home Assistant UniFi integration just recently has started moving from private undocumented API endpoints to the newer public API endpoints.
In other news, Meraki has an AI assistant feature now.
I've been doing some of this too. It's great just messaging claude in discord when I want to make a new device's IP static. I also put my mikrotik config sans passwords in (local only) version control, just in case.
And perhaps it's significantly easier on other routers, but I would not have gotten VLANs working without claude doing it for me...
I only have the agent investigate directly. To actually configure the Mikrotik, I have the agent write a script that is aimed to be idempotent and then run the script. Investigation is fine, but the script acts as a memory of intent which I find useful. As agents get better, it can be a textual representation rather than a script, but for now that suffices.
> I have the agent write a script that is aimed to be idempotent and then run the script.
You can take this one step further and have the agent write Terraform configs [1]. I did this (including having the agent import all the initial resources from the live device), works great and is generally more robust than a script.
I originally wrote specific terraform providers (even one for just configuring an Ubuntu machine), but over time I found that TF is a bit too heavyweight for my use-cases. The shell script works well because state divergence can be investigated by the LLM. The slowness of state refreshing etc. does make a TF apply painful. For me at least.
> As agents get better, it can be a textual representation rather than a script, but for now that suffices
I can’t see any reason to have agents do what a script can do. If the operation is deterministic then why pay every time it gets done? This is why MCP seems so pointless to me.
It's adaptive and can handle config drift if someone has altered the machine in the meantime between script invocations. Not required if you're disciplined, of course.
> ... WinBox (which to my surprise is now cross-platform, and works quite well on Macs)
Winbox having a Linux and Mac version is really nice... I'll have to try the Linux one at some point... hopefully it works as good as the Windows version did under wine.
I’ve been using ChatGPT to configure my mikrotik gear for about a year it’s pretty awesome. And the end result is well documented reusable scripts rather than my usual set of random stack overflow copy pastes and shitty inscrutable notes
MikroTik is one of the only companies that sells a router without WiFi at a non enterprise price. Useful for me to completely turn the power off at night to a separate WiFi (router in Bridge mode).
Mactelnet is infinity useful, no need for terminal servers, you can bounce from your second mikrotik and reset the config no matter how screwed up your config.
A word of warning, my experience with mikrotik in the WiFi-6 space has been overwhelmingly negative, both in a single AP setup at home and on a corporate WiFi network managed by someone else.
Bugs, random drops, poor performance on some machines. It is not set and forget and I gave up on it.
Interesting that sending things like network configurations, keys, and credentials to external entities - which BTW are fueled by data - is considered "ok" now.
Is there anything here that suggests that? You are jumping to conclusions easily.
It's nowadays the default not to export any credentials when exporting MT configs, and even doing that yourself is trivial. Since the equipment is pretty packed with functionality and very flexible, benefits of LLM assistance is big.
As for "sending network configurations" it's a risk everyone needs to consider individually. Having that private may make attackers job harder, but security by obscurity ain't no replacement for a secure setup.
When I was setting up Wireguard server at home, the last step (after testing the setup) was the LLM giving me a set of commands to run manually to regenerate the credentials.
>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
Really? Its standard point and click engineer stuff. The biggest issues with Mikrotik are the features not implemented in the gui, or the way config is interpreted between versions. Also the term of hardware support, and generally flaky code in general.
>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).
Ok so just a hobbyist perspective.
It seems like this article is just "Point an LLM at your mikrotik api, have fun"?
My issue with Mikrotik is that the UI puts all the complexity up front. A good UI should guide the user and reveal relevant information only as it's needed. Mikrotik doesn't do that.
For example, the most common reason I want to connect to my home router is to see what devices are connected, what their IP addresses are, and perhaps make their DHCP leases static. In a good UI that sort of common activity would be front and centre - in MikroTik it's buried under 3 levels of menu.
Under the IP menu is 26 alphabetically sorted options, of which I have to click "DHCP Server". Then the default page is to create a new DHCP server - why would I want to do that? How many users run multiple DHCP servers? I have to click on the "Leases" tab, and then I can see a list of my connected devices.
Every other home router I've used knows that users care about the connected devices, so show it front and centre.
>For example, the most common reason I want to connect to my home router is to see what devices are connected, what their IP addresses are, and perhaps make their DHCP leases static.
You sound like a Windows user who just found his way into Active Directory.
>in MikroTik it's buried under 3 levels of menu.
Its buried 3 levels deep in a hierarchy, the hierarchy you need to learn to operate the system. Quickset is Mikrotiks concession to "Oh wow some users at home are operating these tools". But the tools aren't aimed at home users.
>Then the default page is to create a new DHCP server - why would I want to do that? How many users run multiple DHCP servers?
Me for one haha.
>Every other home router.
Right I think this is your problem right here. "Every apple I have ever eaten I could bite through the skin" is a weird criticism of an orange.
The mikrotik gui is an abstraction of the CLI. Its really good that way so when you are recovering a mikrotik at a remote site you dont need to think too hard about where IP/DHCP Server is from the command line even if you are a gui native.
>A good UI should guide the user and reveal relevant information only as it's needed.
Ok so 99.99995% of all Mikrotik RouterOS devices do not end up in peoples labs.
Even the devices that are homeish in capability are mostly deployed into apartment buildings as NTD's and managed via API/Ansible not by the occupant.
The cheaper routerboards, like the 2000 series, are almost entirely eaten by Wisps.
When you configure a new RouterOS device the use case is non obvious.
It might be an edge router that needs BGP to be stood up first.
It might be a tower router that needs only OSPF, or full stack BGP/OSPF/MPLS.
Maybe its going in a data center to terminate a bunch of VPLS tunnels or VPNs.
It might be an NTD/NTU or it might be a bodgy relay.
I had a customer that would deploy small form routerboards as ethernet regenerators when doing really dodgy cabling.
You are not the target customer. Its cool and good that as a hobby you dipped your toes in. But its a very long stretch to turn around and complain that the interface isn't good enough because it doesn't hold your hand the way you would like it to. Mikrotik offers training and certification for people who cant work it out.
This is the networking version of raising a fault with the linux kernel because you don't want to compile it, you just want the exe.
And no, theres not a potential solution in Mikrotik having a separate code base for non technical people. They cant manage the code they already have. "Its coming in ROS7" was a meme for the better part of a decade. We are almost completely done with "This feature doesnt work on this CPU" which plagued them for ages.
Asking RouterOS to be more like DLink or whatever it is you are more comfortable with is insane and I hope fervently you never encounter JunOS which is the absolute godlike gold standard but will likewise not hold your hand to help you setup your DHCP config.
> Ok so 99.99995% of all Mikrotik RouterOS devices do not end up in peoples labs.
Mikrotik make all sorts of equipment, including home routers. The hAP ax3 is shown on their homepage. It runs Router OS 7.
> Asking RouterOS to be more like DLink or whatever it is you are more comfortable with is insane
It's not insane to ask for sane defaults or UIs which hide progressive complexity. Ubiquiti manage it far better. Teltonika manage it far better.
Networking is a hugely complex and deep field. Mikrotik make equipment targeting small businesses. There's no way your average IT person understands the tradeoffs of every configuration the device can have - which is why a sensible UI which guides you into the complexity would be good.
Perhaps Mikrotik don't have the resources to do that - fair enough, that's a business decision. But it's not insane to desire a UI which encapsulates domain knowledge in a way which guides the user. That's just good UI.
The problem with UIs like Mikrotiks, which are effectively just a graphical overlay on a config file, is that they make it very easy to make a mistake. And even seasoned IT people make mistakes. And in this case, a mistake often means a security vulnerability.
>Mikrotik make all sorts of equipment, including home routers. The hAP ax3 is shown on their homepage. It runs Router OS 7.
See
>Even the devices that are homeish in capability are mostly deployed into apartment buildings as NTD's and managed via API/Ansible not by the occupant.
>The cheaper routerboards, like the 2000 series, are almost entirely eaten by Wisps.
I can see that you might get confused by the form factor, but I guarantee you can find these running entire branches of a wisp network.
>It's not insane to ask for sane defaults or UIs which hide progressive complexity. Ubiquiti manage it far better. Teltonika manage it far better.
Unifi is explicitly targeting prosumers. When they do snap out of that and target the ISP space you get things like their faulty dual UI POE switches (Make a change in the old UI? Welp thats going to wipe your comments from the new one!) or the poor slobs custom building rifle scopes for AF60 LR.
>Perhaps Mikrotik don't have the resources to do that - fair enough, that's a business decision. But it's not insane to desire a UI which encapsulates domain knowledge in a way which guides the user. That's just good UI.
The issue is that is the current situation. It does guide the user, the average one who will purchase their product. What they don't have is a big warning for people stumbling in from elsewhere.
>The problem with UIs like Mikrotiks, which are effectively just a graphical overlay on a config file, is that they make it very easy to make a mistake.
Yeah this is an issue tik has had for a long time. What they need to do is ape junos's commit feature set. But what they have is safe mode which reloads your old config on disconnect.
but.... that would piss off the prosumer crowd even further.
> Really? Its standard point and click engineer stuff.
Really. UI is easy. CLI is easy. But system exposes everything to you. It doesn't hide any complexity. So you need to actually know what you are doing, as happily clicking randomly won't produce any reasonable result.
> Ok so just a hobbyist perspective.
No need to diminish those experiences. That's how most of us got into the job. And enterprise experience ain't exactly a guarantee of wide knowledge.
I've been a long-time fan of Mikrotik. I even ran an ISP on it a fair while ago. I have a couple of archived GitHub projects if they are useful to anyone:
- Router OS Diff - Can diff two configs and give you the commands needed to bring the existing config up to date with the desired config. It's certainly not perfect, but a starting point of anyone needs something like this. [1]
- Netbox Routeros – A netbox plugin for updating the config of RouterOS devices directly from the Netbox interface. [2]
It has been many years since I touched these, but perhaps they will be of interest to someone.
Aside from that, I have had excellent experience with Mikroik. Everywhere from in-datacenter to it running in an off-grid hut on a mountainside. I've even heard reports of people finding rain streaming through a CRS and it just happily ticking along.
[1] https://github.com/adamcharnock/routeros-diff
[2] https://github.com/adamcharnock/netbox-routeros
Diffs are a pain as the order of the export changes in a version by version basis
But using “export terse” is far easier to do a standard “diff”
MikroTik recently updated their documentation site from an Atlassian Confluence Wiki to much more AI-friendly Docusaurus here: https://manual.mikrotik.com/
Any page can be easily converted into Markdown by appending .md to the URL. I mention this because in my experience, the agent is much more accurate when it has access to the docs.
The page you linked to has a TOC for LLMs: https://manual.mikrotik.com/llms.txt
Neat, I'm kicking this off to the web team of the company I work for to see if they can quickly implement this for our documentation.
Finally the Confluence pages were really bad.
Thankfully at least LLMs could figure out things t help me setup SXT LTE 7
Thanks for sharing, this is a great improvement (also and especially for human use! Renders much better on mobile phones compared to Confluence).
It’s interesting to observe and build LLM-driven solutions in Networking.
The biggest challenges that most of us networking people have are around velocity (how fast we can build and scale networks) and how effectively we can operate them (avoid defects, fix them fast when something breaks).
LLMs are great in both areas. AI helps with deployment challenges by speeding up tooling development and the creation of workflows on orchestration platforms. A manual process step today, say - reserving an IP address in an IP DB — is automated the next day instead of on a backlog for years. This post is an example of that (config-gen/config-deploy).
Operations use-cases are more interesting, IMO, and address the “too many signals” problems that we face. Network substrate telemetry, overlay telemetry, service host metrics, service metrics, customer metrics, recent change data, prior alarms - the list goes on. Being a network operator is not for the faint of heart and is under-mentioned on high stress job lists. AI makes AMAZINGLY good network operations triage agents, since they are able to immediately process so many signals.
Exciting times!
>LLMs are great in both areas.
Nuance. LLMs are just going to report that they cant SSH to an endpoint, after delivering your vibeconfig, and throw it back to you to resolve connectivity. Your velocity with LLMs will stall at break fix every time.
>AI makes AMAZINGLY good network operations triage agents, since they are able to immediately process so many signals.
I have seen a lot of tokens spent on solutions that could have just been grafana.
I'm a network engineer at a F500 and am no stranger to automation. We use a lot of Ansible and Terraform to manage both on-prem and AWS network infrastructure. Lots of Juniper and Cloudflare products, and we use NetCM, Netbox, Prometheus, and Grafana. But we've been playing with agents since late 2024, and our team has come a long way since then.
It was already easy enough and straightforward to deploy a network because we had built so many CLI tools to handle what we needed, but it still required a bit of a human touch to validate outputs and feed those to different tools. Thanks to skills with helper scripts, we're pretty close to one click deployments these days. So much of our maintenances or operations can even be handled from our phones. We can just tell an agent that there's a new version, or AMI, and we can reliably trust them to safely update the fleet from end to end without causing service disruptions. When customers need updates made, agents draft the PRs and I just review, and they deploy after I approve.
I would argue that most of what makes this possible though isn't LLMs themselves, but having invested in robust network design, consistent standards (snowflake setups or configs will cause you problems), proper observability, and detailed docs/runbooks. While I have my doubts that someone will ever be able to vibe code that knowledge and experience, you can certainly use agents to amplify an already strong engineering foundation.
>While I have my doubts that someone will ever be able to vibe code that knowledge and experience, you can certainly use agents to amplify an already strong engineering foundation.
Yep, I dont see any disagreement with you at all.
I would expect LLMs to be especially excellent at configuring Mikrotik stuff, given MT publishes markdown reference docs for LLM ingestion, the full config without secrets can be dumped to one text file, and their cli commands are very stable between versions.
I switched recently to OpenWrt from MT, which code agents are also good at. I'd wager most issues are going to be related to the user not specifying what they want clearly enough. The translation from network concepts to RouterOS config is pretty 'fat-free', so there's not much room for hallucinations beyond syntax errors, which can be verified via the API.
I hope for XDP too.
Yes! Recently connected two disparate systems (ubiquiti and mimrotik) using their exposed API’s and a Claude session so that systems I have on either environment could talk to each other. I am not a network engineer so it was liberating to get my gear working together. That said it’s a work in progress and just today I noticed something weird that one of my computers can’t access Minecraft servers while the rest of my network can
Probably a routing issue. Shot in the dark would be that one of these routers is NATing traffic, and the other router doesn’t have a route to that NAT’d range.
Other shot in the dark, misconfigured bridging or similar where ARP isn’t getting forwarded and rewritten quite right
Or look for something mangling SRV records, Minecraft seems to use those more regularly than everything else.
What possibly could you even be talking about? Networking gear already works together due to standards.
LEGOs fit together because they have standards. That doesn’t mean they self-assemble.
Networking can be complex. Standards allow interoperability but they do not magically make everything work with no configuration.
You still would need to know how networking fundamentals and how network protocols work.
Just because standards like DNS, NAT64, OSPF, ARP, etc, exist doesn't means its easy to get these things to communicate.
Ubiquiti isn't exactly known for being the best in terms of standard adherence, especially with their historically week IPv6 support.
Vendor terminology is often different (tagged VLANs vs trunking, etc.) but, in general, it is close enough that an experienced person can figure it out with a bit of googling. I've built networks with Cisco, Mikrotik, Aruba/HP, custom Linux routers, and others. Mikrotik VLANs are a bit weird, for sure.
In today's world, is generally easy to get things to communicate. It's not 30 years ago and nobody is running DECnet, Appletalk, or IPX.
The important thing you need to do is specify which Mikrotik version you're using; apparently the syntax for some things changed between 6 and 7.
It does pretty well, but you need to iterate. I was trying to get it to disallow internet access for non-DHCP clients, and in the end there were so many limits to what was possible that it wasn't worth it. But it did it, and when I was testing I found them.
So like everything for best results you need to know what you're doing so you can test effectively...but it saves you from learning the syntax etc.
LLMs as tech support is such a game changer. I have a fun complicated home network with a Mikrotik and a NAS and my desktop and laptop plus various radios and Raspis, and there's no way I could configure the extremely complicated RouterOS on my Mikrotik without AI. The speed is also helpful. Previously if my network went down I would have to wait until the next weekend to fix it because it would take me all day. Now I can get things back up in an hour or less.
I want something similar to this but for Ubiquiti. I don’t need anything fancy, just something that audits my home config and tell me if I’m doing something stupid, dangerous, or both.
Have you tried poking at the unifi api?
Same. Recently Ubiquiti has been putting more and more into the local API, so this should be getting easier to do. The Home Assistant UniFi integration just recently has started moving from private undocumented API endpoints to the newer public API endpoints.
In other news, Meraki has an AI assistant feature now.
Wish I could configure pfSense via API or config files.
You can. Both pfSense [0] and OPNsense [1] have good API coverage.
[0] https://pfrest.org/api-docs/ [1] https://docs.opnsense.org/development/api.html
Thanks! I'll look into this.
The main pfsense dev who exited the project is working on just that. Forget the name.
I've been doing some of this too. It's great just messaging claude in discord when I want to make a new device's IP static. I also put my mikrotik config sans passwords in (local only) version control, just in case.
And perhaps it's significantly easier on other routers, but I would not have gotten VLANs working without claude doing it for me...
I only have the agent investigate directly. To actually configure the Mikrotik, I have the agent write a script that is aimed to be idempotent and then run the script. Investigation is fine, but the script acts as a memory of intent which I find useful. As agents get better, it can be a textual representation rather than a script, but for now that suffices.
> I have the agent write a script that is aimed to be idempotent and then run the script.
You can take this one step further and have the agent write Terraform configs [1]. I did this (including having the agent import all the initial resources from the live device), works great and is generally more robust than a script.
[1] https://github.com/terraform-routeros/terraform-provider-rou...
I originally wrote specific terraform providers (even one for just configuring an Ubuntu machine), but over time I found that TF is a bit too heavyweight for my use-cases. The shell script works well because state divergence can be investigated by the LLM. The slowness of state refreshing etc. does make a TF apply painful. For me at least.
How big is your TF state on your routers?
Yeah, TF is slow if you have thousands of configs and batching not integrated in the provider.
> As agents get better, it can be a textual representation rather than a script, but for now that suffices
I can’t see any reason to have agents do what a script can do. If the operation is deterministic then why pay every time it gets done? This is why MCP seems so pointless to me.
It's adaptive and can handle config drift if someone has altered the machine in the meantime between script invocations. Not required if you're disciplined, of course.
Seems like a recipe for an expensive disaster to me!!
> ... WinBox (which to my surprise is now cross-platform, and works quite well on Macs)
Winbox having a Linux and Mac version is really nice... I'll have to try the Linux one at some point... hopefully it works as good as the Windows version did under wine.
I’ve been using ChatGPT to configure my mikrotik gear for about a year it’s pretty awesome. And the end result is well documented reusable scripts rather than my usual set of random stack overflow copy pastes and shitty inscrutable notes
MikroTik is one of the only companies that sells a router without WiFi at a non enterprise price. Useful for me to completely turn the power off at night to a separate WiFi (router in Bridge mode).
Mikrotik also has a safe mode for testing configuration
There is also a terraform provider. Not sure if there is a safe mode here. I normally test via ssh safe mode and import the changes afterwards.
Mactelnet is infinity useful, no need for terminal servers, you can bounce from your second mikrotik and reset the config no matter how screwed up your config.
This is quite timely - just had some fun creating a OTLP/Grafana cloud exporter, which sends data directly without requiring intermediaries.
Super light, right now testing on my own set up (was using mktxp before):
https://github.com/jutaz/TikTelemetry
Comments/feedback welcome!
Fantastic tip in this article to use version control (i.e. git) for config files, I hadn't thought of that.
A word of warning, my experience with mikrotik in the WiFi-6 space has been overwhelmingly negative, both in a single AP setup at home and on a corporate WiFi network managed by someone else.
Bugs, random drops, poor performance on some machines. It is not set and forget and I gave up on it.
Interesting that sending things like network configurations, keys, and credentials to external entities - which BTW are fueled by data - is considered "ok" now.
Is there anything here that suggests that? You are jumping to conclusions easily.
It's nowadays the default not to export any credentials when exporting MT configs, and even doing that yourself is trivial. Since the equipment is pretty packed with functionality and very flexible, benefits of LLM assistance is big.
As for "sending network configurations" it's a risk everyone needs to consider individually. Having that private may make attackers job harder, but security by obscurity ain't no replacement for a secure setup.
When I was setting up Wireguard server at home, the last step (after testing the setup) was the LLM giving me a set of commands to run manually to regenerate the credentials.
Yeah, the thought of having private keys and config slurped up by an LLM provider keeps me away from this kind of direct work.
Perfect job for a local LLM!
Once AI finds out you are located at localhost, it's all over for your boxen... RIP 192.168.xxx.xxx!
>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
Really? Its standard point and click engineer stuff. The biggest issues with Mikrotik are the features not implemented in the gui, or the way config is interpreted between versions. Also the term of hardware support, and generally flaky code in general.
>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).
Ok so just a hobbyist perspective.
It seems like this article is just "Point an LLM at your mikrotik api, have fun"?
My issue with Mikrotik is that the UI puts all the complexity up front. A good UI should guide the user and reveal relevant information only as it's needed. Mikrotik doesn't do that.
For example, the most common reason I want to connect to my home router is to see what devices are connected, what their IP addresses are, and perhaps make their DHCP leases static. In a good UI that sort of common activity would be front and centre - in MikroTik it's buried under 3 levels of menu.
Under the IP menu is 26 alphabetically sorted options, of which I have to click "DHCP Server". Then the default page is to create a new DHCP server - why would I want to do that? How many users run multiple DHCP servers? I have to click on the "Leases" tab, and then I can see a list of my connected devices.
Every other home router I've used knows that users care about the connected devices, so show it front and centre.
>For example, the most common reason I want to connect to my home router is to see what devices are connected, what their IP addresses are, and perhaps make their DHCP leases static.
You sound like a Windows user who just found his way into Active Directory.
>in MikroTik it's buried under 3 levels of menu.
Its buried 3 levels deep in a hierarchy, the hierarchy you need to learn to operate the system. Quickset is Mikrotiks concession to "Oh wow some users at home are operating these tools". But the tools aren't aimed at home users.
>Then the default page is to create a new DHCP server - why would I want to do that? How many users run multiple DHCP servers?
Me for one haha.
>Every other home router.
Right I think this is your problem right here. "Every apple I have ever eaten I could bite through the skin" is a weird criticism of an orange.
The mikrotik gui is an abstraction of the CLI. Its really good that way so when you are recovering a mikrotik at a remote site you dont need to think too hard about where IP/DHCP Server is from the command line even if you are a gui native.
Hang on still angry at this:
>A good UI should guide the user and reveal relevant information only as it's needed.
Ok so 99.99995% of all Mikrotik RouterOS devices do not end up in peoples labs.
Even the devices that are homeish in capability are mostly deployed into apartment buildings as NTD's and managed via API/Ansible not by the occupant.
The cheaper routerboards, like the 2000 series, are almost entirely eaten by Wisps.
When you configure a new RouterOS device the use case is non obvious.
It might be an edge router that needs BGP to be stood up first.
It might be a tower router that needs only OSPF, or full stack BGP/OSPF/MPLS.
Maybe its going in a data center to terminate a bunch of VPLS tunnels or VPNs.
It might be an NTD/NTU or it might be a bodgy relay.
I had a customer that would deploy small form routerboards as ethernet regenerators when doing really dodgy cabling.
You are not the target customer. Its cool and good that as a hobby you dipped your toes in. But its a very long stretch to turn around and complain that the interface isn't good enough because it doesn't hold your hand the way you would like it to. Mikrotik offers training and certification for people who cant work it out.
This is the networking version of raising a fault with the linux kernel because you don't want to compile it, you just want the exe.
And no, theres not a potential solution in Mikrotik having a separate code base for non technical people. They cant manage the code they already have. "Its coming in ROS7" was a meme for the better part of a decade. We are almost completely done with "This feature doesnt work on this CPU" which plagued them for ages.
Asking RouterOS to be more like DLink or whatever it is you are more comfortable with is insane and I hope fervently you never encounter JunOS which is the absolute godlike gold standard but will likewise not hold your hand to help you setup your DHCP config.
> Ok so 99.99995% of all Mikrotik RouterOS devices do not end up in peoples labs.
Mikrotik make all sorts of equipment, including home routers. The hAP ax3 is shown on their homepage. It runs Router OS 7.
> Asking RouterOS to be more like DLink or whatever it is you are more comfortable with is insane
It's not insane to ask for sane defaults or UIs which hide progressive complexity. Ubiquiti manage it far better. Teltonika manage it far better.
Networking is a hugely complex and deep field. Mikrotik make equipment targeting small businesses. There's no way your average IT person understands the tradeoffs of every configuration the device can have - which is why a sensible UI which guides you into the complexity would be good.
Perhaps Mikrotik don't have the resources to do that - fair enough, that's a business decision. But it's not insane to desire a UI which encapsulates domain knowledge in a way which guides the user. That's just good UI.
The problem with UIs like Mikrotiks, which are effectively just a graphical overlay on a config file, is that they make it very easy to make a mistake. And even seasoned IT people make mistakes. And in this case, a mistake often means a security vulnerability.
>Mikrotik make all sorts of equipment, including home routers. The hAP ax3 is shown on their homepage. It runs Router OS 7.
See
>Even the devices that are homeish in capability are mostly deployed into apartment buildings as NTD's and managed via API/Ansible not by the occupant.
>The cheaper routerboards, like the 2000 series, are almost entirely eaten by Wisps.
I can see that you might get confused by the form factor, but I guarantee you can find these running entire branches of a wisp network.
>It's not insane to ask for sane defaults or UIs which hide progressive complexity. Ubiquiti manage it far better. Teltonika manage it far better.
Unifi is explicitly targeting prosumers. When they do snap out of that and target the ISP space you get things like their faulty dual UI POE switches (Make a change in the old UI? Welp thats going to wipe your comments from the new one!) or the poor slobs custom building rifle scopes for AF60 LR.
>Perhaps Mikrotik don't have the resources to do that - fair enough, that's a business decision. But it's not insane to desire a UI which encapsulates domain knowledge in a way which guides the user. That's just good UI.
The issue is that is the current situation. It does guide the user, the average one who will purchase their product. What they don't have is a big warning for people stumbling in from elsewhere.
>The problem with UIs like Mikrotiks, which are effectively just a graphical overlay on a config file, is that they make it very easy to make a mistake.
Yeah this is an issue tik has had for a long time. What they need to do is ape junos's commit feature set. But what they have is safe mode which reloads your old config on disconnect.
but.... that would piss off the prosumer crowd even further.
Also on the LLM + Mikrotik front: https://github.com/2GT-Media-Group-LLC/mikrotik-manager
It's an alternative webUI for Mikrotik routers, coded with LLM assistance.
> Really? Its standard point and click engineer stuff.
Really. UI is easy. CLI is easy. But system exposes everything to you. It doesn't hide any complexity. So you need to actually know what you are doing, as happily clicking randomly won't produce any reasonable result.
> Ok so just a hobbyist perspective.
No need to diminish those experiences. That's how most of us got into the job. And enterprise experience ain't exactly a guarantee of wide knowledge.
>I is easy. CLI is easy. But system exposes everything to you
Yeah like I said, ENGINEER.
>No need to diminish those experiences.
Yeah but it certainly diminishes the criticism.