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

Thu Jan 9 19:08:56 UTC 2020

It would likely be helpful if you indicate which /24 and which supernet
you're talking about so people can perhaps comment if it's something around
IRR, ROAs, what their views are of the block(s), etc.

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal

On Thu, Jan 9, 2020 at 10:55 AM William McLendon <wimclend at gmail.com> wrote:

> 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 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 at 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 at gmail.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200109/44bdcc7f/attachment.html>