I don't think the number of networks with disabled loop prevention is that small. For example, let's say you're a hosting provider who has 3 locations... no reason to do cold potato routing and you don't have dedicated links between sites, yet you still want ranges announced at DC A to be reachable from DC B and C. Kind Regards, Filip On 13 June 2019 5:56:16 pm GMT+02:00, Jon Lewis <jlewis@lewis.org> wrote:
I've used it in the distant past for TE purposes. Assuming you're poisoning one ASN via one transit it's not exactly rocket science to figure out if "it worked" or not. As Warren mentioned, sometimes your transits just don't provide all the knobs you need.
I suspect the number of networks that have intentionally disabled loop prevention is relatively small, and those more likely "end user'ish" networks that are less likely to be the target of as-path poisoning TE...says the guy who just disabled loop prevention on a bunch of routers. :)
On Thu, 13 Jun 2019, Jared Mauch wrote:
You also may not know who allows their own ASN inbound as well. It certainly is a mixed bag. I do consider poisoning at best horrible hygiene and at worst evidence of malicious intent.
Good filtering isn’t just prefix or AS path based it’s both.
Best filtering is pinning the prefix to a specific ASN.
Sent from my iCar
On Jun 13, 2019, at 11:24 AM, Job Snijders <job@instituut.net> wrote:
On Thu, Jun 13, 2019 at 11:18 Warren Kumari <warren@kumari.net> wrote: On Thu, Jun 13, 2019 at 9:59 AM Joe Abley <jabley@hopcount.ca> wrote: > > Hey Joe, > > On 12 Jun 2019, at 12:37, Joe Provo <nanog-post@rsuc.gweep.net> wrote: > > > On Wed, Jun 12, 2019 at 04:10:00PM +0000, David Guo via NANOG wrote: > >> Send abuse complaint to the upstreams > > > > ...and then name & shame publicly. AS-path forgery "for TE" was > > never a good idea. Sharing the affected prefix[es]/path[s] would > > be good. > > I realise lots of people dislike AS_PATH stuffing with other peoples' AS numbers and treat it as a form of hijacking. >
Actually, I've been meaning to start a thread on this for a while.
I have an anycast prefix - at one location I'm a customer of a customer of ISP_X & ISP_Y & ISP_Z. Because ISP_X prefers customer routes, any time a packet touches ISP_X, it goes to this location, even though it is (severely) suboptimal -- things would be better if ISP_X didn't accept this route in this location.
Now, the obvious answer of "well, just ask your provider in this location to not announce it to ISP_X. That's what communities / the telephone were invented for!" doesn't work for various (entirely non-technical) reasons...
Other than doing path-poisoning can anyone think of a way to accomplish what I want? (modulo the "just become a direct customer instead of being a customer of a customer" or "disable that site", or "convince the AS upstream of you to deploy communities / filters"). While icky, sometimes stuffing other people's AS in the path seems to be the only solution...
Given the prevalence of peerlock-style filters at the transit-free club, poisoning the path may result in a large outage for your prefix rather than a clever optimization. Poisoning paths is bad for all parties involved.
Kind regards,
Job
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.