Re: Google you have a problem.

On Thu, Jan 31, 2019 at 8:23 PM Mark Andrews wrote: > It was 9:29 AM Feb 1 AEST when I reported this so yes it was FRIDAY. > > :) it's very easy to rile you up.

Re: Google you have a problem.

It was 9:29 AM Feb 1 AEST when I reported this so yes it was FRIDAY. > On 1 Feb 2019, at 3:15 pm, Christopher Morrow wrote: > > > > On Thu, Jan 31, 2019 at 4:34 PM Mark Andrews wrote: > George Michaelson forwarded me Google’s notice which said there would be a > temporary outage along with a

Re: Google you have a problem.

On Thu, Jan 31, 2019 at 4:34 PM Mark Andrews wrote: > George Michaelson forwarded me Google’s notice which said there would be a > temporary outage along with a new home. Time to update the code to use the > new home. > > oh hey neato! :) Also, hey! this change didn't happen on a friday! w00t!

RE: RTBH no_export

> Alejandro Acosta wrote : > One more thing, RFC7999 has category Informational Point well taken. A good thing, IMHO. If I remember correctly, I once opposed this text; not because it was a bad idea (standardizing is sometimes a good idea) but because I found it imprecise enough that it was not

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

* br...@shout.net (Bryan Holloway) [Fri 01 Feb 2019, 02:00 CET]: What do IXes do (or can do) to enforce the completion of a renumbering? Renumbering is not complicated, but it's a lot of work to do it well. - Set a realistic time schedule well in advance. Keep in mind that some have change c

Re: RTBH no_export

One more thing, RFC7999 has category Informational El 31/1/19 a las 16:21, Theodore Baschak escribió: > >> On Jan 31, 2019, at 1:28 PM, Roel Parijs > > wrote: >> >> For our BGP customers the problem is more complex. Our BGP customers >> can send us the RTBH community,

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

What do IXes do (or can do) to enforce the completion of a renumbering? For example, Chicago Equinix announced a renumbering beginning of 2018, and while 99% of our peers have renumbered, we still have an albeit small handful who have not. (I will not name names.) That situation didn't get ne

Re: Google you have a problem.

George Michaelson forwarded me Google’s notice which said there would be a temporary outage along with a new home. Time to update the code to use the new home. > On 1 Feb 2019, at 11:31 am, Christopher Morrow > wrote: > > just in case.. .this appears to be working now. > -chris > > On Thu, Ja

Re: Google you have a problem.

just in case.. .this appears to be working now. -chris On Thu, Jan 31, 2019 at 2:30 PM Mark Andrews wrote: > [beetle:~/git/bind9] marka% fetch -v https://www.google.com/jsapi > looking up www.google.com > connecting to www.google.com:443 > SSL connection established using ECDHE-RSA-AES128-GCM-SH

Google you have a problem.

[beetle:~/git/bind9] marka% fetch -v https://www.google.com/jsapi looking up www.google.com connecting to www.google.com:443 SSL connection established using ECDHE-RSA-AES128-GCM-SHA256 Certificate subject: /C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com Certificate issuer: /C=U

Re: DNS Flag Day, Friday, Feb 1st, 2019

TIMEOUT is TIMEOUT. The whole point of flag day is that you can’t tell whether TIMEOUT is broken routing, packet loss or badly configured firewall. The DNS flag day site assumes the latter as does the old resolver code. We are moving to a state where resolvers assume the former. You get a repor

Re: DNS Flag Day, Friday, Feb 1st, 2019

> On 1 Feb 2019, at 3:32 am, James Stahr wrote: > > On 2019-01-31 08:15, Mark Andrews wrote: > >> We actually have a hard time finding zones where all the servers are >> broken enough to not work with servers that don’t fallback to plain >> DNS on timeout. We can find zones where some of the

RE: RTBH no_export

> Roel Parijs wrote: > To minimize the impact of DDoS, I have setup RTBH. For our own customers, we > can set the RTBH community ourselves towards our transit suppliers and > this works well. For our BGP customers the problem is more complex. Our BGP > customers can send us the RTBH community, an

