Re: Long AS Path

2017-06-27 Thread Jakob Heitz (jheitz)
AS 65000 will drop it, thinking it were looping back. BTW, this is different from a confederation member AS. Thanks, Jakob. > Date: Mon, 26 Jun 2017 16:27:39 + > From: Mel Beckman > To: Michael Hare > Cc: Hunter Fuller , James Bensley >, "nanog@nanog.org" &g

RE: Long AS Path

2017-06-26 Thread Jerry Cloe
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

2017-06-26 Thread Mel Beckman
ilto:nanog-boun...@nanog.org] On Behalf Of Hunter >> Fuller >> Sent: Monday, June 26, 2017 9:40 AM >> To: James Bensley ; nanog@nanog.org >> Subject: Re: Long AS Path >> >> This could just be ignorance, but based on this thread, I'm not sure what >> risk

RE: Long AS Path

2017-06-26 Thread Michael Hare
9:40 AM > To: James Bensley ; 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 to,

Re: Long AS Path

2017-06-26 Thread Hunter Fuller
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

2017-06-25 Thread James Bensley
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 you're just operating

Re: Long AS Path

2017-06-24 Thread Mel Beckman
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, a

Re: Long AS Path

2017-06-24 Thread James Bensley
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 answer is almost de

Re: Long AS Path

2017-06-23 Thread Ryan L
I didn't see anyone answer (sorry if I missed it and this is redundant) ... In the path selection algorithm, local preference is processed before AS-PATH. Within your provider's AS, your prefixes could be a default localpref of 100, and learned prefixes from their peers 85, for example. In this c

Re: Long AS Path

2017-06-23 Thread Mel Beckman
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 Jun 2017 17:51, "Mel B

Re: Long AS Path

2017-06-23 Thread James Bensley
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 have limited max-as to 50 and it has

Re: Long AS Path

2017-06-22 Thread Steve Lalonde
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 Lalon

Re: Long AS Path

2017-06-22 Thread Jakob Heitz (jheitz)
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. Thanks, Jakob. > > Date: Tue, 20 Jun 2017 23:12:45 + > From: James Braunegg > To: "nanog@nanog.org" > Subject: Long AS Path > Message-ID: > Conte

Re: Long AS Path

2017-06-22 Thread Mel Beckman
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 > learners permit. > If I t

Re: Long AS Path

2017-06-22 Thread Stephen Satchell
On 06/22/2017 04:27 AM, Jon Lewis wrote: > > You do have to wonder, what was the thought process that resulted in 35 > being the right number of prepends "accomplish" whatever TE they were > shooting for? > > AS path: 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 > 55644 55644

Re: Long AS Path

2017-06-22 Thread jim deleskie
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

2017-06-22 Thread Jon Lewis
On Wed, 21 Jun 2017, Saku Ytti wrote: 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

Re: Long AS Path

2017-06-21 Thread Pierfrancesco Caci
> "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> my opinion. Mel

Re: Long AS Path

2017-06-21 Thread Mel Beckman
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" wrote: >>> I

Re: Long AS Path

2017-06-21 Thread Tom Beecher
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

Re: Long AS Path

2017-06-21 Thread Saku Ytti
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

Re: Long AS Path

2017-06-21 Thread Bob Evans
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

2017-06-21 Thread Mel Beckman
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* fi

Re: Long AS Path

2017-06-21 Thread sthaug
> > 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 w

Re: Long AS Path

2017-06-21 Thread Stephen Satchell
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 of

Re: Long AS Path

2017-06-21 Thread Randy Bush
> 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 al

Re: Long AS Path

2017-06-21 Thread sthaug
> 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 2345

Re: Long AS Path

2017-06-20 Thread Laszlo Hanyecz
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 2345

Re: Long AS Path

2017-06-20 Thread Olivier Benghozi
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 26