gre tunnel issue

[sarahr202]

Hi

How is everyone doing?

I performed the following scenario using gre tunnel

.1                              .3                                 .2

R1s0/0-----199.199.199.0--s0/0 R3-s0/1------198.198.198.0------s0/0R2

R1#show ip route

R    198.198.198.0/24 [120/1] via 199.199.199.3, 00:00:10, Serial0/0

C    199.199.199.0/24 is directly connected, Serial0/0

C    10.0.0.0/8 is directly connected, Tunnel0

interface Tunnel0

ip address 10.10.10.1 255.0.0.0

tunnel source 12.12.12.1

tunnel destination 198.198.198.2

=====================================================

R2#show ip route

C    198.198.198.0/24 is directly connected, Serial0/0

R    199.199.199.0/24 [120/1] via 198.198.198.3, 00:00:05, Serial0/0

C    10.0.0.0/8 is directly connected, Tunnel0

interface Tunnel0

ip address 10.10.10.2 255.0.0.0

tunnel source 13.13.13.3

tunnel destination 199.199.199.1

====================================================

Now when I issue ping 10.10.10.2 on R1

R1 looks up 10.10.10.2 and finds tunnelo  needs to be used to forward it. R1  creates icmp with src 10.10.10.1,  dst 10.10.10.2,

R1 then creates encapsulates this icmp with src 12.12.12.1 dst 198.198.198.2

R1 then looks up 198.198.198.2  and forwards it out of s0/0 as per routing table.

The above  is verified by wireshark(  You may check the attacked wireshark file r1-r3)

R1 is not getting any response.

I expect R2 to have processed the packet as follows:

R2 receives the packet. R2  removes the  ip header added by R1 to recover the original icmp packet with src 10.10.10.1 dst 10.10.10.2

R2  creates a response with src ip 10.10.10.2 dst 10.10.10.1

R2 looks up the routing table and finds the packet has to be forwarded out of tunnel 0

R2 c then  encapsulates the packet with src ip 13.13.13.3  dst ip 199.199.199.1

R2 then looks up the 199.199.199.1 and finds it has to be forwarded out of s0/0

When I used the wireshark between R3 s0/1 and S0/0R2,(you may check the attached wireshark file r3-r2)  I don't see any  icmp response from R2.

Any input will be greatly appreciated.

thanks and have a good day.

[smitesh kharecha · Accepted solution]

Hi,

Can you check using extended ping.

Also, just confirm that there isn't any ACL which might be obstructing.

Please check below and advise:

ping 10.10.10.2 so tu0

Regards,

Smitesh

[Richard Burts · Accepted solution]

I am not sure what may be in the router configs that you have not posted but based on what is posted there is a serious issue with the tunnel. The tunnel source is configured as 12.12.12.1 (or 13.13.13.1) but the routing table does not show that as an IP on the router. If the source address is not an active IP on the router and reachable from the tunnel peer router then the tunnel will not work.

HTH

Rick

[sarahr202]

Hi Richard.

"If the source address is not an active IP on the router and reachable  from the tunnel peer router then the tunnel will not work".

You are absolutely correct.

R1--199.199.199.199.0-----R2-------200.200.200.0------R3

A gre tunnel exists between  R1-------------R3

R1's roting table:

R1#show ip route

R    200.200.200.0/24 [120/1] via 199.199.199.2, 00:00:17, Serial0/0

C    199.199.199.0/24 is directly connected, Serial0/0

C    10.0.0.0/8 is directly connected, Tunnel0

C    12.0.0.0/8 is directly connected, Loopback1

R    13.0.0.0/8 [120/1] via 199.199.199.2, 00:00:17, Serial0/0

interface Tunnel0

ip address 10.10.10.1 255.0.0.0

tunnel source 12.12.12.1

tunnel destination 200.200.200.3

===========================================

R3 's routing table:

R3#show ip route

C    200.200.200.0/24 is directly connected, Serial0/0

R    199.199.199.0/24 [120/1] via 200.200.200.2, 00:00:11, Serial0/0

C    10.0.0.0/8 is directly connected, Tunnel0

R    12.0.0.0/8 [120/1] via 200.200.200.2, 00:00:11, Serial0/0

C    13.0.0.0/8 is directly connected, Loopback3

interface Tunnel0

ip address 10.10.10.3 255.0.0.0

tunnel source 200.200.200.3

tunnel destination 12.12.12.1

===============================

R1#ping 10.10.10.3

Type escape sequence to abort.

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

!!!!!

Here is my question,  routing decision is based on destination ip. That means  if as long as destination ip under igre tunnel is reachable,  packets should be able to be forwarded.

Let me illustrate it

R1

int tunnel 0

ip address 10.10.10.1

tunnel source 12.12.12.1 ( This  one does not exist in routing table and not reachable by peer,R3)

tunnel destination 200.200.200.3 ( It exists in routing table and reachable by both peers)

R3

Int tunnel 0

ip address 10.10.10.2

tunnel source 13.13.13.3 (   does not exist in routing table and not reachable by peer R1)

tunnel destination 199.199.199.1 ( exists in routing table and reachable by peer R3)

If  i issue ping 10.10.10.3

R1 simply adds tunnel source 12.12.12.1 and destination as 200.200.200.3 to icmp packet.

Since routing decision is based on destination and 200.200.200.3 which is the ip address assigned to R3,  therefore packet arrives at R3.

When R3 receives the packet, it removes the tunnel src ip 12.12.12.1 and destination ip 200.200.200.3 which is ip address assigned to R3 and recovers the original icmp.

R3 creates a icmp response and encapsulates it with  tunnel source ip 13.13.13.3 and dest ip 199.199.199.1 which is the ip address assigned to R1 ;packet arrives at R1.

In above case, we don't see  any importance of tunnel source .

I would greatly appreciate your expert help.

Thanks and have a good day.

[Richard Burts · Accepted solution]

The first part of this post shows a correctly configured tunnel which should work

The issues in your question here get a bit complicated. You are correct that a routing decision is based on destination IP. But forwarding packets is a bit more complicated. In all interfaces, including tunnel interfaces, there are also matters of encapsulation and de-encapsulation, and as the packet is sent will the recipient correctly recognize and process it.

So in your question scenario R1 will create an ICMP for the destination 10.10.10.3 and will encapsulate it in a GRE header with source 12.12.12.1 and send it to destination 200.200.200.3. I believe that when the GRE encapsulated packet arrives at R3 that R3 will not de-encapsulate it. The packet source address does not match the peer that R3 expects and I believe that R3 will not associate the packets with its tunnel0 because of the mismatch. Since the GRE packet does not match any configured tunnel on R3 I believe that R3 will discard the packet.

HTH

Rick

[sarahr202]

thanks Richard