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:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Andrew Hoyos Sent: Sunday, August 07, 2016 2:11 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET 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 andrew@hoyosconsulting.com http://www.hoyosconsulting.com