Re: DNS Flag Day, Friday, Feb 1st, 2019

On 2019-01-31 08:32, James Stahr wrote: I think the advertised testing tool may be flawed as blocking TCP/53 is enough to receive a STOP from the dnsflagday web site. It's been my (possibly flawed) understanding that TCP/53 is an option for clients but primarily it is a mechanism for the *serve

Re: RTBH no_export

> On Jan 31, 2019, at 1:28 PM, Roel Parijs wrote: > > For our BGP customers the problem is more complex. Our BGP customers can send > us the RTBH community, and we will drop the traffic at our borders. Since > we're only running a small network, we don't have the capacity to deal with > large

Re: RTBH no_export

Roel Parijs wrote on 31/01/2019 19:28: What is your opinion on this ? you should implement a different community for upstream blackholing. This should be stripped at your upstream links and replaced with the provider's RTBH community. Your provider will then handle export restrictions as th

Re: RTBH no_export

> On 31 Jan 2019, at 20:28, Roel Parijs wrote: > > Hello NANOG, > > To minimize the impact of DDoS, I have setup RTBH. > For our own customers, we can set the RTBH community ourselves towards our > transit suppliers and this works well. > > For our BGP customers the problem is more complex.

RE: Effects of Cold Front on Internet Infrastructure - U.S. Midwest

Out here in Manitoba we use unheated/no-electricity OSP fiber patch panel pedestals in some locations, those work without issue down to the occasional -40. Note that that’s using all high-quality components. For Fletcher’s case, it’s also possible that: -there had been water intrusion in a s

RTBH no_export

Hello NANOG, To minimize the impact of DDoS, I have setup RTBH. For our own customers, we can set the RTBH community ourselves towards our transit suppliers and this works well. For our BGP customers the problem is more complex. Our BGP customers can send us the RTBH community, and we will drop t

Re: Latency between Dallas and west coast

Hi Nathan My current rtd from DA6 to SV1 is 38ms and from DRT Houston to LA1 is 30ms Jason > On Feb 1, 2019, at 04:40, Nathanael Catangay Cariaga > wrote: > > thank you all for the responses. i guess i would have to discuss this with > our provider. > >> On Fri, Feb 1, 2019, 1:39 AM Tom B

Re: BGP Experiment

> I suspect simple bugs are found by vendor, complex bugs are not > economic to find. the running internet is complex and has a horrifying number of special cases compounded by kiddies being clever. no one, independent of resource requirements, could build a lab to the scale needed to test. and

Re: Effects of Cold Front on Internet Infrastructure - U.S. Midwest

Fletcher, I don’t think that’s true. I find no specs on fiber dB loss being a function of ambient temperature. I do find fiber optic application data sheets for extreme temperature applications of -500F and +500F (spacecraft). You’d think if temperature affected fiber transmission characteristi

Re: Latency between Dallas and west coast

thank you all for the responses. i guess i would have to discuss this with our provider. On Fri, Feb 1, 2019, 1:39 AM Tom Beecher NYC to LA is in the high 60ms range, so no, 200ms from Dallas to US west > coast is not expected. > > > > > On Thu, Jan 31, 2019 at 12:14 PM Mark Tinka wrote: > >> >

Re: Latency between Dallas and west coast

NYC to LA is in the high 60ms range, so no, 200ms from Dallas to US west coast is not expected. On Thu, Jan 31, 2019 at 12:14 PM Mark Tinka wrote: > > > On 31/Jan/19 18:53, Mike Hammett wrote: > > It's 180 ms from Dallas to Djibouti, so no, that much latency to the west > coast of the US is n

Re: Latency between Dallas and west coast

On 31/Jan/19 18:53, Mike Hammett wrote: > It's 180 ms from Dallas to Djibouti, so no, that much latency to the > west coast of the US is not normal. Or from Gaborone to Frankfurt, which is some 184ms. Short of long re-route paths or congested, high packet loss links, I'd not expect the latency

Re: DNS Flag Day, Friday, Feb 1st, 2019

