Bridging traffic from a SPAN port can be tricky. It isn’t a problem with EOIP that you are seeing, but rather a limitation of intelligent (switch-like) bridging. You would run into the same thing if there were nothing but switches along the path, unless they were all configured for RSPAN.
The problem occurs if you are replicating traffic from more than one port on the Cisco to the MT. What happens is that the MT bridge learn table (/int bridge host) will learn that the sources of packets from multiple switch ports all lie on the ethernet side of the bridge, and thus will not forward traffic sent to those MACs out the eoip side.
Say for instance, that you have two hosts, A and B, on ports 1 and 2 of the switch, and want to analyze the traffic between them using SPAN on port 24, connected to the bridging/tunneling MT.
If your Cisco config looks like this:
!
interface FastEthernet0/24
port monitor FastEthernet0/1
port monitor FastEthernet0/2
!
It will not work. The MT bridge will see frames traveling from A to B coming in on ether1, but it will also see frames moving from B to A coming in on the same port. So, it won’t forward them any further, as it now knows that A and B are both on the ether1 side of the bridge.
To work around this, you need to either sniff and forward using TZSP as you already found, or ensure that the MT only learns source MACs from a single port per bridge. Depending on the Cisco’s feature set, it may also possible to stream or tunnel straight out of the switch, or to place the separate source ports on SPAN VLANs rather than ports.
Assuming a weak Cisco feature set, the easy way to do this would be with two cables, and two bridges.
Physically, you could connect the Cisco’s port 24 to ether1 on MT1, and port 23 to ether3.
Then, on the Cisco, setup a config similar to this:
!
interface FastEthernet0/23
port monitor FastEthernet0/1
!
interface FastEthernet0/24
port monitor FastEthernet0/2
!
and on MT1, do something like this:
ip address add address=192.168.254.1/24 interface=ether2
int bridge add name=port1-bridge
int bridge add name=port2-bridge
int eoip add name=eoiptunnel-to-mikrotik2 remote-address=192.168.254.2 tunnel-id=102 disabled=no
int vlan add name=port1-vlan vlan-id=1001 interface=eoiptunnel-to-mikrotik2
int vlan add name=port2-vlan vlan-id=1002 interface=eoiptunnel-to-mikeotik2
int bridge port add bridge=port1-bridge interface=ether1
int bridge port add bridge=port1-bridge interface=port1-vlan
int bridge port add bridge=port2-bridge interface=ether3
int bridge port add bridge=port2-bridge interface=port2-vlan
MT2 would be similar.
Clearly this method won’t scale well, but for monitoring two ports, it should be fine. In reality, the sniffer+streaming solution you already use is probably best. Ultimately, if your switches support it (6500/sup720-series only, afaik), the ‘correct’ solution is ERSPAN.
On the other hand, if the MT guys wanted to, they could perhaps add an option to disable FDB tracking entirely on a bridge, giving it a more hub-like behavior, and making your initial config work. Hint hint, MT guys (per-bridge only please, not a global option like IP firewall processing).
–Eric