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 <jle...@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 <j...@instituut.net> wrote: >> >> On Thu, Jun 13, 2019 at 11:18 Warren Kumari <war...@kumari.net> >wrote: >> On Thu, Jun 13, 2019 at 9:59 AM Joe Abley <jab...@hopcount.ca> >wrote: >> > >> > Hey Joe, >> > >> > On 12 Jun 2019, at 12:37, Joe Provo ><nanog-p...@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.
