On Mon, Aug 28, 2017 at 03:48:44PM +0000, someone wrote:
Damn you Google.. yup.
I am not sure it is fair to say "damn you Google", because accidents happen (be it through human error or software defects). All of us have entered commands at some point and subsequently https://media.giphy.com/media/bI5BEfwbdVPcA/giphy.gif Software defects are a real risk as well: Major BGP implementations have had bugs which caused NO_EXPORT functionality to malfunction, or bugs where random pieces of your configuration are ignored (for instance the part of the configuration which contains a prefix-filter). Allegedly the famous AS 7007 incident was also caused by a software defect. The key concept here is that, since we know accidents an happen, we ought to look out for each other and impose multiple layers of protection for our mutual benefit. Mechanisms that come to mind are maximum prefix limits and coarse as-path filters. At NANOG67 I described a few of these tricks https://www.youtube.com/watch?v=CSLpWBrHy10 / https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pd... To further reduce the risk surface, it may be good to ask your BGP vendor for specific behaviour applicable to EBGP sessions: ask for RFC 8212 support. RFC 8212 defines that when you configure an EBGP session without any routing policy associated with that neighbor, no routes will be exchanged until it is explicitly instructed to do so. Finally, it may be worthwhile exploring if we can standardize and promote maximum prefix limits applied on the the _sending_ side. This way you protect your neighbor (and the Internet at large) by self-destructing when you inadvertently announce more than what you'd expect to announce. BIRD has this functionality http://bird.network.cz/?get_doc&f=bird-3.html#proto-export-limit however I am not aware of other implementations. Feedback welcome! Kind regards, Job