This is fantastic Idea, whoever what you guys think about something like what Unifi or Meraki do, a nice controller that can be hosted, and adopt all Mikrotik device with potentially dude integrated to it for nice network diagram and more... would be killing feature for us deploy and managed MikrotikHello,
MikroTik is planning to develop and build a controller app for MikroTik Devices. Currently we are researching possibilities and options, what should be there and how it could be done and implemented. At the moment we do not want to stick to a specific implementation or standard, but build our own that will help to manage, develop and deploy different scale networks running MikroTik devices.
Any suggestions about features and options are very welcome.
Yes definitely! Just make update and upgrade routerboard in one click, just mark clients on AP.. In which hour and if will include AP, wait to download clinets FW and than upgrade AP on last.Centralised updates and configuration management!
How do you define that? Something like TikApp? I suppose not, that is already there.Hello,
MikroTik is planning to develop and build a controller app for MikroTik Devices.
yes and No, would be good if controller can do the backup of the correct config, can do compare between the versions of the config and it would be great to push the config too.I have seen several mentions of config files, config compare ...
Do you suggest for the controller to operate as a configuration export uploader?
I see, are you going to developing something like Meraki or Unifi as a controller? is Mikrotik planing to have some king of NGFW feature in future produce?The initial goal is to develop a protocol to apply and monitor config, hence the question about needed features that this protocol should be able to do.
- connect to some cloud server and establish trustThe initial goal is to develop a protocol to apply and monitor config, hence the question about needed features that this protocol should be able to do.
@sergejs wrote: MikroTik is planning to develop and build a controller app for MikroTik Devices. Currently we are researching possibilities and options, what should be there and how it could be done and implemented. At the moment we do not want to stick to a specific implementation or standard, but build our own that will help to manage, develop and deploy different scale networks running MikroTik devices. Any suggestions about features and options are very welcome.
@mrz wrote: The initial goal is to develop a protocol to apply and monitor config, hence the question about needed features that this protocol should be able to do.
as I read the responses, I see a lot of mentioning of "cloud". While I don´t think cloud is something inherently bad, one of the selling points of MT for me is that no features _require_ binding to any cloud (except the cloud backup obviously).
If using cloud services inside the EU, this is perfectly fine on the legal side.A cloud only solution using US services might be sensitive in the EU depending on the CLOUD ACT, thus regardless of which solution the devs come up with you need to be able to install this on premise IMO.
This was not my point, but a cloud only solution has lots of other implications, like privacy, like the need for the Internet availability, like the total dependency on the cloud ressource maintainer and the cloud provider itself....
The initial goal is to develop a protocol to apply and monitor config, hence the question about needed features that this protocol should be able to do.
/ip address update .id=*1 interface=bridge1 address=192.168.88.1/24
Do mean the "tree/hierarchical configuration style" of capsman, or forwarding of network traffic to a central router part (e.g. DTLS tunnels/local-forwarding=no). Or, both?Think of it like a capsman, but not just for wireless.
I am talking about the concept, there is a controller that should be able to push configuration, and there are devices that should be able to use that configuration. We are talking about what the controller features that it should be able to do in terms of communication: controller <-> controlled_device
So basically "Make Certificates Great Again", which go a long way as base for AAA in this concept. Now that includes dealing certificates better in RouterOS export/backup as a first step (see @rextended comments above re this topic)...My number one suggestion and highest priority is to build in strong security from the start, not as an afterthought. MikroTik could show the rest of the network equipment industry how to establish best practices for securely maintaining network devices, and that should be the goal!
[...]
Yes, this is a lot. Not everything needs to be in version 1, but everything (and more) needs to be in the product plan and resulting design. Security is just too important an issue these days to not be the primary objective for anything that purports to control network devices and maintain a network system.
ui.com, "stupid" - device without config and havey really on central control managerWhat is a "hUi" company and what do you mean by "stupid" devices? All devices sold by MT include RoS or SwOS thus they are "smart" right?
Like stated above, there is no talk about a smartphone app or web app. The question is about concept of how a mass configuration protocol should operate.
huh?before starting advertise things
Maybe it would be wiser to drop a bit of vanity and instead of inventing everything from the scratch base this new tool on some established standard such as RESTCONF for example which should not only cut developing time and effort but allow for MikroTik devices management to be easier integrated into an existing enterprise management systems ...At the moment we do not want to stick to a specific implementation or standard, but build our own that will help to manage, develop and deploy different scale networks running MikroTik devices.
Can't quote your whole thing, but exactly how I want it to work. I always thought capsman could be extended to support switching and other features. Just mark profiles for a supported feature levels and ignore the rest. Capsman works just fine ( from my experience ) and seems to have all the framing needed to start quickly with this new controller concept. Could even call it MADman Mikrotok Access Device manager.- Controller server would be a separate package installed on a router
- Controller client would be part of standard routeros package.
On a device, I would want to enter 'managed mode' in a way like entering 'capsman mode'. With the reset button.
you want another brick ?create this as a package that can be run in High-Availiability on MT routers.
I do feel anything new needs to be only ARM. Heck MIPS only designs ARM cores now.only on ARM works as expectedcreate this as a package that can be run in High-Availiability on MT routers.
huh?
Hard to know, but they have a pretty list now, from "Layer 0" (fix bugs first) to "Layer 8" (maybe start with requirements).huh?
Or maybe you're just out fishing because you have no clue at all yourselves... ;-)
+1I think issue today is the export/import isn't symmetrical, backup/restore is monolithic+binary, . What's missing is idempotent configuration file. And that's the first step to being able to monitor/apply a configuration in "controller software".
RouterOS does not store configuration in one plain text configuration file.+1I think issue today is the export/import isn't symmetrical, backup/restore is monolithic+binary, . What's missing is idempotent configuration file. And that's the first step to being able to monitor/apply a configuration in "controller software".
+1For start, start just with:
Daily backup on text format, not binary on any point, and full configuration, included ssh keys, certificates, user-manager and dude database.
Some instruments to compare backup among various days for see the changes.
Some instrument for push configuration (like change NTP servers on all devices, or only on a group of devices, or only to selected devices.
Possibility to select/search devices by Group / Hardware / Branding/Platform, ROS version, BIOS/RouterBOOT version, installed packages.
Possibility to send .npk / .dpk / single file and select on what folder put it remotely based on internal memory type "root" or "root/flash".
Yeah, fix that first. /export has to be a complete text dump of the configuration.RouterOS does not store configuration in one plain text configuration file.
Fishing is fun right!Yes we are obviously fishing, did you not read the first post? Nothing has been made, we are asking for ideas how such a system should work in all of your opinion
But it stores configuration in binary structure that can be backed up/recovered. So provide the tools to convert this binary into text configuration and back.RouterOS does not store configuration in one plain text configuration file.
If you're looking to be more radical, have you looked at ZeroTier's LF protocol (which is separate from ZT itself)?Like stated above, there is no talk about a smartphone app or web app. The question is about concept of how a mass configuration protocol should operate.
Well, the first message is rather "vague". What is a controller app ? Is it a mobile application ? A thin client ? A thick client ? Public Cloud ? Private Cloud ? Local network ? Give us more information of what you're aiming at. The best would be to first define your own list of ideas, submit them to the community / to your list of registered clients as a survey and ask people to vote for features, then let them add more ideas or check a checkbox "you're on a wrong path".we are asking for ideas how such a system should work in all of your opinion
I beg to differ, I still didn't have any luck finding e.g. users or certificates in mine. So it's not exactly what I'd call complete.Export already is the complete text dump of the configuration ...
Yes we are obviously fishing, did you not read the first post? Nothing has been made, we are asking for ideas how such a system should work in all of your opinion
Yeah, fix that too!Export already is the complete text dump of the configuration but that text dump is not the way the config is stored. You cannot upload that text file to the router and expect it to replace the configuration on the router.
Whatever you are doing, hope it'll work on linux (not like wine+winbox)
I whole heartly agree. This is a 100% perfect use case for OCI containers on ROS.Whatever you are doing, hope it'll work on linux (not like wine+winbox)
If they are smart they implement the solution as a "container appliance" that's able to run as a cloud service, on premise or perhaps even on MT devices like RB5009 or CCR2004 if they meet the requirements for RAM and storage.
I beg to differ. In my opinion, it depends entirely on the use case. As you’ve probably noticed, there are many different views on what's right or not.Not over complicated stuff..
100% agree here. On practical level, this what a “controller” do that be exactly what I’m looking for my actual use cases.Set Distribution Profiles per feature, like we now can replace a one file and give differ GUI in WebFig.
[…]
I use TheDude server
[…]
Just add a discribution of auto.rsc over The Dude and it will be perfect. In my case of course.
I'd not like to see Winbox go - its Layer2 discovery and control capabilities are invaluableExciting news !
- web based, so the controller can be accessed from nearly any device or platform and eventually phase out winbox. ideally the controller should not be based on java but static binaries deployment or open source ?
- better graphing and analytics, time to move away from mrtg. rrdtool is good, what about grafana ?
- integrated "tailscale-like" controller to easily set up wireguard links between managed endpoints and automatically handle endpoint ports, NAT hole punching etc. "one click wireguard vpn" could be a great marketing tool
- devices overview with status page, device model image, and a satellite map overview to plot wireless links and do line-of-site calculations similar to ubnt's UISP
I'll update my list if I can think of anything else :D
It would be a nice option to have a controller that is connected by the router, instead of the other way around. That enables management of routers that are behind NAT.I think, the dude is good enough software and mikrotik just needs to expand its functionality,because maps of the dude and visuality is unique.
to access router behind nat no need to use vpn, just use NAT mikrotik as dude agent, and all other router will be visible in your centrall dude
It would be a nice option to have a controller that is connected by the router, instead of the other way around. That enables management of routers that are behind NAT.
Of course one implementation could be to have some kind of VPN setup by the router (L2TP/IPsec, SSTP, etc) which then is used for the controller to connect to the router in the existing way (API, winbox).
A problem with Dude is that it is so much work (on a larger network) to detect, configure and map everything.
That should not be a mandatory activity. Lots of users are well served with only "table" presentations of the data and no fancy map.
Then please add a disctribution feature to mass deploy spript to The Dude and we are happy with that. Come Back us TheDude as server at Windows (add contener or linux) and we will build our "clouds" online distribution platform's.The primary idea was the option to control RouterOS devices. But when it comes to that we will look for a possibility to control the SwOS devices too.
(from https://www.change.org/p/mikrotik-relea ... ource-code)The Dude is a extremely powerfull application developed by Mikrotik to manage and monitor network devices running SNMP protocol. For years its development is stopped and mikrotik keep it for it self. This petition is at the same time a tribute and a ultimate request for Mikrotik to release the source code and let the opensource community develop the ultimate NMS System for us all.
Oh, yes. The day Mikrotik goes this route would be the day I would need another vendor.Please, no Ubiquity style where configuration is stored in a local database and you are bounded to particular computer to reconfigure your network.
Yes please, make sure endpoints work from behind CGN.
-It should definitely have a mode where the router reaches out to the controller, like how cnMaestro and UISP work. It allows devices behind NAT to be monitored and maintained without punching holes in a firewall.
I'd prefer to live in an XML-free world – while text, it's just not that easy for humans to write or read.The NETCONF protocol is designed for this sort of thing. Other router vendors are using it for this exactly.
I think the same.For me it's transparent that will be used own ros protocol, tr-069, ftp, ssh because we need allow to communication from our end-device to this "DistributionTik" app and this solve all CGNAT etc.
This app must give us way to
* group units, create bigger group from other group's like we can use those groups: "RB95x" + "RB_LTE6" give us our "RB_Branch" who + "RB_CCRs" = "All_Customer1"
* Multi Select as group/unit that I can say to push config to that grups and that units...
* Re-Connection and Re-Send configuration (like push update.auto.rsc who do reboot ... and resend update.auto.rsc who do latest but upgrade firmware and reboot... resend who confirm latest ros and firmware and remove itself and the end of task, report that all steps done)
* Use all IP to unit who works as RoundRobin, like first will be internal IP over VPN, ... Public IP ... and RoMON connection too!.
In my scenario, TheDude can do that and for easier it should have import connection from WinBox . In WinBox I have at least 2 IP to the same unit (Public and Internal PPP and internal LAN of branch)
Summary, give us way to send our scripts.auto.rsc over ftp over TheDude who can be installed on any VPS/Container and we build or differ distribution centers. TheDuce can do provisioning of configuration and it's all.
Another concept be the controlled device is just aAt the moment we do not want to stick to a specific implementation or standard, but build our own that will help to manage, develop and deploy different scale networks running MikroTik devices.
git
Like having a constant stream of prioritized data saturating your uplinks. (Not so) Great idea! :)Ability to monitor the speed of the Internet, and get a notification in case of reduction.
Hilike ACS ?
yes you can probably do some of that on ROS by utilizing scripts and routing and NAT and QoS , but it´s very impractical.Of course you can do all of that, or most of it, on RouterOS as well...
This type of uplink monitoring and traffic steering is implemented by many vendors and works so well, that most of big industries and enterprises are abandonig a lot of MPLS links in favor of the much cheaper Internet links.The problem is how to trigger an alert. Sure, when you have an internet connection that is saturated 100% of the time (like those "wireless ISP" that share a single 20Mbps line with 100 customers) you can do something like "when my input rate drops below 10Mbps send an alert".
But in the general case, where the internet is usually lightly loaded (running below 10% capacity most of the time, maybe even idle during night), it is much more difficult.
Of course you could try to make "background traffic" that is handled at lower priority in queues, to fill the line, but that requires complete confidence in the priority handling at all places in the network (you often cannot influence how the ISP does their queueing), and also you could be limited by max data quota etc.
Hi pe1chlI am doing that on MikroTik with just a couple of tunnels and BGP to autoroute/failover between them.
No need to watch throughput as the lines are normally lightly loaded. We normally tunnel over IPv4, when that fails we try IPv6 (yes, it has happened that IPv4 routing was down at the ISP but IPv6 still worked) and when both fail we use LTE.
No fancy mysterious secret stuff, just plain routing with MikroTik.
But inter-office links are becoming a thing of the past anyway.
Well that approach works for AWS IoT Core. Basically this mythical controller, using MQTT, could borrow their "device shadows": https://docs.aws.amazon.com/iot/latest/ ... adows.htmlYou could make the use of MQTT (or any other broker) for this. So monitoring enabled devices efficiently send info into the broker and if "controller" is up it can display received data the way it wants and without actual connections to the every device. This decoupling will be more flexible and might scale better. You can even run multiple controllers without any troubles.
UniFi is written in Java. At first that seems attractive as it achieves portability, on the other hand it is a resource hog and lately it has gotten a bad reputation because clueless developers implement attractive modules used by many, which cause nasty security issues. A bit like PHP.I’m saying this as e.g. UniFi dashboard can easily spin a fan on my i7… which is ridiculous.
And clearly a UBNT clone is what no one is looking for.Many great things has been said here and I sign under them. I will have one suggestion:
Please start small and ascetic.
We don’t want a perfect solution in 10 years.
(e.g. they do not understand the difference between system configuration data where you might want to parse ${expression} constructs, and user data where you definitely do not want to do that)
This is not limited to network folks. The Atlassian system used by MikroTik for the help system and issue tracker were down due to such an issue (waiting for a fixed version).(e.g. they do not understand the difference between system configuration data where you might want to parse ${expression} constructs, and user data where you definitely do not want to do that)
Yeah, that's why network folks are in general terrible application developers. ;-)
This is because people who engage in low-level network programming often have a completely different mindset and are therefore usually unsuitable for that kind of job. Bottom line, never ever put a network developer in charge of a large application development project.
Why that?The initial goal is to develop a protocol to apply and monitor config, hence the question about needed features that this protocol should be able to do.
The nice thing about the UISP design is how the devices "phone home" to the controller instead of the controller needing to reach them, which works great for devices behind some kind of NAT where the controller does not have direct access as well. TR069 can do this too but it is not suitable for uses outside of residential gateway management, it would be very strange to use TR069 to manage a BGP router at the core.noooooooooo NOT THAT...
Make a DUDE app. May be modularize Dude so a small installation could use only the device list part. Add configuration management.Hello,
MikroTik is planning to develop and build a controller app for MikroTik Devices. Currently we are researching possibilities and options, what should be there and how it could be done and implemented. At the moment we do not want to stick to a specific implementation or standard, but build our own that will help to manage, develop and deploy different scale networks running MikroTik devices.
Any suggestions about features and options are very welcome.
Can be done yes, but could be done immensely better with a central cloud controllerInteresting idea. Actually the current experience is already quite good.
Managing nearly 100 MT routers at a very remote location, can be done.
That would be interesting for sure. But might be difficult to implement. What is a correct config?it doesn't tell you if the existing config is correct,
We use Solarwinds NCM which is good as a general all-rounder. But MikroTik could make it enormously better/easier/simpler if it were tailored specifically for MikroTikThat would be interesting for sure. But might be difficult to implement. What is a correct config?it doesn't tell you if the existing config is correct,
Today one is not sure ROS will act as expected. "Toruble" shooting can take some time, as there are so many settings, and so many things that impact the behaviour in an unexpected way.
+100 on this and the rest of your suggestions.1) Doing a controller without the ability to have idempotent commit is a fool's errand, and will only end in tears, both for the developers and users. Fix that first, the rest becomes MUCH easier.
That you have representation of running and start up configuration. Where are you can see the differences.I have seen several mentions of config files, config compare ...
Do you suggest for the controller to operate as a configuration export uploader?
For anyone interested in a solution like this, there's Oxidized.Yes that would be nice to have for "the general public".
I have this function for ages as I export my configs to a locally hosted git versioning system with the additional "gitweb" program that shows output similar to the above via a web interface (only accessible locally).
Very useful to be able to look back at what you changed before. Also useful when having more than one admin.
AHAHAHAHAHAAHAHHAH!!!!!!!!!!!demo?
Basically what I said.Nothing at all. The function library never came into existance, 4 years of discussion going to waste.
The way I understood "function library" there would be an optional package that you could install, or some script file you could download to the router and call from your scripts, containing a collection of utility functions as a layer on top of (i.e. written in) the scripting language.Is not all correct, on 7 is added the random number generator... :| :| :|
perfect.My number one suggestion and highest priority is to build in strong security from the start, not as an afterthought. MikroTik could show the rest of the network equipment industry how to establish best practices for securely maintaining network devices, and that should be the goal!
Some suggested approaches:
- Incorporate a robust management facility for establishing and maintaining administrator and user accounts. Ideally, this should also support "machine" accounts that could be used for automated status queries and management of devices. The controller itself should use a "machine" account for its purposes, and this account must be customizable by the customers. Integration with enterprise systems like Microsoft's Active Directory would likely be desirable for some customers.
- Build in a Certificate Authority (CA) for issuing certs to network devices. The new controller should incorporate hardware protection for private keys (especially CA's own private keys), along with the ability to securely clone the CA's private keys to a backup controller using multi-party controls. Network devices should be able to request renewal of certs from the CA using automated methods. There should also be automated tools for installing certs in network devices. Certificate revocation must be supported using a dynamic protocol like OCSP with ability to push out revocations immediately (e.g., via CRL update). An optional approach could be to support integration with a third-party Certificate Issuing/Management system, but these days the tools to implement the subset of services required for network devices are readily available from multiple Open Source projects, including OpenSSL itself.
- Use CA in new controller to also issue client-side certs for network administrators. Client side certs would be used with mutual authentication to handle logins to Winbox and other device-specific services, including an option for providing SSH keys via certs. Automated client cert renewal should be supported, and it must be possible to revoke client certs with immediate pushing of revocation notices to devices along with dynamic cert checking. (Aside: WinBox might directly support requesting administrator certs from new controller's CA.)
- CA should also issue user certs for Wireless access, PPP/VPN remote access, HotSpot services, etc. This implies that there should be specialized access to the controller from users to handle cert requests or update their account details, such as email addresses, phone numbers, workstation details, mobile device details, etc. In an enterprise environment, it might be possible to pull this sort of information from a central service.
- Fully support the latest cryptographic algorithms and measures, including the widely accepted elliptic curve algorithms (e.g., ED25519). Provide policy controls to limit/restrict use of cryptographic suites in the network devices from a network-wide perspective.
- Provide a complete implementation of a robust RADIUS service for legacy devices and services. For extra credit, support RADIUS integration with Microsoft AD NPS/RADIUS facilities.
- Implement an SSH key management system that would support pushing administrators' SSH public keys to network devices and rolling keys as appropriate. Immediate removal or disabling of SSH public keys for administrator login is also necessary. One possibility would be to use SSH and SSH key management to handle securely pushing updates to devices, along with invoking of scripts and automated retrieval of device information, including device configurations.
- Provide an encrypted storage system for maintaining sensitive information at rest, especially for device configurations and any other sensitive information.
- Build in a software repository for redistributing RouterOS (and possibly other software/firmware packages) to network devices in a controlled manner without requiring that individual network devices have access to the Internet. This could be an adjunct to the requests from others on this Post for RouterOS bulk updates. Ideally, this system should support two or more storage partitions on devices that support this option to make it easier and safer to rollback an update. For devices that are not equipped (or configured) with multiple partitions, a rollback facility would still be a valuable capability.
- Implement support for redundant device deployments, including for the new controllers. For example, support measures to independently update RouterOS in each member of a redundant device pair thereby allowing the other member to maintain services during the upgrade. This capability could also allow staging of firmware in redundant systems to confirm stability before completely updating all devices. Similar capabilities would also be necessary for redundant controllers. Resilience is an often-overlooked essential security requirement.
- Support RANCID or an equivalent service for maintaining network device configurations in a source control system (e.g., Git). This could be an add-on package for users dealing with larger networks or complex support requirements. (Aside, my own experience using RANCID with a complex network involving devices from multiple vendors illustrated that this is an invaluable tool for not only tracking configuration changes, but also monitoring changes made by multiple administrators, which in turn provides further security controls with the added ability to recover from unapproved or ill-conceived changes.)
- Support management of security credentials for SNMPv3, including the ability to update credentials periodically in a controlled and automated manner. Provide methods for pushing SNMPv3 credentials to network management systems (e.g., via secure upload of an exported dictionary of credentials).
- Provide tools for automated responses to DDoS attacks using parameter-driven approaches for invoking mitigation measures.
- Implement a comprehensive system logging facility. This could be optimized for MikroTik devices to leverage enhanced features. The system logging should support TCP logging, as well as optional support for logging via encrypted links (SSH, IPsec or other VPN). It should be feasible for customers to implement redundant syslog servers for resilience as well as protecting logs from being modified by attackers. The logging system should be capable of relaying log records to more advanced enterprise-oriented logging systems (e.g., Elastic Search).
- Since DNS is one of the most essential services and also one of the most sensitive from a security perspective, centralized management of DNS services in network devices would be a valuable service. This could include the ability to maintain static DNS caches across some or all network devices to improve availability of essential DNS resolution during periods of degraded operations, such as network outages or partitioning.
- Provide robust NTP services, ideally supporting authenticated access. The new controller would ideally provide an option for GPS time sync so that it could operate as a Tier 1 NTP server. This would also be an underlying security facility for supporting certificate management and use of time-based authentication services.
Yes, this is a lot. However, everything listed above is readily available and supported in the Open Source realm. What is important is to build these capabilities into the product plan, and build other controller features and capabilities on top of a secure base. Not everything needs to be in version 1, but everything (and more) needs to be in the product plan and resulting design. Security is just too important an issue these days to not be the primary objective for anything that purports to control network devices and maintain a network system.
...can also be coupled with, e.g. LibreNMSFor anyone interested in a solution like this, there's Oxidized.Yes that would be nice to have for "the general public".
I have this function for ages as I export my configs to a locally hosted git versioning system with the additional "gitweb" program that shows output similar to the above via a web interface (only accessible locally).
Very useful to be able to look back at what you changed before. Also useful when having more than one admin.
https://github.com/ytti/oxidized
you could setup a public CHR to which your to-be-managed tiks would connect via ovpn/sstp/wireguard (with a /30 subnet for instance or framed /32), establish a routing-protocol for automatic route exchange with route filters in place so every device has its own Lo0 address and you also connect to that CHR and route your management subnet (in which the Lo0 address reside) to that CHR
Really though, at minimum, remote management behind NAT is the biggest PITA at the moment
I can also zerotier each router with my own hosted ZT and access it that way. Point being...it is an extra step which would be nice to avoidyou could setup a public CHR to which your to-be-managed tiks would connect via ovpn/sstp/wireguard (with a /30 subnet for instance or framed /32), establish a routing-protocol for automatic route exchange with route filters in place so every device has its own Lo0 address and you also connect to that CHR and route your management subnet (in which the Lo0 address reside) to that CHR
Really though, at minimum, remote management behind NAT is the biggest PITA at the moment
so NAT is no problem any more in fact. and with sstp/ovpn on tcp port 443 it even would be possible to maybe deploy tiks in china xD ;)
^^^^^^^^^^^^^^^^^^^^^^^In regards to the 'Cloud' solution.
Not everything I have in now >100 devices touches the public internet.
I would prefer a solution I can spin up on a Virtual Machine in a closed environment.
I understand that other people could benefit from a cloud controller, but not in my current use case.
^^^^^^^^^^^^^^^^^^^^^^^In regards to the 'Cloud' solution.
Not everything I have in now >100 devices touches the public internet.
I would prefer a solution I can spin up on a Virtual Machine in a closed environment.
I understand that other people could benefit from a cloud controller, but not in my current use case.
THIS!!!!!
That's worse. You need an extra point of failure ("proxy controller" service) plus the need to rely on 3rd party cloud services (be it MikroTik, the cloud provider they choose, and everyone in between)....Or the best of both worlds: a cloud-based service, with the option for a local "proxy controller", located on the LAN edge.
But do they still offer that? I know it was like that in the past, and I have cut the connection between our locally installed controller and the internet during theThe best approach is what Ubiquiti does. Give the option to either use their cloud service or allow end users/integrators to install it on-premises and be 100% air-gapped.
Wifi 6e??? From Mikrotik?Ok that is great! I'll keep it in mind as probably sometime soon it will be the time to replace (part of) the APs with Wifi-6E models...
No it was referring to the post above that.Wifi 6e??? From Mikrotik?
That was a joke right?
Let's not pollute the topic of centralized management with requests for new features in the router!Seconding IPS/IDS.
I have had too many customers recently that have wanted IPS/IDS and as a result I had to remove Mikrotik routers.
i reckon you do not really know how a IDS/IPS works and what "in depth protocol" steps it iterates through and how quite cpu-intense a IDS/IPS is, or do you?
You don't need a centralised app for that though. I would love a checkbox in winbox that said enable IDS/IPS, as simple as that :)
There are many good syslog handling tools, like Splunk:- better centralized syslog that can be filtered, searched through, copy/pasted, exported, rotated, parsed and scripted
Yes, how about reworking Dude?The Dude offers limited management capabilities, but is quite lackluster
Well, nobody said you should run IDS/IPS on a RB2011.i reckon you do not really know how a IDS/IPS works and what "in depth protocol" steps it iterates through and how quite cpu-intense a IDS/IPS is, or do you?
You don't need a centralised app for that though. I would love a checkbox in winbox that said enable IDS/IPS, as simple as that :)
a real IPS in less than 5min for business... alright.
...
Although to be frank I don't care about the implementation, as long as it comes in a routeros update, and is simple enough to use that I can enable it in less than 5 minutes.
Exactly what I said earlier. I do not care for it being THE WORLDS BEST FIREWALL NO.1 . I just want a checkbox that says Enable IDS, another checkbox that says enable IPS and then some optional whitelisting and blacklisting boxes.
a real IPS in less than 5min for business... alright.
Yeah and it is implemented exactly incorrectly. Who likes to make dosens of mangle rules with l7 firewall rules and a script on a schjeduler that runs every 5 minutes updating those rules from some online place managed mostly by volunteers? Not me.and AFAIK on mikrotik DPI is here anyway. how would all mangle and firewall options be possible otherwise
Yes , version control and configuration enforcement.I have seen several mentions of config files, config compare ...
Do you suggest for the controller to operate as a configuration export uploader?
That has about the same intention as:MikroTik is planning to develop and build a controller app for MikroTik Devices. Currently we are researching possibilities and options
as was posted in 2018 ( viewtopic.php?p=977730 )We are considering to add commonly used functions as built-in.
What functions would you like to see?
While by no means official, there's this: https://registry.terraform.io/providers ... ros/latestSupport for Terraform and an official provider would be amazing.
Looking forward to this.Hello,
MikroTik is planning to develop and build a controller app for MikroTik Devices. Currently we are researching possibilities and options, what should be there and how it could be done and implemented. At the moment we do not want to stick to a specific implementation or standard, but build our own that will help to manage, develop and deploy different scale networks running MikroTik devices.
Any suggestions about features and options are very welcome.
I thought it was BFD reaching out to say hello. But I'm pretty sure we'll both be disappointed.Hmm, I wonder if this video is about the devices controller:
https://www.youtube.com/watch?v=kKnYhWnch0Q
might be CAP AX (XL)Hmm, I wonder if this video is about the devices controller:
https://www.youtube.com/watch?v=kKnYhWnch0Q
... give RouterOS 7 proper configuration transactions. The RouterOS configuration paradigm is already very database-like and, in my opinion, is well-designed compared to some of the big players like Cisco. A huge thing missing for automating Mikrotiks is the lack of native transaction support: the ability to stage a series of changes, commit them in their entirety, and if necessary roll them back. Work spent improving this would make the platform more attractive for all users, no matter whether they manually configure their devices with Winbox/web/CLI or whether they integrate them with an automation tool like Ansible...
+100 for that would be a killer upgrade (checkpoint, VyOS, barracuda,.... all those vendors have something alike for years now)...give RouterOS 7 proper configuration transactions...
integration or a solution like that would enhance large/mass deployments big time!Pretty much all of the network vendors (except JunOS frankly) have one or more of these exact problems and it is certainly a non-trivial effort to make big changes to the core configuration model. However, if you make these types of improvements on the RouterOS side, if you still want to implement an automation/controller/management kind of solution your own engineers won't have to invent something with duct tape and glue on the controller side to keep things in sync or try and generate the API diffs under the hood. Instead, the resulting application can be a pretty basic web app that leverages a simple database or, say, Ansible and git under the hood. You could even partner with an existing automation platform and just make some good RouterOS integrations for it.
The issue is definition of a "failed operation" is tricky, with or without transactions. So the { command, ... } will protect against bad syntax, and that may help in a lot of cases. But everyone's definition of what failure looks like beyond that may be different. So "transactions" aren't the whole story. From a SQL POV, you need a schema to enforce transactional integrity too. And not sure that part be so easily express by the admin (e.g. in the using Ansible etc. track), which look a lot more like policy config, than directly help with controlling devices.You know about the { command; command; command; } construct from commandline?
If only it did work that way, it would save so much pain when trying to bring a replacement unit up. I took me 2 hours of mucking around ti massage my RB750gr3 config into my RB3011, manually extracting certificates and importing them prior to loading config back in for VPN to avoid config errors. also the ability for routeros to ignore duplicate config rather than erroring out.Export already is the complete text dump of the configuration but that text dump is not the way the config is stored. You cannot upload that text file to the router and expect it to replace the configuration on the router.
Agree! The config export file should:If only it did work that way, it would save so much pain when trying to bring a replacement unit up. I took me 2 hours of mucking around ti massage my RB750gr3 config into my RB3011, manually extracting certificates and importing them prior to loading config back in for VPN to avoid config errors. also the ability for routeros to ignore duplicate config rather than erroring out.Export already is the complete text dump of the configuration but that text dump is not the way the config is stored. You cannot upload that text file to the router and expect it to replace the configuration on the router.
I think they have forgotten about it hahaAlready on post #32, this topic is one useless frill... 10 months and no news, no comment, no something from Staff involved of development of something...
viewtopic.php?t=186352#p936170
You didn't see that in the beta version of the controller? ;) I think it already does all those device discovery things...It MUST be able to monitor and auto discover devices [...]
I did not know about this construct. I appreciate the comment :)It is not clear to me what people want and expect... the { command; command; command; } construct already makes sure that only the complete set of grouped commands is processed, and then there is the "safe mode" that can roll back changes when they result in loss of connectivity.
It is already so much better than what I know from e.g. Cisco IOS (but that is some time ago).
Sometimes it is nice to have the model of "apply config, run a test, and if test fails revert to previous config" (as seen in Ubiquiti devices, for example) but it is often difficult to test well within the short interval available for that so it usually is only a test for connectivity, which we already have. Except for the case where you e.g. change the config of a VPN and a disconnect/reconnect is fully expected, in which case safe mode cannot be used.
That is just a NMS. not a controller.Hi all,
because of MT inability to release anything after 1 year...check UPTIME MONITOR. It is opensource and it can run in docker. It can send you notofication thorough many providers etc Microsoft teams and it is very simple, nice monitoring of servers.
https://www.youtube.com/watch?v=DbF96IHOZig
I'm using Cloutik.com but since I learned about Omada and experienced to many disappointments on Mikrotik LTE devices I have to switch to Omada - how it look and work is perfect.Hi all,
because of MT inability to release anything after 1 year...check UPTIME MONITOR. It is opensource and it can run in docker. It can send you notofication thorough many providers etc Microsoft teams and it is very simple, nice monitoring of servers.
https://www.youtube.com/watch?v=DbF96IHOZig
...Already on post #32, this topic is one useless frill... 10 months and no news, no comment, no something from Staff involved of development of something...
viewtopic.php?t=186352#p936170
as i know that kind of feature from checkpoint firewalls or sometime barracuda NGFWsWell, of course for "just access points" it is much easier to do than for generic devices like MikroTik.
I use UBNT access points, but their controller configures similar things as CAPsMAN. The generic solution for a network of routers is much more complicated.
E.g. I would like to see a controller that can maintain configuration on two routers that are in failover configuration.
And also can configure some parts of many routers (e.g. firewall) the same way, while keeping other parts (like details of internet connection) different.
planing and developing a central device controller is quite a huge project.Hi,
Im just wondering why is this topic still open...it has been 2 years since first information about MDC and nothing till now. Not even alpha, beta etc. Everyone is writing their wisches here but realisticly there may not been any device controller from Mikrotik. If you chech competition... MT is getting far behing in HW and even in SW.
I think is something like capsman but for entire box not just WiFi....In fairness, they may want to get a long-term RouterOS first. Since if the controlled devices are in a state of flux/buggy, controlling them becomes a nightmare...
But MT have been talking about a controller here and/or multi-platform client elsewhere for a while...but seem to operate in a vacuum. e.g. we haven't seen any "we're thinking about this?".
And, I'm not even sure if this about a SDN-like L2/L3 network controller, or a Dude-like device management controller, or both...
I would be ok with this! Sign me up for testing.I think is something like capsman but for entire box not just WiFi....
andThe initial goal is to develop a protocol to apply and monitor config [...]
It is intended as a true network management controller, of course probably in the future there could be an option to connect and manage the controller by a smartphone app or any other app or web GUI or whatever.
Think of it like a capsman, but not just for wireless.
Winbox officially supports only Windows. Many admins run Linux.Single app to control all mk devices ?
Winbox with menu -> list devices -> select mk device -> done :)
Winbox place with all devices overview
Winbox templates for auto-configuring ?!
And many admin drink "vine" and run wine...Many admins run Linux.
/caps-man provisioning add action=create-dynamic-enabled hw-supported-modes=gn master-configuration=CurrentMethod name-format=prefix-identity name-prefix=2.4Ghz-
/caps-man configuration add channel=2.4GN country="united states3" datapath.bridge=LAN .client-to-client-forwarding=yes .local-forwarding=yes distance=indoors installation=indoor mode=ap name=CurrentMethod rates=A/N/AC security.authentication-types=wpa-psk .encryption=aes-ccm group-encryption=aes-ccm .group-key-update=5m ssid=TestAP
/caps-man provisioning add action=create-dynamic-enabled hw-supported-modes=gn master-configuration=FROMJSONAPI name-format=prefix-identity name-prefix=2.4Ghz-
{
"channel": "2.4GN",
"country": "united states3",
"datapath.bridge": "LAN",
".client-to-client-forwarding": "yes",
".local-forwarding": "yes",
"distance": "indoors",
"installation": "indoor",
"mode": "ap",
"name": "JSONSample",
"rates": "A/N/AC",
"security.authentication-types": "wpa-psk",
".encryption": "aes-ccm",
"group-encryption": "aes-ccm",
".group-key-update": "5m",
"ssid": "TestAP"
}
ansible can be integrated by today - (rest) api and ssh with pubkey-authFeature: ability to interact with Ansible, and script running capabilities e.g Python/Netmiko for network automation.
Option 2, which in many ways I think would also create the framework for an incredible functionality within RouterOS would be replacing a configuration with JSON client that makes a get request along with various parameters embedded in the request headers and the webserver returns a JSON formatted RouterOS provisioning config.
Wouldn't a simpler solution be some "from-script=" where a script can provides the master-configuration? The script could then /tool/fetch if desired whatever configuration, without being tied to a specific approach like fetching JSON.Code: Select all/caps-man provisioning add action=create-dynamic-enabled hw-supported-modes=gn master-configuration=FROMJSONAPI name-format=prefix-identity name-prefix=2.4Ghz-
If you have RADIUS, why not just WAP-EAP and have CAPsMAN set to use that? I always think of RADIUS as "per-user" thing – so CAP AP provision seems an abuse of RADIUS protocol since mappings on RADIUS server-side wouldn't be clear.Option 1 would be a RADIUS based provisioning method that is part of a configuration profile where the CAPsMAN server contacts a RADIUS server during radio provisioning to get certain attributes like the SSID & WPA
This feels like Apple a few years ago with the iOS releases prior to iOS 12, they rushed year after year to add "features" instead of stability and bug fixes.Before making a big commitment to a new software product; let's get the bread and butter products in order:Existing customers make or break a vendors reputation and they thrive or die from that.
- RouterOS 7 "stable" becomes truly stable (not just a label) first and foremost before all else.
- RouterOS 7 becomes feature complete first and foremost before new software products.
- Hardware products requiring RouterOS 7 features should not impact installed base.
Are you suggesting that openwrt works better on Mikrotik devices. If so, then the faults in RouterOS Wi-Fi must be software related and therefore fixable? I was of the opinion that the flaws were partially hardware?Background: i love Mikrotik devices but they have a flaw: their wireless software part. It works but ... it's not.
Idea: let me install openwrt on them (i already did that)