Ok, I think this change item implements the idea that @strods mentioned here:
While this probably prevent the situation of accidental RA being sent on all interfaces after an upgrade from older versions, this is still less than ideal because:
There is a red warning text over the entries that have "Advertise DNS" turned on from previous versions:
Like all such warnings / errors, in the configuration export, a
# automatic dns option advertising is not started, re-apply dns config
comment will be included above the export entry, which is quite annoying.
While we can easily remove this warning by making some edit to the entries, we might not want to do that for the entry with the all interface. There are configurations where this entry is useful and must stay enabled with the Advertise DNS also active, such as when we have to deal with dynamic interfaces from connecting VPN clients. But if we (accidentally) make edit to the all entry and the warning is gone then we'll have the issue with rogue RA coming from the router again.
I think it would be a better behavior if:
RouterOS scraps the idea of handling "Advertise DNS" differently depending on whether the setting came from an upgrade or was manually set after 7.21.
Instead, RouterOS keeps the behavior introduced with 7.23 (sending out RA even if there is no matching /ipv6 nd prefix entry) but only if the entry does not have interface=all, the entry must be set to a specific interface. If someone wants to advertise RA on a specific interface without prefix, they can always explicitly add a /ipv6 nd entry for that interface only.
When the /ipv6 nd entry has interface=all, then RA is only sent out for an interface if there is an entry for that interface under /ipv6 nd prefix.
In short, the pre-7.23 behavior is kept specifically for the entry with interface=all only. No special handling must be done for the configurations coming from older versions. RA is only sent without prefix entry for an interface if there is an explicit /ipv6 nd entry for that interface. The all entry is not enough for that. The all entry only works for interfaces that also have /ipv6 nd prefix entries (including dynamic entries from dynamic interfaces).
What does this message actually mean/say? I understand automatic dns option advertising is not started, but re-apply dns config? Is this a call to action? "dear admin, please re-apply the dns config"? Or is this a state? "re-applied dns config"? I have set advertise-dns=self that's why I am seeing this message?
If you upgraded from an older version, and the /ipv6 nd have settings that in 7.23 trigger the sending of RA even if no /ipv6 nd prefix entry for the interface is present (for example DNS setting other than no, or MTU setting, I've not tested, but probably when the managed and other configuration checkboxes are active too), then 7.24rc3 will not do that anymore (will not send RA like crazy anymore). The entries will, for now, behave like under <= 7.22.
But if you open an entry, and make some edit, and save change, then RouterOS 7.24rc3 will assume that you've made the necessary adjustment, and will remove the warning from that, and will go back to the behavior introduced by 7.23 for that entry.
This is MikroTik way of mitigating the problem from this upgrade path:
Older version have "Advertised DNS" checked as default value on the default all entry -> Upgrade to 7.21 setting is migrated to advertise-dns=yes but it's no longer a default value, so it appears in export -> Upgrade to 7.23 and RouterOS send RA if advertise-dns is not no, regardless of everything else -> RA are sent on all interfaces.
With the hack in 7.24rc3 it becomes:
Older version have "Advertised DNS" checked as default value on the default all entry -> Upgrade to 7.21 setting is migrated to advertise-dns=yes but it's no longer a default value, so it appears in export -> Upgrade to 7.24rc3 and RouterOS does not send RA if there is no /ipv6 nd prefix entry for the interface, even if the entry has advertise-dns=yes -> RA not sent on all interfaces even if the interface=all entry also have advertise-dns=yes
but if you edit the entry, then the 7.23 behavior resumes.
@CGGXANNX Your diligence is appreciated as always. I still can’t imagine why you didn’t open a support ticket, as Strods suggested, only to wait a month or two for them to ask for another supout, or pcap, and then wait an additional month or two so they could say “we can’t reproduce the problem” and close your ticket …
Indeed. Maybe when a pulldown with both lists and individual interfaces is difficult to make, an option would be to have only standard lists and user-define lists, like in "ip neighbor discover settings".
If this part of configuration would not accept specific interfaces after changes made in a future update, what will happen to all previously configured per-interface entries?
For devices with "home-router-type" default-configuration WAN interface should not advertise anything out to WAN as default. It can even be seen as security issue when RA/DNS advertisements are leaking out.
No wonder that some ISP equipment started to act up after recent changes to the level worth some threads in this forum...
Well, maybe as an intermediate solution they can create an interface list for every interface that was in configuration, substitute that, and publish that it would be better to rework the configuration e.g. to use the LAN list or some other list that covers the particular situation best.
Alternatively they could allow interfaces in existing config but not allow new ones.
It's not that hard to do...
It already exists in the OSPF interface template, for example.
It combines interfaces and interface-lists.
But, to be sincere, I would prefer a bit more verbosity, and a more assertive config.
I know that this is not what Mikrotik used to do...
But to me, the ideal way would be a composed attribute.
Something like below: set interfaces=(interface=ether1,ether2),(list=WAN)
This would make the desired state very specific, and avoid issues with interfaces and interface-lists with the same name.
Considering that this will not pass...
I would suggest to split this parameter (according to where it would fit) to two parameters: set interface=ether1,ether2 set interface-list=WAN
Another thing that would be very welcome?
For the system to come with interface lists for service types already created in the default configuration, including the default interface lists (the blue ones).
Examples:
/interface list add include=all name=ip-neighbors
/ip neighbor discovery-settings set discover-interface-list=ip-neighbors
/interface list add exclude=dynamic include=all name=tools-mac-server
/tool mac-server set allowed-interface-list=tools-mac-server
/tool mac-server mac-winbox set allowed-interface-list=tools-mac-server
/interface list add exclude=dynamic include=all name=tools-romon
/tool romon port add interface=tools-romon
It’s a good way to make better use of object-oriented principles within MikroTik’s RouterOS features.
This way, users would be encouraged to stop modifying configurations directly within the device's specific functions and services, and would (gradually) get used to making changes via object groups—primarily interface lists and address lists.
The list names I came up with there aren't exactly the best... There are people much better at that sort of thing than I am.
But that’s the general idea.
To start incorporating these kinds of options into the default configuration.
if someone has already implemented switch-rules to redirect certain vrf-bound IPs to the CPU for proper packet-handling - how will this interfere with this l3hw-vrf-aware-config?
…