PFE: Packet drop in Ichip

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:

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:

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:

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:

About the author


Leave a Comment