On Thu, Jan 31, 2019 at 10:33 AM James Stahr wrote: [snip] > So is the tool right in saying that TCP/53 is a absolute requirement of > ENDS0 support for "DNS Flag Day"? If so, do we expect a dramatic > increases in TCP/53 requests over UDP/53 queries? Or is the tool flawed [snip] Their test too

Re: DNS Flag Day, Friday, Feb 1st, 2019

On 31/Jan/19 18:32, James Stahr wrote: > > I think the advertised testing tool may be flawed as blocking TCP/53 > is enough to receive a STOP from the dnsflagday web site.  It's been > my (possibly flawed) understanding that TCP/53 is an option for > clients but primarily it is a mechanism for

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

> On Jan 30, 2019, at 17:32 , valdis.kletni...@vt.edu wrote: > > On Wed, 30 Jan 2019 23:55:40 +, "i3D.net - Martijn Schmidt" said: > >> Here: all networks that didn't already change their peering IP are not >> yet connected to the updated route-server. Some networks are not >> connected

Re: Latency between Dallas and west coast

It's 180 ms from Dallas to Djibouti, so no, that much latency to the west coast of the US is not normal. http://he.net/layer2/ - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Nathanael

Latency between Dallas and west coast

I would like to know if anyone here maintains average latency ranges between Dallas and Internet Exchanges at the west coast? Is it normal to have around 192ms to 200ms between the two points? Thanks in advance -nathan

Re: Effects of Cold Front on Internet Infrastructure - U.S. Midwest

Cold changes the transmission characteristics of fiber. At one point we were renting some old dark fiber from the local telephone company in northern Maine. When it would get below -15%-degree F the dB would get bad enough that the link using that fiber would stop working. The telephone company was

Re: DNS Flag Day, Friday, Feb 1st, 2019

> On Jan 30, 2019, at 17:40 , Jim Popovitch via NANOG wrote: > > On Wed, 2019-01-30 at 17:22 -0800, Matthew Petach wrote: >> Any chance this could wait until say the Tuesday >> *after* the Superbowl, when we aren't cutting an >> entire religion's worth of potential workers out of >> the wor

Re: DNS Flag Day, Friday, Feb 1st, 2019

On 2019-01-31 08:15, Mark Andrews wrote: We actually have a hard time finding zones where all the servers are broken enough to not work with servers that don’t fallback to plain DNS on timeout. We can find zones where some of the servers are like that, but there is usually one or more servers t

RE: Effects of Cold Front on Internet Infrastructure - U.S. Midwest

Excessive cold killed us once when the air exit vents froze shut. From: NANOG [mailto:nanog-bounces+david.hiers=cdk@nanog.org] On Behalf Of Naslund, Steve Sent: Wednesday, January 30, 2019 9:43 AM To: nanog@nanog.org Subject: RE: Effects of Cold Front on Internet Infrastructure - U.S. Midwes

Re: DNS Flag Day, Friday, Feb 1st, 2019

> On 1 Feb 2019, at 1:21 am, Stephen Satchell wrote: > > After reading through the thread, this reminds me of the Y2K flap, that > turned into a non-event. My checks of authoritative DNS servers for my > domains show no issues now. As did I, but if we didn’t try and give lots of notice peopl

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

On 31/Jan/19 16:22, Mike Hammett wrote: > A prefix is a prefix. A route is a prefix plus a next-hop. Your next > hop for your PNI is different than your IX. And for me, it doesn't matter as long as I am maintaining both my public link sand PNI's properly. If my peers are not, I'm happy to take

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

A prefix is a prefix. A route is a prefix plus a next-hop. Your next hop for your PNI is different than your IX. I don't believe I advocated running IX links hot. Financially, as an IX operator, I'd prefer that people ran all their bits over an IX and that all links were best kept below 10% ut

Re: DNS Flag Day, Friday, Feb 1st, 2019

> On 31 Jan 2019, at 10:59 pm, Matthew Petach wrote: > > > > On Thu, Jan 31, 2019, 01:27 Radu-Adrian Feurdean > > > On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote: > > You do realise that when the day was chosen it was just the date after > > which new versions of name servers by th

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

