I was actually trying to reset the save-to parameter, which is only available via the CLI; I was NOT trying to reset the BGP session. Mikrotik has already confirmed the problem. Regards.
When you want to set a single parameter, you have to use the âsetâ command. âresetâ does something else than you think it does.
Probably you will get a different response once the âconfirmed problemâ has been discussed internally.
Reset sets the parameters to default, so it's illogical that you can't then set a specific parameter to its default value using the CLI.
As far as I know reset works either on sections like*/settings or on whole entries (reset all parameters). To reset specific properties of an entry you either use unset value-name=<prop> or !<prop>. But I just saw it was already explained in detail by @CGGXANNX above.
Does anyone else have stability Problems when using MVRP?
Iâve updated my CRS 326 Switches to 7.21.2 and two switches decided to kill my network by sending the full 1,3 gbit from the cpu straight to the cpu of all other switches, which killed all possibilities of finding the error because every management interface was effectively ddosâd
All Ports on the Switches causing the Problem were called âunknownâ and some had errors finding their bridge. Unfortunately i couldnt get any logs because the cpu was busy sending crap to the rest of the network.
Has anyone experienced similar behaviour?
Hi, DerDave.
I have not seen this behavior in our labs. After you restore the access to switches, can you manually create supout.rif files and send them to support? Perhaps there will be hints about the issue.
[SUP-209892]: LTE not working SIMCOM_SIM7600CE-T
Thank you!
I created a ticket for a developer so that he can debug the issue.
I will write you, when we have a soulution or we need more information.
Regards, Artis BernÄts.
@EdPa, thank you for the ability to acquire address for VETH via DHCP.
Container tooling ignores MTU provided via DHCP
/ip dhcp-server option add code=26 force=yes name=jumbo-frames value="'9000'"
/interface veth add address="" container-mac-address=00:00:00:00:00:00 dhcp=yes gateway="" gateway6="" mac-address=00:00:00:00:00:01 name=veth-test
/ip dhcp-server lease add address=192.168.0.3 dhcp-option=jumbo-frames mac-address=00:00:00:00:00:01 server=dhcp_lan
This can be mitigated by
/container shell test cmd="ip link set veth-test mtu 9000" no-sh
if container user is root and it has shell. But if container does not contain shell or user is no root and no su/sudo, MTU can only be set by Mikrotik container tooling. And it does not set it.
Could you kindly add it to your tracker for implementation, please?
I also found a small typo in the ipv6 bad_ipv6 address-list:
Copy pasted exactly from the default config script:
address-list add list=bad_ipv6 address=100::/64 comment="defconf: discard only "
It's completely negligible as a "problem" (one more space, not really a typo...) with all the other ones that still need fixing....
For example, this is the only comment that ends with a period. To make things more consistent, it should be removed...
comment="defconf: accept DHCPv6-Client prefix delegation."
who cares???....
Unfortunately a lot of features breaked from 7.20, and a lot of us stucked on 7.19.6. That was the last most usable version in widespread, it would have deserved the long-term flag.
Which has a security issue
While agree, it's still sloppy.
And, if you're looking for comments to do an update... the = would care 
... now I doubt many folks are updating defconf programmatically using exact match on thse comments
Maybe if you made a list of what's broken, they might have hopes of getting fixed.
yes, but also in my fix...
set [find where comment="defconf: drop all from WAN not DSTNATed"] comment="defconf: drop all from WAN not DSTNATed"
because they fix the space
I must add later:
set [find where comment="defconf: discard only "] comment="defconf: discard only"
This is a perfect example of issues that wouldn't happen if development had even a minimum of test driven.
Would it be more work to write the test to test of defconf than the defconf code itself?
ABSOLUTELY!
But once you do that, and then just maintain the test code carefully, the same problem won't happen again.
Tests for a comment? C'mon.
There is no real problem hereâŚ
What I would find valuable is a MikroTik-supported way of âreset/upgrade the firewall to the latest defconfâ.
Most users never upgrade the firewall because that isnât done at RouterOS upgrade, not even when your firewall was still at default config. There could be a button that removes all firewall rules and re-installs the default ones.
YES I KNOW THAT COULD CAUSE PROBLEMS!!! No need to write that, each and every click in the RouterOS GUI could potentially cause problems.
If the first idiot who wanders by the forum can write something like this:
why not have the upgrade/update process do it?
These are all instructions with absolutely no drawbacks...
But the reality is that people also change comments, instead of leaving them as they are, so it's only effective if they haven't been changed randomly...
And resetting the firewall anyway... that's also difficult...
How do you predict if the user renames the WAN to "internet" or other examples?
My sarcasm is just to show how difficult it is to program everything...
Let's say the defaults should be unchangeable, even the group names; it's up to the user to configure the rest properly...