tldr: EOIP seems to be picky about what sort of interface it's local address is on, it simply won't start the interface if it is a VLAN, if said VLAN is subinterface to a bridge.
I'm seeking help understanding if this is expected behavior or if I've done something wrong, and why. Given that it will start on the wireguard interface without manual MTU adjustment, I don't understand how the results of the configs below make sense.
I've only left in the parts that seemed relevant, originally I had put firewall rules to count GRE packets at either end of the link before I narrowed it down to the interface simply not running on the one end, the similar scenarios to those below I tried where the other end was pingable had the same result.
Scenario 1 : local address of 192.168.88.1, remote of 192.168.88.2. The remote does not exist, but that isn't relevant for this scenario. The local-address is assigned on the loopback interface
/ip address add address=192.168.88.1/24 interface=lo network=192.168.88.0
/interface/eoip> print
Flags: X - disabled; R - running
0 R name="eoip-tunnel1" mtu=auto actual-mtu=65493 l2mtu=65535 mac-address=02:32:55:C4:47:8D arp=enabled arp-timeout=auto loop-protect=default
loop-protect-status=off loop-protect-send-interval=5s loop-protect-disable-time=5m local-address=192.168.88.1 remote-address=192.168.88.2 tunnel-id=1
keepalive=10s,10 dscp=inherit clamp-tcp-mss=yes dont-fragment=no allow-fast-path=yes
In this scenario, the tunnel runs.
Scenario 2: It also runs if the address is on a wireguard tunnel:
/ip address add address=192.168.88.1/24 interface=wireguard1 network=192.168.88.0
/interface/eoip print brief
Flags: R - RUNNING
Columns: NAME, MTU, ACTUAL-MTU, ARP, MAC-ADDRESS, KEEPALIVE
# NAME MTU ACTUAL-MTU ARP MAC-ADDRESS KEEPALIVE
0 R eoip-tunnel1 auto 1378 enabled 02:32:55:C4:47:8D 10s,10
Scenario 3: Now let's try it on a non running interface (ether5 is unplugged):
add address=192.168.88.1/24 interface=ether5-mgmt network=192.168.88.0
/interface/eoip print brief
Columns: NAME, MTU, ACTUAL-MTU, ARP, MAC-ADDRESS, KEEPALIVE
# NAME MTU ACTUAL-MTU ARP MAC-ADDRESS KEEPALIVE
0 eoip-tunnel1 auto 1458 enabled 02:32:55:C4:47:8D 10s,10
This makes sense, the address is invalid because of the non running interface. A warning flag on the EOIP interface would be nice, but it makes sense.
Scenario 4: now this next scenario is what had me banging my head against a wall. It seems that it will not start the interface if it's local address is on a VLAN.
/interface vlan add interface=bridge1 name=vlan30 vlan-id=30
add address=192.168.88.1/24 interface=vlan30 network=192.168.88.0
/interface/eoip print brief
Columns: NAME, MTU, ACTUAL-MTU, ARP, MAC-ADDRESS, KEEPALIVE
# NAME MTU ACTUAL-MTU ARP MAC-ADDRESS KEEPALIVE
0 eoip-tunnel1 auto 1458 enabled 02:32:55:C4:47:8D 10s,10
Scenario 5: The VLAN is a subinterface to a bond as opposed to a bridge (this device has no bridge configured). The EOIP interface does start. It is an additional variable, but this device is a CCR1036 as opposed to RB4011 in the other examples.
/interface vlan
add interface=bond-uplink name=vlan103 vlan-id=103
/ip address add address=192.168.88.1/24 disabled=no interface=vlan103 network=192.168.88.0
/interface eoip print brief
R eoip-test auto 1458 enabled 02:04:3E:23:CD:28 10s,10
Thoughts? Next I'm going to try to do scenario 5 on an RB4011, and see if I can eliminate any more variables.