Table Of Contents
Table Of Contents

Visualizing Packet Drops


This showcase presents various simulation models that demonstrate the use of the packet drop visualizer in identifying network problems in INET simulations. The visualizer helps to pinpoint the causes of excessive packet drops, such as poor connectivity, congestion, or misconfiguration, allowing for more efficient debugging and analysis. The simulation models showcase typical scenarios of packet drops resulting from issues such as retransmission in wireless networks and overflowing queues in bottleneck routers.

INET version: 4.0

About the visualizer

Packet drops can be visualized by including a PacketDropVisualizer module in the simulation. The PacketDropVisualizer module indicates packet drops by displaying an animation effect at the node where the packet drop occurs. In the animation, a packet icon gets thrown out from the node icon and fades away.

The visualization of packet drops can be enabled with the visualizer’s displayPacketDrops parameter. By default, all packet drops at all nodes are visualized. This selection can be narrowed with the nodeFilter, interfaceFilter and packetFilter parameters, which match for node, interface and packet. (The packetFilter can filter for packet properties, such as name, fields, chunks, protocol headers, etc.) Additionally, and the detailsFilter parameter to filter for packet drop reason.

The packetFormat parameter is a format string and specifies the text displayed with the packet drop animation. By default, the dropped packet’s name is displayed. The format string can contain the following directives:

  • %n: packet name

  • %c: packet class

  • %r: drop reason

Packets can be dropped for the following reasons, for example:

  • queue overflow

  • retry limit exceeded

  • unroutable packet

  • network address resolution failed

  • interface down

One can click on the packet drop icon to display information about the packet drop in the inspector panel, such as the packet drop reason, or the module where the packet was dropped:


The following sections demonstrate some reasons for dropped packets, with example simulations. In the simulations, the PacketDropVisualizer is configured to indicate the packet name and the drop reason.

Queue overflow

In this section, we present an example for demonstrating packet drops due to queue overflow. This simulation can be run by choosing the QueueFull configuration from the ini file. The network contains a bottleneck link where packets will be dropped due to an overflowing queue:


It contains a StandardHost named source, an EthernetSwitch, a Router, an AccessPoint, and a WirelessHost named destination. The source is configured to send a stream of UDP packets to destination. The packet stream starts at two seconds after destination got associated with the access point. The source is connected to the etherSwitch via a high speed, 100 Gbit/s ethernet cable, while the etherSwitch and the router are connected with a low speed, 10 MBit/s cable. This low speed cable creates a bottleneck in the network, between the switch and the router. The source host is configured to generate more UDP traffic than the 10Mbit/s channel can carry. The cause of packet drops, in this case, is that the queue in etherSwitch fills up.

The queue types in the switch’s Ethernet interfaces are set to DropTailQueue, with a default length of 100 packets (by default, the queues have infinite lengths). The packets are dropped at the ethernet queue of the switch.

The visualization is activated with the displayPacketDrops parameter. The visualizer is configured to display the packet name and the drop reason, by setting the labelFormat parameter. Also, the fade-out time is set to three seconds, so that the packet drop animation is more visible.

*.visualizer.*.packetDropVisualizer.displayPacketDrops = true
*.visualizer.*.packetDropVisualizer.labelFormat = "%n/reason: %r"
*.visualizer.*.packetDropVisualizer.fadeOutTime = 3s

When the simulation is run, the UDP stream starts at around two seconds, and packets start accumulating in the queue of the switch. When the queue fills up, the switch starts dropping packets. This scenario is illustrated in this animation:

Here is the queue in the switch’s eth1 interface, showing the number of packet drops:


This log excerpt shows the packet drop:


ARP resolution failed

In this example, a host tries to ping a non-existent destination. The configuration for this example is ArpResolutionFailed in the ini file. Packets will be dropped because the MAC address of the destination cannot be resolved. The network for this configuration is the following:


It contains only one host, an AdhocHost.

The host is configured to ping the IP address It will try to resolve the destination’s MAC address with ARP. Since there are no other hosts, the ARP resolution will fail, and the ping packets will be dropped.

The following animation illustrates this:

This excerpt shows this in the log:


MAC retry limit reached

In this example, packet drops occur due to two wireless hosts trying to communicate while out of communication range. The simulation can be run by selecting the MACRetryLimitReached configuration from the ini file. The configuration uses the following network:


It contains two AdhocHost’s, named source and destination. The hosts’ communication ranges are set up so they are out of range of each other. The source host is configured to ping the destination host. The reason for packet drops, in this case, is that the hosts are not in range, thus they can’t reach each other. The source transmits the ping packets, but it doesn’t receive any ACK in reply. The source's MAC module drops the packets after the retry limit has been reached. This scenario is illustrated in the following animation:

These events looks like the following in the logs:


No route to destination

In this example, packets will be dropped due to the lack of static routes. The configuration is NoRouteToDestination in the ini file. The network is the following:


It contains two connected StandardHost’s. The Ipv4NetworkConfigurator is instructed not to add any static routes, and host1 is configured to ping host2.

The ping packets can’t be routed, thus the IP module drops them. This scenario is illustrated in the following video:

Here is also a log excerpt illustrating this:


Interface not connected

In this example (InterfaceNotConnected configuration in the ini file), packet drops occur due to a disabled wired connection between the hosts:


It contains two StandardHost’s, connected with an ethernet cable. The ethernet cable is configured in the NED file to be disabled. Additionally, host1 is configured to ping host2.

Since the cable between the hosts is configured to be disabled, the MAC module is unable to send the packets and drops them. This is illustrated in the following animation:

Note the packet drop animation at host1. The packet drops are also evidenced in the log:


Sources: omnetpp.ini, PacketDropVisualizationShowcase.ned

Further information

For more information, refer to the PacketDropVisualizer NED documentation.


Use this page in the GitHub issue tracker for commenting on this showcase.