On 31/Jan/19 15:54, Mike Hammett wrote: > Not all routes are created equal. If you have a PNI and an IX > connection of equal capacity, obviously the IX connection will fill up > first given that there is more opportunity there. I think you meant to say not all "paths" are equal. Routes are rou

Re: DNS Flag Day, Friday, Feb 1st, 2019

After reading through the thread, this reminds me of the Y2K flap, that turned into a non-event. My checks of authoritative DNS servers for my domains show no issues now.

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

Not all routes are created equal. If you have a PNI and an IX connection of equal capacity, obviously the IX connection will fill up first given that there is more opportunity there. Also, there are more moving parts in an IX (and accompanying route servers), thus more to go wrong. - M

Re: DNS Flag Day, Friday, Feb 1st, 2019

On Thu, Jan 31, 2019 at 6:01 AM Matthew Petach wrote: > Google, Cloudflare, Quad9 all changing their codebase/response behaviour on a > Friday before a major sporting and advertising event? > Not sounding like a really great idea from this side of the table. If your DNS zone is hosted on Google

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

On 31/Jan/19 14:59, Mike Hammett wrote: > Do people not know how to use local pref and MED to prefer PNI over > route server? We don't particularly care how the routes are learned. Routes are routes. Our motivation for or against peering with an RS is granular policy control, and the level of

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

Do people not know how to use local pref and MED to prefer PNI over route server? - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Mark Tinka" To: nanog@nanog.org Sent: Thursday, Janua

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

On 31/Jan/19 12:04, Julien Goodwin wrote: > Even in exchanges that strongly encourage their use route collectors > were much less connected to than route servers, and few exchanges had > them in the first place. We, for example, connect to RS's more selectively. We are more liberal about RC's

Re: DNS Flag Day, Friday, Feb 1st, 2019

On Thu, Jan 31, 2019, 01:27 Radu-Adrian Feurdean < na...@radu-adrian.feurdean.net wrote: > > > On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote: > > You do realise that when the day was chosen it was just the date after > > which new versions of name servers by the original group of Open Source

Re: DNS Flag Day, Friday, Feb 1st, 2019

-- Mark Andrews > On 31 Jan 2019, at 20:25, Radu-Adrian Feurdean > wrote: > > > >> On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote: >> You do realise that when the day was chosen it was just the date after >> which new versions of name servers by the original group of Open Source >>

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

On 31/1/19 7:08 pm, Mark Tinka wrote: > I believe most exchange points maintain both route servers and route > collectors. > > Generally, most peers will connect to the RS, but not all. As you > mention, some may connect but not send any routes. > > However, I believe all peers will connect to th

Re: DNS Flag Day, Friday, Feb 1st, 2019

On Thu, Jan 31, 2019, at 03:24, Mark Andrews wrote: > You do realise that when the day was chosen it was just the date after > which new versions of name servers by the original group of Open Source > DNS developers would not have the work arounds incorporated? I think it's pretty safe to say

Re: BGP Experiment

Hey, > This is because you did your due diligence during the testing. > Do you have statistics on the probability of these "complex" bugs occurrence? No. I wish I had and I hope to make change on this. Try to translate how good investment test is, how many customer outages it has saved etc. I su

RE: BGP Experiment

> From: Saku Ytti > Sent: Friday, January 25, 2019 7:59 AM > > On Thu, 24 Jan 2019 at 18:43, wrote: > > > We fight with that all the time, > > I'd say that from the whole Design->Certify->Deploy->Verify->Monitor > service lifecycle time budget, the service certification testing is almost > hal

Re: Calling LinkedIn, Amazon and Akamai @ DE-CIX NY

On 31/Jan/19 09:51, Thomas King wrote: > Hi Ren et al., > > Thanks for pointing out that some peers do not use the route servers. This > group can be subdivided in a group of peers not sending any IP prefixes to > the route servers while maintaining a route server BGP session, and a group >