cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
632
Views
0
Helpful
2
Replies
Ali Razavi
Beginner

Cisco VTI with Different Network Addresses

Hi folks,

Can someone explain this to me please?  I have two routers connected via a WAN connection.  I have a tunnel setup between the two using standard VTI. 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.  Why is this tunnel even up?  Does anybody know what's going on here?  Please see the configs below:

R1

interface GigabitEthernet0/0

ip address 10.10.10.1 255.255.255.0

ip virtual-reassembly in

duplex auto

speed auto

media-type rj45

end

interface GigabitEthernet0/1

ip address 192.168.1.1 255.255.255.0

ip virtual-reassembly in

duplex auto

speed auto

media-type rj45

interface Tunnel100

ip address 172.16.29.1 255.255.255.252

tunnel source 10.10.10.1

tunnel destination 10.10.10.2

end

ip route 192.168.2.2 255.255.255.255 Tunnel100

R1#ping 192.168.2.2 source 192.168.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:

Packet sent with a source address of 192.168.1.1

!!!!!

R2

interface GigabitEthernet0/0

ip address 10.10.10.2 255.255.255.0

ip virtual-reassembly in

duplex auto

speed auto

media-type rj45

end

interface GigabitEthernet0/1

ip address 192.168.2.2 255.255.255.0

ip virtual-reassembly in

duplex auto

speed auto

media-type rj45

interface Tunnel200

ip address 172.16.18.2 255.255.255.252

tunnel source 10.10.10.2

tunnel destination 10.10.10.1

end

ip route 192.168.1.1 255.255.255.255 Tunnel200

R2#show ip route 192.168.1.1

Routing entry for 192.168.1.1/32

  Known via "static", distance 1, metric 0 (connected)

  Routing Descriptor Blocks:

  * directly connected, via Tunnel200

      Route metric is 0, traffic share count is 1

R2#ping 192.168.1.1 source 192.168.2.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.2.2

!!!!!

1 ACCEPTED SOLUTION

Accepted Solutions
Peter Paluch
Hall of Fame Cisco Employee

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

View solution in original post

2 REPLIES 2
Peter Paluch
Hall of Fame Cisco Employee

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

Thank you for the very thorough explanation Peter.  The fact that the actual tunnel IP addresses don't come into play until multicast situations, is all I needed to hear.  I was completely stunned when this worked and I couldn't explain why.  This actually gives me a better insight regarding VTI encapsulation behavior.  Thanks again.