Tunnel traffic stop, but its interface cannot be ping

[Leftz]

Hi In this router, the tunnel is inactive for long time. Checking the tunnel and its interface facing outside, it shows no any traffic. The strange thing is the router shows the interface 39.2.2.2 is up via show ip int bri, but the router cannot ping the ip. Confirmed not vrf there. Is there something wrong? Thanks

interface Tunnel10
ip address 172.16.222.1 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source 39.2.2.2
tunnel destination 51.5.5.5
tunnel protection ipsec profile ABC

[Flavio Miranda]

Is nothing wrong here but would be impossible to say anything looking only this. The other end should be verified and better yet, the whole show run must be provided.

I suggest you to shut and no shut the tunnel or the interface and see is it stablish again. You may see something unreal due software failure.

[David Ruess]

Hello,

Not necessarily. Please see the below documentation:

https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/118361-technote-gre-00.html#anc2

Specifically the line:

A valid tunnel destination is one which is routable. However, it does not have to be reachable

It could also display as up if the tunnel IP address is reachable but the underlay of tunnel source is not if its not running a routing protocol or using static routing within the network. If you're running a routing protocol over the tunnel you cant lean the tunnel destination through the tunnel itself (recursive routing)

Also I have seen tunnels remain up even if the other connection was terminated if it wasn't sending keepalives.

Hope that helps

-David

[Joseph W. Doherty]

From first hand experience, what @David Ruess describes/documents/references is true, i.e. a tunnel interface can be "up" but non-functional.  (First time I bumped into this, years [cough, cough, decades] ago, I thought what-the-heck.)

This always seemed true on older platforms, like those that could only run some GRE variant.  I have also seen, some newer platforms, with newer tunnel interface kinds, stay "down" unless you actually had a working tunnel.  Possibly they use some form of implicit keep-alive.

Regarding the latter point, some tunnels also support an explicit keep-alive which will force "down" tunnel interfaces unless you also have a working tunnel.  (I recall [?] the tunnel kinds that require a working tunnel to come "up" also will not accept an explicit keep-alive option.  [Another interesting factoid, possibly useful, is by default CDP won't run across tunnels, but on some tunnel kinds you can optionally enable it.])

[MHM Cisco World]

first 
ping y.y.y.y source x.x.x.x
y.y.y.y is destination of tunnel 
x.x.x.x is source of tunnel 

second as I mention before for tunnel use interface not IP address.

[Leftz]

Hi Thank you all for your reply. Actually I am talking about the physical interface as below, but I posted tunnel interface as above. The tunnel is using the below physical interface. The interface g0/0 is up, but the device cannot ping its own ip address. I am thinking what cause the ping failure.  

interface GigabitEthernet0/0
ip address 39.2.2.2 255.255.255.248
ip access-group P-SEC in
no ip redirects
no ip unreachables
no ip proxy-arp
ip verify unicast source reachable-via rx allow-default 100
duplex auto
speed auto
no mop enabled
end

[MHM Cisco World]

ping interface in router from router, I don't think this work.

[David Ruess]

Are you trying to get the tunnel to work?

If so can you provide a diagram and tunnel configs along with routing table entries. The underlay (tunnel source/destination) need to be able to reach each other for the tunnel to form. If the interface is connected and up it may not have connectivity to the other side.

-David

[Richard Burts]

There have been several comments about the behavior of GRE tunnels and their behavior that the tunnel can be up even if the peer address is not reachable. But this tunnel is not a traditional GRE tunnel. It is an implementation of Virtual Tunnel Interface which uses IPSEC to encrypt the traffic over the tunnel. And with VTI the tunnel will not be up unless the crypto negotiation was successful.

[Leftz]

@MHM Cisco World 

you mentioned "ping interface in router from router, I don't think this work."

you are trying to answer my question, but I do not think so. Usually each router should able to ping its own interface unless there is some special configuration. For this interface configuration(please see below), I do not see some special configuration there. Why the router cannot ping its own interface G0/0? 

interface GigabitEthernet0/0
ip address 39.2.2.2 255.255.255.248
ip access-group P-SEC in
no ip redirects
no ip unreachables
no ip proxy-arp
ip verify unicast source reachable-via rx allow-default 100
duplex auto
speed auto
no mop enabled
end

[MHM Cisco World · Accepted solution]

I don't try before but If this is OK for other interface then only 
ip access-group will deny the ping traffic 
check the access-group

[Leftz]

Thank you MHM. You are right.