Long AS Path

Tue Jun 27 13:26:18 UTC 2017

The reason that a private ASN in the public routing table is an error is that the AS Path is used to prevent loops. You may have private AS 65000 in your organization and I may have another private AS 65000 in my organization. If my ASN 65000 is in the AS path of a route sent to you, then your AS 65000 will drop it, thinking it were looping back.

BTW, this is different from a confederation member AS.

Thanks,
Jakob.

> Date: Mon, 26 Jun 2017 16:27:39 +0000
> From: Mel Beckman <mel at beckman.org>
> To: Michael Hare <michael.hare at wisc.edu>
> Cc: Hunter Fuller <hf0002+nanog at uah.edu>, James Bensley
>    <jwbensley at gmail.com>,  "nanog at nanog.org" <nanog at nanog.org>
> Subject: Re: Long AS Path
> Message-ID: <5CC4BA8E-8FBF-4AD4-835D-2C06265CE502 at beckman.org>
> Content-Type: text/plain; charset="us-ascii"
> 
> Michael,
> 
> Filtering private ASNs is actually part of the standard. It's intrinsic in the term "private ASN". A private ASN in the public routing table is a clear error, so filtering them is reasonable. Long AS paths are not a clear error.'
> 
> I'm surprised nobody here who complains about long paths is has followed my suggestion: call the ASN operator and ask them why they do it, and report the results here. 
> 
> Until somebody does that, I don't see long path filtering as morally defensible :)
> 
> -mel beckman
> 
>> On Jun 26, 2017, at 8:09 AM, Michael Hare <michael.hare at wisc.edu> wrote:
>> 
>> Couldn't one make the same argument with respect to filtering private ASNs from the global table?  Unlike filtering of RFC1918 and the like a private ASN in the path isn't likely to leak RFC1918 like traffic, yet I believe several major ISPs have done just that.  This topic was discussed ~1 year ago on NANOG.
>> 
>> I do filter private ASNs but have not yet filtered long AS paths.  Before I did it I had to contact a major CDN because I would have dropped their route, in the end costing me money (choosing transit vs peering).