Anyone else see this issue? I noticed it also, cap randomly leave and join, nothing was changed my side, using default firewall, all new mikrotik poe switches and cables tested and all worked fine for 6+ months, no droped single ping between devices.I think it started after 7.23 update. Have not tried the 7.23.2 yet, but as nothing mentioned in changelog not sure if its fixed.
You forgot that the same fix is applied on v6 which has only one binary-facing change besides this fix (the other two should be purely WinBox definition files :> Be clever, don't work harder - work smarter.
Someone to have tested this build on RB5009? Some bugs or anything?
on 4 pcs (one at home) no issues
Updated a RB5009UPr+S+. Config uses a bunch of vlans, fw rules, CAPsMan Server, Wireguard, scripting, DNS, DHCPD, SFP. No advanced routing/ipsec/IPv6/Containers/PPP/.... Everything works as expected so far
There seems to be some kind of race condition when creating ospf interfaces from templates. If I keep removing all interfaces and add them again (in one cli command, so remove [find]; add area= if=if1; add area= if=if2 etc), then it seems that every time randomly some other interface(s) will be marked as duplicate config.
CGGXANNX, pe1chl - Still not seeing this issue in our lab (as you described it). All IPv6 ND settings set to default and IPv6 "/64" address without advertise=yes added. What is the reason why you can not just open support ticket, provide supout file and .pcap capture of such RA advertisement? Bugs should be reported to support first.
Because on my real routers I do not keep the default ND entry enabled and always create individual entries for the interfaces where RA is needed, so I am not affected by this and don't want to spend the time to create a support ticket and have to handle all the waiting? But even in the 7.23 release thread, enough people have reported the problem and I thought MikroTik staff does follow the release threads? Here a some sample threads for you:
- This huge one which at the beginning no one knew
/ipv6 ndwas the real cause: Problem with DHCP in 7.23rc when used behind Rogers' modem in Canada - RouterOS / General - MikroTik community forum - In the 7.23.1 thread 7.23.1 [stable] is released! - Announcements - MikroTik community forum.
- Another IPv6 Nieighbor Discovery for Bridge Advertises Invalid IPv6 Default Route - RouterOS / General - MikroTik community forum.
- More [7.23.1] Invalid IPv6 prefixes after update from 7.22.3 - RouterOS / General - MikroTik community forum.
I did packet capture back then with my test CHR installations. After your comment today, I repeated the test and can now point out to you the real cause why it affected so many people. Do this in your LAB:
- Pick any device, including CHR
- Put 7.20.8 on it. It can be any version <= 7.20.x, but the download link to 7.20.8 can still easily be found on the the "long term" download page without having to manually edit the URLs.
- Reset the configuration, you can even reset to a blank configuration if you want.
- Observe with any packet capture software that the router does not send RA on any interfaces.
- Switch / upgrade to the latest stable 7.23.2.
- Observe that the device now sends RA on all of its interfaces.
And here is the real reason. Before 7.21, before this change:
This is the default state of the default /ipv6 nd entry. The state when /ipv6 nd export produced no output at all:
That's what everyone who have never tinkered with the default IPv6 ND entry would have!
The upgrade to >= 7.21 will convert that to this:
We can say that this is a problem that the majority of device owners who bought their devices before 7.21 (which was released less than 6 months ago) and have not reset the configuration after 7.21+ will have, and MikroTik has to address that!
You should really revert the 7.23 change (the functionality provided by 7.21 is already enough), because there are certainly many long-term users who have upgraded to 7.21.5 and have the dormant
/ipv6 nd
set [ find default=yes ] advertise-dns=yes
on their devices that will throw the problem to them once they upgrade to 7.23+ in the future.
how we check if VRF does HW?
I think that problem is the "advertise-dns=yes" in that default entry.
Previously default entry only had Advertise MAC address enabled. Advertise DNS being enabled in default entry is questionable as not all devices are DNS servers in their default settings (on all interfaces to make it worse).
Does setting "advertise-dns=no" on default entry solve the problem of unwanted RA's?
Yes, it does, and it's the default if you reset the configuration in 7.23. If MikroTik in their tests always reset the configuration to default first (and did not test the upgrade path from <= 7.20.x) then they obviously could not see the problem.
But they normally have the policy that upgrades do not modify the values set by previous defaults. And the users had to manually port the settings themselves. That's why this page from @tangent exists:
MikroTik Solutions: Configuration Flotsam
It's easier and less disruptive to just revert to the RA behavior from <= 7.22. As the use case for which the 7.23 change has been introduced was already covered by 7.21.
If you don't set DNS Servers in this dialog and set Advertise DNS to yes, then the IPv6 entries, if any, that you see under IP -> DNS will be advertised. If there is none there, then the link-local address of the router (similar to self) is advertised.
Have been able to repro this behaviour using two CHR's, so reported an issue.
Exactly that - just ran a capture and these were there. If "advertise-dns=no" capture is empty (nothing goes out to ff02::1)
well, it was nice experience 
after updating bunch of working MT device with many vlan interface
i was forced, at least, to review configs once for good,
Linux servers: adding /etc/sysctl.d/98-ipv6.conf with restrictive stancas
MT devices: only fixed IPv6 for MGMT addr/routes, all auto learn stuff turned off
...etc
only to prevent "non-existent bug", as @strods mention
now, hopefuly, at least MGMT part of network will be protected from MT random ND/RA behaviour in future releases
The biggest failing of this is that RA's go out on WAN interfaces as well (even if "options only") - which caused all these problems with "Rogers cable modems" along other things. It should not be like this as default.
It is not a "non-existent bug" no matter how much Mikrotik would like it to be...
It is a bit strange, though. I checked the sent RA's and while they are "Router Announcements" they do not actually include the subnet prefix. There is only the specified DNS server AND another DNS server entry with the local address of the router with lifetime=0. I don't know if this RA is what upset the Rogers router.
It may be that an RA without subnet is considered a gateway announcement by systems that already have an address. That could be considered a bug, but I agree with @CGGXANNX that RouterOS should not by default start sending RA that it did not send before.
In case we are expected to configure /ipv6 nd in more detail than just for "all" interfaces, it would be welcome when the interface selection also supported interface lists.
This is a valid usecase. For example, I have a test setup where the LAN clients should only acquire IPv6 addresses via DHCPv6, no SLAAC (because the config deosn't have free /64 left). The router advertises RA with RA Lifetime > 0, the management and other flags turned on, and optionally DNS too (with RDNSS option in the RA packet), but no prefix is included. RA is still needed in this case because DHCPv6 does not have the gateway information.
As I've written before, this usecase is already possible in 7.21. No /ipv6 address entry needs to be added to the interface with advertise=yes. What needed was an entry:
/ipv6 nd prefix
add interface=the-interface prefix=none
Before 7.21 it was not possible (because prefix=none was not supported). In 7.21 and 7.22 RA is not sent if no /ipv6 nd prefix entries exists for the affected interface. You need the entry with prefix=none for the usecase of sending RA without prefix.
But this was good so, because no unintentional RA was sent (you needed to turn on advertise=yes under /ipv6 address, which in turn creates dynamic /ipv6 nd prefix entries, or add the static entry with prefix=none).
7.23 suddenly decides to send RA even when nothing exists for the interface under /ipv6 nd prefix.