Print

Print


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