Usually when someone starts griping about RTT between destinations more
than about 6 time zones apart, I start to talk to them about refraction
indicies, platform specific switching delay differences, stuff like that.
Normally I can chase them away or put them to sleep well before getting to
'I can break a lot of things, but physics is not one of them.'
A longer ASN path is not an automatic signifier of a longer latency path.
It can just as easily be a lower latency path that happens to traverse a
expensive link that AS doesn't like to use normally, but wants a backup. Or
maybe they have congestion inside their AS from that way in and want to
influence traffic away from it. Or maybe they just read that chapter and
thought it was a cool setting without knowing what it did.
On Wed, Jun 21, 2017 at 12:42 PM, Bob Evans <b...@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, "sth...@nethelp.no" <sth...@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, sth...@nethelp.no
> >
>
>
>
