From md at bts.sk Thu Dec 1 11:14:24 2016 From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=) Date: Thu, 1 Dec 2016 12:14:24 +0100 Subject: 10G switch drops traffic for a split second In-Reply-To: References: Message-ID: <20161201111424.GA41098@bts.sk> On Wed, Nov 30, 2016 at 11:58:06AM -0500, Lee wrote: > On 11/30/16, Mikael Abrahamsson wrote: > > If your switch is the typical small-buffered-switch that has become more > > and more common the past few years, then the entire switch might have > > buffer to keep packets for 0.1ms or less. So if someone says "flow control > > off" for 0.1ms, depending on the implementation, you might then start > > seeing packet drops on all ports until that device turns flow control > > back on. > > I always disabled flow control on the theory that VoIP & flow control > are incompatible. > just out of curiosity - anyone have it enabled? if so, why? Generally speaking, allowing any ethernet switch to *send* PAUSE frames is very bad idea, causing external head-of-line blocking and congestion spreading. OTOH, a decent use-case of flow control is for subrate services. For example, 622 Mbps microwave link with gigabit ethernet interfaces ultimately needs to use flow control to properly inform the connected equipment that this is only "622M ethernet" link and not a gigabit one. M. From johnl at iecc.com Thu Dec 1 17:34:26 2016 From: johnl at iecc.com (John Levine) Date: 1 Dec 2016 17:34:26 -0000 Subject: Avalanche botnet takedown Message-ID: <20161201173426.2861.qmail@ary.lan> Avalanche is a large nasty botnet, which was just disabled by a large coordinated action by industry and law enforcement in multiple countries. It was a lot of work, involving among other things disabling or sinkholing 800,000 domain names used to control it. More info here: https://www.europol.europa.eu/newsroom/news/%E2%80%98avalanche%E2%80%99-network-dismantled-in-international-cyber-operation http://blog.shadowserver.org/2016/12/01/avalanche/ As both items point out, if your users are infected with Avalance, they're still infected, but now if you disinfect them, they won't get reinfected. At least not with that particular flavor of malware. R's, John From anthony.kasza at gmail.com Thu Dec 1 19:02:50 2016 From: anthony.kasza at gmail.com (anthony kasza) Date: Thu, 1 Dec 2016 12:02:50 -0700 Subject: Avalanche botnet takedown In-Reply-To: <20161201173426.2861.qmail@ary.lan> References: <20161201173426.2861.qmail@ary.lan> Message-ID: >From my understanding Avalanche wasn't a single botnet but was high availability infrastructure used by multiple different families/operators. -AK On Dec 1, 2016 10:37 AM, "John Levine" wrote: > Avalanche is a large nasty botnet, which was just disabled by a large > coordinated action by industry and law enforcement in multiple > countries. It was a lot of work, involving among other things > disabling or sinkholing 800,000 domain names used to control it. > > More info here: > > https://www.europol.europa.eu/newsroom/news/%E2%80% > 98avalanche%E2%80%99-network-dismantled-in-international-cyber-operation > > http://blog.shadowserver.org/2016/12/01/avalanche/ > > As both items point out, if your users are infected with Avalance, > they're still infected, but now if you disinfect them, they won't get > reinfected. At least not with that particular flavor of malware. > > R's, > John > > > From rfg at tristatelogic.com Thu Dec 1 20:38:03 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 01 Dec 2016 12:38:03 -0800 Subject: Avalanche botnet takedown In-Reply-To: <20161201173426.2861.qmail@ary.lan> Message-ID: <32485.1480624683@segfault.tristatelogic.com> In message <20161201173426.2861.qmail at ary.lan>, "John Levine" wrote: >More info here: > >https://www.europol.europa.eu/newsroom/news/%E2%80%98avalanche%E2%80%99-network-dismantled-in-international-cyber-operation I'm always happy when even a small handful of miscreants are captured and taken off the Internet, but... The press release itself says that this botnet had been running since 2009. So, you know, are we supposed to break out the champaign and start celebrating because it "only" took LE *seven years* to take down this one botnet and capture a grand total of five cybercriminals? Like I say, I'm happy that this one botnet was killed, but to my way of thinking, the fact that it took seven years to do so is a testament *not* to the spectacular 21st century capabilities of modern law enforcement, but rather to the ever widening gap between the time scales of law enforcment processes, typically measured in months or years, and the time scales of malicious packets flying around the Internet, usually measured in miliseconds. The Internet, viewed as an organism, quite clearly has, at present, numerous autoimmune diseases. It is attacking itself. And its immune system, such as it is, clearly ain't working. There's going to come a day of reckoning when it will no longer be possible to paper over this sad and self-evident fact. (And no, I'm *not* talking about the fabled "Digital Pearl Harbor". I'm talking instead about the Internet equivalent of the meteor that wiped out the dinosaurs.) Regards, rfg P.S. WTF is "double fast flux[tm]"? Is that anything like "double secret probation" from Animal House? P.P.S. I love this part of the press release, because it is so telling: "The successful takedown of this server infrastructure was supported by ... Registrar of Last Resort, ICANN..." Hahahahaha! Yea. Translation, for those of you who do not speak diplomacy-speak: "It isn't hardly just you unofficial anti-spammers and anti-cybercrime volunteers and private security companies that can't manage to get many domain registrars and somtimes even domain registries to lift a finger to help. Even some of us international law enforcement guys, who have badges and everything, were also told to go pound sand by several of the world's worst and most unhelpful registrars and registries. In fact, they were soooooooo colossally unhelpful that in the end, we finally had to go and plead our case all the way up to ICANN, just in order to get anything done." From fergdawgster at mykolab.com Thu Dec 1 20:43:16 2016 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Thu, 1 Dec 2016 12:43:16 -0800 Subject: Avalanche botnet takedown In-Reply-To: <32485.1480624683@segfault.tristatelogic.com> References: <32485.1480624683@segfault.tristatelogic.com> Message-ID: > P.S. WTF is "double fast flux[tm]?? Double fast-flux is when not only the TTL is set very low on the A record(s), bit also on the NS: https://en.wikipedia.org/wiki/Fast_flux - ferg > On Dec 1, 2016, at 12:38 PM, Ronald F. Guilmette wrote: > > > In message <20161201173426.2861.qmail at ary.lan>, > "John Levine" wrote: > >> More info here: >> >> https://www.europol.europa.eu/newsroom/news/%E2%80%98avalanche%E2%80%99-network-dismantled-in-international-cyber-operation > > I'm always happy when even a small handful of miscreants are captured > and taken off the Internet, but... > > The press release itself says that this botnet had been running since > 2009. So, you know, are we supposed to break out the champaign and > start celebrating because it "only" took LE *seven years* to take down > this one botnet and capture a grand total of five cybercriminals? > > Like I say, I'm happy that this one botnet was killed, but to my way > of thinking, the fact that it took seven years to do so is a testament > *not* to the spectacular 21st century capabilities of modern law > enforcement, but rather to the ever widening gap between the time > scales of law enforcment processes, typically measured in months or > years, and the time scales of malicious packets flying around the > Internet, usually measured in miliseconds. > > The Internet, viewed as an organism, quite clearly has, at present, > numerous autoimmune diseases. It is attacking itself. And its immune > system, such as it is, clearly ain't working. There's going to come > a day of reckoning when it will no longer be possible to paper over > this sad and self-evident fact. (And no, I'm *not* talking about > the fabled "Digital Pearl Harbor". I'm talking instead about the > Internet equivalent of the meteor that wiped out the dinosaurs.) > > > Regards, > rfg > > > P.S. WTF is "double fast flux[tm]"? Is that anything like "double secret > probation" from Animal House? > > P.P.S. I love this part of the press release, because it is so telling: > > "The successful takedown of this server infrastructure was supported > by ... Registrar of Last Resort, ICANN..." > > Hahahahaha! Yea. Translation, for those of you who do not speak > diplomacy-speak: "It isn't hardly just you unofficial anti-spammers and > anti-cybercrime volunteers and private security companies that can't > manage to get many domain registrars and somtimes even domain registries > to lift a finger to help. Even some of us international law enforcement > guys, who have badges and everything, were also told to go pound sand by > several of the world's worst and most unhelpful registrars and registries. > In fact, they were soooooooo colossally unhelpful that in the end, we > finally had to go and plead our case all the way up to ICANN, just in > order to get anything done." ? Paul Ferguson ICEBRG.io Seattle, Washington, USA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 236 bytes Desc: Message signed with OpenPGP using GPGMail URL: From surfer at mauigateway.com Thu Dec 1 20:45:27 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 1 Dec 2016 12:45:27 -0800 Subject: Avalanche botnet takedown Message-ID: <20161201124527.9BE453FD@m0087798.ppops.net> --- rfg at tristatelogic.com wrote: From: "Ronald F. Guilmette" The Internet, viewed as an organism, quite clearly has, at present, numerous autoimmune diseases. It is attacking itself. And its immune system, such as it is, clearly ain't working. There's going to come a day of reckoning when it will no longer be possible to paper over this sad and self-evident fact. (And no, I'm *not* talking about the fabled "Digital Pearl Harbor". I'm talking instead about the Internet equivalent of the meteor that wiped out the dinosaurs.) --------------------------------------------------- What is your suggestion to keep the sky from falling? scott From rsk at gsp.org Thu Dec 1 20:56:47 2016 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 1 Dec 2016 15:56:47 -0500 Subject: Avalanche botnet takedown In-Reply-To: <20161201173426.2861.qmail@ary.lan> References: <20161201173426.2861.qmail@ary.lan> Message-ID: <20161201205647.GA8911@gsp.org> On Thu, Dec 01, 2016 at 05:34:26PM -0000, John Levine wrote: > [...] 800,000 domain names used to control it. 1. Which is why abusers are registrars' best customers and why (some) registrars work so very hard to support and shield them. 2. As an aside, I've been doing a little research project for a few years, focused on domains. I've become convinced that *at least* 99% of domains belong to abusers: spammers, phishers, typosquatters, malware distributors, domaineers, combinations of these, etc. In the last year, I've begun thinking that 99% is a serious underestimate. (And it most certainly is in some of the new gTLDs.) ---rsk From jhellenthal at dataix.net Thu Dec 1 21:02:30 2016 From: jhellenthal at dataix.net (J. Hellenthal) Date: Thu, 1 Dec 2016 15:02:30 -0600 Subject: Avalanche botnet takedown In-Reply-To: <20161201205647.GA8911@gsp.org> References: <20161201173426.2861.qmail@ary.lan> <20161201205647.GA8911@gsp.org> Message-ID: <40F41E0A-B740-49FC-9A8D-B70FE55A857D@DataIX.net> 99% ? That's a pretty high figure there. -- Onward!, Jason Hellenthal, Systems & Network Admin, Mobile: 0x9CA0BD58, JJH48-ARIN On Dec 1, 2016, at 14:56, Rich Kulawiec wrote: > On Thu, Dec 01, 2016 at 05:34:26PM -0000, John Levine wrote: > [...] 800,000 domain names used to control it. 1. Which is why abusers are registrars' best customers and why (some) registrars work so very hard to support and shield them. 2. As an aside, I've been doing a little research project for a few years, focused on domains. I've become convinced that *at least* 99% of domains belong to abusers: spammers, phishers, typosquatters, malware distributors, domaineers, combinations of these, etc. In the last year, I've begun thinking that 99% is a serious underestimate. (And it most certainly is in some of the new gTLDs.) ---rsk From justin at cloudflare.com Thu Dec 1 21:06:39 2016 From: justin at cloudflare.com (Justin Paine) Date: Thu, 1 Dec 2016 13:06:39 -0800 Subject: Avalanche botnet takedown In-Reply-To: <40F41E0A-B740-49FC-9A8D-B70FE55A857D@DataIX.net> References: <20161201173426.2861.qmail@ary.lan> <20161201205647.GA8911@gsp.org> <40F41E0A-B740-49FC-9A8D-B70FE55A857D@DataIX.net> Message-ID: straight from the horse's mouth -- they said "99.99% of the 900,000 domains" have been sinkholed. ____________ Justin Paine Head of Trust & Safety Cloudflare Inc. PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D On Thu, Dec 1, 2016 at 1:02 PM, J. Hellenthal wrote: > 99% ? That's a pretty high figure there. > > -- > Onward!, > Jason Hellenthal, > Systems & Network Admin, > Mobile: 0x9CA0BD58, > JJH48-ARIN > > On Dec 1, 2016, at 14:56, Rich Kulawiec wrote: > >> On Thu, Dec 01, 2016 at 05:34:26PM -0000, John Levine wrote: >> [...] 800,000 domain names used to control it. > > 1. Which is why abusers are registrars' best customers and why > (some) registrars work so very hard to support and shield them. > > 2. As an aside, I've been doing a little research project for a > few years, focused on domains. I've become convinced that *at least* > 99% of domains belong to abusers: spammers, phishers, typosquatters, > malware distributors, domaineers, combinations of these, etc. > > In the last year, I've begun thinking that 99% is a serious underestimate. > (And it most certainly is in some of the new gTLDs.) > > ---rsk > From Steve.Mikulasik at civeo.com Thu Dec 1 22:18:06 2016 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Thu, 1 Dec 2016 22:18:06 +0000 Subject: Avalanche botnet takedown In-Reply-To: <20161201124527.9BE453FD@m0087798.ppops.net> References: <20161201124527.9BE453FD@m0087798.ppops.net> Message-ID: We need a cost effective and performant way of blocking botnet traffic in SP networks. Fact is the only way to enforce network policy is from within the network. Laws, putting the onous on users, notifying infected users, etc will never work. We can't expect to solve them all, but at least make it more diffcult by a large margin to run these things. For example blacklisting domains where spam is coming from doesn't stop the problem, but it does help in a big way. Over 800k domains, but I bet they were not using nearly that many IPs. It would be nice to take info from various honeypots about CNC servers and just blackhole those IPs in one way or another very quickly. I don't want to suggest a method of doing this, just as a idea to play around with. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Scott Weeks Sent: Thursday, December 1, 2016 1:45 PM To: nanog at nanog.org Subject: Re: Avalanche botnet takedown --- rfg at tristatelogic.com wrote: From: "Ronald F. Guilmette" The Internet, viewed as an organism, quite clearly has, at present, numerous autoimmune diseases. It is attacking itself. And its immune system, such as it is, clearly ain't working. There's going to come a day of reckoning when it will no longer be possible to paper over this sad and self-evident fact. (And no, I'm *not* talking about the fabled "Digital Pearl Harbor". I'm talking instead about the Internet equivalent of the meteor that wiped out the dinosaurs.) --------------------------------------------------- What is your suggestion to keep the sky from falling? scott From rsk at gsp.org Thu Dec 1 22:43:51 2016 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 1 Dec 2016 17:43:51 -0500 Subject: Avalanche botnet takedown In-Reply-To: <40F41E0A-B740-49FC-9A8D-B70FE55A857D@DataIX.net> References: <20161201173426.2861.qmail@ary.lan> <20161201205647.GA8911@gsp.org> <40F41E0A-B740-49FC-9A8D-B70FE55A857D@DataIX.net> Message-ID: <20161201224351.GA12440@gsp.org> On Thu, Dec 01, 2016 at 03:02:30PM -0600, J. Hellenthal wrote: > 99% ? That's a pretty high figure there. Yeah. I thought so too. For the first ten years. Now I think it's not nearly high enough. Let me give you three examples -- the three that happen to be occupying my attention at the moment. I've got more if you've got the time. A *lot* more. 1) http://www.firemountain.net/~rsk/loan.txt 2) http://www.firemountain.net/~rsk/space.txt 3) http://www.firemountain.net/~rsk/online.txt 1553, 3794, and 602 domains respectively. For brevity, I'll spare you (4) which is a list of 97,657 domains (all in .info) using variations of the same words, all registered by the same "company". Note that my collection methods are lossy, so all of these are drastically UNDERinclusive. ---rsk From rfg at tristatelogic.com Thu Dec 1 22:58:16 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 01 Dec 2016 14:58:16 -0800 Subject: Avalanche botnet takedown In-Reply-To: <20161201124527.9BE453FD@m0087798.ppops.net> Message-ID: <32956.1480633096@segfault.tristatelogic.com> In message <20161201124527.9BE453FD at m0087798.ppops.net>, surfer at mauigateway.com wrote: >What is your suggestion to keep the sky from falling? My full answer, if fully elaborated, would bore you and everybody else to tears, so I'll try to give you an abbreviated version. It seems to be that it comes down to three things... acceptance, leadership, and new thinking. Acceptance We, the people of this planet, including end users, small ISPs, big ISPs, Tier-1 providers, ICANN, and all of the dangling tentacles that derive their authority and power therefrom, law enforcement globally, and judicial systems globally, have to begin by accepting the undeniable reality that traditional law enforcement and judicial processes have already been utterly overwhelmed by the new phenomenon of international cybercrime, *and*, more importantly, that they always will be. If a teenager can hack your bank account in ten minutes, but it takes three years to bring him to trial, after which he gets a slap on the write and probation... well... any idiot can see that this is an ongoing recipie for disaster on a grand scale. (And in a way, announcements like the one today about a small handful of Internet criminals being busted are actually a bad thing, becase they only serve to perpetuate this comforting but incredibly incorrect mass delusion that traditional law enforcement has the new world of cyberspace well in hand. They don't, and never will. And in fact they are just falling further and further behind with each passing year.) Leadership This has to come from the folks at the top of the food chain, the Tier-1 providers, and sadly, they have become like the banks... everybody hates them, but we all know that we can't live without them, and they are free to make money hand over fist while showing no signs of accountability whatsoever. (And don't kid yourself that there is anything even remotely like independence in any of the bits and pieces, starting from ICANN on down, that currently pass for what is laughingly called "Internet Governance". All of these structures take their cue, and their marching orders, from the Internet industry, and the industry, such as it is, can't change a damn thing without buy-in from the Tier-1 providers.) Unfortunately, in this just-past election, one party's Presidential candidate was criticized for being "too close to the banks", in particular, Goldman Sachs, and the other one has just selected a former Goldman Sachs banker pal of his to run the treasury department in the new administration. This shows that without a massive sea change in the level of anger among the general populace, nothing will change, ever. And so it is also with the Internet industry. End users and consumers need to wake up and start actively demanding that the industry grow up, grow a pair, and stop just sitting idly by while the current ongoing hacking free-for-all claims new victims every goddamn day. When and if that ever happens, perhaps one or more CEOs of Tier-1 providers will finally wake up, smell the coffee, and understand that over a time horizon longer than this coming quarter, they need to start showing some leadership, and help guide the whole industry towards a better and safer future. New Thinking Even miltary men have, for some time now, been calling cyberspace "a new domain of battle, like air, land, sea, and space". Why then do our law enforcement and judicial systems, worldwide, fail to also and likewise accept and begin to deal with this new reality? Everywhere on earth, law enforcement, judicial systems, and governments are, by and large, still trying to pretend that cybercrime is a strictly a local matter. It isn't, and hasn't been, for about 30 years now. Internationalized legal structures are hard to assemble, but they are not hardly without precedent. Why should there not be an international Internet equivalent of the "Law of the Sea"? It is quite common for cybercrimes to cross national borders, and yet I personally have so far never heard of a single instance in which any cybercriminal has been brought before the International Criminal Court in the Hague to stand trial. Why not? Russia and China may (and indeed do) seem to have more than a little reluctance to allow extradition of their cybercriminals to the U.S. to stand trial. OK then. What will be their excuse if we instead say that such defendants should be rendered unto, and be brought before the bar in The Hague? Are ISPs, by and large, so absolutely desperate for new clients that they absolutely and positively MUST sell connectivity to any homo sapien who can successfully fog a mirror? If I go to my local cable TV provider and I ask them to give me new service, but also tell them that I *do not* want to first give them a big fat "security deposit", they will say "Ok. No problem. Just give us a minute whil we check your credit rating." If that comes back green, then they give me service... no big deposit required. On the other hand if it comes back orange or red, then I have to pony up a big deposit... which, depending on my behavior, I might not ever get back... before they will sell me service. Contrast this to Internet service. If you reach out and hack my router, and if I am on the ball, I can and will report you to your (current) ISP, giving the exact date and time of the incident and your IP address. In the rare circumstance where (a) this is not your first offense while on your current ISP and also (b) your ISP is below-average greedy and (c) your ISP is below-average incompetent and (d) your current ISP is below-average irresponsible, then you -may-... I stress -may-... actually lose your current connectivity. But even in that very rare case, of course, you can just waltz down the street, the same day, to the next convenient ISP and start all over again, barely missing a beat. So, when is this industry going to grow up, realize that creative individuals, given a single DHCP connection, even perhaps one with relatively low bandwidth, can get on and cause $tens of millions of dollars worth of either theft or damage? When is the industry going to start admitting to itself that individual end-lusers can be dangerous, sometimes even to the tune of $tens of millions of dollars? In short, when is this industry going to start vetting people, at least a little bit, before giving out connectivity to any Tom, Dick, or Harry who shows up on the doorstep with five dollars burning a hole in his pocket? Where is the equivalent of the "credit rating" for Internet users? If I'm running a mom-n-pop ISP, where do I go if I want to find out whether or not this unsavory-looking individual who slept in my doorway last night is or isn't a guy who has already been tossed off his prior two ISPs for gross misbehavior? Maybe its time for the industry to create a registry of such people. (And don't hand me all of that bleeding heart crap about personal privacy, government survelliance, etc. etc. etc. You'll only serve to make it evident to all that you're in the same camp with the wacko Second Amendment wingnuts and/or the equally wacko Any Rand extremist devotees. Time to grow up and realize that if you want to participate in, and obtain benefit from, a civilized society, then society has a fair right to ask you to give up a little bit of something in return. That's the bargain. Take it or leave it. If you don't like it, then get the flock off the Internet and go live in a cave someplace. And don't let the door hit you in the ass on your way out. You will not be missed. And besides all of that, you're probably carrying around five credit cards in your walet as we speak. So it's more than a liitle disingenuous for you to whine about personal privacy as you are checking your credit score five times a day.) Believe it or not, -that- is the -short- version of my solution to the Internet's problem(s). Regards, rfg From rfg at tristatelogic.com Thu Dec 1 23:01:50 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 01 Dec 2016 15:01:50 -0800 Subject: Avalanche botnet takedown In-Reply-To: <20161201205647.GA8911@gsp.org> Message-ID: <32993.1480633310@segfault.tristatelogic.com> In message <20161201205647.GA8911 at gsp.org>, Rich Kulawiec wrote: >2. As an aside, I've been doing a little research project for a >few years, focused on domains. I've become convinced that *at least* >99% of domains belong to abusers: spammers, phishers, typosquatters, >malware distributors, domaineers, combinations of these, etc. As you probably know Rich, that's not exactly a novel observation. Vixie was already saying it a full six years ago, and things have only gotten worse since then. http://www.circleid.com/posts/20100728_taking_back_the_dns/ Regards, rfg From robert at mckay.com Fri Dec 2 00:24:28 2016 From: robert at mckay.com (Robert McKay) Date: Fri, 02 Dec 2016 00:24:28 +0000 Subject: Avalanche botnet takedown In-Reply-To: References: <20161201173426.2861.qmail@ary.lan> <20161201205647.GA8911@gsp.org> <40F41E0A-B740-49FC-9A8D-B70FE55A857D@DataIX.net> Message-ID: <9bc5c15ede0cf44da7da2931de63eb1b@webmail.mckay.com> I'm just assuming this because it doesn't say anywhere, but given the context it seems likely to me that almost none of the 900000 domains were actually registered. It sounds more likely that they figured out how the domain generation algorithm works and instructed the registries to block out all the possible domains it could generate (preventing them from being registered in the future).. along with also going after the registrars to disable a much smaller number of domains that were actually currently registered. Could be the 0.01% were the ones that were actually registered. Rob On 2016-12-01 21:06, Justin Paine via NANOG wrote: > straight from the horse's mouth -- they said "99.99% of the 900,000 > domains" have been sinkholed. > > ____________ > Justin Paine > Head of Trust & Safety > Cloudflare Inc. > PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D > > > On Thu, Dec 1, 2016 at 1:02 PM, J. Hellenthal > wrote: >> 99% ? That's a pretty high figure there. >> >> -- >> Onward!, >> Jason Hellenthal, >> Systems & Network Admin, >> Mobile: 0x9CA0BD58, >> JJH48-ARIN >> >> On Dec 1, 2016, at 14:56, Rich Kulawiec wrote: >> >>> On Thu, Dec 01, 2016 at 05:34:26PM -0000, John Levine wrote: >>> [...] 800,000 domain names used to control it. >> >> 1. Which is why abusers are registrars' best customers and why >> (some) registrars work so very hard to support and shield them. >> >> 2. As an aside, I've been doing a little research project for a >> few years, focused on domains. I've become convinced that *at least* >> 99% of domains belong to abusers: spammers, phishers, typosquatters, >> malware distributors, domaineers, combinations of these, etc. >> >> In the last year, I've begun thinking that 99% is a serious >> underestimate. >> (And it most certainly is in some of the new gTLDs.) >> >> ---rsk >> From surfer at mauigateway.com Fri Dec 2 04:11:24 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 1 Dec 2016 20:11:24 -0800 Subject: Avalanche botnet takedown Message-ID: <20161201201124.982F28E0@m0086238.ppops.net> --- rfg at tristatelogic.com wrote: From: "Ronald F. Guilmette" In message <20161201124527.9BE453FD at m0087798.ppops.net>, surfer at mauigateway.com wrote: >What is your suggestion to keep the sky from falling? My full answer, if fully elaborated, would bore you and everybody else to tears, so I'll try to give you an abbreviated version. It seems to be that it comes down to three things... acceptance, leadership, and new thinking. -------------------------------------------------- In acceptance you seem to want various laws made to control it. In leadership you seem to want the masses to uprise against the "tier 1" folks and force it there. In new thinking you seem to want various governments to band together to form a "law of cyber" coalition and for a "you must be this tall to ride the internet" measurement. You also mention "When is the industry going to start admitting to itself that individual end-lusers can be dangerous, sometimes even to the tune of $tens of millions of dollars? In short, when is this industry going to start vetting people..." I believe 'this industry' does recognize it and no one can get a list of everyone on this planet that is allowed to 'play' on the internet. Did I get the gist of your response correct? scott From ekgermann at semperen.com Fri Dec 2 04:35:31 2016 From: ekgermann at semperen.com (Eric Germann) Date: Thu, 1 Dec 2016 20:35:31 -0800 Subject: Looking for some Quagga experience to discuss 32 bit ASN + community issue with Message-ID: <0C8C9713-D99C-419E-8725-AC346DB39A9F@semperen.com> Good evening, I?m looking for someone who?s familiar with Quagga and is using 32 bit ASN?s. Trying to do some work with communities with it and having no success. If you have some experience and would like to chat, email me off list or reply on-list if the demand is there. Basically trying to advertise 4 byte ASN?s + communities, and then pick them off elsewhere in a private network. Can?t get the config right for the route map to import them on the ?receiving? side. Help much appreciated. Thanks EKG -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3705 bytes Desc: not available URL: From mark.tinka at seacom.mu Fri Dec 2 05:55:09 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Dec 2016 07:55:09 +0200 Subject: BRAS/BNG Suggestion In-Reply-To: References: Message-ID: <3fcf9866-c426-70de-198e-828979c7c6ac@seacom.mu> On 29/Nov/16 20:33, Lorenzo Mainardi wrote: > Good morning, > Could you suggest some vendors of BRAS/BNG for PPPoE termination? > We have more than 20.000 users. > > In my short list there are already Juniper, Cisco and NOKIA/ALU. > Do you have any other honorable brand or good experiences? Redback used to be popular - I believe they got picked up by Ericsson. Mark. From nick at foobar.org Fri Dec 2 09:00:57 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 02 Dec 2016 09:00:57 +0000 Subject: Looking for some Quagga experience to discuss 32 bit ASN + community issue with In-Reply-To: <0C8C9713-D99C-419E-8725-AC346DB39A9F@semperen.com> References: <0C8C9713-D99C-419E-8725-AC346DB39A9F@semperen.com> Message-ID: <58413849.7020603@foobar.org> Eric Germann wrote: > Basically trying to advertise 4 byte ASN?s + communities, and then > pick them off elsewhere in a private network. Can?t get the config > right for the route map to import them on the ?receiving? side. yes, sounds about right. There is a massive feature deficit regarding BGP communities suitable for asn32s, in that the feature just doesn't really exist yet. This is being remedied at the moment at the ietf, which has just moved the draft-ietf-idr-large-community internet draft to "Publication Requested" state. There are implementations here: http://largebgpcommunities.net/implementations/ The feature hasn't made it into mainline quagga yet, but there is a patch. Also, please prod your commercial vendors for support for this. Nick From job at instituut.net Fri Dec 2 10:27:03 2016 From: job at instituut.net (Job Snijders) Date: Fri, 2 Dec 2016 11:27:03 +0100 Subject: Looking for some Quagga experience to discuss 32 bit ASN + community issue with In-Reply-To: <58413849.7020603@foobar.org> References: <0C8C9713-D99C-419E-8725-AC346DB39A9F@semperen.com> <58413849.7020603@foobar.org> Message-ID: <20161202102703.GS513@Vurt.local> On Fri, Dec 02, 2016 at 09:00:57AM +0000, Nick Hilliard wrote: > Eric Germann wrote: > > Basically trying to advertise 4 byte ASN?s + communities, and then > > pick them off elsewhere in a private network. Can?t get the config > > right for the route map to import them on the ?receiving? side. > > yes, sounds about right. There is a massive feature deficit regarding > BGP communities suitable for asn32s, in that the feature just doesn't > really exist yet. This is being remedied at the moment at the ietf, > which has just moved the draft-ietf-idr-large-community internet draft > to "Publication Requested" state. > > The feature hasn't made it into mainline quagga yet, but there is a > patch. The quagga patch is being developed against quagga 1.1.0, the latest version of the patch (0008-) is available here and would benefit from more testing: https://bugzilla.quagga.net/show_bug.cgi?id=875#c13 The patch should provide a feature-complete implementation of Large Communities, but the daemon crashes sometimes. We don't know why yet. However I am proud to report that it compiles! :-) > Also, please prod your commercial vendors for support for this. Yes! Even if a vendor is listed as 'Planned' or 'Requested' on the http://largebgpcommunities.net/implementations/ page, it really helps if you email your account manager stating "Large Communities is what i want". Most vendors have a big backlog of feature requests and no shortage of ideas. This operational community must make it unambiguously clear to the vendors that Large Communities is the thing that needs to be shipping in 2017. This peer pressure will help them to prioritize the development, testing, Q&A, documentation development, internal & external marketing etc to get it done. So, pause your IPv6 deployments for one day, and start calling your Huawei, Cisco (ask separately for IOS and XR), Juniper, Nokia, Arista, Brocade, ZTE, or Microsoft representatives and ask for it by name! :-) Kind regards, Job From tim at pelican.org Fri Dec 2 10:37:29 2016 From: tim at pelican.org (tim at pelican.org) Date: Fri, 2 Dec 2016 10:37:29 -0000 (GMT) Subject: BRAS/BNG Suggestion In-Reply-To: <3fcf9866-c426-70de-198e-828979c7c6ac@seacom.mu> References: <3fcf9866-c426-70de-198e-828979c7c6ac@seacom.mu> Message-ID: <1480675049.707513258@apps.rackspace.com> On Friday, 2 December, 2016 05:55, "Mark Tinka" said: > Redback used to be popular - I believe they got picked up by Ericsson. I'd steer clear at a small scale like 20k subscribers. In my experience, Ericsson as an organisation just aren't set up to deal with a company that want to buy a couple of boxes, install and run them themselves, and call support when something breaks - it's all about multi-month PoCs and fully-managed rollouts at incumbent-telco scale. Think 20M subs, not 20k. Regards, Tim. From dot at dotat.at Fri Dec 2 10:49:55 2016 From: dot at dotat.at (Tony Finch) Date: Fri, 2 Dec 2016 10:49:55 +0000 Subject: Avalanche botnet takedown In-Reply-To: <32485.1480624683@segfault.tristatelogic.com> References: <32485.1480624683@segfault.tristatelogic.com> Message-ID: Ronald F. Guilmette wrote: > > P.P.S. I love this part of the press release, because it is so telling: > > "The successful takedown of this server infrastructure was supported > by ... Registrar of Last Resort, ICANN..." Note that these are the names of two different organizations - the part before the comma is not a description of the role played by ICANN. http://tldcon.ru/docs/02-Addis.pdf http://www.rolr.org/goals.en.html Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Humber, Thames: Northwest 4 or 5, veering northeast 3 or 4. Moderate, becoming slight later in Thames. Showers. Good. From jwbensley at gmail.com Fri Dec 2 10:53:34 2016 From: jwbensley at gmail.com (James Bensley) Date: Fri, 2 Dec 2016 10:53:34 +0000 Subject: BRAS/BNG Suggestion In-Reply-To: <1480675049.707513258@apps.rackspace.com> References: <3fcf9866-c426-70de-198e-828979c7c6ac@seacom.mu> <1480675049.707513258@apps.rackspace.com> Message-ID: On 2 December 2016 at 10:37, tim at pelican.org wrote: > On Friday, 2 December, 2016 05:55, "Mark Tinka" > said: > > > Redback used to be popular - I believe they got picked up by Ericsson. > > I'd steer clear at a small scale like 20k subscribers. In my experience, > Ericsson as an organisation just aren't set up to deal with a company that > want to buy a couple of boxes, install and run them themselves, and call > support when something breaks - it's all about multi-month PoCs and > fully-managed rollouts at incumbent-telco scale. Think 20M subs, not 20k. > > I've heard Redback aren't so good anymore. We are very happy with Cisco (ASR1000s) and Juniper (MX480s) for this function. Cheers, James. From draganj84 at gmail.com Fri Dec 2 11:01:38 2016 From: draganj84 at gmail.com (Dragan Jovicic) Date: Fri, 2 Dec 2016 12:01:38 +0100 Subject: BRAS/BNG Suggestion In-Reply-To: References: <3fcf9866-c426-70de-198e-828979c7c6ac@seacom.mu> <1480675049.707513258@apps.rackspace.com> Message-ID: Our current deployment uses several Alcatel SR 7750 boxes - we pair these with MX960 and MX2020 for CGNAT for several hundred thousand customers. Alcatel and Juniper have been a rock solid combination so far. Regards Dragan On Fri, Dec 2, 2016 at 11:53 AM, James Bensley wrote: > On 2 December 2016 at 10:37, tim at pelican.org wrote: > > > On Friday, 2 December, 2016 05:55, "Mark Tinka" > > said: > > > > > Redback used to be popular - I believe they got picked up by Ericsson. > > > > I'd steer clear at a small scale like 20k subscribers. In my experience, > > Ericsson as an organisation just aren't set up to deal with a company > that > > want to buy a couple of boxes, install and run them themselves, and call > > support when something breaks - it's all about multi-month PoCs and > > fully-managed rollouts at incumbent-telco scale. Think 20M subs, not > 20k. > > > > > I've heard Redback aren't so good anymore. We are very happy with Cisco > (ASR1000s) and Juniper (MX480s) for this function. > > Cheers, > James. > From rsk at gsp.org Fri Dec 2 11:08:48 2016 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 2 Dec 2016 06:08:48 -0500 Subject: No subject Message-ID: <20161202110848.GA8029@gsp.org> Cc Bcc: Subject: Re: Avalanche botnet takedown Reply-To: In-Reply-To: <32993.1480633310 at segfault.tristatelogic.com> On Thu, Dec 01, 2016 at 03:01:50PM -0800, Ronald F. Guilmette wrote: > As you probably know Rich, that's not exactly a novel observation. Vixie > was already saying it a full six years ago, and things have only gotten > worse since then. Yep. I remember reading that. The only change I would make is that Paul wrote: Most new domain names are malicious. and I think a more accurate/updated/refined statement in 2016 would be: Almost all new domain names are malicious. We are busy trying to support a domain name system that is two to three orders of magnitude larger (as measured by domains) than it should be or needs to be. And nearly all of what we're supporting is malicious. ---rsk From mark.tinka at seacom.mu Fri Dec 2 11:13:03 2016 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Dec 2016 13:13:03 +0200 Subject: BRAS/BNG Suggestion In-Reply-To: <1480675049.707513258@apps.rackspace.com> References: <3fcf9866-c426-70de-198e-828979c7c6ac@seacom.mu> <1480675049.707513258@apps.rackspace.com> Message-ID: <8e69b228-3f17-87ec-b2b0-ce466dc8a6fe@seacom.mu> On 2/Dec/16 12:37, tim at pelican.org wrote: > > I'd steer clear at a small scale like 20k subscribers. In my experience, Ericsson as an organisation just aren't set up to deal with a company that want to buy a couple of boxes, install and run them themselves, and call support when something breaks - it's all about multi-month PoCs and fully-managed rollouts at incumbent-telco scale. Think 20M subs, not 20k. Agreed. Mark. From hsalgado at nic.cl Fri Dec 2 11:28:30 2016 From: hsalgado at nic.cl (Hugo =?iso-8859-1?Q?Salgado-Hern=E1ndez?=) Date: Fri, 2 Dec 2016 08:28:30 -0300 Subject: [nanog] Re: Avalanche botnet takedown In-Reply-To: <40F41E0A-B740-49FC-9A8D-B70FE55A857D@DataIX.net> References: <20161201173426.2861.qmail@ary.lan> <20161201205647.GA8911@gsp.org> <40F41E0A-B740-49FC-9A8D-B70FE55A857D@DataIX.net> Message-ID: <20161202112830.GA16448@pepino> According to a 2015 paper, 85% of new gTLDs domains was some form of parking, defensive redirect, unused, etc: Hugo On 15:02 01/12, J. Hellenthal wrote: > 99% ? That's a pretty high figure there. > > -- > Onward!, > Jason Hellenthal, > Systems & Network Admin, > Mobile: 0x9CA0BD58, > JJH48-ARIN > > On Dec 1, 2016, at 14:56, Rich Kulawiec wrote: > > > On Thu, Dec 01, 2016 at 05:34:26PM -0000, John Levine wrote: > > [...] 800,000 domain names used to control it. > > 1. Which is why abusers are registrars' best customers and why > (some) registrars work so very hard to support and shield them. > > 2. As an aside, I've been doing a little research project for a > few years, focused on domains. I've become convinced that *at least* > 99% of domains belong to abusers: spammers, phishers, typosquatters, > malware distributors, domaineers, combinations of these, etc. > > In the last year, I've begun thinking that 99% is a serious underestimate. > (And it most certainly is in some of the new gTLDs.) > > ---rsk > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From rdobbins at arbor.net Fri Dec 2 11:28:51 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 2 Dec 2016 18:28:51 +0700 Subject: Spitballing IoT Security In-Reply-To: <26234.1477787539@segfault.tristatelogic.com> References: <26234.1477787539@segfault.tristatelogic.com> Message-ID: <66D870F0-7D3D-490C-87E1-C311788F1143@arbor.net> On 30 Oct 2016, at 7:32, Ronald F. Guilmette wrote: > you don't need to be either an omnious "state actor" or even SPECTER > to assemble a truly massive packet weapon. I agree: ;> > Two kids with a modest amount of knowledge and a lot of time on their > hands can do it from their mom's basement. And indeed have done so, many times. The *entire purpose* of Mirai is DDoS-for-hire - it's a foundation for so-called 'booter/stresser' services. So, the various articles about how these botnets 'might' be for sale are uninformed - they're *for rent*, that's their raison d'?tre. And renting them is cheap. The economic and resource asymmetries highly favor the attackers. All the speculation about how 'state actors' are somehow 'learning how to take down the Internet' is equally uninformed. State actors already know how to do this, they don't need to 'learn' or 'test' anything. DDoS attacks are the Great Equalizer; when it comes to DDoS, nation-states are just another player. ----------------------------------- Roland Dobbins From rsk at gsp.org Fri Dec 2 11:47:16 2016 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 2 Dec 2016 06:47:16 -0500 Subject: Avalanche botnet takedown In-Reply-To: <32993.1480633310@segfault.tristatelogic.com> References: <20161201205647.GA8911@gsp.org> <32993.1480633310@segfault.tristatelogic.com> Message-ID: <20161202114716.GA9842@gsp.org> [ Reposted with proper Subject line. My apologies. Insufficient coffee. ] On Thu, Dec 01, 2016 at 03:01:50PM -0800, Ronald F. Guilmette wrote: > As you probably know Rich, that's not exactly a novel observation. Vixie > was already saying it a full six years ago, and things have only gotten > worse since then. Yep. I remember reading that. The only change I would make is that Paul wrote: Most new domain names are malicious. and I think a more accurate/updated/refined statement in 2016 would be: Almost all new domain names are malicious. We are busy trying to support a domain name system that is two to three orders of magnitude larger (as measured by domains) than it should be or needs to be. And nearly all of what we're supporting is malicious. ---rsk From KShah at primustel.ca Fri Dec 2 08:12:11 2016 From: KShah at primustel.ca (Krunal Shah) Date: Fri, 2 Dec 2016 08:12:11 +0000 Subject: BRAS/BNG Suggestion In-Reply-To: References: Message-ID: Ericsson SSR 8010 is good platform. We have been using it since last 3 years with no major issues. Havn't tested IPv6 though. Krunal Shah Network Analyst, IP & Transport Network Engineering kshah at primustel.ca -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Lorenzo Mainardi Sent: Tuesday, November 29, 2016 1:34 PM To: nanog at nanog.org Subject: BRAS/BNG Suggestion Good morning, Could you suggest some vendors of BRAS/BNG for PPPoE termination? We have more than 20.000 users. In my short list there are already Juniper, Cisco and NOKIA/ALU. Do you have any other honorable brand or good experiences? Regards digitel Via della Fortezza 6 - 50129 Firenze www.digitelitalia.com - 800 901 669 Ing. Lorenzo Mainardi Tel +39 055 4624933 Fax +39 055 4624 947 lom at digitelitalia.com -------------------------------- This electronic message contains information from Primus Management ULC ("PRIMUS") , which may be legally privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail (to the number or address above) immediately. Any views, opinions or advice expressed in this electronic message are not necessarily the views, opinions or advice of PRIMUS. It is the responsibility of the recipient to ensure that any attachments are virus free and PRIMUS bears no responsibility for any loss or damage arising in any way from the use thereof.The term "PRIMUS" includes its affiliates. -------------------------------- Pour la version en fran?ais de ce message, veuillez voir http://www.primustel.ca/fr/legal/cs.htm From job at instituut.net Fri Dec 2 14:32:13 2016 From: job at instituut.net (Job Snijders) Date: Fri, 2 Dec 2016 15:32:13 +0100 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) Message-ID: <20161202143213.GT513@Vurt.local> Hi all, Ever since the IEEE started allocating OUIs (MAC address ranges) in a randomly distributed fashion rather then sequentially, the operator community has suffered enormously. Time after time issues pop up related to MAC addresses that start with a 4 or a 6. I believe IEEE changed their strategy to attempt to purposefully higher the chance of collisions with MAC squatters, to encourage people to register and pay the fee. The forwarded email at the bottom is yet another example of a widely deployed, but fundamentally broken ASIC. The switch can't forward VPLS frames which contain a payload where the inner packet is destined to a MAC starting with a 4 or a 6. This is with the switch operating in pure layer-2 mode, it doesn't know what MPLS or VPLS even are. The switch is dropping packets on the floor, based on their _payload_. Try selling such circuits to customers "discounted layer-2 service, some flows might not be forwarded". Had IEEE continued the sequential OUI allocations, it probably would've taken many years before we ever reached MACs starting with a 4 or a 6, but instead, in 2012 the first linecards started rolling out of factories with MACs burned in which start with a 4 or a 6, and this took some vendors by surpise. There have been quite some issues, both in hardware and software: Brocade produced a 24x10GE linecard to the market in 2013/2014, with limited FIB scale, meant for a BGP-free MPLS core, but the card can't keep flows together on LACP bundles if the inner packets in a pseudowire were destined for a 4 or 6 MAC. The result: out of order delivery, hurting performance. Cisco ASR 9k's had a bug where if a payload started with a 6, it assumed it would be an IPv6 packet, compare the calculated packet-length with the packet-length in the packet and obviously fail because an ethernet packet is not an IPv6 packet. The result: packets dropped on the floor. (Fixed in 4.3(0.32)I) The Nexus 9000 issue described at the top of this mail. Brocade IronWare had an issue related to packet reordering for flows inside pseudowires, fixed in 2013/2014. There are probably many more examples out there in the wild, slowly driving operators insane. At this moment, some issues related to MACs starting with a 4 or a 6 can be mitigated if you enable Pseudowire Control-Word (RFC 4385) _AND_ Flow-Aware Transport (RFC 6391). You need both to mitigate certain issues in multi-vendor networks (for instance if you have Cisco edge + Juniper core). But what to do when the ASIC won't forward the payload? As ISP you often don't control the payload. Unfortunatly, I don't think we've seen the end of this. The linecards bought in 2012 will trickle down to the grey/second-hand market about now, often without accompanying support contracts. In a world with increased complexity in our interconnectedness, and lack of visibility into the underlaying infrastructure (think remote peering, cloud connectivity, resellers reselling layer-2) it will hurt when some flows inexplicably fail to arrive. Dear IEEE, please pause assigning MAC addresses that start with a 4 or a 6 for the next 6 years. Or at least, next time you change the policy, consult the operational community. This 4/6 MAC issue was well documented in BCP128 back in 2007. The control-word drafts mentioned that there would be dragons related to 4 and 6 back in 2004. Dear Vendors, take this issue more serious. Realise that for operators these issues are _extremely_ hard to debug, this is an expensive time sink. Some of these issues are only visible under very specific, rare circumstances, much like chasing phantoms. So take every vague report of "mysterious" packetloss, or packet reordering at face value and immediately dispatch smart people to delve into whether your software or hardware makes wrong assumptions based on encountering a 4 or a 6 somewhere in the frame. And you, my fellow operators, please continue to publicly document these issues and possible workarounds. Kind regards, Job resources: c-nsp thread "Wierd MPLS/VPLS issue": https://puck.nether.net/pipermail/cisco-nsp/2016-December/thread.html https://www.nanog.org/meetings/nanog57/presentations/Tuesday/tues.general.SnijdersWheeler.MACaddresses.14.pdf BCP128: https://tools.ietf.org/html/bcp128 ----- Forwarded message from Simon Lockhart ----- Date: Fri, 2 Dec 2016 11:44:21 +0000 From: Simon Lockhart To: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] Wierd MPLS/VPLS issue On Wed Nov 23, 2016 at 12:01:20PM +0000, Simon Lockhart wrote: > On Fri Nov 04, 2016 at 03:40:05PM +0000, Simon Lockhart wrote: > > To me, everything *looks* right, it's just that some VPLS traffic traversing > > the new link gets lost. > > For those who are interested... > > Well, I finally got to the bottom of this, and have pushed it to Cisco TAC > for a fix... Cisco TAC finally accepted the issue. Bug CSCvc33783 has been logged. Nexus BU has investigated. Response is... "[...] unfortunately this is an ASIC limitation on the Nexus 9000 switches and is therefore not fixable." If you want a Layer 2 switch that will forward all valid Ethernet frames, I'd suggest avoiding the Nexus 9000 range... Simon _______________________________________________ cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ----- End forwarded message ----- From manager at monmouth.com Fri Dec 2 14:48:34 2016 From: manager at monmouth.com (Mark Stevens) Date: Fri, 2 Dec 2016 09:48:34 -0500 Subject: ATT Wireless Message-ID: <1358876b-353a-d70b-6124-7019c5c229b8@monmouth.com> Good Morning, If anyone from ATT wireless that is on this list, it would be appreciated if you could contact me offline concerning OCN routing problems with your network. Thanks Mark Stevens From cboyd at gizmopartners.com Fri Dec 2 15:01:05 2016 From: cboyd at gizmopartners.com (Chris Boyd) Date: Fri, 2 Dec 2016 09:01:05 -0600 Subject: OT - Looking for a EU based equipment vendor Message-ID: <6758170F-076A-4859-B167-AA7C5163B634@gizmopartners.com> Sorry for the noise, but I need to find a company similar to ServerMonkey.com or Teksavers.com that?s based in France or Switzerland. My google-fu seems to be weak on this. Thanks! ?Chris From morrowc.lists at gmail.com Fri Dec 2 15:29:56 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Dec 2016 10:29:56 -0500 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <20161202143213.GT513@Vurt.local> References: <20161202143213.GT513@Vurt.local> Message-ID: On Fri, Dec 2, 2016 at 9:32 AM, Job Snijders wrote: > > Dear Vendors, take this issue more serious. Realise that for operators > these issues are _extremely_ hard to debug, this is an expensive time > sink. Some of these issues are only visible under very specific, rare > circumstances, much like chasing phantoms. So take every vague report of > "mysterious" packetloss, or packet reordering at face value and > immediately dispatch smart people to delve into whether your software or > hardware makes wrong assumptions based on encountering a 4 or a 6 > somewhere in the frame. > you'd think standard testing of traffic through the asic path somewhere between 'let's design an asic!' and 'here's your board ms customer!' would have found this sort of thing, no? or does testing only use 1 mac address ever? From morrowc.lists at gmail.com Fri Dec 2 15:31:32 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Dec 2016 10:31:32 -0500 Subject: No subject In-Reply-To: <20161202110848.GA8029@gsp.org> References: <20161202110848.GA8029@gsp.org> Message-ID: On Fri, Dec 2, 2016 at 6:08 AM, Rich Kulawiec wrote: > > We are busy trying to support a domain name system that is two to > three orders of magnitude larger (as measured by domains) than it > should be or needs to be. > > that statement seems ... hard to prove. also, what does it matter the size of the domain system? also, perhaps this is an incentives problem from the top down? (if it's really a problem, I mean). From simon at slimey.org Fri Dec 2 16:02:43 2016 From: simon at slimey.org (Simon Lockhart) Date: Fri, 2 Dec 2016 16:02:43 +0000 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: References: <20161202143213.GT513@Vurt.local> Message-ID: <20161202160243.GJ7925@dilbert.slimey.org> On Fri Dec 02, 2016 at 10:29:56AM -0500, Christopher Morrow wrote: > you'd think standard testing of traffic through the asic path somewhere > between 'let's design an asic!' and 'here's your board ms customer!' would > have found this sort of thing, no? or does testing only use 1 mac address > ever? Well, it's actually payload, rather than src/dst MAC used for forwarding, so there's quite a few more combinations to look for... 2^(8*9216) is quite a lot of different packets to test through the forwarding path... But, wait, that assumes every bit combination for 9216 byte packets, but the packet might be shorter than that... So multiply that by (9216-64). Anyone want to work out how many years that'd take to test, even at 100G? Simon From morrowc.lists at gmail.com Fri Dec 2 16:07:43 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Dec 2016 11:07:43 -0500 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <20161202160243.GJ7925@dilbert.slimey.org> References: <20161202143213.GT513@Vurt.local> <20161202160243.GJ7925@dilbert.slimey.org> Message-ID: On Fri, Dec 2, 2016 at 11:02 AM, Simon Lockhart wrote: > On Fri Dec 02, 2016 at 10:29:56AM -0500, Christopher Morrow wrote: > > you'd think standard testing of traffic through the asic path somewhere > > between 'let's design an asic!' and 'here's your board ms customer!' > would > > have found this sort of thing, no? or does testing only use 1 mac address > > ever? > > Well, it's actually payload, rather than src/dst MAC used for forwarding, > so > there's quite a few more combinations to look for... > > 2^(8*9216) is quite a lot of different packets to test through the > forwarding > path... But, wait, that assumes every bit combination for 9216 byte > packets, > but the packet might be shorter than that... So multiply that by (9216-64). > > but most/all forwarding asics (aside from perhaps extreme's?) only deal with the first N bits in the header (128 or so..) so... not quite as many right? > Anyone want to work out how many years that'd take to test, even at 100G? > > Simon > From morrowc.lists at gmail.com Fri Dec 2 16:08:56 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Dec 2016 11:08:56 -0500 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: References: <20161202143213.GT513@Vurt.local> <20161202160243.GJ7925@dilbert.slimey.org> Message-ID: On Fri, Dec 2, 2016 at 11:07 AM, Christopher Morrow wrote: > > > On Fri, Dec 2, 2016 at 11:02 AM, Simon Lockhart wrote: > >> On Fri Dec 02, 2016 at 10:29:56AM -0500, Christopher Morrow wrote: >> >> 2^(8*9216) is quite a lot of different packets to test through the >> forwarding >> path... But, wait, that assumes every bit combination for 9216 byte >> packets, >> but the packet might be shorter than that... So multiply that by >> (9216-64). >> >> > but most/all forwarding asics (aside from perhaps extreme's?) only deal > with the first N bits in the header (128 or so..) so... not quite as many > right? > > > and REALLY they could have just started ~9 yrs ago: "Hey, maybe this 4/6 thing is really a problem? how about we add 2 other things to our testing framework?" instead of: "High Five! First to market!" From rdobbins at arbor.net Fri Dec 2 16:24:51 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 2 Dec 2016 23:24:51 +0700 Subject: No subject In-Reply-To: References: <20161202110848.GA8029@gsp.org> Message-ID: <4F57D724-BEF5-47C6-96AE-CB820D6F5E1F@arbor.net> On 2 Dec 2016, at 22:31, Christopher Morrow wrote: > that statement seems ... hard to prove. Paging Geoff Huston to the white courtesy phone . . . ;> ----------------------------------- Roland Dobbins From nick at foobar.org Fri Dec 2 16:59:37 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 02 Dec 2016 16:59:37 +0000 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <20161202143213.GT513@Vurt.local> References: <20161202143213.GT513@Vurt.local> Message-ID: <5841A879.5050808@foobar.org> Job Snijders wrote: > Dear IEEE, please pause assigning MAC addresses that start with a 4 or a > 6 for the next 6 years. Disagree that this is an IEEE problem. This is problem that vendors need to work around. There is limited MAC space, and deprecating 1/8 of it due to the inability of vendors to cope properly with it seems like a really bad long term idea. It seems that the problem that cropped up on cisco-nsp is that a layer 2 switch, the Nexus 92160 (and possibly everything else which uses the same forwarding ASIC), cannot forward vpls frames with a 4 or 6 buried at a specific location inside the contents of the frame. This is an extraordinary bug which renders the hardware useless in specific circumstances. What makes it worse is that this is a well known corner case which should have been shaken out during design, if not found during QA. Nick From ekgermann at semperen.com Fri Dec 2 17:13:25 2016 From: ekgermann at semperen.com (Eric Germann) Date: Fri, 2 Dec 2016 09:13:25 -0800 Subject: Looking for some Quagga experience to discuss 32 bit ASN + community issue with In-Reply-To: <20161202102703.GS513@Vurt.local> References: <0C8C9713-D99C-419E-8725-AC346DB39A9F@semperen.com> <58413849.7020603@foobar.org> <20161202102703.GS513@Vurt.local> Message-ID: So from reading the draft, if I?m understanding it correctly, I should be able (with the patch) to encode the 32 bit ASN + a community in to this as as32:x:y Is that correct? EKG > On Dec 2, 2016, at 2:27 AM, Job Snijders wrote: > > On Fri, Dec 02, 2016 at 09:00:57AM +0000, Nick Hilliard wrote: >> Eric Germann wrote: >>> Basically trying to advertise 4 byte ASN?s + communities, and then >>> pick them off elsewhere in a private network. Can?t get the config >>> right for the route map to import them on the ?receiving? side. >> >> yes, sounds about right. There is a massive feature deficit regarding >> BGP communities suitable for asn32s, in that the feature just doesn't >> really exist yet. This is being remedied at the moment at the ietf, >> which has just moved the draft-ietf-idr-large-community internet draft >> to "Publication Requested" state. >> >> The feature hasn't made it into mainline quagga yet, but there is a >> patch. > > The quagga patch is being developed against quagga 1.1.0, the latest > version of the patch (0008-) is available here and would benefit from > more testing: https://bugzilla.quagga.net/show_bug.cgi?id=875#c13 > > The patch should provide a feature-complete implementation of Large > Communities, but the daemon crashes sometimes. We don't know why yet. > However I am proud to report that it compiles! :-) > >> Also, please prod your commercial vendors for support for this. > > Yes! > > Even if a vendor is listed as 'Planned' or 'Requested' on the > http://largebgpcommunities.net/implementations/ page, it really helps if > you email your account manager stating "Large Communities is what i want". > > Most vendors have a big backlog of feature requests and no shortage of > ideas. This operational community must make it unambiguously clear to > the vendors that Large Communities is the thing that needs to be > shipping in 2017. This peer pressure will help them to prioritize the > development, testing, Q&A, documentation development, internal & > external marketing etc to get it done. > > So, pause your IPv6 deployments for one day, and start calling your > Huawei, Cisco (ask separately for IOS and XR), Juniper, Nokia, Arista, > Brocade, ZTE, or Microsoft representatives and ask for it by name! :-) > > Kind regards, > > Job -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3705 bytes Desc: not available URL: From job at instituut.net Fri Dec 2 17:19:47 2016 From: job at instituut.net (Job Snijders) Date: Fri, 2 Dec 2016 18:19:47 +0100 Subject: Looking for some Quagga experience to discuss 32 bit ASN + community issue with In-Reply-To: References: <0C8C9713-D99C-419E-8725-AC346DB39A9F@semperen.com> <58413849.7020603@foobar.org> <20161202102703.GS513@Vurt.local> Message-ID: <20161202171947.GF954@hanna.meerval.net> On Fri, Dec 02, 2016 at 09:13:25AM -0800, Eric Germann wrote: > So from reading the draft, if I?m understanding it correctly, I should > be able (with the patch) to encode the 32 bit ASN + a community in to > this as > > as32:x:y > > Is that correct? yes. I recommend you take a look at https://tools.ietf.org/html/draft-snijders-grow-large-communities-usage-00 for inspiration on how to use Large Communities. Kind regards, Job From bicknell at ufp.org Fri Dec 2 17:32:37 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 2 Dec 2016 09:32:37 -0800 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <20161202143213.GT513@Vurt.local> References: <20161202143213.GT513@Vurt.local> Message-ID: <20161202173237.GA44114@ussenterprise.ufp.org> In a message written on Fri, Dec 02, 2016 at 03:32:13PM +0100, Job Snijders wrote: > Dear Vendors, take this issue more serious. Realise that for operators > these issues are _extremely_ hard to debug, this is an expensive time > sink. Some of these issues are only visible under very specific, rare > circumstances, much like chasing phantoms. So take every vague report of > "mysterious" packetloss, or packet reordering at face value and > immediately dispatch smart people to delve into whether your software or > hardware makes wrong assumptions based on encountering a 4 or a 6 > somewhere in the frame. I also do not think this is an IEEE/MAC assignement problem. This is a vendor's box can't forward a particular payload problem. If I had boxes with this issue, I would be talking to my vendor about how: a) They were going to replace every single one of them with something that does not have the bug. b) What discount I would get on mainteance/support for having to swap all of the devices. Then I would follow it up with the other vendors I'm talking to about all of my future purchases if they are unable to produce boxes that work. And if the vendor who supplied these did not fix it, I would give them no more business. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From cscora at apnic.net Fri Dec 2 18:01:56 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Dec 2016 04:01:56 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20161202180156.8BE97C55A1@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 03 Dec, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 623873 Prefixes after maximum aggregation (per Origin AS): 221154 Deaggregation factor: 2.82 Unique aggregates announced (without unneeded subnets): 303044 Total ASes present in the Internet Routing Table: 55364 Prefixes per ASN: 11.27 Origin-only ASes present in the Internet Routing Table: 36335 Origin ASes announcing only one prefix: 15281 Transit ASes present in the Internet Routing Table: 6530 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 40 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 59 Unregistered ASNs in the Routing Table: 15 Number of 32-bit ASNs allocated by the RIRs: 16391 Number of 32-bit ASNs visible in the Routing Table: 12499 Prefixes from 32-bit ASNs in the Routing Table: 50896 Number of bogon 32-bit ASNs visible in the Routing Table: 507 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 409 Number of addresses announced to Internet: 2833731044 Equivalent to 168 /8s, 231 /16s and 77 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.3 Total number of prefixes smaller than registry allocations: 206138 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156912 Total APNIC prefixes after maximum aggregation: 43068 APNIC Deaggregation factor: 3.64 Prefixes being announced from the APNIC address blocks: 171108 Unique aggregates announced from the APNIC address blocks: 70433 APNIC Region origin ASes present in the Internet Routing Table: 5191 APNIC Prefixes per ASN: 32.96 APNIC Region origin ASes announcing only one prefix: 1150 APNIC Region transit ASes present in the Internet Routing Table: 938 Average APNIC Region AS path length visible: 4.3 Max APNIC Region AS path length visible: 40 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2523 Number of APNIC addresses announced to Internet: 760055428 Equivalent to 45 /8s, 77 /16s and 134 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 188330 Total ARIN prefixes after maximum aggregation: 89429 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 194748 Unique aggregates announced from the ARIN address blocks: 89435 ARIN Region origin ASes present in the Internet Routing Table: 16118 ARIN Prefixes per ASN: 12.08 ARIN Region origin ASes announcing only one prefix: 5621 ARIN Region transit ASes present in the Internet Routing Table: 1704 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1618 Number of ARIN addresses announced to Internet: 1106558880 Equivalent to 65 /8s, 244 /16s and 191 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 149276 Total RIPE prefixes after maximum aggregation: 72731 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 160495 Unique aggregates announced from the RIPE address blocks: 98387 RIPE Region origin ASes present in the Internet Routing Table: 18161 RIPE Prefixes per ASN: 8.84 RIPE Region origin ASes announcing only one prefix: 7785 RIPE Region transit ASes present in the Internet Routing Table: 3047 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5098 Number of RIPE addresses announced to Internet: 709672576 Equivalent to 42 /8s, 76 /16s and 190 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 63222 Total LACNIC prefixes after maximum aggregation: 12666 LACNIC Deaggregation factor: 4.99 Prefixes being announced from the LACNIC address blocks: 79653 Unique aggregates announced from the LACNIC address blocks: 37858 LACNIC Region origin ASes present in the Internet Routing Table: 2484 LACNIC Prefixes per ASN: 32.07 LACNIC Region origin ASes announcing only one prefix: 551 LACNIC Region transit ASes present in the Internet Routing Table: 593 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2981 Number of LACNIC addresses announced to Internet: 170921024 Equivalent to 10 /8s, 48 /16s and 12 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15177 Total AfriNIC prefixes after maximum aggregation: 3252 AfriNIC Deaggregation factor: 4.67 Prefixes being announced from the AfriNIC address blocks: 17460 Unique aggregates announced from the AfriNIC address blocks: 6564 AfriNIC Region origin ASes present in the Internet Routing Table: 737 AfriNIC Prefixes per ASN: 23.69 AfriNIC Region origin ASes announcing only one prefix: 174 AfriNIC Region transit ASes present in the Internet Routing Table: 179 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 28 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 279 Number of AfriNIC addresses announced to Internet: 86055424 Equivalent to 5 /8s, 33 /16s and 26 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3645 390 252 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2980 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2713 1500 539 BSNL-NIB National Internet Backbone, IN 4766 2699 11132 742 KIXS-AS-KR Korea Telecom, KR 9808 2234 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2045 428 218 TATACOMM-AS TATA Communications formerl 45899 1740 1260 90 VNPT-AS-VN VNPT Corp, VN 4808 1652 2166 472 CHINA169-BJ China Unicom Beijing Provin 24560 1566 542 228 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3577 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3259 1333 82 SHAW - Shaw Communications Inc., CA 18566 2196 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1954 2014 405 CHARTER-NET-HKY-NC - Charter Communicat 30036 1779 335 340 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1740 5069 652 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6983 1678 848 227 ITCDELTA - Earthlink, Inc., US 701 1602 10634 657 UUNET - MCI Communications Services, In 16509 1502 2818 510 AMAZON-02 - Amazon.com, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3141 163 17 ALJAWWALSTC-AS , SA 20940 2953 1117 2097 AKAMAI-ASN1 , US 9121 2043 1691 18 TTNET , TR 34984 1991 328 365 TELLCOM-AS , TR 13188 1605 99 58 TRIOLAN , UA 12479 1392 1032 53 UNI2-AS , ES 8551 1201 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 6849 1199 355 22 UKRTELNET , UA 8402 1132 544 15 CORBINA-AS OJSC "Vimpelcom", RU 12389 958 1136 427 ROSTELECOM-AS , RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3529 544 163 Telmex Colombia S.A., CO 8151 2286 3370 551 Uninet S.A. de C.V., MX 6503 1540 437 54 Axtel, S.A.B. de C.V., MX 7303 1517 964 246 Telecom Argentina S.A., AR 11830 1421 368 66 Instituto Costarricense de Electricidad 6147 1286 377 27 Telefonica del Peru S.A.A., PE 28573 1037 2269 171 CLARO S.A., BR 3816 987 476 185 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 911 126 80 Alestra, S. de R.L. de C.V., MX 18881 873 1036 22 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1219 402 42 LINKdotNET-AS, EG 36903 692 348 117 MT-MPLS, MA 37611 683 67 6 Afrihost, ZA 36992 575 1373 25 ETISALAT-MISR, EG 8452 471 1472 15 TE-AS TE-AS, EG 24835 419 658 16 RAYA-AS, EG 37492 396 288 72 ORANGE-TN, TN 29571 364 37 11 CITelecom-AS, CI 15399 312 35 6 WANANCHI-KE, KE 36974 275 140 11 AFNET-AS, CI Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3645 390 252 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3577 2968 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3529 544 163 Telmex Colombia S.A., CO 6327 3259 1333 82 SHAW - Shaw Communications Inc., CA 39891 3141 163 17 ALJAWWALSTC-AS , SA 17974 2980 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2953 1117 2097 AKAMAI-ASN1 , US 9829 2713 1500 539 BSNL-NIB National Internet Backbone, IN 4766 2699 11132 742 KIXS-AS-KR Korea Telecom, KR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3577 3426 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7545 3645 3393 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3529 3366 Telmex Colombia S.A., CO 6327 3259 3177 SHAW - Shaw Communications Inc., CA 39891 3141 3124 ALJAWWALSTC-AS , SA 17974 2980 2909 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2234 2201 CMNET-GD Guangdong Mobile Communication 9829 2713 2174 BSNL-NIB National Internet Backbone, IN 18566 2196 2087 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 2056 BELLSOUTH-NET-BLK - BellSouth.net Inc., Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 64855 PRIVATE 41.220.200.0/21 36945 mcelISP, MZ 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 27.110.192.0/22 45664 UNKNOWN 27.110.196.0/22 45664 UNKNOWN 27.110.200.0/22 45664 UNKNOWN 27.110.204.0/22 45664 UNKNOWN 27.110.224.0/22 45664 UNKNOWN Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:102 /12:274 /13:523 /14:1048 /15:1786 /16:13156 /17:7814 /18:13036 /19:25275 /20:38169 /21:40591 /22:72581 /23:60642 /24:347386 /25:523 /26:411 /27:325 /28:69 /29:40 /30:22 /31:1 /32:34 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3055 3259 SHAW - Shaw Communications Inc., CA 39891 2896 3141 ALJAWWALSTC-AS , SA 22773 2784 3577 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2089 2196 MEGAPATH5-US - MegaPath Corporation, US 30036 1594 1779 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1444 3529 Telmex Colombia S.A., CO 9121 1426 2043 TTNET , TR 6389 1393 2095 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1350 1605 TRIOLAN , UA 6983 1323 1678 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1581 2:815 4:24 5:2346 6:32 8:1011 12:1809 13:54 14:1775 15:23 16:2 17:102 18:130 19:1 20:49 23:1940 24:1818 27:2367 31:1812 32:83 33:11 35:3 36:360 37:2429 38:1306 39:42 40:99 41:2965 42:446 43:1926 44:51 45:2231 46:2531 47:108 49:1192 50:946 51:14 52:596 54:354 55:8 56:4 57:40 58:1562 59:979 60:379 61:1842 62:1487 63:1935 64:4558 65:2168 66:4370 67:2255 68:1155 69:3293 70:1296 71:561 72:2072 74:2588 75:400 76:414 77:1432 78:1548 79:916 80:1358 81:1409 82:1018 83:708 84:865 85:1700 86:481 87:1125 88:751 89:2037 90:201 91:6088 92:931 93:2350 94:2432 95:2687 96:575 97:356 98:939 99:94 100:148 101:1189 103:12895 104:2579 105:140 106:468 107:1489 108:783 109:2486 110:1280 111:1659 112:1151 113:1155 114:1054 115:1697 116:1682 117:1570 118:2106 119:1578 120:982 121:1098 122:2288 123:2033 124:1600 125:1847 128:679 129:473 130:430 131:1395 132:616 133:177 134:523 135:208 136:403 137:394 138:1806 139:437 140:621 141:475 142:715 143:927 144:736 145:171 146:951 147:599 148:1391 149:551 150:680 151:840 152:693 153:310 154:691 155:947 156:542 157:571 158:435 159:1323 160:558 161:719 162:2450 163:545 164:788 165:1126 166:356 167:1215 168:2358 169:685 170:2391 171:262 172:829 173:1830 174:764 175:711 176:1751 177:4112 178:2385 179:1145 180:2185 181:1971 182:2128 183:1013 184:842 185:8113 186:3224 187:2232 188:2323 189:1786 190:7951 191:1315 192:9164 193:5739 194:4548 195:3841 196:1879 197:1250 198:5590 199:5828 200:7192 201:3730 202:10183 203:9823 204:4482 205:2756 206:3004 207:3139 208:4055 209:3889 210:3891 211:2064 212:2739 213:2440 214:856 215:66 216:5741 217:1981 218:819 219:599 220:1653 221:883 222:716 223:1365 End of report From jhellenthal at dataix.net Fri Dec 2 18:30:09 2016 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Fri, 2 Dec 2016 12:30:09 -0600 Subject: [nanog] Avalanche botnet takedown In-Reply-To: <20161202112830.GA16448@pepino> References: <20161201173426.2861.qmail@ary.lan> <20161201205647.GA8911@gsp.org> <40F41E0A-B740-49FC-9A8D-B70FE55A857D@DataIX.net> <20161202112830.GA16448@pepino> Message-ID: <9DCE8BB3-369B-4E90-885D-D5B631C01AA8@dataix.net> If I could have it my way, I would say no gTLD?s should be allowed to transmit any email messages whatsoever. And force them to either use something like sendgrid.com or to purchase a primary .com, .org, .net .co.uk whatever etc.. But thats just me. It?s not a nice world but it is just the world we live in today. > On Dec 2, 2016, at 05:28, Hugo Salgado-Hern?ndez wrote: > > According to a 2015 paper, 85% of new gTLDs domains was some form > of parking, defensive redirect, unused, etc: > > > Hugo > > On 15:02 01/12, J. Hellenthal wrote: >> 99% ? That's a pretty high figure there. >> >> -- >> Onward!, >> Jason Hellenthal, >> Systems & Network Admin, >> Mobile: 0x9CA0BD58, >> JJH48-ARIN >> >> On Dec 1, 2016, at 14:56, Rich Kulawiec wrote: >> >>> On Thu, Dec 01, 2016 at 05:34:26PM -0000, John Levine wrote: >>> [...] 800,000 domain names used to control it. >> >> 1. Which is why abusers are registrars' best customers and why >> (some) registrars work so very hard to support and shield them. >> >> 2. As an aside, I've been doing a little research project for a >> few years, focused on domains. I've become convinced that *at least* >> 99% of domains belong to abusers: spammers, phishers, typosquatters, >> malware distributors, domaineers, combinations of these, etc. >> >> In the last year, I've begun thinking that 99% is a serious underestimate. >> (And it most certainly is in some of the new gTLDs.) >> >> ---rsk >> -- Jason Hellenthal JJH48-ARIN From job at instituut.net Fri Dec 2 19:50:40 2016 From: job at instituut.net (Job Snijders) Date: Fri, 2 Dec 2016 20:50:40 +0100 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <5841A879.5050808@foobar.org> <20161202173237.GA44114@ussenterprise.ufp.org> Message-ID: <20161202195040.GG513@Vurt.local> On Fri, Dec 02, 2016 at 09:32:37AM -0800, Leo Bicknell wrote: > I also do not think this is an IEEE/MAC assignement problem. This is a > vendor's box can't forward a particular payload problem. On Fri, Dec 02, 2016 at 04:59:37PM +0000, Nick Hilliard wrote: > Job Snijders wrote: > > Dear IEEE, please pause assigning MAC addresses that start with a 4 > > or a 6 for the next 6 years. > > Disagree that this is an IEEE problem. This is problem that vendors > need to work around. There is limited MAC space, and deprecating 1/8 of > it due to the inability of vendors to cope properly with it seems like a > really bad long term idea. Yes the vendors are doing a poor job. I also appreciate the argument that IEEE just manages that number space and we should consider these 'just numbers' and the vendors need to make do. On the other hand if IEEE had just stuck to the original allocation plan, you and I wouldn't be dealing with this garbage situation. IEEE told one of my friends: "We changed our allocation methods to prevent vendors using unregistered mac addresses." Does the cost of some squatters on poorly usable MAC space outweight the cost of the community spending countless hours tracking down where those dropped packets went? IEEE could've shown more restrain by (temporary, until IPv4 is dead?) avoiding 4 and 6 and still accomplished some of their goal (if this dubious strategy even is effective). I consider this a cascading failure. Clearly IEEE's change had a ripple effect, and suprised a number of implementers, and ended up hurting us. Kind regards, Job From bzs at theworld.com Fri Dec 2 20:21:39 2016 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 2 Dec 2016 15:21:39 -0500 Subject: Avalanche / domains / registrars & registries In-Reply-To: <20161202110848.GA8029@gsp.org> References: <20161202110848.GA8029@gsp.org> Message-ID: <22593.55251.544057.640739@gargle.gargle.HOWL> FWIW one of the people involved in the takedown has reported that most of the 800K domain names were DGA. Here was my nutshell overview summary synopsis posted elsewhere: DGA = Domain Generation Algorithm (term in wikipedia.) So an infected bot and a C&C (command and control computer) have an algorithm -- on the bot it's in the virus -- to generate seemingly random domains using seeds such as the current date. Usually more sophisticated but that's the idea, the goal is that both ends generate the same seemingly random domain. So they'll each generate for example xerv1dvm and attach it to a TLD, it doesn't matter what, xerv1dvm.foo, or it could be .com or whatever. They resolve it because they also infect the host's DNS resolver software (or just inject their own, same thing) so it queries a non-standard root server controlled by the attacker, could just be the C&C computer, which will return an IP address for the infected bot to use. This set up allows these systems to change these parameters as often as they like, every minute or less if needed tho that's probably not necessary, every hour might do or even just once a day. Whatever it takes to stay one step ahead of anyone seeking to interfere with them such as law enforcement. TL;DR: There needn't be any (accredited) registrars/registries involved. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From nick at foobar.org Fri Dec 2 21:16:58 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 02 Dec 2016 21:16:58 +0000 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <20161202195040.GG513@Vurt.local> References: <20161202195040.GG513@Vurt.local> Message-ID: <5841E4CA.1050209@foobar.org> Job Snijders wrote: > I consider this a cascading failure. Clearly IEEE's change had a ripple > effect, and suprised a number of implementers, and ended up hurting us. this would be credible if this were a previously unknown problem, but it isn't. It's been known for years that you need to be careful when handling mpls encapsulated packets which encapsulate L2 frames and where the source mac address starts with 4 or 6. This is not a new problem and because it's not new, there is no good reason for vendors to make the same mistakes again and again. TBH, it beggars belief that new L2 hardware is being thrown out the door which is unable to forward frames of this form due to hardware limitations, and that it's apparently unfixable. Nick From nick at foobar.org Fri Dec 2 21:26:52 2016 From: nick at foobar.org (Nick Hilliard) Date: Fri, 02 Dec 2016 21:26:52 +0000 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <2BA3E5F7-20EE-495E-AA95-9FE4A6F57D1B@cisco.com> References: <5841A879.5050808@foobar.org> <20161202173237.GA44114@ussenterprise.ufp.org> <20161202195040.GG513@Vurt.local> <2BA3E5F7-20EE-495E-AA95-9FE4A6F57D1B@cisco.com> Message-ID: <5841E71C.4040502@foobar.org> Sukumar Subburayan (sukumars) wrote: > I just want to come back on behalf of Cisco on this. We just > investigated this issue and the issue is not an ASIC bug, but a flag > set wrong by SW. We will reach out to the original customer through > TAC who posted this in NSP to resolve this issue. oh cool - this is great. Thanks for following up and clarifying. Nick From allan at allan.org Fri Dec 2 17:42:45 2016 From: allan at allan.org (Allan Liska) Date: Fri, 02 Dec 2016 12:42:45 -0500 Subject: Extreme Networks Technical Contact Message-ID: <20161202174246.68C44A0140@smtp.hushmail.com> Sorry to bother the whole list, but I am looking for help with a mail issue from someone at Extreme Networks, if you work there would you mind reaching out to me off-list? Thanks! allan From spmediallc at gmail.com Fri Dec 2 17:44:38 2016 From: spmediallc at gmail.com (Edmond M) Date: Fri, 2 Dec 2016 11:44:38 -0600 Subject: Anyone have contact info for NOC of PlayStation Network? Message-ID: Hello, I'm getting a lot of auto abuse notices stemming from 'account takeover attempts' via 443 and would like to resolve it with someone directly there. All I have is snei-noc-abuse at am.sony.com and not getting any response. Thanks in advance From sukumars at cisco.com Fri Dec 2 21:23:24 2016 From: sukumars at cisco.com (Sukumar Subburayan (sukumars)) Date: Fri, 2 Dec 2016 21:23:24 +0000 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <20161202195040.GG513@Vurt.local> References: <5841A879.5050808@foobar.org> <20161202173237.GA44114@ussenterprise.ufp.org> <20161202195040.GG513@Vurt.local> Message-ID: <2BA3E5F7-20EE-495E-AA95-9FE4A6F57D1B@cisco.com> All, I just want to come back on behalf of Cisco on this. We just investigated this issue and the issue is not an ASIC bug, but a flag set wrong by SW. We will reach out to the original customer through TAC who posted this in NSP to resolve this issue. sukumar On 12/2/16, 11:50 AM, "NANOG on behalf of Job Snijders" wrote: On Fri, Dec 02, 2016 at 09:32:37AM -0800, Leo Bicknell wrote: > I also do not think this is an IEEE/MAC assignement problem. This is a > vendor's box can't forward a particular payload problem. On Fri, Dec 02, 2016 at 04:59:37PM +0000, Nick Hilliard wrote: > Job Snijders wrote: > > Dear IEEE, please pause assigning MAC addresses that start with a 4 > > or a 6 for the next 6 years. > > Disagree that this is an IEEE problem. This is problem that vendors > need to work around. There is limited MAC space, and deprecating 1/8 of > it due to the inability of vendors to cope properly with it seems like a > really bad long term idea. Yes the vendors are doing a poor job. I also appreciate the argument that IEEE just manages that number space and we should consider these 'just numbers' and the vendors need to make do. On the other hand if IEEE had just stuck to the original allocation plan, you and I wouldn't be dealing with this garbage situation. IEEE told one of my friends: "We changed our allocation methods to prevent vendors using unregistered mac addresses." Does the cost of some squatters on poorly usable MAC space outweight the cost of the community spending countless hours tracking down where those dropped packets went? IEEE could've shown more restrain by (temporary, until IPv4 is dead?) avoiding 4 and 6 and still accomplished some of their goal (if this dubious strategy even is effective). I consider this a cascading failure. Clearly IEEE's change had a ripple effect, and suprised a number of implementers, and ended up hurting us. Kind regards, Job From akatlas at gmail.com Fri Dec 2 16:16:36 2016 From: akatlas at gmail.com (Alia Atlas) Date: Fri, 2 Dec 2016 11:16:36 -0500 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: References: <20161202143213.GT513@Vurt.local> <20161202160243.GJ7925@dilbert.slimey.org> Message-ID: On Fri, Dec 2, 2016 at 11:07 AM, Christopher Morrow wrote: > On Fri, Dec 2, 2016 at 11:02 AM, Simon Lockhart wrote: > > > On Fri Dec 02, 2016 at 10:29:56AM -0500, Christopher Morrow wrote: > > > you'd think standard testing of traffic through the asic path somewhere > > > between 'let's design an asic!' and 'here's your board ms customer!' > > would > > > have found this sort of thing, no? or does testing only use 1 mac > address > > > ever? > > > > Well, it's actually payload, rather than src/dst MAC used for forwarding, > > so > > there's quite a few more combinations to look for... > > > > 2^(8*9216) is quite a lot of different packets to test through the > > forwarding > > path... But, wait, that assumes every bit combination for 9216 byte > > packets, > > but the packet might be shorter than that... So multiply that by > (9216-64). > > > > > but most/all forwarding asics (aside from perhaps extreme's?) only deal > with the first N bits in the header (128 or so..) so... not quite as many > right? This sounds related to the well-known (at least 10+ years) issues around guessing the type of IP packet by looking at the first nibble of the encapsulated packet. Take a quick look at RFC 7325, section 2.4.5.1 bullet 6. This is what using the pseudo-wire code-word is meant to protect against. I don't know if that's an option for networks using this. Regards, Alia > > > Anyone want to work out how many years that'd take to test, even at 100G? > > > > Simon > > > From simon at slimey.org Fri Dec 2 21:58:47 2016 From: simon at slimey.org (Simon Lockhart) Date: Fri, 2 Dec 2016 21:58:47 +0000 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <2BA3E5F7-20EE-495E-AA95-9FE4A6F57D1B@cisco.com> References: <5841A879.5050808@foobar.org> <20161202173237.GA44114@ussenterprise.ufp.org> <20161202195040.GG513@Vurt.local> <2BA3E5F7-20EE-495E-AA95-9FE4A6F57D1B@cisco.com> Message-ID: <20161202215846.GN7925@dilbert.slimey.org> On Fri Dec 02, 2016 at 09:23:24PM +0000, Sukumar Subburayan (sukumars) wrote: > I just want to come back on behalf of Cisco on this. We just investigated > this issue and the issue is not an ASIC bug, but a flag set wrong by SW. We > will reach out to the original customer through TAC who posted this in NSP to > resolve this issue. Sukumar, Can I just publicly say thank you for taking the time to investigate my issue, and identify that a fix is possible. Looking forward to having a working Nexus... Simon From saku at ytti.fi Fri Dec 2 23:17:48 2016 From: saku at ytti.fi (Saku Ytti) Date: Sat, 3 Dec 2016 01:17:48 +0200 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: References: <20161202143213.GT513@Vurt.local> <20161202160243.GJ7925@dilbert.slimey.org> Message-ID: On 2 December 2016 at 18:16, Alia Atlas wrote: > This sounds related to the well-known (at least 10+ years) issues around > guessing the > type of IP packet by looking at the first nibble of the encapsulated packet. > Take a quick look at RFC 7325, section 2.4.5.1 bullet 6. > This is what using the pseudo-wire code-word is meant to protect against. > > I don't know if that's an option for networks using this. Some devices by default look inside pseudowires to find IP inside them, in this case even control-word won't help, you'll need to also disable looking inside pseudowire. -- ++ytti From randy at psg.com Fri Dec 2 23:31:23 2016 From: randy at psg.com (Randy Bush) Date: Fri, 02 Dec 2016 15:31:23 -0800 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <2BA3E5F7-20EE-495E-AA95-9FE4A6F57D1B@cisco.com> References: <5841A879.5050808@foobar.org> <20161202173237.GA44114@ussenterprise.ufp.org> <20161202195040.GG513@Vurt.local> <2BA3E5F7-20EE-495E-AA95-9FE4A6F57D1B@cisco.com> Message-ID: > I just want to come back on behalf of Cisco on this. We just > investigated this issue and the issue is not an ASIC bug, but a flag > set wrong by SW. damn! you just took all the fun out of lynching ieee. sheesh! randy From wimclend at gmail.com Fri Dec 2 22:43:57 2016 From: wimclend at gmail.com (William McLendon) Date: Fri, 2 Dec 2016 17:43:57 -0500 Subject: Acquiring unused IP range. Some questions Message-ID: <4651E4AA-F820-4059-B0CC-CA936D864DDA@gmail.com> Hi everyone, we are about to acquire a block of IP?s from another organization that has unused space, and being fairly new to these procedures, I was hoping for some guidance. We have already been pre-approved by ARIN for the block size we are acquiring, and finalizing the deal with the current owner of the address space. First question is, once they initiate the transfer request to transfer the IP range to us, how long does that typically take for ARIN to complete? Secondly, our relationship with the IP block owner is a very good one, such that I think they would be ok with us advertising this block before we technically own it. My question is, what do they and we need to do to accomplish that in the proper way, so that the internet at large would accept the advertisement from a different ASN, and not view as some sort of hijacking, etc. I am guessing they may need to update some RADB or something like that, but i?ll be honest my knowledge of how those things work and their complete function is pretty slim. This would be a short term thing as we expect the purchase process to complete pretty quickly, but it would be advantageous to us to be able to advertise the space immediately. We just want to make sure we start off on the right foot. Thanks, Will From tj at pcguys.us Sat Dec 3 01:39:01 2016 From: tj at pcguys.us (TJ Trout) Date: Fri, 2 Dec 2016 17:39:01 -0800 Subject: Acquiring unused IP range. Some questions In-Reply-To: <4651E4AA-F820-4059-B0CC-CA936D864DDA@gmail.com> References: <4651E4AA-F820-4059-B0CC-CA936D864DDA@gmail.com> Message-ID: Arin about a week. Just need a LOA for the block I think. On Fri, Dec 2, 2016 at 2:43 PM, William McLendon wrote: > Hi everyone, > > we are about to acquire a block of IP?s from another organization that has > unused space, and being fairly new to these procedures, I was hoping for > some guidance. > > We have already been pre-approved by ARIN for the block size we are > acquiring, and finalizing the deal with the current owner of the address > space. First question is, once they initiate the transfer request to > transfer the IP range to us, how long does that typically take for ARIN to > complete? > > Secondly, our relationship with the IP block owner is a very good one, > such that I think they would be ok with us advertising this block before we > technically own it. My question is, what do they and we need to do to > accomplish that in the proper way, so that the internet at large would > accept the advertisement from a different ASN, and not view as some sort of > hijacking, etc. I am guessing they may need to update some RADB or > something like that, but i?ll be honest my knowledge of how those things > work and their complete function is pretty slim. > > This would be a short term thing as we expect the purchase process to > complete pretty quickly, but it would be advantageous to us to be able to > advertise the space immediately. We just want to make sure we start off on > the right foot. > > > Thanks, > > Will From faisal at snappytelecom.net Sat Dec 3 03:08:53 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sat, 3 Dec 2016 03:08:53 +0000 (GMT) Subject: Acquiring unused IP range. Some questions In-Reply-To: <4651E4AA-F820-4059-B0CC-CA936D864DDA@gmail.com> References: <4651E4AA-F820-4059-B0CC-CA936D864DDA@gmail.com> Message-ID: <206650856.1153078.1480734533402.JavaMail.zimbra@snappytelecom.net> > My question is, what do they and we need to do to accomplish that in > the proper way, so that the internet at large would accept the advertisement > from a different ASN, The internet in terms of IP Prefix advertisements is a 'Trust' based system. > and not view as some sort of hijacking, etc. The difference between Hijacking vs a valid advertisement is the simple LOA document a.k.a having permission to do so.. > I am guessing they may need to update some RADB or something like that, but i?ll be > honest my knowledge of how those things work and their complete function is > pretty slim. Only if you are using it for yourself or if your upstream is using it to create their prefix Filter lists. RADB is not the only RRDB provider, ARIN also provides this service > This would be a short term thing as we expect the purchase process to complete > pretty quickly, but it would be advantageous to us to be able to advertise the > space immediately. We just want to make sure we start off on the right foot. > All you need is permission from the IP block owner (LOA) and the appropriate upstream filters to be setup or opened. Which could be a manual process (provide them a copy of the LOA) or could be a 'Trust' based using RRDB Record which someone has to create and update. Best of luck. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "William McLendon" > To: "nanog list" > Sent: Friday, December 2, 2016 5:43:57 PM > Subject: Acquiring unused IP range. Some questions > Hi everyone, > > we are about to acquire a block of IP?s from another organization that has > unused space, and being fairly new to these procedures, I was hoping for some > guidance. > > We have already been pre-approved by ARIN for the block size we are acquiring, > and finalizing the deal with the current owner of the address space. First > question is, once they initiate the transfer request to transfer the IP range > to us, how long does that typically take for ARIN to complete? > > Secondly, our relationship with the IP block owner is a very good one, such that > I think they would be ok with us advertising this block before we technically > own it. My question is, what do they and we need to do to accomplish that in > the proper way, so that the internet at large would accept the advertisement > from a different ASN, and not view as some sort of hijacking, etc. I am > guessing they may need to update some RADB or something like that, but i?ll be > honest my knowledge of how those things work and their complete function is > pretty slim. > > This would be a short term thing as we expect the purchase process to complete > pretty quickly, but it would be advantageous to us to be able to advertise the > space immediately. We just want to make sure we start off on the right foot. > > > Thanks, > > Will From z at amused.net Sat Dec 3 12:20:04 2016 From: z at amused.net (Patrick Cole) Date: Sat, 3 Dec 2016 23:20:04 +1100 Subject: BRAS/BNG Suggestion In-Reply-To: <1480675049.707513258@apps.rackspace.com> References: <3fcf9866-c426-70de-198e-828979c7c6ac@seacom.mu> <1480675049.707513258@apps.rackspace.com> Message-ID: <20161203122004.GA7625@amused.net> 2nded, I tried for months to get Ericsson to get us a quote and sort us out with a solution as I'd used their kit and liked it in the past. Exactly as Tim said, they just didn't seem interested if you're not after a big $$ solution. We went with ASR1k as cisco came to the party on price and we were already using 7200 at the time. No complaints. Patrick Fri, Dec 02, 2016 at 10:37:29AM -0000, tim at pelican.org wrote: > On Friday, 2 December, 2016 05:55, "Mark Tinka" said: > > > Redback used to be popular - I believe they got picked up by Ericsson. > > I'd steer clear at a small scale like 20k subscribers. In my experience, Ericsson as an organisation just aren't set up to deal with a company that want to buy a couple of boxes, install and run them themselves, and call support when something breaks - it's all about multi-month PoCs and fully-managed rollouts at incumbent-telco scale. Think 20M subs, not 20k. > > Regards, > Tim. > > -- Patrick Cole Senior Network Specialist World Without Wires PO Box 869. Palm Beach, QLD, 4221 Ph: 0410 626 630 From tony at wicks.co.nz Sat Dec 3 20:17:20 2016 From: tony at wicks.co.nz (Tony Wicks) Date: Sun, 4 Dec 2016 09:17:20 +1300 Subject: BRAS/BNG Suggestion In-Reply-To: <20161203122004.GA7625@amused.net> References: <3fcf9866-c426-70de-198e-828979c7c6ac@seacom.mu> <1480675049.707513258@apps.rackspace.com> <20161203122004.GA7625@amused.net> Message-ID: <001701d24da2$41082820$c3187860$@co.nz> I was told by some high up people in Ericsson several years ago that their target for the Redback range is the top dozen telco's and they are not really interested in smaller customers. It's a shame, because the Redback in many ways is still superior to other offerings IMHO. To the OP's question - 1. The Nokia 7750 is a good option, but you would likely need the larger 7750-SR or 7750-e over the 7750-a series as the "a" does not have the MS-ISA card option that allows access to several key BNG functions. Likely outside of budget once spares etc are taken into account 2. Cisco ASR1K, likely this will do what you need, the advantage if the 1K range is it's just a big CPU based box, so you don't need add on cards to do anything fancy. There is also affordable support and an active grey market option available (2x asr1006-esp40). 3. A virtual offering from Juniper (VMX) or Cisco might work for you. Nokia's offering is a bit too new. I would choose option 2 with option 3 as a backup if you want to get things going quickly. Unless money is not an option then option 1 (2x 7750-sr7 or 7750-e2). -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Patrick Cole Sent: Sunday, 4 December 2016 1:20 AM To: tim at pelican.org Cc: nanog at nanog.org Subject: Re: BRAS/BNG Suggestion 2nded, I tried for months to get Ericsson to get us a quote and sort us out with a solution as I'd used their kit and liked it in the past. Exactly as Tim said, they just didn't seem interested if you're not after a big $$ solution. We went with ASR1k as cisco came to the party on price and we were already using 7200 at the time. No complaints. Patrick Fri, Dec 02, 2016 at 10:37:29AM -0000, tim at pelican.org wrote: From Daniel.Jameson at tdstelecom.com Sun Dec 4 02:08:30 2016 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Sun, 4 Dec 2016 02:08:30 +0000 Subject: BRAS/BNG Suggestion In-Reply-To: <001701d24da2$41082820$c3187860$@co.nz> References: <3fcf9866-c426-70de-198e-828979c7c6ac@seacom.mu> <1480675049.707513258@apps.rackspace.com> <20161203122004.GA7625@amused.net>,<001701d24da2$41082820$c3187860$@co.nz> Message-ID: The Nokia is the rebranded Alcatel 7750. The syntax is funky, but it's a great bras. ________________________________ From: NANOG on behalf of Tony Wicks Sent: Saturday, December 03, 2016 2:17:20 PM To: nanog at nanog.org Subject: RE: BRAS/BNG Suggestion I was told by some high up people in Ericsson several years ago that their target for the Redback range is the top dozen telco's and they are not really interested in smaller customers. It's a shame, because the Redback in many ways is still superior to other offerings IMHO. To the OP's question - 1. The Nokia 7750 is a good option, but you would likely need the larger 7750-SR or 7750-e over the 7750-a series as the "a" does not have the MS-ISA card option that allows access to several key BNG functions. Likely outside of budget once spares etc are taken into account 2. Cisco ASR1K, likely this will do what you need, the advantage if the 1K range is it's just a big CPU based box, so you don't need add on cards to do anything fancy. There is also affordable support and an active grey market option available (2x asr1006-esp40). 3. A virtual offering from Juniper (VMX) or Cisco might work for you. Nokia's offering is a bit too new. I would choose option 2 with option 3 as a backup if you want to get things going quickly. Unless money is not an option then option 1 (2x 7750-sr7 or 7750-e2). -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Patrick Cole Sent: Sunday, 4 December 2016 1:20 AM To: tim at pelican.org Cc: nanog at nanog.org Subject: Re: BRAS/BNG Suggestion 2nded, I tried for months to get Ericsson to get us a quote and sort us out with a solution as I'd used their kit and liked it in the past. Exactly as Tim said, they just didn't seem interested if you're not after a big $$ solution. We went with ASR1k as cisco came to the party on price and we were already using 7200 at the time. No complaints. Patrick Fri, Dec 02, 2016 at 10:37:29AM -0000, tim at pelican.org wrote: From Daniel.Jameson at tdstelecom.com Sun Dec 4 15:11:27 2016 From: Daniel.Jameson at tdstelecom.com (Wormly SMTP Test) Date: Sun, 4 Dec 2016 15:11:27 +0000 Subject: Wormly SMTP Test Message Message-ID: <89b5a49f9d8ba0740aeacec54e45430a@blog.wormly.com> This message was sent using the Wormly SMTP testing tool by this user: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36 197.230.17.94 From Daniel.Jameson at tdstelecom.com Sun Dec 4 15:19:27 2016 From: Daniel.Jameson at tdstelecom.com (Wormly SMTP Test) Date: Sun, 4 Dec 2016 15:19:27 +0000 Subject: Wormly SMTP Test Message Message-ID: This message was sent using the Wormly SMTP testing tool by this user: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36 105.159.251.206 From Daniel.Jameson at tdstelecom.com Sun Dec 4 15:43:42 2016 From: Daniel.Jameson at tdstelecom.com (Wormly SMTP Test) Date: Sun, 4 Dec 2016 15:43:42 +0000 Subject: Wormly SMTP Test Message Message-ID: <2da1cd6970de7c9be809586707234fae@blog.wormly.com> This message was sent using the Wormly SMTP testing tool by this user: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36 197.230.17.94 From Daniel.Jameson at tdstelecom.com Sun Dec 4 15:43:45 2016 From: Daniel.Jameson at tdstelecom.com (Wormly SMTP Test) Date: Sun, 4 Dec 2016 15:43:45 +0000 Subject: Wormly SMTP Test Message Message-ID: <0a4ce998086897682f323bfdea4f4b57@blog.wormly.com> This message was sent using the Wormly SMTP testing tool by this user: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36 197.230.17.94 From lorenzo.mainardi at digitelitalia.com Sat Dec 3 17:19:45 2016 From: lorenzo.mainardi at digitelitalia.com (Lorenzo Mainardi) Date: Sat, 3 Dec 2016 17:19:45 +0000 Subject: BRAS/BNG Suggestion In-Reply-To: <1480675049.707513258@apps.rackspace.com> References: <3fcf9866-c426-70de-198e-828979c7c6ac@seacom.mu>, <1480675049.707513258@apps.rackspace.com> Message-ID: Yes, it seems that our use case it's not the right one for Ericsson. ________________________________ Da: NANOG per conto di tim at pelican.org Inviato: venerd? 2 dicembre 2016 11.37.29 A: nanog at nanog.org Oggetto: Re: BRAS/BNG Suggestion On Friday, 2 December, 2016 05:55, "Mark Tinka" said: > Redback used to be popular - I believe they got picked up by Ericsson. I'd steer clear at a small scale like 20k subscribers. In my experience, Ericsson as an organisation just aren't set up to deal with a company that want to buy a couple of boxes, install and run them themselves, and call support when something breaks - it's all about multi-month PoCs and fully-managed rollouts at incumbent-telco scale. Think 20M subs, not 20k. Regards, Tim. From plosher at plosh.net Sat Dec 3 18:29:01 2016 From: plosher at plosh.net (Peter Losher) Date: Sat, 3 Dec 2016 10:29:01 -0800 Subject: Comcast business IPv6 vs rbldnsd & PSBL In-Reply-To: References: <1480358779.9604.1.camel@surriel.com> <8add43a6-d0e5-def3-1d24-dae08aeeab6f@shout.net> <0A57A82D-CE73-4A72-B8B6-16916C8085B6@puck.nether.net> <1480446839.31110.13.camel@surriel.com> Message-ID: That's true - I had one of the SMC routers for many years when I had static Business HSI service, and switched earlier this year to using a off the shelf Arris (ex Motorola) Surfboard modems and dynamic IP on my BHSI service... my IPv6 service has never been better. :) Unless you have a static IP configuration - As long as it's on Comcast's approved modem list they don't care what modem you use even if it's on their business class service. Best Wishes - Peter On Tue, Nov 29, 2016 at 1:18 PM, wrote: > To clarify, you cannot rent AND have static IP's. > > You can rent your own modem ofr business service when using dynamic IP's. > > Robert Webb > > > On Tue, 29 Nov 2016 15:07:52 -0500 > Jared Mauch wrote: > >> Can't do that with the business service. Oh well, to have choices. >> Jared Mauch >> >>> On Nov 29, 2016, at 2:40 PM, Randy Bush wrote: >>> >>> i am running my own (why rent at silly costs) dpc3008 and wfm. >>> >>> randy >>> >> > -- [ http://blog.plosh.net ] - "Earth Halted: Please reboot to continue" From don at 00100100.net Sat Dec 3 21:14:28 2016 From: don at 00100100.net (Don Fanning) Date: Sat, 3 Dec 2016 13:14:28 -0800 Subject: Disney Brands GeoIP Contact In-Reply-To: References: Message-ID: Hi James, I work for Disney (DTSS) and service that piece of the infrastructure. We use Digital Element's Netacuity product. If your network block is resolving wrong, I would contact them directly. That saves us the work of contacting them directly for you. DE's email relating to data updates is ip-data at digitalelement.com. Cheers, -Don On Wed, Nov 30, 2016 at 8:25 AM, James Baldwin wrote: > > Does anyone have contacts at Disney or an associated brand (Hulu, Disney, > ESPN)? They all appear to have out of date or incorrect GeoIP information > for our Level3 block. > > I have been able to whitelist our corporate locations with Hulu however I > have been unable to reach anyone at the other sites. I would love to find > out which third party they are using for their information and correct the > problem at the source (MaxMind is correct). > > - James From Sam at SanDiegoBroadband.com Sun Dec 4 17:14:57 2016 From: Sam at SanDiegoBroadband.com (Sam Norris) Date: Sun, 4 Dec 2016 09:14:57 -0800 Subject: Level3 / Cogent / NetFlix BGP Assistance Message-ID: <0ede01d24e51$f214c290$d63e47b0$@SanDiegoBroadband.com> Hey all, In early October our traffic levels from NetFlix went from about half Level3 and half Cogent - pretty well balanced - to all on Level3. Standard multihomed BGP setup with minimal TE if I can help it. I am starting to run into problems with a full gigabit port on Level3 and only 100-200mbps on Cogent at that colo. I tried padding, I even tried 65000:2906 bgp community, but it seems like if our level3 port is up NetFlix chooses it solely. How can I load balance NetFlix traffic across my two ports so that I am not paying for overages and/or forced to up to a 10G port immediately? I have 3 other providers at that colo and cannot find any mix of bgp tricks to get some of it thru our other providers. I notice AS2906 has a localpref of 86 - odd ... The 108.175.47.0/24 block seems to be using as 2906 so I thought a 65000:2906 wouldn't announce those prefixes to them at all. I have about 10 prefixes being announced so I could implement a no-export on some of them to load balance but that doesn't work. Thx, Sam BGP routing table entry for 108.175.47.0/24 Paths: (2 available, best #1) 2906 AS-path translation: { 108.175.47.0/24 } ear3.LosAngeles1 (metric 100000) Origin IGP, metric 30334, localpref 86, valid, internal, best Community: 2906:51081 North_America Lclprf_86 United_States Level3_Peer Los_Angeles Level3:10984 Originator: ear3.LosAngeles1 2906 AS-path translation: { 108.175.47.0/24 } ear3.LosAngeles1 (metric 100000) Origin IGP, metric 30334, localpref 86, valid, internal Community: 2906:51081 North_America Lclprf_86 United_States Level3_Peer Los_Angeles Level3:10984 Originator: ear3.LosAngeles1 From faisal at snappytelecom.net Sun Dec 4 17:25:38 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sun, 4 Dec 2016 17:25:38 +0000 (GMT) Subject: Level3 / Cogent / NetFlix BGP Assistance In-Reply-To: <0ede01d24e51$f214c290$d63e47b0$@SanDiegoBroadband.com> References: <0ede01d24e51$f214c290$d63e47b0$@SanDiegoBroadband.com> Message-ID: <1873972174.1172123.1480872338987.JavaMail.zimbra@snappytelecom.net> Have you considered connecting to the nearest peering exchange ? where you can potentially off-load all of this traffic from your paid IP Transit ? Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Sam Norris" > To: "nanog list" > Sent: Sunday, December 4, 2016 12:14:57 PM > Subject: Level3 / Cogent / NetFlix BGP Assistance > Hey all, > > > > In early October our traffic levels from NetFlix went from about half Level3 and > half Cogent - pretty well balanced - to all on Level3. Standard multihomed BGP > setup with minimal TE if I can help it. I am starting to run into problems with > a full gigabit port on Level3 and only 100-200mbps on Cogent at that colo. I > tried padding, I even tried 65000:2906 bgp community, but it seems like if our > level3 port is up NetFlix chooses it solely. How can I load balance NetFlix > traffic across my two ports so that I am not paying for overages and/or forced > to up to a 10G port immediately? I have 3 other providers at that colo and > cannot find any mix of bgp tricks to get some of it thru our other providers. > > > > I notice AS2906 has a localpref of 86 - odd ... > > > > The 108.175.47.0/24 block seems to be using as 2906 so I thought a 65000:2906 > wouldn't announce those prefixes to them at all. I have about 10 prefixes being > announced so I could implement a no-export on some of them to load balance but > that doesn't work. > > > > Thx, > > Sam > > > > > > BGP routing table entry for 108.175.47.0/24 > > > > Paths: (2 available, best #1) > > 2906 > > AS-path translation: { 108.175.47.0/24 } > > ear3.LosAngeles1 (metric 100000) > > Origin IGP, metric 30334, localpref 86, valid, internal, best > > Community: 2906:51081 North_America Lclprf_86 United_States Level3_Peer > Los_Angeles Level3:10984 > > Originator: ear3.LosAngeles1 > > 2906 > > AS-path translation: { 108.175.47.0/24 } > > ear3.LosAngeles1 (metric 100000) > > Origin IGP, metric 30334, localpref 86, valid, internal > > Community: 2906:51081 North_America Lclprf_86 United_States Level3_Peer > Los_Angeles Level3:10984 > > Originator: ear3.LosAngeles1 From erich at gotfusion.net Sun Dec 4 17:30:26 2016 From: erich at gotfusion.net (Kaiser, Erich) Date: Sun, 4 Dec 2016 11:30:26 -0600 Subject: Level3 / Cogent / NetFlix BGP Assistance In-Reply-To: <1873972174.1172123.1480872338987.JavaMail.zimbra@snappytelecom.net> References: <0ede01d24e51$f214c290$d63e47b0$@SanDiegoBroadband.com> <1873972174.1172123.1480872338987.JavaMail.zimbra@snappytelecom.net> Message-ID: Sam I just sent you an email offlist. a public ix port could be an option. Erich Kaiser The Fusion Network erich at gotfusion.net Office: 630-621-4804 Cell: 630-777-9291 On Sun, Dec 4, 2016 at 11:25 AM, Faisal Imtiaz wrote: > Have you considered connecting to the nearest peering exchange ? where you > can potentially off-load all of this traffic from your paid IP Transit ? > > Faisal Imtiaz > Snappy Internet & Telecom > > ----- Original Message ----- > > From: "Sam Norris" > > To: "nanog list" > > Sent: Sunday, December 4, 2016 12:14:57 PM > > Subject: Level3 / Cogent / NetFlix BGP Assistance > > > Hey all, > > > > > > > > In early October our traffic levels from NetFlix went from about half > Level3 and > > half Cogent - pretty well balanced - to all on Level3. Standard > multihomed BGP > > setup with minimal TE if I can help it. I am starting to run into > problems with > > a full gigabit port on Level3 and only 100-200mbps on Cogent at that > colo. I > > tried padding, I even tried 65000:2906 bgp community, but it seems like > if our > > level3 port is up NetFlix chooses it solely. How can I load balance > NetFlix > > traffic across my two ports so that I am not paying for overages and/or > forced > > to up to a 10G port immediately? I have 3 other providers at that colo > and > > cannot find any mix of bgp tricks to get some of it thru our other > providers. > > > > > > > > I notice AS2906 has a localpref of 86 - odd ... > > > > > > > > The 108.175.47.0/24 block seems to be using as 2906 so I thought a > 65000:2906 > > wouldn't announce those prefixes to them at all. I have about 10 > prefixes being > > announced so I could implement a no-export on some of them to load > balance but > > that doesn't work. > > > > > > > > Thx, > > > > Sam > > > > > > > > > > > > BGP routing table entry for 108.175.47.0/24 > > > > > > > > Paths: (2 available, best #1) > > > > 2906 > > > > AS-path translation: { 108.175.47.0/24 } > > > > ear3.LosAngeles1 (metric 100000) > > > > Origin IGP, metric 30334, localpref 86, valid, internal, best > > > > Community: 2906:51081 North_America Lclprf_86 United_States > Level3_Peer > > Los_Angeles Level3:10984 > > > > Originator: ear3.LosAngeles1 > > > > 2906 > > > > AS-path translation: { 108.175.47.0/24 } > > > > ear3.LosAngeles1 (metric 100000) > > > > Origin IGP, metric 30334, localpref 86, valid, internal > > > > Community: 2906:51081 North_America Lclprf_86 United_States > Level3_Peer > > Los_Angeles Level3:10984 > > > > Originator: ear3.LosAngeles1 > From johnstong at westmancom.com Mon Dec 5 14:50:38 2016 From: johnstong at westmancom.com (Graham Johnston) Date: Mon, 5 Dec 2016 14:50:38 +0000 Subject: Favorite Speed Test Systems Message-ID: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> For many years we have had a local instance of the Ookla speedtest.net on our network, and while it is pretty good some other tests seem include more detailed results. I am aware of the following speedtest systems that an operator can likely have a local instance of: * Speedtest.net * Sourceforge.net/speedtest * Dslreports.com/speedtest Are there others? What is your preferred one and why? Thanks, Graham From mianosm at gmail.com Mon Dec 5 15:46:45 2016 From: mianosm at gmail.com (Steven Miano) Date: Mon, 5 Dec 2016 10:46:45 -0500 Subject: Favorite Speed Test Systems In-Reply-To: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: fast.com is a dead fast/simple download result page. ...also with a huge customer base - it is often closer to speedtest..net|com than some of those others. There is also a speedtest-cli available on Linux/MacOS (via Brew). On Mon, Dec 5, 2016 at 9:50 AM, Graham Johnston wrote: > For many years we have had a local instance of the Ookla speedtest.net on > our network, and while it is pretty good some other tests seem include more > detailed results. > > I am aware of the following speedtest systems that an operator can likely > have a local instance of: > > * Speedtest.net > > * Sourceforge.net/speedtest > > * Dslreports.com/speedtest > > Are there others? What is your preferred one and why? > > Thanks, > Graham > > -- Miano, Steven M. http://stevenmiano.com From josh at kyneticwifi.com Mon Dec 5 15:51:30 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 5 Dec 2016 09:51:30 -0600 Subject: Favorite Speed Test Systems In-Reply-To: References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: A lot of people have crappy performance to those. For example, from a 10G server to fast.com I was pulling around 9Mbps up/down. 1 hop away from a Netflix open connect appliance. On Dec 5, 2016 9:49 AM, "Steven Miano" wrote: > fast.com is a dead fast/simple download result page. > > ...also with a huge customer base - it is often closer to > speedtest..net|com than some of those others. > > There is also a speedtest-cli available on Linux/MacOS (via Brew). > > On Mon, Dec 5, 2016 at 9:50 AM, Graham Johnston > wrote: > > > For many years we have had a local instance of the Ookla speedtest.net > on > > our network, and while it is pretty good some other tests seem include > more > > detailed results. > > > > I am aware of the following speedtest systems that an operator can likely > > have a local instance of: > > > > * Speedtest.net > > > > * Sourceforge.net/speedtest > > > > * Dslreports.com/speedtest > > > > Are there others? What is your preferred one and why? > > > > Thanks, > > Graham > > > > > > > -- > Miano, Steven M. > http://stevenmiano.com > From nanog at ics-il.net Mon Dec 5 15:54:42 2016 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 5 Dec 2016 09:54:42 -0600 (CST) Subject: Favorite Speed Test Systems In-Reply-To: References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: <507261831.1726.1480953279884.JavaMail.mhammett@ThunderFuck> Ah, this is the first I've heard of slow fast.com performance with someone actually connected to them. Usually it's an ISP that's a few AS hops away from Netflix. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Josh Reynolds" To: "Steven Miano" Cc: "NANOG" Sent: Monday, December 5, 2016 9:51:30 AM Subject: Re: Favorite Speed Test Systems A lot of people have crappy performance to those. For example, from a 10G server to fast.com I was pulling around 9Mbps up/down. 1 hop away from a Netflix open connect appliance. On Dec 5, 2016 9:49 AM, "Steven Miano" wrote: > fast.com is a dead fast/simple download result page. > > ...also with a huge customer base - it is often closer to > speedtest..net|com than some of those others. > > There is also a speedtest-cli available on Linux/MacOS (via Brew). > > On Mon, Dec 5, 2016 at 9:50 AM, Graham Johnston > wrote: > > > For many years we have had a local instance of the Ookla speedtest.net > on > > our network, and while it is pretty good some other tests seem include > more > > detailed results. > > > > I am aware of the following speedtest systems that an operator can likely > > have a local instance of: > > > > * Speedtest.net > > > > * Sourceforge.net/speedtest > > > > * Dslreports.com/speedtest > > > > Are there others? What is your preferred one and why? > > > > Thanks, > > Graham > > > > > > > -- > Miano, Steven M. > http://stevenmiano.com > From mianosm at gmail.com Mon Dec 5 15:58:35 2016 From: mianosm at gmail.com (Steven Miano) Date: Mon, 5 Dec 2016 10:58:35 -0500 Subject: Favorite Speed Test Systems In-Reply-To: References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: First, you only get down from fast.com not up - so the up/down is a bit suspect there. Second, this is a more 'real world' test than iperf - if you want to ensure that your NIC is operating at the rated speed I'd imagine you'd have the ability to setup an iperf target and check Layer2/Layer3 transfer speeds/etc. Third, you should really look into that if you are 1 hop away and getting that type of speed. Clearly you deserve better. ;-) 80Mbps result (with comparison link if you don't like that one): http://i.imgur.com/Cnr92Ag.png - of course I'm on a 240Mbps WAN connection: *Last Result:* Download Speed: *236960* kbps (29620 KB/sec transfer rate) Upload Speed: *22991* kbps (2873.9 KB/sec transfer rate) Latency: *12* ms Jitter: *2* ms 12/5/2016, 10:57:56 AM (Those results are from my provider in the Tampa Bay area at: speedtest.bhn.net). ~Steven On Mon, Dec 5, 2016 at 10:51 AM, Josh Reynolds wrote: > A lot of people have crappy performance to those. For example, from a 10G > server to fast.com I was pulling around 9Mbps up/down. 1 hop away from a > Netflix open connect appliance. > > On Dec 5, 2016 9:49 AM, "Steven Miano" wrote: > >> fast.com is a dead fast/simple download result page. >> >> ...also with a huge customer base - it is often closer to >> speedtest..net|com than some of those others. >> >> There is also a speedtest-cli available on Linux/MacOS (via Brew). >> >> On Mon, Dec 5, 2016 at 9:50 AM, Graham Johnston > > >> wrote: >> >> > For many years we have had a local instance of the Ookla speedtest.net >> on >> > our network, and while it is pretty good some other tests seem include >> more >> > detailed results. >> > >> > I am aware of the following speedtest systems that an operator can >> likely >> > have a local instance of: >> > >> > * Speedtest.net >> > >> > * Sourceforge.net/speedtest >> > >> > * Dslreports.com/speedtest >> > >> > Are there others? What is your preferred one and why? >> > >> > Thanks, >> > Graham >> > >> > >> >> >> -- >> Miano, Steven M. >> http://stevenmiano.com >> > -- Miano, Steven M. http://stevenmiano.com From ttauber at 1-4-5.net Mon Dec 5 16:18:09 2016 From: ttauber at 1-4-5.net (Tony Tauber) Date: Mon, 5 Dec 2016 11:18:09 -0500 Subject: Acquiring unused IP range. Some questions In-Reply-To: <206650856.1153078.1480734533402.JavaMail.zimbra@snappytelecom.net> References: <4651E4AA-F820-4059-B0CC-CA936D864DDA@gmail.com> <206650856.1153078.1480734533402.JavaMail.zimbra@snappytelecom.net> Message-ID: It would be helpful also if the whois record is updated with the Origin AS listed. See ARIN's post on the topic: https://www.arin.net/resources/originas.html Tony On Fri, Dec 2, 2016 at 10:08 PM, Faisal Imtiaz wrote: > > My question is, what do they and we need to do to accomplish that in > > the proper way, so that the internet at large would accept the > advertisement > > from a different ASN, > > The internet in terms of IP Prefix advertisements is a 'Trust' based > system. > > > > and not view as some sort of hijacking, etc. > > The difference between Hijacking vs a valid advertisement is the simple > LOA document a.k.a having permission to do so.. > > > > I am guessing they may need to update some RADB or something like that, > but i?ll be > > honest my knowledge of how those things work and their complete function > is > > pretty slim. > > > Only if you are using it for yourself or if your upstream is using it to > create their prefix Filter lists. > RADB is not the only RRDB provider, ARIN also provides this service > > > This would be a short term thing as we expect the purchase process to > complete > > pretty quickly, but it would be advantageous to us to be able to > advertise the > > space immediately. We just want to make sure we start off on the right > foot. > > > > All you need is permission from the IP block owner (LOA) and the > appropriate upstream filters to be setup or opened. > Which could be a manual process (provide them a copy of the LOA) or could > be a 'Trust' based using RRDB Record which someone has to create and update. > > Best of luck. > > Faisal Imtiaz > Snappy Internet & Telecom > > > ----- Original Message ----- > > From: "William McLendon" > > To: "nanog list" > > Sent: Friday, December 2, 2016 5:43:57 PM > > Subject: Acquiring unused IP range. Some questions > > > Hi everyone, > > > > we are about to acquire a block of IP?s from another organization that > has > > unused space, and being fairly new to these procedures, I was hoping for > some > > guidance. > > > > We have already been pre-approved by ARIN for the block size we are > acquiring, > > and finalizing the deal with the current owner of the address space. > First > > question is, once they initiate the transfer request to transfer the IP > range > > to us, how long does that typically take for ARIN to complete? > > > > Secondly, our relationship with the IP block owner is a very good one, > such that > > I think they would be ok with us advertising this block before we > technically > > own it. My question is, what do they and we need to do to accomplish > that in > > the proper way, so that the internet at large would accept the > advertisement > > from a different ASN, and not view as some sort of hijacking, etc. I am > > guessing they may need to update some RADB or something like that, but > i?ll be > > honest my knowledge of how those things work and their complete function > is > > pretty slim. > > > > This would be a short term thing as we expect the purchase process to > complete > > pretty quickly, but it would be advantageous to us to be able to > advertise the > > space immediately. We just want to make sure we start off on the right > foot. > > > > > > Thanks, > > > > Will > From josh at kyneticwifi.com Mon Dec 5 16:27:54 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 5 Dec 2016 10:27:54 -0600 Subject: Favorite Speed Test Systems In-Reply-To: References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: I was thinking they tested up too, but still.. Never had good performance testing to them upon release. Good connectivity with several diverse upstreams. Always had better results with beta.speedtest. YMMV On Dec 5, 2016 9:59 AM, "Steven Miano" wrote: > First, you only get down from fast.com not up - so the up/down is a bit > suspect there. > > Second, this is a more 'real world' test than iperf - if you want to > ensure that your NIC is operating at the rated speed I'd imagine you'd have > the ability to setup an iperf target and check Layer2/Layer3 transfer > speeds/etc. > > Third, you should really look into that if you are 1 hop away and getting > that type of speed. Clearly you deserve better. ;-) > > 80Mbps result (with comparison link if you don't like that one): > http://i.imgur.com/Cnr92Ag.png - of course I'm on a 240Mbps WAN > connection: > > *Last Result:* > Download Speed: *236960* kbps (29620 KB/sec transfer rate) > Upload Speed: *22991* kbps (2873.9 KB/sec transfer rate) > Latency: *12* ms > Jitter: *2* ms > 12/5/2016, 10:57:56 AM > > (Those results are from my provider in the Tampa Bay area at: > speedtest.bhn.net). > > ~Steven > > On Mon, Dec 5, 2016 at 10:51 AM, Josh Reynolds > wrote: > >> A lot of people have crappy performance to those. For example, from a 10G >> server to fast.com I was pulling around 9Mbps up/down. 1 hop away from a >> Netflix open connect appliance. >> >> On Dec 5, 2016 9:49 AM, "Steven Miano" wrote: >> >>> fast.com is a dead fast/simple download result page. >>> >>> ...also with a huge customer base - it is often closer to >>> speedtest..net|com than some of those others. >>> >>> There is also a speedtest-cli available on Linux/MacOS (via Brew). >>> >>> On Mon, Dec 5, 2016 at 9:50 AM, Graham Johnston < >>> johnstong at westmancom.com> >>> wrote: >>> >>> > For many years we have had a local instance of the Ookla speedtest.net >>> on >>> > our network, and while it is pretty good some other tests seem include >>> more >>> > detailed results. >>> > >>> > I am aware of the following speedtest systems that an operator can >>> likely >>> > have a local instance of: >>> > >>> > * Speedtest.net >>> > >>> > * Sourceforge.net/speedtest >>> > >>> > * Dslreports.com/speedtest >>> > >>> > Are there others? What is your preferred one and why? >>> > >>> > Thanks, >>> > Graham >>> > >>> > >>> >>> >>> -- >>> Miano, Steven M. >>> http://stevenmiano.com >>> >> > > > -- > Miano, Steven M. > http://stevenmiano.com > From josh at kyneticwifi.com Mon Dec 5 16:28:22 2016 From: josh at kyneticwifi.com (Josh Reynolds) Date: Mon, 5 Dec 2016 10:28:22 -0600 Subject: Favorite Speed Test Systems In-Reply-To: <507261831.1726.1480953279884.JavaMail.mhammett@ThunderFuck> References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> <507261831.1726.1480953279884.JavaMail.mhammett@ThunderFuck> Message-ID: There was an afmug thread about this exact issue several months ago. On Dec 5, 2016 9:57 AM, "Mike Hammett" wrote: > Ah, this is the first I've heard of slow fast.com performance with > someone actually connected to them. Usually it's an ISP that's a few AS > hops away from Netflix. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Josh Reynolds" > To: "Steven Miano" > Cc: "NANOG" > Sent: Monday, December 5, 2016 9:51:30 AM > Subject: Re: Favorite Speed Test Systems > > A lot of people have crappy performance to those. For example, from a 10G > server to fast.com I was pulling around 9Mbps up/down. 1 hop away from a > Netflix open connect appliance. > > On Dec 5, 2016 9:49 AM, "Steven Miano" wrote: > > > fast.com is a dead fast/simple download result page. > > > > ...also with a huge customer base - it is often closer to > > speedtest..net|com than some of those others. > > > > There is also a speedtest-cli available on Linux/MacOS (via Brew). > > > > On Mon, Dec 5, 2016 at 9:50 AM, Graham Johnston < > johnstong at westmancom.com> > > wrote: > > > > > For many years we have had a local instance of the Ookla speedtest.net > > on > > > our network, and while it is pretty good some other tests seem include > > more > > > detailed results. > > > > > > I am aware of the following speedtest systems that an operator can > likely > > > have a local instance of: > > > > > > * Speedtest.net > > > > > > * Sourceforge.net/speedtest > > > > > > * Dslreports.com/speedtest > > > > > > Are there others? What is your preferred one and why? > > > > > > Thanks, > > > Graham > > > > > > > > > > > > -- > > Miano, Steven M. > > http://stevenmiano.com > > > > From hank at efes.iucc.ac.il Mon Dec 5 17:31:08 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 5 Dec 2016 19:31:08 +0200 Subject: Favorite Speed Test Systems In-Reply-To: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: <986cef27-a695-bb2e-0710-5a54b499d3b3@efes.iucc.ac.il> On 05/12/2016 16:50, Graham Johnston wrote: http://openspeedtest.com/ http://labs.comcast.com/beta-testing-a-new-open-source-speed-test -Hank > For many years we have had a local instance of the Ookla speedtest.net on our network, and while it is pretty good some other tests seem include more detailed results. > > I am aware of the following speedtest systems that an operator can likely have a local instance of: > > * Speedtest.net > > * Sourceforge.net/speedtest > > * Dslreports.com/speedtest > > Are there others? What is your preferred one and why? > > Thanks, > Graham > From nanog at ics-il.net Mon Dec 5 18:42:56 2016 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 5 Dec 2016 12:42:56 -0600 (CST) Subject: Favorite Speed Test Systems In-Reply-To: References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> <507261831.1726.1480953279884.JavaMail.mhammett@ThunderFuck> Message-ID: <1573334247.1908.1480963375203.JavaMail.mhammett@ThunderFuck> Right, it's mostly ISPs that don't understand the BGP world or how speedtests work. I think, you, Paul and myself were the only ones participating that really knew. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Josh Reynolds" To: "Mike Hammett" Cc: "NANOG" Sent: Monday, December 5, 2016 10:28:22 AM Subject: Re: Favorite Speed Test Systems There was an afmug thread about this exact issue several months ago. On Dec 5, 2016 9:57 AM, "Mike Hammett" < nanog at ics-il.net > wrote: Ah, this is the first I've heard of slow fast.com performance with someone actually connected to them. Usually it's an ISP that's a few AS hops away from Netflix. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Josh Reynolds" < josh at kyneticwifi.com > To: "Steven Miano" < mianosm at gmail.com > Cc: "NANOG" < nanog at nanog.org > Sent: Monday, December 5, 2016 9:51:30 AM Subject: Re: Favorite Speed Test Systems A lot of people have crappy performance to those. For example, from a 10G server to fast.com I was pulling around 9Mbps up/down. 1 hop away from a Netflix open connect appliance. On Dec 5, 2016 9:49 AM, "Steven Miano" < mianosm at gmail.com > wrote: > fast.com is a dead fast/simple download result page. > > ...also with a huge customer base - it is often closer to > speedtest..net|com than some of those others. > > There is also a speedtest-cli available on Linux/MacOS (via Brew). > > On Mon, Dec 5, 2016 at 9:50 AM, Graham Johnston < johnstong at westmancom.com > > wrote: > > > For many years we have had a local instance of the Ookla speedtest.net > on > > our network, and while it is pretty good some other tests seem include > more > > detailed results. > > > > I am aware of the following speedtest systems that an operator can likely > > have a local instance of: > > > > * Speedtest.net > > > > * Sourceforge.net/speedtest > > > > * Dslreports.com/speedtest > > > > Are there others? What is your preferred one and why? > > > > Thanks, > > Graham > > > > > > > -- > Miano, Steven M. > http://stevenmiano.com > From nanog at ics-il.net Mon Dec 5 18:48:32 2016 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 5 Dec 2016 12:48:32 -0600 (CST) Subject: Favorite Speed Test Systems In-Reply-To: <1573334247.1908.1480963375203.JavaMail.mhammett@ThunderFuck> References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> <507261831.1726.1480953279884.JavaMail.mhammett@ThunderFuck> <1573334247.1908.1480963375203.JavaMail.mhammett@ThunderFuck> Message-ID: <728749819.1957.1480963710422.JavaMail.mhammett@ThunderFuck> A lot of people can't differentiate between what the test is testing, a bad test and connectivity issues producing bad results on an otherwise good test. I'd say that most of the time, it's the last category. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mike Hammett" Cc: "NANOG" Sent: Monday, December 5, 2016 12:42:56 PM Subject: Re: Favorite Speed Test Systems Right, it's mostly ISPs that don't understand the BGP world or how speedtests work. I think, you, Paul and myself were the only ones participating that really knew. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Josh Reynolds" To: "Mike Hammett" Cc: "NANOG" Sent: Monday, December 5, 2016 10:28:22 AM Subject: Re: Favorite Speed Test Systems There was an afmug thread about this exact issue several months ago. On Dec 5, 2016 9:57 AM, "Mike Hammett" < nanog at ics-il.net > wrote: Ah, this is the first I've heard of slow fast.com performance with someone actually connected to them. Usually it's an ISP that's a few AS hops away from Netflix. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Josh Reynolds" < josh at kyneticwifi.com > To: "Steven Miano" < mianosm at gmail.com > Cc: "NANOG" < nanog at nanog.org > Sent: Monday, December 5, 2016 9:51:30 AM Subject: Re: Favorite Speed Test Systems A lot of people have crappy performance to those. For example, from a 10G server to fast.com I was pulling around 9Mbps up/down. 1 hop away from a Netflix open connect appliance. On Dec 5, 2016 9:49 AM, "Steven Miano" < mianosm at gmail.com > wrote: > fast.com is a dead fast/simple download result page. > > ...also with a huge customer base - it is often closer to > speedtest..net|com than some of those others. > > There is also a speedtest-cli available on Linux/MacOS (via Brew). > > On Mon, Dec 5, 2016 at 9:50 AM, Graham Johnston < johnstong at westmancom.com > > wrote: > > > For many years we have had a local instance of the Ookla speedtest.net > on > > our network, and while it is pretty good some other tests seem include > more > > detailed results. > > > > I am aware of the following speedtest systems that an operator can likely > > have a local instance of: > > > > * Speedtest.net > > > > * Sourceforge.net/speedtest > > > > * Dslreports.com/speedtest > > > > Are there others? What is your preferred one and why? > > > > Thanks, > > Graham > > > > > > > -- > Miano, Steven M. > http://stevenmiano.com > From applebaumt at ochin.org Mon Dec 5 19:29:44 2016 From: applebaumt at ochin.org (Tyler Applebaum) Date: Mon, 5 Dec 2016 19:29:44 +0000 Subject: Need contact info for AS1798 - State of Oregon Message-ID: <25440C4BF31A8E44872003195DEB57BE05AF672C@omail1.community-health.org> If you could contact me off-list, I'd appreciate it. - Tyler From the.lists at mgm51.com Mon Dec 5 19:30:57 2016 From: the.lists at mgm51.com (Mike) Date: Mon, 5 Dec 2016 14:30:57 -0500 Subject: Favorite Speed Test Systems In-Reply-To: <986cef27-a695-bb2e-0710-5a54b499d3b3@efes.iucc.ac.il> References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> <986cef27-a695-bb2e-0710-5a54b499d3b3@efes.iucc.ac.il> Message-ID: On 12/5/2016 12:31 PM, Hank Nussbacher wrote: > On 05/12/2016 16:50, Graham Johnston wrote: > > http://openspeedtest.com/ > Pegs my connection at 40.30 mbps upload. I have Comcast 25/5. My upload is usually in the 6 or 7 mbps range. From theodore at ciscodude.net Mon Dec 5 19:44:37 2016 From: theodore at ciscodude.net (Theodore Baschak) Date: Mon, 5 Dec 2016 13:44:37 -0600 Subject: Favorite Speed Test Systems In-Reply-To: <986cef27-a695-bb2e-0710-5a54b499d3b3@efes.iucc.ac.il> References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> <986cef27-a695-bb2e-0710-5a54b499d3b3@efes.iucc.ac.il> Message-ID: On Mon, Dec 5, 2016 at 11:31 AM, Hank Nussbacher wrote: > On 05/12/2016 16:50, Graham Johnston wrote: > > http://openspeedtest.com/ > > http://labs.comcast.com/beta-testing-a-new-open-source-speed-test > > -Hank > > I'm impressed that openspeedtest.com supports IPv6! I haven't noticed this in too many speedtests yet, and its something I've been asked about on occasion. Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/ From janusz at speedchecker.xyz Mon Dec 5 20:37:13 2016 From: janusz at speedchecker.xyz (Janusz Jezowicz) Date: Mon, 5 Dec 2016 21:37:13 +0100 Subject: Favorite Speed Test Systems In-Reply-To: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: My company Speedchecker offers good alternative, we have HTML5 technology as well as native SDKs for mobile such as iOS,Android and Windows I can send more information about our measurement methodology, customer base etc if required. We did comparison of Fast.com and our technology few months ago here - http://blog.speedchecker.xyz/2016/09/08/are-isps-still-throttling-netflix/ Regards, Janusz Jezowicz *Speedchecker Ltd* *email*: janusz at speedchecker.xyz *skype*: jezowicz *phone*: +442032863573 *web*: www.speedchecker.xyz The Black Church, St. Mary?s Place, Dublin 7, D07 P4AX, Ireland On 5 December 2016 at 15:50, Graham Johnston wrote: > For many years we have had a local instance of the Ookla speedtest.net on > our network, and while it is pretty good some other tests seem include more > detailed results. > > I am aware of the following speedtest systems that an operator can likely > have a local instance of: > > * Speedtest.net > > * Sourceforge.net/speedtest > > * Dslreports.com/speedtest > > Are there others? What is your preferred one and why? > > Thanks, > Graham > > From nick at fluency.net.uk Mon Dec 5 15:34:00 2016 From: nick at fluency.net.uk (Nick Ryce) Date: Mon, 5 Dec 2016 15:34:00 +0000 Subject: Favorite Speed Test Systems In-Reply-To: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: For testing downloads, fast.com is pretty nice Nick Ryce Fluency Communications (Commsworld Ltd T/A) T: +44 (0) 330 121 1000 www.fluency.net.uk nick at fluency.net.uk On 05/12/2016, 14:50, "NANOG on behalf of Graham Johnston" wrote: For many years we have had a local instance of the Ookla speedtest.net on our network, and while it is pretty good some other tests seem include more detailed results. I am aware of the following speedtest systems that an operator can likely have a local instance of: * Speedtest.net * Sourceforge.net/speedtest * Dslreports.com/speedtest Are there others? What is your preferred one and why? Thanks, Graham From edugas at unknowndevice.ca Mon Dec 5 23:14:53 2016 From: edugas at unknowndevice.ca (Eric Dugas) Date: Mon, 5 Dec 2016 18:14:53 -0500 Subject: Favorite Speed Test Systems In-Reply-To: References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: I like nperf.com as I usually always get consistent results and you can keep track of your results if you sign up. They only have one server in Canada (hosted by OVH in Beauharnois) but you can host your own like Ookla's Speedtest.net. On 5 December 2016 at 15:37, Janusz Jezowicz wrote: > My company Speedchecker offers good alternative, we have HTML5 technology > as well as native SDKs for mobile such as iOS,Android and Windows > > I can send more information about our measurement methodology, customer > base etc if required. > > We did comparison of Fast.com and our technology few months ago here - > http://blog.speedchecker.xyz/2016/09/08/are-isps-still-throttling-netflix/ > > Regards, > > Janusz Jezowicz > *Speedchecker Ltd* > *email*: janusz at speedchecker.xyz > *skype*: jezowicz > *phone*: +442032863573 > *web*: www.speedchecker.xyz > The Black Church, St. Mary?s Place, Dublin 7, D07 P4AX, Ireland > > > On 5 December 2016 at 15:50, Graham Johnston > wrote: > >> For many years we have had a local instance of the Ookla speedtest.net on >> our network, and while it is pretty good some other tests seem include more >> detailed results. >> >> I am aware of the following speedtest systems that an operator can likely >> have a local instance of: >> >> * Speedtest.net >> >> * Sourceforge.net/speedtest >> >> * Dslreports.com/speedtest >> >> Are there others? What is your preferred one and why? >> >> Thanks, >> Graham >> >> From rdobbins at arbor.net Tue Dec 6 02:38:33 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 6 Dec 2016 09:38:33 +0700 Subject: Favorite Speed Test Systems In-Reply-To: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: On 5 Dec 2016, at 21:50, Graham Johnston wrote: > What is your preferred one and why? Thorough, reasonable teat methodology, allows one to store history, decent range of test servers worldwide. ----------------------------------- Roland Dobbins From job at instituut.net Tue Dec 6 12:28:41 2016 From: job at instituut.net (Job Snijders) Date: Tue, 6 Dec 2016 13:28:41 +0100 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <20161202160243.GJ7925@dilbert.slimey.org> References: <20161202143213.GT513@Vurt.local> <20161202160243.GJ7925@dilbert.slimey.org> Message-ID: <20161206122841.GA984@Vurt.local> On Fri, Dec 02, 2016 at 04:02:43PM +0000, Simon Lockhart wrote: > On Fri Dec 02, 2016 at 10:29:56AM -0500, Christopher Morrow wrote: > > you'd think standard testing of traffic through the asic path > > somewhere between 'let's design an asic!' and 'here's your board ms > > customer!' would have found this sort of thing, no? or does testing > > only use 1 mac address ever? > > Well, it's actually payload, rather than src/dst MAC used for > forwarding, so there's quite a few more combinations to look for... > > 2^(8*9216) is quite a lot of different packets to test through the > forwarding path... But, wait, that assumes every bit combination for > 9216 byte packets, but the packet might be shorter than that... So > multiply that by (9216-64). > > Anyone want to work out how many years that'd take to test, even at > 100G? Folks on NLNOG found another gem: http://mailman.nlnog.net/pipermail/nlnog/2016-December/002637.html Liberal translation below. The big take-away for operators is that service providers need to make it part of the MPLS Psuedo-wire troubleshooting procedure to ask the customer which MACs are involved and raise the red flag when a 4 or 6 is involved. ----------- Hi, We've observed a similar problem on the Arista 7150S-52 with EOS 4.12.3.1: issues with passing transient MPLS traffic through a layer-2 domain where the payload contains certain MACs. Arista EOS 4.16.9M apparently contains a fix to address this problem. MACs that didnt make it through the switch when running 4.12.3.1: 4*:**:**:**:**:** 6*:**:**:**:**:** *4:**:**:**:**:** *6:**:**:**:**:** **:**:*B:**:6*:** **:**:*F:**:4*:** Maybe there are more combinations, but we didn't iterate through all possibilities. Big thank you to Richard van Looijen (Flowmailer) for finding this issue, Edwin Kalle (2hip) for pointing us at this thread, and Job Snijders, his email which prompted us to investigate the intermediate switches. Kind regards, Robert From mike at mikejones.in Tue Dec 6 12:50:38 2016 From: mike at mikejones.in (Mike Jones) Date: Tue, 6 Dec 2016 12:50:38 +0000 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <20161206122841.GA984@Vurt.local> References: <20161202143213.GT513@Vurt.local> <20161202160243.GJ7925@dilbert.slimey.org> <20161206122841.GA984@Vurt.local> Message-ID: > MACs that didnt make it through the switch when running 4.12.3.1: > > 4*:**:**:**:**:** > 6*:**:**:**:**:** > *4:**:**:**:**:** > *6:**:**:**:**:** > **:**:*B:**:6*:** > **:**:*F:**:4*:** Can anyone explain the last 2 for me? I was under the impression that this bug was mainly caused by some optimistic attempt to detect raw IPv4 or IPv6 payloads by checking for a version at the start of the frame. This does not explain why it would be looking at the 5th octet. I also would assume that there must be something else to the last 2 examples beyond just the B or F and 4 or 6 because otherwise it would match way too many addresses to have not been noticed before. Perhaps the full MAC address looks like some other protocol with a 4 byte header? Thanks, Mike From dave at temk.in Tue Dec 6 13:03:30 2016 From: dave at temk.in (Dave Temkin) Date: Tue, 6 Dec 2016 05:03:30 -0800 Subject: Level3 / Cogent / NetFlix BGP Assistance In-Reply-To: <0ede01d24e51$f214c290$d63e47b0$@SanDiegoBroadband.com> References: <0ede01d24e51$f214c290$d63e47b0$@SanDiegoBroadband.com> Message-ID: Hi Sam, As you may have noticed, Netflix no longer uses Cogent as a transit provider. You will see all of your transit traffic from us traverse Level3. We are happy to try to work with you to find the best way to deliver your traffic. Please reach out to peering at netflix.com and the team will try to help. Regards, -Dave On Sun, Dec 4, 2016 at 9:14 AM, Sam Norris wrote: > Hey all, > > > > In early October our traffic levels from NetFlix went from about half > Level3 and > half Cogent - pretty well balanced - to all on Level3. Standard > multihomed BGP > setup with minimal TE if I can help it. I am starting to run into > problems with > a full gigabit port on Level3 and only 100-200mbps on Cogent at that > colo. I > tried padding, I even tried 65000:2906 bgp community, but it seems like if > our > level3 port is up NetFlix chooses it solely. How can I load balance > NetFlix > traffic across my two ports so that I am not paying for overages and/or > forced > to up to a 10G port immediately? I have 3 other providers at that colo and > cannot find any mix of bgp tricks to get some of it thru our other > providers. > > > > I notice AS2906 has a localpref of 86 - odd ... > > > > The 108.175.47.0/24 block seems to be using as 2906 so I thought a > 65000:2906 > wouldn't announce those prefixes to them at all. I have about 10 prefixes > being > announced so I could implement a no-export on some of them to load balance > but > that doesn't work. > > > > Thx, > > Sam > > > > > > BGP routing table entry for 108.175.47.0/24 > > > > Paths: (2 available, best #1) > > 2906 > > AS-path translation: { 108.175.47.0/24 } > > ear3.LosAngeles1 (metric 100000) > > Origin IGP, metric 30334, localpref 86, valid, internal, best > > Community: 2906:51081 North_America Lclprf_86 United_States Level3_Peer > Los_Angeles Level3:10984 > > Originator: ear3.LosAngeles1 > > 2906 > > AS-path translation: { 108.175.47.0/24 } > > ear3.LosAngeles1 (metric 100000) > > Origin IGP, metric 30334, localpref 86, valid, internal > > Community: 2906:51081 North_America Lclprf_86 United_States Level3_Peer > Los_Angeles Level3:10984 > > Originator: ear3.LosAngeles1 > > > > > > > > From matthew at walster.org Tue Dec 6 13:28:55 2016 From: matthew at walster.org (Matthew Walster) Date: Tue, 6 Dec 2016 13:28:55 +0000 Subject: Favorite Speed Test Systems In-Reply-To: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: On 5 December 2016 at 14:50, Graham Johnston wrote: > Are there others? What is your preferred one and why? > ?Generally I don't bother with speed testers unless I'm wanting a quick guesstimate -- I wouldn't recommend using them as a measure of how "fast" an internet connection is because there's always other factors in contention, and it only tests the path to the speedtester. Having said that, despite the obnoxious adverts on the site, speedof.me provides a really nice non-flash interface that is an excellent teaching tool for showing people how TCP congestion windows work, and lets you demonstrate to people the effect of buffers in a network etc. I'll be taking notes if anyone provides anything else similar that does a similar (if not better) job, maybe one that can be self-hosted too! M? From saku at ytti.fi Tue Dec 6 13:50:57 2016 From: saku at ytti.fi (Saku Ytti) Date: Tue, 6 Dec 2016 15:50:57 +0200 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <20161206122841.GA984@Vurt.local> References: <20161202143213.GT513@Vurt.local> <20161202160243.GJ7925@dilbert.slimey.org> <20161206122841.GA984@Vurt.local> Message-ID: On 6 December 2016 at 14:28, Job Snijders wrote: > Liberal translation below. The big take-away for operators is that > service providers need to make it part of the MPLS Psuedo-wire > troubleshooting procedure to ask the customer which MACs are involved > and raise the red flag when a 4 or 6 is involved. Expect also per-vendor behaviour on ethertype values, result from one vendor: http://ytti.fi/ether_type.png Granted these are not technically ethertypes at all, but 802.3 frame length, still some other vendors don't care and pass each of these transparently. Here we can observe blackholing and policing depending on 802.3 frame length value. The same vendor here experiences packet loss on pseudowires if ethertype tells it's ipv4, ipv6, mpls, vlan and packet /does not/ contain said payload. Potentially because NPU time-cost increases too much. Vendor never really explained either behaviour. Other behavioural differences is that some vendors don't accept bad source addresses, like MCAST source address, some other vendors do. Pseudowires behaviour is highly dependent on hardware and software release in corner cases. It's easy to debate that bad MACs should be dropped, but it's also easy to argue that perhaps you're testing things, and you expect to get transparent pipe and you to test if your SUT accepts bad MACs or not. -- ++ytti From bicknell at ufp.org Tue Dec 6 13:58:11 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 6 Dec 2016 05:58:11 -0800 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: <20161202195040.GG513@Vurt.local> References: <5841A879.5050808@foobar.org> <20161202173237.GA44114@ussenterprise.ufp.org> <20161202195040.GG513@Vurt.local> Message-ID: <20161206135811.GA41277@ussenterprise.ufp.org> In a message written on Fri, Dec 02, 2016 at 08:50:40PM +0100, Job Snijders wrote: > IEEE told one of my friends: "We changed our allocation methods to > prevent vendors using unregistered mac addresses." > > Does the cost of some squatters on poorly usable MAC space outweight the > cost of the community spending countless hours tracking down where those > dropped packets went? That's the wrong question to ask. The right question is, what could have been done to prevent this entire situation? This problem has occured in all sorts of number spaces before. There have been squatters in almost every number space, boxes "optimized" based on the pattern of allocation, code bugs that went unnoticed due to part of the number space not being used. It's happened to MAC's, IP's, ports, even protocol numbers. One of the answers is to better allocate numbers. Starting at the bottom and working up is almost never the optimal solution. Various sparce allocation strategies exist which insure a wider range of addresses are used early, there is a greater chance of wacking a squatter early, and that the number space ends up more efficiently used in many cases. Had the IETF allocated a MAC starting with 0 then 2, then 4 then 6 then 8 then 10 then 12 then 14 this problem would have likely been identified early on in vendor labs when testing the pseudowire code and would have prevented the "hack" of looking deeper in the packet and guessing because too many 4 and 6 MACs were already deployed. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nanog at namor.ca Tue Dec 6 14:52:35 2016 From: nanog at namor.ca (J) Date: Tue, 06 Dec 2016 08:52:35 -0600 Subject: Favorite Speed Test Systems In-Reply-To: References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: <158d49f3ca5.e4f225f2113019.9073133744983711677@namor.ca> I've used Visualware's My Connection Server, and the stats it gives are decent. Haven't yet updated to the latest version, which seems to be require client software installation, however. http://www.myconnectionserver.com/ Have also used Ookla's, but it seems more useful to join their speedtest network, than host the standalone, now. ---- On Tue, 06 Dec 2016 07:28:55 -0600 Matthew Walster <matthew at walster.org> wrote ---- On 5 December 2016 at 14:50, Graham Johnston <johnstong at westmancom.com> wrote: > Are there others? What is your preferred one and why? > ?Generally I don't bother with speed testers unless I'm wanting a quick guesstimate -- I wouldn't recommend using them as a measure of how "fast" an internet connection is because there's always other factors in contention, and it only tests the path to the speedtester. Having said that, despite the obnoxious adverts on the site, speedof.me provides a really nice non-flash interface that is an excellent teaching tool for showing people how TCP congestion windows work, and lets you demonstrate to people the effect of buffers in a network etc. I'll be taking notes if anyone provides anything else similar that does a similar (if not better) job, maybe one that can be self-hosted too! M? From baldur.norddahl at gmail.com Tue Dec 6 15:33:17 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 6 Dec 2016 16:33:17 +0100 Subject: Favorite Speed Test Systems In-Reply-To: References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: On 05-12-2016 16:34, Nick Ryce wrote: > For testing downloads, fast.com is pretty nice > The problem with fast.com is that they use HTTPS for the test. The user needs a fast computer to decode the SSL at full speed. Even if you have a very fast computer the test will max out at 100-200 Mbps because the Netflix servers are apparently not able to encode SSL any faster. Maybe we would get better speed if multiple SSL connections were used. I just did a test on fast.com and got 150 Mbps. Click the compare on speedtest.net button and I got 940 Mbps at beta.speedtest.net. The computer is Intel i7 5820K, the OS is Ubuntu 16.04 and the internet is 1 Gbps delivered on GPON. The test runs on IPv6. We are directly peered with Netflix with 2x10G and there is plenty of capacity. It appears fast.com is on Akamai but the test itself is downloading data via our peering. Regards, Baldur From alexsm at gmail.com Tue Dec 6 13:23:01 2016 From: alexsm at gmail.com (Alex Moura) Date: Tue, 6 Dec 2016 11:23:01 -0200 Subject: Favorite Speed Test Systems In-Reply-To: References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: There is also http://speedof.me/ tool around for a while as well as: https://sourceforge.net/speedtest/ http://www.bandwidthplace.com/ http://testmy.net/ I've got a good result of 880Mbps[1] from fast.com from 6 hops away (~9ms)[2]: [1] http://pasteboard.co/6xAnRRa6F.png [2] http://pasteboard.co/6xBIViwaM.png 2016-12-06 0:38 GMT-02:00 Roland Dobbins : > On 5 Dec 2016, at 21:50, Graham Johnston wrote: > > What is your preferred one and why? >> > > > > Thorough, reasonable teat methodology, allows one to store history, decent > range of test servers worldwide. > > ----------------------------------- > Roland Dobbins > From clane1875 at gmail.com Tue Dec 6 15:08:45 2016 From: clane1875 at gmail.com (Chris Lane) Date: Tue, 6 Dec 2016 10:08:45 -0500 Subject: Looking for a Comcast engineer Message-ID: If a Comcast engineer is available mind hitting me up offline. I am not a customer, but a former customer of mine is still advertising my IP /24 out to you Comcast. the prefix belongs to our company and the former customer won't return my calls. I'd like you to remove prefix from filters. Much regards, Chris ? From andy at newslink.com Tue Dec 6 15:48:12 2016 From: andy at newslink.com (Andy Ringsmuth) Date: Tue, 6 Dec 2016 09:48:12 -0600 Subject: Canadian National Railway contact Message-ID: <6E12B224-3EDE-4360-B7E0-72B2FA921783@newslink.com> If there happens to be someone here from the Canadian National Railway, or if someone knows someone there, could you hit me up off-list? Attempting to work through an e-mail block from us to them that I?ve been unsuccessful remedying so far. Much appreciated! ---- Andy Ringsmuth andy at newslink.com News Link ? Manager Travel, Technology & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From deleskie at gmail.com Tue Dec 6 17:41:50 2016 From: deleskie at gmail.com (jim deleskie) Date: Tue, 6 Dec 2016 13:41:50 -0400 Subject: Canadian National Railway contact In-Reply-To: <6E12B224-3EDE-4360-B7E0-72B2FA921783@newslink.com> References: <6E12B224-3EDE-4360-B7E0-72B2FA921783@newslink.com> Message-ID: Have a friend that used to work there, will reach out to see if he still does. -jim On Tue, Dec 6, 2016 at 11:48 AM, Andy Ringsmuth wrote: > If there happens to be someone here from the Canadian National Railway, or > if someone knows someone there, could you hit me up off-list? > > Attempting to work through an e-mail block from us to them that I?ve been > unsuccessful remedying so far. > > Much appreciated! > > ---- > Andy Ringsmuth > andy at newslink.com > News Link ? Manager Travel, Technology & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397 (402) 304-0083 cellular > > From curtis at generous.com Wed Dec 7 00:09:16 2016 From: curtis at generous.com (Curtis Generous) Date: Tue, 06 Dec 2016 19:09:16 -0500 Subject: Favorite Speed Test Systems In-Reply-To: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: <97F4025B-3C7E-4B0C-811D-DBFE892CD8AA@generous.com> http://speedof.me/ Keeps history of past tests and is HTML5 based so no flash or java needed --curtis On 12/5/16, 9:50 AM, "NANOG on behalf of Graham Johnston" wrote: For many years we have had a local instance of the Ookla speedtest.net on our network, and while it is pretty good some other tests seem include more detailed results. I am aware of the following speedtest systems that an operator can likely have a local instance of: * Speedtest.net * Sourceforge.net/speedtest * Dslreports.com/speedtest Are there others? What is your preferred one and why? Thanks, Graham From mjo at dojo.mi.org Wed Dec 7 01:45:11 2016 From: mjo at dojo.mi.org (Mike O'Connor) Date: Tue, 6 Dec 2016 20:45:11 -0500 Subject: Favorite Speed Test Systems In-Reply-To: References: <82C0CE81789FE64D8F4D152631918297117DF32B@MSG6.westman.int> Message-ID: <20161207014511.yrttyqzqe7cxenrf@dojo.mi.org> :On 05-12-2016 16:34, Nick Ryce wrote: :> For testing downloads, fast.com is pretty nice :> : :The problem with fast.com is that they use HTTPS for the test. The user needs :a fast computer to decode the SSL at full speed. Even if you have a very fast :computer the test will max out at 100-200 Mbps because the Netflix servers :are apparently not able to encode SSL any faster. Maybe we would get better :speed if multiple SSL connections were used. I've run into the opposite problem -- fast.com sporadically reporting 1+ Gbps times for circuits that are only 20-40 Mbps. There's no obvious client-side issues -- no proxying, interesting browsers, etc. fast.com is glitchy just often enough to give some friends of mine silly glee when it misreports. -Mike -- Michael J. O'Connor mjo at dojo.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "A superhero should always speak from his diaphragm!" -The Tick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From clane1875 at gmail.com Wed Dec 7 14:03:15 2016 From: clane1875 at gmail.com (Chris Lane) Date: Wed, 7 Dec 2016 09:03:15 -0500 Subject: Fwd: Looking for a Comcast engineer In-Reply-To: References: Message-ID: Thanks to the team that reached out, this has been resolved ---------- Forwarded message ---------- From: Chris Lane Date: Tue, Dec 6, 2016 at 10:08 AM Subject: Looking for a Comcast engineer To: nanog at nanog.org If a Comcast engineer is available mind hitting me up offline. I am not a customer, but a former customer of mine is still advertising my IP /24 out to you Comcast. the prefix belongs to our company and the former customer won't return my calls. I'd like you to remove prefix from filters. Much regards, Chris ? -- Capt.Chris Lane 401.662.1875 From asuciu at arista.com Wed Dec 7 12:19:02 2016 From: asuciu at arista.com (Alexandru Suciu) Date: Wed, 7 Dec 2016 12:19:02 +0000 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: References: <20161202143213.GT513@Vurt.local> <20161202160243.GJ7925@dilbert.slimey.org> <20161206122841.GA984@Vurt.local> Message-ID: The root cause for that issue is most likely due to the following bug: BUG65077 : On the DCS-7150 series, the MPLS label of a frame may be incorrectly overwritten by a DSCP field update in the ASIC. Fixed in 4.11.7 , 4.12.6 , 4.13.0 . It was not related on the MAC values but rather the incorrect parsing of the MPLS header. On Tue, Dec 6, 2016 at 12:50 PM, Mike Jones wrote: > > MACs that didnt make it through the switch when running 4.12.3.1: > > > > 4*:**:**:**:**:** > > 6*:**:**:**:**:** > > *4:**:**:**:**:** > > *6:**:**:**:**:** > > **:**:*B:**:6*:** > > **:**:*F:**:4*:** > > Can anyone explain the last 2 for me? > > I was under the impression that this bug was mainly caused by some > optimistic attempt to detect raw IPv4 or IPv6 payloads by checking for > a version at the start of the frame. This does not explain why it > would be looking at the 5th octet. > > I also would assume that there must be something else to the last 2 > examples beyond just the B or F and 4 or 6 because otherwise it would > match way too many addresses to have not been noticed before. Perhaps > the full MAC address looks like some other protocol with a 4 byte > header? > > Thanks, > Mike > -- Regards, Alexandru Suciu From job at instituut.net Wed Dec 7 19:46:15 2016 From: job at instituut.net (Job Snijders) Date: Wed, 7 Dec 2016 20:46:15 +0100 Subject: Forwarding issues related to MACs starting with a 4 or a 6 (Was: [c-nsp] Wierd MPLS/VPLS issue) In-Reply-To: References: <20161202143213.GT513@Vurt.local> <20161202160243.GJ7925@dilbert.slimey.org> <20161206122841.GA984@Vurt.local> Message-ID: <20161207194615.GU984@Vurt.local> Dear Alexandru, > > > MACs that didnt make it through the switch when running 4.12.3.1: > > > > > > 4*:**:**:**:**:** > > > 6*:**:**:**:**:** > > > *4:**:**:**:**:** > > > *6:**:**:**:**:** > > > **:**:*B:**:6*:** > > > **:**:*F:**:4*:** > > > > Can anyone explain the last 2 for me? On Wed, Dec 07, 2016 at 12:19:02PM +0000, Alexandru Suciu via NANOG wrote: > The root cause for that issue is most likely due to the following bug: > > BUG65077 : On the DCS-7150 series, the MPLS label of a frame may be > incorrectly overwritten by a DSCP field update in the ASIC. Fixed in > 4.11.7 , 4.12.6 , 4.13.0 . > > It was not related on the MAC values but rather the incorrect parsing > of the MPLS header. That seems phrased somewhat strange. To me as end user it really does seem related to the MAC values, the NLNOG folk tested: packets destined to MAC address 4*:**:**:**:**:** do not arrive, on the other hand, same packet destined to 3*:**:**:**:**:** does arrive. Keep in mind that in this scenario the 7150 is a layer-2 switch between two MPLS PE routers. The 7150 is used as a layer-2 bridge, NOT as MPLS Label Switching Router. Packet layout probably was something like this: outer Ethernet header Dest MAC A Source MAC B Type: 0x8847 MPLS Header 1 or 2 labels inner Ethernet header Dest MAC C Source MAC D Type: 0x0800 IP src X dst Y ICMP type: request The bug in 4.12.3.1 was triggered if "MAC C" started with a 4 or a 6, but I'd expect that anything below the "outer Ethernet header" (including the MPLS header) is considered just the payload by the switch. Kind regards, Job From pingmurder at gmail.com Wed Dec 7 18:34:27 2016 From: pingmurder at gmail.com (ping murder) Date: Wed, 7 Dec 2016 12:34:27 -0600 Subject: Verizon Email Contacts Message-ID: Hello, I need to connect with an admin w/ Verizon's email abuse team. Thanks, ping From drew.weaver at thenap.com Thu Dec 8 16:09:42 2016 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 8 Dec 2016 16:09:42 +0000 Subject: Cogent Router code updates during height of ecommerce season? Message-ID: <2b97e0ebb569443d92e289601b79dd7c@EXCHANGE2K13.thenap.com> Hello, Over the last several days we have had interruptions at multiple times in our service with Cogent due to them performing router code updates on multiple nodes. I know that some companies put these sorts of updates on hold during the holiday season but I was wondering if anyone has heard of any unannounced security flaws that only larger companies such as Cogent would be privy to? I am certain that if you have heard of these flaws you cannot post the details but a simple yes or no about the existence of such a thing is plenty for me. Happy Holidays Thanks, -Drew From jared at puck.nether.net Thu Dec 8 17:25:09 2016 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 Dec 2016 12:25:09 -0500 Subject: Cogent Router code updates during height of ecommerce season? In-Reply-To: <2b97e0ebb569443d92e289601b79dd7c@EXCHANGE2K13.thenap.com> References: <2b97e0ebb569443d92e289601b79dd7c@EXCHANGE2K13.thenap.com> Message-ID: <270BD7E4-1F58-4989-9309-98C4E550F3DC@puck.nether.net> > On Dec 8, 2016, at 11:09 AM, Drew Weaver wrote: > > Hello, > > Over the last several days we have had interruptions at multiple times in our service with Cogent due to them performing router code updates on multiple nodes. I know that some companies put these sorts of updates on hold during the holiday season but I was wondering if anyone has heard of any unannounced security flaws that only larger companies such as Cogent would be privy to? > > I am certain that if you have heard of these flaws you cannot post the details but a simple yes or no about the existence of such a thing is plenty for me. Nothing I?m aware of. I know we are rolling new XR releases as well this season to address operational issues we?ve been having. I expect they are doing similar for their platforms, etc. - Jared From joly at punkcast.com Thu Dec 8 08:36:03 2016 From: joly at punkcast.com (Joly MacFie) Date: Thu, 8 Dec 2016 03:36:03 -0500 Subject: Internet Governance Forum DNS Message-ID: "www.intgovforum.org?s server DNS address could not be found." and http://downforeveryoneorjustme.com/www.intgovforum.org is negative. Any clues as to what's up? -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From dc.flatline at gmail.com Thu Dec 8 17:35:07 2016 From: dc.flatline at gmail.com (Doc Flatline) Date: Thu, 8 Dec 2016 19:35:07 +0200 Subject: Cogent Router code updates during height of ecommerce season? Message-ID: Could. https://quickview.cloudapps.cisco.com/quickview/bug/CSCtd35382 https://github.com/Sab0tag3d/SIET From mihaigabriel at gmail.com Thu Dec 8 22:20:35 2016 From: mihaigabriel at gmail.com (Mihai) Date: Thu, 8 Dec 2016 22:20:35 +0000 Subject: load balancers convergence (Radware) Message-ID: <69f9aeea-173c-adc3-64cd-efcdf13fcced@gmail.com> Hi, Sorry if this is not the right list to post but it's the last resort and any clue would be highly appreciated. I am new to LBs world and have the following active-standby topology (Alteon 5524): Router1------------Router2 | | | | eBGP eBGP | | | | Alteon1(act) Alteon2(stb) | | |_______________________| | | WEB servers - BGP local-pref is higher on the R1-A1 session. - VRRP priority is higher on Alteon1. - both Lbs advertise the same VIP address in BGP. - NAT is configured for WEB servers IPs. I am using these devices to load balance HTTP traffic and have the following issue: 1. Alteon1 fails and the traffic moves to Alteon2 without problems. 2. After Alteon1 recovers, it becomes the VRRP master due to higher priority, but the BGP session between Alteon1 and Router1 establishes after VRRP preemption (more than 1 minute after A1 becomes master) and the traffic gets dropped. I tried to use the hold-off timer to delay the VRRP preemption to match the BGP session establishment but still have ~30s downtime. Creating a direct link and BGP session between Alteons does not help as the traffic will be asymmetrical and is dropped on Alteon1. Regards From dot at dotat.at Fri Dec 9 10:24:47 2016 From: dot at dotat.at (Tony Finch) Date: Fri, 9 Dec 2016 10:24:47 +0000 Subject: Internet Governance Forum DNS In-Reply-To: References: Message-ID: Joly MacFie wrote: > www.intgovforum.org?s server DNS address could not be found. One of its three name servers doesn't exist. ; <<>> DiG 9.11.0 <<>> +norec ns www.intgovforum.org @a0.org.afilias-nst.info. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53295 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.intgovforum.org. IN NS ;; AUTHORITY SECTION: intgovforum.org. 86400 IN NS ns.vervehosting.com. intgovforum.org. 86400 IN NS ns2.vervehosting.com. intgovforum.org. 86400 IN NS ns1.vervehosting.com. ;; Query time: 251 msec ;; SERVER: 2001:500:e::1#53(2001:500:e::1) ;; WHEN: Fri Dec 09 10:22:00 GMT 2016 ;; MSG SIZE rcvd: 117 ; <<>> DiG 9.11.0 <<>> +norec ns1.vervehosting.com. @ns.vervehosting.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65348 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ns1.vervehosting.com. IN A ;; AUTHORITY SECTION: vervehosting.com. 300 IN SOA ns.vervehosting.com. ccharity.vervehosting.com. 2016061109 14400 7200 1209600 300 ;; Query time: 74 msec ;; SERVER: 108.61.21.139#53(108.61.21.139) ;; WHEN: Fri Dec 09 10:24:29 GMT 2016 ;; MSG SIZE rcvd: 97 Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Malin, Hebrides: Southerly, veering southwesterly, 6 to gale 8, occasionally 5 in southeast Malin. Rough at first, becoming very rough or high, occasionally very high later in west Hebrides. Rain then showers. Good, occasionally poor at first. From bortzmeyer at nic.fr Fri Dec 9 10:37:42 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 9 Dec 2016 11:37:42 +0100 Subject: Internet Governance Forum DNS In-Reply-To: References: Message-ID: <20161209103742.raqbyjgjuqpao5nu@nic.fr> On Thu, Dec 08, 2016 at 03:36:03AM -0500, Joly MacFie wrote a message of 13 lines which said: > "www.intgovforum.org?s server DNS address could not be found." Welcome to the UN... Updated Date: 2016-12-08T14:33:28Z It expired and was renewed yesterday (source: Internet governance civil society mailing list). But the negative TTL of .org is 24 hours... From joly at punkcast.com Fri Dec 9 11:51:33 2016 From: joly at punkcast.com (Joly MacFie) Date: Fri, 9 Dec 2016 06:51:33 -0500 Subject: Internet Governance Forum DNS In-Reply-To: <20161209103742.raqbyjgjuqpao5nu@nic.fr> References: <20161209103742.raqbyjgjuqpao5nu@nic.fr> Message-ID: Thanks. My post got moderated and thus was delayed.. The site came back up about 9:30am ET on Thursday. Just in time for day 3 of the IGF in Guadalajara. I'm guessing some strings may have been pulled. ?j ? On Fri, Dec 9, 2016 at 5:37 AM, Stephane Bortzmeyer wrote: > On Thu, Dec 08, 2016 at 03:36:03AM -0500, > Joly MacFie wrote > a message of 13 lines which said: > > > "www.intgovforum.org?s server DNS address could not be found." > > Welcome to the UN... > > Updated Date: 2016-12-08T14:33:28Z > > It expired and was renewed yesterday (source: Internet governance > civil society mailing list). But the negative TTL of .org is 24 > hours... > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From ahebert at pubnix.net Fri Dec 9 16:32:03 2016 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 9 Dec 2016 11:32:03 -0500 Subject: Canadian Legacy Subnets & ARIN - Looking for feedback Message-ID: <7cdf1afe-bbb6-61f1-a869-2a912633fd49@pubnix.net> Hi, How easy is it to resolve? We have 4-5 subnets which where erroneously assigned to our customers when ARIN took over all the NA smaller registries like UToronto. All the paperwork refer to US legalese, which we have some difficulties meshing with Canadian resources at our disposal. ( And some level of form-phobia from my part =D ) Beside that, good friday. -- ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From woody at pch.net Fri Dec 9 17:17:19 2016 From: woody at pch.net (Bill Woodcock) Date: Fri, 9 Dec 2016 09:17:19 -0800 Subject: Canadian Legacy Subnets & ARIN - Looking for feedback In-Reply-To: <7cdf1afe-bbb6-61f1-a869-2a912633fd49@pubnix.net> References: <7cdf1afe-bbb6-61f1-a869-2a912633fd49@pubnix.net> Message-ID: > On Dec 9, 2016, at 8:32 AM, Alain Hebert wrote: > We have 4-5 subnets which where erroneously assigned to our > customers when ARIN took over all the NA smaller registries like UToronto. > All the paperwork refer to US legalese, which we have some > difficulties meshing with Canadian resources at our disposal. I?ve referred this to the appropriate people at ARIN. You should receive a reply shortly. -Bill (with ARIN trustee hat on) From jcurran at arin.net Fri Dec 9 17:31:02 2016 From: jcurran at arin.net (John Curran) Date: Fri, 9 Dec 2016 17:31:02 +0000 Subject: Canadian Legacy Subnets & ARIN - Looking for feedback In-Reply-To: <7cdf1afe-bbb6-61f1-a869-2a912633fd49@pubnix.net> References: <7cdf1afe-bbb6-61f1-a869-2a912633fd49@pubnix.net> Message-ID: Alain - It shouldn't be difficult to resolve, presuming that changes were made in error. Are you the best person to work with on this, or someone else in your organization? /John John Curran President and CEO ARIN > On Dec 9, 2016, at 11:32 AM, Alain Hebert wrote: > > Hi, > > How easy is it to resolve? > > We have 4-5 subnets which where erroneously assigned to our > customers when ARIN took over all the NA smaller registries like UToronto. > > All the paperwork refer to US legalese, which we have some > difficulties meshing with Canadian resources at our disposal. > > ( And some level of form-phobia from my part =D ) > > Beside that, good friday. > > -- > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > From cscora at apnic.net Fri Dec 9 18:01:49 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Dec 2016 04:01:49 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20161209180149.3D9F4C55A1@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 10 Dec, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 625744 Prefixes after maximum aggregation (per Origin AS): 221145 Deaggregation factor: 2.83 Unique aggregates announced (without unneeded subnets): 303392 Total ASes present in the Internet Routing Table: 55416 Prefixes per ASN: 11.29 Origin-only ASes present in the Internet Routing Table: 36308 Origin ASes announcing only one prefix: 15268 Transit ASes present in the Internet Routing Table: 6548 Transit-only ASes present in the Internet Routing Table: 168 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 40 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 66 Unregistered ASNs in the Routing Table: 20 Number of 32-bit ASNs allocated by the RIRs: 16498 Number of 32-bit ASNs visible in the Routing Table: 12560 Prefixes from 32-bit ASNs in the Routing Table: 51171 Number of bogon 32-bit ASNs visible in the Routing Table: 531 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 420 Number of addresses announced to Internet: 2832567524 Equivalent to 168 /8s, 213 /16s and 140 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 207007 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156955 Total APNIC prefixes after maximum aggregation: 43049 APNIC Deaggregation factor: 3.65 Prefixes being announced from the APNIC address blocks: 171305 Unique aggregates announced from the APNIC address blocks: 70384 APNIC Region origin ASes present in the Internet Routing Table: 5185 APNIC Prefixes per ASN: 33.04 APNIC Region origin ASes announcing only one prefix: 1139 APNIC Region transit ASes present in the Internet Routing Table: 938 Average APNIC Region AS path length visible: 4.2 Max APNIC Region AS path length visible: 40 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2545 Number of APNIC addresses announced to Internet: 761026948 Equivalent to 45 /8s, 92 /16s and 89 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 188525 Total ARIN prefixes after maximum aggregation: 89408 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 195025 Unique aggregates announced from the ARIN address blocks: 89499 ARIN Region origin ASes present in the Internet Routing Table: 16118 ARIN Prefixes per ASN: 12.10 ARIN Region origin ASes announcing only one prefix: 5622 ARIN Region transit ASes present in the Internet Routing Table: 1713 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1641 Number of ARIN addresses announced to Internet: 1104672416 Equivalent to 65 /8s, 215 /16s and 246 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 150074 Total RIPE prefixes after maximum aggregation: 72764 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 161269 Unique aggregates announced from the RIPE address blocks: 98618 RIPE Region origin ASes present in the Internet Routing Table: 18161 RIPE Prefixes per ASN: 8.88 RIPE Region origin ASes announcing only one prefix: 7792 RIPE Region transit ASes present in the Internet Routing Table: 3057 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5100 Number of RIPE addresses announced to Internet: 709327232 Equivalent to 42 /8s, 71 /16s and 121 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 63552 Total LACNIC prefixes after maximum aggregation: 12594 LACNIC Deaggregation factor: 5.05 Prefixes being announced from the LACNIC address blocks: 80088 Unique aggregates announced from the LACNIC address blocks: 37900 LACNIC Region origin ASes present in the Internet Routing Table: 2482 LACNIC Prefixes per ASN: 32.27 LACNIC Region origin ASes announcing only one prefix: 547 LACNIC Region transit ASes present in the Internet Routing Table: 597 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 2993 Number of LACNIC addresses announced to Internet: 171017024 Equivalent to 10 /8s, 49 /16s and 131 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15400 Total AfriNIC prefixes after maximum aggregation: 3322 AfriNIC Deaggregation factor: 4.64 Prefixes being announced from the AfriNIC address blocks: 17637 Unique aggregates announced from the AfriNIC address blocks: 6612 AfriNIC Region origin ASes present in the Internet Routing Table: 736 AfriNIC Prefixes per ASN: 23.96 AfriNIC Region origin ASes announcing only one prefix: 168 AfriNIC Region transit ASes present in the Internet Routing Table: 179 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 281 Number of AfriNIC addresses announced to Internet: 86035968 Equivalent to 5 /8s, 32 /16s and 206 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5549 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3648 390 250 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2980 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2720 11133 740 KIXS-AS-KR Korea Telecom, KR 9829 2708 1500 539 BSNL-NIB National Internet Backbone, IN 9808 2229 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2041 428 217 TATACOMM-AS TATA Communications formerl 45899 1745 1252 92 VNPT-AS-VN VNPT Corp, VN 4808 1645 2165 468 CHINA169-BJ China Unicom Beijing Provin 24560 1574 552 229 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3590 2968 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3255 1333 83 SHAW - Shaw Communications Inc., CA 18566 2195 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1955 2017 400 CHARTER-NET-HKY-NC - Charter Communicat 30036 1784 338 335 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1714 5064 631 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6983 1677 848 227 ITCDELTA - Earthlink, Inc., US 701 1598 10629 662 UUNET - MCI Communications Services, In 16509 1504 2818 512 AMAZON-02 - Amazon.com, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3141 163 17 ALJAWWALSTC-AS , SA 20940 2954 1112 2100 AKAMAI-ASN1 , US 9121 2127 1691 18 TTNET , TR 34984 1991 328 367 TELLCOM-AS , TR 13188 1605 99 58 TRIOLAN , UA 12479 1397 1032 53 UNI2-AS , ES 6849 1286 355 22 UKRTELNET , UA 8551 1201 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 8402 1168 544 15 CORBINA-AS OJSC "Vimpelcom", RU 12389 971 1144 433 ROSTELECOM-AS , RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3538 545 148 Telmex Colombia S.A., CO 8151 2292 3371 551 Uninet S.A. de C.V., MX 11830 1798 368 66 Instituto Costarricense de Electricidad 6503 1530 437 54 Axtel, S.A.B. de C.V., MX 7303 1516 964 245 Telecom Argentina S.A., AR 6147 1098 377 27 Telefonica del Peru S.A.A., PE 28573 1046 2273 172 CLARO S.A., BR 3816 991 477 183 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 910 126 80 Alestra, S. de R.L. de C.V., MX 18881 876 1036 22 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1302 402 42 LINKdotNET-AS, EG 36903 691 347 118 MT-MPLS, MA 37611 676 67 6 Afrihost, ZA 36992 575 1373 25 ETISALAT-MISR, EG 24835 486 658 16 RAYA-AS, EG 8452 476 1472 15 TE-AS TE-AS, EG 37492 396 288 72 ORANGE-TN, TN 29571 369 37 11 CITelecom-AS, CI 15399 313 35 6 WANANCHI-KE, KE 36974 275 140 11 AFNET-AS, CI Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5549 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3648 390 250 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3590 2968 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3538 545 148 Telmex Colombia S.A., CO 6327 3255 1333 83 SHAW - Shaw Communications Inc., CA 39891 3141 163 17 ALJAWWALSTC-AS , SA 17974 2980 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2954 1112 2100 AKAMAI-ASN1 , US 4766 2720 11133 740 KIXS-AS-KR Korea Telecom, KR 9829 2708 1500 539 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3590 3438 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7545 3648 3398 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3538 3390 Telmex Colombia S.A., CO 6327 3255 3172 SHAW - Shaw Communications Inc., CA 39891 3141 3124 ALJAWWALSTC-AS , SA 17974 2980 2909 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2229 2196 CMNET-GD Guangdong Mobile Communication 9829 2708 2169 BSNL-NIB National Internet Backbone, IN 9121 2127 2109 TTNET , TR 18566 2195 2086 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 64855 PRIVATE 41.220.200.0/21 36945 mcelISP, MZ 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 27.112.96.0/22 19136 NNET, ZA 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:276 /13:529 /14:1046 /15:1794 /16:13165 /17:7822 /18:13037 /19:25317 /20:38176 /21:40692 /22:73006 /23:61135 /24:348246 /25:524 /26:405 /27:309 /28:33 /29:20 /30:17 /31:0 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3050 3255 SHAW - Shaw Communications Inc., CA 39891 2896 3141 ALJAWWALSTC-AS , SA 22773 2794 3590 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2088 2195 MEGAPATH5-US - MegaPath Corporation, US 30036 1597 1784 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 9121 1483 2127 TTNET , TR 10620 1448 3538 Telmex Colombia S.A., CO 6389 1393 2095 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1350 1605 TRIOLAN , UA 6983 1322 1677 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1582 2:821 4:24 5:2348 6:32 8:1012 12:1804 13:55 14:1775 15:24 16:2 17:103 18:127 19:1 20:51 23:2000 24:1812 27:2361 31:1812 32:83 33:11 34:1 35:3 36:361 37:2437 38:1308 39:42 40:99 41:2965 42:451 43:1919 44:51 45:2248 46:2535 47:106 49:1193 50:946 51:15 52:597 54:354 55:8 56:8 57:40 58:1559 59:981 60:389 61:1862 62:1487 63:1935 64:4533 65:2176 66:4397 67:2262 68:1159 69:3299 70:1297 71:560 72:2053 74:2594 75:402 76:414 77:1410 78:1553 79:908 80:1354 81:1420 82:1009 83:718 84:857 85:1707 86:484 87:1127 88:779 89:2038 90:204 91:6095 92:987 93:2360 94:2328 95:2780 96:577 97:357 98:941 99:93 100:147 101:1199 103:12954 104:2599 105:141 106:467 107:1486 108:782 109:2491 110:1281 111:1653 112:1155 113:1158 114:1053 115:1706 116:1684 117:1576 118:2117 119:1581 120:988 121:1098 122:2287 123:2032 124:1605 125:1832 128:736 129:477 130:431 131:1395 132:621 133:178 134:529 135:208 136:387 137:398 138:1783 139:435 140:621 141:475 142:718 143:917 144:735 145:171 146:956 147:641 148:1389 149:554 150:686 151:789 152:696 153:310 154:704 155:946 156:546 157:547 158:429 159:1326 160:562 161:731 162:2444 163:545 164:789 165:1129 166:359 167:1218 168:2352 169:680 170:2426 171:266 172:834 173:1821 174:765 175:713 176:1744 177:4115 178:2405 179:1150 180:2183 181:1934 182:2121 183:1010 184:844 185:8190 186:3250 187:2242 188:2332 189:1795 190:7859 191:1331 192:9263 193:5727 194:4549 195:3850 196:1877 197:1258 198:5594 199:5834 200:7187 201:3989 202:10141 203:9835 204:4473 205:2771 206:2996 207:3150 208:4043 209:3886 210:3892 211:2068 212:2779 213:2454 214:870 215:66 216:5753 217:1982 218:819 219:597 220:1654 221:886 222:719 223:1367 End of report From eric.kuhnke at gmail.com Fri Dec 9 19:07:21 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 9 Dec 2016 11:07:21 -0800 Subject: SNMP syslocation field for GPS coordinates, and use with automation tools Message-ID: Hello list, I'm wondering if anyone out there has been doing something like this, and what the results were like... Assuming a network with routed carrier-class CPEs for singlehomed last mile business customers, or carrier-ethernet L2 transport services for the same sort of customers. Each CPE has a full set of SNMP monitoring features and the standard syslocation field where many ISPs put the street address of the device. Has anyone out there standardized on putting GPS coordinates in this field, in decimal degrees, such as this example: 45.563694,-122.528015 (a randomly chosen location in Portland OR) Using this, it seems that one could use automation tools and scripting to populate CPE statuses and locations on a huge map, or feed into a GIS system backend (ESRI or Autodesk), which would in turn feed an interactive mapping display. Has anyone used a system such as this for NOCs to quickly identify county-sized power outages or other anomalies that affect CPEs together in specific geographic regions? Or any other examples of the use of live SNMP location data on a large scale with thousands of CPEs. From lists at mtin.net Fri Dec 9 19:30:10 2016 From: lists at mtin.net (Justin Wilson) Date: Fri, 9 Dec 2016 14:30:10 -0500 Subject: Cogent Router code updates during height of ecommerce season? In-Reply-To: <2b97e0ebb569443d92e289601b79dd7c@EXCHANGE2K13.thenap.com> References: <2b97e0ebb569443d92e289601b79dd7c@EXCHANGE2K13.thenap.com> Message-ID: Are they not doing these during maintenance windows? Anytime we get a notice from Cogent, Level3, Att they are always during a maintenance window at least a week ahead of time. We have yet to see any maintenance window notifications from Hurricane Electric. Maybe our circuit has never had to have one in a few years. Or maybe they have so much redundancy it doesn?t matter and we never see the maintenance. Justin Wilson j2sw at mtin.net --- http://www.mtin.net Owner/CEO xISP Solutions- Consulting ? Data Centers - Bandwidth http://www.midwest-ix.com COO/Chairman Internet Exchange - Peering - Distributed Fabric > On Dec 8, 2016, at 11:09 AM, Drew Weaver wrote: > > Hello, > > Over the last several days we have had interruptions at multiple times in our service with Cogent due to them performing router code updates on multiple nodes. I know that some companies put these sorts of updates on hold during the holiday season but I was wondering if anyone has heard of any unannounced security flaws that only larger companies such as Cogent would be privy to? > > I am certain that if you have heard of these flaws you cannot post the details but a simple yes or no about the existence of such a thing is plenty for me. > > Happy Holidays > > Thanks, > -Drew > From joelja at bogus.com Fri Dec 9 19:38:05 2016 From: joelja at bogus.com (joel jaeggli) Date: Fri, 9 Dec 2016 11:38:05 -0800 Subject: Cogent Router code updates during height of ecommerce season? In-Reply-To: References: <2b97e0ebb569443d92e289601b79dd7c@EXCHANGE2K13.thenap.com> Message-ID: On 12/9/16 11:30 AM, Justin Wilson wrote: > Are they not doing these during maintenance windows? Anytime we get a notice from Cogent, Level3, Att they are always during a maintenance window at least a week ahead of time. We have yet to see any maintenance window notifications from Hurricane Electric. Maybe our circuit has never had to have one in a few years. Or maybe they have so much redundancy it doesn?t matter and we never see the maintenance. FWIW I have a few Cogent circuits, The maintenance look normalish and are all scheduled per their normal process, I aware of at least one cisco bug related to source mac usage they had that was annoying if not catastrophic since it was visible on our ports. > > Justin Wilson > j2sw at mtin.net > > --- > http://www.mtin.net Owner/CEO > xISP Solutions- Consulting ? Data Centers - Bandwidth > > http://www.midwest-ix.com COO/Chairman > Internet Exchange - Peering - Distributed Fabric > >> On Dec 8, 2016, at 11:09 AM, Drew Weaver wrote: >> >> Hello, >> >> Over the last several days we have had interruptions at multiple times in our service with Cogent due to them performing router code updates on multiple nodes. I know that some companies put these sorts of updates on hold during the holiday season but I was wondering if anyone has heard of any unannounced security flaws that only larger companies such as Cogent would be privy to? >> >> I am certain that if you have heard of these flaws you cannot post the details but a simple yes or no about the existence of such a thing is plenty for me. >> >> Happy Holidays >> >> Thanks, >> -Drew >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From rfg at tristatelogic.com Fri Dec 9 20:08:34 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 09 Dec 2016 12:08:34 -0800 Subject: Avalanche botnet takedown In-Reply-To: <20161201201124.982F28E0@m0086238.ppops.net> Message-ID: <4507.1481314114@segfault.tristatelogic.com> In message <20161201201124.982F28E0 at m0086238.ppops.net>, surfer at mauigateway.com wrote: >In message <20161201124527.9BE453FD at m0087798.ppops.net>, >surfer at mauigateway.com wrote: > >>What is your suggestion to keep the sky from falling? > >My full answer, if fully elaborated, would bore you and >everybody else to tears, so I'll try to give you an >abbreviated version. > >It seems to be that it comes down to three things... >acceptance, leadership, and new thinking. >-------------------------------------------------- > >In acceptance you seem to want various laws made to >control it. Yes. >In leadership you seem to want the masses to uprise against >the "tier 1" folks and force it there. Actually, I'm not 100% sure even that would do it. Look at the banks, who are now widley loathed, and yet they still continue to get away with massive crimes and nobody is seriously punished. But wider public awarness of jsut what the problems are, and just who can and should be working to correct them would be helpful. >In new thinking you seem to want various governments to >band together to form a "law of cyber" coalition Yes. >and for a "you must be this tall to ride the internet" measurement. No, I never said that. I don't care how tall you are, or how young or how old or how whatever you are. You should be able to use the Internet. But with privledges should come some accountability, and that is entirely lacking at present. >You also mention "When is the industry going to start >admitting to itself that individual end-lusers can be >dangerous, sometimes even to the tune of $tens of millions >of dollars? In short, when is this industry going to start >vetting people..." > >I believe 'this industry' does recognize it and no one can >get a list of everyone on this planet that is allowed to >'play' on the internet. Correct. And that is a major part of the problem. >Did I get the gist of your response correct? Partially. See above. Regards, rfg From ahebert at pubnix.net Fri Dec 9 20:23:54 2016 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 9 Dec 2016 15:23:54 -0500 Subject: Canadian Legacy Subnets & ARIN - Looking for feedback In-Reply-To: References: <7cdf1afe-bbb6-61f1-a869-2a912633fd49@pubnix.net> Message-ID: <82c3f09a-7c89-1800-d5b8-07f830ae3874@pubnix.net> Hi, Yes that is the harder part, and that they date back from the UToronto days (93-96 or about). I do not think any of those faxes survived (or someone bothered archiving them on micro fiche) =D In any case, thx for the follow up. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 12/09/16 12:31, John Curran wrote: > Alain - > > It shouldn't be difficult to resolve, presuming that changes were > made in error. > > Are you the best person to work with on this, or someone else in > your organization? > > /John > > John Curran > President and CEO > ARIN > >> On Dec 9, 2016, at 11:32 AM, Alain Hebert wrote: >> >> Hi, >> >> How easy is it to resolve? >> >> We have 4-5 subnets which where erroneously assigned to our >> customers when ARIN took over all the NA smaller registries like UToronto. >> >> All the paperwork refer to US legalese, which we have some >> difficulties meshing with Canadian resources at our disposal. >> >> ( And some level of form-phobia from my part =D ) >> >> Beside that, good friday. >> >> -- >> ----- >> Alain Hebert ahebert at pubnix.net >> PubNIX Inc. >> 50 boul. St-Charles >> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 >> Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 >> From A.L.M.Buxey at lboro.ac.uk Fri Dec 9 22:09:40 2016 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Fri, 9 Dec 2016 22:09:40 +0000 Subject: SNMP syslocation field for GPS coordinates, and use with automation tools Message-ID: Yes. But don?t just put in coordinates... Put in other details and use a standard separator ? alan From jim at reptiles.org Fri Dec 9 22:11:03 2016 From: jim at reptiles.org (Jim Mercer) Date: Fri, 9 Dec 2016 17:11:03 -0500 Subject: Canadian Legacy Subnets & ARIN - Looking for feedback In-Reply-To: <82c3f09a-7c89-1800-d5b8-07f830ae3874@pubnix.net> References: <7cdf1afe-bbb6-61f1-a869-2a912633fd49@pubnix.net> <82c3f09a-7c89-1800-d5b8-07f830ae3874@pubnix.net> Message-ID: <20161209221103.GA92281@reptiles.org> On Fri, Dec 09, 2016 at 03:23:54PM -0500, Alain Hebert wrote: > Yes that is the harder part, and that they date back from the > UToronto days (93-96 or about). > > I do not think any of those faxes survived (or someone bothered > archiving them on micro fiche) =D open a dialogue with the folks at ARIN. my guess is they have a cache of documents that were forwarded to them by the likes of herb kugel and others, when the transition happened. they may not be complete, but they will likely have enough info to get you authorized to fix things up. when it comes to the legacy stuff, i've found ARIN to be fair, but thorough. --jim > > In any case, thx for the follow up. > > ----- > Alain Hebert ahebert at pubnix.net > PubNIX Inc. > 50 boul. St-Charles > P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > > On 12/09/16 12:31, John Curran wrote: > > Alain - > > > > It shouldn't be difficult to resolve, presuming that changes were > > made in error. > > > > Are you the best person to work with on this, or someone else in > > your organization? > > > > /John > > > > John Curran > > President and CEO > > ARIN > > > >> On Dec 9, 2016, at 11:32 AM, Alain Hebert wrote: > >> > >> Hi, > >> > >> How easy is it to resolve? > >> > >> We have 4-5 subnets which where erroneously assigned to our > >> customers when ARIN took over all the NA smaller registries like UToronto. > >> > >> All the paperwork refer to US legalese, which we have some > >> difficulties meshing with Canadian resources at our disposal. > >> > >> ( And some level of form-phobia from my part =D ) > >> > >> Beside that, good friday. > >> > >> -- > >> ----- > >> Alain Hebert ahebert at pubnix.net > >> PubNIX Inc. > >> 50 boul. St-Charles > >> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 > >> Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 > >> -- Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" -- Hunter S. Thompson From eric.kuhnke at gmail.com Fri Dec 9 22:30:32 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 9 Dec 2016 14:30:32 -0800 Subject: SNMP syslocation field for GPS coordinates, and use with automation tools In-Reply-To: References: Message-ID: Yes, that's along the lines of what I was thinking. Pre-define a certain number of columns of data that will fit in the snmp syslocation field in most devices (some vendors have surprisingly short string length limits, grrrrrr). And use something like a pipe delimited CSV format in that field, so it has the comma separated decimal degrees lat/long in one column, and human readable street address in another. Also worth noting that many recent SNMP-enabled, high capacity point to point microwave radios have built in GPS receivers for timing and location purposes, which gather elevation data (in meters above MSL usually). Perhaps a column for elevation in meters MSL. The sort of data that is useful for a mobile network operator with thousands of point to point RF links on rooftops and towers, for auditing and compliance purposes. On Fri, Dec 9, 2016 at 2:09 PM, Alan Buxey wrote: > Yes. But don?t just put in coordinates... Put in other details and use a > standard separator ? > > > > > > alan > From Valdis.Kletnieks at vt.edu Fri Dec 9 22:40:10 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 09 Dec 2016 17:40:10 -0500 Subject: SNMP syslocation field for GPS coordinates, and use with automation tools In-Reply-To: References: Message-ID: <78222.1481323210@turing-police.cc.vt.edu> On Fri, 09 Dec 2016 22:09:40 +0000, Alan Buxey said: > Yes. But don???t just put in coordinates... Put in other details and use a > standard separator You want to tell that to the creator of some software I recently encountered that used a non-breaking space rather than a tab, or comma, or other sane values? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From eric.kuhnke at gmail.com Fri Dec 9 22:46:27 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 9 Dec 2016 14:46:27 -0800 Subject: SNMP syslocation field for GPS coordinates, and use with automation tools In-Reply-To: <78222.1481323210@turing-police.cc.vt.edu> References: <78222.1481323210@turing-police.cc.vt.edu> Message-ID: If you think that's bad, the public copy of the entire Industry Canada licensed frequency database (for every type of radio system, nationwide) comes in a giant space delimited text file with many database fields truncated when they export it from whatever ancient database system they're using. Nevermind that the owner/control entity fields and many other fields also contain spaces. The FCC version which is much more sane and usable is a pipe delimited CSV format file with no fields cut off. On Fri, Dec 9, 2016 at 2:40 PM, wrote: > On Fri, 09 Dec 2016 22:09:40 +0000, Alan Buxey said: > > Yes. But don???t just put in coordinates... Put in other details and use > a > > standard separator > > You want to tell that to the creator of some software I recently > encountered > that used a non-breaking space rather than a tab, or comma, or other sane > values? :) > > From surfer at mauigateway.com Sat Dec 10 04:08:44 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 9 Dec 2016 20:08:44 -0800 Subject: Avalanche botnet takedown Message-ID: <20161209200844.C4003EFC@m0087791.ppops.net> I did some snippage, but I believe I kept to the idea. :: you seem to want various laws made to control it. > Yes. It's a global network. I want to say what country's laws, but see below. Also, if you want something to be broken beyond recognition get a government to regulate it. It'll be a major FAIL. :: you seem to want the masses to uprise against the :: "tier 1" folks and force it there. > Actually, I'm not 100% sure even that would do it. One the masses of the world will not rise up together for anything, much less that this. :: you seem to want various governments to band :: together to form a "law of cyber" coalition > Yes. This will never happen. Even if some did band together others will not and that would create a haven for the bad people. :: and for a "you must be this tall to ride the internet" :: measurement. > No, I never said that. I don't care how tall you are, > or how young or how old or how whatever you are. You > should be able to use the Internet. I should've been more clear. You didn't understand what I meant. > But with privledges should come some accountability, > and that is entirely lacking at present. How will you get a two year kid in Kaaawa, Oahu to obtain accountability before 'riding' the internet. :: no one can get a list of everyone on this planet that :: is allowed to 'play' on the internet. > Correct. And that is a major part of the problem. indeed... From simon.leinen at switch.ch Sat Dec 10 10:23:51 2016 From: simon.leinen at switch.ch (Simon Leinen) Date: Sat, 10 Dec 2016 11:23:51 +0100 Subject: Talk extract: Submarine cable systems 101 for AWS partners Message-ID: Amazon held their "re:Invent" event two weeks ago. Wasn't there, but I'm a James Hamilton fan so I started watching the recordings of his talks. In one, he talks about fiber optic cables under the oceans. Here's the start of that section: https://youtu.be/AyOAjFNPAbA?t=672 Even though this is presented at a suitable level for a large event (32'000 attendees total, holy cow) of mostly non-network specialists, I learned a few interesting things, e.g. about dealing with shunt faults. If you rewind to a few minutes before that section, he also talks about Amazon's private inter-DC network and how it is all (N*) 100G now. -- Simon. From beckman at angryox.com Mon Dec 12 17:36:31 2016 From: beckman at angryox.com (Peter Beckman) Date: Mon, 12 Dec 2016 12:36:31 -0500 Subject: SNMP syslocation field for GPS coordinates, and use with automation tools In-Reply-To: References: Message-ID: Since we all live on standards, I can suggest RFC7946, GeoJSON (https://tools.ietf.org/html/rfc7946) for all of your location specification needs: { "type" : "Point", "coordinates" : [ -121.556359, 39.5137752 ] } or one line (55 characters, no spaces, hopefully short enough): {"type":"Point","coordinates":[-121.556359,39.5137752]} GeoJSON supports "properties" which you can define how you like: { "type" : "Point", "coordinates" : [ -121.556359, 39.5137752 ], "properties" : { "address" : "121 Gigawatts Ave, Springfield, OH 45501 US", "hardware" : "Cisco 2924", "elevation" : "124m" } } Note that many formats now list Longitude first, Latitude second. http://www.macwright.org/lonlat/ I tend to try to offer/use machine-readable formats first, then human-readable, because I live for automation. GeoJSON benefits from being both. Beckman On Fri, 9 Dec 2016, Eric Kuhnke wrote: > Yes, that's along the lines of what I was thinking. Pre-define a certain > number of columns of data that will fit in the snmp syslocation field in > most devices (some vendors have surprisingly short string length limits, > grrrrrr). And use something like a pipe delimited CSV format in that field, > so it has the comma separated decimal degrees lat/long in one column, and > human readable street address in another. > > Also worth noting that many recent SNMP-enabled, high capacity point to > point microwave radios have built in GPS receivers for timing and location > purposes, which gather elevation data (in meters above MSL usually). > Perhaps a column for elevation in meters MSL. The sort of data that is > useful for a mobile network operator with thousands of point to point RF > links on rooftops and towers, for auditing and compliance purposes. > > On Fri, Dec 9, 2016 at 2:09 PM, Alan Buxey wrote: > >> Yes. But don?t just put in coordinates... Put in other details and use a >> standard separator ? >> >> >> >> >> >> alan >> > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From eric.kuhnke at gmail.com Mon Dec 12 17:50:01 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 12 Dec 2016 09:50:01 -0800 Subject: SNMP syslocation field for GPS coordinates, and use with automation tools In-Reply-To: References: Message-ID: This is an excellent suggestion and I'll do more research into use of the geojson format from this RFC. Looks very similar to data that can be fed through a small perl or python script to batch output google earth KML format files, to give people a quick and easy GUI overview of an area. My thought on the one line format is: {"type":"Point","coordinates":[-121.556359,39.5137752]} It may be better to just put the raw coordinates as "-121.556359,39.5137752" in a specific pipe delimited place in the snmp location string on the device, and have the python script running on the system that is batch-querying all of the devices create the geojson on its side after retrieving the coordinates, rather than putting the geojson format in the device itself. This will hopefully allow for enough length to put a full human readable street address in the syslocation field along with the gps coordinates on even the most manufacturer-hobbled of devices. As for the lat/long vs long/lat format question, that is a tough one... Many users who've been using google maps or google earth are accustomed to pasting in coordinates in a format like 39.5137,-121.5563 (lat/long), but as that URL points out a large amount of GIS software does it the other way around. I've seen a lot of other software not listed on that page which operates in the format lat,long for human data entry of coordinates, or when it uses two different fields for lat and long (in a GUI or its backend storage), always places the lat field first and long second. On Mon, Dec 12, 2016 at 9:36 AM, Peter Beckman wrote: > Since we all live on standards, I can suggest RFC7946, GeoJSON > (https://tools.ietf.org/html/rfc7946) for all of your location > specification > needs: > > { > "type" : "Point", > "coordinates" : [ > -121.556359, > 39.5137752 > ] > } > > or one line (55 characters, no spaces, hopefully short enough): > > {"type":"Point","coordinates":[-121.556359,39.5137752]} > > GeoJSON supports "properties" which you can define how you like: > > { > "type" : "Point", > "coordinates" : [ > -121.556359, > 39.5137752 > ], > "properties" : { > "address" : "121 Gigawatts Ave, Springfield, OH > 45501 US", > "hardware" : "Cisco 2924", > "elevation" : "124m" > } > } > > Note that many formats now list Longitude first, Latitude second. > http://www.macwright.org/lonlat/ > > I tend to try to offer/use machine-readable formats first, then > human-readable, > because I live for automation. GeoJSON benefits from being both. > > Beckman > > > On Fri, 9 Dec 2016, Eric Kuhnke wrote: > > Yes, that's along the lines of what I was thinking. Pre-define a certain >> number of columns of data that will fit in the snmp syslocation field in >> most devices (some vendors have surprisingly short string length limits, >> grrrrrr). And use something like a pipe delimited CSV format in that >> field, >> so it has the comma separated decimal degrees lat/long in one column, and >> human readable street address in another. >> >> Also worth noting that many recent SNMP-enabled, high capacity point to >> point microwave radios have built in GPS receivers for timing and location >> purposes, which gather elevation data (in meters above MSL usually). >> Perhaps a column for elevation in meters MSL. The sort of data that is >> useful for a mobile network operator with thousands of point to point RF >> links on rooftops and towers, for auditing and compliance purposes. >> >> On Fri, Dec 9, 2016 at 2:09 PM, Alan Buxey >> wrote: >> >> Yes. But don?t just put in coordinates... Put in other details and use a >>> standard separator ? >>> >>> >>> >>> >>> >>> alan >>> >>> >> > ------------------------------------------------------------ > --------------- > Peter Beckman Internet Guy > beckman at angryox.com > http://www.angryox.com/ > ------------------------------------------------------------ > --------------- From fmartin at linkedin.com Mon Dec 12 18:39:15 2016 From: fmartin at linkedin.com (Franck Martin) Date: Mon, 12 Dec 2016 10:39:15 -0800 Subject: Build an anycast network on a shoestring Message-ID: This is quite a nice write up by a colleague of mine: https://www.linkedin.com/pulse/build-your-own-anycast-network-9-steps-samir-jafferali From chris at nifry.com Mon Dec 12 19:27:22 2016 From: chris at nifry.com (chris) Date: Mon, 12 Dec 2016 19:27:22 +0000 Subject: Build an anycast network on a shoestring Message-ID: ?@natmorris did something similar 18 months to 2 years or so ago too? ?video below from uknof 30 .. https://youtu.be/itEtjsauwFQ Sent from Samsung Mobile on O2 -------- Original message --------From: Franck Martin via NANOG Date: 12/12/2016 18:39 (GMT+00:00) To: NANOG Subject: Build an anycast network on a shoestring This is quite a nice write up by a colleague of mine: https://www.linkedin.com/pulse/build-your-own-anycast-network-9-steps-samir-jafferali From theodore at ciscodude.net Mon Dec 12 21:59:29 2016 From: theodore at ciscodude.net (Theodore Baschak) Date: Mon, 12 Dec 2016 15:59:29 -0600 Subject: Build an anycast network on a shoestring In-Reply-To: References: Message-ID: Wow thanks for sharing both of these. Anycast can be "black magic" sometimes, and the more that is known about it by operators the better. I'm somewhat surprised that ECMP I've done a little poor-mans anycasting within a network by simply using OSPF and some /32's. Had IPv4 space not been at such a premium when I got into the game, I would have definitely attempted to get a larger block so that I could anycast a /24 of it. :-( Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/ On Mon, Dec 12, 2016 at 1:27 PM, chris wrote: > @natmorris did something similar 18 months to 2 years or so ago too > video below from uknof 30 .. > > https://youtu.be/itEtjsauwFQ > > > Sent from Samsung Mobile on O2 > -------- Original message --------From: Franck Martin via NANOG < > nanog at nanog.org> Date: 12/12/2016 18:39 (GMT+00:00) To: NANOG < > nanog at nanog.org> Subject: Build an anycast network on a shoestring > This is quite a nice write up by a colleague of mine: > https://www.linkedin.com/pulse/build-your-own-anycast- > network-9-steps-samir-jafferali > From woody at pch.net Mon Dec 12 23:29:49 2016 From: woody at pch.net (Bill Woodcock) Date: Mon, 12 Dec 2016 15:29:49 -0800 Subject: Build an anycast network on a shoestring In-Reply-To: References: Message-ID: > On Dec 12, 2016, at 1:59 PM, Theodore Baschak wrote: > > Wow thanks for sharing both of these. Anycast can be "black magic" > sometimes, and the more that is known about it by operators the better. Honestly, it?s not that difficult? Here are a few papers from quite a while ago, when some of the lessons were a little more recently-learned: https://www.pch.net/resources/Papers/anycast/ https://www.pch.net/resources/Papers/dns-service-architecture/dns-service-architecture-v11.pdf -Bill From hugo at slabnet.com Mon Dec 12 23:31:57 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Mon, 12 Dec 2016 15:31:57 -0800 Subject: Build an anycast network on a shoestring In-Reply-To: References: Message-ID: <20161212233157.GC16300@bamboo.slabnet.com> If you're doing ECMP w/i the DC, PMTUD does come to mind, though: https://blog.cloudflare.com/path-mtu-discovery-in-practice/ -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On Mon 2016-Dec-12 15:59:29 -0600, Theodore Baschak wrote: >Wow thanks for sharing both of these. Anycast can be "black magic" >sometimes, and the more that is known about it by operators the better. I'm >somewhat surprised that ECMP >I've done a little poor-mans anycasting within a network by simply using >OSPF and some /32's. Had IPv4 space not been at such a premium when I got >into the game, I would have definitely attempted to get a larger block so >that I could anycast a /24 of it. :-( > > >Theodore Baschak - AS395089 - Hextet Systems >https://ciscodude.net/ - https://hextet.systems/ >http://mbix.ca/ > > >On Mon, Dec 12, 2016 at 1:27 PM, chris wrote: > >> @natmorris did something similar 18 months to 2 years or so ago too >> video below from uknof 30 .. >> >> https://youtu.be/itEtjsauwFQ >> >> >> Sent from Samsung Mobile on O2 >> -------- Original message --------From: Franck Martin via NANOG < >> nanog at nanog.org> Date: 12/12/2016 18:39 (GMT+00:00) To: NANOG < >> nanog at nanog.org> Subject: Build an anycast network on a shoestring >> This is quite a nice write up by a colleague of mine: >> https://www.linkedin.com/pulse/build-your-own-anycast- >> network-9-steps-samir-jafferali >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From gdt at gdt.id.au Sun Dec 11 21:32:56 2016 From: gdt at gdt.id.au (Glen Turner) Date: Mon, 12 Dec 2016 08:32:56 +1100 Subject: SNMP syslocation field for GPS coordinates, and use with automation tools In-Reply-To: References: Message-ID: <1481491976.2171.7.camel@gdt.id.au> Eric Kuhnke wrote: > Has anyone out there standardized on putting GPS coordinates in this > field [SNMP sysLocation] See also: the LOC record type in DNS. -glen From p.bonvin at edsi-tech.com Tue Dec 13 19:17:54 2016 From: p.bonvin at edsi-tech.com (Philippe Bonvin) Date: Tue, 13 Dec 2016 19:17:54 +0000 Subject: Build an anycast network on a shoestring In-Reply-To: <20161212233157.GC16300@bamboo.slabnet.com> References: , <20161212233157.GC16300@bamboo.slabnet.com> Message-ID: <1481656676937.35617@edsi-tech.com> I've also set up an anycast AS, based on the work of others, notably Nat Morris. If you are looking for providers that are willing to peer with your VPS over BGP, you can check the IRR records of AS204248: whois -r AS204248 But you need to manually check for best routing paths, which can be a slow process. Using the nlnog ring is a great help when dealing with routings issues on an anycast network. I'm available if somebody need help with that. _________________________________ From: NANOG on behalf of Hugo Slabbert Sent: Tuesday, December 13, 2016 00:31 To: Theodore Baschak Cc: NANOG Operators' Group Subject: Re: Build an anycast network on a shoestring If you're doing ECMP w/i the DC, PMTUD does come to mind, though: https://blog.cloudflare.com/path-mtu-discovery-in-practice/ -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On Mon 2016-Dec-12 15:59:29 -0600, Theodore Baschak wrote: >Wow thanks for sharing both of these. Anycast can be "black magic" >sometimes, and the more that is known about it by operators the better. I'm >somewhat surprised that ECMP >I've done a little poor-mans anycasting within a network by simply using >OSPF and some /32's. Had IPv4 space not been at such a premium when I got >into the game, I would have definitely attempted to get a larger block so >that I could anycast a /24 of it. :-( > > >Theodore Baschak - AS395089 - Hextet Systems >https://ciscodude.net/ - https://hextet.systems/ >http://mbix.ca/ > > >On Mon, Dec 12, 2016 at 1:27 PM, chris wrote: > >> @natmorris did something similar 18 months to 2 years or so ago too >> video below from uknof 30 .. >> >> https://youtu.be/itEtjsauwFQ >> >> >> Sent from Samsung Mobile on O2 >> -------- Original message --------From: Franck Martin via NANOG < >> nanog at nanog.org> Date: 12/12/2016 18:39 (GMT+00:00) To: NANOG < >> nanog at nanog.org> Subject: Build an anycast network on a shoestring >> This is quite a nice write up by a colleague of mine: >> https://www.linkedin.com/pulse/build-your-own-anycast- >> network-9-steps-samir-jafferali >> [EDSI-Tech Sarl] Philippe Bonvin, Directeur EDSI-Tech S?rl EPFL Innovation Park, Batiment C, 1015 Lausanne, Suisse | T?l?phone: +41 (0) 21 566 14 15, ext. 99 Savoie Technolac, 17 Avenue du Lac L?man, 73375 Le Bourget-du-Lac, France | T?l?phone: +33 (0)4 86 15 44 78, ext. 99 Disclaimer: This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this information, be advised that you have received this email in error and that any usage, disclosure, distribution, copying of the information or any part of it in any form whatsoever is strictly prohibited. If you have received this email in error please notify the EDSI-Tech helpdesk by phone on +41 21 566 14 15 and then delete this e-mail. From kiwi at oav.net Wed Dec 14 07:11:25 2016 From: kiwi at oav.net (Xavier Beaudouin) Date: Wed, 14 Dec 2016 08:11:25 +0100 (CET) Subject: DTAG / AS 3320 needed some contacts. Message-ID: <749463693.79273.1481699485557.JavaMail.zimbra@oav.net> Hello there, My company has some issue with probably null routed IP that is maybe used or related to mirai issues. Is some network operator can contact me in private, I have an issue to check with an DTAG / AS 3320 operator. Kind regards from France, Xavier From amps at djlab.com Wed Dec 14 19:16:41 2016 From: amps at djlab.com (Randy) Date: Wed, 14 Dec 2016 11:16:41 -0800 Subject: Cogent NOC Message-ID: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> Hi all, Anyone beyond front line support at cogento on list? Nanog is the last place I'd look for assistance but it seems support over at cogentco is not nearly what it used to be. Example MTR to cogen't own website (support doesn't utilize or understand MTR at all apparently): Host Loss% Snt Last Avg Best Wrst StDev 1. x.x.x.x 0.0% 196 0.5 11.7 0.3 186.8 35.2 2. x.x.x.x 0.0% 196 0.6 10.2 0.4 226.3 36.2 3. 38.88.249.209 0.0% 196 0.9 1.1 0.7 17.7 1.2 4. te0-0-2-3.nr13.b023801-0.iad01.atl 0.0% 196 1.0 1.0 0.8 2.0 0.1 5. te0-0-0-1.rcr22.iad01.atlas.cogent 2.0% 196 2.1 1.9 1.0 3.3 0.4 6. be2961.ccr41.iad02.atlas.cogentco. 2.6% 196 1.8 2.1 1.1 3.8 0.5 7. be2954.rcr21.iad03.atlas.cogentco. 2.6% 196 2.0 2.3 1.2 9.4 0.7 8. be2952.agr11.iad03.atlas.cogentco. 0.5% 196 2.7 2.6 1.5 6.8 0.6 9. cogentco.com 4.1% 196 2.1 2.0 1.0 16.8 1.1 Pretty much the same to anywhere. Packet loss begins at rcr22.iad01 and propagates all the way down the line. Worse during peak hours, gone late at night. After three days of no email response for my ticket, I called and after an hour of my life I want back, front line support cannot reproduce the loss. Final conclusion: "Your host is dropping packets". -- ~Randy From listas at kurtkraut.net Wed Dec 14 19:53:56 2016 From: listas at kurtkraut.net (Kurt Kraut) Date: Wed, 14 Dec 2016 17:53:56 -0200 Subject: Cogent NOC In-Reply-To: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> References: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> Message-ID: Hello, mtr packet loss column has no scientific precision and should not be considered. It is not mtr fault but forwarding routers have a low priority to respond to ICMP requests. The only way you can prove there is a problem is a end to end ping, the regular ping command, not mtr. Best regards, Kurt Kraut 2016-12-14 17:16 GMT-02:00 Randy : > Hi all, > > Anyone beyond front line support at cogento on list? > > Nanog is the last place I'd look for assistance but it seems support over > at cogentco is not nearly what it used to be. > > Example MTR to cogen't own website (support doesn't utilize or understand > MTR at all apparently): > > Host Loss% Snt Last Avg Best Wrst > StDev > 1. x.x.x.x 0.0% 196 0.5 11.7 0.3 > 186.8 35.2 > 2. x.x.x.x 0.0% 196 0.6 10.2 0.4 > 226.3 36.2 > 3. 38.88.249.209 0.0% 196 0.9 1.1 0.7 > 17.7 1.2 > 4. te0-0-2-3.nr13.b023801-0.iad01.atl 0.0% 196 1.0 1.0 0.8 > 2.0 0.1 > 5. te0-0-0-1.rcr22.iad01.atlas.cogent 2.0% 196 2.1 1.9 1.0 > 3.3 0.4 > 6. be2961.ccr41.iad02.atlas.cogentco. 2.6% 196 1.8 2.1 1.1 > 3.8 0.5 > 7. be2954.rcr21.iad03.atlas.cogentco. 2.6% 196 2.0 2.3 1.2 > 9.4 0.7 > 8. be2952.agr11.iad03.atlas.cogentco. 0.5% 196 2.7 2.6 1.5 > 6.8 0.6 > 9. cogentco.com 4.1% 196 2.1 2.0 1.0 > 16.8 1.1 > > Pretty much the same to anywhere. Packet loss begins at rcr22.iad01 and > propagates all the way down the line. Worse during peak hours, gone late > at night. > > After three days of no email response for my ticket, I called and after an > hour of my life I want back, front line support cannot reproduce the loss. > Final conclusion: "Your host is dropping packets". > > -- > ~Randy > From amps at djlab.com Wed Dec 14 20:04:39 2016 From: amps at djlab.com (Randy) Date: Wed, 14 Dec 2016 12:04:39 -0800 Subject: Cogent NOC In-Reply-To: References: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> Message-ID: <2733588f7d06873a8a3aec155cafbf36@mailbox.fastserv.com> On 12/14/2016 11:53 am, Kurt Kraut wrote: > Hello, > > mtr packet loss column has no scientific precision and should not be considered. It is not mtr fault but forwarding routers have a low priority to respond to ICMP requests. The only way you can prove there is a problem is a end to end ping, the regular ping command, not mtr. (understood, however FYI,) Also reproduced the results with pings walking them down the line up to and including the actual host. The MTR example provided is simply the clearest representation of the ping results which show the same. ~Randy From math at sizone.org Wed Dec 14 20:08:52 2016 From: math at sizone.org (Ken Chase) Date: Wed, 14 Dec 2016 15:08:52 -0500 Subject: Cogent NOC In-Reply-To: References: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> Message-ID: <20161214200852.GU11251@sizone.org> I was going to reply and repeat Job Snijders's indications of Thu, 7 Jul 2016 to Please review the excellent presentation from RA{T,S}: https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf https://www.youtube.com/watch?v=a1IaRAVGPEE esp the pdf there, but in this case Randy's mtr does do a ping to the last hop. He did have 4.1% pl to the endpoint for his specific setup and current gear/route/etc. However, I go through the same hostname'd router he does (he didnt provide an ip, but paris-traceroute doesnt show me load balancing, at least visibly), and I only get 0.3% pl. (Though, my immediate upstream DSL provider's router is giving me 0.2% pl, so who knows what that 0.3% means at the far end, really.) Without bidirectional concurrent mtr's (one from cogent back to him at the same time), it's quite hard to say what's going on. Even then that's no guarantee of diagnosis. Here's just the most recent thread with some depth on how to read traces and packetloss: http://seclists.org/nanog/2016/Jul/155 the whole thread is useful. But is only one of the dozens of times this has come up on nanog. (Again: read that pdf!) /kc On Wed, Dec 14, 2016 at 05:53:56PM -0200, Kurt Kraut said: >Hello, > > >mtr packet loss column has no scientific precision and should not be >considered. It is not mtr fault but forwarding routers have a low priority >to respond to ICMP requests. The only way you can prove there is a problem >is a end to end ping, the regular ping command, not mtr. > > >Best regards, > > >Kurt Kraut > >2016-12-14 17:16 GMT-02:00 Randy : > >> Hi all, >> >> Anyone beyond front line support at cogento on list? >> >> Nanog is the last place I'd look for assistance but it seems support over >> at cogentco is not nearly what it used to be. >> >> Example MTR to cogen't own website (support doesn't utilize or understand >> MTR at all apparently): >> >> Host Loss% Snt Last Avg Best Wrst >> StDev >> 1. x.x.x.x 0.0% 196 0.5 11.7 0.3 >> 186.8 35.2 >> 2. x.x.x.x 0.0% 196 0.6 10.2 0.4 >> 226.3 36.2 >> 3. 38.88.249.209 0.0% 196 0.9 1.1 0.7 >> 17.7 1.2 >> 4. te0-0-2-3.nr13.b023801-0.iad01.atl 0.0% 196 1.0 1.0 0.8 >> 2.0 0.1 >> 5. te0-0-0-1.rcr22.iad01.atlas.cogent 2.0% 196 2.1 1.9 1.0 >> 3.3 0.4 >> 6. be2961.ccr41.iad02.atlas.cogentco. 2.6% 196 1.8 2.1 1.1 >> 3.8 0.5 >> 7. be2954.rcr21.iad03.atlas.cogentco. 2.6% 196 2.0 2.3 1.2 >> 9.4 0.7 >> 8. be2952.agr11.iad03.atlas.cogentco. 0.5% 196 2.7 2.6 1.5 >> 6.8 0.6 >> 9. cogentco.com 4.1% 196 2.1 2.0 1.0 >> 16.8 1.1 >> >> Pretty much the same to anywhere. Packet loss begins at rcr22.iad01 and >> propagates all the way down the line. Worse during peak hours, gone late >> at night. >> >> After three days of no email response for my ticket, I called and after an >> hour of my life I want back, front line support cannot reproduce the loss. >> Final conclusion: "Your host is dropping packets". >> >> -- >> ~Randy >> -- Ken Chase - math at sizone.org Guelph Canada From amps at djlab.com Wed Dec 14 20:15:52 2016 From: amps at djlab.com (Randy) Date: Wed, 14 Dec 2016 12:15:52 -0800 Subject: Cogent NOC In-Reply-To: References: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> Message-ID: <9aaa2b58b5b5d927c9368113a20c1da8@mailbox.fastserv.com> Walking the line, so to speak. Starting with our directly connected cogent peer. Loss begins at the same hop and carries through to the end host. I'm only using cogentco as an example, but the results are the same anywhere. [root at mon ~]# ping -c 1000 -f 38.88.249.209 PING 38.88.249.209 (38.88.249.209) 56(84) bytes of data. --- 38.88.249.209 ping statistics --- 1000 packets transmitted, 1000 received, 0% packet loss, time 765ms rtt min/avg/max/mdev = 0.422/0.703/3.064/0.273 ms, ipg/ewma 0.765/0.648 ms [root at mon ~]# ping -c 1000 -f 154.24.36.5 PING 154.24.36.5 (154.24.36.5) 56(84) bytes of data. --- 154.24.36.5 ping statistics --- 1000 packets transmitted, 1000 received, 0% packet loss, time 754ms rtt min/avg/max/mdev = 0.523/0.699/2.958/0.190 ms, ipg/ewma 0.755/0.663 ms [root at mon ~]# ping -c 1000 -f 154.24.36.21 PING 154.24.36.21 (154.24.36.21) 56(84) bytes of data. ..... --- 154.24.36.21 ping statistics --- 1000 packets transmitted, 995 received, 0% packet loss, time 1473ms rtt min/avg/max/mdev = 0.718/1.330/3.471/0.461 ms, ipg/ewma 1.475/1.611 ms [root at mon ~]# ping -c 1000 -f 154.54.42.105 PING 154.54.42.105 (154.54.42.105) 56(84) bytes of data. ........ --- 154.54.42.105 ping statistics --- 1000 packets transmitted, 992 received, 0% packet loss, time 1996ms rtt min/avg/max/mdev = 0.884/1.794/6.813/0.626 ms, ipg/ewma 1.998/1.983 ms [root at mon ~]# ping -c 1000 -f 154.54.7.54 PING 154.54.7.54 (154.54.7.54) 56(84) bytes of data. ..... --- 154.54.7.54 ping statistics --- 1000 packets transmitted, 995 received, 0% packet loss, time 2376ms rtt min/avg/max/mdev = 1.202/2.227/5.847/0.901 ms, ipg/ewma 2.378/1.465 ms [root at mon ~]# ping -c 1000 -f 154.54.0.82 PING 154.54.0.82 (154.54.0.82) 56(84) bytes of data. ......... --- 154.54.0.82 ping statistics --- 1000 packets transmitted, 991 received, 0% packet loss, time 2766ms rtt min/avg/max/mdev = 1.178/2.530/6.219/0.831 ms, ipg/ewma 2.769/2.583 ms [root at mon ~]# ping -c 1000 -f 38.100.128.10 PING 38.100.128.10 (38.100.128.10) 56(84) bytes of data. ..... --- 38.100.128.10 ping statistics --- 1000 packets transmitted, 995 received, 0% packet loss, time 1730ms rtt min/avg/max/mdev = 0.835/1.548/19.553/0.717 ms, ipg/ewma 1.732/1.077 ms >> After three days of no email response for my ticket, I called and >> after an hour of my life I want back, front line support cannot >> reproduce the loss. Final conclusion: "Your host is dropping >> packets". >> >> -- >> ~Randy From nanog at ics-il.net Wed Dec 14 20:18:10 2016 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 14 Dec 2016 14:18:10 -0600 (CST) Subject: Cogent NOC In-Reply-To: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> References: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> Message-ID: <850801708.8420.1481746688596.JavaMail.mhammett@ThunderFuck> I think people are just going to see a traceroute determining packet loss and not going to read the rest of what happened. Just going to shortcut to an answer. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Randy" To: "Nanog" Sent: Wednesday, December 14, 2016 1:16:41 PM Subject: Cogent NOC Hi all, Anyone beyond front line support at cogento on list? Nanog is the last place I'd look for assistance but it seems support over at cogentco is not nearly what it used to be. Example MTR to cogen't own website (support doesn't utilize or understand MTR at all apparently): Host Loss% Snt Last Avg Best Wrst StDev 1. x.x.x.x 0.0% 196 0.5 11.7 0.3 186.8 35.2 2. x.x.x.x 0.0% 196 0.6 10.2 0.4 226.3 36.2 3. 38.88.249.209 0.0% 196 0.9 1.1 0.7 17.7 1.2 4. te0-0-2-3.nr13.b023801-0.iad01.atl 0.0% 196 1.0 1.0 0.8 2.0 0.1 5. te0-0-0-1.rcr22.iad01.atlas.cogent 2.0% 196 2.1 1.9 1.0 3.3 0.4 6. be2961.ccr41.iad02.atlas.cogentco. 2.6% 196 1.8 2.1 1.1 3.8 0.5 7. be2954.rcr21.iad03.atlas.cogentco. 2.6% 196 2.0 2.3 1.2 9.4 0.7 8. be2952.agr11.iad03.atlas.cogentco. 0.5% 196 2.7 2.6 1.5 6.8 0.6 9. cogentco.com 4.1% 196 2.1 2.0 1.0 16.8 1.1 Pretty much the same to anywhere. Packet loss begins at rcr22.iad01 and propagates all the way down the line. Worse during peak hours, gone late at night. After three days of no email response for my ticket, I called and after an hour of my life I want back, front line support cannot reproduce the loss. Final conclusion: "Your host is dropping packets". -- ~Randy From bryan at shout.net Wed Dec 14 23:42:05 2016 From: bryan at shout.net (Bryan Holloway) Date: Wed, 14 Dec 2016 17:42:05 -0600 Subject: Cogent NOC In-Reply-To: <850801708.8420.1481746688596.JavaMail.mhammett@ThunderFuck> References: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> <850801708.8420.1481746688596.JavaMail.mhammett@ThunderFuck> Message-ID: <0f5a4026-7436-9821-de32-9e30a8912abb@shout.net> Odd, though, that they didn't respond for three days. I've typically had good luck with that, although admittedly it's been months since I've opened an e-mail ticket with their NOC. Spam-filter? On 12/14/16 2:18 PM, Mike Hammett wrote: > I think people are just going to see a traceroute determining packet loss and not going to read the rest of what happened. Just going to shortcut to an answer. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Randy" > To: "Nanog" > Sent: Wednesday, December 14, 2016 1:16:41 PM > Subject: Cogent NOC > > Hi all, > > Anyone beyond front line support at cogento on list? > > Nanog is the last place I'd look for assistance but it seems support > over at cogentco is not nearly what it used to be. > > Example MTR to cogen't own website (support doesn't utilize or > understand MTR at all apparently): > > Host Loss% Snt Last Avg Best > Wrst StDev > 1. x.x.x.x 0.0% 196 0.5 11.7 0.3 > 186.8 35.2 > 2. x.x.x.x 0.0% 196 0.6 10.2 0.4 > 226.3 36.2 > 3. 38.88.249.209 0.0% 196 0.9 1.1 0.7 > 17.7 1.2 > 4. te0-0-2-3.nr13.b023801-0.iad01.atl 0.0% 196 1.0 1.0 0.8 > 2.0 0.1 > 5. te0-0-0-1.rcr22.iad01.atlas.cogent 2.0% 196 2.1 1.9 1.0 > 3.3 0.4 > 6. be2961.ccr41.iad02.atlas.cogentco. 2.6% 196 1.8 2.1 1.1 > 3.8 0.5 > 7. be2954.rcr21.iad03.atlas.cogentco. 2.6% 196 2.0 2.3 1.2 > 9.4 0.7 > 8. be2952.agr11.iad03.atlas.cogentco. 0.5% 196 2.7 2.6 1.5 > 6.8 0.6 > 9. cogentco.com 4.1% 196 2.1 2.0 1.0 > 16.8 1.1 > > Pretty much the same to anywhere. Packet loss begins at rcr22.iad01 > and propagates all the way down the line. Worse during peak hours, > gone late at night. > > After three days of no email response for my ticket, I called and after > an hour of my life I want back, front line support cannot reproduce the > loss. Final conclusion: "Your host is dropping packets". > From amps at djlab.com Wed Dec 14 23:56:54 2016 From: amps at djlab.com (Randy) Date: Wed, 14 Dec 2016 15:56:54 -0800 Subject: Cogent NOC In-Reply-To: <0f5a4026-7436-9821-de32-9e30a8912abb@shout.net> References: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> <850801708.8420.1481746688596.JavaMail.mhammett@ThunderFuck> <0f5a4026-7436-9821-de32-9e30a8912abb@shout.net> Message-ID: <8351e78ff642d007d942ce63edd5da93@mailbox.fastserv.com> On 12/14/2016 3:42 pm, Bryan Holloway wrote: > Odd, though, that they didn't respond for three days. I've typically > had good luck with that, although admittedly it's been months since > I've opened an e-mail ticket with their NOC. Spam-filter? > No, I got a confirmation and ticket ID immediately. Three days later I call it in and they pull it up, sure enough nobody took ownership. Same thing happened about a month ago. Seems email ticket priority is zero. You HAVE to call to get any kind of action. And it also seems the front line techs are not as skilled as before -- basic pinging and questionable understanding of traceroutes / asymmetrical routing. It didn't used to be this way. ~Randy From NANOG at BRIANDENT.COM Mon Dec 12 16:35:29 2016 From: NANOG at BRIANDENT.COM (Brian J. Dent) Date: Mon, 12 Dec 2016 08:35:29 -0800 Subject: ChangeIP.com has been down for 20+ hours Message-ID: <0CDCB07FD2F8463B9A18B67FF4907E49.MAI@COMPUDENT.US> From andrew at paolucci.ca Wed Dec 14 19:59:53 2016 From: andrew at paolucci.ca (Andrew Paolucci) Date: Wed, 14 Dec 2016 14:59:53 -0500 Subject: Cogent NOC In-Reply-To: References: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> Message-ID: If the loss is seen towards a terminating webserver maybe spool curl response times over the course of a day and correlated that to observed loss via a smokeping service. Support may be more responsive with some hard statistics. Regards, Andrew Paolucci Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- Original Message -------- Subject: Re: Cogent NOC Local Time: December 14, 2016 2:53 PM UTC Time: December 14, 2016 7:53 PM From: listas at kurtkraut.net To: amps at djlab.com Nanog Hello, mtr packet loss column has no scientific precision and should not be considered. It is not mtr fault but forwarding routers have a low priority to respond to ICMP requests. The only way you can prove there is a problem is a end to end ping, the regular ping command, not mtr. Best regards, Kurt Kraut 2016-12-14 17:16 GMT-02:00 Randy : > Hi all, > > Anyone beyond front line support at cogento on list? > > Nanog is the last place I'd look for assistance but it seems support over > at cogentco is not nearly what it used to be. > > Example MTR to cogen't own website (support doesn't utilize or understand > MTR at all apparently): > > Host Loss% Snt Last Avg Best Wrst > StDev > 1. x.x.x.x 0.0% 196 0.5 11.7 0.3 > 186.8 35.2 > 2. x.x.x.x 0.0% 196 0.6 10.2 0.4 > 226.3 36.2 > 3. 38.88.249.209 0.0% 196 0.9 1.1 0.7 > 17.7 1.2 > 4. te0-0-2-3.nr13.b023801-0.iad01.atl 0.0% 196 1.0 1.0 0.8 > 2.0 0.1 > 5. te0-0-0-1.rcr22.iad01.atlas.cogent 2.0% 196 2.1 1.9 1.0 > 3.3 0.4 > 6. be2961.ccr41.iad02.atlas.cogentco. 2.6% 196 1.8 2.1 1.1 > 3.8 0.5 > 7. be2954.rcr21.iad03.atlas.cogentco. 2.6% 196 2.0 2.3 1.2 > 9.4 0.7 > 8. be2952.agr11.iad03.atlas.cogentco. 0.5% 196 2.7 2.6 1.5 > 6.8 0.6 > 9. cogentco.com 4.1% 196 2.1 2.0 1.0 > 16.8 1.1 > > Pretty much the same to anywhere. Packet loss begins at rcr22.iad01 and > propagates all the way down the line. Worse during peak hours, gone late > at night. > > After three days of no email response for my ticket, I called and after an > hour of my life I want back, front line support cannot reproduce the loss. > Final conclusion: "Your host is dropping packets". > > -- > ~Randy > From pingmurder at gmail.com Wed Dec 14 22:19:04 2016 From: pingmurder at gmail.com (ping murder) Date: Wed, 14 Dec 2016 16:19:04 -0600 Subject: DOS for hire issues Message-ID: Hello, One of the hosting brands we recently acquired is overrun with DOS for hire providers and individuals. We kill them as they alert however I'm curious if there's a discussion group or location, contacts, etc we might be able to coordinate in about the actors behind these accounts (assuming this isn't the right place for that, however has a lot of the right people). If I'm out of my lane, forgive me. Thanks, pm From jayfar at jayfar.com Thu Dec 15 02:24:42 2016 From: jayfar at jayfar.com (Jay Farrell) Date: Wed, 14 Dec 2016 21:24:42 -0500 Subject: ChangeIP.com has been down for 20+ hours In-Reply-To: <0CDCB07FD2F8463B9A18B67FF4907E49.MAI@COMPUDENT.US> References: <0CDCB07FD2F8463B9A18B67FF4907E49.MAI@COMPUDENT.US> Message-ID: See their twitter: https://twitter.com/changeipcom ChangeIP.com ?@ChangeIPcom Dec 13 DNS Service functions restored, website, dynamic dns, and control panel functions remain offline as we continue DB restore process. On Mon, Dec 12, 2016 at 11:35 AM, Brian J. Dent wrote: > From raymond at prolocation.net Thu Dec 15 07:40:35 2016 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Thu, 15 Dec 2016 08:40:35 +0100 Subject: DOS for hire issues In-Reply-To: References: Message-ID: Hai! Many hosting providers and esp's experience that same issue. After many discussions at maawg (www.maawg.org) a community efford was founded and supported by a few very big esp's helping to optimize their signup proces and implementing customer vetting. Much can be done on that end to bring down abuse issues. There is also a community database included where you can 'report' these bad actors. So other people wont run into the same miscreants over and over. If you make effords to keep bad guys out by tightening up your signup proces things do tend to get better. Posting on list since i hope, just like we tell people to implement bcp38, more people will look into cleaning things at the far beginning of the chain. If you want to make the world a better place i think Thanks, Raymond Dijkxhoorn (You can find more about it on the e-hawk site (www.e-hawk.net). Just posting this single url, since i dont know any others that will help you out with that. If other people do know please post offlist to me do i can also recommend that wherever i can. > Op 14 dec. 2016 om 23:19 heeft ping murder het volgende geschreven: > > Hello, > One of the hosting brands we recently acquired is overrun with DOS for hire > providers and individuals. We kill them as they alert however I'm curious > if there's a discussion group or location, contacts, etc we might be able > to coordinate in about the actors behind these accounts (assuming this > isn't the right place for that, however has a lot of the right people). > > If I'm out of my lane, forgive me. > Thanks, > pm From list at satchell.net Thu Dec 15 14:48:13 2016 From: list at satchell.net (Stephen Satchell) Date: Thu, 15 Dec 2016 06:48:13 -0800 Subject: BCP38 and Red Hat Message-ID: https://bugzilla.redhat.com/show_bug.cgi?id=1370963 Just a reminder that I have a feature request outstanding with Red Hat to add support for BCP38, as well as measures for certain protocol-based amplification reflection attacks. My intent for making the suggestion is to stiffen firewalld(8) in Red Hat Enterprise and clones, particularly when an RHEL-based box is used as an edge router or firewall box. I've looked at firewalld, and it would be easy to add *some* of BCP38 into it rather quickly...assuming that the developers step up to the plate. There are parts of BCP38 that won't be so easy to do, given the architecture of the package. In my spare time, by the way, I'm working on a BCP-compilant firewall generator for IPTABLES. Spare time? Well, that *is* a bit of a laugh... From morrowc.lists at gmail.com Thu Dec 15 15:54:44 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 15 Dec 2016 10:54:44 -0500 Subject: BCP38 and Red Hat In-Reply-To: References: Message-ID: On Thu, Dec 15, 2016 at 9:48 AM, Stephen Satchell wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1370963 > > Just a reminder that I have a feature request outstanding with Red Hat > to add support for BCP38, as well as measures for certain protocol-based > amplification reflection attacks. My intent for making the suggestion > is to stiffen firewalld(8) in Red Hat Enterprise and clones, > particularly when an RHEL-based box is used as an edge router or > firewall box. > > I've looked at firewalld, and it would be easy to add *some* of BCP38 > into it rather quickly...assuming that the developers step up to the > plate. There are parts of BCP38 that won't be so easy to do, given the > architecture of the package. > > In my spare time, by the way, I'm working on a BCP-compilant firewall > generator for IPTABLES. Spare time? Well, that *is* a bit of a laugh... > Given some quick time with definition making: https://github.com/google/capirca does this pretty easily, for example: def/NETWORK.net - content: MYNETS = 192.0.24.0/24 MYWEB = 192.0.24.2/32 STEPHEN_HOME = 198.16.0.23/32 def/SERVICES.svc - content: HTTP = tcp/80 HTTPS = tcp/443 SQUID = tcp/3128 APACHE_PROXY = tcp/8080 PROXY = SQUID APACHE_PROXY office/pol/fw.pol - content header { comment:: "My firewall policy" target:: iptables OUTPUT DROP nostate } term permit-web-stephen { comment:: "Permit stephen to my web, really FROM my web to stephen" destination-address:: STEPHEN_HOME source-address:: MYWEB protocol:: tcp destination-port:: HTTP HTTPS PROXY action:: permit } term bcp-38-only { comment:: "Permit only mynets outbound" source-address:: MYNETS action:: accept } term default-deny { comment:: "All other traffic dies" action:: deny } run the acl generation (aclgen.py) and ... out pops iptables to do what you want. a simple matter of script/software makes this even simple for iptables operators across many flavors of topology. -chris (note: I am not just a user of this solution I'm also a contributor) From ryangard at gmail.com Thu Dec 15 19:33:43 2016 From: ryangard at gmail.com (Ryan Gard) Date: Thu, 15 Dec 2016 14:33:43 -0500 Subject: Rogers Peering Request Message-ID: Looking for a Rogers contact to get things moving on a peering request. Been trying to shout into their ear for well over a month, and haven't heard anything back. Further, PeeringDB information seems egregiously outdated as the URLs listed no longer are serviceable. Hoping this is the last ditch effort to wake somebody up in the red tower. Thanks! -- Ryan Gard From amps at djlab.com Thu Dec 15 21:08:18 2016 From: amps at djlab.com (Randy) Date: Thu, 15 Dec 2016 13:08:18 -0800 Subject: Cogent NOC In-Reply-To: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> References: <17099dc9ec0890396cbe841aac7d46e3@mailbox.fastserv.com> Message-ID: Hi All, Final update from Cogent -- glad they have finally acknowledged -- but no ETA, just great: After further investigation, we have identified an issue of congestion on our core device. At this time we are scheduling a maintenance to alleviate the congestion which in turn will fix the packetloss seen across the Ashburn area. The maintenance has not yet been scheduled but we will inform you once we have a set date. --- ~Randy From deleskie at gmail.com Thu Dec 15 21:13:44 2016 From: deleskie at gmail.com (jim deleskie) Date: Thu, 15 Dec 2016 17:13:44 -0400 Subject: Rogers Peering Request In-Reply-To: References: Message-ID: Will reach out to some folks I know there. PM me Network, AS etc. On Thu, Dec 15, 2016 at 3:33 PM, Ryan Gard wrote: > Looking for a Rogers contact to get things moving on a peering request. > Been trying to shout into their ear for well over a month, and haven't > heard anything back. Further, PeeringDB information seems egregiously > outdated as the URLs listed no longer are serviceable. > > Hoping this is the last ditch effort to wake somebody up in the red tower. > > Thanks! > > -- > Ryan Gard > From gerardo.perales at axtel.com.mx Thu Dec 15 22:45:19 2016 From: gerardo.perales at axtel.com.mx (Jose Gerardo Perales Soto) Date: Thu, 15 Dec 2016 22:45:19 +0000 Subject: Recent NTP pool traffic increase Message-ID: Hi, We've recently experienced a traffic increase on the NTP queries to NTP pool project (pool.ntp.org) servers. One theory is that some service provider NTP infraestructure failed approximately 2 days ago and traffic is now being redirected to servers belonging to the NTP pool project. Does anyone from the service provider community have any comments? Gerardo Perales ________________________________ NOTA: La informaci?n de este correo es de propiedad exclusiva y confidencial. Este mensaje es s?lo para el destinatario se?alado, si usted no lo es, destr?yalo de inmediato. Ninguna informaci?n aqu? contenida debe ser entendida como dada o avalada por AXTEL, S.A.B. de C.V, sus subsidiarias o sus empleados, salvo cuando ello expresamente se indique. Es responsabilidad de quien recibe este correo de asegurarse que est? libre de virus, por lo tanto ni AXTEL, S.A.B. de C.V, sus subsidiarias ni sus empleados aceptan responsabilidad alguna. NOTE: The information in this email is proprietary and confidential. This message is for the designated recipient only, if you are not the intended recipient, you should destroy it immediately. Any information in this message shall not be understood as given or endorsed by AXTEL, S.A.B. de C.V, its subsidiaries or their employees, unless expressly so stated. It is the responsibility of the recipient to ensure that this email is virus free, therefore neither AXTEL, S.A.B. de C.V, its subsidiaries nor their employees accept any responsibility. From blake at ispn.net Thu Dec 15 23:00:27 2016 From: blake at ispn.net (Blake Hudson) Date: Thu, 15 Dec 2016 17:00:27 -0600 Subject: Recent NTP pool traffic increase In-Reply-To: References: Message-ID: <0047b19e-bf57-ad42-c60f-42ad35482933@ispn.net> I would think if a service provider failed, the stats would bear that out. For example, if one of the top ISPs in the world was forwarding requests, then you would likely see an increase in the number of queries generated from IP addresses registered to that organization. A similar effect could occur if a large ISP recently started distributing NTP servers as part of their DHCP options when they had not previously. If historical query data is not available, the current data could be used to make an educated guess and follow up on the likely data trails as currently visible. I would also not rule out the possibility that a Netgear, DLink, T-mobile or some other vendor or distributor of access gear pushed out a firmware update which enabled NTP when it previously was disabled or otherwise changed a device's NTP settings or behavior. --Blake Jose Gerardo Perales Soto wrote on 12/15/2016 4:45 PM: > Hi, > > We've recently experienced a traffic increase on the NTP queries to NTP pool project (pool.ntp.org) servers. One theory is that some service provider NTP infraestructure failed approximately 2 days ago and traffic is now being redirected to servers belonging to the NTP pool project. > > Does anyone from the service provider community have any comments? > > Gerardo Perales From dan-nanog at drown.org Thu Dec 15 23:07:24 2016 From: dan-nanog at drown.org (Dan Drown) Date: Thu, 15 Dec 2016 17:07:24 -0600 Subject: Recent NTP pool traffic increase In-Reply-To: Message-ID: <20161215170724.Horde.1ojbzMEfTPjWE1EnzitN_7e@mail.drown.org> Quoting Jose Gerardo Perales Soto : > We've recently experienced a traffic increase on the NTP queries to > NTP pool project (pool.ntp.org) servers. One theory is that some > service provider NTP infraestructure failed approximately 2 days ago > and traffic is now being redirected to servers belonging to the NTP > pool project. > > Does anyone from the service provider community have any comments? To add some more numbers to this, I'm seeing 4x the usual NTP traffic to my server in pool.ntp.org, starting Dec 13. Top source ASNs by % of NTP traffic seen by my server (I don't have pre-Dec 13 traffic by ASN handy) sprint 4.0% verizon-wireless 3.4% tmobile 2.9% att-wireless 2.8% comcast 2.1% orange 1.8% sky 1.6% twc 1.0% att 1.0% swisscom 0.9% saudinet 0.8% virgin 0.6% opaltelecom 0.5% qwest 0.5% eli 0.2% verizon 0.2% Possibly related is the new iOS release. Does the new iOS generate more NTP traffic? Can anyone measure that? From joelja at bogus.com Thu Dec 15 23:13:12 2016 From: joelja at bogus.com (joel jaeggli) Date: Thu, 15 Dec 2016 15:13:12 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <20161215170724.Horde.1ojbzMEfTPjWE1EnzitN_7e@mail.drown.org> References: <20161215170724.Horde.1ojbzMEfTPjWE1EnzitN_7e@mail.drown.org> Message-ID: <19e4ced8-3726-5746-94e9-e3b378f23102@bogus.com> On 12/15/16 3:07 PM, Dan Drown wrote: > Quoting Jose Gerardo Perales Soto : >> We've recently experienced a traffic increase on the NTP queries to >> NTP pool project (pool.ntp.org) servers. One theory is that some >> service provider NTP infraestructure failed approximately 2 days ago >> and traffic is now being redirected to servers belonging to the NTP >> pool project. >> >> Does anyone from the service provider community have any comments? > > To add some more numbers to this, I'm seeing 4x the usual NTP traffic > to my server in pool.ntp.org, starting Dec 13. > > Top source ASNs by % of NTP traffic seen by my server (I don't have > pre-Dec 13 traffic by ASN handy) > > sprint 4.0% > verizon-wireless 3.4% > tmobile 2.9% > att-wireless 2.8% > comcast 2.1% > orange 1.8% > sky 1.6% > twc 1.0% > att 1.0% > swisscom 0.9% > saudinet 0.8% > virgin 0.6% > opaltelecom 0.5% > qwest 0.5% > eli 0.2% > verizon 0.2% > > Possibly related is the new iOS release. Does the new iOS generate > more NTP traffic? Can anyone measure that? IOS uses time.appple.com which is widely available. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From javier at advancedmachines.us Fri Dec 16 01:55:14 2016 From: javier at advancedmachines.us (Javier J) Date: Thu, 15 Dec 2016 20:55:14 -0500 Subject: ChangeIP.com has been down for 20+ hours In-Reply-To: References: <0CDCB07FD2F8463B9A18B67FF4907E49.MAI@COMPUDENT.US> Message-ID: Anyone have a contact there? They probably could have used a hot standby of their DB. On Wed, Dec 14, 2016 at 9:24 PM, Jay Farrell via NANOG wrote: > See their twitter: https://twitter.com/changeipcom > > ChangeIP.com ?@ChangeIPcom Dec 13 > > DNS Service functions restored, website, dynamic dns, and control panel > functions remain offline as we continue DB restore process. > > On Mon, Dec 12, 2016 at 11:35 AM, Brian J. Dent > wrote: > > > > From kraig at enguity.com Fri Dec 16 02:01:19 2016 From: kraig at enguity.com (Kraig Beahn) Date: Thu, 15 Dec 2016 21:01:19 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: References: Message-ID: How much of a traffic increase? On Dec 15, 2016 5:46 PM, "Jose Gerardo Perales Soto" < gerardo.perales at axtel.com.mx> wrote: > Hi, > > We've recently experienced a traffic increase on the NTP queries to NTP > pool project (pool.ntp.org) servers. One theory is that some service > provider NTP infraestructure failed approximately 2 days ago and traffic is > now being redirected to servers belonging to the NTP pool project. > > Does anyone from the service provider community have any comments? > > Gerardo Perales > > > ________________________________ > > NOTA: La informaci?n de este correo es de propiedad exclusiva y > confidencial. Este mensaje es s?lo para el destinatario se?alado, si usted > no lo es, destr?yalo de inmediato. Ninguna informaci?n aqu? contenida debe > ser entendida como dada o avalada por AXTEL, S.A.B. de C.V, sus > subsidiarias o sus empleados, salvo cuando ello expresamente se indique. Es > responsabilidad de quien recibe este correo de asegurarse que est? libre de > virus, por lo tanto ni AXTEL, S.A.B. de C.V, sus subsidiarias ni sus > empleados aceptan responsabilidad alguna. > NOTE: The information in this email is proprietary and confidential. This > message is for the designated recipient only, if you are not the intended > recipient, you should destroy it immediately. Any information in this > message shall not be understood as given or endorsed by AXTEL, S.A.B. de > C.V, its subsidiaries or their employees, unless expressly so stated. It is > the responsibility of the recipient to ensure that this email is virus > free, therefore neither AXTEL, S.A.B. de C.V, its subsidiaries nor their > employees accept any responsibility. > From rdobbins at arbor.net Fri Dec 16 02:50:39 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 16 Dec 2016 09:50:39 +0700 Subject: Recent NTP pool traffic increase In-Reply-To: References: Message-ID: On 16 Dec 2016, at 5:45, Jose Gerardo Perales Soto wrote: > We've recently experienced a traffic increase on the NTP queries to > NTP pool project (pool.ntp.org) servers. Do you have flow telemetry, which provides a lot more information than basic pps/bps stats? Are you seeing normal timesync queries, or lots of level-6/level-7 admin command attempts? ----------------------------------- Roland Dobbins From dan-nanog at drown.org Fri Dec 16 03:09:58 2016 From: dan-nanog at drown.org (Dan Drown) Date: Thu, 15 Dec 2016 21:09:58 -0600 Subject: Recent NTP pool traffic increase In-Reply-To: References: Message-ID: <20161215210958.Horde.66Rpc60G0_j5sSrVlGT6f15@mail.drown.org> Quoting Roland Dobbins : > Do you have flow telemetry, which provides a lot more information > than basic pps/bps stats? Sources are pretty widely spread out among cell networks/home internet, seem to be mostly US based. I'm not seeing a large amount of traffic per single IP or single subnet. This seems more like "someone pushed out bad firmware" rather than something malicious. > Are you seeing normal timesync queries, or lots of level-6/level-7 > admin command attempts? SNTP Client timesync queries make up 91.3% of the traffic to my server. The following NTP settings being most the popular (47% of all traffic to my server): stratum=0, poll=4, precision=-6, root delay=1, root dispersion=1, reference timestamp=0, originator timestamp=0, receive timestamp=0 From rdobbins at arbor.net Fri Dec 16 03:16:05 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 16 Dec 2016 10:16:05 +0700 Subject: Recent NTP pool traffic increase In-Reply-To: <20161215210958.Horde.66Rpc60G0_j5sSrVlGT6f15@mail.drown.org> References: <20161215210958.Horde.66Rpc60G0_j5sSrVlGT6f15@mail.drown.org> Message-ID: On 16 Dec 2016, at 10:09, Dan Drown wrote: > This seems more like "someone pushed out bad firmware" rather than > something malicious. Everything old is new again . . . ----------------------------------- Roland Dobbins From rdobbins at arbor.net Fri Dec 16 03:17:28 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 16 Dec 2016 10:17:28 +0700 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161215210958.Horde.66Rpc60G0_j5sSrVlGT6f15@mail.drown.org> Message-ID: <6B7C0C66-F6A4-40A0-8134-8925FC608C63@arbor.net> On 16 Dec 2016, at 10:16, Roland Dobbins wrote: > ----------------------------------- Roland Dobbins From rdobbins at arbor.net Fri Dec 16 04:19:16 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 16 Dec 2016 11:19:16 +0700 Subject: Recent NTP pool traffic increase In-Reply-To: <6B7C0C66-F6A4-40A0-8134-8925FC608C63@arbor.net> References: <20161215210958.Horde.66Rpc60G0_j5sSrVlGT6f15@mail.drown.org> <6B7C0C66-F6A4-40A0-8134-8925FC608C63@arbor.net> Message-ID: <77BD9071-1170-4866-978A-08FE0CBEDFC1@arbor.net> On 16 Dec 2016, at 10:17, Roland Dobbins wrote: > Over on nznog, Cameron Bradley posited that this may be related to a TR-069/-064 Mirai variant, which makes use of a 'SetNTPServers' exploit. Perhaps one of them is actually setting timeservers? This SANS writeup details the SOAP strings: ----------------------------------- Roland Dobbins From andrew at andrewimeson.com Thu Dec 15 18:54:34 2016 From: andrew at andrewimeson.com (Andrew Imeson) Date: Thu, 15 Dec 2016 13:54:34 -0500 Subject: Prepending with another ASN you don't own Message-ID: Is it acceptable to prepend using another networks ASN as long as your ASN is the last one in the path? I can think of a few scenarios where this is helpful. One scenario: Anycast content provider with an ISP (who you aren't directly peering with) is choosing to send all traffic to a PoP on another continent. Solution: Prepend at the geographically-distant PoP so that the AS path looks like , and thus that service provider () views it as a routing loop and chooses one of your other PoPs. Sure there are better solutions like communities, but why (if it is) would this be "bad?" -- Andrew Imeson andrew at andrewimeson.com From allan at allan.org Thu Dec 15 23:20:00 2016 From: allan at allan.org (Allan Liska) Date: Thu, 15 Dec 2016 18:20:00 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: Message-ID: <20161215232001.255A6E0537@smtp.hushmail.com> I manage two NTP servers in the pool, one in the US and the other in EMEA. FWIW The US server has seen a spike in traffic, but I have not seen a similar spike on the EMEA server. allan On 12/15/2016 at 5:46 PM, "Jose Gerardo Perales Soto" wrote:Hi, We've recently experienced a traffic increase on the NTP queries to NTP pool project (pool.ntp.org) servers. One theory is that some service provider NTP infraestructure failed approximately 2 days ago and traffic is now being redirected to servers belonging to the NTP pool project. Does anyone from the service provider community have any comments? Gerardo Perales From patrick at pahem.de Fri Dec 16 07:57:46 2016 From: patrick at pahem.de (patrick at pahem.de) Date: Fri, 16 Dec 2016 08:57:46 +0100 (CET) Subject: Network Access to and from China Mainland Message-ID: <680472246.1567.1481875066688@office.mailbox.org> Hello, I have a customer based in Europe which have a subsidiary in China (Mainland) and also do a lot of businesses with China (Mainland). Lately the customer have a lot of issues with accessing websites which are hosted outside China from the subsidiary in China and sees also a lot of delivery problems with emails send to China. The SMTP-Gateway is located in Germany and in the logs we can see timeouts during the connection to the STMP servers in China (Mainland). I suspect that the Chinese Firewall has changed it's behaviour. Have anyone else currently similar issues with communication to and from China? Thanks, Patrick From rdobbins at arbor.net Fri Dec 16 09:40:36 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 16 Dec 2016 16:40:36 +0700 Subject: Recent NTP pool traffic increase In-Reply-To: <20161215232001.255A6E0537@smtp.hushmail.com> References: <20161215232001.255A6E0537@smtp.hushmail.com> Message-ID: <1D433314-6E30-4207-8085-D74B8219FBB1@arbor.net> On 16 Dec 2016, at 6:20, Allan Liska wrote: > FWIW The US server has seen a spike in traffic, but I have not seen a > similar spike on the EMEA server. Looking at the source IP distribution, does a significant proportion of the larger query base seem to originate out-of-region? ----------------------------------- Roland Dobbins From rdobbins at arbor.net Fri Dec 16 09:44:04 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 16 Dec 2016 16:44:04 +0700 Subject: Recent NTP pool traffic increase In-Reply-To: <1D433314-6E30-4207-8085-D74B8219FBB1@arbor.net> References: <20161215232001.255A6E0537@smtp.hushmail.com> <1D433314-6E30-4207-8085-D74B8219FBB1@arbor.net> Message-ID: On 16 Dec 2016, at 16:40, Roland Dobbins wrote: > Looking at the source IP distribution, does a significant proportion > of the larger query base seem to originate out-of-region? And are do they appear to be mostly broadband access networks, or . . . ? ----------------------------------- Roland Dobbins From rubensk at gmail.com Fri Dec 16 10:13:50 2016 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 16 Dec 2016 08:13:50 -0200 Subject: Prepending with another ASN you don't own In-Reply-To: References: Message-ID: Even in that case I believe you should encapsulate between two instances of your own ASN. Your example follows this but the text says only about the last one in the path, while having both last and at least one previous is better since you won't be implying that some other AS has connection to yet another AS, it's just you doing this. Rubens On Thu, Dec 15, 2016 at 4:54 PM, Andrew Imeson wrote: > Is it acceptable to prepend using another networks ASN as long as your > ASN is the last one in the path? I can think of a few scenarios where > this is helpful. > > One scenario: Anycast content provider with an ISP (who you aren't > directly peering with) is choosing to send all traffic to a PoP on > another > continent. > > Solution: > Prepend at the geographically-distant PoP so that the AS path looks > like , and thus that service provider > () > views it as a routing loop and chooses one of your other PoPs. Sure > there are better solutions like communities, but why (if it is) would > this > be "bad?" > > -- > Andrew Imeson > andrew at andrewimeson.com > From randy at psg.com Fri Dec 16 11:21:07 2016 From: randy at psg.com (Randy Bush) Date: Fri, 16 Dec 2016 20:21:07 +0900 Subject: Prepending with another ASN you don't own In-Reply-To: References: Message-ID: this is called path poisoning. an italian friend used it in his phd thesis. a few friends and i used it to detect use of default across the internet. but 42 people will scream "that's my AS!" of course, as it is your prefix, that is ASinine :) ramdu From rsk at gsp.org Fri Dec 16 15:58:00 2016 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 16 Dec 2016 10:58:00 -0500 Subject: Wanted: volunteers with bandwidth/storage to help save climate data Message-ID: <20161216155800.GA504@gsp.org> This is a short-term (about one month) project being thrown together in a hurry...and it could use some help. I know that some of you have lots of resources to throw at this, so if you have an interest in preserving a lot of scientific research data, I've set up a mailing list to coordinate IT efforts to help out. Signup via climatedata-request at firemountain.net or, if you prefer Mailman's web interface, http://www.firemountain.net/mailman/listinfo/climatedata should work. Thanks, ---rsk From daknob.mac at gmail.com Fri Dec 16 16:02:46 2016 From: daknob.mac at gmail.com (DaKnOb) Date: Fri, 16 Dec 2016 18:02:46 +0200 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <20161216155800.GA504@gsp.org> References: <20161216155800.GA504@gsp.org> Message-ID: <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> If you?re interested, there?s also a Slack team: climatemirror.slack.com You can find more info about that here: - https://climate.daknob.net/ - http://climatemirror.org/ - http://www.ppehlab.org/datarefuge Thank you for your help! > On 16 Dec 2016, at 17:58, Rich Kulawiec wrote: > > This is a short-term (about one month) project being thrown together > in a hurry...and it could use some help. I know that some of > you have lots of resources to throw at this, so if you have an > interest in preserving a lot of scientific research data, I've set > up a mailing list to coordinate IT efforts to help out. Signup via > climatedata-request at firemountain.net or, if you prefer Mailman's web > interface, http://www.firemountain.net/mailman/listinfo/climatedata > should work. > > Thanks, > ---rsk > From royce at techsolvency.com Fri Dec 16 16:17:22 2016 From: royce at techsolvency.com (Royce Williams) Date: Fri, 16 Dec 2016 07:17:22 -0900 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> Message-ID: See also: https://twitter.com/textfiles/status/808715999042117632 https://twitter.com/textfiles/status/808922272551550976 Jason Scott?@textfiles When your boss gives you the goahead to mirror 200tb of NOAA data, you run with it Don't let the fact that The Internet Archive is all over this deter you, though. Coordinate here: https://docs.google.com/spreadsheets/d/12-__RqTqQxuxHNOln3H5ciVztsDMJcZ2SVs1BrfqYCc/edit#gid=0 Royce On Fri, Dec 16, 2016 at 7:02 AM, DaKnOb wrote: > If you?re interested, there?s also a Slack team: climatemirror.slack.com > > You can find more info about that here: > > - https://climate.daknob.net/ > - http://climatemirror.org/ > - http://www.ppehlab.org/datarefuge > > Thank you for your help! > > >> On 16 Dec 2016, at 17:58, Rich Kulawiec wrote: >> >> This is a short-term (about one month) project being thrown together >> in a hurry...and it could use some help. I know that some of >> you have lots of resources to throw at this, so if you have an >> interest in preserving a lot of scientific research data, I've set >> up a mailing list to coordinate IT efforts to help out. Signup via >> climatedata-request at firemountain.net or, if you prefer Mailman's web >> interface, http://www.firemountain.net/mailman/listinfo/climatedata >> should work. >> >> Thanks, >> ---rsk >> > From math at sizone.org Fri Dec 16 16:30:08 2016 From: math at sizone.org (Ken Chase) Date: Fri, 16 Dec 2016 11:30:08 -0500 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> Message-ID: <20161216163008.GG28510@sizone.org> Surfing through the links - any hints on how big these datasets are? Everyone's got a few TB to throw at things, but fewer of us have spare PB to throw around. There's some random #s on the goog doc sheet for sizes (100's of TB for the landsat archive seems credible), and there's one number that destroys credibility of the sheet (100000000000 GB (100 ZB)) for the EPA archive. The other page has many 'TBA' entries for size. Not sure what level of player one needs to be to be able to serve a useful segment of these archives. I realize some of the datasets are tiny (If you???re interested, there???s also a Slack team: climatemirror.slack.com > >You can find more info about that here: > >- https://climate.daknob.net/ >- http://climatemirror.org/ >- http://www.ppehlab.org/datarefuge > >Thank you for your help! > > >> On 16 Dec 2016, at 17:58, Rich Kulawiec wrote: >> >> This is a short-term (about one month) project being thrown together >> in a hurry...and it could use some help. I know that some of >> you have lots of resources to throw at this, so if you have an >> interest in preserving a lot of scientific research data, I've set >> up a mailing list to coordinate IT efforts to help out. Signup via >> climatedata-request at firemountain.net or, if you prefer Mailman's web >> interface, http://www.firemountain.net/mailman/listinfo/climatedata >> should work. >> >> Thanks, >> ---rsk >> > -- Ken Chase - math at sizone.org Guelph Canada From daknob.mac at gmail.com Fri Dec 16 16:42:46 2016 From: daknob.mac at gmail.com (DaKnOb) Date: Fri, 16 Dec 2016 18:42:46 +0200 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <20161216163008.GG28510@sizone.org> References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> Message-ID: We are currently working on a scheme to successfully authenticate and verify the integrity of the data. Datasets in https://climate.daknob.net/ are compressed to a .tar.bz2 and then hashed using SHA-256. The final file with all checksums is then signed using a set of PGP keys. We are still working on a viable way to verify the authenticity of files before there are tons of copies lying around and there?s a working group in the Slack team I sent previously where your input is much needed! Thanks, Antonios > On 16 Dec 2016, at 18:30, Ken Chase wrote: > > Surfing through the links - any hints on how big these datasets are? Everyone's got > a few TB to throw at things, but fewer of us have spare PB to throw around. > > There's some random #s on the goog doc sheet for sizes (100's of TB for the > landsat archive seems credible), and there's one number that destroys > credibility of the sheet (100000000000 GB (100 ZB)) for the EPA archive. > > The other page has many 'TBA' entries for size. > > Not sure what level of player one needs to be to be able to serve a useful > segment of these archives. I realize some of the datasets are tiny ( but which ones are most important vs size (ie the win-per-byte ratio) isnt indicated. > (I know its early times.) > > Also I hope they've SHA512'd the datasets for authenticity before all these > myriad copies being flungabout are 'accused' of being manipulated 'to promote > the climate change agenda' yadda. > > Canada: time to step up! (Cant imagine the Natl Research Council would do so > on their mirror site, too much of a gloves-off slap in the face to Trump.) > > /kc > > > On Fri, Dec 16, 2016 at 06:02:46PM +0200, DaKnOb said: >> If you???re interested, there???s also a Slack team: climatemirror.slack.com >> >> You can find more info about that here: >> >> - https://climate.daknob.net/ >> - http://climatemirror.org/ >> - http://www.ppehlab.org/datarefuge >> >> Thank you for your help! >> >> >>> On 16 Dec 2016, at 17:58, Rich Kulawiec wrote: >>> >>> This is a short-term (about one month) project being thrown together >>> in a hurry...and it could use some help. I know that some of >>> you have lots of resources to throw at this, so if you have an >>> interest in preserving a lot of scientific research data, I've set >>> up a mailing list to coordinate IT efforts to help out. Signup via >>> climatedata-request at firemountain.net or, if you prefer Mailman's web >>> interface, http://www.firemountain.net/mailman/listinfo/climatedata >>> should work. >>> >>> Thanks, >>> ---rsk >>> >> > > -- > Ken Chase - math at sizone.org Guelph Canada From hugo at slabnet.com Fri Dec 16 16:47:15 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 16 Dec 2016 08:47:15 -0800 Subject: Network Access to and from China Mainland In-Reply-To: <680472246.1567.1481875066688@office.mailbox.org> References: <680472246.1567.1481875066688@office.mailbox.org> Message-ID: <20161216164715.GH16300@bamboo.slabnet.com> On Fri 2016-Dec-16 08:57:46 +0100, patrick at pahem.de wrote: >Hello, > >I have a customer based in Europe which have a subsidiary in China (Mainland) and also do a lot of businesses with China (Mainland). Lately the customer have a lot of issues with accessing websites which are hosted outside China from the subsidiary in China and sees also a lot of delivery problems with emails send to China. The SMTP-Gateway is located in Germany and in the logs we can see timeouts during the connection to the STMP servers in China (Mainland). I suspect that the Chinese Firewall has changed it's behaviour. Have anyone else currently similar issues with communication to and from China? We gave up on fighting the GFW and got dedicated links between NA and locations in China. No complaints so far. >Thanks, >Patrick -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From job at ntt.net Fri Dec 16 17:13:50 2016 From: job at ntt.net (Job Snijders) Date: Fri, 16 Dec 2016 18:13:50 +0100 Subject: Prepending with another ASN you don't own In-Reply-To: References: Message-ID: <20161216171350.GA34914@Vurt.local> Hi Andrew, On Thu, Dec 15, 2016 at 01:54:34PM -0500, Andrew Imeson wrote: > Is it acceptable to prepend using another networks ASN as long as your > ASN is the last one in the path? I can think of a few scenarios where > this is helpful. Your milage may vary. You risk introducing breakage instead of the desired optimisation. There are providers who inspect the AS_PATH's contents and make decisions to reject (ignore) a route announcement or not based on the presence of certain values. An example: If NTT's backbone (AS 2914) receives a route announcement from any of its adjacent ASN (customers and peering partners alike) which contains AT&T's ASN (7018), _anywhere_ in the AS_PATH, the announcement is considered invalid and rejected (except on the direct 2914 <> 7018 BGP sessions of course). This concept is called 'Peerlocking'. NTT has enabled this for an undisclosed number of ASNs. This is a highly effective measure against route leaks. More information: https://www.youtube.com/watch?v=CSLpWBrHy10 So, where you initially targetted to manipulate one ASN's best path selection, you could end up being unreachable from mulitple seemingly unrelated ASNs because they consider the announcement part of a route leak! > One scenario: Anycast content provider with an ISP (who you aren't > directly peering with) is choosing to send all traffic to a PoP on > another continent. > > Solution: > Prepend at the geographically-distant PoP so that the AS path looks > like , and thus that service provider > () views it as a routing loop and chooses one of your other > PoPs. Sure there are better solutions like communities, but why (if it > is) would this be "bad?" You are right that BGP Communities usually are a better method, especially BGP Communities which are acted upon on "ibgp-in" rather then "ebgp-out" (with per-region granularity). Communities which manipulate the intermediate provider's best path selection can have a better effect on keeping traffic local for anycasters then just suppressing announcements on the far-end. For instance, the community to "set lowest local preference, but only on routers located outside the country I'm connected in" (2914:435 in NTT's network) can in many cases replace the need for forging AS_PATHs. Such a method also provides a safetynet: there always is a route, but during normal operations its just highly unattractive. With AS_PATH forging you don't automatically protect yourself against certain outage scenarios. Finally, keep in mind that there are networks which have disabled AS_PATH Loop Detection, or point default somewhere, so the forged AS_PATH kludge might be in-effective. Kine regards, Job ps. Eric Loos once shared this piece of wisdom with me: "Whenever in doubt, use BGP Communities." ;-) From marty at cloudflare.com Fri Dec 16 17:21:34 2016 From: marty at cloudflare.com (Marty Strong) Date: Fri, 16 Dec 2016 17:21:34 +0000 Subject: Routeviews Message-ID: <7AE974E8-C3CD-47DA-A017-0473FB9595EE@cloudflare.com> Looks like somebody didn?t renew the domain $ whois routeviews.org Domain Name: ROUTEVIEWS.ORG Domain ID: D48496876-LROR WHOIS Server: Referral URL: http://www.networksolutions.com Updated Date: 2016-12-16T10:30:46Z Creation Date: 2000-12-14T23:05:47Z Registry Expiry Date: 2017-12-14T23:05:47Z Sponsoring Registrar: Network Solutions, LLC Sponsoring Registrar IANA ID: 2 Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod Registrant ID: C11717-NS Registrant Name: Perfect Privacy, LLC Registrant Organization: Network Solutions LLC Registrant Street: 12808 Gran Bay Parkway West Registrant Street: care of Network Solutions (DOMAIN-RESALE) Registrant Street: FL Registrant City: Jacksonville Registrant State/Province: FL Registrant Postal Code: 32217 Registrant Country: US Registrant Phone: +1.5707088780 Registrant Phone Ext: Registrant Fax: +1.5707088780 Registrant Fax Ext: Registrant Email: pendingrenewalordeletion at networksolutions.com Admin ID: C11717-NS Admin Name: Perfect Privacy, LLC Admin Organization: Network Solutions LLC Admin Street: 12808 Gran Bay Parkway West Admin Street: care of Network Solutions (DOMAIN-RESALE) Admin Street: FL Admin City: Jacksonville Admin State/Province: FL Admin Postal Code: 32217 Admin Country: US Admin Phone: +1.5707088780 Admin Phone Ext: Admin Fax: +1.5707088780 Admin Fax Ext: Admin Email: pendingrenewalordeletion at networksolutions.com Tech ID: C11717-NS Tech Name: Perfect Privacy, LLC Tech Organization: Network Solutions LLC Tech Street: 12808 Gran Bay Parkway West Tech Street: care of Network Solutions (DOMAIN-RESALE) Tech Street: FL Tech City: Jacksonville Tech State/Province: FL Tech Postal Code: 32217 Tech Country: US Tech Phone: +1.5707088780 Tech Phone Ext: Tech Fax: +1.5707088780 Tech Fax Ext: Tech Email: pendingrenewalordeletion at networksolutions.com Name Server: NS1.PENDINGRENEWALDELETION.COM Name Server: NS2.PENDINGRENEWALDELETION.COM DNSSEC: unsigned >>> Last update of WHOIS database: 2016-12-16T17:19:44Z <<< For more information on Whois status codes, please visit https://icann.org/epp Access to Public Interest Registry WHOIS information is provided to assist persons in determining the contents of a domain name registration record in the Public Interest Registry registry database. The data in this record is provided by Public Interest Registry for informational purposes only, and Public Interest Registry does not guarantee its accuracy. This service is intended only for query-based access. You agree that you will use this data only for lawful purposes and that, under no circumstances will you use this data to(a) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient's own existing customers; or (b) enable high volume, automate Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 From math at sizone.org Fri Dec 16 17:24:37 2016 From: math at sizone.org (Ken Chase) Date: Fri, 16 Dec 2016 12:24:37 -0500 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> Message-ID: <20161216172437.GK28510@sizone.org> University Toronto's Robarts Library is hosting an all-day party tomorrow of people to surf and help identify datasets, survey and get size and details, authenticate copies, etc. fb event: https://www.facebook.com/events/1828129627464671/ /kc On Fri, Dec 16, 2016 at 06:42:46PM +0200, DaKnOb said: >We are currently working on a scheme to successfully authenticate and verify the integrity of the data. Datasets in https://climate.daknob.net/ are compressed to a .tar.bz2 and then hashed using SHA-256. The final file with all checksums is then signed using a set of PGP keys. > >We are still working on a viable way to verify the authenticity of files before there are tons of copies lying around and there???s a working group in the Slack team I sent previously where your input is much needed! > >Thanks, >Antonios > >> On 16 Dec 2016, at 18:30, Ken Chase wrote: >> >> Surfing through the links - any hints on how big these datasets are? Everyone's got >> a few TB to throw at things, but fewer of us have spare PB to throw around. >> >> There's some random #s on the goog doc sheet for sizes (100's of TB for the >> landsat archive seems credible), and there's one number that destroys >> credibility of the sheet (100000000000 GB (100 ZB)) for the EPA archive. >> >> The other page has many 'TBA' entries for size. >> >> Not sure what level of player one needs to be to be able to serve a useful >> segment of these archives. I realize some of the datasets are tiny (> but which ones are most important vs size (ie the win-per-byte ratio) isnt indicated. >> (I know its early times.) >> >> Also I hope they've SHA512'd the datasets for authenticity before all these >> myriad copies being flungabout are 'accused' of being manipulated 'to promote >> the climate change agenda' yadda. >> >> Canada: time to step up! (Cant imagine the Natl Research Council would do so >> on their mirror site, too much of a gloves-off slap in the face to Trump.) >> >> /kc >> >> >> On Fri, Dec 16, 2016 at 06:02:46PM +0200, DaKnOb said: >>> If you???re interested, there???s also a Slack team: climatemirror.slack.com >>> >>> You can find more info about that here: >>> >>> - https://climate.daknob.net/ >>> - http://climatemirror.org/ >>> - http://www.ppehlab.org/datarefuge >>> >>> Thank you for your help! >>> >>> >>>> On 16 Dec 2016, at 17:58, Rich Kulawiec wrote: >>>> >>>> This is a short-term (about one month) project being thrown together >>>> in a hurry...and it could use some help. I know that some of >>>> you have lots of resources to throw at this, so if you have an >>>> interest in preserving a lot of scientific research data, I've set >>>> up a mailing list to coordinate IT efforts to help out. Signup via >>>> climatedata-request at firemountain.net or, if you prefer Mailman's web >>>> interface, http://www.firemountain.net/mailman/listinfo/climatedata >>>> should work. >>>> >>>> Thanks, >>>> ---rsk >>>> >>> >> -- Ken Chase - math at sizone.org Guelph Canada From rdobbins at arbor.net Fri Dec 16 17:27:14 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Sat, 17 Dec 2016 00:27:14 +0700 Subject: Prepending with another ASN you don't own In-Reply-To: <20161216171350.GA34914@Vurt.local> References: <20161216171350.GA34914@Vurt.local> Message-ID: <3576DC32-AA4A-40F1-B724-833326376B2C@arbor.net> On 17 Dec 2016, at 0:13, Job Snijders wrote: > There are providers who inspect the AS_PATH's contents and make > decisions to reject (ignore) a route announcement or > not based on the presence of certain values. +1 ----------------------------------- Roland Dobbins From kemp at network-services.uoregon.edu Fri Dec 16 17:44:28 2016 From: kemp at network-services.uoregon.edu (John Kemp) Date: Fri, 16 Dec 2016 09:44:28 -0800 Subject: Routeviews In-Reply-To: <7AE974E8-C3CD-47DA-A017-0473FB9595EE@cloudflare.com> References: <7AE974E8-C3CD-47DA-A017-0473FB9595EE@cloudflare.com> Message-ID: <65acbe1d-729d-7fad-f28c-8de4efcc2af2@network-services.uoregon.edu> We're looking at it now. Thanks. John Kemp On 12/16/16 9:21 AM, Marty Strong via NANOG wrote: > Looks like somebody didn?t renew the domain > > $ whois routeviews.org > Domain Name: ROUTEVIEWS.ORG > Domain ID: D48496876-LROR > WHOIS Server: > Referral URL: http://www.networksolutions.com > Updated Date: 2016-12-16T10:30:46Z > Creation Date: 2000-12-14T23:05:47Z > Registry Expiry Date: 2017-12-14T23:05:47Z > Sponsoring Registrar: Network Solutions, LLC > Sponsoring Registrar IANA ID: 2 > Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited > Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod > Registrant ID: C11717-NS > Registrant Name: Perfect Privacy, LLC > Registrant Organization: Network Solutions LLC > Registrant Street: 12808 Gran Bay Parkway West > Registrant Street: care of Network Solutions (DOMAIN-RESALE) > Registrant Street: FL > Registrant City: Jacksonville > Registrant State/Province: FL > Registrant Postal Code: 32217 > Registrant Country: US > Registrant Phone: +1.5707088780 > Registrant Phone Ext: > Registrant Fax: +1.5707088780 > Registrant Fax Ext: > Registrant Email: pendingrenewalordeletion at networksolutions.com > Admin ID: C11717-NS > Admin Name: Perfect Privacy, LLC > Admin Organization: Network Solutions LLC > Admin Street: 12808 Gran Bay Parkway West > Admin Street: care of Network Solutions (DOMAIN-RESALE) > Admin Street: FL > Admin City: Jacksonville > Admin State/Province: FL > Admin Postal Code: 32217 > Admin Country: US > Admin Phone: +1.5707088780 > Admin Phone Ext: > Admin Fax: +1.5707088780 > Admin Fax Ext: > Admin Email: pendingrenewalordeletion at networksolutions.com > Tech ID: C11717-NS > Tech Name: Perfect Privacy, LLC > Tech Organization: Network Solutions LLC > Tech Street: 12808 Gran Bay Parkway West > Tech Street: care of Network Solutions (DOMAIN-RESALE) > Tech Street: FL > Tech City: Jacksonville > Tech State/Province: FL > Tech Postal Code: 32217 > Tech Country: US > Tech Phone: +1.5707088780 > Tech Phone Ext: > Tech Fax: +1.5707088780 > Tech Fax Ext: > Tech Email: pendingrenewalordeletion at networksolutions.com > Name Server: NS1.PENDINGRENEWALDELETION.COM > Name Server: NS2.PENDINGRENEWALDELETION.COM > DNSSEC: unsigned >>>> Last update of WHOIS database: 2016-12-16T17:19:44Z <<< > > For more information on Whois status codes, please visit https://icann.org/epp > > Access to Public Interest Registry WHOIS information is provided to assist persons in determining the contents of a domain name registration record in the Public Interest Registry registry database. The data in this record is provided by Public Interest Registry for informational purposes only, and Public Interest Registry does not guarantee its accuracy. This service is intended only for query-based access. You agree that you will use this data only for lawful purposes and that, under no circumstances will you use this data to(a) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient's own existing customers; or (b) enable high volume, automate > > Regards, > Marty Strong > -------------------------------------- > Cloudflare - AS13335 > Network Engineer > marty at cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > https://www.peeringdb.com/asn/13335 > From cscora at apnic.net Fri Dec 16 18:01:50 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Dec 2016 04:01:50 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20161216180150.601F412BE@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 17 Dec, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 625735 Prefixes after maximum aggregation (per Origin AS): 221470 Deaggregation factor: 2.83 Unique aggregates announced (without unneeded subnets): 303432 Total ASes present in the Internet Routing Table: 55446 Prefixes per ASN: 11.29 Origin-only ASes present in the Internet Routing Table: 36286 Origin ASes announcing only one prefix: 15252 Transit ASes present in the Internet Routing Table: 6548 Transit-only ASes present in the Internet Routing Table: 166 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 38 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 65 Unregistered ASNs in the Routing Table: 19 Number of 32-bit ASNs allocated by the RIRs: 16577 Number of 32-bit ASNs visible in the Routing Table: 12612 Prefixes from 32-bit ASNs in the Routing Table: 51551 Number of bogon 32-bit ASNs visible in the Routing Table: 610 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 388 Number of addresses announced to Internet: 2834097636 Equivalent to 168 /8s, 236 /16s and 229 /24s Percentage of available address space announced: 76.6 Percentage of allocated address space announced: 76.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 207209 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156457 Total APNIC prefixes after maximum aggregation: 43125 APNIC Deaggregation factor: 3.63 Prefixes being announced from the APNIC address blocks: 170884 Unique aggregates announced from the APNIC address blocks: 70394 APNIC Region origin ASes present in the Internet Routing Table: 5185 APNIC Prefixes per ASN: 32.96 APNIC Region origin ASes announcing only one prefix: 1141 APNIC Region transit ASes present in the Internet Routing Table: 938 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 38 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2555 Number of APNIC addresses announced to Internet: 761096836 Equivalent to 45 /8s, 93 /16s and 106 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 188238 Total ARIN prefixes after maximum aggregation: 89443 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 194870 Unique aggregates announced from the ARIN address blocks: 89539 ARIN Region origin ASes present in the Internet Routing Table: 16105 ARIN Prefixes per ASN: 12.10 ARIN Region origin ASes announcing only one prefix: 5619 ARIN Region transit ASes present in the Internet Routing Table: 1714 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1653 Number of ARIN addresses announced to Internet: 1106135968 Equivalent to 65 /8s, 238 /16s and 75 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 150375 Total RIPE prefixes after maximum aggregation: 73011 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 161682 Unique aggregates announced from the RIPE address blocks: 98646 RIPE Region origin ASes present in the Internet Routing Table: 18151 RIPE Prefixes per ASN: 8.91 RIPE Region origin ASes announcing only one prefix: 7769 RIPE Region transit ASes present in the Internet Routing Table: 3056 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5105 Number of RIPE addresses announced to Internet: 709408128 Equivalent to 42 /8s, 72 /16s and 181 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 63635 Total LACNIC prefixes after maximum aggregation: 12596 LACNIC Deaggregation factor: 5.05 Prefixes being announced from the LACNIC address blocks: 80198 Unique aggregates announced from the LACNIC address blocks: 37900 LACNIC Region origin ASes present in the Internet Routing Table: 2487 LACNIC Prefixes per ASN: 32.25 LACNIC Region origin ASes announcing only one prefix: 552 LACNIC Region transit ASes present in the Internet Routing Table: 593 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3018 Number of LACNIC addresses announced to Internet: 170839872 Equivalent to 10 /8s, 46 /16s and 207 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15413 Total AfriNIC prefixes after maximum aggregation: 3287 AfriNIC Deaggregation factor: 4.69 Prefixes being announced from the AfriNIC address blocks: 17713 Unique aggregates announced from the AfriNIC address blocks: 6599 AfriNIC Region origin ASes present in the Internet Routing Table: 734 AfriNIC Prefixes per ASN: 24.13 AfriNIC Region origin ASes announcing only one prefix: 171 AfriNIC Region transit ASes present in the Internet Routing Table: 182 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 281 Number of AfriNIC addresses announced to Internet: 86154496 Equivalent to 5 /8s, 34 /16s and 157 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3669 390 249 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2988 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2718 11133 740 KIXS-AS-KR Korea Telecom, KR 9829 2697 1498 532 BSNL-NIB National Internet Backbone, IN 9808 2242 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2041 428 217 TATACOMM-AS TATA Communications formerl 45899 1755 1258 98 VNPT-AS-VN VNPT Corp, VN 4808 1646 2165 468 CHINA169-BJ China Unicom Beijing Provin 24560 1578 556 233 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3603 2968 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3247 1333 82 SHAW - Shaw Communications Inc., CA 18566 2195 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1955 2017 400 CHARTER-NET-HKY-NC - Charter Communicat 30036 1739 327 410 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1729 5066 639 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6983 1676 848 227 ITCDELTA - Earthlink, Inc., US 701 1597 10629 662 UUNET - MCI Communications Services, In 16509 1505 2818 509 AMAZON-02 - Amazon.com, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3141 163 17 ALJAWWALSTC-AS , SA 20940 2948 1110 2097 AKAMAI-ASN1 , US 9121 2250 1709 98 TTNET , TR 34984 1990 328 368 TELLCOM-AS , TR 13188 1605 99 58 TRIOLAN , UA 12479 1403 1032 53 UNI2-AS , ES 6849 1292 355 22 UKRTELNET , UA 8551 1199 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 8402 1146 544 15 CORBINA-AS OJSC "Vimpelcom", RU 12389 995 1156 443 ROSTELECOM-AS , RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3527 543 179 Telmex Colombia S.A., CO 8151 2297 3370 554 Uninet S.A. de C.V., MX 11830 1798 368 66 Instituto Costarricense de Electricidad 6503 1543 437 54 Axtel, S.A.B. de C.V., MX 7303 1522 970 251 Telecom Argentina S.A., AR 6147 1287 377 27 Telefonica del Peru S.A.A., PE 28573 1055 2271 173 CLARO S.A., BR 3816 1026 480 190 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 912 126 80 Alestra, S. de R.L. de C.V., MX 18881 877 1036 22 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1300 402 42 LINKdotNET-AS, EG 36903 681 342 126 MT-MPLS, MA 37611 676 67 6 Afrihost, ZA 36992 575 1373 25 ETISALAT-MISR, EG 8452 490 1472 15 TE-AS TE-AS, EG 24835 486 658 16 RAYA-AS, EG 37492 396 288 72 ORANGE-TN, TN 29571 373 37 13 CITelecom-AS, CI 15399 314 35 6 WANANCHI-KE, KE 36974 275 140 11 AFNET-AS, CI Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3669 390 249 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3603 2968 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3527 543 179 Telmex Colombia S.A., CO 6327 3247 1333 82 SHAW - Shaw Communications Inc., CA 39891 3141 163 17 ALJAWWALSTC-AS , SA 17974 2988 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2948 1110 2097 AKAMAI-ASN1 , US 4766 2718 11133 740 KIXS-AS-KR Korea Telecom, KR 9829 2697 1498 532 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 22773 3603 3451 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 7545 3669 3420 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3527 3348 Telmex Colombia S.A., CO 6327 3247 3165 SHAW - Shaw Communications Inc., CA 39891 3141 3124 ALJAWWALSTC-AS , SA 17974 2988 2917 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2242 2209 CMNET-GD Guangdong Mobile Communication 9829 2697 2165 BSNL-NIB National Internet Backbone, IN 9121 2250 2152 TTNET , TR 18566 2195 2086 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom 65220 PRIVATE 61.128.136.0/21 23456 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:276 /13:530 /14:1048 /15:1800 /16:13168 /17:7807 /18:13025 /19:25285 /20:38095 /21:40681 /22:73021 /23:61293 /24:348202 /25:525 /26:409 /27:309 /28:33 /29:17 /30:16 /31:0 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3043 3247 SHAW - Shaw Communications Inc., CA 39891 2896 3141 ALJAWWALSTC-AS , SA 22773 2805 3603 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2088 2195 MEGAPATH5-US - MegaPath Corporation, US 9121 1582 2250 TTNET , TR 30036 1550 1739 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1446 3527 Telmex Colombia S.A., CO 6389 1393 2095 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1350 1605 TRIOLAN , UA 6983 1323 1676 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1587 2:823 4:23 5:2395 6:32 8:1016 12:1813 13:55 14:1774 15:24 16:2 17:104 18:127 19:1 20:49 23:2005 24:1795 27:2388 31:1828 32:83 33:11 34:1 35:3 36:378 37:2469 38:1295 39:42 40:100 41:2993 42:455 43:1929 44:52 45:2264 46:2541 47:106 49:1167 50:940 51:15 52:601 54:355 55:8 56:4 57:40 58:1567 59:993 60:388 61:1866 62:1490 63:1929 64:4527 65:2176 66:4378 67:2222 68:1153 69:3308 70:1299 71:561 72:2054 74:2593 75:401 76:415 77:1388 78:1569 79:907 80:1363 81:1425 82:971 83:716 84:856 85:1713 86:486 87:1133 88:780 89:2037 90:202 91:6092 92:986 93:2334 94:2335 95:2839 96:578 97:358 98:944 99:93 100:148 101:1204 103:13005 104:2620 105:142 106:463 107:1486 108:777 109:2491 110:1271 111:1656 112:1135 113:1172 114:1003 115:1721 116:1676 117:1581 118:2127 119:1579 120:933 121:1097 122:2281 123:2006 124:1591 125:1841 128:734 129:482 130:431 131:1396 132:617 133:179 134:526 135:209 136:385 137:398 138:1791 139:446 140:620 141:475 142:719 143:904 144:736 145:168 146:955 147:639 148:1394 149:554 150:682 151:794 152:700 153:313 154:721 155:943 156:546 157:556 158:426 159:1338 160:563 161:733 162:2446 163:534 164:778 165:1136 166:359 167:1221 168:2387 169:683 170:2472 171:266 172:839 173:1811 174:777 175:704 176:1751 177:4089 178:2413 179:1141 180:2188 181:1956 182:2121 183:1003 184:840 185:8236 186:3225 187:2227 188:2301 189:1773 190:7951 191:1335 192:9276 193:5778 194:4549 195:3862 196:1861 197:1254 198:5608 199:5821 200:7208 201:4010 202:10159 203:9819 204:4470 205:2755 206:2968 207:3157 208:4026 209:3884 210:3893 211:2066 212:2776 213:2441 214:849 215:66 216:5757 217:1978 218:826 219:597 220:1665 221:886 222:723 223:1054 End of report From mianosm at gmail.com Fri Dec 16 19:05:01 2016 From: mianosm at gmail.com (Steven Miano) Date: Fri, 16 Dec 2016 14:05:01 -0500 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <20161216172437.GK28510@sizone.org> References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> Message-ID: It would seem like the more copies the better, seemingly chunking this data up and using .torrent files may be a way to both (a) ensure the integrity of the data, and (b) enable an additional method to ensure that there are enough copies being replicated (initial seeders would hopefully retain the data for as long as possible)... On Fri, Dec 16, 2016 at 12:24 PM, Ken Chase wrote: > University Toronto's Robarts Library is hosting an all-day party tomorrow > of > people to surf and help identify datasets, survey and get size and details, > authenticate copies, etc. > > fb event: https://www.facebook.com/events/1828129627464671/ > > /kc > > On Fri, Dec 16, 2016 at 06:42:46PM +0200, DaKnOb said: > >We are currently working on a scheme to successfully authenticate and > verify the integrity of the data. Datasets in https://climate.daknob.net/ > are compressed to a .tar.bz2 and then hashed using SHA-256. The final file > with all checksums is then signed using a set of PGP keys. > > > >We are still working on a viable way to verify the authenticity of > files before there are tons of copies lying around and there???s a working > group in the Slack team I sent previously where your input is much needed! > > > >Thanks, > >Antonios > > > >> On 16 Dec 2016, at 18:30, Ken Chase wrote: > >> > >> Surfing through the links - any hints on how big these datasets are? > Everyone's got > >> a few TB to throw at things, but fewer of us have spare PB to throw > around. > >> > >> There's some random #s on the goog doc sheet for sizes (100's of TB > for the > >> landsat archive seems credible), and there's one number that destroys > >> credibility of the sheet (100000000000 GB (100 ZB)) for the EPA > archive. > >> > >> The other page has many 'TBA' entries for size. > >> > >> Not sure what level of player one needs to be to be able to serve a > useful > >> segment of these archives. I realize some of the datasets are tiny > ( >> but which ones are most important vs size (ie the win-per-byte ratio) > isnt indicated. > >> (I know its early times.) > >> > >> Also I hope they've SHA512'd the datasets for authenticity before all > these > >> myriad copies being flungabout are 'accused' of being manipulated 'to > promote > >> the climate change agenda' yadda. > >> > >> Canada: time to step up! (Cant imagine the Natl Research Council > would do so > >> on their mirror site, too much of a gloves-off slap in the face to > Trump.) > >> > >> /kc > >> > >> > >> On Fri, Dec 16, 2016 at 06:02:46PM +0200, DaKnOb said: > >>> If you???re interested, there???s also a Slack team: > climatemirror.slack.com > >>> > >>> You can find more info about that here: > >>> > >>> - https://climate.daknob.net/ > >>> - http://climatemirror.org/ > >>> - http://www.ppehlab.org/datarefuge > >>> > >>> Thank you for your help! > >>> > >>> > >>>> On 16 Dec 2016, at 17:58, Rich Kulawiec wrote: > >>>> > >>>> This is a short-term (about one month) project being thrown together > >>>> in a hurry...and it could use some help. I know that some of > >>>> you have lots of resources to throw at this, so if you have an > >>>> interest in preserving a lot of scientific research data, I've set > >>>> up a mailing list to coordinate IT efforts to help out. Signup via > >>>> climatedata-request at firemountain.net or, if you prefer Mailman's > web > >>>> interface, http://www.firemountain.net/mailman/listinfo/climatedata > >>>> should work. > >>>> > >>>> Thanks, > >>>> ---rsk > >>>> > >>> > >> > > -- > Ken Chase - math at sizone.org Guelph Canada > -- Miano, Steven M. http://stevenmiano.com From math at sizone.org Fri Dec 16 20:30:44 2016 From: math at sizone.org (Ken Chase) Date: Fri, 16 Dec 2016 15:30:44 -0500 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> Message-ID: <20161216203044.GA9904@sizone.org> I seriously doubt that there's going to be a witchhunt even close to as well funded as anti-torrent DMCA-wielding piracy hunters, and it's not even nearly the same as keeping a copy of wikileaks.aes, or sattelite photos of Streisand's campus, or photos of Elian Gonzales, a copy of deCSS, the cyberSitter killfile, etc ("we've been here before."). The issue will be 1000s of half copies that are from differing dates sometimes with no timestamps or other metadata, no SHA256 sums, etc etc. It's going to be a records management nightmare. Remember, all these agencies wont be shut down on Jan 20th making that the universal time-stamp date. Some of them may even be encouraged to continue producing data, possibly even cherry picked or otherwise tainted. Others will carry on quietly, without the administration noticing. Im glad some serious orgs are getting into it - U of T, archive.org, wikipedia, etc. We'll have at least a few repo's that cross-agree on progeny, date, sha256, etc. Only once jackboots are knocking on doors "where's the icecore sample data, Lebowski!" will we really have to consider the quality levels of the other repos. Not that they shouldnt be kept either, of course. Remember, this is only one piece of the puzzle. The scientists can do as much data- collecting as they want -- if the political side of the process wants to make 'mentioning climate change illegal' in state bills or other policies or department missions, it's far more effective than rm'ing a buncha datasets. http://abcnews.go.com/US/north-carolina-bans-latest-science-rising-sea-level/story?id=16913782 Nonetheless - mirror everything everywhere always... /kc On Fri, Dec 16, 2016 at 02:05:01PM -0500, Steven Miano said: >It would seem like the more copies the better, seemingly chunking this data >up and using .torrent files may be a way to both (a) ensure the integrity >of the data, and (b) enable an additional method to ensure that there are >enough copies being replicated (initial seeders would hopefully retain the >data for as long as possible)... > >On Fri, Dec 16, 2016 at 12:24 PM, Ken Chase wrote: > >> University Toronto's Robarts Library is hosting an all-day party tomorrow >> of >> people to surf and help identify datasets, survey and get size and details, >> authenticate copies, etc. >> >> fb event: https://www.facebook.com/events/1828129627464671/ >> >> /kc >> >> On Fri, Dec 16, 2016 at 06:42:46PM +0200, DaKnOb said: >> >We are currently working on a scheme to successfully authenticate and >> verify the integrity of the data. Datasets in https://climate.daknob.net/ >> are compressed to a .tar.bz2 and then hashed using SHA-256. The final file >> with all checksums is then signed using a set of PGP keys. >> > >> >We are still working on a viable way to verify the authenticity of >> files before there are tons of copies lying around and there???s a working >> group in the Slack team I sent previously where your input is much needed! >> > >> >Thanks, >> >Antonios >> > >> >> On 16 Dec 2016, at 18:30, Ken Chase wrote: >> >> >> >> Surfing through the links - any hints on how big these datasets are? >> Everyone's got >> >> a few TB to throw at things, but fewer of us have spare PB to throw >> around. >> >> >> >> There's some random #s on the goog doc sheet for sizes (100's of TB >> for the >> >> landsat archive seems credible), and there's one number that destroys >> >> credibility of the sheet (100000000000 GB (100 ZB)) for the EPA >> archive. >> >> >> >> The other page has many 'TBA' entries for size. >> >> >> >> Not sure what level of player one needs to be to be able to serve a >> useful >> >> segment of these archives. I realize some of the datasets are tiny >> (> >> but which ones are most important vs size (ie the win-per-byte ratio) >> isnt indicated. >> >> (I know its early times.) >> >> >> >> Also I hope they've SHA512'd the datasets for authenticity before all >> these >> >> myriad copies being flungabout are 'accused' of being manipulated 'to >> promote >> >> the climate change agenda' yadda. >> >> >> >> Canada: time to step up! (Cant imagine the Natl Research Council >> would do so >> >> on their mirror site, too much of a gloves-off slap in the face to >> Trump.) >> >> >> >> /kc >> >> >> >> >> >> On Fri, Dec 16, 2016 at 06:02:46PM +0200, DaKnOb said: >> >>> If you???re interested, there???s also a Slack team: >> climatemirror.slack.com >> >>> >> >>> You can find more info about that here: >> >>> >> >>> - https://climate.daknob.net/ >> >>> - http://climatemirror.org/ >> >>> - http://www.ppehlab.org/datarefuge >> >>> >> >>> Thank you for your help! >> >>> >> >>> >> >>>> On 16 Dec 2016, at 17:58, Rich Kulawiec wrote: >> >>>> >> >>>> This is a short-term (about one month) project being thrown together >> >>>> in a hurry...and it could use some help. I know that some of >> >>>> you have lots of resources to throw at this, so if you have an >> >>>> interest in preserving a lot of scientific research data, I've set >> >>>> up a mailing list to coordinate IT efforts to help out. Signup via >> >>>> climatedata-request at firemountain.net or, if you prefer Mailman's >> web >> >>>> interface, http://www.firemountain.net/mailman/listinfo/climatedata >> >>>> should work. >> >>>> >> >>>> Thanks, >> >>>> ---rsk >> >>>> >> >>> >> >> >> >> -- >> Ken Chase - math at sizone.org Guelph Canada >> > > > >-- >Miano, Steven M. >http://stevenmiano.com -- Ken Chase - math at sizone.org From rob at invaluement.com Fri Dec 16 21:35:36 2016 From: rob at invaluement.com (Rob McEwen) Date: Fri, 16 Dec 2016 16:35:36 -0500 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <20161216203044.GA9904@sizone.org> References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> Message-ID: <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> On 12/16/2016 3:30 PM, Ken Chase wrote: > http://abcnews.go.com/US/north-carolina-bans-latest-science-rising-sea-level/story?id=16913782 North Carolina is not banning science. It is banning absolutely preposterous and manipulated junk science. A 39-inch rise in the ocean levels over the next century is based on fear-mongering and junk science designed to scare politicians into increasing grant $$ from the federal government. It is not based on science. In fact, the sea levels continue to rise at the SAME TINY 2-4mm per year that they've been rising at for decades, with ZERO sign of an increase. If global warming was real and cumulative - this shouldn't even be possible, based all that we've been told over the past 20 years. Every article that states that oceans rising at alarmingly faster rates - due to global warming - either lie about or manipulate the the data... or they grab one relatively small short term spike and extrapolates from that. Meanwhile, dozens of sea-level rising predictions from so-called credible scientists have not only failed, but failed by order of magnitudes, and again, relied upon junk science. True science makes "risky predictions" and is willing to throw out the theory when that theories "risky predictions" don't come true. But I truly due hope that this collection process is successful because I hope that ALL of this (mostly) manipulated data gets recorded for posterity so that (honest) scientists a century from now can do extensive studies on how/why science became so political and manipulated as they look back on the first few decades of the 21st century's slide into a strong long-term cooling trend, due to long term cyclical sun cycles. This is not a victim-less crime. This manipulation of the data by global warmongers harms people because is miscalculates resources and damages the economy. Does that mean we should spew toxic waste into rivers or streams or spew smog into the air? Of course not. But global warming and CO2 being a cause of it... and "oceans rising" has MUCH junk science behind it. Still, I hope this data is preserved. The truth will win out in the long term. (as is already starting to happen) -- Rob McEwen From hugo at slabnet.com Fri Dec 16 21:48:34 2016 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 16 Dec 2016 13:48:34 -0800 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> Message-ID: <20161216214834.GI16300@bamboo.slabnet.com> This started as a technical appeal, but: https://www.nanog.org/list 1. Discussion will focus on Internet operational and technical issues as described in the charter of NANOG. ... 6. Postings of political, philosophical, and legal nature are prohibited. ... -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On Fri 2016-Dec-16 16:35:36 -0500, Rob McEwen wrote: >On 12/16/2016 3:30 PM, Ken Chase wrote: >>http://abcnews.go.com/US/north-carolina-bans-latest-science-rising-sea-level/story?id=16913782 > >North Carolina is not banning science. It is banning absolutely >preposterous and manipulated junk science. > >A 39-inch rise in the ocean levels over the next century is based on >fear-mongering and junk science designed to scare politicians into >increasing grant $$ from the federal government. It is not based on >science. > >In fact, the sea levels continue to rise at the SAME TINY 2-4mm per >year that they've been rising at for decades, with ZERO sign of an >increase. > >If global warming was real and cumulative - this shouldn't even be >possible, based all that we've been told over the past 20 years. > >Every article that states that oceans rising at alarmingly faster >rates - due to global warming - either lie about or manipulate the >the data... or they grab one relatively small short term spike and >extrapolates from that. > >Meanwhile, dozens of sea-level rising predictions from so-called >credible scientists have not only failed, but failed by order of >magnitudes, and again, relied upon junk science. True science makes >"risky predictions" and is willing to throw out the theory when that >theories "risky predictions" don't come true. > >But I truly due hope that this collection process is successful >because I hope that ALL of this (mostly) manipulated data gets >recorded for posterity so that (honest) scientists a century from now >can do extensive studies on how/why science became so political and >manipulated as they look back on the first few decades of the 21st >century's slide into a strong long-term cooling trend, due to long >term cyclical sun cycles. > >This is not a victim-less crime. This manipulation of the data by >global warmongers harms people because is miscalculates resources and >damages the economy. Does that mean we should spew toxic waste into >rivers or streams or spew smog into the air? Of course not. But >global warming and CO2 being a cause of it... and "oceans rising" has >MUCH junk science behind it. > >Still, I hope this data is preserved. The truth will win out in the >long term. (as is already starting to happen) > >-- >Rob McEwen > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From rob at invaluement.com Fri Dec 16 21:55:19 2016 From: rob at invaluement.com (Rob McEwen) Date: Fri, 16 Dec 2016 16:55:19 -0500 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <20161216214834.GI16300@bamboo.slabnet.com> References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> Message-ID: <621ecb8f-ad81-9b59-57d4-e00f87e59c72@invaluement.com> On 12/16/2016 4:48 PM, Hugo Slabbert wrote: > This started as a technical appeal, but: > https://www.nanog.org/list > 1. Discussion will focus on Internet operational and technical issues as > described in the charter of NANOG. > 6. Postings of political, philosophical, and legal nature are prohibited. EXACTLY - but I had to finally respond because it was getting obnoxious... all the "we all think this way and we KNOW that the other side is wrong"--implications/statements embedded in various previous posts. -- Rob McEwen From aaron at heyaaron.com Fri Dec 16 22:06:03 2016 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 16 Dec 2016 14:06:03 -0800 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> Message-ID: On Fri, Dec 16, 2016 at 1:35 PM, Rob McEwen wrote: > On 12/16/2016 3:30 PM, Ken Chase wrote: > A 39-inch rise in the ocean levels over the next century is based on > fear-mongering and junk science designed to scare politicians into > increasing grant $$ from the federal government. It is not based on science. 39 inches? I'm going to start laying fiber up and down I-5. I'll have the cheapest trans-ocean cable between Canada and Mexico... -A From mark at exonetric.com Fri Dec 16 22:13:47 2016 From: mark at exonetric.com (Mark Blackman) Date: Fri, 16 Dec 2016 22:13:47 +0000 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> Message-ID: <3B8C1A91-1E6C-4D14-A9ED-1380E9B22B5E@exonetric.com> > On 16 Dec 2016, at 21:35, Rob McEwen wrote: > But global warming and CO2 being a cause of it. http://climate.nasa.gov/evidence/ What sort of effects do you reckon a 35% increase in atmospheric CO2 over historical levels over the space of 65 years might lead to? - Mark From jfmezei_nanog at vaxination.ca Fri Dec 16 22:16:30 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 16 Dec 2016 17:16:30 -0500 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <20161216155800.GA504@gsp.org> References: <20161216155800.GA504@gsp.org> Message-ID: <585467BE.2040406@vaxination.ca> On 2016-12-16 10:58, Rich Kulawiec wrote: > This is a short-term (about one month) project being thrown together > in a hurry...and it could use some help. How much data are we talking about here? A few floppy disks ? a couple of megabytes ? gigabytes ? terabytes ? petabytes ? Have you considered giving "courtesy copies" to other environmental organistaions such as Environment Canada, Australian Bureau of Meteorology etc ? From jlewis at lewis.org Fri Dec 16 22:22:31 2016 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 16 Dec 2016 17:22:31 -0500 (EST) Subject: Prepending with another ASN you don't own In-Reply-To: References: Message-ID: On Fri, 16 Dec 2016, Randy Bush wrote: > this is called path poisoning. an italian friend used it in his phd > thesis. a few friends and i used it to detect use of default across > the internet. I've done this in the past as a work-around for insufficient BGP community support. Just prepending the AS I wanted to ignore the paths. But, if the problem is an anycast CDN choosing a sub-optimal path to reach you, you might try reaching out to them. They're probably just as, if not more interested, in getting their traffic to you as efficiently as possible. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jfmezei_nanog at vaxination.ca Fri Dec 16 22:25:48 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 16 Dec 2016 17:25:48 -0500 Subject: Multicast IPTV on DOCSIS Message-ID: <585469EC.9060709@vaxination.ca> Today, Rogers (in Canada) announced it was ditching it long running project to move to an IPTV platform it had been developping and will adopt Comcast X1. (some $500 million writeoff). Telco IPTV systems use multicasting all the way to the customer's LAN and generally use the Microsoft/Ericcson MediaRoom product suite and compatible STBs. Could a cableco have deployed Mediaroom on a DOCSIS system? Does docsis support multicasting ? I assume it would run on a separate DOCSIS group of NTSC channels on the coax and likely require 2 modems in the home. I am curious on why Rogers would have spent so much time trying to develop its own system. With regards to Comcast X1, is this a very conventional TV on coax system, with a bunch of switched video channels to cater to on-demand services to invividual homes ? Or does X1 use some form of IP connection to deliver "data" for the on-demand content ? (while linear TV still provided in traditional digital channels bundled into an NTSC channel ? BTW, one of the original arguments for Rogers is that cable STBs had proprietary software that was slow to evolve and get new features approved/tested, so they lagged behind the IPTV STB software which didn't require certificatioN/approval by the STB hardware vendors (cisco etc). Has any Cable system converted to IPTV ? From lguillory at reservetele.com Fri Dec 16 22:43:32 2016 From: lguillory at reservetele.com (Luke Guillory) Date: Fri, 16 Dec 2016 22:43:32 +0000 Subject: Multicast IPTV on DOCSIS In-Reply-To: <585469EC.9060709@vaxination.ca> References: <585469EC.9060709@vaxination.ca> Message-ID: <459E0664-3065-49F0-8909-F84B9FEA4B18@reservetele.com> Yes it works over docsis, you assigned downstreams to part of a multicast group and the CMTS will use those when a device asks to join. X1 is both traditional HFC and also full on IPTV which is where everyone is going including HFC plants. Mediaroom is the least popular middleware when looking at the major ones, Minerva has much more market share. Cox licensed the X1 platform for their Contor product after ditching Cisco for some reason. Sent from my iPhone On Dec 16, 2016, at 4:27 PM, Jean-Francois Mezei > wrote: Today, Rogers (in Canada) announced it was ditching it long running project to move to an IPTV platform it had been developping and will adopt Comcast X1. (some $500 million writeoff). Telco IPTV systems use multicasting all the way to the customer's LAN and generally use the Microsoft/Ericcson MediaRoom product suite and compatible STBs. Could a cableco have deployed Mediaroom on a DOCSIS system? Does docsis support multicasting ? I assume it would run on a separate DOCSIS group of NTSC channels on the coax and likely require 2 modems in the home. I am curious on why Rogers would have spent so much time trying to develop its own system. With regards to Comcast X1, is this a very conventional TV on coax system, with a bunch of switched video channels to cater to on-demand services to invividual homes ? Or does X1 use some form of IP connection to deliver "data" for the on-demand content ? (while linear TV still provided in traditional digital channels bundled into an NTSC channel ? BTW, one of the original arguments for Rogers is that cable STBs had proprietary software that was slow to evolve and get new features approved/tested, so they lagged behind the IPTV STB software which didn't require certificatioN/approval by the STB hardware vendors (cisco etc). Has any Cable system converted to IPTV ? Luke Guillory Network Operations Manager [cid:image56af80.JPG at 29a6b056.4196f16d] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From randy at psg.com Fri Dec 16 23:22:42 2016 From: randy at psg.com (Randy Bush) Date: Sat, 17 Dec 2016 08:22:42 +0900 Subject: Prepending with another ASN you don't own In-Reply-To: References: Message-ID: >> this is called path poisoning. an italian friend used it in his phd >> thesis. a few friends and i used it to detect use of default across >> the internet. > > I've done this in the past as a work-around for insufficient BGP > community support. Just prepending the AS I wanted to ignore the > paths. > > But, if the problem is an anycast CDN choosing a sub-optimal path to > reach you, you might try reaching out to them. They're probably just > as, if not more interested, in getting their traffic to you as > efficiently as possible. apologies. i should have been more explicit. both of the examples were using path poisoning for routing research. it is not a technique i would reccommend in normal operations. randy From larrysheldon at cox.net Sat Dec 17 01:01:04 2016 From: larrysheldon at cox.net (Larry Sheldon) Date: Fri, 16 Dec 2016 19:01:04 -0600 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> Message-ID: <1017ddd7-07d9-905a-f030-ac81b9ece2dd@cox.net> I guess at long last it is time for Larry to stop thinking there was a common interest here. NANOG has gone completely into the weeds (my email client treats it as political spam). Sad--once upon a time it was a home for science in an insane academic world. -- "Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." --Albert Einstein From Larry's Cox account. From kemp at network-services.uoregon.edu Sat Dec 17 18:30:48 2016 From: kemp at network-services.uoregon.edu (John Kemp) Date: Sat, 17 Dec 2016 10:30:48 -0800 Subject: Routeviews In-Reply-To: <65acbe1d-729d-7fad-f28c-8de4efcc2af2@network-services.uoregon.edu> References: <7AE974E8-C3CD-47DA-A017-0473FB9595EE@cloudflare.com> <65acbe1d-729d-7fad-f28c-8de4efcc2af2@network-services.uoregon.edu> Message-ID: <8e980818-9332-4a85-c118-18a4576fc371@network-services.uoregon.edu> It's back/renewed as of... Domain Name: ROUTEVIEWS.ORG Domain ID: D48496876-LROR WHOIS Server: Referral URL: http://www.networksolutions.com Updated Date: 2016-12-16T18:41:42Z Creation Date: 2000-12-14T23:05:47Z John Kemp On 12/16/16 9:44 AM, John Kemp wrote: > > We're looking at it now. Thanks. > > John Kemp > > On 12/16/16 9:21 AM, Marty Strong via NANOG wrote: >> Looks like somebody didn?t renew the domain >> >> $ whois routeviews.org >> Domain Name: ROUTEVIEWS.ORG >> Domain ID: D48496876-LROR >> WHOIS Server: >> Referral URL: http://www.networksolutions.com >> Updated Date: 2016-12-16T10:30:46Z >> Creation Date: 2000-12-14T23:05:47Z >> Registry Expiry Date: 2017-12-14T23:05:47Z >> Sponsoring Registrar: Network Solutions, LLC >> Sponsoring Registrar IANA ID: 2 >> Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited >> Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod >> Registrant ID: C11717-NS >> Registrant Name: Perfect Privacy, LLC >> Registrant Organization: Network Solutions LLC >> Registrant Street: 12808 Gran Bay Parkway West >> Registrant Street: care of Network Solutions (DOMAIN-RESALE) >> Registrant Street: FL >> Registrant City: Jacksonville >> Registrant State/Province: FL >> Registrant Postal Code: 32217 >> Registrant Country: US >> Registrant Phone: +1.5707088780 >> Registrant Phone Ext: >> Registrant Fax: +1.5707088780 >> Registrant Fax Ext: >> Registrant Email: pendingrenewalordeletion at networksolutions.com >> Admin ID: C11717-NS >> Admin Name: Perfect Privacy, LLC >> Admin Organization: Network Solutions LLC >> Admin Street: 12808 Gran Bay Parkway West >> Admin Street: care of Network Solutions (DOMAIN-RESALE) >> Admin Street: FL >> Admin City: Jacksonville >> Admin State/Province: FL >> Admin Postal Code: 32217 >> Admin Country: US >> Admin Phone: +1.5707088780 >> Admin Phone Ext: >> Admin Fax: +1.5707088780 >> Admin Fax Ext: >> Admin Email: pendingrenewalordeletion at networksolutions.com >> Tech ID: C11717-NS >> Tech Name: Perfect Privacy, LLC >> Tech Organization: Network Solutions LLC >> Tech Street: 12808 Gran Bay Parkway West >> Tech Street: care of Network Solutions (DOMAIN-RESALE) >> Tech Street: FL >> Tech City: Jacksonville >> Tech State/Province: FL >> Tech Postal Code: 32217 >> Tech Country: US >> Tech Phone: +1.5707088780 >> Tech Phone Ext: >> Tech Fax: +1.5707088780 >> Tech Fax Ext: >> Tech Email: pendingrenewalordeletion at networksolutions.com >> Name Server: NS1.PENDINGRENEWALDELETION.COM >> Name Server: NS2.PENDINGRENEWALDELETION.COM >> DNSSEC: unsigned >>>>> Last update of WHOIS database: 2016-12-16T17:19:44Z <<< >> >> For more information on Whois status codes, please visit https://icann.org/epp >> >> Access to Public Interest Registry WHOIS information is provided to assist persons in determining the contents of a domain name registration record in the Public Interest Registry registry database. The data in this record is provided by Public Interest Registry for informational purposes only, and Public Interest Registry does not guarantee its accuracy. This service is intended only for query-based access. You agree that you will use this data only for lawful purposes and that, under no circumstances will you use this data to(a) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient's own existing customers; or (b) enable high volume, automate >> >> Regards, >> Marty Strong >> -------------------------------------- >> Cloudflare - AS13335 >> Network Engineer >> marty at cloudflare.com >> +44 7584 906 055 >> smartflare (Skype) >> >> https://www.peeringdb.com/asn/13335 >> From liz.fazekas at gmail.com Sun Dec 18 00:03:42 2016 From: liz.fazekas at gmail.com (Elizabethtown) Date: Sat, 17 Dec 2016 19:03:42 -0500 Subject: Routeviews Message-ID: Sent from my Samsung device -------- Original message -------- From: John Kemp Date: 2016-12-17 13:30 (GMT-05:00) To: nanog at nanog.org Subject: Re: Routeviews It's back/renewed as of... Domain Name: ROUTEVIEWS.ORG Domain ID: D48496876-LROR WHOIS Server: Referral URL: http://www.networksolutions.com Updated Date: 2016-12-16T18:41:42Z Creation Date: 2000-12-14T23:05:47Z John Kemp On 12/16/16 9:44 AM, John Kemp wrote: > > We're looking at it now.? Thanks. > > John Kemp > > On 12/16/16 9:21 AM, Marty Strong via NANOG wrote: >> Looks like somebody didn?t renew the domain >> >> $ whois routeviews.org >> Domain Name: ROUTEVIEWS.ORG >> Domain ID: D48496876-LROR >> WHOIS Server: >> Referral URL: http://www.networksolutions.com >> Updated Date: 2016-12-16T10:30:46Z >> Creation Date: 2000-12-14T23:05:47Z >> Registry Expiry Date: 2017-12-14T23:05:47Z >> Sponsoring Registrar: Network Solutions, LLC >> Sponsoring Registrar IANA ID: 2 >> Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited >> Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod >> Registrant ID: C11717-NS >> Registrant Name: Perfect Privacy, LLC >> Registrant Organization: Network Solutions LLC >> Registrant Street: 12808 Gran Bay Parkway West >> Registrant Street: care of Network Solutions (DOMAIN-RESALE) >> Registrant Street: FL >> Registrant City: Jacksonville >> Registrant State/Province: FL >> Registrant Postal Code: 32217 >> Registrant Country: US >> Registrant Phone: +1.5707088780 >> Registrant Phone Ext: >> Registrant Fax: +1.5707088780 >> Registrant Fax Ext: >> Registrant Email: pendingrenewalordeletion at networksolutions.com >> Admin ID: C11717-NS >> Admin Name: Perfect Privacy, LLC >> Admin Organization: Network Solutions LLC >> Admin Street: 12808 Gran Bay Parkway West >> Admin Street: care of Network Solutions (DOMAIN-RESALE) >> Admin Street: FL >> Admin City: Jacksonville >> Admin State/Province: FL >> Admin Postal Code: 32217 >> Admin Country: US >> Admin Phone: +1.5707088780 >> Admin Phone Ext: >> Admin Fax: +1.5707088780 >> Admin Fax Ext: >> Admin Email: pendingrenewalordeletion at networksolutions.com >> Tech ID: C11717-NS >> Tech Name: Perfect Privacy, LLC >> Tech Organization: Network Solutions LLC >> Tech Street: 12808 Gran Bay Parkway West >> Tech Street: care of Network Solutions (DOMAIN-RESALE) >> Tech Street: FL >> Tech City: Jacksonville >> Tech State/Province: FL >> Tech Postal Code: 32217 >> Tech Country: US >> Tech Phone: +1.5707088780 >> Tech Phone Ext: >> Tech Fax: +1.5707088780 >> Tech Fax Ext: >> Tech Email: pendingrenewalordeletion at networksolutions.com >> Name Server: NS1.PENDINGRENEWALDELETION.COM >> Name Server: NS2.PENDINGRENEWALDELETION.COM >> DNSSEC: unsigned >>>>> Last update of WHOIS database: 2016-12-16T17:19:44Z <<< >> >> For more information on Whois status codes, please visit https://icann.org/epp >> >> Access to Public Interest Registry WHOIS information is provided to assist persons in determining the contents of a domain name registration record in the Public Interest Registry registry database. The data in this record is provided by Public Interest Registry for informational purposes only, and Public Interest Registry does not guarantee its accuracy. This service is intended only for query-based access. You agree that you will use this data only for lawful purposes and that, under no circumstances will you use this data to(a) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient's own existing customers; or (b) enable high volume, automate >> >> Regards, >> Marty Strong >> -------------------------------------- >> Cloudflare - AS13335 >> Network Engineer >> marty at cloudflare.com >> +44 7584 906 055 >> smartflare (Skype) >> >> https://www.peeringdb.com/asn/13335 >> From andreas at naund.org Fri Dec 16 17:27:21 2016 From: andreas at naund.org (Andreas Ott) Date: Fri, 16 Dec 2016 09:27:21 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: ; from rdobbins@arbor.net on Fri, Dec 16, 2016 at 04:44:04PM +0700 References: <20161215232001.255A6E0537@smtp.hushmail.com> <1D433314-6E30-4207-8085-D74B8219FBB1@arbor.net> Message-ID: <20161216092721.O30331@naund.org> Hi, On Fri, Dec 16, 2016 at 04:44:04PM +0700, Roland Dobbins wrote: > > Looking at the source IP distribution, does a significant proportion > > of the larger query base seem to originate out-of-region? > > And are do they appear to be mostly broadband access networks, or . . . > ? Datapoints are via nfsen (nflow/sflow collection) from a US west coast network lab that has "three" NTP pool servers, one IPv4 only set to 25 Mbps, the other one IPv4 and IPv6 on the same server both set to 100Mbps at the NTP pool registration site. Traffic is about 4 times P95 in the last 3 days from what it was before, and the increase is IPv4 on the server that has IPv4 and IPv6. IPv6 traffic is in line with what it used to be, no large increase. The server with higher bandwidth and IPv4+IPv6 is seeing a large increase on IPv4, from single hosts that seem to be in broadband networks and a certain site's crawler that is hosted on AWS. The latter almost looks like someone hardcoded a config instead of relying on the pool's DNS. The top talker abuses something in the protocol, this does not look for real and I will contact Verizon/FiOS tcpdump -nvvi hme0 port 123 and host 98.113.213.d|grep "Originator - Transmit Timestamp:" Originator - Transmit Timestamp: 2123062516.816546608 (1967/04/12 11:35:16) Originator - Transmit Timestamp: 862276608.564645656 (1927/04/30 01:16:48) Originator - Transmit Timestamp: 3399899220.431115995 (2007/09/27 16:27:00) Originator - Transmit Timestamp: 140873162.935483905 (1904/06/19 11:26:02) Originator - Transmit Timestamp: 1878223676.912769495 (1959/07/09 16:47:56) Originator - Transmit Timestamp: 2713286246.929585296 (1985/12/24 18:37:26) Originator - Transmit Timestamp: 3219464534.831489402 (2002/01/08 07:42:14) Originator - Transmit Timestamp: 2210689093.339715993 (1970/01/20 16:18:13) Originator - Transmit Timestamp: 3899283084.650125848 (2023/07/25 14:11:24) [...] nfdump -M /var/nfsen/profiles-data/live/dmz208_0201:br1 -T -R 2016/12/13/nfcapd.201612131630:2016/12/16/nfcapd.201612161630 -n 10 -s record/bytes -A proto,srcip,dstport -6 "dst ip j.k.l.235 and proto udp" Aggregated flows 51346 Top 10 flows ordered by bytes: Date first seen Duration Proto Src IP Addr Dst Pt Packets Bytes bps Bpp Flows 2016-12-13 16:31:22.608 259394.340 UDP 98.113.213.d 123 12.3 M 1.1 G 34107 90 3000 2016-12-13 16:50:31.649 253960.650 UDP 54.236.1.d 123 126976 11.4 M 359 90 31 2016-12-13 17:43:29.760 255090.188 UDP 54.236.1.d 123 114688 10.3 M 323 90 28 2016-12-13 20:23:39.198 211054.259 UDP 54.236.1.d 123 90112 8.1 M 307 90 22 2016-12-13 22:29:12.265 218623.774 UDP 204.177.184.d 123 61440 5.5 M 202 90 15 2016-12-14 04:12:44.389 102634.717 UDP 162.243.191.d 123 61440 5.5 M 431 90 15 2016-12-13 22:10:33.226 223641.048 UDP 198.199.99.d 123 53248 4.8 M 171 90 13 2016-12-13 21:31:18.841 194915.427 UDP 220.253.150.d 123 53248 4.8 M 196 90 13 2016-12-13 20:01:40.452 242771.757 UDP troublemaker 123 49152 4.4 M 145 90 12 2016-12-14 05:21:20.634 208902.664 UDP 54.236.1.d 123 40960 3.7 M 141 90 10 Summary: total flows: 60396, total bytes: 21023451720, total packets: 233586118, avg bps: 648125, avg pps: 900, avg bpp: 90 Time window: 1970-01-01 00:00:01 - 2016-12-16 16:34:54 Total flows processed: 29676807, Blocks skipped: 0, Bytes read: 1662858132 Sys: 7.730s flows/second: 3839128.8 Wall: 7.722s flows/second: 3842810.0 Note: "troublemaker" is a host on the internal network that has a known issue with NTP time keeping, it originates a lot of packets and steps a lot. Reply to me directly if you want more details. -andreas -- Andreas Ott andreas at naund.org From gem at rellim.com Sun Dec 18 01:54:55 2016 From: gem at rellim.com (Gary E. Miller) Date: Sat, 17 Dec 2016 17:54:55 -0800 Subject: Recent NTP pool traffic increase Message-ID: <20161217175455.30107c37@spidey.rellim.com> Yo All! Someone on nanog was reporrting on the new NTP mystery. He suggested doing a dump similar to this: # tcpdump -nvvi eth0 port 123 |grep "Originator - Transmit Timestamp:" And I do indeed get odd results. Some on my local network... This is from a chronyd host to an ntpsec host. I monitor them both continuously and both seem to be keeping good time. 17:36:11.369329 IP (tos 0x0, ttl 64, id 21405, offset 0, flags [DF], proto UDP ( 17), length 76) 204.17.205.7.50937 > 204.17.205.27.123: [udp sum ok] NTPv4, length 48 Client, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecifi ed), poll 6 (64s), precision 32 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 3691013707.207257069 (2016/12/17 17:35:07) Receive Timestamp: 276521666.321684728 (2044/11/11 10:02:42) Transmit Timestamp: 3684123061.899235956 (2016/09/29 00:31:01) Originator - Receive Timestamp: +880475255.114427658 Originator - Transmit Timestamp: -6890645.308021113 That 'Receive Timestamp' is strange. Here is another one from the same chronyd host, to another ntpsec host: 17:36:23.395415 IP (tos 0x0, ttl 64, id 3599, offset 0, flags [DF], proto UDP (1 7), length 76) 204.17.205.7.33551 > 204.17.205.1.123: [udp sum ok] NTPv4, length 48 Client, Leap indicator: clock unsynchronized (192), Stratum 0 (unspecifi ed), poll 6 (64s), precision 32 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 3691013718.824150890 (2016/12/17 17:35:18) Receive Timestamp: 1779216017.648483479 (2092/06/24 18:08:33) Transmit Timestamp: 1405803137.064633429 (2080/08/24 20:20:33) Originator - Receive Timestamp: -1911797701.175667410 Originator - Transmit Timestamp: +2009756714.240482539 Note both the 'Receive Timestamp' and 'Transmit Timestamp' are both strange. All three hosts have GPS for local time. Here is one from a laptop, running chrony, that has not GPS: 17:36:52.643814 IP (tos 0x0, ttl 64, id 24624, offset 0, flags [DF], proto UDP ( 17), length 76) 204.17.205.21.41485 > 204.17.205.8.123: [udp sum ok] NTPv4, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 6 (64s), pre cision 32 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 3691013747.797479298 (2016/12/17 17:35:47) Receive Timestamp: 317494016.811980062 (2046/02/28 15:15:12) Transmit Timestamp: 127487236.597620268 (2040/02/21 11:35:32) Originator - Receive Timestamp: +921447565.014500764 Originator - Transmit Timestamp: +731440784.800140969 I have only seen this oddity from chronyd hosts... RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dougb at dougbarton.us Sun Dec 18 03:15:31 2016 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 17 Dec 2016 19:15:31 -0800 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <20161216214834.GI16300@bamboo.slabnet.com> References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> Message-ID: <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> On 12/16/2016 1:48 PM, Hugo Slabbert wrote: > This started as a technical appeal, but: > > https://www.nanog.org/list > > 1. Discussion will focus on Internet operational and technical issues as > described in the charter of NANOG. Hard to see how the OP has anything to do with either of the above. From gem at rellim.com Sun Dec 18 03:25:38 2016 From: gem at rellim.com (Gary E. Miller) Date: Sat, 17 Dec 2016 19:25:38 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <20161217175455.30107c37@spidey.rellim.com> References: <20161217175455.30107c37@spidey.rellim.com> Message-ID: <20161217192538.7b74386f@spidey.rellim.com> Yo All! On Sat, 17 Dec 2016 17:54:55 -0800 "Gary E. Miller" wrote: > # tcpdump -nvvi eth0 port 123 |grep "Originator - Transmit Timestamp:" > > And I do indeed get odd results. Some on my local network... To follow up on my own post, so this can be promply laid to rest. After some discussion at NTPsec. It seems that chronyd takes a lot of 'creative license' with RFC 5905 (NTPv4). But it is not malicious, just 'odd', and not new. So, nothing see here, back to the hunt for the real cause of the new NTP traffic. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From large.hadron.collider at gmx.com Sun Dec 18 04:15:58 2016 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Sat, 17 Dec 2016 20:15:58 -0800 Subject: Not a representative of gmx.com but their emails are being blocked by those who subscribe to the SORBS RBL. Message-ID: <54d75b90-7549-b95f-353e-a4a743ecf955@gmx.com> Does anyone have information on why this is, and if you represent SORBS and/or GMX and/or both, would you please trouble yourself with contacting me off-list? From ken at wemonitoremail.com Sun Dec 18 13:24:43 2016 From: ken at wemonitoremail.com (Ken O'Driscoll) Date: Sun, 18 Dec 2016 13:24:43 +0000 Subject: Not a representative of gmx.com but their emails are being blocked by those who subscribe to the SORBS RBL. In-Reply-To: <54d75b90-7549-b95f-353e-a4a743ecf955@gmx.com> References: <54d75b90-7549-b95f-353e-a4a743ecf955@gmx.com> Message-ID: <1482067483.2380.6.camel@wemonitoremail.com> On Sat, 2016-12-17 at 20:15 -0800, Large Hadron Collider wrote: > Does anyone have information on why this is, and if you represent SORBS? > and/or GMX and/or both, would you please trouble yourself with? > contacting me off-list? You can find out why an IP was listed via their lookup facility: http://www. sorbs.net/lookup.shtml You can request de-listing by opening a support request: http://www.sorbs.net/cgi-bin/support You don't need to be an IP block owner to request de-listing but you do need to be empowered to stop whatever caused the listing in the first place. Their support is very responsive. Ken. --?? Ken O'Driscoll / We Monitor Email t: +353 1 254 9400 | w: www.wemonitoremail.com From beecher at beecher.cc Sun Dec 18 19:08:05 2016 From: beecher at beecher.cc (Tom Beecher) Date: Sun, 18 Dec 2016 19:08:05 +0000 Subject: Not a representative of gmx.com but their emails are being blocked by those who subscribe to the SORBS RBL. In-Reply-To: <1482067483.2380.6.camel@wemonitoremail.com> References: <54d75b90-7549-b95f-353e-a4a743ecf955@gmx.com> <1482067483.2380.6.camel@wemonitoremail.com> Message-ID: I tend to scratch my head at anyone still using SORBS at this point. On Sun, Dec 18, 2016 at 8:27 AM Ken O'Driscoll wrote: > On Sat, 2016-12-17 at 20:15 -0800, Large Hadron Collider wrote: > > > Does anyone have information on why this is, and if you represent SORBS > > > and/or GMX and/or both, would you please trouble yourself with > > > contacting me off-list? > > > > You can find out why an IP was listed via their lookup facility: > > http://www. > > sorbs.net/lookup.shtml > > > > You can request de-listing by opening a support request: > > http://www.sorbs.net/cgi-bin/support > > > > You don't need to be an IP block owner to request de-listing but you do > need to be empowered to stop whatever caused the listing in the first > place. Their support is very responsive. > > > > Ken. > > > > -- > > Ken O'Driscoll / We Monitor Email > > t: +353 1 254 9400 | w: www.wemonitoremail.com > > > > From david at mailplus.nl Mon Dec 19 11:02:23 2016 From: david at mailplus.nl (David Hofstee) Date: Mon, 19 Dec 2016 12:02:23 +0100 (CET) Subject: Not a representative of gmx.com but their emails are being blocked by those who subscribe to the SORBS RBL. In-Reply-To: References: <54d75b90-7549-b95f-353e-a4a743ecf955@gmx.com> <1482067483.2380.6.camel@wemonitoremail.com> Message-ID: <522624273.4529017.1482145343676.JavaMail.zimbra@office.bmholding.nl> Sorbs is a pretty good list. And I've been on the listed-side too. I personally would not use it to block, but I would give it 3 of the 5 points. The anti-spam gang is never going to be perfect. But since (self)regulation is not working, we need them. I value them at the moment. The only thing you can do about it, is figuring a way to solve this security issue (called spam). Met vriendelijke groet, David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) ----- Oorspronkelijk bericht ----- Van: "Tom Beecher" Aan: "Ken O'Driscoll" , nanog at nanog.org Verzonden: Zondag 18 december 2016 20:08:05 Onderwerp: Re: Not a representative of gmx.com but their emails are being blocked by those who subscribe to the SORBS RBL. I tend to scratch my head at anyone still using SORBS at this point. On Sun, Dec 18, 2016 at 8:27 AM Ken O'Driscoll wrote: > On Sat, 2016-12-17 at 20:15 -0800, Large Hadron Collider wrote: > > > Does anyone have information on why this is, and if you represent SORBS > > > and/or GMX and/or both, would you please trouble yourself with > > > contacting me off-list? > > > > You can find out why an IP was listed via their lookup facility: > > http://www. > > sorbs.net/lookup.shtml > > > > You can request de-listing by opening a support request: > > http://www.sorbs.net/cgi-bin/support > > > > You don't need to be an IP block owner to request de-listing but you do > need to be empowered to stop whatever caused the listing in the first > place. Their support is very responsive. > > > > Ken. > > > > -- > > Ken O'Driscoll / We Monitor Email > > t: +353 1 254 9400 | w: www.wemonitoremail.com > > > > From admin at coldnorthadmin.com Mon Dec 19 18:29:19 2016 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Mon, 19 Dec 2016 13:29:19 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: <20161217192538.7b74386f@spidey.rellim.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> Message-ID: <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> I also have a similar experience with an increased load. I'm running a pretty basic Linode VPS and I had to fine tune a few things in order to deal with the increased traffic. I can clearly see a date around the 14-15 where my traffic increases to 3-4 times the usual amounts. I did a quick dump and in 60 seconds I was hit by slightly over 190K IPs http://i.imgur.com/mygYINk.png Weird stuff Laurent On 12/17/2016 10:25 PM, Gary E. Miller wrote: > Yo All! > > On Sat, 17 Dec 2016 17:54:55 -0800 > "Gary E. Miller" wrote: > >> # tcpdump -nvvi eth0 port 123 |grep "Originator - Transmit Timestamp:" >> >> And I do indeed get odd results. Some on my local network... > To follow up on my own post, so this can be promply laid to rest. > > After some discussion at NTPsec. It seems that chronyd takes a lot > of 'creative license' with RFC 5905 (NTPv4). But it is not malicious, > just 'odd', and not new. > > So, nothing see here, back to the hunt for the real cause of the new > NTP traffic. > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > gem at rellim.com Tel:+1 541 382 8588 From cb.list6 at gmail.com Mon Dec 19 18:33:52 2016 From: cb.list6 at gmail.com (Ca By) Date: Mon, 19 Dec 2016 18:33:52 +0000 Subject: Recent NTP pool traffic increase In-Reply-To: <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> Message-ID: My WAG is that the one plus updated firmeware on that day and they baked in the pool. Complete WAG, but time and distributed sources including wireless networks On Mon, Dec 19, 2016 at 10:30 AM Laurent Dumont wrote: > I also have a similar experience with an increased load. > > > > I'm running a pretty basic Linode VPS and I had to fine tune a few > > things in order to deal with the increased traffic. I can clearly see a > > date around the 14-15 where my traffic increases to 3-4 times the usual > > amounts. > > > > I did a quick dump and in 60 seconds I was hit by slightly over 190K IPs > > > > http://i.imgur.com/mygYINk.png > > > > Weird stuff > > > > Laurent > > > > > > On 12/17/2016 10:25 PM, Gary E. Miller wrote: > > > Yo All! > > > > > > On Sat, 17 Dec 2016 17:54:55 -0800 > > > "Gary E. Miller" wrote: > > > > > >> # tcpdump -nvvi eth0 port 123 |grep "Originator - Transmit Timestamp:" > > >> > > >> And I do indeed get odd results. Some on my local network... > > > To follow up on my own post, so this can be promply laid to rest. > > > > > > After some discussion at NTPsec. It seems that chronyd takes a lot > > > of 'creative license' with RFC 5905 (NTPv4). But it is not malicious, > > > just 'odd', and not new. > > > > > > So, nothing see here, back to the hunt for the real cause of the new > > > NTP traffic. > > > > > > RGDS > > > GARY > > > > --------------------------------------------------------------------------- > > > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > > > gem at rellim.com Tel:+1 541 382 8588 > > > > From denys at visp.net.lb Mon Dec 19 19:11:24 2016 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Mon, 19 Dec 2016 21:11:24 +0200 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> Message-ID: I noticed now many customers using tp-links reported issues with internet connection. Analyzing internet traffic, i noticed that tp-link seems excessively requesting ntp from those ip addresses, and not trying others: > 192.5.41.40.123: NTPv3, Client, length 48 > 192.5.41.41.123: NTPv3, Client, length 48 > 133.100.9.2.123: NTPv3, Client, length 48 I'm asking customer to make photo of device, to retrieve model and revision, and checking other customers as well, if they are abusing same servers. On 2016-12-19 20:33, Ca By wrote: > My WAG is that the one plus updated firmeware on that day and they > baked in > the pool. > > Complete WAG, but time and distributed sources including wireless > networks > > > On Mon, Dec 19, 2016 at 10:30 AM Laurent Dumont > > wrote: > >> I also have a similar experience with an increased load. >> >> >> >> I'm running a pretty basic Linode VPS and I had to fine tune a few >> >> things in order to deal with the increased traffic. I can clearly see >> a >> >> date around the 14-15 where my traffic increases to 3-4 times the >> usual >> >> amounts. >> >> >> >> I did a quick dump and in 60 seconds I was hit by slightly over 190K >> IPs >> >> >> >> http://i.imgur.com/mygYINk.png >> >> >> >> Weird stuff >> >> >> >> Laurent >> >> >> >> >> >> On 12/17/2016 10:25 PM, Gary E. Miller wrote: >> >> > Yo All! >> >> > >> >> > On Sat, 17 Dec 2016 17:54:55 -0800 >> >> > "Gary E. Miller" wrote: >> >> > >> >> >> # tcpdump -nvvi eth0 port 123 |grep "Originator - Transmit Timestamp:" >> >> >> >> >> >> And I do indeed get odd results. Some on my local network... >> >> > To follow up on my own post, so this can be promply laid to rest. >> >> > >> >> > After some discussion at NTPsec. It seems that chronyd takes a lot >> >> > of 'creative license' with RFC 5905 (NTPv4). But it is not malicious, >> >> > just 'odd', and not new. >> >> > >> >> > So, nothing see here, back to the hunt for the real cause of the new >> >> > NTP traffic. >> >> > >> >> > RGDS >> >> > GARY >> >> > >> --------------------------------------------------------------------------- >> >> > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 >> >> > gem at rellim.com Tel:+1 541 382 8588 >> >> >> >> From denys at visp.net.lb Mon Dec 19 19:22:11 2016 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Mon, 19 Dec 2016 21:22:11 +0200 Subject: Recent NTP pool traffic increase (update) In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> Message-ID: <1c45fa7a2425045d30efb3623bbe3d5a@nuclearcat.com> Many sorry! Update, seems illiterate in english (worse than me, hehe) customer was not precise about model of router, while he reported issue. I noticed now many customers using specific models of routers reported issues with internet connection. Analyzing internet traffic, i noticed that this routers seems excessively requesting ntp from those ip addresses, and not trying others: > 192.5.41.40.123: NTPv3, Client, length 48 > 192.5.41.41.123: NTPv3, Client, length 48 > 133.100.9.2.123: NTPv3, Client, length 48 I'm asking customer to make photo of device, to retrieve model and revision, and checking other customers as well, if they are abusing same servers. There is definitely pattern, that all of them are using just this 3 hardcoded servers. Problem is that many customers are changing mac of router, so i cannot clearly identify vendor by first mac nibbles. He sent me 2 photos, one of them LB-Link (mac vendor lookup 20:f4:1b says Shenzhen Bilian electronic CO.,LTD), another is Tenda (c8:3a:35 is Tenda). If it is necessary i can investigate further. On 2016-12-19 20:33, Ca By wrote: > My WAG is that the one plus updated firmeware on that day and they > baked in > the pool. > > Complete WAG, but time and distributed sources including wireless > networks > > > On Mon, Dec 19, 2016 at 10:30 AM Laurent Dumont > > wrote: > >> I also have a similar experience with an increased load. >> >> >> >> I'm running a pretty basic Linode VPS and I had to fine tune a few >> >> things in order to deal with the increased traffic. I can clearly see >> a >> >> date around the 14-15 where my traffic increases to 3-4 times the >> usual >> >> amounts. >> >> >> >> I did a quick dump and in 60 seconds I was hit by slightly over 190K >> IPs >> >> >> >> http://i.imgur.com/mygYINk.png >> >> >> >> Weird stuff >> >> >> >> Laurent >> >> >> >> >> >> On 12/17/2016 10:25 PM, Gary E. Miller wrote: >> >> > Yo All! >> >> > >> >> > On Sat, 17 Dec 2016 17:54:55 -0800 >> >> > "Gary E. Miller" wrote: >> >> > >> >> >> # tcpdump -nvvi eth0 port 123 |grep "Originator - Transmit Timestamp:" >> >> >> >> >> >> And I do indeed get odd results. Some on my local network... >> >> > To follow up on my own post, so this can be promply laid to rest. >> >> > >> >> > After some discussion at NTPsec. It seems that chronyd takes a lot >> >> > of 'creative license' with RFC 5905 (NTPv4). But it is not malicious, >> >> > just 'odd', and not new. >> >> > >> >> > So, nothing see here, back to the hunt for the real cause of the new >> >> > NTP traffic. >> >> > >> >> > RGDS >> >> > GARY >> >> > >> --------------------------------------------------------------------------- >> >> > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 >> >> > gem at rellim.com Tel:+1 541 382 8588 >> >> >> >> From opendak at shaw.ca Mon Dec 19 19:52:59 2016 From: opendak at shaw.ca (David) Date: Mon, 19 Dec 2016 12:52:59 -0700 Subject: Recent NTP pool traffic increase In-Reply-To: <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> Message-ID: <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> On 2016-12-19 11:29 AM, Laurent Dumont wrote: > I also have a similar experience with an increased load. > > I'm running a pretty basic Linode VPS and I had to fine tune a few > things in order to deal with the increased traffic. I can clearly see a > date around the 14-15 where my traffic increases to 3-4 times the usual > amounts. From a source network point of view we see devices come online and hit ~35 unique NTP servers within a few seconds. I'll try to see if I can track down what type of devices they are. > > I did a quick dump and in 60 seconds I was hit by slightly over 190K IPs > > http://i.imgur.com/mygYINk.png > > Weird stuff > > Laurent > > > On 12/17/2016 10:25 PM, Gary E. Miller wrote: >> Yo All! >> >> On Sat, 17 Dec 2016 17:54:55 -0800 >> "Gary E. Miller" wrote: >> >>> # tcpdump -nvvi eth0 port 123 |grep "Originator - Transmit Timestamp:" >>> >>> And I do indeed get odd results. Some on my local network... >> To follow up on my own post, so this can be promply laid to rest. >> >> After some discussion at NTPsec. It seems that chronyd takes a lot >> of 'creative license' with RFC 5905 (NTPv4). But it is not malicious, >> just 'odd', and not new. >> >> So, nothing see here, back to the hunt for the real cause of the new >> NTP traffic. >> >> RGDS >> GARY >> --------------------------------------------------------------------------- >> >> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 >> gem at rellim.com Tel:+1 541 382 8588 > From opendak at shaw.ca Mon Dec 19 20:32:50 2016 From: opendak at shaw.ca (David) Date: Mon, 19 Dec 2016 13:32:50 -0700 Subject: Recent NTP pool traffic increase In-Reply-To: <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> Message-ID: On 2016-12-19 12:52 PM, David wrote: > On 2016-12-19 11:29 AM, Laurent Dumont wrote: >> I also have a similar experience with an increased load. >> >> I'm running a pretty basic Linode VPS and I had to fine tune a few >> things in order to deal with the increased traffic. I can clearly see a >> date around the 14-15 where my traffic increases to 3-4 times the usual >> amounts. > > From a source network point of view we see devices come online and hit > ~35 unique NTP servers within a few seconds. > > I'll try to see if I can track down what type of devices they are. > I found devices doing lookups for all of these at the same time {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa,europe}.pool.ntp.org and then it proceeds to use everything returned, which explains why everyone is seeing an increase. From denys at visp.net.lb Mon Dec 19 20:33:15 2016 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Mon, 19 Dec 2016 22:33:15 +0200 Subject: Recent NTP pool traffic increase (update) In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <1c45fa7a2425045d30efb3623bbe3d5a@nuclearcat.com> Message-ID: I'm not sure if this issue relevant to discussed topic, Tenda routers here for a while on market, and i think i noticed this issue just now, because NTP servers they are using supposedly for healthcheck went down (or NTP owners blocked ISP's i support, due such routers). At least after checking numerous users, i believe Tenda hardcoded those NTP IPs. What worsen issue, that in Lebanon several times per day, for example at 18pm - short electricity cutoff, and majority of users routers will reboot and surely reconnect, so it will look like a countrywide spike in NTP traffic. I checked for a 10min also this NTP ips in dns responses, none of thousands of users tried to resolve any name with them over any DNS server, so i conclude they are hardcoded somewhere in firmware. Here is traffic of Tenda router after reconnecting (but not full powercycle, i dont have it in my hands). But as you can see, no DNS resolution attempts: 20:15:59.305739 PPPoE [ses 0x1483] CHAP, Success (0x03), id 1, Msg S=XXXXXX M=Authentication succeeded 20:15:59.306100 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 1, length 12 20:15:59.317840 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 1, length 24 20:15:59.317841 PPPoE [ses 0x1483] IPCP, Conf-Ack (0x02), id 1, length 12 20:15:59.317867 PPPoE [ses 0x1483] IPCP, Conf-Nack (0x03), id 1, length 18 20:15:59.325253 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 2, length 24 20:15:59.325273 PPPoE [ses 0x1483] IPCP, Conf-Ack (0x02), id 2, length 24 20:15:59.335589 PPPoE [ses 0x1483] IP 172.17.49.245.123 > 133.100.9.2.123: NTPv3, Client, length 48 20:15:59.335588 PPPoE [ses 0x1483] IP 172.17.49.245.123 > 192.5.41.41.123: NTPv3, Client, length 48 20:15:59.335588 PPPoE [ses 0x1483] IP 172.17.49.245.123 > 192.5.41.40.123: NTPv3, Client, length 48 Here is example of Tenda traffic if it is unable to reach destination, it repeats request each 10 seconds endlessly, my guess they are using ntp to show status of internet connection. So, now that NTP servers getting quite significant DDoS such way. 19:57:52.162863 IP (tos 0x0, ttl 64, id 38515, offset 0, flags [none], proto UDP (17), length 76) 172.16.31.67.123 > 192.5.41.40.123: [udp sum ok] NTPv3, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) 19:57:52.163277 IP (tos 0x0, ttl 64, id 38516, offset 0, flags [none], proto UDP (17), length 76) 172.16.31.67.123 > 192.5.41.41.123: [udp sum ok] NTPv3, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) 19:57:52.164435 IP (tos 0x0, ttl 64, id 38517, offset 0, flags [none], proto UDP (17), length 76) 172.16.31.67.123 > 133.100.9.2.123: [udp sum ok] NTPv3, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) 19:58:02.164781 IP (tos 0x0, ttl 64, id 38518, offset 0, flags [none], proto UDP (17), length 76) 172.16.31.67.123 > 192.5.41.40.123: [udp sum ok] NTPv3, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) 19:58:02.164884 IP (tos 0x0, ttl 64, id 38519, offset 0, flags [none], proto UDP (17), length 76) 172.16.31.67.123 > 192.5.41.41.123: [udp sum ok] NTPv3, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) 19:58:02.165061 IP (tos 0x0, ttl 64, id 38520, offset 0, flags [none], proto UDP (17), length 76) 172.16.31.67.123 > 133.100.9.2.123: [udp sum ok] NTPv3, length 48 Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) On 2016-12-19 21:40, Roland Dobbins wrote: > On 20 Dec 2016, at 2:22, Denys Fedoryshchenko wrote: > >> If it is necessary i can investigate further. > > Yes, please! > > ----------------------------------- > Roland Dobbins From Valdis.Kletnieks at vt.edu Mon Dec 19 20:35:25 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 19 Dec 2016 15:35:25 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> Message-ID: <10667.1482179725@turing-police.cc.vt.edu> On Mon, 19 Dec 2016 12:52:59 -0700, David said: > From a source network point of view we see devices come online and hit > ~35 unique NTP servers within a few seconds. Am I the only one who read that and started wondering if some engineer writing CPE code read a recommendation someplace to "query 3-5 different servers" and managed to miss the "-"? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From dan-nanog at drown.org Mon Dec 19 20:44:34 2016 From: dan-nanog at drown.org (Dan Drown) Date: Mon, 19 Dec 2016 14:44:34 -0600 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> Message-ID: <20161219144434.Horde.w0NH8X6rYsIa1ujrCPuLzkE@mail.drown.org> Quoting David : > I found devices doing lookups for all of these at the same time > {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa,europe}.pool.ntp.org and then it proceeds to use everything returned, which explains why everyone is seeing an > increase. I'm very interested to find out what devices these are. This would explain why places like New Zealand are getting massive amounts of NTP traffic from North America. From ask at develooper.com Mon Dec 19 02:26:34 2016 From: ask at develooper.com (=?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?=) Date: Sun, 18 Dec 2016 18:26:34 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: References: Message-ID: <46148C1B-E31C-4E17-8463-07BDFB59CCBE@develooper.com> > On Dec 15, 2016, at 14:45, Jose Gerardo Perales Soto wrote: > > We've recently experienced a traffic increase on the NTP queries to NTP pool project (pool.ntp.org) servers. One theory is that some service provider NTP infraestructure failed approximately 2 days ago and traffic is now being redirected to servers belonging to the NTP pool project. Hi Jose, It?s more widespread than a particular service provider, so it seems more likely it?s a software update for some ?IoT? device or similar. The increase in DNS queries was on the ?non-vendor? names, so it?s difficult to know who it is without being on a local network with one of the bad device The increase in DNS queries is much smaller than the increase in NTP queries that are being seen, so it?s not just more clients, but badly behaving ones. :-( https://status.ntppool.org/incidents/vps6y4mm0m69 If you have NTP servers that can be added to the pool. it?d be greatly appreciated. http://www.pool.ntp.org/join.html Ask From opendak at shaw.ca Mon Dec 19 21:12:27 2016 From: opendak at shaw.ca (David) Date: Mon, 19 Dec 2016 14:12:27 -0700 Subject: Recent NTP pool traffic increase In-Reply-To: <20161219205556.GA25715@32k.org> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> Message-ID: On 2016-12-19 1:55 PM, Jan Tore Morken wrote: > On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote: >> I found devices doing lookups for all of these at the same time >> {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa,europe}.pool.ntp.org >> and then it proceeds to use everything returned, which explains why >> everyone is seeing an increase. > > Thanks, David. That perfectly matches the list of servers used by > older versions of the ios-ntp library[1][2], which would point toward > some iPhone app being the source of the traffic. > > [1] https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts > [2] https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9dec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122 > That would make sense - I see a lot of iCloud related lookups from these hosts as well. Also, app.snapchat.com generally seems to follow just after the NTP pool DNS lookups. I don't have an iPhone to test that though. Thanks, From justin at cloudflare.com Mon Dec 19 21:19:40 2016 From: justin at cloudflare.com (Justin Paine) Date: Mon, 19 Dec 2016 13:19:40 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> Message-ID: the new Mario app perhaps? :) ____________ Justin Paine Head of Trust & Safety Cloudflare Inc. PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D On Mon, Dec 19, 2016 at 1:12 PM, David wrote: > On 2016-12-19 1:55 PM, Jan Tore Morken wrote: >> >> On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote: >>> >>> I found devices doing lookups for all of these at the same time >>> >>> {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa,europe}.pool.ntp.org >>> and then it proceeds to use everything returned, which explains why >>> everyone is seeing an increase. >> >> >> Thanks, David. That perfectly matches the list of servers used by >> older versions of the ios-ntp library[1][2], which would point toward >> some iPhone app being the source of the traffic. >> >> [1] >> https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts >> [2] >> https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9dec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122 >> > > That would make sense - I see a lot of iCloud related lookups from these > hosts as well. > > Also, app.snapchat.com generally seems to follow just after the NTP pool DNS > lookups. I don't have an iPhone to test that though. > > Thanks, > From dan-nanog at drown.org Mon Dec 19 21:49:11 2016 From: dan-nanog at drown.org (Dan Drown) Date: Mon, 19 Dec 2016 15:49:11 -0600 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> Message-ID: <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> Quoting David : > On 2016-12-19 1:55 PM, Jan Tore Morken wrote: >> On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote: >>> I found devices doing lookups for all of these at the same time >>> {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa}.pool.ntp.org >>> and then it proceeds to use everything returned, which explains why >>> everyone is seeing an increase. >> >> Thanks, David. That perfectly matches the list of servers used by >> older versions of the ios-ntp library[1][2], which would point toward >> some iPhone app being the source of the traffic. >> >> [1] >> https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts >> [2] >> https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9dec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122 >> > > That would make sense - I see a lot of iCloud related lookups from > these hosts as well. > > Also, app.snapchat.com generally seems to follow just after the NTP > pool DNS lookups. I don't have an iPhone to test that though. Confirmed - starting up the iOS Snapchat app does a lookup to the domains you listed, and then sends NTP to every unique IP. Around 35-60 different IPs. Anyone have a contact at Snapchat? From justin at cloudflare.com Mon Dec 19 22:12:49 2016 From: justin at cloudflare.com (Justin Paine) Date: Mon, 19 Dec 2016 14:12:49 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> Message-ID: replying off list. ____________ Justin Paine Head of Trust & Safety Cloudflare Inc. PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D On Mon, Dec 19, 2016 at 1:49 PM, Dan Drown wrote: > Quoting David : >> >> On 2016-12-19 1:55 PM, Jan Tore Morken wrote: >>> >>> On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote: >>>> >>>> I found devices doing lookups for all of these at the same time >>>> >>>> {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa}.pool.ntp.org >>>> and then it proceeds to use everything returned, which explains why >>>> everyone is seeing an increase. >>> >>> >>> Thanks, David. That perfectly matches the list of servers used by >>> older versions of the ios-ntp library[1][2], which would point toward >>> some iPhone app being the source of the traffic. >>> >>> [1] >>> https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts >>> [2] >>> https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9dec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122 >>> >> >> That would make sense - I see a lot of iCloud related lookups from these >> hosts as well. >> >> Also, app.snapchat.com generally seems to follow just after the NTP pool >> DNS lookups. I don't have an iPhone to test that though. > > > Confirmed - starting up the iOS Snapchat app does a lookup to the domains > you listed, and then sends NTP to every unique IP. Around 35-60 different > IPs. > > Anyone have a contact at Snapchat? From nanog at jantore.net Mon Dec 19 20:55:56 2016 From: nanog at jantore.net (Jan Tore Morken) Date: Mon, 19 Dec 2016 21:55:56 +0100 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> Message-ID: <20161219205556.GA25715@32k.org> On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote: > I found devices doing lookups for all of these at the same time > {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa,europe}.pool.ntp.org > and then it proceeds to use everything returned, which explains why > everyone is seeing an increase. Thanks, David. That perfectly matches the list of servers used by older versions of the ios-ntp library[1][2], which would point toward some iPhone app being the source of the traffic. [1] https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts [2] https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9dec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122 -- Jan Tore Morken From jason at rokeach.net Mon Dec 19 21:15:01 2016 From: jason at rokeach.net (Jason Rokeach) Date: Mon, 19 Dec 2016 16:15:01 -0500 Subject: Google Global Cache Contact Message-ID: Hi folks, could a contact for GGC contact me off-list? Thank you! - Jason R. Rokeach From hannigan at gmail.com Tue Dec 20 04:04:59 2016 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 19 Dec 2016 23:04:59 -0500 Subject: Google Global Cache Contact In-Reply-To: References: Message-ID: Jason, In case you haven't already heard from the good people at Google: http://bit.ly/2hTJOhX Best, -M< On Mon, Dec 19, 2016 at 4:15 PM, Jason Rokeach wrote: > Hi folks, could a contact for GGC contact me off-list? > > Thank you! > - Jason R. Rokeach From admin at coldnorthadmin.com Tue Dec 20 05:18:18 2016 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Tue, 20 Dec 2016 00:18:18 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> Message-ID: <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> If anything comes from this, I'd love to hear about it. As a student in the field, this is the kind of stuff I live for! ;) Pretty awesome to see the chain of events after seeing a post on the [pool] list! Laurent On 12/19/2016 05:12 PM, Justin Paine via NANOG wrote: > replying off list. > > ____________ > Justin Paine > Head of Trust & Safety > Cloudflare Inc. > PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D > > > On Mon, Dec 19, 2016 at 1:49 PM, Dan Drown wrote: >> Quoting David : >>> On 2016-12-19 1:55 PM, Jan Tore Morken wrote: >>>> On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote: >>>>> I found devices doing lookups for all of these at the same time >>>>> >>>>> {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa}.pool.ntp.org >>>>> and then it proceeds to use everything returned, which explains why >>>>> everyone is seeing an increase. >>>> >>>> Thanks, David. That perfectly matches the list of servers used by >>>> older versions of the ios-ntp library[1][2], which would point toward >>>> some iPhone app being the source of the traffic. >>>> >>>> [1] >>>> https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts >>>> [2] >>>> https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9dec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122 >>>> >>> That would make sense - I see a lot of iCloud related lookups from these >>> hosts as well. >>> >>> Also, app.snapchat.com generally seems to follow just after the NTP pool >>> DNS lookups. I don't have an iPhone to test that though. >> >> Confirmed - starting up the iOS Snapchat app does a lookup to the domains >> you listed, and then sends NTP to every unique IP. Around 35-60 different >> IPs. >> >> Anyone have a contact at Snapchat? From jay at west.net Tue Dec 20 07:39:50 2016 From: jay at west.net (Jay Hennigan) Date: Mon, 19 Dec 2016 23:39:50 -0800 Subject: South Carolina attempts to repeal Rule 34 Message-ID: Break out the popcorn. http://www.charlotteobserver.com/news/local/article121673402.html -- -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From cheetahmorph at gmail.com Tue Dec 20 08:25:34 2016 From: cheetahmorph at gmail.com (Jippen) Date: Tue, 20 Dec 2016 08:25:34 +0000 Subject: South Carolina attempts to repeal Rule 34 In-Reply-To: References: Message-ID: So, $20 tax on all computers sold in SC in practice On Mon, Dec 19, 2016, 11:41 PM Jay Hennigan wrote: > Break out the popcorn. > > http://www.charlotteobserver.com/news/local/article121673402.html > > -- > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > From oscar.vives at gmail.com Tue Dec 20 10:26:56 2016 From: oscar.vives at gmail.com (Tei) Date: Tue, 20 Dec 2016 11:26:56 +0100 Subject: South Carolina attempts to repeal Rule 34 In-Reply-To: References: Message-ID: Users are crafty. One user on a network I had to admin use to mail porn has Microsoft Word documents to his Gmail account. So if you want to stop porn, you have to ban file attachments and monospace fonts. Good luck with that. On 20 December 2016 at 09:25, Jippen wrote: > So, $20 tax on all computers sold in SC in practice > > On Mon, Dec 19, 2016, 11:41 PM Jay Hennigan wrote: > >> Break out the popcorn. >> >> http://www.charlotteobserver.com/news/local/article121673402.html >> >> -- >> -- >> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net >> Impulse Internet Service - http://www.impulse.net/ >> Your local telephone and internet company - 805 884-6323 - WB6RDV >> -- -- ?in del ?ensaje. From dovid at telecurve.com Tue Dec 20 10:55:59 2016 From: dovid at telecurve.com (Dovid Bender) Date: Tue, 20 Dec 2016 05:55:59 -0500 Subject: South Carolina attempts to repeal Rule 34 In-Reply-To: References: Message-ID: Let's call it for what it is. It's a new tax. The manufactures/stores etc. wont want to he held liable and they will simply include the cost when selling a PC (does anyone other than us buy one of those these days?) On Tue, Dec 20, 2016 at 5:26 AM, Tei wrote: > Users are crafty. > > One user on a network I had to admin use to mail porn has Microsoft > Word documents to his Gmail account. > > So if you want to stop porn, you have to ban file attachments and > monospace fonts. > > Good luck with that. > > On 20 December 2016 at 09:25, Jippen wrote: > > So, $20 tax on all computers sold in SC in practice > > > > On Mon, Dec 19, 2016, 11:41 PM Jay Hennigan wrote: > > > >> Break out the popcorn. > >> > >> http://www.charlotteobserver.com/news/local/article121673402.html > >> > >> -- > >> -- > >> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > >> Impulse Internet Service - http://www.impulse.net/ > >> Your local telephone and internet company - 805 884-6323 - WB6RDV > >> > > > > -- > -- > ?in del ?ensaje. > From rdobbins at arbor.net Tue Dec 20 11:50:49 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Tue, 20 Dec 2016 18:50:49 +0700 Subject: Recent NTP pool traffic increase In-Reply-To: <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> Message-ID: <81907D75-303B-4D11-8E76-AD2E04521567@arbor.net> On 20 Dec 2016, at 12:18, Laurent Dumont wrote: > As a student in the field, this is the kind of stuff I live for! ;) ----------------------------------- Roland Dobbins From list at satchell.net Tue Dec 20 14:37:50 2016 From: list at satchell.net (Stephen Satchell) Date: Tue, 20 Dec 2016 06:37:50 -0800 Subject: South Carolina attempts to repeal Rule 34 In-Reply-To: References: Message-ID: <22524a85-6c1e-609f-9176-543f794b0217@satchell.net> On 12/19/2016 11:39 PM, Jay Hennigan wrote: > Break out the popcorn. > > http://www.charlotteobserver.com/news/local/article121673402.html > "A bill pre-filed this month by state Rep. Bill Chumley would require sellers to install digital blocking capabilities on computers and other devices that access the internet to prevent the viewing of obscene content." 1. Buy computer without the $20 tax 2. Erase operating system 3. Install Linux Mint (or one's favourite distribution) 4. PROFIT! "The bill would fine manufacturers that sell a device without the blocking system..." How about if the manufacturer doesn't install an operating system? Getting this vaguely back to NANOG territory, this is a far greater improvement over the "plan" to have ISPs block the traffic on their side of the customer/ISP interface. THAT is just an invitation to pick up a mallet and play whack-a-mole... (N.B.: if this were extended to other states, like Nevada, then stores like Suzie's in Reno would only increase their business selling porn DVDs.) From royce at techsolvency.com Tue Dec 20 15:23:45 2016 From: royce at techsolvency.com (Royce Williams) Date: Tue, 20 Dec 2016 06:23:45 -0900 Subject: Recent NTP pool traffic increase In-Reply-To: <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> Message-ID: On Mon, Dec 19, 2016 at 12:49 PM, Dan Drown wrote: > Quoting David : >> >> On 2016-12-19 1:55 PM, Jan Tore Morken wrote: >>> >>> On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote: >>>> >>>> I found devices doing lookups for all of these at the same time >>>> >>>> {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa}.pool.ntp.org >>>> and then it proceeds to use everything returned, which explains why >>>> everyone is seeing an increase. >>> >>> >>> Thanks, David. That perfectly matches the list of servers used by >>> older versions of the ios-ntp library[1][2], which would point toward >>> some iPhone app being the source of the traffic. >>> >>> [1] >>> https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts >>> [2] >>> https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9dec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122 >>> >> >> That would make sense - I see a lot of iCloud related lookups from these >> hosts as well. >> >> Also, app.snapchat.com generally seems to follow just after the NTP pool >> DNS lookups. I don't have an iPhone to test that though. > > > Confirmed - starting up the iOS Snapchat app does a lookup to the domains > you listed, and then sends NTP to every unique IP. Around 35-60 different > IPs. > > Anyone have a contact at Snapchat? Looks like folks got in touch with them. Thanks! https://community.ntppool.org/t/recent-ntp-pool-traffic-increase/18 Royce From royce at techsolvency.com Tue Dec 20 16:08:26 2016 From: royce at techsolvency.com (Royce Williams) Date: Tue, 20 Dec 2016 07:08:26 -0900 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> Message-ID: n Sat, Dec 17, 2016 at 6:15 PM, Doug Barton wrote: > On 12/16/2016 1:48 PM, Hugo Slabbert wrote: >> >> This started as a technical appeal, but: >> >> https://www.nanog.org/list >> >> 1. Discussion will focus on Internet operational and technical issues as >> described in the charter of NANOG. > > Hard to see how the OP has anything to do with either of the above. Actually, it's not that hard ... *if* we can control ourselves from making them partisan, and focus instead on the operational aspects. (Admittedly, that's pretty hard!) The OP's query was a logical combination of two concepts: - First, from the charter (emphasis mine): "NANOG provides a forum where people from the network research community, the network operator community and the network vendor community can come together *to identify and solve the problems that arise in operating and growing the Internet*." - Second, from John Gilmore: "The Net interprets censorship as damage and routes around it." The OP appears to be managing risk associated with a (perhaps low) chance of future censorship. Was the OP asking a straight question about BGP or SFPs or CDNs? Of course not. But should doctors only talk about surgical technique -- and not about, say, the need for a living will? Of course not. IMO, *operational, politics-free* discussion of items like these would also be on topic for NANOG: - Some *operational* workarounds for country-wide blocking of Facebook, Whatsapp, and Twitter [1], or Signal [2] - The *operational* challenges of replicating the Internet Archive to Canada [3] Each operator has to make such risk calculations for themselves. Some may see the "NA" in NANOG as insurance that such censorship could never happen here. Others -- especially those who came from other countries -- may feel differently. Put another way: Everyone has a line at which "I don't care what's in the pipes, I just work here" changes into something more actionable. Being *operationally* ready for that day seems like a good idea to me. Royce 1. http://www.telegraph.co.uk/technology/2016/12/20/turkey-blocks-access-facebook-twitter-whatsapp-following-ambassadors/ 2. http://www.nytimes.com/aponline/2016/12/20/world/middleeast/ap-ml-egypt-app-blocked.html 3. https://blog.archive.org/2016/11/29/help-us-keep-the-archive-free-accessible-and-private/ From jason at rokeach.net Tue Dec 20 02:56:31 2016 From: jason at rokeach.net (Jason Rokeach) Date: Tue, 20 Dec 2016 02:56:31 +0000 Subject: Google Global Cache Contact In-Reply-To: References: Message-ID: Thanks everyone, all set. The form was down earlier today but folks have pointed out an email address for me. On Mon, Dec 19, 2016, 4:15 PM Jason Rokeach wrote: > Hi folks, could a contact for GGC contact me off-list? > > Thank you! > - Jason R. Rokeach > From jad at snap.com Tue Dec 20 05:27:15 2016 From: jad at snap.com (Jad Boutros) Date: Mon, 19 Dec 2016 21:27:15 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> Message-ID: We - at Snap - were forwarded this thread just a few hours ago and are investigating. Please email me should you still be looking for a contact for Snapchat. Thank you, Jad On Mon, Dec 19, 2016 at 9:18 PM, Laurent Dumont wrote: > If anything comes from this, I'd love to hear about it. As a student in > the field, this is the kind of stuff I live for! ;) > > Pretty awesome to see the chain of events after seeing a post on the > [pool] list! > > Laurent > > On 12/19/2016 05:12 PM, Justin Paine via NANOG wrote: > >> replying off list. >> >> ____________ >> Justin Paine >> Head of Trust & Safety >> Cloudflare Inc. >> PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D >> >> >> On Mon, Dec 19, 2016 at 1:49 PM, Dan Drown wrote: >> >>> Quoting David : >>> >>>> On 2016-12-19 1:55 PM, Jan Tore Morken wrote: >>>> >>>>> On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote: >>>>> >>>>>> I found devices doing lookups for all of these at the same time >>>>>> >>>>>> {0,0.uk,0.us,asia,europe,north-america,south-america,oceania,africa}. >>>>>> pool.ntp.org >>>>>> and then it proceeds to use everything returned, which explains why >>>>>> everyone is seeing an increase. >>>>>> >>>>> >>>>> Thanks, David. That perfectly matches the list of servers used by >>>>> older versions of the ios-ntp library[1][2], which would point toward >>>>> some iPhone app being the source of the traffic. >>>>> >>>>> [1] >>>>> https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0 >>>>> c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts >>>>> [2] >>>>> https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9d >>>>> ec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122 >>>>> >>>>> That would make sense - I see a lot of iCloud related lookups from >>>> these >>>> hosts as well. >>>> >>>> Also, app.snapchat.com generally seems to follow just after the NTP >>>> pool >>>> DNS lookups. I don't have an iPhone to test that though. >>>> >>> >>> Confirmed - starting up the iOS Snapchat app does a lookup to the domains >>> you listed, and then sends NTP to every unique IP. Around 35-60 >>> different >>> IPs. >>> >>> Anyone have a contact at Snapchat? >>> >> > From paul at gear.dyndns.org Tue Dec 20 05:40:42 2016 From: paul at gear.dyndns.org (Paul Gear) Date: Tue, 20 Dec 2016 15:40:42 +1000 Subject: Recent NTP pool traffic increase In-Reply-To: <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> Message-ID: On 20/12/16 15:18, Laurent Dumont wrote: > If anything comes from this, I'd love to hear about it. As a student in > the field, this is the kind of stuff I live for! ;) > > Pretty awesome to see the chain of events after seeing a post on the > [pool] list! https://news.ntppool.org/2016/12/load/ https://community.ntppool.org/t/recent-ntp-pool-traffic-increase/18 From wido at abuse.io Tue Dec 20 10:29:43 2016 From: wido at abuse.io (Wido Potters) Date: Tue, 20 Dec 2016 11:29:43 +0100 Subject: compliance with Canadian copyright law Message-ID: <1482229783.21739.78.camel@abuse.io> Hi, I am involved in the free and open source toolkit AbuseIO (https://abus e.io/). It is a toolkit anyone can use to receive, process, correlate abuse reports and send notifications with specific information regarding the abuse case(s) on your network. AbuseIO's purpose is to consolidate efforts by various companies and individuals to automate and improve the abuse handling process. Last months we have been receiving requests for information about the implementation of AbuseIO in Canadian networks, in order to be compliant with Canadian Copyright Law. It seems our toolkit might be of use for these Canadian networks, but it needs some tweaking to really comply. I am looking for Canadian network operators / abuse desks / compliance officers that might be interested in using AbuseIO and would like to give some input or join efforts in making the software compliant for Canadian law. Please contact me off-list or discuss on- list. Kind regards, Wido From arivera at pccwglobal.com Tue Dec 20 14:15:31 2016 From: arivera at pccwglobal.com (Rivera, Alberto) Date: Tue, 20 Dec 2016 14:15:31 +0000 (GMT+00:00) Subject: NTT Taipei 3 data center address? Message-ID: <015201d25acb$84f008b0$8ed01a10$@pccwglobal.com> I am searching for NTT Taipei 3 data center address. Do you have it by any chance? Thank you! Alberto Rivera PreSales Engineer PCCW Global 450 Spring Park Place Suite 100 Herndon, VA 20170 Tel: +1(703)774-9459 Office | + (571)315-5309 Cell Email: arivera at pccwglobal.com Website: www.pccwglobal.com To view PCCW Global's communication videos click here cid:9f4812ce-f4a5-4441-a4e4-1d77c1ee1ad7 cid:21f87991-196a-41be-a978-deb2e5059c9b cid:1d9fa650-71e3-4e53-a84f-f92859afadfa cid:e396fb8d-688f-4d85-befe-85c9f88f81c9 cid:0e7d23dc-f767-4fec-b036-a8410443413f From johnl at iecc.com Tue Dec 20 18:41:35 2016 From: johnl at iecc.com (John Levine) Date: 20 Dec 2016 18:41:35 -0000 Subject: South Carolina attempts to repeal Rule 34 In-Reply-To: Message-ID: <20161220184135.23313.qmail@ary.lan> In article you write: >Let's call it for what it is. It's a new tax. No, it's just grandstanding. The proposed law egregiously violates the First Amendment and wouldn't last 5 minutes in a court challenge. R's, John From jad at snap.com Tue Dec 20 18:58:57 2016 From: jad at snap.com (Jad Boutros) Date: Tue, 20 Dec 2016 10:58:57 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> Message-ID: Immediately after being notified that our latest iOS release was causing problems with NTP traffic, we started working to disable the offending code in v9.45. We submitted a new mobile release to the Apple App Store earlier this morning for their review, which should disable these NTP requests. We are hoping Apple will be able to review this release in time before the holiday break, and we have stressed its urgency. When the release does get approved, we should very quickly begin to see a decrease in NTP traffic from our app as users start upgrading to the new release. We deeply regret this situation, and we will post an update here once we hear back from Apple. We are also open to any suggestions on how we can help with the present traffic. On Mon, Dec 19, 2016 at 9:27 PM, Jad Boutros wrote: > We - at Snap - were forwarded this thread just a few hours ago and are > investigating. Please email me should you still be looking for a contact > for Snapchat. > > Thank you, > Jad > > On Mon, Dec 19, 2016 at 9:18 PM, Laurent Dumont > wrote: > >> If anything comes from this, I'd love to hear about it. As a student in >> the field, this is the kind of stuff I live for! ;) >> >> Pretty awesome to see the chain of events after seeing a post on the >> [pool] list! >> >> Laurent >> >> On 12/19/2016 05:12 PM, Justin Paine via NANOG wrote: >> >>> replying off list. >>> >>> ____________ >>> Justin Paine >>> Head of Trust & Safety >>> Cloudflare Inc. >>> PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D >>> >>> >>> On Mon, Dec 19, 2016 at 1:49 PM, Dan Drown wrote: >>> >>>> Quoting David : >>>> >>>>> On 2016-12-19 1:55 PM, Jan Tore Morken wrote: >>>>> >>>>>> On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote: >>>>>> >>>>>>> I found devices doing lookups for all of these at the same time >>>>>>> >>>>>>> {0,0.uk,0.us,asia,europe,north-america,south-america,oceania >>>>>>> ,africa}.pool.ntp.org >>>>>>> and then it proceeds to use everything returned, which explains why >>>>>>> everyone is seeing an increase. >>>>>>> >>>>>> >>>>>> Thanks, David. That perfectly matches the list of servers used by >>>>>> older versions of the ios-ntp library[1][2], which would point toward >>>>>> some iPhone app being the source of the traffic. >>>>>> >>>>>> [1] >>>>>> https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0 >>>>>> c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts >>>>>> [2] >>>>>> https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9d >>>>>> ec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122 >>>>>> >>>>>> That would make sense - I see a lot of iCloud related lookups from >>>>> these >>>>> hosts as well. >>>>> >>>>> Also, app.snapchat.com generally seems to follow just after the NTP >>>>> pool >>>>> DNS lookups. I don't have an iPhone to test that though. >>>>> >>>> >>>> Confirmed - starting up the iOS Snapchat app does a lookup to the >>>> domains >>>> you listed, and then sends NTP to every unique IP. Around 35-60 >>>> different >>>> IPs. >>>> >>>> Anyone have a contact at Snapchat? >>>> >>> >> > From job at ntt.net Tue Dec 20 19:09:51 2016 From: job at ntt.net (Job Snijders) Date: Tue, 20 Dec 2016 20:09:51 +0100 Subject: NTT Taipei 3 data center address? In-Reply-To: <015201d25acb$84f008b0$8ed01a10$@pccwglobal.com> References: <015201d25acb$84f008b0$8ed01a10$@pccwglobal.com> Message-ID: <20161220190951.GG7357@Vurt.local> On Tue, Dec 20, 2016 at 02:15:31PM +0000, Rivera, Alberto wrote: > I am searching for NTT Taipei 3 data center address. Do you have it by > any chance? I'll ping you off-list. Kind regards, Job From jad at snap.com Tue Dec 20 22:37:04 2016 From: jad at snap.com (Jad Boutros) Date: Tue, 20 Dec 2016 14:37:04 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> Message-ID: Thank you Eduardo, You beat me to it. Apple was quick to approve our release with the fix, we should start seeing a decrease in such traffic. On Tue, Dec 20, 2016 at 2:29 PM, Eduardo Schoedler wrote: > 2016-12-20 16:58 GMT-02:00 Jad Boutros via NANOG : > > Immediately after being notified that our latest iOS release was causing > > problems with NTP traffic, we started working to disable the offending > code > > in v9.45. We submitted a new mobile release to the Apple App Store > earlier > > this morning for their review, which should disable these NTP requests. > We > > are hoping Apple will be able to review this release in time before the > > holiday break, and we have stressed its urgency. When the release does > get > > approved, we should very quickly begin to see a decrease in NTP traffic > > from our app as users start upgrading to the new release. > > Just received update to 9.45.2.0. > > -- > Eduardo Schoedler > From beckman at angryox.com Tue Dec 20 23:11:11 2016 From: beckman at angryox.com (Peter Beckman) Date: Tue, 20 Dec 2016 18:11:11 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> Message-ID: Mostly out of curiosity, what was the reason for the change in the Snapchat code, and what plans does Snap have for whatever reason the NTP change was put in place? Beckman On Tue, 20 Dec 2016, Jad Boutros via NANOG wrote: > Immediately after being notified that our latest iOS release was causing > problems with NTP traffic, we started working to disable the offending code > in v9.45. We submitted a new mobile release to the Apple App Store earlier > this morning for their review, which should disable these NTP requests. We > are hoping Apple will be able to review this release in time before the > holiday break, and we have stressed its urgency. When the release does get > approved, we should very quickly begin to see a decrease in NTP traffic > from our app as users start upgrading to the new release. > > We deeply regret this situation, and we will post an update here once we > hear back from Apple. We are also open to any suggestions on how we can > help with the present traffic. > > On Mon, Dec 19, 2016 at 9:27 PM, Jad Boutros wrote: > >> We - at Snap - were forwarded this thread just a few hours ago and are >> investigating. Please email me should you still be looking for a contact >> for Snapchat. >> >> Thank you, >> Jad >> >> On Mon, Dec 19, 2016 at 9:18 PM, Laurent Dumont >> wrote: >> >>> If anything comes from this, I'd love to hear about it. As a student in >>> the field, this is the kind of stuff I live for! ;) >>> >>> Pretty awesome to see the chain of events after seeing a post on the >>> [pool] list! >>> >>> Laurent >>> >>> On 12/19/2016 05:12 PM, Justin Paine via NANOG wrote: >>> >>>> replying off list. >>>> >>>> ____________ >>>> Justin Paine >>>> Head of Trust & Safety >>>> Cloudflare Inc. >>>> PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D >>>> >>>> >>>> On Mon, Dec 19, 2016 at 1:49 PM, Dan Drown wrote: >>>> >>>>> Quoting David : >>>>> >>>>>> On 2016-12-19 1:55 PM, Jan Tore Morken wrote: >>>>>> >>>>>>> On Mon, Dec 19, 2016 at 01:32:50PM -0700, David wrote: >>>>>>> >>>>>>>> I found devices doing lookups for all of these at the same time >>>>>>>> >>>>>>>> {0,0.uk,0.us,asia,europe,north-america,south-america,oceania >>>>>>>> ,africa}.pool.ntp.org >>>>>>>> and then it proceeds to use everything returned, which explains why >>>>>>>> everyone is seeing an increase. >>>>>>>> >>>>>>> >>>>>>> Thanks, David. That perfectly matches the list of servers used by >>>>>>> older versions of the ios-ntp library[1][2], which would point toward >>>>>>> some iPhone app being the source of the traffic. >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/jbenet/ios-ntp/blob/d5eade6a99041094f12f0 >>>>>>> c976dd4aaeed37e0564/ios-ntp-rez/ntp.hosts >>>>>>> [2] >>>>>>> https://github.com/jbenet/ios-ntp/blob/5cc3b6e437a6422dcee9d >>>>>>> ec9da5183e283eff9f2/ios-ntp-lib/NetworkClock.m#L122 >>>>>>> >>>>>>> That would make sense - I see a lot of iCloud related lookups from >>>>>> these >>>>>> hosts as well. >>>>>> >>>>>> Also, app.snapchat.com generally seems to follow just after the NTP >>>>>> pool >>>>>> DNS lookups. I don't have an iPhone to test that though. >>>>>> >>>>> >>>>> Confirmed - starting up the iOS Snapchat app does a lookup to the >>>>> domains >>>>> you listed, and then sends NTP to every unique IP. Around 35-60 >>>>> different >>>>> IPs. >>>>> >>>>> Anyone have a contact at Snapchat? >>>>> >>>> >>> >> > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From Valdis.Kletnieks at vt.edu Wed Dec 21 01:20:48 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 20 Dec 2016 20:20:48 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> Message-ID: <10994.1482283248@turing-police.cc.vt.edu> On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said: > Mostly out of curiosity, what was the reason for the change in the Snapchat > code, and what plans does Snap have for whatever reason the NTP change was > put in place? >From other comments in the thread, it sounds like the app was simply linked against a broken version of a library.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From gem at rellim.com Wed Dec 21 01:26:23 2016 From: gem at rellim.com (Gary E. Miller) Date: Tue, 20 Dec 2016 17:26:23 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <10994.1482283248@turing-police.cc.vt.edu> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> Message-ID: <20161220172623.0af945c8@spidey.rellim.com> Yo Valdis.Kletnieks at vt.edu! On Tue, 20 Dec 2016 20:20:48 -0500 Valdis.Kletnieks at vt.edu wrote: > On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said: > > Mostly out of curiosity, what was the reason for the change in the > > Snapchat code, and what plans does Snap have for whatever reason > > the NTP change was put in place? > > From other comments in the thread, it sounds like the app was simply > linked against a broken version of a library.... But why is a chat app doing NTP at all? it should rely on the OS, or a specialized app, to keep local time accurate. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem at rellim.com Tel:+1 541 382 8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From dave at temk.in Wed Dec 21 01:32:16 2016 From: dave at temk.in (Dave Temkin) Date: Tue, 20 Dec 2016 17:32:16 -0800 Subject: [NANOG-announce] 2016 NANOG Election Results In-Reply-To: References: Message-ID: Hi NANOG Community, Following up from our election in October, the NANOG Board listened to feedback from our members and discussed the potential implications of releasing vote counts. The Board has decided that while we will not publish the individual vote counts from this past election, we will publish the results going forward. Given the ambiguity as to whether or not we are obligated to publish these counts, we felt it best to be conservative as to not alienate those that ran under the impression that counts would not be released. As part of the discussion, the board as well decided to change the makeup of the Election Committee. In past elections, it was made up of two non-conflicted board members and the Executive Director. Going forward, two board members will be joined by 3 NANOG members, to be selected by the seated board. Best Regards, -Dave Temkin Chair, NANOG Board of Directors On Thu, Oct 20, 2016 at 2:30 PM, Dave Temkin wrote: > Greetings NANOG Colleagues, > > The 2016 NANOG Board and Bylaw election process is now complete. > > The results were shared during NANOG 68, are posted on the NANOG website, > and summarized here. > > In 2016, there were two regular open positions on the Board of Directors. > The appointments are: > > - > > Will Charnock - 3 years > - > > Patrick Gilmore - 3 years > > > The officers elected and committee liaisons are: > > - > > Chair - Dave Temkin > - > > Vice Chair - Ryan Donnelly > - > > Treasurer - Will Charnock > - > > Secretary - Betty Burke > - > > Communications Committee Liaison - Jezzibell Gilmore > - > > Program Committee Liaison - Patrick Gilmore > > > The proposed amendments to the NANOG Bylaws were accepted. The updated > Bylaws document will be posted to the NANOG website. > > > Best Regards, > > -Dave Temkin > > Chair, NANOG Board of Directors > > -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From raphael.timothy at gmail.com Wed Dec 21 01:34:25 2016 From: raphael.timothy at gmail.com (Tim Raphael) Date: Wed, 21 Dec 2016 09:34:25 +0800 Subject: Recent NTP pool traffic increase In-Reply-To: <20161220172623.0af945c8@spidey.rellim.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> Message-ID: <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> This was my thought actually, Apple does offer some time services as part of the OS but it?s becoming common with larger / more popular apps to provide some of these services internally. Look at the FB app for example, there are a lot of ?system? things they do themselves due to the ability to control specifics. Users don?t want to have to install a second ?specialised app? for this either. With regard to an ephemeral chat app requiring time sync, I can think of quite a few use cases and mechanisms in the app that might require time services. - Tim > On 21 Dec. 2016, at 9:26 am, Gary E. Miller wrote: > > Yo Valdis.Kletnieks at vt.edu! > > On Tue, 20 Dec 2016 20:20:48 -0500 > Valdis.Kletnieks at vt.edu wrote: > >> On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said: >>> Mostly out of curiosity, what was the reason for the change in the >>> Snapchat code, and what plans does Snap have for whatever reason >>> the NTP change was put in place? >> >> From other comments in the thread, it sounds like the app was simply >> linked against a broken version of a library.... > > But why is a chat app doing NTP at all? it should rely on the OS, or > a specialized app, to keep local time accurate. > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > gem at rellim.com Tel:+1 541 382 8588 From emille at abccommunications.com Wed Dec 21 02:13:24 2016 From: emille at abccommunications.com (Emille Blanc) Date: Tue, 20 Dec 2016 18:13:24 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com>, <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> Message-ID: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> Perhaps the host OS' to which snapchat caters, don't all have a devent ntp subststem available? I have vague recollections of some other software (I'm sure we all know which) implemented it's own malloc layer for every system it ran on, for less trivial reasons. ;) ________________________________________ From: NANOG [nanog-bounces at nanog.org] On Behalf Of Tim Raphael [raphael.timothy at gmail.com] Sent: Tuesday, December 20, 2016 5:34 PM To: Gary E. Miller Cc: nanog at nanog.org Subject: Re: Recent NTP pool traffic increase This was my thought actually, Apple does offer some time services as part of the OS but it?s becoming common with larger / more popular apps to provide some of these services internally. Look at the FB app for example, there are a lot of ?system? things they do themselves due to the ability to control specifics. Users don?t want to have to install a second ?specialised app? for this either. With regard to an ephemeral chat app requiring time sync, I can think of quite a few use cases and mechanisms in the app that might require time services. - Tim > On 21 Dec. 2016, at 9:26 am, Gary E. Miller wrote: > > Yo Valdis.Kletnieks at vt.edu! > > On Tue, 20 Dec 2016 20:20:48 -0500 > Valdis.Kletnieks at vt.edu wrote: > >> On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said: >>> Mostly out of curiosity, what was the reason for the change in the >>> Snapchat code, and what plans does Snap have for whatever reason >>> the NTP change was put in place? >> >> From other comments in the thread, it sounds like the app was simply >> linked against a broken version of a library.... > > But why is a chat app doing NTP at all? it should rely on the OS, or > a specialized app, to keep local time accurate. > > RGDS > GARY > --------------------------------------------------------------------------- > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > gem at rellim.com Tel:+1 541 382 8588 From raphael.timothy at gmail.com Wed Dec 21 02:16:38 2016 From: raphael.timothy at gmail.com (Tim Raphael) Date: Wed, 21 Dec 2016 10:16:38 +0800 Subject: Recent NTP pool traffic increase In-Reply-To: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> Message-ID: <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> Exactly, Also they?re across Android and iOS and getting parity of operations across those two OSs isn?t easy. Better to just embed what they need inside the app if it is specialised enough. - Tim > On 21 Dec. 2016, at 10:13 am, Emille Blanc wrote: > > Perhaps the host OS' to which snapchat caters, don't all have a devent ntp subststem available? > I have vague recollections of some other software (I'm sure we all know which) implemented it's own malloc layer for every system it ran on, for less trivial reasons. ;) > > ________________________________________ > From: NANOG [nanog-bounces at nanog.org] On Behalf Of Tim Raphael [raphael.timothy at gmail.com] > Sent: Tuesday, December 20, 2016 5:34 PM > To: Gary E. Miller > Cc: nanog at nanog.org > Subject: Re: Recent NTP pool traffic increase > > This was my thought actually, Apple does offer some time services as part of the OS but it?s becoming common with larger / more popular apps to provide some of these services internally. > Look at the FB app for example, there are a lot of ?system? things they do themselves due to the ability to control specifics. Users don?t want to have to install a second ?specialised app? for this either. > > With regard to an ephemeral chat app requiring time sync, I can think of quite a few use cases and mechanisms in the app that might require time services. > > - Tim > > >> On 21 Dec. 2016, at 9:26 am, Gary E. Miller wrote: >> >> Yo Valdis.Kletnieks at vt.edu! >> >> On Tue, 20 Dec 2016 20:20:48 -0500 >> Valdis.Kletnieks at vt.edu wrote: >> >>> On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said: >>>> Mostly out of curiosity, what was the reason for the change in the >>>> Snapchat code, and what plans does Snap have for whatever reason >>>> the NTP change was put in place? >>> >>> From other comments in the thread, it sounds like the app was simply >>> linked against a broken version of a library.... >> >> But why is a chat app doing NTP at all? it should rely on the OS, or >> a specialized app, to keep local time accurate. >> >> RGDS >> GARY >> --------------------------------------------------------------------------- >> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 >> gem at rellim.com Tel:+1 541 382 8588 From jad at snap.com Wed Dec 21 02:21:23 2016 From: jad at snap.com (Jad Boutros) Date: Tue, 20 Dec 2016 18:21:23 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> Message-ID: The Snapchat mobile app does not currently have a need to talk with NTP servers, it was an error. Also, this afternoon we spun off NTP server instances in Australia and South America to help with the load. Thanks, Jad On Tue, Dec 20, 2016 at 5:34 PM, Tim Raphael wrote: > This was my thought actually, Apple does offer some time services as part > of the OS but it?s becoming common with larger / more popular apps to > provide some of these services internally. > Look at the FB app for example, there are a lot of ?system? things they do > themselves due to the ability to control specifics. Users don?t want to > have to install a second ?specialised app? for this either. > > With regard to an ephemeral chat app requiring time sync, I can think of > quite a few use cases and mechanisms in the app that might require time > services. > > - Tim > > > > On 21 Dec. 2016, at 9:26 am, Gary E. Miller wrote: > > > > Yo Valdis.Kletnieks at vt.edu! > > > > On Tue, 20 Dec 2016 20:20:48 -0500 > > Valdis.Kletnieks at vt.edu wrote: > > > >> On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said: > >>> Mostly out of curiosity, what was the reason for the change in the > >>> Snapchat code, and what plans does Snap have for whatever reason > >>> the NTP change was put in place? > >> > >> From other comments in the thread, it sounds like the app was simply > >> linked against a broken version of a library.... > > > > But why is a chat app doing NTP at all? it should rely on the OS, or > > a specialized app, to keep local time accurate. > > > > RGDS > > GARY > > ------------------------------------------------------------ > --------------- > > Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > > gem at rellim.com Tel:+1 541 382 8588 > > From ktims at stargate.ca Wed Dec 21 02:41:37 2016 From: ktims at stargate.ca (Keenan Tims) Date: Tue, 20 Dec 2016 18:41:37 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> Message-ID: Better for whom? I'm sure all mobile operating systems provide some access to time, with a least 'seconds' resolution. If an app deems this time source untrustworthy for some reason, I don't think the reasonable response is to make independent time requests from a volunteer-operated pool for public servers designed for host synchronization. Particularly on mobile, the compartmentalization of applications means that this 'better' time will only be accessible to one application, and many applications may have this 'better time' requirement. These developers should be lobbying Apple and Google for better time, if they need it, not making many millions of calls to the NTP pool. To make things worse, I'm fairly sure that Apple's 'no background tasks' policy means that an application can't *maintain* its sense of time, so it would not surprise me if it fires off NTP requests every time it is focused, further compounding the burden. Time is already available, and having every application query for its own time against a public resource doesn't seem very friendly. It certainly doesn't scale. If they are unsuccessful lobbying the OS, why not trust the time provided by the API calls they are surely doing to their own servers? Most HTTP responses include a timestamp; surely this is good enough for expiring Snaps. Or at least operate their own NTP infrastructure. I'm sure that Snap had no malicious intent and commend them for their quick and appropriate response once the issue was identified, but I don't think this behaviour is very defensible. I for one was not harmed by the ~10x increase in load and traffic on my NTP pool node, but the 100x increase if a handful of similar apps decided they 'need' more accurate time than the OS provides would be cause for concern, and I suspect a great many pool nodes would simply disappear, compounding the problem. Please make use of these and similar services as they are designed to be used, and as efficiently as possible, especially if you are responsible for millions of users / machines. In a similar vein, I've always been curious what the ratio Google sees of ICMP echo vs. DNS traffic to 8.8.8.8 is... Keenan On 2016-12-20 18:16, Tim Raphael wrote: > Exactly, > > Also they?re across Android and iOS and getting parity of operations across those two OSs isn?t easy. > Better to just embed what they need inside the app if it is specialised enough. > > - Tim > >> On 21 Dec. 2016, at 10:13 am, Emille Blanc wrote: >> >> Perhaps the host OS' to which snapchat caters, don't all have a devent ntp subststem available? >> I have vague recollections of some other software (I'm sure we all know which) implemented it's own malloc layer for every system it ran on, for less trivial reasons. ;) >> >> ________________________________________ >> From: NANOG [nanog-bounces at nanog.org] On Behalf Of Tim Raphael [raphael.timothy at gmail.com] >> Sent: Tuesday, December 20, 2016 5:34 PM >> To: Gary E. Miller >> Cc: nanog at nanog.org >> Subject: Re: Recent NTP pool traffic increase >> >> This was my thought actually, Apple does offer some time services as part of the OS but it?s becoming common with larger / more popular apps to provide some of these services internally. >> Look at the FB app for example, there are a lot of ?system? things they do themselves due to the ability to control specifics. Users don?t want to have to install a second ?specialised app? for this either. >> >> With regard to an ephemeral chat app requiring time sync, I can think of quite a few use cases and mechanisms in the app that might require time services. >> >> - Tim >> >> >>> On 21 Dec. 2016, at 9:26 am, Gary E. Miller wrote: >>> >>> Yo Valdis.Kletnieks at vt.edu! >>> >>> On Tue, 20 Dec 2016 20:20:48 -0500 >>> Valdis.Kletnieks at vt.edu wrote: >>> >>>> On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said: >>>>> Mostly out of curiosity, what was the reason for the change in the >>>>> Snapchat code, and what plans does Snap have for whatever reason >>>>> the NTP change was put in place? >>>> From other comments in the thread, it sounds like the app was simply >>>> linked against a broken version of a library.... >>> But why is a chat app doing NTP at all? it should rely on the OS, or >>> a specialized app, to keep local time accurate. >>> >>> RGDS >>> GARY >>> --------------------------------------------------------------------------- >>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 >>> gem at rellim.com Tel:+1 541 382 8588 From admin at coldnorthadmin.com Wed Dec 21 03:27:18 2016 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Tue, 20 Dec 2016 22:27:18 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> Message-ID: <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> I do think that the point of the Pool network is to be used by both consumers and vendors. And as mentioned before, there is a process if you are a vendor and want to use the pool within a commercial product. I have 3 NTP servers running and I don't really care who is using it. That said, setting up your own infrastructure is also worth considering if it's a business critical feature. I assume that a Snapchat app that fails to have accurate time or correct itself could be abused. To be honest, the fact that NTP is still something managed by volunteers and not a regulated entity (a bit like DNS) is mind boggling. On 12/20/2016 09:41 PM, Keenan Tims wrote: > Better for whom? I'm sure all mobile operating systems provide some > access to time, with a least 'seconds' resolution. If an app deems > this time source untrustworthy for some reason, I don't think the > reasonable response is to make independent time requests from a > volunteer-operated pool for public servers designed for host > synchronization. Particularly on mobile, the compartmentalization of > applications means that this 'better' time will only be accessible to > one application, and many applications may have this 'better time' > requirement. These developers should be lobbying Apple and Google for > better time, if they need it, not making many millions of calls to the > NTP pool. To make things worse, I'm fairly sure that Apple's 'no > background tasks' policy means that an application can't *maintain* > its sense of time, so it would not surprise me if it fires off NTP > requests every time it is focused, further compounding the burden. > > Time is already available, and having every application query for its > own time against a public resource doesn't seem very friendly. It > certainly doesn't scale. If they are unsuccessful lobbying the OS, why > not trust the time provided by the API calls they are surely doing to > their own servers? Most HTTP responses include a timestamp; surely > this is good enough for expiring Snaps. Or at least operate their own > NTP infrastructure. > > I'm sure that Snap had no malicious intent and commend them for their > quick and appropriate response once the issue was identified, but I > don't think this behaviour is very defensible. I for one was not > harmed by the ~10x increase in load and traffic on my NTP pool node, > but the 100x increase if a handful of similar apps decided they 'need' > more accurate time than the OS provides would be cause for concern, > and I suspect a great many pool nodes would simply disappear, > compounding the problem. Please make use of these and similar services > as they are designed to be used, and as efficiently as possible, > especially if you are responsible for millions of users / machines. > > In a similar vein, I've always been curious what the ratio Google sees > of ICMP echo vs. DNS traffic to 8.8.8.8 is... > > Keenan > > > On 2016-12-20 18:16, Tim Raphael wrote: >> Exactly, >> >> Also they?re across Android and iOS and getting parity of operations >> across those two OSs isn?t easy. >> Better to just embed what they need inside the app if it is >> specialised enough. >> >> - Tim >> >>> On 21 Dec. 2016, at 10:13 am, Emille Blanc >>> wrote: >>> >>> Perhaps the host OS' to which snapchat caters, don't all have a >>> devent ntp subststem available? >>> I have vague recollections of some other software (I'm sure we all >>> know which) implemented it's own malloc layer for every system it >>> ran on, for less trivial reasons. ;) >>> >>> ________________________________________ >>> From: NANOG [nanog-bounces at nanog.org] On Behalf Of Tim Raphael >>> [raphael.timothy at gmail.com] >>> Sent: Tuesday, December 20, 2016 5:34 PM >>> To: Gary E. Miller >>> Cc: nanog at nanog.org >>> Subject: Re: Recent NTP pool traffic increase >>> >>> This was my thought actually, Apple does offer some time services as >>> part of the OS but it?s becoming common with larger / more popular >>> apps to provide some of these services internally. >>> Look at the FB app for example, there are a lot of ?system? things >>> they do themselves due to the ability to control specifics. Users >>> don?t want to have to install a second ?specialised app? for this >>> either. >>> >>> With regard to an ephemeral chat app requiring time sync, I can >>> think of quite a few use cases and mechanisms in the app that might >>> require time services. >>> >>> - Tim >>> >>> >>>> On 21 Dec. 2016, at 9:26 am, Gary E. Miller wrote: >>>> >>>> Yo Valdis.Kletnieks at vt.edu! >>>> >>>> On Tue, 20 Dec 2016 20:20:48 -0500 >>>> Valdis.Kletnieks at vt.edu wrote: >>>> >>>>> On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said: >>>>>> Mostly out of curiosity, what was the reason for the change in the >>>>>> Snapchat code, and what plans does Snap have for whatever reason >>>>>> the NTP change was put in place? >>>>> From other comments in the thread, it sounds like the app was simply >>>>> linked against a broken version of a library.... >>>> But why is a chat app doing NTP at all? it should rely on the OS, or >>>> a specialized app, to keep local time accurate. >>>> >>>> RGDS >>>> GARY >>>> --------------------------------------------------------------------------- >>>> >>>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 >>>> gem at rellim.com Tel:+1 541 382 8588 > From Valdis.Kletnieks at vt.edu Wed Dec 21 03:42:05 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 20 Dec 2016 22:42:05 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> Message-ID: <18551.1482291725@turing-police.cc.vt.edu> On Tue, 20 Dec 2016 18:41:37 -0800, Keenan Tims said: > Better for whom? I'm sure all mobile operating systems provide some > access to time, with a least 'seconds' resolution. If an app deems this > time source untrustworthy for some reason, I don't think the reasonable > response is to make independent time requests from a volunteer-operated > pool for public servers designed for host synchronization. This is possibly at least partly due to "dependency hell". For a worked example from earlier this year: http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ So a lot of people had their stuff blow up, even though their code called left_pad exactly noplace.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From stenn at nwtime.org Wed Dec 21 04:02:16 2016 From: stenn at nwtime.org (Harlan Stenn) Date: Tue, 20 Dec 2016 20:02:16 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> References: <20161217175455.30107c37@spidey.rellim.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> Message-ID: <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> On 12/20/16 7:27 PM, Laurent Dumont wrote: > I do think that the point of the Pool network is to be used by both > consumers and vendors. And as mentioned before, there is a process if > you are a vendor and want to use the pool within a commercial product. I > have 3 NTP servers running and I don't really care who is using it. > > That said, setting up your own infrastructure is also worth considering > if it's a business critical feature. I assume that a Snapchat app that > fails to have accurate time or correct itself could be abused. > > To be honest, the fact that NTP is still something managed by volunteers > and not a regulated entity (a bit like DNS) is mind boggling. Time *is* managed by regulated entities - the National Time Labs. And Network Time Foundation's NTP Project (the reference implementation for NTP) could do lots more if we had a useful budget. Folks pay money for DNS registrations. There's no revenue stream around "time". Help us get enough support to NTF, and we'll have the staff and infrastructure to do more for folks. -- Harlan Stenn http://networktimefoundation.org - be a member! From shefys at gmail.com Wed Dec 21 05:04:35 2016 From: shefys at gmail.com (Yury Shefer) Date: Wed, 21 Dec 2016 05:04:35 +0000 Subject: Recent NTP pool traffic increase In-Reply-To: <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> References: <20161217175455.30107c37@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> Message-ID: Google announced public NTP service some time ago: https://developers.google.com/time/ On Tue, Dec 20, 2016 at 7:29 PM Laurent Dumont wrote: > I do think that the point of the Pool network is to be used by both > > consumers and vendors. And as mentioned before, there is a process if > > you are a vendor and want to use the pool within a commercial product. I > > have 3 NTP servers running and I don't really care who is using it. > > > > That said, setting up your own infrastructure is also worth considering > > if it's a business critical feature. I assume that a Snapchat app that > > fails to have accurate time or correct itself could be abused. > > > > To be honest, the fact that NTP is still something managed by volunteers > > and not a regulated entity (a bit like DNS) is mind boggling. > > > > On 12/20/2016 09:41 PM, Keenan Tims wrote: > > > Better for whom? I'm sure all mobile operating systems provide some > > > access to time, with a least 'seconds' resolution. If an app deems > > > this time source untrustworthy for some reason, I don't think the > > > reasonable response is to make independent time requests from a > > > volunteer-operated pool for public servers designed for host > > > synchronization. Particularly on mobile, the compartmentalization of > > > applications means that this 'better' time will only be accessible to > > > one application, and many applications may have this 'better time' > > > requirement. These developers should be lobbying Apple and Google for > > > better time, if they need it, not making many millions of calls to the > > > NTP pool. To make things worse, I'm fairly sure that Apple's 'no > > > background tasks' policy means that an application can't *maintain* > > > its sense of time, so it would not surprise me if it fires off NTP > > > requests every time it is focused, further compounding the burden. > > > > > > Time is already available, and having every application query for its > > > own time against a public resource doesn't seem very friendly. It > > > certainly doesn't scale. If they are unsuccessful lobbying the OS, why > > > not trust the time provided by the API calls they are surely doing to > > > their own servers? Most HTTP responses include a timestamp; surely > > > this is good enough for expiring Snaps. Or at least operate their own > > > NTP infrastructure. > > > > > > I'm sure that Snap had no malicious intent and commend them for their > > > quick and appropriate response once the issue was identified, but I > > > don't think this behaviour is very defensible. I for one was not > > > harmed by the ~10x increase in load and traffic on my NTP pool node, > > > but the 100x increase if a handful of similar apps decided they 'need' > > > more accurate time than the OS provides would be cause for concern, > > > and I suspect a great many pool nodes would simply disappear, > > > compounding the problem. Please make use of these and similar services > > > as they are designed to be used, and as efficiently as possible, > > > especially if you are responsible for millions of users / machines. > > > > > > In a similar vein, I've always been curious what the ratio Google sees > > > of ICMP echo vs. DNS traffic to 8.8.8.8 is... > > > > > > Keenan > > > > > > > > > On 2016-12-20 18:16, Tim Raphael wrote: > > >> Exactly, > > >> > > >> Also they?re across Android and iOS and getting parity of operations > > >> across those two OSs isn?t easy. > > >> Better to just embed what they need inside the app if it is > > >> specialised enough. > > >> > > >> - Tim > > >> > > >>> On 21 Dec. 2016, at 10:13 am, Emille Blanc > > >>> wrote: > > >>> > > >>> Perhaps the host OS' to which snapchat caters, don't all have a > > >>> devent ntp subststem available? > > >>> I have vague recollections of some other software (I'm sure we all > > >>> know which) implemented it's own malloc layer for every system it > > >>> ran on, for less trivial reasons. ;) > > >>> > > >>> ________________________________________ > > >>> From: NANOG [nanog-bounces at nanog.org] On Behalf Of Tim Raphael > > >>> [raphael.timothy at gmail.com] > > >>> Sent: Tuesday, December 20, 2016 5:34 PM > > >>> To: Gary E. Miller > > >>> Cc: nanog at nanog.org > > >>> Subject: Re: Recent NTP pool traffic increase > > >>> > > >>> This was my thought actually, Apple does offer some time services as > > >>> part of the OS but it?s becoming common with larger / more popular > > >>> apps to provide some of these services internally. > > >>> Look at the FB app for example, there are a lot of ?system? things > > >>> they do themselves due to the ability to control specifics. Users > > >>> don?t want to have to install a second ?specialised app? for this > > >>> either. > > >>> > > >>> With regard to an ephemeral chat app requiring time sync, I can > > >>> think of quite a few use cases and mechanisms in the app that might > > >>> require time services. > > >>> > > >>> - Tim > > >>> > > >>> > > >>>> On 21 Dec. 2016, at 9:26 am, Gary E. Miller wrote: > > >>>> > > >>>> Yo Valdis.Kletnieks at vt.edu! > > >>>> > > >>>> On Tue, 20 Dec 2016 20:20:48 -0500 > > >>>> Valdis.Kletnieks at vt.edu wrote: > > >>>> > > >>>>> On Tue, 20 Dec 2016 18:11:11 -0500, Peter Beckman said: > > >>>>>> Mostly out of curiosity, what was the reason for the change in the > > >>>>>> Snapchat code, and what plans does Snap have for whatever reason > > >>>>>> the NTP change was put in place? > > >>>>> From other comments in the thread, it sounds like the app was simply > > >>>>> linked against a broken version of a library.... > > >>>> But why is a chat app doing NTP at all? it should rely on the OS, or > > >>>> a specialized app, to keep local time accurate. > > >>>> > > >>>> RGDS > > >>>> GARY > > >>>> > --------------------------------------------------------------------------- > > >>>> > > >>>> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 > > >>>> gem at rellim.com Tel:+1 541 382 8588 > > > > > > > From royce at techsolvency.com Wed Dec 21 05:19:09 2016 From: royce at techsolvency.com (Royce Williams) Date: Tue, 20 Dec 2016 20:19:09 -0900 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> Message-ID: On Tue, Dec 20, 2016 at 8:04 PM, Yury Shefer wrote: > > Google announced public NTP service some time ago: > https://developers.google.com/time/ Leap smearing does look interesting as way to sidestep the potentially-jarring leap-second problem ... but a note of caution. I've had multiple time geeks tell me that leap-smearing is pretty different from strict-RFC NTP, and Google themselves say on that page: "We recommend that you don?t configure Google Public NTP together with non-leap-smearing NTP servers." So it looks like we shouldn't mix and match. And since most folks should probably want some heterogeneity in their NTP, it may be a little premature to jump on the leap-smear bandwagon just yet. I'm vague on the details, so I could be wrong. Does anyone know of any other (non Google) leap-smearing NTP implementations? Royce From royce at techsolvency.com Wed Dec 21 05:21:47 2016 From: royce at techsolvency.com (Royce Williams) Date: Tue, 20 Dec 2016 20:21:47 -0900 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> Message-ID: On Tue, Dec 20, 2016 at 8:19 PM, Royce Williams wrote: > On Tue, Dec 20, 2016 at 8:04 PM, Yury Shefer wrote: >> >> Google announced public NTP service some time ago: >> https://developers.google.com/time/ > > Leap smearing does look interesting as way to sidestep the > potentially-jarring leap-second problem ... but a note of caution. > > I've had multiple time geeks tell me that leap-smearing is pretty > different from strict-RFC NTP, and Google themselves say on that page: > > "We recommend that you don?t configure Google Public NTP together with > non-leap-smearing NTP servers." > > So it looks like we shouldn't mix and match. And since most folks > should probably want some heterogeneity in their NTP, it may be a > little premature to jump on the leap-smear bandwagon just yet. > > I'm vague on the details, so I could be wrong. This is informative: https://docs.ntpsec.org/latest/leapsmear.html > Does anyone know of any other (non Google) leap-smearing NTP implementations? Royce From stenn at nwtime.org Wed Dec 21 05:32:01 2016 From: stenn at nwtime.org (Harlan Stenn) Date: Tue, 20 Dec 2016 21:32:01 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> Message-ID: On 12/20/16 9:21 PM, Royce Williams wrote: > On Tue, Dec 20, 2016 at 8:19 PM, Royce Williams wrote: >> On Tue, Dec 20, 2016 at 8:04 PM, Yury Shefer wrote: >>> >>> Google announced public NTP service some time ago: >>> https://developers.google.com/time/ >> >> Leap smearing does look interesting as way to sidestep the >> potentially-jarring leap-second problem ... but a note of caution. >> >> I've had multiple time geeks tell me that leap-smearing is pretty >> different from strict-RFC NTP, and Google themselves say on that page: >> >> "We recommend that you don?t configure Google Public NTP together with >> non-leap-smearing NTP servers." >> >> So it looks like we shouldn't mix and match. And since most folks >> should probably want some heterogeneity in their NTP, it may be a >> little premature to jump on the leap-smear bandwagon just yet. >> >> I'm vague on the details, so I could be wrong. > > This is informative: > > https://docs.ntpsec.org/latest/leapsmear.html > >> Does anyone know of any other (non Google) leap-smearing NTP implementations? The NTP Project has had a leap-smear implementation for a while. We also have a proposal for a REFID that indicates the provided time is a leap-smear time, and Network Time Foundation is working on a new timestamp format and API that will easily allow time exchange between systems using different timescales. -- Harlan Stenn http://networktimefoundation.org - be a member! From damian at google.com Wed Dec 21 06:26:09 2016 From: damian at google.com (Damian Menscher) Date: Tue, 20 Dec 2016 22:26:09 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> Message-ID: On Tue, Dec 20, 2016 at 6:41 PM, Keenan Tims wrote: > In a similar vein, I've always been curious what the ratio Google sees of > ICMP echo vs. DNS traffic to 8.8.8.8 is... > The more fun question is how many pagers would go off around the world if Google stopped responding to ICMP echo. Damian From denys at visp.net.lb Wed Dec 21 09:36:49 2016 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Wed, 21 Dec 2016 11:36:49 +0200 Subject: Recent NTP pool traffic increase (update) In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <1c45fa7a2425045d30efb3623bbe3d5a@nuclearcat.com> Message-ID: <07c6752a5396d8d99d11dfca131b8155@nuclearcat.com> Hello, I'm not sure i should continue to CC nanog, if someone interested to be in CC for further updates this story please let me know. TP-Link not related, it was misunderstanding or wrong customer report. Tenda routers i believe most of cheap models are affected by this problem. On ISPs i have access i see too many of them sending requests to 133.100.9.2 (if it is unreachable, repeating each 10 seconds), this particular ip seems hardcoded there. I am sure as soon as your server is down, way they coded - it will make all this routers to ddos this particular ip, repeating NTP queries very often without any backoff/protection mechanism. Particular model i tested - W308R / Wireless N300 Home Router, but i believe many models are affected. Firmware: System Version: 5.0.7.53_en hw version : v1.0 Another possible vendor is LB-Link, but i dont have yet any info from customers who own them. On 2016-12-21 11:00, FUJIMURA Sho wrote: > Hello. > > I'm Sho FUJIMURA. > Thank you for your information. > I operate the public NTP Services as 133.100.9.2 and 133.100.11.8. > I'd like to reduce the traffic because I have trouble with too much > traffic recently. > So, I'm interested in the root of the the problem. > If possible, would you please tell me the model numbers of Tenda and > TP-Link?? > > -- > Sho FUJIMURA > Information Technology Center, Fukuoka University. > 8-19-1, Nanakuma, Jyonan-ku, Fukuoka, 8140180, Japan > > fujimura at fukuoka-u.ac.jp > > 2016-12-20 5:33 GMT+09:00 Denys Fedoryshchenko : > >> I'm not sure if this issue relevant to discussed topic, Tenda >> routers here for a while on market, and i think i noticed this issue >> just now, >> because NTP servers they are using supposedly for healthcheck went >> down (or NTP owners blocked ISP's i support, due such routers). >> >> At least after checking numerous users, i believe Tenda hardcoded >> those NTP IPs. What worsen issue, that in Lebanon several times per >> day, for example at 18pm - short electricity cutoff, >> and majority of users routers will reboot and surely reconnect, so >> it will look like a countrywide spike in NTP traffic. >> >> I checked for a 10min also this NTP ips in dns responses, none of >> thousands of users tried to resolve any name with them over any DNS >> server, so i conclude they are hardcoded somewhere in firmware. >> >> Here is traffic of Tenda router after reconnecting (but not full >> powercycle, i dont have it in my hands). But as you can see, no DNS >> resolution attempts: >> >> 20:15:59.305739 PPPoE [ses 0x1483] CHAP, Success (0x03), id 1, Msg >> S=XXXXXX M=Authentication succeeded >> 20:15:59.306100 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 1, >> length 12 >> 20:15:59.317840 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 1, >> length 24 >> 20:15:59.317841 PPPoE [ses 0x1483] IPCP, Conf-Ack (0x02), id 1, >> length 12 >> 20:15:59.317867 PPPoE [ses 0x1483] IPCP, Conf-Nack (0x03), id 1, >> length 18 >> 20:15:59.325253 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 2, >> length 24 >> 20:15:59.325273 PPPoE [ses 0x1483] IPCP, Conf-Ack (0x02), id 2, >> length 24 >> 20:15:59.335589 PPPoE [ses 0x1483] IP 172.17.49.245.123 > >> 133.100.9.2.123: NTPv3, Client, length 48 >> 20:15:59.335588 PPPoE [ses 0x1483] IP 172.17.49.245.123 > >> 192.5.41.41.123: NTPv3, Client, length 48 >> 20:15:59.335588 PPPoE [ses 0x1483] IP 172.17.49.245.123 > >> 192.5.41.40.123: NTPv3, Client, length 48 >> >> Here is example of Tenda traffic if it is unable to reach >> destination, it repeats request each 10 seconds endlessly, my guess >> they are using ntp to show >> status of internet connection. >> So, now that NTP servers getting quite significant DDoS such way. >> >> 19:57:52.162863 IP (tos 0x0, ttl 64, id 38515, offset 0, flags >> [none], proto UDP (17), length 76) >> 172.16.31.67.123 > 192.5.41.40.123: [udp sum ok] NTPv3, length >> 48 >> Client, Leap indicator: (0), Stratum 0 (unspecified), poll >> 0 (1s), precision 0 >> Root Delay: 0.000000, Root dispersion: 0.000000, >> Reference-ID: (unspec) >> Reference Timestamp: 0.000000000 >> Originator Timestamp: 0.000000000 >> Receive Timestamp: 0.000000000 >> Transmit Timestamp: 3691177063.000000000 (2016/12/19 >> 22:57:43) >> Originator - Receive Timestamp: 0.000000000 >> Originator - Transmit Timestamp: 3691177063.000000000 >> (2016/12/19 22:57:43) >> 19:57:52.163277 IP (tos 0x0, ttl 64, id 38516, offset 0, flags >> [none], proto UDP (17), length 76) >> 172.16.31.67.123 > 192.5.41.41.123: [udp sum ok] NTPv3, length >> 48 >> Client, Leap indicator: (0), Stratum 0 (unspecified), poll >> 0 (1s), precision 0 >> Root Delay: 0.000000, Root dispersion: 0.000000, >> Reference-ID: (unspec) >> Reference Timestamp: 0.000000000 >> Originator Timestamp: 0.000000000 >> Receive Timestamp: 0.000000000 >> Transmit Timestamp: 3691177063.000000000 (2016/12/19 >> 22:57:43) >> Originator - Receive Timestamp: 0.000000000 >> Originator - Transmit Timestamp: 3691177063.000000000 >> (2016/12/19 22:57:43) >> 19:57:52.164435 IP (tos 0x0, ttl 64, id 38517, offset 0, flags >> [none], proto UDP (17), length 76) >> 172.16.31.67.123 > 133.100.9.2.123: [udp sum ok] NTPv3, length >> 48 >> Client, Leap indicator: (0), Stratum 0 (unspecified), poll >> 0 (1s), precision 0 >> Root Delay: 0.000000, Root dispersion: 0.000000, >> Reference-ID: (unspec) >> Reference Timestamp: 0.000000000 >> Originator Timestamp: 0.000000000 >> Receive Timestamp: 0.000000000 >> Transmit Timestamp: 3691177063.000000000 (2016/12/19 >> 22:57:43) >> Originator - Receive Timestamp: 0.000000000 >> Originator - Transmit Timestamp: 3691177063.000000000 >> (2016/12/19 22:57:43) >> 19:58:02.164781 IP (tos 0x0, ttl 64, id 38518, offset 0, flags >> [none], proto UDP (17), length 76) >> 172.16.31.67.123 > 192.5.41.40.123: [udp sum ok] NTPv3, length >> 48 >> Client, Leap indicator: (0), Stratum 0 (unspecified), poll >> 0 (1s), precision 0 >> Root Delay: 0.000000, Root dispersion: 0.000000, >> Reference-ID: (unspec) >> Reference Timestamp: 0.000000000 >> Originator Timestamp: 0.000000000 >> Receive Timestamp: 0.000000000 >> Transmit Timestamp: 3691177073.000000000 (2016/12/19 >> 22:57:53) >> Originator - Receive Timestamp: 0.000000000 >> Originator - Transmit Timestamp: 3691177073.000000000 >> (2016/12/19 22:57:53) >> 19:58:02.164884 IP (tos 0x0, ttl 64, id 38519, offset 0, flags >> [none], proto UDP (17), length 76) >> 172.16.31.67.123 > 192.5.41.41.123: [udp sum ok] NTPv3, length >> 48 >> Client, Leap indicator: (0), Stratum 0 (unspecified), poll >> 0 (1s), precision 0 >> Root Delay: 0.000000, Root dispersion: 0.000000, >> Reference-ID: (unspec) >> Reference Timestamp: 0.000000000 >> Originator Timestamp: 0.000000000 >> Receive Timestamp: 0.000000000 >> Transmit Timestamp: 3691177073.000000000 (2016/12/19 >> 22:57:53) >> Originator - Receive Timestamp: 0.000000000 >> Originator - Transmit Timestamp: 3691177073.000000000 >> (2016/12/19 22:57:53) >> 19:58:02.165061 IP (tos 0x0, ttl 64, id 38520, offset 0, flags >> [none], proto UDP (17), length 76) >> 172.16.31.67.123 > 133.100.9.2.123: [udp sum ok] NTPv3, length >> 48 >> Client, Leap indicator: (0), Stratum 0 (unspecified), poll >> 0 (1s), precision 0 >> Root Delay: 0.000000, Root dispersion: 0.000000, >> Reference-ID: (unspec) >> Reference Timestamp: 0.000000000 >> Originator Timestamp: 0.000000000 >> Receive Timestamp: 0.000000000 >> Transmit Timestamp: 3691177073.000000000 (2016/12/19 >> 22:57:53) >> Originator - Receive Timestamp: 0.000000000 >> Originator - Transmit Timestamp: 3691177073.000000000 >> (2016/12/19 22:57:53) >> >> On 2016-12-19 21:40, Roland Dobbins wrote: >> On 20 Dec 2016, at 2:22, Denys Fedoryshchenko wrote: >> >> If it is necessary i can investigate further. >> >> Yes, please! >> >> ----------------------------------- >> Roland Dobbins From fujimura at fukuoka-u.ac.jp Wed Dec 21 03:58:10 2016 From: fujimura at fukuoka-u.ac.jp (FUJIMURA Sho) Date: Wed, 21 Dec 2016 12:58:10 +0900 Subject: Recent NTP pool traffic increase (update) In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <1c45fa7a2425045d30efb3623bbe3d5a@nuclearcat.com> Message-ID: Hello. I'm Sho FUJIMURA. I operate the public NTP Services as 133.100.9.2 and 133.100.11.8. I'd like to reduce the traffic because I have trouble with too much traffic recently. So, I'm interested in the root of the the problem. If possible, would you please tell me the model numbers of Tenda and TP-Link?? -- Sho FUJIMURA Information Technology Center, Fukuoka University. 8-19-1, Nanakuma, Jyonan-ku, Fukuoka, 8140180, Japan 2016-12-20 5:33 GMT+09:00 Denys Fedoryshchenko : > I'm not sure if this issue relevant to discussed topic, Tenda routers here > for a while on market, and i think i noticed this issue just now, > because NTP servers they are using supposedly for healthcheck went down (or > NTP owners blocked ISP's i support, due such routers). > > At least after checking numerous users, i believe Tenda hardcoded those NTP > IPs. What worsen issue, that in Lebanon several times per day, for example > at 18pm - short electricity cutoff, > and majority of users routers will reboot and surely reconnect, so it will > look like a countrywide spike in NTP traffic. > > I checked for a 10min also this NTP ips in dns responses, none of thousands > of users tried to resolve any name with them over any DNS server, so i > conclude they are hardcoded somewhere in firmware. > > Here is traffic of Tenda router after reconnecting (but not full powercycle, > i dont have it in my hands). But as you can see, no DNS resolution attempts: > > 20:15:59.305739 PPPoE [ses 0x1483] CHAP, Success (0x03), id 1, Msg S=XXXXXX > M=Authentication succeeded > 20:15:59.306100 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 1, length > 12 > 20:15:59.317840 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 1, length > 24 > 20:15:59.317841 PPPoE [ses 0x1483] IPCP, Conf-Ack (0x02), id 1, length 12 > 20:15:59.317867 PPPoE [ses 0x1483] IPCP, Conf-Nack (0x03), id 1, length 18 > 20:15:59.325253 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 2, length > 24 > 20:15:59.325273 PPPoE [ses 0x1483] IPCP, Conf-Ack (0x02), id 2, length 24 > 20:15:59.335589 PPPoE [ses 0x1483] IP 172.17.49.245.123 > 133.100.9.2.123: > NTPv3, Client, length 48 > 20:15:59.335588 PPPoE [ses 0x1483] IP 172.17.49.245.123 > 192.5.41.41.123: > NTPv3, Client, length 48 > 20:15:59.335588 PPPoE [ses 0x1483] IP 172.17.49.245.123 > 192.5.41.40.123: > NTPv3, Client, length 48 > > > Here is example of Tenda traffic if it is unable to reach destination, it > repeats request each 10 seconds endlessly, my guess they are using ntp to > show > status of internet connection. > So, now that NTP servers getting quite significant DDoS such way. > > 19:57:52.162863 IP (tos 0x0, ttl 64, id 38515, offset 0, flags [none], proto > UDP (17), length 76) > 172.16.31.67.123 > 192.5.41.40.123: [udp sum ok] NTPv3, length 48 > Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), > precision 0 > Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: > (unspec) > Reference Timestamp: 0.000000000 > Originator Timestamp: 0.000000000 > Receive Timestamp: 0.000000000 > Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) > Originator - Receive Timestamp: 0.000000000 > Originator - Transmit Timestamp: 3691177063.000000000 > (2016/12/19 22:57:43) > 19:57:52.163277 IP (tos 0x0, ttl 64, id 38516, offset 0, flags [none], proto > UDP (17), length 76) > 172.16.31.67.123 > 192.5.41.41.123: [udp sum ok] NTPv3, length 48 > Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), > precision 0 > Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: > (unspec) > Reference Timestamp: 0.000000000 > Originator Timestamp: 0.000000000 > Receive Timestamp: 0.000000000 > Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) > Originator - Receive Timestamp: 0.000000000 > Originator - Transmit Timestamp: 3691177063.000000000 > (2016/12/19 22:57:43) > 19:57:52.164435 IP (tos 0x0, ttl 64, id 38517, offset 0, flags [none], proto > UDP (17), length 76) > 172.16.31.67.123 > 133.100.9.2.123: [udp sum ok] NTPv3, length 48 > Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), > precision 0 > Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: > (unspec) > Reference Timestamp: 0.000000000 > Originator Timestamp: 0.000000000 > Receive Timestamp: 0.000000000 > Transmit Timestamp: 3691177063.000000000 (2016/12/19 22:57:43) > Originator - Receive Timestamp: 0.000000000 > Originator - Transmit Timestamp: 3691177063.000000000 > (2016/12/19 22:57:43) > 19:58:02.164781 IP (tos 0x0, ttl 64, id 38518, offset 0, flags [none], proto > UDP (17), length 76) > 172.16.31.67.123 > 192.5.41.40.123: [udp sum ok] NTPv3, length 48 > Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), > precision 0 > Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: > (unspec) > Reference Timestamp: 0.000000000 > Originator Timestamp: 0.000000000 > Receive Timestamp: 0.000000000 > Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) > Originator - Receive Timestamp: 0.000000000 > Originator - Transmit Timestamp: 3691177073.000000000 > (2016/12/19 22:57:53) > 19:58:02.164884 IP (tos 0x0, ttl 64, id 38519, offset 0, flags [none], proto > UDP (17), length 76) > 172.16.31.67.123 > 192.5.41.41.123: [udp sum ok] NTPv3, length 48 > Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), > precision 0 > Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: > (unspec) > Reference Timestamp: 0.000000000 > Originator Timestamp: 0.000000000 > Receive Timestamp: 0.000000000 > Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) > Originator - Receive Timestamp: 0.000000000 > Originator - Transmit Timestamp: 3691177073.000000000 > (2016/12/19 22:57:53) > 19:58:02.165061 IP (tos 0x0, ttl 64, id 38520, offset 0, flags [none], proto > UDP (17), length 76) > 172.16.31.67.123 > 133.100.9.2.123: [udp sum ok] NTPv3, length 48 > Client, Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), > precision 0 > Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: > (unspec) > Reference Timestamp: 0.000000000 > Originator Timestamp: 0.000000000 > Receive Timestamp: 0.000000000 > Transmit Timestamp: 3691177073.000000000 (2016/12/19 22:57:53) > Originator - Receive Timestamp: 0.000000000 > Originator - Transmit Timestamp: 3691177073.000000000 > (2016/12/19 22:57:53) > > > On 2016-12-19 21:40, Roland Dobbins wrote: >> >> On 20 Dec 2016, at 2:22, Denys Fedoryshchenko wrote: >> >>> If it is necessary i can investigate further. >> >> >> Yes, please! >> >> ----------------------------------- >> Roland Dobbins > > From jean at ddostest.me Wed Dec 21 16:05:53 2016 From: jean at ddostest.me (Jean | ddostest.me) Date: Wed, 21 Dec 2016 11:05:53 -0500 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack Message-ID: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> Hello all, I'm a first time poster here and hope to follow all rules. I found a new way to amplify traffic that would generate really high volume of traffic.+10Tbps ** There is no need for spoofing ** so any device in the world could initiate a really big attack or be part of an attack. We talk about an amplification factor x100+. This mean that a single computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. Imagine what a botnet could do? The list of affected business is huge and I would like to privately disclose the details to the Tier1 ISP as they are highly vulnerable. XO Comm PSINET Level 3 Qwest Windstream Comm Eearthlink MCI Comm/Verizon Buss Comcast Cable Comm AT&T Sprint I know it's Christmas time and there is no rush in disclosing this but, it could be a nice opportunity to meditate and shed some lights on this new DDoS threat. We could start the real work in January. If you are curious and you operate/manage one of the network mentioned above, please write to me at tornaddos at ddostest.me from your job email to confirm the identity. I will then forward you the DDoS details. Best regards Jean St-Laurent ddostest.me 365 boul. Sir-Wilfrid-Laurier #202 Beloeil, QC J3G 4T2 From dougb at dougbarton.us Thu Dec 22 00:41:29 2016 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 21 Dec 2016 16:41:29 -0800 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> Message-ID: On 12/20/2016 8:08 AM, Royce Williams wrote: > n Sat, Dec 17, 2016 at 6:15 PM, Doug Barton wrote: >> On 12/16/2016 1:48 PM, Hugo Slabbert wrote: >>> >>> This started as a technical appeal, but: >>> >>> https://www.nanog.org/list >>> >>> 1. Discussion will focus on Internet operational and technical issues as >>> described in the charter of NANOG. >> >> Hard to see how the OP has anything to do with either of the above. > > Actually, it's not that hard ... *if* we can control ourselves from > making them partisan, and focus instead on the operational aspects. > (Admittedly, that's pretty hard!) > > The OP's query was a logical combination of two concepts: > > - First, from the charter (emphasis mine): "NANOG provides a forum > where people from the network research community, the network operator > community and the network vendor community can come together *to > identify and solve the problems that arise in operating and growing > the Internet*." > > - Second, from John Gilmore: "The Net interprets censorship as damage > and routes around it." [snip] > Everyone has a line at which "I don't care what's in the pipes, I just > work here" changes into something more actionable. Stretched far beyond any credibility. Your argument boils down to, "If it's a political thing that *I* like, it's on topic." From math at sizone.org Thu Dec 22 00:49:41 2016 From: math at sizone.org (Ken Chase) Date: Wed, 21 Dec 2016 19:49:41 -0500 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: References: <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> Message-ID: <20161222004941.GP2029@sizone.org> On Wed, Dec 21, 2016 at 04:41:29PM -0800, Doug Barton said: [..] >>Everyone has a line at which "I don't care what's in the pipes, I just >>work here" changes into something more actionable. > >Stretched far beyond any credibility. Your argument boils down to, "If it's >a political thing that *I* like, it's on topic." "If it's a politically-generated thing I'll have to deal with at an operational level, it's on topic." That work? /kc -- Ken Chase - math at sizone.org From royce at techsolvency.com Thu Dec 22 02:15:50 2016 From: royce at techsolvency.com (Royce Williams) Date: Wed, 21 Dec 2016 17:15:50 -0900 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <20161222004941.GP2029@sizone.org> References: <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> <20161222004941.GP2029@sizone.org> Message-ID: On Wed, Dec 21, 2016 at 3:49 PM, Ken Chase wrote: > On Wed, Dec 21, 2016 at 04:41:29PM -0800, Doug Barton said: > [..] > >>Everyone has a line at which "I don't care what's in the pipes, I just > >>work here" changes into something more actionable. > > > >Stretched far beyond any credibility. Your argument boils down to, "If it's > >a political thing that *I* like, it's on topic." I can see why you've concluded that. My final phrasing was indeed ambiguous. I would have hoped that the rest of my carefully non-partisan post would have offset that ambiguity. > "If it's a politically-generated thing I'll have to deal with at an > operational level, it's on topic." > > That work? That is indeed what I was trying to say - thanks, Ken. Royce From trelane at trelane.net Thu Dec 22 02:54:42 2016 From: trelane at trelane.net (Andrew Kirch) Date: Wed, 21 Dec 2016 21:54:42 -0500 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: References: <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> <20161222004941.GP2029@sizone.org> Message-ID: I can't for the life of me see why we'd have to deal with it in the course of our jobs beyond calling someone and having them install more A/C. This is, flat-out, off topic. Andrew On Wed, Dec 21, 2016 at 9:15 PM, Royce Williams wrote: > On Wed, Dec 21, 2016 at 3:49 PM, Ken Chase wrote: > > On Wed, Dec 21, 2016 at 04:41:29PM -0800, Doug Barton said: > > [..] > > >>Everyone has a line at which "I don't care what's in the pipes, I > just > > >>work here" changes into something more actionable. > > > > > >Stretched far beyond any credibility. Your argument boils down to, > "If it's > > >a political thing that *I* like, it's on topic." > > I can see why you've concluded that. My final phrasing was indeed > ambiguous. I would have hoped that the rest of my carefully > non-partisan post would have offset that ambiguity. > > > "If it's a politically-generated thing I'll have to deal with at an > > operational level, it's on topic." > > > > That work? > > That is indeed what I was trying to say - thanks, Ken. > > Royce > From ryan at finnesey.com Thu Dec 22 03:00:35 2016 From: ryan at finnesey.com (Ryan Finnesey) Date: Thu, 22 Dec 2016 03:00:35 +0000 Subject: replacing EPP? Message-ID: Has there been an discussion about replacing EPP with something more modern? Cheers Ryan From johnl at iecc.com Thu Dec 22 03:11:33 2016 From: johnl at iecc.com (John Levine) Date: 22 Dec 2016 03:11:33 -0000 Subject: replacing EPP? In-Reply-To: Message-ID: <20161222031133.1634.qmail@ary.lan> In article you write: >Has there been an discussion about replacing EPP with something more modern? No. That was easy. The spec has been updated a few times, most recently by RFC 5730 and 5734 in 2009 but it hasn't changed much. There is an active eppext working group in the IETF that spends most of its time documenting and cleaning up EPP extensions that regstries and registrars have been using all along but never got around to writing up clearly. A new protocol called RDAP is intended to replace WHOIS. It's pretty modern, blobs of JSON over http. You can read all about it in RFC 7480 through 7484. Some people want to use RDAP to check whether a domain is available, but there's been a lot of pushback and advice to use EPP, that's what it's for. R's, John From beecher at beecher.cc Thu Dec 22 03:23:55 2016 From: beecher at beecher.cc (Tom Beecher) Date: Wed, 21 Dec 2016 22:23:55 -0500 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> Message-ID: NTP Monlist was what, 200x? 100x amplification attacks are soooo 2013. :) I doubt many will fall for your Rolodex expanding exercise though, sorry. ( Do people still have Rolodexes? ) On Wed, Dec 21, 2016 at 11:05 AM, Jean | ddostest.me via NANOG < nanog at nanog.org> wrote: > Hello all, I'm a first time poster here and hope to follow all rules. > > I found a new way to amplify traffic that would generate really high > volume of traffic.+10Tbps > > ** There is no need for spoofing ** so any device in the world could > initiate a really big attack or be part of an attack. > > We talk about an amplification factor x100+. This mean that a single > computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. > Imagine what a botnet could do? > > The list of affected business is huge and I would like to privately > disclose the details to the Tier1 ISP as they are highly vulnerable. > > XO Comm > PSINET > Level 3 > Qwest > Windstream Comm > Eearthlink > MCI Comm/Verizon Buss > Comcast Cable Comm > AT&T > Sprint > > I know it's Christmas time and there is no rush in disclosing this but, it > could be a nice opportunity to meditate and shed some lights on this new > DDoS threat. We could start the real work in January. > > > If you are curious and you operate/manage one of the network mentioned > above, please write to me at tornaddos at ddostest.me from your job email to > confirm the identity. I will then forward you the DDoS details. > > Best regards > > Jean St-Laurent > ddostest.me > 365 boul. Sir-Wilfrid-Laurier #202 > Beloeil, QC J3G 4T2 > From royce at techsolvency.com Thu Dec 22 04:16:14 2016 From: royce at techsolvency.com (Royce Williams) Date: Wed, 21 Dec 2016 19:16:14 -0900 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> Message-ID: On Tue, Dec 20, 2016 at 7:08 AM, Royce Williams wrote: [snip] > IMO, *operational, politics-free* discussion of items like these would > also be on topic for NANOG: > > - Some *operational* workarounds for country-wide blocking of > Facebook, Whatsapp, and Twitter [1], or Signal [2] [snip] > 2. http://www.nytimes.com/aponline/2016/12/20/world/middleeast/ap-ml-egypt-app-blocked.html Steering things back towards the operational, the makers of Signal announced today [1] an update to Signal with a workaround for the blocking that I noted earlier. Support in iOS is still in beta. The technique (which was new to me) is called 'domain fronting' [2]. It works by distributing TLS-based components among domains for which blocking would cause wide-sweeping collateral damage if blocked (such as Google, Amazon S3, Akamai, etc.), making blocking less attractive. Since it's TLS, the Signal connections cannot be differentiated from other services in those domains. Signal's implementation of domain fronting is currently limited to countries where the blocking has been observed, but their post says that they're ramping up to make it available more broadly, and to automatically enable the feature when non-local phone numbers travel into areas subject to blocking. The cited domain-fronting paper [2] was co-authored by David Fifield, who has worked on nmap and Tor. Royce 1. https://whispersystems.org/blog/doodles-stickers-censorship/ 2. http://www.icir.org/vern/papers/meek-PETS-2015.pdf From jhellenthal at dataix.net Thu Dec 22 05:03:45 2016 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Wed, 21 Dec 2016 23:03:45 -0600 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> Message-ID: <8DF7B3D1-350D-4D31-AB49-C22B287D141C@dataix.net> Simply put? if the data that is hosted on the sites aforementioned then cough up the damn space and host it. Data space is cheap as hell these days, parse it and get the hell on with it already. *Disclaimer* not meant to single out any one party in this conversation but the whole subject all together. Need someone to help mirror the data ? I may or may not be able to assist with that. Provide the space to upload it to and the direction to the data you want. But beyond all that. This subject is plainly just off topic. > On Dec 21, 2016, at 22:16, Royce Williams wrote: > > On Tue, Dec 20, 2016 at 7:08 AM, Royce Williams wrote: > > [snip] > >> IMO, *operational, politics-free* discussion of items like these would >> also be on topic for NANOG: >> >> - Some *operational* workarounds for country-wide blocking of >> Facebook, Whatsapp, and Twitter [1], or Signal [2] > > [snip] > >> 2. http://www.nytimes.com/aponline/2016/12/20/world/middleeast/ap-ml-egypt-app-blocked.html > > Steering things back towards the operational, the makers of Signal > announced today [1] an update to Signal with a workaround for the > blocking that I noted earlier. Support in iOS is still in beta. > > The technique (which was new to me) is called 'domain fronting' [2]. > It works by distributing TLS-based components among domains for which > blocking would cause wide-sweeping collateral damage if blocked (such > as Google, Amazon S3, Akamai, etc.), making blocking less attractive. > Since it's TLS, the Signal connections cannot be differentiated from > other services in those domains. > > Signal's implementation of domain fronting is currently limited to > countries where the blocking has been observed, but their post says > that they're ramping up to make it available more broadly, and to > automatically enable the feature when non-local phone numbers travel > into areas subject to blocking. > > The cited domain-fronting paper [2] was co-authored by David Fifield, > who has worked on nmap and Tor. > > Royce > > 1. https://whispersystems.org/blog/doodles-stickers-censorship/ > 2. http://www.icir.org/vern/papers/meek-PETS-2015.pdf -- Jason Hellenthal JJH48-ARIN From royce at techsolvency.com Thu Dec 22 05:35:07 2016 From: royce at techsolvency.com (Royce Williams) Date: Wed, 21 Dec 2016 20:35:07 -0900 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <8DF7B3D1-350D-4D31-AB49-C22B287D141C@dataix.net> References: <20161216155800.GA504@gsp.org> <4CC024FA-DE4D-4AF4-B05F-CF624E8A3E68@gmail.com> <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> <8DF7B3D1-350D-4D31-AB49-C22B287D141C@dataix.net> Message-ID: On Wed, Dec 21, 2016 at 8:03 PM, Jason Hellenthal wrote: > Simply put? if the data that is hosted on the sites aforementioned then cough up the damn space and host it. Data space is cheap as hell these days, parse it and get the hell on with it already. > > *Disclaimer* > not meant to single out any one party in this conversation but the whole subject all together. Need someone to help mirror the data ? I may or may not be able to assist with that. Provide the space to upload it to and the direction to the data you want. But beyond all that. This subject is plainly just off topic. Jason, understood. I clearly should have updated the subject line of the thread, as you're not the first to continue to respond to the subject line, instead of what I've been recently saying. :) My most recent reply was about some operational aspects of country-wide Signal blocking, not the OP topic. I would almost consider updating the subject accordingly ... but at this point, it's clear that transcendence of the amygdala will continue to elude us, and this thread would apparently rather die than suffer my attempts to beat it into a plowshare. :) Royce >> On Dec 21, 2016, at 22:16, Royce Williams wrote: >> >> On Tue, Dec 20, 2016 at 7:08 AM, Royce Williams wrote: >> >> [snip] >> >>> IMO, *operational, politics-free* discussion of items like these would >>> also be on topic for NANOG: >>> >>> - Some *operational* workarounds for country-wide blocking of >>> Facebook, Whatsapp, and Twitter [1], or Signal [2] >> >> [snip] >> >>> 2. http://www.nytimes.com/aponline/2016/12/20/world/middleeast/ap-ml-egypt-app-blocked.html >> >> Steering things back towards the operational, the makers of Signal >> announced today [1] an update to Signal with a workaround for the >> blocking that I noted earlier. Support in iOS is still in beta. >> >> The technique (which was new to me) is called 'domain fronting' [2]. >> It works by distributing TLS-based components among domains for which >> blocking would cause wide-sweeping collateral damage if blocked (such >> as Google, Amazon S3, Akamai, etc.), making blocking less attractive. >> Since it's TLS, the Signal connections cannot be differentiated from >> other services in those domains. >> >> Signal's implementation of domain fronting is currently limited to >> countries where the blocking has been observed, but their post says >> that they're ramping up to make it available more broadly, and to >> automatically enable the feature when non-local phone numbers travel >> into areas subject to blocking. >> >> The cited domain-fronting paper [2] was co-authored by David Fifield, >> who has worked on nmap and Tor. >> >> Royce >> >> 1. https://whispersystems.org/blog/doodles-stickers-censorship/ >> 2. http://www.icir.org/vern/papers/meek-PETS-2015.pdf From Valdis.Kletnieks at vt.edu Thu Dec 22 05:43:02 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 22 Dec 2016 00:43:02 -0500 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <20161222004941.GP2029@sizone.org> References: <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> <20161222004941.GP2029@sizone.org> Message-ID: <28246.1482385382@turing-police.cc.vt.edu> On Wed, 21 Dec 2016 19:49:41 -0500, Ken Chase said: > "If it's a politically-generated thing I'll have to deal with at an > operational level, it's on topic." Hmm.. works for me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Dec 22 05:44:52 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 22 Dec 2016 00:44:52 -0500 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: References: <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> <20161222004941.GP2029@sizone.org> Message-ID: <28454.1482385492@turing-police.cc.vt.edu> On Wed, 21 Dec 2016 21:54:42 -0500, Andrew Kirch said: > I can't for the life of me see why we'd have to deal with it in the course > of our jobs beyond calling someone and having them install more A/C. This > is, flat-out, off topic. You don't have any fiber that runs into regen shacks in low-lying areas that didn't *used* to flood, do you? Ask Verizon how much fun they had getting salt water off underground copper after Sandy. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From mike.lyon at gmail.com Thu Dec 22 06:00:15 2016 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 21 Dec 2016 22:00:15 -0800 Subject: Any WAVE Business clue on the list? Message-ID: If so, can you hit me up offlist? Thank You, Mike -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From la at qrator.net Thu Dec 22 06:46:09 2016 From: la at qrator.net (Alexander Lyamin) Date: Thu, 22 Dec 2016 09:46:09 +0300 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> Message-ID: care to do a demo ? On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me via NANOG < nanog at nanog.org> wrote: > Hello all, I'm a first time poster here and hope to follow all rules. > > I found a new way to amplify traffic that would generate really high > volume of traffic.+10Tbps > > ** There is no need for spoofing ** so any device in the world could > initiate a really big attack or be part of an attack. > > We talk about an amplification factor x100+. This mean that a single > computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. > Imagine what a botnet could do? > > The list of affected business is huge and I would like to privately > disclose the details to the Tier1 ISP as they are highly vulnerable. > > XO Comm > PSINET > Level 3 > Qwest > Windstream Comm > Eearthlink > MCI Comm/Verizon Buss > Comcast Cable Comm > AT&T > Sprint > > I know it's Christmas time and there is no rush in disclosing this but, it > could be a nice opportunity to meditate and shed some lights on this new > DDoS threat. We could start the real work in January. > > > If you are curious and you operate/manage one of the network mentioned > above, please write to me at tornaddos at ddostest.me from your job email to > confirm the identity. I will then forward you the DDoS details. > > Best regards > > Jean St-Laurent > ddostest.me > 365 boul. Sir-Wilfrid-Laurier #202 > Beloeil, QC J3G 4T2 > -- Alexander Lyamin CEO | Qrator * Labs* office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net From la at qrator.net Thu Dec 22 06:51:36 2016 From: la at qrator.net (Alexander Lyamin) Date: Thu, 22 Dec 2016 09:51:36 +0300 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> Message-ID: I am just trying to grasp what is similarity between networks on the list and why it doesn't include, say NTT or Cogent. On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me via NANOG < nanog at nanog.org> wrote: > Hello all, I'm a first time poster here and hope to follow all rules. > > I found a new way to amplify traffic that would generate really high > volume of traffic.+10Tbps > > ** There is no need for spoofing ** so any device in the world could > initiate a really big attack or be part of an attack. > > We talk about an amplification factor x100+. This mean that a single > computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. > Imagine what a botnet could do? > > The list of affected business is huge and I would like to privately > disclose the details to the Tier1 ISP as they are highly vulnerable. > > XO Comm > PSINET > Level 3 > Qwest > Windstream Comm > Eearthlink > MCI Comm/Verizon Buss > Comcast Cable Comm > AT&T > Sprint > > I know it's Christmas time and there is no rush in disclosing this but, it > could be a nice opportunity to meditate and shed some lights on this new > DDoS threat. We could start the real work in January. > > > If you are curious and you operate/manage one of the network mentioned > above, please write to me at tornaddos at ddostest.me from your job email to > confirm the identity. I will then forward you the DDoS details. > > Best regards > > Jean St-Laurent > ddostest.me > 365 boul. Sir-Wilfrid-Laurier #202 > Beloeil, QC J3G 4T2 > -- Alexander Lyamin CEO | Qrator * Labs* office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net From edward.dore at freethought-internet.co.uk Thu Dec 22 09:25:31 2016 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Thu, 22 Dec 2016 09:25:31 +0000 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> Message-ID: <4EA68193-D5F6-4344-AA90-9E75E8A19CAF@freethought-internet.co.uk> Depending on which bit of PSINET Jean is talking about, that could be Cogent. Edward Dore Freethought Internet > On 22 Dec 2016, at 06:51, Alexander Lyamin wrote: > > I am just trying to grasp what is similarity between networks on the list > and why it doesn't include, say NTT or Cogent. > > > > On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me via NANOG < > nanog at nanog.org> wrote: > >> Hello all, I'm a first time poster here and hope to follow all rules. >> >> I found a new way to amplify traffic that would generate really high >> volume of traffic.+10Tbps >> >> ** There is no need for spoofing ** so any device in the world could >> initiate a really big attack or be part of an attack. >> >> We talk about an amplification factor x100+. This mean that a single >> computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. >> Imagine what a botnet could do? >> >> The list of affected business is huge and I would like to privately >> disclose the details to the Tier1 ISP as they are highly vulnerable. >> >> XO Comm >> PSINET >> Level 3 >> Qwest >> Windstream Comm >> Eearthlink >> MCI Comm/Verizon Buss >> Comcast Cable Comm >> AT&T >> Sprint >> >> I know it's Christmas time and there is no rush in disclosing this but, it >> could be a nice opportunity to meditate and shed some lights on this new >> DDoS threat. We could start the real work in January. >> >> >> If you are curious and you operate/manage one of the network mentioned >> above, please write to me at tornaddos at ddostest.me from your job email to >> confirm the identity. I will then forward you the DDoS details. >> >> Best regards >> >> Jean St-Laurent >> ddostest.me >> 365 boul. Sir-Wilfrid-Laurier #202 >> Beloeil, QC J3G 4T2 >> > > > > -- > > Alexander Lyamin > > CEO | Qrator * Labs* > > office: 8-800-3333-LAB (522) > > mob: +7-916-9086122 > > skype: melanor9 > > mailto: la at qrator.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From la at qrator.net Thu Dec 22 10:52:12 2016 From: la at qrator.net (Alexander Lyamin) Date: Thu, 22 Dec 2016 13:52:12 +0300 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: <4EA68193-D5F6-4344-AA90-9E75E8A19CAF@freethought-internet.co.uk> References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <4EA68193-D5F6-4344-AA90-9E75E8A19CAF@freethought-internet.co.uk> Message-ID: nice one, Edward. On Thu, Dec 22, 2016 at 12:25 PM, Edward Dore < edward.dore at freethought-internet.co.uk> wrote: > Depending on which bit of PSINET Jean is talking about, that could be > Cogent. > > Edward Dore > Freethought Internet > > On 22 Dec 2016, at 06:51, Alexander Lyamin wrote: > > I am just trying to grasp what is similarity between networks on the list > and why it doesn't include, say NTT or Cogent. > > > > On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me via NANOG < > nanog at nanog.org> wrote: > > Hello all, I'm a first time poster here and hope to follow all rules. > > I found a new way to amplify traffic that would generate really high > volume of traffic.+10Tbps > > ** There is no need for spoofing ** so any device in the world could > initiate a really big attack or be part of an attack. > > We talk about an amplification factor x100+. This mean that a single > computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. > Imagine what a botnet could do? > > The list of affected business is huge and I would like to privately > disclose the details to the Tier1 ISP as they are highly vulnerable. > > XO Comm > PSINET > Level 3 > Qwest > Windstream Comm > Eearthlink > MCI Comm/Verizon Buss > Comcast Cable Comm > AT&T > Sprint > > I know it's Christmas time and there is no rush in disclosing this but, it > could be a nice opportunity to meditate and shed some lights on this new > DDoS threat. We could start the real work in January. > > > If you are curious and you operate/manage one of the network mentioned > above, please write to me at tornaddos at ddostest.me from your job email to > confirm the identity. I will then forward you the DDoS details. > > Best regards > > Jean St-Laurent > ddostest.me > 365 boul. Sir-Wilfrid-Laurier #202 > Beloeil, QC J3G 4T2 > > > > > -- > > Alexander Lyamin > > CEO | Qrator * Labs* > > office: 8-800-3333-LAB (522) > > mob: +7-916-9086122 > > skype: melanor9 > > mailto: la at qrator.net > > > -- Alexander Lyamin CEO | Qrator * Labs* office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net From fujimura at fukuoka-u.ac.jp Thu Dec 22 03:13:42 2016 From: fujimura at fukuoka-u.ac.jp (FUJIMURA Sho) Date: Thu, 22 Dec 2016 12:13:42 +0900 Subject: Recent NTP pool traffic increase (update) In-Reply-To: <07c6752a5396d8d99d11dfca131b8155@nuclearcat.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <1c45fa7a2425045d30efb3623bbe3d5a@nuclearcat.com> <07c6752a5396d8d99d11dfca131b8155@nuclearcat.com> Message-ID: Hello. I operate the public NTP Service as 133.100.9.2 and 133.100.11.8 at Fukuoka University, Japan. I have a lot of trouble with too much NTP traffic from many routers which 133.100.9.2 as default setting of NTP has been set like Tenda or LB-Link etc. So, although I'd like to contact Firmware developpers of these company and would like them to change the default settins, is there the person knowing the contact information? -- Sho FUJIMURA Information Technology Center, Fukuoka University. 8-19-1, Nanakuma, Jyonan-ku, Fukuoka, 8140180, Japan 2016-12-21 18:36 GMT+09:00 Denys Fedoryshchenko : > Hello, > > I'm not sure i should continue to CC nanog, if someone interested to be in > CC for further updates this story please let me know. > > TP-Link not related, it was misunderstanding or wrong customer report. > > Tenda routers i believe most of cheap models are affected by this problem. > On ISPs i have access i see too many of them sending requests to 133.100.9.2 > (if it is unreachable, repeating each 10 seconds), this particular ip seems > hardcoded there. I am sure as soon as your server is down, way they coded - > it will make all this routers to ddos this particular ip, repeating NTP > queries very often without any backoff/protection mechanism. > Particular model i tested - W308R / Wireless N300 Home Router, but i believe > many models are affected. > Firmware: System Version: 5.0.7.53_en hw version : v1.0 > > Another possible vendor is LB-Link, but i dont have yet any info from > customers who own them. > > On 2016-12-21 11:00, FUJIMURA Sho wrote: >> >> Hello. >> >> I'm Sho FUJIMURA. >> Thank you for your information. >> I operate the public NTP Services as 133.100.9.2 and 133.100.11.8. >> I'd like to reduce the traffic because I have trouble with too much >> traffic recently. >> So, I'm interested in the root of the the problem. >> If possible, would you please tell me the model numbers of Tenda and >> TP-Link?? >> >> -- >> Sho FUJIMURA >> Information Technology Center, Fukuoka University. >> 8-19-1, Nanakuma, Jyonan-ku, Fukuoka, 8140180, Japan >> >> fujimura at fukuoka-u.ac.jp >> >> 2016-12-20 5:33 GMT+09:00 Denys Fedoryshchenko : >> >>> I'm not sure if this issue relevant to discussed topic, Tenda >>> routers here for a while on market, and i think i noticed this issue >>> just now, >>> because NTP servers they are using supposedly for healthcheck went >>> down (or NTP owners blocked ISP's i support, due such routers). >>> >>> At least after checking numerous users, i believe Tenda hardcoded >>> those NTP IPs. What worsen issue, that in Lebanon several times per >>> day, for example at 18pm - short electricity cutoff, >>> and majority of users routers will reboot and surely reconnect, so >>> it will look like a countrywide spike in NTP traffic. >>> >>> I checked for a 10min also this NTP ips in dns responses, none of >>> thousands of users tried to resolve any name with them over any DNS >>> server, so i conclude they are hardcoded somewhere in firmware. >>> >>> Here is traffic of Tenda router after reconnecting (but not full >>> powercycle, i dont have it in my hands). But as you can see, no DNS >>> resolution attempts: >>> >>> 20:15:59.305739 PPPoE [ses 0x1483] CHAP, Success (0x03), id 1, Msg >>> S=XXXXXX M=Authentication succeeded >>> 20:15:59.306100 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 1, >>> length 12 >>> 20:15:59.317840 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 1, >>> length 24 >>> 20:15:59.317841 PPPoE [ses 0x1483] IPCP, Conf-Ack (0x02), id 1, >>> length 12 >>> 20:15:59.317867 PPPoE [ses 0x1483] IPCP, Conf-Nack (0x03), id 1, >>> length 18 >>> 20:15:59.325253 PPPoE [ses 0x1483] IPCP, Conf-Request (0x01), id 2, >>> length 24 >>> 20:15:59.325273 PPPoE [ses 0x1483] IPCP, Conf-Ack (0x02), id 2, >>> length 24 >>> 20:15:59.335589 PPPoE [ses 0x1483] IP 172.17.49.245.123 > >>> 133.100.9.2.123: NTPv3, Client, length 48 >>> 20:15:59.335588 PPPoE [ses 0x1483] IP 172.17.49.245.123 > >>> 192.5.41.41.123: NTPv3, Client, length 48 >>> 20:15:59.335588 PPPoE [ses 0x1483] IP 172.17.49.245.123 > >>> 192.5.41.40.123: NTPv3, Client, length 48 >>> >>> Here is example of Tenda traffic if it is unable to reach >>> destination, it repeats request each 10 seconds endlessly, my guess >>> they are using ntp to show >>> status of internet connection. >>> So, now that NTP servers getting quite significant DDoS such way. >>> >>> 19:57:52.162863 IP (tos 0x0, ttl 64, id 38515, offset 0, flags >>> [none], proto UDP (17), length 76) >>> 172.16.31.67.123 > 192.5.41.40.123: [udp sum ok] NTPv3, length >>> 48 >>> Client, Leap indicator: (0), Stratum 0 (unspecified), poll >>> 0 (1s), precision 0 >>> Root Delay: 0.000000, Root dispersion: 0.000000, >>> Reference-ID: (unspec) >>> Reference Timestamp: 0.000000000 >>> Originator Timestamp: 0.000000000 >>> Receive Timestamp: 0.000000000 >>> Transmit Timestamp: 3691177063.000000000 (2016/12/19 >>> 22:57:43) >>> Originator - Receive Timestamp: 0.000000000 >>> Originator - Transmit Timestamp: 3691177063.000000000 >>> (2016/12/19 22:57:43) >>> 19:57:52.163277 IP (tos 0x0, ttl 64, id 38516, offset 0, flags >>> [none], proto UDP (17), length 76) >>> 172.16.31.67.123 > 192.5.41.41.123: [udp sum ok] NTPv3, length >>> 48 >>> Client, Leap indicator: (0), Stratum 0 (unspecified), poll >>> 0 (1s), precision 0 >>> Root Delay: 0.000000, Root dispersion: 0.000000, >>> Reference-ID: (unspec) >>> Reference Timestamp: 0.000000000 >>> Originator Timestamp: 0.000000000 >>> Receive Timestamp: 0.000000000 >>> Transmit Timestamp: 3691177063.000000000 (2016/12/19 >>> 22:57:43) >>> Originator - Receive Timestamp: 0.000000000 >>> Originator - Transmit Timestamp: 3691177063.000000000 >>> (2016/12/19 22:57:43) >>> 19:57:52.164435 IP (tos 0x0, ttl 64, id 38517, offset 0, flags >>> [none], proto UDP (17), length 76) >>> 172.16.31.67.123 > 133.100.9.2.123: [udp sum ok] NTPv3, length >>> 48 >>> Client, Leap indicator: (0), Stratum 0 (unspecified), poll >>> 0 (1s), precision 0 >>> Root Delay: 0.000000, Root dispersion: 0.000000, >>> Reference-ID: (unspec) >>> Reference Timestamp: 0.000000000 >>> Originator Timestamp: 0.000000000 >>> Receive Timestamp: 0.000000000 >>> Transmit Timestamp: 3691177063.000000000 (2016/12/19 >>> 22:57:43) >>> Originator - Receive Timestamp: 0.000000000 >>> Originator - Transmit Timestamp: 3691177063.000000000 >>> (2016/12/19 22:57:43) >>> 19:58:02.164781 IP (tos 0x0, ttl 64, id 38518, offset 0, flags >>> [none], proto UDP (17), length 76) >>> 172.16.31.67.123 > 192.5.41.40.123: [udp sum ok] NTPv3, length >>> 48 >>> Client, Leap indicator: (0), Stratum 0 (unspecified), poll >>> 0 (1s), precision 0 >>> Root Delay: 0.000000, Root dispersion: 0.000000, >>> Reference-ID: (unspec) >>> Reference Timestamp: 0.000000000 >>> Originator Timestamp: 0.000000000 >>> Receive Timestamp: 0.000000000 >>> Transmit Timestamp: 3691177073.000000000 (2016/12/19 >>> 22:57:53) >>> Originator - Receive Timestamp: 0.000000000 >>> Originator - Transmit Timestamp: 3691177073.000000000 >>> (2016/12/19 22:57:53) >>> 19:58:02.164884 IP (tos 0x0, ttl 64, id 38519, offset 0, flags >>> [none], proto UDP (17), length 76) >>> 172.16.31.67.123 > 192.5.41.41.123: [udp sum ok] NTPv3, length >>> 48 >>> Client, Leap indicator: (0), Stratum 0 (unspecified), poll >>> 0 (1s), precision 0 >>> Root Delay: 0.000000, Root dispersion: 0.000000, >>> Reference-ID: (unspec) >>> Reference Timestamp: 0.000000000 >>> Originator Timestamp: 0.000000000 >>> Receive Timestamp: 0.000000000 >>> Transmit Timestamp: 3691177073.000000000 (2016/12/19 >>> 22:57:53) >>> Originator - Receive Timestamp: 0.000000000 >>> Originator - Transmit Timestamp: 3691177073.000000000 >>> (2016/12/19 22:57:53) >>> 19:58:02.165061 IP (tos 0x0, ttl 64, id 38520, offset 0, flags >>> [none], proto UDP (17), length 76) >>> 172.16.31.67.123 > 133.100.9.2.123: [udp sum ok] NTPv3, length >>> 48 >>> Client, Leap indicator: (0), Stratum 0 (unspecified), poll >>> 0 (1s), precision 0 >>> Root Delay: 0.000000, Root dispersion: 0.000000, >>> Reference-ID: (unspec) >>> Reference Timestamp: 0.000000000 >>> Originator Timestamp: 0.000000000 >>> Receive Timestamp: 0.000000000 >>> Transmit Timestamp: 3691177073.000000000 (2016/12/19 >>> 22:57:53) >>> Originator - Receive Timestamp: 0.000000000 >>> Originator - Transmit Timestamp: 3691177073.000000000 >>> (2016/12/19 22:57:53) >>> >>> On 2016-12-19 21:40, Roland Dobbins wrote: >>> On 20 Dec 2016, at 2:22, Denys Fedoryshchenko wrote: >>> >>> If it is necessary i can investigate further. >>> >>> Yes, please! >>> >>> ----------------------------------- >>> Roland Dobbins > > From j.j.santanna at utwente.nl Thu Dec 22 08:46:58 2016 From: j.j.santanna at utwente.nl (j.j.santanna at utwente.nl) Date: Thu, 22 Dec 2016 08:46:58 +0000 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> Message-ID: <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> Hi Jean, You are either naive or have a lot of guts to offer a Booter service in one of the most respected network operators list. Man, as long as you use amplifiers (third party services) or botnets your ?service? is illegal & immoral. In case you use your own infrastructure or rent a legal (cloud) infrastructure to provide your "service" it will not pay your costs. Not at least by the price that you offer your service: 0, 13, 100 bucks. Even if you have a legal/moral acceptable attack infrastructure, if you throw those big attacks that you advertise will possibly take down many others third-parties on the way. Sometimes you folks say that (mis)use amplifiers for ?testing? purpose is not a problem because those services are open and publicly available on the Internet. Come on? if I leave my car open with the key inside it doesn?t give you the right to use my car to throw into a third party company. And if you do, it is YOUR CRIME, not mine. I don?t need to explain why using botnets is illegal and immoral, right? Man, it is up to you decide between cyber crime and cyber security (https://www.europol.europa.eu/activities-services/public-awareness-and-prevention-guides/cyber-crime-vs-cyber-security-what-will-you-choose). Now, we are also looking to you on http://booterblacklist.com. Thanks! Cheers, Jair Santanna On 22 Dec 2016, at 07:51, Alexander Lyamin > wrote: I am just trying to grasp what is similarity between networks on the list and why it doesn't include, say NTT or Cogent. On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me via NANOG < nanog at nanog.org> wrote: Hello all, I'm a first time poster here and hope to follow all rules. I found a new way to amplify traffic that would generate really high volume of traffic.+10Tbps ** There is no need for spoofing ** so any device in the world could initiate a really big attack or be part of an attack. We talk about an amplification factor x100+. This mean that a single computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. Imagine what a botnet could do? The list of affected business is huge and I would like to privately disclose the details to the Tier1 ISP as they are highly vulnerable. XO Comm PSINET Level 3 Qwest Windstream Comm Eearthlink MCI Comm/Verizon Buss Comcast Cable Comm AT&T Sprint I know it's Christmas time and there is no rush in disclosing this but, it could be a nice opportunity to meditate and shed some lights on this new DDoS threat. We could start the real work in January. If you are curious and you operate/manage one of the network mentioned above, please write to me at tornaddos at ddostest.me from your job email to confirm the identity. I will then forward you the DDoS details. Best regards Jean St-Laurent ddostest.me 365 boul. Sir-Wilfrid-Laurier #202 Beloeil, QC J3G 4T2 -- Alexander Lyamin CEO | Qrator * Labs* office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net From jean at ddostest.me Thu Dec 22 10:45:09 2016 From: jean at ddostest.me (Jean | ddostest.me) Date: Thu, 22 Dec 2016 05:45:09 -0500 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> Message-ID: <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> I admit that I have a lot of guts. Not sure who said that I am a booter or that I operate a booter. I fight booter since more than 5 years and who would be stupid enough to put his full name with full address to a respected network operators list? Definitely not me. I want to help and fix things and I am not the kind of person to break things. Jean On 16-12-22 03:46 AM, j.j.santanna at utwente.nl wrote: > Hi Jean, > > You are either naive or have a lot of guts to offer a Booter service in one of the most respected network operators list. Man, as long as you use amplifiers (third party services) or botnets your ?service? is illegal & immoral. In case you use your own infrastructure or rent a legal (cloud) infrastructure to provide your "service" it will not pay your costs. Not at least by the price that you offer your service: 0, 13, 100 bucks. Even if you have a legal/moral acceptable attack infrastructure, if you throw those big attacks that you advertise will possibly take down many others third-parties on the way. > > Sometimes you folks say that (mis)use amplifiers for ?testing? purpose is not a problem because those services are open and publicly available on the Internet. Come on? if I leave my car open with the key inside it doesn?t give you the right to use my car to throw into a third party company. And if you do, it is YOUR CRIME, not mine. > > I don?t need to explain why using botnets is illegal and immoral, right? > > Man, it is up to you decide between cyber crime and cyber security (https://www.europol.europa.eu/activities-services/public-awareness-and-prevention-guides/cyber-crime-vs-cyber-security-what-will-you-choose). Now, we are also looking to you on http://booterblacklist.com. Thanks! > > Cheers, > > Jair Santanna > > > > > On 22 Dec 2016, at 07:51, Alexander Lyamin > wrote: > > I am just trying to grasp what is similarity between networks on the list > and why it doesn't include, say NTT or Cogent. > > > > On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me via NANOG < > nanog at nanog.org> wrote: > > Hello all, I'm a first time poster here and hope to follow all rules. > > I found a new way to amplify traffic that would generate really high > volume of traffic.+10Tbps > > ** There is no need for spoofing ** so any device in the world could > initiate a really big attack or be part of an attack. > > We talk about an amplification factor x100+. This mean that a single > computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. > Imagine what a botnet could do? > > The list of affected business is huge and I would like to privately > disclose the details to the Tier1 ISP as they are highly vulnerable. > > XO Comm > PSINET > Level 3 > Qwest > Windstream Comm > Eearthlink > MCI Comm/Verizon Buss > Comcast Cable Comm > AT&T > Sprint > > I know it's Christmas time and there is no rush in disclosing this but, it > could be a nice opportunity to meditate and shed some lights on this new > DDoS threat. We could start the real work in January. > > > If you are curious and you operate/manage one of the network mentioned > above, please write to me at tornaddos at ddostest.me from your job email to > confirm the identity. I will then forward you the DDoS details. > > Best regards > > Jean St-Laurent > ddostest.me > 365 boul. Sir-Wilfrid-Laurier #202 > Beloeil, QC J3G 4T2 > > > > > -- > > Alexander Lyamin > > CEO | Qrator * Labs* > > office: 8-800-3333-LAB (522) > > mob: +7-916-9086122 > > skype: melanor9 > > mailto: la at qrator.net > From beecher at beecher.cc Thu Dec 22 13:21:53 2016 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 22 Dec 2016 08:21:53 -0500 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> Message-ID: You're claiming to be able to generate more than 10 times as much traffic as the largest DDoS ever seen in the wild whilst 3 months into a position at a company that sells 'self-DDoS' services for testing purposes. In that absence of anything more than 'GUYZ THIS IS SERIOUS' , with no technical details, you can surely understand the skepticism. On Thu, Dec 22, 2016 at 5:45 AM, Jean | ddostest.me via NANOG < nanog at nanog.org> wrote: > I admit that I have a lot of guts. > > Not sure who said that I am a booter or that I operate a booter. I fight > booter since more than 5 years and who would be stupid enough to put his > full name with full address to a respected network operators list? > Definitely not me. > > I want to help and fix things and I am not the kind of person to break > things. > > > Jean > > > On 16-12-22 03:46 AM, j.j.santanna at utwente.nl wrote: > >> Hi Jean, >> >> You are either naive or have a lot of guts to offer a Booter service in >> one of the most respected network operators list. Man, as long as you use >> amplifiers (third party services) or botnets your ?service? is illegal & >> immoral. In case you use your own infrastructure or rent a legal (cloud) >> infrastructure to provide your "service" it will not pay your costs. Not at >> least by the price that you offer your service: 0, 13, 100 bucks. Even if >> you have a legal/moral acceptable attack infrastructure, if you throw those >> big attacks that you advertise will possibly take down many others >> third-parties on the way. >> >> Sometimes you folks say that (mis)use amplifiers for ?testing? purpose is >> not a problem because those services are open and publicly available on the >> Internet. Come on? if I leave my car open with the key inside it doesn?t >> give you the right to use my car to throw into a third party company. And >> if you do, it is YOUR CRIME, not mine. >> >> I don?t need to explain why using botnets is illegal and immoral, right? >> >> Man, it is up to you decide between cyber crime and cyber security ( >> https://www.europol.europa.eu/activities-services/public-aw >> areness-and-prevention-guides/cyber-crime-vs-cyber-security- >> what-will-you-choose). Now, we are also looking to you on >> http://booterblacklist.com. Thanks! >> >> Cheers, >> >> Jair Santanna >> >> >> >> >> On 22 Dec 2016, at 07:51, Alexander Lyamin > r.net>> wrote: >> >> I am just trying to grasp what is similarity between networks on the list >> and why it doesn't include, say NTT or Cogent. >> >> >> >> On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me >> via NANOG < >> nanog at nanog.org> wrote: >> >> Hello all, I'm a first time poster here and hope to follow all rules. >> >> I found a new way to amplify traffic that would generate really high >> volume of traffic.+10Tbps >> >> ** There is no need for spoofing ** so any device in the world could >> initiate a really big attack or be part of an attack. >> >> We talk about an amplification factor x100+. This mean that a single >> computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. >> Imagine what a botnet could do? >> >> The list of affected business is huge and I would like to privately >> disclose the details to the Tier1 ISP as they are highly vulnerable. >> >> XO Comm >> PSINET >> Level 3 >> Qwest >> Windstream Comm >> Eearthlink >> MCI Comm/Verizon Buss >> Comcast Cable Comm >> AT&T >> Sprint >> >> I know it's Christmas time and there is no rush in disclosing this but, it >> could be a nice opportunity to meditate and shed some lights on this new >> DDoS threat. We could start the real work in January. >> >> >> If you are curious and you operate/manage one of the network mentioned >> above, please write to me at tornaddos at ddostest.me> ornaddos at ddostest.me> from your job email to >> confirm the identity. I will then forward you the DDoS details. >> >> Best regards >> >> Jean St-Laurent >> ddostest.me >> 365 boul. Sir-Wilfrid-Laurier #202 >> Beloeil, QC J3G 4T2 >> >> >> >> >> -- >> >> Alexander Lyamin >> >> CEO | Qrator * Labs* >> >> office: 8-800-3333-LAB (522) >> >> mob: +7-916-9086122 >> >> skype: melanor9 >> >> mailto: la at qrator.net >> >> From jean at ddostest.me Thu Dec 22 13:27:03 2016 From: jean at ddostest.me (Jean | ddostest.me) Date: Thu, 22 Dec 2016 08:27:03 -0500 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> Message-ID: I apologize for my previous email. After a second thought it might sound like it's a booter even though I want to offer something else. I don't want the conversation shifting toward business when we talk about a new DDoS technique that operate at Layer 3 with amplification power x100. I disabled the "booter" service and will review this offline with my lawyer. Thanks for pointing this out. Now back to this new DDoS technique. If it can amplify at Layer 3, it could potentially be use in conjunction with the already known Layer 4 amp DDoS like dns, ntp, ssdp, snmp, etc. It doesn't need to be use in conjunction but it could. Like mentioned earlier, it doesn't need spoofing so any device could be part of it. Google already acknowledged through their vulnerability program that there is something interesting there and they are still assessing the risk/impact. They suggested me to start privately disclose this with some big players. I thought NANOG would be a good start. I guess they also need time and maybe partners to test and validate all this data. Cert-CC is also aware and they are also working out something on their side. I am in good faith here and time is not against us. I discover something new that I want to share properly and I am not here to make business. Sincerely, Jean St-Laurent On 16-12-22 08:21 AM, Tom Beecher wrote: > You're claiming to be able to generate more than 10 times as much traffic > as the largest DDoS ever seen in the wild whilst 3 months into a position > at a company that sells 'self-DDoS' services for testing purposes. > > In that absence of anything more than 'GUYZ THIS IS SERIOUS' , with no > technical details, you can surely understand the skepticism. > > > On Thu, Dec 22, 2016 at 5:45 AM, Jean | ddostest.me via NANOG < > nanog at nanog.org> wrote: > >> I admit that I have a lot of guts. >> >> Not sure who said that I am a booter or that I operate a booter. I fight >> booter since more than 5 years and who would be stupid enough to put his >> full name with full address to a respected network operators list? >> Definitely not me. >> >> I want to help and fix things and I am not the kind of person to break >> things. >> >> >> Jean >> >> >> On 16-12-22 03:46 AM, j.j.santanna at utwente.nl wrote: >> >>> Hi Jean, >>> >>> You are either naive or have a lot of guts to offer a Booter service in >>> one of the most respected network operators list. Man, as long as you use >>> amplifiers (third party services) or botnets your ?service? is illegal & >>> immoral. In case you use your own infrastructure or rent a legal (cloud) >>> infrastructure to provide your "service" it will not pay your costs. Not at >>> least by the price that you offer your service: 0, 13, 100 bucks. Even if >>> you have a legal/moral acceptable attack infrastructure, if you throw those >>> big attacks that you advertise will possibly take down many others >>> third-parties on the way. >>> >>> Sometimes you folks say that (mis)use amplifiers for ?testing? purpose is >>> not a problem because those services are open and publicly available on the >>> Internet. Come on? if I leave my car open with the key inside it doesn?t >>> give you the right to use my car to throw into a third party company. And >>> if you do, it is YOUR CRIME, not mine. >>> >>> I don?t need to explain why using botnets is illegal and immoral, right? >>> >>> Man, it is up to you decide between cyber crime and cyber security ( >>> https://www.europol.europa.eu/activities-services/public-aw >>> areness-and-prevention-guides/cyber-crime-vs-cyber-security- >>> what-will-you-choose). Now, we are also looking to you on >>> http://booterblacklist.com. Thanks! >>> >>> Cheers, >>> >>> Jair Santanna >>> >>> >>> >>> >>> On 22 Dec 2016, at 07:51, Alexander Lyamin >> r.net>> wrote: >>> >>> I am just trying to grasp what is similarity between networks on the list >>> and why it doesn't include, say NTT or Cogent. >>> >>> >>> >>> On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me >>> via NANOG < >>> nanog at nanog.org> wrote: >>> >>> Hello all, I'm a first time poster here and hope to follow all rules. >>> >>> I found a new way to amplify traffic that would generate really high >>> volume of traffic.+10Tbps >>> >>> ** There is no need for spoofing ** so any device in the world could >>> initiate a really big attack or be part of an attack. >>> >>> We talk about an amplification factor x100+. This mean that a single >>> computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. >>> Imagine what a botnet could do? >>> >>> The list of affected business is huge and I would like to privately >>> disclose the details to the Tier1 ISP as they are highly vulnerable. >>> >>> XO Comm >>> PSINET >>> Level 3 >>> Qwest >>> Windstream Comm >>> Eearthlink >>> MCI Comm/Verizon Buss >>> Comcast Cable Comm >>> AT&T >>> Sprint >>> >>> I know it's Christmas time and there is no rush in disclosing this but, it >>> could be a nice opportunity to meditate and shed some lights on this new >>> DDoS threat. We could start the real work in January. >>> >>> >>> If you are curious and you operate/manage one of the network mentioned >>> above, please write to me at tornaddos at ddostest.me>> ornaddos at ddostest.me> from your job email to >>> confirm the identity. I will then forward you the DDoS details. >>> >>> Best regards >>> >>> Jean St-Laurent >>> ddostest.me >>> 365 boul. Sir-Wilfrid-Laurier #202 >>> Beloeil, QC J3G 4T2 >>> >>> >>> >>> >>> -- >>> >>> Alexander Lyamin >>> >>> CEO | Qrator * Labs* >>> >>> office: 8-800-3333-LAB (522) >>> >>> mob: +7-916-9086122 >>> >>> skype: melanor9 >>> >>> mailto: la at qrator.net >>> >>> > From j.j.santanna at utwente.nl Thu Dec 22 11:01:23 2016 From: j.j.santanna at utwente.nl (j.j.santanna at utwente.nl) Date: Thu, 22 Dec 2016 11:01:23 +0000 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> Message-ID: <61D6C415-D8E1-4C74-99DE-36D072BF8539@utwente.nl> I am saying! As far as I understand you are offering DDoS attacks as a paid service, right? Some people would say that you offer DDoS for hire. What is the difference between your service and a Booter service. Only a ?validation" that your client is ?stress testing? him/herself does not make you legal. Sorry man but you can NOT claim yourself as a legal/moral acceptable stress tester if you misuse devices on the Internet, such as amplifiers, webshell, and botnets. Although you don?t consider yourself a Booter, you are one of them! I leave up to you the definition of stupid. Cheers, Jair Santanna jairsantanna.com On 22 Dec 2016, at 11:45, Jean | ddostest.me > wrote: I admit that I have a lot of guts. Not sure who said that I am a booter or that I operate a booter. I fight booter since more than 5 years and who would be stupid enough to put his full name with full address to a respected network operators list? Definitely not me. I want to help and fix things and I am not the kind of person to break things. Jean On 16-12-22 03:46 AM, j.j.santanna at utwente.nl wrote: Hi Jean, You are either naive or have a lot of guts to offer a Booter service in one of the most respected network operators list. Man, as long as you use amplifiers (third party services) or botnets your ?service? is illegal & immoral. In case you use your own infrastructure or rent a legal (cloud) infrastructure to provide your "service" it will not pay your costs. Not at least by the price that you offer your service: 0, 13, 100 bucks. Even if you have a legal/moral acceptable attack infrastructure, if you throw those big attacks that you advertise will possibly take down many others third-parties on the way. Sometimes you folks say that (mis)use amplifiers for ?testing? purpose is not a problem because those services are open and publicly available on the Internet. Come on? if I leave my car open with the key inside it doesn?t give you the right to use my car to throw into a third party company. And if you do, it is YOUR CRIME, not mine. I don?t need to explain why using botnets is illegal and immoral, right? Man, it is up to you decide between cyber crime and cyber security (https://www.europol.europa.eu/activities-services/public-awareness-and-prevention-guides/cyber-crime-vs-cyber-security-what-will-you-choose). Now, we are also looking to you on http://booterblacklist.com. Thanks! Cheers, Jair Santanna On 22 Dec 2016, at 07:51, Alexander Lyamin > wrote: I am just trying to grasp what is similarity between networks on the list and why it doesn't include, say NTT or Cogent. On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me via NANOG < nanog at nanog.org> wrote: Hello all, I'm a first time poster here and hope to follow all rules. I found a new way to amplify traffic that would generate really high volume of traffic.+10Tbps ** There is no need for spoofing ** so any device in the world could initiate a really big attack or be part of an attack. We talk about an amplification factor x100+. This mean that a single computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. Imagine what a botnet could do? The list of affected business is huge and I would like to privately disclose the details to the Tier1 ISP as they are highly vulnerable. XO Comm PSINET Level 3 Qwest Windstream Comm Eearthlink MCI Comm/Verizon Buss Comcast Cable Comm AT&T Sprint I know it's Christmas time and there is no rush in disclosing this but, it could be a nice opportunity to meditate and shed some lights on this new DDoS threat. We could start the real work in January. If you are curious and you operate/manage one of the network mentioned above, please write to me at tornaddos at ddostest.me from your job email to confirm the identity. I will then forward you the DDoS details. Best regards Jean St-Laurent ddostest.me 365 boul. Sir-Wilfrid-Laurier #202 Beloeil, QC J3G 4T2 -- Alexander Lyamin CEO | Qrator * Labs* office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net From nanog at ics-il.net Thu Dec 22 13:51:25 2016 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 22 Dec 2016 07:51:25 -0600 (CST) Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: <61D6C415-D8E1-4C74-99DE-36D072BF8539@utwente.nl> References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> <61D6C415-D8E1-4C74-99DE-36D072BF8539@utwente.nl> Message-ID: <188365876.2112.1482414685356.JavaMail.mhammett@ThunderFuck> Let's wait and see if his stated message of being here to discuss technical matters of the vulnerability with the aforementioned carriers bears anything out. If not, don the torches. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "j j santanna" To: jean at ddostest.me Cc: nanog at nanog.org Sent: Thursday, December 22, 2016 5:01:23 AM Subject: Re: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack I am saying! As far as I understand you are offering DDoS attacks as a paid service, right? Some people would say that you offer DDoS for hire. What is the difference between your service and a Booter service. Only a ?validation" that your client is ?stress testing? him/herself does not make you legal. Sorry man but you can NOT claim yourself as a legal/moral acceptable stress tester if you misuse devices on the Internet, such as amplifiers, webshell, and botnets. Although you don?t consider yourself a Booter, you are one of them! I leave up to you the definition of stupid. Cheers, Jair Santanna jairsantanna.com On 22 Dec 2016, at 11:45, Jean | ddostest.me > wrote: I admit that I have a lot of guts. Not sure who said that I am a booter or that I operate a booter. I fight booter since more than 5 years and who would be stupid enough to put his full name with full address to a respected network operators list? Definitely not me. I want to help and fix things and I am not the kind of person to break things. Jean On 16-12-22 03:46 AM, j.j.santanna at utwente.nl wrote: Hi Jean, You are either naive or have a lot of guts to offer a Booter service in one of the most respected network operators list. Man, as long as you use amplifiers (third party services) or botnets your ?service? is illegal & immoral. In case you use your own infrastructure or rent a legal (cloud) infrastructure to provide your "service" it will not pay your costs. Not at least by the price that you offer your service: 0, 13, 100 bucks. Even if you have a legal/moral acceptable attack infrastructure, if you throw those big attacks that you advertise will possibly take down many others third-parties on the way. Sometimes you folks say that (mis)use amplifiers for ?testing? purpose is not a problem because those services are open and publicly available on the Internet. Come on? if I leave my car open with the key inside it doesn?t give you the right to use my car to throw into a third party company. And if you do, it is YOUR CRIME, not mine. I don?t need to explain why using botnets is illegal and immoral, right? Man, it is up to you decide between cyber crime and cyber security (https://www.europol.europa.eu/activities-services/public-awareness-and-prevention-guides/cyber-crime-vs-cyber-security-what-will-you-choose). Now, we are also looking to you on http://booterblacklist.com. Thanks! Cheers, Jair Santanna On 22 Dec 2016, at 07:51, Alexander Lyamin > wrote: I am just trying to grasp what is similarity between networks on the list and why it doesn't include, say NTT or Cogent. On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me via NANOG < nanog at nanog.org> wrote: Hello all, I'm a first time poster here and hope to follow all rules. I found a new way to amplify traffic that would generate really high volume of traffic.+10Tbps ** There is no need for spoofing ** so any device in the world could initiate a really big attack or be part of an attack. We talk about an amplification factor x100+. This mean that a single computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. Imagine what a botnet could do? The list of affected business is huge and I would like to privately disclose the details to the Tier1 ISP as they are highly vulnerable. XO Comm PSINET Level 3 Qwest Windstream Comm Eearthlink MCI Comm/Verizon Buss Comcast Cable Comm AT&T Sprint I know it's Christmas time and there is no rush in disclosing this but, it could be a nice opportunity to meditate and shed some lights on this new DDoS threat. We could start the real work in January. If you are curious and you operate/manage one of the network mentioned above, please write to me at tornaddos at ddostest.me from your job email to confirm the identity. I will then forward you the DDoS details. Best regards Jean St-Laurent ddostest.me 365 boul. Sir-Wilfrid-Laurier #202 Beloeil, QC J3G 4T2 -- Alexander Lyamin CEO | Qrator * Labs* office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net From la at qrator.net Thu Dec 22 13:53:46 2016 From: la at qrator.net (Alexander Lyamin) Date: Thu, 22 Dec 2016 16:53:46 +0300 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: <188365876.2112.1482414685356.JavaMail.mhammett@ThunderFuck> References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> <61D6C415-D8E1-4C74-99DE-36D072BF8539@utwente.nl> <188365876.2112.1482414685356.JavaMail.mhammett@ThunderFuck> Message-ID: I just reviewed our data at http://radar.qrator.net provided network list. I am highly skeptical. On Thu, Dec 22, 2016 at 4:51 PM, Mike Hammett wrote: > Let's wait and see if his stated message of being here to discuss > technical matters of the vulnerability with the aforementioned carriers > bears anything out. If not, don the torches. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "j j santanna" > To: jean at ddostest.me > Cc: nanog at nanog.org > Sent: Thursday, December 22, 2016 5:01:23 AM > Subject: Re: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack > > I am saying! > > As far as I understand you are offering DDoS attacks as a paid service, > right? Some people would say that you offer DDoS for hire. What is the > difference between your service and a Booter service. Only a ?validation" > that your client is ?stress testing? him/herself does not make you legal. > Sorry man but you can NOT claim yourself as a legal/moral acceptable stress > tester if you misuse devices on the Internet, such as amplifiers, webshell, > and botnets. > > Although you don?t consider yourself a Booter, you are one of them! > > I leave up to you the definition of stupid. > > Cheers, > > Jair Santanna > jairsantanna.com > > > > On 22 Dec 2016, at 11:45, Jean | ddostest.me < > jean at ddostest.me> wrote: > > I admit that I have a lot of guts. > > Not sure who said that I am a booter or that I operate a booter. I fight > booter since more than 5 years and who would be stupid enough to put his > full name with full address to a respected network operators list? > Definitely not me. > > I want to help and fix things and I am not the kind of person to break > things. > > > Jean > > On 16-12-22 03:46 AM, j.j.santanna at utwente.nl j.j.santanna at utwente.nl> wrote: > Hi Jean, > > You are either naive or have a lot of guts to offer a Booter service in > one of the most respected network operators list. Man, as long as you use > amplifiers (third party services) or botnets your ?service? is illegal & > immoral. In case you use your own infrastructure or rent a legal (cloud) > infrastructure to provide your "service" it will not pay your costs. Not at > least by the price that you offer your service: 0, 13, 100 bucks. Even if > you have a legal/moral acceptable attack infrastructure, if you throw those > big attacks that you advertise will possibly take down many others > third-parties on the way. > > Sometimes you folks say that (mis)use amplifiers for ?testing? purpose is > not a problem because those services are open and publicly available on the > Internet. Come on? if I leave my car open with the key inside it doesn?t > give you the right to use my car to throw into a third party company. And > if you do, it is YOUR CRIME, not mine. > > I don?t need to explain why using botnets is illegal and immoral, right? > > Man, it is up to you decide between cyber crime and cyber security ( > https://www.europol.europa.eu/activities-services/public- > awareness-and-prevention-guides/cyber-crime-vs-cyber- > security-what-will-you-choose). Now, we are also looking to you on > http://booterblacklist.com. Thanks! > > Cheers, > > Jair Santanna > > > > > On 22 Dec 2016, at 07:51, Alexander Lyamin qrator.net>> wrote: > > I am just trying to grasp what is similarity between networks on the list > and why it doesn't include, say NTT or Cogent. > > > > On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me< > http://ddostest.me/> via NANOG < > nanog at nanog.org> wrote: > > Hello all, I'm a first time poster here and hope to follow all rules. > > I found a new way to amplify traffic that would generate really high > volume of traffic.+10Tbps > > ** There is no need for spoofing ** so any device in the world could > initiate a really big attack or be part of an attack. > > We talk about an amplification factor x100+. This mean that a single > computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. > Imagine what a botnet could do? > > The list of affected business is huge and I would like to privately > disclose the details to the Tier1 ISP as they are highly vulnerable. > > XO Comm > PSINET > Level 3 > Qwest > Windstream Comm > Eearthlink > MCI Comm/Verizon Buss > Comcast Cable Comm > AT&T > Sprint > > I know it's Christmas time and there is no rush in disclosing this but, it > could be a nice opportunity to meditate and shed some lights on this new > DDoS threat. We could start the real work in January. > > > If you are curious and you operate/manage one of the network mentioned > above, please write to me at tornaddos at ddostest.me ornaddos at ddostest.me> from your job email to > confirm the identity. I will then forward you the DDoS details. > > Best regards > > Jean St-Laurent > ddostest.me > 365 boul. Sir-Wilfrid-Laurier #202 > Beloeil, QC J3G 4T2 > > > > > -- > > Alexander Lyamin > > CEO | Qrator * Labs* > > office: 8-800-3333-LAB (522) > > mob: +7-916-9086122 > > skype: melanor9 > > mailto: la at qrator.net > > > -- Alexander Lyamin CEO | Qrator * Labs* office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net From la at qrator.net Thu Dec 22 14:11:49 2016 From: la at qrator.net (Alexander Lyamin) Date: Thu, 22 Dec 2016 17:11:49 +0300 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> Message-ID: On Thu, Dec 22, 2016 at 4:21 PM, Tom Beecher wrote: > > In that absence of anything more than 'GUYZ THIS IS SERIOUS' , with no > technical details, you can surely understand the skepticism. > > Exactly my thought. Tingling sensation "this is some kind of fraud". -- Alexander Lyamin CEO | Qrator * Labs* office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net From rdobbins at arbor.net Thu Dec 22 14:12:06 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 22 Dec 2016 21:12:06 +0700 Subject: [Tier1 ISP] : Vulnerable to a new DDoS amplification attack In-Reply-To: References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> Message-ID: <6AB83521-AFC3-4CBA-AD01-68E046CD64A3@arbor.net> On 22 Dec 2016, at 20:27, Jean | ddostest.me via NANOG wrote: > the already known Layer 4 amp DDoS like dns, ntp, ssdp, snmp These are layer-7 reflection/amplification attacks - i.e., application-layer - *not* layer-4. ----------------------------------- Roland Dobbins From nanog at ics-il.net Thu Dec 22 14:27:44 2016 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 22 Dec 2016 08:27:44 -0600 (CST) Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> <61D6C415-D8E1-4C74-99DE-36D072BF8539@utwente.nl> <188365876.2112.1482414685356.JavaMail.mhammett@ThunderFuck> Message-ID: <2030659116.2188.1482416862511.JavaMail.mhammett@ThunderFuck> Skepticism is of course warranted with such bold claims and little public information to back it up. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Alexander Lyamin" To: "Mike Hammett" Cc: "j j santanna" , "NANOG list" Sent: Thursday, December 22, 2016 7:53:46 AM Subject: Re: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack I just reviewed our data at http://radar.qrator.net provided network list. I am highly skeptical. On Thu, Dec 22, 2016 at 4:51 PM, Mike Hammett < nanog at ics-il.net > wrote: Let's wait and see if his stated message of being here to discuss technical matters of the vulnerability with the aforementioned carriers bears anything out. If not, don the torches. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "j j santanna" < j.j.santanna at utwente.nl > To: jean at ddostest.me Cc: nanog at nanog.org Sent: Thursday, December 22, 2016 5:01:23 AM Subject: Re: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack I am saying! As far as I understand you are offering DDoS attacks as a paid service, right? Some people would say that you offer DDoS for hire. What is the difference between your service and a Booter service. Only a ?validation" that your client is ?stress testing? him/herself does not make you legal. Sorry man but you can NOT claim yourself as a legal/moral acceptable stress tester if you misuse devices on the Internet, such as amplifiers, webshell, and botnets. Although you don?t consider yourself a Booter, you are one of them! I leave up to you the definition of stupid. Cheers, Jair Santanna jairsantanna.com < http://jairsantanna.com > On 22 Dec 2016, at 11:45, Jean | ddostest.me < http://ddostest.me > < jean at ddostest.me > wrote: I admit that I have a lot of guts. Not sure who said that I am a booter or that I operate a booter. I fight booter since more than 5 years and who would be stupid enough to put his full name with full address to a respected network operators list? Definitely not me. I want to help and fix things and I am not the kind of person to break things. Jean On 16-12-22 03:46 AM, j.j.santanna at utwente.nl wrote: Hi Jean, You are either naive or have a lot of guts to offer a Booter service in one of the most respected network operators list. Man, as long as you use amplifiers (third party services) or botnets your ?service? is illegal & immoral. In case you use your own infrastructure or rent a legal (cloud) infrastructure to provide your "service" it will not pay your costs. Not at least by the price that you offer your service: 0, 13, 100 bucks. Even if you have a legal/moral acceptable attack infrastructure, if you throw those big attacks that you advertise will possibly take down many others third-parties on the way. Sometimes you folks say that (mis)use amplifiers for ?testing? purpose is not a problem because those services are open and publicly available on the Internet. Come on? if I leave my car open with the key inside it doesn?t give you the right to use my car to throw into a third party company. And if you do, it is YOUR CRIME, not mine. I don?t need to explain why using botnets is illegal and immoral, right? Man, it is up to you decide between cyber crime and cyber security ( https://www.europol.europa.eu/activities-services/public-awareness-and-prevention-guides/cyber-crime-vs-cyber-security-what-will-you-choose ). Now, we are also looking to you on http://booterblacklist.com < http://booterblacklist.com/ >. Thanks! Cheers, Jair Santanna On 22 Dec 2016, at 07:51, Alexander Lyamin < la at qrator.net > wrote: I am just trying to grasp what is similarity between networks on the list and why it doesn't include, say NTT or Cogent. On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me < http://ddostest.me/ >< http://ddostest.me/ > via NANOG < nanog at nanog.org > wrote: Hello all, I'm a first time poster here and hope to follow all rules. I found a new way to amplify traffic that would generate really high volume of traffic.+10Tbps ** There is no need for spoofing ** so any device in the world could initiate a really big attack or be part of an attack. We talk about an amplification factor x100+. This mean that a single computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. Imagine what a botnet could do? The list of affected business is huge and I would like to privately disclose the details to the Tier1 ISP as they are highly vulnerable. XO Comm PSINET Level 3 Qwest Windstream Comm Eearthlink MCI Comm/Verizon Buss Comcast Cable Comm AT&T Sprint I know it's Christmas time and there is no rush in disclosing this but, it could be a nice opportunity to meditate and shed some lights on this new DDoS threat. We could start the real work in January. If you are curious and you operate/manage one of the network mentioned above, please write to me at tornaddos at ddostest.me from your job email to confirm the identity. I will then forward you the DDoS details. Best regards Jean St-Laurent ddostest.me < http://ddostest.me/ >< http://ddostest.me/ > 365 boul. Sir-Wilfrid-Laurier #202 Beloeil, QC J3G 4T2 -- Alexander Lyamin CEO | Qrator < http://qrator.net/ >* Labs* office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net -- Alexander Lyamin CEO | Qrator Labs office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net From beecher at beecher.cc Thu Dec 22 14:33:34 2016 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 22 Dec 2016 09:33:34 -0500 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> Message-ID: Aside from the 'that's not layer 4' point that's already been made, I feel obligated to point out that if you were advised to 'privately disclose to some big players', the NANOG list is pretty much the exact opposite of that. This is a very public list. My paranoid brain doesn't want to completely discount you ; but the onus is on you to provide proof. Are you willing to send me the details to this address if you're not willing to provide any specifics to the list? On Thu, Dec 22, 2016 at 8:27 AM, Jean | ddostest.me wrote: > I apologize for my previous email. > > After a second thought it might sound like it's a booter even though I > want to offer something else. > > I don't want the conversation shifting toward business when we talk about > a new DDoS technique that operate at Layer 3 with amplification power x100. > I disabled the "booter" service and will review this offline with my > lawyer. Thanks for pointing this out. > > Now back to this new DDoS technique. If it can amplify at Layer 3, it > could potentially be use in conjunction with the already known Layer 4 amp > DDoS like dns, ntp, ssdp, snmp, etc. It doesn't need to be use in > conjunction but it could. > > Like mentioned earlier, it doesn't need spoofing so any device could be > part of it. > > Google already acknowledged through their vulnerability program that there > is something interesting there and they are still assessing the > risk/impact. They suggested me to start privately disclose this with some > big players. I thought NANOG would be a good start. I guess they also need > time and maybe partners to test and validate all this data. > > Cert-CC is also aware and they are also working out something on their > side. > > I am in good faith here and time is not against us. I discover something > new that I want to share properly and I am not here to make business. > > > Sincerely, > Jean St-Laurent > > > On 16-12-22 08:21 AM, Tom Beecher wrote: > >> You're claiming to be able to generate more than 10 times as much traffic >> as the largest DDoS ever seen in the wild whilst 3 months into a position >> at a company that sells 'self-DDoS' services for testing purposes. >> >> In that absence of anything more than 'GUYZ THIS IS SERIOUS' , with no >> technical details, you can surely understand the skepticism. >> >> >> On Thu, Dec 22, 2016 at 5:45 AM, Jean | ddostest.me via NANOG < >> nanog at nanog.org> wrote: >> >> I admit that I have a lot of guts. >>> >>> Not sure who said that I am a booter or that I operate a booter. I fight >>> booter since more than 5 years and who would be stupid enough to put his >>> full name with full address to a respected network operators list? >>> Definitely not me. >>> >>> I want to help and fix things and I am not the kind of person to break >>> things. >>> >>> >>> Jean >>> >>> >>> On 16-12-22 03:46 AM, j.j.santanna at utwente.nl wrote: >>> >>> Hi Jean, >>>> >>>> You are either naive or have a lot of guts to offer a Booter service in >>>> one of the most respected network operators list. Man, as long as you >>>> use >>>> amplifiers (third party services) or botnets your ?service? is illegal & >>>> immoral. In case you use your own infrastructure or rent a legal >>>> (cloud) >>>> infrastructure to provide your "service" it will not pay your costs. >>>> Not at >>>> least by the price that you offer your service: 0, 13, 100 bucks. Even >>>> if >>>> you have a legal/moral acceptable attack infrastructure, if you throw >>>> those >>>> big attacks that you advertise will possibly take down many others >>>> third-parties on the way. >>>> >>>> Sometimes you folks say that (mis)use amplifiers for ?testing? purpose >>>> is >>>> not a problem because those services are open and publicly available on >>>> the >>>> Internet. Come on? if I leave my car open with the key inside it doesn?t >>>> give you the right to use my car to throw into a third party company. >>>> And >>>> if you do, it is YOUR CRIME, not mine. >>>> >>>> I don?t need to explain why using botnets is illegal and immoral, right? >>>> >>>> Man, it is up to you decide between cyber crime and cyber security ( >>>> https://www.europol.europa.eu/activities-services/public-aw >>>> areness-and-prevention-guides/cyber-crime-vs-cyber-security- >>>> what-will-you-choose). Now, we are also looking to you on >>>> http://booterblacklist.com. Thanks! >>>> >>>> Cheers, >>>> >>>> Jair Santanna >>>> >>>> >>>> >>>> >>>> On 22 Dec 2016, at 07:51, Alexander Lyamin >>> la at qrato >>>> r.net>> wrote: >>>> >>>> I am just trying to grasp what is similarity between networks on the >>>> list >>>> and why it doesn't include, say NTT or Cogent. >>>> >>>> >>>> >>>> On Wed, Dec 21, 2016 at 7:05 PM, Jean | ddostest.me>>> > >>>> via NANOG < >>>> nanog at nanog.org> wrote: >>>> >>>> Hello all, I'm a first time poster here and hope to follow all rules. >>>> >>>> I found a new way to amplify traffic that would generate really high >>>> volume of traffic.+10Tbps >>>> >>>> ** There is no need for spoofing ** so any device in the world could >>>> initiate a really big attack or be part of an attack. >>>> >>>> We talk about an amplification factor x100+. This mean that a single >>>> computer with 1 Gbps outgoing bandwidth would generate a 100 Gbps DDoS. >>>> Imagine what a botnet could do? >>>> >>>> The list of affected business is huge and I would like to privately >>>> disclose the details to the Tier1 ISP as they are highly vulnerable. >>>> >>>> XO Comm >>>> PSINET >>>> Level 3 >>>> Qwest >>>> Windstream Comm >>>> Eearthlink >>>> MCI Comm/Verizon Buss >>>> Comcast Cable Comm >>>> AT&T >>>> Sprint >>>> >>>> I know it's Christmas time and there is no rush in disclosing this but, >>>> it >>>> could be a nice opportunity to meditate and shed some lights on this new >>>> DDoS threat. We could start the real work in January. >>>> >>>> >>>> If you are curious and you operate/manage one of the network mentioned >>>> above, please write to me at tornaddos at ddostest.me>>> ornaddos at ddostest.me> from your job email to >>>> confirm the identity. I will then forward you the DDoS details. >>>> >>>> Best regards >>>> >>>> Jean St-Laurent >>>> ddostest.me >>>> 365 boul. Sir-Wilfrid-Laurier #202 >>>> Beloeil, QC J3G 4T2 >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Alexander Lyamin >>>> >>>> CEO | Qrator * Labs* >>>> >>>> office: 8-800-3333-LAB (522) >>>> >>>> mob: +7-916-9086122 >>>> >>>> skype: melanor9 >>>> >>>> mailto: la at qrator.net >>>> >>>> >>>> >> From jfmezei_nanog at vaxination.ca Thu Dec 22 14:59:22 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 22 Dec 2016 09:59:22 -0500 Subject: Canada joins the 21st century ! Message-ID: <585BEA4A.7050809@vaxination.ca> This is more of an FYI. Yesterday, the CRTC released a big decision on broadband. In 2011, the same process resulted in CRTC to not declare the Internet as "basic service" and to set speed goals to 1990s 5/1. Yesterday, the CRTC declared the Internet to be a basic service (which enables additional regulatory powers) and set speed goals to 50/10. Note that this is not a definition of broadband as the FCC had done, it one of many criteria that will be weighted when proposal to get funding is received. But hopefully, it means the end of deployment of DSL. Also, as a result of declaring it a basic service, the CRTC enables powers to force ISPs to contrtibute to a fund that will be used to subsidize deplooyment in rural areas. It plans to collect $100 million/year, increasing by $25m each year to top at $200m which will then be distributed to companies who deploy internet to unserved areas. By setting the speed standard to 50/10, it basically marks any territory not served by cableco as underserved since telco's copper can't reliably deliver those speeds. Nothing happens for now because a "follow up" process is needed to decide how the funding mechanism will work (what portions of a companies revenues are counted to calculated its mandated contribution to fund) and how the process of bidding for subsidies will work. That could take 1 to 2 years. Also in the decision is the phasing out of the equivalent programme for POTS which saw telephone deployed everywhere. The difference is that the POTS program had an "obligation to serve" whereas the internet doesn't. From math at sizone.org Thu Dec 22 16:04:14 2016 From: math at sizone.org (Ken Chase) Date: Thu, 22 Dec 2016 11:04:14 -0500 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> Message-ID: <20161222160414.GS2029@sizone.org> Maybe he's found what's already known and posted 2 months ago (and every 2 months?) on nanog, the TCP 98,000x amplifier (which is a little higher than 100x), among dozens of misbehaving devices, all >200x amp. https://www.usenix.org/system/files/conference/woot14/woot14-kuhrer.pdf (Table 1's 'total load risk', (not calculated; Im using potential #hosts * amp factor) shows that each protocol listed curiously all have similar values, within 40%. Little too curious, in fact. I'd expect distribution across a few magnitudes.) /kc -- Ken Chase - math at sizone.org Guelph Canada From blake at ispn.net Thu Dec 22 16:32:21 2016 From: blake at ispn.net (Blake Hudson) Date: Thu, 22 Dec 2016 10:32:21 -0600 Subject: Canada joins the 21st century ! In-Reply-To: <585BEA4A.7050809@vaxination.ca> References: <585BEA4A.7050809@vaxination.ca> Message-ID: Jean-Francois Mezei wrote on 12/22/2016 8:59 AM: > ... > > Yesterday, the CRTC declared the Internet to be a basic service (which > enables additional regulatory powers) and set speed goals to 50/10. > > Note that this is not a definition of broadband as the FCC had done, it > one of many criteria that will be weighted when proposal to get funding > is received. But hopefully, it means the end of deployment of DSL. > > ... Some rural areas in the US are seeing either VDSL2 or bonded DSL deployments which do push the capabilities available via copper to the home deployments. Having operated cable, DSL, and fiber networks, I can say that cable and DSL have managed to stay relevant a lot longer than I expected. I also think it's a bit disingenuous to say that cable provider meets the 50/10 standard and DSL provider doesn't when a hypothetical cable plant might provide 1Gbps x 72Mbps of last mile bandwidth shared between 100+ subscribers and DSL plant might provide 20Mbps x 1.5Mbps dedicated to each subscriber circuit. In this example, the worst case for the cable plant is 10Mx768K per subscriber (note, this doesn't meet the specified goal) & the DSL plant is 20Mx1.5M per subscriber (twice the speed, but also doesn't meet the specified goal). In other words, sometimes the cable subscribers might experience faster speeds than DSL subscribers, sometimes they might experience slower speeds. The DSL subscribers would see consistent speeds. If a provider's deployment model provides "up to" the specified 50/10M, but subscribers see lower than these rates, then I would argue that the provider hasn't met the goal. While a cable provider could engineer their plant to dedicate 50/10 bandwidth per subscriber, this is not done today and will not be done in the near future because it isn't profitable (whether its necessary is another discussion). This seems to be profitable in FTTH and vDSL2 deployments because providers are exceeding these goals today in the US. Both cable and DSL technologies have managed to stay relevant longer than I expected because each seem to have pros, including the ability to utilize an existing infrastructure. I don't see either technology dying immediately, and can imagine that vendors may yet be able to eek out more performance from the existing infrastructure, but I do see more future potential using fiber to the premises infrastructure. From bill at herrin.us Thu Dec 22 16:48:14 2016 From: bill at herrin.us (William Herrin) Date: Thu, 22 Dec 2016 11:48:14 -0500 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: <20161222160414.GS2029@sizone.org> References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> <20161222160414.GS2029@sizone.org> Message-ID: On Thu, Dec 22, 2016 at 11:04 AM, Ken Chase wrote: > Maybe he's found what's already known and posted 2 months ago (and every 2 months?) > on nanog, the TCP 98,000x amplifier (which is a little higher than 100x), among > dozens of misbehaving devices, all >200x amp. > > https://www.usenix.org/system/files/conference/woot14/woot14-kuhrer.pdf Hi Ken, He said, "There is no need for spoofing " so it wouldn't be that one. Jean, Respectfully: you're not well known to us as having identified earth shattering vulnerabilities in the past. We hear about utterly unimportant "priority one" events every single day, so without enough information to assess whether you're looking at is something new, important or even possible within our various architectures, few of us will be inclined to take you seriously. We're all too familiar with the consequence of giving credence to people who say "believe me" instead of offering verifiable fact. I respect that you're trying to help, but "I have something important to tell you, please contact me off list" is not the way to do that. And if it turns out we should have listened and kept this secret as long as possible, well, that's on us. ;) Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From beecher at beecher.cc Thu Dec 22 16:56:34 2016 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 22 Dec 2016 11:56:34 -0500 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> <20161222160414.GS2029@sizone.org> Message-ID: Jean sent me details. I won't share the link or password to it based on his request, but he hasn't found anything new, and it's not even amplification at all. What he did was send 1500 byte ICMP packets with a max TTL at an IP address that is not reachable due to a routing loop. No amplification is occurring ; it's just the same packets hanging around longer looking for free food because of the TTL. I think he _assumed_ amplification was happening because link utilization between his lab routers doing the looping was increasing. Totally expected when you're using --flood and in a lab environment where the TTL entering the loop is still above 250. :) On Thu, Dec 22, 2016 at 11:48 AM, William Herrin wrote: > On Thu, Dec 22, 2016 at 11:04 AM, Ken Chase wrote: > > Maybe he's found what's already known and posted 2 months ago (and every > 2 months?) > > on nanog, the TCP 98,000x amplifier (which is a little higher than > 100x), among > > dozens of misbehaving devices, all >200x amp. > > > > https://www.usenix.org/system/files/conference/woot14/woot14-kuhrer.pdf > > Hi Ken, > > He said, "There is no need for spoofing " so it wouldn't be that one. > > > Jean, > > Respectfully: you're not well known to us as having identified earth > shattering vulnerabilities in the past. We hear about utterly > unimportant "priority one" events every single day, so without enough > information to assess whether you're looking at is something new, > important or even possible within our various architectures, few of us > will be inclined to take you seriously. > > We're all too familiar with the consequence of giving credence to > people who say "believe me" instead of offering verifiable fact. > > I respect that you're trying to help, but "I have something important > to tell you, please contact me off list" is not the way to do that. > > And if it turns out we should have listened and kept this secret as > long as possible, well, that's on us. ;) > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > From rdobbins at arbor.net Thu Dec 22 17:04:03 2016 From: rdobbins at arbor.net (Roland Dobbins) Date: Fri, 23 Dec 2016 00:04:03 +0700 Subject: [Tier1 ISP] : Vulnerable to a new DDoS amplification attack In-Reply-To: References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> <20161222160414.GS2029@sizone.org> Message-ID: <5776BF71-B723-44E7-AB31-0B9CEF79AFA1@arbor.net> On 22 Dec 2016, at 23:56, Tom Beecher wrote: > What he did was send 1500 byte ICMP packets with a max TTL at an IP > address that is not reachable due to a routing loop. Same here. Here's some context I sent him: Note related discussion of mitigation tactics here (e.g., TTL-based filtering via tACLs): ----------------------------------- Roland Dobbins From la at qrator.net Thu Dec 22 17:09:15 2016 From: la at qrator.net (Alexander Lyamin) Date: Thu, 22 Dec 2016 20:09:15 +0300 Subject: [Tier1 ISP]: Vulnerable to a new DDoS amplification attack In-Reply-To: References: <04dba92b-c3cb-bbed-809b-6085da7dbb46@ddostest.me> <7D38F931-ED6F-4ED6-8D5A-14E130D0A78B@utwente.nl> <692a6db8-18aa-83c2-f6b4-e7660b054f49@ddostest.me> <20161222160414.GS2029@sizone.org> Message-ID: Whoa. Default route loop, thats definitely new ;) Protip: always do prior works research. On Thu, Dec 22, 2016 at 7:56 PM, Tom Beecher wrote: > Jean sent me details. I won't share the link or password to it based on his > request, but he hasn't found anything new, and it's not even amplification > at all. > > What he did was send 1500 byte ICMP packets with a max TTL at an IP address > that is not reachable due to a routing loop. No amplification is occurring > ; it's just the same packets hanging around longer looking for free food > because of the TTL. > > I think he _assumed_ amplification was happening because link utilization > between his lab routers doing the looping was increasing. Totally expected > when you're using --flood and in a lab environment where the TTL entering > the loop is still above 250. :) > > On Thu, Dec 22, 2016 at 11:48 AM, William Herrin wrote: > > > On Thu, Dec 22, 2016 at 11:04 AM, Ken Chase wrote: > > > Maybe he's found what's already known and posted 2 months ago (and > every > > 2 months?) > > > on nanog, the TCP 98,000x amplifier (which is a little higher than > > 100x), among > > > dozens of misbehaving devices, all >200x amp. > > > > > > https://www.usenix.org/system/files/conference/woot14/ > woot14-kuhrer.pdf > > > > Hi Ken, > > > > He said, "There is no need for spoofing " so it wouldn't be that one. > > > > > > Jean, > > > > Respectfully: you're not well known to us as having identified earth > > shattering vulnerabilities in the past. We hear about utterly > > unimportant "priority one" events every single day, so without enough > > information to assess whether you're looking at is something new, > > important or even possible within our various architectures, few of us > > will be inclined to take you seriously. > > > > We're all too familiar with the consequence of giving credence to > > people who say "believe me" instead of offering verifiable fact. > > > > I respect that you're trying to help, but "I have something important > > to tell you, please contact me off list" is not the way to do that. > > > > And if it turns out we should have listened and kept this secret as > > long as possible, well, that's on us. ;) > > > > Regards, > > Bill Herrin > > > > > > > > -- > > William Herrin ................ herrin at dirtside.com bill at herrin.us > > Owner, Dirtside Systems ......... Web: > > > -- Alexander Lyamin CEO | Qrator * Labs* office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net From ask at develooper.com Fri Dec 23 00:04:54 2016 From: ask at develooper.com (=?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?=) Date: Thu, 22 Dec 2016 16:04:54 -0800 Subject: Recent NTP pool traffic increase (update) In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <1c45fa7a2425045d30efb3623bbe3d5a@nuclearcat.com> <07c6752a5396d8d99d11dfca131b8155@nuclearcat.com> Message-ID: <3DA4CBC1-CABD-4992-8C05-3629CCAC19B8@develooper.com> Hello, Those servers aren?t (and have never been) part of the NTP Pool - https://www.ntppool.org/en/ If they were you could remove them from the system and over the next hours, days and months the traffic would go away. We also have features to change the relative amount of clients you get (to just get less queries instead of withdrawing from the pool altogether). Anyway, it looks like your IPs are listed on support.ntp.org as ?public servers?, so removing them from there would be step 1. However there?s no working mechanism for you to tell the clients that they should go away after they?ve hard coded your IP in their configuration. (That?s the point of the NTP Pool system really, to let you offer a public service and have a avenue to stop doing it, too). support.ntp.org appears to be down, but your IPs are listed on the site according to a Google search: https://www.google.com/search?q=133.100.9.2+ntp Ask > On Dec 21, 2016, at 7:13 PM, FUJIMURA Sho wrote: > > Hello. > > I operate the public NTP Service as 133.100.9.2 > and 133.100.11.8 at Fukuoka University, Japan. > I have a lot of trouble with too much NTP traffic from > many routers which 133.100.9.2 as default setting of NTP > has been set like Tenda or LB-Link etc. > So, although I'd like to contact Firmware developpers of these company > and would like them to change the default settins, > is there the person knowing the contact information? > > -- > Sho FUJIMURA > Information Technology Center, Fukuoka University. > 8-19-1, Nanakuma, Jyonan-ku, Fukuoka, 8140180, Japan From ask at develooper.com Fri Dec 23 00:11:09 2016 From: ask at develooper.com (=?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?=) Date: Thu, 22 Dec 2016 16:11:09 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> References: <20161217175455.30107c37@spidey.rellim.com> <70f7ad37-06b3-e238-9a2f-3b35adcb4068@shaw.ca> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> Message-ID: <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> > On Dec 20, 2016, at 8:02 PM, Harlan Stenn wrote: > >> On 12/20/16 7:27 PM, Laurent Dumont wrote: >> To be honest, the fact that NTP is still something managed by volunteers >> and not a regulated entity (a bit like DNS) is mind boggling. > > Time *is* managed by regulated entities - the National Time Labs. That was pretty clearly not what Laurent was talking about. > And Network Time Foundation's NTP Project (the reference implementation > for NTP) could do lots more if we had a useful budget. > > Folks pay money for DNS registrations. There's no revenue stream around > "time". > > Help us get enough support to NTF, and we'll have the staff and > infrastructure to do more for folks. What does the NTF have to do with the NTP Pool (or the ?recent NTP pool traffic increase?)? The NTP Pool is run by volunteers, as you very well know. Both the management and DNS system and the thousands of people who contribute their NTP service to the system. (And we manage on a pretty scarce budget). Ask -- http://www.askask.com From stenn at nwtime.org Fri Dec 23 01:05:58 2016 From: stenn at nwtime.org (Harlan Stenn) Date: Thu, 22 Dec 2016 17:05:58 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> Message-ID: <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> On 12/22/16 4:11 PM, Ask Bj?rn Hansen wrote: >> On Dec 20, 2016, at 8:02 PM, Harlan Stenn >> wrote: >> >>> On 12/20/16 7:27 PM, Laurent Dumont wrote: To be honest, the fact >>> that NTP is still something managed by volunteers and not a >>> regulated entity (a bit like DNS) is mind boggling. >> >> Time *is* managed by regulated entities - the National Time Labs. > > That was pretty clearly not what Laurent was talking about. Not all that clearly, at least to me. >> And Network Time Foundation's NTP Project (the reference >> implementation for NTP) could do lots more if we had a useful >> budget. >> >> Folks pay money for DNS registrations. There's no revenue stream >> around "time". >> >> Help us get enough support to NTF, and we'll have the staff and >> infrastructure to do more for folks. > > What does the NTF have to do with the NTP Pool (or the ?recent NTP > pool traffic increase?)? Nothing. But it has to do with companies putting NTP into their products. When they do this with problematic configurations, it causes trouble. In this case, it was trouble for the Pool project. The NTP Pool project certainly isn't the place to solve this issue. > The NTP Pool is run by volunteers, as you very well know. Both the > management and DNS system and the thousands of people who contribute > their NTP service to the system. (And we manage on a pretty scarce > budget). What's your point? This sort of misconfiguration will happen and the NTP Pool Project clearly isn't the place to solve this problem overall. It *is* something NTF is in a position to address. And we're almost exclusively an overstretched volunteer organization, too, as you very well know. Do we have different goals around this issue? -- Harlan Stenn http://networktimefoundation.org - be a member! From royce at techsolvency.com Fri Dec 23 01:25:40 2016 From: royce at techsolvency.com (Royce Williams) Date: Thu, 22 Dec 2016 16:25:40 -0900 Subject: Recent NTP pool traffic increase In-Reply-To: <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> References: <20161217175455.30107c37@spidey.rellim.com> <20161219205556.GA25715@32k.org> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> Message-ID: On Thu, Dec 22, 2016 at 4:05 PM, Harlan Stenn wrote: > This sort of misconfiguration will happen and the NTP Pool Project > clearly isn't the place to solve this problem overall. It *is* > something NTF is in a position to address. Harlan, could you be more specific about how NTF can address this? Would it require modification of the NTP protocol, or something else? Royce From stenn at nwtime.org Fri Dec 23 02:38:10 2016 From: stenn at nwtime.org (Harlan Stenn) Date: Thu, 22 Dec 2016 18:38:10 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> Message-ID: <0a425873-650b-f965-46fa-2eafa94dd64b@nwtime.org> On 12/22/16 5:25 PM, Royce Williams wrote: > On Thu, Dec 22, 2016 at 4:05 PM, Harlan Stenn wrote: > >> This sort of misconfiguration will happen and the NTP Pool Project >> clearly isn't the place to solve this problem overall. It *is* >> something NTF is in a position to address. > > Harlan, could you be more specific about how NTF can address this? > Would it require modification of the NTP protocol, or something else? Network Time Foundation has two projects to directly help here. One is a Certification and Compliance program. The other is a project to analyze/produce BCP-compliant ntp.conf files. Due to limited resources we're making slow progress on each of these. That's the backwards way of saying we can make much more useful progress on these and other issues (like the development of NTPv5 and the General Timestamp API) if we can get useful support. With more support we can also make more pool servers available. -- Harlan Stenn http://networktimefoundation.org - be a member! From admin at coldnorthadmin.com Fri Dec 23 04:31:08 2016 From: admin at coldnorthadmin.com (Laurent Dumont) Date: Thu, 22 Dec 2016 23:31:08 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> References: <20161217175455.30107c37@spidey.rellim.com> <20161219154911.Horde.3gd3oeF2oc4iYUIoPf37uAH@mail.drown.org> <6f6c19f9-98a2-257f-0299-45d2765870df@coldnorthadmin.com> <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> Message-ID: <4ef1d708-5302-15df-23fb-b942f1651af1@coldnorthadmin.com> Sorry if I wasn't being clear. What I mostly meant is that there should be a regulated, industry-wide effort in order to provide a stable and active pool program. With the current models, a protocol that is widely used by commercial devices is being supported by the time and effort of volunteers around the world. Initiative like the NTF and the Pool program are awesome, but I believe that NTP is something that shouldn't relegated to the wayside as the internet continues to evolve. Reading a bit more, NTF could be "upgraded" into a more official role too. I'm just a bit puzzled that this entire mixup actually happened with the modern internet. Laurent On 12/22/2016 08:05 PM, Harlan Stenn wrote: > On 12/22/16 4:11 PM, Ask Bj?rn Hansen wrote: >>> On Dec 20, 2016, at 8:02 PM, Harlan Stenn >>> wrote: >>> >>>> On 12/20/16 7:27 PM, Laurent Dumont wrote: To be honest, the fact >>>> that NTP is still something managed by volunteers and not a >>>> regulated entity (a bit like DNS) is mind boggling. >>> Time *is* managed by regulated entities - the National Time Labs. >> That was pretty clearly not what Laurent was talking about. > Not all that clearly, at least to me. > >>> And Network Time Foundation's NTP Project (the reference >>> implementation for NTP) could do lots more if we had a useful >>> budget. >>> >>> Folks pay money for DNS registrations. There's no revenue stream >>> around "time". >>> >>> Help us get enough support to NTF, and we'll have the staff and >>> infrastructure to do more for folks. >> What does the NTF have to do with the NTP Pool (or the ?recent NTP >> pool traffic increase?)? > Nothing. But it has to do with companies putting NTP into their > products. When they do this with problematic configurations, it causes > trouble. In this case, it was trouble for the Pool project. > > The NTP Pool project certainly isn't the place to solve this issue. > >> The NTP Pool is run by volunteers, as you very well know. Both the >> management and DNS system and the thousands of people who contribute >> their NTP service to the system. (And we manage on a pretty scarce >> budget). > What's your point? > > This sort of misconfiguration will happen and the NTP Pool Project > clearly isn't the place to solve this problem overall. It *is* > something NTF is in a position to address. > > And we're almost exclusively an overstretched volunteer organization, > too, as you very well know. > > Do we have different goals around this issue? > From randy at psg.com Fri Dec 23 05:17:34 2016 From: randy at psg.com (Randy Bush) Date: Fri, 23 Dec 2016 14:17:34 +0900 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: <28246.1482385382@turing-police.cc.vt.edu> References: <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> <20161222004941.GP2029@sizone.org> <28246.1482385382@turing-police.cc.vt.edu> Message-ID: >> "If it's a politically-generated thing I'll have to deal with at an >> operational level, it's on topic." > Hmm.. works for me. and do not omit the amplification attack of endless rinse repeat of self-righteous pontification of what people should and should not post randy From large.hadron.collider at gmx.com Fri Dec 23 05:44:56 2016 From: large.hadron.collider at gmx.com (Large Hadron Collider) Date: Thu, 22 Dec 2016 21:44:56 -0800 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: References: <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> <20161222004941.GP2029@sizone.org> <28246.1482385382@turing-police.cc.vt.edu> Message-ID: i mind not one iota to store some on my computer but it won't be accessible because i don't want to publish it until i can get a dedicated server On 2016-12-22 09:17 PM, Randy Bush wrote: >>> "If it's a politically-generated thing I'll have to deal with at an >>> operational level, it's on topic." >> Hmm.. works for me. > and do not omit the amplification attack of endless rinse repeat of > self-righteous pontification of what people should and should not post > > randy -- These ads are used to support jjovereats' sites. From david at zeromail.us Fri Dec 23 06:47:50 2016 From: david at zeromail.us (David S.) Date: Fri, 23 Dec 2016 13:47:50 +0700 Subject: Trouble connecting to wechat.com Message-ID: Hi, Is anyone having trouble connecting to wechat? Our network can't reach wechat.com and seems was blocked by firewall. I tried to contact their hostmaster and not replied yet. Here is the traceroute from our network: Tracing route to wechat.com [203.205.147.173] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 103.58.160.25 2 <1 ms <1 ms <1 ms 103.58.160.6 3 <1 ms <1 ms <1 ms 10.20.0.1 4 <1 ms <1 ms <1 ms 10.58.160.1 5 16 ms 15 ms 15 ms 124.195.38.8 6 55 ms 54 ms 54 ms 119.27.63.70 7 55 ms 55 ms 55 ms 10.200.174.114 8 55 ms 55 ms 55 ms 10.228.119.38 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. Best regards, David S. ------------------------------------------------ e. david at zeromail.us w. pnyet.web.id p. 087881216110 From nanog at ics-il.net Fri Dec 23 13:18:49 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 23 Dec 2016 07:18:49 -0600 (CST) Subject: Canada joins the 21st century ! In-Reply-To: <585BEA4A.7050809@vaxination.ca> References: <585BEA4A.7050809@vaxination.ca> Message-ID: <1490299301.5631.1482499128416.JavaMail.mhammett@ThunderFuck> The government getting involved with the Internet rarely goes well. The FCC is a shining example of how to usually do it wrong. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Jean-Francois Mezei" To: Nanog at nanog.org Sent: Thursday, December 22, 2016 8:59:22 AM Subject: Canada joins the 21st century ! This is more of an FYI. Yesterday, the CRTC released a big decision on broadband. In 2011, the same process resulted in CRTC to not declare the Internet as "basic service" and to set speed goals to 1990s 5/1. Yesterday, the CRTC declared the Internet to be a basic service (which enables additional regulatory powers) and set speed goals to 50/10. Note that this is not a definition of broadband as the FCC had done, it one of many criteria that will be weighted when proposal to get funding is received. But hopefully, it means the end of deployment of DSL. Also, as a result of declaring it a basic service, the CRTC enables powers to force ISPs to contrtibute to a fund that will be used to subsidize deplooyment in rural areas. It plans to collect $100 million/year, increasing by $25m each year to top at $200m which will then be distributed to companies who deploy internet to unserved areas. By setting the speed standard to 50/10, it basically marks any territory not served by cableco as underserved since telco's copper can't reliably deliver those speeds. Nothing happens for now because a "follow up" process is needed to decide how the funding mechanism will work (what portions of a companies revenues are counted to calculated its mandated contribution to fund) and how the process of bidding for subsidies will work. That could take 1 to 2 years. Also in the decision is the phasing out of the equivalent programme for POTS which saw telephone deployed everywhere. The difference is that the POTS program had an "obligation to serve" whereas the internet doesn't. From oliver.oboyle at gmail.com Fri Dec 23 14:07:57 2016 From: oliver.oboyle at gmail.com (Oliver O'Boyle) Date: Fri, 23 Dec 2016 09:07:57 -0500 Subject: Canada joins the 21st century ! In-Reply-To: <1490299301.5631.1482499128416.JavaMail.mhammett@ThunderFuck> References: <585BEA4A.7050809@vaxination.ca> <1490299301.5631.1482499128416.JavaMail.mhammett@ThunderFuck> Message-ID: Awesome, some maybe in 5 years we'll see the speeds we should have seen 20 years earlier! Can't wait! On Fri, Dec 23, 2016 at 8:18 AM, Mike Hammett wrote: > The government getting involved with the Internet rarely goes well. The > FCC is a shining example of how to usually do it wrong. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Jean-Francois Mezei" > To: Nanog at nanog.org > Sent: Thursday, December 22, 2016 8:59:22 AM > Subject: Canada joins the 21st century ! > > This is more of an FYI. > > Yesterday, the CRTC released a big decision on broadband. In 2011, the > same process resulted in CRTC to not declare the Internet as "basic > service" and to set speed goals to 1990s 5/1. > > Yesterday, the CRTC declared the Internet to be a basic service (which > enables additional regulatory powers) and set speed goals to 50/10. > > Note that this is not a definition of broadband as the FCC had done, it > one of many criteria that will be weighted when proposal to get funding > is received. But hopefully, it means the end of deployment of DSL. > > > Also, as a result of declaring it a basic service, the CRTC enables > powers to force ISPs to contrtibute to a fund that will be used to > subsidize deplooyment in rural areas. > > It plans to collect $100 million/year, increasing by $25m each year to > top at $200m which will then be distributed to companies who deploy > internet to unserved areas. > > By setting the speed standard to 50/10, it basically marks any territory > not served by cableco as underserved since telco's copper can't reliably > deliver those speeds. > > > Nothing happens for now because a "follow up" process is needed to > decide how the funding mechanism will work (what portions of a companies > revenues are counted to calculated its mandated contribution to fund) > and how the process of bidding for subsidies will work. That could take > 1 to 2 years. > > Also in the decision is the phasing out of the equivalent programme for > POTS which saw telephone deployed everywhere. The difference is that the > POTS program had an "obligation to serve" whereas the internet doesn't. > > -- :o@> From sethm at rollernet.us Fri Dec 23 15:37:10 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 23 Dec 2016 07:37:10 -0800 Subject: Canada joins the 21st century ! In-Reply-To: <585BEA4A.7050809@vaxination.ca> References: <585BEA4A.7050809@vaxination.ca> Message-ID: <6c55706b-0ad6-60e8-128d-5eecaefe01bd@rollernet.us> On 12/22/16 6:59 AM, Jean-Francois Mezei wrote: > > Nothing happens for now because a "follow up" process is needed to > decide how the funding mechanism will work (what portions of a companies > revenues are counted to calculated its mandated contribution to fund) > and how the process of bidding for subsidies will work. That could take > 1 to 2 years. It would certainly suck to be an ISP in Canada and be forced to fund your competitors. Or does Canada not have any small privately run ISPs like we do in the US? ~Seth From jfmezei_nanog at vaxination.ca Fri Dec 23 16:11:25 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 23 Dec 2016 11:11:25 -0500 Subject: Canada joins the 21st century ! In-Reply-To: <6c55706b-0ad6-60e8-128d-5eecaefe01bd@rollernet.us> References: <585BEA4A.7050809@vaxination.ca> <6c55706b-0ad6-60e8-128d-5eecaefe01bd@rollernet.us> Message-ID: <585D4CAD.8080709@vaxination.ca> On 2016-12-23 10:37, Seth Mattinen wrote: > It would certainly suck to be an ISP in Canada and be forced to fund > your competitors. Or does Canada not have any small privately run ISPs > like we do in the US? We not only have smaller ISPs, but also a wholesale framework where ISPs can purchase access to last mile from the incumbents (telco and cable). The current plan (which will be defined in a subsequent proceeding) calls for any ISPs with more than 10 million in revenues to contribute to the fund, the amount being a percentage of their revenues. The percentage will be adjusted annually to cause contributions to the fund to total the desired amount ($100 million on year 1, increasing by $25m until iut reaches $200). And yeah, this means ISPs contribute money which will be used by a competitor to deploy in rural areas. Of course, since we're talking about billions to get all Canadians connected, this is peanuts. From cscora at apnic.net Fri Dec 23 18:01:46 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Dec 2016 04:01:46 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20161223180146.705AD8BD36@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 24 Dec, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 626295 Prefixes after maximum aggregation (per Origin AS): 221402 Deaggregation factor: 2.83 Unique aggregates announced (without unneeded subnets): 303816 Total ASes present in the Internet Routing Table: 55496 Prefixes per ASN: 11.29 Origin-only ASes present in the Internet Routing Table: 36274 Origin ASes announcing only one prefix: 15209 Transit ASes present in the Internet Routing Table: 6547 Transit-only ASes present in the Internet Routing Table: 170 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 38 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 58 Unregistered ASNs in the Routing Table: 19 Number of 32-bit ASNs allocated by the RIRs: 16676 Number of 32-bit ASNs visible in the Routing Table: 12675 Prefixes from 32-bit ASNs in the Routing Table: 51879 Number of bogon 32-bit ASNs visible in the Routing Table: 627 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 385 Number of addresses announced to Internet: 2833553892 Equivalent to 168 /8s, 228 /16s and 153 /24s Percentage of available address space announced: 76.5 Percentage of allocated address space announced: 76.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 207587 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156526 Total APNIC prefixes after maximum aggregation: 43103 APNIC Deaggregation factor: 3.63 Prefixes being announced from the APNIC address blocks: 170977 Unique aggregates announced from the APNIC address blocks: 70544 APNIC Region origin ASes present in the Internet Routing Table: 5182 APNIC Prefixes per ASN: 32.99 APNIC Region origin ASes announcing only one prefix: 1131 APNIC Region transit ASes present in the Internet Routing Table: 937 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 38 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2568 Number of APNIC addresses announced to Internet: 761387652 Equivalent to 45 /8s, 97 /16s and 218 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 188266 Total ARIN prefixes after maximum aggregation: 89328 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 195158 Unique aggregates announced from the ARIN address blocks: 89565 ARIN Region origin ASes present in the Internet Routing Table: 16087 ARIN Prefixes per ASN: 12.13 ARIN Region origin ASes announcing only one prefix: 5609 ARIN Region transit ASes present in the Internet Routing Table: 1712 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1670 Number of ARIN addresses announced to Internet: 1105876640 Equivalent to 65 /8s, 234 /16s and 86 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 150514 Total RIPE prefixes after maximum aggregation: 73101 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 161898 Unique aggregates announced from the RIPE address blocks: 98885 RIPE Region origin ASes present in the Internet Routing Table: 18153 RIPE Prefixes per ASN: 8.92 RIPE Region origin ASes announcing only one prefix: 7757 RIPE Region transit ASes present in the Internet Routing Table: 3054 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5106 Number of RIPE addresses announced to Internet: 709572480 Equivalent to 42 /8s, 75 /16s and 55 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 63659 Total LACNIC prefixes after maximum aggregation: 12583 LACNIC Deaggregation factor: 5.06 Prefixes being announced from the LACNIC address blocks: 80194 Unique aggregates announced from the LACNIC address blocks: 37813 LACNIC Region origin ASes present in the Internet Routing Table: 2487 LACNIC Prefixes per ASN: 32.25 LACNIC Region origin ASes announcing only one prefix: 543 LACNIC Region transit ASes present in the Internet Routing Table: 595 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3047 Number of LACNIC addresses announced to Internet: 170723904 Equivalent to 10 /8s, 45 /16s and 10 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15392 Total AfriNIC prefixes after maximum aggregation: 3279 AfriNIC Deaggregation factor: 4.69 Prefixes being announced from the AfriNIC address blocks: 17683 Unique aggregates announced from the AfriNIC address blocks: 6662 AfriNIC Region origin ASes present in the Internet Routing Table: 736 AfriNIC Prefixes per ASN: 24.03 AfriNIC Region origin ASes announcing only one prefix: 169 AfriNIC Region transit ASes present in the Internet Routing Table: 180 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 284 Number of AfriNIC addresses announced to Internet: 85533184 Equivalent to 5 /8s, 25 /16s and 34 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3710 390 250 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2986 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2718 11133 740 KIXS-AS-KR Korea Telecom, KR 9829 2693 1498 534 BSNL-NIB National Internet Backbone, IN 9808 2252 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2042 428 217 TATACOMM-AS TATA Communications formerl 45899 1742 1261 98 VNPT-AS-VN VNPT Corp, VN 4808 1648 2165 468 CHINA169-BJ China Unicom Beijing Provin 24560 1580 559 238 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3610 2968 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3251 1333 82 SHAW - Shaw Communications Inc., CA 18566 2195 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1956 2021 402 CHARTER-NET-HKY-NC - Charter Communicat 30036 1744 328 401 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1730 5066 639 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6983 1676 848 227 ITCDELTA - Earthlink, Inc., US 701 1598 10629 661 UUNET - MCI Communications Services, In 16509 1522 2837 519 AMAZON-02 - Amazon.com, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3141 163 17 ALJAWWALSTC-AS , SA 20940 2964 1117 2103 AKAMAI-ASN1 , US 9121 2323 1708 96 TTNET , TR 34984 1985 327 373 TELLCOM-AS , TR 13188 1605 99 58 TRIOLAN , UA 12479 1414 1033 51 UNI2-AS , ES 6849 1289 355 22 UKRTELNET , UA 8551 1198 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 8402 1148 544 15 CORBINA-AS OJSC "Vimpelcom", RU 12389 999 1156 446 ROSTELECOM-AS , RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3527 543 179 Telmex Colombia S.A., CO 8151 2293 3373 556 Uninet S.A. de C.V., MX 11830 1799 368 66 Instituto Costarricense de Electricidad 6503 1543 437 54 Axtel, S.A.B. de C.V., MX 7303 1524 970 251 Telecom Argentina S.A., AR 6147 1347 377 27 Telefonica del Peru S.A.A., PE 28573 1055 2271 173 CLARO S.A., BR 3816 1028 480 191 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 914 126 78 Alestra, S. de R.L. de C.V., MX 18881 879 1036 22 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1295 402 42 LINKdotNET-AS, EG 36903 687 345 122 MT-MPLS, MA 37611 676 67 6 Afrihost, ZA 36992 579 1373 25 ETISALAT-MISR, EG 8452 488 1472 15 TE-AS TE-AS, EG 24835 487 658 16 RAYA-AS, EG 29571 368 36 10 CITelecom-AS, CI 37492 355 280 71 ORANGE-TN, TN 15399 314 35 6 WANANCHI-KE, KE 2018 272 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3710 390 250 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3610 2968 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3527 543 179 Telmex Colombia S.A., CO 6327 3251 1333 82 SHAW - Shaw Communications Inc., CA 39891 3141 163 17 ALJAWWALSTC-AS , SA 17974 2986 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2964 1117 2103 AKAMAI-ASN1 , US 4766 2718 11133 740 KIXS-AS-KR Korea Telecom, KR 9829 2693 1498 534 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 3710 3460 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3610 3458 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3527 3348 Telmex Colombia S.A., CO 6327 3251 3169 SHAW - Shaw Communications Inc., CA 39891 3141 3124 ALJAWWALSTC-AS , SA 17974 2986 2915 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9121 2323 2227 TTNET , TR 9808 2252 2219 CMNET-GD Guangdong Mobile Communication 9829 2693 2159 BSNL-NIB National Internet Backbone, IN 18566 2195 2086 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom 65220 PRIVATE 61.128.136.0/21 23456 -Reserved AS-, ZZ Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG 41.73.20.0/24 37004 Suburban-Broadband-AS, NG Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:276 /13:529 /14:1046 /15:1796 /16:13154 /17:7794 /18:13020 /19:25268 /20:38075 /21:40639 /22:73119 /23:61353 /24:348686 /25:546 /26:413 /27:311 /28:33 /29:19 /30:23 /31:0 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3047 3251 SHAW - Shaw Communications Inc., CA 39891 2896 3141 ALJAWWALSTC-AS , SA 22773 2811 3610 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2088 2195 MEGAPATH5-US - MegaPath Corporation, US 9121 1632 2323 TTNET , TR 30036 1556 1744 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1446 3527 Telmex Colombia S.A., CO 6389 1393 2095 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1350 1605 TRIOLAN , UA 6983 1323 1676 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1588 2:816 4:23 5:2407 6:32 8:1022 12:1812 13:65 14:1780 15:24 16:2 17:104 18:128 19:1 20:51 23:2031 24:1800 27:2400 31:1831 32:83 33:11 34:1 35:3 36:376 37:2486 38:1298 39:42 40:99 41:3037 42:454 43:1903 44:52 45:2301 46:2516 47:106 49:1195 50:948 51:15 52:609 54:356 55:8 56:4 57:40 58:1567 59:978 60:389 61:1867 62:1499 63:1927 64:4540 65:2177 66:4398 67:2213 68:1168 69:3308 70:1302 71:560 72:2055 74:2595 75:404 76:413 77:1414 78:1603 79:907 80:1358 81:1420 82:968 83:717 84:857 85:1685 86:486 87:1132 88:781 89:2041 90:195 91:6096 92:976 93:2370 94:2343 95:2795 96:595 97:359 98:944 99:93 100:148 101:1200 103:13037 104:2631 105:138 106:473 107:1491 108:779 109:2530 110:1274 111:1661 112:1131 113:1170 114:1001 115:1626 116:1680 117:1577 118:2111 119:1588 120:942 121:1075 122:2281 123:1999 124:1593 125:1839 128:727 129:481 130:432 131:1357 132:613 133:187 134:528 135:209 136:385 137:395 138:1820 139:455 140:621 141:475 142:720 143:893 144:748 145:168 146:960 147:641 148:1355 149:555 150:683 151:797 152:703 153:313 154:715 155:949 156:544 157:562 158:428 159:1339 160:564 161:732 162:2451 163:537 164:779 165:1135 166:361 167:1225 168:2440 169:687 170:2518 171:262 172:848 173:1819 174:782 175:711 176:1748 177:4083 178:2411 179:1125 180:2192 181:1923 182:2127 183:1012 184:849 185:8330 186:3247 187:2242 188:2316 189:1777 190:7972 191:1292 192:9287 193:5768 194:4551 195:3856 196:1849 197:1257 198:5597 199:5819 200:7207 201:4012 202:10152 203:9831 204:4454 205:2772 206:2970 207:3166 208:4019 209:3867 210:3886 211:2077 212:2796 213:2446 214:849 215:66 216:5767 217:1973 218:825 219:595 220:1666 221:894 222:726 223:1101 End of report From cgrundemann at gmail.com Fri Dec 23 20:36:10 2016 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 23 Dec 2016 15:36:10 -0500 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization Message-ID: Hail NANOGers! A global hospitality organization with 100+ locations recently asked us how to weigh the importance of standardizing infrastructure across all their locations versus allowing each international location to select on their own kit. My first instinct was to jump on my favorite search engine and look for an authoritative document covering the topic. To my surprise I have not been able to find such a thing. So I've begun to write one myself, and as I start I've realized that: a) This is likely to be a document that will be helpful to the wider community, and b) This is likely a topic that many of you have a great deal of knowledge and personal experience. If you have pointers to an existing doc, please share. If you have a case study, lesson learned, data point, or even just a strong opinion; I'd love to hear it! My intention is to put this together BCOP style, but with more of a focus on why rather than how this time around. Feel free to reply on or off list. Thanks in advance for your input! Cheers, ~Chris PS - I won't use any direct quotes without advance permission and I'll provide attribution to all that contribute meaningfully. -- @ChrisGrundemann http://chrisgrundemann.com From jsage at finchhaven.com Fri Dec 23 14:23:26 2016 From: jsage at finchhaven.com (John Sage) Date: Fri, 23 Dec 2016 06:23:26 -0800 Subject: Canada joins the 21st century ! In-Reply-To: <1490299301.5631.1482499128416.JavaMail.mhammett@ThunderFuck> References: <585BEA4A.7050809@vaxination.ca> <1490299301.5631.1482499128416.JavaMail.mhammett@ThunderFuck> Message-ID: <585D335E.1090900@finchhaven.com> On 12/23/2016 05:18 AM, Mike Hammett wrote: > The government getting involved with the Internet rarely goes well. The FCC is a shining example of how to usually do it wrong. > I agree. To hell with 'government'. What has it done for you lately, anyway? Canada should just have Comcast (or is it "Xfinity"?) provided nation-wide Internet service as a for-profit monopoly. Problem solved! - John -- From pch-nanog-1 at u-1.phicoh.com Fri Dec 23 12:21:42 2016 From: pch-nanog-1 at u-1.phicoh.com (Philip Homburg) Date: Fri, 23 Dec 2016 13:21:42 +0100 Subject: Recent NTP pool traffic increase In-Reply-To: Your message of "Thu, 22 Dec 2016 23:31:08 -0500 ." <4ef1d708-5302-15df-23fb-b942f1651af1@coldnorthadmin.com> Message-ID: >What I mostly meant is that there should be a regulated, industry-wide >effort in order to provide a stable and active pool program. With the >current models, a protocol that is widely used by commercial devices is >being supported by the time and effort of volunteers around the world. My employer has a budget 'for the good of the Internet' So I'd suggest that people involved in NTP (certainly pool) submit proposals. Likewise, there are country code DNS registries that are non-profits and have budgets for research, etc. Given that time is important for DNSSEC, it maybe worth contacting them. From nanog at ics-il.net Fri Dec 23 21:58:25 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 23 Dec 2016 15:58:25 -0600 (CST) Subject: Canada joins the 21st century ! In-Reply-To: <585D335E.1090900@finchhaven.com> References: <585BEA4A.7050809@vaxination.ca> <1490299301.5631.1482499128416.JavaMail.mhammett@ThunderFuck> <585D335E.1090900@finchhaven.com> Message-ID: <256566967.53253.1482530301931.JavaMail.mhammett@ThunderFuck> In the US there are thousands of independent ISPs. I assume Canada at least has hundreds of them. There are plenty of ways of utilize independents to improve access versus throwing cash into a fan. Not to mention the ridiculousness of a 50/10 requirement. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "John Sage" To: Nanog at nanog.org Sent: Friday, December 23, 2016 8:23:26 AM Subject: Re: Canada joins the 21st century ! On 12/23/2016 05:18 AM, Mike Hammett wrote: > The government getting involved with the Internet rarely goes well. The FCC is a shining example of how to usually do it wrong. > I agree. To hell with 'government'. What has it done for you lately, anyway? Canada should just have Comcast (or is it "Xfinity"?) provided nation-wide Internet service as a for-profit monopoly. Problem solved! - John -- From dougb at dougbarton.us Fri Dec 23 22:44:25 2016 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 23 Dec 2016 14:44:25 -0800 Subject: Wanted: volunteers with bandwidth/storage to help save climate data In-Reply-To: References: <20161216163008.GG28510@sizone.org> <20161216172437.GK28510@sizone.org> <20161216203044.GA9904@sizone.org> <0cb4574f-00f5-af19-7714-84e734944f68@invaluement.com> <20161216214834.GI16300@bamboo.slabnet.com> <2659a100-e1fc-a821-6153-724517edbcc5@dougbarton.us> <20161222004941.GP2029@sizone.org> Message-ID: On 12/21/2016 06:15 PM, Royce Williams wrote: > On Wed, Dec 21, 2016 at 3:49 PM, Ken Chase wrote: >> On Wed, Dec 21, 2016 at 04:41:29PM -0800, Doug Barton said: >> [..] >> >>Everyone has a line at which "I don't care what's in the pipes, I just >> >>work here" changes into something more actionable. >> > >> >Stretched far beyond any credibility. Your argument boils down to, "If it's >> >a political thing that *I* like, it's on topic." > > I can see why you've concluded that. My final phrasing was indeed > ambiguous. I would have hoped that the rest of my carefully > non-partisan post would have offset that ambiguity. There was no ambiguity, your argument was clear. I simply think you were wrong. :) >> "If it's a politically-generated thing I'll have to deal with at an >> operational level, it's on topic." >> >> That work? > > That is indeed what I was trying to say - thanks, Ken. Again, hard to see how the OP asking for assistance with his pet project fits any definition of "have to deal with at an operational level." But now I'm repeating myself, so I'll leave it at that. Doug From rod.beck at unitedcablecompany.com Fri Dec 23 23:20:18 2016 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 23 Dec 2016 23:20:18 +0000 Subject: Canada joins the 21st century ! In-Reply-To: <256566967.53253.1482530301931.JavaMail.mhammett@ThunderFuck> References: <585BEA4A.7050809@vaxination.ca> <1490299301.5631.1482499128416.JavaMail.mhammett@ThunderFuck> <585D335E.1090900@finchhaven.com>, <256566967.53253.1482530301931.JavaMail.mhammett@ThunderFuck> Message-ID: Thousands of ISPs that collectively add up to a pimple on a horse's ass. In practice you have two dominant landline providers in each market, the ILEC and the cable company. A duopoly with a competitive fringe. Whereas other countries like South Korea and France have achieved much higher broadband penetration rates using other approaches. ________________________________ From: NANOG on behalf of Mike Hammett Sent: Friday, December 23, 2016 10:58 PM Cc: Nanog at nanog.org Subject: Re: Canada joins the 21st century ! In the US there are thousands of independent ISPs. I assume Canada at least has hundreds of them. There are plenty of ways of utilize independents to improve access versus throwing cash into a fan. Not to mention the ridiculousness of a 50/10 requirement. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "John Sage" To: Nanog at nanog.org Sent: Friday, December 23, 2016 8:23:26 AM Subject: Re: Canada joins the 21st century ! On 12/23/2016 05:18 AM, Mike Hammett wrote: > The government getting involved with the Internet rarely goes well. The FCC is a shining example of how to usually do it wrong. > I agree. To hell with 'government'. What has it done for you lately, anyway? Canada should just have Comcast (or is it "Xfinity"?) provided nation-wide Internet service as a for-profit monopoly. Problem solved! - John -- From lyndon at orthanc.ca Fri Dec 23 23:55:27 2016 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Fri, 23 Dec 2016 15:55:27 -0800 (PST) Subject: Canada joins the 21st century ! In-Reply-To: <585D335E.1090900@finchhaven.com> References: <585BEA4A.7050809@vaxination.ca> <1490299301.5631.1482499128416.JavaMail.mhammett@ThunderFuck> <585D335E.1090900@finchhaven.com> Message-ID: > Canada should just have Comcast (or is it "Xfinity"?) provided nation-wide > Internet service as a for-profit monopoly. Just as long as we have *someone* to Telus whom to chose. From nanog at ics-il.net Sat Dec 24 04:22:29 2016 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 23 Dec 2016 22:22:29 -0600 (CST) Subject: Canada joins the 21st century ! In-Reply-To: References: <585BEA4A.7050809@vaxination.ca> <1490299301.5631.1482499128416.JavaMail.mhammett@ThunderFuck> <585D335E.1090900@finchhaven.com> <256566967.53253.1482530301931.JavaMail.mhammett@ThunderFuck> Message-ID: <1595248480.67714.1482553344485.JavaMail.mhammett@ThunderFuck> Fake competition. Lack of innovation competition. Lack of diversity. As I said, there are plenty of ways to utilize independents to accomplish reasonable goals. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Rod Beck" To: "Mike Hammett" Cc: Nanog at nanog.org Sent: Friday, December 23, 2016 5:20:18 PM Subject: Re: Canada joins the 21st century ! Thousands of ISPs that collectively add up to a pimple on a horse's ass. In practice you have two dominant landline providers in each market, the ILEC and the cable company. A duopoly with a competitive fringe. Whereas other countries like South Korea and France have achieved much higher broadband penetration rates using other approaches. From: NANOG on behalf of Mike Hammett Sent: Friday, December 23, 2016 10:58 PM Cc: Nanog at nanog.org Subject: Re: Canada joins the 21st century ! In the US there are thousands of independent ISPs. I assume Canada at least has hundreds of them. There are plenty of ways of utilize independents to improve access versus throwing cash into a fan. Not to mention the ridiculousness of a 50/10 requirement. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "John Sage" To: Nanog at nanog.org Sent: Friday, December 23, 2016 8:23:26 AM Subject: Re: Canada joins the 21st century ! On 12/23/2016 05:18 AM, Mike Hammett wrote: > The government getting involved with the Internet rarely goes well. The FCC is a shining example of how to usually do it wrong. > I agree. To hell with 'government'. What has it done for you lately, anyway? Canada should just have Comcast (or is it "Xfinity"?) provided nation-wide Internet service as a for-profit monopoly. Problem solved! - John -- From liste at freeheberg.com Sat Dec 24 00:14:39 2016 From: liste at freeheberg.com (Jeremy) Date: Sat, 24 Dec 2016 01:14:39 +0100 Subject: DWDM on 250 Km dark fiber without re-amplification Message-ID: Hi all, First, i'm sorry for my english, i'm french and i don't have a good level in this language. But i want some informations and i'm sure, someone will be give the good anwser about my question. So, i'm regarding to rent a dual dark fiber in France, the estimated distance is 225 Km, but i know there are a lot of optical switching on the highway where it's fiber is installed (in theory, all 80 Km). So, i used the bad scenario, in adding 25 Km on my need. I would like to buy a amplificator and multiplexer DWDM to add some 10Gb/s waves on this dark fiber. I've see that the amplification is better on 100 Gb/s synchronised ports, but we don't have enoug capacity on our router to add 100 Gb/s interfaces. So, someone has installed this type of hardware on a dark fiber without regeneration on 250 Km of distance ? If yes, with what kind of hardware ? If you are commercial for this hardware, please contact me in private message. Thanks you for your time, J?r?my AS197922 From jloiacon at csc.com Sat Dec 24 17:45:28 2016 From: jloiacon at csc.com (Joe Loiacono) Date: Sat, 24 Dec 2016 12:45:28 -0500 Subject: Canada joins the 21st century ! In-Reply-To: <1490299301.5631.1482499128416.JavaMail.mhammett@ThunderFuck> References: <585BEA4A.7050809@vaxination.ca> <1490299301.5631.1482499128416.JavaMail.mhammett@ThunderFuck> Message-ID: +1 Joe Loiacono From: Mike Hammett To: Cc: Nanog at nanog.org Date: 12/23/2016 08:20 AM Subject: Re: Canada joins the 21st century ! Sent by: "NANOG" The government getting involved with the Internet rarely goes well. The FCC is a shining example of how to usually do it wrong. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Jean-Francois Mezei" To: Nanog at nanog.org Sent: Thursday, December 22, 2016 8:59:22 AM Subject: Canada joins the 21st century ! This is more of an FYI. Yesterday, the CRTC released a big decision on broadband. In 2011, the same process resulted in CRTC to not declare the Internet as "basic service" and to set speed goals to 1990s 5/1. Yesterday, the CRTC declared the Internet to be a basic service (which enables additional regulatory powers) and set speed goals to 50/10. Note that this is not a definition of broadband as the FCC had done, it one of many criteria that will be weighted when proposal to get funding is received. But hopefully, it means the end of deployment of DSL. Also, as a result of declaring it a basic service, the CRTC enables powers to force ISPs to contrtibute to a fund that will be used to subsidize deplooyment in rural areas. It plans to collect $100 million/year, increasing by $25m each year to top at $200m which will then be distributed to companies who deploy internet to unserved areas. By setting the speed standard to 50/10, it basically marks any territory not served by cableco as underserved since telco's copper can't reliably deliver those speeds. Nothing happens for now because a "follow up" process is needed to decide how the funding mechanism will work (what portions of a companies revenues are counted to calculated its mandated contribution to fund) and how the process of bidding for subsidies will work. That could take 1 to 2 years. Also in the decision is the phasing out of the equivalent programme for POTS which saw telephone deployed everywhere. The difference is that the POTS program had an "obligation to serve" whereas the internet doesn't. From baldur.norddahl at gmail.com Sat Dec 24 19:08:17 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 24 Dec 2016 20:08:17 +0100 Subject: Canada joins the 21st century ! In-Reply-To: <585BEA4A.7050809@vaxination.ca> References: <585BEA4A.7050809@vaxination.ca> Message-ID: We have customers with 150/30 Mbps service on DSL and next year we will get 300 Mbps. We are just renting access, it is the ILEC that decided to make a large roll out with vectoring, pair bonding and VDSL2 annex 35b. I would say that the majority around here can get at least 50/10 from DSL. There is of course also large areas were you can not. In many cases these areas can be "fixed" by adding another DSLAM closer to the users. We are actually primary a FTTH provider. I just want to point out that you need to be aware of what DSL can do if someone decides to invest in it. It can do 50/10. It will never be able to do the 1000/1000 FTTH that we are selling at $44 USD/month. Cable might be able to compete with that too however. The same ILEC also owns most of the cable network and they are rolling out DOCSIS 3.1 with plans to sell 1000 Mbps next year. Regards, Baldur Den 22/12/2016 kl. 15.59 skrev Jean-Francois Mezei: > This is more of an FYI. > > Yesterday, the CRTC released a big decision on broadband. In 2011, the > same process resulted in CRTC to not declare the Internet as "basic > service" and to set speed goals to 1990s 5/1. > > Yesterday, the CRTC declared the Internet to be a basic service (which > enables additional regulatory powers) and set speed goals to 50/10. > > Note that this is not a definition of broadband as the FCC had done, it > one of many criteria that will be weighted when proposal to get funding > is received. But hopefully, it means the end of deployment of DSL. > > > Also, as a result of declaring it a basic service, the CRTC enables > powers to force ISPs to contrtibute to a fund that will be used to > subsidize deplooyment in rural areas. > > It plans to collect $100 million/year, increasing by $25m each year to > top at $200m which will then be distributed to companies who deploy > internet to unserved areas. > > By setting the speed standard to 50/10, it basically marks any territory > not served by cableco as underserved since telco's copper can't reliably > deliver those speeds. > > > Nothing happens for now because a "follow up" process is needed to > decide how the funding mechanism will work (what portions of a companies > revenues are counted to calculated its mandated contribution to fund) > and how the process of bidding for subsidies will work. That could take > 1 to 2 years. > > Also in the decision is the phasing out of the equivalent programme for > POTS which saw telephone deployed everywhere. The difference is that the > POTS program had an "obligation to serve" whereas the internet doesn't. From baldur.norddahl at gmail.com Sat Dec 24 19:30:40 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 24 Dec 2016 20:30:40 +0100 Subject: DWDM on 250 Km dark fiber without re-amplification In-Reply-To: References: Message-ID: <34af09f9-8db0-6c60-e422-086633550314@gmail.com> Hello I have not done this as our links are not that long. However in theory this is how I would do it. There are nice integrated solutions that will do it as a black box, but someone else will have to tell you about that. I am using Fiberstore as a reference because they have the necessary components with pricing directly online, but there is of course multiple alternatives. So first off forget about 40G and 100G. This will be N x 10G and N can be as large as 96 channels. 100G would be the same equipment (possibly without dispersion compensation) but with each 100G stream as four 25G wavelengths. However the optics are very expensive and hard to get for 40G and 100G while 10G is relatively cheap and easy. You need the following components: http://www.fs.com/support/dwdm-edfa-amplifier-for-long-haul-applications-100 They list all you need with a nice drawing. Get the components from them or someone else. The nice integrated solutions are just these components in a box. They only list the solution as 200 km. You will have to send them a mail and ask if they can do 225 km. Also you need to check that the black fiber provider allows amplified signals at this level. Not everyone do. Normally the signals are not that dangerous, but with this a unaware tech can go blind if he is unlucky. It is not clear if the Fiberstore equipment automatically turns of the laser in the case of a fiber cut and that might also be a requirement. Regards, Baldur Den 24/12/2016 kl. 01.14 skrev Jeremy: > Hi all, > > First, i'm sorry for my english, i'm french and i don't have a good > level in this language. But i want some informations and i'm sure, > someone will be give the good anwser about my question. > > So, i'm regarding to rent a dual dark fiber in France, the estimated > distance is 225 Km, but i know there are a lot of optical switching on > the highway where it's fiber is installed (in theory, all 80 Km). So, > i used the bad scenario, in adding 25 Km on my need. > > I would like to buy a amplificator and multiplexer DWDM to add some > 10Gb/s waves on this dark fiber. I've see that the amplification is > better on 100 Gb/s synchronised ports, but we don't have enoug > capacity on our router to add 100 Gb/s interfaces. > > So, someone has installed this type of hardware on a dark fiber > without regeneration on 250 Km of distance ? > If yes, with what kind of hardware ? If you are commercial for this > hardware, please contact me in private message. > > Thanks you for your time, > J?r?my > AS197922 > From nanog at ics-il.net Sat Dec 24 21:11:34 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 24 Dec 2016 15:11:34 -0600 (CST) Subject: Canada joins the 21st century ! In-Reply-To: References: <585BEA4A.7050809@vaxination.ca> Message-ID: <1384638544.85866.1482613891504.JavaMail.mhammett@ThunderFuck> Most of the areas without sufficient speed can be addressed with fixed wireless, but usually the regulators become as much of a hindrance as a help. LOS customers are no problem via 5 GHz, but they've drug their feet in allocating useful rules for 3600 and under 700 MHz. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Saturday, December 24, 2016 1:08:17 PM Subject: Re: Canada joins the 21st century ! We have customers with 150/30 Mbps service on DSL and next year we will get 300 Mbps. We are just renting access, it is the ILEC that decided to make a large roll out with vectoring, pair bonding and VDSL2 annex 35b. I would say that the majority around here can get at least 50/10 from DSL. There is of course also large areas were you can not. In many cases these areas can be "fixed" by adding another DSLAM closer to the users. We are actually primary a FTTH provider. I just want to point out that you need to be aware of what DSL can do if someone decides to invest in it. It can do 50/10. It will never be able to do the 1000/1000 FTTH that we are selling at $44 USD/month. Cable might be able to compete with that too however. The same ILEC also owns most of the cable network and they are rolling out DOCSIS 3.1 with plans to sell 1000 Mbps next year. Regards, Baldur Den 22/12/2016 kl. 15.59 skrev Jean-Francois Mezei: > This is more of an FYI. > > Yesterday, the CRTC released a big decision on broadband. In 2011, the > same process resulted in CRTC to not declare the Internet as "basic > service" and to set speed goals to 1990s 5/1. > > Yesterday, the CRTC declared the Internet to be a basic service (which > enables additional regulatory powers) and set speed goals to 50/10. > > Note that this is not a definition of broadband as the FCC had done, it > one of many criteria that will be weighted when proposal to get funding > is received. But hopefully, it means the end of deployment of DSL. > > > Also, as a result of declaring it a basic service, the CRTC enables > powers to force ISPs to contrtibute to a fund that will be used to > subsidize deplooyment in rural areas. > > It plans to collect $100 million/year, increasing by $25m each year to > top at $200m which will then be distributed to companies who deploy > internet to unserved areas. > > By setting the speed standard to 50/10, it basically marks any territory > not served by cableco as underserved since telco's copper can't reliably > deliver those speeds. > > > Nothing happens for now because a "follow up" process is needed to > decide how the funding mechanism will work (what portions of a companies > revenues are counted to calculated its mandated contribution to fund) > and how the process of bidding for subsidies will work. That could take > 1 to 2 years. > > Also in the decision is the phasing out of the equivalent programme for > POTS which saw telephone deployed everywhere. The difference is that the > POTS program had an "obligation to serve" whereas the internet doesn't. From nanog at ics-il.net Sat Dec 24 23:51:23 2016 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 24 Dec 2016 17:51:23 -0600 (CST) Subject: BCM5341x In-Reply-To: <1453184615.94007.1482622806053.JavaMail.mhammett@ThunderFuck> Message-ID: <115402558.94042.1482623479606.JavaMail.mhammett@ThunderFuck> I've asked Broadcom directly, but being as though I don't have an intent to buy tens of thousands of chips (or any at all), I don't expect I'll hear back. I was hoping someone here would have some insight. Do any of you know what functionality is available on those chips? That's the chip that powers the Ubiquiti 10G switches and I figured I would limit my most aggressive feature requests to things they can actually deliver with the platform as is. Other than things you just assume a managed switch has like 802.1p and 802.1q, it mentions an advanced ContentAware? Engine (which means?), IEEE1588 (sync over Ethernet), 802.1ag (OAM stuff), "Enhanced DoS attack statistics gathering" (which means?), "IPv4/IPv6 L3 packet classification" (which means?), etc. I'm sure there's an array of things to ask about, but MLAG and S-Flow are at the top of my list at the moment. https://www.broadcom.com/products/ethernet-connectivity/switch-fabric/bcm5341x/ ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From faisal at snappytelecom.net Sun Dec 25 00:53:00 2016 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sun, 25 Dec 2016 00:53:00 +0000 (GMT) Subject: DWDM on 250 Km dark fiber without re-amplification In-Reply-To: <34af09f9-8db0-6c60-e422-086633550314@gmail.com> References: <34af09f9-8db0-6c60-e422-086633550314@gmail.com> Message-ID: <2040039879.1406216.1482627180863.JavaMail.zimbra@snappytelecom.net> I agree with what Baldur suggested.. Only thing I would point out that .. Hardly anyone installs 200km fiber runs without having some sort of a Regen facility. While you can push the signal over the 200km link, in the long run you may be better off see if there a Regen facility (typically 70/80km) that you can use to re-generate the light. Best of luck. Faisal Imtiaz Snappy Internet & Telecom ----- Original Message ----- > From: "Baldur Norddahl" > To: "nanog list" > Sent: Saturday, December 24, 2016 2:30:40 PM > Subject: Re: DWDM on 250 Km dark fiber without re-amplification > Hello > > I have not done this as our links are not that long. However in theory > this is how I would do it. There are nice integrated solutions that will > do it as a black box, but someone else will have to tell you about that. > I am using Fiberstore as a reference because they have the necessary > components with pricing directly online, but there is of course multiple > alternatives. > > So first off forget about 40G and 100G. This will be N x 10G and N can > be as large as 96 channels. 100G would be the same equipment (possibly > without dispersion compensation) but with each 100G stream as four 25G > wavelengths. However the optics are very expensive and hard to get for > 40G and 100G while 10G is relatively cheap and easy. > > You need the following components: > > http://www.fs.com/support/dwdm-edfa-amplifier-for-long-haul-applications-100 > > They list all you need with a nice drawing. Get the components from them > or someone else. The nice integrated solutions are just these components > in a box. > > They only list the solution as 200 km. You will have to send them a mail > and ask if they can do 225 km. > > Also you need to check that the black fiber provider allows amplified > signals at this level. Not everyone do. Normally the signals are not > that dangerous, but with this a unaware tech can go blind if he is > unlucky. It is not clear if the Fiberstore equipment automatically turns > of the laser in the case of a fiber cut and that might also be a > requirement. > > Regards, > > Baldur > > > > Den 24/12/2016 kl. 01.14 skrev Jeremy: >> Hi all, >> >> First, i'm sorry for my english, i'm french and i don't have a good >> level in this language. But i want some informations and i'm sure, >> someone will be give the good anwser about my question. >> >> So, i'm regarding to rent a dual dark fiber in France, the estimated >> distance is 225 Km, but i know there are a lot of optical switching on >> the highway where it's fiber is installed (in theory, all 80 Km). So, >> i used the bad scenario, in adding 25 Km on my need. >> >> I would like to buy a amplificator and multiplexer DWDM to add some >> 10Gb/s waves on this dark fiber. I've see that the amplification is >> better on 100 Gb/s synchronised ports, but we don't have enoug >> capacity on our router to add 100 Gb/s interfaces. >> >> So, someone has installed this type of hardware on a dark fiber >> without regeneration on 250 Km of distance ? >> If yes, with what kind of hardware ? If you are commercial for this >> hardware, please contact me in private message. >> >> Thanks you for your time, >> J?r?my >> AS197922 From mloftis at wgops.com Sun Dec 25 01:46:48 2016 From: mloftis at wgops.com (Michael Loftis) Date: Sun, 25 Dec 2016 01:46:48 +0000 Subject: BCM5341x In-Reply-To: <115402558.94042.1482623479606.JavaMail.mhammett@ThunderFuck> References: <1453184615.94007.1482622806053.JavaMail.mhammett@ThunderFuck> <115402558.94042.1482623479606.JavaMail.mhammett@ThunderFuck> Message-ID: The chip really doesn't even function as an Ethernet switch by itself...all of the behavior is software driven. It's the ... actualization of "software defined networking" -- It provides a lot of low level constructs inside the hardware to support your application, but it's really a software defined switch. It has many programmable offload functions the idea being you do not handle packets on the onboard CPU. ContentAware is their term for L4-L7 I believe I don't think it's much more than simple pattern matching in the hardware and can be used to apply as ACL or drive QoS decisions. The chip can do things like handle limited v4/v6 lookups and routing (but it's not going to do ARP response... nor LACP...) It has a huge number of integrated hardware counters, lots are built in but you can count basically anything the hardware can match (which is basically anything you can describe in a stateless manner). So s-flow... probably in hardware it can be programmed to do most or all of it as it's largely copying a buffer into a header but I don't have the data sheets so couldn't say for sure. MCLAG/MLAG, sure, that's software directed and behaves exactly like LACP or static lag down at the hardware. Really the hardware doesn't much care as that all exists above it in the control plane. I'm not clear at all what depth of v4/v6 classification they support - but that's usually the basics of QoS and calling it out specifically is marketing wankery I think. How big the tables can get I don't know. Nearly two decades ago they had 2k in the L3 space with 8K in L2 on 24x100+2x1G ... so I can't imagine it's less than that for table sizes :) probably like 8k/4K entries range as the RAMs and TCAMs haven't scaled up in speed very well. On Sat, Dec 24, 2016 at 15:52 Mike Hammett wrote: > I've asked Broadcom directly, but being as though I don't have an intent > to buy tens of thousands of chips (or any at all), I don't expect I'll hear > back. I was hoping someone here would have some insight. > > > > Do any of you know what functionality is available on those chips? That's > the chip that powers the Ubiquiti 10G switches and I figured I would limit > my most aggressive feature requests to things they can actually deliver > with the platform as is. > > > > Other than things you just assume a managed switch has like 802.1p and > 802.1q, it mentions an advanced ContentAware? Engine (which means?), > IEEE1588 (sync over Ethernet), 802.1ag (OAM stuff), "Enhanced DoS attack > statistics gathering" (which means?), "IPv4/IPv6 L3 packet classification" > (which means?), etc. > > > > I'm sure there's an array of things to ask about, but MLAG and S-Flow are > at the top of my list at the moment. > > > > > https://www.broadcom.com/products/ethernet-connectivity/switch-fabric/bcm5341x/ > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > > From fujimura at fukuoka-u.ac.jp Sat Dec 24 14:11:53 2016 From: fujimura at fukuoka-u.ac.jp (FUJIMURA Sho) Date: Sat, 24 Dec 2016 23:11:53 +0900 Subject: Recent NTP pool traffic increase (update) In-Reply-To: <3DA4CBC1-CABD-4992-8C05-3629CCAC19B8@develooper.com> References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <1c45fa7a2425045d30efb3623bbe3d5a@nuclearcat.com> <07c6752a5396d8d99d11dfca131b8155@nuclearcat.com> <3DA4CBC1-CABD-4992-8C05-3629CCAC19B8@develooper.com> Message-ID: Hello, I know 133.100.9.2 and 133.100.11.8 are listed. The Server Contact is old information. So, I sent e-mail to webmaster at ntp.org a few times. But, I have't received e-mail from them. I'd like them to change the information. Is there the person knowing the contact information to ntp.org? -- Sho FUJIMURA Information Technology Center, Fukuoka University. 8-19-1, Nanakuma, Jyonan-ku, Fukuoka, 8140180, Japan 2016-12-23 9:04 GMT+09:00 Ask Bj?rn Hansen : > Hello, > > Those servers aren?t (and have never been) part of the NTP Pool - https://www.ntppool.org/en/ > > If they were you could remove them from the system and over the next hours, days and months the traffic would go away. We also have features to change the relative amount of clients you get (to just get less queries instead of withdrawing from the pool altogether). > > Anyway, it looks like your IPs are listed on support.ntp.org as ?public servers?, so removing them from there would be step 1. However there?s no working mechanism for you to tell the clients that they should go away after they?ve hard coded your IP in their configuration. (That?s the point of the NTP Pool system really, to let you offer a public service and have a avenue to stop doing it, too). > > support.ntp.org appears to be down, but your IPs are listed on the site according to a Google search: > https://www.google.com/search?q=133.100.9.2+ntp > > > Ask > >> On Dec 21, 2016, at 7:13 PM, FUJIMURA Sho wrote: >> >> Hello. >> >> I operate the public NTP Service as 133.100.9.2 >> and 133.100.11.8 at Fukuoka University, Japan. >> I have a lot of trouble with too much NTP traffic from >> many routers which 133.100.9.2 as default setting of NTP >> has been set like Tenda or LB-Link etc. >> So, although I'd like to contact Firmware developpers of these company >> and would like them to change the default settins, >> is there the person knowing the contact information? >> >> -- >> Sho FUJIMURA >> Information Technology Center, Fukuoka University. >> 8-19-1, Nanakuma, Jyonan-ku, Fukuoka, 8140180, Japan > > > From lists.nanog at monmotha.net Sun Dec 25 08:41:12 2016 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sun, 25 Dec 2016 03:41:12 -0500 Subject: DWDM on 250 Km dark fiber without re-amplification In-Reply-To: References: Message-ID: <585F8628.8090701@monmotha.net> On 12/23/2016 07:14 PM, Jeremy wrote: > Hi all, > > First, i'm sorry for my english, i'm french and i don't have a good > level in this language. But i want some informations and i'm sure, > someone will be give the good anwser about my question. > > So, i'm regarding to rent a dual dark fiber in France, the estimated > distance is 225 Km, but i know there are a lot of optical switching on > the highway where it's fiber is installed (in theory, all 80 Km). So, i > used the bad scenario, in adding 25 Km on my need. > > I would like to buy a amplificator and multiplexer DWDM to add some > 10Gb/s waves on this dark fiber. I've see that the amplification is > better on 100 Gb/s synchronised ports, but we don't have enoug capacity > on our router to add 100 Gb/s interfaces. > > So, someone has installed this type of hardware on a dark fiber without > regeneration on 250 Km of distance ? > If yes, with what kind of hardware ? If you are commercial for this > hardware, please contact me in private message. Look up Raman amplification. The short of what this does is it pumps a ton of power into the near end of the fiber span and creates what looks somewhat like a typical color-blind amplifier somewhere several dozen km out on the span. You'll also need to dump a ton of power into the span at the far end using an EDFA or similar. Even with both of those, that distance is still going to push the raw optical power budget of even most state-of-the-art transceivers especially if the fiber is old or of low quality (high loss, high dispersion, etc.). The longest span I've ever gotten a vendor to commit to an engineered design for was about 140km, and of course they needed full characterization of the span before they'd do it. At those distances, distance alone is no longer sufficient to throw together a design. It seems highly likely that there's at least one re-gen facility along that span. I'd definitely see if there is one and if you can get some space in it. That will knock you down into the 100-130km range on both sides of the re-gen, hopefully, which is perfectly doable. You are somewhat correct that 100Gb interfaces often handle longer distances better, but it's because they are often using coherent receivers and carrier-synchronous transmitters rather than raw power receivers and ASK pulsed transmitters. There are vendors that sell coherent 10Gb transceivers, too, and they'll be cheaper than 100Gb solutions especially if you don't need the extra capacity anyway. I'd definitely check them out for this type of application especially if you can't get any dispersion compensation in the middle since coherent optics are usually much more tolerant of chromatic dispersion. The big vendor I've worked with in the past on this sort of stuff is Ciena (and they're certainly a juggernaut in the industry) though I have no connection to them other than as a satisfied (if occasionally broke after a PO or out of breath after seeing a quotation) customer/integrator. -- Brandon Martin From stenn at nwtime.org Sun Dec 25 10:43:13 2016 From: stenn at nwtime.org (Harlan Stenn) Date: Sun, 25 Dec 2016 02:43:13 -0800 Subject: Recent NTP pool traffic increase (update) In-Reply-To: References: <20161217175455.30107c37@spidey.rellim.com> <20161217192538.7b74386f@spidey.rellim.com> <88a02ab4-7d66-f0d0-2a7e-9606dda501be@coldnorthadmin.com> <1c45fa7a2425045d30efb3623bbe3d5a@nuclearcat.com> <07c6752a5396d8d99d11dfca131b8155@nuclearcat.com> <3DA4CBC1-CABD-4992-8C05-3629CCAC19B8@develooper.com> Message-ID: <7befe2a6-fa5f-87cd-29a6-459c0adfd5a9@nwtime.org> Hi Fujimura-san, On 12/24/16 6:11 AM, FUJIMURA Sho wrote: > Hello, > > I know 133.100.9.2 and 133.100.11.8 are listed. > The Server Contact is old information. > So, I sent e-mail to webmaster at ntp.org a few times. > But, I have't received e-mail from them. > I'd like them to change the information. > Is there the person knowing the contact information to ntp.org? I don't recall seeing the emails you sent to webmaster, but we do have a new group of folks watching the Servers web. We would be happy to work with you to give you access to those entries so you can update them. -- Harlan Stenn http://networktimefoundation.org - be a member! From joelja at bogus.com Sun Dec 25 15:48:13 2016 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 25 Dec 2016 07:48:13 -0800 Subject: BCM5341x In-Reply-To: <115402558.94042.1482623479606.JavaMail.mhammett@ThunderFuck> References: <115402558.94042.1482623479606.JavaMail.mhammett@ThunderFuck> Message-ID: Sent from my iPhone > On Dec 24, 2016, at 15:51, Mike Hammett wrote: > > I've asked Broadcom directly, but being as though I don't have an intent to buy tens of thousands of chips (or any at all), I don't expect I'll hear back. I was hoping someone here would have some insight. > > Do any of you know what functionality is available on those chips? That's the chip that powers the Ubiquiti 10G switches and I figured I would limit my most aggressive feature requests to things they can actually deliver with the platform as is. > > Other than things you just assume a managed switch has like 802.1p and 802.1q, it mentions an advanced ContentAware? Engine (which means?), IEEE1588 (sync over Ethernet), 802.1ag (OAM stuff), "Enhanced DoS attack statistics gathering" (which means?), "IPv4/IPv6 L3 packet classification" (which means?), etc. > > I'm sure there's an array of things to ask about, but MLAG and S-Flow are at the top of my list at the moment. MCLAG is a control plane function. Sflow on devices that don't generate it in a distributed fashion is done but punting sampled packets to the control-plane for classification by an sflow agent. Sample rate is therefore contingent on adequate CPU and control-plane bandwidth. The greyhound switch SOC may be hampered by the amount of CPU available locally, but the 2MB packet buffer also is probably cause for caution. > https://www.broadcom.com/products/ethernet-connectivity/switch-fabric/bcm5341x/ > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From brough at netblazr.com Mon Dec 26 16:02:24 2016 From: brough at netblazr.com (Brough Turner) Date: Mon, 26 Dec 2016 11:02:24 -0500 Subject: BCM5341x In-Reply-To: References: <115402558.94042.1482623479606.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, Another practical question (for what you are seeking) is how much of the control plane software (for features you seek) does Broadcom provide with their reference design and how much must Ubiquiti write? Thanks, Brough Brough Turner netBlazr Inc. ? Free your Broadband! Mobile: 617-285-0433 Skype: brough netBlazr Inc. | Google+ | Twitter | LinkedIn | Facebook | Blog | Personal website On Sun, Dec 25, 2016 at 10:48 AM, Joel Jaeggli wrote: > > > Sent from my iPhone > > > On Dec 24, 2016, at 15:51, Mike Hammett wrote: > > > > I've asked Broadcom directly, but being as though I don't have an intent > to buy tens of thousands of chips (or any at all), I don't expect I'll hear > back. I was hoping someone here would have some insight. > > > > Do any of you know what functionality is available on those chips? > That's the chip that powers the Ubiquiti 10G switches and I figured I would > limit my most aggressive feature requests to things they can actually > deliver with the platform as is. > > > > Other than things you just assume a managed switch has like 802.1p and > 802.1q, it mentions an advanced ContentAware? Engine (which means?), > IEEE1588 (sync over Ethernet), 802.1ag (OAM stuff), "Enhanced DoS attack > statistics gathering" (which means?), "IPv4/IPv6 L3 packet classification" > (which means?), etc. > > > > I'm sure there's an array of things to ask about, but MLAG and S-Flow > are at the top of my list at the moment. > > MCLAG is a control plane function. > > Sflow on devices that don't generate it in a distributed fashion is done > but punting sampled packets to the control-plane for classification by an > sflow agent. Sample rate is therefore contingent on adequate CPU and > control-plane bandwidth. > > The greyhound switch SOC may be hampered by the amount of CPU available > locally, but the 2MB packet buffer also is probably cause for caution. > > > https://www.broadcom.com/products/ethernet-connectivity/switch-fabric/ > bcm5341x/ > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > > > > From Valdis.Kletnieks at vt.edu Tue Dec 27 01:55:07 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 26 Dec 2016 20:55:07 -0500 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: References: Message-ID: <205612.1482803707@turing-police.cc.vt.edu> On Fri, 23 Dec 2016 15:36:10 -0500, Chris Grundemann said: > A global hospitality organization with 100+ locations recently asked us how > to weigh the importance of standardizing infrastructure across all their > locations versus allowing each international location to select on their > own kit. The first question that comes to mind is: Does the organization have any centralized IT, or is *that* done by each location? The procurement directives need to be coming from the group that actually does day-to-day support of each location, or the resulting culture clash will cause issues.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From briansupport at hotmail.com Tue Dec 27 17:41:00 2016 From: briansupport at hotmail.com (Brian R) Date: Tue, 27 Dec 2016 17:41:00 +0000 Subject: DWDM on 250 Km dark fiber without re-amplification In-Reply-To: <585F8628.8090701@monmotha.net> References: , <585F8628.8090701@monmotha.net> Message-ID: I have to agree with Brandon. I have not worked with Ciena equipment directly but have work with carriers that use it. I worked with Adtran on this kind of setup and like Brandon said they require a lot of information to build what is needed for each specific run (fiber type, quality, wave length optimization, number of splices, etc). I've seen the tools Adtran uses to calculate exactly what equipment is required and it is pretty complex for distances even close to what you are talking about. Definitely check for a re-gen site(s), most likely the carrier has to re-gen their own runs down this fiber path (another thing to consider in the calculation matrix especially if you are not trying to re-gen your run). I have to give Baldur kudos for finding that I'm still amazed that Fiberstore is claiming that's possible without a lot of information. I have worked with Fiberstore and they are a cooperative vendor and their products work for what we have used them for. My suggestion is to reach out to Fiberstore, Ciena, Adtran, and other vendors that people recommend with a detailed email of what you would like to accomplish and the information you can get. Ask for a design engineer (I know Adtran has them and assume others do) to get the info you need and see what they can mock up for you. Brian ________________________________ From: NANOG on behalf of Brandon Martin Sent: Sunday, December 25, 2016 12:41 AM To: nanog at nanog.org Subject: Re: DWDM on 250 Km dark fiber without re-amplification On 12/23/2016 07:14 PM, Jeremy wrote: > Hi all, > > First, i'm sorry for my english, i'm french and i don't have a good > level in this language. But i want some informations and i'm sure, > someone will be give the good anwser about my question. > > So, i'm regarding to rent a dual dark fiber in France, the estimated > distance is 225 Km, but i know there are a lot of optical switching on > the highway where it's fiber is installed (in theory, all 80 Km). So, i > used the bad scenario, in adding 25 Km on my need. > > I would like to buy a amplificator and multiplexer DWDM to add some > 10Gb/s waves on this dark fiber. I've see that the amplification is > better on 100 Gb/s synchronised ports, but we don't have enoug capacity > on our router to add 100 Gb/s interfaces. > > So, someone has installed this type of hardware on a dark fiber without > regeneration on 250 Km of distance ? > If yes, with what kind of hardware ? If you are commercial for this > hardware, please contact me in private message. Look up Raman amplification. The short of what this does is it pumps a ton of power into the near end of the fiber span and creates what looks somewhat like a typical color-blind amplifier somewhere several dozen km out on the span. You'll also need to dump a ton of power into the span at the far end using an EDFA or similar. Even with both of those, that distance is still going to push the raw optical power budget of even most state-of-the-art transceivers especially if the fiber is old or of low quality (high loss, high dispersion, etc.). The longest span I've ever gotten a vendor to commit to an engineered design for was about 140km, and of course they needed full characterization of the span before they'd do it. At those distances, distance alone is no longer sufficient to throw together a design. It seems highly likely that there's at least one re-gen facility along that span. I'd definitely see if there is one and if you can get some space in it. That will knock you down into the 100-130km range on both sides of the re-gen, hopefully, which is perfectly doable. You are somewhat correct that 100Gb interfaces often handle longer distances better, but it's because they are often using coherent receivers and carrier-synchronous transmitters rather than raw power receivers and ASK pulsed transmitters. There are vendors that sell coherent 10Gb transceivers, too, and they'll be cheaper than 100Gb solutions especially if you don't need the extra capacity anyway. I'd definitely check them out for this type of application especially if you can't get any dispersion compensation in the middle since coherent optics are usually much more tolerant of chromatic dispersion. The big vendor I've worked with in the past on this sort of stuff is Ciena (and they're certainly a juggernaut in the industry) though I have no connection to them other than as a satisfied (if occasionally broke after a PO or out of breath after seeing a quotation) customer/integrator. -- Brandon Martin From josh at zevlag.com Tue Dec 27 19:08:37 2016 From: josh at zevlag.com (Josh Galvez) Date: Tue, 27 Dec 2016 12:08:37 -0700 Subject: DWDM on 250 Km dark fiber without re-amplification In-Reply-To: References: <585F8628.8090701@monmotha.net> Message-ID: Jeremy, SmartOptics is one such vendor that I've used in the past that may be able to do this. http://www.smartoptics.com/ -Josh On Tue, Dec 27, 2016 at 10:41 AM, Brian R wrote: > I have to agree with Brandon. I have not worked with Ciena equipment > directly but have work with carriers that use it. I worked with Adtran on > this kind of setup and like Brandon said they require a lot of information > to build what is needed for each specific run (fiber type, quality, wave > length optimization, number of splices, etc). I've seen the tools Adtran > uses to calculate exactly what equipment is required and it is pretty > complex for distances even close to what you are talking about. > > Definitely check for a re-gen site(s), most likely the carrier has to > re-gen their own runs down this fiber path (another thing to consider in > the calculation matrix especially if you are not trying to re-gen your run). > > > I have to give Baldur kudos for finding that I'm still amazed that > Fiberstore is claiming that's possible without a lot of information. I > have worked with Fiberstore and they are a cooperative vendor and their > products work for what we have used them for. > > > My suggestion is to reach out to Fiberstore, Ciena, Adtran, and other > vendors that people recommend with a detailed email of what you would like > to accomplish and the information you can get. Ask for a design engineer > (I know Adtran has them and assume others do) to get the info you need and > see what they can mock up for you. > > > Brian > > > ________________________________ > From: NANOG on behalf of Brandon Martin < > lists.nanog at monmotha.net> > Sent: Sunday, December 25, 2016 12:41 AM > To: nanog at nanog.org > Subject: Re: DWDM on 250 Km dark fiber without re-amplification > > On 12/23/2016 07:14 PM, Jeremy wrote: > > Hi all, > > > > First, i'm sorry for my english, i'm french and i don't have a good > > level in this language. But i want some informations and i'm sure, > > someone will be give the good anwser about my question. > > > > So, i'm regarding to rent a dual dark fiber in France, the estimated > > distance is 225 Km, but i know there are a lot of optical switching on > > the highway where it's fiber is installed (in theory, all 80 Km). So, i > > used the bad scenario, in adding 25 Km on my need. > > > > I would like to buy a amplificator and multiplexer DWDM to add some > > 10Gb/s waves on this dark fiber. I've see that the amplification is > > better on 100 Gb/s synchronised ports, but we don't have enoug capacity > > on our router to add 100 Gb/s interfaces. > > > > So, someone has installed this type of hardware on a dark fiber without > > regeneration on 250 Km of distance ? > > If yes, with what kind of hardware ? If you are commercial for this > > hardware, please contact me in private message. > > > Look up Raman amplification. The short of what this does is it pumps a > ton of power into the near end of the fiber span and creates what looks > somewhat like a typical color-blind amplifier somewhere several dozen km > out on the span. You'll also need to dump a ton of power into the span > at the far end using an EDFA or similar. Even with both of those, that > distance is still going to push the raw optical power budget of even > most state-of-the-art transceivers especially if the fiber is old or of > low quality (high loss, high dispersion, etc.). > > The longest span I've ever gotten a vendor to commit to an engineered > design for was about 140km, and of course they needed full > characterization of the span before they'd do it. At those distances, > distance alone is no longer sufficient to throw together a design. > > It seems highly likely that there's at least one re-gen facility along > that span. I'd definitely see if there is one and if you can get some > space in it. That will knock you down into the 100-130km range on both > sides of the re-gen, hopefully, which is perfectly doable. > > You are somewhat correct that 100Gb interfaces often handle longer > distances better, but it's because they are often using coherent > receivers and carrier-synchronous transmitters rather than raw power > receivers and ASK pulsed transmitters. There are vendors that sell > coherent 10Gb transceivers, too, and they'll be cheaper than 100Gb > solutions especially if you don't need the extra capacity anyway. I'd > definitely check them out for this type of application especially if you > can't get any dispersion compensation in the middle since coherent > optics are usually much more tolerant of chromatic dispersion. > > The big vendor I've worked with in the past on this sort of stuff is > Ciena (and they're certainly a juggernaut in the industry) though I have > no connection to them other than as a satisfied (if occasionally broke > after a PO or out of breath after seeing a quotation) customer/integrator. > > -- > Brandon Martin > From eric.kuhnke at gmail.com Tue Dec 27 19:17:37 2016 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 27 Dec 2016 11:17:37 -0800 Subject: DWDM on 250 Km dark fiber without re-amplification In-Reply-To: References: Message-ID: You will want to request an OTDR characterization of the dark fiber path from its owner. If you can post OTDR "shots" with full resolution images in a lossless image format to the list, we may be able to take a guess if the distance is feasible without amplification inline. For equipment choices you're looking at the usual vendors for DWDM long haul ROADM chassis such as Ciena, Adva, Huawei, ZTE, Infinera, etc. If you simply want to do point to point DWDM mux:demux on the 250km fiber, your choices will be different than if you want the ability to insert a chassis at an intermediate location and drop or insert wavelengths. It may be possible, at a lower cost than buying 100GbE capable DWDM chassis type systems, to do a single router-to-router linecard link with coherent 100GbE signal with FEC on the 250km path. Again this will totally depend on the OTDR results and link budget available. On Fri, Dec 23, 2016 at 4:14 PM, Jeremy wrote: > Hi all, > > First, i'm sorry for my english, i'm french and i don't have a good level > in this language. But i want some informations and i'm sure, someone will > be give the good anwser about my question. > > So, i'm regarding to rent a dual dark fiber in France, the estimated > distance is 225 Km, but i know there are a lot of optical switching on the > highway where it's fiber is installed (in theory, all 80 Km). So, i used > the bad scenario, in adding 25 Km on my need. > > I would like to buy a amplificator and multiplexer DWDM to add some 10Gb/s > waves on this dark fiber. I've see that the amplification is better on 100 > Gb/s synchronised ports, but we don't have enoug capacity on our router to > add 100 Gb/s interfaces. > > So, someone has installed this type of hardware on a dark fiber without > regeneration on 250 Km of distance ? > If yes, with what kind of hardware ? If you are commercial for this > hardware, please contact me in private message. > > Thanks you for your time, > J?r?my > AS197922 > > From bicknell at ufp.org Tue Dec 27 20:10:08 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 27 Dec 2016 12:10:08 -0800 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: References: Message-ID: <20161227201008.GA31233@ussenterprise.ufp.org> In a message written on Fri, Dec 23, 2016 at 03:36:10PM -0500, Chris Grundemann wrote: > If you have a case study, lesson learned, data point, or even just a strong > opinion; I'd love to hear it! I think the high level items are pretty clear here: 1 Vendor Quicker/easier to implement, staff only needs to learn/configure one platform, vendor can help end to end, usually fewer interop issues. Spend may get extra discounts or support bennies. However one bug can wipe out everything, no ability to compare real world performance with a competitor, vendor may think they "own" you come renewal or more sales. Hard to threaten to leave. 2 Vendor Can be implemented multiple ways, for instance 1 vendor per site alternating sites, or gear deployed in pairs with one from each vendor up and down the stack. Harder to implement, staff needs to know both, all configs must be done for both, vendors will always blame the other vendor for interop issues. Twice as much chance of needing to do emergency upgrades. More resilliance to a single bug, can compare real world performance of the two vendors. Both vendors will compete hard to get more of your business, but have a harder time justifing bennies internally due to lower spend. 3 or more Vendors Generally the same as two-vendors, just ++. That is more of the pros, and more of the cons. Limited additional upside to having 3 or more active vendors. Generally occurs as a vendor falls out of favor, two new ones get deployed moving forward, the old one sticks around for a while. Having worked places that were single vendor, 2 vendor, and "whatever we can buy" shops I'll say it basically doesn't matter. What matters is how you set up the org. Want to be lean on staff, go single vendor. Want maximum resilliance and/or negotiating power, go 2 vendor. Inherit a mess, learn to live in a 3+ vendor world. It's not that one is better than the other, it's just they require different approaches to get the same outcome. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From rjacobs at pslightwave.com Tue Dec 27 23:20:46 2016 From: rjacobs at pslightwave.com (Robert Jacobs) Date: Tue, 27 Dec 2016 23:20:46 +0000 Subject: DWDM on 250 Km dark fiber without re-amplification In-Reply-To: References: Message-ID: Polarization and dispersion will come into play at these distances if you plan on running a DWDM system. In that world you get what you pay for as a rule. The more expensive gear is more forgiving to fiber that is not 100 % up to high quality. Most small one or two RU gear from all the vendors mentioned have 100 gig cards that will be 100 gig on the DWDM side and break it out to 10 sfp Plus ten gig ports for the client side. Another thing to look for in this is link down propergation ... you will want the client facing links on both sides of the optical span to go down if the span goes down. Good luck with your quest -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke Sent: Tuesday, December 27, 2016 1:18 PM To: Jeremy ; nanog at nanog.org list Subject: Re: DWDM on 250 Km dark fiber without re-amplification You will want to request an OTDR characterization of the dark fiber path from its owner. If you can post OTDR "shots" with full resolution images in a lossless image format to the list, we may be able to take a guess if the distance is feasible without amplification inline. For equipment choices you're looking at the usual vendors for DWDM long haul ROADM chassis such as Ciena, Adva, Huawei, ZTE, Infinera, etc. If you simply want to do point to point DWDM mux:demux on the 250km fiber, your choices will be different than if you want the ability to insert a chassis at an intermediate location and drop or insert wavelengths. It may be possible, at a lower cost than buying 100GbE capable DWDM chassis type systems, to do a single router-to-router linecard link with coherent 100GbE signal with FEC on the 250km path. Again this will totally depend on the OTDR results and link budget available. On Fri, Dec 23, 2016 at 4:14 PM, Jeremy wrote: > Hi all, > > First, i'm sorry for my english, i'm french and i don't have a good > level in this language. But i want some informations and i'm sure, > someone will be give the good anwser about my question. > > So, i'm regarding to rent a dual dark fiber in France, the estimated > distance is 225 Km, but i know there are a lot of optical switching on > the highway where it's fiber is installed (in theory, all 80 Km). So, > i used the bad scenario, in adding 25 Km on my need. > > I would like to buy a amplificator and multiplexer DWDM to add some > 10Gb/s waves on this dark fiber. I've see that the amplification is > better on 100 Gb/s synchronised ports, but we don't have enoug > capacity on our router to add 100 Gb/s interfaces. > > So, someone has installed this type of hardware on a dark fiber > without regeneration on 250 Km of distance ? > If yes, with what kind of hardware ? If you are commercial for this > hardware, please contact me in private message. > > Thanks you for your time, > J?r?my > AS197922 > > From nolan.berry at RACKSPACE.COM Tue Dec 27 17:30:22 2016 From: nolan.berry at RACKSPACE.COM (Nolan Berry) Date: Tue, 27 Dec 2016 17:30:22 +0000 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: <205612.1482803707@turing-police.cc.vt.edu> References: , <205612.1482803707@turing-police.cc.vt.edu> Message-ID: System automation and life cycle management is exponentially easier when you have uniform environments. I am in the process of standardizing global infrastructure and developing the automation process now. Nolan ________________________________ From: NANOG on behalf of Valdis.Kletnieks at vt.edu Sent: Monday, December 26, 2016 7:55 PM To: Chris Grundemann Cc: nanog at nanog.org Subject: Re: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization On Fri, 23 Dec 2016 15:36:10 -0500, Chris Grundemann said: > A global hospitality organization with 100+ locations recently asked us how > to weigh the importance of standardizing infrastructure across all their > locations versus allowing each international location to select on their > own kit. The first question that comes to mind is: Does the organization have any centralized IT, or is *that* done by each location? The procurement directives need to be coming from the group that actually does day-to-day support of each location, or the resulting culture clash will cause issues.... From joly at punkcast.com Wed Dec 28 11:03:37 2016 From: joly at punkcast.com (Joly MacFie) Date: Wed, 28 Dec 2016 06:03:37 -0500 Subject: WEBCAST TODAY: ION Bucharest 2016 Message-ID: Over the holiday I am taking the opportunity to catch up on some editing. This session, from October, is a series of very informative presentations on the latest in network security practice and IPv6 deployment. I'm afraid the 3rd presentation is in Romanian, but the slides are in English! joly posted: "Today, Wednesday December 28 2016, ION Bucharest 2016 - which took place on October 12 2016 - will be restreamed live on the Internet Society Livestream Channel. The Internet Society's Deploy 360 team host a series of presentations, plus a panel, on the l" [image: Livestream] Today, *Wednesday December 28 2016*, *ION Bucharest 2016 * - which took place on October 12 2016 - will be restreamed live on the *Internet Society Livestream Channel *. The Internet Society's *Deploy 360 * team host a series of presentations, plus a panel, on the latest developments with *DNSSEC*, *DANE*, *MANRS*, and *IPv6* with an emphasis on Romania. *What: ION Bucharest 2016 When: Wednesday December 28 2016 9am-12:30pm EST | 13:00-16:30 UTC Webcast: https://livestream.com/internetsociety/ionbucharest/ Slides: http://www.internetsociety.org/deploy360/ion/bucharest2016/presentations/ Twitter: https://twitter.com/hashtag/IONConf * Comment See all comments *?Permalink* http://isoc-ny.org/p2/8870 -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - From cgrundemann at gmail.com Wed Dec 28 18:39:59 2016 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 28 Dec 2016 13:39:59 -0500 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: <20161227201008.GA31233@ussenterprise.ufp.org> References: <20161227201008.GA31233@ussenterprise.ufp.org> Message-ID: On Tue, Dec 27, 2016 at 3:10 PM, Leo Bicknell wrote: > 2 Vendor > > Can be implemented multiple ways, for instance 1 vendor per site > alternating sites, or gear deployed in pairs with one from each vendor > up and down the stack. > An alternative multi-vendor approach is to use 1 vendor per stack layer, but alternate layer to layer. That is; Vendor A edge router, Vendor B firewall, Vendor A/C switches, Vendor D anti-SPAM software, etc. This doesn't address the bug impact issue as well as it alleviates the vendor "ownership" issue though... From morrowc.lists at gmail.com Wed Dec 28 20:36:46 2016 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 28 Dec 2016 15:36:46 -0500 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: References: <20161227201008.GA31233@ussenterprise.ufp.org> Message-ID: On Wed, Dec 28, 2016 at 1:39 PM, Chris Grundemann wrote: > On Tue, Dec 27, 2016 at 3:10 PM, Leo Bicknell wrote: > > > 2 Vendor > > > > Can be implemented multiple ways, for instance 1 vendor per site > > alternating sites, or gear deployed in pairs with one from each vendor > > up and down the stack. > > > > An alternative multi-vendor approach is to use 1 vendor per stack layer, > but alternate layer to layer. That is; Vendor A edge router, Vendor B > firewall, Vendor A/C switches, Vendor D anti-SPAM software, etc. This > doesn't address the bug impact issue as well as it alleviates the vendor > "ownership" issue though... > It also doesn't get you to a place where you can 'require' similar functionality between vendors at each layer... you MAY (if not careful) get locked into a particular vendor at one/some levels of the stack ;( (which you noted as a problem still) if you choose poorly on 'features used' (oops! I love me some eigrp... crap) -chris From randy at psg.com Thu Dec 29 01:34:09 2016 From: randy at psg.com (Randy Bush) Date: Thu, 29 Dec 2016 10:34:09 +0900 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: References: <20161227201008.GA31233@ussenterprise.ufp.org> Message-ID: > An alternative multi-vendor approach is to use 1 vendor per stack layer, > but alternate layer to layer. That is; Vendor A edge router, Vendor B > firewall, Vendor A/C switches, Vendor D anti-SPAM software, etc. This > doesn't address the bug impact issue as well as it alleviates the vendor > "ownership" issue though... i think this is where i say that i hope my competitors do this. it is a recipe for a complex set of delicate dependencies and great fun debugging. randy From thegameiam at yahoo.com Thu Dec 29 04:13:28 2016 From: thegameiam at yahoo.com (David Barak) Date: Wed, 28 Dec 2016 20:13:28 -0800 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: References: <20161227201008.GA31233@ussenterprise.ufp.org> Message-ID: <8330A582-7B55-4F99-A80F-571524E37871@yahoo.com> On Dec 28, 2016, at 5:34 PM, Randy Bush wrote: >> An alternative multi-vendor approach is to use 1 vendor per stack layer, >> but alternate layer to layer. That is; Vendor A edge router, Vendor B >> firewall, Vendor A/C switches, Vendor D anti-SPAM software, etc. This >> doesn't address the bug impact issue as well as it alleviates the vendor >> "ownership" issue though... > > i think this is where i say that i hope my competitors do this. it > is a recipe for a complex set of delicate dependencies and great fun > debugging. > One of the more spectacular failures I've seen was a bug in a network core router that caused bad into to be carried by all of that same vendor's routers across the core to the edges (made by a different vendor) which promptly barfed and locked up. So I'd be cautious about saying "vendor X for one layer, vendor Y for adjacent layer" as a multi-vendor strategy. David Barak Sent from mobile device, please excuse autocorrection artifacts From cgrundemann at gmail.com Thu Dec 29 13:13:51 2016 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 29 Dec 2016 08:13:51 -0500 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: References: <20161227201008.GA31233@ussenterprise.ufp.org> <8330A582-7B55-4F99-A80F-571524E37871@yahoo.com> Message-ID: I apparently wasn't very clear. In the layered approach to multiple vendors, you would (obviously) choose your layer definitions to avoid such delicate interdependence. Regardless of my failure to fully explain, I'm curious as to how mixing vendors at the same layer is seen to be less problematic than assigning vendors specific roles? ---- >My Android sent this< http://chrisgrundemann.com On Dec 28, 2016 11:13 PM, "David Barak" wrote: On Dec 28, 2016, at 5:34 PM, Randy Bush wrote: >> An alternative multi-vendor approach is to use 1 vendor per stack layer, >> but alternate layer to layer. That is; Vendor A edge router, Vendor B >> firewall, Vendor A/C switches, Vendor D anti-SPAM software, etc. This >> doesn't address the bug impact issue as well as it alleviates the vendor >> "ownership" issue though... > > i think this is where i say that i hope my competitors do this. it > is a recipe for a complex set of delicate dependencies and great fun > debugging. > One of the more spectacular failures I've seen was a bug in a network core router that caused bad into to be carried by all of that same vendor's routers across the core to the edges (made by a different vendor) which promptly barfed and locked up. So I'd be cautious about saying "vendor X for one layer, vendor Y for adjacent layer" as a multi-vendor strategy. David Barak Sent from mobile device, please excuse autocorrection artifacts From randy at psg.com Thu Dec 29 15:05:48 2016 From: randy at psg.com (Randy Bush) Date: Fri, 30 Dec 2016 00:05:48 +0900 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: References: <20161227201008.GA31233@ussenterprise.ufp.org> <8330A582-7B55-4F99-A80F-571524E37871@yahoo.com> Message-ID: > I apparently wasn't very clear. In the layered approach to multiple > vendors, you would (obviously) choose your layer definitions to avoid > such delicate interdependence. can you describe in useful detail your operational experience doing this? randy From cgrundemann at gmail.com Thu Dec 29 15:43:07 2016 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 29 Dec 2016 10:43:07 -0500 Subject: Multi-vendor strategies [was: Re: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization] Message-ID: On Thu, Dec 29, 2016 at 10:05 AM, Randy Bush wrote: > > I apparently wasn't very clear. In the layered approach to multiple > > vendors, you would (obviously) choose your layer definitions to avoid > > such delicate interdependence. > > can you describe in useful detail your operational experience doing > this? I'll certainly try. As one hopefully fairly clear example; at a large (US-nation-wide) metro Ethernet provider, we standardized as follows: L3 devices (aka core, customer edge, and Internet/peering edge routers) were all from Vendor A - These devices spoke OSPF, BGP, and RSVP with each other. L2 devices (aka metro ring switches) were all from Vendor B - These devices spoke STP with each other. L1 devices (aka optical transport) were all from Vendors C or D (individual markets got to choose which, but they could only have one each) - These devices inter-operated with each other at the optical layer. Basic network security was handled by devices from Vendor E - These devices collected netflow data and flagged alerts DNS was handled by software from another vendor on servers from yet another vendor, etc... Is that enough detail to be useful? From bicknell at ufp.org Thu Dec 29 15:44:45 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 29 Dec 2016 07:44:45 -0800 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: References: <20161227201008.GA31233@ussenterprise.ufp.org> Message-ID: <20161229154445.GA22378@ussenterprise.ufp.org> In a message written on Wed, Dec 28, 2016 at 01:39:59PM -0500, Chris Grundemann wrote: > An alternative multi-vendor approach is to use 1 vendor per stack layer, > but alternate layer to layer. That is; Vendor A edge router, Vendor B > firewall, Vendor A/C switches, Vendor D anti-SPAM software, etc. This > doesn't address the bug impact issue as well as it alleviates the vendor > "ownership" issue though... While a lot of people seem to be beating you up over this approach, many folks end up in it for various reasons. For instance the chances a vendor makes both a functional edge router and a high quality firewall are low, which means they often are sourced from different companies. But I think the question others are trying to ask is a different hyptothetical. Say there are two vendors, of of which makes perfectly good edge routers and core routers. What are the pros to buying all of the edge from one, and all of the core from the other? I have to admit I'm having trouble coming up with potential technical upsides to such a solution. There may well be a business up side, in that due to the way price structures are done that such a method saves captial. But in terms of technical resilliance, if there's a bug that takes out all cores or all edges the whole network is down, and there's actually 2x the risk as it could happen at either layer! -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Dec 29 18:22:28 2016 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 29 Dec 2016 13:22:28 -0500 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: <20161229154445.GA22378@ussenterprise.ufp.org> References: <20161227201008.GA31233@ussenterprise.ufp.org> <20161229154445.GA22378@ussenterprise.ufp.org> Message-ID: <175344.1483035748@turing-police.cc.vt.edu> On Thu, 29 Dec 2016 07:44:45 -0800, Leo Bicknell said: > But I think the question others are trying to ask is a different > hyptothetical. Say there are two vendors, of of which makes perfectly > good edge routers and core routers. What are the pros to buying all > of the edge from one, and all of the core from the other? The *original* question, which seems to have gotten lost, was: Say you're doing business in 100 countries, with some stated level of possible autonomy for each business unit. Is it better for upper corporate to say "all 100 national business units will use vendor A for edge devices and vendor B for routing", or "all 100 business units shall choose, based on local conditions such as vendor support, a standard set of vendors for their operations"? Stated differently, "Which causes more trouble - a mix of Vendor A in Denmark talking to Vendor B in Finland, or corporate mandating the use of Vendor Q even if Q doesn't have a support office in Kazakhstan while vendor F has an office in the building next door"? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 484 bytes Desc: not available URL: From bicknell at ufp.org Thu Dec 29 19:11:42 2016 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 29 Dec 2016 11:11:42 -0800 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: <175344.1483035748@turing-police.cc.vt.edu> References: <20161227201008.GA31233@ussenterprise.ufp.org> <20161229154445.GA22378@ussenterprise.ufp.org> <175344.1483035748@turing-police.cc.vt.edu> Message-ID: <20161229191142.GA28130@ussenterprise.ufp.org> In a message written on Thu, Dec 29, 2016 at 01:22:28PM -0500, Valdis.Kletnieks at vt.edu wrote: > Say you're doing business in 100 countries, with some stated level of > possible autonomy for each business unit. In all honesty, the original question was a poor straw man for multiple reasons: * Basically nobody does business in 100 countries. Level 3 only claims 60. Verizon does claim 150, but a lot of those are rather arms-length deals. Apple has a "presense" in 97 countries. It's a question about perhaps not a unicorn, but a rare albino pony only seen a few times in the wild! * The companies that do business in these countries rarely have "100 national business units". The chance that all countries are wholy owned subsidiaries created by the corporate parent is zero. They are parterships, co-branding deals, buyouts of existing companies. All of which bring baggage that affects the question more than any any technical details. * Because of how these entities come to be, the chance that the network contains Vendor's A and B, and corporate gets to dictate anything is zero. The network will have Vendors A-Z, plus a few more. Legacy stuff hidden in corners from 50 different M&A activities. Multiple engineering teams, in multiple locations. * Technical people never get to decide the level of "autonomy". A mix of local laws, M&A terms, and other business interests will rule. > Is it better for upper corporate to say "all 100 national business units > will use vendor A for edge devices and vendor B for routing", or "all 100 > business units shall choose, based on local conditions such as vendor > support, a standard set of vendors for their operations"? Which leads to an easy answer. It's better for upper corporate to negotiate bulk deals (note I did not say one vendor) and offer standard solutions to each national BU, so that the engineering does not need to be repeated 100 times. Simple economies of scale. That said, some number of the national BU's will not follow that advice, for perhaps good and often bad reason. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From joelja at bogus.com Thu Dec 29 19:14:34 2016 From: joelja at bogus.com (joel jaeggli) Date: Thu, 29 Dec 2016 11:14:34 -0800 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: <175344.1483035748@turing-police.cc.vt.edu> References: <20161227201008.GA31233@ussenterprise.ufp.org> <20161229154445.GA22378@ussenterprise.ufp.org> <175344.1483035748@turing-police.cc.vt.edu> Message-ID: On 12/29/16 10:22 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 29 Dec 2016 07:44:45 -0800, Leo Bicknell said: > >> But I think the question others are trying to ask is a different >> hyptothetical. Say there are two vendors, of of which makes perfectly >> good edge routers and core routers. What are the pros to buying all >> of the edge from one, and all of the core from the other? > > The *original* question, which seems to have gotten lost, was: > > Say you're doing business in 100 countries, with some stated level of > possible autonomy for each business unit. > > Is it better for upper corporate to say "all 100 national business units > will use vendor A for edge devices and vendor B for routing", or "all 100 > business units shall choose, based on local conditions such as vendor > support, a standard set of vendors for their operations"? > > Stated differently, "Which causes more trouble - a mix of Vendor A in > Denmark talking to Vendor B in Finland, or corporate mandating the use > of Vendor Q even if Q doesn't have a support office in Kazakhstan while > vendor F has an office in the building next door"? ok I'll bite. imho, repeatable patterns of deployment are a great economic and organizational simplification. imho that doesn't mean they are identical. There may be generational differences even in what otherwise would be cookie cutter deployments, e.g. because devices go end of sale, new ones become available, regional vendor preference or vendor diversification. If these are centrally organized and operated or coordinated, then the minimum number of variants possible considering the circumstances where variation is is desirable. It minimizes the effort and training required to deploy and operate the system. If I were to take CDN pops as an example. Inter-generational variation is necessary as are accommodations for varying scale. the system is centrally coordinated and common operating methods are necessary if these systems are to behave a cohesive whole. Systems where deployment is less centralized, and local autonomy is therefore necessary as for example occurs when local contractors use their own equipment may come to different conclusions. e.g. that the specification of the minimum necessary common elements becomes the only feasible approach. For example if you are an Uber driver your minim IT requirements are something like Uber cell phone requirements iPhone requirements to run the Uber driver app Must be iPhone 4S, 5, 5C, 5S, 6, 6 Plus, 6S, 6S Plus, SE, 7, or 7 Plus running iOS 8 or later versions For best results: Use iPhone 5 or newer Android requirements to run the Uber driver app Any smart phone from 2013 or newer, running Android version 4.0 or newer For best results: The phone should run Android 5.0 or newer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From jfmezei_nanog at vaxination.ca Thu Dec 29 19:22:01 2016 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 29 Dec 2016 14:22:01 -0500 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: References: Message-ID: <58656259.4010602@vaxination.ca> When doing business in 100 countries, what if vendor A has support in 80 of those countries, and vendor B has good presence in the last 20 ? What if you require a vendor that has presence in all countries and this limits your RFPs to a single vendor ? Does your company run semi autonomous subsidiaries in each country with its own IT/networking staff ? Who buys local connectivity, HQ in USA or the local subsidiary ? So, if you maintain links to 100 countries around the globe, do you want central management ? can it provide localised support in local languages and local times zones from head office ? Or would that stretch it beyond reasonable capacity and you start to need support from different locations anyways ? Does HQ staff have legal knowledge or all local regulations? Do they have experience bribing officials where bribing is part of business? What happens when country X has special legal requirements, and country Y has conflicting requirememnts that prevent uniform deployment ? It wasn't that long ago that US equipment with encryption couldn't be exported everywhere because encryption was considered a military secret. Consider that in today's environment, it isn't so ludicrous to suggest that a country may require that the equipment has a "backdoor". So it is best to allow that country to have its own separate equipment with minimal management abilities to/from that country to prevent that country's government from interfering with your opps in other countries. It may seem more efficient to manage everything centrally but... I'll use an airline analogy: Southwest airlines was quite succesful with a single plane type. Common training for pilots, all planes maintained from a central hangar, common spare parts etc. If it had 100 planes, and all were maintained from one hangar capable of maintaining 100 planes, this was much better than having 50 737s, and 50 A 320s, requiring 2 separate hangars, each used at only 50% capacity. BUT, if you have 200 planes, then the second batch of planes could be Airbus, and maintained in their own hangar, resulting in both hangars being used at 100% capacity. The point is that beyond a certain size, the advantages of having everything common are not as important, and having dfferent equipment gives you more leverage when negotiating, as well as isolates bugs/viruses to only part of your network. Another aspect is of innovation. When HQ standardizes with one vendor and it is all centralliy managed, it becomes really hard to introduce new technologies because your systems are cast into concrete. If you give each country some autonomy for local equipment, they may be experimenting with different vendors and could find that some new vendor is much better than the one used at HQ, and that experience could then percolate up to headquarters (instead of everything decided at HQ and percolating down to each branch office/subsidiary). At the end of the day, it all depends on how autonomous each subsidiary is around the world. This is quite different from having 100 branches in the USA, each getting physical connection from the same fibre vendor and each operating under same laws, and minimal time zones (still 5 hours between New York and Hawaii though). From baldur.norddahl at gmail.com Thu Dec 29 21:45:02 2016 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 29 Dec 2016 22:45:02 +0100 Subject: microducts Message-ID: <03fb32c5-3377-a158-3b6e-d0024efee7af@gmail.com> Hi I am planing a new FTTH outside plant deployment. We are going to use microducts but which system is the best? I see many resources describing the options available but few if any will take a stance on which one to choose. Some of the choices are: 1) Ducts with larger fixed tubes for direct burial 12/8 mm. Typically 7 ducts in a larger tube. 2) Ducts with smaller fixed tubes 5/3,5 mm. Typically 24 small tubes with one larger centre tube for backbone. 3) Ducts for direct burial arranged in a stripe side by side instead of in a tube. 12/8 mm ducts. Makes it easier to access the tubes and avoids problems with tubes of different length on the drum. And many more variations. I am planing to deploy in an area with the average distance between houses of 10 meters (actually 20 meters but we can serve both sides of the road from one walkway, so that makes it 10 meters average). I want to support a low level of initial uptake of just 10%. The problem is that most sources assume that I am planing for anything between 100% and 50%. I do expect that we will get more customers than just 10%, but the solution might become too expensive, if I have to pay all costs upfront years before I have any hope of that many customers. Some people say just put a lot of plastic down because it is so cheap. But it really isn't. I need to put down the correct amount of tubes because tubes are everything but cheap. I also need a system that is easy and quick to work with because labour is very expensive (but also very skilled) around here. I would appreciate any pointers to articles about this subject. Regards, Baldur From dale.shaw+nanog at gmail.com Wed Dec 28 09:42:05 2016 From: dale.shaw+nanog at gmail.com (Dale Shaw) Date: Wed, 28 Dec 2016 20:42:05 +1100 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: <20161227201008.GA31233@ussenterprise.ufp.org> References: <20161227201008.GA31233@ussenterprise.ufp.org> Message-ID: G'day Leo, On 28 December 2016 at 07:10, Leo Bicknell wrote: > > In a message written on Fri, Dec 23, 2016 at 03:36:10PM -0500, Chris Grundemann wrote: > > If you have a case study, lesson learned, data point, or even just a strong > > opinion; I'd love to hear it! > > I think the high level items are pretty clear here: > [...] > 2 Vendor > > Can be implemented multiple ways, for instance 1 vendor per site > alternating sites, or gear deployed in pairs with one from each vendor > up and down the stack. > > Harder to implement, staff needs to know both, all configs must be > done for both, vendors will always blame the other vendor for interop > issues. Twice as much chance of needing to do emergency upgrades. > > More resilliance to a single bug, can compare real world performance > of the two vendors. Both vendors will compete hard to get more of your > business, but have a harder time justifing bennies internally due to > lower spend. [...] I agree with many of the points you made but here's another data point on the topic of bugs -- I watched a presentation [1] from a couple of guys from Facebook at AusNOG 2016 and one of the takeaways from their talk was that "multivendor is hard". When you have two vendors, you get Vendor A's bugs, Vendor B's bugs, and the Vendor A+B interop bugs. In theory this only gets worse with 3+ vendors. Cheers, Dale [1] < http://www.ausnog.net/sites/default/files/ausnog-2016/presentations/2.10.6_Zaid_Hammoudi_AusNOG2016_Lightning.pdf > From nanog at thedaileyplanet.com Thu Dec 29 16:02:55 2016 From: nanog at thedaileyplanet.com (Chad Dailey) Date: Thu, 29 Dec 2016 10:02:55 -0600 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization In-Reply-To: <20161229154445.GA22378@ussenterprise.ufp.org> References: <20161227201008.GA31233@ussenterprise.ufp.org> <20161229154445.GA22378@ussenterprise.ufp.org> Message-ID: I'm not a fan of vendor lock-in, and have been bitten by it. I eschew vendor specific solutions unless it is essential to delivering a particular result. Keeping multiple players at the table, and making those players aware that you have other options that you can and do take advantage of seems to keep them on their toes when it's time for refresh. On Thu, Dec 29, 2016 at 9:44 AM, Leo Bicknell wrote: > In a message written on Wed, Dec 28, 2016 at 01:39:59PM -0500, Chris > Grundemann wrote: > > An alternative multi-vendor approach is to use 1 vendor per stack layer, > > but alternate layer to layer. That is; Vendor A edge router, Vendor B > > firewall, Vendor A/C switches, Vendor D anti-SPAM software, etc. This > > doesn't address the bug impact issue as well as it alleviates the vendor > > "ownership" issue though... > > While a lot of people seem to be beating you up over this approach, many > folks end up in it for various reasons. For instance the chances a > vendor makes both a functional edge router and a high quality firewall > are low, which means they often are sourced from different companies. > > But I think the question others are trying to ask is a different > hyptothetical. Say there are two vendors, of of which makes perfectly > good edge routers and core routers. What are the pros to buying all > of the edge from one, and all of the core from the other? > > I have to admit I'm having trouble coming up with potential technical > upsides to such a solution. There may well be a business up side, > in that due to the way price structures are done that such a method > saves captial. But in terms of technical resilliance, if there's a > bug that takes out all cores or all edges the whole network is down, > and there's actually 2x the risk as it could happen at either layer! > > -- > Leo Bicknell - bicknell at ufp.org > PGP keys at http://www.ufp.org/~bicknell/ > From jared at puck.nether.net Fri Dec 30 02:17:03 2016 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 29 Dec 2016 21:17:03 -0500 Subject: microducts In-Reply-To: <03fb32c5-3377-a158-3b6e-d0024efee7af@gmail.com> References: <03fb32c5-3377-a158-3b6e-d0024efee7af@gmail.com> Message-ID: <2CAD0D25-3FBC-445A-9BF8-208F8840B65F@puck.nether.net> > On Dec 29, 2016, at 4:45 PM, Baldur Norddahl wrote: > > Hi > > I am planing a new FTTH outside plant deployment. We are going to use microducts but which system is the best? I see many resources describing the options available but few if any will take a stance on which one to choose. > > Some of the choices are: > > 1) Ducts with larger fixed tubes for direct burial 12/8 mm. Typically 7 ducts in a larger tube. > 2) Ducts with smaller fixed tubes 5/3,5 mm. Typically 24 small tubes with one larger centre tube for backbone. > 3) Ducts for direct burial arranged in a stripe side by side instead of in a tube. 12/8 mm ducts. Makes it easier to access the tubes and avoids problems with tubes of different length on the drum. > > And many more variations. > > I am planing to deploy in an area with the average distance between houses of 10 meters (actually 20 meters but we can serve both sides of the road from one walkway, so that makes it 10 meters average). > > I want to support a low level of initial uptake of just 10%. The problem is that most sources assume that I am planing for anything between 100% and 50%. I do expect that we will get more customers than just 10%, but the solution might become too expensive, if I have to pay all costs upfront years before I have any hope of that many customers. > > Some people say just put a lot of plastic down because it is so cheap. But it really isn't. I need to put down the correct amount of tubes because tubes are everything but cheap. I also need a system that is easy and quick to work with because labour is very expensive (but also very skilled) around here. > > I would appreciate any pointers to articles about this subject. I can provide you some advice from a local person in my area that is doing this, while homes aren?t of such a nice identity of 10 meters, they place a pedestal that has capacity for 96 count splice trays at every 3rd home. You can use something like a flat drop cable to be buried later as that connection. They may also drill up to the home or use a maxi or mini-sneaker type device to directly place the duct in the ground from that pedestal. The bonus of this type of solution is in the winter months where the ground is frozen you can often leave this cable on the ground to be buried at a later date. I helped a local WISP turn up their first fiber link in the past two weeks and this was the strategy they took. - Jared From nanog at ics-il.net Fri Dec 30 04:36:49 2016 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 29 Dec 2016 22:36:49 -0600 (CST) Subject: microducts In-Reply-To: <2CAD0D25-3FBC-445A-9BF8-208F8840B65F@puck.nether.net> References: <03fb32c5-3377-a158-3b6e-d0024efee7af@gmail.com> <2CAD0D25-3FBC-445A-9BF8-208F8840B65F@puck.nether.net> Message-ID: <1830891085.3382.1483072606196.JavaMail.mhammett@ThunderFuck> I doubt any such data exists, but I wonder how many fiber miles and customers WISPs turned up in the past year as compared to some high-profile goalpost... Google Fiber or Verizon FiOS or AT&T Gigawhatever or... Obviously not 1:1, but WISPs as a whole compared to the titans. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Jared Mauch" To: "Baldur Norddahl" Cc: nanog at nanog.org Sent: Thursday, December 29, 2016 8:17:03 PM Subject: Re: microducts > On Dec 29, 2016, at 4:45 PM, Baldur Norddahl wrote: > > Hi > > I am planing a new FTTH outside plant deployment. We are going to use microducts but which system is the best? I see many resources describing the options available but few if any will take a stance on which one to choose. > > Some of the choices are: > > 1) Ducts with larger fixed tubes for direct burial 12/8 mm. Typically 7 ducts in a larger tube. > 2) Ducts with smaller fixed tubes 5/3,5 mm. Typically 24 small tubes with one larger centre tube for backbone. > 3) Ducts for direct burial arranged in a stripe side by side instead of in a tube. 12/8 mm ducts. Makes it easier to access the tubes and avoids problems with tubes of different length on the drum. > > And many more variations. > > I am planing to deploy in an area with the average distance between houses of 10 meters (actually 20 meters but we can serve both sides of the road from one walkway, so that makes it 10 meters average). > > I want to support a low level of initial uptake of just 10%. The problem is that most sources assume that I am planing for anything between 100% and 50%. I do expect that we will get more customers than just 10%, but the solution might become too expensive, if I have to pay all costs upfront years before I have any hope of that many customers. > > Some people say just put a lot of plastic down because it is so cheap. But it really isn't. I need to put down the correct amount of tubes because tubes are everything but cheap. I also need a system that is easy and quick to work with because labour is very expensive (but also very skilled) around here. > > I would appreciate any pointers to articles about this subject. I can provide you some advice from a local person in my area that is doing this, while homes aren?t of such a nice identity of 10 meters, they place a pedestal that has capacity for 96 count splice trays at every 3rd home. You can use something like a flat drop cable to be buried later as that connection. They may also drill up to the home or use a maxi or mini-sneaker type device to directly place the duct in the ground from that pedestal. The bonus of this type of solution is in the winter months where the ground is frozen you can often leave this cable on the ground to be buried at a later date. I helped a local WISP turn up their first fiber link in the past two weeks and this was the strategy they took. - Jared From surfer at mauigateway.com Fri Dec 30 05:47:31 2016 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 29 Dec 2016 21:47:31 -0800 Subject: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization Message-ID: <20161229214731.BB4AECC@m0087797.ppops.net> :: and minimal time zones (still 5 hours :: between New York and Hawaii though). Apologies, I can't resist. :) Sometimes it's 6 hours and some times it's 5 between Hawaii and the East Coast. Hawaii is *always* -10 GMT. We don't do daylight savings time. scott From rsk at gsp.org Fri Dec 30 14:56:41 2016 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 30 Dec 2016 09:56:41 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> References: <10994.1482283248@turing-police.cc.vt.edu> <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> Message-ID: <20161230145641.GA3738@gsp.org> On Tue, Dec 20, 2016 at 10:27:18PM -0500, Laurent Dumont wrote: > To be honest, the fact that NTP is still something managed by volunteers and > not a regulated entity (a bit like DNS) is mind boggling. I don't see why. Look back on 30-ish years of domain registration, I think that it was far more responsibly, ethically, and professionally managed when it was handled by volunteers. ---rsk From cscora at apnic.net Fri Dec 30 18:01:46 2016 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 31 Dec 2016 04:01:46 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20161230180146.5BA7954F3A@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 31 Dec, 2016 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 626822 Prefixes after maximum aggregation (per Origin AS): 221601 Deaggregation factor: 2.83 Unique aggregates announced (without unneeded subnets): 304431 Total ASes present in the Internet Routing Table: 55506 Prefixes per ASN: 11.29 Origin-only ASes present in the Internet Routing Table: 36264 Origin ASes announcing only one prefix: 15201 Transit ASes present in the Internet Routing Table: 6538 Transit-only ASes present in the Internet Routing Table: 169 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 38 Max AS path prepend of ASN ( 55644) 36 Prefixes from unregistered ASNs in the Routing Table: 52 Unregistered ASNs in the Routing Table: 17 Number of 32-bit ASNs allocated by the RIRs: 16714 Number of 32-bit ASNs visible in the Routing Table: 12704 Prefixes from 32-bit ASNs in the Routing Table: 52166 Number of bogon 32-bit ASNs visible in the Routing Table: 656 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 376 Number of addresses announced to Internet: 2834970340 Equivalent to 168 /8s, 250 /16s and 54 /24s Percentage of available address space announced: 76.6 Percentage of allocated address space announced: 76.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.4 Total number of prefixes smaller than registry allocations: 207813 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 156571 Total APNIC prefixes after maximum aggregation: 43183 APNIC Deaggregation factor: 3.63 Prefixes being announced from the APNIC address blocks: 171063 Unique aggregates announced from the APNIC address blocks: 70682 APNIC Region origin ASes present in the Internet Routing Table: 5188 APNIC Prefixes per ASN: 32.97 APNIC Region origin ASes announcing only one prefix: 1132 APNIC Region transit ASes present in the Internet Routing Table: 939 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 38 Number of APNIC region 32-bit ASNs visible in the Routing Table: 2579 Number of APNIC addresses announced to Internet: 761702276 Equivalent to 45 /8s, 102 /16s and 167 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 188253 Total ARIN prefixes after maximum aggregation: 89318 ARIN Deaggregation factor: 2.11 Prefixes being announced from the ARIN address blocks: 195160 Unique aggregates announced from the ARIN address blocks: 89620 ARIN Region origin ASes present in the Internet Routing Table: 16071 ARIN Prefixes per ASN: 12.14 ARIN Region origin ASes announcing only one prefix: 5598 ARIN Region transit ASes present in the Internet Routing Table: 1707 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 1679 Number of ARIN addresses announced to Internet: 1106805408 Equivalent to 65 /8s, 248 /16s and 130 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 150572 Total RIPE prefixes after maximum aggregation: 73138 RIPE Deaggregation factor: 2.06 Prefixes being announced from the RIPE address blocks: 162013 Unique aggregates announced from the RIPE address blocks: 99014 RIPE Region origin ASes present in the Internet Routing Table: 18145 RIPE Prefixes per ASN: 8.93 RIPE Region origin ASes announcing only one prefix: 7750 RIPE Region transit ASes present in the Internet Routing Table: 3053 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 5103 Number of RIPE addresses announced to Internet: 709633664 Equivalent to 42 /8s, 76 /16s and 38 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 63826 Total LACNIC prefixes after maximum aggregation: 12660 LACNIC Deaggregation factor: 5.04 Prefixes being announced from the LACNIC address blocks: 80478 Unique aggregates announced from the LACNIC address blocks: 38041 LACNIC Region origin ASes present in the Internet Routing Table: 2488 LACNIC Prefixes per ASN: 32.35 LACNIC Region origin ASes announcing only one prefix: 552 LACNIC Region transit ASes present in the Internet Routing Table: 591 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3059 Number of LACNIC addresses announced to Internet: 170855744 Equivalent to 10 /8s, 47 /16s and 13 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-266652 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 15381 Total AfriNIC prefixes after maximum aggregation: 3294 AfriNIC Deaggregation factor: 4.67 Prefixes being announced from the AfriNIC address blocks: 17732 Unique aggregates announced from the AfriNIC address blocks: 6730 AfriNIC Region origin ASes present in the Internet Routing Table: 735 AfriNIC Prefixes per ASN: 24.13 AfriNIC Region origin ASes announcing only one prefix: 169 AfriNIC Region transit ASes present in the Internet Routing Table: 183 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 18 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 284 Number of AfriNIC addresses announced to Internet: 85518848 Equivalent to 5 /8s, 24 /16s and 234 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3712 390 250 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2984 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2722 11133 741 KIXS-AS-KR Korea Telecom, KR 9829 2692 1499 535 BSNL-NIB National Internet Backbone, IN 9808 2253 8698 33 CMNET-GD Guangdong Mobile Communication 4755 2043 428 216 TATACOMM-AS TATA Communications formerl 45899 1749 1265 99 VNPT-AS-VN VNPT Corp, VN 4808 1651 2169 469 CHINA169-BJ China Unicom Beijing Provin 24560 1583 561 242 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 22773 3614 2968 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3251 1333 82 SHAW - Shaw Communications Inc., CA 18566 2195 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2095 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 1956 2021 402 CHARTER-NET-HKY-NC - Charter Communicat 30036 1747 328 398 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1731 5066 640 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 6983 1676 848 227 ITCDELTA - Earthlink, Inc., US 701 1599 10629 662 UUNET - MCI Communications Services, In 16509 1526 3029 522 AMAZON-02 - Amazon.com, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 39891 3141 163 17 ALJAWWALSTC-AS , SA 20940 2952 1108 2100 AKAMAI-ASN1 , US 9121 2267 1707 95 TTNET , TR 34984 1993 327 376 TELLCOM-AS , TR 13188 1603 99 61 TRIOLAN , UA 12479 1414 1033 51 UNI2-AS , ES 6849 1312 355 22 UKRTELNET , UA 8551 1205 377 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 8402 1128 544 15 CORBINA-AS OJSC "Vimpelcom", RU 12389 996 1156 445 ROSTELECOM-AS , RU Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 3527 543 179 Telmex Colombia S.A., CO 8151 2483 3370 553 Uninet S.A. de C.V., MX 11830 1799 368 66 Instituto Costarricense de Electricidad 6503 1544 437 54 Axtel, S.A.B. de C.V., MX 7303 1522 970 251 Telecom Argentina S.A., AR 6147 1354 377 27 Telefonica del Peru S.A.A., PE 28573 1050 2271 177 CLARO S.A., BR 3816 1030 480 193 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 914 126 78 Alestra, S. de R.L. de C.V., MX 18881 879 1036 22 TELEF?NICA BRASIL S.A, BR Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1293 398 42 LINKdotNET-AS, EG 36903 687 345 122 MT-MPLS, MA 37611 676 67 6 Afrihost, ZA 36992 579 1373 25 ETISALAT-MISR, EG 24835 492 658 16 RAYA-AS, EG 8452 485 1474 16 TE-AS TE-AS, EG 37492 396 288 72 ORANGE-TN, TN 29571 368 36 10 CITelecom-AS, CI 15399 314 35 6 WANANCHI-KE, KE 2018 285 327 74 TENET-1, ZA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 4538 5550 4190 74 ERX-CERNET-BKB China Education and Rese 7545 3712 390 250 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3614 2968 152 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3527 543 179 Telmex Colombia S.A., CO 6327 3251 1333 82 SHAW - Shaw Communications Inc., CA 39891 3141 163 17 ALJAWWALSTC-AS , SA 17974 2984 905 71 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2952 1108 2100 AKAMAI-ASN1 , US 4766 2722 11133 741 KIXS-AS-KR Korea Telecom, KR 9829 2692 1499 535 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 3712 3462 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3614 3462 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3527 3348 Telmex Colombia S.A., CO 6327 3251 3169 SHAW - Shaw Communications Inc., CA 39891 3141 3124 ALJAWWALSTC-AS , SA 17974 2984 2913 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2253 2220 CMNET-GD Guangdong Mobile Communication 9121 2267 2172 TTNET , TR 9829 2692 2157 BSNL-NIB National Internet Backbone, IN 18566 2195 2086 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65001 PRIVATE 5.143.176.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/20 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.192.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.200.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.208.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65001 PRIVATE 31.172.216.0/21 15468 KLGELECS-AS 38, Teatralnaya st 65000 PRIVATE 31.219.177.0/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65000 PRIVATE 31.219.177.128/25 8966 ETISALAT-AS P.O. Box 1150, Dub 65001 PRIVATE 46.237.32.0/20 13118 ASN-YARTELECOM PJSC Rostelecom 65001 PRIVATE 94.242.128.0/20 15468 KLGELECS-AS 38, Teatralnaya st Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55763 UNKNOWN 14.128.12.0/24 55763 UNKNOWN 14.128.13.0/24 55763 UNKNOWN 14.128.15.0/24 55763 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 41.62.1.0/24 19136 NNET, ZA 41.73.16.0/24 37004 Suburban-Broadband-AS, NG 41.73.17.0/24 37004 Suburban-Broadband-AS, NG 41.73.18.0/24 37004 Suburban-Broadband-AS, NG 41.73.19.0/24 37004 Suburban-Broadband-AS, NG Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:13 /10:36 /11:103 /12:276 /13:530 /14:1049 /15:1801 /16:13173 /17:7811 /18:13022 /19:25260 /20:38054 /21:40602 /22:73135 /23:61420 /24:349161 /25:548 /26:411 /27:312 /28:29 /29:16 /30:17 /31:0 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3047 3251 SHAW - Shaw Communications Inc., CA 39891 2896 3141 ALJAWWALSTC-AS , SA 22773 2815 3614 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2088 2195 MEGAPATH5-US - MegaPath Corporation, US 9121 1576 2267 TTNET , TR 30036 1559 1747 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 10620 1446 3527 Telmex Colombia S.A., CO 6389 1393 2095 BELLSOUTH-NET-BLK - BellSouth.net Inc., 13188 1348 1603 TRIOLAN , UA 6983 1323 1676 ITCDELTA - Earthlink, Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1585 2:820 4:23 5:2416 6:32 8:1023 12:1811 13:65 14:1780 15:24 16:2 17:104 18:124 19:1 20:51 23:2003 24:1802 27:2400 31:1839 32:83 33:11 34:1 35:3 36:376 37:2479 38:1301 39:44 40:99 41:2969 42:455 43:1908 44:52 45:2283 46:2530 47:120 49:1201 50:951 51:15 52:616 54:355 55:7 56:4 57:40 58:1599 59:975 60:388 61:1863 62:1498 63:1926 64:4538 65:2177 66:4393 67:2215 68:1167 69:3293 70:1303 71:560 72:2058 74:2594 75:404 76:412 77:1419 78:1574 79:915 80:1360 81:1420 82:967 83:722 84:862 85:1689 86:487 87:1129 88:782 89:2050 90:196 91:6099 92:967 93:2373 94:2350 95:2767 96:564 97:359 98:945 99:93 100:148 101:1200 103:13120 104:2632 105:146 106:474 107:1499 108:774 109:2540 110:1280 111:1659 112:1131 113:1172 114:1004 115:1634 116:1680 117:1569 118:2112 119:1590 120:942 121:1074 122:2282 123:2005 124:1599 125:1828 128:709 129:481 130:432 131:1388 132:622 133:187 134:528 135:210 136:385 137:393 138:1819 139:452 140:621 141:474 142:723 143:895 144:752 145:168 146:965 147:647 148:1364 149:559 150:683 151:798 152:703 153:313 154:720 155:950 156:545 157:564 158:427 159:1343 160:564 161:732 162:2452 163:535 164:778 165:1139 166:361 167:1234 168:2459 169:721 170:2519 171:264 172:865 173:1827 174:781 175:718 176:1751 177:4184 178:2423 179:1156 180:2063 181:1946 182:2163 183:1012 184:837 185:8343 186:3218 187:2244 188:2330 189:1780 190:7983 191:1294 192:9295 193:5768 194:4557 195:3859 196:1866 197:1244 198:5590 199:5818 200:7226 201:4142 202:10137 203:9822 204:4462 205:2771 206:2971 207:3170 208:4018 209:3899 210:3907 211:2079 212:2786 213:2453 214:847 215:66 216:5767 217:1974 218:824 219:600 220:1668 221:895 222:727 223:1103 End of report From msa at latt.net Fri Dec 30 18:19:48 2016 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 30 Dec 2016 13:19:48 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: <4ef1d708-5302-15df-23fb-b942f1651af1@coldnorthadmin.com> References: <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> <4ef1d708-5302-15df-23fb-b942f1651af1@coldnorthadmin.com> Message-ID: <20161230181948.GA28243@puck.nether.net> On Thu, Dec 22, 2016 at 11:31:08PM -0500, Laurent Dumont wrote: > What I mostly meant is that there should be a regulated, industry-wide > effort in order to provide a stable and active pool program. With the > current models, a protocol that is widely used by commercial devices is > being supported by the time and effort of volunteers around the world. Who's authoritative for time? Even the national labs aren't -- UTC is figured well after the fact. Thing about the pool is -- you may use it, you don't have to. You're welcome to provide your own services, including to your customers. There has to be one sole DNS -- there isn't one sole source of time. --msa From allan at allan.org Fri Dec 30 19:08:50 2016 From: allan at allan.org (Allan Liska) Date: Fri, 30 Dec 2016 14:08:50 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: <20161230181948.GA28243@puck.nether.net> References: <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> <4ef1d708-5302-15df-23fb-b942f1651af1@coldnorthadmin.com> <20161230181948.GA28243@puck.nether.net> Message-ID: <20161230190850.9FDAAE0372@smtp.hushmail.com> On 12/30/2016 at 1:20 PM, "Majdi S. Abbas" wrote:On Thu, Dec 22, 2016 at 11:31:08PM -0500, Laurent Dumont wrote: > What I mostly meant is that there should be a regulated, industry-wide > effort in order to provide a stable and active pool program. With the > current models, a protocol that is widely used by commercial devices is > being supported by the time and effort of volunteers around the world. Who's authoritative for time? Even the national labs aren't -- UTC is figured well after the fact. In the United States that would the United States Naval Observatory (USNO) Master Clock (http://tycho.usno.navy.mil/). You can read more about it here: http://motherboard.vice.com/read/demetrios-matsakis-and-the-master-clock allan From emille at abccommunications.com Fri Dec 30 19:26:18 2016 From: emille at abccommunications.com (Emille Blanc) Date: Fri, 30 Dec 2016 11:26:18 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <20161230190850.9FDAAE0372@smtp.hushmail.com> References: <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> <4ef1d708-5302-15df-23fb-b942f1651af1@coldnorthadmin.com> <20161230181948.GA28243@puck.nether.net> <20161230190850.9FDAAE0372@smtp.hushmail.com> Message-ID: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DEDFFEA@exchange> Ah, but who do you trust? Trump, Putin, or Xi's clock? That said, we use a Stratum2 clock for our AS, which syncs using GPS at $dayjob. So... I guess we trust Trump's clock. Perhaps there's a market for a device that takes GPS, GLONASS, and Beidou, and references the three for sanity checks in the event of $unforseen_circumstance. Assuming such a thing were possible - admittedly I know little about GLONASS, and even less about Beidou. "Perhaps some kind of death clock?" -----Original Message----- From: NANOG [mailto:nanog-bounces+emille=abccommunications.com at nanog.org] On Behalf Of Allan Liska Sent: December-30-16 11:09 AM To: Majdi S. Abbas; Laurent Dumont Cc: nanog at nanog.org Subject: Re: Recent NTP pool traffic increase On 12/30/2016 at 1:20 PM, "Majdi S. Abbas" wrote:On Thu, Dec 22, 2016 at 11:31:08PM -0500, Laurent Dumont wrote: > What I mostly meant is that there should be a regulated, industry-wide > effort in order to provide a stable and active pool program. With the > current models, a protocol that is widely used by commercial devices is > being supported by the time and effort of volunteers around the world. Who's authoritative for time? Even the national labs aren't -- UTC is figured well after the fact. In the United States that would the United States Naval Observatory (USNO) Master Clock (http://tycho.usno.navy.mil/). You can read more about it here: http://motherboard.vice.com/read/demetrios-matsakis-and-the-master-clock allan From allan at allan.org Fri Dec 30 19:31:52 2016 From: allan at allan.org (Allan Liska) Date: Fri, 30 Dec 2016 14:31:52 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DEDFFEA@exchange> References: <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> <4ef1d708-5302-15df-23fb-b942f1651af1@coldnorthadmin.com> <20161230181948.GA28243@puck.nether.net> <20161230190850.9FDAAE0372@smtp.hushmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DEDFFEA@exchange> Message-ID: <20161230193153.1C8F0E0372@smtp.hushmail.com> On 12/30/2016 at 2:26 PM, "Emille Blanc" wrote:Ah, but who do you trust? Trump, Putin, or Xi's clock? That said, we use a Stratum2 clock for our AS, which syncs using GPS at $dayjob. So... I guess we trust Trump's clock. Perhaps there's a market for a device that takes GPS, GLONASS, and Beidou, and references the three for sanity checks in the event of $unforseen_circumstance. Assuming such a thing were possible - admittedly I know little about GLONASS, and even less about Beidou. "Perhaps some kind of death clock?" Personally, when it goes online, I plan on trusting the "Jeff Bezos" clock :) http://www.10000yearclock.net/ allan From jeffm at iglou.com Fri Dec 30 19:34:51 2016 From: jeffm at iglou.com (Jeff McAdams) Date: Fri, 30 Dec 2016 14:34:51 -0500 (EST) Subject: Recent NTP pool traffic increase In-Reply-To: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DEDFFEA@exchange> References: <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> <4ef1d708-5302-15df-23fb-b942f1651af1@coldnorthadmin.com> <20161230181948.GA28243@puck.nether.net> <20161230190850.9FDAAE0372@smtp.hushmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DEDFFEA@exchange> Message-ID: <48636.64.6.220.221.1483126491.iglou@webmail.iglou.com> On Fri, December 30, 2016 14:26, Emille Blanc wrote: > Ah, but who do you trust? Trump, Putin, or Xi's clock? > > > That said, we use a Stratum2 clock for our AS, which syncs using GPS at > $dayjob. So... I guess we trust Trump's clock. > > > Perhaps there's a market for a device that takes GPS, GLONASS, and > Beidou, and references the three for sanity checks in the event of > $unforseen_circumstance. Assuming such a thing were possible - admittedly > I know little about GLONASS, and even less about Beidou. I was casually (yes, really) looking around at some GNSS modules available the other day, and readily found quite affordable ones that can receive at least 2 at a time, of those systems. GPS and GLONASS being the most complete, so probably the best bang-for-the-buck. I'm only an armchair time-nut, so I can't really speak to their precision and such, so this is very much a FWIW post. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces+emille=abccommunications.com at nanog.org] > On Behalf Of Allan Liska > Sent: December-30-16 11:09 AM > To: Majdi S. Abbas; Laurent Dumont > Cc: nanog at nanog.org > Subject: Re: Recent NTP pool traffic increase > > > > On 12/30/2016 at 1:20 PM, "Majdi S. Abbas" wrote:On Thu, Dec 22, 2016 > at 11:31:08PM -0500, Laurent Dumont wrote: >> What I mostly meant is that there should be a regulated, >> > industry-wide >> effort in order to provide a stable and active pool program. With > the >> current models, a protocol that is widely used by commercial devices > is >> being supported by the time and effort of volunteers around the > world. > > Who's authoritative for time? Even the national labs aren't -- > UTC is figured well after the fact. > > > In the United States that would the United States Naval Observatory > (USNO) Master Clock (http://tycho.usno.navy.mil/). You can read more > about it here: > http://motherboard.vice.com/read/demetrios-matsakis-and-the-master-clock > > > allan > > > -- Jeff From msa at latt.net Fri Dec 30 21:04:15 2016 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 30 Dec 2016 16:04:15 -0500 Subject: Recent NTP pool traffic increase In-Reply-To: <20161230190850.9FDAAE0372@smtp.hushmail.com> References: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> <4ef1d708-5302-15df-23fb-b942f1651af1@coldnorthadmin.com> <20161230181948.GA28243@puck.nether.net> <20161230190850.9FDAAE0372@smtp.hushmail.com> Message-ID: <20161230210415.GA28330@puck.nether.net> On Fri, Dec 30, 2016 at 02:08:50PM -0500, Allan Liska wrote: > In the United States that would the United States Naval Observatory > (USNO) Master Clock (http://tycho.usno.navy.mil/). You can read more > about it here: > http://motherboard.vice.com/read/demetrios-matsakis-and-the-master-clock One of the things I have learned as a time hobbyist is that if something involves time, and you think there is a simple answer, you are probably wrong. :) USNO is our military time keeper -- NIST keeps time for civil purposes, and while they coordinate to stay in reasonably close proximity, even they don't agree. Even better, the GPS clocks are run by (and corrections distributed) by the Air Force, not the Navy. And they have made mistakes in recent memory. From an international perspective, BIPM is responsible for UTC, but it is only figured well after the fact. We distribute "UTC" via NTP, but it's not true UTC since that is not figured in real time, it's much, much coarser, and everyone's local views differ anyway. For an idea just how many components there are, take a look at BIPM's Circular T: ftp://ftp2.bipm.org/pub/tai//Circular-T/cirthtm/cirt.347.html But back to the point...while UTC is an international time scale, individual national labs and institutions keep their own views of it, and correct periodically...then they distribute these timescales, and in some fashion we attempt to get a coarse version of it onto the Internet in real time. There is no one authority responsible for this, and you may take time from any one (or more) of them that you choose. And for this reason, there is no single authority for time distribution on the Internet -- because there is none for the world as a whole, either. We /can/ have an authoritative system for something like host naming, where it's comparatively easy to produce a single authoritative source. Timing is not nearly such a simple subject. Cheers, --msa From Bobin.Joseph at mitchell.com Fri Dec 30 16:55:11 2016 From: Bobin.Joseph at mitchell.com (Bobin Joseph) Date: Fri, 30 Dec 2016 16:55:11 +0000 Subject: SYN Floods from Verizon in the Midwest-Chicago area? Message-ID: <7b8ed65aec7441529024fcca4195e9d9@mail210ntv.corp.int> Wondering if anyone noticed issues with customers coming from Verizon's handoff in Chicago - 204.255.168.61? We have couple of customers with Verizon that seem to have been flooding us with SYN's. It seems Verizon has acknowledged this, but as we are not customers of VZN, we have no information about this. The SYN floods stopped around 10:20 PST on 12/29. Had enough impact to cause a minor outage. Thanks, Bobin Joseph From stenn at nwtime.org Fri Dec 30 21:43:14 2016 From: stenn at nwtime.org (Harlan Stenn) Date: Fri, 30 Dec 2016 13:43:14 -0800 Subject: Recent NTP pool traffic increase In-Reply-To: <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DEDFFEA@exchange> References: <20161220172623.0af945c8@spidey.rellim.com> <86B7426F-6729-4F39-8C88-97B782959A16@gmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DBC986F@exchange> <30C1C33C-2AE3-428A-BAD1-6B17DA236504@gmail.com> <8cec1456-7764-a109-8b96-3520d878bd7d@coldnorthadmin.com> <0422ebbf-ea2c-b21b-9f69-a47b181fa4a2@nwtime.org> <90DC2DDB-B740-435F-A4E1-CF6E292EE696@develooper.com> <6b1300b1-866c-a0ce-14a3-390aaea17911@nwtime.org> <4ef1d708-5302-15df-23fb-b942f1651af1@coldnorthadmin.com> <20161230181948.GA28243@puck.nether.net> <20161230190850.9FDAAE0372@smtp.hushmail.com> <4FBAFC2ECF5D6244BA4A26C1C94A1E270D5DEDFFEA@exchange> Message-ID: <0b069b66-88e1-ad75-185c-58749c5fdb9c@nwtime.org> On 12/30/16 11:26 AM, Emille Blanc wrote: > Ah, but who do you trust? Trump, Putin, or Xi's clock? > > That said, we use a Stratum2 clock for our AS, which syncs using GPS > at $dayjob. So... I guess we trust Trump's clock. > > Perhaps there's a market for a device that takes GPS, GLONASS, and > Beidou, and references the three for sanity checks in the event of > $unforseen_circumstance. Assuming such a thing were possible - > admittedly I know little about GLONASS, and even less about Beidou. Why are you trying to re-invent a properly configured S2 NTP server? H -- > "Perhaps some kind of death clock?" > > -----Original Message----- From: NANOG > [mailto:nanog-bounces+emille=abccommunications.com at nanog.org] On > Behalf Of Allan Liska Sent: December-30-16 11:09 AM To: Majdi S. > Abbas; Laurent Dumont Cc: nanog at nanog.org Subject: Re: Recent NTP > pool traffic increase > > > On 12/30/2016 at 1:20 PM, "Majdi S. Abbas" wrote:On Thu, Dec 22, > 2016 at 11:31:08PM -0500, Laurent Dumont wrote: >> What I mostly meant is that there should be a regulated, > industry-wide >> effort in order to provide a stable and active pool program. With > the >> current models, a protocol that is widely used by commercial >> devices > is >> being supported by the time and effort of volunteers around the > world. > > Who's authoritative for time? Even the national labs aren't -- UTC is > figured well after the fact. > > In the United States that would the United States Naval Observatory > (USNO) Master Clock (http://tycho.usno.navy.mil/). You can read > more about it here: > http://motherboard.vice.com/read/demetrios-matsakis-and-the-master-clock > > allan > > -- Harlan Stenn http://networktimefoundation.org - be a member! From bzs at theworld.com Fri Dec 30 21:48:35 2016 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 30 Dec 2016 16:48:35 -0500 Subject: Quick name and shame -- Apologies but... Message-ID: <22630.54835.993061.196167@gargle.gargle.HOWL> For years, YEARS, Microsoft's OUTLOOK.COM has flooded us with this sort of dictionary spamming on a daily basis. Is there anyone at MS who cares? Surely it's not that difficult to notice someone is blasting stuff like this from your servers every single day for years? Or are your servers just an out of control free-for-all? Do you even know who is using them? If you need another few zillion records like this for motivation just ask. 2016-12-30T16:34:29.342803-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus1 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] 2016-12-30T16:34:29.593566-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus2 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] 2016-12-30T16:34:29.844258-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus3 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] 2016-12-30T16:34:30.094905-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus4 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] 2016-12-30T16:35:23.984284-05:00 pcls5 sendmail[7053]: NOUSER: ehansen1 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:35:24.235025-05:00 pcls5 sendmail[7053]: NOUSER: ehansen10 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:35:24.485697-05:00 pcls5 sendmail[7053]: NOUSER: ehansen5 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:35:24.736408-05:00 pcls5 sendmail[7053]: NOUSER: ehansen2 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:35:24.987137-05:00 pcls5 sendmail[7053]: NOUSER: ehansen3 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] 2016-12-30T16:36:01.134355-05:00 pcls5 sendmail[7889]: NOUSER: efd5 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:36:01.385161-05:00 pcls5 sendmail[7889]: NOUSER: efd6 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:36:01.635940-05:00 pcls5 sendmail[7889]: NOUSER: efd7 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:36:01.886771-05:00 pcls5 sendmail[7889]: NOUSER: efd8 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:36:02.137626-05:00 pcls5 sendmail[7889]: NOUSER: efd9 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] 2016-12-30T16:41:25.012620-05:00 pcls5 sendmail[15054]: NOUSER: josephl6 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] 2016-12-30T16:41:25.263296-05:00 pcls5 sendmail[15054]: NOUSER: josephl4 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] 2016-12-30T16:41:25.514058-05:00 pcls5 sendmail[15054]: NOUSER: josephl7 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] 2016-12-30T16:41:25.764786-05:00 pcls5 sendmail[15054]: NOUSER: josephl8 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] 2016-12-30T16:41:26.015469-05:00 pcls5 sendmail[15054]: NOUSER: josephl5 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From aaron at heyaaron.com Sat Dec 31 00:19:55 2016 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 30 Dec 2016 16:19:55 -0800 Subject: Quick name and shame -- Apologies but... In-Reply-To: <22630.54835.993061.196167@gargle.gargle.HOWL> References: <22630.54835.993061.196167@gargle.gargle.HOWL> Message-ID: You might try the mailop mailing list. A few MS staff lurk there and might be able to shed some light. -A On Fri, Dec 30, 2016 at 1:48 PM, wrote: > > For years, YEARS, Microsoft's OUTLOOK.COM has flooded us with this > sort of dictionary spamming on a daily basis. > > Is there anyone at MS who cares? > > Surely it's not that difficult to notice someone is blasting stuff > like this from your servers every single day for years? Or are your > servers just an out of control free-for-all? Do you even know who is > using them? > > If you need another few zillion records like this for motivation just > ask. > > 2016-12-30T16:34:29.342803-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus1 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] > 2016-12-30T16:34:29.593566-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus2 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] > 2016-12-30T16:34:29.844258-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus3 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] > 2016-12-30T16:34:30.094905-05:00 pcls5 sendmail[5627]: NOUSER: jmarkus4 relay=mail-bn3nam01on0058.outbound.protection.outlook.com [104.47.33.58] > 2016-12-30T16:35:23.984284-05:00 pcls5 sendmail[7053]: NOUSER: ehansen1 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] > 2016-12-30T16:35:24.235025-05:00 pcls5 sendmail[7053]: NOUSER: ehansen10 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] > 2016-12-30T16:35:24.485697-05:00 pcls5 sendmail[7053]: NOUSER: ehansen5 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] > 2016-12-30T16:35:24.736408-05:00 pcls5 sendmail[7053]: NOUSER: ehansen2 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] > 2016-12-30T16:35:24.987137-05:00 pcls5 sendmail[7053]: NOUSER: ehansen3 relay=mail-sn1nam02hn0244.outbound.protection.outlook.com [104.47.36.244] > 2016-12-30T16:36:01.134355-05:00 pcls5 sendmail[7889]: NOUSER: efd5 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] > 2016-12-30T16:36:01.385161-05:00 pcls5 sendmail[7889]: NOUSER: efd6 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] > 2016-12-30T16:36:01.635940-05:00 pcls5 sendmail[7889]: NOUSER: efd7 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] > 2016-12-30T16:36:01.886771-05:00 pcls5 sendmail[7889]: NOUSER: efd8 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] > 2016-12-30T16:36:02.137626-05:00 pcls5 sendmail[7889]: NOUSER: efd9 relay=mail-bl2nam02hn0233.outbound.protection.outlook.com [104.47.38.233] > 2016-12-30T16:41:25.012620-05:00 pcls5 sendmail[15054]: NOUSER: josephl6 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] > 2016-12-30T16:41:25.263296-05:00 pcls5 sendmail[15054]: NOUSER: josephl4 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] > 2016-12-30T16:41:25.514058-05:00 pcls5 sendmail[15054]: NOUSER: josephl7 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] > 2016-12-30T16:41:25.764786-05:00 pcls5 sendmail[15054]: NOUSER: josephl8 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] > 2016-12-30T16:41:26.015469-05:00 pcls5 sendmail[15054]: NOUSER: josephl5 relay=mail-dm3nam03hn0218.outbound.protection.outlook.com [104.47.41.218] > > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo*