cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1931
Views
0
Helpful
2
Replies

DMVPN Phase-3 Packet drops on tunnel interface

sumit menaria
Level 1
Level 1

Hi,

I am really stuck at this one ,since I dont know the way ahead to check issues which could be causing the drops on my tunnel interface on the CPE for DMVPN. I have attached a brief topology overview of the connectivity.

Here lets consider one of the spoke-SPOKE1

psn-cr272-ce1#sh int tunnel 100
Tunnel100 is up, line protocol is up
Hardware is Tunnel
Description: ** vpn health internal **
Internet address is 10.80.49.16/22
MTU 17870 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 255/255, rxload 255/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.81.49.16 (Loopback100)
Tunnel Subblocks:
src-track:
Tunnel100 source tracking subblock associated with Loopback100
Set of tunnels with source Loopback100, 1 member (includes iterators), on interface <OK>
Tunnel protocol/transport multi-GRE/IP
Key 0x39068D30, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255, Fast tunneling enabled
Tunnel transport MTU 1430 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "health_vpn_profile")
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters 1d23h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 12223
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 660000 bits/sec, 655 packets/sec
5 minute output rate 526000 bits/sec, 355 packets/sec
96902202 packets input, 3681528614 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
53118134 packets output, 1324940025 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out

If you see the above output there are drops on the tunnel interface and they are increasing gradually at the rate of 5-10 per minute.

I cannot see any errors or crc.However the users on the LAN side are reporting disconnect or drops between the site to site and the site to hub connectivity only on the LAN part. If you see the peers in DMVPN they are still up.

psn-cr272-ce1#sh dmvpn int tu100

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb

----- --------------- --------------- ----- -------- -----
1 10.81.49.153 10.80.49.153 UP 2d01h D
1 10.81.49.245 10.80.49.245 UP 1d15h S
1 10.81.49.251 10.80.49.251 UP 00:04:28 D
1 10.81.51.245 10.80.51.245 UP 2d01h S
1 10.81.51.251 10.80.51.251 UP 00:04:29 D

Now this could be issue at the LAN side too at any of the spoke or the Hub ,but I wanted to fully remove the drops from the Tunnel interface to be sure of it .

Configuration of the tunnel interface is as below.

interface Tunnel100
description ** vpn health internal **
ip vrf forwarding health_internal
ip address 10.80.49.16 255.255.252.0
no ip redirects
no ip proxy-arp
ip mtu 1400
ip nhrp authentication p0lice
ip nhrp map multicast 10.81.49.245
ip nhrp map 10.80.49.245 10.81.49.245
ip nhrp map multicast 10.81.51.245
ip nhrp map 10.80.51.245 10.81.51.245
ip nhrp network-id 100
ip nhrp holdtime 600
ip nhrp nhs 10.80.49.245
ip nhrp nhs 10.80.51.245
ip nhrp registration no-unique
ip rip v2-broadcast
ip rip advertise 15
ip rip send version 2
ip rip receive version 2
ip tcp adjust-mss 1360
no ip split-horizon
tunnel source Loopback100
tunnel mode gre multipoint
tunnel key 956730672
tunnel protection ipsec profile health_vpn_profile
end

Cannot see any drops as such on the Tunnel to tunnel interface connectivity too.

psn-cr272-ce1#ping vrf health_internal 10.80.49.245 source 10.80.49.16 size 2000 repeat 100
Type escape sequence to abort.
Sending 100, 2000-byte ICMP Echos to 10.80.49.245, timeout is 2 seconds:
Packet sent with a source address of 10.80.49.16
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 16/17/20 ms

Is it that I am missing some checks or something which could be cause of these drops.

psn-cr272-ce1#sh int tunnel 100 | in drops
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 12246
0 unknown protocol drops

Please note that this is not at just one spoke but almost all the spokes.

2 Replies 2

sumit menaria
Level 1
Level 1

One more thing to add is that the physical interface from the spoke to the service provider PE does not show any drops.

psn-cr272-ce1#sh int MF4 | in drops
Input queue: 0/75/6/0 (size/max/drops/flushes); Total output drops: 1
Output queue: 0/1000/0 (size/max total/drops)
0 unknown protocol drops
psn-cr272-ce1#sh int Serial0/0/1:0 | in drops
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
0 unknown protocol drops
psn-cr272-ce1#sh int Serial0/0/0:0 | in drops
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
0 unknown protocol drops

psn-cr272-ce1#sh int tunnel 100 | in drops
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 12293
0 unknown protocol drops

Hello,

The most common reason why we see output drops on tunnel interface
is when it received large packets with DF bit set while end hosts doing
PMTUD. These packets are registered as outout drops on the tunnel
interface. Other option is when the router receives packets
but not have the destination in its CEF table.
This CEF drops could very well be contributing the output on tunnel
interface. A thrid option is when router has high CPU, which
doesn't seem to be the case.
Finally if the tunnel destination cannot be reach is I believe also
generating
drops.

http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html#fifth

Another thing to try is “no ip route-cache” under tunnel interface.

We can also use “debug ip cef drop”

Do you see drops with ipsec removed?

thanks

Manish