Long AS Path
jwbensley at gmail.com
Fri Jun 23 11:32:18 CST 2017
On 21 Jun 2017 17:51, "Mel Beckman" <mel at beckman.org> wrote:
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:
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.
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
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
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
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:
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.
More information about the NANOG