OK...what gives? What am I missing? Why cant I PING an interface on the router from the router itself?
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
tunnel source Loopback100
tunnel mode gre multipoint
tunnel key 100001
tunnel protection ipsec profile DMVPN-RL
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 184.108.40.206 (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
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)
Solved! Go to Solution.
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 ?
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.
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.
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
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.
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.
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