Forgot to mention: yes, I did try enabling flow control, but that did not help. Besides, if the switch buffer overflow is the explanation, there are two (well, at least one) contradictions here: Works with CRS305. Theoretically could be explained by a larger buffer, but still suspicious. The problem...

I have an RB5009UG+S+ with RouterOS 7.13.3, with a literally default configuration: /system/reset-configuration caps-mode=no keep-users=yes no-defaults=no skip-backup=yes A linux server is plugged into the SFP+ port via DAC, a TP-Link access point is plugged into ether2 (I tried EAP610 and EAP245 mo...

I'm seeing this same behaviour on 7.8 while trying to setup a mdns-repeating container for multiple bridge vlans, the moment veth is enabled tcp traffic originating from the router (including vpns) is crippled (speeds from 300+mbps down to 1mbps) I've reported the issue to the support back in Febru...

Amm0, you were right, the issue does not reproduce as easily as I initially thought. Here is the full minimized config: /interface bridge add admin-mac=DC:2C:6E:66:3A:E0 auto-mac=no frame-types=\ admit-only-vlan-tagged name=bridge protocol-mode=none vlan-filtering=yes /interface veth add address=192...

I'm saying it's most likely a configuration error, NOT a bug . The packet flow is complex, but all this traceable through RouterOS: Hm, so there might be an explanation for the fact that this behavior is triggered by adding a VETH to the bridge? Well, OK. I don't want to share my current configurat...

I disabled RSTP and set "admit only untagged and priority tags" for ether4, making it an access-only port. The problem did not go away. In any case, it looks like you agree that in general my configuration makes sense and this is more likely a bug, rather than a configuration error. Hopefu...

The idea was to have it as an untagged port, and enabling it correctly adds it as an untagged port to /interface/bridge/vlan without explicit configuration. Other than that, there are no changes to the VLAN table caused by toggling the port.

Also, you should use frame-type of "only untagged and priority tags" if the intend is for VETH to be an access port.

But "admit all" should also work, shouldn't it? I mean, it's not necessary to restrict the accepted frame types, right?

Nothing, it's not mentioned there.

There is no address assigned to veth1 in `/ip/addresses`. There is a link-local ipv6 address which was created automatically, however removing it did not fix the problem.

I have an RB5009 with the routeros 7.7 and the following bridge configuration: /interface bridge add admin-mac=DC:2C:6E:66:3A:E0 auto-mac=no frame-types=admit-only-vlan-tagged name=bridge vlan-filtering=yes /interface bridge port add bridge=bridge frame-types=admit-only-vlan-tagged interface=ether1 ...

It may be a matter of settings of the virtualisation platform, and these differ significantly between platforms. On Hyper-V, you need to permit use of individual VLANs on the interfaces of the virtual switches using Powershell (GUI is not sufficient) and also in RouterOS, vlan-filtering must be set...

I'm currently evaluating a virtualized x86 routeros and trying to set up a connection to my ISP, which requires a pppoe connection over a VLAN. So, starting with the simplest configuration (ether1 is a real Intel I210 NIC connected via PCI-passthrough): # jan/01/2022 19:56:49 by RouterOS 7.2rc1 # /i...

Found the solution! Removing the ethernet port from the switch (master port=none) and adding it directly to the bridge fixed the problem for me.

Exactly the same problem: when Apple TV connected directly to Ethernet port all traffic stops after utilizing it for 100% for about 10-30 seconds. Adding a switch between Apple TV and mikrotik helps. Not sure how to troubleshoot.

Try to set local-address in ipsec peer settings.

Thank you, should've thought of that myself.

I have a mikrotik at ISP which provides native ipv6 via SLAAC on PPPoE interface, plus delegates a prefix via DHCP. I had ipsec configured for certain networks and everything worked perfectly until a week or two ago. Unfortunately, I did notice if the problem appeared after recent updates. Current v...