I don't understand well the config but now 192.168.6.0/24 network, uses 5.x.x.x for incoming and outcoming traffic. so all the traffic from 192.168.6.0/24 goes through the GRE tunnel.
When you specify an IP address as a gateway
of a route, the system searches through the network
values of the /ip address
rows to find one to which the gateway
address fits, and uses the interface
to which this /ip address
item is associated as an out-interface for the packet. If the interface is a point-to-point one, which is the case of GRE, there are no more steps; for point-to-multipoint interfaces, the IP address of the gateway must be also resolved to a MAC address, so that the packet was sent through the right interface to the right device.
Plus routes with distance
0 are dynamically created for each /ip address
item, with dst-address
matching the network parameter of the /ip address
item, with the interface
of that /ip address
item as gateway
So if you set the 5.x.x.x/32 as a network
at the /ip address
item attached to the GRE interface at the DC-tik, a route to 5.x.x.x/32 via that GRE interface is dynamically created. The address
value of the item may be any IP address other than 5.x.x.x
At Theatre-tik, 5.x.x.x/32 must be up on some interface in order that the Theatre-tik would consider it its own; it is most logical to set it as the own address
of the GRE interface. The network
address associated to the GRE must be different from 5.x.x.x/32, but it actually doesn't matter much if it is the same (like in your export above) if you use the interface name, rather than the network
address associated to it, as a gateway
parameter of routes.
I have another problem now, and is that speed is more or less a half of the real speed if traffic goes through the normal gateway 212.x.x.x Could be a MTU size problem in GRE tunnel? Any ideas? regards!!
MTU is definitely reduced by tunneling via GRE, as the GRE headers occupy part of the actual Ethernet/PPPoE MTU, but not to 1/2. Without IPsec encryption, the MTU of GRE tunnel transported using MTU 1500 packets is 1476 bytes, so more than 98% of the original one. TCP accommodates to this, so instead of sending 1500-byte packets which the router would split into two each, it sends slightly more 1476-byte packets.
But bear in mind that if you test the throughput using a symmetric flow, the bandwidth of the WAN interface at the DC-tik is the limiting factor, as each direction of the flow occupies both download and upload bandwidth at that interface. A y.y.y.y -> 5.x.x.x packet is first received by DC-tik via WAN and then forwarded to 5.x.x.x via the tunnel via the same WAN interface; the response from Theatre-tik is first received by DC-tik via WAN and then forwarded to y.y.y.y via the same WAN interface.
So you may want to use non-symmetric throughput test (i.e. one which tests upload and download bandwidth separately), it should show less depressive results.