Dear forum & Support,
MTU on the EOIP tunnel is partly working. It seems I cannot always control which MTU size is really used. If you generate a packet local all is fine (probably if you route also). But if you truly bridge it, the max MTU is always the size of the leaving interface.
This is the example that works:
/interface eoip
add arp=enabled disabled=no l2mtu=65535 local-address=0.0.0.0 mac-address=\
02:4D:C4:B1:24:13 mtu=1500 name=tunnel remote-address=1.2.3.4 tunnel-id=1
/ip address
add address=169.254.254.1/24 disabled=no interface=tunnel network=169.254.254.0
/ip arp
add address=169.254.254.2 disabled=no interface=tunnel mac-address=\
D4:CA:6D:6F:A8:43
/interface print value-list
name: sfp1 ether1 ether2 ether3 ether4 ether5 ether6 ether7 ether8 ether9 ether10 tunnel
type: ether ether ether ether ether ether ether ether ether ether ether eoip-tunnel
mtu: 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500
l2mtu: 1598 1598 1598 1598 1598 1598 1598 1598 1598 1598 1598 65535
max-l2mtu: 4074 4074 4074 4074 4074 4074 2028 2028 2028 2028 2028
/tool sniffer
set file-limit=10KiB file-name="" filter-direction=tx filter-ip-address="" filter-ip-protocol=gre filter-mac-address="" filter-mac-protocol="" filter-port="" filter-stream=yes interface=ether2 memory-limit=10KiB memory-scroll=yes \
only-headers=no streaming-enabled=no streaming-server=0.0.0.0
/tool sniffer start
/ping 169.254.254.2 size=1500 count=1
/tool sniffer stop
/tool sniffer packet print detail
0 time=0.025 num=1 direction=tx src-mac=D4:CA:6D:8D:FE:0F dst-mac=2C:21:72:A2:B6:41 interface=ether2 src-address=Xxxx dst-address=1.2.3.4 protocol=ip ip-protocol=gre size=1514 ip-packet-size=1500 ip-header-size=20 dscp=0
identification=30751 fragment-offset=0 ttl=64
1 time=0.025 num=2 direction=tx src-mac=D4:CA:6D:8D:FE:0F dst-mac=2C:21:72:A2:B6:41 interface=ether2 src-address=xxxxx dst-address=1.2.3.4 protocol=ip ip-protocol=gre size=76 ip-packet-site=62 ip-header-size=20 dscp=0
identification=30751 fragment-offset=1480 ttl=64
This result is normal, and when I change the mtu, it does what I expect.
/interface eoip set mtu=1450 numbers=0
/tool sniffer start
/ping 169.254.254.2 size=1500 count=1
/tool sniffer stop
/tool sniffer packet print detail
0 time=0.012 num=1 direction=tx src-mac=D4:CA:6D:8D:FE:0F dst-mac=2C:21:72:A2:B6:41 interface=ether2 src-address=xxxxxxx dst-address=1.2.3.4 protocol=ip ip-protocol=gre size=1500 ip-packet-size=1486 ip-header-size=20 dscp=0
identification=30783 fragment-offset=0 ttl=64
1 time=0.012 num=2 direction=tx src-mac=D4:CA:6D:8D:FE:0F dst-mac=2C:21:72:A2:B6:41 interface=ether2 src-address=xxxxxxx dst-address=1.2.3.4 protocol=ip ip-protocol=gre size=132 ip-packet-size=118 ip-header-size=20 dscp=0
identification=30784 fragment-offset=0 ttl=64
Excellent the packets got smaller and will fit nicely in to a connection with a max of 1492 MTU (typical VDSL/PPPoE).
If I create a bridge and put the ip on the bridge interface, and the static arp behind the bridge it will no longer use the mtu of the EoIP interface. Setting the mtu on the bridge gives the same good result.
My problem
Performance is less that it could be. I bridge two network using EoIP. I transfer also the vlan tags. This works but it “ignores” the mtu setting of the eoip interface. It will listen to the mtu of the outgoing interface but I can’t change that, it would break ospf. One side is 1492 and the other side is 1500.
Basically what happens is that a 1500 mtu ip pakket on vlan5 on the bridge gets fraged in two packets for the other side and the other side recieves 3 packets. One big and two smalls 
. I send one with a mtu of 1500 and the other one about 60. It hits some router in the middle that frags the 1500 in two packets and leaves the small one intact. The solution would be to sent the ip packet with eoip inside with a max of 1492 mtu.
I tried routeros v5.26 and many v6 version including v6.27.
(Above example is done on a v5.26 rb2011)
Please let me know if I do something wrong. I will probably add an additional interface with a smaller mtu to work around my issue.
Cheers!