The I-chip packet writer drop counter is incrementing, possibly indicating packet drops which might, but not necessarily, be due to a faulty switching board.
The Packet drop in Ichip message is logged when the I-chip is reporting dropped packets.
Unless there is an actual impact to traffic, these messages are harmless and can be ignored.
When the I-chip on the FPC/FEB/CFEB is dropping packets from the PFE, it logs the action into the syslog. Some examples of the message are:
cfeb ICHIP(0):Packet drop in Ichip pktwr,rate: 1, total: 28861 fpc1 ICHIP(3):Packet drop in Ichip pktwr,rate: 1, total: 1339064 fpc4 ICHIP(0):Packet drop in Ichip pktwr,rate: 486, total: 2351881 fpc0 ICHIP(3):Packet drop in Ichip pktwr,rate: %PFE-3: 1, total: 12177 feb4 ICHIP(0):Packet drop in Ichip pktwr,rate: %PFE-3: 1, total: 5257105
Ipktwr is the block in the Packet Forwarding Engine (PFE) which receives the packet as data and notification cells and forwards to memory bank and look-up blocks, respectively. There can be many reasons for the packets to get dropped in this block, including some unrecognized vendor-specific packets such as CDP, native vlan-tag and so on.
Every vendor uses their own protocol to discover/negotiate certain features. Proprietary protocols such as CDP, DTP, VTP, and so on are used for features such as discovery protocol, trunking, VLAN spanning, and so on. These packets are not supported by Juniper and are dropped in Ipktwr blocks. The dropped packets may be reported as any of the following:
- L3 incompletes – Packets that fail a Layer 3 header sanity check
- L2 channel errors – Number of times the software did not find a valid logical interface for an incoming frame
- Policed Discards – Discarded frames that were not recognized or were not of interest
- Input DA Rejects – Number of packets with a destination Media Access Control (MAC) address that is not on the accept list. It is normal to see this number increment. For example, a packet with a VLAN ID that does not exist on this interface will be rejected.
In rare scenarios, hardware such as SCB or FPC components can show a hardware state that produces the message.
Perform these steps to determine the cause and resolve the problem (if any):
1. Collect the show command output to help determine the cause of this message.
Capture the output to a file (in case you have to open a technical support case). To do this, configure each SSH client/terminal emulator to log your session.
show interfaces extensive
show pfe statistics error
2. Analyze the show command output. Determine if Policed Discards, L3 incompletes, and/or DA rejects are being recorded by looking at the output of these two commands.
If these counters are incrementing with the Packet drop in Ichip messages, then the I-chip is performing as designed and dropping packets for protocols which it is not programmed to handle. This can be verified by checking the equipment that is sending/receiving traffic to the device. If connecting network devices are from other vendors, then these devices can be sending unrecognized traffic to Junos.
3. If no upgrade was done and no interface errors are being seen, check the log messages output for other events being reported in the same timeframe:
show log messages show log chassisd
If the message refers to an FPC or FEB, then obtain the logs from the FPC/FEB. This can be done with one of the following sets of commands:
start shell pfe network [fpc#/feb#] > set syslog tty disable > show ichip ifd > show ichip 0 wi spi error > show ichip 0 spi4 errors > show ichip 0 ipktwr statistics > show syslog messages > show nvram > exit -OR-- request pfe execute command "show ichip ifd" target [fpc#/feb#] request pfe execute command "show ichip 0 wi spi error" target [fpc#/feb#] request pfe execute command "show ichip 0 spi4 errors" target [fpc#/feb#] request pfe execute command "show ichip 0 ipktwr statistics" target [fpc#/feb#] request pfe execute command "show syslog messages" target [fpc#/feb#] request pfe execute command "show nvram" target [fpc#/feb#]
Be sure to replace the above [fpc#/feb#] entry with the reference to the system component, which is reporting the log message.
You might see other messages related to this component or other components in the PFE. Hardware issues can be reported in the chassisd output. Finally, the logs from the PFE components can also report the Ipktwr activity, which can also be associated with other error messages.
4. These error log messages are not harmful and will not cause any service impact towards routers. However, a huge number of log messages will write to the hard disk on the Routing Engine, which might be the cause for the hard disk failed issue.
If a customer cannot disable the trigger, which includes the Cisco native VLAN or CDP, and the log messages occur frequently, the customer can configure the syslog filter to ignore the messages, so as to avoid hard disk failure, using the following command:
- set system syslog file messages match "!(.* Packet drop in Ichip pktwr,rate .*) "