I posted the below on an academic list a week or two ago, figured I'd share it here. -Michael ==/== I'm supportive of Job's bogon ASN filtering in theory but make sure you understand the implications before typing commit. Unlike accepting RFC1918 space, I'd argue that rejecting private ASN is fundamentally a philosophically correct stance that can unfairly penalize those doing the correct thing. Specifically, we observed the deployment of this filter dropping a more specific peering route causing traffic to less preferred peering paths [or potentially, commodity]. Deploying this config could have financial implications for your organization. On 2016/06/08 I looked at this for AS3128 and came to these high level conclusions; * We saw over 400 upstream routes falling into this category, mostly with ASN in the 64512 - 65534 range. * Based on our flow bandwidth stats we chose to reach out to several origin ASN, two fairly well known [tw telecom, edgecast], as a courtesy. One of the Edgecast prefixes we were/are exchanging several hundred Mbps with. Both providers did address the issue once raised. Obviously without ongoing monitoring this or a similar problem could recur without us knowing. * Not present in Job's recommendation, none the less I added a community [3128:60003 for us] when I rejected a route so that I could do a poorman's audit/snapshot of rejected routes over time. A didn't execute a framework to review diffs of routes as they enter/leave this state, but I should [perhaps another use for openBMP]. > -----Original Message----- > From: MICE Discuss [mailto:[log in to unmask]] On Behalf Of > Andrew Hoyos > Sent: Sunday, August 07, 2016 2:11 PM > To: [log in to unmask] > Subject: [MICE-DISCUSS] route servers - bogon ASN filtering > > Hi all, > > We recently implemented bogon ASN filtering on all transit/peering edges (see > http://mailman.nanog.org/pipermail/nanog/2016-June/086078.html). > > There were a few participants we peer with via route servers that had bogon > ASN’s in path for various prefixes which we are now rejecting. > > I’d suggest that we look at adding similar filtering to the route-servers as well, > similar to RFC1918 filters already in place. > > Thoughts? > > — > Andrew Hoyos > Hoyos Consulting LLC > ofc: +1 608 616 9950 > [log in to unmask] > http://www.hoyosconsulting.com