We've been tracing a reachability issue trying to detect which ASN is performing DPI on incoming DNS packets towards one of our root servers and blocking some of them.
Ultimately we used ping-trace to build a view of the topology facing that server, and then had to manually run tests on the chosen nodes to find out which ones had the query blocked, and from that determine which common ASN was responsible for that blocking.
It would be really useful if ping-trace could run a secondary command alongside the mtr tracer, and then indicate in the 0th hop output what the return status of that command was. This would allow us at a single glance to identify which group of topologically connected nodes are causing an issue.
We've been tracing a reachability issue trying to detect which ASN is performing DPI on incoming DNS packets towards one of our root servers and blocking some of them.
Ultimately we used
ping-traceto build a view of the topology facing that server, and then had to manually run tests on the chosen nodes to find out which ones had the query blocked, and from that determine which common ASN was responsible for that blocking.It would be really useful if
ping-tracecould run a secondary command alongside the mtr tracer, and then indicate in the 0th hop output what the return status of that command was. This would allow us at a single glance to identify which group of topologically connected nodes are causing an issue.