Input errors

[engineer on duty]

I have Cisco 7206VXR (NPE-G2) running C7200P-ADVIPSERVICESK9_LI-M.

The router is an edge router that is supposed to route traffic from our AS to the internet. We have dual-homed BGP with two ISP.

the ISP's are conneced to physical interface gig0/2 and gig0/3

Our PI(provider independent network) is configured on subinterface(GigabitEthernet0/1.200) of physical interface gigabit0/1

and there is one more subinterface with private network (GigabitEthernet0/1.100) of physical interface gigabit 0/1

Recently I had to implement three ipsec tunnels and in order to provide redundancy I had to terminate them on interface (GigabitEthernet0/1.200).

Besides I had to add Service Policy(PBR) to interface GigabitEthernet0/1.100 to make local traffic get into cryptomap which is placed on interface GigabitEthernet0/1.200.

After adding service policy(PBR) to interface GigabitEthernet0/1.100 the Input errors counter began increasing also Input queue counter started increasing. 

the question is why while Input queue counter is increasing input queue size is always zero?

Input queue: 0/100/12599/0 (size/max/drops/flushes)

GigabitEthernet0/1 is up, line protocol is up
Hardware is MV64460 Internal MAC, address is 0026.52c7.1c1b (bia 0026.52c7.1c1b)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 22/255, rxload 40/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is RJ45
output flow-control is XON, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:15:13
Input queue: 0/100/12599/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 157051000 bits/sec, 16219 packets/sec
5 minute output rate 87180000 bits/sec, 12304 packets/sec
15095172 packets input, 1392936945 bytes, 0 no buffer
Received 787 broadcasts, 0 runts, 0 giants, 0 throttles
10962 input errors, 0 CRC, 0 frame, 0 overrun, 10962 ignored
0 watchdog, 20753 multicast, 0 pause input
0 input packets with dribble condition detected
10992756 packets output, 1207968853 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
30 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

It could be the input queue depth appears zero because you've just haven't caught it with packets in the queue.  Input queue packets are waiting on the CPU.  As yours is a gig interface and queue size is only 100 packets, for example, a burst of minimum sized packets could quickly (.05 ms) overflow the input queue depth and also be very quickly drained .

[engineer on duty]

There are a lot of errors. the counter is incrementing almost every second and I am entering the command also almost every second so I think I should see the queue even once bigger than zero. but it is always zero. besides there is one command that shows the headers of the packets that are queued but when I use it, it shows that there are no packets in a queue.

and one more question - what is the reason of these errors?

the cabling is checked.

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

It might take lots and lots and lots of tries to catch a queue depth value when it can happen and be gone in as little of about .05 ms.  (It's also possible you have a bug that doesn't display the input queue depth.)

My understanding, on a 7200, the input queue is used when the CPU falls behind processing the input stream.  You might try increasing the input queue size (a lot - such as even the max), which I also understand, is usually benign.