I never found anything exciting about them … (and yes have wasted money on buying some of them a number of years ago) … they change outbound routing because that’s the only thing they can control (and perhaps the latest generation can influence your inbound routes) but I found they spit out fancy reports of all the things wrong that it fixed to save 1-2 ms on a bunch of routes….
> On Sep 1, 2017, at 8:59 AM, Mike Hammett <af...@ics-il.net> wrote: > > There are appliances that receive your traffic information through various > ways (traffic flows, port mirroring, etc.) and see who you're communicating > with remotely. They then do tests to that destination out each of your > upstream interfaces. They determine which upstream has the best performance > to that destination and then adjust your BGP settings (advertised and > received) such as prefix length, communities, local pref, MED, etc. to move > that traffic to that upstream. > > They do this to work around congestion, long AS paths that may be better than > short AS paths for whatever reason, etc. > > > > ----- > Mike Hammett > Intelligent Computing Solutions <http://www.ics-il.com/> > <https://www.facebook.com/ICSIL> > <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> > <https://www.linkedin.com/company/intelligent-computing-solutions> > <https://twitter.com/ICSIL> > Midwest Internet Exchange <http://www.midwest-ix.com/> > <https://www.facebook.com/mdwestix> > <https://www.linkedin.com/company/midwest-internet-exchange> > <https://twitter.com/mdwestix> > The Brothers WISP <http://www.thebrotherswisp.com/> > <https://www.facebook.com/thebrotherswisp> > > > <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> > From: "Steve Jones" <thatoneguyst...@gmail.com > <mailto:thatoneguyst...@gmail.com>> > To: af@afmug.com <mailto:af@afmug.com> > Sent: Thursday, August 31, 2017 10:45:03 PM > Subject: [AFMUG] Fwd: Re: BGP Optimizers (Was: Validating possible BGP MITM > attack) > > Please convert this to a guy who just got into bgp. What are rhey talking > about exactly? > ---------- Forwarded message ---------- > From: "Mike Hammett" <na...@ics-il.net <mailto:na...@ics-il.net>> > Date: Aug 31, 2017 9:06 PM > Subject: Re: BGP Optimizers (Was: Validating possible BGP MITM attack) > To: > Cc: <na...@nanog.org <mailto:na...@nanog.org>> > > Sorry for now taking up 1/4 of this thread.... > > > My words in the last message don't match what I was thinking, but I think you > all get the point. I'm sick, maybe I should be in bed instead of on NANOG. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com <http://www.ics-il.com/> > > Midwest-IX > http://www.midwest-ix.com <http://www.midwest-ix.com/> > > ----- Original Message ----- > > From: "Mike Hammett" <na...@ics-il.net <mailto:na...@ics-il.net>> > Cc: na...@nanog.org <mailto:na...@nanog.org> > Sent: Thursday, August 31, 2017 9:02:07 PM > Subject: Re: BGP Optimizers (Was: Validating possible BGP MITM attack) > > Actually, I do remember that one of them would optimize inbound routes, but > only billed on outbound usage (as it was content-focused). My in is over 8x > my out, so hrm... maybe I'm on to something. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com <http://www.ics-il.com/> > > Midwest-IX > http://www.midwest-ix.com <http://www.midwest-ix.com/> > > ----- Original Message ----- > > From: "Mike Hammett" <na...@ics-il.net <mailto:na...@ics-il.net>> > Cc: na...@nanog.org <mailto:na...@nanog.org> > Sent: Thursday, August 31, 2017 8:55:46 PM > Subject: Re: BGP Optimizers (Was: Validating possible BGP MITM attack) > > I would like to use a BGP optimizer, but I'm too poor. :-\ > > That said, I'm also an eyeball network, so modifications of my own > advertisements are what affects the desired traffic, not so much the outbound > routes. I know the BGP optimization industry is weighted towards content > networks. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com <http://www.ics-il.com/> > > Midwest-IX > http://www.midwest-ix.com <http://www.midwest-ix.com/> > > ----- Original Message ----- > > From: "Job Snijders" <j...@ntt.net <mailto:j...@ntt.net>> > To: na...@nanog.org <mailto:na...@nanog.org> > Sent: Thursday, August 31, 2017 3:06:49 PM > Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) > > Dear all, > > disclaimer: > > [ The following is targetted at the context where a BGP optimizer > generates BGP announcement that are ordinarily not seen in the > Default-Free Zone. The OP indicated they announce a /23, and were > unpleasantly surprised to see two unauthorized announcements for /24 > more-specifics pop up in their alerting system. No permission was > granted to create and announce these more-specifics. The AS_PATH > for those /24 announcements was entirely fabricated. Original thread > https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html > <https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html> ] > > On Thu, Aug 31, 2017 at 11:13:18AM -0700, Andy Litzinger wrote: > > Presuming it was a route optimizer and the issue was ongoing, what > > would be the suggested course of action? > > I strongly recommend to turn off those BGP optimizers, glue the ports > shut, burn the hardware, and salt the grounds on which the BGP optimizer > sales people walked. > > It is extremely irresponsible behavior to use software that generates > _fake_ BGP more-specifics for the purpose of traffic engineering. You > simply cannot expect that those more-specifics will never escape into > the global DFZ! Relying on NO_EXPORT is not sufficient: we regularly see > software bugs related to NO_EXPORT, and community-squashing > configuration mistakes happen all the time. > > Consider the following: if you leak your own internal more-specifics, at > least you are the legitimate destination. (You may suffer from > suboptimal routing, but it isn't guaranteed downtime.) However if you > generate fake more-specifics for prefixes belonging to OTHER > organisations, you essentially are complicit in BGP hijacking. If those > fake more-specifics accidentally leak into the DFZ, you are bringing > down the actual owner of such prefixes, and depriving people from access > to the Internet. Example case: > https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html > <https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html> > > > reach out to those 2 AS owners and see if they could stop it? > > Yes, absolutely! And if everyone of the affected parties of this > localized hijack leak (or should we say 'victims') reaches out to the > wrongdoers, they contribute peer pressure to rectify the situation. Just > make sure you assign blame to the correct party. :) > > > Or is it something I just have to live with as a traffic engineering > > solution they are using and mark the alerts as false positives? > > No, this is not something we should just accept. The Default-Free Zone > is a shared resource. Anyone using "BGP optimizers" is not only risking > their own online presence, but also everyone else's. Using a BGP > optimizer is essentially trading a degree of risk to society for the > purpose of saving a few bucks or milliseconds. It is basically saying: > "The optimizer helps me, but may hurt others, and I am fine with that". > > An analogy: We don't want transporters of radioactive material to cut > corners by using non-existant roads to bring the spent nuclear fuels > from A to B faster, nor do we want them to rely on non-robust shielding > that works "most of the time". > > We share the BGP DFZ environment, 'BGP optimizers' are downright > pollution contributors. > > Kind regards, > > Job > > ps. If you want to do BGP optimization: don't have the BGP optimizer > generate fake BGP announcements, but focus only on manipulating > non-transitive attributes (like LOCAL_PREF) on real announcements you > actually received from others. Or Perhaps BGP optimizers shouldn't even > talk BGP but rather push freshly generated TE-optimized routing-policy > to your edge boxes. Or perhaps the 'BGP optimizer' vendors should come > to IETF to figure out a safe way (maybe a new AFI/SAFI to manipulate > real announcements)... there are ways to do this, without risk to others! > > p.s. providing a publicly available BGP looking glasses will contribute > to proving your innocence in cases like these. Since in many cases the > AS_PATH is a complete fabrication, we need to manually check every AS in > the AS_PATH to see whether the AS carries the fake more-specific. A > public looking glass speeds up this fault-finding process. If you don't > want to host a webinterface yourself, please consider sending a BGP feed > to the Route Views Project or RIPE RIS, or for something queryable in a > real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/ > <http://lg.ring.nlnog.net/>
