Re: Long AS Path

f0002+na...@uah.edu>, James Bensley ><jwbens...@gmail.com>, "nanog@nanog.org" <nanog@nanog.org> > Subject: Re: Long AS Path > Message-ID: <5cc4ba8e-8fbf-4ad4-835d-2c06265ce...@beckman.org> > Content-Type: text/plain; charset="us-ascii"

RE: Long AS Path

Superstition has no basis in reality (i.e. black cat walks past DC door) Pro-Active is based on experience and knowledge (i.e. when disk space is 90% full for a regularly growing volume, we need to clean or add more before it hits 100%)   I mean this as a rhetorical question as we could talk

Re: Long AS Path

about long paths is has followed my suggestion: call the ASN operator and ask them why they do it, and report the results here. Until somebody does that, I don't see long path filtering as morally defensible :) -mel beckman > On Jun 26, 2017, at 8:09 AM, Michael Hare <michael.h...

RE: Long AS Path

: James Bensley <jwbens...@gmail.com>; nanog@nanog.org > Subject: Re: Long AS Path > > This could just be ignorance, but based on this thread, I'm not sure what > risk we would be managing, as DFZ router operators, by filtering those > paths. They seem silly, but harmless (similar

Re: Long AS Path

This could just be ignorance, but based on this thread, I'm not sure what risk we would be managing, as DFZ router operators, by filtering those paths. They seem silly, but harmless (similar to, for instance, painting a nyan cat on a graph by announcing prefixes at certain times). On Sun, Jun 25,

Re: Long AS Path

On 24 June 2017 at 13:10, Mel Beckman wrote: > James, > > By "experienced by someone else" I mean someone who is not one of your > customers. > > The better strategy, I think, is to not filter long paths unless you have a > reason to see their creating a problem. Otherwise

Re: Long AS Path

James, By "experienced by someone else" I mean someone who is not one of your customers. The better strategy, I think, is to not filter long paths unless you have a reason to see their creating a problem. Otherwise you're just operating on superstition, no? -mel via cell > On Jun 24, 2017,

Re: Long AS Path

On 23 Jun 2017 17:03, "Mel Beckman" wrote: James, The question is whether you would actually hear of any problems. Chances are that the problem would be experienced by somebody else, who has no idea that your filtering was causing it. -mel beckman Hi Mel, For us this the

Re: Long AS Path

55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 > > 55644 55644 55644 45271 > > > > I don't mean to single out 55644. It's just the first/most obnoxiously > > long as-path I found when looking for long ones. > > > > I seriously doubt provider/cus

Re: Long AS Path

James, The question is whether you would actually hear of any problems. Chances are that the problem would be experienced by somebody else, who has no idea that your filtering was causing it. -mel beckman > On Jun 23, 2017, at 4:33 AM, James Bensley wrote: > > On 21

Re: Long AS Path

On 21 Jun 2017 17:51, "Mel Beckman" wrote: Steinar, What reason is there to filter them? The main reason I know of is this: On 22 Jun 2017 17:17, "Steve Lalonde" wrote: Mel, There was a Cisco bug many years ago that caused lots of issues. Since then we

Re: Long AS Path

Mel, 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. http://blog.ipspace.net/2009/02/oversized-as-paths-cisco-ios-bug.html Regards Steve

Re: Long AS Path

g.org" <nanog@nanog.org> > Subject: Long AS Path > Message-ID: <e679487be750411a874b7376a7037aa9@EX-01.m21.local> > Content-Type: text/plain; charset="us-ascii" > > Dear All > > Just wondering if anyone else saw this yesterday afternoon ? > &

Re: Long AS Path

You don't have to wonder. You can call and ask them. -mel via cell > On Jun 22, 2017, at 5:47 AM, jim deleskie 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 >

Re: Long AS Path

44 55644 55644 > 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 > 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 > 55644 55644 55644 45271 > > I don't mean to single out 55644. It's just the first/most obnoxiously > long as-p

Re: Long AS Path

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. If I think back to when I learned to code or when making ACL's, we still used line number and practice would be to give ourselves lots of

Re: Long AS Path

5644 55644 55644 55644 55644 45271 I don't mean to single out 55644. It's just the first/most obnoxiously long as-path I found when looking for long ones. I seriously doubt provider/customer/customer-of-customer relationships ever get much deeper than a handful or so of ASNs...so if prepending a

Re: Long AS Path

> "Mel" == Mel Beckman writes: Mel> Why not ask the operator why they are pretending this path? Perhaps Mel> they have a good explanation that you haven't thought of. Blindly Mel> limiting otherwise legal path lengths is not a defensible practice, in Mel>

Re: Long AS Path

Why not ask the operator why they are pretending this path? Perhaps they have a good explanation that you haven't thought of. Blindly limiting otherwise legal path lengths is not a defensible practice, in my opinion. -mel beckman On Jun 21, 2017, at 1:36 PM, "sth...@nethelp.no"

Re: Long AS Path

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

Re: Long AS Path

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

Re: Long AS Path

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

Re: Long AS Path

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*

Re: Long AS Path

> > 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? > > Well, as I mentioned in my Net Neutrality filing to the FCC, a TTL of 30 > is OK for intra-planet routing, but

Re: Long AS Path

On 06/21/2017 12:56 AM, sth...@nethelp.no wrote: > 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? > Well, as I mentioned in my Net Neutrality filing to the FCC, a TTL

Re: Long AS Path

> 177.23.232.0/24*[BGP/170] 00:52:40, MED 0, localpref 105 ... > ... > I see no valid reason for such long AS paths. [ assuming it is not the microtik thing ] the /24 can not be sliced to steer inbound, so they're desperately trying to push it away with prepend. of course, their upstreams

Re: Long AS Path

> 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

Re: Long AS Path

On 2017-06-20 23:12, James Braunegg wrote: Dear All 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= AS_SEQ(2) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456

Re: Long AS Path

Yes, we had this kind of stuff in our logs: Jun 20 08:15:25 cr-co-01-pareq2-re0 rpd[9656]: %DAEMON-3: Prefix Send failed ! x:x:186.177.176.0/23 (label 19) bgp_rt_trace_too_big_message:1213 path attribute too big. Cannot build update. The AS path we have here is currently 12956 262206 262206

Long AS Path

Dear All 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= AS_SEQ(2) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456

Long AS-PATH / Blank Routing Report last weekend - update

Hi everyone, Apologies for the blank Routing Report last weekend. Unfortunately my script was tripped up by a very long AS-PATH. This one: *i193.105.15.0 202.249.2.1100120 0 2516 3257 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404 50404