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"

Re: Vendors spamming NANOG attendees

2017-06-21 Thread Anne P. Mitchell Esq.
> On 6/13/17 10:28 PM, Mel Beckman wrote: >> But as I said, harvesting emails is not illegal under can spam. But it is illegal under the laws of nearly every other technology-enabled developed country. And there are at least a few people on this list who are in those countries. And once

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

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

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: mailops https breakage

2017-06-21 Thread John Levine
In article you write: >> Fun fact about letsencrypt certs, they expire after a month or so. > >90 days Well, yes. That's why highly skilled and experienced administrators such as yourself set up the automatic renewal scripts at the same time they install the initial

Re: Google Cloud and IX - Traffic behavior

2017-06-21 Thread Alain Hebert
Thanks Tom, Yeah my test points VM's where all FreeBSD 10.3/11.0, so I decided to randomize some of them and added a CentOS on my Telia peer (10Gbps), and start getting normal performance from GCLD ( In the 500Mbps/500Mbps range ) PS: Even weirderer(tm) The *BSD VMs always

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*

Re: Google Cloud and IX - Traffic behavior

2017-06-21 Thread Tom Beecher
Just did a quick test from a personal VM, no throughput difference over direct peering, public IX, or transit. GCP might have a bottleneck in your case though, might be a good idea to ask them. Also, I'll have what Gordon is having. On Tue, Jun 20, 2017 at 8:49 PM, Gordon Cook

Re: Vendors spamming NANOG attendees

2017-06-21 Thread Tom Beecher
I was just thinking that as I caught up on the thread. I ignore unsolicited sales contacts as a general rule. If they persist to the point of annoyance, I'll kindly advise them that I'm not interested, and ask they cease. If they still persist, I'll drop out the 'I'll never do business with you,

Re: Vendors spamming NANOG attendees

2017-06-21 Thread Ge Dupin
I think so And I said it a coulpe of times already Ge > Le 21 juin 2017 à 15:25, Josh Luthman a écrit : > > Does anyone else feel this thread has generated more spam in their inbox > than the vendors? > > > Josh Luthman > Office: 937-552-2340 > Direct:

Re: Vendors spamming NANOG attendees

2017-06-21 Thread Josh Luthman
Does anyone else feel this thread has generated more spam in their inbox than the vendors? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Wed, Jun 21, 2017 at 1:45 AM, Jay Hennigan wrote: > On 6/13/17 10:28 PM, Mel Beckman

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

Re: PCIe adapters supporting long distance 10GB fiber?

2017-06-21 Thread Alain Hebert
Hi, Remember to check the power available to the XFP/SFP+. Its the most common issue related with achievable distance. We worked with optic.ca to figured out that type of issue with some extreme network gear and after a few "patches" to the XGm board, it's been stable since.

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

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

Re: mailops https breakage

2017-06-21 Thread Edwin Pers
Both. Either. Take your pick Ed Pers From: Seth Mattinen Sent: Tuesday, June 20, 8:06 PM Subject: Re: mailops https breakage To: nanog@nanog.org On 6/20/17 16:57, Keith Medcalf wrote: > How else would one maintain government control over free encryption certificates? So Let's Encrypt is run

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

Re: PCIe adapters supporting long distance 10GB fiber?

2017-06-21 Thread James Bensley
On 20 June 2017 at 17:10, Denys Fedoryshchenko wrote: > On 2017-06-20 18:59, Hunter Fuller wrote: >> >> On Tue, Jun 20, 2017 at 10:29 AM Chris Adams wrote: >> >>> For Linux at least, the standard driver includes a load-time option to >>> disable vendor check.