Alright Cap'n spanky. Let's do some Cisco to MikroTik work!
If you inspect your /routing rip network section with /routing rip network print detail you will see that your networks are defined as /32 for each. This was probably an unintended consequence as you are used to Cisco not requiring a wildcard or subnet mask for networks in RIP because they cut them on class-full boundaries for that protocol. We also need to add the network for bridge so MikroTik includes that in the updates. This was previously covered by the class-full network statements. So we'll need to adjust those. If we were setting RIP up from defaults we'd do:
routing rip network add network=172.19.29.32/30
routing rip network add network=192.168.6.0/30
routing rip network add network=172.16.6.0/254
I also prefer to set passive appropriately on any interfaces that have networks involved in RIP and statically define them with "/routing rip interface." You'll notice I set your bridge (LAN) interface to passive. I assume you don't have the router neighboring with any other devices on the LAN. If you do in fact then just set "passive=no" and the neighbor will form. This is something you could extend to your Cisco side with passive-interface default under the router rip section. You then need to specify which interfaces to run RIP on with "no passive-interface <int>" statements. This is a great way to ensure RIP neighbors only form on the interfaces you intend them to.
routing rip interface add interface=Wateen passive=no send=v2 receive=v2
routing rip interface add interface=Tunnel6 passive=no send=v2 receive=v2
routing rip interface add interface=bridge1 passive=yes send=v2 receive=v2
This will get RIP sorted and you should now have the remote network populated into the routing table allowing you to reach it like you'd expect.
Let's Play Nice with Tunnels
I'm a fan of tunnel keep-alives. That's just me. It will dynamically shut down the GRE tunnel if a break occurs. This can be done on the Cisco side with keepalive under the tunnel interface like so:
And on the MikroTik side like:
interface tunnel set tun6 keepalive=10,6
This results in both sides sending a keep alive every 10 seconds and will retry 6 times (1 minute). If it fails to receive a reply in that time the tunnel will dynamically shut down. The alternative is that the tunnel may get stuck in an up state after a link failure.
MTU, What the heck?
Looking at the Cisco configuration you're doing things with TCP MSS. I'm guessing this came about because you were having fragmentation related issues. You also are trying to leverage TCP based path MTU discovery. Seems like good things to do. Let's explore MTU a bit. In IPv4 routers are responsible for fragmentation, hosts can over-ride this fragmentation by setting the DF bit in their communications which results in dropped packets. In IPv6 it is the responsibility of the traffic initiator to fragment traffic, this was done to lighten load on routers. It is managed by ICMPv6 Too Big messages that are sent by a router back to the initiator and the original offending packet is dropped.
Let's start by defining our limits. In IPv4 our minimum is 576 bytes. In IPv6 our minimum is 1280 bytes. I prefer to design to accomodate the IPv6 minimum. It protects us for the future when we in fact need IPv6. In addition to "ip tcp mss-adjust <bytes>" you'd want to define "ipv6 tcp mss-adjust <bytes>" on the Cisco devices when you enable IPv6. With the baselines for each IP protocol in mind we need to define the starting layer 3 MTU of each of your connections. An Ethernet connection by default will have its MTU set to 1500. If that's the case in your network then we move onto the tunnel interfaces. A GRE interface encapsulates the original packet with a GRE header (4 to 12 bytes) and an IP header. In your use case the GRE header will be 4 bytes. The IP header is determined by the outside protocol. In your case you are sending IPv4 over IPv4. GRE can be used to send IPv4 over IPv6. This has to be known to calculate MTU. In your case you add one additional IPv4 header at 20 bytes. When we add the GRE header (4 bytes) and the IPv4 header (20 bytes) that we've added (encapsulated) around the original packet we've added 24 bytes of additional overhead. This means at a minimum we need to set the MTU of the tunnel interfaces to 1500 - 24 or 1476. Awesome we have MTU figured out.
What is this TCP MSS business all about? Like MTU it defines the Maximum Segment Size. Segment is how we define the layer 4 (TCP in this case) size. Like MTU this has a defined minimum size, for IPv4 it is 536 and for IPv6 it is 1220. We arrive to these figures by subtracting the layer 3 header size and the TCP header size from the minimum MTU size of each packet. This is 576 - 20 (IPv4 header) - 20 (TCP header) for 536 and 1280 - 40 (IPv6 header) - 20 (TCP header). When we define this in Cisco land we are telling the router to adjust the TCP header to include the MSS value that would transport a segment across the GRE tunnel without fragmentation. We do this with "ip tcp adjust-mss <value>" under the tunnel interface in Cisco and we set the "clamp-tcp-mss" value in the GRE interface to yes like "interface gre set tun6 clamp-tcp-mss=yes."
So what do you need to do. To be honest I can't say, if you post a diagram of your network and scribble down at least the layer 3 MTU of each link we can get you all squared away and ensure the fragmentation issues of yester-year are long forgotten. Below is a link to a post I recently did that includes screenshots of GRE and EoIP in WireShark displaying how an encapsulated packet looks and what the header sizes look like.