Maybe it will be a larger update vs incremental.
Can someone explain -
“The Dude requires “winbox” policy instead of “dude” to monitor v6.46.4 and v6.47beta30+ RouterOS type devices.”
My guess is that they make some changes how the dude interact with routerOS so you need to have winbox policy in order to user the [emoji819] RouterOS in the dude application
Sent from my Moto Z3 Play using Tapatalk
It must be the problem of ROS. It is normal to use other routers IPv6.
The minimum can be set to 10 minutes, the time is too long, everything is meaningless, do not know if it will work.
Thanks for the support, I don’t know if the official will ignore it.
yes, it still sucks. moreover those ND prefix entries are dynamic.
there’s another workaround i proposed to support:
once an interface is getting renumbered (read: it looses a certain previous GUA) either automatically (via pool addressing) or manually (/ipva address remove X)
RouterOS should send a last RA with the disappearing prefix to the network with valid-lifetime = 0. this shall flush all the caches on the nodes that receive it.
in reality this isn’t a workaround, more like an addition. i collected packet captures from different devices, and they all respect the DHCPv6 lease time in their RA.
so this two changes shall be combined.
ok, there should maybe be 3 changes, as the DHCP-PD server in routeros also doesn’t care about the lease of dynamic pools if it operates based on them.
sure, you can tune down the lease-time setting in the manually created DHCP-PD entries, but not in the dynamic ones, spawned by /ppp profile configuration.
in either way, you have a change in the pool you receive via PD, and your entire downstream network will lose v6 connectivity.
in this latter case i’d definitely use a simple algorithm to avoid massive leases on all PD clients:
- setting for a default lease time (globally) say SYSTEM_DEFAULT_DHCPV6PD_LEASE (currently it’s 3d)
- setting for each PD entry specific lease setting, DHCPV6PD_ENTRY_LEASE (if not specified explicitly then copy over SYSTEM_DEFAULT_DHCPV6PD_LEASE)
- the value derived from the current lease expiration of the referenced pool entry (POOL_LEASE_LEFT)
and the DHCPv6 reply to the PD client shall set th valid lifetime in the IA Prefix option to X, where
X=min(DHCPV6PD_ENTRY_LEASE, POOL_LEASE_LEFT)
this way we’d only have shorter leases than intended if the pool we operate on is running out of lifetime. and we avoid propagating outdated info and potentially cut of parts of the dynamically addressed v6 network from the outside
Yes, that is what I wrote above as well. But it does not do that.
I checked in a trace and I see that it also does not clamp the time to the 1800 seconds set for ND so lowering that probably will not work either.
The valid time transmitted in the RA is the time it gets from the DHCPv6 PD pool. Even when that is more than 1800 seconds. That is a bug as well, IMHO.
Fortunately this dynamic address crap is not used over here… it is a big PITA especially because RouterOS does not have NPT (network prefix translation).
It makes IPv6 practically unusable on your local network.
The ipv6 of ros is really too bad, even the basic use cannot be guaranteed, everything needs official attention and repair.
i’d say there’s a lot more to improve, but it is still superior to many other available implementations out there. and i love the flexibility it offers to me. i spent 20+ yrs in networking, working with all kinds of devices. when it comes down to flexibility, only junOS comes near to routerOS. i’ve grown up using the cisco CLI, still do it in my ‘other life’. nothing is perfect.
you would not believe what kind of pains we endured because of a small packet parser issue in the iOS XR code, and it kept bringing our network to its knees for more than 1 month with absolutely random occurrences. all this was because the microcode identified az IPv4 packet to be IPv6 one which started a chain reaction, and took out sometimes 3-7 ASR9k routers in a row. or when we had to as for an enhancement, because the device was not doing fragmentation and broke PMTUD by silently dropping packets with DF flags.
shit keeps on happening, and sometimes it is totally ridiculous to see what type of junk goes through the software QA of some big brand names.
ROS certainly lacks a lot of things, but it is improving, sometimes in bursts, but some things take a longer time. if we can provide usable feedbacks to dev, they can pretty much nail it down quickly. i once had a feature request with 6.32(?) to add support for DWDM SFPs, and it was done in less than 2 weeks and it was working. if you are specific with the enhancement details or can pinpoint the actual issue, stuff can improve pretty fast.
I agree with you.
IPv4 will be eliminated in the near future, and IPv6 will become mainstream. The function of ROS in ipv4. Flexibility is unmatched by other router systems, I hope it can continue to develop in IPv6.
+1
for conditional forwarding of DNS queries AND DoH TOGETHER.
Upgraded from 6.45.5 to 6.47rc2.
Noticed that btest is taking up more memory causing boards with 32MB RAM to become unresponsive.
I don’t know in which version this started. I also tried 6.46.6 with the same results.
Note from MT about the Btest
Please remember that Bandwidth Test uses a lot of resources. If you want to test real throughput of a router, you should run Bandwidth Test through the tested router not from or to it. To do this you need at least 3 devices connected in chain: the Bandwidth Test server, the router being tested and the Bandwidth Test client.
This is irrelevant.
The change log is not comprehensive. Shouldn’t it include all changes when moving the release candidate to it’s own thread?
I’m referring to the following changes which fix packet loss due to bridges learning IP neighbor mac address on blocked STP ports, easily reproducible in a simple ABC triangle.
Originally reported:
http://forum.mikrotik.com/t/v6-44-3-stable-is-released/129680/122
Discussed this in more detail via a support ticket where some items were simply ignored, for example that LLDP RFC details that link local discovery shouldn’t be forwarded by bridges.
Annoying not to ever get feedback when reported problems are worked on, undercuts the good work that is being done and often doesn’t allow the original reporter to test and provide feedback while the developers’ memory regarding the changes is fresh…
From somewhere in the middle of 6.47 beta:
*) discovery - do not send discovery packets on inactive bonding slave interfaces;
*) discovery - do not send discovery packets on interfaces that are blocked by STP;
Would also like to know? Have only been around since N days. One link I could test showed no difference.
Well, since there is no detail on this, I can share our experience of 5 Km PtP Nstream. There is infrequent disconnection that we cannot explain. We tried to move to NV2 when possible but sometimes in the past Nstream would have given better throughput. Not sure if this is related or not.
I didn’t notice any difference on an 802.11n Nstreme link that I tried 6.47rc2 on.
But it was working fine before anyway.
The general problem with Nstreme, since 802.11n, is that it keeps disconnecting for no apparent reason.
“Polling timeout” IIRC.
When it works OK (clean frequency and biting your tongue the right way) it can even outperform NV2.
You get “0 to 100” in less than a second, while on NV2 the bandwidth slowly climbs to the maximum.
Also the latency is much lower (0.5-0.6ms compared to 2+ms of NV2).
In general, NV2 is mediocre (compared to other TDMA implementations) and not suitable for PtP links.
Especially when you go over multiple NV2 hops, the performance can be atrocious!