Cant PING Interface from router itself

[lamav]

OK...what gives? What am I missing? Why cant I PING an interface on the router from the router itself?

interface Tunnel0
description THIS TUNNEL SUPPORTS MULTIPLE SITE-TO-SITE VPN TUNNELS
ip address 10.40.16.1 255.255.252.0
ip verify unicast source reachable-via any
no ip redirects
ip mtu 1420
ip nhrp authentication xxxx
ip nhrp map multicast dynamic
ip nhrp network-id 77
ip nhrp holdtime 300
no ip route-cache cef
no ip route-cache
ip ospf message-digest-key 1 md5 7 xxxxxx
ip ospf network point-to-multipoint
ip ospf cost 100
ip ospf priority 255
no ip mroute-cache
cdp enable
tunnel source Loopback100
tunnel mode gre multipoint
tunnel key 100001
tunnel protection ipsec profile DMVPN-RL
end

VPN01#sh int tun 0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Description: THIS TUNNEL SUPPORTS MULTIPLE SITE-TO-SITE VPN TUNNELS
  Internet address is 10.40.16.1/22
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
     reliability 255/255, txload 66/255, rxload 50/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 138.69.152.3 (Loopback100), destination UNKNOWN
  Tunnel protocol/transport multi-GRE/IP
    Key 0x186A1, sequencing disabled
    Checksumming of packets disabled

  Fast tunneling enabled
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Tunnel protection via IPSec (profile "DMVPN-RL")
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/1057106/0 (size/max/drops/flushes); Total output drops: 8648961
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 11547000 bits/sec, 1224 packets/sec
  5 minute output rate 1949000 bits/sec, 819 packets/sec
     76957792665 packets input, 94288980602030 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     44239653088 packets output, 9828102711747 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
VPN01#ping 10.40.16.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.40.16.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
VPN01#

[sachinraja]

Hi Lamav

Are you able to ping the other end of the connection ? sometimes i have seen local pings going to the other end coming back through the circuit... are you having the same issue the other end ?

Raj

[lamav]

10.40.16.1 is the hub router

I can ping one of the spokes and the spoke can PING the hub...the hub cannot ping itself

[lamav]

Helloooooooooooooooo.....anybody out there? :-)

I can hear the crickets chirping

[Reza Sharifi · Accepted solution]

Hi,

I can hear you

It this connection over a serial (frame relay interface)?

Reza

[lamav]

I rated your post by mistake...big mistake.

Please read the post. I am not going over any connection. I am PINGing a routers interface from the router itself.

[Reza Sharifi]

I read your post and I understand you are pinging the router interface from the router itself.

The reason I asked is because in a frame relay point to multipoint environment you can not ping your own interface unless you do a mapping if the IP address of the interface to a DLCI number.

Reza

[lamav]

Reza, my apologies for not seeing the logic behind your answer...thank you...rated your second post -- this time deliberatrely

[Giuseppe Larosa]

Hello Victor,

I think Reza is not far from the reason the ping fails:

the multipoint GRE can be equated to a FR point to multipoint subinterface for some aspects.

What should do the router to ping itself?

it should create a GRE packet with source = physical interface destination = physical interface that contains an ICMP packet with mGRE ip address and destination of mGRE ip address.

A Lan interface ping itself without sending the packet out on wire.

Here the GRE should be deincapsulated to be able to get the ICMP echo request.

It should be a question of depth of recursion.

So I would suggest that this should not be seen as a sign of a real problem.

You can easily get other indicators of good working:

pinging of other spokes in mGRE logical subnet

OSPF neighborships in the mGRE subnet

Hope to help

Giuseppe

[lamav]

Giuseppe:

I am thinking about something along those lines, but I still cant make sense out of it in my head....still fuzzy.

I do know that there is no problem, per se. I just want to know why this behavior exists. Its a learning experience.

The DMVPN environment is fine -- I know that.

OK, so what is the difference between pinging an ethernet interface and a GRE interface in terms of encapsulation?

Giuseppe, can I give you some constructive criticism? Please dont take this the wrong way, OK?

I think you're a brilliant and a gifted engineer and I appreciate the time you take to help me and others. I look forward to reading your thoughts and input. The language barrier, however, degrades your responses because I oftentimes find it difficult to read and understand your posts. Now, I am grateful and impressed that your English is as good as it is living in Italy. Your English is a lot better than my Italian! :-) Nonetheless, the problem remains.

So, can you do me a favor and take your time writing a response -- focus a bit more on language and clarity, especially punctuation. It is important to punctuate your sentences so that they can be read clearly.

I hope I didnt speak out of turn. I just want to be able to fully appreciate the intelligence of your thoughts and experience.

Victor

[Giuseppe Larosa]

Hello Victor,

your kind remarks are similar to those I received from my teachers at the high school!

I've appreciated your earnest feedback

I will come back with better content on your question.

Best Regards

Giuseppe

[Giuseppe Larosa]

Hello Victor,

I try to explain better my thoughts on this issue.

The multipoint GRE relays on NHRP to resolve the private address on an actual public address for each remote.

Each remote has a static entry telling the corrispondence between hub private address and hub public address.

In addtion to this, each remote is configured with the hub private ip address as the NHRP server for the segment.

As a result of these two configuration elements, each remote is able to solve the hub using the static entry and registers itself to the server with periodic NHRP messages.

The NHRP provides an abstraction of an NBMA allowing to resolve private ip addresses into public ip addresses.

I see two possible reasons for the ping failure of the hub ip address on the hub router itself:

- a resolution problem that may be caused by the missing entry for hub private ip address to hub public ip address on the NHRP server running on the hub router

- a problem of depth of encapsulation.

About first possible cause you can check NHRP entries with

sh ip nhrp

this can easily tell if the entry exists on the hub NHRP cache.

debug ip icmp

debug nhrp packet

these two debug commands can be of help in troubleshooting during ping attempts

Hope to help

Giuseppe

[lamav]

Hey, Giuseppe:

Thank you very much for your time and patience.

Interesting theory...I'll look further into it....

Thank you