Can you explain to me how do you count lost packets if they never arrived?
Only the higher-level protocols that count the packets they expect can give any idea of packet-loss.
There are no “expected” packets in transport.
Ping is a service, use ICMP protocol, not a transport, and can count expected not-replied pings.
The courier who brings the parcels doesn’t know if he has lost one or it hasn’t been delivered to him on departure,
unless SOMETHING ELSE of a higher level (the waybill) tells him what is missing.
In fact, the truck itself knows nothing about the packages it carries,
but the transport note, which USES the truck to be transported, has the list instead.
But the truck cannot read the delivery note, and only at the end, when the load has arrived,
can someone who reads the delivery note, also transported by the truck, be able to determine if any parcels are missing,
but by now the transport has already taken place and ended…
Some users have bad performances with ipv4 and enabled bridge filters actives.
In previous versions (7.7 and 7.8) there was no issue. Since 7.9 (stable) ipv4 bandwith is lower for about 35%.
So what is your problem?
I see the same thing. Packet loss is 0% on ping from either router or host behind it.
So my conclusion is: no problem.
But apparently some people believe they have a problem. What is it? You see “rx drop” and assume that is a problem?
It seems that something in bridging code has indeed been changed - in my case the wired bridge ports on RB952 (CPU mipsbe, switch chip 8227) with hw=yes setting do not communicate (except DHCP) if they turn up AFTER another port with hw=no is already up. If the port with hw=yes turns up as the first one in the bridge, everything works as configured. I worked around this inconsistent behavior by setting hw=no on all wired bridge ports and will investigate it in a detail when I find some spare time.
I’m having issues with the switch ports on RB750Gr3. Very strange behaviour. Sometimes no packets Tx or Rx shown under “interfaces” (but the port is active and transmitting packets). Shows no link active (but it is…). Seems to be the last port plugged in. E.g., by unplugging the “bad” port and one “good” port, then plugging back in the bad port first, the “good” port now becomes bad!
And the log shows link up and link down all the time, even though… it isn’t. And sometimes, all the switch ports go inactive. Setup is basically stock. Reverting to 7.8 fixes all issues. Going back to 7.9 brings them back.
Never had this kind of issue before. Anyone else, or am I blessed or have done something daft?
Checked on my Hex, can’t confirm (pretty basic config as well).
I switched it on this morning around 7 AM and up til now (16h11), no messages in log about ports being toggled.
Hardware: RB5009
Issue: Container import problem in v7.9. After upgraded firmware v7.9 to RB5009, I tried to update the existing working container for Adguardhome to the latest version as well (adguard/adguardhome:latest). The following error was found in the log.
Registry in use : https://registry-1.docker.io
Solution: http://forum.mikrotik.com/t/v7-8beta-testing-is-released/163742/1
... importing remote image: adguard/adguardhome, tag: latest
... was unable to import, container d9f3b14b-efe0-4788-90ee-edeb024f08fb
Thanks for checking. Mine ran okay for around 10 hours or so. I also noted something in the logs about configuring switch ports for hw offload (not sure if I have seen that before?) after upgrading to 7.9. System is performing normally now I have “downgraded” to 7.8. I am reluctant to revert to 7.9 to get a support.rif or dig deeper for fear of inducing user anger (I have teenagers…).
As I don’t need any of the fixes, I will wait for 7.10 perhaps. Logging this here in case others see the same thing.
still present a memory leak about rotuing bgp when:
the memory usage is above 5GB (6M routes with 250 sessions running for some days)
there is a number of sessions flapped
this pushes something in loop, with 3 or 4 cores at 100% and bgp parameters/configuration not accessible via winbox or cli, and the memory usage grows costantly.
support #[SUP-110510]
Problem seems no more present in x86 (it was up to 7.8).
Since I upgraded to 7.9 (from 7.9rc2) my Homepod seems to have connection issues. I’m getting “The Home hub is not responding / The Home hub is now responding” notifications several times a day.
Wifi controller shows an uptime of 1d+ for this device without an increased rate in retransmissions in comparison to the last few days, so I’d rule this out.
Nothing else was changed, may be related to the packet loss issue, a few people have reported. I’m still investigating, I’ll update this post if I have found the cause.
Edit: In the connection tracking table, I only saw connections with state ‘syn received’ for this device. To be sure Apple didn’t mess up the homepod with one of it’s auto installing updates, I fully reset it. Now there are only ‘established’ connections like it should be. I hope this fixed my issue. Still strange it occurred right after the ros upgrade..
Assuming you are using IPv6, take a look at the IPv6 firewall connections. Are there any connections to global IPv6 addresses? As I reported earlier, IPv6 does not work for me with V7.9.
Are you using stateful or slaac? I am using slaac. The dhcpv6 client asks for and gets a prefix for ND. I add an address from the pool for the router which creates a route. This works fine with 7.8 but not 7.9. I will dig into it later but was curious what is working for you.