[195124] in North American Network Operators' Group
Re: Long AS Path
daemon@ATHENA.MIT.EDU (Mel Beckman)
Fri Jun 23 11:03:50 2017
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: James Bensley <jwbensley@gmail.com>
Date: Fri, 23 Jun 2017 15:03:39 +0000
In-Reply-To: <CAAWx_pWCVkKytxt23+0OqNxBJ0tbdKetD3zz36wrUFmR82Sk7A@mail.gmail.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
James,=20
The question is whether you would actually hear of any problems. Chances ar=
e that the problem would be experienced by somebody else, who has no idea t=
hat your filtering was causing it.=20
-mel beckman
> On Jun 23, 2017, at 4:33 AM, James Bensley <jwbensley@gmail.com> wrote:
>=20
> On 21 Jun 2017 17:51, "Mel Beckman" <mel@beckman.org> wrote:
>=20
> Steinar,
>=20
> What reason is there to filter them?
>=20
>=20
> The main reason I know of is this:
>=20
> On 22 Jun 2017 17:17, "Steve Lalonde" <steve@enta.net> wrote:
>=20
> Mel,
>=20
> There was a Cisco bug many years ago that caused lots of issues. Since th=
en
> we have limited max-as to 50 and it has not caused any reported issues ye=
t.
>=20
> Link that does not require a CCO login to view.
> http://blog.ipspace.net/2009/02/oversized-as-paths-cisco-ios-bug.html
>=20
>=20
> 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.
>=20
> On 21 Jun 2017 18:45, "Bob Evans" <bob@fiberinternetcenter.com> wrote:
>=20
> My cut off is 6 ASNs - more than 6 and it never makes it to the FIB.
>=20
>=20
> 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 wan=
t
> 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.
>=20
> On 22 Jun 2017 14:49, "jim deleskie" <deleskie@gmail.com> wrote:
>=20
> 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.
>=20
>=20
> 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.
>=20
> 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 s=
o
> its still in place.
>=20
> 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 bloc=
k
> 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 exist=
s.
> Great care must be taken when doing this.
>=20
> Otherwise the following issue arises:
>=20
> On 21 Jun 2017 19:13, "Saku Ytti" <saku@ytti.fi> wrote:
>=20
> Hey,
>=20
> 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?
>=20
> 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.
>=20
>=20
> 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.
>=20
> On 22 Jun 2017 16:54, "Jakob Heitz (jheitz)" <jheitz@cisco.com> wrote:
>=20
> 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.
>=20
>=20
> This ties in with my point about specific ASN filtering. Its not a proble=
m
> 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 lengt=
h
> 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.
>=20
> 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.
>=20
> Cheers,
> James.
