I'm really curious as to what is lease time for affected people, especially those that get network for a while but then lose it. Is it that DHCP lease lasts only short time and RouterOS does not renew it or is DHCP lease active and bound while network traffic suddenly stops being received?
At least for me, the lease acquired after negotiation with upstream is, iirc, 23h30m.
Hi all!
I just read through this whole thread, but didn't see if anyone figured it out? I had the exact same issue. Firmware updates have been seamless until 7.23. I updated it and it dropped the Wan connection. If I rebooted the modem, I would get an IP, and briefly have connectivity, then it would drop again, and the only thing I could do to get thye IP back was to reboot the modem again. I have to walk several flights of stairs to get to that modem, so I am not sure how long it lasted, but I don't believe it ever lasted more than 5-7 minutes. A couple times it had dropped before I got upstairs again. I do NOT use Rogers Internet, but I don't know who makes their modem. I am in NYC, and use Spectrum Cable Internet, and my modem is a model **"**EU2251", but it doesn't say who makes it. So has anyone figured out what the issue is yet? I see they released a 7.23.1. Is it fixed in that? i couldn't tell from the release notes.
Thanks in advance!
@roram3, same advice as other: sniffer during startup be best, and/or adding topics=dhcp to /system/logging to collect debug-level logs at boot also be helpful. Since it may be device related... if it's RB5009, that someone did say worked, but model may be a relevant detail.
For logging, this get you more detail. If you save a supout.rif after adding logging changing and rebooting... you'd have that debug log info in report for MikroTik:
/system logging action
add memory-lines=10000 name=dhcpmem target=memory
/system logging
add action=dhcpmem topics=dhcp,!packet
The new logging action uses more memory to store more than default 1000 lines, and the topic= should get DHCP without packet level logging. Now you can remove the !packet but it become almost unreadable, but above is likely a good starting place.
The EU2251 DOCSIS 3.1 modem, widely distributed by Spectrum, is manufactured by Ubee Interactive
I have noticed that, with the default settings, version 7.23.x (also RC versions) sends a route advertisement containing link-local addresses to all ports even without a public IPv6 address; this also applies to the WAN interface.
For my configuration, I have disabled the default setting for ‘all’ and configured only specific ports or VLANs.
As far as I know, that wasn’t the case up to version 7.23.x.
@mozerd
Perhaps the problem isn’t with the DHCP itself, but rather that this RA is confusing the modem.
Thanks for your contribution but that is not the problem. I have always defined my ND as you can see in the following:
That just proves that you have ND enabled on your WAN interface, ether2.
/ip dhcp-client add interface=ether2 name=ether2 use-peer-dns=no
/ipv6 dhcp-client add add-default-route=yes comment="delegate ISP-assigned prefix" interface=ether2 pool-name=rogers-ipv6 pool-prefix-length=64 prefix-hint=::/56 request=address,prefix use-peer-dns=no
/ipv6 nd set [ find default=yes ] advertise-dns=yes interface=ether2 mtu=1500 ra-lifetime=none reachable-time=5m
Why are you even advertising DNS to your ISP? 
Would be hilarious for this to be the cause.
Mr Sunshine <> Yes that is an error <> Thank you for finding that error of mine ... and NO that is not the issue of the failing v7.23xx.x and 7.24beta1 ...
Did you test with the entry for ether2 removed?
First let me say that Znevna found my problem and now 7.23.1 works ... Thank you and I apologize for my poor behaviour ...
Its remarkable that all previous versions from 6.48 through 7.22.3 worked with that error in place ... so apparently Mikrotik have improved the network stack to the point that makes that error only obvious to the decerning eye ... WoW ... THANK YOU Znevna, you truly are an expert ...
And thanks to @DanMos79 who highlighted the network discovery issue that drew attention to the error condition found by Znevna in my ROS code directive ...
The problem code
/ipv6 nd set [ find default=yes ] advertise-dns=yes interface=ether2 mtu=1500 ra-lifetime=none reachable-time=5m
Now corrected to /ipv6 nd set [ find default=yes ] interface=ether2 mtu=1500 ra-lifetime=none reachable-time=5m
I did not find your problem, @DanMos79 mentioned it as a possible cause, you can mark that as the actual solution in this topic, you didn't solve it.
I've only pointed out that your config was actually set as he mentioned, even though you were a d*** about it. (you can actually thank him for his contribution 
)
But I'll be damned, your NOC guy surely was hallucinating, huh? Bridge Option 82, Transaction ID stuff and other crap.
You're welcome...
In my opinion, the default setting shouldn't be set to 'all interfaces' but to the bridge. However, the modem should also ignore any RA it receives, as it makes absolutely no sense at this point.
I agree with Znevna, give @DanMos79 the credit he deserves and mark his comment as the solution.
It is.
But what is tragic (IMHO) is that the good Mikrotik support guys (that should know in detail the changes at each OS release, besides the one-liners that are published) should have handy a sort of reference like:
Change #1 affects settings in or are affected by settings in:
- here
- there
- also here
- and here
- etc.
so that it should have been easy to find the (mis-) configuration that at the end was the culprit.
Nobody thought that Rogers is that stupid to block the subscriber for a silly RA.
1000% this. In my case, my edge router (RB5009, since they can't fix the Hex refresh crap SoC ether1 problem) already had custom ND settings for IPv6, so no ISP DHCP issues were seen by me.
However....
I also run several MikroTik devices downstream of my router, which ALL started spewing IPv6 ND/RA packets out after updating to 7.23, putting bogus IPv6 default routes all over my network. Didn't take me long to realize this, of course.
So, yes, the "the good Mikrotik support guys" as jaclaz refers to them maybe should have realized this would happen in a network with multiple MikroTik devices using the default ND settings, and therefore changed the default setting for IPv6 ND "all interfaces" to the default "bridge", as suggested here by DanMos79, or perhaps even have it be disabled by default.
Or make it support interface lists .....
I don't think that this issue is only caused by a misconfiguration. It will also happen with the default configuration that has the single /ipv6 nd entry with the all interface.
As I wrote in the 7.23.1 thread, probably due to this change:
RouterOS now sends RA for every matching interfaces, even when nothing is turned on. No prefix / MTU / DNS / MAC setting needed. If you set ra-lifetime=none, a RA packets are still sent, just with RA Lifetime set to 0s.
So the default configuration with the all entry is enough for @mozerd to experience the problem.