Packet Reordering Detection

IP Networks don't guarantee that the packets sent will arrive at the destination in the exact same order. When the order of the packets is not the same, it is generally referred to as Packet Reordering, Packet Out-of-Order or Packet Out-of-Sequence.

When using TCP in applications such as web browsing, the received packets that are out-of-order are reordered automatically by the TCP Stack. It is transparent to the application but can still have some performance impact in some cases.

However, when using UDP, there are no built-in mechanisms to reorder out-of-order packets. This can cause major performance issues for real-time applications such as VoIP or video-conferencing. With these applications, the jitter buffer algorithms need to take the reordering into account, which is not ideal in most cases.

The only way to detect packet reordering is by sending packets at a very fast speed and then comparing the received packet order with what was sent. The delay between two packets must be minimal in order to catch the reordering. At Obkio, our Network Performance Monitoring algorithm sends packets every 500ms. This interval is great to measure network performance and catch issues. However, in order to detect out-of-order packets with this algorithm, the packets must be delayed by more than 500ms, which is a very long time.

In order to remedy the situation, we introduced packet bursts to our algorithm to help us detect packet reordering. Every minute or so, a burst of 5 packets is sent as fast as possible. If there is packet reordering, a Packet Reordering network issue will be raised with the severity Information. Once the issue is raised, it will be cleared after 10 minutes if no more out-of-order packets are detected.

Packet reordering can happen during network route changes. This is due to the convergence of the network routing protocols (BGP, OSPF, EIGRP, etc.). This is normal and should not affect your applications that much because only a few packets will be reordered during a short period of time, and it should stop once the network is converged (i.e. the routes are stabilized). This usually takes a few seconds depending on the routing procotol and the configuration.

If the packet reordering continues, it is probably caused by load balancing on multiple links. When configuring load balancing (or load sharing) on multiple links, the equipment must decide where each packet goes. It is usually recommended to use a hashing algorithm that will load balance based on fields in the packet headers (such as IPs and Ports). Packet reordering can happen when per-packet load balancing is configured.

You can disable the Packet Reordering alerts in the Monitoring Template Advanced Parameters.