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 <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 >> > > -- ++ytti