cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
832
Views
5
Helpful
14
Replies

GRE tunnel

chris.damore
Level 1
Level 1

I am trying to configure an encrypted GRE tunnel between two routers connected via DSL. The tunnel interfaces are up up on both routers. I am not able to reliably PING the tunnel interface on the main router while I am connected to that router. I can?t figure out what is going on.

The router shows the tunnels IP address is directly connected. Why can?t I PING this address reliably?

Thanks,

14 Replies 14

Richard Burts
Hall of Fame
Hall of Fame

Chris

There may be several things which could be the reason for this. First I think is the fact that depending on how you configure the tunnel (whether you specify GRE keepalive or not) the default is for the GRE tunnel to show as up/up as long as the router has a viable route to the tunnel destination. So a GRE tunnel up/up does not necessarily mean that it is passing traffic.

Second is that with point to point interfaces when you ping the local interface the router will actually send the ping packet out the interface and over the link so that the neighbor receives the ping request and forwards it back (and a similar process for the response). So pinging your own interface is more complicated than it is for something like Ethernet.

I am not clear when you say that "I am not able to reliably PING the tunnel interface" whether means that sometimes it works and sometimes not or does it mean that you can not ping it at all? I believe that the approach to troubleshooting will depend on whether it is sometimes working or never working.

HTH

Rick

HTH

Rick

minumathur
Level 1
Level 1

Hi

Following things need to be check

1) Configure Keepalive both side same

2) check the routing

3) perform traceroute/ping for fault resolution.

i think this will help you out. please rate this post.

-Minu

mohammedmahmoud
Level 11
Level 11

Hi there,

By default GRE tunnel keepalive is disabled, accordingly it seems that the tunnel is illusionary UP/UP (as long as the tunnel destination is reachable in the routing table) and thats why you cant ping, so kindly enable keepalives and we shall see the case.

HTH,

Mohammed Mahmoud.

After I added "keepalive 3 3" to both tunnel interfaces, the interfaces went up down.

Please see attachment for config.

Thanks,

Chris

Hi Chris,

Can you ping the tunnel destinations from the opposite ends.

BR,

Mohammed Mahmoud.

I am not able to PING the tunnel destinations.

Are my routes correct in the attachments I posted before?

Thanks,

Chris

The static routes appear to be correct as such but it is hard to determine what the issue is without knowing how many hops are in between the two routers and how they are configured.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

I am not able to PING the default gateway for the Manchester location from the manchester router.

Hi Chris,

It seems that you have a routing problem between the 2 routers and accordingly the tunnel can't get up, you'll need to traceroute from both ends to find out where is the routing broken and fix this problem.

HTH,

Mohammed Mahmoud.

Chris

If you are not able to ping the default gateway that would be the place to start troubleshooting. I would suggest to check for physical connectivity issues first. Assuming that physical connectivity looks ok then I would probably see if cdp is enabled (from the configs you posted it should be) and if so does the router see the gateway as a cdp neighbor. It would also be helpful to check the ARP table and verify whether the router has an ARP entry for the gateway address.

HTH

Rick

HTH

Rick

Chris

As Harold points out the partial configs that you posted are internally consistent and look ok. For example the static route:

ip route 216.41.92.158 255.255.255.255 155.212.77.193

correctly defines the destination address and defines a next hop that appears to be in the subnet of a physical interface. So it looks good to us. There is no way for us to know whether 155.212.77.193 has a route to 216.41.92.158. From the behavior I am guessing that it does not. Can you verify this?

HTH

Rick

HTH

Rick

Try troubleshooting basic IP connectivity between the tunnel endpoints using extended ping.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hi,

Agree with Hritter, why don't you do a tracert (extended would be much better) and paste the output so that we may know where exactly the packet is dropping and why.

Regards

This issue has been resolved. The provider had to make some changes on their side.

Thanks for all of everyone help!!!!!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco