Description of the dropped message counter in TIBCO LogLogic LMI
Article ID: KB0077146
Updated On:
| Products | Versions |
|---|---|
| TIBCO LogLogic Log Management Intelligence | all versions |
Description
On the LogLogic LMI System Status dashboard is a widget titled Message Counts. One of these counters is called Dropped Messages (starting with LMI 6.2.0 this has been changed to Dropped Packets).
This value is a sum of 3 independent counters that are tracked by the underlying operating system.
OSI layer 2 - This command is executed for each ethernet interface and summed before being added to the values for layers 3 and 4.
$ /usr/sbin/ethtool -S eth0 2>/dev/null | grep rx_errors | awk '{print $2}'
OSI layer 3
$ netstat -s -w | grep 'incoming packets discarded'
OSI layer 4
$ cat/proc/net/snmp | grep Udp | grep -v InErrors | awk '{print $4}'
Depending on the layer at which the packets are dropped the drops will mean something different and the troubleshooting will also differ. As can be seen, TCP drops are not tracked by LMI but that's because they are not directly tracked by Linux. Linux tracks layer 4 re-transmissions but if a packet is re-transmitted it's not dropped indefinitely, This is due in nature to the built in functionality of TCP. If a message is lost or dropped with TCP the sending system will be made aware and will re-transmit the packet.
Layer 2 drops can occur, for example, because frames sent by the source host are larger than the appliance's MRU value, which is 1500 bytes by default. If a source is configured to use jumbo frames (MTU = 9000) then LMI's ethernet interfaces will drop them.
Layer 3 drops can occur if, for example, UDP packets need fragmenting. Because UDP can't fragment on its own it relies on IP to do that. If the IP layer fails to send all fragments and LMI only receives a subset then it will eventually discard the packets it received; they won't be re-transmitted like they are when using TCP.
Layer 4 drops can occur if, for example, the datagrams' checksums are invalid.
Contact TIBCO LogLogic Support if you need assistance with troubleshooting dropped packets. Note that Linux does not record any details about the individual packets that are dropped so depending on the situation it may be difficult or impossible to identify the source(s) and/or root cause for the dropped packets. For example, identifying jumbo frames is feasible if there are a large number of them that stand out from all other packets but identifying a handful of random packets containing invalid checksums out of hundreds of thousands of packets received every second is not possible.
This value is a sum of 3 independent counters that are tracked by the underlying operating system.
OSI layer 2 - This command is executed for each ethernet interface and summed before being added to the values for layers 3 and 4.
$ /usr/sbin/ethtool -S eth0 2>/dev/null | grep rx_errors | awk '{print $2}'
OSI layer 3
$ netstat -s -w | grep 'incoming packets discarded'
OSI layer 4
$ cat/proc/net/snmp | grep Udp | grep -v InErrors | awk '{print $4}'
Depending on the layer at which the packets are dropped the drops will mean something different and the troubleshooting will also differ. As can be seen, TCP drops are not tracked by LMI but that's because they are not directly tracked by Linux. Linux tracks layer 4 re-transmissions but if a packet is re-transmitted it's not dropped indefinitely, This is due in nature to the built in functionality of TCP. If a message is lost or dropped with TCP the sending system will be made aware and will re-transmit the packet.
Layer 2 drops can occur, for example, because frames sent by the source host are larger than the appliance's MRU value, which is 1500 bytes by default. If a source is configured to use jumbo frames (MTU = 9000) then LMI's ethernet interfaces will drop them.
Layer 3 drops can occur if, for example, UDP packets need fragmenting. Because UDP can't fragment on its own it relies on IP to do that. If the IP layer fails to send all fragments and LMI only receives a subset then it will eventually discard the packets it received; they won't be re-transmitted like they are when using TCP.
Layer 4 drops can occur if, for example, the datagrams' checksums are invalid.
Contact TIBCO LogLogic Support if you need assistance with troubleshooting dropped packets. Note that Linux does not record any details about the individual packets that are dropped so depending on the situation it may be difficult or impossible to identify the source(s) and/or root cause for the dropped packets. For example, identifying jumbo frames is feasible if there are a large number of them that stand out from all other packets but identifying a handful of random packets containing invalid checksums out of hundreds of thousands of packets received every second is not possible.
Issue/Introduction
This article explains how the dropped message counter operates in LogLogic LMI.
Resolution
Feedback
Yes
No
Powered by
