Dear Ryan, I have come to believe this is a Noction IRP specific issue. On Sat, Aug 01, 2020 at 01:29:59PM -0700, Ryan Hamel wrote:
I disagree on the fact that it is not fair to the BGP implementation ecosystem, to enforce a single piece of software to activate the no-export community by default
I am not exaggerating when I say that *ONLY* the name of this software is mentioned when incidents like this happen. Other route manipulation tools either use different (safer) technologies and/or mark routes with NO_EXPORT. Every few weeks I am in phone calls with new people who happened originated hijacks which existed for traffic engineering purposes and without fail it is always the same software from the same company that originated the rogue routes. It seems more efficient if the software were to ship with improved default settings than me explaining the problem ad-nauseum to every new engineer after they unsuspectingly stepped into this trap. Not extremely dangerous by default, is it really too much to ask?
Also, wasn't it you that said Cisco routers had a bug in ignoring NO_EXPORT? Would you go on a rant with Cisco, even if Noction add that enabled checkbox by default?
Cisco and Noction are separate companies, regardless of what Noction does, the Cisco implementations are expected to confirm to their own documentation and the BGP-4 specifications. 1/ Without setting NO_EXPORT by a default, route manipulation software by default is very dangerous. 2/ Even if NO_EXPORT is set, software defects happen from time to time and the existence of fake more-specific routes in a specific routing domain can have dire consequences (as has been demonstrated time after time). Not setting NO_EXPORT as a default is setting your customers up for failure. If your car's seatbelt accidentally breaks, it wouldn't logically follow to also remove the airbags.
Why are you not on your soap box about BIRD, FRrouting, OpenBGPd, Cisco, Juniper, etc... about how they can possibly allow every day screw ups to happen
It is interesting you mention these names, as all of them in recent years went through a process to revisit some unsafe default behavior and address it. These companies have far larger userbases, so if they can do it, anyone can do it! For the longest time many BGP implementations - BY DEFAULT - would propagate any and all routes from EBGP peers to all other IGBP and EBGP peers. The community identified this to be a root cause for many incidents, and eventually came up with a change to the BGP-4 specification which codifies that the default should be safe instead of dangerous. https://tools.ietf.org/html/rfc8212 - BIRD introduced support for RFC 8212 in BIRD 2 and higher - FRRouting changed the defaults in 7.4 and higher - Cisco IOS XR had RFC 8212 right from the start - OpenBGPD changed its default behavior in version 6.4 - Juniper is still working on this, in the meantime a SLAX script can be used to emulate RFC 8212 behavior: https://github.com/packetsource/rfc8212-junos It is well understood how default settings strongly shape the success or failure of deployments. This is no different. Kind regards, Job