%PKT_INFRA-PQMON-6-QUEUE_DROP | ASR9K | 5.3.3 SP2

nfajnzyn78 · ‎07-04-2016

Hi Community!

I have the following log, and found some information PQMON DROP.

Could help me to find the root cause? 
Are there some troubleshooting for these cases?
It could be related to the process nfsvr (NetFlow) or netio?

Thank you very much in advance.

ALARM


nfsvr[293]: %PKT_INFRA-PQMON-6-QUEUE_DROP : Taildrop on XIPC queue 1 owned by netio (jid=288)

PROCESS


RP/0/RSP0/CPU0:#sh processes 288
Mon Jul 4 14:57:02.656 ARG
 Job Id: 288
 PID: 241824
 Executable path: /disk0/iosxr-fwding-5.3.3/0x100305/sbin/ipv4_arm
 Instance #: 1
 Version ID: 00.00.0000
 Respawn: ON
 Respawn count: 1
 Last started: Thu Jun 23 02:26:16 2016
 Process state: Run
 Package state: Normal
 Process group: dlrsc
 core: MAINMEM 
 Max. core: 0
 Level: 98
 Placement: DLRSC Tracker
 startup_path: /pkg/startup/ipv4_arm.startup
 Ready: 0.465s
 Available: 4.366s
 Process cpu time: 1.935 user, 0.330 kernel, 2.265 total
JID TID CPU Stack pri state TimeInState HR:MM:SS:MSEC NAME
288 1 1 72K 10 Receive 0:01:27:0198 0:00:02:0239 ipv4_arm
288 2 1 72K 10 Receive 276:30:45:0995 0:00:00:0000 ipv4_arm
288 3 1 72K 10 Receive 276:25:41:0622 0:00:00:0005 ipv4_arm
288 4 3 72K 10 Receive 0:00:03:0676 0:00:00:0014 ipv4_arm
288 5 3 72K 10 Receive 4:06:41:0463 0:00:00:0000 ipv4_arm
288 6 3 72K 10 Receive 0:00:00:0329 0:00:00:0006 ipv4_arm

PLATFORM

RP/0/RSP0/CPU0:#SH PLAT
Mon Jul 4 14:57:55.861 ARG
Node Type State Config State
-----------------------------------------------------------------------------
0/RSP0/CPU0 A9K-RSP440-SE(Active) IOS XR RUN PWR,NSHUT,MON
0/RSP1/CPU0 A9K-RSP440-SE(Standby) IOS XR RUN PWR,NSHUT,MON
0/3/CPU0 A9K-2x100GE-TR IOS XR RUN PWR,NSHUT,MON

INTERFACE 100G


RP/0/RSP0/CPU0:#sh int hundredGigE 0/3/0/0
Mon Jul 4 15:21:43.795 ARG
HundredGigE0/3/0/0 is up, line protocol is up 
 Interface state transitions: 1
 Hardware is HundredGigE, address is
 Layer 1 Transport Mode is LAN
 Internet address is 186.153.152.174/30
 MTU 4484 bytes, BW 100000000 Kbit (Max: 100000000 Kbit)
 reliability 255/255, txload 89/255, rxload 75/255
 Encapsulation ARPA,
 Full-duplex, 100000Mb/s, link type is force-up
 output flow control is off, input flow control is off
 Carrier delay (up) is 10 msec
 loopback not set,
 Last link flapped 1w4d
 ARP type ARPA, ARP timeout 04:00:00
 Last input 00:00:00, output 00:00:00
 Last clearing of "show interface" counters 1w2d
30 second input rate 29560645000 bits/sec, 5192521 packets/sec
 30 second output rate 35072684000 bits/sec, 6003996 packets/sec
 3279257235173 packets input, 2320177270218759 bytes, 873411556 total input drops
 0 drops for unrecognized upper-level protocol
 Received 0 broadcast packets, 351335 multicast packets
 0 runts, 0 giants, 0 throttles, 0 parity
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
 3748981147495 packets output, 2620607410892948 bytes, 0 total output drops
 Output 0 broadcast packets, 340116 multicast packets
 0 output errors, 0 underruns, 0 applique, 0 resets
 0 output buffer failures, 0 output buffers swapped out
 0 carrier transitions

Syed Zaidi · ‎07-04-2016

We fixed an issue with CSCty04480 which is fixed since 430 onward ,

nfsvr[272]: %PKT_INFRA-PQMON-6-QUEUE_DROP : Taildrop on XIPC queue 1 owned by netio (jid=267)
This cause flows that have been collected not to be exported to the external NetFlow collector appliance

Conditions:
This has been observed only when the cache is constantly reaching the highwater mark and flows need to be aggressively exported until the number of flows in the cache is below 80% of cache size.

Workaround:
Lower the sampling rate. It is recommended that for 10G interfaces the sampling rate be no higher than 1 out 1000.

What is your sampling rate on 100G interface and can you update us if lowering the sampling rate is helping here or not .