Hello,
There is a static route to the LAN IP behind each router, but each end of the VTI has an out-of-range address from the other. Yet, the two networks can reach each other.
Yes, that may be confusing but it is nevertheless working. Let's break down in detail what is happening:
On R1, there is a static route saying
ip route 192.168.2.2 255.255.255.255 Tunnel100
So when a packet arrives to R1 and is destined for 192.168.2.2, the router will forward it out the Tunnel100 interface. However, what does it mean to forward a packet out a tunnel interface? In principle, it means that the existing packet will be encapsulated (tunneled) in a new packet whose source will be set to the
tunnel source
(10.10.10.1 here), destination will be set to the
tunnel destination
(10.10.10.2 here) and the entire new packet will be routed again. Now, because R1 can reach 10.10.10.2, the packet will be delivered there, decapsulated, and the original packet will be routed further.
A similar process will repeat on R2 if a packet arrives towards 192.168.1.1 - you can certainly now tell the individual steps.
Note that during this whole process, the internal IP address of the tunnel interface never came into focus. Why is that so, you may ask? The reason is that your Tunnel interfaces are point-to-point tunnels. When you forward a packet out a point-to-point interface, there is really only one valid destination - the other end. When using point-to-point links as transit links (i.e. packets are forwarded over them but neither of the link's endpoints is the final destination), the IP addresses on either link ends are irrelevant to the routing as long as the router knows that a particular packet is to be forwarded through this particular point-to-point link. You can see how this works in your configuration - a static route tells the router to send some packets directly through a point-to-point tunnel so it does. The internal IP address of the other tunnel end was not needed to this process.
As a matter of fact, imagine a slightly modified configuration on R1:
interface Tunnel100
ip address 172.16.29.1 255.255.255.0
tunnel source 10.10.10.1
tunnel destination 10.10.10.2
Note the mask is set to /24. Here, if you wanted to reach 192.168.2.2 over the tunnel, you could use the following static route:
ip route 192.168.2.2 255.255.255.255 172.16.29.X
with X being in range from 1 to 254 inclusive - and it would still work. Why? Because in this case, the first lookup of the destination 192.168.2.2 in the routing table would produce just a next-hop IP address of 172.16.29.X, and the recursive lookup of this next-hop IP would in the routing table would produce the egress interface Tunnel100 - and we're back to what I explained in the beginning how a packet is handled when routing it out a Tunnel interface.
This is the reason why in your case, the routing works despite the tunnel endpoints are in different IP networks.
You may ask why do we need the addresses on Tunnel interfaces at all. These addresses are necessary for "on-link" communication of two routers that are endpoints of this tunnel. Imagine that you were running a routing protocol, say, EIGRP or OSPF, over this tunnel. The routing protocol will be sending its packets sourced from the internal IP address of the tunnel interface. Obviously, in order for two routers on a common link to establish an adjacency over a routing protocol, they must be on the same subnet. Because a tunnel is also a common link to both tunnel endpoints, here, they would have to be in the same IP network, otherwise the routing protocols would complain about neighbors being in wrong subnet and would not establish any adjacency to each other. So in other words, if at least one of the tunnel endpoints needed to become a source or a destination of the tunneled traffic, then the internal tunnel IP addresses would be the corresponding sources and/or destinations of the tunneled packets (in the inner headers).
Why is this tunnel even up?
Because a tunnel interface using GRE encapsulation is up as soon as the
tunnel source
IP address is active and the
tunnel destination
IP address is reachable according to the current routing table. There is no connectivity check with the opposite tunnel endpoint unless you also configure the so-called keepalive feature.
Please feel welcome to ask further!
Best regards,
Peter
