help with diagnosing traffic blackhole to / from select akamai ranges?

[William McLendon <wimclend () gmail com>]

Good afternoon,

we have a downstream customer originating a more specific /24 prefix, and when they do so, traffic sourced from that 
/24 prefix to at least a subset of akamai ranges (at minimum the 184.27.24.0/22 block at this time) are getting 
blackholed somewhere along the path either to or from, but i’m not sure how best to go about troubleshooting or getting 
assistance with diagnosing where the problem may be.

from a device in the offending IP block I cannot ping or curl to www.akamai.com <http://www.akamai.com/> that resolves 
to 184.27.25.72, however from an IP outside the /24 specific prefix but still in their supernet range I am able to ping 
and get an HTTP 301 redirect response.  Some other akamai prefixes like 23.73.0.0/20 seem to work without issue from 
what I can tell thus far.  If the /24 prefix is removed, all works as expected via their covering announcement (which 
does return via their primary provider, as we are generally a backup path for their larger block).

Any guidance the community can share as to how to go about trying to resolve I would greatly appreciate — this is the 
first time i’ve had to trace down a [seemingly random] reachability issue like this.  Connectivity to other services 
seem ok from what I can gather so far, even to some other akamai ranges.  from looking glass perspective it looks like 
the route is being accepted properly by our upstreams and other large providers like NTT, etc.  I did send an email to 
noc () akamai com <mailto:noc () akamai com> but not sure that is the appropriate way to reach out for assistance or 
not, since we nor our downstream customer are direct customers or peers of theirs.

Thanks,

Will McLendon
wimclend () gmail com <mailto:wimclend () gmail com>