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
|