Long AS Path

Saku Ytti saku at ytti.fi
Wed Jun 21 17:11:37 CST 2017


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. Do you
have data how many of such paths exist and what is the latency delta?
I'm extremely skeptical that long AS_PATH rejection has any measurable
impact on aggregate path latencies.



On 21 June 2017 at 19:42, Bob Evans <bob at fiberinternetcenter.com> wrote:
> My cut off is 6 ASNs - more than 6 and it never makes it to the FIB.
>
> However, for this to be viable with plenty of unique prefixes to maintain
> a large table, we have lots and lots of direct big and small peers and
> much more than the usual amount of transit neighbors in our network.
> Silicon Valley companies are very demanding for the fasted path with the
> lowest number of router hops. ASN hops almost always lead to more router
> hops in the trace. We have customers that call us if everything is fine
> and they want to shave off milliseconds to favorite destinations. Picky,
> picky, picky.
>
> I am wondering how may other networks get requests (more like demands)
> from customers wanting you to speed packets up to and from a specific
> office in India or China. Customers knowing nothing about their office ISP
> overseas. BTW, it's almost always they have the cheapest congested shared
> office connection in the building overseas (especially in India). So they
> can't do anything there except "pretend" about the bandwidth available.
> About all they know is the IP address of the VPN and they were told they
> have a full gig connection. Sure they have a gig port, but it's on a
> switch together with 10 building neighbors that all also have a gig port
> on a circuit to the building that no one can maintain a gig for more than
> 3 ms. Go ahead try and fix that latency packet dropping issue with a
> firewall on both ends with SPI turned on in both directions.  It's your
> fault if you cant make it better. After all their VPN from London to
> Bangalore works fine. And the ones in China all work fine to and from
> Australia.
>
> Anyways, I always wondered is it just me or do others get these kind of
> requests?
>
> Thank You
> Bob Evans
> CTO
>
>
>
>
>> Steinar,
>>
>> What reason is there to filter them? They are not a significant fraction
>> of BGP paths. They cause no harm. It's just your sense of tidiness.
>>
>> You might consider contacting one of the operators to see if they do have
>> a good reason you haven't considered. But absent a good reason *to* filter
>> them, I would let BGP mechanics work as intended.
>>
>>  -mel beckman
>>
>> On Jun 21, 2017, at 12:57 AM, "sthaug at nethelp.no" <sthaug at nethelp.no>
>> wrote:
>>
>>>> Just wondering if anyone else saw this yesterday afternoon ?
>>>>
>>>> Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH=3D
>>>> AS_SEQ(2=
>>>> ) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456
>>>> 234=
>>>> 56 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456
>>>> 23456 =
>>>> 23456 23456 23456 23456 23456 ... attribute length (567) More than
>>>> configur=
>>>> ed MAXAS-LIMIT
>>>
>>> There are quite a few examples of people using stupidly long AS paths.
>>> For instance
>>>
>>> 177.23.232.0/24    *[BGP/170] 00:52:40, MED 0, localpref 105
>>>                      AS path: 6939 16735 28163 28163 28163 28163 28163
>>> 28163 28163 28163 28163 28163 28163 28163 28163
>>> 28163 28163 28163 262401 262401 262401 262401
>>> 262401 262401 262401 262401 262401 262401 262401
>>> 262401 262401 262401 262401 262401 262949 52938
>>> 52938 52938 52938 52938 52938 52938 52938 52938
>>> 52938 52938 I
>>>
>>> I currently have 27 prefixes in my Internet routing table with 40 or
>>> more ASes in the AS path (show route aspath-regex ".{40,}").
>>>
>>> I see no valid reason for such long AS paths. Time to update filters
>>> here. I'm tempted to set the cutoff at 30 - can anybody see a good
>>> reason to permit longer AS paths?
>>>
>>> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
>>
>
>



-- 
  ++ytti


More information about the NANOG mailing list