I wasn't aware of this feature before. Thanks for pointing it out!
I'm still curious why the DHCP client behavior was changed. Before RouterOS 7.22, if I enabled a DHCP client on the same interface that was running a DHCP server, the router would not obtain an IP address.
I have one Router(first one in image), acted as CapMan, and 7 APs. All upgrade from 7.22.3 to 7.23.1
Then I found in /ipv6/neighbor:
Flags: D - DYNAMIC; R - ROUTER
Columns: ADDRESS, MAC-ADDRESS, INTERFACE, VRF
# ADDRESS MAC-ADDRESS INTERFACE VRF
0 DR fe80::1 3C:A1:61:6C:E9:44 ether1 main
1 DR fe80::2ec8:1bff:fe4a:828f 2C:C8:1B:4A:82:8F bridge main
4 DR fe80::2ec8:1bff:fe4a:805b 2C:C8:1B:4A:80:5B bridge main
It means two CAPs from bridge sent IPv6 RA and router and other machines accepted. Router ipv6 route table was
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC, r - RIP, b - BGP, o - OSPF, i - IS-IS, d - DHCP, v - VPN, m - MODEM, g - SLAAC, y - BGP-MPLS-VPN;
H - HW-OFFLOADED; + - ECMP
DAg + dst-address=::/0 routing-table=main gateway=fe80::2ec8:1bff:fe4a:828f%bridge immediate-gw=fe80::2ec8:1bff:fe4a:828f%bridge distance=0 scope=30 target-scope=10
D v dst-address=::/0 routing-table=main gateway=pppoe immediate-gw=pppoe distance=1 scope=30 target-scope=10 vrf-interface=pppoe
DAg + dst-address=::/0 routing-table=main gateway=fe80::da86:8eff:fea1:37%pppoe immediate-gw=fe80::da86:8eff:fea1:37%pppoe distance=0 scope=30 target-scope=10
DAg + dst-address=::/0 routing-table=main gateway=fe80::2ec8:1bff:fe4a:805b%bridge immediate-gw=fe80::2ec8:1bff:fe4a:805b%bridge distance=0 scope=30 target-scope=10
So ipv6 traffic send to wrong gateways.
I don't know why CAPs send ipv6 RA. So I logined to every CAP and disable items under /ipv6/nd
Then everything works well.
I found 3 CAPs ipv6 enabled in (/ipv6/settings/print) while other CAPs are all disabled. So I also turn off ipv6 of all CAPs.
Anyone has better solution?
Do you have IPv6 forwarding on CAPs enabled or disabled?
There have been several reports of this. I think it's from this change item:
I did some tests, and RouterOS now always sends RA on an interface if there is an /ipv6 nd entry that matches that interface, including the default entry with the all interface. No prefix needs to be present, even the MTU and DNS settings can be empty. If you dont want the router to advertise itself as gateway then you should set ra-lifetime=none on the entry matching the interface, or remove it. However don't forget that if you keep the entry with the all interface enabled then RA will still be sent for all interfaces not having their own ND entry in the table. So that should be removed too, or set ra-lifetime=none for it.
I did some more tests with an old installation running 7.21.1 and the behavior with one single default /ipv6 nd entry with the all interface was:
If the interface has an /ipv6 address entry with advertise turned on -> RouterOS sends RA on the interface.
If the interface has no /ipv6 address entry, or has one but with advertise turned off:
/ipv6 nd prefix and add an entry with prefix=none for the interface -> RouterOS sends RA on the interface, with support for the options in the /ipv6 nd entry like MTU or DNS.The option for setting prefix=none under /ipv6 nd prefix was added in 7.21:
And I did use it when it came out on one my test setups that provides no SLAAC for the clients, only DHCPv6, by adding an entry with prefix=none I was able to have the router send out RA message normally, with route / DNS / MTU information. And that worked well.
So I don't see the need for the change in 7.23 that has caused problems for many people on the forum in the past day. There is no need to change the behavior so that RA is now always sent, event when /ipv6 address has no entry with advertise. That should not be the default. If sending RA without prefix is needed, there exists already the method with /ipv6 nd prefix add prefix=none... introduced since 7.21.
by default setting, IPv6 forwarding is enabled
Yes it is, but normally CAP does not do forwarding so I disable it always on all devices that are not routers. Maybe this is why I do not have this problem with RA messages sent out by AP's...
So is IPv4 forwarding and it should really always be disabled on anything but routers and IMHO it should be disabled by default same as DNS allow-remote-requests for example ...
I agree that default setup should be conservative about sending out RAs. Specially so as similar functionality is pretty centralized in IPv4 - mostly it's about gateway setting on DHCP server - and people are used to it. And specially so as sending RAs on WAN interface can screw ISP's gear (as proves case of @mozerd and a few others) for such user and pissibly also for other ISP subscribers (rogue router in this case can be as detrimental as rogue DHCP server).
With MT there's plenty of controversy about default operation mode. IMO there should be a QuickSet mode for "AP+LAN switch" on all device modrks with wifi interfaces (and on wired-only devices that would shrink to "LAN switch" only) ... but AFAIK thete isn't one. Further devices with less than 3 wired interfaces should IMO come configured to "AP+LAN switch" mode by default. I'm not saying that e.g. cAP ax or wAP ax won't be ever used as home routers (for people not using wired connections), but IMO majority of those devices are used to provide (additional) wireless coverage in use cases where there's another device doing routing.
Not to mention "pro line" of devices (CRS families, CCR family and a few other) which come without any configuration whatsoever ... but quite a few are used by inexperienced people because of availability of multi-gig home internet access and people need something beefier than RB5009 to benefit of excessive speeds provided by ISP. Lacking any configuration forces people to look for help with configuration online ... and we all know that most online help (including AI), when it comes to Mikrotik, sucks big time.
On non-router devices I usually disable all IP forwarding. btw even in dual-stack network you do not actually need IPv6 be enabled anywhere else beside routers (if other devices are not doing IP forwarding)
At least now we have RA guard feature to fight the possibility of rogue devices.
This issue seems to have been solved here Problem with dhcp in 7.23rc. The solution is to disable the default RA setting which sends RAs on all interfaces and instead create per interface RA configs for your ipv6 enabled interfaces.
Two Latvian products do not play well together at times...
Is it just me or this 7.23.1 generating A LOT is sector-writes again ??
My box is running since 2d 15h and has already performed 1 012 767 sector writes since last reboot ?!!
Total of 44M sector writes since I first powered it on a few years ago...
EDIT : I think I know what is going on. I have both "smb" and "nfs" disks mounted. With certain logging levels I write files on my NAS. I have the impression this "counts" for disk-writes too, albeit strictly speaking they are not because it should go into a network-socket and that's it....
I have had similar suspicion about writes to SD-card as well...
Since my test yesterday it seems to have stabilized at 1 013 521 writes.
So I turned off my "smb logging" (to a SMB-share mounted on a NAS)
So either that is a bug that RouterOS considers remote mounts also as a disk or/and there is some "buffering" intermediate that I'm not actually writing directly to a SMB-share, but first to buffer-space on the embedded disk and that gets counted....
Hello,
To restart any session we only needed to use "enable" CLI command or Winbox button.
Since 7.23.1 (maybe before but i doubt of it) it is no more possible.
So there is no more safe way to restart sessions (PPPoE, L2TP...) except reboot completely the device, that's a huge regression.
Thank you for fixing it ASAP.
Hi,
I have problems with this version of routeros on CRS326-24G-2S+ .
since I upgraded to this version, some ports no longer connect above 10 or 100 Mbps, including with other Mikrotik equipment. I have noticed this on all CRS326-24G-2S+ switches that I have upgraded.
Thanks,
Geo
I can't confirm that. All ports run at 1 Gbps if the device supports it. All the others run at 100 Mbps.
Maybe specific settings were configured for certain ports in the past, which worked fine in the previous version but may no longer do so.
Have you already tried resetting one of the affected ports?
interface/ethernet/reset