Long AS Path

Fri Jun 23 15:03:39 UTC 2017

James, 

The question is whether you would actually hear of any problems. Chances are that the problem would be experienced by somebody else, who has no idea that your filtering was causing it. 

 -mel beckman

> On Jun 23, 2017, at 4:33 AM, James Bensley <jwbensley at gmail.com> wrote:
> 
> On 21 Jun 2017 17:51, "Mel Beckman" <mel at beckman.org> wrote:
> 
> Steinar,
> 
> What reason is there to filter them?
> 
> 
> The main reason I know of is this:
> 
> On 22 Jun 2017 17:17, "Steve Lalonde" <steve at enta.net> wrote:
> 
> Mel,
> 
> There was a Cisco bug many years ago that caused lots of issues. Since then
> we have limited max-as to 50 and it has not caused any reported issues yet.
> 
> Link that does not require a CCO login to view.
> http://blog.ipspace.net/2009/02/oversized-as-paths-cisco-ios-bug.html
> 
> 
> Like many providers we do still have legacy kit tucked away with shameful
> firmware versions running and also multiple vendors in play so I can't be
> sure we don't have devices still susceptible to such a bug in view of the
> DFZ.
> 
> On 21 Jun 2017 18:45, "Bob Evans" <bob at fiberinternetcenter.com> wrote:
> 
> My cut off is 6 ASNs - more than 6 and it never makes it to the FIB.
> 
> 
> So for the above reason we do have an AS_PATH limit but it is quite high
> like 63 or 120 ASNs (on mobile can't remember and right now). I don't want
> to get near a ^2 boundary like 255 or 128 but also don't want to drop
> prefixes if possible like a last resort fail-safe, so it's a very high
> number and will remove it at some point.
> 
> On 22 Jun 2017 14:49, "jim deleskie" <deleskie at gmail.com> wrote:
> 
> I see 5+ prepends as maybe not reason to have your "BGP driving license
> revoked" but if I can continue with the concept that you have your BGP
> learners permit.
> 
> 
> That (6) seems pretty low to me. Apart from a potential bug the other
> reason we thought of to block routes with a massive AS_PATH is that it
> could be a sign that the operator of a network doesn't know what their
> doing or doesn't have good processes in place (YMMV). If you have a path
> twice in BGP, once with a "giant" path length and once with a "normal"
> length the provider offering the "longer" path may have any manner of
> problems internally if they can't even manage their BGP routing policies
> appropriately.
> 
> I have seen genuine reasons for up to about 6 pre-prends and beyond so
> you're probably dropping a decent amount of routes. At the time I set our
> filter I think we were dropping one single route. No one has complained so
> its still in place.
> 
> Giant AS_PATHs can be debated in a similar fashion to AS numbers
> used/restricted by RFCs. We have AS number filters in place to block
> prefixes with a private ASN in the path, any transit provider should block
> such routes, again if they aren't it's a sign to me they're not doing a
> really great job. But it's very hard to know if you can drop those routes
> without affecting your customer base or that a suitable alternative exists.
> Great care must be taken when doing this.
> 
> Otherwise the following issue arises:
> 
> On 21 Jun 2017 19:13, "Saku Ytti" <saku at ytti.fi> wrote:
> 
> Hey,
> 
> Uou're saying, you drop long AS_PATH, to improve customer observed
> latency? Implication being, because you dropped the long AS_PATH
> prefixes, you're now selecting shorter AS_PATH prefixes to the FIB?
> 
> Absent of this policy, in which scenario would you have inserted the
> filtered longer AS_PATH prefix to the FIB? I assume only scenario
> where this happens is where there is larger aggregate route, which is
> lower latency than the more specific route with longer as_path.
> 
> 
> So we drop "giant" AS_PATH length routes and routes with certain ASNs in
> the path, but we are fairly certain we don't need them / our customers
> don't need them etc. Not because we believe we are getting better (lower
> latency routes) routes from somewhere else as Saku said above, we can't
> feasibly "test" and compare the performance of every route we receive or
> need/want, but to protect our infrastructure.
> 
> On 22 Jun 2017 16:54, "Jakob Heitz (jheitz)" <jheitz at cisco.com> wrote:
> 
> 23456 is AS_TRANS. Either your router does not support 4 byte AS or there
> is a bug at AS 12956 or AS 12956 is intentionally prepending 23456.
> 
> 
> This ties in with my point about specific ASN filtering. Its not a problem
> seeing 23456 in your table but again perhaps an indicator of a problem or
> someone using legacy kit. No problem with 23456 routes like AS_PATH length
> of up to say 50 but beyond that, I can't thing of a genuine reasons and
> could be a sign that along the path there may be stability issues for
> example. Again, too difficult to measure.
> 
> Depending on your customer base and requirements it can be safe to drop
> giant paths but care is needed, and if you do it, I think a number like 6
> is way too low.
> 
> Cheers,
> James.