Original Publication Date: 07/15/2009
Updated Date: 01/13/2014
When administering network devices, such as switches or routers, it is important to understand the causes of packet drops. Not all devices drop packets for the same reason, and drops are not always indicative of an issue with the device; in some cases, packet drops may be expected behavior. For example, the BIG-IP system may intentionally drop packets in certain situations, such as when a BIG-IP interface receives a frame containing an invalid VLAN ID. However, in other instances, packet drops may indicate an issue with the configuration or the device itself. For example, a BIG-IP interface will drop packets containing frame check sequence (FCS) errors. A high ratio of FCS errors may be a sign of a configuration issue, such as a duplex mismatch.
In addition, packet drops may occur at various stages of processing on the BIG-IP system; packets can be dropped by the BIG-IP interface or discarded by the Traffic Management Microkernel (TMM). For example, when a packet arrives at a BIG-IP interface containing an invalid VLAN ID, the switch chip drops the packet and the system increments the drop counter for the interface. When a packet arrives at the BIG-IP system with the destination IP address matching a virtual server, but containing a non-matching service port, the switch chip accepts the packet but the TMM discards the packet.
You can use command line utilities to monitor packets dropped by a BIG-IP interface, however, the command output does not indicate a reason for the drops. The following commands report the total numbers of packets dropped by the interface:
An understanding of how packets flow through the switch chip is helpful when discussing packets dropped by the interface. Packets flow through the BIG-IP switch chip in the following sequence:
The ingress logic determines how a packet is processed when it is received by the device. The ingress logic accepts the packet, determines the egress port to which the packet will be sent, and passes the packet to the memory management unit (MMU) for processing.
The MMU manages the internal/external packet buffering for the switch and schedules the packet for transmission.
The egress logic requests packets from the MMU and transmits to the egress port.
In general, when an ingress packet arrives at a BIG-IP interface, the switch chip must determine whether to buffer the packet, drop the packet, or drop another packet to make room.
The BIG-IP command line utilities include an input drop counter that reports when a frame is dropped by the switch chip. The following table lists some of the reasons why a packet can be dropped at the switch chip:
|Drop reason||Description||Possible cause|
|VLAN ID||The interface drop counter increments when an ingress packet is dropped due to an invalid VLAN ID.||Frames contain a VLAN tag that is not configured on the port.|
|Unknown packet||The interface drop counter increments when an ingress packet is dropped due to an unknown traffic type.
||A network device is sending unknown packets.
|FCS||When an ingress packet contains a frame check sequence (FCS) error, the interface will drop the packet.||Corrupt frames exist.
A duplex mismatch exists.
|Port flooding||The BIG-IP switchboard will drop a frame if the dynamic forwarding database (FDB) indicates that the egress port for the frame is the same as the ingress port. For example, if the switchboard receives a frame on port 1.1, destined for MAC address 02:10:01:f5:f5:f5, and the switchboard has already learned that MAC address 02:10:01:f5:f5:f5 resides on port 1.1, it will drop the frame.
||The upstream switch receives a frame destined for a MAC address not in its address table and subsequently floods the frame out all of its ports.|
In BIG-IP 9.x, in addition to the above drops, the bigpipe interface command input drop counter also reports buffer exhaustion drops.
In BIG-IP 9.4.7 and later, the bigpipe interface (9.x - 10.x) and tmsh show /net interface (11.x) commands output drop counter reports packets dropped due to buffer exhaustion:
|Drop reason||Description||Possible cause|
|Buffer exhaustion||Egress ports have an HOL (head-of-line) register that defines total buffer space that the port can consume before entering an HOL condition. The interface drop counter increments when the egress port buffer is full and the switch tells the ingress port(s) to drop packets destined for the egress port.||The link is oversubscribed.|
In BIG-IP 9.x, the bigpipe interface command output drop counter is always zero, since the BIG-IP system does not drop packets on transmission.
Once the packet is passed to the TMM, the TMM must decide whether to process the packet or drop the packet. You can view packets dropped by the TMM by using the following commands:
The following table lists some of the reasons that packets can be dropped by the TMM:
|IP drop reason||Description||Possible cause|
|Virtual server match||A packet arriving at the BIG-IP system with the destination IP address matching a virtual server, but containing a non-matching service port, will be dropped by the IP filter and the bigpipe ip drop counter will increment. For more information, refer to SOL13151: Configuring the rate at which the BIG-IP system issues TCP RSTs or ICMP unreachable packets (11.x).||Misconfigured client|
|IP version number||The IP drop counter increments when a packet contains an incorrect or invalid IP version number and the IP filter drops packet.||Corrupt packet|
|Checksum||The IP drop counter increments when a packet contains an invalid L3 checksum and the IP filter drops the packet.||Corrupt packet|
|IP option||The IP drop counter increments when a packet contains an IP option. If the TM.AcceptIPOptions BigDB key is set to enable, the system accept IPv4 packets with IP options.||Client performing debug, security test|
|Length||The IP drop counter increments when a packet contains an invalid L3 length field.||Corrupt packet|
|Protocol||The IP drop counter increments when a packet contains an invalid L3 protocol field.||Corrupt packet|
|Maintenance||The IP drop counter increments when a new request arrives for a traffic management object and the IP filter drops the packet because the system is in maintenance mode.||Maintenance mode is enabled on the BIG-IP system|
|Connection limit||The IP drop counter increments when a new request arrives for a virtual server and the IP filter drops the packet because the connection limit was reached.||A connection limit is enabled for the virtual server|
|License||The IP drop counter increments when a new request arrives for a virtual server and the IP filter drops the packet because of a licensing issue.||The license is not activated or installed|
BIG-IP packet drops may be the result of a known issue. For more information, refer to the following table:
|SOL5682||The dropped packet counter behavior is different on some BIG-IP platforms.|
|SOL9203||A trunk interface drops a small number of frames during link recovery.|
|SOL9792||BIG-IP platforms containing a Packet Velocity ASIC chip show packet loss on the internal links.|
|SOL9797||The bigpipe interface command does not include HOL packet drops.|
|SOL8894||The BIG-IP drops TCP RST packets with sequence numbers that do not match the last acknowledged sequence number.|
|SOL10290||Change in Behavior: The BIG-IP system drops packets containing double 802.1q VLAN tags.|
|SOL9317||The BIG-IP system may drop packets when more than eight different MAC masquerade addresses are defined.|
|SOL11096||The BIG-IP system may incorrectly drop a RST packet for an established flow when the system is holding a pending ACK.|
|SOL12375||Running the tcpdump command on an interface may cause the BIG-IP system to drop STP BPDU frames.|