You may try to remove one of the ether2..ether5 ports from the bridge and attach another LAN to that port directly (give it an IP address from another subnet than 192.168.0.0/24 and the corresponding /ip pool and /ip dhcp-server settings) and try to connect the PC to that other port, then disable the bridge and try the speedtest again. It is possible that the bridge processing adds some load or delay which has a noticeable effect on a 1 Gbit/s link. I can’t say, mine is a 16 Mbit/s one
speedtest.net normally uses four independent streams in parallel, first measuring only download with just a negligible flow of ACK in the upload direction, and then vice versa.
sindy, glad to see we are on personal name basis, but I am not sure I have yours yet
My understanding of firewall / ip filter rules is that the packet must be checked against all rules, starting at rule 1 from top to down until it matches one, irrelevant if it is a input, forward or output chain rule.
And typically, your forward chain rules will have the most traffic, hence I suggested that should be placed before input chain rules so the packet does not have to go through any other unnecessary input/output rules.
Is my understanding / logic incorrect?
@MikroRouter, sorry for temporarily hijacking the topic.
That makes little difference as everyone calls me Sindy anyway, including my wife and my boss And if I should worry about what the word means in English, what would @Sob have to do for same reason
Only 10 % of it Quoting myself with a little adjustment (ipfilter → netfilter):
If you look at iptables on linux (which is just another configuration front-end to the netfilter, although so popular that the world says iptables and has netfilter in mind), there the chains are strictly separated from one another even in the configuration, not only in the compiled internal form. In another words, in RouterOS, the chain=xyz attribute of the rule is not yet another match condition to evaluate, but a key to insert the rule into the proper netfilter chain used during runtime, and these runtime chains consist of only the rules belonging to them. So my messy configuration from the example above, ( I1, O1, O2, F1, I2, O3, F2, F3, F4, I3, I4, O4), gets internally converted into three "separate, independent and distinct " chains: (I1,I2,I3,I4) for input packets, (F1,F2,F3,F4) for forwarded packets, and (O1,O2,O3,O4) for output packets.
@sindy: For the record, my name is not the popular acronym, it has the same unimaginative origin as yours (judging by your e-mail you leaked here in the past).
And to not make double OT, I’ll add to your original OT that the reason why forward and input are together is because there can also be subchains (accessed by action=jump) and those can be common for both. So if forward and input would be in different tabs (which could be less confusing for new users), it would bring another problem, where the possible subchains should be.
which suggests that we are almost neighbors by global measures?
Yes, they can, but it requires a high degree of geniality (or masochism) to really use that possibility as certain restrictions exist on which match conditions can be used on which of the three packet paths:
[me@MyTik] > ip firewall filter add chain=my-test in-interface=ether1 out-interface=ether2 action=passthrough
[me@MyTik] > ip firewall filter add chain=input action=jump place-before=4 jump-target=my-test
failure: outgoing interface matching not possible in input and prerouting chains
Plus the fact that you can call same custom chains from different basic ones still doesn’t change anything about the fact that the configuration is unknitted into the separate chains as it is converted into the netfilter internal form. So if a packet is an input one, it is never matched against any rule in the forward chain and vice versa.
@sindy: You’re probably drinking beer not very far from me. But shh, we don’t want anyone to know that we’re slowly taking over the forum (maybe we can accept @CZFan as honorary member, he could be useful, he’s not as much into motorcycles as I initially thought, but other things).
Correct about firewall. I rarely use shared input/forward subchains myself, but the possibility exists. And I can see how people may think that the matching is done on all rules, with chain as another condition, even though it’s not like that.
Depending on how the 750r3 is configured, i.e. all switched ports will share 1Gb path, if not switched, then ports 1,3 & 5 shares 1Gb path and 2 & 4 shares another 1Gb path, so other devices might interfere with download speeds.
In fact, only the bold part of @CZFan’s advice above made the difference. As I’ve explained in post #20, the order of rules is crucial but only within each chain, as packets handled by chain=forward never hit any rules in any other chain - they get straight to the topomost rule in chain=forward no matter how many rules in other chains are before that one in the configuration.
Once a packet belonging to a tracked connection matches the conditions of an action=fasttrack-connection rule, most (but not all!) of subsequent packets of that connection aren’t checked by any rule at all - this is the very essence of the fasttracking. Hence the action=fasttrack-connection rule need not necessarily be the very first one in the chain, but it must not be shadowed by other rules matching on the same packets.
I have the exact same issue on hEX S (RB760iGS) running v6.46.4 , which I just installed replacing the provider’s CPE.
FastTrack works fine (validated through IP / Firewall / Connections in WebFig).
Disabling STP doesn’t help.
Is there anything that can be done, or is this the speed limit of the device?
Thanks, I saw that. But the reality with PPPoE for me and others is different.
Given that my main motivation for purchasing this device was gigabit speed with PPPoE, that’s quite a let down.
