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@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@cmadams.net>