Customer sending blackhole route with another provider's AS
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>
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>
Chris Adams wrote on 11/02/2020 17:30:
Just curious what others do... I always assumed AS path filtering to customer (and their downstream customers) AS was a standard best practice.
It is. Then again, there exists every exception to the rule you can think of. If the exception has not been seen yet, we have not looked hard enough. => I.e. it depends. Is my answer. BCP is to not accept direct customer routes 'another provider's AS in the path'. If you can reach an agreement with the customer. You can agree to a >standardized< exception for this single customer. <= Your dice to roll. You are the customers upstream in this case. AS-path rewriting on the customers side of the eBGP connection is an option. If they remove $otherProviders ASN from the path before (re-)announcing the black-hole routes to you. So $customerASN is seen as the source when you receive the announcements. Chriztoffer
participants (3)
-
Chris Adams -
Chriztoffer Hansen -
Matthew Petach