DMVPN packet loss

[NayAungLin7876]

Although the dmvpn is up, it have the packet loss when ping from R1 to R2. I think it could be MTU issue but I configure same MTU size in all routers. But ping success rate is 100% between R1 and R2. This ping loss lead to EIGRP neighbor flapping up and down with the error message limited exceeded.

R1 ( Hub)

interface Tunnel0
ip address 192.168.1.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication cisco
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip tcp adjust-mss 1360
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 2

R3(spoke)interface Tunnel0
ip address 192.168.1.3 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication cisco
ip nhrp map 192.168.1.1 100.0.14.2
ip nhrp map multicast 192.168.1.1
ip nhrp network-id 1
ip nhrp holdtime 60
ip nhrp nhs 192.168.1.1
ip nhrp registration timeout 30
ip tcp adjust-mss 1360
tunnel source FastEthernet2/0
tunnel mode gre multipoint
tunnel key 2

R1(spoke)

interface Tunnel0
ip address 192.168.1.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication cisco
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip tcp adjust-mss 1360
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 2

[Georg Pauwen]

Hello,

the packet loss can occur anywhere, actually, so it is going to take some digging to find out what is going on. If your IOS supports the below, post the output of:

show interface
show ip cef switching statistics feature
show crypto ipsec sa detail
show crypto engine accelerator stat

[Joseph W. Doherty]

It's not uncommon for the hub's port to have more bandwidth then the spoke's port. Might it be possible, if yours is such a topology and if you're not using QoS, that the hub could be transmitting more traffic than the spoke can accept (even during a short burst)? (NB: If so, any such drops won't be "visible" on your network devices.)