Guys please tel me why ? It’s local loop. On far end eoip not in bridge.
Most likely known bug: EOIP generates this everytime it receives an (R)STP frame. On my devices I solved it by blocking all input/output/forward (R)STP frames in bridge-filter on both ends of EoIP.
Not sure if it will be ever fixed.
I’ll try the same conf with vpls and rtsp disabled.
Edit. effect is the same - loop
just remember that rstp can be forwarded from another device. It can be identified as having DST mac 01:80:C2:00:00:00 / 01:80:C2:00:00:08 - all these dst mac must be blocked.
sorry to hear it didn’t work for you 
It did in my case and it helped many people earlier.
What if you really have a loop in there?
Can you show me example of your filter rules ?
/interface bridge filter
add action=drop chain=forward dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF
I guess you could specify ports/bridges to make sure your local bridge will be unaffected.
Edit: removed second rule. I didnt realize that one is ROMON block, not STP.
Unfortunately, it did not help 
Still loop after adding to bridge
I guess last idea: Can you try to sniff the data? That’s how I figured out it was caused by RSTP in my case. If you put ****
/tool sniffer
on your EoIP, it should show few packets before it gets down for another minute - one or more of these packets will be most likely those which cause issues.
Or maybe someone else will come up with something smarter 
Interface vlan works just fine for me. Don’t know why eoip/vpls cousing loop. But i have another problem default-forwarding=no and i can mac-ping clients on AP. Is that normal ?
“default forwarding” on wlan is something different:
default-forwarding=yes
- data from one wlan client to another (on the same wlan interface) are passing directly through wlan interface. It does not leave the interface (interface behaves almost like it had an internal bridge)
It looks like this: ****
client1 --- wlan1 --- client2
default-forwarding=no
- data from one wlan client to another must go through master interface (typically bridge), where you can apply filter/nat rules.
It looks for example like this: ****
client1 --- wlan1 --- bridge1 --- wlan1 --- client2
If you want to prevent clients talking to each other, you must firstly disable default forwarding (so data can’t go straight through wlan) and then you must disable this on bridge as well:
for example one of my configs:
/interface bridge filter
add action=drop chain=forward in-bridge=bridge-guest in-interface=!eoip-guest-uplink out-bridge=bridge-guest out-interface=!eoip-guest-uplink
It prevents any frames being forwarded within guest bridge, unless they go from/to uplink eoip.
I know this config is funny. Usually you would do a guest vlan, but thats impossible in my case - this company has some ancient switches which blocks vlans… no way to convince them to buy new ones. IP based tunnel is the only choice.
Thank you, that works!