When reading your post on the mobile, I've only checked the output of the /ip firewall connection print and I wrote that brief post to fix that.
Now at the PC, this is what seems most important to me from your post #4:
One other intersting fact I have noticed, the MAC address of the client 172.16.123.1, 7069.5a98.fac9, is only learnt by rtr-mk-a5 when I ping the broadcast address 172.16.123.3 (it is a /30 subnet), if I ping 172.16.123.2 is not learnt.
In actual fact when I ping 172.16.123.2 rtr-lon-02 does not see that mac address on ether3, it is only when I ping .3 that the mac address appears on rtr-lon-02 ether3 and then on rtr-mkt-a5
The MAC address is learnt from any incoming frame. So if the 172.16.123.1 was sending arp requests for 172.16.123.2 to the cable connected to ether3, you would see 70:69:5a:98:fa:c9 in the output of /interface bridge host print
; if you don't, you can be pretty sure the Cisco switch in between or the actual device on which 172.16.123.1/30 is up do not forward the frame carrying the ARP packet to you.
It is not clear from the export what Mikrotik model is rtr-lon-02, so better do /interface bridge port set [find interface~"ether3"] hw=no
, and then run /tool sniffer quick interface=ether3
and try to ping 172.16.123.2 from 172.16.123.1 again (after, say, 15 minutes from the last attempt to let the MAC expire in all the ARP and FDB tables). You should see whether the frames come in or not. If they don't, the issue is unrelated not only to EoIP but even to rtr-lon-02. If you can only see one ARP request and one ARP response and nothing more, it is likely the case.
Also, do you have to take some special measures at the 172.16.123.1 machine when pinging 172.16.123.3? Normally it is not possible to ping an address from a system which treats it as a broadcast one unless you provide an option to ping
telling it that it is really your intention. So if you don't need to do that, it is possible that the netmask at 172.16.123.1 is not set properly. This should, however, not be related to your issue, it is just strange.
Last point is the /ip firewall connection print. I don't get what is wrong with the Mikrotik firewall but this is not the only case where the GRE connection between two IP addresses is not treated as a single one but as two unidirectional connections (1 and 6 in your case). As gents have fixed a netfilter bug in 6.45.1, maybe this issue has been resolved as a side effect, I haven't checked yet. But what is much worse is that there is no connection shown at the rtr-mkt-a5. As the EoIP packets are originated locally, there is no way how the GRE packets carrying the EoIP payload could escape the firewall, so the only explanation which comes to my mind is that you have some rules in /ip firewall filter raw
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.