Customer sending blackhole route with another provider's AS

Tue Feb 11 18:00:46 UTC 2020

Anyone that is using blackhole communities should have enough Clue-fu
to adjust announcements along each pathway to have the correct sequence
of ASNs.  Passing a route with a different upstream's ASN as the origin,
instead
of their own, is just *asking* for "blackhole leakage", where they
inadvertently
become a conduit for blackhole prefixes from provider A getting
redistributed to
you as provider B.

Push back on them, and indicate they must pass properly-crafted AS-PATH
attributes to you in order to be accepted.  If they don't know how to do
that,
a) they shouldn't be mucking with blackhole communities, and b) they should
consider hiring Clue-fu to bring their network policies up to snuff.   ^_^;

Matt

On Tue, Feb 11, 2020 at 8:31 AM Chris Adams <cma at cmadams.net> wrote:

> One of our multihomed customers is set up with some type of security
> system from another upstream that can announce blackhole routes for
> targeted IPs.  They have a BGP policy to take those blackhole routes and
> add our blackhole community string so that we can drop the traffic (and
> we in turn translate to our transit providers).  All good.
>
> However, it doesn't work, because the route the customer sends to us has
> the other upstream's AS as the source, and we have AS path filtering on
> our customer links.
>
> Is this a typical setup?  Should we just accept the route(s) with
> another provider's AS in the path?  That seems... unusual.  Our internal
> blackhole system uses a private AS (so it can be stripped off before
> sending to anyone else).
>
> Just curious what others do... I always assumed AS path filtering to
> customer (and their downstream customers) AS was a standard best
> practice.
>
> --
> Chris Adams <cma at cmadams.net>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200211/c7c3caf2/attachment.html>