We have EoIP between two sites (RB1100AHx2, 6.32) and it's working great. At either end we are running Cisco switches with RAPID-PVST. We are noticing that BPDUs sent from site A do not get to site B and vice versa.

Is this by design? Is there a way to make it work? While on the subject, can you set up EtherChannels over EoIP links? What about LACP?

You are able to bond EoIP tunnels. How do you have the EoIPs placed in relation to the Cisco switches? Can you post a quick and dirty drawing?

To answer your question about BPDU's. I've only been able to confirm it with STP. This is because I just ran the test in GNS3 which limited it to a Cisco 3725 with a EtherSwitch module and the latest MikroTik VM, 6.40rc8.
The EoIP tunnel is added to a bridge with a priority set to 16,384 (4,096 * 4) on a MikroTik. The next image is the topology. The c1 and c2 nodes are Cisco 3725's with EtherSwitch modules and m1 and m2 are MikroTik routers. The inet1 device is a MikroTik router that the EoIP tunnel between m1 and m2 devices.
Just tested really quick transitions, I gave m1 a priority of 12,288 (4,096 * 3). This caused m1 to become the root bridge and begin transmitting BPDUs which did traverse the EoIP tunnel to m2 and m2 recognized it immediately. I then moved to c1 and set the priority to 4,096 (4,096 * 1) and watched the state change as well as see the new root, c1, BPDU traverse EoIP.
So in summary. It works.We'll have to dive into your bridge configuration, EoIP tunnel configuration as well as the priority of each bridge in the topology. This will help us understand which bridge should become root and which direction BPDUs should be flooding. It appears your MikroTiks are running 6.32 so you are running under the traditional bridging code. It's my understanding 6.40rc8 uses this same method after the revert took affect.

Well this is embarrassing: I checked the remote end there was no BPDU filtering enabled. However the local side looks like this:

interface GigabitEthernet1/0/23
switchport mode trunk
load-interval 30
spanning-tree bpdufilter enable

So that would explain the no BPDUs in either direction!

While on this topic, any advice on the correct strategy to build redundancy between the two sites if a 2nd EoIP link is added (with a 2nd set of RB1100s, to different switches at each site)? My previous experience of spanning tree over a WAN has been rubbish, and we definitely need the L2 broadcast domain to be at both sites. Stacking the Cisco switches at either end is probably one option (with a cross stack EtherChannel). Split Horizon looks like it will prevent a bridging loop, but not the redundancy part.

To be honest I'd start with spanning-tree unless you have significant issues with ports flapping. Remember you can also bring spanning-tree up on the EoIP bridges (on the RBs). If you are looking for load balancing you could do an etherchannel between the sites. You could build on the redundancy by stacking a pair of switches (either virtually, VSS, or stack-wise).

Why are you stretching layer 2? I just want to make sure it is not exclusively for vMotion. That is now supported at layer 3.

To be honest I'd start with spanning-tree unless you have significant issues with ports flapping. Remember you can also bring spanning-tree up on the EoIP bridges (on the RBs). If you are looking for load balancing you could do an etherchannel between the sites. You could build on the redundancy by stacking a pair of switches (either virtually, VSS, or stack-wise).

Why are you stretching layer 2? I just want to make sure it is not exclusively for vMotion. That is now supported at layer 3.

Yeah after labbing this up in EVE-NG (amazing software!), I'm inclined to go for the spanning-tree option. I've been burned by ISPs suddenly not tunneling BPDUs anymore (straight QinQ, no L2 overlay) but in this case we'll reduce this risk substantially by controlling the tunneling/

The L2 is mostly for live migration, but there are some badly designed apps which require L2 adjacency. Fortunately this is a small project and the data centers are 1ms apart, and the connectivity does not fail often.

Thanks for your input - much appreciated!

No problem! Live migration, ESXi or KVM?

No problem! Live migration, ESXi or KVM?

Neither...Hyper-V

Ahh that one ... JK

Not sure if they support layer 3 migration. I'd hope they do. Everything is pushing that way. Cisco pushes away from layer 2 stretch as hard as possible, almost to the point of ignorance with "oh well just shut off old crappy apps." With that I've adopted the approach of do everything you can today over layer 3 and only stretch the least amount of networks that are required to keep those old applications running. That way the shared failure domain is as small as possible and I'm as ready as possible to be layer 3 everywhere.

Make sure you adjust MTU appropriately and that you are clamping MSS whenever possible for traffic that traverses the tunnel. You could also reduce the MTU of the machines at the operating system level. This would greatly limit the amount of issues you would see with fragmentation or MTU related drops. Alternatively and if the provider supports it you can set the MTU on the MikroTik's high enough to offset the overhead from EoIP (GRE) and IPSec (if you are using that, hopefully for Internet traversing traffic).

Good luck to ya!