Yes, of course I have support ticket. They see problem, but cannot replicate.
1100AHx4 freezed every week because of this.
Now it runs on chr Core i9 9900KF and 48GB ram
that is nasty, if MT can’t reproduce it, they can’t fix it …
The only thing that can be done is try to pinpoint it to certain hardware, configuration and/or combinations of that.
I used to run dude on chr until 2 years ago, had so many VM related problems that I decided to get a dedicated MT device to run dude on.
No problems since then.
This should be easy to replicate. I have a CHR running Dude on Hyper-V and it reconnects enough that it crashed winbox server on one of my ccr1036 out in the field. Had to reboot it through SSH.
Have been Struggling with this issues for months - and have found my reason… but it’s not a happy situation.
Have CHR with 4gb RAM and 4 Cores - nothing over the top.
Issue arises when i have Dude trying to reconnect to multiple ROS devices at the same time - CPU perfs out on one core, and as they use the winbox service for these connections now (historically was the dude service) All connectivity to the Dude flies out the window, including Dude Client and Winbox into unit. Perfs out for extended times.
The "Fix i have in place at the moment… disabling my allow for winbox connections from Dude… Obviously that entirely breaks monitoring for ROS functions, but having monitoring for all my devices (4k+) trumps having dude fall over because of a few hundred winbox connections.
Have re-eanbled for my core devices - but client cores and other structure are to be determined at this stage.
I also have a spare ccr 1016 with microsd slot floating around - will look to build it up quick at some stage to test, but have a couple weeks on the road coming up, so will have to to it after.
Hopefully this helps someone, and if anyone think’s the info is pertinent, hand it over to the dev team (i don’t even know where to start with contact - will be looking deeper once i have the CCR tested)
Same issue here. We have an Amazon Ec2 machine with CHR with The Dude.
We confirm that 6.45.9 is the last stable version.
We are in struggle because we need to upgrade our devices (1000+) and we nned to monitor them, but we can’t beacuse The Dude v6.45.9 can’t monitor devices with firmware v6.46.4+
reduce or remove all ros_command and ros_info used,
simply convert all to SNMP
like the uptime use
oid(“iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.sysUpTimeInstance”)
than ros_command to obtain it
I do not understand. How can you take away the functionality that is the main feature ... Cut the possibility of normal collection of information through ros_command & ros_info ... Some information is either not possible or difficult to obtain through SNMP. Also, how can you write this lie that can't repeat the problem. Are you holding us fools ??? This is a question for developers. Give at least one comment!
Here, look at this beauty. No wonder the dude is going crazy. And now imagine if the dude has a 3000 routerboard.
Imagine that for many years the network with 3000+ MikroTik’s was monitored by an update through a dude, and used ros_info and ros_command for this purpose. And here is an update that breaks everything. I understand you do everything as easy as possible for you. But we have been buying your products for many years and have the right to be treated humanely. For many years, please make the dude a commercial product. we are ready to pay, but make a quality product !!!
For you there is no need, you already are if you read things that I have not written …
And this is a user forum, not a support platform, if you do not have noticed that.
Write directly do support@mikrotik.com
Are these enough?
It’s perfectly normal than the connection is open just for execute the command and then closed,
It’s perfectly normal than the connection is logged on RouterBOARD log,
What you expect from this?
Everything I wrote does not apply to you. I have just quoted you and fully confirm your observations on this issue. Also, my post only applies to developers.
Sorry, but I misunderstand, you wroted continuosly without break…
That is the Log of ONE RouterBOARD, not the Log of The Dude, or at most it is the RouterBOARD where The Dude is that self-interrogates…
However it goes, each RouterBOARD has its own Log, not all 3000 are put together.
And if someone have 3000 devices, probably have more than one dude…
And again, you understand this?: It’s perfectly normal than the connection is open just for execute the command and then closed,
It’s perfectly normal than the connection is logged on RouterBOARD log,
I do not understand why you were blown up by my posts. I have no complaints about you. Everything I wrote is for developers. Let them comment. And to write in technical support does not make sense for 10 years they didn't solve any problem about which I wrote on the dude.
Go ahead and write direct posts to the developers,
who can’t wait to come here on this topic to see what you write,
but don’t quote others when you do, or it seems that you write to the quoted…
I doubt that they will give you the slightest listen if you have not even understood the two bold lines, on previous post, I wrote to you.
Goodbye.
Where did you get what I didn't understand?
And I'm not interested in your opinion at all. And you have no right to call me a fool. I didn't call you names. I did not address you. If you call someone you are a juvenile jerk.
I don’t understand this sentence, who should I call?
This is a user forum, and you keep to not understand, if you do not want opinons, do not write,
You still keep this behavior because you do not understand simply this two sentences: It’s perfectly normal than the connection is open just for execute the command and then closed,
It’s perfectly normal than the connection is logged on RouterBOARD log, Probably that is a new choice, instead to keep connection alive for thousand of devices, which will surely consume more memory to keep them all open.
You must understand that it is perfectly normal for Access Logs to be written to the remote device,
one for when The Dude connects to the remote device,
and one for when it disconnects.
You would like the service to no longer be logged in and any unexpected access wod not be noticed…
This is not a The Dude bug, is your problem, what you expect from support?
For not see anymore the access Log, simply put on /system logging on the info topi settings add !account
The problem is that the same configuration on 6.45.9 works fine, but sooner or later it will need to be updated. I presented the log only as an example of a new approach to the work of a dude. Which after 6.45.9 constantly loses contact with devices on the network. I'm not saying that the problem is in the connection logs.
You described how to solve this with SNMP and I just commented on it. Why are you so negative to me, i as if not your blood enemy