Why my packet got dropped on the way ?

Whenever a specific flow encounters drops due to a misconfigured ACL, it was difficult to find the root cause. Usual traceroute will not be useful in this scenario and an advanced tcptraceroute was required to be triggered along the network path to detect the issue. In many cases, feedback was suppressed this made it very difficult to ascertain the root cause.

In early 2000, Cisco used to have a product by name ACL Manager. If I am right, this was used for analysis of an ACL sequence before applying it to the switch. The product was taken off and there was a void that was left open for several years.

From an operational perspective, Netflow was gaining a lot of attention due to its capability to provide a granular performance metrics in a flow context. Today, this has taken a different shape and falls under the broad area of flow telemetry. Sensors in network interfaces or ASICs/FPGAs interconnecting network interfaces to the switch chipsets collect statistics.

Back then a thought of combining flow context in Netflow when drops occurred to me and Dinesh when we were working on improving network operations. It provides the drop reason in the flow context which can be used by the collector to trigger appropriate action. This catches flow drops at the earliest and with the specific reason, it also provides the pin pointed feedback to the network operators. The associated patent was issued as US Patent 8,605,588.

Recent internet draft on "In-situ OAM raw data export with IPFIX" has included the reason for export. Here is the excerpt from the draft..

Report the reason why IOAM data was exported. The "reason for export" is to complement the IOAM data retrieved from the packet. For example, if a packet was dropped by a node due to congestion,...

Excited to see the recent developments to improving the operations area