From amitchell at isipp.com Tue Aug 1 17:19:01 2017 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Tue, 1 Aug 2017 11:19:01 -0600 Subject: Contact at Orange? Message-ID: <63B054EA-7CB9-4AAD-93F8-095DF12C5D82@isipp.com> Does anybody here have a contact at Orange? Asking for a colleague. Thank you! Anne Anne P. Mitchell, Attorney at Law Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Elevations Credit Union Member Council Member, Board of Directors, Asilomar Microcomputer Workshop Member, Board of Directors, Greenwood Wildlife Rehabilitation Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From job at instituut.net Tue Aug 1 17:54:47 2017 From: job at instituut.net (Job Snijders) Date: Tue, 01 Aug 2017 17:54:47 +0000 Subject: Contact at Orange? In-Reply-To: <63B054EA-7CB9-4AAD-93F8-095DF12C5D82@isipp.com> References: <63B054EA-7CB9-4AAD-93F8-095DF12C5D82@isipp.com> Message-ID: Hi Anne, You aren't very specific about what you are looking for. Orange has many business units and subsidiaries. Are you looking for sales contacts or investor relations? Kind regards, Job ps. Do you think it's possible to make your footer somewhat longer? It doesn't quite yet fill a 28" screen. :-) On Tue, 1 Aug 2017 at 19:24, Anne P. Mitchell Esq. wrote: > Does anybody here have a contact at Orange? Asking for a colleague. > > Thank you! > > Anne > > Anne P. Mitchell, > Attorney at Law > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Legislative Consultant > CEO/President, Institute for Social Internet Public Policy > Member, Cal. Bar Cyberspace Law Committee > Member, Colorado Cyber Committee > Member, Elevations Credit Union Member Council > Member, Board of Directors, Asilomar Microcomputer Workshop > Member, Board of Directors, Greenwood Wildlife Rehabilitation > Ret. Professor of Law, Lincoln Law School of San Jose > Ret. Chair, Asilomar Microcomputer Workshop > > From rfg at tristatelogic.com Wed Aug 2 07:36:27 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 02 Aug 2017 00:36:27 -0700 Subject: AS202746 Hijacks: Is Telia (a) stupid, or (b) lazy, or (c) complicit? Message-ID: <7098.1501659387@segfault.tristatelogic.com> The annotations in the RIPE WHOIS record for AS202746 seem pretty clear to me. This thing is B-O-G-U-S! Even RIPE, which is always reticent to say any bad things about any of its crooked customers... even after they have kicked them out of RIPE altogether, e.g. for being just toooooo obviously and blatantly crooked... was able to determine that this particular AS is rubbish, and said so, right in the WHOIS record: remarks: this object has been locked by the RIPE NCC pending deregistration So, you know, what's up with Telia (AS1299) which is the one and only peer of this stupid thing (AS202746)? I only ask because AS202746 is currently blatantly and obviously hijacking the following four separate Brazillian /22 blocks: 200.220.160.0/22 200.220.164.0/22 200.220.168.0/22 200.220.172.0/22 Unlike a lot of other cases I've seen of late, Telia can't even fall back on the lame excuse that "Oh! Gosh! We are only passing those routes through for our customer because they have corresponding route objects properly registered in the RIPE IRR telling us that it's A-OK for them to route this stuff." Whoever the actual hijacker is in this case, he/she/it didn't even bother to create bogus route objects in the RIPE data base, even though it is trivially easy for any criminal who can fog a mirror to do that. So, as the Subject line above says, I'd like to hear opinions on the following pertinent question: Is Telia (a) stupid, or (b) lazy, or (c) complicit? Vote early! Vote often! (I wouldn't even mind about these blatant hijackings if it were not for the fact that all of those hijacked /22 blocks have, quite predictably, been filed to the brim with outbound mail servers belonging to some snowshoe spammer... which is par for the course these days when it comes to IPv4 space hijackings.) Regards, rfg P.S. Over on some of the RIPE mailing lists, they've recently been discussing whether or not to continue allowing Joe Random Criminal to create totally unauthorized and totally unchecked/unverified (and typically bogus) route objects in the RIPE data base for so-called "out of region" IP address block resources. Of course, if anybody had any brains or any backbone over on that side of the pond, they would have done this already ten years ago. But such is the pace of change in the Old World, where even the most obvious things can't be implemented until everybody and his brother agrees, including even the stupid kid. My point, of course, is that even when and if those crazy europeans get around to doing the obviously rational thing... like locking the door to the bank before you leave at night... even that won't and wouldn't have made one wit of difference to this case of Telia's passing of the bogus/hijacked routes being announced by AS202746, which is ongoing, as we speak. There's no authority anywhere that I am aware of that is telling the Telia folks that it is OK for either them or their customer to pass out those routes. They are just doing it, because, quite obviously, they are being -paid- to do it, and screw everybody else. We can all just shut up and eat our spam, I guess. From morrowc.lists at gmail.com Wed Aug 2 08:19:06 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 2 Aug 2017 04:19:06 -0400 Subject: AS202746 Hijacks: Is Telia (a) stupid, or (b) lazy, or (c) complicit? In-Reply-To: <7098.1501659387@segfault.tristatelogic.com> References: <7098.1501659387@segfault.tristatelogic.com> Message-ID: On Wed, Aug 2, 2017 at 3:36 AM, Ronald F. Guilmette wrote: > > > P.S. Over on some of the RIPE mailing lists, they've recently been > discussing > whether or not to continue allowing Joe Random Criminal to create totally > unauthorized and totally unchecked/unverified (and typically bogus) route > objects in the RIPE data base for so-called "out of region" IP address > block > resources. Of course, if anybody had any brains or any backbone over on > that > side of the pond, they would have done this already ten years ago. But > such > is the pace of change in the Old World, where even the most obvious things > can't be implemented until everybody and his brother agrees, including even > the stupid kid. > There are/were providers which required RIPE-IRR registration to accept routes, I don't know that this is still the case, but it might account for unwillingness to remove 'out of region' content. As well, there are folk with space from more than just one RIR, who may have chosen (for a myriad of resaons) to centralize their IRR content on a single IRR. Sometimes your message is lost in the emotive editorializing :( From mark.tinka at seacom.mu Wed Aug 2 15:41:06 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 2 Aug 2017 17:41:06 +0200 Subject: SAFNOG-3: Program Agenda Message-ID: <2a634558-c22d-2fe9-2574-bbe7e146a453@seacom.mu> Hello all. It gives me great pleasure to inform you that the SAFNOG-3 program agenda has taken shape, and is already 70% full. You can view the program agenda at the URL below: http://safnog.org/#section-agenda If you are interested in presenting a paper at this year's SAFNOG meeting, please send your submission to the SAFNOG-3 Program Committee as soon as possible, at the URL below: https://papers.safnog.org/user/login.php?event=62 We expect to have a 100%-filled program by this time next week. We look forward to seeing you in Durban. Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee From benoit.panizzon at imp.ch Thu Aug 3 07:00:25 2017 From: benoit.panizzon at imp.ch (Benoit Panizzon) Date: Thu, 3 Aug 2017 09:00:25 +0200 Subject: Contact at Orange? In-Reply-To: <63B054EA-7CB9-4AAD-93F8-095DF12C5D82@isipp.com> References: <63B054EA-7CB9-4AAD-93F8-095DF12C5D82@isipp.com> Message-ID: <20170803090025.5255d28b@go.imp.ch> Hi In 2013/2014 we also had to deal with a massive spam spike from orange.fr Our stats showed that the spam to ham ratio was at about 95% or higher from their 'mailserver' IP Range. After sending several emails to their different abuse and postmaster email addresses and trying to escalate the problem via orange.ch (now salt), as a last resort we blacklisted their whole IP Range via SWINOG Blacklist, which is used by many swiss ISP. This finally resulted in orange.fr getting in contact with us. Apparently the do receive and look at emails at their normal abuse contact address. But they never bother to reply, especially when they do not feel responsible for the specific IP addresses, even if they are in their range. The problem at that time was, that they had leased a part of their IP range to one of their branches in eastern europe and this branch had somehow been massively abused by spamers. After they were able to tell me which IP ranges belonged to their 'east europe' branch, we could shrink the blocked range to those specific ip addresses and this was also fine with their abuse desk, because they could clearly see the problem and more or less confirmed their colleagues in eastern europe apparently did not care so much about spam or being listed in anti-spam blacklists. Apparently this was not their problem. So, yes, try their abuse contact email address, write in french if somehow possible, and make clear you need a reply. Hopefully this will help. Kind regards -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ From goemon at sasami.anime.net Thu Aug 3 07:19:07 2017 From: goemon at sasami.anime.net (Dan Hollis) Date: Thu, 3 Aug 2017 00:19:07 -0700 (PDT) Subject: Contact at Orange? In-Reply-To: <20170803090025.5255d28b@go.imp.ch> References: <63B054EA-7CB9-4AAD-93F8-095DF12C5D82@isipp.com> <20170803090025.5255d28b@go.imp.ch> Message-ID: On Thu, 3 Aug 2017, Benoit Panizzon wrote: > Apparently this was not their problem. As long as the money's green? -Dan From large.hadron.collider at gmx.com Thu Aug 3 07:22:47 2017 From: large.hadron.collider at gmx.com (LHC (k9m)) Date: Thu, 03 Aug 2017 00:22:47 -0700 Subject: Contact at Orange? In-Reply-To: References: <63B054EA-7CB9-4AAD-93F8-095DF12C5D82@isipp.com> <20170803090025.5255d28b@go.imp.ch> Message-ID: <031C4DBE-A67A-4A83-A4F1-40B8BF8F20A2@gmx.com> Wrong currency zone On August 3, 2017 12:19:07 AM PDT, Dan Hollis wrote: >On Thu, 3 Aug 2017, Benoit Panizzon wrote: >> Apparently this was not their problem. > >As long as the money's green? > >-Dan -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From rfg at tristatelogic.com Thu Aug 3 09:52:43 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 03 Aug 2017 02:52:43 -0700 Subject: Multicom Hijacks: Do you peer with these turkeys (AS35916)? Message-ID: <24545.1501753963@segfault.tristatelogic.com> Well, it took less than a day for my last missive here to get the hijacks associated with AS202746 (Nexus Webhosting) taken down. I guess that somebody must have smacked Telia upside the head with a clue-by-four at long last. So, with that out of the way, let's see what else I can accomplish this week. As I understand it, the theory is that the thing that keeps the entire Internet from descending into the final stages of a totally broken "tragedy of the commons" is peer pressure. As everyone knows, there is no "Internet Police", so the whole system relies on the ability and willingness of networks to de-peer from other networks when those other networks are demonstratably behaving badly. Let's find out if that actually works, in practice, shall we? According to bgp.he.net, the top three peers of AS35916 (Multacom) are as follows: AS2914 NTT America, Inc. AS3223 Voxility S.R.L. AS209 Qwest Communications Company, LLC I'd like help from any and all subscribers to this mailing list who might have contacts in these companies. I'd like you to call their attention to Multacom's routing of the following block specifically: 163.198.0.0/16 This is a long-abandoned Afrinic block belonging to a semi-defunct company called "Agrihold". In fact, this block was a part of the massive number of hijacked legacy Afrinic /16 blocks that I pointed out, right here on this maling list, way back last November: https://mailman.nanog.org/pipermail/nanog/2016-November/089164.html After that posting, whoever was responsible for all those blatant hijackings got cold feet, apparently, and stopped passing all of those bogus route announcements out through their pals at AS260, Xconnect24 Inc. And so, for a brief time at least, the wanton pillaging of legacy Afrinic /16 blocks, and the reselling of those stolen blocks to various snowshoe spammers stopped... for awhile. But it appears that on or about January 6th of this year, Mulutacom lept into the breach and re-hijacked both the 163.198.0.0/16 block and also the additional Afrinic legacy block, 160.115.0.0/16. (They apparently stopped routing this latter block some time ago, for reasons unknown. But that fact that Multacom was indeed routing this second purloined legacy Afrinic /16 block also is in the historical records now, and cannot be denied. Multicom's routing of both blocks began around January 6th or so of this year, 2017.) Just as a courtesy, I sent the block absconders at Multacom a short email, earlier today, asking them if they had an LOA which demonstrates that they have rights/permission to be routing the 163.198.0.0/16 block. Of course, the mystery person (noc@) who emailed me back claimed that they did, but unfortunately, he was not under oath at the time. I asked if he could show me a copy of this purported LOA, and I haven't heard back from anybody at Mulatcom ever since. I don't really think there is any big mystery here, nor do I think that Multacom has or had, at any time, any rights to be routing these two legacy Afrinic /16 blocks. But they have done so, and continue to do so, in the case of the 163.198.0.0/16 block at least, quite obviously because -somebody- is paying them to do it, even in the total absence of a legitimate LOA. And as it turns out, it is quite easy to figure out who Multacom has been routing these two hijacked legacy Afrinic /16 blocks both for and to. It's trivially easy to run a traceroute to any arbitrary IP address within the 163.198.0.0/16 block. No matter which one you pick, the traceroute always passes through a particular IP address, 178.250.191.162, before the remainder of the traceroute gets deliberately blocked. That IP address is registered *not* to some long lost African concern, but rather to a Romanian networking company called Architecture Iq Data S.R.L. That company itself is apparently owned by a fellow by the name of Alexandru ("Andrei") Stanciu who hails from the city of Suceava, Romania. (Note that this is apparently *not* the same Alexandru Stanciu who the FBI arrested on bank and wire fraud charges in 2014. That one apparently hailed from Bucharest.) Anyway, "networking" seems to be only one of our Mr. Stanciu's many and varied business interest. His networking company, Architecture Iq Data S.R.L. has a web site (http://architekiq.ro/) but it is "shallow" to say the least. Many, and perhaps evenmost of the links on the home page of that company's web site seem to lead nowhere. In cotrast, Mr. Stanciu has the following other well-developed web sites and companies: ads.com.ro promoart.ro largeformatprinting.ro Promoart S.R.L. Advertising Distribution Supplies S.R.L. Mostly, he seems to be in the advertising business, as evidenced by the above web sites, and also by his membership in the "Email Marketing Gurus" special interest group over on LinkedIn: https://ro.linkedin.com/in/alexandru-stanciu-8846aa12a Given Mr. Stanciu's apparent professonal interests, it is not really all that surprising that the two hijacked legacy Afrinic /16 blocks that Multacom has been kind enough to route... both for him and to him... do in fact seem to be associated with numerous domain names that obviously consist of just two random dictionary words smashed together, followed by either .com or .net. This exact motif is quite commonly used by and among many of the Internet's most prolific snowshoe spammers. And of course, Mr. Stanciu's snowshoe spamming domains would not be maximally productive unless they each had SPF TXT records attached... ones that would pass muster with the recipients of Mr. Stanciu's spams. Those SPF TXT records are listed here, along the relevant domain names: https://pastebin.com/raw/BbK2YGe6 (Whenever possible snowshoe spammers also like to be able to send out their spams from from IP addresses where they have already set up nicely mattching reverse DNS, because a lot of recipient mail servers these days just won't accept inbound email anymore from no-reverse-dns IP addreses. But unfortunately for Mr. Stanciu, and for Multacom, the fact that they both just sort of walked off with the 163.198.0.0/16 block means that although they can -route- that space, they can't get the authority to control the reverse DNS for this block delegated to them. In order to do that, they'd have to get permission to do reverse DNS for the block FROM THE REAL AND LEGITIMATE BLOCK OWNER. And since that ain't them, nor even anybody who even knows what these clever fellows are up to, they can't. So Mr. Stanciu is stuck sending out his spams in a sub-optimal way, without either matching reverse DNS or even *any* reverse DNS for the entire /16 block he's stolen. Sorry Mr. Stanciu! Sorry Multacom!) As anybody who understand this stuff will by now be utterly convinced, the legacy Afrinic address block, 163.198.0.0/16, has been hijacked, stolen, or whatever you prefer to call it, by Mr. Alexandru ("Andrei") Stanciu of Suceava, Romania, specifically for "snowshode" spamming purposes, and with the significant help and assistance of AS35916, aka Multacom Corporation of 16654 Soledad Canyon Rd #150, Canyon Country, Calfornia, 91387, which is actually the entity announcing the routes to this clearly illicitly "liberated" IP block. So now, would one or more of you kind folks on this list who are more fortunate than me, and who have connections please be so kind as to let the following entities know about what Multacom is acctually up to here? AS2914 NTT America, Inc. AS3223 Voxility S.R.L. AS209 Qwest Communications Company, LLC Maybe they won't care, but they should. Maybe we can find out if the notion of peer pressure... or perhaps even de-peer pressure... works as well in practice as it allegedly does in theory. Thanks for listening. Regards, rfg From job at ntt.net Thu Aug 3 10:23:51 2017 From: job at ntt.net (Job Snijders) Date: Thu, 3 Aug 2017 12:23:51 +0200 Subject: Multicom Hijacks: Do you peer with these turkeys (AS35916)? In-Reply-To: <24545.1501753963@segfault.tristatelogic.com> References: <24545.1501753963@segfault.tristatelogic.com> Message-ID: <20170803102351.2ssalavmk5icfbaz@hanna.meerval.net> Dear Ronald, Thanks for your report, we'll investigate. Kind regards, Job From math at sizone.org Thu Aug 3 11:21:01 2017 From: math at sizone.org (Ken Chase) Date: Thu, 3 Aug 2017 07:21:01 -0400 Subject: Multicom Hijacks: Do you peer with these turkeys (AS35916)? In-Reply-To: <20170803102351.2ssalavmk5icfbaz@hanna.meerval.net> References: <24545.1501753963@segfault.tristatelogic.com> <20170803102351.2ssalavmk5icfbaz@hanna.meerval.net> Message-ID: <20170803112101.GP22924@sizone.org> RIPE or one of dem dere responsible RIRs should hire him. I got a sales call in a few weeks with NTT, let's see if Job is successful and then I can be duly impressed and even more interested in their products. This shit actually matters, sometimes. /kc On Thu, Aug 03, 2017 at 12:23:51PM +0200, Job Snijders said: >Dear Ronald, > >Thanks for your report, we'll investigate. > >Kind regards, > >Job -- Ken Chase - math at sizone.org Guelph Canada From nanog at jima.us Thu Aug 3 12:24:42 2017 From: nanog at jima.us (Jima) Date: Thu, 3 Aug 2017 06:24:42 -0600 Subject: Multicom Hijacks: Do you peer with these turkeys (AS35916)? In-Reply-To: <20170803112101.GP22924@sizone.org> References: <24545.1501753963@segfault.tristatelogic.com> <20170803102351.2ssalavmk5icfbaz@hanna.meerval.net> <20170803112101.GP22924@sizone.org> Message-ID: <3a6c4f25-7208-ef62-961a-b0153a833d42@jima.us> A few years back, Ronald named-and-shamed my work's new carrier for facilitating a prefix hijacker on this very list. As luck would have it, I had a fresh, crisp business card from our sales rep, so I passed the (quite legitimate) grievance along, and a short time later, the hijacked prefixes had one less upstream. Years later now, I have a different job, and a circuit with AS209. I'll see if I can't scare someone up (if it's still active by the time I get into the office). Thanks Ronald. Rest assured that many of us remember. :-) Jima On 2017-08-03 05:21, Ken Chase wrote: > RIPE or one of dem dere responsible RIRs should hire him. > > I got a sales call in a few weeks with NTT, let's see if Job is successful > and then I can be duly impressed and even more interested in their products. > > This shit actually matters, sometimes. From rsk at gsp.org Thu Aug 3 12:56:30 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 3 Aug 2017 08:56:30 -0400 Subject: Multicom Hijacks: Do you peer with these turkeys (AS35916)? In-Reply-To: <24545.1501753963@segfault.tristatelogic.com> References: <24545.1501753963@segfault.tristatelogic.com> Message-ID: <20170803125630.GA30615@gsp.org> On Thu, Aug 03, 2017 at 02:52:43AM -0700, Ronald F. Guilmette wrote: > And of course, Mr. Stanciu's snowshoe spamming domains would not be > maximally productive unless they each had SPF TXT records attached [...] > > https://pastebin.com/raw/BbK2YGe6 FYI, 85 of the 101 domains listed here are have been picked up by various spammer domain detection methods in place here. I have no doubt that the other 16 either will be in due course or simply reflect an inadequacy in my methods. ---rsk From yang.yu.list at gmail.com Thu Aug 3 16:24:27 2017 From: yang.yu.list at gmail.com (Yang Yu) Date: Thu, 3 Aug 2017 11:24:27 -0500 Subject: Multicom Hijacks: Do you peer with these turkeys (AS35916)? In-Reply-To: <24545.1501753963@segfault.tristatelogic.com> References: <24545.1501753963@segfault.tristatelogic.com> Message-ID: Also AS57166 (single upstream AS29632 NetAssist) is likely hijacking 10 ASNs, and AS43659 (currently inactive). Both with mnt-by: D2INVEST-MNT. http://bgp.he.net/AS57166#_peers DATASTAR-MNT created 14 autnum and 31 route dummy objects in RIPE, on resources that looks abandoned (2 of them confirmed hijacking) https://apps.db.ripe.net/search/query.html?searchtext=DATASTAR-MNT&inverse=mnt-by;mnt-domains;mnt-irt;mnt-lower;mnt-nfy;mnt-ref;mnt-routes&bflag=true&source=RIPE#resultsAnchor Someone actually mentioned these back in Oct https://mailman.nanog.org/pipermail/nanog/2016-October/088487.html From nanog at jima.us Fri Aug 4 13:15:44 2017 From: nanog at jima.us (Jima) Date: Fri, 4 Aug 2017 07:15:44 -0600 Subject: Multicom Hijacks: Do you peer with these turkeys (AS35916)? In-Reply-To: <3a6c4f25-7208-ef62-961a-b0153a833d42@jima.us> References: <24545.1501753963@segfault.tristatelogic.com> <20170803102351.2ssalavmk5icfbaz@hanna.meerval.net> <20170803112101.GP22924@sizone.org> <3a6c4f25-7208-ef62-961a-b0153a833d42@jima.us> Message-ID: <6b3a5b90-5de0-ef56-28f5-d59d26df9dcd@jima.us> Oops, following up a bit late. I was told yesterday that AS209 blocked their acceptance of 163.198.0.0/16 from AS35916 based on a number of complaints, which unfortunately left a path via their peering with NTT (which I presume they can't filter for $reasons). But then a short time later AS35916 withdrew the announcement entirely, possibly because of the traffic engineering implications of that filtering (not sure). Short-term, it's a win, but long-term we may not have seen the last of this prefix. Jima On 2017-08-03 06:24, Jima wrote: > A few years back, Ronald named-and-shamed my work's new carrier for > facilitating a prefix hijacker on this very list. As luck would have it, > I had a fresh, crisp business card from our sales rep, so I passed the > (quite legitimate) grievance along, and a short time later, the hijacked > prefixes had one less upstream. > > Years later now, I have a different job, and a circuit with AS209. I'll > see if I can't scare someone up (if it's still active by the time I get > into the office). > > Thanks Ronald. Rest assured that many of us remember. :-) From KShah at primustel.ca Fri Aug 4 15:14:26 2017 From: KShah at primustel.ca (Krunal Shah) Date: Fri, 4 Aug 2017 15:14:26 +0000 Subject: Bell outage Message-ID: Does anyone know what is happening with Bell network at East Canada? http://canadianoutages.com/status/bell/map/ Krunal ________________________________ 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 deleskie at gmail.com Fri Aug 4 15:44:58 2017 From: deleskie at gmail.com (jim deleskie) Date: Fri, 4 Aug 2017 12:44:58 -0300 Subject: Bell outage In-Reply-To: References: Message-ID: Cell and the internet all down here from Bell and those sharing their towers, also 911 services. Banking / ATM also impacted, no idea reason though. -jim Mimir Networks www.mimirnetworks.com On Fri, Aug 4, 2017 at 12:14 PM, Krunal Shah wrote: > Does anyone know what is happening with Bell network at East Canada? > > http://canadianoutages.com/status/bell/map/ > > > Krunal > ________________________________ > > 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 rod.beck at unitedcablecompany.com Fri Aug 4 17:34:34 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 4 Aug 2017 17:34:34 +0000 Subject: Transparent Waves Message-ID: Can someone refer me to the ITU SPEC on transparent 10 gig wave service. I have a client is looking to lease two 10 gig waves but they do not want an Ethernet format. Just transparent. I want to make sure the carrier gets it right when they configure the service. Regards, Roderick. Roderick Beck Director of Global Sales United Cable Company DRG Undersea Consulting Affiliate Member www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From nanog at namor.ca Fri Aug 4 17:59:40 2017 From: nanog at namor.ca (J) Date: Fri, 04 Aug 2017 12:59:40 -0500 Subject: Bell outage In-Reply-To: References: Message-ID: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> https://www.theglobeandmail.com/news/national/much-of-atlantic-canada-loses-cellphone-service-in-widespread-outage/article35881182/ Apparently some fiber cut. No word on the exact model of construction equipment, yet, though. :\ ---- On Fri, 04 Aug 2017 10:14:26 -0500 Krunal Shah <KShah at primustel.ca> wrote ---- Does anyone know what is happening with Bell network at East Canada? http://canadianoutages.com/status/bell/map/ Krunal ________________________________ 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 cscora at apnic.net Fri Aug 4 18:02:41 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 Aug 2017 04:02:41 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170804180241.D8281DCB@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, SANOG, PacNOG, SAFNOG MENOG, CaribNOG, BJNOG, SDNOG, CMNOG, IRNOG 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 05 Aug, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 656011 Prefixes after maximum aggregation (per Origin AS): 255861 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 317134 Total ASes present in the Internet Routing Table: 57975 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 50148 Origin ASes announcing only one prefix: 22171 Transit ASes present in the Internet Routing Table: 7827 Transit-only ASes present in the Internet Routing Table: 216 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 56 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 116 Numnber of instances of unregistered ASNs: 120 Number of 32-bit ASNs allocated by the RIRs: 19624 Number of 32-bit ASNs visible in the Routing Table: 15352 Prefixes from 32-bit ASNs in the Routing Table: 62584 Number of bogon 32-bit ASNs visible in the Routing Table: 70 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 364 Number of addresses announced to Internet: 2851265636 Equivalent to 169 /8s, 242 /16s and 220 /24s Percentage of available address space announced: 77.0 Percentage of allocated address space announced: 77.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 218313 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 178729 Total APNIC prefixes after maximum aggregation: 51643 APNIC Deaggregation factor: 3.46 Prefixes being announced from the APNIC address blocks: 177767 Unique aggregates announced from the APNIC address blocks: 73944 APNIC Region origin ASes present in the Internet Routing Table: 8257 APNIC Prefixes per ASN: 21.53 APNIC Region origin ASes announcing only one prefix: 2297 APNIC Region transit ASes present in the Internet Routing Table: 1174 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 56 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3108 Number of APNIC addresses announced to Internet: 763858788 Equivalent to 45 /8s, 135 /16s and 143 /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: 200256 Total ARIN prefixes after maximum aggregation: 95322 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 202116 Unique aggregates announced from the ARIN address blocks: 93094 ARIN Region origin ASes present in the Internet Routing Table: 17944 ARIN Prefixes per ASN: 11.26 ARIN Region origin ASes announcing only one prefix: 6657 ARIN Region transit ASes present in the Internet Routing Table: 1776 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: 2124 Number of ARIN addresses announced to Internet: 1110239392 Equivalent to 66 /8s, 44 /16s and 232 /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: 175789 Total RIPE prefixes after maximum aggregation: 86316 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 171639 Unique aggregates announced from the RIPE address blocks: 103612 RIPE Region origin ASes present in the Internet Routing Table: 24244 RIPE Prefixes per ASN: 7.08 RIPE Region origin ASes announcing only one prefix: 11144 RIPE Region transit ASes present in the Internet Routing Table: 3428 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6052 Number of RIPE addresses announced to Internet: 713016704 Equivalent to 42 /8s, 127 /16s and 197 /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: 83955 Total LACNIC prefixes after maximum aggregation: 18720 LACNIC Deaggregation factor: 4.48 Prefixes being announced from the LACNIC address blocks: 85179 Unique aggregates announced from the LACNIC address blocks: 39225 LACNIC Region origin ASes present in the Internet Routing Table: 6216 LACNIC Prefixes per ASN: 13.70 LACNIC Region origin ASes announcing only one prefix: 1738 LACNIC Region transit ASes present in the Internet Routing Table: 1147 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 37 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3733 Number of LACNIC addresses announced to Internet: 170914016 Equivalent to 10 /8s, 47 /16s and 240 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 17164 Total AfriNIC prefixes after maximum aggregation: 3799 AfriNIC Deaggregation factor: 4.52 Prefixes being announced from the AfriNIC address blocks: 18946 Unique aggregates announced from the AfriNIC address blocks: 6951 AfriNIC Region origin ASes present in the Internet Routing Table: 1064 AfriNIC Prefixes per ASN: 17.81 AfriNIC Region origin ASes announcing only one prefix: 334 AfriNIC Region transit ASes present in the Internet Routing Table: 207 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: 335 Number of AfriNIC addresses announced to Internet: 92816128 Equivalent to 5 /8s, 136 /16s and 67 /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 5459 4192 87 ERX-CERNET-BKB China Education and Rese 7545 4003 407 389 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2967 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2799 11124 745 KIXS-AS-KR Korea Telecom, KR 9829 2754 1498 549 BSNL-NIB National Internet Backbone, IN 9808 2353 8699 32 CMNET-GD Guangdong Mobile Communication 45899 2282 1449 106 VNPT-AS-VN VNPT Corp, VN 4755 2096 423 221 TATACOMM-AS TATA Communications formerl 7552 1663 1104 73 VIETEL-AS-AP Viettel Corporation, VN 9498 1614 361 144 BBIL-AP BHARTI Airtel Ltd., IN 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 3828 2953 159 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3450 1341 88 SHAW - Shaw Communications Inc., CA 18566 2209 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2043 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2020 2201 441 CHARTER-NET-HKY-NC - Charter Communicat 209 1858 5065 636 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1843 3861 590 AMAZON-02 - Amazon.com, Inc., US 30036 1819 328 290 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 6983 1697 854 231 ITCDELTA - Earthlink, Inc., US 701 1560 10559 629 UUNET - MCI Communications Services, In 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 3387 186 23 ALJAWWALSTC-AS, SA 20940 2960 969 2131 AKAMAI-ASN1, US 8551 2558 377 40 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2052 332 425 TELLCOM-AS, TR 9121 1924 1691 17 TTNET, TR 12479 1642 1048 59 UNI2-AS, ES 13188 1602 100 55 TRIOLAN, UA 12389 1523 1422 640 ROSTELECOM-AS, RU 6849 1225 355 21 UKRTELNET, UA 8402 1100 544 15 CORBINA-AS OJSC "Vimpelcom", 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 3549 543 203 Telmex Colombia S.A., CO 8151 2657 3402 578 Uninet S.A. de C.V., MX 11830 2103 370 65 Instituto Costarricense de Electricidad 6503 1557 437 53 Axtel, S.A.B. de C.V., MX 7303 1556 1015 244 Telecom Argentina S.A., AR 6147 1236 377 27 Telefonica del Peru S.A.A., PE 3816 1024 501 93 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 955 2277 194 CLARO S.A., BR 11172 916 126 86 Alestra, S. de R.L. de C.V., MX 18881 898 1052 23 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 1216 398 48 LINKdotNET-AS, EG 37611 745 91 8 Afrihost, ZA 36903 711 357 130 MT-MPLS, MA 36992 654 1377 27 ETISALAT-MISR, EG 24835 501 850 15 RAYA-AS, EG 29571 421 36 10 CITelecom-AS, CI 37492 406 320 75 ORANGE-, TN 15399 357 35 7 WANANCHI-, KE 8452 318 1730 17 TE-AS TE-AS, EG 2018 303 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 5459 4192 87 ERX-CERNET-BKB China Education and Rese 7545 4003 407 389 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3828 2953 159 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3549 543 203 Telmex Colombia S.A., CO 6327 3450 1341 88 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 17974 2967 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 20940 2960 969 2131 AKAMAI-ASN1, US 4766 2799 11124 745 KIXS-AS-KR Korea Telecom, KR 9829 2754 1498 549 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 3828 3669 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 4003 3614 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 6327 3450 3362 SHAW - Shaw Communications Inc., CA 10620 3549 3346 Telmex Colombia S.A., CO 17974 2967 2894 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8551 2558 2518 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9808 2353 2321 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2754 2205 BSNL-NIB National Internet Backbone, IN 45899 2282 2176 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65532 PRIVATE 14.192.19.0/24 132717 NDCTPL-IN NxtGen Datacenter & 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 4294901876 PRIVATE 59.101.19.0/24 2764 AAPT AAPT Limited, AU 4294902000 PRIVATE 59.101.45.0/24 2764 AAPT AAPT Limited, AU 4294901905 PRIVATE 59.101.49.0/24 2764 AAPT AAPT Limited, AU Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.79.12.0/22 37306 -Reserved AS-, ZZ 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:15 /9:13 /10:36 /11:105 /12:284 /13:553 /14:1050 /15:1852 /16:13458 /17:7646 /18:13427 /19:24665 /20:38988 /21:41551 /22:78192 /23:64918 /24:366995 /25:878 /26:631 /27:644 /28:37 /29:25 /30:18 /31:2 /32:28 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3246 3450 SHAW - Shaw Communications Inc., CA 22773 2996 3828 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2946 3387 ALJAWWALSTC-AS, SA 18566 2093 2209 MEGAPATH5-US - MegaPath Corporation, US 8551 2023 2558 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1603 1819 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1493 2103 Instituto Costarricense de Electricidad y Telec 10620 1489 3549 Telmex Colombia S.A., CO 11492 1395 1560 CABLEONE - CABLE ONE, INC., US 6389 1355 2043 BELLSOUTH-NET-BLK - BellSouth.net 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:810 4:18 5:2436 6:34 7:1 8:1054 12:1837 13:146 14:1715 15:27 16:2 17:161 18:90 20:61 23:2457 24:1911 25:2 27:2354 29:1 31:1913 32:84 33:18 35:21 36:386 37:2363 38:1329 39:65 40:97 41:2970 42:460 43:1963 44:77 45:2995 46:2821 47:157 49:1231 50:992 51:19 52:824 54:362 55:6 56:4 57:44 58:1557 59:1015 60:324 61:1932 62:1696 63:1912 64:4642 65:2219 66:4572 67:2286 68:1229 69:3360 70:1135 71:586 72:2211 74:2705 75:390 76:427 77:1517 78:1422 79:1952 80:1414 81:1386 82:997 83:720 84:958 85:1786 86:460 87:1184 88:751 89:2136 90:165 91:6202 92:991 93:2372 94:2406 95:2660 96:638 97:353 98:1049 99:93 100:153 101:1216 103:15519 104:3009 105:187 106:556 107:1784 108:824 109:2894 110:1471 111:1734 112:1234 113:1249 114:1042 115:1547 116:1633 117:1737 118:2151 119:1644 120:721 121:1081 122:2326 123:1822 124:1484 125:1802 128:854 129:649 130:436 131:1432 132:555 133:200 134:674 135:226 136:427 137:456 138:1916 139:499 140:399 141:604 142:774 143:867 144:813 145:183 146:1096 147:696 148:1488 149:588 150:707 151:973 152:704 153:300 154:856 155:753 156:641 157:657 158:471 159:1531 160:707 161:747 162:2518 163:534 164:928 165:1383 166:381 167:1254 168:2986 169:836 170:3467 171:332 172:1035 173:1989 174:813 175:746 176:1900 177:3982 178:2552 179:1146 180:2211 181:1904 182:2373 183:776 184:873 185:10328 186:3261 187:2216 188:2621 189:1789 190:8355 191:1334 192:9527 193:5793 194:4677 195:3909 196:2103 197:1336 198:5527 199:5904 200:7541 201:4304 202:10340 203:9974 204:4492 205:2830 206:3054 207:3145 208:3958 209:3984 210:3943 211:2097 212:2876 213:2503 214:857 215:66 216:5883 217:2124 218:889 219:597 220:1702 221:893 222:744 223:1191 End of report From deleskie at gmail.com Fri Aug 4 18:07:18 2017 From: deleskie at gmail.com (jim deleskie) Date: Fri, 4 Aug 2017 15:07:18 -0300 Subject: Bell outage In-Reply-To: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> Message-ID: Single fiber cut causes the much impact? -jim On Fri, Aug 4, 2017 at 2:59 PM, J wrote: > https://www.theglobeandmail.com/news/national/much-of- > atlantic-canada-loses-cellphone-service-in-widespread-outage/ > article35881182/ > > > > Apparently some fiber cut. No word on the exact model of construction > equipment, yet, though. > > > > :\ > > > > > ---- On Fri, 04 Aug 2017 10:14:26 -0500 Krunal Shah <KShah at primustel.ca> > wrote ---- > > > > > Does anyone know what is happening with Bell network at East Canada? > > > > http://canadianoutages.com/status/bell/map/ > > > > > > Krunal > > ________________________________ > > > > 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 rod.beck at unitedcablecompany.com Fri Aug 4 18:11:31 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 4 Aug 2017 18:11:31 +0000 Subject: Bell outage In-Reply-To: References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca>, Message-ID: Everyone has a resilient network until they don't. 😊 ________________________________ From: NANOG on behalf of jim deleskie Sent: Friday, August 4, 2017 8:07 PM To: J Cc: NANOG list Subject: Re: Bell outage Single fiber cut causes the much impact? -jim On Fri, Aug 4, 2017 at 2:59 PM, J wrote: > https://www.theglobeandmail.com/news/national/much-of- > atlantic-canada-loses-cellphone-service-in-widespread-outage/ > article35881182/ > > > > Apparently some fiber cut. No word on the exact model of construction > equipment, yet, though. > > > > :\ > > > > > ---- On Fri, 04 Aug 2017 10:14:26 -0500 Krunal Shah <KShah at primustel.ca> > wrote ---- > > > > > Does anyone know what is happening with Bell network at East Canada? > > > > http://canadianoutages.com/status/bell/map/ [http://canadianoutages.com/i/logo/bell.png] Bell down? Realtime status and problems overview ... canadianoutages.com Bell Canada offers internet, mobile phone and home phone services to individuals and businesses. Internet is delivered through DSL or fiber technology. > > > > > > Krunal > > ________________________________ > > > > 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 nate at dopedesign.com Fri Aug 4 18:14:16 2017 From: nate at dopedesign.com (Nate Metheny) Date: Fri, 4 Aug 2017 12:14:16 -0600 Subject: [SPAM] Re: Bell outage In-Reply-To: References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> Message-ID: :s/fiber/conduit On Fri, Aug 4, 2017 at 12:11 PM, Rod Beck wrote: > Everyone has a resilient network until they don't. 😊 > > > ________________________________ > From: NANOG on > behalf of jim deleskie > Sent: Friday, August 4, 2017 8:07 PM > To: J > Cc: NANOG list > Subject: Re: Bell outage > > Single fiber cut causes the much impact? > > -jim > > On Fri, Aug 4, 2017 at 2:59 PM, J wrote: > > > https://www.theglobeandmail.com/news/national/much-of- > > atlantic-canada-loses-cellphone-service-in-widespread-outage/ > > article35881182/ > > > > > > > > Apparently some fiber cut. No word on the exact model of construction > > equipment, yet, though. > > > > > > > > :\ > > > > > > > > > > ---- On Fri, 04 Aug 2017 10:14:26 -0500 Krunal Shah & > lt;KShah at primustel.ca> > > wrote ---- > > > > > > > > > > Does anyone know what is happening with Bell network at East Canada? > > > > > > > > http://canadianoutages.com/status/bell/map/ > [http://canadianoutages.com/i/logo/bell.png] canadianoutages.com/status/bell/map/> > > Bell down? Realtime status and problems overview ...< > http://canadianoutages.com/status/bell/map/> > canadianoutages.com > Bell Canada offers internet, mobile phone and home phone services to > individuals and businesses. Internet is delivered through DSL or fiber > technology. > > > > > > > > > > > > > > Krunal > > > > ________________________________ > > > > > > > > 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 > > > > > > > > > > > > > > > -- Nate Metheny natemetheny at gmail.com From aaron at heyaaron.com Fri Aug 4 18:47:55 2017 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 4 Aug 2017 11:47:55 -0700 Subject: [SPAM] Re: Bell outage In-Reply-To: References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> Message-ID: We have multiple redundant backup paths in case of a cut. The backup paths run about 1 mm away from the primary path in the same cable in the same conduit. ;) On Fri, Aug 4, 2017 at 11:14 AM, Nate Metheny wrote: > :s/fiber/conduit > > On Fri, Aug 4, 2017 at 12:11 PM, Rod Beck > wrote: > >> Everyone has a resilient network until they don't. 😊 >> >> >> ________________________________ >> From: NANOG on >> behalf of jim deleskie >> Sent: Friday, August 4, 2017 8:07 PM >> To: J >> Cc: NANOG list >> Subject: Re: Bell outage >> >> Single fiber cut causes the much impact? >> >> -jim >> >> On Fri, Aug 4, 2017 at 2:59 PM, J wrote: >> >> > https://www.theglobeandmail.com/news/national/much-of- >> > atlantic-canada-loses-cellphone-service-in-widespread-outage/ >> > article35881182/ >> > >> > >> > >> > Apparently some fiber cut. No word on the exact model of construction >> > equipment, yet, though. >> > >> > >> > >> > :\ >> > >> > >> > >> > >> > ---- On Fri, 04 Aug 2017 10:14:26 -0500 Krunal Shah & >> lt;KShah at primustel.ca> >> > wrote ---- >> > >> > >> > >> > >> > Does anyone know what is happening with Bell network at East Canada? >> > >> > >> > >> > http://canadianoutages.com/status/bell/map/ >> [http://canadianoutages.com/i/logo/bell.png]> canadianoutages.com/status/bell/map/> >> >> Bell down? Realtime status and problems overview ...< >> http://canadianoutages.com/status/bell/map/> >> canadianoutages.com >> Bell Canada offers internet, mobile phone and home phone services to >> individuals and businesses. Internet is delivered through DSL or fiber >> technology. >> >> >> > >> > >> > >> > >> > >> > Krunal >> > >> > ________________________________ >> > >> > >> > >> > 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 >> > >> > >> > >> > >> > >> > >> > >> > > > > -- > Nate Metheny > natemetheny at gmail.com From ahebert at pubnix.net Fri Aug 4 18:57:22 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 4 Aug 2017 14:57:22 -0400 Subject: Bell outage In-Reply-To: References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> Message-ID: <32ad418c-5849-fcc6-4390-b0109a3fec5f@pubnix.net> Well, Saying they provided you with geographically diverse circuits versus actually doing it, happen way too often. ----- 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 08/04/17 14:07, jim deleskie wrote: > Single fiber cut causes the much impact? > > -jim > > On Fri, Aug 4, 2017 at 2:59 PM, J wrote: > >> https://www.theglobeandmail.com/news/national/much-of- >> atlantic-canada-loses-cellphone-service-in-widespread-outage/ >> article35881182/ >> >> >> >> Apparently some fiber cut. No word on the exact model of construction >> equipment, yet, though. >> >> >> >> :\ >> >> >> >> >> ---- On Fri, 04 Aug 2017 10:14:26 -0500 Krunal Shah <KShah at primustel.ca> >> wrote ---- >> >> >> >> >> Does anyone know what is happening with Bell network at East Canada? >> >> >> >> http://canadianoutages.com/status/bell/map/ >> >> >> >> >> >> Krunal >> >> ________________________________ >> >> >> >> 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 math at sizone.org Fri Aug 4 19:07:40 2017 From: math at sizone.org (Ken Chase) Date: Fri, 4 Aug 2017 15:07:40 -0400 Subject: Bell outage In-Reply-To: <32ad418c-5849-fcc6-4390-b0109a3fec5f@pubnix.net> References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> <32ad418c-5849-fcc6-4390-b0109a3fec5f@pubnix.net> Message-ID: <20170804190740.GJ32614@sizone.org> And can be hard to know without serious dilligence - two of our upstreams happened to go through the same 360 networks conduit in montreal that "saw significant rodent activity". Both were down for 6 hours. A couple customers had some custom apps that relied on the two, each as redundancy to the other. That didnt work out. Getting salesdroids to give you the info can be very hard though, and even tech dept's may not know what secondary providers their fibres run through or where, readily. /kc On Fri, Aug 04, 2017 at 02:57:22PM -0400, Alain Hebert said: > Well, > > Saying they provided you with geographically diverse circuits versus >actually doing it, happen way too often. > >----- >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 -- Ken Chase - math at sizone.org Guelph Canada From nanog at ics-il.net Fri Aug 4 19:23:51 2017 From: nanog at ics-il.net (Mike Hammett) Date: Fri, 4 Aug 2017 14:23:51 -0500 (CDT) Subject: Bell outage In-Reply-To: <20170804190740.GJ32614@sizone.org> References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> <32ad418c-5849-fcc6-4390-b0109a3fec5f@pubnix.net> <20170804190740.GJ32614@sizone.org> Message-ID: <1901484531.1324.1501874626766.JavaMail.mhammett@ThunderFuck> They can still be incorrect, but KMZs or shapefiles of my route or no deal. Accurate ones too, none of this line running through the middle of a house crap. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Ken Chase" To: "Alain Hebert" Cc: nanog at nanog.org Sent: Friday, August 4, 2017 2:07:40 PM Subject: Re: Bell outage And can be hard to know without serious dilligence - two of our upstreams happened to go through the same 360 networks conduit in montreal that "saw significant rodent activity". Both were down for 6 hours. A couple customers had some custom apps that relied on the two, each as redundancy to the other. That didnt work out. Getting salesdroids to give you the info can be very hard though, and even tech dept's may not know what secondary providers their fibres run through or where, readily. /kc On Fri, Aug 04, 2017 at 02:57:22PM -0400, Alain Hebert said: > Well, > > Saying they provided you with geographically diverse circuits versus >actually doing it, happen way too often. > >----- >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 -- Ken Chase - math at sizone.org Guelph Canada From eric.kuhnke at gmail.com Fri Aug 4 19:44:24 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Fri, 4 Aug 2017 12:44:24 -0700 Subject: Bell outage In-Reply-To: <20170804190740.GJ32614@sizone.org> References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> <32ad418c-5849-fcc6-4390-b0109a3fec5f@pubnix.net> <20170804190740.GJ32614@sizone.org> Message-ID: Makes me wonder what the GIS department is like at $BIGCARRIER and how such a workgroup of specialists interfaces with their in house OSP fiber teams (and those responsible for acquiring IRUs, leasing and documenting third party dark, etc). On Fri, Aug 4, 2017 at 12:07 PM, Ken Chase wrote: > And can be hard to know without serious dilligence - two of our upstreams > happened to go through the same 360 networks conduit in montreal that "saw > significant rodent activity". Both were down for 6 hours. A couple > customers > had some custom apps that relied on the two, each as redundancy to the > other. > > That didnt work out. > > Getting salesdroids to give you the info can be very hard though, and even > tech dept's may not know what secondary providers their fibres run through > or > where, readily. > > /kc > > On Fri, Aug 04, 2017 at 02:57:22PM -0400, Alain Hebert said: > > Well, > > > > Saying they provided you with geographically diverse circuits versus > >actually doing it, happen way too often. > > > >----- > >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 > > -- > Ken Chase - math at sizone.org Guelph Canada > From SNaslund at medline.com Fri Aug 4 20:33:45 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 4 Aug 2017 20:33:45 +0000 Subject: Bell outage In-Reply-To: <1901484531.1324.1501874626766.JavaMail.mhammett@ThunderFuck> References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> <32ad418c-5849-fcc6-4390-b0109a3fec5f@pubnix.net> <20170804190740.GJ32614@sizone.org> <1901484531.1324.1501874626766.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B4023F751CC2@MUNPRDMBXA1.medline.com> It can be really impossible with multiple carriers because even if you get a geographically diverse route on day 1, carriers are constantly grooming and reconfiguring and since each carrier does not monitor the other ones architecture they cannot even know that they are ruining your redundancy by re-grooming circuits into the same physical paths. The only way you could even begin to know would be to demand regular updates of your circuits physical layout (if they will give it to you and they actual know what it is) and then you would just have to hope that a) their records are current and b) you don't get re-groomed that very same evening. If you request geo diversity from a single carrier, they should be able to check that they have diverse paths but you have to stay on them to ensure they stay that way. Steven Naslund Chicago IL From: "Ken Chase" To: "Alain Hebert" Cc: nanog at nanog.org Sent: Friday, August 4, 2017 2:07:40 PM Subject: Re: Bell outage And can be hard to know without serious dilligence - two of our upstreams happened to go through the same 360 networks conduit in montreal that "saw significant rodent activity". Both were down for 6 hours. A couple customers had some custom apps that relied on the two, each as redundancy to the other. That didnt work out. Getting salesdroids to give you the info can be very hard though, and even tech dept's may not know what secondary providers their fibres run through or where, readily. /kc On Fri, Aug 04, 2017 at 02:57:22PM -0400, Alain Hebert said: > Well, > > Saying they provided you with geographically diverse circuits versus >actually doing it, happen way too often. > >----- >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 -- Ken Chase - math at sizone.org Guelph Canada From ahebert at pubnix.net Fri Aug 4 20:34:15 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 4 Aug 2017 16:34:15 -0400 Subject: Bell outage In-Reply-To: <20170804190740.GJ32614@sizone.org> References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> <32ad418c-5849-fcc6-4390-b0109a3fec5f@pubnix.net> <20170804190740.GJ32614@sizone.org> Message-ID: Well, We have a case where 2 paths, between 151 front to somewhere in Markham, ended up overlapping 3 times for about 300m total :( And to cap the whole thing off... Enter the building thru the same conduit. You pretty much need to be onsite supervising the whole thing up. And yes their files have the circuits going thru a home, what looks like a gas station, an electrical grids, etc =D. Pretty impressive. PS: As rodent, you mean the punks that fire bomb "that" conduit under "that" bridge, a few years back? ----- 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 08/04/17 15:07, Ken Chase wrote: > And can be hard to know without serious dilligence - two of our upstreams > happened to go through the same 360 networks conduit in montreal that "saw > significant rodent activity". Both were down for 6 hours. A couple customers > had some custom apps that relied on the two, each as redundancy to the other. > > That didnt work out. > > Getting salesdroids to give you the info can be very hard though, and even > tech dept's may not know what secondary providers their fibres run through or > where, readily. > > /kc > > On Fri, Aug 04, 2017 at 02:57:22PM -0400, Alain Hebert said: > > Well, > > > > Saying they provided you with geographically diverse circuits versus > >actually doing it, happen way too often. > > > >----- > >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 rod.beck at unitedcablecompany.com Fri Aug 4 20:54:45 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 4 Aug 2017 20:54:45 +0000 Subject: Bell outage In-Reply-To: References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> <32ad418c-5849-fcc6-4390-b0109a3fec5f@pubnix.net> <20170804190740.GJ32614@sizone.org>, Message-ID: Well, imagine what happens when you have a body of water like Lake Ontario separating the key hubs on each side of the border, 151 Front Street and 350 Main Street. The fiber is probably stacked parallel around the lake and at certain points is collapsed into one right of way. - R. ________________________________ From: NANOG on behalf of Alain Hebert Sent: Friday, August 4, 2017 10:34 PM To: nanog at nanog.org Subject: Re: Bell outage Well, We have a case where 2 paths, between 151 front to somewhere in Markham, ended up overlapping 3 times for about 300m total :( And to cap the whole thing off... Enter the building thru the same conduit. You pretty much need to be onsite supervising the whole thing up. And yes their files have the circuits going thru a home, what looks like a gas station, an electrical grids, etc =D. Pretty impressive. PS: As rodent, you mean the punks that fire bomb "that" conduit under "that" bridge, a few years back? ----- 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 PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... On 08/04/17 15:07, Ken Chase wrote: > And can be hard to know without serious dilligence - two of our upstreams > happened to go through the same 360 networks conduit in montreal that "saw > significant rodent activity". Both were down for 6 hours. A couple customers > had some custom apps that relied on the two, each as redundancy to the other. > > That didnt work out. > > Getting salesdroids to give you the info can be very hard though, and even > tech dept's may not know what secondary providers their fibres run through or > where, readily. > > /kc > > On Fri, Aug 04, 2017 at 02:57:22PM -0400, Alain Hebert said: > > Well, > > > > Saying they provided you with geographically diverse circuits versus > >actually doing it, happen way too often. > > > >----- > >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 PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > From chk at pobox.com Fri Aug 4 21:06:36 2017 From: chk at pobox.com (Harald Koch) Date: Fri, 4 Aug 2017 17:06:36 -0400 Subject: Bell outage In-Reply-To: References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> <32ad418c-5849-fcc6-4390-b0109a3fec5f@pubnix.net> <20170804190740.GJ32614@sizone.org> Message-ID: On 4 August 2017 at 16:54, Rod Beck wrote: > Well, imagine what happens when you have a body of water like Lake Ontario > separating the key hubs on each side of the border, 151 Front Street and > 350 Main Street. The fiber is probably stacked parallel around the lake and > at certain points is collapsed into one right of way. > To generalise - most of Canada's population lives within 160 km of the US border. That's a 8800 km long, but very skinny piece of territory, and that makes finding geographically diverse routes ... challenging. -- Harald Koch (with CA*net in the 1990s :) From rod.beck at unitedcablecompany.com Fri Aug 4 22:13:08 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 4 Aug 2017 22:13:08 +0000 Subject: Bell outage In-Reply-To: <156DE667-D606-480D-A3DF-EADE6F0E244F@lixfeld.ca> References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> <32ad418c-5849-fcc6-4390-b0109a3fec5f@pubnix.net> <20170804190740.GJ32614@sizone.org> , <156DE667-D606-480D-A3DF-EADE6F0E244F@lixfeld.ca> Message-ID: I am pretty sure most of the fiber runs counterclockwise from Toronto to Buffalo. Just a fact. - R. ________________________________ From: Jason Lixfeld Sent: Friday, August 4, 2017 11:48 PM To: Rod Beck Cc: nanog at nanog.org; ahebert at pubnix.net Subject: Re: Bell outage I think having a lake right in the middle makes a really nice, natural, diverse route between the two locations, as is the case with the many routes running east and west around the lake out of both 151 Front and 350 Main. It’s great for non latency sensitive traffic if your short path fails, but it sucks for latency sensitive traffic if your short path fails. What’s the solution in that case if you need geo diverse, low latency routes between two longish haul points that can only be connected by one major highway and one major railway, and where there’s a large likelihood that the even a single route would have to use both those pathways? I’m sure it's trivial to get geo diverse routes out of any major carrier hotel, but what about the in between bits? > On Aug 4, 2017, at 4:54 PM, Rod Beck wrote: > > Well, imagine what happens when you have a body of water like Lake Ontario separating the key hubs on each side of the border, 151 Front Street and 350 Main Street. The fiber is probably stacked parallel around the lake and at certain points is collapsed into one right of way. > > > - R. > > > ________________________________ > From: NANOG on behalf of Alain Hebert > Sent: Friday, August 4, 2017 10:34 PM > To: nanog at nanog.org > Subject: Re: Bell outage > > Well, > > We have a case where 2 paths, between 151 front to somewhere in > Markham, ended up overlapping 3 times for about 300m total :( > > And to cap the whole thing off... Enter the building thru the same > conduit. > > You pretty much need to be onsite supervising the whole thing up. > > And yes their files have the circuits going thru a home, what looks > like a gas station, an electrical grids, etc =D. Pretty impressive. > > PS: As rodent, you mean the punks that fire bomb "that" conduit > under "that" bridge, a few years back? > > ----- > 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 PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > PubNIX Inc. – Branché sur le monde – Connected to the World PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > www.pubnix.net PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > > > > On 08/04/17 15:07, Ken Chase wrote: >> And can be hard to know without serious dilligence - two of our upstreams >> happened to go through the same 360 networks conduit in montreal that "saw >> significant rodent activity". Both were down for 6 hours. A couple customers >> had some custom apps that relied on the two, each as redundancy to the other. >> >> That didnt work out. >> >> Getting salesdroids to give you the info can be very hard though, and even >> tech dept's may not know what secondary providers their fibres run through or >> where, readily. >> >> /kc >> >> On Fri, Aug 04, 2017 at 02:57:22PM -0400, Alain Hebert said: >>> Well, >>> >>> Saying they provided you with geographically diverse circuits versus >>> actually doing it, happen way too often. >>> >>> ----- >>> 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 PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > PubNIX Inc. – Branché sur le monde – Connected to the World PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > www.pubnix.net PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > > >> > From bryan at shout.net Sat Aug 5 15:21:49 2017 From: bryan at shout.net (Bryan Holloway) Date: Sat, 5 Aug 2017 10:21:49 -0500 Subject: Transparent Waves In-Reply-To: References: Message-ID: <59099aa4-adaa-0a52-d6c0-f6e86f42948c@shout.net> Are you referring to GFP? I think G.7041 is what you want. The "transparent" flavor. https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.7041-201608-I!!PDF-E&type=items On 8/4/17 12:34 PM, Rod Beck wrote: > Can someone refer me to the ITU SPEC on transparent 10 gig wave service. I have a client is looking to lease two 10 gig waves but they do not want an Ethernet format. Just transparent. I want to make sure the carrier gets it right when they configure the service. > > > Regards, > > > Roderick. > > > Roderick Beck > > Director of Global Sales > > United Cable Company > > DRG Undersea Consulting > > Affiliate Member > > www.unitedcablecompany.com > > 85 Király utca, 1077 Budapest > > rod.beck at unitedcablecompany.com > > 36-30-859-5144 > > > [1467221477350_image005.png] > From erich at gotfusion.net Sun Aug 6 21:41:49 2017 From: erich at gotfusion.net (Kaiser, Erich) Date: Sun, 6 Aug 2017 16:41:49 -0500 Subject: Microsoft peering - no response Message-ID: We have been trying to complete our peering with Microsoft at Equinix Ashburn for over a month, keep getting the run-around, all we need is for someone to complete the sessions on their end. Hopefully this will get to someone that can do that. We are peered at several other IX locations across the US already. Our ASN is 19754. Our side is already complete. Just sent another email to peering_at_microsoft and got an undeliverable email response. Sincerely, Erich Kaiser The Fusion Network erich at gotfusion.net From nanog at ics-il.net Sun Aug 6 22:03:21 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 6 Aug 2017 17:03:21 -0500 (CDT) Subject: Microsoft peering - no response In-Reply-To: References: Message-ID: <158779700.533.1502056670917.JavaMail.mhammett@ThunderFuck> I know that one person at Microsoft for interconnection is no longer there. The other person I've been talking to has been silent as well. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Erich Kaiser" To: "NANOG list" Sent: Sunday, August 6, 2017 4:41:49 PM Subject: Microsoft peering - no response We have been trying to complete our peering with Microsoft at Equinix Ashburn for over a month, keep getting the run-around, all we need is for someone to complete the sessions on their end. Hopefully this will get to someone that can do that. We are peered at several other IX locations across the US already. Our ASN is 19754. Our side is already complete. Just sent another email to peering_at_microsoft and got an undeliverable email response. Sincerely, Erich Kaiser The Fusion Network erich at gotfusion.net From jlewis at lewis.org Mon Aug 7 01:13:06 2017 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 6 Aug 2017 21:13:06 -0400 (EDT) Subject: Microsoft peering - no response In-Reply-To: References: Message-ID: On Sun, 6 Aug 2017, Kaiser, Erich wrote: > We have been trying to complete our peering with Microsoft at Equinix > Ashburn for over a month, keep getting the run-around, all we need is for > someone to complete the sessions on their end. Hopefully this will get to > someone that can do that. We are peered at several other IX locations > across the US already. Our ASN is 19754. Our side is already complete. I assume you found and used their peering request web form? I'm in exactly the same boat. Trying to get an additional set of sessions setup at Equinix Ashburn, used their form (twice) and have not even gotten the automated confirmation email the form says should be sent. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From erich at gotfusion.net Mon Aug 7 03:49:33 2017 From: erich at gotfusion.net (Kaiser, Erich) Date: Sun, 6 Aug 2017 22:49:33 -0500 Subject: Microsoft peering - no response In-Reply-To: References: Message-ID: Yes had some correspondence with their peering dept, but then nothing... Erich Kaiser The Fusion Network erich at gotfusion.net Office: 630-621-4804 Cell: 630-777-9291 On Sun, Aug 6, 2017 at 8:13 PM, Jon Lewis wrote: > On Sun, 6 Aug 2017, Kaiser, Erich wrote: > > We have been trying to complete our peering with Microsoft at Equinix >> Ashburn for over a month, keep getting the run-around, all we need is for >> someone to complete the sessions on their end. Hopefully this will get to >> someone that can do that. We are peered at several other IX locations >> across the US already. Our ASN is 19754. Our side is already complete. >> > > I assume you found and used their peering request web form? I'm in > exactly the same boat. Trying to get an additional set of sessions setup > at Equinix Ashburn, used their form (twice) and have not even gotten the > automated confirmation email the form says should be sent. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From mehmet at akcin.net Mon Aug 7 05:55:01 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 6 Aug 2017 22:55:01 -0700 Subject: Microsoft peering - no response In-Reply-To: References: Message-ID: I will directly connect you people who will respond. I used to work in this team. Intros being made offlist On Sun, Aug 6, 2017 at 8:49 PM, Kaiser, Erich wrote: > Yes had some correspondence with their peering dept, but then nothing... > > Erich Kaiser > The Fusion Network > erich at gotfusion.net > Office: 630-621-4804 > Cell: 630-777-9291 > > > > On Sun, Aug 6, 2017 at 8:13 PM, Jon Lewis wrote: > > > On Sun, 6 Aug 2017, Kaiser, Erich wrote: > > > > We have been trying to complete our peering with Microsoft at Equinix > >> Ashburn for over a month, keep getting the run-around, all we need is > for > >> someone to complete the sessions on their end. Hopefully this will get > to > >> someone that can do that. We are peered at several other IX locations > >> across the US already. Our ASN is 19754. Our side is already complete. > >> > > > > I assume you found and used their peering request web form? I'm in > > exactly the same boat. Trying to get an additional set of sessions setup > > at Equinix Ashburn, used their form (twice) and have not even gotten the > > automated confirmation email the form says should be sent. > > > > ---------------------------------------------------------------------- > > Jon Lewis, MCP :) | I route > > | therefore you are > > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > From ramy.ihashish at gmail.com Mon Aug 7 13:31:26 2017 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 7 Aug 2017 15:31:26 +0200 Subject: Reviews - GTT, NTT and Telia Message-ID: Good day all, If you are going to have two 10G "multiservice" ports in Europe, over which you will run IPT, EVPL (point-to-point switched Ethernet) and IP MPLS VPNs, and you are about to choose between GTT, NTT and Telia, which one will you choose as per your previous experience? Or please share your experience with any of their support, general or specific content quality of experience, overall performance or service delivery. Thanks in advance. Ramy Hashish From dmburgess at linktechs.net Mon Aug 7 14:21:45 2017 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 7 Aug 2017 14:21:45 +0000 Subject: ATT Support Message-ID: I am looking to talk to ATT MIS support, someone that can actually look at stuff. :( Please e-mail me off-list. Going in circles with their normal support .... Dennis Burgess - Network Solution Engineer - Consultant MikroTik Certified Trainer/Consultant - MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE For Wireless Hardware/Routers visit www.linktechs.net Radio Frequency Coverages: www.towercoverage.com Office: 314-735-0270 E-Mail: dmburgess at linktechs.net From beecher at beecher.cc Mon Aug 7 14:59:45 2017 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 7 Aug 2017 10:59:45 -0400 Subject: Bell outage In-Reply-To: References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> <32ad418c-5849-fcc6-4390-b0109a3fec5f@pubnix.net> <20170804190740.GJ32614@sizone.org> <156DE667-D606-480D-A3DF-EADE6F0E244F@lixfeld.ca> Message-ID: ( Buffalo resident here.) That's pretty much true. From Toronto down around the lake, most of the fiber paths follow the QEW, although I think I saw a map once that had some down the 406. The challenge then becomes the Niagara River. There are only really 3 good points north of Niagara Falls to cross the gorge, the Rainbow / Whirlpool Rapids / Lewiston-Queenston. (There is an old train bridge just south of Whirlpool Rapids, but it's pretty decrepit.) Even then, L/Q is the only option that's generally feasible to reach, and has any decent infrastructure on the US side. To my knowledge, most everything goes south to the Peace Bridge . into Buffalo proper, and over to 350 Main Street. Just about everyone in this region comes through there, except for Level3. (They're close, down on Scott Street, and just stub up to Main. But even they don't actually have a gateway there, they still pull people back to NY/Cleveland.) I know there is a group trying to do a cable directly across Lake Ontario to my neck of the woods, which would be really interesting if it happens. You could save potentially 60k-ish with a direct path vs coming around and down, and there's a surprisingly decent volume of in-region glass in the ground on different paths. Plus much of the area north of Buffalo to the lake is rural farmland, so building something new wouldn't be terribly hard or expensive either. Crossing the lake itself is a challenge though. Lake Ontario is really deep, and there are steep underwater cliffs off the mouth of the Niagara River (~50m drop over less than 1km) , and again on the eastern side of Toronto. If they can work around that to get something run, I think it could be a very intriguing path. I'm a little biased because I think it could be a great boon for my area ; putting datacenter space in around here is basically free compared to space up there, and you'd be <5ms from Toronto, and ~10ms from NYC. On Fri, Aug 4, 2017 at 6:13 PM, Rod Beck wrote: > I am pretty sure most of the fiber runs counterclockwise from Toronto to > Buffalo. Just a fact. > > > - R. > > > ________________________________ > From: Jason Lixfeld > Sent: Friday, August 4, 2017 11:48 PM > To: Rod Beck > Cc: nanog at nanog.org; ahebert at pubnix.net > Subject: Re: Bell outage > > I think having a lake right in the middle makes a really nice, natural, > diverse route between the two locations, as is the case with the many > routes running east and west around the lake out of both 151 Front and 350 > Main. It’s great for non latency sensitive traffic if your short path > fails, but it sucks for latency sensitive traffic if your short path fails. > > What’s the solution in that case if you need geo diverse, low latency > routes between two longish haul points that can only be connected by one > major highway and one major railway, and where there’s a large likelihood > that the even a single route would have to use both those pathways? I’m > sure it's trivial to get geo diverse routes out of any major carrier hotel, > but what about the in between bits? > > > On Aug 4, 2017, at 4:54 PM, Rod Beck > wrote: > > > > Well, imagine what happens when you have a body of water like Lake > Ontario separating the key hubs on each side of the border, 151 Front > Street and 350 Main Street. The fiber is probably stacked parallel around > the lake and at certain points is collapsed into one right of way. > > > > > > - R. > > > > > > ________________________________ > > From: NANOG on behalf of Alain Hebert < > ahebert at pubnix.net> > > Sent: Friday, August 4, 2017 10:34 PM > > To: nanog at nanog.org > > Subject: Re: Bell outage > > > > Well, > > > > We have a case where 2 paths, between 151 front to somewhere in > > Markham, ended up overlapping 3 times for about 300m total :( > > > > And to cap the whole thing off... Enter the building thru the same > > conduit. > > > > You pretty much need to be onsite supervising the whole thing up. > > > > And yes their files have the circuits going thru a home, what looks > > like a gas station, an electrical grids, etc =D. Pretty impressive. > > > > PS: As rodent, you mean the punks that fire bomb "that" conduit > > under "that" bridge, a few years back? > > > > ----- > > 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 > PubNIX Inc. – Branché sur le monde – Connected to the World< > http://www.pubnix.net/> > www.pubnix.net > PubNIX is a boutique Internet service provider with personalized service > that offers you an alternative to "Big Telco". At PubNIX, we are committed > to providing you ... > > > > PubNIX Inc. – Branché sur le monde – Connected to the World< > http://www.pubnix.net/> > PubNIX Inc. – Branché sur le monde – Connected to the World< > http://www.pubnix.net/> > www.pubnix.net > PubNIX is a boutique Internet service provider with personalized service > that offers you an alternative to "Big Telco". At PubNIX, we are committed > to providing you ... > > > > www.pubnix.net > PubNIX Inc. – Branché sur le monde – Connected to the World< > http://www.pubnix.net/> > www.pubnix.net > PubNIX is a boutique Internet service provider with personalized service > that offers you an alternative to "Big Telco". At PubNIX, we are committed > to providing you ... > > > > PubNIX is a boutique Internet service provider with personalized service > that offers you an alternative to "Big Telco". At PubNIX, we are committed > to providing you ... > > > > > > > > On 08/04/17 15:07, Ken Chase wrote: > >> And can be hard to know without serious dilligence - two of our > upstreams > >> happened to go through the same 360 networks conduit in montreal that > "saw > >> significant rodent activity". Both were down for 6 hours. A couple > customers > >> had some custom apps that relied on the two, each as redundancy to the > other. > >> > >> That didnt work out. > >> > >> Getting salesdroids to give you the info can be very hard though, and > even > >> tech dept's may not know what secondary providers their fibres run > through or > >> where, readily. > >> > >> /kc > >> > >> On Fri, Aug 04, 2017 at 02:57:22PM -0400, Alain Hebert said: > >>> Well, > >>> > >>> Saying they provided you with geographically diverse circuits versus > >>> actually doing it, happen way too often. > >>> > >>> ----- > >>> 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 > PubNIX Inc. – Branché sur le monde – Connected to the World< > http://www.pubnix.net/> > www.pubnix.net > PubNIX is a boutique Internet service provider with personalized service > that offers you an alternative to "Big Telco". At PubNIX, we are committed > to providing you ... > > > > PubNIX Inc. – Branché sur le monde – Connected to the World< > http://www.pubnix.net/> > PubNIX Inc. – Branché sur le monde – Connected to the World< > http://www.pubnix.net/> > www.pubnix.net > PubNIX is a boutique Internet service provider with personalized service > that offers you an alternative to "Big Telco". At PubNIX, we are committed > to providing you ... > > > > www.pubnix.net > PubNIX Inc. – Branché sur le monde – Connected to the World< > http://www.pubnix.net/> > www.pubnix.net > PubNIX is a boutique Internet service provider with personalized service > that offers you an alternative to "Big Telco". At PubNIX, we are committed > to providing you ... > > > > PubNIX is a boutique Internet service provider with personalized service > that offers you an alternative to "Big Telco". At PubNIX, we are committed > to providing you ... > > > > > >> > > > > From rod.beck at unitedcablecompany.com Mon Aug 7 15:07:37 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Mon, 7 Aug 2017 15:07:37 +0000 Subject: Bell outage In-Reply-To: References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> <32ad418c-5849-fcc6-4390-b0109a3fec5f@pubnix.net> <20170804190740.GJ32614@sizone.org> <156DE667-D606-480D-A3DF-EADE6F0E244F@lixfeld.ca> , Message-ID: Yeah, I am one of the sales guys for this project across Lake Ontario. It is called Crosslake. - R. ________________________________ From: Tom Beecher Sent: Monday, August 7, 2017 4:59 PM To: Rod Beck Cc: Jason Lixfeld; nanog at nanog.org Subject: Re: Bell outage ( Buffalo resident here.) That's pretty much true. From Toronto down around the lake, most of the fiber paths follow the QEW, although I think I saw a map once that had some down the 406. The challenge then becomes the Niagara River. There are only really 3 good points north of Niagara Falls to cross the gorge, the Rainbow / Whirlpool Rapids / Lewiston-Queenston. (There is an old train bridge just south of Whirlpool Rapids, but it's pretty decrepit.) Even then, L/Q is the only option that's generally feasible to reach, and has any decent infrastructure on the US side. To my knowledge, most everything goes south to the Peace Bridge . into Buffalo proper, and over to 350 Main Street. Just about everyone in this region comes through there, except for Level3. (They're close, down on Scott Street, and just stub up to Main. But even they don't actually have a gateway there, they still pull people back to NY/Cleveland.) I know there is a group trying to do a cable directly across Lake Ontario to my neck of the woods, which would be really interesting if it happens. You could save potentially 60k-ish with a direct path vs coming around and down, and there's a surprisingly decent volume of in-region glass in the ground on different paths. Plus much of the area north of Buffalo to the lake is rural farmland, so building something new wouldn't be terribly hard or expensive either. Crossing the lake itself is a challenge though. Lake Ontario is really deep, and there are steep underwater cliffs off the mouth of the Niagara River (~50m drop over less than 1km) , and again on the eastern side of Toronto. If they can work around that to get something run, I think it could be a very intriguing path. I'm a little biased because I think it could be a great boon for my area ; putting datacenter space in around here is basically free compared to space up there, and you'd be <5ms from Toronto, and ~10ms from NYC. On Fri, Aug 4, 2017 at 6:13 PM, Rod Beck > wrote: I am pretty sure most of the fiber runs counterclockwise from Toronto to Buffalo. Just a fact. - R. ________________________________ From: Jason Lixfeld > Sent: Friday, August 4, 2017 11:48 PM To: Rod Beck Cc: nanog at nanog.org; ahebert at pubnix.net Subject: Re: Bell outage I think having a lake right in the middle makes a really nice, natural, diverse route between the two locations, as is the case with the many routes running east and west around the lake out of both 151 Front and 350 Main. It’s great for non latency sensitive traffic if your short path fails, but it sucks for latency sensitive traffic if your short path fails. What’s the solution in that case if you need geo diverse, low latency routes between two longish haul points that can only be connected by one major highway and one major railway, and where there’s a large likelihood that the even a single route would have to use both those pathways? I’m sure it's trivial to get geo diverse routes out of any major carrier hotel, but what about the in between bits? > On Aug 4, 2017, at 4:54 PM, Rod Beck > wrote: > > Well, imagine what happens when you have a body of water like Lake Ontario separating the key hubs on each side of the border, 151 Front Street and 350 Main Street. The fiber is probably stacked parallel around the lake and at certain points is collapsed into one right of way. > > > - R. > > > ________________________________ > From: NANOG > on behalf of Alain Hebert > > Sent: Friday, August 4, 2017 10:34 PM > To: nanog at nanog.org > Subject: Re: Bell outage > > Well, > > We have a case where 2 paths, between 151 front to somewhere in > Markham, ended up overlapping 3 times for about 300m total :( > > And to cap the whole thing off... Enter the building thru the same > conduit. > > You pretty much need to be onsite supervising the whole thing up. > > And yes their files have the circuits going thru a home, what looks > like a gas station, an electrical grids, etc =D. Pretty impressive. > > PS: As rodent, you mean the punks that fire bomb "that" conduit > under "that" bridge, a few years back? > > ----- > 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 PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > PubNIX Inc. – Branché sur le monde – Connected to the World PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > www.pubnix.net PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > > > > On 08/04/17 15:07, Ken Chase wrote: >> And can be hard to know without serious dilligence - two of our upstreams >> happened to go through the same 360 networks conduit in montreal that "saw >> significant rodent activity". Both were down for 6 hours. A couple customers >> had some custom apps that relied on the two, each as redundancy to the other. >> >> That didnt work out. >> >> Getting salesdroids to give you the info can be very hard though, and even >> tech dept's may not know what secondary providers their fibres run through or >> where, readily. >> >> /kc >> >> On Fri, Aug 04, 2017 at 02:57:22PM -0400, Alain Hebert said: >>> Well, >>> >>> Saying they provided you with geographically diverse circuits versus >>> actually doing it, happen way too often. >>> >>> ----- >>> 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 PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > PubNIX Inc. – Branché sur le monde – Connected to the World PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > www.pubnix.net PubNIX Inc. – Branché sur le monde – Connected to the World www.pubnix.net PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > PubNIX is a boutique Internet service provider with personalized service that offers you an alternative to "Big Telco". At PubNIX, we are committed to providing you ... > > >> > From edward.dore at freethought-internet.co.uk Mon Aug 7 15:16:28 2017 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Mon, 07 Aug 2017 16:16:28 +0100 Subject: Reviews - GTT, NTT and Telia In-Reply-To: References: Message-ID: <5E3D0F66-8317-401F-A8FB-3B33A0133136@freethought-internet.co.uk> On 07/08/2017, 14:31, "NANOG on behalf of Ramy Hashish" wrote: Good day all, If you are going to have two 10G "multiservice" ports in Europe, over which you will run IPT, EVPL (point-to-point switched Ethernet) and IP MPLS VPNs, and you are about to choose between GTT, NTT and Telia, which one will you choose as per your previous experience? Or please share your experience with any of their support, general or specific content quality of experience, overall performance or service delivery. Thanks in advance. Ramy Hashish Hi Ramy, We use both GTT and NTT for IP transit in the UK. The NTT NOC is absolutely excellent and I wouldn’t hesitate to recommend them. We had serious service delivery problems with GTT which dragged on for months, but once they finally managed to provision the service it has been perfectly reliable and their NOC seemed OK on the few occasions that we’ve needed to deal with them. Edward Dore Freethought Internet From chkuhtz at microsoft.com Mon Aug 7 15:57:07 2017 From: chkuhtz at microsoft.com (Christian Kuhtz) Date: Mon, 7 Aug 2017 15:57:07 +0000 Subject: Microsoft peering - no response In-Reply-To: References: Message-ID: Thanks everyone. Problem was on our end and has been fixed. Thanks, Christian From: Kaiser, Erich Sent: Sunday, August 6, 2:43 PM Subject: Microsoft peering - no response To: NANOG list We have been trying to complete our peering with Microsoft at Equinix Ashburn for over a month, keep getting the run-around, all we need is for someone to complete the sessions on their end. Hopefully this will get to someone that can do that. We are peered at several other IX locations across the US already. Our ASN is 19754. Our side is already complete. Just sent another email to peering_at_microsoft and got an undeliverable email response. Sincerely, Erich Kaiser The Fusion Network erich at gotfusion.net From ramy.ihashish at gmail.com Mon Aug 7 17:19:13 2017 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Mon, 7 Aug 2017 19:19:13 +0200 Subject: Reviews - GTT, NTT and Telia In-Reply-To: <5E3D0F66-8317-401F-A8FB-3B33A0133136@freethought-internet.co.uk> References: <5E3D0F66-8317-401F-A8FB-3B33A0133136@freethought-internet.co.uk> Message-ID: Thank you so much Edward for your elaborate review. I would like to read more reviews, we are going to consolidate many smaller circuits in two 10Gs, it would be great if we can learn the experience the easy way :) Ramy On Aug 7, 2017 17:16, "Edward Dore" wrote: Hi Ramy, We use both GTT and NTT for IP transit in the UK. The NTT NOC is absolutely excellent and I wouldn’t hesitate to recommend them. We had serious service delivery problems with GTT which dragged on for months, but once they finally managed to provision the service it has been perfectly reliable and their NOC seemed OK on the few occasions that we’ve needed to deal with them. Edward Dore Freethought Internet From martijnschmidt at i3d.net Tue Aug 8 08:55:39 2017 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Tue, 8 Aug 2017 10:55:39 +0200 Subject: Reviews - GTT, NTT and Telia In-Reply-To: References: <5E3D0F66-8317-401F-A8FB-3B33A0133136@freethought-internet.co.uk> Message-ID: <63843d24-6fa2-c428-8629-f4a4596b087b@i3d.net> Hi Ramy, Having worked with NTT & GTT, but not Telia, I can heartily recommend NTT. Every one of these providers has its peering challenges so you'll need diversity regardless of the one you pick, but the operations team over at NTT has been absolutely stellar in terms of technical know-how and always provides clear communication about any issues that one might encounter operationally speaking. Best regards, Martijn On 07-08-17 19:19, Ramy Hashish wrote: > Thank you so much Edward for your elaborate review. > > I would like to read more reviews, we are going to consolidate many smaller > circuits in two 10Gs, it would be great if we can learn the experience the > easy way :) > > Ramy > > On Aug 7, 2017 17:16, "Edward Dore" > wrote: > > > Hi Ramy, > > We use both GTT and NTT for IP transit in the UK. The NTT NOC is absolutely > excellent and I wouldn’t hesitate to recommend them. We had serious service > delivery problems with GTT which dragged on for months, but once they > finally managed to provision the service it has been perfectly reliable and > their NOC seemed OK on the few occasions that we’ve needed to deal with > them. > > Edward Dore > Freethought Internet From jcurran at arin.net Tue Aug 8 15:14:28 2017 From: jcurran at arin.net (John Curran) Date: Tue, 8 Aug 2017 15:14:28 +0000 Subject: ARIN NRPM 2017.4: New Policies Implemented References: <5989D404.7000408@arin.net> Message-ID: <1187FF7A-F44F-4959-9A3E-327EA8333147@arin.net> NANOGers: Two new policies affecting transfers of number resources have been implemented at ARIN – it is worthing taking a moment to become familiar with these changes if you manage IP number resources. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-ppml] NRPM 2017.4: New Policies Implemented Date: 8 August 2017 at 11:08:52 AM EDT To: > On 22 June 2017, the Board of Trustees adopted the following Recommended Draft Policies: Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers These policies are now in effect. A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2017.4 is effective 8 August 2017 and supersedes the previous version. The NRPM is available at: https://www.arin.net/policy/nrpm.html Board minutes are available at: https://www.arin.net/about_us/bot/index.html Draft policies and proposals are available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process (PDP) is available at: https://www.arin.net/policy/pdp.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From mel at beckman.org Tue Aug 8 15:25:35 2017 From: mel at beckman.org (Mel Beckman) Date: Tue, 8 Aug 2017 15:25:35 +0000 Subject: ARIN NRPM 2017.4: New Policies Implemented In-Reply-To: <1187FF7A-F44F-4959-9A3E-327EA8333147@arin.net> References: <5989D404.7000408@arin.net>, <1187FF7A-F44F-4959-9A3E-327EA8333147@arin.net> Message-ID: <2ACEE963-E421-4EF9-A6F6-63BC9BA52BFF@beckman.org> John, Forgive me if I'm missing something obvious, but I looked at all the links in the email you forwarded to TW list, and I cannot see anything that specifically details the set of two policy changes you mentioned. The minutes of the June meeting talk about some policy changes in general, but they don't provide the specific language. I could try to diff the entire policy in the NPRM, but that's not very practical. Is there a mark-up document showing the specific changes and where they appear in the in NPRM? -mel > On Aug 8, 2017, at 8:15 AM, John Curran wrote: > > NANOGers: > > Two new policies affecting transfers of number resources have been implemented > at ARIN – it is worthing taking a moment to become familiar with these changes if > you manage IP number resources. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > Begin forwarded message: > > From: ARIN > > Subject: [arin-ppml] NRPM 2017.4: New Policies Implemented > Date: 8 August 2017 at 11:08:52 AM EDT > To: > > > On 22 June 2017, the Board of Trustees adopted the following Recommended Draft Policies: > > Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers > > Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers > > These policies are now in effect. A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. > > NRPM version 2017.4 is effective 8 August 2017 and supersedes the previous version. > > The NRPM is available at: > > https://www.arin.net/policy/nrpm.html > > Board minutes are available at: > > https://www.arin.net/about_us/bot/index.html > > Draft policies and proposals are available at: > > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process (PDP) is available at: > > https://www.arin.net/policy/pdp.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From jcurran at arin.net Tue Aug 8 15:30:58 2017 From: jcurran at arin.net (John Curran) Date: Tue, 8 Aug 2017 15:30:58 +0000 Subject: ARIN NRPM 2017.4: New Policies Implemented In-Reply-To: <2ACEE963-E421-4EF9-A6F6-63BC9BA52BFF@beckman.org> References: <5989D404.7000408@arin.net> <1187FF7A-F44F-4959-9A3E-327EA8333147@arin.net> <2ACEE963-E421-4EF9-A6F6-63BC9BA52BFF@beckman.org> Message-ID: <56F2314E-2559-4802-BE8E-C893DB27CBF5@arin.net> Mel - My apologies. There is a NRPM change log is available in the navigation box on the right hand side of the NRPM page, and it contains links to the two policy language changes (which I’ve included below for ready reference) - https://www.arin.net/policy/proposals/2016_3.html https://www.arin.net/policy/proposals/2016_9.html Thanks! /John On 8 Aug 2017, at 11:25 AM, Mel Beckman > wrote: John, Forgive me if I'm missing something obvious, but I looked at all the links in the email you forwarded to TW list, and I cannot see anything that specifically details the set of two policy changes you mentioned. The minutes of the June meeting talk about some policy changes in general, but they don't provide the specific language. I could try to diff the entire policy in the NPRM, but that's not very practical. Is there a mark-up document showing the specific changes and where they appear in the in NPRM? -mel On Aug 8, 2017, at 8:15 AM, John Curran > wrote: NANOGers: Two new policies affecting transfers of number resources have been implemented at ARIN – it is worthing taking a moment to become familiar with these changes if you manage IP number resources. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-ppml] NRPM 2017.4: New Policies Implemented Date: 8 August 2017 at 11:08:52 AM EDT To: > On 22 June 2017, the Board of Trustees adopted the following Recommended Draft Policies: Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers These policies are now in effect. A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2017.4 is effective 8 August 2017 and supersedes the previous version. The NRPM is available at: https://www.arin.net/policy/nrpm.html Board minutes are available at: https://www.arin.net/about_us/bot/index.html Draft policies and proposals are available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process (PDP) is available at: https://www.arin.net/policy/pdp.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From dvandyk at akamai.com Tue Aug 8 15:34:43 2017 From: dvandyk at akamai.com (Van Dyk, Donovan) Date: Tue, 8 Aug 2017 15:34:43 +0000 Subject: Reviews - GTT, NTT and Telia In-Reply-To: References: <5E3D0F66-8317-401F-A8FB-3B33A0133136@freethought-internet.co.uk> Message-ID: <533B781E-2D47-4D52-9C5E-1DECB0E9B35D@akamai.com> Hello, We use all three globally. NTT – Like everyone already stated, excellent customer service. Fast and very knowledgeable. TELIA – It was a rocky start with them in the beginning, but they’ve been very good lately (About a year). Customer service is always fast and decent. In the beginning, their maintenances tended to cause problems they did not expect. We would have a couple service interruption and later find out they were conducting maintenance on their internal network. We were not expected to be affected so weren’t notified type thing. They also have had quite a few mis-configuration issues which put a little doubt in their changes and engineers. But they’ve implemented stricter change control and peer review which seems to have mitigated this. A good thing in my eyes is they are always forth coming if there was a problem on their side. All in all, I recommend them. GTT – Ever since they merged their network with Hibernia (About 6months ago), their customer service has taken a big hit. Tickets can now take days to hear back from them, have to constantly ask for updates. I think their NOC is swamped with work and are backed up. If your issue is not ongoing, it could be awhile. I don’t want to harp on them, but their customer service used to be excellent. I think they are going through some growing pains right now, hopefully they turn it around soon. As for their network, it’s reliable, a couple hits here and there, but you’ll see that anywhere. Regards, -- Donovan Van Dyk SOC Network Engineer Office: +1.954.620.6002 x911 Fort Lauderdale, FL USA The information contained in this electronic mail transmission and its attachments may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient (or an individual responsible for delivery of the message to such person), you are strictly prohibited from copying, disseminating or distributing this communication. If you have received this communication in error, please notify the sender immediately and destroy all electronic, paper or other versions. On 8/7/17, 1:19 PM, "Ramy Hashish" wrote: Thank you so much Edward for your elaborate review. I would like to read more reviews, we are going to consolidate many smaller circuits in two 10Gs, it would be great if we can learn the experience the easy way :) Ramy On Aug 7, 2017 17:16, "Edward Dore" wrote: Hi Ramy, We use both GTT and NTT for IP transit in the UK. The NTT NOC is absolutely excellent and I wouldn’t hesitate to recommend them. We had serious service delivery problems with GTT which dragged on for months, but once they finally managed to provision the service it has been perfectly reliable and their NOC seemed OK on the few occasions that we’ve needed to deal with them. Edward Dore Freethought Internet From sebastian at karotte.org Wed Aug 2 15:51:43 2017 From: sebastian at karotte.org (Sebastian Wiesinger) Date: Wed, 2 Aug 2017 17:51:43 +0200 Subject: AS202746 Hijacks: Is Telia (a) stupid, or (b) lazy, or (c) complicit? In-Reply-To: <7098.1501659387@segfault.tristatelogic.com> References: <7098.1501659387@segfault.tristatelogic.com> Message-ID: <20170802155143.GC20621@danton.fire-world.de> * Ronald F. Guilmette [2017-08-02 09:37]: > > The annotations in the RIPE WHOIS record for AS202746 seem pretty clear to me. > This thing is B-O-G-U-S! You know, people might be more willing to listen to you when you express your points in a less emotional and aggressive tone. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From mjl at caida.org Fri Aug 4 01:19:18 2017 From: mjl at caida.org (Matthew Luckie) Date: Fri, 4 Aug 2017 13:19:18 +1200 Subject: Spoofer Project Message-ID: <20170804011917.GA60443@sorcerer.cms.waikato.ac.nz> Hi, The CAIDA Spoofer project has been collecting and publicly sharing data on the deployment of source address validation since March 2016. We've built up a reasonably large install-base of the open-source client, and receive tests from 400-500 unique IPs per day. We're posting reports with links to test outcomes on the spoofer website. In particular, we've got summary statistics for each AS at: https://spoofer.caida.org/as_stats.php If you know an operator for anyone on that list who has at least one spoofable prefix, please feel free to reach out to them and let them know. I've been sending emails to abuse contacts for nearly a year now. Roughly 1/5 ASes I've contacted have fixed at least one problem. The remediation we know about (automatically generated) is at: https://spoofer.caida.org/remedy.php In order to improve the notification emails, I'm also soliciting configuration snippets from operators who have deployed source address validation. If you have deployed SAV and wouldn't mind sharing redacted configuration (privately is fine) including any necessary platform details (such as vendor and operating system) we would greatly appreciate it. We will aggregate and post configuration snippets at https://spoofer.caida.org/ Matthew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From andy at strugglers.net Wed Aug 2 11:02:04 2017 From: andy at strugglers.net (Andy Smith) Date: Wed, 2 Aug 2017 11:02:04 +0000 Subject: Admiral Hosting in London In-Reply-To: <20170727195401.GI7311@manor.msen.com> References: <20170727195401.GI7311@manor.msen.com> Message-ID: <20170802110204.GJ3304@bitfolk.com> Hello, On Thu, Jul 27, 2017 at 03:54:01PM -0400, Michael Wayne wrote: > We were contacted by Admiral Hosting in London to rent some our > unused IP space. While they insist that they're not spammers, we can > not find out much about them. > > Has anyone had any dealings with this company? Legit? Scam? We > are not interested in contributing to the Scam/Spam problem and > figured I would ask here. Had a couple of exactly the same messages from them. It seems like one guy with no infrastructure of their own. Asked him a few questions along the lines of why he was willing to pay more than the cost of becoming a RIPE member for less than a /22 and he eventually went away. As others have said, anyone wanting to lease IPs is likely going to do something that ruins the reputation of the IPs and relies on not having their name on it at the registry level. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting From jcavanaugh at netcraftsmen.com Fri Aug 4 18:22:14 2017 From: jcavanaugh at netcraftsmen.com (John Cavanaugh) Date: Fri, 04 Aug 2017 14:22:14 -0400 Subject: Bell outage In-Reply-To: References: <15dae671fa6.c29852ee1168481.4658726993447126938@namor.ca> Message-ID: <7F611668-A6B4-4934-A0D7-D4C2F89D1872@netcraftsmen.com> No a single fiber bundle cut doesn’t cause this level of outage. I am at a family reunion in Nova Scotia and – Bell internet is down, all cell services are down, most land lines are down and 911 services are problematic. A lot of flights in Halifax have been cancelled (impacting our reunion). Downdetector.com shows a lot, but do not see any details on outages. Looks more like a Cyber incident. At the moment cable service at the cottage is still up…. Was in town and all the banks were closed except RBC. Only one gas station on the highway was operational. Thanks, John Cavanaugh On 8/4/17, 2:07 PM, "NANOG on behalf of jim deleskie" wrote: Single fiber cut causes the much impact? -jim On Fri, Aug 4, 2017 at 2:59 PM, J wrote: > https://www.theglobeandmail.com/news/national/much-of- > atlantic-canada-loses-cellphone-service-in-widespread-outage/ > article35881182/ > > > > Apparently some fiber cut. No word on the exact model of construction > equipment, yet, though. > > > > :\ > > > > > ---- On Fri, 04 Aug 2017 10:14:26 -0500 Krunal Shah <KShah at primustel.ca> > wrote ---- > > > > > Does anyone know what is happening with Bell network at East Canada? > > > > http://canadianoutages.com/status/bell/map/ > > > > > > Krunal > > ________________________________ > > > > 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 Daniel.Jameson at tdstelecom.com Sat Aug 5 16:15:47 2017 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Sat, 5 Aug 2017 16:15:47 +0000 Subject: Transparent Waves In-Reply-To: <59099aa4-adaa-0a52-d6c0-f6e86f42948c@shout.net> References: <59099aa4-adaa-0a52-d6c0-f6e86f42948c@shout.net> Message-ID: They're probably looking for a G.709 spec service. You still need to know something about their traffic, is it analog RFOG, or something already framed like SONET or 1/10/100G. If they can hand you a connection with G.709 styled framing most modern transport gear can ship it end-to-end, even over ROADM. https://en.wikipedia.org/wiki/G.709 https://www.itu.int/rec/T-REC-G.709-201611-I!Amd1/en https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.709-201611-I!Amd1!PDF-E&type=items -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bryan Holloway Sent: Saturday, August 05, 2017 9:22 AM To: Rod Beck; nanog at nanog.org Subject: Re: Transparent Waves Are you referring to GFP? I think G.7041 is what you want. The "transparent" flavor. https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.7041-201608-I!!PDF-E&type=items On 8/4/17 12:34 PM, Rod Beck wrote: > Can someone refer me to the ITU SPEC on transparent 10 gig wave service. I have a client is looking to lease two 10 gig waves but they do not want an Ethernet format. Just transparent. I want to make sure the carrier gets it right when they configure the service. > > > Regards, > > > Roderick. > > > Roderick Beck > > Director of Global Sales > > United Cable Company > > DRG Undersea Consulting > > Affiliate Member > > www.unitedcablecompany.com > > 85 Király utca, 1077 Budapest > > rod.beck at unitedcablecompany.com > > 36-30-859-5144 > > > [1467221477350_image005.png] > From simon at slimey.org Tue Aug 8 22:48:42 2017 From: simon at slimey.org (Simon Lockhart) Date: Tue, 8 Aug 2017 23:48:42 +0100 Subject: Cisco Nexus 93180YC Switch Feedback In-Reply-To: <201707260331.v6Q3Vtu0027729@bgl-core-1.cisco.com> References: <80d84c909fc8414f8619a1446ec5583d@EX-01.m21.local> <201707260331.v6Q3Vtu0027729@bgl-core-1.cisco.com> Message-ID: <20170808224842.GO15390@dilbert.slimey.org> On Tue Jul 25, 2017 at 08:31:54PM -0700, Tim Stevenson wrote: > tstevens-92160yc-1# sh int cap | beg 1/49 | eg Eth|Speed > Ethernet1/49 > Speed: 40000 > Ethernet1/50 > Speed: 1000,10000,25000,40000,50000,100000 > Ethernet1/51 > Speed: 40000 > Ethernet1/52 > Speed: 1000,10000,25000,40000,50000,100000 > Ethernet1/53 > Speed: 40000 > Ethernet1/54 > Speed: 40000 Are you sure? xsw-01.ixn# show ver | incl Nexus9 cisco Nexus9000 C92160YC-X chassis xsw-01.ixn# sh int cap | beg 1/49 | eg Eth|Speed Ethernet1/49 Speed: 40000,100000 Ethernet1/50 Speed: 1000,10000,25000,40000,50000,100000 Ethernet1/51 Speed: 1000,10000,25000,40000,50000,100000 Ethernet1/52 Speed: 1000,10000,25000,40000,50000,100000 xsw-01.ixn# show run | incl portmode hardware profile portmode 48x25G+4x100G xsw-01.ixn(config)# hardware profile portmode ? 48x25g+2x100g+4x40g 48x25G+2x100G+4x40G port mode 48x25g+4x100g 48x25G+4x100G port mode You can configure how the ports present themselves... Simon From brandon at rd.bbc.co.uk Tue Aug 8 23:22:07 2017 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Wed, 9 Aug 2017 00:22:07 +0100 Subject: Cisco Nexus 93180YC Switch Feedback In-Reply-To: <201707260331.v6Q3Vtu0027729@bgl-core-1.cisco.com> References: <80d84c909fc8414f8619a1446ec5583d@EX-01.m21.local> <201707260331.v6Q3Vtu0027729@bgl-core-1.cisco.com> Message-ID: <20170808232207.GA12519@sunf10.rd.bbc.co.uk> On Tue Jul 25, 2017 at 08:31:54PM -0700, Tim Stevenson wrote: > Actually, only two. > > tstevens-92160yc-1# sh int cap | beg 1/49 | eg Eth|Speed > Ethernet1/49 > Speed: 40000 > Ethernet1/50 > Speed: 1000,10000,25000,40000,50000,100000 > Ethernet1/51 > Speed: 40000 > Ethernet1/52 > Speed: 1000,10000,25000,40000,50000,100000 > Ethernet1/53 > Speed: 40000 > Ethernet1/54 > Speed: 40000 > tstevens-92160yc-1# same box, cisco Nexus9000 C92160YC-X is2.ed# sh int cap | beg 1/49 | eg Eth|Speed Ethernet1/49 Speed: 40000,100000 Ethernet1/50 Speed: 1000,10000,25000,40000,50000,100000 Ethernet1/51 Speed: 1000,10000,25000,40000,50000,100000 Ethernet1/52 Speed: 1000,10000,25000,40000,50000,100000 You have to tell it you want more 100G with fewer ports hardware profile portmode 48x25G+4x100G brandon From mjl at caida.org Tue Aug 8 23:45:56 2017 From: mjl at caida.org (Matthew Luckie) Date: Wed, 9 Aug 2017 11:45:56 +1200 Subject: Spoofer Project Message-ID: To my knowledge this is the meeting network. https://spoofer.caida.org/recent_tests.php?as_include=19230 Your interpretation of the results is congruent with mine. If you look through the history of tests you can see SAV is usually deployed on the network during the meeting. This is true of other network operator group meeting networks as well. On 08/09/17 11:25, Info | ddostest.me wrote: > Is it me or NANOG's AS allowing spoofing? > > https://spoofer.caida.org/as.php?asn=19230 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 216 bytes Desc: OpenPGP digital signature URL: From mureninc at gmail.com Tue Aug 8 23:54:56 2017 From: mureninc at gmail.com (Constantine A. Murenin) Date: Tue, 8 Aug 2017 17:54:56 -0600 Subject: US/Canada International border concerns for routing In-Reply-To: References: Message-ID: On 20/07/2017, Hiers, David wrote: > Hi, > We're looking to extend some services into Canada. While our lawyers dig > into it, I thought that I'd ask the hive mind about border restrictions. > > For traffic routing, is anyone constraining cross-border routing between > Canada and the US? IOW, if you are routing from Toronto to Montreal, do you > have to guarantee that the path cannot go through, say, Syracuse, New York? Guarantee to whom? Back a few years ago when I looked into it, most of the traffic within Canada went through the US, e.g., since Bell didn't want to peer with anyone in Canada, you'd go something like YYZ - ORD - YYZ, clearly visible through the traceroute. Possibly somewhat better nowadays — there's been quite a few new IX POPs that popped up — but I doubt the scenario is a thing of the past. P.S. Just for the giggles — checked http://lg.he.net/ routing from core1.tor1.he.net to www.bell.ca — still goes through Chicago, to Montreal, from Toronto. :-) Going straight to Montreal, core1.ymq1.he.net, will route you to www.bell.ca (still in Montreal) through the peering at NYC. P.P.S. In other words — if someone wants guarantees, they better explicitly ask you for it. Cheers, Constantine. http://cm.su/ From woody at pch.net Wed Aug 9 00:10:48 2017 From: woody at pch.net (Bill Woodcock) Date: Tue, 8 Aug 2017 17:10:48 -0700 Subject: US/Canada International border concerns for routing In-Reply-To: References: Message-ID: > On Jul 20, 2017, at 7:01 AM, Hiers, David wrote: > For traffic routing, is anyone constraining cross-border routing between Canada and the US? IOW, if you are routing from Toronto to Montreal, do you have to guarantee that the path cannot go through, say, Syracuse, New York? No. In fact, Bell Canada / Bell Aliant and Telus guarantee that you _will_ go through Chicago, Seattle, New York, or Ashburn, since none of them peer anywhere in Canada at all. Last I checked (November of last year) the best-connected commercial networks (i.e. not CANARIE) in Canada were Hurricane Electric, MTS Allstream, Primus, and Zip Telecom, all of which peer at three or more Canadian IXes. So, they’re capable of keeping traffic in Canada so long as the other end isn’t on Bell or Telus, which only sell U.S. bandwidth to Canadians. In November, only 27% of intra-Canadian routes stayed within Canada; 64% went through the U.S. That’s way worse than five years ago, when 60% stayed within Canada, and 38% went through the U.S. As has been pointed out, Canada has been building IXPs… Just not as fast as the rest of the world has. They’re behind the global average growth rate, and behind the U.S. growth rate, which is why the problem is getting worse. Bandwidth costs are falling faster elsewhere, so they’re importing more foreign bandwidth. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From tshaw at oitc.com Wed Aug 9 00:19:56 2017 From: tshaw at oitc.com (TR Shaw) Date: Tue, 8 Aug 2017 20:19:56 -0400 Subject: US/Canada International border concerns for routing In-Reply-To: References: Message-ID: <06B16018-48FF-4DD3-9474-05DB14962426@oitc.com> Bill, What does Bell buying MTS do? Does it change your statement or will the MTS portion of Bell still peer locally? Tom > On Aug 8, 2017, at 8:10 PM, Bill Woodcock wrote: > > >> On Jul 20, 2017, at 7:01 AM, Hiers, David wrote: >> For traffic routing, is anyone constraining cross-border routing between Canada and the US? IOW, if you are routing from Toronto to Montreal, do you have to guarantee that the path cannot go through, say, Syracuse, New York? > > No. In fact, Bell Canada / Bell Aliant and Telus guarantee that you _will_ go through Chicago, Seattle, New York, or Ashburn, since none of them peer anywhere in Canada at all. > > Last I checked (November of last year) the best-connected commercial networks (i.e. not CANARIE) in Canada were Hurricane Electric, MTS Allstream, Primus, and Zip Telecom, all of which peer at three or more Canadian IXes. So, they’re capable of keeping traffic in Canada so long as the other end isn’t on Bell or Telus, which only sell U.S. bandwidth to Canadians. > > In November, only 27% of intra-Canadian routes stayed within Canada; 64% went through the U.S. That’s way worse than five years ago, when 60% stayed within Canada, and 38% went through the U.S. > > As has been pointed out, Canada has been building IXPs… Just not as fast as the rest of the world has. They’re behind the global average growth rate, and behind the U.S. growth rate, which is why the problem is getting worse. Bandwidth costs are falling faster elsewhere, so they’re importing more foreign bandwidth. > > -Bill > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP URL: From nanog at ics-il.net Wed Aug 9 00:25:56 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 8 Aug 2017 19:25:56 -0500 (CDT) Subject: Admiral Hosting in London In-Reply-To: <0B2D86A2-2DF4-45B7-ADEF-578B2745A300@semihuman.com> References: <20170727195401.GI7311@manor.msen.com> <0B2D86A2-2DF4-45B7-ADEF-578B2745A300@semihuman.com> Message-ID: <1564632542.3131.1502238354219.JavaMail.mhammett@ThunderFuck> I've heard of some people that don't have the capital to purchase their own block yet, but want PI space so they can move away from whomever is providing their transit + IP space now. I'm sure the discussed reason is much more prevalent, though. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Chris Woodfield" To: "Randy Bush" , "Michael Wayne" Cc: "NANOG list" Sent: Monday, July 31, 2017 11:31:47 AM Subject: Re: Admiral Hosting in London And I’d *love* to hear the story they come up with when you ask why they only want to rent space vs buy it… -C > On Jul 27, 2017, at 9:22 PM, Randy Bush wrote: > >> We were contacted by Admiral Hosting in London to rent some our >> unused IP space. > > anyone wanting to rent/lease space is 99% sure to be not nice folk. > if you get your space back, it will be radioactive with an amazingly > long half life. > > if you are willing to let go of the space, just tell them the price > for which you are willing to sell it. > > randy > From woody at pch.net Wed Aug 9 00:30:26 2017 From: woody at pch.net (Bill Woodcock) Date: Tue, 8 Aug 2017 17:30:26 -0700 Subject: US/Canada International border concerns for routing In-Reply-To: <06B16018-48FF-4DD3-9474-05DB14962426@oitc.com> References: <06B16018-48FF-4DD3-9474-05DB14962426@oitc.com> Message-ID: <713DD4FC-ED25-417D-9A2C-047B17FF25B1@pch.net> > On Aug 8, 2017, at 5:19 PM, TR Shaw wrote: > > Bill, > > What does Bell buying MTS do? Does it change your statement or will the MTS portion of Bell still peer locally? I’d have to go back and look at the actual ASNs in our analysis. I think what we called “MTS Allstream” in the chart is actually the Zayo-owned Allstream, not the Bell-owned Bell MTS. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From sf at lists.esoteric.ca Wed Aug 9 00:31:30 2017 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Tue, 8 Aug 2017 20:31:30 -0400 Subject: US/Canada International border concerns for routing In-Reply-To: <06B16018-48FF-4DD3-9474-05DB14962426@oitc.com> References: <06B16018-48FF-4DD3-9474-05DB14962426@oitc.com> Message-ID: TR, MTS Allstream is no longer a combined entity. MTS was purchased by Bell Canada and Allstream was purchased by Zayo. -- Stephen On 2017-08-08 8:19 PM, TR Shaw wrote: > Bill, > > What does Bell buying MTS do? Does it change your statement or will the MTS portion of Bell still peer locally? > > Tom > >> On Aug 8, 2017, at 8:10 PM, Bill Woodcock wrote: >> >> >>> On Jul 20, 2017, at 7:01 AM, Hiers, David wrote: >>> For traffic routing, is anyone constraining cross-border routing between Canada and the US? IOW, if you are routing from Toronto to Montreal, do you have to guarantee that the path cannot go through, say, Syracuse, New York? >> >> No. In fact, Bell Canada / Bell Aliant and Telus guarantee that you _will_ go through Chicago, Seattle, New York, or Ashburn, since none of them peer anywhere in Canada at all. >> >> Last I checked (November of last year) the best-connected commercial networks (i.e. not CANARIE) in Canada were Hurricane Electric, MTS Allstream, Primus, and Zip Telecom, all of which peer at three or more Canadian IXes. So, they’re capable of keeping traffic in Canada so long as the other end isn’t on Bell or Telus, which only sell U.S. bandwidth to Canadians. >> >> In November, only 27% of intra-Canadian routes stayed within Canada; 64% went through the U.S. That’s way worse than five years ago, when 60% stayed within Canada, and 38% went through the U.S. >> >> As has been pointed out, Canada has been building IXPs… Just not as fast as the rest of the world has. They’re behind the global average growth rate, and behind the U.S. growth rate, which is why the problem is getting worse. Bandwidth costs are falling faster elsewhere, so they’re importing more foreign bandwidth. >> >> -Bill >> >> >> >> > From clayton at MNSi.Net Wed Aug 9 00:33:28 2017 From: clayton at MNSi.Net (Clayton Zekelman) Date: Tue, 08 Aug 2017 20:33:28 -0400 Subject: US/Canada International border concerns for routing In-Reply-To: References: Message-ID: <1502238812_32182@surgemail.mnsi.net> With the peering policies of the major Canadian ISPs, you're virtually guaranteed to hairpin through the US on most paths. Robellus (Rogers, Bell & Telus) will peer with you at any of their major Canadian peering points, such as NYC, Chicago or LA. At 10:01 AM 20/07/2017, Hiers, David wrote: >Hi, >We're looking to extend some services into Canada. While our >lawyers dig into it, I thought that I'd ask the hive mind about >border restrictions. > >For traffic routing, is anyone constraining cross-border routing >between Canada and the US? IOW, if you are routing from Toronto to >Montreal, do you have to guarantee that the path cannot go through, >say, Syracuse, New York? > >I'm asking network operators about packet routing; data storage is a >very different matter, of course. > >Thanks, > >David > >---------------------------------------------------------------------- >This message and any attachments are intended only for the use of >the addressee and may contain information that is privileged and >confidential. If the reader of the message is not the intended >recipient or an authorized representative of the intended recipient, >you are hereby notified that any dissemination of this communication >is strictly prohibited. If you have received this communication in >error, notify the sender immediately by return email and delete the >message and any attachments from your system. -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From woody at pch.net Wed Aug 9 00:41:12 2017 From: woody at pch.net (Bill Woodcock) Date: Tue, 8 Aug 2017 17:41:12 -0700 Subject: US/Canada International border concerns for routing In-Reply-To: <1502238812_32182@surgemail.mnsi.net> References: <1502238812_32182@surgemail.mnsi.net> Message-ID: > On Aug 8, 2017, at 5:33 PM, Clayton Zekelman wrote: > > > > With the peering policies of the major Canadian ISPs, you're virtually guaranteed to hairpin through the US on most paths. > > Robellus (Rogers, Bell & Telus) will peer with you at any of their major Canadian peering points, such as NYC, Chicago or LA. To be fair, Rogers does peer in Toronto. Along with New York, Chicago, Seattle, and Ashburn. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From ktims at stargate.ca Wed Aug 9 00:48:26 2017 From: ktims at stargate.ca (Keenan Tims) Date: Tue, 8 Aug 2017 17:48:26 -0700 Subject: US/Canada International border concerns for routing In-Reply-To: References: Message-ID: On 2017-08-08 17:10, Bill Woodcock wrote: > No. In fact, Bell Canada / Bell Aliant and Telus guarantee that you_will_ go through Chicago, Seattle, New York, or Ashburn, since none of them peer anywhere in Canada at all. The major national networks (Bell, Rogers, Telus, Shaw, Zayo/Allstream) do peer with each other and some other large / old Canadian networks (e.g. MTS, SaskTel, Peer1) within Canada. While they do practice peering protectionism and only purchase transit out of country, the situation is not *quite* so bad that all traffic round-trips through the US. Of course if neither side of the conversation has at least one of those major networks as a transit upstream - which is most of the eyeballs and most of the important Canadian content - you'll see that hop through Chicago or Seattle (or worse). Which is exactly the way they like it. Keenan From craetdave at gmail.com Wed Aug 9 00:52:43 2017 From: craetdave at gmail.com (Dave Cohen) Date: Tue, 8 Aug 2017 20:52:43 -0400 Subject: US/Canada International border concerns for routing Message-ID: <6FB948C4-EF91-4726-ABDD-A3B40DE99BCA@gmail.com> It seems to me the original question was asking about it more from a legal perspective, in other words does Canadian traffic have to stay in Canada. IANAL (or a Canadian), but the answer is "mostly, no, especially as related to publicly routed traffic" as should be evidenced based on what's already been discussed here. In other words, there is restricted traffic but unless you're making a play for MAN/WAN type service on owned infrastructure, those requirements are unlikely to arise. To support the macro point, there is some big-boy level peering in Toronto but not really much else outside that, but there are plenty of routes that don't cross the border if you don't have to jump networks to your destination, for example going to an AWS on ramp in Canada using a native partner network, especially in the Toronto-Ottawa-Montreal. Dave Cohen craetdave at gmail.com > On Aug 8, 2017, at 8:41 PM, Bill Woodcock wrote: > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=us-ascii > > >> On Aug 8, 2017, at 5:33 PM, Clayton Zekelman wrote: >> =20 >> =20 >> =20 >> With the peering policies of the major Canadian ISPs, you're virtually = > guaranteed to hairpin through the US on most paths. >> =20 >> Robellus (Rogers, Bell & Telus) will peer with you at any of their = > major Canadian peering points, such as NYC, Chicago or LA. > > To be fair, Rogers does peer in Toronto. Along with New York, Chicago, = > Seattle, and Ashburn. > > -Bill > > > > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename=signature.asc > Content-Type: application/pgp-signature; > name=signature.asc > Content-Description: Message signed with OpenPGP > > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCAAGBQJZilooAAoJEG+kcEsoi3+HgNsQAIPkgL/lVL/j1sdPyiyQsepE > TCyHm4bsAq6m085kXoRj/IWn+KsVwmAq8ZGKnKEAiozmrSeyxAa2vmw5Kfs57l1/ > crBima+EOOlPT4VcD7tv9e8yEiVdjDuMp5tnLI238qCfIlHeHRtuU7CClzWPv6uD > 3jCNIBEcScrLWz37Ofm/D2AkYRAhhK5H8I417Y/39TH4MIoIKFsGbvWwpl30Fv8r > 5phO0MrTP6mB8niHne6HTxyMED5TGQpVEL2Qgh6qgaI9vzAs5/47KwwY57tZpxaL > v9GjkPJ4Ql7QVWbsSkXnFmHxXzqaHXAfg8SR+gsCN42Jyn99AIyAAwdALhqc4RuZ > ydi+lOlEutAMndA01CnrI81Eu/RpWrN+q/vi37W2rb6EPTPcCz2196JDlpC6VVW6 > tJOMNuP6Pa/ee52Cxu6RWwA4QZ6QVIT9fbDcRFXTGNuohwP8XVpujcsPLChzsFXA > Y2nt+TliL697lTZNbTZEzQ0f9w2rpCDpcLjTMCR8MNWZ4MjQHL3eDgO5ZIWHPTQf > ggR1Dz2EhPSXXZdvN7KPh1q9rhRb2VUPSn3EeEDo2TjgUVeUlunsDg/ILpf8lxUY > RTsXe5Nky7YqXKDG4HSlLF3R/RtfaVqKJfjljYg351cs40rzivzjD2TJ8r35RQeW > btKUtEvrcU28g15nOhLG > =MTUG > -----END PGP SIGNATURE----- > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E-- > From clayton at MNSi.Net Wed Aug 9 00:53:12 2017 From: clayton at MNSi.Net (Clayton Zekelman) Date: Tue, 08 Aug 2017 20:53:12 -0400 Subject: US/Canada International border concerns for routing In-Reply-To: References: <1502238812_32182@surgemail.mnsi.net> Message-ID: <1502239996_32229@surgemail.mnsi.net> OK, Maybe I was a bit overly dramatic. One of the big 3 peered with us in a US location, but refused to peer in Canada. I can't recall if we actually did specifically ask Rogers at one point or not. I know we haven't asked recently. At 08:41 PM 08/08/2017, Bill Woodcock wrote: > > On Aug 8, 2017, at 5:33 PM, Clayton Zekelman wrote: > > > > > > > > With the peering policies of the major Canadian ISPs, you're > virtually guaranteed to hairpin through the US on most paths. > > > > Robellus (Rogers, Bell & Telus) will peer with you at any of > their major Canadian peering points, such as NYC, Chicago or LA. > >To be fair, Rogers does peer in Toronto. Along with New York, >Chicago, Seattle, and Ashburn. > > -Bill > > > > > -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From nanog at ics-il.net Wed Aug 9 00:59:29 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 8 Aug 2017 19:59:29 -0500 (CDT) Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: Message-ID: <462128132.3290.1502240367069.JavaMail.mhammett@ThunderFuck> 1.9.7+hotfix.1 is the currently available stable. 1.9.1.1 was released on May 1st. https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-EdgeRouter-software-security-release-v1-9-7-hotfix-1/ba-p/2019161 ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Nick W" To: nanog at nanog.org Sent: Thursday, July 20, 2017 10:55:28 PM Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"? Tried the Infinity, unsuccessfully. Several of them. Ended up pulling them all, sitting in my homelab for now. Multiple full tables, nothing fancy for firewall or QOS, but ran into issues with random ribd/bgpd crashes and kernel panics. I've submitted a lot of logs and core dumps to UBNT. I would personally stay away from them until they are out of beta, and possibly even another 6-12 months after that. The current stable EdgeMax version (1.9.1.1) is relatively stable, but using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, BGP) - nothing too major, but can be annoying. Probably okay for what you described. Depending on how much throughput you need, an ERPro, or Mikrotik would probably be fine. If you need 10G, load up VyOS on some cheap servers with an Intel or Solarflare card... probably cheaper than a beta Infinity or Mikrotik. On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders wrote: > Dear NANOG, > > Some friends of mine are operating a nonprofit (on shoe string) and looking > to connect some CDN caches to an IX fabric. A BGP speaking device is needed > between the caches and the BGP peers connected to the fabric. The BGP > speaker is needed to present the peers on the IX with a unified view of the > assemblage of CDN nodes. > > I was wondering whether anyone was experience with the "EdgeRouter Infinity > XG" device, specifically in the role of a simple peering router for a > couple of tens of thousands of routes. (I'd point default to the left and > take just the on-net routes on the right to reduce the table size > requirement). > > I hope the device can do at least 2xLACP trunks, has a sizable FIB, is > automatable (supports idempotency), can forward IMIX at line-rate, *flow, > and exposes some telemetry via SNMP. > > Any note sharing would be appreciated! > > Kind regards, > > Job > From josh at kyneticwifi.com Wed Aug 9 01:07:36 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Tue, 8 Aug 2017 20:07:36 -0500 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: <462128132.3290.1502240367069.JavaMail.mhammett@ThunderFuck> References: <462128132.3290.1502240367069.JavaMail.mhammett@ThunderFuck> Message-ID: Forgot reply all... That does not apply to the infinity. Those shipped with 1.9.8dev. On Aug 8, 2017 8:03 PM, "Mike Hammett" wrote: > 1.9.7+hotfix.1 is the currently available stable. 1.9.1.1 was released on > May 1st. > > https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX- > EdgeRouter-software-security-release-v1-9-7-hotfix-1/ba-p/2019161 > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Nick W" > To: nanog at nanog.org > Sent: Thursday, July 20, 2017 10:55:28 PM > Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"? > > Tried the Infinity, unsuccessfully. Several of them. Ended up pulling them > all, sitting in my homelab for now. Multiple full tables, nothing fancy for > firewall or QOS, but ran into issues with random ribd/bgpd crashes and > kernel panics. I've submitted a lot of logs and core dumps to UBNT. I would > personally stay away from them until they are out of beta, and possibly > even another 6-12 months after that. > > The current stable EdgeMax version (1.9.1.1) is relatively stable, but > using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, BGP) > - nothing too major, but can be annoying. Probably okay for what you > described. Depending on how much throughput you need, an ERPro, or Mikrotik > would probably be fine. If you need 10G, load up VyOS on some cheap servers > with an Intel or Solarflare card... probably cheaper than a beta Infinity > or Mikrotik. > > On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders wrote: > > > Dear NANOG, > > > > Some friends of mine are operating a nonprofit (on shoe string) and > looking > > to connect some CDN caches to an IX fabric. A BGP speaking device is > needed > > between the caches and the BGP peers connected to the fabric. The BGP > > speaker is needed to present the peers on the IX with a unified view of > the > > assemblage of CDN nodes. > > > > I was wondering whether anyone was experience with the "EdgeRouter > Infinity > > XG" device, specifically in the role of a simple peering router for a > > couple of tens of thousands of routes. (I'd point default to the left and > > take just the on-net routes on the right to reduce the table size > > requirement). > > > > I hope the device can do at least 2xLACP trunks, has a sizable FIB, is > > automatable (supports idempotency), can forward IMIX at line-rate, *flow, > > and exposes some telemetry via SNMP. > > > > Any note sharing would be appreciated! > > > > Kind regards, > > > > Job > > > > From nanog at ics-il.net Wed Aug 9 01:20:26 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 8 Aug 2017 20:20:26 -0500 (CDT) Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: <462128132.3290.1502240367069.JavaMail.mhammett@ThunderFuck> Message-ID: <226392852.3311.1502241625839.JavaMail.mhammett@ThunderFuck> Ah, okay. I haven't used one yet. Also, I don't talk about beta outside of beta. ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Josh Reynolds" To: "Mike Hammett" Cc: "NANOG" Sent: Tuesday, August 8, 2017 8:07:36 PM Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"? Forgot reply all... That does not apply to the infinity. Those shipped with 1.9.8dev. On Aug 8, 2017 8:03 PM, "Mike Hammett" < nanog at ics-il.net > wrote: 1.9.7+hotfix.1 is the currently available stable. 1.9.1.1 was released on May 1st. https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-EdgeRouter-software-security-release-v1-9-7-hotfix-1/ba-p/2019161 ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Nick W" < nickdwhite at gmail.com > To: nanog at nanog.org Sent: Thursday, July 20, 2017 10:55:28 PM Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"? Tried the Infinity, unsuccessfully. Several of them. Ended up pulling them all, sitting in my homelab for now. Multiple full tables, nothing fancy for firewall or QOS, but ran into issues with random ribd/bgpd crashes and kernel panics. I've submitted a lot of logs and core dumps to UBNT. I would personally stay away from them until they are out of beta, and possibly even another 6-12 months after that. The current stable EdgeMax version (1.9.1.1) is relatively stable, but using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, BGP) - nothing too major, but can be annoying. Probably okay for what you described. Depending on how much throughput you need, an ERPro, or Mikrotik would probably be fine. If you need 10G, load up VyOS on some cheap servers with an Intel or Solarflare card... probably cheaper than a beta Infinity or Mikrotik. On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders < job at instituut.net > wrote: > Dear NANOG, > > Some friends of mine are operating a nonprofit (on shoe string) and looking > to connect some CDN caches to an IX fabric. A BGP speaking device is needed > between the caches and the BGP peers connected to the fabric. The BGP > speaker is needed to present the peers on the IX with a unified view of the > assemblage of CDN nodes. > > I was wondering whether anyone was experience with the "EdgeRouter Infinity > XG" device, specifically in the role of a simple peering router for a > couple of tens of thousands of routes. (I'd point default to the left and > take just the on-net routes on the right to reduce the table size > requirement). > > I hope the device can do at least 2xLACP trunks, has a sizable FIB, is > automatable (supports idempotency), can forward IMIX at line-rate, *flow, > and exposes some telemetry via SNMP. > > Any note sharing would be appreciated! > > Kind regards, > > Job > From woody at pch.net Wed Aug 9 01:38:52 2017 From: woody at pch.net (Bill Woodcock) Date: Tue, 8 Aug 2017 18:38:52 -0700 Subject: US/Canada International border concerns for routing In-Reply-To: References: Message-ID: <29D547CC-980A-4DBB-87A4-51A7ACBF90F2@pch.net> > On Aug 8, 2017, at 5:48 PM, Keenan Tims wrote: > While they do practice peering protectionism and only purchase transit out of country, the situation is not *quite* so bad that all traffic round-trips through the US. No, not all, 64%. By comparison, only 0.27% of intra-US traffic goes through Canada. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From eric.kuhnke at gmail.com Wed Aug 9 02:13:49 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 8 Aug 2017 19:13:49 -0700 Subject: US/Canada International border concerns for routing In-Reply-To: References: <06B16018-48FF-4DD3-9474-05DB14962426@oitc.com> Message-ID: It is worth noting, however, that the former AllStream ASN (formerly AT&T Canada) AS15290 is a completely different thing, and has distinct infrastructure and routing from the AboveNet ASN which is operated by Zayo. Although they are probably using "Free" Zayo transport by now. If I am grossly wrong and anybody from layer 3 network operations at Zayo wants to chime in and tell us about the 40,000 ft view of their plans to combine AS15290 and AS6461, I am sure the community would be very interested. On Tue, Aug 8, 2017 at 5:31 PM, Stephen Fulton wrote: > TR, > > MTS Allstream is no longer a combined entity. MTS was purchased by Bell > Canada and Allstream was purchased by Zayo. > > -- Stephen > > > On 2017-08-08 8:19 PM, TR Shaw wrote: > >> Bill, >> >> What does Bell buying MTS do? Does it change your statement or will the >> MTS portion of Bell still peer locally? >> >> Tom >> >> On Aug 8, 2017, at 8:10 PM, Bill Woodcock wrote: >>> >>> >>> On Jul 20, 2017, at 7:01 AM, Hiers, David wrote: >>>> For traffic routing, is anyone constraining cross-border routing >>>> between Canada and the US? IOW, if you are routing from Toronto to >>>> Montreal, do you have to guarantee that the path cannot go through, say, >>>> Syracuse, New York? >>>> >>> >>> No. In fact, Bell Canada / Bell Aliant and Telus guarantee that you >>> _will_ go through Chicago, Seattle, New York, or Ashburn, since none of >>> them peer anywhere in Canada at all. >>> >>> Last I checked (November of last year) the best-connected commercial >>> networks (i.e. not CANARIE) in Canada were Hurricane Electric, MTS >>> Allstream, Primus, and Zip Telecom, all of which peer at three or more >>> Canadian IXes. So, they’re capable of keeping traffic in Canada so long as >>> the other end isn’t on Bell or Telus, which only sell U.S. bandwidth to >>> Canadians. >>> >>> In November, only 27% of intra-Canadian routes stayed within Canada; 64% >>> went through the U.S. That’s way worse than five years ago, when 60% >>> stayed within Canada, and 38% went through the U.S. >>> >>> As has been pointed out, Canada has been building IXPs… Just not as >>> fast as the rest of the world has. They’re behind the global average >>> growth rate, and behind the U.S. growth rate, which is why the problem is >>> getting worse. Bandwidth costs are falling faster elsewhere, so they’re >>> importing more foreign bandwidth. >>> >>> -Bill >>> >>> >>> >>> >>> >> From edugas at unknowndevice.ca Wed Aug 9 02:27:51 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Wed, 09 Aug 2017 02:27:51 +0000 Subject: US/Canada International border concerns for routing In-Reply-To: <1502239996_32229@surgemail.mnsi.net> References: <1502238812_32182@surgemail.mnsi.net> <1502239996_32229@surgemail.mnsi.net> Message-ID: From rsk at gsp.org Wed Aug 9 12:49:07 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 9 Aug 2017 08:49:07 -0400 Subject: AS202746 Hijacks: Is Telia (a) stupid, or (b) lazy, or (c) complicit? In-Reply-To: <20170802155143.GC20621@danton.fire-world.de> References: <7098.1501659387@segfault.tristatelogic.com> <20170802155143.GC20621@danton.fire-world.de> Message-ID: <20170809124907.GA25150@gsp.org> On Wed, Aug 02, 2017 at 05:51:43PM +0200, Sebastian Wiesinger wrote: > You know, people might be more willing to listen to you when you > express your points in a less emotional and aggressive tone. You know, lots of us tried that for the first ten or twenty years. But snark aside, I care a lot more about the actionable intelligence being provided than the manner of its presentation. Ron has been doing valuable, useful research for years and has been kind enough to share the results with us. For free. I'm grateful for that. ---rsk From rod.beck at unitedcablecompany.com Wed Aug 9 12:50:32 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Wed, 9 Aug 2017 12:50:32 +0000 Subject: US/Canada International border concerns for routing In-Reply-To: References: <06B16018-48FF-4DD3-9474-05DB14962426@oitc.com> , Message-ID: Hi Eric, Allstream fiber goes counterclockwise from Toronto to Buffalo along the lake. Just like the rest of them. And at several places all these sysgtems are probably in the same conduit. Finally, all fiber is exhausted Toronto/Buffalo. Existing players could not sell if they wanted to and no one selling dark on this route today. - R. ________________________________ From: NANOG on behalf of Eric Kuhnke Sent: Wednesday, August 9, 2017 4:13 AM To: Stephen Fulton; nanog at nanog.org list Subject: Re: US/Canada International border concerns for routing It is worth noting, however, that the former AllStream ASN (formerly AT&T Canada) AS15290 is a completely different thing, and has distinct infrastructure and routing from the AboveNet ASN which is operated by Zayo. Although they are probably using "Free" Zayo transport by now. If I am grossly wrong and anybody from layer 3 network operations at Zayo wants to chime in and tell us about the 40,000 ft view of their plans to combine AS15290 and AS6461, I am sure the community would be very interested. On Tue, Aug 8, 2017 at 5:31 PM, Stephen Fulton wrote: > TR, > > MTS Allstream is no longer a combined entity. MTS was purchased by Bell > Canada and Allstream was purchased by Zayo. > > -- Stephen > > > On 2017-08-08 8:19 PM, TR Shaw wrote: > >> Bill, >> >> What does Bell buying MTS do? Does it change your statement or will the >> MTS portion of Bell still peer locally? >> >> Tom >> >> On Aug 8, 2017, at 8:10 PM, Bill Woodcock wrote: >>> >>> >>> On Jul 20, 2017, at 7:01 AM, Hiers, David wrote: >>>> For traffic routing, is anyone constraining cross-border routing >>>> between Canada and the US? IOW, if you are routing from Toronto to >>>> Montreal, do you have to guarantee that the path cannot go through, say, >>>> Syracuse, New York? >>>> >>> >>> No. In fact, Bell Canada / Bell Aliant and Telus guarantee that you >>> _will_ go through Chicago, Seattle, New York, or Ashburn, since none of >>> them peer anywhere in Canada at all. >>> >>> Last I checked (November of last year) the best-connected commercial >>> networks (i.e. not CANARIE) in Canada were Hurricane Electric, MTS >>> Allstream, Primus, and Zip Telecom, all of which peer at three or more >>> Canadian IXes. So, they’re capable of keeping traffic in Canada so long as >>> the other end isn’t on Bell or Telus, which only sell U.S. bandwidth to >>> Canadians. >>> >>> In November, only 27% of intra-Canadian routes stayed within Canada; 64% >>> went through the U.S. That’s way worse than five years ago, when 60% >>> stayed within Canada, and 38% went through the U.S. >>> >>> As has been pointed out, Canada has been building IXPs… Just not as >>> fast as the rest of the world has. They’re behind the global average >>> growth rate, and behind the U.S. growth rate, which is why the problem is >>> getting worse. Bandwidth costs are falling faster elsewhere, so they’re >>> importing more foreign bandwidth. >>> >>> -Bill >>> >>> >>> >>> >>> >> From andrew at thekerrs.ca Wed Aug 9 01:02:50 2017 From: andrew at thekerrs.ca (Andrew Kerr) Date: Wed, 09 Aug 2017 01:02:50 +0000 Subject: US/Canada International border concerns for routing In-Reply-To: <6FB948C4-EF91-4726-ABDD-A3B40DE99BCA@gmail.com> References: <6FB948C4-EF91-4726-ABDD-A3B40DE99BCA@gmail.com> Message-ID: Canadian here who's evaluated service providers and dealt with legal requirements for our customers... Generally we weren't worried about data travelling through the US based on normal internet routes, as long as it was encrypted. The thing we usually specified in RFPs was that the data could never be stored in the US. On Tue, 8 Aug 2017 at 17:52 Dave Cohen wrote > It seems to me the original question was asking about it more from a legal > perspective, in other words does Canadian traffic have to stay in Canada. > IANAL (or a Canadian), but the answer is "mostly, no, especially as related > to publicly routed traffic" as should be evidenced based on what's already > been discussed here. In other words, there is restricted traffic but unless > you're making a play for MAN/WAN type service on owned infrastructure, > those requirements are unlikely to arise. > > To support the macro point, there is some big-boy level peering in Toronto > but not really much else outside that, but there are plenty of routes that > don't cross the border if you don't have to jump networks to your > destination, for example going to an AWS on ramp in Canada using a native > partner network, especially in the Toronto-Ottawa-Montreal. > > Dave Cohen > craetdave at gmail.com > > > On Aug 8, 2017, at 8:41 PM, Bill Woodcock wrote: > > > > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E > > Content-Transfer-Encoding: quoted-printable > > Content-Type: text/plain; > > charset=us-ascii > > > > > >> On Aug 8, 2017, at 5:33 PM, Clayton Zekelman wrote: > >> =20 > >> =20 > >> =20 > >> With the peering policies of the major Canadian ISPs, you're virtually = > > guaranteed to hairpin through the US on most paths. > >> =20 > >> Robellus (Rogers, Bell & Telus) will peer with you at any of their = > > major Canadian peering points, such as NYC, Chicago or LA. > > > > To be fair, Rogers does peer in Toronto. Along with New York, Chicago, = > > Seattle, and Ashburn. > > > > -Bill > > > > > > > > > > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E > > Content-Transfer-Encoding: 7bit > > Content-Disposition: attachment; > > filename=signature.asc > > Content-Type: application/pgp-signature; > > name=signature.asc > > Content-Description: Message signed with OpenPGP > > > > -----BEGIN PGP SIGNATURE----- > > > > iQIcBAEBCAAGBQJZilooAAoJEG+kcEsoi3+HgNsQAIPkgL/lVL/j1sdPyiyQsepE > > TCyHm4bsAq6m085kXoRj/IWn+KsVwmAq8ZGKnKEAiozmrSeyxAa2vmw5Kfs57l1/ > > crBima+EOOlPT4VcD7tv9e8yEiVdjDuMp5tnLI238qCfIlHeHRtuU7CClzWPv6uD > > 3jCNIBEcScrLWz37Ofm/D2AkYRAhhK5H8I417Y/39TH4MIoIKFsGbvWwpl30Fv8r > > 5phO0MrTP6mB8niHne6HTxyMED5TGQpVEL2Qgh6qgaI9vzAs5/47KwwY57tZpxaL > > v9GjkPJ4Ql7QVWbsSkXnFmHxXzqaHXAfg8SR+gsCN42Jyn99AIyAAwdALhqc4RuZ > > ydi+lOlEutAMndA01CnrI81Eu/RpWrN+q/vi37W2rb6EPTPcCz2196JDlpC6VVW6 > > tJOMNuP6Pa/ee52Cxu6RWwA4QZ6QVIT9fbDcRFXTGNuohwP8XVpujcsPLChzsFXA > > Y2nt+TliL697lTZNbTZEzQ0f9w2rpCDpcLjTMCR8MNWZ4MjQHL3eDgO5ZIWHPTQf > > ggR1Dz2EhPSXXZdvN7KPh1q9rhRb2VUPSn3EeEDo2TjgUVeUlunsDg/ILpf8lxUY > > RTsXe5Nky7YqXKDG4HSlLF3R/RtfaVqKJfjljYg351cs40rzivzjD2TJ8r35RQeW > > btKUtEvrcU28g15nOhLG > > =MTUG > > -----END PGP SIGNATURE----- > > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E-- > > > From ahad at swiftelnetworks.com Wed Aug 9 03:19:37 2017 From: ahad at swiftelnetworks.com (Ahad Aboss) Date: Wed, 09 Aug 2017 03:19:37 +0000 Subject: US/Canada International border concerns for routing In-Reply-To: References: Message-ID: David Generally speaking, when customers have concerns about their traffic crossing borders, they do ask upfront. As a multinational operator you can only guarantee traffic if customers asks and offcours pays the fee for special class of service. Ahad On Wed, 9 Aug 2017 at 9:21 am, Hiers, David wrote: > Hi, > We're looking to extend some services into Canada. While our lawyers dig > into it, I thought that I'd ask the hive mind about border restrictions. > > For traffic routing, is anyone constraining cross-border routing between > Canada and the US? IOW, if you are routing from Toronto to Montreal, do > you have to guarantee that the path cannot go through, say, Syracuse, New > York? > > I'm asking network operators about packet routing; data storage is a very > different matter, of course. > > Thanks, > > David > > ---------------------------------------------------------------------- > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, notify the sender immediately by > return email and delete the message and any attachments from your system. > From brock at bmwl.co Wed Aug 9 01:16:27 2017 From: brock at bmwl.co (Brock Tice) Date: Tue, 08 Aug 2017 19:16:27 -0600 Subject: Admiral Hosting in London In-Reply-To: <1564632542.3131.1502238354219.JavaMail.mhammett@ThunderFuck> References: <20170727195401.GI7311@manor.msen.com> <0B2D86A2-2DF4-45B7-ADEF-578B2745A300@semihuman.com> <1564632542.3131.1502238354219.JavaMail.mhammett@ThunderFuck> Message-ID: <8A5F7D9D-FE10-440C-862A-C2CC63B2B1B9@bmwl.co> On August 8, 2017 6:25:56 PM MDT, Mike Hammett wrote: >I've heard of some people that don't have the capital to purchase their >own block yet, but want PI space so they can move away from whomever is >providing their transit + IP space now. I'm sure the discussed reason >is much more prevalent, though. > > > > >----- >Mike Hammett >Intelligent Computing Solutions >http://www.ics-il.com > >Midwest-IX >http://www.midwest-ix.com > >----- Original Message ----- > >From: "Chris Woodfield" >To: "Randy Bush" , "Michael Wayne" >Cc: "NANOG list" >Sent: Monday, July 31, 2017 11:31:47 AM >Subject: Re: Admiral Hosting in London > >And I’d *love* to hear the story they come up with when you ask why >they only want to rent space vs buy it… > >-C > >> On Jul 27, 2017, at 9:22 PM, Randy Bush wrote: >> >>> We were contacted by Admiral Hosting in London to rent some our >>> unused IP space. >> >> anyone wanting to rent/lease space is 99% sure to be not nice folk. >> if you get your space back, it will be radioactive with an amazingly >> long half life. >> >> if you are willing to let go of the space, just tell them the price >> for which you are willing to sell it. >> >> randy >> We are renting space to supplement our ARIN IPv4 allocation until we get 464xlat going. Some of the IPs had bad reputations but we sorted them out. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From David.Hiers at cdk.com Wed Aug 9 01:11:13 2017 From: David.Hiers at cdk.com (Hiers, David) Date: Wed, 9 Aug 2017 01:11:13 +0000 Subject: US/Canada International border concerns for routing In-Reply-To: <6FB948C4-EF91-4726-ABDD-A3B40DE99BCA@gmail.com> References: <6FB948C4-EF91-4726-ABDD-A3B40DE99BCA@gmail.com> Message-ID: I can't thank everyone enough for their input and insight! It sounds like my discovery didn't miss some glaringly obvious form, checkbox, agreement or community (NO-US-EH, for instance ) to keep traffic from crossing the border. Data *storage*, on the other hand, is a very different thing, and even a drunk intern can find the rules around that kind of thing. Thanks again, David -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Dave Cohen Sent: Tuesday, August 08, 2017 5:53 PM To: Bill Woodcock Cc: nanog at nanog.org Subject: Re: US/Canada International border concerns for routing It seems to me the original question was asking about it more from a legal perspective, in other words does Canadian traffic have to stay in Canada. IANAL (or a Canadian), but the answer is "mostly, no, especially as related to publicly routed traffic" as should be evidenced based on what's already been discussed here. In other words, there is restricted traffic but unless you're making a play for MAN/WAN type service on owned infrastructure, those requirements are unlikely to arise. To support the macro point, there is some big-boy level peering in Toronto but not really much else outside that, but there are plenty of routes that don't cross the border if you don't have to jump networks to your destination, for example going to an AWS on ramp in Canada using a native partner network, especially in the Toronto-Ottawa-Montreal. Dave Cohen craetdave at gmail.com > On Aug 8, 2017, at 8:41 PM, Bill Woodcock wrote: > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=us-ascii > > >> On Aug 8, 2017, at 5:33 PM, Clayton Zekelman wrote: >> =20 >> =20 >> =20 >> With the peering policies of the major Canadian ISPs, you're >> virtually = > guaranteed to hairpin through the US on most paths. >> =20 >> Robellus (Rogers, Bell & Telus) will peer with you at any of their = > major Canadian peering points, such as NYC, Chicago or LA. > > To be fair, Rogers does peer in Toronto. Along with New York, > Chicago, = Seattle, and Ashburn. > > -Bill > > > > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename=signature.asc > Content-Type: application/pgp-signature; > name=signature.asc > Content-Description: Message signed with OpenPGP > > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCAAGBQJZilooAAoJEG+kcEsoi3+HgNsQAIPkgL/lVL/j1sdPyiyQsepE > TCyHm4bsAq6m085kXoRj/IWn+KsVwmAq8ZGKnKEAiozmrSeyxAa2vmw5Kfs57l1/ > crBima+EOOlPT4VcD7tv9e8yEiVdjDuMp5tnLI238qCfIlHeHRtuU7CClzWPv6uD > 3jCNIBEcScrLWz37Ofm/D2AkYRAhhK5H8I417Y/39TH4MIoIKFsGbvWwpl30Fv8r > 5phO0MrTP6mB8niHne6HTxyMED5TGQpVEL2Qgh6qgaI9vzAs5/47KwwY57tZpxaL > v9GjkPJ4Ql7QVWbsSkXnFmHxXzqaHXAfg8SR+gsCN42Jyn99AIyAAwdALhqc4RuZ > ydi+lOlEutAMndA01CnrI81Eu/RpWrN+q/vi37W2rb6EPTPcCz2196JDlpC6VVW6 > tJOMNuP6Pa/ee52Cxu6RWwA4QZ6QVIT9fbDcRFXTGNuohwP8XVpujcsPLChzsFXA > Y2nt+TliL697lTZNbTZEzQ0f9w2rpCDpcLjTMCR8MNWZ4MjQHL3eDgO5ZIWHPTQf > ggR1Dz2EhPSXXZdvN7KPh1q9rhRb2VUPSn3EeEDo2TjgUVeUlunsDg/ILpf8lxUY > RTsXe5Nky7YqXKDG4HSlLF3R/RtfaVqKJfjljYg351cs40rzivzjD2TJ8r35RQeW > btKUtEvrcU28g15nOhLG > =MTUG > -----END PGP SIGNATURE----- > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E-- > ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. From tstevens at cisco.com Tue Aug 8 23:15:33 2017 From: tstevens at cisco.com (Tim Stevenson) Date: Tue, 08 Aug 2017 16:15:33 -0700 Subject: Cisco Nexus 93180YC Switch Feedback In-Reply-To: <20170808224842.GO15390@dilbert.slimey.org> References: <80d84c909fc8414f8619a1446ec5583d@EX-01.m21.local> <201707260331.v6Q3Vtu0027729@bgl-core-1.cisco.com> <20170808224842.GO15390@dilbert.slimey.org> Message-ID: <201708082315.v78NFaXZ007270@bgl-core-3.cisco.com> At 03:48 PM 8/8/2017 Tuesday, Simon Lockhart opined: >On Tue Jul 25, 2017 at 08:31:54PM -0700, Tim Stevenson wrote: > > tstevens-92160yc-1# sh int cap | beg 1/49 | eg Eth|Speed > > Ethernet1/49 > Speed: 40000 > > Ethernet1/50 > Speed: 1000,10000,25000,40000,50000,100000 > > Ethernet1/51 > Speed: 40000 > > Ethernet1/52 > Speed: 1000,10000,25000,40000,50000,100000 > > Ethernet1/53 > Speed: 40000 > > Ethernet1/54 > Speed: 40000 > >Are you sure? I'll claim correctness on a technicality ;) Since the original statement was: "Notably only four of the six 100G ports on the 92160YCX will run at 100G, leaving two at 40G." In the default mode, you get 4 x 40G + 2 x 100G. Good point that there is an optional mode which is 4 x 100G - but there is no 40G in that mode, ports 53-54 are disabled in that mode. Thanks, Tim >xsw-01.ixn# show ver | incl Nexus9 > cisco Nexus9000 C92160YC-X chassis > >xsw-01.ixn# sh int cap | beg 1/49 | eg Eth|Speed >Ethernet1/49 > Speed: 40000,100000 >Ethernet1/50 > Speed: 1000,10000,25000,40000,50000,100000 >Ethernet1/51 > Speed: 1000,10000,25000,40000,50000,100000 >Ethernet1/52 > Speed: 1000,10000,25000,40000,50000,100000 > >xsw-01.ixn# show run | incl portmode >hardware profile portmode 48x25G+4x100G > >xsw-01.ixn(config)# hardware profile portmode ? > 48x25g+2x100g+4x40g 48x25G+2x100G+4x40G port mode > 48x25g+4x100g 48x25G+4x100G port mode > >You can configure how the ports present themselves... > >Simon Tim Stevenson, tstevens at cisco.com Routing & Switching CCIE #5561 Distinguished Engineer, Technical Marketing Data Center Switching Cisco - http://www.cisco.com +1(408)526-6759 From rod.beck at unitedcablecompany.com Wed Aug 9 13:17:47 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Wed, 9 Aug 2017 13:17:47 +0000 Subject: US/Canada International border concerns for routing In-Reply-To: References: , Message-ID: I would bet that most British Columbia traffic gets routed to Vancouver>Seattle. Just a hunch, but I suspect that connectivity capacity across Canada from British Columbia to the Eastern part of the country is pretty limited. - R. ________________________________ From: NANOG on behalf of Keenan Tims Sent: Wednesday, August 9, 2017 2:48 AM To: nanog at nanog.org Subject: Re: US/Canada International border concerns for routing On 2017-08-08 17:10, Bill Woodcock wrote: > No. In fact, Bell Canada / Bell Aliant and Telus guarantee that you_will_ go through Chicago, Seattle, New York, or Ashburn, since none of them peer anywhere in Canada at all. The major national networks (Bell, Rogers, Telus, Shaw, Zayo/Allstream) do peer with each other and some other large / old Canadian networks (e.g. MTS, SaskTel, Peer1) within Canada. While they do practice peering protectionism and only purchase transit out of country, the situation is not *quite* so bad that all traffic round-trips through the US. Of course if neither side of the conversation has at least one of those major networks as a transit upstream - which is most of the eyeballs and most of the important Canadian content - you'll see that hop through Chicago or Seattle (or worse). Which is exactly the way they like it. Keenan From rod.beck at unitedcablecompany.com Wed Aug 9 13:25:09 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Wed, 9 Aug 2017 13:25:09 +0000 Subject: US/Canada International border concerns for routing In-Reply-To: References: , Message-ID: I am not sure that this answers your question, but carriers are looking for more diversity on cross border traffic. Right now virtually all Toronto/NYC runs through Buffalo and 350 Main, Buffalo. May be Montreal/NYC has more options. There have been huge network builds in the US Northeast by Unite and Firstlight, which are providing optical backhaul from cell towers. So more routing options may be available than in the past. An issue that no one discussed in the age of the fiber. The big carriers and the Web Giants do not want to 1998 manufactured fiber. And some of the Web Giants are only putting 4x 100 gig waves per fiber pair. So the incentive to create new diverse routes with new large fiber builds is growing. - R. ________________________________ From: NANOG on behalf of Constantine A. Murenin Sent: Wednesday, August 9, 2017 1:54 AM To: Hiers, David Cc: nanog at nanog.org Subject: Re: US/Canada International border concerns for routing On 20/07/2017, Hiers, David wrote: > Hi, > We're looking to extend some services into Canada. While our lawyers dig > into it, I thought that I'd ask the hive mind about border restrictions. > > For traffic routing, is anyone constraining cross-border routing between > Canada and the US? IOW, if you are routing from Toronto to Montreal, do you > have to guarantee that the path cannot go through, say, Syracuse, New York? Guarantee to whom? Back a few years ago when I looked into it, most of the traffic within Canada went through the US, e.g., since Bell didn't want to peer with anyone in Canada, you'd go something like YYZ - ORD - YYZ, clearly visible through the traceroute. Possibly somewhat better nowadays — there's been quite a few new IX POPs that popped up — but I doubt the scenario is a thing of the past. P.S. Just for the giggles — checked http://lg.he.net/ routing from Looking Glass - Hurricane Electric (AS6939) lg.he.net Hurricane Electric (AS6939) Network Looking Glass core1.tor1.he.net to www.bell.ca — still goes through Chicago, to [http://upload.wikimedia.org/wikipedia/commons/thumb/9/91/Bell_logo.svg/120px-Bell_logo.svg.png] Bell Canada - Mobile phones, TV, Internet and Home phone ... www.bell.ca Bell is Canada's largest telecommunications company, providing Mobile phone, TV, high speed and wireless Internet, and residential Home phone services. Montreal, from Toronto. :-) Going straight to Montreal, core1.ymq1.he.net, will route you to www.bell.ca (still in Montreal) [http://upload.wikimedia.org/wikipedia/commons/thumb/9/91/Bell_logo.svg/120px-Bell_logo.svg.png] Bell Canada - Mobile phones, TV, Internet and Home phone ... www.bell.ca Bell is Canada's largest telecommunications company, providing Mobile phone, TV, high speed and wireless Internet, and residential Home phone services. through the peering at NYC. P.P.S. In other words — if someone wants guarantees, they better explicitly ask you for it. Cheers, Constantine. http://cm.su/ cm.su. — Constantine Murenin is Super User cm.su Constantine Murenin is Super User Yes, it's true! Constantine.SU; BXR.SU; mdoc.su; nginx.conf 2016; GitHub; StackOverflow © 2016 Constantine A. Murenin (cnst) From jeff+nanog at waddellsolutions.com Wed Aug 9 13:27:22 2017 From: jeff+nanog at waddellsolutions.com (Jeff Waddell) Date: Wed, 9 Aug 2017 09:27:22 -0400 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: <226392852.3311.1502241625839.JavaMail.mhammett@ThunderFuck> References: <462128132.3290.1502240367069.JavaMail.mhammett@ThunderFuck> <226392852.3311.1502241625839.JavaMail.mhammett@ThunderFuck> Message-ID: When I lasted checked in with Ubiquiti on these issues for that and the ER-Pros - they told me that everything was to be resolved in 2.0.... We shall see... On Tue, Aug 8, 2017 at 9:20 PM, Mike Hammett wrote: > Ah, okay. I haven't used one yet. > > Also, I don't talk about beta outside of beta. ;-) > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Josh Reynolds" > To: "Mike Hammett" > Cc: "NANOG" > Sent: Tuesday, August 8, 2017 8:07:36 PM > Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"? > > > Forgot reply all... > > > That does not apply to the infinity. Those shipped with 1.9.8dev. > > > > > > On Aug 8, 2017 8:03 PM, "Mike Hammett" < nanog at ics-il.net > wrote: > > > 1.9.7+hotfix.1 is the currently available stable. 1.9.1.1 was released on > May 1st. > > https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX- > EdgeRouter-software-security-release-v1-9-7-hotfix-1/ba-p/2019161 > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Nick W" < nickdwhite at gmail.com > > To: nanog at nanog.org > Sent: Thursday, July 20, 2017 10:55:28 PM > Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"? > > Tried the Infinity, unsuccessfully. Several of them. Ended up pulling them > all, sitting in my homelab for now. Multiple full tables, nothing fancy for > firewall or QOS, but ran into issues with random ribd/bgpd crashes and > kernel panics. I've submitted a lot of logs and core dumps to UBNT. I would > personally stay away from them until they are out of beta, and possibly > even another 6-12 months after that. > > The current stable EdgeMax version (1.9.1.1) is relatively stable, but > using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, BGP) > - nothing too major, but can be annoying. Probably okay for what you > described. Depending on how much throughput you need, an ERPro, or Mikrotik > would probably be fine. If you need 10G, load up VyOS on some cheap servers > with an Intel or Solarflare card... probably cheaper than a beta Infinity > or Mikrotik. > > On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders < job at instituut.net > wrote: > > > Dear NANOG, > > > > Some friends of mine are operating a nonprofit (on shoe string) and > looking > > to connect some CDN caches to an IX fabric. A BGP speaking device is > needed > > between the caches and the BGP peers connected to the fabric. The BGP > > speaker is needed to present the peers on the IX with a unified view of > the > > assemblage of CDN nodes. > > > > I was wondering whether anyone was experience with the "EdgeRouter > Infinity > > XG" device, specifically in the role of a simple peering router for a > > couple of tens of thousands of routes. (I'd point default to the left and > > take just the on-net routes on the right to reduce the table size > > requirement). > > > > I hope the device can do at least 2xLACP trunks, has a sizable FIB, is > > automatable (supports idempotency), can forward IMIX at line-rate, *flow, > > and exposes some telemetry via SNMP. > > > > Any note sharing would be appreciated! > > > > Kind regards, > > > > Job > > > > > > > From craetdave at gmail.com Wed Aug 9 15:09:48 2017 From: craetdave at gmail.com (Dave Cohen) Date: Wed, 9 Aug 2017 11:09:48 -0400 Subject: US/Canada International border concerns for routing In-Reply-To: References: <06B16018-48FF-4DD3-9474-05DB14962426@oitc.com> Message-ID: Sorta, kinda. The various ASs operated by Zayo are more interconnected than that description would imply. The traditional mode of operation on an "acquired AS" has been to turn down any upstream transit as quickly as contractually possible and upgrade NNI capacity between that AS and 6461 to compensate. Over time, legacy devices are overbuilt or replaced with ones directly on 6461. The net-net of it is that most traffic will end up egressing to other providers via 6461's peering after a fairly short period, although this isn't universally true, especially for "local" traffic (e.g. traffic originating on the Neo AS staying in France, etc.). Dave Cohen craetdave at gmail.com > On Aug 8, 2017, at 10:13 PM, Eric Kuhnke wrote: > > It is worth noting, however, that the former AllStream ASN (formerly AT&T > Canada) AS15290 is a completely different thing, and has distinct > infrastructure and routing from the AboveNet ASN which is operated by Zayo. > Although they are probably using "Free" Zayo transport by now. > > If I am grossly wrong and anybody from layer 3 network operations at Zayo > wants to chime in and tell us about the 40,000 ft view of their plans to > combine AS15290 and AS6461, I am sure the community would be very > interested. > >> On Tue, Aug 8, 2017 at 5:31 PM, Stephen Fulton wrote: >> >> TR, >> >> MTS Allstream is no longer a combined entity. MTS was purchased by Bell >> Canada and Allstream was purchased by Zayo. >> >> -- Stephen >> >> >>> On 2017-08-08 8:19 PM, TR Shaw wrote: >>> >>> Bill, >>> >>> What does Bell buying MTS do? Does it change your statement or will the >>> MTS portion of Bell still peer locally? >>> >>> Tom >>> >>>> On Aug 8, 2017, at 8:10 PM, Bill Woodcock wrote: >>>> >>>> >>>>> On Jul 20, 2017, at 7:01 AM, Hiers, David wrote: >>>>> For traffic routing, is anyone constraining cross-border routing >>>>> between Canada and the US? IOW, if you are routing from Toronto to >>>>> Montreal, do you have to guarantee that the path cannot go through, say, >>>>> Syracuse, New York? >>>>> >>>> >>>> No. In fact, Bell Canada / Bell Aliant and Telus guarantee that you >>>> _will_ go through Chicago, Seattle, New York, or Ashburn, since none of >>>> them peer anywhere in Canada at all. >>>> >>>> Last I checked (November of last year) the best-connected commercial >>>> networks (i.e. not CANARIE) in Canada were Hurricane Electric, MTS >>>> Allstream, Primus, and Zip Telecom, all of which peer at three or more >>>> Canadian IXes. So, they’re capable of keeping traffic in Canada so long as >>>> the other end isn’t on Bell or Telus, which only sell U.S. bandwidth to >>>> Canadians. >>>> >>>> In November, only 27% of intra-Canadian routes stayed within Canada; 64% >>>> went through the U.S. That’s way worse than five years ago, when 60% >>>> stayed within Canada, and 38% went through the U.S. >>>> >>>> As has been pointed out, Canada has been building IXPs… Just not as >>>> fast as the rest of the world has. They’re behind the global average >>>> growth rate, and behind the U.S. growth rate, which is why the problem is >>>> getting worse. Bandwidth costs are falling faster elsewhere, so they’re >>>> importing more foreign bandwidth. >>>> >>>> -Bill >>>> >>>> >>>> >>>> >>>> >>> From karim.adel at gmail.com Thu Aug 10 00:52:26 2017 From: karim.adel at gmail.com (Kasper Adel) Date: Wed, 9 Aug 2017 17:52:26 -0700 Subject: DevOps workflow for networking Message-ID: We are pretty new to those new-age network orchestrators and automation, I am curious to ask what everyone is the community is doing? sorry for such a long and broad question. What is your workflow? What tools are your teams using? What is working what is not? What do you really like and what do you need to improve? How mature do you think your process is? etc etc Wanted to ask and see what approaches the many different teams here are taking! We are going to start working from a GitLab based workflow. Projects are created, issues entered and developed with a gitflow branching strategy. GitLab CI pipelines run package loadings and run tests inside a lab. Tests are usually python unit tests that are run to do both functional and service creation, modification and removal tests. For unit testing we typically use python libraries to open transactions to do the service modifications (along with functional tests) against physical lab devices. For our prod deployment we leverage 'push on green' and gating to push package changes to prod devices. Thanks From karim.adel at gmail.com Thu Aug 10 01:01:37 2017 From: karim.adel at gmail.com (Kasper Adel) Date: Wed, 9 Aug 2017 18:01:37 -0700 Subject: (Network Orchestrators evaluation) : tail-f vs Anuta vs UBIqube vs OpenDaylight Message-ID: Hi, This is not a vendor bashing thread. We are a group of networking engineers less experience with software) in the middle of the process of procuring a network automation/orchestration controller, if that is even a good definition and we are clueless on how to evaluate them. Other than the obvious, which is to try them out, i wonder what else is important to consider/watch out for. We are presented with 3 different vendors and even OpenDayLight was considered as the open source alternative. My humble thoughts are given below and i would appreciate getting 'schooled' on what i need to ask the vendors: 1) Are they Model driven : But i still don't know how to evaluate that. 2) Do they parse Cisco/Juniper CLI or they are limited to SNMP and YANG. 3) If they do parse, we want to check if they'll hold us by the balls if the current parsers need to be updated, i.e: can we change the code ourselves and add new features to be parsed. 4) Can they work/orchestrate between CLI devices and Non CLI devices (SNMP) 5) How flexible are they to support different Vendors (Cisco, Juniper, some-weird-firewall...etc) thanks, Kim From lathama at gmail.com Thu Aug 10 15:44:12 2017 From: lathama at gmail.com (Andrew Latham) Date: Thu, 10 Aug 2017 10:44:12 -0500 Subject: DevOps workflow for networking In-Reply-To: References: Message-ID: Kasper I know that many are embarrassed to share their overly manual processes and or others are keeping their solutions private. It sounds like you have a solution for your needs. I would add some transparency to the process in the form of a dashboard or summary of status for support staff, security, QA, etc to understand that a particular release was tested, approved and deployed "days" prior to the customer having an issue vs "minutes". Inter-organization communication and socialization for the win! Maybe a poll on workflow would be fun: 1. Break Fix workflow - aka ASAP 2. Whale customer requests only 3. Budget constrained projects only 4. Everything is awesome we get to test all the things AND have single button rollback 5. All of the above depending on the team and department. :) On Wed, Aug 9, 2017 at 7:52 PM, Kasper Adel wrote: > We are pretty new to those new-age network orchestrators and automation, > > I am curious to ask what everyone is the community is doing? sorry for such > a long and broad question. > > What is your workflow? What tools are your teams using? What is working > what is not? What do you really like and what do you need to improve? How > mature do you think your process is? etc etc > > Wanted to ask and see what approaches the many different teams here are > taking! > > We are going to start working from a GitLab based workflow. > > Projects are created, issues entered and developed with a gitflow branching > strategy. > > GitLab CI pipelines run package loadings and run tests inside a lab. > > Tests are usually python unit tests that are run to do both functional and > service creation, modification and removal tests. > > For unit testing we typically use python libraries to open transactions to > do the service modifications (along with functional tests) against physical > lab devices. > > For our prod deployment we leverage 'push on green' and gating to push > package changes to prod devices. > > Thanks > -- - Andrew "lathama" Latham lathama at gmail.com http://lathama.com - From ray at oneunified.net Thu Aug 10 16:41:26 2017 From: ray at oneunified.net (Raymond Burkholder) Date: Thu, 10 Aug 2017 13:41:26 -0300 Subject: DevOps workflow for networking In-Reply-To: References: Message-ID: some observations below: > On 9 Aug 2017, at 21:52, Kasper Adel wrote: > > We are pretty new to those new-age network orchestrators and automation, There are definitely many options out there. With a considerable amount of sophisticated. But fortunately, it is possible to start simple and add layers of abstraction as knowledge and experience is gained. > > I am curious to ask what everyone is the community is doing? sorry for such > a long and broad question. the brief version: we are working towards integrating a SaltStack with Napalm management and orchestration solution. > > What is your workflow? What tools are your teams using? What is working > what is not? What do you really like and what do you need to improve? How > mature do you think your process is? etc etc Things are getting started. I am able to automate the build of servers simply by knowing the mac address and then pxebooting the device. The operating system is installed, auto - reboote. It then automatically gets its total configuration applied , again automatically, from a Salt server. Our operating environment uses Debian. And by incorporating the auto installation of Quagga/FRR, Openvswitch, KVM/Qemu, and LXC into the appropriate devices, it is possible to build a homogenous server/router/switch/virtualization solution with certain devices picking up varying weights of those roles. The people on this list who are running high bandwidth networks, may not see this a much of a benefit, but for smaller operators, I thinks there is value. But then again, when something like Napalm is incorporated into the mix, then automation of the ‘big iron’ becomes part of the overall solution. I came across a CloudFlare slide deck which shows their perspective for management, implementation, and orchestration. https://ripe72.ripe.net/presentations/58-RIPE72-Network-Automation-with-Salt-and-NAPALM-Mircea-Ulinic-CloudFlare.pdf And SaltStack has a proxy minion, which enables it to talk to cli based devices. > > Wanted to ask and see what approaches the many different teams here are > taking! > > We are going to start working from a GitLab based workflow. Salt uses generic ‘state’ files which are completed with device specific settings from ‘pillar’ files. Both of which can be version controlled in git. > > Projects are created, issues entered and developed with a gitflow branching > strategy. > > GitLab CI pipelines run package loadings and run tests inside a lab. I not affiliated with SaltStack, just a happy user. Having said that, various dev/test/prod scenarios can be implemented. With orchestrated work flows and provisioning processes based upon the level of sophistication required. > > Tests are usually python unit tests that are run to do both functional and > service creation, modification and removal tests. Rather than re-inventing the wheel, take a look at SaltStack or Ansible and/or Napalm. All are python based and could probably get you to your target faster than when using Python natively. When it is necessary to go native python on a hairy integration problem, then it is no problem to incorporate Python as needed. > > For unit testing we typically use python libraries to open transactions to > do the service modifications (along with functional tests) against physical > lab devices. Napalm may get you that next level of sophistication where configs can be diff’d before roll-out. > > For our prod deployment we leverage 'push on green' and gating to push > package changes to prod devices. Which can be orchestrated. > > Thanks Raymond Burkholder https://blog.raymond.burkholder.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ray at oneunified.net Thu Aug 10 17:15:44 2017 From: ray at oneunified.net (Raymond Burkholder) Date: Thu, 10 Aug 2017 14:15:44 -0300 Subject: (Network Orchestrators evaluation) : tail-f vs Anuta vs UBIqube vs OpenDaylight In-Reply-To: References: Message-ID: <75BED8E7-9584-4213-93FC-5F06E6C669EE@oneunified.net> > On 9 Aug 2017, at 22:01, Kasper Adel wrote: > > We are a group of networking engineers less experience with software) in > the middle of the process of procuring a network automation/orchestration > controller, if that is even a good definition and we are clueless on how to > evaluate them. There are quite a number of vendors out there. And what you select will probably depend heavily on your budget and network size and abilities. And whether you prefer open source, closed source, or need some mix of home grown solutions. On the heavy duty commercial side, I have heard the name Nuage quite a bit, but no personal experience. > > Other than the obvious, which is to try them out, i wonder what else is > important to consider/watch out for. When relating this email message to your other message, you may need to be thinking about your network automation at a number of different conceptual levels. In my mind, OpenDaylight is more of a low level tool for ‘telling packets where to go’. And is open source. But useful for orchestrating packet movement within overall infrastructure. The other tools mentioned in the subject line are probably closed source and lock you into their way of thinking. To be overwhelmed with SDN style stuff, visit https://www.sdxcentral.com to see if some enlightenment can be found. But as you mentioned in your other message, you may be concerned not only about packet management, but you may have a need to deal with a heterogenous environment of devices, which the applications in the subject line may or may not easily work with. You may need to integrate a number of different tools together. Do you have a ‘wish it could do this’ style of list? > > We are presented with 3 different vendors and even OpenDayLight was > considered as the open source alternative. A big question is how well do they integrate with other automation tools? Vendors like to say they have RESTful interfaces and such. Which means you may need to create a lot of your own glue. Which may or may not be a good thing, depending upon time and skill sets. > > My humble thoughts are given below and i would appreciate getting > 'schooled' on what i need to ask the vendors: > > 1) Are they Model driven : But i still don't know how to evaluate that. The latest buzz word I have heard is ‘intent based networking’. Again that is low level packet handling and infrastructure provisioning. And how well does it integrate with IPAM, DNS, LAN, WAN, security, monitoring, telemetry, alarming, resiliency, … Which, as I write this, reminds me of another layer of sophistication: automatic load levelling. For example, when building Openflow style networks (which OpenDayLight is designed for), and where ECMP is a desired feature, and where failures/upgrades/maintenance/change occurs, it would be nice to have flows routed based upon not only source/destination address/ports, but also on link utilization. Which requires integration with interface and load statistics. There are some linear programming models around which help to turn this into a distributed packet management solution. Is anyone on this implemented solutions like that? > 2) Do they parse Cisco/Juniper CLI or they are limited to SNMP and YANG. Gets in a Napalm style configuration management — open source. > 3) If they do parse, we want to check if they'll hold us by the balls if > the current parsers need to be updated, i.e: can we change the code > ourselves and add new features to be parsed. Can you work with open source? Then you get to contribute back solutions as you encounter unique scenarios. > 4) Can they work/orchestrate between CLI devices and Non CLI devices (SNMP) As someone said recently, SNMP is very popular, but may be waning in certain use scenarios. There may be other ways around this problem. > 5) How flexible are they to support different Vendors (Cisco, Juniper, > some-weird-firewall…etc) If you need vendor supported solutions, then the field narrows somewhat. On the other hand, there are tool sets available which provide good baseline coverage, while allowing you to open the hood and get your hands dirty. Anyway, it sounds like you need to think about many different things: traditional routing / switch protocols, new fangled open flow style packet management, device configuration management, orchestrating upgrades/migrations/repairs, telemetry/monitoring, alarm management … and orchestrating all the bits and pieces to minimise ‘touch’ as network elements are changed. Raymond Burkholder https://blog.raymond.burkholder.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From David.Hiers at cdk.com Wed Aug 9 14:11:28 2017 From: David.Hiers at cdk.com (Hiers, David) Date: Wed, 9 Aug 2017 14:11:28 +0000 Subject: US/Canada International border concerns for routing In-Reply-To: References: <6FB948C4-EF91-4726-ABDD-A3B40DE99BCA@gmail.com> Message-ID: That is what our lawyers are starting to figure out, too. Very glad to see them converging on the tribal wisdom. Cheers, David -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Andrew Kerr Sent: Tuesday, August 08, 2017 6:03 PM To: nanog at nanog.org Subject: Re: US/Canada International border concerns for routing Canadian here who's evaluated service providers and dealt with legal requirements for our customers... Generally we weren't worried about data travelling through the US based on normal internet routes, as long as it was encrypted. The thing we usually specified in RFPs was that the data could never be stored in the US. On Tue, 8 Aug 2017 at 17:52 Dave Cohen wrote > It seems to me the original question was asking about it more from a > legal perspective, in other words does Canadian traffic have to stay in Canada. > IANAL (or a Canadian), but the answer is "mostly, no, especially as > related to publicly routed traffic" as should be evidenced based on > what's already been discussed here. In other words, there is > restricted traffic but unless you're making a play for MAN/WAN type > service on owned infrastructure, those requirements are unlikely to arise. > > To support the macro point, there is some big-boy level peering in > Toronto but not really much else outside that, but there are plenty of > routes that don't cross the border if you don't have to jump networks > to your destination, for example going to an AWS on ramp in Canada > using a native partner network, especially in the Toronto-Ottawa-Montreal. > > Dave Cohen > craetdave at gmail.com > > > On Aug 8, 2017, at 8:41 PM, Bill Woodcock wrote: > > > > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E > > Content-Transfer-Encoding: quoted-printable > > Content-Type: text/plain; > > charset=us-ascii > > > > > >> On Aug 8, 2017, at 5:33 PM, Clayton Zekelman wrote: > >> =20 > >> =20 > >> =20 > >> With the peering policies of the major Canadian ISPs, you're > >> virtually = > > guaranteed to hairpin through the US on most paths. > >> =20 > >> Robellus (Rogers, Bell & Telus) will peer with you at any of their > >> = > > major Canadian peering points, such as NYC, Chicago or LA. > > > > To be fair, Rogers does peer in Toronto. Along with New York, > > Chicago, = Seattle, and Ashburn. > > > > -Bill > > > > > > > > > > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E > > Content-Transfer-Encoding: 7bit > > Content-Disposition: attachment; > > filename=signature.asc > > Content-Type: application/pgp-signature; > > name=signature.asc > > Content-Description: Message signed with OpenPGP > > > > -----BEGIN PGP SIGNATURE----- > > > > iQIcBAEBCAAGBQJZilooAAoJEG+kcEsoi3+HgNsQAIPkgL/lVL/j1sdPyiyQsepE > > TCyHm4bsAq6m085kXoRj/IWn+KsVwmAq8ZGKnKEAiozmrSeyxAa2vmw5Kfs57l1/ > > crBima+EOOlPT4VcD7tv9e8yEiVdjDuMp5tnLI238qCfIlHeHRtuU7CClzWPv6uD > > 3jCNIBEcScrLWz37Ofm/D2AkYRAhhK5H8I417Y/39TH4MIoIKFsGbvWwpl30Fv8r > > 5phO0MrTP6mB8niHne6HTxyMED5TGQpVEL2Qgh6qgaI9vzAs5/47KwwY57tZpxaL > > v9GjkPJ4Ql7QVWbsSkXnFmHxXzqaHXAfg8SR+gsCN42Jyn99AIyAAwdALhqc4RuZ > > ydi+lOlEutAMndA01CnrI81Eu/RpWrN+q/vi37W2rb6EPTPcCz2196JDlpC6VVW6 > > tJOMNuP6Pa/ee52Cxu6RWwA4QZ6QVIT9fbDcRFXTGNuohwP8XVpujcsPLChzsFXA > > Y2nt+TliL697lTZNbTZEzQ0f9w2rpCDpcLjTMCR8MNWZ4MjQHL3eDgO5ZIWHPTQf > > ggR1Dz2EhPSXXZdvN7KPh1q9rhRb2VUPSn3EeEDo2TjgUVeUlunsDg/ILpf8lxUY > > RTsXe5Nky7YqXKDG4HSlLF3R/RtfaVqKJfjljYg351cs40rzivzjD2TJ8r35RQeW > > btKUtEvrcU28g15nOhLG > > =MTUG > > -----END PGP SIGNATURE----- > > > > --Apple-Mail=_8DA28412-F6D0-43D8-A90F-5E151E54468E-- > > > ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. From jean at ddostest.me Wed Aug 9 22:19:11 2017 From: jean at ddostest.me (Jean | ddostest.me) Date: Wed, 9 Aug 2017 18:19:11 -0400 Subject: Spoofer Project In-Reply-To: <20170804011917.GA60443@sorcerer.cms.waikato.ac.nz> References: <20170804011917.GA60443@sorcerer.cms.waikato.ac.nz> Message-ID: <36da6a85-e712-91c3-8c55-0389975babec@ddostest.me> Is it me or NANOG's AS allowing spoofing? https://spoofer.caida.org/as.php?asn=19230 On 17-08-03 09:19 PM, Matthew Luckie wrote: > Hi, > > The CAIDA Spoofer project has been collecting and publicly sharing > data on the deployment of source address validation since March 2016. > We've built up a reasonably large install-base of the open-source > client, and receive tests from 400-500 unique IPs per day. We're > posting reports with links to test outcomes on the spoofer website. > In particular, we've got summary statistics for each AS at: > > https://spoofer.caida.org/as_stats.php > > If you know an operator for anyone on that list who has at least one > spoofable prefix, please feel free to reach out to them and let them > know. I've been sending emails to abuse contacts for nearly a year > now. Roughly 1/5 ASes I've contacted have fixed at least one problem. > The remediation we know about (automatically generated) is at: > > https://spoofer.caida.org/remedy.php > > In order to improve the notification emails, I'm also soliciting > configuration snippets from operators who have deployed source address > validation. If you have deployed SAV and wouldn't mind sharing > redacted configuration (privately is fine) including any necessary > platform details (such as vendor and operating system) we would > greatly appreciate it. We will aggregate and post configuration > snippets at https://spoofer.caida.org/ > > Matthew > From joe at nethead.com Thu Aug 10 02:16:16 2017 From: joe at nethead.com (Joe Hamelin) Date: Wed, 9 Aug 2017 19:16:16 -0700 Subject: DevOps workflow for networking In-Reply-To: References: Message-ID: We've been using this tool since we're a LEAN company, but it actually is a good way to assign tasks/projects and delegate tasks so everyone can see what is going on. Managers can move cards to your active lane or ask why a task/project has stalled. I'm not sure what exactly you are looking for but as a team management tool, this has mostly worked for us for the last 3-4 years. YMMV. https://kanbanize.com/ -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 On Wed, Aug 9, 2017 at 5:52 PM, Kasper Adel wrote: > We are pretty new to those new-age network orchestrators and automation, > > I am curious to ask what everyone is the community is doing? sorry for such > a long and broad question. > > What is your workflow? What tools are your teams using? What is working > what is not? What do you really like and what do you need to improve? How > mature do you think your process is? etc etc > > Wanted to ask and see what approaches the many different teams here are > taking! > > We are going to start working from a GitLab based workflow. > > Projects are created, issues entered and developed with a gitflow branching > strategy. > > GitLab CI pipelines run package loadings and run tests inside a lab. > > Tests are usually python unit tests that are run to do both functional and > service creation, modification and removal tests. > > For unit testing we typically use python libraries to open transactions to > do the service modifications (along with functional tests) against physical > lab devices. > > For our prod deployment we leverage 'push on green' and gating to push > package changes to prod devices. > > Thanks > From randy at psg.com Fri Aug 11 03:34:34 2017 From: randy at psg.com (Randy Bush) Date: Fri, 11 Aug 2017 12:34:34 +0900 Subject: supermicro server visio templates Message-ID: anyone can send $ubject? specifically 1ru & 2ru. one needs a supermicro sales rep, and their email addy to get from supermicro site, and i buy from a reseller. thanks randy From morrowc.lists at gmail.com Fri Aug 11 03:42:34 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 11 Aug 2017 04:42:34 +0100 Subject: supermicro server visio templates In-Reply-To: References: Message-ID: https://miketabor.com/tools/ mike seems to have them on his side.. On Fri, Aug 11, 2017 at 4:34 AM, Randy Bush wrote: > anyone can send $ubject? specifically 1ru & 2ru. > > one needs a supermicro sales rep, and their email addy to get from > supermicro site, and i buy from a reseller. > > thanks > > randy > From george.herbert at gmail.com Fri Aug 11 05:47:15 2017 From: george.herbert at gmail.com (George William Herbert) Date: Thu, 10 Aug 2017 22:47:15 -0700 Subject: supermicro server visio templates In-Reply-To: References: Message-ID: <8C776528-871A-4AFA-B4B9-1EC308BFD1BA@gmail.com> I emailed support at supermicro.com When I needed them, I think, but those I had are years obsolete now and lurking in a corner somewhere. Sent from my iPhone > On Aug 10, 2017, at 8:42 PM, Christopher Morrow wrote: > > https://miketabor.com/tools/ > > mike seems to have them on his side.. > >> On Fri, Aug 11, 2017 at 4:34 AM, Randy Bush wrote: >> >> anyone can send $ubject? specifically 1ru & 2ru. >> >> one needs a supermicro sales rep, and their email addy to get from >> supermicro site, and i buy from a reseller. >> >> thanks >> >> randy >> From randy at psg.com Fri Aug 11 07:07:49 2017 From: randy at psg.com (Randy Bush) Date: Fri, 11 Aug 2017 16:07:49 +0900 Subject: supermicro server visio templates In-Reply-To: References: Message-ID: > https://miketabor.com/tools/A > mike seems to have them on his site.. junk. there is a lot of junk vss out there on the intertubes. randy From large.hadron.collider at gmx.com Fri Aug 11 07:15:45 2017 From: large.hadron.collider at gmx.com (LHC (k9m)) Date: Fri, 11 Aug 2017 00:15:45 -0700 Subject: US/Canada International border concerns for routing In-Reply-To: <1502238812_32182@surgemail.mnsi.net> References: <1502238812_32182@surgemail.mnsi.net> Message-ID: <8B22BF1A-88B0-4854-91B9-9C116F553CD6@gmx.com> You mean ROBALLOFUS right? :-) On August 8, 2017 5:33:28 PM PDT, Clayton Zekelman wrote: > > >With the peering policies of the major Canadian ISPs, you're >virtually guaranteed to hairpin through the US on most paths. > >Robellus (Rogers, Bell & Telus) will peer with you at any of their >major Canadian peering points, such as NYC, Chicago or LA. > > > >At 10:01 AM 20/07/2017, Hiers, David wrote: >>Hi, >>We're looking to extend some services into Canada. While our >>lawyers dig into it, I thought that I'd ask the hive mind about >>border restrictions. >> >>For traffic routing, is anyone constraining cross-border routing >>between Canada and the US? IOW, if you are routing from Toronto to >>Montreal, do you have to guarantee that the path cannot go through, >>say, Syracuse, New York? >> >>I'm asking network operators about packet routing; data storage is a >>very different matter, of course. >> >>Thanks, >> >>David >> >>---------------------------------------------------------------------- >>This message and any attachments are intended only for the use of >>the addressee and may contain information that is privileged and >>confidential. If the reader of the message is not the intended >>recipient or an authorized representative of the intended recipient, >>you are hereby notified that any dissemination of this communication >>is strictly prohibited. If you have received this communication in >>error, notify the sender immediately by return email and delete the >>message and any attachments from your system. > >-- > >Clayton Zekelman >Managed Network Systems Inc. (MNSi) >3363 Tecumseh Rd. E >Windsor, Ontario >N8W 1H4 > >tel. 519-985-8410 >fax. 519-985-8409 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From cheetahmorph at gmail.com Fri Aug 11 07:18:39 2017 From: cheetahmorph at gmail.com (Jippen) Date: Fri, 11 Aug 2017 00:18:39 -0700 Subject: DevOps workflow for networking In-Reply-To: References: Message-ID: To be honest, most companies I've worked at have moved to amazon, where the networking stack has APIs. I've also seen folks who use CI/CD pipelines to generate configuration files for devices that don't directly support automation. On Wed, Aug 9, 2017 at 7:16 PM, Joe Hamelin wrote: > We've been using this tool since we're a LEAN company, but it actually is a > good way to assign tasks/projects and delegate tasks so everyone can see > what is going on. Managers can move cards to your active lane or ask why a > task/project has stalled. > > I'm not sure what exactly you are looking for but as a team management > tool, this has mostly worked for us for the last 3-4 years. YMMV. > > https://kanbanize.com/ > > > > -- > Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 > > On Wed, Aug 9, 2017 at 5:52 PM, Kasper Adel wrote: > > > We are pretty new to those new-age network orchestrators and automation, > > > > I am curious to ask what everyone is the community is doing? sorry for > such > > a long and broad question. > > > > What is your workflow? What tools are your teams using? What is working > > what is not? What do you really like and what do you need to improve? How > > mature do you think your process is? etc etc > > > > Wanted to ask and see what approaches the many different teams here are > > taking! > > > > We are going to start working from a GitLab based workflow. > > > > Projects are created, issues entered and developed with a gitflow > branching > > strategy. > > > > GitLab CI pipelines run package loadings and run tests inside a lab. > > > > Tests are usually python unit tests that are run to do both functional > and > > service creation, modification and removal tests. > > > > For unit testing we typically use python libraries to open transactions > to > > do the service modifications (along with functional tests) against > physical > > lab devices. > > > > For our prod deployment we leverage 'push on green' and gating to push > > package changes to prod devices. > > > > Thanks > > > From randy at psg.com Fri Aug 11 07:25:00 2017 From: randy at psg.com (Randy Bush) Date: Fri, 11 Aug 2017 16:25:00 +0900 Subject: supermicro server visio templates In-Reply-To: <8C776528-871A-4AFA-B4B9-1EC308BFD1BA@gmail.com> References: <8C776528-871A-4AFA-B4B9-1EC308BFD1BA@gmail.com> Message-ID: > I emailed support at supermicro.com When I needed them RNA so far From josh at kyneticwifi.com Fri Aug 11 15:29:39 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 11 Aug 2017 10:29:39 -0500 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: <462128132.3290.1502240367069.JavaMail.mhammett@ThunderFuck> Message-ID: Since it's been announced now... I have an alpha unit. It came with 1.9.8dev straight from $manufacturer. My box still has markings from customs all over it. Expect a new version with some minor fixes soon. A lot of firmware work going on at the moment on various edgeOS product lines. On Aug 11, 2017 10:03 AM, "Nick W" wrote: > 1.9.7 definitely applies to Infinity: > > ER-8-XG: > https://dl.ubnt.com/firmwares/edgemax/v1.9.7/ER-e1000.v1.9. > 7+hotfix.1.5005858.tar > (SHA256:b1a16900e3fbe1eef3876548ac7eda12a95ef849d4328f22b478459e2a506b92) > > > > On Tue, Aug 8, 2017 at 9:07 PM, Josh Reynolds > wrote: > >> Forgot reply all... >> >> That does not apply to the infinity. Those shipped with 1.9.8dev. >> >> >> On Aug 8, 2017 8:03 PM, "Mike Hammett" wrote: >> >> > 1.9.7+hotfix.1 is the currently available stable. 1.9.1.1 was released >> on >> > May 1st. >> > >> > https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX- >> > EdgeRouter-software-security-release-v1-9-7-hotfix-1/ba-p/2019161 >> > >> > >> > >> > >> > ----- >> > Mike Hammett >> > Intelligent Computing Solutions >> > http://www.ics-il.com >> > >> > Midwest-IX >> > http://www.midwest-ix.com >> > >> > ----- Original Message ----- >> > >> > From: "Nick W" >> > To: nanog at nanog.org >> > Sent: Thursday, July 20, 2017 10:55:28 PM >> > Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"? >> > >> > Tried the Infinity, unsuccessfully. Several of them. Ended up pulling >> them >> > all, sitting in my homelab for now. Multiple full tables, nothing fancy >> for >> > firewall or QOS, but ran into issues with random ribd/bgpd crashes and >> > kernel panics. I've submitted a lot of logs and core dumps to UBNT. I >> would >> > personally stay away from them until they are out of beta, and possibly >> > even another 6-12 months after that. >> > >> > The current stable EdgeMax version (1.9.1.1) is relatively stable, but >> > using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, >> BGP) >> > - nothing too major, but can be annoying. Probably okay for what you >> > described. Depending on how much throughput you need, an ERPro, or >> Mikrotik >> > would probably be fine. If you need 10G, load up VyOS on some cheap >> servers >> > with an Intel or Solarflare card... probably cheaper than a beta >> Infinity >> > or Mikrotik. >> > >> > On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders wrote: >> > >> > > Dear NANOG, >> > > >> > > Some friends of mine are operating a nonprofit (on shoe string) and >> > looking >> > > to connect some CDN caches to an IX fabric. A BGP speaking device is >> > needed >> > > between the caches and the BGP peers connected to the fabric. The BGP >> > > speaker is needed to present the peers on the IX with a unified view >> of >> > the >> > > assemblage of CDN nodes. >> > > >> > > I was wondering whether anyone was experience with the "EdgeRouter >> > Infinity >> > > XG" device, specifically in the role of a simple peering router for a >> > > couple of tens of thousands of routes. (I'd point default to the left >> and >> > > take just the on-net routes on the right to reduce the table size >> > > requirement). >> > > >> > > I hope the device can do at least 2xLACP trunks, has a sizable FIB, is >> > > automatable (supports idempotency), can forward IMIX at line-rate, >> *flow, >> > > and exposes some telemetry via SNMP. >> > > >> > > Any note sharing would be appreciated! >> > > >> > > Kind regards, >> > > >> > > Job >> > > >> > >> > >> > > From josh at kyneticwifi.com Fri Aug 11 15:34:31 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 11 Aug 2017 10:34:31 -0500 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: <462128132.3290.1502240367069.JavaMail.mhammett@ThunderFuck> Message-ID: As an additional note, sometimes drivers get backported, this is how 1.9.7hotfix1 works on Infinity. There are multiple trees in various stages of dev at any given time. On Aug 11, 2017 10:29 AM, "Josh Reynolds" wrote: > Since it's been announced now... > > I have an alpha unit. It came with 1.9.8dev straight from $manufacturer. > My box still has markings from customs all over it. > > Expect a new version with some minor fixes soon. A lot of firmware work > going on at the moment on various edgeOS product lines. > > On Aug 11, 2017 10:03 AM, "Nick W" wrote: > >> 1.9.7 definitely applies to Infinity: >> >> ER-8-XG: >> https://dl.ubnt.com/firmwares/edgemax/v1.9.7/ER-e1000.v1.9.7 >> +hotfix.1.5005858.tar >> (SHA256:b1a16900e3fbe1eef3876548ac7eda12a95ef849d4328f22b478459e2a506b92) >> >> >> >> On Tue, Aug 8, 2017 at 9:07 PM, Josh Reynolds >> wrote: >> >>> Forgot reply all... >>> >>> That does not apply to the infinity. Those shipped with 1.9.8dev. >>> >>> >>> On Aug 8, 2017 8:03 PM, "Mike Hammett" wrote: >>> >>> > 1.9.7+hotfix.1 is the currently available stable. 1.9.1.1 was released >>> on >>> > May 1st. >>> > >>> > https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX- >>> > EdgeRouter-software-security-release-v1-9-7-hotfix-1/ba-p/2019161 >>> > >>> > >>> > >>> > >>> > ----- >>> > Mike Hammett >>> > Intelligent Computing Solutions >>> > http://www.ics-il.com >>> > >>> > Midwest-IX >>> > http://www.midwest-ix.com >>> > >>> > ----- Original Message ----- >>> > >>> > From: "Nick W" >>> > To: nanog at nanog.org >>> > Sent: Thursday, July 20, 2017 10:55:28 PM >>> > Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"? >>> > >>> > Tried the Infinity, unsuccessfully. Several of them. Ended up pulling >>> them >>> > all, sitting in my homelab for now. Multiple full tables, nothing >>> fancy for >>> > firewall or QOS, but ran into issues with random ribd/bgpd crashes and >>> > kernel panics. I've submitted a lot of logs and core dumps to UBNT. I >>> would >>> > personally stay away from them until they are out of beta, and possibly >>> > even another 6-12 months after that. >>> > >>> > The current stable EdgeMax version (1.9.1.1) is relatively stable, but >>> > using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, >>> BGP) >>> > - nothing too major, but can be annoying. Probably okay for what you >>> > described. Depending on how much throughput you need, an ERPro, or >>> Mikrotik >>> > would probably be fine. If you need 10G, load up VyOS on some cheap >>> servers >>> > with an Intel or Solarflare card... probably cheaper than a beta >>> Infinity >>> > or Mikrotik. >>> > >>> > On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders >>> wrote: >>> > >>> > > Dear NANOG, >>> > > >>> > > Some friends of mine are operating a nonprofit (on shoe string) and >>> > looking >>> > > to connect some CDN caches to an IX fabric. A BGP speaking device is >>> > needed >>> > > between the caches and the BGP peers connected to the fabric. The BGP >>> > > speaker is needed to present the peers on the IX with a unified view >>> of >>> > the >>> > > assemblage of CDN nodes. >>> > > >>> > > I was wondering whether anyone was experience with the "EdgeRouter >>> > Infinity >>> > > XG" device, specifically in the role of a simple peering router for a >>> > > couple of tens of thousands of routes. (I'd point default to the >>> left and >>> > > take just the on-net routes on the right to reduce the table size >>> > > requirement). >>> > > >>> > > I hope the device can do at least 2xLACP trunks, has a sizable FIB, >>> is >>> > > automatable (supports idempotency), can forward IMIX at line-rate, >>> *flow, >>> > > and exposes some telemetry via SNMP. >>> > > >>> > > Any note sharing would be appreciated! >>> > > >>> > > Kind regards, >>> > > >>> > > Job >>> > > >>> > >>> > >>> >> >> From hugo at slabnet.com Fri Aug 11 15:51:25 2017 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 11 Aug 2017 08:51:25 -0700 Subject: DevOps workflow for networking In-Reply-To: References: Message-ID: <20170811155125.GD29045@bamboo.slabnet.com> Possibly a minor nit, but if the devices "don't directly support automation", how is the "D" part of "CI/CD" accomplished there? `integration -ne deployment`. Do you mean something like "there is no API or e.g. netconf interface, but they can generate config off-box, scp it, and `copy start run` to load"? -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal On Fri 2017-Aug-11 00:18:39 -0700, Jippen wrote: >To be honest, most companies I've worked at have moved to amazon, where the >networking stack has APIs. I've also seen folks who use CI/CD pipelines to >generate configuration files for devices that don't directly support >automation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From david at zeromail.us Fri Aug 11 16:18:20 2017 From: david at zeromail.us (David S.) Date: Fri, 11 Aug 2017 23:18:20 +0700 Subject: DHL - ASN2571 contact Message-ID: Dear All, I have problem accessing dhl.com from my network /23 since 2 days ago, is here any DHL (ASN 2571) person or contact? Thank you. Best regards, David S. ------------------------------------------------ e. david at zeromail.us From bicknell at ufp.org Fri Aug 11 16:34:41 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 11 Aug 2017 09:34:41 -0700 Subject: DevOps workflow for networking In-Reply-To: <20170811155125.GD29045@bamboo.slabnet.com> References: <20170811155125.GD29045@bamboo.slabnet.com> Message-ID: <20170811163441.GA73371@ussenterprise.ufp.org> In a message written on Fri, Aug 11, 2017 at 08:51:25AM -0700, Hugo Slabbert wrote: > Possibly a minor nit, but if the devices "don't directly support > automation", how is the "D" part of "CI/CD" accomplished there? > `integration -ne deployment`. Do you mean something like "there is no API > or e.g. netconf interface, but they can generate config off-box, scp it, > and `copy start run` to load"? More or less. I've worked at places that do this sort of thing. 1) Download config from box. 2) Run script to determine changes necesary to config. 3) Load changes. 4) Download config again. 5) Re-run the script to determine changes necessary, verify there are none. For a lot of the devices with a Cisco-IOS like interface it's not even hard. Generate a code snippet: config terminal interface e0 description bar end write mem Then tftp the config to a server, have the script see e0 has description bar. -- 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 david at zeromail.us Fri Aug 11 17:07:29 2017 From: david at zeromail.us (David S.) Date: Sat, 12 Aug 2017 00:07:29 +0700 Subject: DHL - ASN2571 contact In-Reply-To: References: Message-ID: Hi, Problem solved, please ignore my previous request. Thank you Best regards, David S. ------------------------------------------------ e. david at zeromail.us On Fri, Aug 11, 2017 at 11:18 PM, David S. wrote: > Dear All, > > I have problem accessing dhl.com from my network /23 since 2 days ago, is > here any DHL (ASN 2571) person or contact? > > Thank you. > > > Best regards, > David S. > ------------------------------------------------ > e. david at zeromail.us > From cscora at apnic.net Fri Aug 11 18:02:40 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 12 Aug 2017 04:02:40 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170811180241.3CC4E167D@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, SANOG, PacNOG, SAFNOG MENOG, BJNOG, SDNOG, CMNOG, IRNOG 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 12 Aug, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 657261 Prefixes after maximum aggregation (per Origin AS): 256276 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 317961 Total ASes present in the Internet Routing Table: 58053 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 50206 Origin ASes announcing only one prefix: 22210 Transit ASes present in the Internet Routing Table: 7847 Transit-only ASes present in the Internet Routing Table: 219 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 56 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 111 Number of instances of unregistered ASNs: 112 Number of 32-bit ASNs allocated by the RIRs: 19680 Number of 32-bit ASNs visible in the Routing Table: 15437 Prefixes from 32-bit ASNs in the Routing Table: 62907 Number of bogon 32-bit ASNs visible in the Routing Table: 67 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 375 Number of addresses announced to Internet: 2850849892 Equivalent to 169 /8s, 236 /16s and 132 /24s Percentage of available address space announced: 77.0 Percentage of allocated address space announced: 77.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 219003 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 178583 Total APNIC prefixes after maximum aggregation: 51741 APNIC Deaggregation factor: 3.45 Prefixes being announced from the APNIC address blocks: 177604 Unique aggregates announced from the APNIC address blocks: 74126 APNIC Region origin ASes present in the Internet Routing Table: 8271 APNIC Prefixes per ASN: 21.47 APNIC Region origin ASes announcing only one prefix: 2303 APNIC Region transit ASes present in the Internet Routing Table: 1178 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 56 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3129 Number of APNIC addresses announced to Internet: 763191268 Equivalent to 45 /8s, 125 /16s and 95 /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: 200827 Total ARIN prefixes after maximum aggregation: 95469 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 202621 Unique aggregates announced from the ARIN address blocks: 93365 ARIN Region origin ASes present in the Internet Routing Table: 17954 ARIN Prefixes per ASN: 11.29 ARIN Region origin ASes announcing only one prefix: 6652 ARIN Region transit ASes present in the Internet Routing Table: 1780 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: 2145 Number of ARIN addresses announced to Internet: 1109821216 Equivalent to 66 /8s, 38 /16s and 135 /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: 176231 Total RIPE prefixes after maximum aggregation: 86418 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 172120 Unique aggregates announced from the RIPE address blocks: 103881 RIPE Region origin ASes present in the Internet Routing Table: 24274 RIPE Prefixes per ASN: 7.09 RIPE Region origin ASes announcing only one prefix: 11175 RIPE Region transit ASes present in the Internet Routing Table: 3435 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6073 Number of RIPE addresses announced to Internet: 713095040 Equivalent to 42 /8s, 128 /16s and 247 /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: 84281 Total LACNIC prefixes after maximum aggregation: 18754 LACNIC Deaggregation factor: 4.49 Prefixes being announced from the LACNIC address blocks: 85517 Unique aggregates announced from the LACNIC address blocks: 39302 LACNIC Region origin ASes present in the Internet Routing Table: 6238 LACNIC Prefixes per ASN: 13.71 LACNIC Region origin ASes announcing only one prefix: 1746 LACNIC Region transit ASes present in the Internet Routing Table: 1145 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3754 Number of LACNIC addresses announced to Internet: 170951648 Equivalent to 10 /8s, 48 /16s and 131 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 17226 Total AfriNIC prefixes after maximum aggregation: 3838 AfriNIC Deaggregation factor: 4.49 Prefixes being announced from the AfriNIC address blocks: 19024 Unique aggregates announced from the AfriNIC address blocks: 6971 AfriNIC Region origin ASes present in the Internet Routing Table: 1067 AfriNIC Prefixes per ASN: 17.83 AfriNIC Region origin ASes announcing only one prefix: 333 AfriNIC Region transit ASes present in the Internet Routing Table: 211 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 336 Number of AfriNIC addresses announced to Internet: 93364480 Equivalent to 5 /8s, 144 /16s and 161 /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 5425 4192 87 ERX-CERNET-BKB China Education and Rese 7545 4014 407 392 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2963 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2801 11124 744 KIXS-AS-KR Korea Telecom, KR 9829 2751 1498 549 BSNL-NIB National Internet Backbone, IN 9808 2356 8699 32 CMNET-GD Guangdong Mobile Communication 45899 2234 1449 106 VNPT-AS-VN VNPT Corp, VN 4755 2095 422 220 TATACOMM-AS TATA Communications formerl 7552 1671 1104 73 VIETEL-AS-AP Viettel Corporation, VN 9498 1622 361 144 BBIL-AP BHARTI Airtel Ltd., IN 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 3830 2952 159 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3445 1341 88 SHAW - Shaw Communications Inc., CA 18566 2207 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2066 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2021 2203 434 CHARTER-NET-HKY-NC - Charter Communicat 209 1863 5066 639 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1833 3861 579 AMAZON-02 - Amazon.com, Inc., US 30036 1823 328 290 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 701 1718 10559 629 UUNET - MCI Communications Services, In 6983 1695 854 231 ITCDELTA - Earthlink, 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 3387 186 23 ALJAWWALSTC-AS, SA 20940 2969 970 2133 AKAMAI-ASN1, US 8551 2554 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2050 332 422 TELLCOM-AS, TR 9121 1911 1691 17 TTNET, TR 12479 1647 1048 59 UNI2-AS, ES 13188 1602 100 55 TRIOLAN, UA 12389 1560 1482 651 ROSTELECOM-AS, RU 6849 1225 355 21 UKRTELNET, UA 8402 1153 544 15 CORBINA-AS OJSC "Vimpelcom", 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 3546 542 219 Telmex Colombia S.A., CO 8151 2656 3402 578 Uninet S.A. de C.V., MX 11830 2107 370 65 Instituto Costarricense de Electricidad 6503 1556 437 53 Axtel, S.A.B. de C.V., MX 7303 1556 1015 244 Telecom Argentina S.A., AR 6147 1230 377 27 Telefonica del Peru S.A.A., PE 3816 1023 501 93 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 955 2277 194 CLARO S.A., BR 11172 917 126 86 Alestra, S. de R.L. de C.V., MX 18881 897 1052 23 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 1196 398 48 LINKdotNET-AS, EG 37611 747 91 8 Afrihost, ZA 36903 711 357 130 MT-MPLS, MA 36992 678 1378 29 ETISALAT-MISR, EG 24835 501 850 15 RAYA-AS, EG 29571 421 36 10 CITelecom-AS, CI 37492 407 321 75 ORANGE-, TN 15399 357 35 7 WANANCHI-, KE 8452 313 1730 17 TE-AS TE-AS, EG 2018 304 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 5425 4192 87 ERX-CERNET-BKB China Education and Rese 7545 4014 407 392 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3830 2952 159 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3546 542 219 Telmex Colombia S.A., CO 6327 3445 1341 88 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2969 970 2133 AKAMAI-ASN1, US 17974 2963 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2801 11124 744 KIXS-AS-KR Korea Telecom, KR 9829 2751 1498 549 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 3830 3671 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 4014 3622 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 6327 3445 3357 SHAW - Shaw Communications Inc., CA 10620 3546 3327 Telmex Colombia S.A., CO 17974 2963 2890 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8551 2554 2513 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9808 2356 2324 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2751 2202 BSNL-NIB National Internet Backbone, IN 45899 2234 2128 VNPT-AS-VN VNPT Corp, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65532 PRIVATE 14.192.19.0/24 132717 NDCTPL-IN NxtGen Datacenter & 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 4294901876 PRIVATE 59.101.19.0/24 2764 AAPT AAPT Limited, AU 4294902000 PRIVATE 59.101.45.0/24 2764 AAPT AAPT Limited, AU 4294901905 PRIVATE 59.101.49.0/24 2764 AAPT AAPT Limited, AU Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.12.0/23 62878 XLITT - Xlitt, US 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.79.12.0/22 37306 -Reserved AS-, ZZ 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:15 /9:13 /10:36 /11:104 /12:284 /13:553 /14:1049 /15:1851 /16:13445 /17:7650 /18:13436 /19:24671 /20:38968 /21:41614 /22:78456 /23:65015 /24:367890 /25:847 /26:624 /27:631 /28:37 /29:25 /30:18 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3241 3445 SHAW - Shaw Communications Inc., CA 22773 2998 3830 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2946 3387 ALJAWWALSTC-AS, SA 18566 2091 2207 MEGAPATH5-US - MegaPath Corporation, US 8551 2019 2554 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1605 1823 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1497 2107 Instituto Costarricense de Electricidad y Telec 10620 1493 3546 Telmex Colombia S.A., CO 11492 1402 1580 CABLEONE - CABLE ONE, INC., US 6389 1372 2066 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1580 2:818 4:18 5:2442 6:31 7:1 8:1055 12:1838 13:134 14:1712 15:27 16:2 17:186 18:90 20:61 23:2433 24:1911 25:2 27:2366 29:1 31:1918 32:84 33:18 35:21 36:392 37:2370 38:1327 39:65 40:97 41:2978 42:460 43:1964 44:78 45:3012 46:2807 47:161 49:1234 50:995 51:19 52:826 54:362 55:6 56:4 57:46 58:1564 59:1012 60:323 61:1928 62:1675 63:1910 64:4648 65:2215 66:4584 67:2302 68:1281 69:3362 70:1191 71:620 72:2229 74:2716 75:405 76:426 77:1481 78:1452 79:1952 80:1407 81:1390 82:1004 83:727 84:956 85:1793 86:464 87:1204 88:755 89:2186 90:164 91:6206 92:990 93:2406 94:2394 95:2662 96:653 97:355 98:1063 99:94 100:153 101:1218 103:15538 104:3024 105:187 106:568 107:1744 108:821 109:2895 110:1457 111:1744 112:1234 113:1253 114:1046 115:1555 116:1646 117:1749 118:2156 119:1651 120:723 121:1060 122:2330 123:1824 124:1485 125:1803 128:840 129:662 130:437 131:1452 132:564 133:191 134:681 135:226 136:453 137:468 138:1910 139:506 140:394 141:632 142:769 143:878 144:806 145:182 146:1094 147:696 148:1481 149:578 150:708 151:973 152:709 153:299 154:885 155:753 156:659 157:659 158:480 159:1540 160:730 161:741 162:2539 163:538 164:938 165:1386 166:383 167:1282 168:2989 169:839 170:3490 171:334 172:1024 173:1988 174:815 175:732 176:1891 177:4015 178:2548 179:1127 180:2203 181:1934 182:2379 183:776 184:876 185:10403 186:3290 187:2187 188:2613 189:1788 190:8345 191:1347 192:9524 193:5798 194:4683 195:3912 196:2099 197:1329 198:5546 199:5902 200:7577 201:4308 202:10329 203:9990 204:4500 205:2838 206:3070 207:3158 208:3945 209:3996 210:3949 211:2082 212:2879 213:2511 214:861 215:66 216:5899 217:2132 218:888 219:600 220:1696 221:892 222:743 223:1188 End of report From saku at ytti.fi Fri Aug 11 20:45:56 2017 From: saku at ytti.fi (Saku Ytti) Date: Fri, 11 Aug 2017 23:45:56 +0300 Subject: DevOps workflow for networking In-Reply-To: <20170811163441.GA73371@ussenterprise.ufp.org> References: <20170811155125.GD29045@bamboo.slabnet.com> <20170811163441.GA73371@ussenterprise.ufp.org> Message-ID: On 11 August 2017 at 19:34, Leo Bicknell wrote: Hey, > For a lot of the devices with a Cisco-IOS like interface it's not even > hard. Generate a code snippet: > > config terminal > interface e0 > description bar > end > write mem > > Then tftp the config to a server, have the script see e0 has description > bar. To me there are two fundamentally different ways to do this 1) consider world dynamic, incrementally change it 2) consider world static, generate it from scratch The first one, is like managing servers with puppet/chef/ansible, you ask it to run some set of commands when you decide you want to turn up new service. The second one, is like using docker, if you want to change it, you build new full container, and swap it to the network. The benefit of second one is, that there is absolute guarantee of the state of the device immediately after the change has been made. The first one assumes there is known state in the system, when incremental change is pushed. I am great proponent of the second way of doing things. Mainly because: a) I find it trivial to generate full config from database, where as figuring how to go from A to B I find complicated (i.e. error prone) to do b) 2nd mandates that only system is managing the device, because if someone does login and does do something out-of-system, it will go away on next change - I think this is large advantage c) I do not need to try to prove system state is currently correct by implementing more and more tests towards figuring out state, instead I prove system state by setting all of it Downside of the 2nd method is, that it requires device which supports replacing whole config, classic IOS(-XE) and SR-OS today do not. JunOS, IOS-XR, EOS (Both compass and arista) and VRP do. SR-OS is making strides towards solving this. IOS-XE I'm hoping but not holding breath. -- ++ytti From beecher at beecher.cc Fri Aug 11 20:53:29 2017 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 11 Aug 2017 16:53:29 -0400 Subject: DevOps workflow for networking In-Reply-To: <20170811155125.GD29045@bamboo.slabnet.com> References: <20170811155125.GD29045@bamboo.slabnet.com> Message-ID: The same way we've done it for years ; really hacky expect scripts. :) On Fri, Aug 11, 2017 at 11:51 AM, Hugo Slabbert wrote: > Possibly a minor nit, but if the devices "don't directly support > automation", how is the "D" part of "CI/CD" accomplished there? > `integration -ne deployment`. Do you mean something like "there is no API > or e.g. netconf interface, but they can generate config off-box, scp it, > and `copy start run` to load"? > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > > > On Fri 2017-Aug-11 00:18:39 -0700, Jippen wrote: > > To be honest, most companies I've worked at have moved to amazon, where the >> networking stack has APIs. I've also seen folks who use CI/CD pipelines to >> generate configuration files for devices that don't directly support >> automation. >> > From bruns at 2mbit.com Sat Aug 12 04:13:37 2017 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 11 Aug 2017 22:13:37 -0600 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: <462128132.3290.1502240367069.JavaMail.mhammett@ThunderFuck> Message-ID: On 8/11/2017 9:34 AM, Josh Reynolds wrote: > As an additional note, sometimes drivers get backported, this is how > 1.9.7hotfix1 works on Infinity. There are multiple trees in various stages > of dev at any given time. The Infinity started out on 1.9.0 (which is what my Infinity alpha hardware had) and went up from there as the various in between releases came up, up until the current 1.9.7 release. The 1.9.8 dev releases are not currently for the Infinity or any previous ER hardware. That's about all I can say. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From josh at kyneticwifi.com Sat Aug 12 04:30:08 2017 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 11 Aug 2017 23:30:08 -0500 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: <462128132.3290.1502240367069.JavaMail.mhammett@ThunderFuck> Message-ID: I'm dumb, Brielle is right. 1.9.0, 1.9.5, 1.9.7h1 1.9.8dev and 1.9.8b1 are for two other newer products. On Aug 11, 2017 11:16 PM, "Brielle Bruns" wrote: > On 8/11/2017 9:34 AM, Josh Reynolds wrote: > >> As an additional note, sometimes drivers get backported, this is how >> 1.9.7hotfix1 works on Infinity. There are multiple trees in various stages >> of dev at any given time. >> > > > > The Infinity started out on 1.9.0 (which is what my Infinity alpha > hardware had) and went up from there as the various in between releases > came up, up until the current 1.9.7 release. > > The 1.9.8 dev releases are not currently for the Infinity or any previous > ER hardware. That's about all I can say. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From bruns at 2mbit.com Sat Aug 12 04:41:51 2017 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 11 Aug 2017 22:41:51 -0600 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: <462128132.3290.1502240367069.JavaMail.mhammett@ThunderFuck> Message-ID: On 8/11/2017 10:30 PM, Josh Reynolds wrote: > I'm dumb, Brielle is right. > > 1.9.0, 1.9.5, 1.9.7h1 > > 1.9.8dev and 1.9.8b1 are for two other newer products. Ubiquiti has been pretty active in developing improvements lately. I do recommend anyone who does use the Edge* series in production that they join the beta program on the Ubnt forums to keep current on whats being worked on. It pays off in the long run, and gives you a chance to test out new features and fixes before deploying them in real world scenarios. The Infinity isn't a perfect fit for everyone, but it is a 'disruptive' device and worth a look if you have > 1G needs. Now that its 'out there' in production, hopefully those that can put it to use will be able to give out real world numbers. (Note: I don't work for Ubnt, but I've used many of their products in the Edge and Unifi lines. I only speak for myself.) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From mehmet at akcin.net Sat Aug 12 11:27:57 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 12 Aug 2017 11:27:57 +0000 Subject: Puerto Rico Internet Exchange Message-ID: Hey there! ... ok this time I am not going to call it PRIX ;) well name doesn't matter really. Nearly 13 years ago I have attempted to start Puerto rico Internet exchange in San Juan. I have lived there over 5 years and i just wanted to really watch videos faster. The project somewhat died when i moved to LA but now there are few interested party to start an internet exchange in Puerto rico. The jsland historically had one of the slowest broadband/internet services which seemed to have improved in recent years however as of 2017 there still is not an IX in Puerto rico. We , 3-4 internet engineers (on island and remote) , want to look into relaunch of this IX and hopefully find a way to keep local traffic exchanged at high speeds and low cost. We need expertise, and people who want to help any way they can. We are trying to make this IX a not-for-profit one and we are looking at opeeating models to adapt which has worked incredibly well like Seattle IX. We are hoping the relaunch to happen sometime in 2018. Thanks in advance hope to share more info and traffic data sometime , soon. Watch this space! Mehmet From nanog at ics-il.net Sat Aug 12 12:14:07 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 12 Aug 2017 07:14:07 -0500 (CDT) Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: <537506594.3313.1502540044667.JavaMail.mhammett@ThunderFuck> Reach out to Gino Villarini at Aeronet. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Mehmet Akcin" To: "nanog" Sent: Saturday, August 12, 2017 6:27:57 AM Subject: Puerto Rico Internet Exchange Hey there! ... ok this time I am not going to call it PRIX ;) well name doesn't matter really. Nearly 13 years ago I have attempted to start Puerto rico Internet exchange in San Juan. I have lived there over 5 years and i just wanted to really watch videos faster. The project somewhat died when i moved to LA but now there are few interested party to start an internet exchange in Puerto rico. The jsland historically had one of the slowest broadband/internet services which seemed to have improved in recent years however as of 2017 there still is not an IX in Puerto rico. We , 3-4 internet engineers (on island and remote) , want to look into relaunch of this IX and hopefully find a way to keep local traffic exchanged at high speeds and low cost. We need expertise, and people who want to help any way they can. We are trying to make this IX a not-for-profit one and we are looking at opeeating models to adapt which has worked incredibly well like Seattle IX. We are hoping the relaunch to happen sometime in 2018. Thanks in advance hope to share more info and traffic data sometime , soon. Watch this space! Mehmet From dovid at telecurve.com Sun Aug 13 15:51:23 2017 From: dovid at telecurve.com (Dovid Bender) Date: Sun, 13 Aug 2017 11:51:23 -0400 Subject: AS202746 Hijacks: Is Telia (a) stupid, or (b) lazy, or (c) complicit? In-Reply-To: <20170802155143.GC20621@danton.fire-world.de> References: <7098.1501659387@segfault.tristatelogic.com> <20170802155143.GC20621@danton.fire-world.de> Message-ID: It seems that his emails are accomplishing something! http://bgp.he.net/AS202746 On Wed, Aug 2, 2017 at 11:51 AM, Sebastian Wiesinger wrote: > * Ronald F. Guilmette [2017-08-02 09:37]: > > > > The annotations in the RIPE WHOIS record for AS202746 seem pretty clear > to me. > > This thing is B-O-G-U-S! > > You know, people might be more willing to listen to you when you > express your points in a less emotional and aggressive tone. > > Regards > > > Sebastian > > -- > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE > SCYTHE. > -- Terry Pratchett, The Fifth Elephant > From cb.list6 at gmail.com Sun Aug 13 16:05:34 2017 From: cb.list6 at gmail.com (Ca By) Date: Sun, 13 Aug 2017 16:05:34 +0000 Subject: AS202746 Hijacks: Is Telia (a) stupid, or (b) lazy, or (c) complicit? In-Reply-To: References: <7098.1501659387@segfault.tristatelogic.com> <20170802155143.GC20621@danton.fire-world.de> Message-ID: On Sun, Aug 13, 2017 at 8:53 AM Dovid Bender wrote: > It seems that his emails are accomplishing something! > > http://bgp.he.net/AS202746 > Name and shame does work sometimes The tier 1s like Telia need to be the “grownups” and not let hijacks invade the DFZ CB > > > On Wed, Aug 2, 2017 at 11:51 AM, Sebastian Wiesinger < > sebastian at karotte.org> > wrote: > > > * Ronald F. Guilmette [2017-08-02 09:37]: > > > > > > The annotations in the RIPE WHOIS record for AS202746 seem pretty clear > > to me. > > > This thing is B-O-G-U-S! > > > > You know, people might be more willing to listen to you when you > > express your points in a less emotional and aggressive tone. > > > > Regards > > > > > > Sebastian > > > > -- > > GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) > > 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE > > SCYTHE. > > -- Terry Pratchett, The Fifth Elephant > > > From arturo.servin at gmail.com Sun Aug 13 17:54:10 2017 From: arturo.servin at gmail.com (Arturo Servin) Date: Sun, 13 Aug 2017 17:54:10 +0000 Subject: Puerto Rico Internet Exchange In-Reply-To: <537506594.3313.1502540044667.JavaMail.mhammett@ThunderFuck> References: <537506594.3313.1502540044667.JavaMail.mhammett@ThunderFuck> Message-ID: What about the PRBI project for an IXP? I think that is working, possibly it just need a hand. If possible, I would like to put my effort in something that is working and improve it rather than start something else from scratch. Regards as On Sat, 12 Aug 2017 at 14:15 Mike Hammett wrote: > Reach out to Gino Villarini at Aeronet. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "Mehmet Akcin" > To: "nanog" > Sent: Saturday, August 12, 2017 6:27:57 AM > Subject: Puerto Rico Internet Exchange > > Hey there! > > ... ok this time I am not going to call it PRIX ;) well name doesn't matter > really. Nearly 13 years ago I have attempted to start Puerto rico Internet > exchange in San Juan. I have lived there over 5 years and i just wanted to > really watch videos faster. The project somewhat died when i moved to LA > but now there are few interested party to start an internet exchange in > Puerto rico. The jsland historically had one of the slowest > broadband/internet services which seemed to have improved in recent years > however as of 2017 there still is not an IX in Puerto rico. > > We , 3-4 internet engineers (on island and remote) , want to look into > relaunch of this IX and hopefully find a way to keep local traffic > exchanged at high speeds and low cost. We need expertise, and people who > want to help any way they can. > > We are trying to make this IX a not-for-profit one and we are looking at > opeeating models to adapt which has worked incredibly well like Seattle IX. > > We are hoping the relaunch to happen sometime in 2018. Thanks in advance > hope to share more info and traffic data sometime , soon. Watch this space! > > Mehmet > > From mehmet at akcin.net Sun Aug 13 19:34:15 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 13 Aug 2017 19:34:15 +0000 Subject: Puerto Rico Internet Exchange In-Reply-To: References: <537506594.3313.1502540044667.JavaMail.mhammett@ThunderFuck> Message-ID: I have been trying to get a hold of someone from that project. No response yet. Still hoping to find someone. Peeringdb contact info didnt help. On Sun, Aug 13, 2017 at 10:54 AM Arturo Servin wrote: > What about the PRBI project for an IXP? > > I think that is working, possibly it just need a hand. If possible, I would > like to put my effort in something that is working and improve it rather > than start something else from scratch. > > Regards > as > > On Sat, 12 Aug 2017 at 14:15 Mike Hammett wrote: > > > Reach out to Gino Villarini at Aeronet. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > > ----- Original Message ----- > > > > From: "Mehmet Akcin" > > To: "nanog" > > Sent: Saturday, August 12, 2017 6:27:57 AM > > Subject: Puerto Rico Internet Exchange > > > > Hey there! > > > > ... ok this time I am not going to call it PRIX ;) well name doesn't > matter > > really. Nearly 13 years ago I have attempted to start Puerto rico > Internet > > exchange in San Juan. I have lived there over 5 years and i just wanted > to > > really watch videos faster. The project somewhat died when i moved to LA > > but now there are few interested party to start an internet exchange in > > Puerto rico. The jsland historically had one of the slowest > > broadband/internet services which seemed to have improved in recent years > > however as of 2017 there still is not an IX in Puerto rico. > > > > We , 3-4 internet engineers (on island and remote) , want to look into > > relaunch of this IX and hopefully find a way to keep local traffic > > exchanged at high speeds and low cost. We need expertise, and people who > > want to help any way they can. > > > > We are trying to make this IX a not-for-profit one and we are looking at > > opeeating models to adapt which has worked incredibly well like Seattle > IX. > > > > We are hoping the relaunch to happen sometime in 2018. Thanks in advance > > hope to share more info and traffic data sometime , soon. Watch this > space! > > > > Mehmet > > > > > From nanog at jima.us Sun Aug 13 19:47:51 2017 From: nanog at jima.us (Jima) Date: Sun, 13 Aug 2017 13:47:51 -0600 Subject: AS202746 Hijacks: Is Telia (a) stupid, or (b) lazy, or (c) complicit? In-Reply-To: References: <7098.1501659387@segfault.tristatelogic.com> <20170802155143.GC20621@danton.fire-world.de> Message-ID: <7ad85772-1ce6-eabd-19df-fb03ae804978@jima.us> On 2017-08-13 10:05, Ca By wrote: > On Sun, Aug 13, 2017 at 8:53 AM Dovid Bender wrote: > >> It seems that his emails are accomplishing something! >> >> http://bgp.he.net/AS202746 >> > > Name and shame does work sometimes IMO, this works better than most name-and-shame efforts because the behavior being called out is fairly universally indefensible. I think we can all agree to hate prefix hijackers (when we all pay for our IP assets) and spammers (because they cause most of us varying levels of grief), whereas "I personally don't like $x" (e.g., slow IPv6/BCP adoption) is often met with "I don't care about this, so fooey on your initiative." There may be a pointed statement in there -- thanks. ;-) Jima From ramirezcyrus at yahoo.com Sun Aug 13 19:53:11 2017 From: ramirezcyrus at yahoo.com (cyrus ramirez) Date: Sun, 13 Aug 2017 19:53:11 +0000 (UTC) Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: <114083068.887376.1502653991521@mail.yahoo.com> Hello:Have you looked into WIFI?  Cyrus Sent from Yahoo Mail on Android On Sat, Aug 12, 2017 at 7:29 AM, Mehmet Akcin wrote: Hey there! ... ok this time I am not going to call it PRIX ;) well name doesn't matter really. Nearly 13 years ago I have attempted to start Puerto rico Internet exchange in San Juan. I have lived there over 5 years and i just wanted to really watch videos faster. The project somewhat died when i moved to LA but now there are few interested party to start an internet exchange in Puerto rico. The jsland historically had one of the slowest broadband/internet services which seemed to have improved in recent years however as of 2017 there still is not an IX in Puerto rico. We , 3-4 internet engineers (on island and remote) , want to look into relaunch of this IX and hopefully find a way to keep local traffic exchanged at high speeds and low cost. We need expertise, and people who want to help any way they can. We are trying to make this IX a not-for-profit one and we are looking at opeeating models to adapt which has worked incredibly well like Seattle IX. We are hoping the relaunch to happen sometime in 2018. Thanks in advance hope to share more info and traffic data sometime , soon. Watch this space! Mehmet From william.allen.simpson at gmail.com Sun Aug 13 20:23:24 2017 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sun, 13 Aug 2017 16:23:24 -0400 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: <99d1bf43-4485-9e42-59ec-61cdb0b2ef13@gmail.com> On 8/12/17 7:27 AM, Mehmet Akcin wrote: > Hey there! > > ... ok this time I am not going to call it PRIX ;) I thought that was a perfectly good name. > [...] The jsland historically had one of the slowest > broadband/internet services which seemed to have improved in recent years > however as of 2017 there still is not an IX in Puerto rico. > What happened to Internet Exchange of Puerto Rico (ix.pr)? Run by AS36810? > We , 3-4 internet engineers (on island and remote) , want to look into > relaunch of this IX and hopefully find a way to keep local traffic > exchanged at high speeds and low cost. We need expertise, and people who > want to help any way they can. > https://www.pch.net/ > We are trying to make this IX a not-for-profit one and we are looking at > opeeating models to adapt which has worked incredibly well like Seattle IX. > > We are hoping the relaunch to happen sometime in 2018. Thanks in advance > hope to share more info and traffic data sometime , soon. Watch this space! > From mehmet at akcin.net Sun Aug 13 20:58:27 2017 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 13 Aug 2017 20:58:27 +0000 Subject: Puerto Rico Internet Exchange In-Reply-To: <99d1bf43-4485-9e42-59ec-61cdb0b2ef13@gmail.com> References: <99d1bf43-4485-9e42-59ec-61cdb0b2ef13@gmail.com> Message-ID: Basically i and second key person moved to california, could't push politics remotely and project died after couple gigs if traffic getting exchanged over ixp via few asns On Sun, Aug 13, 2017 at 1:23 PM William Allen Simpson < william.allen.simpson at gmail.com> wrote: > On 8/12/17 7:27 AM, Mehmet Akcin wrote: > > Hey there! > > > > ... ok this time I am not going to call it PRIX ;) > > I thought that was a perfectly good name. > > > [...] The jsland historically had one of the slowest > > broadband/internet services which seemed to have improved in recent years > > however as of 2017 there still is not an IX in Puerto rico. > > > What happened to Internet Exchange of Puerto Rico (ix.pr)? > > Run by AS36810? > > > > We , 3-4 internet engineers (on island and remote) , want to look into > > relaunch of this IX and hopefully find a way to keep local traffic > > exchanged at high speeds and low cost. We need expertise, and people who > > want to help any way they can. > > > https://www.pch.net/ > > > > We are trying to make this IX a not-for-profit one and we are looking at > > opeeating models to adapt which has worked incredibly well like Seattle > IX. > > > > We are hoping the relaunch to happen sometime in 2018. Thanks in advance > > hope to share more info and traffic data sometime , soon. Watch this > space! > > > > From hannigan at gmail.com Sun Aug 13 22:04:38 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Sun, 13 Aug 2017 22:04:38 +0000 Subject: Puerto Rico Internet Exchange In-Reply-To: References: <537506594.3313.1502540044667.JavaMail.mhammett@ThunderFuck> Message-ID: Hi Arturo, Good call. I believe the funds are coming from the USF? (Mike Hammet knows more about this than me). I had conversations with multiple congressional staffers about using USF funds for IXP development. They're in for good projects. The USG and US congress is more than willing to fund IXPs using USF funds. Commercial or otherwise, depending on the bnenefits and commits. I agree, it would be a good vector to work an improved IXP with larger scale support in Puerto Rico, building on the work Mehmet did with PR^H^HIX-PR. :-) I remember that conversation here vividly. Still requires a key location e.g. Power + fiber. Where to? Econmically, PR is long overdue for a neutral IX, locally organized, that can make an impact. Cheers, -M< On Sun, Aug 13, 2017 at 13:56 Arturo Servin wrote: > What about the PRBI project for an IXP? > > I think that is working, possibly it just need a hand. If possible, I would > like to put my effort in something that is working and improve it rather > than start something else from scratch. > > Regards > as > > On Sat, 12 Aug 2017 at 14:15 Mike Hammett wrote: > > > Reach out to Gino Villarini at Aeronet. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > > ----- Original Message ----- > > > > From: "Mehmet Akcin" > > To: "nanog" > > Sent: Saturday, August 12, 2017 6:27:57 AM > > Subject: Puerto Rico Internet Exchange > > > > Hey there! > > > > ... ok this time I am not going to call it PRIX ;) well name doesn't > matter > > really. Nearly 13 years ago I have attempted to start Puerto rico > Internet > > exchange in San Juan. I have lived there over 5 years and i just wanted > to > > really watch videos faster. The project somewhat died when i moved to LA > > but now there are few interested party to start an internet exchange in > > Puerto rico. The jsland historically had one of the slowest > > broadband/internet services which seemed to have improved in recent years > > however as of 2017 there still is not an IX in Puerto rico. > > > > We , 3-4 internet engineers (on island and remote) , want to look into > > relaunch of this IX and hopefully find a way to keep local traffic > > exchanged at high speeds and low cost. We need expertise, and people who > > want to help any way they can. > > > > We are trying to make this IX a not-for-profit one and we are looking at > > opeeating models to adapt which has worked incredibly well like Seattle > IX. > > > > We are hoping the relaunch to happen sometime in 2018. Thanks in advance > > hope to share more info and traffic data sometime , soon. Watch this > space! > > > > Mehmet > > > > > From benno at NLnetLabs.nl Mon Aug 14 14:49:37 2017 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Mon, 14 Aug 2017 16:49:37 +0200 Subject: 2nd call for presentations RIPE 75 Message-ID: <70d57b18-8327-a40c-2262-052ca46f8656@NLnetLabs.nl> Dear colleagues, Please note the approaching deadline of *20 August 2017* for RIPE 75 plenary programme submissions. You can find the CFP for RIPE 75 below or at https://ripe75.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Note: Due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Kind regards, Benno Overeinder RIPE PC Chair https://ripe75.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 75 will take place from 22-26 October in Dubai, UAE. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 75. See the full descriptions of the different presentation formats, https://ripe75.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *20 August 2017*. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Speakers Due to UAE law, confirmed speakers will need to submit a copy of their passport and contact information in advance of the meeting. More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Please also note that speakers do not receive any discount or funding towards the meeting fee at RIPE Meetings. Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe75.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe75.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From rod.beck at unitedcablecompany.com Mon Aug 14 14:54:04 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Mon, 14 Aug 2017 14:54:04 +0000 Subject: For the Wireless Guys Message-ID: https://phys.org/news/2017-08-transmission-terahertz-multiplexer.html Roderick Beck Director of Global Sales United Cable Company DRG Undersea Consulting Affiliate Member www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From goemon at sasami.anime.net Mon Aug 14 16:54:51 2017 From: goemon at sasami.anime.net (Dan Hollis) Date: Mon, 14 Aug 2017 09:54:51 -0700 (PDT) Subject: For the Wireless Guys In-Reply-To: References: Message-ID: Good for a few meters at best? Terahertz is blocked by air. -Dan On Mon, 14 Aug 2017, Rod Beck wrote: > https://phys.org/news/2017-08-transmission-terahertz-multiplexer.html > > > Roderick Beck > > Director of Global Sales > > United Cable Company > > DRG Undersea Consulting > > Affiliate Member > > www.unitedcablecompany.com > > 85 Király utca, 1077 Budapest > > rod.beck at unitedcablecompany.com > > 36-30-859-5144 > > > [1467221477350_image005.png] > From mlfreita at mtu.edu Mon Aug 14 17:21:24 2017 From: mlfreita at mtu.edu (Matt Freitag) Date: Mon, 14 Aug 2017 13:21:24 -0400 Subject: For the Wireless Guys In-Reply-To: References: Message-ID: Turn up the Tx power a bit and you'll have a nice little heater too. Matt Freitag Network Engineer Information Technology Michigan Technological University (906) 487-3696 <%28906%29%20487-3696> https://www.mtu.edu/ https://www.mtu.edu/it On Mon, Aug 14, 2017 at 12:54 PM, Dan Hollis wrote: > Good for a few meters at best? Terahertz is blocked by air. > > -Dan > > > On Mon, 14 Aug 2017, Rod Beck wrote: > > https://phys.org/news/2017-08-transmission-terahertz-multiplexer.html >> >> >> Roderick Beck >> >> Director of Global Sales >> >> United Cable Company >> >> DRG Undersea Consulting >> >> Affiliate Member >> >> www.unitedcablecompany.com >> >> 85 Király utca, 1077 Budapest >> >> rod.beck at unitedcablecompany.com >> >> 36-30-859-5144 >> >> >> [1467221477350_image005.png] >> >> From jhaustin at gmail.com Mon Aug 14 17:26:39 2017 From: jhaustin at gmail.com (Jeremy Austin) Date: Mon, 14 Aug 2017 09:26:39 -0800 Subject: Puerto Rico Internet Exchange In-Reply-To: References: <537506594.3313.1502540044667.JavaMail.mhammett@ThunderFuck> Message-ID: On Sun, Aug 13, 2017 at 2:04 PM, Martin Hannigan wrote: > Hi Arturo, > > Good call. I believe the funds are coming from the USF? (Mike Hammet knows > more about this than me). I had conversations with multiple congressional > staffers about using USF funds for IXP development. They're in for good > projects. The USG and US congress is more than willing to fund IXPs using > USF funds. Commercial or otherwise, depending on the bnenefits and commits. > > Hi Martin I'm curious about the mechanism for funding such a thing. Historically the majority of USF funds have gone to telcos rather than ISPs, if I am not mistaken. I'd love to continue this discussion off list if necessary. -- Jeremy Austin (907) 895-2311 office (907) 803-5422 cell jhaustin at gmail.com Heritage NetWorks Whitestone Power & Communications Vertical Broadband, LLC From rfg at tristatelogic.com Mon Aug 14 18:47:56 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 14 Aug 2017 11:47:56 -0700 Subject: AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these schmucks? Message-ID: <14956.1502736476@segfault.tristatelogic.com> I think that this is primarily Level3's problem to fix. But you be the judge. Please, read on. +_+_+_+_+_+_+_+_ Over the weekend, I stumbled upon an interesting blog calld "Bad Packets", where a fellow named Troy has written about various unsavory goings on involving various newtorks. One network that he called out in particular was AS29073, formerly called "Ecatel". on his blog, this fellow Troy has noted at length some break-in attempts originating from AS29073 and his inability to get anyone, in particular RIPE NCC, to give a damn. https://badpackets.net/the-master-needler-80-82-65-66/ https://badpackets.net/a-conversation-with-ripe-ncc-regarding-quasi-networks-ltd/ https://badpackets.net/quasi-networks-responds-as-we-witness-the-death-of-the-master-needler-80-82-65-66-for-now/ The fact that RIPE NCC declined to accept the role of The Internet Police didn't surprise me at all... they never have and probably never will... but I decided to have a quick look at what this newtork was routing, at present, which can be easily see here: http://bgp.he.net/AS29073#_prefixes So I was looking through the announced routes for AS29073, and it all looked pretty normal... a /24 block, check, a /24 block, check, a /21 block check... another /24 block, and then ... WAIT A SECOND! HOLY MOTHER OF GOD! WHAT'S THIS??? 196.16.0.0/14 !!! So how does a little two-bit network with a rather dubious reputation and a grand total of only about a /19 to its name suddenly come to be routing an entire /14 block?? And of course, its a legacy (abandoned) Afrinic block. And of course, there's no reverse DNS for any of it, because there is no valid delegation for the reverse DNS for any of it... usually a good sign that whoever is routing the block right now -does not- have legit rights to do so. (If they did, then they would have presented their LOAs or whatever to Afrinic and thus gotten the reverse DNS properly delegated to their own name servers.) I've seen this movie before. You all have. This gives every indication of being just another sad chapter in the ongoing mass pillaging of unused Afrinic legacy IPv4 space, by various actors with evil intent. I've already documented this hightly unfortunate fad right here on multiple occasions: https://mailman.nanog.org/pipermail/nanog/2016-November/089232.html https://mailman.nanog.org/pipermail/nanog/2017-August/091821.html This incident is a bit different from the others however, in that it -does not- appear that the 196.16.0.0/14 block has been filed to the brim with snoeshoe spammers. Well, not yet anyway. But if in fact the stories are correct, and if AS29073 does indeed have a history of hosting outbound hacking activities, then the mind reels when thinking about how much mischief such bad actors could get into if given an entire /14 to play with. (And by the way, this is a new world's record I think, for largest singe-route deliberate hijack. I've seen plenty of /16 go walkabout before, and even a whole /15. But an entire /14?? That is uniquely brazen.) In addition to the above, and the points raised within teh Bad Packets blog (see links above) I found, via passive DNS a number of other causes for concern about AS29073, to wit: ================================================================== 80.82.64.193 ftp.little-preteen.com 80.82.64.193 mail.little-preteen.com 80.82.64.193 pop.little-preteen.com 80.82.64.193 smtp.little-preteen.com 80.82.78.2 mx.preteen-video.com 80.82.78.2 mx.preteenstop.com 80.82.78.2 ns1.preteen-video.com 80.82.78.2 ns1.preteenstop.com 80.82.78.2 ns2.preteen-video.com 80.82.78.2 ns2.preteenstop.com 80.82.78.2 preteen-video.com 80.82.78.2 preteenstop.com 80.82.78.2 www.preteen-video.com 80.82.78.2 www.preteenstop.com 80.82.79.11 magic-preteens.seductive-models.com 80.82.79.176 ftp.preteennude.net 80.82.79.176 mail.preteennude.net 89.248.164.84 preteen.nn100.in 89.248.166.21 mobile.preteen-angels.info 89.248.166.21 preteen-art.info 93.174.91.159 img.preteen-angels.info 93.174.91.159 www.preteen-angels.info 93.174.91.159 www.preteen-art.info 93.174.91.164 img.preteen-art.info 93.174.91.164 m.preteen-angels.info 94.102.48.103 preteen-angels.info ================================================================== 80.82.64.30 mobilebankofamerica.com-125765.duiassistant.com 80.82.64.30 mobilebankofamerica.com-131438.bestlegalform.com 80.82.64.30 mobilebankofamerica.com-179103.bestlegalform.com 80.82.64.30 mobilebankofamerica.com-312745.njdui.org 80.82.64.30 mobilebankofamerica.com-498912.njdui.org 80.82.64.30 mobilebankofamerica.com-528835.njdui.org 80.82.64.30 mobilebankofamerica.com-5973124.njdui.org 80.82.64.30 mobilebankofamerica.com-8528941.njdui.org 80.82.64.30 mobilebankofamerica.com-873366.duiassistant.com 80.82.64.30 mobilebankofamerica.com-927397.bestlegalform.com 80.82.64.30 wvw.mobilebankofamerica.com-0385488.rodee.net 80.82.64.30 wvw.mobilebankofamerica.com-08908.rodee.net 80.82.64.30 wvw.mobilebankofamerica.com-20282.rodee.net 80.82.64.30 wvw.mobilebankofamerica.com-2629335.rodee.net 80.82.64.30 wvw.mobilebankofamerica.com-34289.rodee.net 80.82.64.30 wvw.mobilebankofamerica.com-39426.rodee.net 80.82.64.30 wvw.mobilebankofamerica.com-394894.rodee.net 80.82.64.30 wvw.mobilebankofamerica.com-482862.rodee.net 80.82.64.30 wvw.mobilebankofamerica.com-66488375.rodee.net 80.82.64.30 wvw.mobilebankofamerica.com-77749.rodee.net 80.82.64.30 wvw.mobilebankofamerica.com-998759.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-0028552.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-034275.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-040259.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-058258.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-07684037.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-079286.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-2259.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-24880.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-254243.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-360065.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-505724.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-54776.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-57238347.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-57856.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-59078906.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-603.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-60937.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-6205.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-643507.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-64698.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-662564.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-72047.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-7209660.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-722776.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-742.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-74305.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-74408.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-76339.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-7745606.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-824983.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-8302546.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-8480.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-8584933.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-89600996.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-9362498.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-97690.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-9865.rodee.net 80.82.64.30 wwv.mobile-bankofamerica.com-9926689.rodee.net 80.82.64.30 www.bankofamerica.com-restoreid342.mrcars.net 89.248.170.241 mobile-bankofamerica.com-ld52945771735.tiresforless.mobi 89.248.170.241 mobile-bankofamerica.com-ld68275215685.tiresforless.mobi 89.248.170.241 wvw.mobile-bankofamerica.com-88596423.tiresforless.mobi 93.174.88.189 bankofamerica-verification.info 93.174.88.189 bankofamerica-verification01.com 93.174.88.189 mail.bankofamerica-verification.info 93.174.88.189 www.bankofamerica-verification.info 93.174.88.189 www.bankofamerica-verification01.com ================================================================== 80.82.66.63 barclays.wimore.com 80.82.66.65 barclays.xheiw.com 89.248.173.119 barclays.co.uk.personalbanking.p1242557947640.p1242557947640.p1242557947640.093030023030230230002300239.braidingcenter.com 93.174.88.189 barclaysib.net 93.174.88.189 barclaysibtc.com 93.174.88.189 barclaysprivateoffshore.online 93.174.88.189 mail.barclaysprivateoffshore.online 93.174.88.189 www.barclaysib.net 93.174.88.189 www.barclaysibtc.com 93.174.91.38 bank.barclays.co.uk.olb.auth.loginlink.action.cabe110.com.ar 93.174.91.38 barclays.co.uk.personalbanking.p1242557947640.p1242557947640.p1242557947640.093030023030230230002300239.cabe110.com.ar 93.174.91.38 barclays.co.uk.personalbanking.p1242557947640.p1242557947640.p1242557947640.p1242557947640.cabe110.com.ar ================================================================== 93.174.91.38 connect.secure.wellsfargo.com.auth.login.present.origin.cob.cabe110.com.ar 93.174.91.38 www.connect.secure.wellsfargo.com.auth.login.present.origin.cob.cabe110.com.ar ================================================================== 80.82.66.63 verizon.uhtml5game.com 80.82.66.63 verizon.wimore.com 80.82.66.63 verizonwireless.wimore.com 80.82.66.65 verizon.xheiw.com 80.82.69.144 verizonwireless.com-itunes-offerid11124871812.jmwellness.net 80.82.69.144 verizonwireless.com-itunes-offerid11425558129.jmwellness.net 80.82.69.144 verizonwireless.com-itunes-offerid12225125564.jmwellness.net 80.82.69.144 verizonwireless.com-itunes-offerid12278425795.jmwellness.net 80.82.69.144 verizonwireless.com-itunes-offerid12948633366.jmwellness.net 80.82.69.144 verizonwireless.com-itunes-offerid13293736858.jmwellness.net ... 80.82.69.144 verizonwireless.com-itunesgift-shopiphone-id11944461198.cyrusbucks.net 80.82.69.144 verizonwireless.com-itunesgift-shopiphone-id23454498634.cyrusbucks.net 80.82.69.144 verizonwireless.com-itunesgift-shopiphone-id23817823159.cyrusbucks.net 80.82.69.144 verizonwireless.com-itunesgift-shopiphone-id25178695232.cyrusbucks.net 80.82.69.144 verizonwireless.com-itunesgift-shopiphone-id25942262252.cyrusbucks.net ... 89.248.170.241 verizonwireless.com-itunesgiftid-37285419676.interventionlv.info 89.248.170.241 verizonwireless.com-itunesgiftid-41435778356.interventionlv.info 89.248.170.241 verizonwireless.com-itunesgiftid-93692234458.interventionlv.info 94.102.52.5 verizonwireiess.com-0.fixcarforless.com 94.102.52.5 verizonwireless.offer4.agacoverage.net 94.102.52.5 wwv.verizonwireiess.com-039.fixcarforless.com 94.102.52.5 wwv.verizonwireiess.com-247.fixcarforless.com 94.102.52.70 verizonwireless.com-itunesgift-id12764814492.bigefire.com 94.102.52.70 verizonwireless.com-itunesgift-id27633376736.bigefire.com 94.102.52.70 verizonwireless.com-itunesgift-id32343178271.bigefire.com ... 94.102.58.35 verizon-wireless.com-779shop.eurohangar.net 94.102.58.35 verizon-wireless.com-77shop.eurohangar.net 94.102.58.35 verizon-wireless.com-7shop.eurohangar.net 94.102.58.35 verizonwireless.com-16shop.eurohangar.net 94.102.58.35 verizonwireless.com-2529shop.eurohangar.net 94.102.58.35 verizonwireless.com-34shop.eurohangar.net 94.102.58.35 verizonwireless.com-396shop.eurohangar.net 94.102.58.35 verizonwireless.com-425.infinitygreen.co 94.102.58.35 verizonwireless.com-45.infinitygreen.co 94.102.58.35 verizonwireless.com-66shop.eurohangar.net 94.102.58.35 verizonwireless.com-67shop.eurohangar.net 94.102.58.35 verizonwireless.com-73shop.eurohangar.net 94.102.58.35 verizonwireless.com-76shop.eurohangar.net 94.102.58.35 verizonwireless.com-860shop.eurohangar.net 94.102.58.35 verizonwireless.com-901shop.eurohangar.net 94.102.58.35 verizonwireless.com-99shop.eurohangar.net 94.102.58.35 verizonwireless.com-shop.eurohangar.net 94.102.58.35 wwv.verizon-wireless.com-185.infinitygreen.net 94.102.58.35 wwv.verizon-wireless.com-8.infinitygreen.net ================================================================== (In addition to the above, I've also found plenty of additional domain names associated with AS29073 which incorporate the names "Apple" "AirBnB", "Facebook", and "Groupon", as well as dozens of other legitimate companies and organizations.) I confess that I have not had the time to look at any of the web sites that may or may not be associated with any of the above FQDNs, but the domain names themselves are certainly strongly suggestive of (a) the possible hosting of child porn and also and separately (b) the possible hosting of phishing sites. So, given the history of this network (as is well documented on the Bad Packets blog) and given all of the above, and given what would appear to be the unauthorized "liberation" of the entire 196.16.0.0/14 block by AS29073, one cannot help but wonder Why does anybody still even peer with these jerks? The always helpful and informative web site bgp.he.net indicates that very nearly 50% of the connectivity currently enjoyed by AS29073 is being provided to them by Level3. I would thus like to ask Level3 to reconsider that peering arrangement in light of the above facts, and especially in light of what would appear to be the unauthorized routing of the 196.16.0.0/14 block by AS29073. Surprisingly, given its history, AS29073 apparently has a total of 99 different peers, at present, and I would likewise ask all of them to reconsider their current peering arrangements with this network. I am listing all 99 peers below. Before I get to that however, I'd liek to also note that there currently exists, within the RIPE Routing Registry, the following route object: route: 196.16.0.0/14 origin: AS29073 mnt-by: QUASINETWORKS-MNT mnt-by: EC42500-MNT mnt-routes: EC42500-MNT mnt-routes: M247-EU-MNT created: 2017-03-28T21:47:03Z last-modified: 2017-08-11T19:58:39Z source: RIPE I confess that I am not 100% sure of the exact semantics of the "mnt-routes" tag, but it would appear from the above that the UK's M247 network (AS9009)... which itself is not even peering with AS29073... appears to have, in effect countersigned the above RIPE route object, vouching for its correctness and authenticity as they did so. Why they would have done that, especially given that they themselves are not even peering with AS29073, is, I confess, beyond me. But I would love to have them explain it, or even try to explain it. It's enigmatic, to say the least. Anyway, the "created" date in the above record seems to be consistant with that actual start of the announcement of 196.16.0.0/14 by AS29073, which the RIPE Routing History tool says occured sometime in March of this year. One additional (and rather bizzare) footnote to this whole story about the 196.16.0.0/14 block has to do with the entity that allegedly -is- the current rightful owner of the block (as far as Afrinic is concerned). That entity is designated by the Afrinic handle ORG-IA41-AFRINIC and that in turn has an admin-c and tech-c of NAIT1-AFRINIC. The record for that handle is as follows: ------------------------------------------------------- person: Network and Information Technology Administrator address: Unit 117, Orion Mall, Palm Street address: Victoria, Mahe address: Seychelles (SC) phone: +972-54-2203545 e-mail: info at networkandinformationtechnology.com nic-hdl: NAIT1-AFRINIC mnt-by: MNT-NETWORKANDINFORMATIONTECHNOLOGY changed: info at networkandinformationtechnology.com 20150725 source: AFRINIC ------------------------------------------------------- Upon fetching the current WHOIS record for networkandinformationtechnology.com I found it more than passing strange that all of the contact details therein are associated *not* with anything in Africa, nor even anything in the home country of AS29073 (Netherlands) but rather, the address and ophone numbers therein all appear to be ones associated with a relatively well known Internet attorney in Santa Monica, Califiornia by the name of Bennet Kelly. As it happens, in the distant past (about 10 years ago) I personally crossed swords with this particular fellow. He may be a lot of things, but it never seemed to me that stupid was one of them. And indeed the domain name networkandinformationtechnology.com and all of its connections to the 196.16.0.0/14 block appear to date from 2015... long before AS29073 started routing this block (which only started in March of this year). So, my best guess about this whole confuseing mess is that the -original- legitimate owners of the 196.16.0.0/14 block most probably sold it on, in a legitimate transaction, to some other party in 2015, where that other party was/is represented by Mr. Bennet Kelly, Esq. And my guess is that neither he nor the new owners, who he represents, even know that their expensive /14 has gone walkabout, as of March of this year. I will be trying to make contact with Mr. Kelley today to discuss this with him and will post a follow-up if any new and interesting information arises from that conversation. Regards, rfg Peers of AS29073: ================================================================================ 1 Level 3 Communications, Inc. United States AS3356 2 REBA Communications BV Netherlands AS56611 3 Hurricane Electric, Inc. United States AS6939 4 Core-Backbone GmbH Germany AS33891 5 Init7 (Switzerland) Ltd. Switzerland AS13030 6 RETN Limited Ukraine AS9002 7 COLT Technology Services Group Limited United Kingdom AS8220 8 State Institute of Information Technologies and Telecommunications (SIIT&T "Informika") Russian Federation AS3267 9 GlobeNet Cabos Submarinos Colombia, S.A.S. Colombia AS52320 10 Digital Telecommunication Services S.r.l. Italy AS49605 11 IT.Gate S.p.A. Italy AS12779 12 green.ch AG Switzerland AS1836 13 UNIDATA S.p.A. Italy AS5394 14 GEANT Limited European Union AS20965 15 IP-Max SA Switzerland AS25091 16 Lost Oasis SARL France AS29075 17 nexellent ag Switzerland AS31424 18 SEACOM Limited Mauritius AS37100 19 Angola Cables Angola AS37468 20 ENTANET International Limited United Kingdom AS8468 21 Blix Solutions AS Norway AS50304 22 POST Luxembourg Luxembourg AS6661 23 Zayo France SAS France AS8218 24 Wind Telecomunicazioni SpA Italy AS1267 25 Swisscom (Switzerland) Ltd Switzerland AS3303 26 Pacnet Global Ltd Hong Kong AS10026 27 SURFnet bv Netherlands AS1103 28 SEEWEB s.r.l. Italy AS12637 29 BIT BV Netherlands AS12859 30 euNetworks Managed Services GmbH Germany AS13237 31 CAIW Diensten B.V. Netherlands AS15435 32 netplus.ch SA Switzerland AS15547 33 DOKOM Gesellschaft fuer Telekommunikation mbH Germany AS15763 34 ADISTA SAS France AS16347 35 Viewqwest Pte Ltd Singapore AS18106 36 Digital Ocean, Inc. European Union AS200130 37 Digital Ocean, Inc. Netherlands AS202018 38 Open Peering B.V. Netherlands AS20562 39 Services Industriels de Geneve Switzerland AS20932 40 Cemig Telecomunicaes SA Brazil AS23106 41 SG.GS Singapore AS24482 42 Vorboss Limited United Kingdom AS25160 43 equada network GmbH Germany AS25220 44 Avantel, Close Joint Stock Company Russian Federation AS25227 45 Gyron Internet Ltd United Kingdom AS29017 46 IPROUTE SRL Italy AS49289 47 LLC "TRC FIORD" Russian Federation AS28917 48 Hostserver GmbH Germany AS29140 49 Telekommunikation Mittleres Ruhrgebiet GmbH Germany AS12329 50 Internet Systems Consortium, Inc. United States AS30132 51 Liquid Telecommunications Ltd United Kingdom AS30844 52 Paulus M. Hoogsteder trading as Meanie Netherlands AS31019 53 Digiweb ltd Ireland AS31122 54 Fiberax Networking&Cloud Ltd. United Kingdom AS3252 55 Hivane France AS34019 56 CELESTE SAS France AS34177 57 Kantonsschule Zug Switzerland AS34288 58 Citycable Switzerland AS34781 59 SoftLayer Technologies Inc. United States AS36351 60 Network Platforms (PTY) LTD South Africa AS37497 61 Micron21 Datacentre Pty Ltd Australia AS38880 62 Convergenze S.p.A. Italy AS39120 63 Fiberby ApS Denmark AS42541 64 IP ServerOne Solutions Sdn Bhd, Malaysia AS45352 65 Easynet Global Services European Union AS4589 66 IP-Only Networks AB Sweden AS12552 67 Tango S.A. Luxembourg AS48526 68 Les Nouveaux Constructeurs SA France AS49463 69 CustodianDC Limited United Kingdom AS50300 70 MCKAYCOM LTD United Kingdom AS50763 71 Daisy Communications Ltd United Kingdom AS5413 72 MC-IX Matrix Internet Exchange RS-1 Indonesia AS55818 73 NetIX Communications Ltd. Bulgaria AS57463 74 Anycast Global Backbone Australia AS58511 75 LUXNETWORK S.A. Luxembourg AS29467 76 oja.at GmbH Austria AS39912 77 Elisa Oyj Finland AS6667 78 A1 Telekom Austria AG Austria AS8447 79 Fusix Networks B.V. Netherlands AS57866 80 ClaraNET LTD United Kingdom AS8426 81 "OBIT" Ltd. Russian Federation AS8492 82 Console Network Solutions Ltd United Kingdom AS43531 83 NetCologne GmbH Germany AS8422 84 Tesonet Ltd Lithuania AS201341 85 Linx Telecommunications B.V. Estonia AS3327 86 Strato AG Germany AS6724 87 CJSC RASCOM Russian Federation AS20764 88 Sunrise Communications AG Switzerland AS6730 89 KPN B.V. Netherlands AS1136 90 MTN SA South Africa AS16637 91 Portlane AB Sweden AS42708 92 TM Net, Internet Service Provider Malaysia AS4788 93 Network Dedicated SAS Switzerland AS62355 94 Next Layer Telekommunikationsdienstleistungs- und Beratungs GmbH Austria AS1764 95 Telkom SA Ltd. South Africa AS5713 96 ShockSRV Internet Services Private Limited Netherlands AS60115 97 JUPITER 25 LIMITED Netherlands AS64484 98 M-net Telekommunikations GmbH Germany AS8767 99 Neterra Ltd. Bulgaria AS34224 From rod.beck at unitedcablecompany.com Mon Aug 14 19:46:18 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Mon, 14 Aug 2017 19:46:18 +0000 Subject: For the Wireless Guys In-Reply-To: References: , Message-ID: I had my suspicions. 😊 ________________________________ From: Curtis Maurand Sent: Monday, August 14, 2017 9:44 PM To: Dan Hollis Cc: Rod Beck; nanog at nanog.org Subject: Re: For the Wireless Guys The higher the frequency, the more it acts like light. at that frequency, it wouldn't take much to block it. even 2.4GHz is stopped by a tree. On Mon, Aug 14, 2017 at 12:54 PM, Dan Hollis > wrote: Good for a few meters at best? Terahertz is blocked by air. -Dan On Mon, 14 Aug 2017, Rod Beck wrote: https://phys.org/news/2017-08-transmission-terahertz-multiplexer.html Roderick Beck Director of Global Sales United Cable Company DRG Undersea Consulting Affiliate Member www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] -- --Curtis From rfg at tristatelogic.com Mon Aug 14 19:49:54 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 14 Aug 2017 12:49:54 -0700 Subject: AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these schmucks? Message-ID: <15340.1502740194@segfault.tristatelogic.com> Sorry for the re-post, but it has been brought to my attention that my inclusion, in my prior posting, of various unsavory FQDNs resolving to various IPv4 addresses on AS29073 has triggered some people's spam filters. (Can't imagine why. :-) So I am re-posting this message now, with just a link to where those shady FQDNs and their current forward resolutions may be found. (I also took the opportunity to clean up some minor typos.) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I think that this is primarily Level3's problem to fix. But you be the judge. Please, read on. +_+_+_+_+_+_+_+_ Over the weekend, I stumbled upon an interesting blog calld "Bad Packets", where a fellow named Troy has written about various unsavory goings on involving various newtorks. One network that he called out in particular was AS29073, formerly called "Ecatel". on his blog, this fellow Troy has noted at length some break-in attempts originating from AS29073 and his inability to get anyone, in particular RIPE NCC, to give a damn. https://badpackets.net/the-master-needler-80-82-65-66/ https://badpackets.net/a-conversation-with-ripe-ncc-regarding-quasi-networks-ltd/ https://badpackets.net/quasi-networks-responds-as-we-witness-the-death-of-the-master-needler-80-82-65-66-for-now/ The fact that RIPE NCC declined to accept the role of The Internet Police didn't surprise me at all... they never have and probably never will. But I decided to have a quick look at what this newtork was routing, at present, which can be easily see here: http://bgp.he.net/AS29073#_prefixes So I was looking through the announced routes for AS29073, and it all looked pretty normal... a /24 block, check, a /24 block, check, a /21 block check... another /24 block, and then ... WAIT A SECOND! HOLY MOTHER OF GOD! WHAT'S THIS??? 196.16.0.0/14 !!! So how does a little two-bit network with a rather dubious reputation and a grand total of only about a /19 to its name suddenly come to be routing an entire /14 block?? And of course, its a legacy (abandoned) Afrinic block. And of course, there's no reverse DNS for any of it, because there is no valid delegation for the reverse DNS for any of it... usually a good sign that whoever is routing the block right now -does not- have legit rights to do so. (If they did, then they would have presented their LOAs or whatever to Afrinic and thus gotten the reverse DNS properly delegated to their own name servers.) I've seen this movie before. You all have. This gives every indication of being just another sad chapter in the ongoing mass pillaging of unused Afrinic legacy IPv4 space, by various actors with evil intent. I've already documented this hightly unfortunate fad right here on multiple occasions: https://mailman.nanog.org/pipermail/nanog/2016-November/089232.html https://mailman.nanog.org/pipermail/nanog/2017-August/091821.html This incident is a bit different from the others however, in that it -does not- appear that the 196.16.0.0/14 block has been filed to the brim with snowshoe spammers. Well, not yet anyway. But if in fact the stories are correct, and if AS29073 does indeed have a history of hosting outbound hacking activities, then the mind reels when thinking about how much mischief such bad actors could get into if given an entire /14 to play with. (And by the way, this is a new world's record I think, for largest single-route deliberate hijack. I've seen plenty of /16s go walkabout before, and even a whole /15. But an entire /14?!?! That is uniquely brazen.) In addition to the above, and the points raised within the Bad Packets blog (see links above) I found, via passive DNS, a number of other causes for concern about AS29073, to wit: Shady FQDNs (incl possible child porn ones) on AS29073 moved here: https://pastebin.com/raw/f4M09UKL (In addition to the above, I've also found plenty more domain names associated with AS29073 which incorporate the names "Apple" "AirBnB", "Facebook", and "Groupon", as well as dozens of other legitimate companies and organizations.) I confess that I have not had the time to look at any of the web sites that may or may not be associated with any of the above FQDNs, but the domain names themselves are certainly strongly suggestive of (a) the possible hosting of child porn and also and separately (b) the possible hosting of phishing sites. So, given the history of this network (as is well documented on the Bad Packets blog) and given all of the above, and given what would appear to be the unauthorized "liberation" of the entire 196.16.0.0/14 block by AS29073, one cannot help but wonder: Why does anybody still even peer with these jerks? The always helpful and informative web site bgp.he.net indicates that very nearly 50% of the connectivity currently enjoyed by AS29073 is being provided to them by Level3. I would thus like to ask Level3 to reconsider that peering arrangement in light of the above facts, and especially in light of what would appear to be the unauthorized routing of the 196.16.0.0/14 block by AS29073. Surprisingly, given its history, AS29073 apparently has a total of 99 different peers, at present, and I would likewise ask all of them to reconsider their current peering arrangements with this network. I am listing all 99 peers below. Before I get to that however, I'd like to also note that there currently exists, within the RIPE Routing Registry, the following route object: route: 196.16.0.0/14 origin: AS29073 mnt-by: QUASINETWORKS-MNT mnt-by: EC42500-MNT mnt-routes: EC42500-MNT mnt-routes: M247-EU-MNT created: 2017-03-28T21:47:03Z last-modified: 2017-08-11T19:58:39Z source: RIPE I confess that I am not 100% sure of the exact semantics of the "mnt-routes" tag, but it would appear from the above that the UK's M247 network (AS9009)... which itself is not even peering with AS29073... appears to have, in effect countersigned the above RIPE route object, vouching for its correctness and authenticity as they did so. Why they would have done that, especially given that they themselves are not even peering with AS29073, is, I confess, beyond me. But I would love to have them explain it, or even try to explain it. It's enigmatic, to say the least. Anyway, the "created" date in the above record seems to be consistant with that actual start of the announcement of 196.16.0.0/14 by AS29073, which the RIPE Routing History tool says occured sometime in March of this year. One additional (and rather bizzare) footnote to this whole story about the 196.16.0.0/14 block has to do with the entity that allegedly -is- the current rightful owner of the block (as far as Afrinic is concerned). That entity is designated by the Afrinic handle ORG-IA41-AFRINIC and that in turn has an admin-c and tech-c of NAIT1-AFRINIC. The record for that handle is as follows: ------------------------------------------------------- person: Network and Information Technology Administrator address: Unit 117, Orion Mall, Palm Street address: Victoria, Mahe address: Seychelles (SC) phone: +972-54-2203545 e-mail: info at networkandinformationtechnology.com nic-hdl: NAIT1-AFRINIC mnt-by: MNT-NETWORKANDINFORMATIONTECHNOLOGY changed: info at networkandinformationtechnology.com 20150725 source: AFRINIC ------------------------------------------------------- Upon fetching the current WHOIS record for networkandinformationtechnology.com I found it more than passing strange that all of the contact details therein are associated *not* with anything in Africa, nor even anything in the home country of AS29073 (Netherlands) but rather, the address and phone numbers therein all appear to be ones associated with a relatively well known Internet attorney in Santa Monica, Califiornia by the name of Bennet Kelly. As it happens, in the distant past (about 10 years ago) I personally crossed swords with this particular fellow. He may be a lot of things, but it never seemed to me that stupid was one of them. And indeed the domain name networkandinformationtechnology.com and all of its connections to the 196.16.0.0/14 block appear to date from 2015... long before AS29073 started routing this block (which only started in March of this year). So, my best guess about this whole confusing mess is that the -original- legitimate owners of the 196.16.0.0/14 block most probably sold it on, in a legitimate transaction, to some other party in 2015, where that other party was/is represented by Mr. Bennet Kelly, Esq. And my guess is that neither he nor the new owners, who he represents, even know that their expensive /14 has gone walkabout, as of March of this year. I will be trying to make contact with Mr. Kelley today to discuss this with him and will post a follow-up if any new and interesting information arises from that conversation. Regards, rfg Peers of AS29073: ================================================================================ 1 Level 3 Communications, Inc. United States AS3356 2 REBA Communications BV Netherlands AS56611 3 Hurricane Electric, Inc. United States AS6939 4 Core-Backbone GmbH Germany AS33891 5 Init7 (Switzerland) Ltd. Switzerland AS13030 6 RETN Limited Ukraine AS9002 7 COLT Technology Services Group Limited United Kingdom AS8220 8 State Institute of Information Technologies and Telecommunications (SIIT&T "Informika") Russian Federation AS3267 9 GlobeNet Cabos Submarinos Colombia, S.A.S. Colombia AS52320 10 Digital Telecommunication Services S.r.l. Italy AS49605 11 IT.Gate S.p.A. Italy AS12779 12 green.ch AG Switzerland AS1836 13 UNIDATA S.p.A. Italy AS5394 14 GEANT Limited European Union AS20965 15 IP-Max SA Switzerland AS25091 16 Lost Oasis SARL France AS29075 17 nexellent ag Switzerland AS31424 18 SEACOM Limited Mauritius AS37100 19 Angola Cables Angola AS37468 20 ENTANET International Limited United Kingdom AS8468 21 Blix Solutions AS Norway AS50304 22 POST Luxembourg Luxembourg AS6661 23 Zayo France SAS France AS8218 24 Wind Telecomunicazioni SpA Italy AS1267 25 Swisscom (Switzerland) Ltd Switzerland AS3303 26 Pacnet Global Ltd Hong Kong AS10026 27 SURFnet bv Netherlands AS1103 28 SEEWEB s.r.l. Italy AS12637 29 BIT BV Netherlands AS12859 30 euNetworks Managed Services GmbH Germany AS13237 31 CAIW Diensten B.V. Netherlands AS15435 32 netplus.ch SA Switzerland AS15547 33 DOKOM Gesellschaft fuer Telekommunikation mbH Germany AS15763 34 ADISTA SAS France AS16347 35 Viewqwest Pte Ltd Singapore AS18106 36 Digital Ocean, Inc. European Union AS200130 37 Digital Ocean, Inc. Netherlands AS202018 38 Open Peering B.V. Netherlands AS20562 39 Services Industriels de Geneve Switzerland AS20932 40 Cemig Telecomunicaes SA Brazil AS23106 41 SG.GS Singapore AS24482 42 Vorboss Limited United Kingdom AS25160 43 equada network GmbH Germany AS25220 44 Avantel, Close Joint Stock Company Russian Federation AS25227 45 Gyron Internet Ltd United Kingdom AS29017 46 IPROUTE SRL Italy AS49289 47 LLC "TRC FIORD" Russian Federation AS28917 48 Hostserver GmbH Germany AS29140 49 Telekommunikation Mittleres Ruhrgebiet GmbH Germany AS12329 50 Internet Systems Consortium, Inc. United States AS30132 51 Liquid Telecommunications Ltd United Kingdom AS30844 52 Paulus M. Hoogsteder trading as Meanie Netherlands AS31019 53 Digiweb ltd Ireland AS31122 54 Fiberax Networking&Cloud Ltd. United Kingdom AS3252 55 Hivane France AS34019 56 CELESTE SAS France AS34177 57 Kantonsschule Zug Switzerland AS34288 58 Citycable Switzerland AS34781 59 SoftLayer Technologies Inc. United States AS36351 60 Network Platforms (PTY) LTD South Africa AS37497 61 Micron21 Datacentre Pty Ltd Australia AS38880 62 Convergenze S.p.A. Italy AS39120 63 Fiberby ApS Denmark AS42541 64 IP ServerOne Solutions Sdn Bhd, Malaysia AS45352 65 Easynet Global Services European Union AS4589 66 IP-Only Networks AB Sweden AS12552 67 Tango S.A. Luxembourg AS48526 68 Les Nouveaux Constructeurs SA France AS49463 69 CustodianDC Limited United Kingdom AS50300 70 MCKAYCOM LTD United Kingdom AS50763 71 Daisy Communications Ltd United Kingdom AS5413 72 MC-IX Matrix Internet Exchange RS-1 Indonesia AS55818 73 NetIX Communications Ltd. Bulgaria AS57463 74 Anycast Global Backbone Australia AS58511 75 LUXNETWORK S.A. Luxembourg AS29467 76 oja.at GmbH Austria AS39912 77 Elisa Oyj Finland AS6667 78 A1 Telekom Austria AG Austria AS8447 79 Fusix Networks B.V. Netherlands AS57866 80 ClaraNET LTD United Kingdom AS8426 81 "OBIT" Ltd. Russian Federation AS8492 82 Console Network Solutions Ltd United Kingdom AS43531 83 NetCologne GmbH Germany AS8422 84 Tesonet Ltd Lithuania AS201341 85 Linx Telecommunications B.V. Estonia AS3327 86 Strato AG Germany AS6724 87 CJSC RASCOM Russian Federation AS20764 88 Sunrise Communications AG Switzerland AS6730 89 KPN B.V. Netherlands AS1136 90 MTN SA South Africa AS16637 91 Portlane AB Sweden AS42708 92 TM Net, Internet Service Provider Malaysia AS4788 93 Network Dedicated SAS Switzerland AS62355 94 Next Layer Telekommunikationsdienstleistungs- und Beratungs GmbH Austria AS1764 95 Telkom SA Ltd. South Africa AS5713 96 ShockSRV Internet Services Private Limited Netherlands AS60115 97 JUPITER 25 LIMITED Netherlands AS64484 98 M-net Telekommunikations GmbH Germany AS8767 99 Neterra Ltd. Bulgaria AS34224 From Dave.Siegel at level3.com Mon Aug 14 20:17:06 2017 From: Dave.Siegel at level3.com (Siegel, David) Date: Mon, 14 Aug 2017 20:17:06 +0000 Subject: AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these schmucks? In-Reply-To: <15340.1502740194@segfault.tristatelogic.com> References: <15340.1502740194@segfault.tristatelogic.com> Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC0DE623E91@USIDCWVEMBX08.corp.global.level3.com> If you believe that a customer of a network service provider is in violation of that service providers AUP, you should email abuse at serviceprovider.net. Most large networks have a security team that monitors that email address regularly and will cooperate with you to address the problem. Dave -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ronald F. Guilmette Sent: Monday, August 14, 2017 1:50 PM To: nanog at nanog.org Subject: AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these schmucks? Sorry for the re-post, but it has been brought to my attention that my inclusion, in my prior posting, of various unsavory FQDNs resolving to various IPv4 addresses on AS29073 has triggered some people's spam filters. (Can't imagine why. :-) So I am re-posting this message now, with just a link to where those shady FQDNs and their current forward resolutions may be found. (I also took the opportunity to clean up some minor typos.) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I think that this is primarily Level3's problem to fix. But you be the judge. Please, read on. +_+_+_+_+_+_+_+_ Over the weekend, I stumbled upon an interesting blog calld "Bad Packets", where a fellow named Troy has written about various unsavory goings on involving various newtorks. One network that he called out in particular was AS29073, formerly called "Ecatel". on his blog, this fellow Troy has noted at length some break-in attempts originating from AS29073 and his inability to get anyone, in particular RIPE NCC, to give a damn. https://badpackets.net/the-master-needler-80-82-65-66/ https://badpackets.net/a-conversation-with-ripe-ncc-regarding-quasi-networks-ltd/ https://badpackets.net/quasi-networks-responds-as-we-witness-the-death-of-the-master-needler-80-82-65-66-for-now/ The fact that RIPE NCC declined to accept the role of The Internet Police didn't surprise me at all... they never have and probably never will. But I decided to have a quick look at what this newtork was routing, at present, which can be easily see here: http://bgp.he.net/AS29073#_prefixes So I was looking through the announced routes for AS29073, and it all looked pretty normal... a /24 block, check, a /24 block, check, a /21 block check... another /24 block, and then ... WAIT A SECOND! HOLY MOTHER OF GOD! WHAT'S THIS??? 196.16.0.0/14 !!! So how does a little two-bit network with a rather dubious reputation and a grand total of only about a /19 to its name suddenly come to be routing an entire /14 block?? And of course, its a legacy (abandoned) Afrinic block. And of course, there's no reverse DNS for any of it, because there is no valid delegation for the reverse DNS for any of it... usually a good sign that whoever is routing the block right now -does not- have legit rights to do so. (If they did, then they would have presented their LOAs or whatever to Afrinic and thus gotten the reverse DNS properly delegated to their own name servers.) I've seen this movie before. You all have. This gives every indication of being just another sad chapter in the ongoing mass pillaging of unused Afrinic legacy IPv4 space, by various actors with evil intent. I've already documented this hightly unfortunate fad right here on multiple occasions: https://mailman.nanog.org/pipermail/nanog/2016-November/089232.html https://mailman.nanog.org/pipermail/nanog/2017-August/091821.html This incident is a bit different from the others however, in that it -does not- appear that the 196.16.0.0/14 block has been filed to the brim with snowshoe spammers. Well, not yet anyway. But if in fact the stories are correct, and if AS29073 does indeed have a history of hosting outbound hacking activities, then the mind reels when thinking about how much mischief such bad actors could get into if given an entire /14 to play with. (And by the way, this is a new world's record I think, for largest single-route deliberate hijack. I've seen plenty of /16s go walkabout before, and even a whole /15. But an entire /14?!?! That is uniquely brazen.) In addition to the above, and the points raised within the Bad Packets blog (see links above) I found, via passive DNS, a number of other causes for concern about AS29073, to wit: Shady FQDNs (incl possible child porn ones) on AS29073 moved here: https://pastebin.com/raw/f4M09UKL (In addition to the above, I've also found plenty more domain names associated with AS29073 which incorporate the names "Apple" "AirBnB", "Facebook", and "Groupon", as well as dozens of other legitimate companies and organizations.) I confess that I have not had the time to look at any of the web sites that may or may not be associated with any of the above FQDNs, but the domain names themselves are certainly strongly suggestive of (a) the possible hosting of child porn and also and separately (b) the possible hosting of phishing sites. So, given the history of this network (as is well documented on the Bad Packets blog) and given all of the above, and given what would appear to be the unauthorized "liberation" of the entire 196.16.0.0/14 block by AS29073, one cannot help but wonder: Why does anybody still even peer with these jerks? The always helpful and informative web site bgp.he.net indicates that very nearly 50% of the connectivity currently enjoyed by AS29073 is being provided to them by Level3. I would thus like to ask Level3 to reconsider that peering arrangement in light of the above facts, and especially in light of what would appear to be the unauthorized routing of the 196.16.0.0/14 block by AS29073. Surprisingly, given its history, AS29073 apparently has a total of 99 different peers, at present, and I would likewise ask all of them to reconsider their current peering arrangements with this network. I am listing all 99 peers below. Before I get to that however, I'd like to also note that there currently exists, within the RIPE Routing Registry, the following route object: route: 196.16.0.0/14 origin: AS29073 mnt-by: QUASINETWORKS-MNT mnt-by: EC42500-MNT mnt-routes: EC42500-MNT mnt-routes: M247-EU-MNT created: 2017-03-28T21:47:03Z last-modified: 2017-08-11T19:58:39Z source: RIPE I confess that I am not 100% sure of the exact semantics of the "mnt-routes" tag, but it would appear from the above that the UK's M247 network (AS9009)... which itself is not even peering with AS29073... appears to have, in effect countersigned the above RIPE route object, vouching for its correctness and authenticity as they did so. Why they would have done that, especially given that they themselves are not even peering with AS29073, is, I confess, beyond me. But I would love to have them explain it, or even try to explain it. It's enigmatic, to say the least. Anyway, the "created" date in the above record seems to be consistant with that actual start of the announcement of 196.16.0.0/14 by AS29073, which the RIPE Routing History tool says occured sometime in March of this year. One additional (and rather bizzare) footnote to this whole story about the 196.16.0.0/14 block has to do with the entity that allegedly -is- the current rightful owner of the block (as far as Afrinic is concerned). That entity is designated by the Afrinic handle ORG-IA41-AFRINIC and that in turn has an admin-c and tech-c of NAIT1-AFRINIC. The record for that handle is as follows: ------------------------------------------------------- person: Network and Information Technology Administrator address: Unit 117, Orion Mall, Palm Street address: Victoria, Mahe address: Seychelles (SC) phone: +972-54-2203545 e-mail: info at networkandinformationtechnology.com nic-hdl: NAIT1-AFRINIC mnt-by: MNT-NETWORKANDINFORMATIONTECHNOLOGY changed: info at networkandinformationtechnology.com 20150725 source: AFRINIC ------------------------------------------------------- Upon fetching the current WHOIS record for networkandinformationtechnology.com I found it more than passing strange that all of the contact details therein are associated *not* with anything in Africa, nor even anything in the home country of AS29073 (Netherlands) but rather, the address and phone numbers therein all appear to be ones associated with a relatively well known Internet attorney in Santa Monica, Califiornia by the name of Bennet Kelly. As it happens, in the distant past (about 10 years ago) I personally crossed swords with this particular fellow. He may be a lot of things, but it never seemed to me that stupid was one of them. And indeed the domain name networkandinformationtechnology.com and all of its connections to the 196.16.0.0/14 block appear to date from 2015... long before AS29073 started routing this block (which only started in March of this year). So, my best guess about this whole confusing mess is that the -original- legitimate owners of the 196.16.0.0/14 block most probably sold it on, in a legitimate transaction, to some other party in 2015, where that other party was/is represented by Mr. Bennet Kelly, Esq. And my guess is that neither he nor the new owners, who he represents, even know that their expensive /14 has gone walkabout, as of March of this year. I will be trying to make contact with Mr. Kelley today to discuss this with him and will post a follow-up if any new and interesting information arises from that conversation. Regards, rfg Peers of AS29073: ================================================================================ 1 Level 3 Communications, Inc. United States AS3356 2 REBA Communications BV Netherlands AS56611 3 Hurricane Electric, Inc. United States AS6939 4 Core-Backbone GmbH Germany AS33891 5 Init7 (Switzerland) Ltd. Switzerland AS13030 6 RETN Limited Ukraine AS9002 7 COLT Technology Services Group Limited United Kingdom AS8220 8 State Institute of Information Technologies and Telecommunications (SIIT&T "Informika") Russian Federation AS3267 9 GlobeNet Cabos Submarinos Colombia, S.A.S. Colombia AS52320 10 Digital Telecommunication Services S.r.l. Italy AS49605 11 IT.Gate S.p.A. Italy AS12779 12 green.ch AG Switzerland AS1836 13 UNIDATA S.p.A. Italy AS5394 14 GEANT Limited European Union AS20965 15 IP-Max SA Switzerland AS25091 16 Lost Oasis SARL France AS29075 17 nexellent ag Switzerland AS31424 18 SEACOM Limited Mauritius AS37100 19 Angola Cables Angola AS37468 20 ENTANET International Limited United Kingdom AS8468 21 Blix Solutions AS Norway AS50304 22 POST Luxembourg Luxembourg AS6661 23 Zayo France SAS France AS8218 24 Wind Telecomunicazioni SpA Italy AS1267 25 Swisscom (Switzerland) Ltd Switzerland AS3303 26 Pacnet Global Ltd Hong Kong AS10026 27 SURFnet bv Netherlands AS1103 28 SEEWEB s.r.l. Italy AS12637 29 BIT BV Netherlands AS12859 30 euNetworks Managed Services GmbH Germany AS13237 31 CAIW Diensten B.V. Netherlands AS15435 32 netplus.ch SA Switzerland AS15547 33 DOKOM Gesellschaft fuer Telekommunikation mbH Germany AS15763 34 ADISTA SAS France AS16347 35 Viewqwest Pte Ltd Singapore AS18106 36 Digital Ocean, Inc. European Union AS200130 37 Digital Ocean, Inc. Netherlands AS202018 38 Open Peering B.V. Netherlands AS20562 39 Services Industriels de Geneve Switzerland AS20932 40 Cemig Telecomunicaes SA Brazil AS23106 41 SG.GS Singapore AS24482 42 Vorboss Limited United Kingdom AS25160 43 equada network GmbH Germany AS25220 44 Avantel, Close Joint Stock Company Russian Federation AS25227 45 Gyron Internet Ltd United Kingdom AS29017 46 IPROUTE SRL Italy AS49289 47 LLC "TRC FIORD" Russian Federation AS28917 48 Hostserver GmbH Germany AS29140 49 Telekommunikation Mittleres Ruhrgebiet GmbH Germany AS12329 50 Internet Systems Consortium, Inc. United States AS30132 51 Liquid Telecommunications Ltd United Kingdom AS30844 52 Paulus M. Hoogsteder trading as Meanie Netherlands AS31019 53 Digiweb ltd Ireland AS31122 54 Fiberax Networking&Cloud Ltd. United Kingdom AS3252 55 Hivane France AS34019 56 CELESTE SAS France AS34177 57 Kantonsschule Zug Switzerland AS34288 58 Citycable Switzerland AS34781 59 SoftLayer Technologies Inc. United States AS36351 60 Network Platforms (PTY) LTD South Africa AS37497 61 Micron21 Datacentre Pty Ltd Australia AS38880 62 Convergenze S.p.A. Italy AS39120 63 Fiberby ApS Denmark AS42541 64 IP ServerOne Solutions Sdn Bhd, Malaysia AS45352 65 Easynet Global Services European Union AS4589 66 IP-Only Networks AB Sweden AS12552 67 Tango S.A. Luxembourg AS48526 68 Les Nouveaux Constructeurs SA France AS49463 69 CustodianDC Limited United Kingdom AS50300 70 MCKAYCOM LTD United Kingdom AS50763 71 Daisy Communications Ltd United Kingdom AS5413 72 MC-IX Matrix Internet Exchange RS-1 Indonesia AS55818 73 NetIX Communications Ltd. Bulgaria AS57463 74 Anycast Global Backbone Australia AS58511 75 LUXNETWORK S.A. Luxembourg AS29467 76 oja.at GmbH Austria AS39912 77 Elisa Oyj Finland AS6667 78 A1 Telekom Austria AG Austria AS8447 79 Fusix Networks B.V. Netherlands AS57866 80 ClaraNET LTD United Kingdom AS8426 81 "OBIT" Ltd. Russian Federation AS8492 82 Console Network Solutions Ltd United Kingdom AS43531 83 NetCologne GmbH Germany AS8422 84 Tesonet Ltd Lithuania AS201341 85 Linx Telecommunications B.V. Estonia AS3327 86 Strato AG Germany AS6724 87 CJSC RASCOM Russian Federation AS20764 88 Sunrise Communications AG Switzerland AS6730 89 KPN B.V. Netherlands AS1136 90 MTN SA South Africa AS16637 91 Portlane AB Sweden AS42708 92 TM Net, Internet Service Provider Malaysia AS4788 93 Network Dedicated SAS Switzerland AS62355 94 Next Layer Telekommunikationsdienstleistungs- und Beratungs GmbH Austria AS1764 95 Telkom SA Ltd. South Africa AS5713 96 ShockSRV Internet Services Private Limited Netherlands AS60115 97 JUPITER 25 LIMITED Netherlands AS64484 98 M-net Telekommunikations GmbH Germany AS8767 99 Neterra Ltd. Bulgaria AS34224 From baldur.norddahl at gmail.com Mon Aug 14 20:47:33 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 14 Aug 2017 22:47:33 +0200 Subject: AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these schmucks? In-Reply-To: <15340.1502740194@segfault.tristatelogic.com> References: <15340.1502740194@segfault.tristatelogic.com> Message-ID: Den 14. aug. 2017 21.51 skrev "Ronald F. Guilmette" : Sorry for the re-post, but it has been brought to my attention that my inclusion, in my prior posting, of various unsavory FQDNs resolving to various IPv4 addresses on AS29073 has triggered some people's spam filters. (Can't imagine why. :-) So I am re-posting this message now, with just a link to where those shady FQDNs and their current forward resolutions may be found. (I also took the opportunity to clean up some minor typos.) Why are domain registrars allowing some of those domains, which are clearly advertising highly illegal content that will get you in jail in most of the world? From jneiberger at gmail.com Mon Aug 14 22:22:40 2017 From: jneiberger at gmail.com (John Neiberger) Date: Mon, 14 Aug 2017 16:22:40 -0600 Subject: Anyone from AS62052 ASNICOM here? Message-ID: Sorry for posting to the list, but we are unable to find any working contact information. If anyone from AS 62052 (ASNICOM) is on the list, please contact me. You're advertising some of our IP space and we need to get that corrected. Thanks, John From ops.lists at gmail.com Mon Aug 14 23:32:03 2017 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 15 Aug 2017 05:02:03 +0530 Subject: AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these schmucks? In-Reply-To: References: <15340.1502740194@segfault.tristatelogic.com> Message-ID: <9791103F-79C1-40CF-AA74-40C48B5BC3F1@gmail.com> 1. They aren’t the internet police either or so quite a few of them think 2. Hanlon’s razor --srs > On 15-Aug-2017, at 2:17 AM, Baldur Norddahl wrote: > > Why are domain registrars allowing some of those domains, which are clearly > advertising highly illegal content that will get you in jail in most of the > world? From jwbensley at gmail.com Tue Aug 15 07:23:05 2017 From: jwbensley at gmail.com (James Bensley) Date: Tue, 15 Aug 2017 08:23:05 +0100 Subject: (Network Orchestrators evaluation) : tail-f vs Anuta vs UBIqube vs OpenDaylight In-Reply-To: References: Message-ID: On 10 August 2017 at 02:01, Kasper Adel wrote: > Hi, Hi Kim, > This is not a vendor bashing thread. > > We are a group of networking engineers less experience with software) in > the middle of the process of procuring a network automation/orchestration > controller, if that is even a good definition and we are clueless on how to > evaluate them. If you don't have much in house software expertise buying an off the shelf solution with support could be the best bet for you. ODL is aimed more at somebody who wants to "roll their own" solution as it's really giving you a unified southbound API to your devices but you still need to connect with the ODL via its northbound API in order to orchestrate your tin really fluently. This will require a lot of in house development work (probably more than you want). Also this is “just” (albiet a powerful one) an API to your network. It won’t act as a single source of truth, it’s not a data store, or an IPAM, or an NMS etc. Anuta seems quite good, of all the ones you listed in the subject line I'd recommend that one. We had a demo of Anuta NCX and I was pretty happy with it, it's vendor neutral with support for the big names already built it an you can write Python plugins to extending support to any weird vendor kit you might have lurking in a remote dusty PoP, they also take feature request if enough customers have vendor X they’ll add support for it. It is also semi-service orchestrated, you can define “services” yourself and config templates and push them out to devices. I quite liked it, I'd recommend you get a demo if you want an off the self-product that is vendor neutral with support. It ticks those basic boxes (probably more but I can’t remember as we didn’t choose it – not because it was flawed, it just wasn’t what we needed for the project we had in mind). Like ODL it is just for mass configuration and essentially and zero touch provisioning. You need to glue it to the rest of your OSS stack probably via the API. Tail-f - seeing as they were gobbled up by Cisco, do you mean whatever the Cisco product is called now, NSO I believe (Network Services Orchestrator). We had a meeting with Cisco a while back to arrange a demo, at the time it was very Cisco focused however I think it has become more open (in that it is still a closed source product but more network device vendor agnostic). Don’t know UBiqube – I’ll have a read up on it, thanks! > Other than the obvious, which is to try them out, i wonder what else is > important to consider/watch out for. As mentioned above, get something with an API, if you have multiple systems internally for BSS and OSS, try to move towards only having systems with APIs so that in the long term when say the BSS system accepts an order it can push an update to your OSS stack which configure a port on an edge router ready for that customer to connect to, and connects to your NMS API and pre-emptively starts to graph the port; all that jazz. Service orchestration is more than just automating config deployment which some people seem to forgot, or focus too much on, the service wrap is also very important (after accepting an order for a new CPE from a customer, and having fired the order over your suppliers API, in the response from the supplier with the new CPEs serial number, that needs to go into your asset database and be marked against that customer and the end site it’s being shipped to etc). Flexible products with a standardised API. > We are presented with 3 different vendors and even OpenDayLight was > considered as the open source alternative. NAPALM was already mentioned as an open source alternative. If you want to get your hands a bit more dirty consider Ansible or SaltStack (both of which can be used with and without NAPALM but generally you want to use them with NAPALM) as they are both open source and free to use but you can pay for support. We also looked at Blue Planet from Ciena, it’s an impressive product with some big name customers. It also has a big price tag as it’s really for large deployments. We didn’t go with it because we wanted to start (very) small trials and build up. > My humble thoughts are given below and i would appreciate getting > 'schooled' on what i need to ask the vendors: > > 1) Are they Model driven : But i still don't know how to evaluate that. By model driven do you mean like YANG models to infer the configuration state, or model driven from a service perspective? Anuta NCX, Blue Planet, Tail-F/NSO, ODL all have support for YANG models if you meant YANG. Anuta and NSO will let you create “services” which can be config templates that are deployed as a whole and verified, if you mean “service” model driven. > 2) Do they parse Cisco/Juniper CLI or they are limited to SNMP and YANG. If you have IOS devices you NEED a product that supports IOS CLI. IOS is a pain in the backside to automate and the CLI is the only really way of doing it sadly. > 3) If they do parse, we want to check if they'll hold us by the balls if > the current parsers need to be updated, i.e: can we change the code > ourselves and add new features to be parsed. > > 4) Can they work/orchestrate between CLI devices and Non CLI devices (SNMP) Most are supporting multiple transport protocols with the end device, CLI, API etc. All the ones talked about so far do. > 5) How flexible are they to support different Vendors (Cisco, Juniper, > some-weird-firewall...etc) Another question I would ask would be about event driven updates and triggers. After pushing out config template X which configured a new interface on a device, can the system make a call to our NMS API an add that new interface to our graphing platform (if it’s not already being graphed). Equally when removing interface config, make an API call to the NMS to stop graphing it. So that is the system sourcing an event trigger. Can it also receive them, for ZTP for example? You may also want to ask about RBAC; most tools have some sort of RBAC support, for us this is essential in terms of keeping our accreditations. > thanks, > Kim Cheers, James. From rod.beck at unitedcablecompany.com Tue Aug 15 14:52:44 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 15 Aug 2017 14:52:44 +0000 Subject: Virtual or Remote Peering Message-ID: How well does this service work? I understand it usually involves point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds like a service for ISP that would like to peer, but have relatively small volumes for peering purposes or lopsided volumes. Roderick Beck Director of Global Sales United Cable Company DRG Undersea Consulting Affiliate Member www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From hugge at nordu.net Tue Aug 15 15:00:39 2017 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Tue, 15 Aug 2017 17:00:39 +0200 Subject: Virtual or Remote Peering In-Reply-To: References: Message-ID: <006e80d0-4a7c-d1fc-73f9-b2b579a92faf@nordu.net> > How well does this service work? I understand it usually involves point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds like a service for ISP that would like to peer, but have relatively small volumes for peering purposes or lopsided volumes. > > > Roderick Beck > > Director of Global Sales > > United Cable Company > > DRG Undersea Consulting > > Affiliate Member > > www.unitedcablecompany.com > > 85 Király utca, 1077 Budapest > > rod.beck at unitedcablecompany.com > > 36-30-859-5144 > > > [1467221477350_image005.png] > Its like buying regular ip-transit, but worse. -- hugge From rod.beck at unitedcablecompany.com Tue Aug 15 17:22:03 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 15 Aug 2017 17:22:03 +0000 Subject: Last Week's Canadian Fiber Cut Message-ID: Did we ever get any resolution on why this was such a big outage? Appears there were two fiber cuts. Were the fibers damaged in the same conduit? Is this a collapsed ring scenario? http://www.cbc.ca/news/canada/newfoundland-labrador/concerns-about-backup-bell-outage-1.4239064 Roderick Beck Director of Global Sales United Cable Company DRG Undersea Consulting Affiliate Member www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From clinton at scripty.com Tue Aug 15 18:59:26 2017 From: clinton at scripty.com (Clinton Work) Date: Tue, 15 Aug 2017 12:59:26 -0600 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: Message-ID: <1502823566.392709.1074405680.050E5B25@webmail.messagingengine.com> My understanding is that the Bell Aliant outage was a double fault situation. Bell Aliant had a fiber cut on one of their fiber routes early in the morning and then they had a fault on the diverse fiber route before the first trouble could be repaired. On Tue, Aug 15, 2017, at 11:22 AM, Rod Beck wrote: > Did we ever get any resolution on why this was such a big outage? Appears > there were two fiber cuts. Were the fibers damaged in the same conduit? > Is this a collapsed ring scenario? > From rod.beck at unitedcablecompany.com Tue Aug 15 19:04:59 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 15 Aug 2017 19:04:59 +0000 Subject: Last Week's Canadian Fiber Cut In-Reply-To: <1502823566.392709.1074405680.050E5B25@webmail.messagingengine.com> References: , <1502823566.392709.1074405680.050E5B25@webmail.messagingengine.com> Message-ID: In other words, bad luck. Probability dictates if enough time transpires, every bad thing will happen. 😝 ________________________________ From: NANOG on behalf of Clinton Work Sent: Tuesday, August 15, 2017 8:59 PM To: nanog at nanog.org Subject: Re: Last Week's Canadian Fiber Cut My understanding is that the Bell Aliant outage was a double fault situation. Bell Aliant had a fiber cut on one of their fiber routes early in the morning and then they had a fault on the diverse fiber route before the first trouble could be repaired. On Tue, Aug 15, 2017, at 11:22 AM, Rod Beck wrote: > Did we ever get any resolution on why this was such a big outage? Appears > there were two fiber cuts. Were the fibers damaged in the same conduit? > Is this a collapsed ring scenario? > From jared at puck.nether.net Tue Aug 15 19:52:06 2017 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 15 Aug 2017 15:52:06 -0400 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: Message-ID: > On Aug 15, 2017, at 1:22 PM, Rod Beck wrote: > > Did we ever get any resolution on why this was such a big outage? Appears there were two fiber cuts. Were the fibers damaged in the same conduit? Is this a collapsed ring scenario? > > > http://www.cbc.ca/news/canada/newfoundland-labrador/concerns-about-backup-bell-outage-1.4239064 Perhaps some transatlantic fallback? It looks like the only cable out there is the Greenland one.. guessing that’s not very competitive? It only gets you to Iceland it seems. - Jared From clinton at scripty.com Tue Aug 15 20:07:53 2017 From: clinton at scripty.com (Clinton Work) Date: Tue, 15 Aug 2017 14:07:53 -0600 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: Message-ID: <1502827673.408249.1074473208.501C5274@webmail.messagingengine.com> I can't speak for the Bell Aliant network, but I'm only aware of two diverse fiber routes out of Halifax, Nova Scotia. Halifax -> New Brunswick -> Quebec City is the Canadian route and Halifax -> Boston is the diverse route. On Tue, Aug 15, 2017, at 01:52 PM, Jared Mauch wrote: > Perhaps some transatlantic fallback? It looks like the only cable out > there is the Greenland one.. guessing that’s not very competitive? It > only gets you to Iceland it seems. > From rod.beck at unitedcablecompany.com Tue Aug 15 20:37:41 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 15 Aug 2017 20:37:41 +0000 Subject: Last Week's Canadian Fiber Cut In-Reply-To: <1502827673.408249.1074473208.501C5274@webmail.messagingengine.com> References: , <1502827673.408249.1074473208.501C5274@webmail.messagingengine.com> Message-ID: Well Hibernia had those routes. I thought it would have been the 360 terrestrial cable and Hibernia's underwater cable from Halifax to their Boston landing station. ________________________________ From: NANOG on behalf of Clinton Work Sent: Tuesday, August 15, 2017 10:07 PM To: nanog at nanog.org Subject: Re: Last Week's Canadian Fiber Cut I can't speak for the Bell Aliant network, but I'm only aware of two diverse fiber routes out of Halifax, Nova Scotia. Halifax -> New Brunswick -> Quebec City is the Canadian route and Halifax -> Boston is the diverse route. On Tue, Aug 15, 2017, at 01:52 PM, Jared Mauch wrote: > Perhaps some transatlantic fallback? It looks like the only cable out > there is the Greenland one.. guessing that’s not very competitive? It > only gets you to Iceland it seems. > From jbothe at me.com Tue Aug 15 22:04:02 2017 From: jbothe at me.com (JASON BOTHE) Date: Tue, 15 Aug 2017 17:04:02 -0500 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: <1502827673.408249.1074473208.501C5274@webmail.messagingengine.com> Message-ID: Interesting enough, we did not lose connectivity to our offices in PEI, so I assume there is some diversity from that point in the Bell network. J~ > On 15, Aug 2017, at 3:37 PM, Rod Beck wrote: > > Well Hibernia had those routes. I thought it would have been the 360 terrestrial cable and Hibernia's underwater cable from Halifax to their Boston landing station. > > > ________________________________ > From: NANOG on behalf of Clinton Work > Sent: Tuesday, August 15, 2017 10:07 PM > To: nanog at nanog.org > Subject: Re: Last Week's Canadian Fiber Cut > > I can't speak for the Bell Aliant network, but I'm only aware of two > diverse fiber routes out of Halifax, Nova Scotia. Halifax -> New > Brunswick -> Quebec City is the Canadian route and Halifax -> Boston is > the diverse route. > > On Tue, Aug 15, 2017, at 01:52 PM, Jared Mauch wrote: >> Perhaps some transatlantic fallback? It looks like the only cable out >> there is the Greenland one.. guessing that’s not very competitive? It >> only gets you to Iceland it seems. >> > From dcharlebois at gmail.com Wed Aug 16 01:05:04 2017 From: dcharlebois at gmail.com (David Charlebois) Date: Tue, 15 Aug 2017 21:05:04 -0400 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: <1502827673.408249.1074473208.501C5274@webmail.messagingengine.com> Message-ID: Just read this on http://www.ctvnews.ca/business/bell-aliant-says- double-cable-cut-that-led-to-cell-outages-was-perfect-storm-1.3547018 "Bell spokesman Nathan Gibson says the first cut was by a highway construction crew near Drummondville, Que. He says service wasn't impacted in any significant way because of redundancy in the network until a second major cut near Richibucto, N.B., by a logging company in a densely forested location. He says the second cut was difficult to access and took some time to locate precisely, and the site's inaccessibility slowed the arrival of heavy equipment and repair crews." On Tue, Aug 15, 2017 at 6:04 PM, JASON BOTHE wrote: > Interesting enough, we did not lose connectivity to our offices in PEI, so > I assume there is some diversity from that point in the Bell network. > > J~ > > > On 15, Aug 2017, at 3:37 PM, Rod Beck > wrote: > > > > Well Hibernia had those routes. I thought it would have been the 360 > terrestrial cable and Hibernia's underwater cable from Halifax to their > Boston landing station. > > > > > > ________________________________ > > From: NANOG on behalf of Clinton Work < > clinton at scripty.com> > > Sent: Tuesday, August 15, 2017 10:07 PM > > To: nanog at nanog.org > > Subject: Re: Last Week's Canadian Fiber Cut > > > > I can't speak for the Bell Aliant network, but I'm only aware of two > > diverse fiber routes out of Halifax, Nova Scotia. Halifax -> New > > Brunswick -> Quebec City is the Canadian route and Halifax -> Boston is > > the diverse route. > > > > On Tue, Aug 15, 2017, at 01:52 PM, Jared Mauch wrote: > >> Perhaps some transatlantic fallback? It looks like the only cable out > >> there is the Greenland one.. guessing that’s not very competitive? It > >> only gets you to Iceland it seems. > >> > > > > From nanog at ics-il.net Wed Aug 16 13:02:47 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 16 Aug 2017 08:02:47 -0500 (CDT) Subject: Virtual or Remote Peering In-Reply-To: <006e80d0-4a7c-d1fc-73f9-b2b579a92faf@nordu.net> References: <006e80d0-4a7c-d1fc-73f9-b2b579a92faf@nordu.net> Message-ID: <1220319583.2588.1502888562138.JavaMail.mhammett@ThunderFuck> That seems to be a rather lopsided opinion. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Fredrik Korsbäck" To: nanog at nanog.org Sent: Tuesday, August 15, 2017 10:00:39 AM Subject: Re: Virtual or Remote Peering > How well does this service work? I understand it usually involves point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds like a service for ISP that would like to peer, but have relatively small volumes for peering purposes or lopsided volumes. > > > Roderick Beck > > Director of Global Sales > > United Cable Company > > DRG Undersea Consulting > > Affiliate Member > > www.unitedcablecompany.com > > 85 Király utca, 1077 Budapest > > rod.beck at unitedcablecompany.com > > 36-30-859-5144 > > > [1467221477350_image005.png] > Its like buying regular ip-transit, but worse. -- hugge From Mark_Feldman at comcast.com Wed Aug 16 19:24:47 2017 From: Mark_Feldman at comcast.com (Feldman, Mark) Date: Wed, 16 Aug 2017 19:24:47 +0000 Subject: Google Fiber contact Message-ID: Can someone from Google Fiber contact me off list? Thanks. Mark Comcast T&P Core Network Services From brussell at stratusnet.com Tue Aug 15 15:36:08 2017 From: brussell at stratusnet.com (Ben Russell) Date: Tue, 15 Aug 2017 15:36:08 +0000 Subject: Cogent BCP-38 Message-ID: Could someone from Cogent contact me off-list? We are having an issue with one of our downstream customers who is multi-homed to another carrier. The end customer is advertising their prefix to both us and the other carrier. Both us and the other carrier peer with 174. However, if the prefix is preferred through us and the outbound traffic flows over the other carrier it is dropped. We suspect uRPF-strict on the other carriers Cogent link. We are working together with the other carrier and have a ticket open the help desk seem to be confused. Any help would be appreciated. Thanks Ben Russell Senior Network Engineer Stratus Networks (309)370-3174 [logo] From cmaurand at gmail.com Mon Aug 14 19:44:14 2017 From: cmaurand at gmail.com (Curtis Maurand) Date: Mon, 14 Aug 2017 15:44:14 -0400 Subject: For the Wireless Guys In-Reply-To: References: Message-ID: The higher the frequency, the more it acts like light. at that frequency, it wouldn't take much to block it. even 2.4GHz is stopped by a tree. On Mon, Aug 14, 2017 at 12:54 PM, Dan Hollis wrote: > Good for a few meters at best? Terahertz is blocked by air. > > -Dan > > On Mon, 14 Aug 2017, Rod Beck wrote: > > https://phys.org/news/2017-08-transmission-terahertz-multiplexer.html >> >> >> Roderick Beck >> >> Director of Global Sales >> >> United Cable Company >> >> DRG Undersea Consulting >> >> Affiliate Member >> >> www.unitedcablecompany.com >> >> 85 Király utca, 1077 Budapest >> >> rod.beck at unitedcablecompany.com >> >> 36-30-859-5144 >> >> >> [1467221477350_image005.png] >> >> -- --Curtis From paul at paulstewart.org Tue Aug 15 18:36:50 2017 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 15 Aug 2017 14:36:50 -0400 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: Message-ID: <1091FC74-D2BE-4055-B41D-221A91BAEBDA@paulstewart.org> Never really heard a lot about it …. We never lost connectivity to Halifax from Montreal via Hibernia - interesting topic though as we have a backup path that I’m looking to replace :) Paul > On Aug 15, 2017, at 1:22 PM, Rod Beck wrote: > > Did we ever get any resolution on why this was such a big outage? Appears there were two fiber cuts. Were the fibers damaged in the same conduit? Is this a collapsed ring scenario? > > > http://www.cbc.ca/news/canada/newfoundland-labrador/concerns-about-backup-bell-outage-1.4239064 > > > Roderick Beck > > Director of Global Sales > > United Cable Company > > DRG Undersea Consulting > > Affiliate Member > > www.unitedcablecompany.com > > 85 Király utca, 1077 Budapest > > rod.beck at unitedcablecompany.com > > 36-30-859-5144 > > > [1467221477350_image005.png] From paul at paulstewart.org Tue Aug 15 19:56:16 2017 From: paul at paulstewart.org (Paul Stewart) Date: Tue, 15 Aug 2017 15:56:16 -0400 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: Message-ID: It wasn’t an issue getting transatlantic - it was an issue within a relatively small region in Eastern Canada talking to the rest of the world for certain carriers. There were several smaller carriers/providers not affected - just happens the local incumbent telco and one of their larger competitors got knocked out … > On Aug 15, 2017, at 3:52 PM, Jared Mauch wrote: > > >> On Aug 15, 2017, at 1:22 PM, Rod Beck wrote: >> >> Did we ever get any resolution on why this was such a big outage? Appears there were two fiber cuts. Were the fibers damaged in the same conduit? Is this a collapsed ring scenario? >> >> >> http://www.cbc.ca/news/canada/newfoundland-labrador/concerns-about-backup-bell-outage-1.4239064 > > Perhaps some transatlantic fallback? It looks like the only cable out there is the Greenland one.. guessing that’s not very competitive? It only gets you to Iceland it seems. > > - Jared From nickdwhite at gmail.com Fri Aug 11 15:03:09 2017 From: nickdwhite at gmail.com (Nick W) Date: Fri, 11 Aug 2017 11:03:09 -0400 Subject: EdgeRouter Infinity as medium-sized "IXP Peering Router"? In-Reply-To: References: <462128132.3290.1502240367069.JavaMail.mhammett@ThunderFuck> Message-ID: 1.9.7 definitely applies to Infinity: ER-8-XG: https://dl.ubnt.com/firmwares/edgemax/v1.9.7/ER-e1000.v1.9.7+hotfix.1.5005858.tar (SHA256:b1a16900e3fbe1eef3876548ac7eda12a95ef849d4328f22b478459e2a506b92) On Tue, Aug 8, 2017 at 9:07 PM, Josh Reynolds wrote: > Forgot reply all... > > That does not apply to the infinity. Those shipped with 1.9.8dev. > > > On Aug 8, 2017 8:03 PM, "Mike Hammett" wrote: > > > 1.9.7+hotfix.1 is the currently available stable. 1.9.1.1 was released on > > May 1st. > > > > https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX- > > EdgeRouter-software-security-release-v1-9-7-hotfix-1/ba-p/2019161 > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Nick W" > > To: nanog at nanog.org > > Sent: Thursday, July 20, 2017 10:55:28 PM > > Subject: Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"? > > > > Tried the Infinity, unsuccessfully. Several of them. Ended up pulling > them > > all, sitting in my homelab for now. Multiple full tables, nothing fancy > for > > firewall or QOS, but ran into issues with random ribd/bgpd crashes and > > kernel panics. I've submitted a lot of logs and core dumps to UBNT. I > would > > personally stay away from them until they are out of beta, and possibly > > even another 6-12 months after that. > > > > The current stable EdgeMax version (1.9.1.1) is relatively stable, but > > using an outdated ZebOS (1.2.0?) with a number of issues (MPLS, OSPF, > BGP) > > - nothing too major, but can be annoying. Probably okay for what you > > described. Depending on how much throughput you need, an ERPro, or > Mikrotik > > would probably be fine. If you need 10G, load up VyOS on some cheap > servers > > with an Intel or Solarflare card... probably cheaper than a beta Infinity > > or Mikrotik. > > > > On Mon, Jul 3, 2017 at 3:07 PM, Job Snijders wrote: > > > > > Dear NANOG, > > > > > > Some friends of mine are operating a nonprofit (on shoe string) and > > looking > > > to connect some CDN caches to an IX fabric. A BGP speaking device is > > needed > > > between the caches and the BGP peers connected to the fabric. The BGP > > > speaker is needed to present the peers on the IX with a unified view of > > the > > > assemblage of CDN nodes. > > > > > > I was wondering whether anyone was experience with the "EdgeRouter > > Infinity > > > XG" device, specifically in the role of a simple peering router for a > > > couple of tens of thousands of routes. (I'd point default to the left > and > > > take just the on-net routes on the right to reduce the table size > > > requirement). > > > > > > I hope the device can do at least 2xLACP trunks, has a sizable FIB, is > > > automatable (supports idempotency), can forward IMIX at line-rate, > *flow, > > > and exposes some telemetry via SNMP. > > > > > > Any note sharing would be appreciated! > > > > > > Kind regards, > > > > > > Job > > > > > > > > From seanfitz at snap.com Mon Aug 14 17:41:38 2017 From: seanfitz at snap.com (Sean Fitzgerald) Date: Mon, 14 Aug 2017 17:41:38 +0000 Subject: Contact within Verizon Wireless Message-ID: Hello all, I'm looking for a contact within Verizon Wireless US networking operations. Please contact me at this address. thanks, Sean Fitzgerald From afmug at zirkel.us Wed Aug 16 20:47:45 2017 From: afmug at zirkel.us (Sean Heskett) Date: Wed, 16 Aug 2017 14:47:45 -0600 Subject: For the Wireless Guys In-Reply-To: References: Message-ID: 2.4GHz is only stopped by a tree because the FCC EIRP limit for point to multipoint gear is 4 watts or 36dbm. If you turn the power up high enough 2.4GHz will easily go through trees and other objects. It's a regulatory limit, not a physics limit ;-) -Sean On Mon, Aug 14, 2017 at 1:44 PM, Curtis Maurand wrote: > The higher the frequency, the more it acts like light. at that frequency, > it wouldn't take much to block it. even 2.4GHz is stopped by a tree. > > On Mon, Aug 14, 2017 at 12:54 PM, Dan Hollis > wrote: > > > Good for a few meters at best? Terahertz is blocked by air. > > > > -Dan > > > > On Mon, 14 Aug 2017, Rod Beck wrote: > > > > https://phys.org/news/2017-08-transmission-terahertz-multiplexer.html > >> > >> > >> Roderick Beck > >> > >> Director of Global Sales > >> > >> United Cable Company > >> > >> DRG Undersea Consulting > >> > >> Affiliate Member > >> > >> www.unitedcablecompany.com > >> > >> 85 Király utca, 1077 Budapest > >> > >> rod.beck at unitedcablecompany.com > >> > >> 36-30-859-5144 > >> > >> > >> [1467221477350_image005.png] > >> > >> > > > -- > --Curtis > From jlewis at lewis.org Wed Aug 16 21:03:10 2017 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 16 Aug 2017 17:03:10 -0400 (EDT) Subject: For the Wireless Guys In-Reply-To: References: Message-ID: On Wed, 16 Aug 2017, Sean Heskett wrote: > 2.4GHz is only stopped by a tree because the FCC EIRP limit for point to > multipoint gear is 4 watts or 36dbm. If you turn the power up high enough > 2.4GHz will easily go through trees and other objects. It's a regulatory > limit, not a physics limit ;-) So you're saying, with enough power, line of sight will be cleared...at least of any organic obstacles? :) ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mansaxel at besserwisser.org Thu Aug 17 05:42:21 2017 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 17 Aug 2017 07:42:21 +0200 Subject: Virtual or Remote Peering In-Reply-To: <1220319583.2588.1502888562138.JavaMail.mhammett@ThunderFuck> References: <006e80d0-4a7c-d1fc-73f9-b2b579a92faf@nordu.net> <1220319583.2588.1502888562138.JavaMail.mhammett@ThunderFuck> Message-ID: <20170817054220.GA4618@besserwisser.org> Subject: Re: Virtual or Remote Peering Date: Wed, Aug 16, 2017 at 08:02:47AM -0500 Quoting Mike Hammett (nanog at ics-il.net): >>> How well does this service work? I understand it usually involves point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds like a service for ISP that would like to peer, but have relatively small volumes for peering purposes or lopsided volumes. >> Its like buying regular ip-transit, but worse. > That seems to be a rather lopsided opinion. You get connections to other operators over an unreliable path that you have no control over, and the opportunities to keep traffic local are limited. Adding to that, it is all your fault since your provider does not do L3 and can claim a very passive rôle in the process. Like transit, but worse. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 YOW!! The land of the rising SONY!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From tknchris at gmail.com Thu Aug 17 06:02:03 2017 From: tknchris at gmail.com (chris) Date: Thu, 17 Aug 2017 02:02:03 -0400 Subject: Cogent BCP-38 In-Reply-To: References: Message-ID: Time for someone to bake them a bcp38 cake .... On Aug 16, 2017 4:04 PM, "Ben Russell" wrote: > Could someone from Cogent contact me off-list? We are having an issue > with one of our downstream customers who is multi-homed to another > carrier. The end customer is advertising their prefix to both us and the > other carrier. Both us and the other carrier peer with 174. However, if > the prefix is preferred through us and the outbound traffic flows over the > other carrier it is dropped. We suspect uRPF-strict on the other carriers > Cogent link. We are working together with the other carrier and have a > ticket open the help desk seem to be confused. Any help would be > appreciated. Thanks > > > Ben Russell > Senior Network Engineer > Stratus Networks > (309)370-3174 > [logo] > > From swmike at swm.pp.se Thu Aug 17 06:27:17 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 17 Aug 2017 08:27:17 +0200 (CEST) Subject: Cogent BCP-38 In-Reply-To: References: Message-ID: On Thu, 17 Aug 2017, chris wrote: > Time for someone to bake them a bcp38 cake .... I am all for people deploying BCP38, but from the original email this is definitely not a cause for celebration. BCP38 should be used against single homed customers only if you're doing it by using uRPF. Otherwise extreme care needs to be taken to make sure traffic isn't dropped because uRPF does the wrong thing (like it seems in this case). -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at ics-il.net Thu Aug 17 11:35:50 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 17 Aug 2017 06:35:50 -0500 (CDT) Subject: Cogent BCP-38 In-Reply-To: References: Message-ID: <496940670.3866.1502969745768.JavaMail.mhammett@ThunderFuck> Strict vs. loose. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mikael Abrahamsson" To: "chris" Cc: "NANOG list" Sent: Thursday, August 17, 2017 1:27:17 AM Subject: Re: Cogent BCP-38 On Thu, 17 Aug 2017, chris wrote: > Time for someone to bake them a bcp38 cake .... I am all for people deploying BCP38, but from the original email this is definitely not a cause for celebration. BCP38 should be used against single homed customers only if you're doing it by using uRPF. Otherwise extreme care needs to be taken to make sure traffic isn't dropped because uRPF does the wrong thing (like it seems in this case). -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at ics-il.net Thu Aug 17 11:41:45 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 17 Aug 2017 06:41:45 -0500 (CDT) Subject: Virtual or Remote Peering In-Reply-To: <20170817054220.GA4618@besserwisser.org> References: <006e80d0-4a7c-d1fc-73f9-b2b579a92faf@nordu.net> <1220319583.2588.1502888562138.JavaMail.mhammett@ThunderFuck> <20170817054220.GA4618@besserwisser.org> Message-ID: <1889894508.3887.1502970104289.JavaMail.mhammett@ThunderFuck> A company you have a contractual arrangement with vs. random operators of which neither you nor the end party have any relationship with. Which one's unreliable, again? >From a technical perspective: router located with IX > wave to IX > switched PtP\PtMP to IX > remote peering service > transit Fiscally, it's almost the other way around, with where transit goes being variable based on locations and volumes. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Måns Nilsson" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Thursday, August 17, 2017 12:42:21 AM Subject: Re: Virtual or Remote Peering Subject: Re: Virtual or Remote Peering Date: Wed, Aug 16, 2017 at 08:02:47AM -0500 Quoting Mike Hammett (nanog at ics-il.net): >>> How well does this service work? I understand it usually involves point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds like a service for ISP that would like to peer, but have relatively small volumes for peering purposes or lopsided volumes. >> Its like buying regular ip-transit, but worse. > That seems to be a rather lopsided opinion. You get connections to other operators over an unreliable path that you have no control over, and the opportunities to keep traffic local are limited. Adding to that, it is all your fault since your provider does not do L3 and can claim a very passive rôle in the process. Like transit, but worse. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 YOW!! The land of the rising SONY!! From bill at herrin.us Thu Aug 17 13:11:05 2017 From: bill at herrin.us (William Herrin) Date: Thu, 17 Aug 2017 09:11:05 -0400 Subject: Cogent BCP-38 In-Reply-To: <496940670.3866.1502969745768.JavaMail.mhammett@ThunderFuck> References: <496940670.3866.1502969745768.JavaMail.mhammett@ThunderFuck> Message-ID: On Thu, Aug 17, 2017 at 7:35 AM, Mike Hammett wrote: > Strict vs. loose. > Hi Mike, Doesn't loose mode URPF allow packets from anything that exists in the routing table regardless of source? Seems just about worthless. You're allowing the site to spoof anything in the routing table which is NOT BCP38. Strict mode URPF down paths guaranteed to be single-homed. Manually configure allowed sources and announcements for BGP-talking customers. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From ahebert at pubnix.net Thu Aug 17 13:14:49 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 17 Aug 2017 09:14:49 -0400 Subject: Cogent BCP-38 In-Reply-To: References: Message-ID: <76a5f005-1f78-8032-12c1-88555fa99c37@pubnix.net> Give me a contact and I might send enough cupcakes for most of their engineers =D PS: Progression pain is still progression. ----- 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 08/17/17 02:02, chris wrote: > Time for someone to bake them a bcp38 cake .... > > On Aug 16, 2017 4:04 PM, "Ben Russell" wrote: > >> Could someone from Cogent contact me off-list? We are having an issue >> with one of our downstream customers who is multi-homed to another >> carrier. The end customer is advertising their prefix to both us and the >> other carrier. Both us and the other carrier peer with 174. However, if >> the prefix is preferred through us and the outbound traffic flows over the >> other carrier it is dropped. We suspect uRPF-strict on the other carriers >> Cogent link. We are working together with the other carrier and have a >> ticket open the help desk seem to be confused. Any help would be >> appreciated. Thanks >> >> >> Ben Russell >> Senior Network Engineer >> Stratus Networks >> (309)370-3174 >> [logo] >> >> From saku at ytti.fi Thu Aug 17 13:27:21 2017 From: saku at ytti.fi (Saku Ytti) Date: Thu, 17 Aug 2017 16:27:21 +0300 Subject: Cogent BCP-38 In-Reply-To: References: <496940670.3866.1502969745768.JavaMail.mhammett@ThunderFuck> Message-ID: On 17 August 2017 at 16:11, William Herrin wrote: > Doesn't loose mode URPF allow packets from anything that exists in the > routing table regardless of source? Seems just about worthless. You're > allowing the site to spoof anything in the routing table which is NOT > BCP38. Correct. uRPF/loose is pretty undesirable, what you get for the premium you pay, it's rarely justifiable. > Strict mode URPF down paths guaranteed to be single-homed. Manually > configure allowed sources and announcements for BGP-talking customers. JunOS offers 'strict feasible', which would allow packet if there is some route pointing to that interface, not necessarily best. But even that would not be well received by customers, some do TE by omitting advertising prefix out, yet send traffic out without any specific policy, so you may receive traffic from prefix they are allowed to advertise but they do not. I've previously used in JunOS same prefix-list for BGP and firewall filter with good success, but unfortunately sometimes even telling what prefixes might be behind specific BGP session/interface is not trivial. -- ++ytti From jmilko at gmail.com Thu Aug 17 14:18:22 2017 From: jmilko at gmail.com (James Milko) Date: Thu, 17 Aug 2017 10:18:22 -0400 Subject: For the Wireless Guys In-Reply-To: References: Message-ID: Never has the phrase "It burns when IP" been more accurate. On Wed, Aug 16, 2017 at 5:03 PM, Jon Lewis wrote: > On Wed, 16 Aug 2017, Sean Heskett wrote: > > 2.4GHz is only stopped by a tree because the FCC EIRP limit for point to >> multipoint gear is 4 watts or 36dbm. If you turn the power up high enough >> 2.4GHz will easily go through trees and other objects. It's a regulatory >> limit, not a physics limit ;-) >> > > So you're saying, with enough power, line of sight will be cleared...at > least of any organic obstacles? :) > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From jayhanke at gmail.com Thu Aug 17 14:35:28 2017 From: jayhanke at gmail.com (Jay Hanke) Date: Thu, 17 Aug 2017 09:35:28 -0500 Subject: Virtual or Remote Peering In-Reply-To: <1889894508.3887.1502970104289.JavaMail.mhammett@ThunderFuck> References: <006e80d0-4a7c-d1fc-73f9-b2b579a92faf@nordu.net> <1220319583.2588.1502888562138.JavaMail.mhammett@ThunderFuck> <20170817054220.GA4618@besserwisser.org> <1889894508.3887.1502970104289.JavaMail.mhammett@ThunderFuck> Message-ID: I think you are talking about different applications of remote peering. If you connect to a remote IX via transport the routing decision is more along the lines is this packet destined to me. Having a router sitting in the "remote" colo is of little value. It would not help to keep the traffic local as there are only two paths. The router would just forward between the ports on either side. A common application of this is a "backup" IX to pick up content in the event of a failure at the primary IX. A wave service is just a very long cross connect in this regard. If you provide services across the IX and start bouncing things through remote ports (that could stay local). That is a different animal. Jay On Thu, Aug 17, 2017 at 6:41 AM, Mike Hammett wrote: > A company you have a contractual arrangement with vs. random operators of which neither you nor the end party have any relationship with. Which one's unreliable, again? > > From a technical perspective: > router located with IX > wave to IX > switched PtP\PtMP to IX > remote peering service > transit > > Fiscally, it's almost the other way around, with where transit goes being variable based on locations and volumes. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Måns Nilsson" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Thursday, August 17, 2017 12:42:21 AM > Subject: Re: Virtual or Remote Peering > > Subject: Re: Virtual or Remote Peering Date: Wed, Aug 16, 2017 at 08:02:47AM -0500 Quoting Mike Hammett (nanog at ics-il.net): > >>>> How well does this service work? I understand it usually involves point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds like a service for ISP that would like to peer, but have relatively small volumes for peering purposes or lopsided volumes. > >>> Its like buying regular ip-transit, but worse. > >> That seems to be a rather lopsided opinion. > > You get connections to other operators over an unreliable path that you > have no control over, and the opportunities to keep traffic local are > limited. Adding to that, it is all your fault since your provider does > not do L3 and can claim a very passive rôle in the process. > > Like transit, but worse. > > -- > Måns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE SA0XLR +46 705 989668 > YOW!! The land of the rising SONY!! > From nanog at ics-il.net Thu Aug 17 21:23:20 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 17 Aug 2017 16:23:20 -0500 (CDT) Subject: Virtual or Remote Peering In-Reply-To: References: <006e80d0-4a7c-d1fc-73f9-b2b579a92faf@nordu.net> <1220319583.2588.1502888562138.JavaMail.mhammett@ThunderFuck> <20170817054220.GA4618@besserwisser.org> <1889894508.3887.1502970104289.JavaMail.mhammett@ThunderFuck> Message-ID: <2046069954.4429.1503004997598.JavaMail.mhammett@ThunderFuck> I guess I didn't go on to say more about the router situation, but I meant an official network presence, diverse paths to other POPs, etc. for the first entry. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jay Hanke" To: "Mike Hammett" Cc: "NANOG list" Sent: Thursday, August 17, 2017 9:35:28 AM Subject: Re: Virtual or Remote Peering I think you are talking about different applications of remote peering. If you connect to a remote IX via transport the routing decision is more along the lines is this packet destined to me. Having a router sitting in the "remote" colo is of little value. It would not help to keep the traffic local as there are only two paths. The router would just forward between the ports on either side. A common application of this is a "backup" IX to pick up content in the event of a failure at the primary IX. A wave service is just a very long cross connect in this regard. If you provide services across the IX and start bouncing things through remote ports (that could stay local). That is a different animal. Jay On Thu, Aug 17, 2017 at 6:41 AM, Mike Hammett wrote: > A company you have a contractual arrangement with vs. random operators of which neither you nor the end party have any relationship with. Which one's unreliable, again? > > From a technical perspective: > router located with IX > wave to IX > switched PtP\PtMP to IX > remote peering service > transit > > Fiscally, it's almost the other way around, with where transit goes being variable based on locations and volumes. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Måns Nilsson" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Thursday, August 17, 2017 12:42:21 AM > Subject: Re: Virtual or Remote Peering > > Subject: Re: Virtual or Remote Peering Date: Wed, Aug 16, 2017 at 08:02:47AM -0500 Quoting Mike Hammett (nanog at ics-il.net): > >>>> How well does this service work? I understand it usually involves point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds like a service for ISP that would like to peer, but have relatively small volumes for peering purposes or lopsided volumes. > >>> Its like buying regular ip-transit, but worse. > >> That seems to be a rather lopsided opinion. > > You get connections to other operators over an unreliable path that you > have no control over, and the opportunities to keep traffic local are > limited. Adding to that, it is all your fault since your provider does > not do L3 and can claim a very passive rôle in the process. > > Like transit, but worse. > > -- > Måns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE SA0XLR +46 705 989668 > YOW!! The land of the rising SONY!! > From Jeroen.Wunnink at gtt.net Fri Aug 18 09:26:09 2017 From: Jeroen.Wunnink at gtt.net (Jeroen Wunnink) Date: Fri, 18 Aug 2017 09:26:09 +0000 Subject: Virtual or Remote Peering In-Reply-To: References: Message-ID: <20DE61A8-197C-4205-8C09-720E01849BFA@gtt.net> It’s simply extending an exchange vlan over an l2circuit. It works as good as the provider’s network and the intended use for it. As a customer you either want to reach an exchange on a location you’re not at or get a smaller circuit then an exchange would normally sell you directly. Although you pay the provider that provides you the circuit into the exchange as a reseller, you are a full member there. There’s some controversy in the community on its intended use. Some companies simply use it to get onto an exchange within a metro or country without actually getting kit into an exchange’s POP to save money. Others use it across country borders/oceans and use a high-latency circuit to get onto a local exchange, which defeats some purpose of a local internet exchange. (short low latency-paths into local networks) Then again, getting a circuit from the US into an big exchange like LINX, AMSIX or DECIX can be very appealing on both saving cost of transit and keeping your as-paths (artificially?) short. Jeroen Wunnink IP Engineering manager office: +31.208.200.622 ext. 1011 Amsterdam Office www.gtt.net On 15/08/2017, 16:53, "NANOG on behalf of Rod Beck" wrote: How well does this service work? I understand it usually involves point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds like a service for ISP that would like to peer, but have relatively small volumes for peering purposes or lopsided volumes. Roderick Beck Director of Global Sales United Cable Company DRG Undersea Consulting Affiliate Member www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From cscora at apnic.net Fri Aug 18 18:02:39 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 19 Aug 2017 04:02:39 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170818180239.36A43167D@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, SANOG, PacNOG, SAFNOG MENOG, BJNOG, SDNOG, CMNOG, IRNOG 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 19 Aug, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 657966 Prefixes after maximum aggregation (per Origin AS): 256321 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 318644 Total ASes present in the Internet Routing Table: 58117 Prefixes per ASN: 11.32 Origin-only ASes present in the Internet Routing Table: 50261 Origin ASes announcing only one prefix: 22199 Transit ASes present in the Internet Routing Table: 7856 Transit-only ASes present in the Internet Routing Table: 219 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 56 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 65 Number of instances of unregistered ASNs: 69 Number of 32-bit ASNs allocated by the RIRs: 19739 Number of 32-bit ASNs visible in the Routing Table: 15504 Prefixes from 32-bit ASNs in the Routing Table: 63312 Number of bogon 32-bit ASNs visible in the Routing Table: 26 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 329 Number of addresses announced to Internet: 2852057444 Equivalent to 169 /8s, 254 /16s and 241 /24s Percentage of available address space announced: 77.0 Percentage of allocated address space announced: 77.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 219103 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 179034 Total APNIC prefixes after maximum aggregation: 51785 APNIC Deaggregation factor: 3.46 Prefixes being announced from the APNIC address blocks: 178012 Unique aggregates announced from the APNIC address blocks: 74353 APNIC Region origin ASes present in the Internet Routing Table: 8286 APNIC Prefixes per ASN: 21.48 APNIC Region origin ASes announcing only one prefix: 2302 APNIC Region transit ASes present in the Internet Routing Table: 1174 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 56 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3139 Number of APNIC addresses announced to Internet: 764417508 Equivalent to 45 /8s, 144 /16s and 21 /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: 200851 Total ARIN prefixes after maximum aggregation: 95479 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 202628 Unique aggregates announced from the ARIN address blocks: 93514 ARIN Region origin ASes present in the Internet Routing Table: 17958 ARIN Prefixes per ASN: 11.28 ARIN Region origin ASes announcing only one prefix: 6646 ARIN Region transit ASes present in the Internet Routing Table: 1775 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: 2155 Number of ARIN addresses announced to Internet: 1109948448 Equivalent to 66 /8s, 40 /16s and 120 /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: 176258 Total RIPE prefixes after maximum aggregation: 86469 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 172136 Unique aggregates announced from the RIPE address blocks: 104075 RIPE Region origin ASes present in the Internet Routing Table: 24295 RIPE Prefixes per ASN: 7.09 RIPE Region origin ASes announcing only one prefix: 11175 RIPE Region transit ASes present in the Internet Routing Table: 3439 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6095 Number of RIPE addresses announced to Internet: 712878720 Equivalent to 42 /8s, 125 /16s and 170 /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: 84593 Total LACNIC prefixes after maximum aggregation: 18725 LACNIC Deaggregation factor: 4.52 Prefixes being announced from the LACNIC address blocks: 85858 Unique aggregates announced from the LACNIC address blocks: 39440 LACNIC Region origin ASes present in the Internet Routing Table: 6264 LACNIC Prefixes per ASN: 13.71 LACNIC Region origin ASes announcing only one prefix: 1742 LACNIC Region transit ASes present in the Internet Routing Table: 1161 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3780 Number of LACNIC addresses announced to Internet: 171061472 Equivalent to 10 /8s, 50 /16s and 48 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 17163 Total AfriNIC prefixes after maximum aggregation: 3807 AfriNIC Deaggregation factor: 4.51 Prefixes being announced from the AfriNIC address blocks: 19003 Unique aggregates announced from the AfriNIC address blocks: 6990 AfriNIC Region origin ASes present in the Internet Routing Table: 1063 AfriNIC Prefixes per ASN: 17.88 AfriNIC Region origin ASes announcing only one prefix: 333 AfriNIC Region transit ASes present in the Internet Routing Table: 208 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 335 Number of AfriNIC addresses announced to Internet: 93287936 Equivalent to 5 /8s, 143 /16s and 118 /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 5438 4192 87 ERX-CERNET-BKB China Education and Rese 7545 4004 408 395 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2966 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2840 11124 749 KIXS-AS-KR Korea Telecom, KR 9829 2753 1498 549 BSNL-NIB National Internet Backbone, IN 9808 2358 8699 32 CMNET-GD Guangdong Mobile Communication 45899 2293 1453 111 VNPT-AS-VN VNPT Corp, VN 4755 2095 422 220 TATACOMM-AS TATA Communications formerl 7552 1686 1106 71 VIETEL-AS-AP Viettel Corporation, VN 9498 1625 361 144 BBIL-AP BHARTI Airtel Ltd., IN 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 3816 2952 159 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3456 1341 88 SHAW - Shaw Communications Inc., CA 18566 2205 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2063 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2026 2214 434 CHARTER-NET-HKY-NC - Charter Communicat 209 1859 5065 635 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1826 329 279 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16509 1819 3862 538 AMAZON-02 - Amazon.com, Inc., US 701 1718 10559 628 UUNET - MCI Communications Services, In 6983 1693 854 229 ITCDELTA - Earthlink, 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 3387 186 23 ALJAWWALSTC-AS, SA 20940 2971 968 2135 AKAMAI-ASN1, US 8551 2546 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2057 332 424 TELLCOM-AS, TR 9121 1909 1691 17 TTNET, TR 12479 1653 1048 59 UNI2-AS, ES 12389 1607 1536 668 ROSTELECOM-AS, RU 13188 1602 100 55 TRIOLAN, UA 6849 1225 355 21 UKRTELNET, UA 8402 1169 544 15 CORBINA-AS OJSC "Vimpelcom", 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 3547 542 217 Telmex Colombia S.A., CO 8151 2843 3410 583 Uninet S.A. de C.V., MX 11830 2109 370 65 Instituto Costarricense de Electricidad 7303 1560 1018 247 Telecom Argentina S.A., AR 6503 1555 437 53 Axtel, S.A.B. de C.V., MX 6147 1214 377 27 Telefonica del Peru S.A.A., PE 3816 1026 504 95 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 953 2278 185 CLARO S.A., BR 11172 917 126 86 Alestra, S. de R.L. de C.V., MX 18881 898 1052 23 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 1198 398 48 LINKdotNET-AS, EG 37611 748 91 8 Afrihost, ZA 36903 711 357 130 MT-MPLS, MA 36992 679 1378 29 ETISALAT-MISR, EG 24835 499 850 15 RAYA-AS, EG 29571 421 36 10 CITelecom-AS, CI 37492 407 321 75 ORANGE-, TN 15399 357 35 7 WANANCHI-, KE 2018 305 327 74 TENET-1, ZA 23889 278 103 14 MauritiusTelecom, MU 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 5438 4192 87 ERX-CERNET-BKB China Education and Rese 7545 4004 408 395 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3816 2952 159 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3547 542 217 Telmex Colombia S.A., CO 6327 3456 1341 88 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2971 968 2135 AKAMAI-ASN1, US 17974 2966 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 8151 2843 3410 583 Uninet S.A. de C.V., MX 4766 2840 11124 749 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 3816 3657 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 4004 3609 TPG-INTERNET-AP TPG Telecom Limited, AU 6327 3456 3368 SHAW - Shaw Communications Inc., CA 39891 3387 3364 ALJAWWALSTC-AS, SA 10620 3547 3330 Telmex Colombia S.A., CO 17974 2966 2893 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8551 2546 2505 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9808 2358 2326 CMNET-GD Guangdong Mobile Communication Co.Ltd. 8151 2843 2260 Uninet S.A. de C.V., MX 9829 2753 2204 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65532 PRIVATE 14.192.19.0/24 132717 NDCTPL-IN NxtGen Datacenter & 65001 PRIVATE 43.229.208.0/24 135334 NEO-AS-AP NetExpress Online, B 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 290012147 UNALLOCATED 63.65.43.0/24 7046 RFC2270-UUNET-CUSTOMER - MCI C Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.79.12.0/22 37306 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 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:15 /9:13 /10:36 /11:104 /12:284 /13:554 /14:1051 /15:1852 /16:13432 /17:7672 /18:13425 /19:24703 /20:38890 /21:41705 /22:78620 /23:65002 /24:368360 /25:856 /26:634 /27:650 /28:37 /29:25 /30:17 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3252 3456 SHAW - Shaw Communications Inc., CA 22773 3002 3816 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2946 3387 ALJAWWALSTC-AS, SA 18566 2089 2205 MEGAPATH5-US - MegaPath Corporation, US 8551 2011 2546 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1608 1826 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1499 2109 Instituto Costarricense de Electricidad y Telec 10620 1493 3547 Telmex Colombia S.A., CO 11492 1388 1567 CABLEONE - CABLE ONE, INC., US 6389 1371 2063 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1572 2:832 4:18 5:2454 6:31 7:1 8:1052 12:1854 13:142 14:1709 15:27 16:2 17:193 18:90 20:61 23:2439 24:1914 25:2 27:2361 29:1 31:1920 32:84 33:18 35:21 36:393 37:2362 38:1330 39:65 40:97 41:2954 42:463 43:1966 44:78 45:3015 46:2793 47:163 49:1257 50:995 51:19 52:815 54:364 55:7 56:4 57:45 58:1569 59:1009 60:327 61:1922 62:1695 63:1907 64:4653 65:2208 66:4570 67:2282 68:1232 69:3360 70:1176 71:615 72:2226 74:2718 75:389 76:427 77:1469 78:1447 79:1944 80:1410 81:1393 82:1000 83:731 84:946 85:1823 86:467 87:1206 88:769 89:2181 90:166 91:6188 92:1005 93:2394 94:2343 95:2656 96:652 97:355 98:1067 99:98 100:153 101:1220 103:15646 104:3023 105:186 106:568 107:1753 108:820 109:2903 110:1457 111:1746 112:1252 113:1251 114:1059 115:1559 116:1660 117:1757 118:2163 119:1652 120:733 121:1060 122:2334 123:1824 124:1484 125:1785 128:886 129:665 130:440 131:1473 132:571 133:191 134:680 135:225 136:453 137:470 138:1924 139:505 140:399 141:642 142:778 143:878 144:809 145:184 146:1087 147:701 148:1482 149:570 150:722 151:981 152:727 153:297 154:883 155:758 156:660 157:663 158:479 159:1556 160:739 161:744 162:2520 163:503 164:950 165:1396 166:382 167:1291 168:2991 169:841 170:3481 171:335 172:1014 173:1992 174:813 175:747 176:1896 177:4002 178:2556 179:1128 180:2214 181:1962 182:2389 183:776 184:877 185:10473 186:3316 187:2199 188:2603 189:1798 190:8347 191:1342 192:9553 193:5802 194:4680 195:3919 196:2100 197:1325 198:5542 199:5900 200:7579 201:4299 202:10334 203:9994 204:4540 205:2850 206:3076 207:3156 208:3941 209:3995 210:3950 211:2061 212:2890 213:2520 214:860 215:66 216:5891 217:2130 218:897 219:601 220:1686 221:899 222:749 223:1193 End of report From dougb at dougbarton.us Fri Aug 18 18:04:19 2017 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 18 Aug 2017 11:04:19 -0700 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: <1502827673.408249.1074473208.501C5274@webmail.messagingengine.com> Message-ID: <52aadec9-cd4f-e772-f025-d9d5cf230352@dougbarton.us> Does this sound like a dry run to anyone else? Or did I forget to take my anti-paranoia pills today? On 08/15/2017 06:05 PM, David Charlebois wrote: > Just read this on http://www.ctvnews.ca/business/bell-aliant-says- > double-cable-cut-that-led-to-cell-outages-was-perfect-storm-1.3547018 > > "Bell spokesman Nathan Gibson says the first cut was by a highway > construction crew near Drummondville, Que. > > He says service wasn't impacted in any significant way because of > redundancy in the network until a second major cut near Richibucto, N.B., > by a logging company in a densely forested location. > > He says the second cut was difficult to access and took some time to locate > precisely, and the site's inaccessibility slowed the arrival of heavy > equipment and repair crews." From mark.tinka at seacom.mu Sat Aug 19 03:41:38 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 19 Aug 2017 05:41:38 +0200 Subject: Network & Socialize @ SAFNOG-3 Message-ID: Hello all. The Internet is built on mutually fulfilling human connections, and at this year's SAFNOG meeting, we look forward to further enhancing these opportunities. There are a number of networking and social engagements planned for you, our delegates, at SAFNOG-3 in Durban: a) SAFNOG-3 will be co-located with iWeek, at the very same venue. You will have the chance to interact with several Internet personalities attending iWeek to understand their perspective. b) Prior to the start of each day, as well as during the lunch and coffee breaks, you will be able to surround yourself with fellow delegates and exchange ideas about the topics that will have been presented, or your own personal and professional experiences working on the Internet. c) NAPAfrica, Africa's largest Internet exchange point, will hold a Beers for Peers event at the California Dreaming venue in Durban. You are all invited to attend, free of charge, upon presentation of a ticket which will be handed to you at the registration counter. d) SEACOM, Eastern Africa's first submarine cable system, will hold the Closing Social Dinner at the Joint Jazz Cafe in Durban. You are all invited to attend, free of charge, upon presentation of a ticket which will be handed to you at the registration counter. e) For a bit of fun, an iPhone 7 Plus Jet Black, 256GB and iPad Pro 12.9-inch Space Gray, 512GB, Wi-Fi + Cellular, will be up for grabs in a lucky draw at the NAPAfrica and SEACOM events, respectively. So please carry your business cards and stand a chance to win one of these cool devices. For more details on the agenda and timing listings, please see: http://safnog.org/#section-agenda Do register your attendance as soon as you can. We look forward to seeing you in Durban. Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee From hannigan at gmail.com Sat Aug 19 05:32:04 2017 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 19 Aug 2017 01:32:04 -0400 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: Message-ID: On Tue, Aug 15, 2017 at 3:52 PM, Jared Mauch wrote: > > > On Aug 15, 2017, at 1:22 PM, Rod Beck > wrote: > > > > Did we ever get any resolution on why this was such a big outage? > Appears there were two fiber cuts. Were the fibers damaged in the same > conduit? Is this a collapsed ring scenario? > > > > > > http://www.cbc.ca/news/canada/newfoundland-labrador/concerns > -about-backup-bell-outage-1.4239064 > > Perhaps some transatlantic fallback? It looks like the only cable out > there is the Greenland one.. guessing that’s not very competitive? It only > gets you to Iceland it seems. > > For background on the Greenland Connect cable, the UKNOF presentation I presented (built by Heller, Harland, and I) in 2009 is here at http://bit.ly/GrConnect - You can get past Iceland for sure. Just not for free. (Honorable mentions in all of this for AMS-IX, LINX, Nick Hilliard, Andy Davidson and Will Hargrave. Remco van Mook got the Golden Jökulhlaup for his part). The route was cost prohibitive as you guessed. There was reach-ability from the EU to CA via RVK and GOH, The built paths were CPH-RVK-GOH-YHZ and LON-RVK-GOH-YHZ. While the GOH route were most prohibitive, the RVK paths less so. It was much cheaper to route LON to LGA via Hibernia. I like it as a back up path. So did a few banks. But cost. Do I think this is a viable path? Yes. Will it ever come down in cost? I'd go back to try this again. Maybe things have changed? Best, -M< From nanog at ics-il.net Sun Aug 20 15:45:38 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 20 Aug 2017 10:45:38 -0500 (CDT) Subject: 100G - Whitebox In-Reply-To: <719160085.6429.1503243718084.JavaMail.mhammett@ThunderFuck> Message-ID: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> I first sent to an IX-specific mailing list, but as I have yet to see the message hit the list, I figured I would post it here as well. We've had multiple requests for 100G interfaces (instead of Nx10G) and no one seems to care about the 40G interfaces we have available. Looking at cost effective options brings us to whitebox switches. Obviously there's a wide range of hardware vendors and there are a few OSes available as well. Cumulus seems to be the market leader, while IPinFusion seems to be the most feature-rich. We're not doing any automation on the switches at this time, so it would still need decent manual configuration. It wouldn't need a Cisco-centric CLI as we're quite comfortable managing standard Linux-type config files. We're not going all-in on some overlay either given that we wouldn't be replacing our entire infrastructure, only supplementing it where we need 100G. I know that LINX has gone IPinfusion. What OS would be appropriate for our usage? I'm not finding many good comparisons of the OSes out there. I'm assuming any of them would work, but there may be gotchas that a "cheapest that meets requirements" doesn't quite unveil. Any particular hardware platforms to go towards or avoid? Broadcom Tomahawk seems to be quite popular with varying control planes. LINX went Edgecore, which was on my list given my experience with other Accton brands. Fiberstore has a switch where they actually publish the pricing vs. a bunch of mystery. Thoughts? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From joelja at bogus.com Sun Aug 20 16:07:07 2017 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 20 Aug 2017 09:07:07 -0700 Subject: 100G - Whitebox In-Reply-To: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> References: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> Message-ID: > On Aug 20, 2017, at 08:45, Mike Hammett wrote: > > Any particular hardware platforms to go towards or avoid? Broadcom Tomahawk seems to be quite popular with varying control planes. LINX went Edgecore, which was on my list given my experience with other Accton brands. Fiberstore has a switch where they actually publish the pricing vs. a bunch of mystery. Tomahawk and tomahawk 2 have precious little in the form of packet packet buffer (e.g. As little as 4 x 4MB for original tomahawk) which might be a problem in a environment where you need to rate convert 100G attached peers to a big bundle of 10s). White box Broadcom dnx / jericho is somewhat less common but does exist. That 40s are less popular I think is no surprise. They were / are largely consigned to datacenter applications. > Thoughts? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From nanog at ics-il.net Sun Aug 20 16:30:47 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 20 Aug 2017 11:30:47 -0500 (CDT) Subject: 100G - Whitebox In-Reply-To: References: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> Message-ID: <320692956.6476.1503246646539.JavaMail.mhammett@ThunderFuck> DNX/Jericho would have sufficient buffers to handle the rate conversions? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Joel Jaeggli" To: "Mike Hammett" Cc: "NANOG list" Sent: Sunday, August 20, 2017 11:07:07 AM Subject: Re: 100G - Whitebox > On Aug 20, 2017, at 08:45, Mike Hammett wrote: > > Any particular hardware platforms to go towards or avoid? Broadcom Tomahawk seems to be quite popular with varying control planes. LINX went Edgecore, which was on my list given my experience with other Accton brands. Fiberstore has a switch where they actually publish the pricing vs. a bunch of mystery. Tomahawk and tomahawk 2 have precious little in the form of packet packet buffer (e.g. As little as 4 x 4MB for original tomahawk) which might be a problem in a environment where you need to rate convert 100G attached peers to a big bundle of 10s). White box Broadcom dnx / jericho is somewhat less common but does exist. That 40s are less popular I think is no surprise. They were / are largely consigned to datacenter applications. > Thoughts? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > From ray at oneunified.net Sun Aug 20 16:38:25 2017 From: ray at oneunified.net (Raymond Burkholder) Date: Sun, 20 Aug 2017 13:38:25 -0300 Subject: 100G - Whitebox In-Reply-To: <320692956.6476.1503246646539.JavaMail.mhammett@ThunderFuck> References: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> <320692956.6476.1503246646539.JavaMail.mhammett@ThunderFuck> Message-ID: On 08/20/17 13:30, Mike Hammett wrote: > DNX/Jericho would have sufficient buffers to handle the rate conversions? You could try Mellanox. Some of the promotional stuff I've seen/heard indicates their focus on appropriate sized buffers & low packet loss on rate conversion. > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > -- Raymond Burkholder https://blog.raymond.burkholder.net/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From woody at pch.net Sun Aug 20 16:40:49 2017 From: woody at pch.net (Bill Woodcock) Date: Sun, 20 Aug 2017 09:40:49 -0700 Subject: 100G - Whitebox In-Reply-To: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> References: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> Message-ID: <4A3FA52E-22E1-49C0-B533-F49FC7E27F64@pch.net> Why don't we just swap out your 40g switch for a 100g switch? You've had the 40g one for a while, and we anticipate upgrades every 18-24 months. -Bill > On Aug 20, 2017, at 08:46, Mike Hammett wrote: > > I first sent to an IX-specific mailing list, but as I have yet to see the message hit the list, I figured I would post it here as well. > > We've had multiple requests for 100G interfaces (instead of Nx10G) and no one seems to care about the 40G interfaces we have available. > > Looking at cost effective options brings us to whitebox switches. Obviously there's a wide range of hardware vendors and there are a few OSes available as well. Cumulus seems to be the market leader, while IPinFusion seems to be the most feature-rich. > > We're not doing any automation on the switches at this time, so it would still need decent manual configuration. It wouldn't need a Cisco-centric CLI as we're quite comfortable managing standard Linux-type config files. We're not going all-in on some overlay either given that we wouldn't be replacing our entire infrastructure, only supplementing it where we need 100G. I know that LINX has gone IPinfusion. What OS would be appropriate for our usage? I'm not finding many good comparisons of the OSes out there. I'm assuming any of them would work, but there may be gotchas that a "cheapest that meets requirements" doesn't quite unveil. > > Any particular hardware platforms to go towards or avoid? Broadcom Tomahawk seems to be quite popular with varying control planes. LINX went Edgecore, which was on my list given my experience with other Accton brands. Fiberstore has a switch where they actually publish the pricing vs. a bunch of mystery. > > Thoughts? > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com From hugge at nordu.net Sun Aug 20 17:24:41 2017 From: hugge at nordu.net (=?utf-8?Q?Fredrik_Korsb=C3=A4ck?=) Date: Sun, 20 Aug 2017 19:24:41 +0200 Subject: 100G - Whitebox In-Reply-To: <4A3FA52E-22E1-49C0-B533-F49FC7E27F64@pch.net> References: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> <4A3FA52E-22E1-49C0-B533-F49FC7E27F64@pch.net> Message-ID: <0FC35FEA-1E30-4E73-90F4-655A70087573@nordu.net> The only viable merchant silicon chip that would be useful for a IXP is from the StrataDNX-family which house the jericho/qumran/petra/arad chips from broadcom. No packetbuffer in the exhangepoint will shred performance significantly, especially when one of your bursty 100G customers starts sending data into 1/10G customers. To the best of my knowledge the only one that offers DNX in whitebox-fashion is Agema and Edgecore. But why whitebox? Except on a very few occasions whitebox is just "i like paying hardware and software on different invoices = whitebox" the TCO is just the same but. As an exchangepoint i also see that it can hard to reap the benefits of all the hipstershit going on in these NOS-startups, you want spanning-tree, port-security, something to loadbalance over links and perhaps a overlaying-technology if the IXP becomes to big and distributed, like vxlan. This is to easy almost. Whenever i see unbuffered mix-speed IXPs i ask if i can pay 25% of the portcost since that is actually how much oumpfff i would get through the port. // hugge @ 2603 > 20 aug. 2017 kl. 18:40 skrev Bill Woodcock : > > Why don't we just swap out your 40g switch for a 100g switch? You've had the 40g one for a while, and we anticipate upgrades every 18-24 months. > > -Bill > > >> On Aug 20, 2017, at 08:46, Mike Hammett wrote: >> >> I first sent to an IX-specific mailing list, but as I have yet to see the message hit the list, I figured I would post it here as well. >> >> We've had multiple requests for 100G interfaces (instead of Nx10G) and no one seems to care about the 40G interfaces we have available. >> >> Looking at cost effective options brings us to whitebox switches. Obviously there's a wide range of hardware vendors and there are a few OSes available as well. Cumulus seems to be the market leader, while IPinFusion seems to be the most feature-rich. >> >> We're not doing any automation on the switches at this time, so it would still need decent manual configuration. It wouldn't need a Cisco-centric CLI as we're quite comfortable managing standard Linux-type config files. We're not going all-in on some overlay either given that we wouldn't be replacing our entire infrastructure, only supplementing it where we need 100G. I know that LINX has gone IPinfusion. What OS would be appropriate for our usage? I'm not finding many good comparisons of the OSes out there. I'm assuming any of them would work, but there may be gotchas that a "cheapest that meets requirements" doesn't quite unveil. >> >> Any particular hardware platforms to go towards or avoid? Broadcom Tomahawk seems to be quite popular with varying control planes. LINX went Edgecore, which was on my list given my experience with other Accton brands. Fiberstore has a switch where they actually publish the pricing vs. a bunch of mystery. >> >> Thoughts? >> >> >> >> >> ----- >> Mike Hammett >> Intelligent Computing Solutions >> http://www.ics-il.com >> >> Midwest-IX >> http://www.midwest-ix.com > From nick at foobar.org Sun Aug 20 22:12:12 2017 From: nick at foobar.org (Nick Hilliard) Date: Sun, 20 Aug 2017 23:12:12 +0100 Subject: 100G - Whitebox In-Reply-To: <0FC35FEA-1E30-4E73-90F4-655A70087573@nordu.net> References: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> <4A3FA52E-22E1-49C0-B533-F49FC7E27F64@pch.net> <0FC35FEA-1E30-4E73-90F4-655A70087573@nordu.net> Message-ID: <599A093C.8070706@foobar.org> Fredrik Korsbäck wrote: > The only viable merchant silicon chip that would be useful for a IXP > is from the StrataDNX-family which house the > jericho/qumran/petra/arad chips from broadcom. No packetbuffer in the > exhangepoint will shred performance significantly, especially when > one of your bursty 100G customers starts sending data into 1/10G > customers. > > To the best of my knowledge the only one that offers DNX in > whitebox-fashion is Agema and Edgecore. But why whitebox? Except on a > very few occasions whitebox is just "i like paying hardware and > software on different invoices = whitebox" the TCO is just the same > but. As an exchangepoint i also see that it can hard to reap the > benefits of all the hipstershit going on in these NOS-startups, you > want spanning-tree, port-security, something to loadbalance over > links and perhaps a overlaying-technology if the IXP becomes to big > and distributed, like vxlan. This is to easy almost. so yeah, hmm. spanning-tree: urgh. port-security: no thank you. Static ACLs only. core ecmp/lag load-balance: don't use vpls. Buffering is hard and gets down to having a good understanding of cost / benefit analysis of your core network and your stakeholders' requirements. The main problem category which IXPs will find it difficult to handle is the set of situations where two participant networks are exchanging individual traffic streams at a rate which is comparable to the egress port speed of the receiving network. This could be 100G-connected devices sending 50G-80G traffic streams to other 100G-connected devices, but the other main situation where this would occur would be high speed CDNs sending traffic to access networks where the individual ISP->customer links would be provisioned in roughly the same speed category as the IXP-ISP link. For example, a small provider doing high speed gpon or docsis, with a small IXP port, e.g. because it's only for a couple of small peers, or maybe it's a backup port or something. In that situation, tcp streams will flood the IXP port at rates which are comparable to the ISP-access layer. If you're not buffering in that situation, the ISP will end up in trouble because they'll drop packets like crazy and the IXP can end up in trouble because shared buffers will be exhausted and may be unavailable for other IXP participants. Mostly you can engineer around this, but it's not as simple as saying that small-buffer switches aren't suitable for an IXP. They can be, but it depends on the network engineering requirements of the ixp participants, and how the ixp is designed. No simple answers here, sorry :-( The flip side of this is that individual StrataDNX asics don't offer the raw performance grunt of the StrataXGS family, and there is a serious difference in costs and performance between a 1U box with a single tomahawk and a 2U box with a 4-way jericho config, make no mistake about it. Otherwise white boxes can reduce costs if you know what you're doing and you're spot on that TCO should be one of the main determinants if the performance characteristics are otherwise similar. TCO is a strange beast though. Everything from kit capex to FLS to depreciation term counts forwards TCO, so it's important to understand your cost base and organisational costing model thoroughly before making any decisions. Nick From swmike at swm.pp.se Mon Aug 21 04:33:24 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 21 Aug 2017 06:33:24 +0200 (CEST) Subject: 100G - Whitebox In-Reply-To: <599A093C.8070706@foobar.org> References: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> <4A3FA52E-22E1-49C0-B533-F49FC7E27F64@pch.net> <0FC35FEA-1E30-4E73-90F4-655A70087573@nordu.net> <599A093C.8070706@foobar.org> Message-ID: On Sun, 20 Aug 2017, Nick Hilliard wrote: > Mostly you can engineer around this, but it's not as simple as saying > that small-buffer switches aren't suitable for an IXP. Could you please elaborate on this? How do you engineer around having basically no buffers at all, and especially if these very small buffers are shared between ports. -- Mikael Abrahamsson email: swmike at swm.pp.se From nick at foobar.org Mon Aug 21 11:10:17 2017 From: nick at foobar.org (Nick Hilliard) Date: Mon, 21 Aug 2017 12:10:17 +0100 Subject: 100G - Whitebox In-Reply-To: References: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> <4A3FA52E-22E1-49C0-B533-F49FC7E27F64@pch.net> <0FC35FEA-1E30-4E73-90F4-655A70087573@nordu.net> <599A093C.8070706@foobar.org> Message-ID: <599ABF99.5060507@foobar.org> Mikael Abrahamsson wrote: > On Sun, 20 Aug 2017, Nick Hilliard wrote: >> Mostly you can engineer around this, but it's not as simple as saying >> that small-buffer switches aren't suitable for an IXP. > > Could you please elaborate on this? > > How do you engineer around having basically no buffers at all, and > especially if these very small buffers are shared between ports. you assess and measure, then choose the appropriate set of tools to deal with your requirements and which is cost appropriate for your financials, i.e. the same as in any engineering situation. At an IXP, it comes down to the maximum size of tcp stream you expect to transport. This will vary depending on the stakeholders at the IXP, which usually depends on the size of the IXP. Larger IXPs will have a wider traffic remit and probably a much larger variance in this regard. Smaller IXPs typically transport content to access network data, which is usually well behaved traffic. Traffic drops on the core need to be kept to the minimum, particularly during normal operation. Eliminating traffic drops is unnecessary and unwanted because of how IP works, so in your core you need to aim for either link overengineering or else enough buffering to ensure that site-to-site latency does not exceed X ms and Y% packet loss. Each option has a cost implication. At the IXP participant edge, there is a different set of constraints which will depend on what's downstream of the participant, where the traffic flows are, what size they are, etc. In general, traffic loss at the IXP handoff will tend only to be a problem if there is a disparity between the bandwidth left available on the egress direction and the maximum link speed downstream of the IXP participant. For example, a content network has servers which inject content at 10G, which connects through a 100G IXP port. The egress IXP port is a mid-loaded 1G link which connects through to 10mbit WISP customers. In this case, the ixp will end up doing negligible buffering because most of the buffering load will be handled on the WISP's internal infrastructure, specifically at the core-to-10mbit handoff. The IXP port might end up dropping a packet or two during the initial tcp burst, but that is likely to be latency specific and won't particularly harm overall performance because of tcp slow start. On the other hand, if it were a mid-loaded 1G link with 500mbit access customers on the other side (e.g. docsis / gpon / ftth), then the IXP would end up being the primary buffering point between the content source and destination and this would cause problems. The remedy here is either for the ixp to move the customer to a buffered port (e.g. different switch), or for the access customer to upgrade their link. If you want to push 50G-80G streams through an IXP, I'd argue that you really shouldn't, not just because of cost but also because this is very expensive to engineer properly and you're also certainly better off with a pni. This approach works better on some networks than others. The larger the IXP, the more difficult it is to manage this, both in terms of core and edge provisioning, i.e. the greater the requirement for buffering in both situations because you have a greater variety of streaming scales per network. So although this isn't going to work as well for top-10 ixps as for mid- or smaller-scale ixps, where it works, it can provide similar quality of service at a significantly lower cost base. IOW, know your requirements and choose your tools to match. Same as with all engineering. Nick From jerome at ceriz.fr Mon Aug 21 12:40:23 2017 From: jerome at ceriz.fr (=?UTF-8?Q?J=c3=a9r=c3=b4me_Nicolle?=) Date: Mon, 21 Aug 2017 14:40:23 +0200 Subject: 100G - Whitebox In-Reply-To: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> References: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> Message-ID: Hello Mike, Le 20/08/2017 à 17:45, Mike Hammett a écrit : > Looking at cost effective options brings us to whitebox switches. Obviously there's a wide range of hardware vendors and there are a few OSes available as well. Cumulus seems to be the market leader, while IPinFusion seems to be the most feature-rich. You may want to take a look at this paper before choosing your NOS : https://hal-univ-tlse3.archives-ouvertes.fr/hal-01276379v1 This described an OpenFlow SDN approach to dumb-down whitebox switches as to fully avoid broadcast traffic, while performing as well as a complex VPLS fabric. This design is operating consistently on the Toulouse Internet Exchange since 2015 using Pica8's gear. So maybe a CLI and feature-full NOS will better suit your needs, but for an IXP, the programmatic approach has demonstrated to be working just fine. Best regards, -- Jérôme Nicolle +33 (0)6 19 31 27 14 From coyo at darkdna.net Mon Aug 21 19:24:07 2017 From: coyo at darkdna.net (Coyo Stormcaller) Date: Mon, 21 Aug 2017 14:24:07 -0500 Subject: 100G - Whitebox In-Reply-To: <599ABF99.5060507@foobar.org> References: <1954258250.6444.1503243933932.JavaMail.mhammett@ThunderFuck> <4A3FA52E-22E1-49C0-B533-F49FC7E27F64@pch.net> <0FC35FEA-1E30-4E73-90F4-655A70087573@nordu.net> <599A093C.8070706@foobar.org> <599ABF99.5060507@foobar.org> Message-ID: <20170821142407.14ec7e09@nullhead> On Mon, 21 Aug 2017 12:10:17 +0100 Nick Hilliard wrote: > IOW, know your requirements and choose your tools to match. Same as > with all engineering. Very fascinating read. Thank you for posting. From davidpeahi at gmail.com Mon Aug 21 20:05:54 2017 From: davidpeahi at gmail.com (david peahi) Date: Mon, 21 Aug 2017 13:05:54 -0700 Subject: Cox in Omaha blackhole routing to Level 3 Message-ID: Can someone from Cox reply to me offline regarding a Cox routing issue in Omaha? Both ends of connection are on Cox network, but a traceroute shows packets being routed into Level 3 at 4.35.186.61 24 msec 24 msec 24 msec, and blackholed in Level 3 network. David Holmes From colton.conor at gmail.com Mon Aug 21 20:26:20 2017 From: colton.conor at gmail.com (Colton Conor) Date: Mon, 21 Aug 2017 15:26:20 -0500 Subject: Creating a Circuit ID Format Message-ID: We are building a new fiber network, and need help creating a circuit ID format to for new fiber circuits. Is there a guide or standard for fiber circuit formats? Does the circuit ID change when say a customer upgrades for 100Mbps to 1Gbps port? What do the larger carriers do? Any advice on creating a circuit ID format for a brand new fiber network? Originally we ran a CLEC using a LECs copper, and our circuit ID was historically a telephone number for DSL circuits. The ILEC had a complex method for assigning circuit IDs. I am sure anything will work as long as you keep track of it, but any advice would be great! From nick at foobar.org Mon Aug 21 20:31:54 2017 From: nick at foobar.org (Nick Hilliard) Date: Mon, 21 Aug 2017 21:31:54 +0100 Subject: Creating a Circuit ID Format In-Reply-To: References: Message-ID: <599B433A.1010507@foobar.org> Colton Conor wrote: > What do the larger carriers do? Any advice on creating a circuit ID format > for a brand new fiber network? "Begin at the beginning", the King said, very gravely, "and go on till you come to the end: then stop." I suggest starting at "1". Feel free to pad with zeros as appropriate. Nick From jared at puck.Nether.net Mon Aug 21 20:38:02 2017 From: jared at puck.Nether.net (Jared Mauch) Date: Mon, 21 Aug 2017 16:38:02 -0400 Subject: Creating a Circuit ID Format In-Reply-To: References: Message-ID: <20170821203801.GA28859@puck.nether.net> On Mon, Aug 21, 2017 at 03:26:20PM -0500, Colton Conor wrote: > We are building a new fiber network, and need help creating a circuit ID > format to for new fiber circuits. Is there a guide or standard for fiber > circuit formats? Does the circuit ID change when say a customer upgrades > for 100Mbps to 1Gbps port? I've seen a few different methods for this, the most common includes some form of the source/dest pop locations for the service delivery. an example: yy-chcgil-dllstx-xx where yy and xx may provide some more detail. the pop codes might include more detail about the equipment in use, same for yy/xx that might encode the underlying service/speeds or numbering in the case of multiple things involved. from the circuit-id you would be able to look up other details like underlying carriers, service or abstraction layers such as what routers/DWDM/fiber the service rides upon. > What do the larger carriers do? Any advice on creating a circuit ID format > for a brand new fiber network? I would stick with some variant of A-Z location data and leave any service speeds at the phy speed of the device, eg: don't call it 300m if it's 1G ethernet rate-limited. > Originally we ran a CLEC using a LECs copper, and our circuit ID was > historically a telephone number for DSL circuits. The ILEC had a complex > method for assigning circuit IDs. I've seen a few different types over the years from ISDN to T1 to much faster services. They all have merit, but the key is to be usable and readble. Don't use both 0 and O for example, don't make case sensitive, avoid lookalikes like l and 1. I would even consider putting in a check digit if you are creating your own. > I am sure anything will work as long as you keep track of it, but any > advice would be great! - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From bill at herrin.us Mon Aug 21 21:24:48 2017 From: bill at herrin.us (William Herrin) Date: Mon, 21 Aug 2017 17:24:48 -0400 Subject: Creating a Circuit ID Format In-Reply-To: References: Message-ID: On Mon, Aug 21, 2017 at 4:26 PM, Colton Conor wrote: > We are building a new fiber network, and need help creating a circuit ID > format to for new fiber circuits. > I am sure anything will work as long as you keep track of it, but any > advice would be great! > Hi Colton, The key thing a circuit ID should inherently identify is whether or not the circuit is one of yours. Typically this is a two or three letter code in a particular position whose absence allows a tech to immediately realize that the ID the customer read out refers to something else. You might also consider putting a simple checksum in the circuit ID like the credit card companies do so that you can detect when an ID has been mis-entered. Finally, structure it with breaks (slashes, commas, spaces) so it can be read out over the phone without a high probability of error. It's easy to lose your place in a 20 digit number one digit after another after another. And when you write the database software, make sure the UI provides and accepts those breaks! Beyond that, there's no great value in not simply counting up by one. Your network's architecture will change over time so any architecture-based scheme will end up with confusing exceptions. Locality-based schemes aren't a whole lot better. Finally, there's a database principle called normalization: it means don't put the same information two places because inevitably one will end up disagreeing with the other. Put the customer's configuration (such as speed) in your database and leave it out of the circuit id. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From pozar at lns.com Mon Aug 21 23:41:38 2017 From: pozar at lns.com (Tim Pozar) Date: Mon, 21 Aug 2017 16:41:38 -0700 Subject: Creating a Circuit ID Format In-Reply-To: References: Message-ID: <2ef2a912-9223-3f7a-615b-60069e10e1d5@lns.com> Could start looking at the AT&T/Telecordia standards for this sort of thing... https://en.wikipedia.org/wiki/Circuit_ID http://www.centurylink.com/wholesale/systems/WebHelp/reference/circuit_id_formats_guide.htm On 8/21/17 1:26 PM, Colton Conor wrote: > We are building a new fiber network, and need help creating a circuit ID > format to for new fiber circuits. Is there a guide or standard for fiber > circuit formats? Does the circuit ID change when say a customer upgrades > for 100Mbps to 1Gbps port? > > What do the larger carriers do? Any advice on creating a circuit ID format > for a brand new fiber network? > > > Originally we ran a CLEC using a LECs copper, and our circuit ID was > historically a telephone number for DSL circuits. The ILEC had a complex > method for assigning circuit IDs. > > I am sure anything will work as long as you keep track of it, but any > advice would be great! > From jfmezei_nanog at vaxination.ca Tue Aug 22 05:38:37 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 22 Aug 2017 01:38:37 -0400 Subject: US/Canada International border concerns for routing In-Reply-To: References: <6FB948C4-EF91-4726-ABDD-A3B40DE99BCA@gmail.com> Message-ID: On 2017-08-09 10:11, Hiers, David wrote: > That is what our lawyers are starting to figure out, too. Very glad to see them converging on the tribal wisdom. late to discussion. You might get some organisations which require you to provide intra-canada routes for privacy reasons. But at the moment there are no laws that require it. Also, you need to consider that the way the Internet is designed, should a Montréal-Toroonto link go down, traffic will automatically reroute Montréal-New-York-Chicago-Toronto. So it becomes hard to *guarantee* intra-Canadian routes. (such arrangements do exist for military type of classified private networks). It is consumer pressure and advocacy groups who are raising the issue of intra-Canada routing. (Patriot Act in USA gets NSA to listen to any/all intl traffic, and Canada-USA-Canada traffic is considered such by USA). But from a regulatory poimt of view, the most one could expect would be a requireement to openly peer at exchanges where a netowrk has a presence. (as opposed to garanteeing intra-canada routes). And even that isn't on horizon at the moment. Note that normal businesses want to peer because it reduces costs. The old incumbents such as Bell work on a monopoly mentality of forcing people to buy transit from them, so allowing peering is against their philosophy of forcing yo to buy transit. (and if you don't buy from them, you then have to buy extra capacity to USA to connect to them). Some US transit providers, after having been here for a while, start to get their own intra-Canada links (such as Montréal to Toronto) where traffic warrants. reduced latency is likely the biggest winner in this. From jwbensley at gmail.com Tue Aug 22 07:24:15 2017 From: jwbensley at gmail.com (James Bensley) Date: Tue, 22 Aug 2017 08:24:15 +0100 Subject: Creating a Circuit ID Format In-Reply-To: References: Message-ID: On 21 August 2017 at 21:26, Colton Conor wrote: > We are building a new fiber network, and need help creating a circuit ID > format to for new fiber circuits. Is there a guide or standard for fiber > circuit formats? Does the circuit ID change when say a customer upgrades > for 100Mbps to 1Gbps port? > > What do the larger carriers do? Any advice on creating a circuit ID format > for a brand new fiber network? > > > Originally we ran a CLEC using a LECs copper, and our circuit ID was > historically a telephone number for DSL circuits. The ILEC had a complex > method for assigning circuit IDs. > > I am sure anything will work as long as you keep track of it, but any > advice would be great! In my opinion the circuit ID should be an abitrary (but unique) value and nothing more. As Nick suggested start at 1 and go up. If your company is called ABC Ltd then maybe have your first circuit ID as ABC00000001 and count up from there, it's as simple as that. For me, all the circuit ID should be is a record number/ID of a database entry and nothing more (or a search string). Some people like to have circuit IDs which include circuit types, or circuit speeds, or interface type, but as you asked, do you then change the circuit ID if the circuit speed changes, or the interface types changes, or the medium etc? No, it's just a pointer to a database record, KISS. Cheers, James. From jwbensley at gmail.com Tue Aug 22 07:31:52 2017 From: jwbensley at gmail.com (James Bensley) Date: Tue, 22 Aug 2017 08:31:52 +0100 Subject: Virtual or Remote Peering In-Reply-To: References: Message-ID: On 15 August 2017 at 15:52, Rod Beck wrote: > How well does this service work? I understand it usually involves point-to-multipoint Switched Ethernet with VLANs and resold IX ports. Sounds like a service for ISP that would like to peer, but have relatively small volumes for peering purposes or lopsided volumes. > > > Roderick Beck > > Director of Global Sales > > United Cable Company > > DRG Undersea Consulting > > Affiliate Member > > www.unitedcablecompany.com > > 85 Király utca, 1077 Budapest > > rod.beck at unitedcablecompany.com > > 36-30-859-5144 > > > [1467221477350_image005.png] I think for very samll providers were cost pretty much governs everything, it is quite handy. I know of a small provider who takes/took a 1G pipe to such a remote connectivity provider, the pipe is split with VLANs and over one VLAN they have a remote peering session to a IXP, over another VLAN they receive a blended transit service and over another VLAN L2 connectivity to other PoP the remote peering provider is also. It is several eggs in one basket but for very small providers this can provide a much needed money saving opportunity. Cheers, James. From jwbensley at gmail.com Tue Aug 22 08:18:02 2017 From: jwbensley at gmail.com (James Bensley) Date: Tue, 22 Aug 2017 09:18:02 +0100 Subject: DevOps workflow for networking In-Reply-To: References: Message-ID: On 10 August 2017 at 01:52, Kasper Adel wrote: > We are pretty new to those new-age network orchestrators and automation, > > I am curious to ask what everyone is the community is doing? sorry for such > a long and broad question. > > What is your workflow? What tools are your teams using? What is working > what is not? What do you really like and what do you need to improve? How > mature do you think your process is? etc etc The wheels here move extremely slowly so it's slowly, slowly catchy monkey for us. So far we have been using Ansible and GitLab CI and the current plan is to slowly engulf the existing network device by device into the process/toolset. > Wanted to ask and see what approaches the many different teams here are > taking! > > We are going to start working from a GitLab based workflow. > > Projects are created, issues entered and developed with a gitflow branching > strategy. > > GitLab CI pipelines run package loadings and run tests inside a lab. Yes that is the "joy" of GitLab, see below for a more detailed breakdown but we use docker images to run CI processes, we can branch and make merge requests which trigger the CI and CD processes. It's not very complicated and it just works. I didn't compare with stuff like BitBucket, I must admit I just looked at GitLab and saw that it worked, tried it, stuck with it, no problems so far. > Tests are usually python unit tests that are run to do both functional and > service creation, modification and removal tests. > > For unit testing we typically use python libraries to open transactions to > do the service modifications (along with functional tests) against physical > lab devices. Again see below, physical and virtual devices, and also some custom python scripts for unit tests like checking IPv4/6 addresses are valid (not 999.1.2.3 or AA:BB:HH::1), AS numbers are valid integeters of the right size etc. > For our prod deployment we leverage 'push on green' and gating to push > package changes to prod devices. > > Thanks Yeah that is pretty much my approach too. Device configs are in YAML files (actually multiple files). So one git repo stores the constituent YAML files, when you update a file and push to the repo the CI process starts which runs syntax checks and semantic checks against the YAML files (some custom python scripts basically). As Saku mentioned, we also follow the “replace entire device config” approach to guarantee the configuration state (or at least “try” when it comes to crazy old IOS). So this means we have Jinja2 templates that render YAML files into device specific CLI config files. They live in a separate repo and again many constituent Jinaj2 files make one entire device template. So any push to this Jinja2 repo triggers a separate CI workflow which performs syntax checking and semantic checking of the Jinja2 templates (again, custom Python scripts). When one pushes to the YAML repo to update a device config, the syntax and semantic checks are made against the YAML files; they are then “glued” together to make the entire device configs in a single file, the Jinja2 repo is checked out, the entire YAML file is used to feed the Jinja templates and configs are built and now the vendor specific config needs to be syntax checked. This CD part of the process (to a testing area) is a WIP still, for Junos we can push to a device and use “commit check” for IOS and others we can’t. So right now I’m working on a mixture of pushing the config to virtual IOS devices and to physical kit in the lab but this also causes problems in that interface / line card slot numbers/names will change so we need to run a few regex statements against the config to jimmy it into a lab device (so pretty ugly and temporary I hope). When the CD to “testing” passes then CD to “production” can be manually triggered. Another repo stores the running config of all devices (from the previous push). So we can push the candidate config to a live device (using Ansible with NAPALM [1]) and get a diff against the running config, make the “config replace” action, then download the running config and put that back into the repo. So we have a local stored copy of device configs so we can see off-line the diff’s between pushes. It also provides a record that the process of going form YAML > Jinaj2 > to device produces the config we expected (although prior to this one will have had to make a branch and then a merge request, which is peer reviewed, to get the CD part to run and push to device, so there shouldn’t be any surprises this late in the process!). Is it fool proof, no. It is a young system still being design and developed. Is it better than before, hell yes. Cheers, James. [1] Ansible and NAPALM here might seem like overkill but we use Ansible for other stuff like x86 box management so this means configuring a server or a router is abstracted through one single tool to the operator (i.e. playbooks are use irrelevant of device type, rather than say playbooks for servers but python scripts for firewalls). Also we use YAML files as config files for x86 boxes also living in GitLab with a CI/CD process so again, one set of tools for all. From achatz at forthnet.gr Tue Aug 22 16:01:56 2017 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Tue, 22 Aug 2017 19:01:56 +0300 Subject: Creating a Circuit ID Format In-Reply-To: References: Message-ID: <6b76d308-1a55-af42-c7cd-195d77147a3b@forthnet.gr> I don't know if it has any relation to your issue, but we use Circuit-ID to uniquely identify the access node plus the customer's access loop logical port on the access node. Access node can be either a DSLAM, a switch, an OLT, etc. You may have a look at BBF's TR-101 (section 3.9.3) or TR-156 (section 5.7) for syntax guide . -- Tassos Colton Conor wrote on 21/8/17 23:26: > We are building a new fiber network, and need help creating a circuit ID > format to for new fiber circuits. Is there a guide or standard for fiber > circuit formats? Does the circuit ID change when say a customer upgrades > for 100Mbps to 1Gbps port? > > What do the larger carriers do? Any advice on creating a circuit ID format > for a brand new fiber network? > > > Originally we ran a CLEC using a LECs copper, and our circuit ID was > historically a telephone number for DSL circuits. The ILEC had a complex > method for assigning circuit IDs. > > I am sure anything will work as long as you keep track of it, but any > advice would be great! > From jared at puck.nether.net Tue Aug 22 16:37:08 2017 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 22 Aug 2017 12:37:08 -0400 Subject: Creating a Circuit ID Format In-Reply-To: <6b76d308-1a55-af42-c7cd-195d77147a3b@forthnet.gr> References: <6b76d308-1a55-af42-c7cd-195d77147a3b@forthnet.gr> Message-ID: <2AF810AB-E963-4CD4-867C-3D96B73A4C8C@puck.nether.net> > On Aug 22, 2017, at 12:01 PM, Tassos Chatzithomaoglou wrote: > > I don't know if it has any relation to your issue, but we use Circuit-ID to uniquely identify the access node plus the customer's access loop logical port on the access node. > Access node can be either a DSLAM, a switch, an OLT, etc. > > You may have a look at BBF's TR-101 (section 3.9.3) or TR-156 (section 5.7) for syntax guide . My favorite circuit-ids were those from MFS where it had the service type (2 chars i think) + a pop-code + z pop-code + service count number. We could then tell what pop/facility everything was handed off at easily enough. I think my house even got a MFS pop code at one time due to the T1 which was there. - Jared From dave at temk.in Tue Aug 22 17:21:32 2017 From: dave at temk.in (Dave Temkin) Date: Tue, 22 Aug 2017 10:21:32 -0700 Subject: 2017 NANOG Elections General Information Message-ID: Hello NANOGers! We are once again approaching the annual NANOG election and appointment time. Board candidate nominations open August 7th and the complete Election timeline can be found here . We encourage those in the community who are not currently NANOG members to consider becoming members of NANOG and to consider standing for a position in our leadership. Through membership and voting, you will be an active participant in directing all NANOG activities. Only NANOG members are eligible to nominate, be a candidate, vote, and serve in the NANOG Board of Directors and Committees. Click here to become a member today! **If you are not a member and wish to vote in this election, your membership must be received by 9:00 a.m. Pacific Time on Wednesday, October 4, 2017.** Why? NANOG is at its strongest and best when there is an engaged group of members. If you care about NANOG and would like to take a turn at volunteering your time, please consider becoming part of the team by taking part in the nomination and election process. If you know someone else that you believe would be interested in serving on the Board of Directors, nominate them by completing the Online Process beginning August 7, 2017. Any questions should be submitted to elections at nanog.org. As I spoke about during my opening at NANOG 70, diversity is key to the viability of the NANOG community. Personally, it concerns me that our only non-white, non-male elected member of the Board is leaving the board this year, having served the maximum allowable number of terms. While everyone is welcome, it is important that we represent our community well at all levels and so if you or someone you know could help improve that representation, please consider the nomination process. As NANOG continues to evolve, our Board of Directors and Committees will continue to play an increasingly important role in our success. By joining now, you can be an integral part of the process. For more information about the role of a Board of Director or any Committee Member, or to find out more about what's involved in serving, please consult the current NANOG Bylaws or follow the links to the Board and Committee pages from the General 2017 NANOG Elections Page . Best regards, Dave Temkin On behalf of the NANOG Board of Directors From streinerj at gmail.com Tue Aug 22 20:50:40 2017 From: streinerj at gmail.com (Justin M. Streiner) Date: Tue, 22 Aug 2017 16:50:40 -0400 (EDT) Subject: Creating a Circuit ID Format In-Reply-To: References: Message-ID: On Tue, 22 Aug 2017, James Bensley wrote: > In my opinion the circuit ID should be an abitrary (but unique) value > and nothing more. As Nick suggested start at 1 and go up. If your > company is called ABC Ltd then maybe have your first circuit ID as > ABC00000001 and count up from there, it's as simple as that. > > For me, all the circuit ID should be is a record number/ID of a > database entry and nothing more (or a search string). Some people like > to have circuit IDs which include circuit types, or circuit speeds, or > interface type, but as you asked, do you then change the circuit ID if > the circuit speed changes, or the interface types changes, or the > medium etc? Agreed. I designed something similar at a previous employer, and it just used a date-coded ID with sequence number (ex: UOP 20170822.0001), and then all of the cross-connect details were recorded in a place that was better suited to capturing that sort of information. That would also allow us to re-use fiber paths when we upgraded 1G links to 10G, etc. This also included IDs that could reference other circuit IDs - including circuit IDs from other providers - so we could tie non-dark elements together, such as waves through DWDM gear end up riding on separate dark fiber paths on either side of the mux. The biggest obstacle was getting people to label fiber jumpers in the field, but that obstacle went away as people get a better understanding of it and having all of the cross-connects documented saved lots of time and frustration when having to search through a large patch field at 3 AM... jms From nick at foobar.org Tue Aug 22 21:20:20 2017 From: nick at foobar.org (Nick Hilliard) Date: Tue, 22 Aug 2017 22:20:20 +0100 Subject: Creating a Circuit ID Format In-Reply-To: References: Message-ID: <599CA014.5020704@foobar.org> James Bensley wrote: > In my opinion the circuit ID should be an abitrary (but unique) value > and nothing more. As Nick suggested start at 1 and go up. If your > company is called ABC Ltd then maybe have your first circuit ID as > ABC00000001 and count up from there, it's as simple as that. there are a lot of ways of handling this, which broadly speaking break down into whether you want to encode data in your circuit ID or whether you want it to act as nothing more than an index on a database table. Regardless of what way you go about things, there are some parallel issues, including whether you want inline checksumming, whether you want random value increases or +1 increases, and whether you want an alphanumeric or strictly numeric ID. Alphanumeric can allow unique prefixes or suffixes to help identify who owns a circuit ID or what type it is, at the complexity of adding identifiers which can be misinterpreted over the phone. There are differing opinions on whether other information such as service type, node location, speed, etc should be encoded in the service name. Things that most people generally agree on include: - carefully splitting out service types. E.g. a fibre cable to a location is one ID; a wavelength on that service is another ID of another type; an IP transit service on that wave is a third ID, etc. - don't reuse IDs, ever. There are plenty of numbers out there. - don't change from one ID mechanism to another, if possible. Otherwise, for every well-reasoned suggestion to use a specific format, there are other well-reasoned arguments to do things in a different way. Choose one and stick with it. Nick From trelane at trelane.net Wed Aug 23 01:44:24 2017 From: trelane at trelane.net (Andrew Kirch) Date: Tue, 22 Aug 2017 21:44:24 -0400 Subject: Spectrum web cache engineer Message-ID: Would a Spectrum engineer please contact me off list? It appears you're caching an expired certificate for https://www.icei.org. The issue is tested/working everywhere else. Thanks! Andrew From timothy at creswick.eu Wed Aug 23 08:18:52 2017 From: timothy at creswick.eu (Timothy Creswick) Date: Wed, 23 Aug 2017 08:18:52 +0000 Subject: Creating a Circuit ID Format In-Reply-To: <599CA014.5020704@foobar.org> References: <599CA014.5020704@foobar.org> Message-ID: > Things that most people generally agree on include: > > - carefully splitting out service types. E.g. a fibre cable to a > location is one ID; a wavelength on that service is another ID of > another type; an IP transit service on that wave is a third ID, etc. Definitely. We have one digit in our circuit ID which denotes the type to aid with quick identification. We also use a luhn-10 checksum digit at the end, which is optional on re-entry. This is really helpful when getting references over the phone. When written, it's with a hyphen so that it's clear that it's able to be dropped. A few things we also decided on: - Circuit references are purely numerical (although we prefix them with letters when written, those letters are not part of what makes the numbers unique in our business). The main reason for this is that they can easily be entered in a variety of *compact* barcode formats. Most label printers support this, and it saves loads of time in the datacentre when you can just scan the label on a circuit on a handheld PC. - Circuit references are always the same length. This way, if the checksum digit is being dropped (e.g. because it's coming from a non-human source like a barcode), we know that the checksum digit is missing. - The first digit is never a zero, to avoid silly mistakes if you're sorting them in Excel etc. - The first four digits are a simple date code of YYMM that the ID was generated. This is surprisingly handy when you're looking for a specific circuit reference in a list, and it sort of helps to spread the dataset out a bit. This is what ensures that it's a non-zero first digit for the next 80 years or so. The date code isn't a *requirement* of our format, however. Should we need more than 10,000 circuits per month, we'll just abandon the date coding. For those interested, our system looks like this: VCI-150600019-7 Any non [0-9] characters (including symbols) can be omitted. VCI : denotes that this circuit identifier corresponds to our business 1506 : date code 0001 : sequence number, incremented per circuit, per month 9 : circuit type 7 : checksum (optional) T From ilissa at imillerpr.com Wed Aug 23 13:57:08 2017 From: ilissa at imillerpr.com (Ilissa Miller) Date: Wed, 23 Aug 2017 09:57:08 -0400 Subject: Urgent CISCO WebEX Tech Support Request Message-ID: Hoping a Cisco WebEx Tech Support Expert can contact me offline ASAP on an urgent matter. Thank you. Before 10:45am ET today please. Thank you. -- *Ilissa Miller* CEO, *iMiller Public Relations* www.imillerpr.com email: ilissa at imillerpr.com From Jacques.Latour at cira.ca Wed Aug 23 14:08:05 2017 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Wed, 23 Aug 2017 14:08:05 +0000 Subject: Call for Participation -- ICANN DNSSEC Workshop at ICANN60 in Abu Dhabi, UAE Message-ID: <8937a2cf346144bbaa0e85c0f207572b@cira.ca> Call for Participation -- ICANN DNSSEC Workshop at ICANN60 in Abu Dhabi, UAE The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop during the ICANN60 meeting held from 01 November 2017 in Abu Dhabi, UAE tentatively from 0900-1500 local time. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN Policy Forum in Johannesburg, South Africa. The presentations and transcripts are available at: https://schedule.icann.org/event/B3zi/dnssec-workshop[schedule.icann.org]. At ICANN60 we are particularly interested in live demonstrations of uses of DNSSEC or DANE. Examples might include: * Innovative uses of APIs to do something new and different using DNSSEC/DANE. * Email clients and servers using DNSSEC, OPENPGPKEY, or S/MIME for secure email. * DNSSEC automation and deployment using CDS, CDNSKey, and CSYNC. * DNSSEC signing solutions and innovation. * Tools for automating the generation of DNSSEC/DANE records. * Services for monitoring or managing DNSSEC signing or validation. * Tools or services for using DNSSEC/DANE along with other existing protocols and services such as SSH, XMPP, SMTP, S/MIME or PGP/GPG. Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation can be used to increase the overall security of the Internet. We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE. Examples of the types of topics we are seeking include: 1. DNSSEC activities in the Middle East Region For this panel we are seeking participation from those who have been involved in DNSSEC deployment in the region and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions: Are you interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do for you? What doesn't it do? What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers. 2. Impact and Results of Root Key Rollover Following the Root Key Rollover, we would like to bring together a panel of people who can talk about the impacts to ISPs, equipment providers and end users, and also what was done to mitigate those issues. In particular, we are seeking participation from vendors, ISPs, and the community that may have been affected by distribution of new root keys. you have a specific concern about the Root Key Rollover we would like to hear from you. 3. Implementing next generation DNSSEC signing at Registries and DNS Operators Now that DNSSEC technology has matured many Registries and DNS Operators have upgraded their legacy DNSSEC signing services with innovative solutions. * Real world use cases of HSMs and key management. * Signing at the edge We would be interested in seeing presentations or demonstrations on those topics. 4. The operational realities of running DNSSEC Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What is the best practice around your local key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? What operational statistics have we gathered about DNSSEC? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones? 5. DANE and DNSSEC application automation For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as: * How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet? * What tools, systems and services are available to help automate DNSSEC key management? * Can you provide an analysis of current tools/services and identify gaps? * What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries? * What tools and services are now available that can support DANE usage? We would be particularly interested in any live demonstrations of DNSSEC / DANE application automation and services. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome. 6. DNSSEC and DANE in the enterprise and in the enterprise tool set Enterprises and enterprise software can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the domains owned by the enterprise. We are seeking presentations from enterprises and enterprise software providers that have implemented DNSSEC on validation and/or signing processes and can address questions such as: * What enterprise software support or plan do you have to support DNSSEC? * What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so? * What are the challenges to deployment for these organizations and how could DANE and other DNSSEC applications address those challenges? * How should an enterprise best prepare its IT staff and network to implement DNSSEC? * What enterprise tools and systems are available to assist enterprises in the deployment of DNSSEC? * How can the DANE protocol be used within an enterprise to bring a higher level of security to transactions using SSL/TLS certificates? 7. Implementing DNSSEC validation at Internet Service Providers (ISPs) Internet Service Providers (ISPs) play a critical role by enabling DNSSEC validation for the caching DNS resolvers used by their customers. We have now seen massive rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world. We are interested in presentations on topics such as: * Can you describe your experiences with negative Trust Anchors and operational realities? * What does an ISP need to do to prepare its network for implementing DNSSEC validation? * How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation? * Can you provide results and/or impacts of the impact of root key rollover? * What rollover technique do you use, i.e., RFC 5011 or other? In addition, we welcome suggestions for additional topics. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-abudhabi at isoc.org by **08 September 2017** We hope that you can join us. Thank you, Julie Hedlund On behalf of the DNSSEC Workshop Program Committee: Jean Robert Hountomey, AfricaCERT Jacques Latour, .CA Xiaodong Lee, CNNIC Russ Mundy, Parsons Ondřej Filip, CZ.NIC Yoshiro Yoneya, JPRS Dan York, Internet Society Mark Elkins, DNS/ZACR From listas at kurtkraut.net Wed Aug 23 14:08:31 2017 From: listas at kurtkraut.net (Kurt Kraut) Date: Wed, 23 Aug 2017 11:08:31 -0300 Subject: How can I obtain the abuse e-mail address for IPs from Japan? Message-ID: Hello, I'm having a hard time to figure out the abuse e-mail address for IPs from Japan. Any query I perform at the WHOIS, for any IP, from any autonomoyus system I get the same e-mail addresses: abuse at apnic.net hm-changed at apnic.net ip-apnic at nic.ad.jp hostmaster at nic.ad.jp These e-mail addresses belong to JPNIC, not the autonomous system itself. So any messages sent to these e-mail addresses will not reach the offending NOC/SOC so I can report vulnerabilities and DDoS attacks. What am I missing and how should I report security issues to autonomous systems from this region? Has anyone here any experience on this? Thanks in advance, Kurt Kraut From ops.lists at gmail.com Wed Aug 23 14:55:16 2017 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 23 Aug 2017 20:25:16 +0530 Subject: How can I obtain the abuse e-mail address for IPs from Japan? In-Reply-To: References: Message-ID: whois -h whois.nic.ad.jp IP /e --srs > On 23-Aug-2017, at 7:38 PM, Kurt Kraut wrote: > > Hello, > > > I'm having a hard time to figure out the abuse e-mail address for IPs from > Japan. Any query I perform at the WHOIS, for any IP, from any autonomoyus > system I get the same e-mail addresses: > > abuse at apnic.net > hm-changed at apnic.net > ip-apnic at nic.ad.jp > hostmaster at nic.ad.jp > > These e-mail addresses belong to JPNIC, not the autonomous system itself. > So any messages sent to these e-mail addresses will not reach the offending > NOC/SOC so I can report vulnerabilities and DDoS attacks. > > What am I missing and how should I report security issues to autonomous > systems from this region? Has anyone here any experience on this? > > > Thanks in advance, > > > Kurt Kraut From listas at kurtkraut.net Wed Aug 23 15:16:05 2017 From: listas at kurtkraut.net (Kurt Kraut) Date: Wed, 23 Aug 2017 12:16:05 -0300 Subject: How can I obtain the abuse e-mail address for IPs from Japan? In-Reply-To: References: Message-ID: Hello Suresh, It doesn't seem to help a lot: ktk at ktk:~$ whois -h whois.nic.ad.jp 59.106.13.181 [ JPNIC database provides information regarding IP address and ASN. Its use ] [ is restricted to network administration purposes. For further information, ] [ use 'whois -h whois.nic.ad.jp help'. To only display English output, ] [ add '/e' at the end of command, e.g. 'whois -h whois.nic.ad.jp xxx/e'. ] Network Information: a. [Network Number] 59.106.12.0-59.106.27.255 b. [Network Name] SAKURA-NET g. [Organization] SAKURA Internet Inc. m. [Administrative Contact] KT749JP n. [Technical Contact] KW419JP p. [Nameserver] ns1.dns.ne.jp p. [Nameserver] ns2.dns.ne.jp [Assigned Date] 2004/11/24 [Return Date] [Last Update] 2004/11/24 18:41:02(JST) Less Specific Info. ---------- SAKURA Internet Inc. [Allocation] 59.106.0.0/16 More Specific Info. No e-mail addresses of the abuse team or NOC or SOC. Best regards, Kurt Kraut 2017-08-23 11:55 GMT-03:00 Suresh Ramasubramanian : > whois -h whois.nic.ad.jp IP /e > > --srs > > > On 23-Aug-2017, at 7:38 PM, Kurt Kraut wrote: > > > > Hello, > > > > > > I'm having a hard time to figure out the abuse e-mail address for IPs > from > > Japan. Any query I perform at the WHOIS, for any IP, from any autonomoyus > > system I get the same e-mail addresses: > > > > abuse at apnic.net > > hm-changed at apnic.net > > ip-apnic at nic.ad.jp > > hostmaster at nic.ad.jp > > > > These e-mail addresses belong to JPNIC, not the autonomous system itself. > > So any messages sent to these e-mail addresses will not reach the > offending > > NOC/SOC so I can report vulnerabilities and DDoS attacks. > > > > What am I missing and how should I report security issues to autonomous > > systems from this region? Has anyone here any experience on this? > > > > > > Thanks in advance, > > > > > > Kurt Kraut > From streinerj at gmail.com Wed Aug 23 15:43:49 2017 From: streinerj at gmail.com (Justin M. Streiner) Date: Wed, 23 Aug 2017 11:43:49 -0400 (EDT) Subject: How can I obtain the abuse e-mail address for IPs from Japan? In-Reply-To: References: Message-ID: On Wed, 23 Aug 2017, Kurt Kraut wrote: > Network Information: > a. [Network Number] 59.106.12.0-59.106.27.255 > b. [Network Name] SAKURA-NET > g. [Organization] SAKURA Internet Inc. > m. [Administrative Contact] KT749JP > n. [Technical Contact] KW419JP > > No e-mail addresses of the abuse team or NOC or SOC. Since they don't have an abuse contact and there's not much additional useful contact information in their peeringdb entry, your next best bet would be to reach out to the admin and technical contacts listed in their whois record, or try the abuse contacts for one or more of their upstreams. jms From lathama at gmail.com Wed Aug 23 15:52:38 2017 From: lathama at gmail.com (Andrew Latham) Date: Wed, 23 Aug 2017 10:52:38 -0500 Subject: How can I obtain the abuse e-mail address for IPs from Japan? In-Reply-To: References: Message-ID: Kurt I see contact info for KW419JP maybe I don't understand what you are looking for. On Wed, Aug 23, 2017 at 10:16 AM, Kurt Kraut wrote: > Hello Suresh, > > > It doesn't seem to help a lot: > > ktk at ktk:~$ whois -h whois.nic.ad.jp 59.106.13.181 > [ JPNIC database provides information regarding IP address and ASN. Its use > ] > [ is restricted to network administration purposes. For further > information, ] > [ use 'whois -h whois.nic.ad.jp help'. To only display English output, > ] > [ add '/e' at the end of command, e.g. 'whois -h whois.nic.ad.jp xxx/e'. > ] > > Network Information: > a. [Network Number] 59.106.12.0-59.106.27.255 > b. [Network Name] SAKURA-NET > g. [Organization] SAKURA Internet Inc. > m. [Administrative Contact] KT749JP > n. [Technical Contact] KW419JP > p. [Nameserver] ns1.dns.ne.jp > p. [Nameserver] ns2.dns.ne.jp > [Assigned Date] 2004/11/24 > [Return Date] > [Last Update] 2004/11/24 18:41:02(JST) > > Less Specific Info. > ---------- > SAKURA Internet Inc. > [Allocation] > 59.106.0.0/16 > > More Specific Info. > > > > No e-mail addresses of the abuse team or NOC or SOC. > > > Best regards, > > > Kurt Kraut > > 2017-08-23 11:55 GMT-03:00 Suresh Ramasubramanian : > > > whois -h whois.nic.ad.jp IP /e > > > > --srs > > > > > On 23-Aug-2017, at 7:38 PM, Kurt Kraut wrote: > > > > > > Hello, > > > > > > > > > I'm having a hard time to figure out the abuse e-mail address for IPs > > from > > > Japan. Any query I perform at the WHOIS, for any IP, from any > autonomoyus > > > system I get the same e-mail addresses: > > > > > > abuse at apnic.net > > > hm-changed at apnic.net > > > ip-apnic at nic.ad.jp > > > hostmaster at nic.ad.jp > > > > > > These e-mail addresses belong to JPNIC, not the autonomous system > itself. > > > So any messages sent to these e-mail addresses will not reach the > > offending > > > NOC/SOC so I can report vulnerabilities and DDoS attacks. > > > > > > What am I missing and how should I report security issues to autonomous > > > systems from this region? Has anyone here any experience on this? > > > > > > > > > Thanks in advance, > > > > > > > > > Kurt Kraut > > > -- - Andrew "lathama" Latham - From listas at kurtkraut.net Wed Aug 23 15:58:36 2017 From: listas at kurtkraut.net (Kurt Kraut) Date: Wed, 23 Aug 2017 12:58:36 -0300 Subject: How can I obtain the abuse e-mail address for IPs from Japan? In-Reply-To: References: Message-ID: Hello folks, Thank you for your assistance. I'm used to query AS entries for LACNIC region and their WHOIS spit out righ away all contacts. I didn't realise I had to make a secondary query for the Technical Contact ID to only then see the e-mail address. Best regards, Kurt Kraut 2017-08-23 12:52 GMT-03:00 Andrew Latham : > Kurt > > I see contact info for KW419JP maybe I don't understand what you are > looking for. > > On Wed, Aug 23, 2017 at 10:16 AM, Kurt Kraut wrote: > >> Hello Suresh, >> >> >> It doesn't seem to help a lot: >> >> ktk at ktk:~$ whois -h whois.nic.ad.jp 59.106.13.181 >> [ JPNIC database provides information regarding IP address and ASN. Its >> use >> ] >> [ is restricted to network administration purposes. For further >> information, ] >> [ use 'whois -h whois.nic.ad.jp help'. To only display English output, >> ] >> [ add '/e' at the end of command, e.g. 'whois -h whois.nic.ad.jp xxx/e'. >> ] >> >> Network Information: >> a. [Network Number] 59.106.12.0-59.106.27.255 >> b. [Network Name] SAKURA-NET >> g. [Organization] SAKURA Internet Inc. >> m. [Administrative Contact] KT749JP >> n. [Technical Contact] KW419JP >> p. [Nameserver] ns1.dns.ne.jp >> p. [Nameserver] ns2.dns.ne.jp >> [Assigned Date] 2004/11/24 >> [Return Date] >> [Last Update] 2004/11/24 18:41:02(JST) >> >> Less Specific Info. >> ---------- >> SAKURA Internet Inc. >> [Allocation] >> 59.106.0.0/16 >> >> More Specific Info. >> >> >> >> No e-mail addresses of the abuse team or NOC or SOC. >> >> >> Best regards, >> >> >> Kurt Kraut >> >> 2017-08-23 11:55 GMT-03:00 Suresh Ramasubramanian : >> >> > whois -h whois.nic.ad.jp IP /e >> > >> > --srs >> > >> > > On 23-Aug-2017, at 7:38 PM, Kurt Kraut wrote: >> > > >> > > Hello, >> > > >> > > >> > > I'm having a hard time to figure out the abuse e-mail address for IPs >> > from >> > > Japan. Any query I perform at the WHOIS, for any IP, from any >> autonomoyus >> > > system I get the same e-mail addresses: >> > > >> > > abuse at apnic.net >> > > hm-changed at apnic.net >> > > ip-apnic at nic.ad.jp >> > > hostmaster at nic.ad.jp >> > > >> > > These e-mail addresses belong to JPNIC, not the autonomous system >> itself. >> > > So any messages sent to these e-mail addresses will not reach the >> > offending >> > > NOC/SOC so I can report vulnerabilities and DDoS attacks. >> > > >> > > What am I missing and how should I report security issues to >> autonomous >> > > systems from this region? Has anyone here any experience on this? >> > > >> > > >> > > Thanks in advance, >> > > >> > > >> > > Kurt Kraut >> > >> > > > > -- > - Andrew "lathama" Latham - > From niels=nanog at bakker.net Wed Aug 23 15:59:48 2017 From: niels=nanog at bakker.net (Niels Bakker) Date: Wed, 23 Aug 2017 17:59:48 +0200 Subject: How can I obtain the abuse e-mail address for IPs from Japan? In-Reply-To: References: Message-ID: <20170823155947.GA37550@excession.tpb.net> * listas at kurtkraut.net (Kurt Kraut) [Wed 23 Aug 2017, 17:16 CEST]: >No e-mail addresses of the abuse team or NOC or SOC. | % whois 59.106.13.181 | grep support | remarks: Email address for spam or abuse complaints : support at sakura.ad.jp That's not a special whois client but is in the text returned by APNIC. note that whois.nic.ad.jp does not, unlike RIPE whois, automatically also include person objects referenced in an inetnum object, so you will have to query for those separately, as another poster pointed out. -- Niels. From johnl at iecc.com Wed Aug 23 20:03:29 2017 From: johnl at iecc.com (John Levine) Date: 23 Aug 2017 20:03:29 -0000 Subject: How can I obtain the abuse e-mail address for IPs from Japan? In-Reply-To: Message-ID: <20170823200329.18814.qmail@ary.lan> In article you write: >Thank you for your assistance. I'm used to query AS entries for LACNIC >region and their WHOIS spit out righ away all contacts. I didn't realise I >had to make a secondary query for the Technical Contact ID to only then see >the e-mail address. If you do write to Japanese network contacts, expect a very polite response saying that they can't deal with your report because they're too scared to open attachments. R's, John From ESundberg at nitelusa.com Wed Aug 23 20:09:49 2017 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Wed, 23 Aug 2017 20:09:49 +0000 Subject: Google DNS --- Figuring out which DNS Cluster you are using Message-ID: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> I sent this out on the outage list, with a lots of good feedback sent to me. So I figured it would be useful to share the information on nanog as well. A couple months ago had to troubleshoot a google DNS issue with Google’s NOC. Below is some helpful information on how to determine which DNS Cluster you are going to. Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 and 8.8.4.4. Anycast routes your DNS queries to the closes DNS cluster based on the best route / lowest metric to 8.8.8.8/8.8.4.4. Google has deployed multiple DNS clusters across the world and each DNS Cluster has multiple servers. So a DNS query in Chicago will go to a different DNS clusters than queries from a device in Atlanta or New York. How to get a list of google DNS Cluster’s. dig -t TXT +short locations.publicdns.goog. @8.8.8.8 How to print this list in a table format. Script from: https://developers.google.com/speed/public-dns/faq --------------- #!/bin/bash IFS="\"$IFS" for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8) do case $LOC in '') : ;; *.*|*:*) printf '%s ' ${LOC} ;; *) printf '%s\n' ${LOC} ;; esac done --------------- Which will give you a list like below. This is all of the IP network’s that google uses for their DNS Clusters and their associated locations. 74.125.18.0/26 iad 74.125.18.64/26 iad 74.125.18.128/26 syd 74.125.18.192/26 lhr 74.125.19.0/24 mrn 74.125.41.0/24 tpe 74.125.42.0/24 atl 74.125.44.0/24 mrn 74.125.45.0/24 tul 74.125.46.0/24 lpp 74.125.47.0/24 bru 74.125.72.0/24 cbf 74.125.73.0/24 bru 74.125.74.0/24 lpp 74.125.75.0/24 chs 74.125.76.0/24 cbf 74.125.77.0/24 chs 74.125.79.0/24 lpp 74.125.80.0/24 dls 74.125.81.0/24 dub 74.125.92.0/24 mrn 74.125.93.0/24 cbf 74.125.112.0/24 lpp 74.125.113.0/24 cbf 74.125.115.0/24 tul 74.125.176.0/24 mrn 74.125.177.0/24 atl 74.125.179.0/24 cbf 74.125.181.0/24 bru 74.125.182.0/24 cbf 74.125.183.0/24 cbf 74.125.184.0/24 chs 74.125.186.0/24 dls 74.125.187.0/24 dls 74.125.190.0/24 sin 74.125.191.0/24 tul 172.217.32.0/26 lhr 172.217.32.64/26 lhr 172.217.32.128/26 sin 172.217.33.0/26 syd 172.217.33.64/26 syd 172.217.33.128/26 fra 172.217.33.192/26 fra 172.217.34.0/26 fra 172.217.34.64/26 bom 172.217.34.192/26 bom 172.217.35.0/24 gru 172.217.36.0/24 atl 172.217.37.0/24 gru 173.194.90.0/24 cbf 173.194.91.0/24 scl 173.194.93.0/24 tpe 173.194.94.0/24 cbf 173.194.95.0/24 tul 173.194.97.0/24 chs 173.194.98.0/24 lpp 173.194.99.0/24 tul 173.194.100.0/24 mrn 173.194.101.0/24 tul 173.194.102.0/24 atl 173.194.103.0/24 cbf 173.194.168.0/26 nrt 173.194.168.64/26 nrt 173.194.168.128/26 nrt 173.194.168.192/26 iad 173.194.169.0/24 grq 173.194.170.0/24 grq 173.194.171.0/24 tpe 2404:6800:4000::/48 bom 2404:6800:4003::/48 sin 2404:6800:4006::/48 syd 2404:6800:4008::/48 tpe 2404:6800:400b::/48 nrt 2607:f8b0:4001::/48 cbf 2607:f8b0:4002::/48 atl 2607:f8b0:4003::/48 tul 2607:f8b0:4004::/48 iad 2607:f8b0:400c::/48 chs 2607:f8b0:400d::/48 mrn 2607:f8b0:400e::/48 dls 2800:3f0:4001::/48 gru 2800:3f0:4003::/48 scl 2a00:1450:4001::/48 fra 2a00:1450:4009::/48 lhr 2a00:1450:400b::/48 dub 2a00:1450:400c::/48 bru 2a00:1450:4010::/48 lpp 2a00:1450:4013::/48 grq There are IPv4 Networks: 68 IPv6 Networks: 20 DNS Cluster’s Identified by POP Code’s: 20 DNS Clusters identified by POP Code to City, State, or Country. Not all of these are Google’s Core Datacenters, some of them are Edge Points of Presences (POPs). https://peering.google.com/#/infrastructure and https://www.google.com/about/datacenters/inside/locations/ Most of these are airport codes, it did my best to get the location correct. iad Washington, DC syd Sydney, Australia lhr London, UK mrn Lenoir, NC tpe Taiwan atl Altanta, GA tul Tulsa, OK lpp Findland bru Brussels, Belgium cbf Council Bluffs, IA chs Charleston, SC dls The Dalles, Oregon dub Dublin, Ireland sin Singapore fra Frankfort, Germany bom Mumbai, India gru Sao Paulo, Brazil scl Santiago, Chile nrt Tokyo, Japan grq Groningen, Netherlans Which Google DNS Server Cluster am I using. I am testing this from Chicago, IL # dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 "173.194.94.135" <<<<< References: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> Message-ID: <1968162469.886870.1503520652959@mail.yahoo.com> This is great.  Thanks for sharing .  Sent from Yahoo Mail on Android On Wed, Aug 23, 2017 at 1:11 PM, Erik Sundberg wrote: I sent this out on the outage list, with a lots of good feedback sent to me. So I figured it would be useful to share the information on nanog as well. A couple months ago had to troubleshoot a google DNS issue with Google’s NOC. Below is some helpful information on how to determine which DNS Cluster you are going to. Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 and 8.8.4.4. Anycast routes your DNS queries to the closes DNS cluster based on the best route / lowest metric to 8.8.8.8/8.8.4.4.  Google has deployed multiple DNS clusters across the world and each DNS Cluster has multiple servers. So a DNS query in Chicago will go to a different DNS clusters than queries from a device in Atlanta or New York. How to get a list of google DNS Cluster’s. dig -t TXT +short locations.publicdns.goog. @8.8.8.8 How to print this list in a table format. Script from: https://developers.google.com/speed/public-dns/faq --------------- #!/bin/bash IFS="\"$IFS" for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8) do   case $LOC in     '') : ;;     *.*|*:*) printf '%s ' ${LOC} ;;     *) printf '%s\n' ${LOC} ;;   esac done --------------- Which will give you a list like below. This is all of the IP network’s that google uses for their DNS Clusters and their associated locations. 74.125.18.0/26 iad 74.125.18.64/26 iad 74.125.18.128/26 syd 74.125.18.192/26 lhr 74.125.19.0/24 mrn 74.125.41.0/24 tpe 74.125.42.0/24 atl 74.125.44.0/24 mrn 74.125.45.0/24 tul 74.125.46.0/24 lpp 74.125.47.0/24 bru 74.125.72.0/24 cbf 74.125.73.0/24 bru 74.125.74.0/24 lpp 74.125.75.0/24 chs 74.125.76.0/24 cbf 74.125.77.0/24 chs 74.125.79.0/24 lpp 74.125.80.0/24 dls 74.125.81.0/24 dub 74.125.92.0/24 mrn 74.125.93.0/24 cbf 74.125.112.0/24 lpp 74.125.113.0/24 cbf 74.125.115.0/24 tul 74.125.176.0/24 mrn 74.125.177.0/24 atl 74.125.179.0/24 cbf 74.125.181.0/24 bru 74.125.182.0/24 cbf 74.125.183.0/24 cbf 74.125.184.0/24 chs 74.125.186.0/24 dls 74.125.187.0/24 dls 74.125.190.0/24 sin 74.125.191.0/24 tul 172.217.32.0/26 lhr 172.217.32.64/26 lhr 172.217.32.128/26 sin 172.217.33.0/26 syd 172.217.33.64/26 syd 172.217.33.128/26 fra 172.217.33.192/26 fra 172.217.34.0/26 fra 172.217.34.64/26 bom 172.217.34.192/26 bom 172.217.35.0/24 gru 172.217.36.0/24 atl 172.217.37.0/24 gru 173.194.90.0/24 cbf 173.194.91.0/24 scl 173.194.93.0/24 tpe 173.194.94.0/24 cbf 173.194.95.0/24 tul 173.194.97.0/24 chs 173.194.98.0/24 lpp 173.194.99.0/24 tul 173.194.100.0/24 mrn 173.194.101.0/24 tul 173.194.102.0/24 atl 173.194.103.0/24 cbf 173.194.168.0/26 nrt 173.194.168.64/26 nrt 173.194.168.128/26 nrt 173.194.168.192/26 iad 173.194.169.0/24 grq 173.194.170.0/24 grq 173.194.171.0/24 tpe 2404:6800:4000::/48 bom 2404:6800:4003::/48 sin 2404:6800:4006::/48 syd 2404:6800:4008::/48 tpe 2404:6800:400b::/48 nrt 2607:f8b0:4001::/48 cbf 2607:f8b0:4002::/48 atl 2607:f8b0:4003::/48 tul 2607:f8b0:4004::/48 iad 2607:f8b0:400c::/48 chs 2607:f8b0:400d::/48 mrn 2607:f8b0:400e::/48 dls 2800:3f0:4001::/48 gru 2800:3f0:4003::/48 scl 2a00:1450:4001::/48 fra 2a00:1450:4009::/48 lhr 2a00:1450:400b::/48 dub 2a00:1450:400c::/48 bru 2a00:1450:4010::/48 lpp 2a00:1450:4013::/48 grq There are IPv4 Networks: 68 IPv6 Networks: 20 DNS Cluster’s Identified by POP Code’s: 20 DNS Clusters identified by POP Code to City, State, or Country. Not all of these are Google’s Core Datacenters, some of them are Edge Points of Presences (POPs). https://peering.google.com/#/infrastructure and https://www.google.com/about/datacenters/inside/locations/ Most of these are airport codes, it did my best to get the location correct. iad          Washington, DC syd        Sydney, Australia lhr          London, UK mrn        Lenoir, NC tpe        Taiwan atl          Altanta, GA tul          Tulsa, OK lpp          Findland bru        Brussels, Belgium cbf        Council Bluffs, IA chs        Charleston, SC dls          The Dalles, Oregon dub        Dublin, Ireland sin          Singapore fra          Frankfort, Germany bom      Mumbai, India gru        Sao Paulo, Brazil scl          Santiago, Chile nrt          Tokyo, Japan grq        Groningen, Netherlans Which Google DNS Server Cluster am I using. I am testing this from Chicago, IL # dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 "173.194.94.135"                    <<<<< References: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> <1968162469.886870.1503520652959@mail.yahoo.com> Message-ID: On Wed, Aug 23, 2017 at 4:37 PM, i mawsog via NANOG wrote: > > This is great. Thanks for sharing . > > Sent from Yahoo Mail on Android > > On Wed, Aug 23, 2017 at 1:11 PM, Erik Sundberg > wrote: I sent this out on the outage list, with a lots of good feedback > sent to me. So I figured it would be useful to share the information on > nanog as well. > > > A couple months ago had to troubleshoot a google DNS issue with Google’s > NOC. Below is some helpful information on how to determine which DNS > Cluster you are going to. > > Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 and > 8.8.4.4. Anycast routes your DNS queries to the closes DNS cluster based on > the best route / lowest metric to 8.8.8.8/8.8.4.4. Google has deployed > multiple DNS clusters across the world and each DNS Cluster has multiple > servers. > > So a DNS query in Chicago will go to a different DNS clusters than queries > from a device in Atlanta or New York. > > > How to get a list of google DNS Cluster’s. > dig -t TXT +short locations.publicdns.goog. @8.8.8.8 > > How to print this list in a table format. Script from: > https://developers.google.com/speed/public-dns/faq > --------------- > #!/bin/bash > IFS="\"$IFS" > for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8) > do > case $LOC in > '') : ;; > *.*|*:*) printf '%s ' ${LOC} ;; > *) printf '%s\n' ${LOC} ;; > esac > done > --------------- > > Which will give you a list like below. This is all of the IP network’s > that google uses for their DNS Clusters and their associated locations. > > 74.125.18.0/26 iad > 74.125.18.64/26 iad > 74.125.18.128/26 syd > 74.125.18.192/26 lhr > 74.125.19.0/24 mrn > 74.125.41.0/24 tpe > 74.125.42.0/24 atl > 74.125.44.0/24 mrn > 74.125.45.0/24 tul > 74.125.46.0/24 lpp > 74.125.47.0/24 bru > 74.125.72.0/24 cbf > 74.125.73.0/24 bru > 74.125.74.0/24 lpp > 74.125.75.0/24 chs > 74.125.76.0/24 cbf > 74.125.77.0/24 chs > 74.125.79.0/24 lpp > 74.125.80.0/24 dls > 74.125.81.0/24 dub > 74.125.92.0/24 mrn > 74.125.93.0/24 cbf > 74.125.112.0/24 lpp > 74.125.113.0/24 cbf > 74.125.115.0/24 tul > 74.125.176.0/24 mrn > 74.125.177.0/24 atl > 74.125.179.0/24 cbf > 74.125.181.0/24 bru > 74.125.182.0/24 cbf > 74.125.183.0/24 cbf > 74.125.184.0/24 chs > 74.125.186.0/24 dls > 74.125.187.0/24 dls > 74.125.190.0/24 sin > 74.125.191.0/24 tul > 172.217.32.0/26 lhr > 172.217.32.64/26 lhr > 172.217.32.128/26 sin > 172.217.33.0/26 syd > 172.217.33.64/26 syd > 172.217.33.128/26 fra > 172.217.33.192/26 fra > 172.217.34.0/26 fra > 172.217.34.64/26 bom > 172.217.34.192/26 bom > 172.217.35.0/24 gru > 172.217.36.0/24 atl > 172.217.37.0/24 gru > 173.194.90.0/24 cbf > 173.194.91.0/24 scl > 173.194.93.0/24 tpe > 173.194.94.0/24 cbf > 173.194.95.0/24 tul > 173.194.97.0/24 chs > 173.194.98.0/24 lpp > 173.194.99.0/24 tul > 173.194.100.0/24 mrn > 173.194.101.0/24 tul > 173.194.102.0/24 atl > 173.194.103.0/24 cbf > 173.194.168.0/26 nrt > 173.194.168.64/26 nrt > 173.194.168.128/26 nrt > 173.194.168.192/26 iad > 173.194.169.0/24 grq > 173.194.170.0/24 grq > 173.194.171.0/24 tpe > 2404:6800:4000::/48 bom > 2404:6800:4003::/48 sin > 2404:6800:4006::/48 syd > 2404:6800:4008::/48 tpe > 2404:6800:400b::/48 nrt > 2607:f8b0:4001::/48 cbf > 2607:f8b0:4002::/48 atl > 2607:f8b0:4003::/48 tul > 2607:f8b0:4004::/48 iad > 2607:f8b0:400c::/48 chs > 2607:f8b0:400d::/48 mrn > 2607:f8b0:400e::/48 dls > 2800:3f0:4001::/48 gru > 2800:3f0:4003::/48 scl > 2a00:1450:4001::/48 fra > 2a00:1450:4009::/48 lhr > 2a00:1450:400b::/48 dub > 2a00:1450:400c::/48 bru > 2a00:1450:4010::/48 lpp > 2a00:1450:4013::/48 grq > > isn't this list also here: https://developers.google.com/speed/public-dns/faq#locations I mean, you could read the docs first to get the same answer, I think... right? I'm also pretty sure there are RIPE Atlas measurements of 8.8.8.8/8.8.4.4 that could tell you from which source-asn a backend sees traffic from.. right? (or with a tiny bit of thought one could be proposed/executed) > There are > IPv4 Networks: 68 > IPv6 Networks: 20 > DNS Cluster’s Identified by POP Code’s: 20 > > DNS Clusters identified by POP Code to City, State, or Country. Not all of > these are Google’s Core Datacenters, some of them are Edge Points of > Presences (POPs). https://peering.google.com/#/infrastructure and > https://www.google.com/about/datacenters/inside/locations/ > > Most of these are airport codes, it did my best to get the location > correct. > iad Washington, DC > syd Sydney, Australia > lhr London, UK > mrn Lenoir, NC > tpe Taiwan > atl Altanta, GA > tul Tulsa, OK > lpp Findland > bru Brussels, Belgium > cbf Council Bluffs, IA > chs Charleston, SC > dls The Dalles, Oregon > dub Dublin, Ireland > sin Singapore > fra Frankfort, Germany > bom Mumbai, India > gru Sao Paulo, Brazil > scl Santiago, Chile > nrt Tokyo, Japan > grq Groningen, Netherlans > > > > Which Google DNS Server Cluster am I using. I am testing this from > Chicago, IL > > # dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 > "173.194.94.135" <<<<< list above to get the cluster, Council Bluffs, IA > "edns0-client-subnet 207.xxx.xxx.0/24" > <<<< Your Source IP Block > > > Side note, the google dns servers will not respond to DNS queries to the > Cluster’s Member’s IP, they will only respond to dns queries to 8.8.8.8 and > 8.8.4.4. So the following will not work. > dig google.com @173.194.94.135 > > > > Now to see the DNS Cluster load balancing in action. I am doing a dig > query from our Telx\Digital Realty POP in Atlanta, GA. We do peer with > google at this location. > > I dig a dig query about 10 times and received the following unique dns > cluster member ip’s as responses. > > dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 > "74.125.42.138" > "173.194.102.132" > "74.125.177.5" > "74.125.177.74" > "74.125.177.71" > "74.125.177.4" > > Which all are Google DNS Networks in Atlanta. > 74.125.42.0/24 > > atl > > 74.125.177.0/24 > > atl > > 172.217.36.0/24 > > atl > > 173.194.102.0/24 > > atl > > 2607:f8b0:4002::/48 > > atl > > > > Just thought it would be helpful when troubleshooting google DNS issues. > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > > From morrowc.lists at gmail.com Thu Aug 24 00:39:27 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 23 Aug 2017 20:39:27 -0400 Subject: Google DNS --- Figuring out which DNS Cluster you are using In-Reply-To: References: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> <1968162469.886870.1503520652959@mail.yahoo.com> Message-ID: On Wed, Aug 23, 2017 at 8:30 PM, Joe Hamelin wrote: > Gee Chris, that's kind of an asinine response. Erik took the time to let > us know about what he had found out, with > sure, except I think the link has even been posted to nanog in the past. My point was really: it's documented, so you don't have to do the work. -chris a nice code snippet too. I don't have time in my job to just go surfing > around google.com to see what is there. His mail took me about 2 minutes > to read and now I know that such info exists. > > Thank you Erik! > > -- > Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 <(360)%20474-7474> > > On Wed, Aug 23, 2017 at 5:10 PM, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > >> On Wed, Aug 23, 2017 at 4:37 PM, i mawsog via NANOG >> wrote: >> >> > >> > This is great. Thanks for sharing . >> > >> > Sent from Yahoo Mail on Android >> > >> > On Wed, Aug 23, 2017 at 1:11 PM, Erik Sundberg> > >> > wrote: I sent this out on the outage list, with a lots of good >> feedback >> > sent to me. So I figured it would be useful to share the information on >> > nanog as well. >> > >> > >> > A couple months ago had to troubleshoot a google DNS issue with Google’s >> > NOC. Below is some helpful information on how to determine which DNS >> > Cluster you are going to. >> > >> > Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 >> and >> > 8.8.4.4. Anycast routes your DNS queries to the closes DNS cluster >> based on >> > the best route / lowest metric to 8.8.8.8/8.8.4.4. Google has deployed >> > multiple DNS clusters across the world and each DNS Cluster has multiple >> > servers. >> > >> > So a DNS query in Chicago will go to a different DNS clusters than >> queries >> > from a device in Atlanta or New York. >> > >> > >> > How to get a list of google DNS Cluster’s. >> > dig -t TXT +short locations.publicdns.goog. @8.8.8.8 >> > >> > How to print this list in a table format. Script from: >> > https://developers.google.com/speed/public-dns/faq >> > --------------- >> > #!/bin/bash >> > IFS="\"$IFS" >> > for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8) >> > do >> > case $LOC in >> > '') : ;; >> > *.*|*:*) printf '%s ' ${LOC} ;; >> > *) printf '%s\n' ${LOC} ;; >> > esac >> > done >> > --------------- >> > >> > Which will give you a list like below. This is all of the IP network’s >> > that google uses for their DNS Clusters and their associated locations. >> > >> > 74.125.18.0/26 iad >> > 74.125.18.64/26 iad >> > 74.125.18.128/26 syd >> > 74.125.18.192/26 lhr >> > 74.125.19.0/24 mrn >> > 74.125.41.0/24 tpe >> > 74.125.42.0/24 atl >> > 74.125.44.0/24 mrn >> > 74.125.45.0/24 tul >> > 74.125.46.0/24 lpp >> > 74.125.47.0/24 bru >> > 74.125.72.0/24 cbf >> > 74.125.73.0/24 bru >> > 74.125.74.0/24 lpp >> > 74.125.75.0/24 chs >> > 74.125.76.0/24 cbf >> > 74.125.77.0/24 chs >> > 74.125.79.0/24 lpp >> > 74.125.80.0/24 dls >> > 74.125.81.0/24 dub >> > 74.125.92.0/24 mrn >> > 74.125.93.0/24 cbf >> > 74.125.112.0/24 lpp >> > 74.125.113.0/24 cbf >> > 74.125.115.0/24 tul >> > 74.125.176.0/24 mrn >> > 74.125.177.0/24 atl >> > 74.125.179.0/24 cbf >> > 74.125.181.0/24 bru >> > 74.125.182.0/24 cbf >> > 74.125.183.0/24 cbf >> > 74.125.184.0/24 chs >> > 74.125.186.0/24 dls >> > 74.125.187.0/24 dls >> > 74.125.190.0/24 sin >> > 74.125.191.0/24 tul >> > 172.217.32.0/26 lhr >> > 172.217.32.64/26 lhr >> > 172.217.32.128/26 sin >> > 172.217.33.0/26 syd >> > 172.217.33.64/26 syd >> > 172.217.33.128/26 fra >> > 172.217.33.192/26 fra >> > 172.217.34.0/26 fra >> > 172.217.34.64/26 bom >> > 172.217.34.192/26 bom >> > 172.217.35.0/24 gru >> > 172.217.36.0/24 atl >> > 172.217.37.0/24 gru >> > 173.194.90.0/24 cbf >> > 173.194.91.0/24 scl >> > 173.194.93.0/24 tpe >> > 173.194.94.0/24 cbf >> > 173.194.95.0/24 tul >> > 173.194.97.0/24 chs >> > 173.194.98.0/24 lpp >> > 173.194.99.0/24 tul >> > 173.194.100.0/24 mrn >> > 173.194.101.0/24 tul >> > 173.194.102.0/24 atl >> > 173.194.103.0/24 cbf >> > 173.194.168.0/26 nrt >> > 173.194.168.64/26 nrt >> > 173.194.168.128/26 nrt >> > 173.194.168.192/26 iad >> > 173.194.169.0/24 grq >> > 173.194.170.0/24 grq >> > 173.194.171.0/24 tpe >> > 2404:6800:4000::/48 bom >> > 2404:6800:4003::/48 sin >> > 2404:6800:4006::/48 syd >> > 2404:6800:4008::/48 tpe >> > 2404:6800:400b::/48 nrt >> > 2607:f8b0:4001::/48 cbf >> > 2607:f8b0:4002::/48 atl >> > 2607:f8b0:4003::/48 tul >> > 2607:f8b0:4004::/48 iad >> > 2607:f8b0:400c::/48 chs >> > 2607:f8b0:400d::/48 mrn >> > 2607:f8b0:400e::/48 dls >> > 2800:3f0:4001::/48 gru >> > 2800:3f0:4003::/48 scl >> > 2a00:1450:4001::/48 fra >> > 2a00:1450:4009::/48 lhr >> > 2a00:1450:400b::/48 dub >> > 2a00:1450:400c::/48 bru >> > 2a00:1450:4010::/48 lpp >> > 2a00:1450:4013::/48 grq >> > >> > >> isn't this list also here: >> https://developers.google.com/speed/public-dns/faq#locations >> >> I mean, you could read the docs first to get the same answer, I think... >> right? >> I'm also pretty sure there are RIPE Atlas measurements of 8.8.8.8/8.8.4.4 >> that could tell you from which source-asn a backend sees traffic from.. >> right? (or with a tiny bit of thought one could be proposed/executed) >> >> >> > There are >> > IPv4 Networks: 68 >> > IPv6 Networks: 20 >> > DNS Cluster’s Identified by POP Code’s: 20 >> > >> > DNS Clusters identified by POP Code to City, State, or Country. Not all >> of >> > these are Google’s Core Datacenters, some of them are Edge Points of >> > Presences (POPs). https://peering.google.com/#/infrastructure and >> > https://www.google.com/about/datacenters/inside/locations/ >> > >> > Most of these are airport codes, it did my best to get the location >> > correct. >> > iad Washington, DC >> > syd Sydney, Australia >> > lhr London, UK >> > mrn Lenoir, NC >> > tpe Taiwan >> > atl Altanta, GA >> > tul Tulsa, OK >> > lpp Findland >> > bru Brussels, Belgium >> > cbf Council Bluffs, IA >> > chs Charleston, SC >> > dls The Dalles, Oregon >> > dub Dublin, Ireland >> > sin Singapore >> > fra Frankfort, Germany >> > bom Mumbai, India >> > gru Sao Paulo, Brazil >> > scl Santiago, Chile >> > nrt Tokyo, Japan >> > grq Groningen, Netherlans >> > >> > >> > >> > Which Google DNS Server Cluster am I using. I am testing this from >> > Chicago, IL >> > >> > # dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 >> > "173.194.94.135" <<<<<> > list above to get the cluster, Council Bluffs, IA >> > "edns0-client-subnet 207.xxx.xxx.0/24" >> > <<<< Your Source IP Block >> > >> > >> > Side note, the google dns servers will not respond to DNS queries to the >> > Cluster’s Member’s IP, they will only respond to dns queries to 8.8.8.8 >> and >> > 8.8.4.4. So the following will not work. >> > dig google.com @173.194.94.135 >> > >> > >> > >> > Now to see the DNS Cluster load balancing in action. I am doing a dig >> > query from our Telx\Digital Realty POP in Atlanta, GA. We do peer with >> > google at this location. >> > >> > I dig a dig query about 10 times and received the following unique dns >> > cluster member ip’s as responses. >> > >> > dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 >> > "74.125.42.138" >> > "173.194.102.132" >> > "74.125.177.5" >> > "74.125.177.74" >> > "74.125.177.71" >> > "74.125.177.4" >> > >> > Which all are Google DNS Networks in Atlanta. >> > 74.125.42.0/24 >> > >> > atl >> > >> > 74.125.177.0/24 >> > >> > atl >> > >> > 172.217.36.0/24 >> > >> > atl >> > >> > 173.194.102.0/24 >> > >> > atl >> > >> > 2607:f8b0:4002::/48 >> > >> > atl >> > >> > >> > >> > Just thought it would be helpful when troubleshooting google DNS issues. >> > >> > >> > ________________________________ >> > >> > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, >> files >> > or previous e-mail messages attached to it may contain confidential >> > information that is legally privileged. If you are not the intended >> > recipient, or a person responsible for delivering it to the intended >> > recipient, you are hereby notified that any disclosure, copying, >> > distribution or use of any of the information contained in or attached >> to >> > this transmission is STRICTLY PROHIBITED. If you have received this >> > transmission in error please notify the sender immediately by replying >> to >> > this e-mail. You must destroy the original transmission and its >> attachments >> > without reading or saving in any manner. Thank you. >> > >> > >> > > From marka at isc.org Thu Aug 24 00:53:58 2017 From: marka at isc.org (Mark Andrews) Date: Thu, 24 Aug 2017 10:53:58 +1000 Subject: Google DNS --- Figuring out which DNS Cluster you are using In-Reply-To: Your message of "Wed, 23 Aug 2017 20:39:27 -0400." References: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> <1968162469.886870.1503520652959@mail.yahoo.com> Message-ID: <20170824005358.42FA18303D8C@rock.dv.isc.org> If Google was being sensible the servers would just return the information along with the answer. They all support EDNS. e.g. dig +nsid @8.8.8.8 This is the type of thing the NSID (RFC 5001) was designed to do. It just requires Google to configure the servers to return a id. You would then back something like this. In this case the nsid is the hostname but it can be anything you like it to be. A value that makes sense to most people or a value that only make sense to a Google. ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> +nsid . ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38770 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; NSID: 72 6f 63 6b 2e 64 76 2e 69 73 63 2e 6f 72 67 ("rock.dv.isc.org") ; COOKIE: f58c358da14bc19476e2331f599e21c452df41a06367d78d (good) ;; QUESTION SECTION: ;. IN A ;; AUTHORITY SECTION: . 10773 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017082301 1800 900 604800 86400 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Aug 24 10:45:56 AEST 2017 ;; MSG SIZE rcvd: 150 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From henson at acm.org Thu Aug 24 02:11:30 2017 From: henson at acm.org (Paul B. Henson) Date: Wed, 23 Aug 2017 19:11:30 -0700 Subject: Frontier SoCal FIOS contact? - gateway proxy arp issue Message-ID: <2cb301d31c7e$4cbb0ba0$e63122e0$@acm.org> So yesterday I started seeing some arp warnings in my server logs: Aug 23 16:09:29 lisa /bsd: arp info overwritten for 96.251.22.154 by f0:1c:2d:8d:0e:cf on em2 Aug 23 16:12:24 lisa /bsd: arp info overwritten for 96.251.22.154 by f0:1c:2d:8d:0e:cf on em2 Aug 23 16:21:28 lisa /bsd: arp info overwritten for 96.251.22.154 by 00:25:90:da:ea:f9 on em2 f0:1c:2d:8d:0e:cf is the MAC address of 96.251.22.1, L100.LSANCA-VFTTP-55.gni.frontiernet.net, my FIOS gateway. It seems that for some reason proxy arp has been enabled on the router providing my gateway, and it is arp'ing for my static IP addresses as shown below: 0c:c4:7a:b3:ca:54 - MAC of lisa.pbhware.com (96.251.22.156) 00:25:90:da:ea:f9 - MAC of bart.pbhware.com (96.251.22.154) f0:1c:2d:8d:0e:cf - MAC of L100.LSANCA-VFTTP-55.gni.frontiernet.net (96.251.22.1) On 96.251.22.156: $ ping 96.251.22.154 16:12:24.416146 0c:c4:7a:b3:ca:54 Broadcast arp 42: arp who-has bart.pbhware.com tell lisa.pbhware.com 16:12:24.416405 00:25:90:da:ea:f9 0c:c4:7a:b3:ca:54 arp 60: arp reply bart.pbhware.com is-at 00:25:90:da:ea:f9 16:12:24.419522 f0:1c:2d:8d:0e:cf 0c:c4:7a:b3:ca:54 arp 60: arp reply bart.pbhware.com is-at f0:1c:2d:8d:0e:cf Another example for an IP address (96.251.22.158/static-5.pbhware.com) not currently in use: $ ping 96.251.22.158 16:26:15.784494 0c:c4:7a:b3:ca:54 Broadcast arp 42: arp who-has static-5.pbhware.com tell lisa.pbhware.com 16:26:15.787624 f0:1c:2d:8d:0e:cf 0c:c4:7a:b3:ca:54 arp 60: arp reply static-5.pbhware.com is-at f0:1c:2d:8d:0e:cf 16:26:15.787677 0c:c4:7a:b3:ca:54 f0:1c:2d:8d:0e:cf ip 98: lisa.pbhware.com > static-5.pbhware.com: icmp: echo request The gateway starts arp'ing looking for the real owner of that IP so it can proxy the traffic: 16:28:07.074869 f0:1c:2d:8d:0e:cf Broadcast arp 60: arp who-has static-5.pbhware.com tell L100.LSANCA-VFTTP-55.gni.frontiernet.net When I googled it, I found a number of complaints about this dating back years regarding Verizon FIOS, where proxy arp deployments seemed to be a standard practice in some areas, but for the decade I have had business FIOS this has never happened before. So I contacted frontier technical support to ask about it; unfortunately, the interaction was less than successful :(. While the level 1 support person was very helpful and didn't take very long to convince to escalate the issue, the first level 2 support person didn't quite seem to understand the concept, as demonstrated by the following excerpts from the chat: "turning off the ARP is done from the device that is receiving the request" "that is something he would need to turn off on his router, because we do not support 3rd party equipment" "sorry but we cannot make the change that he is requesting, it needs to be done on his device" "I understand what you are saying but the ARP request needs to be turned off through his equipment it is what is allowing signal in, just like a Ping can be turned off in the router even if something else is requesting the OPING" Technically, that last comment is true - if my system did not make an arp request, the frontier router would indeed not respond with a proxy arp reply. Of course, my systems would have a really hard time talking to each other if they weren't running arp 8-/. The last thing he had to say was "its not, on a router if you turn off Ping requests it will not get pinged, same thing with ARP requests" and I decided to stop wasting my time on him. Sadly, the level 1 tech informed me that the level 2 tech was actually working with his lead while responding to my issue. As I mentioned, the level 1 tech was very helpful, he offered to try to reach a different level 2 tech. The second level 2 tech refused to have anything to do with me unless I hooked up the original actiontech router that came with the Fios service 10 years ago, so I wrote off the official tech-support channel for now. So, long story short, are there any fios employees hanging out here that could possibly get me in contact with someone who understands the concept of proxy arp and would be able to determine why it suddenly was enabled on the gateway for my service yesterday and hopefully get it turned back off? That would be much appreciated. In the worst case I suppose I can work around this mess with arp inspection on the switch or static arp entries on the servers s, but I'd rather avoid being kludgy. Thanks much. From alejandroacostaalamo at gmail.com Thu Aug 24 02:40:12 2017 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Wed, 23 Aug 2017 22:40:12 -0400 Subject: Google DNS --- Figuring out which DNS Cluster you are using In-Reply-To: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> Message-ID: Excellent, thanks for sharing. El 23/8/17 a las 4:09 p.m., Erik Sundberg escribió: > I sent this out on the outage list, with a lots of good feedback sent to me. So I figured it would be useful to share the information on nanog as well. > > > A couple months ago had to troubleshoot a google DNS issue with Google’s NOC. Below is some helpful information on how to determine which DNS Cluster you are going to. > > Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 and 8.8.4.4. Anycast routes your DNS queries to the closes DNS cluster based on the best route / lowest metric to 8.8.8.8/8.8.4.4. Google has deployed multiple DNS clusters across the world and each DNS Cluster has multiple servers. > > So a DNS query in Chicago will go to a different DNS clusters than queries from a device in Atlanta or New York. > > > How to get a list of google DNS Cluster’s. > dig -t TXT +short locations.publicdns.goog. @8.8.8.8 > > How to print this list in a table format. Script from: https://developers.google.com/speed/public-dns/faq > --------------- > #!/bin/bash > IFS="\"$IFS" > for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8) > do > case $LOC in > '') : ;; > *.*|*:*) printf '%s ' ${LOC} ;; > *) printf '%s\n' ${LOC} ;; > esac > done > --------------- > > Which will give you a list like below. This is all of the IP network’s that google uses for their DNS Clusters and their associated locations. > > 74.125.18.0/26 iad > 74.125.18.64/26 iad > 74.125.18.128/26 syd > 74.125.18.192/26 lhr > 74.125.19.0/24 mrn > 74.125.41.0/24 tpe > 74.125.42.0/24 atl > 74.125.44.0/24 mrn > 74.125.45.0/24 tul > 74.125.46.0/24 lpp > 74.125.47.0/24 bru > 74.125.72.0/24 cbf > 74.125.73.0/24 bru > 74.125.74.0/24 lpp > 74.125.75.0/24 chs > 74.125.76.0/24 cbf > 74.125.77.0/24 chs > 74.125.79.0/24 lpp > 74.125.80.0/24 dls > 74.125.81.0/24 dub > 74.125.92.0/24 mrn > 74.125.93.0/24 cbf > 74.125.112.0/24 lpp > 74.125.113.0/24 cbf > 74.125.115.0/24 tul > 74.125.176.0/24 mrn > 74.125.177.0/24 atl > 74.125.179.0/24 cbf > 74.125.181.0/24 bru > 74.125.182.0/24 cbf > 74.125.183.0/24 cbf > 74.125.184.0/24 chs > 74.125.186.0/24 dls > 74.125.187.0/24 dls > 74.125.190.0/24 sin > 74.125.191.0/24 tul > 172.217.32.0/26 lhr > 172.217.32.64/26 lhr > 172.217.32.128/26 sin > 172.217.33.0/26 syd > 172.217.33.64/26 syd > 172.217.33.128/26 fra > 172.217.33.192/26 fra > 172.217.34.0/26 fra > 172.217.34.64/26 bom > 172.217.34.192/26 bom > 172.217.35.0/24 gru > 172.217.36.0/24 atl > 172.217.37.0/24 gru > 173.194.90.0/24 cbf > 173.194.91.0/24 scl > 173.194.93.0/24 tpe > 173.194.94.0/24 cbf > 173.194.95.0/24 tul > 173.194.97.0/24 chs > 173.194.98.0/24 lpp > 173.194.99.0/24 tul > 173.194.100.0/24 mrn > 173.194.101.0/24 tul > 173.194.102.0/24 atl > 173.194.103.0/24 cbf > 173.194.168.0/26 nrt > 173.194.168.64/26 nrt > 173.194.168.128/26 nrt > 173.194.168.192/26 iad > 173.194.169.0/24 grq > 173.194.170.0/24 grq > 173.194.171.0/24 tpe > 2404:6800:4000::/48 bom > 2404:6800:4003::/48 sin > 2404:6800:4006::/48 syd > 2404:6800:4008::/48 tpe > 2404:6800:400b::/48 nrt > 2607:f8b0:4001::/48 cbf > 2607:f8b0:4002::/48 atl > 2607:f8b0:4003::/48 tul > 2607:f8b0:4004::/48 iad > 2607:f8b0:400c::/48 chs > 2607:f8b0:400d::/48 mrn > 2607:f8b0:400e::/48 dls > 2800:3f0:4001::/48 gru > 2800:3f0:4003::/48 scl > 2a00:1450:4001::/48 fra > 2a00:1450:4009::/48 lhr > 2a00:1450:400b::/48 dub > 2a00:1450:400c::/48 bru > 2a00:1450:4010::/48 lpp > 2a00:1450:4013::/48 grq > > There are > IPv4 Networks: 68 > IPv6 Networks: 20 > DNS Cluster’s Identified by POP Code’s: 20 > > DNS Clusters identified by POP Code to City, State, or Country. Not all of these are Google’s Core Datacenters, some of them are Edge Points of Presences (POPs). https://peering.google.com/#/infrastructure and https://www.google.com/about/datacenters/inside/locations/ > > Most of these are airport codes, it did my best to get the location correct. > iad Washington, DC > syd Sydney, Australia > lhr London, UK > mrn Lenoir, NC > tpe Taiwan > atl Altanta, GA > tul Tulsa, OK > lpp Findland > bru Brussels, Belgium > cbf Council Bluffs, IA > chs Charleston, SC > dls The Dalles, Oregon > dub Dublin, Ireland > sin Singapore > fra Frankfort, Germany > bom Mumbai, India > gru Sao Paulo, Brazil > scl Santiago, Chile > nrt Tokyo, Japan > grq Groningen, Netherlans > > > > Which Google DNS Server Cluster am I using. I am testing this from Chicago, IL > > # dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 > "173.194.94.135" <<<<< "edns0-client-subnet 207.xxx.xxx.0/24" <<<< Your Source IP Block > > > Side note, the google dns servers will not respond to DNS queries to the Cluster’s Member’s IP, they will only respond to dns queries to 8.8.8.8 and 8.8.4.4. So the following will not work. > dig google.com @173.194.94.135 > > > > Now to see the DNS Cluster load balancing in action. I am doing a dig query from our Telx\Digital Realty POP in Atlanta, GA. We do peer with google at this location. > > I dig a dig query about 10 times and received the following unique dns cluster member ip’s as responses. > > dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 > "74.125.42.138" > "173.194.102.132" > "74.125.177.5" > "74.125.177.74" > "74.125.177.71" > "74.125.177.4" > > Which all are Google DNS Networks in Atlanta. > 74.125.42.0/24 > > atl > > 74.125.177.0/24 > > atl > > 172.217.36.0/24 > > atl > > 173.194.102.0/24 > > atl > > 2607:f8b0:4002::/48 > > atl > > > > Just thought it would be helpful when troubleshooting google DNS issues. > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From ESundberg at nitelusa.com Thu Aug 24 04:41:21 2017 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Thu, 24 Aug 2017 04:41:21 +0000 Subject: Google DNS --- Figuring out which DNS Cluster you are using In-Reply-To: <20170823232128.99DA.B2447BB2@shat.net> References: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> <20170823232128.99DA.B2447BB2@shat.net> Message-ID: <495D0934DA46854A9CA758393724D590A5FDC902@NI-MAIL02.nii.ads> Shaun, Good catch!!! I would be nice if this was lowered to 1 second. #dig o-o.myaddr.l.google.com -t txt @8.8.4.4 ;; ANSWER SECTION: o-o.myaddr.l.google.com. 51 IN TXT "74.125.80.4" o-o.myaddr.l.google.com. 51 IN TXT "edns0-client-subnet 14.161.5.0/24" <<< Not my ip but someone from this IP did query this 9 seconds ago. -----Original Message----- From: Shaun [mailto:nanog at shat.net] Sent: Wednesday, August 23, 2017 11:21 PM To: Erik Sundberg Cc: nanog at nanog.org Subject: Re: Google DNS --- Figuring out which DNS Cluster you are using On Wed, 23 Aug 2017 20:09:49 +0000 Erik Sundberg wrote: > Which Google DNS Server Cluster am I using. I am testing this from > Chicago, IL > > # dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 > "173.194.94.135" <<<<< "edns0-client-subnet 207.xxx.xxx.0/24" <<<< Your Source IP Block Worth noting, this record has TTL 60 and caching can cause unexpected responses; you may have to try a few times to get the correct data. My first attempt gave me an unrecognized "edns0-client-subnet" and a Google IP from Finland when I was querying from Atlanta. -s ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From ESundberg at nitelusa.com Thu Aug 24 04:42:27 2017 From: ESundberg at nitelusa.com (Erik Sundberg) Date: Thu, 24 Aug 2017 04:42:27 +0000 Subject: Google DNS --- Figuring out which DNS Cluster you are using In-Reply-To: References: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> Message-ID: <495D0934DA46854A9CA758393724D590A5FDC938@NI-MAIL02.nii.ads> All.. You're welcome for the info. Let's remember what NANOG is about "mailing list is established to provide a forum for the exchange of technical information and the discussion of specific implementation issues that require cooperation among network service providers." I sent this out to educate everyone and share the knowledge about how Google's Recursive DNS servers are setup for 8.8.8.8 / 8.8.4.4. Yes, some people already know how google handles their DNS service and have read the Google DNS FAQ page where this information is buried in the middle of the page. But if you never had to really troubleshoot in depth an issue with Google's DNS Server you probably never read that article. (https://developers.google.com/speed/public-dns/faq) We still get the email on the various lists whether it's Nanog or the Outages with the subject "OMG 8.8.8.8 IS DOWN!!!!" (Yes I admitted I was responsible for one of these email threads when we had the issues with Google DNS servers in the Atlanta Area a couple months ago). Then everyone starts responding with, mine works and I am in New York, London, Chicago, Dallas, and etc. And the original reporter of this issue has no idea why they are down and no one else is down to 8.8.8.8. At least this way someone might be able to take the troubleshooting step further and narrowing down the issue to a Google DNS Cluster or a Server in the cluster. Maybe giving a Google Network or DNS admin lurking on the forum some more information go off of, which might make them take a more serious look at the outage report. I also don’t run a blog or anything, but let's not forget our posts do get indexed by Google's search engines. And this thread is already the 3rd result for "Google DNS Cluster" which might help some lone network admin that is not apart of NANOG troubleshooting google dns issues. They might even open a more informative ticket with their service provider's NOC. Anyways I am just another network engineer running my little corner of this global experiment that we call the "Internet" sharing some knowledge. -Erik -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alejandro Acosta Sent: Wednesday, August 23, 2017 9:40 PM To: nanog at nanog.org Subject: Re: Google DNS --- Figuring out which DNS Cluster you are using Excellent, thanks for sharing. El 23/8/17 a las 4:09 p.m., Erik Sundberg escribió: > I sent this out on the outage list, with a lots of good feedback sent to me. So I figured it would be useful to share the information on nanog as well. > > > A couple months ago had to troubleshoot a google DNS issue with Google’s NOC. Below is some helpful information on how to determine which DNS Cluster you are going to. > > Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 and 8.8.4.4. Anycast routes your DNS queries to the closes DNS cluster based on the best route / lowest metric to 8.8.8.8/8.8.4.4. Google has deployed multiple DNS clusters across the world and each DNS Cluster has multiple servers. > > So a DNS query in Chicago will go to a different DNS clusters than queries from a device in Atlanta or New York. > > > How to get a list of google DNS Cluster’s. > dig -t TXT +short locations.publicdns.goog. @8.8.8.8 > > How to print this list in a table format. Script from: > https://developers.google.com/speed/public-dns/faq > --------------- > #!/bin/bash > IFS="\"$IFS" > for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8) do > case $LOC in > '') : ;; > *.*|*:*) printf '%s ' ${LOC} ;; > *) printf '%s\n' ${LOC} ;; > esac > done > --------------- > > Which will give you a list like below. This is all of the IP network’s that google uses for their DNS Clusters and their associated locations. > > 74.125.18.0/26 iad > 74.125.18.64/26 iad > 74.125.18.128/26 syd > 74.125.18.192/26 lhr > 74.125.19.0/24 mrn > 74.125.41.0/24 tpe > 74.125.42.0/24 atl > 74.125.44.0/24 mrn > 74.125.45.0/24 tul > 74.125.46.0/24 lpp > 74.125.47.0/24 bru > 74.125.72.0/24 cbf > 74.125.73.0/24 bru > 74.125.74.0/24 lpp > 74.125.75.0/24 chs > 74.125.76.0/24 cbf > 74.125.77.0/24 chs > 74.125.79.0/24 lpp > 74.125.80.0/24 dls > 74.125.81.0/24 dub > 74.125.92.0/24 mrn > 74.125.93.0/24 cbf > 74.125.112.0/24 lpp > 74.125.113.0/24 cbf > 74.125.115.0/24 tul > 74.125.176.0/24 mrn > 74.125.177.0/24 atl > 74.125.179.0/24 cbf > 74.125.181.0/24 bru > 74.125.182.0/24 cbf > 74.125.183.0/24 cbf > 74.125.184.0/24 chs > 74.125.186.0/24 dls > 74.125.187.0/24 dls > 74.125.190.0/24 sin > 74.125.191.0/24 tul > 172.217.32.0/26 lhr > 172.217.32.64/26 lhr > 172.217.32.128/26 sin > 172.217.33.0/26 syd > 172.217.33.64/26 syd > 172.217.33.128/26 fra > 172.217.33.192/26 fra > 172.217.34.0/26 fra > 172.217.34.64/26 bom > 172.217.34.192/26 bom > 172.217.35.0/24 gru > 172.217.36.0/24 atl > 172.217.37.0/24 gru > 173.194.90.0/24 cbf > 173.194.91.0/24 scl > 173.194.93.0/24 tpe > 173.194.94.0/24 cbf > 173.194.95.0/24 tul > 173.194.97.0/24 chs > 173.194.98.0/24 lpp > 173.194.99.0/24 tul > 173.194.100.0/24 mrn > 173.194.101.0/24 tul > 173.194.102.0/24 atl > 173.194.103.0/24 cbf > 173.194.168.0/26 nrt > 173.194.168.64/26 nrt > 173.194.168.128/26 nrt > 173.194.168.192/26 iad > 173.194.169.0/24 grq > 173.194.170.0/24 grq > 173.194.171.0/24 tpe > 2404:6800:4000::/48 bom > 2404:6800:4003::/48 sin > 2404:6800:4006::/48 syd > 2404:6800:4008::/48 tpe > 2404:6800:400b::/48 nrt > 2607:f8b0:4001::/48 cbf > 2607:f8b0:4002::/48 atl > 2607:f8b0:4003::/48 tul > 2607:f8b0:4004::/48 iad > 2607:f8b0:400c::/48 chs > 2607:f8b0:400d::/48 mrn > 2607:f8b0:400e::/48 dls > 2800:3f0:4001::/48 gru > 2800:3f0:4003::/48 scl > 2a00:1450:4001::/48 fra > 2a00:1450:4009::/48 lhr > 2a00:1450:400b::/48 dub > 2a00:1450:400c::/48 bru > 2a00:1450:4010::/48 lpp > 2a00:1450:4013::/48 grq > > There are > IPv4 Networks: 68 > IPv6 Networks: 20 > DNS Cluster’s Identified by POP Code’s: 20 > > DNS Clusters identified by POP Code to City, State, or Country. Not > all of these are Google’s Core Datacenters, some of them are Edge > Points of Presences (POPs). > https://peering.google.com/#/infrastructure and > https://www.google.com/about/datacenters/inside/locations/ > > Most of these are airport codes, it did my best to get the location correct. > iad Washington, DC > syd Sydney, Australia > lhr London, UK > mrn Lenoir, NC > tpe Taiwan > atl Altanta, GA > tul Tulsa, OK > lpp Findland > bru Brussels, Belgium > cbf Council Bluffs, IA > chs Charleston, SC > dls The Dalles, Oregon > dub Dublin, Ireland > sin Singapore > fra Frankfort, Germany > bom Mumbai, India > gru Sao Paulo, Brazil > scl Santiago, Chile > nrt Tokyo, Japan > grq Groningen, Netherlans > > > > Which Google DNS Server Cluster am I using. I am testing this from > Chicago, IL > > # dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 > "173.194.94.135" <<<<< "edns0-client-subnet 207.xxx.xxx.0/24" <<<< Your Source IP Block > > > Side note, the google dns servers will not respond to DNS queries to the Cluster’s Member’s IP, they will only respond to dns queries to 8.8.8.8 and 8.8.4.4. So the following will not work. > dig google.com @173.194.94.135 > > > > Now to see the DNS Cluster load balancing in action. I am doing a dig query from our Telx\Digital Realty POP in Atlanta, GA. We do peer with google at this location. > > I dig a dig query about 10 times and received the following unique dns cluster member ip’s as responses. > > dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 "74.125.42.138" > "173.194.102.132" > "74.125.177.5" > "74.125.177.74" > "74.125.177.71" > "74.125.177.4" > > Which all are Google DNS Networks in Atlanta. > 74.125.42.0/24 > > atl > > 74.125.177.0/24 > > atl > > 172.217.36.0/24 > > atl > > 173.194.102.0/24 > > atl > > 2607:f8b0:4002::/48 > > atl > > > > Just thought it would be helpful when troubleshooting google DNS issues. > > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you. From bortzmeyer at nic.fr Thu Aug 24 07:42:42 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 24 Aug 2017 09:42:42 +0200 Subject: Google DNS --- Figuring out which DNS Cluster you are using In-Reply-To: <20170824005358.42FA18303D8C@rock.dv.isc.org> References: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> <1968162469.886870.1503520652959@mail.yahoo.com> <20170824005358.42FA18303D8C@rock.dv.isc.org> Message-ID: <20170824074242.5vqxuqwbxgudjfwt@nic.fr> On Thu, Aug 24, 2017 at 10:53:58AM +1000, Mark Andrews wrote a message of 39 lines which said: > If Google was being sensible the servers would just return the > information along with the answer. They all support EDNS. I fully agree with you that NSID (RFC 5001) is great and Google should really deploy it. However: > e.g. dig +nsid @8.8.8.8 I assume that Google wants also to be debuggable by people who work on inferior operating systems, and have no dig. Hence this trick. For instance, L.root-servers.net has both NSID and a special name, identity.l.root-servers.org (see RFC 7108). From bjorn at mork.no Thu Aug 24 11:41:10 2017 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 24 Aug 2017 13:41:10 +0200 Subject: Google DNS --- Figuring out which DNS Cluster you are using In-Reply-To: <20170824074242.5vqxuqwbxgudjfwt@nic.fr> (Stephane Bortzmeyer's message of "Thu, 24 Aug 2017 09:42:42 +0200") References: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> <1968162469.886870.1503520652959@mail.yahoo.com> <20170824005358.42FA18303D8C@rock.dv.isc.org> <20170824074242.5vqxuqwbxgudjfwt@nic.fr> Message-ID: <8760dd9ort.fsf@miraculix.mork.no> Stephane Bortzmeyer writes: > On Thu, Aug 24, 2017 at 10:53:58AM +1000, > Mark Andrews wrote > a message of 39 lines which said: > >> If Google was being sensible the servers would just return the >> information along with the answer. They all support EDNS. > > I fully agree with you that NSID (RFC 5001) is great and Google should > really deploy it. +1 for NSID! Should be mandatory for anycast DNS, IMHO. I don't understand why Google haven't enabled it. > However: > >> e.g. dig +nsid @8.8.8.8 > > I assume that Google wants also to be debuggable by people who work on > inferior operating systems, and have no dig. Hence this trick. For > instance, L.root-servers.net has both NSID and a special name, > identity.l.root-servers.org (see RFC 7108). As you state, there is no problem providing both. Or an infinite number of special names if they like. But NSID provides something none of the special names can. Quoting the justification in the intro of RFC5001: Given that a DNS query is an idempotent operation with no retained state, it would appear that the only completely reliable way to obtain the identity of the name server that responded to a particular query is to have that name server include identifying information in the response itself. Sometimes it just isn't enough to know which server answered the previous or next requests. Bjørn From fkittred at gwi.net Wed Aug 16 20:29:17 2017 From: fkittred at gwi.net (Fletcher Kittredge) Date: Wed, 16 Aug 2017 16:29:17 -0400 Subject: Last Week's Canadian Fiber Cut In-Reply-To: <1502827673.408249.1074473208.501C5274@webmail.messagingengine.com> References: <1502827673.408249.1074473208.501C5274@webmail.messagingengine.com> Message-ID: There is a third route from Halifax -> New Brunswick -> Portland, ME -> [Albany, Boston] On Tue, Aug 15, 2017 at 4:07 PM, Clinton Work wrote: > I can't speak for the Bell Aliant network, but I'm only aware of two > diverse fiber routes out of Halifax, Nova Scotia. Halifax -> New > Brunswick -> Quebec City is the Canadian route and Halifax -> Boston is > the diverse route. > > On Tue, Aug 15, 2017, at 01:52 PM, Jared Mauch wrote: > > Perhaps some transatlantic fallback? It looks like the only cable out > > there is the Greenland one.. guessing that’s not very competitive? It > > only gets you to Iceland it seems. > > > > -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net From troy at wolvtech.com Thu Aug 17 03:51:56 2017 From: troy at wolvtech.com (Troy Mursch) Date: Wed, 16 Aug 2017 20:51:56 -0700 Subject: AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these schmucks? In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC0DE623E91@USIDCWVEMBX08.corp.global.level3.com> References: <15340.1502740194@segfault.tristatelogic.com> <970945E55BFD8C4EA4CAD74B647A9DC0DE623E91@USIDCWVEMBX08.corp.global.level3.com> Message-ID: This discussion is not pertaining to a customer of a network service provider. Ecatel / Quasi Networks (AS29073) has an established track record of ignoring abuse requests for years. So much so they are now in legal trouble, per court documents published on August 14: https://uitspraken.rechtspraak.nl/inziendocument?id=ECLI:NL:RBDHA:2017:9026 (Use Google Translate if you can’t read Dutch) Setting aside the child porn, phishing sites, route hijacking, copyright infringement, and large-scale outbound hacking activities - why would anyone peer with another AS who deliberately ignores abuse requests? Yesterday I spoke with BREIN, the organization leading case against AS29073, they advised, "Our effort is aimed at outing the actual people behind it so they can be held responsible." If anyone has information regarding AS29073 and would like to share it with BREIN you can submit it via this web form: https://stichtingbrein.nl/contact.php __ *Troy Mursch* Bad Packets Report (702) 509-1248 On Mon, Aug 14, 2017 at 1:17 PM, Siegel, David wrote: > If you believe that a customer of a network service provider is in > violation of that service providers AUP, you should email > abuse at serviceprovider.net. Most large networks have a security team that > monitors that email address regularly and will cooperate with you to > address the problem. > > Dave > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ronald F. > Guilmette > Sent: Monday, August 14, 2017 1:50 PM > To: nanog at nanog.org > Subject: AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these > schmucks? > > > Sorry for the re-post, but it has been brought to my attention that my > inclusion, in my prior posting, of various unsavory FQDNs resolving to > various IPv4 addresses on AS29073 has triggered some people's spam > filters. (Can't imagine why. :-) So I am re-posting this message now, > with just a link to where those shady FQDNs and their current forward > resolutions may be found. (I also took the opportunity to clean up some > minor typos.) > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > I think that this is primarily Level3's problem to fix. But you be the > judge. Please, read on. > > +_+_+_+_+_+_+_+_ > > Over the weekend, I stumbled upon an interesting blog calld "Bad Packets", > where a fellow named Troy has written about various unsavory goings on > involving various newtorks. One network that he called out in particular > was AS29073, formerly called "Ecatel". on his blog, this fellow Troy has > noted at length some break-in attempts originating from AS29073 and his > inability to get anyone, in particular RIPE NCC, to give a damn. > > https://badpackets.net/the-master-needler-80-82-65-66/ > https://badpackets.net/a-conversation-with-ripe-ncc-regardin > g-quasi-networks-ltd/ > https://badpackets.net/quasi-networks-responds-as-we-witness > -the-death-of-the-master-needler-80-82-65-66-for-now/ > > The fact that RIPE NCC declined to accept the role of The Internet Police > didn't surprise me at all... they never have and probably never will. > But I decided to have a quick look at what this newtork was routing, at > present, which can be easily see here: > > http://bgp.he.net/AS29073#_prefixes > > So I was looking through the announced routes for AS29073, and it all > looked pretty normal... a /24 block, check, a /24 block, check, a /21 block > check... another /24 block, and then ... WAIT A SECOND! HOLY MOTHER OF > GOD! WHAT'S THIS??? 196.16.0.0/14 !!! > > So how does a little two-bit network with a rather dubious reputation and > a grand total of only about a /19 to its name suddenly come to be routing > an entire /14 block?? > > And of course, its a legacy (abandoned) Afrinic block. > > And of course, there's no reverse DNS for any of it, because there is no > valid delegation for the reverse DNS for any of it... usually a good sign > that whoever is routing the block right now -does not- have legit rights to > do so. (If they did, then they would have presented their LOAs or whatever > to Afrinic and thus gotten the reverse DNS properly delegated to their own > name servers.) > > I've seen this movie before. You all have. This gives every indication > of being just another sad chapter in the ongoing mass pillaging of unused > Afrinic legacy IPv4 space, by various actors with evil intent. > I've already documented this hightly unfortunate fad right here on > multiple occasions: > > https://mailman.nanog.org/pipermail/nanog/2016-November/089232.html > https://mailman.nanog.org/pipermail/nanog/2017-August/091821.html > > This incident is a bit different from the others however, in that it -does > not- appear that the 196.16.0.0/14 block has been filed to the brim with > snowshoe spammers. Well, not yet anyway. > > But if in fact the stories are correct, and if AS29073 does indeed have a > history of hosting outbound hacking activities, then the mind reels when > thinking about how much mischief such bad actors could get into if given an > entire /14 to play with. (And by the way, this is a new world's record I > think, for largest single-route deliberate hijack. > I've seen plenty of /16s go walkabout before, and even a whole /15. > But an entire /14?!?! That is uniquely brazen.) > > In addition to the above, and the points raised within the Bad Packets > blog (see links above) I found, via passive DNS, a number of other causes > for concern about AS29073, to wit: > > Shady FQDNs (incl possible child porn ones) on AS29073 moved here: > https://pastebin.com/raw/f4M09UKL > > (In addition to the above, I've also found plenty more domain names > associated with AS29073 which incorporate the names "Apple" "AirBnB", > "Facebook", and "Groupon", as well as dozens of other legitimate companies > and organizations.) > > I confess that I have not had the time to look at any of the web sites > that may or may not be associated with any of the above FQDNs, but the > domain names themselves are certainly strongly suggestive of (a) the > possible hosting of child porn and also and separately (b) the possible > hosting of phishing sites. > > So, given the history of this network (as is well documented on the Bad > Packets blog) and given all of the above, and given what would appear to be > the unauthorized "liberation" of the entire 196.16.0.0/14 block by > AS29073, one cannot help but wonder: Why does anybody still even peer with > these jerks? > > The always helpful and informative web site bgp.he.net indicates that > very nearly 50% of the connectivity currently enjoyed by AS29073 is being > provided to them by Level3. I would thus like to ask Level3 to reconsider > that peering arrangement in light of the above facts, and especially in > light of what would appear to be the unauthorized routing of the > 196.16.0.0/14 block by AS29073. > > Surprisingly, given its history, AS29073 apparently has a total of 99 > different peers, at present, and I would likewise ask all of them to > reconsider their current peering arrangements with this network. I am > listing all 99 peers below. > > Before I get to that however, I'd like to also note that there currently > exists, within the RIPE Routing Registry, the following route object: > > route: 196.16.0.0/14 > origin: AS29073 > mnt-by: QUASINETWORKS-MNT > mnt-by: EC42500-MNT > mnt-routes: EC42500-MNT > mnt-routes: M247-EU-MNT > created: 2017-03-28T21:47:03Z > last-modified: 2017-08-11T19:58:39Z > source: RIPE > > I confess that I am not 100% sure of the exact semantics of the > "mnt-routes" > tag, but it would appear from the above that the UK's M247 network > (AS9009)... > which itself is not even peering with AS29073... appears to have, in > effect countersigned the above RIPE route object, vouching for its > correctness and authenticity as they did so. Why they would have done > that, especially given that they themselves are not even peering with > AS29073, is, I confess, beyond me. But I would love to have them explain > it, or even try to explain it. > It's enigmatic, to say the least. > > Anyway, the "created" date in the above record seems to be consistant with > that actual start of the announcement of 196.16.0.0/14 by AS29073, which > the RIPE Routing History tool says occured sometime in March of this year. > > One additional (and rather bizzare) footnote to this whole story about the > 196.16.0.0/14 block has to do with the entity that allegedly -is- the > current rightful owner of the block (as far as Afrinic is concerned). > That entity is designated by the Afrinic handle ORG-IA41-AFRINIC and that > in turn has an admin-c and tech-c of NAIT1-AFRINIC. The record for that > handle is as follows: > > ------------------------------------------------------- > person: Network and Information Technology Administrator > address: Unit 117, Orion Mall, Palm Street > address: Victoria, Mahe > address: Seychelles (SC) > phone: +972-54-2203545 > e-mail: info at networkandinformationtechnology.com > nic-hdl: NAIT1-AFRINIC > mnt-by: MNT-NETWORKANDINFORMATIONTECHNOLOGY > changed: info at networkandinformationtechnology.com 20150725 > source: AFRINIC > ------------------------------------------------------- > > Upon fetching the current WHOIS record for networkandinformationtechnolog > y.com > I found it more than passing strange that all of the contact details > therein are associated *not* with anything in Africa, nor even anything in > the home country of AS29073 (Netherlands) but rather, the address and phone > numbers therein all appear to be ones associated with a relatively well > known Internet attorney in Santa Monica, Califiornia by the name of Bennet > Kelly. > > As it happens, in the distant past (about 10 years ago) I personally > crossed swords with this particular fellow. He may be a lot of things, but > it never seemed to me that stupid was one of them. And indeed the domain > name networkandinformationtechnology.com and all of its connections to > the 196.16.0.0/14 block appear to date from 2015... > long before AS29073 started routing this block (which only started in > March of this year). > > So, my best guess about this whole confusing mess is that the -original- > legitimate owners of the 196.16.0.0/14 block most probably sold it on, in > a legitimate transaction, to some other party in 2015, where that other > party was/is represented by Mr. Bennet Kelly, Esq. And my guess is that > neither he nor the new owners, who he represents, even know that their > expensive /14 has gone walkabout, as of March of this year. > I will be trying to make contact with Mr. Kelley today to discuss this > with him and will post a follow-up if any new and interesting information > arises from that conversation. > > > Regards, > rfg > > > Peers of AS29073: > ============================================================ > ==================== > 1 Level 3 Communications, Inc. > United States > AS3356 > 2 REBA Communications BV > Netherlands > AS56611 > 3 Hurricane Electric, Inc. > United States > AS6939 > 4 Core-Backbone GmbH > Germany > AS33891 > 5 Init7 (Switzerland) Ltd. > Switzerland > AS13030 > 6 RETN Limited > Ukraine > AS9002 > 7 COLT Technology Services Group Limited > United Kingdom > AS8220 > 8 State Institute of Information Technologies and Telecommunications > (SIIT&T "Informika") > Russian Federation > AS3267 > 9 GlobeNet Cabos Submarinos Colombia, S.A.S. > Colombia > AS52320 > 10 Digital Telecommunication Services S.r.l. > Italy > AS49605 > 11 IT.Gate S.p.A. > Italy > AS12779 > 12 green.ch AG > Switzerland > AS1836 > 13 UNIDATA S.p.A. > Italy > AS5394 > 14 GEANT Limited > European Union > AS20965 > 15 IP-Max SA > Switzerland > AS25091 > 16 Lost Oasis SARL > France > AS29075 > 17 nexellent ag > Switzerland > AS31424 > 18 SEACOM Limited > Mauritius > AS37100 > 19 Angola Cables > Angola > AS37468 > 20 ENTANET International Limited > United Kingdom > AS8468 > 21 Blix Solutions AS > Norway > AS50304 > 22 POST Luxembourg > Luxembourg > AS6661 > 23 Zayo France SAS > France > AS8218 > 24 Wind Telecomunicazioni SpA > Italy > AS1267 > 25 Swisscom (Switzerland) Ltd > Switzerland > AS3303 > 26 Pacnet Global Ltd > Hong Kong > AS10026 > 27 SURFnet bv > Netherlands > AS1103 > 28 SEEWEB s.r.l. > Italy > AS12637 > 29 BIT BV > Netherlands > AS12859 > 30 euNetworks Managed Services GmbH > Germany > AS13237 > 31 CAIW Diensten B.V. > Netherlands > AS15435 > 32 netplus.ch SA > Switzerland > AS15547 > 33 DOKOM Gesellschaft fuer Telekommunikation mbH > Germany > AS15763 > 34 ADISTA SAS > France > AS16347 > 35 Viewqwest Pte Ltd > Singapore > AS18106 > 36 Digital Ocean, Inc. > European Union > AS200130 > 37 Digital Ocean, Inc. > Netherlands > AS202018 > 38 Open Peering B.V. > Netherlands > AS20562 > 39 Services Industriels de Geneve > Switzerland > AS20932 > 40 Cemig Telecomunicaes SA > Brazil > AS23106 > 41 SG.GS > Singapore > AS24482 > 42 Vorboss Limited > United Kingdom > AS25160 > 43 equada network GmbH > Germany > AS25220 > 44 Avantel, Close Joint Stock Company > Russian Federation > AS25227 > 45 Gyron Internet Ltd > United Kingdom > AS29017 > 46 IPROUTE SRL > Italy > AS49289 > 47 LLC "TRC FIORD" > Russian Federation > AS28917 > 48 Hostserver GmbH > Germany > AS29140 > 49 Telekommunikation Mittleres Ruhrgebiet GmbH > Germany > AS12329 > 50 Internet Systems Consortium, Inc. > United States > AS30132 > 51 Liquid Telecommunications Ltd > United Kingdom > AS30844 > 52 Paulus M. Hoogsteder trading as Meanie > Netherlands > AS31019 > 53 Digiweb ltd > Ireland > AS31122 > 54 Fiberax Networking&Cloud Ltd. > United Kingdom > AS3252 > 55 Hivane > France > AS34019 > 56 CELESTE SAS > France > AS34177 > 57 Kantonsschule Zug > Switzerland > AS34288 > 58 Citycable > Switzerland > AS34781 > 59 SoftLayer Technologies Inc. > United States > AS36351 > 60 Network Platforms (PTY) LTD > South Africa > AS37497 > 61 Micron21 Datacentre Pty Ltd > Australia > AS38880 > 62 Convergenze S.p.A. > Italy > AS39120 > 63 Fiberby ApS > Denmark > AS42541 > 64 IP ServerOne Solutions Sdn Bhd, > Malaysia > AS45352 > 65 Easynet Global Services > European Union > AS4589 > 66 IP-Only Networks AB > Sweden > AS12552 > 67 Tango S.A. > Luxembourg > AS48526 > 68 Les Nouveaux Constructeurs SA > France > AS49463 > 69 CustodianDC Limited > United Kingdom > AS50300 > 70 MCKAYCOM LTD > United Kingdom > AS50763 > 71 Daisy Communications Ltd > United Kingdom > AS5413 > 72 MC-IX Matrix Internet Exchange RS-1 > Indonesia > AS55818 > 73 NetIX Communications Ltd. > Bulgaria > AS57463 > 74 Anycast Global Backbone > Australia > AS58511 > 75 LUXNETWORK S.A. > Luxembourg > AS29467 > 76 oja.at GmbH > Austria > AS39912 > 77 Elisa Oyj > Finland > AS6667 > 78 A1 Telekom Austria AG > Austria > AS8447 > 79 Fusix Networks B.V. > Netherlands > AS57866 > 80 ClaraNET LTD > United Kingdom > AS8426 > 81 "OBIT" Ltd. > Russian Federation > AS8492 > 82 Console Network Solutions Ltd > United Kingdom > AS43531 > 83 NetCologne GmbH > Germany > AS8422 > 84 Tesonet Ltd > Lithuania > AS201341 > 85 Linx Telecommunications B.V. > Estonia > AS3327 > 86 Strato AG > Germany > AS6724 > 87 CJSC RASCOM > Russian Federation > AS20764 > 88 Sunrise Communications AG > Switzerland > AS6730 > 89 KPN B.V. > Netherlands > AS1136 > 90 MTN SA > South Africa > AS16637 > 91 Portlane AB > Sweden > AS42708 > 92 TM Net, Internet Service Provider > Malaysia > AS4788 > 93 Network Dedicated SAS > Switzerland > AS62355 > 94 Next Layer Telekommunikationsdienstleistungs- und Beratungs GmbH > Austria > AS1764 > 95 Telkom SA Ltd. > South Africa > AS5713 > 96 ShockSRV Internet Services Private Limited > Netherlands > AS60115 > 97 JUPITER 25 LIMITED > Netherlands > AS64484 > 98 M-net Telekommunikations GmbH > Germany > AS8767 > 99 Neterra Ltd. > Bulgaria > AS34224 > From paul at paulstewart.org Thu Aug 17 09:51:48 2017 From: paul at paulstewart.org (Paul Stewart) Date: Thu, 17 Aug 2017 05:51:48 -0400 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: Message-ID: <6A6F5101-4611-4BC0-A4CD-DA545E62AF20@paulstewart.org> Yeah good point Chris …. Got thinking about this too much from an IP perspective :) > On Aug 16, 2017, at 6:29 PM, Christopher Morrell wrote: > > Let’s not forget that all POTS and cell service was offline during the outage - even for local and 911 service. > > There is some high level of dependence on some equipment in Quebec and/or westward which should not be there. > > A double fault like that should not knock out all local service for 4 out of 10 provinces. I would expect that an architectural review is under way. > > > On Wed, Aug 16, 2017 at 16:14 Paul Stewart > wrote: > It wasn’t an issue getting transatlantic - it was an issue within a relatively small region in Eastern Canada talking to the rest of the world for certain carriers. There were several smaller carriers/providers not affected - just happens the local incumbent telco and one of their larger competitors got knocked out … > > > > On Aug 15, 2017, at 3:52 PM, Jared Mauch > wrote: > > > > > >> On Aug 15, 2017, at 1:22 PM, Rod Beck > wrote: > >> > >> Did we ever get any resolution on why this was such a big outage? Appears there were two fiber cuts. Were the fibers damaged in the same conduit? Is this a collapsed ring scenario? > >> > >> > >> http://www.cbc.ca/news/canada/newfoundland-labrador/concerns-about-backup-bell-outage-1.4239064 > > > > Perhaps some transatlantic fallback? It looks like the only cable out there is the Greenland one.. guessing that’s not very competitive? It only gets you to Iceland it seems. > > > > - Jared > From sganguly at box.com Sat Aug 19 19:16:02 2017 From: sganguly at box.com (Sahil Ganguly) Date: Sat, 19 Aug 2017 12:16:02 -0700 Subject: AT&T NOC contact? Message-ID: Hello, Is there someone at AT&T on the mailing list I can talk to regarding a possible routing loop getting from AT&T to Box? Thanks! -- Sahil Ganguly Senior Network Operations Engineer M: 303.250.8893 900 Jefferson Ave Redwood City, CA 94063 From nickdwhite at gmail.com Tue Aug 22 00:05:03 2017 From: nickdwhite at gmail.com (Nick W) Date: Mon, 21 Aug 2017 20:05:03 -0400 Subject: Creating a Circuit ID Format In-Reply-To: <2ef2a912-9223-3f7a-615b-60069e10e1d5@lns.com> References: <2ef2a912-9223-3f7a-615b-60069e10e1d5@lns.com> Message-ID: More information for AT&T circuit IDs, could give some ideas: http://etler.com/docs/AT&T/ATTCCGTab11.pdf On Mon, Aug 21, 2017 at 7:41 PM, Tim Pozar wrote: > Could start looking at the AT&T/Telecordia standards for this sort of > thing... > > https://en.wikipedia.org/wiki/Circuit_ID > http://www.centurylink.com/wholesale/systems/WebHelp/ > reference/circuit_id_formats_guide.htm > > On 8/21/17 1:26 PM, Colton Conor wrote: > > We are building a new fiber network, and need help creating a circuit ID > > format to for new fiber circuits. Is there a guide or standard for fiber > > circuit formats? Does the circuit ID change when say a customer upgrades > > for 100Mbps to 1Gbps port? > > > > What do the larger carriers do? Any advice on creating a circuit ID > format > > for a brand new fiber network? > > > > > > Originally we ran a CLEC using a LECs copper, and our circuit ID was > > historically a telephone number for DSL circuits. The ILEC had a complex > > method for assigning circuit IDs. > > > > I am sure anything will work as long as you keep track of it, but any > > advice would be great! > > > From eising at nordu.net Tue Aug 22 07:36:39 2017 From: eising at nordu.net (Allan Eising) Date: Tue, 22 Aug 2017 08:36:39 +0100 Subject: Creating a Circuit ID Format In-Reply-To: References: Message-ID: <1503386202.plhmfv5pqi.eising@mbp1-eising.nordu.net> Excerpts from Colton Conor's message of August 21, 2017 10:26 pm: > We are building a new fiber network, and need help creating a circuit ID > format to for new fiber circuits. Is there a guide or standard for fiber > circuit formats? Does the circuit ID change when say a customer upgrades > for 100Mbps to 1Gbps port? > > What do the larger carriers do? Any advice on creating a circuit ID format > for a brand new fiber network? > > > Originally we ran a CLEC using a LECs copper, and our circuit ID was > historically a telephone number for DSL circuits. The ILEC had a complex > method for assigning circuit IDs. > > I am sure anything will work as long as you keep track of it, but any > advice would be great! > Hi, I see you have already received some very good suggestions. The key for me with circuit IDs are that they have to integrate well in your backend systems as well as your products. There is little point in creating a telcordia-like system if you will have trouble filling in all the fields in an automated way, just like it can be troublesome to keep an incrementing number accurate, if you don't have a good central database to track it in. Avoid creating a number system where the A-end and B-end is part of the ID if you have (or ever will have) logical multi-point circuits. Also avoid having circuit numbers that take assumptions of your country of operation if you ever have to deliver something cross-border. I happen to like the format of PREFIX-NUMBERS, where the prefix indicates some sort of broad type, and with such a form it is important not to have too restrictive prefix types. For example consider only having Fiber, Copper, and logical as types, or whatever makes sense in your operation. With too many similar types comes the risk of having disparity between what your circuit ID suggests, and what is actually out there. I would suggest that you keep separate IDs for the actual fiber in the ground, and the service the customer buys. That way you can track the customer subscription, modify the parameters of it, if the customer upgrades his speed, but separately track your fiber deployment. At a previous employer we had to implement Service IDs on an already existing network where everything previously had been using only the actual fiber IDs, and that was a painful process, so it's better to get these things right as early as possible. -- Best Regards Allan Eising IP Network Engineer NORDUnet A/S m: eising at nordu.net w: http://www.nordu.net From Daniel.Jameson at tdstelecom.com Tue Aug 22 18:11:43 2017 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Tue, 22 Aug 2017 18:11:43 +0000 Subject: Creating a Circuit ID Format In-Reply-To: References: Message-ID: What's the intended use of the Circuit ID? Internal ID, Stickered Customer CPE; Planning to carry other carriers circuits? With so many virtual components in circuits now, Where the circuit ID used to have some useful information, it's been largely reduced to a minimum amount of information that can get a customer/service tech in touch with the right tech support group. It's a-typical to provide a circuit-id for residential customers, they're typically reserved for business class services although there isn't anything that would prevent it other than managing the data/changes. 29/EC00/123456/002/MYCO/0 (prefix 2) usually a form of where the service originates (Commonly where the IP address is provisioned) Service type - format is up to the circuit owner. A common syntax is: First digit identifies the service delivery type - E = Ethernet A=ATM S=Sonet P=PON ... Second digit identifies the physical delivery type. A=64K B=1.5Mbps C=25Mbps D=45Mbps(STS1) E=100Mbps F=155Mbps(oc3) G=100Mbps H=466Mbps(oc9) I=622Mbps(oc12) J=1Gbps K=1.5Gbps L=2.5G M=10Gbps (oc192) N=13Gbps(oc255) O=25gpbs P=40Gbps(OC768) Q=100G ... Third and fourth digits identify the fractional provisioned rate as a % 00=100% 10=10% 25=25% Serial number - 6 digit alphanumeric serial number usually encoded with cust/location/ Suffix - used if cust/location for circuit count. Or generically as circuit count. (customer has 2 10G) Company Code - use up to 4 letter (this is the controller of the circuit) Segment - if it's a multi-segment circuit. Occasionally used to denote if a circuit is protection. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor Sent: Monday, August 21, 2017 2:26 PM To: NANOG Subject: Creating a Circuit ID Format We are building a new fiber network, and need help creating a circuit ID format to for new fiber circuits. Is there a guide or standard for fiber circuit formats? Does the circuit ID change when say a customer upgrades for 100Mbps to 1Gbps port? What do the larger carriers do? Any advice on creating a circuit ID format for a brand new fiber network? Originally we ran a CLEC using a LECs copper, and our circuit ID was historically a telephone number for DSL circuits. The ILEC had a complex method for assigning circuit IDs. I am sure anything will work as long as you keep track of it, but any advice would be great! From crhode at usf.edu Tue Aug 22 18:39:52 2017 From: crhode at usf.edu (Chris Rhode) Date: Tue, 22 Aug 2017 14:39:52 -0400 Subject: Contact at Charter Communications? Message-ID: Hello, I apologize if this is not the appropriate place to ask, however we have been trying to get in touch with someone at Charter Communications to see if they are blocking part of our IP range and have been unsuccessful in getting in touch with anybody.  I've contacted both the email address and called the phone number listed under the tech contact for brighthouse.com (which is the domain in question) listed on whois.icann.org and have not received any response.  Would someone please contact me off-list with someone who I might be able to reach out to in order to check on this? Thank you! -- *Chris Rhode *Network Engineer University of South Florida – Information Technology crhode at usf.edu From joe at nethead.com Thu Aug 24 00:30:03 2017 From: joe at nethead.com (Joe Hamelin) Date: Wed, 23 Aug 2017 17:30:03 -0700 Subject: Google DNS --- Figuring out which DNS Cluster you are using In-Reply-To: References: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> <1968162469.886870.1503520652959@mail.yahoo.com> Message-ID: Gee Chris, that's kind of an asinine response. Erik took the time to let us know about what he had found out, with a nice code snippet too. I don't have time in my job to just go surfing around google.com to see what is there. His mail took me about 2 minutes to read and now I know that such info exists. Thank you Erik! -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 On Wed, Aug 23, 2017 at 5:10 PM, Christopher Morrow wrote: > On Wed, Aug 23, 2017 at 4:37 PM, i mawsog via NANOG > wrote: > > > > > This is great. Thanks for sharing . > > > > Sent from Yahoo Mail on Android > > > > On Wed, Aug 23, 2017 at 1:11 PM, Erik Sundberg > > wrote: I sent this out on the outage list, with a lots of good feedback > > sent to me. So I figured it would be useful to share the information on > > nanog as well. > > > > > > A couple months ago had to troubleshoot a google DNS issue with Google’s > > NOC. Below is some helpful information on how to determine which DNS > > Cluster you are going to. > > > > Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 > and > > 8.8.4.4. Anycast routes your DNS queries to the closes DNS cluster based > on > > the best route / lowest metric to 8.8.8.8/8.8.4.4. Google has deployed > > multiple DNS clusters across the world and each DNS Cluster has multiple > > servers. > > > > So a DNS query in Chicago will go to a different DNS clusters than > queries > > from a device in Atlanta or New York. > > > > > > How to get a list of google DNS Cluster’s. > > dig -t TXT +short locations.publicdns.goog. @8.8.8.8 > > > > How to print this list in a table format. Script from: > > https://developers.google.com/speed/public-dns/faq > > --------------- > > #!/bin/bash > > IFS="\"$IFS" > > for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8) > > do > > case $LOC in > > '') : ;; > > *.*|*:*) printf '%s ' ${LOC} ;; > > *) printf '%s\n' ${LOC} ;; > > esac > > done > > --------------- > > > > Which will give you a list like below. This is all of the IP network’s > > that google uses for their DNS Clusters and their associated locations. > > > > 74.125.18.0/26 iad > > 74.125.18.64/26 iad > > 74.125.18.128/26 syd > > 74.125.18.192/26 lhr > > 74.125.19.0/24 mrn > > 74.125.41.0/24 tpe > > 74.125.42.0/24 atl > > 74.125.44.0/24 mrn > > 74.125.45.0/24 tul > > 74.125.46.0/24 lpp > > 74.125.47.0/24 bru > > 74.125.72.0/24 cbf > > 74.125.73.0/24 bru > > 74.125.74.0/24 lpp > > 74.125.75.0/24 chs > > 74.125.76.0/24 cbf > > 74.125.77.0/24 chs > > 74.125.79.0/24 lpp > > 74.125.80.0/24 dls > > 74.125.81.0/24 dub > > 74.125.92.0/24 mrn > > 74.125.93.0/24 cbf > > 74.125.112.0/24 lpp > > 74.125.113.0/24 cbf > > 74.125.115.0/24 tul > > 74.125.176.0/24 mrn > > 74.125.177.0/24 atl > > 74.125.179.0/24 cbf > > 74.125.181.0/24 bru > > 74.125.182.0/24 cbf > > 74.125.183.0/24 cbf > > 74.125.184.0/24 chs > > 74.125.186.0/24 dls > > 74.125.187.0/24 dls > > 74.125.190.0/24 sin > > 74.125.191.0/24 tul > > 172.217.32.0/26 lhr > > 172.217.32.64/26 lhr > > 172.217.32.128/26 sin > > 172.217.33.0/26 syd > > 172.217.33.64/26 syd > > 172.217.33.128/26 fra > > 172.217.33.192/26 fra > > 172.217.34.0/26 fra > > 172.217.34.64/26 bom > > 172.217.34.192/26 bom > > 172.217.35.0/24 gru > > 172.217.36.0/24 atl > > 172.217.37.0/24 gru > > 173.194.90.0/24 cbf > > 173.194.91.0/24 scl > > 173.194.93.0/24 tpe > > 173.194.94.0/24 cbf > > 173.194.95.0/24 tul > > 173.194.97.0/24 chs > > 173.194.98.0/24 lpp > > 173.194.99.0/24 tul > > 173.194.100.0/24 mrn > > 173.194.101.0/24 tul > > 173.194.102.0/24 atl > > 173.194.103.0/24 cbf > > 173.194.168.0/26 nrt > > 173.194.168.64/26 nrt > > 173.194.168.128/26 nrt > > 173.194.168.192/26 iad > > 173.194.169.0/24 grq > > 173.194.170.0/24 grq > > 173.194.171.0/24 tpe > > 2404:6800:4000::/48 bom > > 2404:6800:4003::/48 sin > > 2404:6800:4006::/48 syd > > 2404:6800:4008::/48 tpe > > 2404:6800:400b::/48 nrt > > 2607:f8b0:4001::/48 cbf > > 2607:f8b0:4002::/48 atl > > 2607:f8b0:4003::/48 tul > > 2607:f8b0:4004::/48 iad > > 2607:f8b0:400c::/48 chs > > 2607:f8b0:400d::/48 mrn > > 2607:f8b0:400e::/48 dls > > 2800:3f0:4001::/48 gru > > 2800:3f0:4003::/48 scl > > 2a00:1450:4001::/48 fra > > 2a00:1450:4009::/48 lhr > > 2a00:1450:400b::/48 dub > > 2a00:1450:400c::/48 bru > > 2a00:1450:4010::/48 lpp > > 2a00:1450:4013::/48 grq > > > > > isn't this list also here: > https://developers.google.com/speed/public-dns/faq#locations > > I mean, you could read the docs first to get the same answer, I think... > right? > I'm also pretty sure there are RIPE Atlas measurements of 8.8.8.8/8.8.4.4 > that could tell you from which source-asn a backend sees traffic from.. > right? (or with a tiny bit of thought one could be proposed/executed) > > > > There are > > IPv4 Networks: 68 > > IPv6 Networks: 20 > > DNS Cluster’s Identified by POP Code’s: 20 > > > > DNS Clusters identified by POP Code to City, State, or Country. Not all > of > > these are Google’s Core Datacenters, some of them are Edge Points of > > Presences (POPs). https://peering.google.com/#/infrastructure and > > https://www.google.com/about/datacenters/inside/locations/ > > > > Most of these are airport codes, it did my best to get the location > > correct. > > iad Washington, DC > > syd Sydney, Australia > > lhr London, UK > > mrn Lenoir, NC > > tpe Taiwan > > atl Altanta, GA > > tul Tulsa, OK > > lpp Findland > > bru Brussels, Belgium > > cbf Council Bluffs, IA > > chs Charleston, SC > > dls The Dalles, Oregon > > dub Dublin, Ireland > > sin Singapore > > fra Frankfort, Germany > > bom Mumbai, India > > gru Sao Paulo, Brazil > > scl Santiago, Chile > > nrt Tokyo, Japan > > grq Groningen, Netherlans > > > > > > > > Which Google DNS Server Cluster am I using. I am testing this from > > Chicago, IL > > > > # dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 > > "173.194.94.135" <<<<< > list above to get the cluster, Council Bluffs, IA > > "edns0-client-subnet 207.xxx.xxx.0/24" > > <<<< Your Source IP Block > > > > > > Side note, the google dns servers will not respond to DNS queries to the > > Cluster’s Member’s IP, they will only respond to dns queries to 8.8.8.8 > and > > 8.8.4.4. So the following will not work. > > dig google.com @173.194.94.135 > > > > > > > > Now to see the DNS Cluster load balancing in action. I am doing a dig > > query from our Telx\Digital Realty POP in Atlanta, GA. We do peer with > > google at this location. > > > > I dig a dig query about 10 times and received the following unique dns > > cluster member ip’s as responses. > > > > dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 > > "74.125.42.138" > > "173.194.102.132" > > "74.125.177.5" > > "74.125.177.74" > > "74.125.177.71" > > "74.125.177.4" > > > > Which all are Google DNS Networks in Atlanta. > > 74.125.42.0/24 > > > > atl > > > > 74.125.177.0/24 > > > > atl > > > > 172.217.36.0/24 > > > > atl > > > > 173.194.102.0/24 > > > > atl > > > > 2607:f8b0:4002::/48 > > > > atl > > > > > > > > Just thought it would be helpful when troubleshooting google DNS issues. > > > > > > ________________________________ > > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, > files > > or previous e-mail messages attached to it may contain confidential > > information that is legally privileged. If you are not the intended > > recipient, or a person responsible for delivering it to the intended > > recipient, you are hereby notified that any disclosure, copying, > > distribution or use of any of the information contained in or attached to > > this transmission is STRICTLY PROHIBITED. If you have received this > > transmission in error please notify the sender immediately by replying to > > this e-mail. You must destroy the original transmission and its > attachments > > without reading or saving in any manner. Thank you. > > > > > From nanog at shat.net Thu Aug 24 04:21:28 2017 From: nanog at shat.net (Shaun) Date: Wed, 23 Aug 2017 23:21:28 -0500 Subject: Google DNS --- Figuring out which DNS Cluster you are using In-Reply-To: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> References: <495D0934DA46854A9CA758393724D590A5FD813E@NI-MAIL02.nii.ads> Message-ID: <20170823232128.99DA.B2447BB2@shat.net> On Wed, 23 Aug 2017 20:09:49 +0000 Erik Sundberg wrote: > Which Google DNS Server Cluster am I using. I am testing this from Chicago, IL > > # dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8 > "173.194.94.135" <<<<< "edns0-client-subnet 207.xxx.xxx.0/24" <<<< Your Source IP Block Worth noting, this record has TTL 60 and caching can cause unexpected responses; you may have to try a few times to get the correct data. My first attempt gave me an unrecognized "edns0-client-subnet" and a Google IP from Finland when I was querying from Atlanta. -s From alumbis at gmail.com Fri Aug 18 18:08:01 2017 From: alumbis at gmail.com (Pete Lumbis) Date: Fri, 18 Aug 2017 14:08:01 -0400 Subject: DevOps workflow for networking In-Reply-To: References: Message-ID: Awesome! I gave a presentation on CI/CD for networking last year at the Interop conference; my demo was based on Gitlab https://gitlab.com/plumbis/cumulus-ci-cd/ I use Behave for testing, but it is just a front end for python code under the hood to actually validate that everything is doing what it's supposed to be doing. I did a little bit of work to try and get Ansible to do checking and validation in a playbook, but since Ansible isn't really a programming language it felt like putting a square peg in a round hole. I would recommend an actual programming language or testing frame work. Likely the biggest challenge you'll encounter is a lack of features in vendor VMs and the fact you can't change interface names. Generally, in production, we don't have "eth1, eth2, eth3" as the cabled up interfaces, so you end up needing to maintain two sets of configs (prod and test) or something to modify production configs on the fly, both of which are crummy options. >From a workflow perspective, you can treat configuration like code and run full test suites when pull requests are issued and then use the test results as the basis for a change review meeting. Don't let humans talk about changes that we already know won't work. Glad to hear about other people seriously considering CI/CD in the network space, good luck! -Pete On Wed, Aug 9, 2017 at 8:52 PM, Kasper Adel wrote: > We are pretty new to those new-age network orchestrators and automation, > > I am curious to ask what everyone is the community is doing? sorry for such > a long and broad question. > > What is your workflow? What tools are your teams using? What is working > what is not? What do you really like and what do you need to improve? How > mature do you think your process is? etc etc > > Wanted to ask and see what approaches the many different teams here are > taking! > > We are going to start working from a GitLab based workflow. > > Projects are created, issues entered and developed with a gitflow branching > strategy. > > GitLab CI pipelines run package loadings and run tests inside a lab. > > Tests are usually python unit tests that are run to do both functional and > service creation, modification and removal tests. > > For unit testing we typically use python libraries to open transactions to > do the service modifications (along with functional tests) against physical > lab devices. > > For our prod deployment we leverage 'push on green' and gating to push > package changes to prod devices. > > Thanks > From cjwolff at nola.gov Thu Aug 10 13:56:42 2017 From: cjwolff at nola.gov (Christopher J. Wolff) Date: Thu, 10 Aug 2017 13:56:42 +0000 Subject: (Network Orchestrators evaluation) : tail-f vs Anuta vs UBIqube vs OpenDaylight In-Reply-To: References: Message-ID: <47F264CE123954429FC99B9E768819F224FB3E01@CNO-XCH03.cityofno.com> Haven't looked at Cisco DNA yet? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kasper Adel Sent: Wednesday, August 9, 2017 8:02 PM To: NANOG list Subject: (Network Orchestrators evaluation) : tail-f vs Anuta vs UBIqube vs OpenDaylight Hi, This is not a vendor bashing thread. We are a group of networking engineers less experience with software) in the middle of the process of procuring a network automation/orchestration controller, if that is even a good definition and we are clueless on how to evaluate them. Other than the obvious, which is to try them out, i wonder what else is important to consider/watch out for. We are presented with 3 different vendors and even OpenDayLight was considered as the open source alternative. My humble thoughts are given below and i would appreciate getting 'schooled' on what i need to ask the vendors: 1) Are they Model driven : But i still don't know how to evaluate that. 2) Do they parse Cisco/Juniper CLI or they are limited to SNMP and YANG. 3) If they do parse, we want to check if they'll hold us by the balls if the current parsers need to be updated, i.e: can we change the code ourselves and add new features to be parsed. 4) Can they work/orchestrate between CLI devices and Non CLI devices (SNMP) 5) How flexible are they to support different Vendors (Cisco, Juniper, some-weird-firewall...etc) thanks, Kim From christopher.morrell.nanog at gmail.com Wed Aug 16 22:29:34 2017 From: christopher.morrell.nanog at gmail.com (Christopher Morrell) Date: Wed, 16 Aug 2017 22:29:34 +0000 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: Message-ID: Let’s not forget that all POTS and cell service was offline during the outage - even for local and 911 service. There is some high level of dependence on some equipment in Quebec and/or westward which should not be there. A double fault like that should not knock out all local service for 4 out of 10 provinces. I would expect that an architectural review is under way. On Wed, Aug 16, 2017 at 16:14 Paul Stewart wrote: > It wasn’t an issue getting transatlantic - it was an issue within a > relatively small region in Eastern Canada talking to the rest of the world > for certain carriers. There were several smaller carriers/providers not > affected - just happens the local incumbent telco and one of their larger > competitors got knocked out … > > > > On Aug 15, 2017, at 3:52 PM, Jared Mauch wrote: > > > > > >> On Aug 15, 2017, at 1:22 PM, Rod Beck > wrote: > >> > >> Did we ever get any resolution on why this was such a big outage? > Appears there were two fiber cuts. Were the fibers damaged in the same > conduit? Is this a collapsed ring scenario? > >> > >> > >> > http://www.cbc.ca/news/canada/newfoundland-labrador/concerns-about-backup-bell-outage-1.4239064 > > > > Perhaps some transatlantic fallback? It looks like the only cable out > there is the Greenland one.. guessing that’s not very competitive? It only > gets you to Iceland it seems. > > > > - Jared > > From lathama at gmail.com Thu Aug 24 15:14:04 2017 From: lathama at gmail.com (Andrew Latham) Date: Thu, 24 Aug 2017 10:14:04 -0500 Subject: DevOps workflow for networking In-Reply-To: References: Message-ID: Related I am working on https://github.com/lathama/Adynaton and hope to get parts into the Python Standard Library with help from some peers. Anyone who wants to help out ping me off list. On Fri, Aug 18, 2017 at 1:08 PM, Pete Lumbis wrote: > Awesome! > > I gave a presentation on CI/CD for networking last year at the Interop > conference; my demo was based on Gitlab > https://gitlab.com/plumbis/cumulus-ci-cd/ > > I use Behave for testing, but it is just a front end for python code under > the hood to actually validate that everything is doing what it's supposed > to be doing. > > I did a little bit of work to try and get Ansible to do checking and > validation in a playbook, but since Ansible isn't really a programming > language it felt like putting a square peg in a round hole. I would > recommend an actual programming language or testing frame work. > > Likely the biggest challenge you'll encounter is a lack of features in > vendor VMs and the fact you can't change interface names. Generally, in > production, we don't have "eth1, eth2, eth3" as the cabled up interfaces, > so you end up needing to maintain two sets of configs (prod and test) or > something to modify production configs on the fly, both of which are crummy > options. > > From a workflow perspective, you can treat configuration like code and run > full test suites when pull requests are issued and then use the test > results as the basis for a change review meeting. Don't let humans talk > about changes that we already know won't work. > > Glad to hear about other people seriously considering CI/CD in the network > space, good luck! > > -Pete > > On Wed, Aug 9, 2017 at 8:52 PM, Kasper Adel wrote: > > > We are pretty new to those new-age network orchestrators and automation, > > > > I am curious to ask what everyone is the community is doing? sorry for > such > > a long and broad question. > > > > What is your workflow? What tools are your teams using? What is working > > what is not? What do you really like and what do you need to improve? How > > mature do you think your process is? etc etc > > > > Wanted to ask and see what approaches the many different teams here are > > taking! > > > > We are going to start working from a GitLab based workflow. > > > > Projects are created, issues entered and developed with a gitflow > branching > > strategy. > > > > GitLab CI pipelines run package loadings and run tests inside a lab. > > > > Tests are usually python unit tests that are run to do both functional > and > > service creation, modification and removal tests. > > > > For unit testing we typically use python libraries to open transactions > to > > do the service modifications (along with functional tests) against > physical > > lab devices. > > > > For our prod deployment we leverage 'push on green' and gating to push > > package changes to prod devices. > > > > Thanks > > > -- - Andrew "lathama" Latham lathama at gmail.com http://lathama.com - From amitchell at isipp.com Thu Aug 24 16:34:25 2017 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Thu, 24 Aug 2017 10:34:25 -0600 Subject: AT&T NOC contact? In-Reply-To: References: Message-ID: > > Hello, > > Is there someone at AT&T on the mailing list I can talk to regarding a > possible routing loop getting from AT&T to Box? > Sahil - have pinged our AT&T contact ..will let you know what I hear. Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Attorney at Law / Legislative Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Author: The Email Deliverability Handbook Member, California Bar Cyberspace Law Committee Member, Colorado Cybersecurity Consortium Member, Board of Directors, Asilomar Microcomputer Workshop Member, Advisory Board, Cause for Awareness Member, Board of Directors, Greenwood Wildlife Rehabilitation Member, Elevations Credit Union Member Council Former Chair, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Available for consultations by special arrangement. amitchell at isipp.com | @AnnePMitchell Facebook/AnnePMitchell | LinkedIn/in/annemitchell From sganguly at box.com Thu Aug 24 16:35:46 2017 From: sganguly at box.com (Sahil Ganguly) Date: Thu, 24 Aug 2017 09:35:46 -0700 Subject: AT&T NOC contact? In-Reply-To: References: Message-ID: Hello, Thank you for checking, the issue was resolved. On Thu, Aug 24, 2017 at 7:52 AM, Nimrod Levy wrote: > There was a message to the outages list over the weekend on this, has this > issue not been resolved? > > On Thu, Aug 24, 2017 at 10:38 AM Sahil Ganguly via NANOG > wrote: > >> Hello, >> >> Is there someone at AT&T on the mailing list I can talk to regarding a >> possible routing loop getting from AT&T to Box? >> >> Thanks! >> >> -- >> Sahil Ganguly >> Senior Network Operations Engineer >> >> >> M: 303.250.8893 <(303)%20250-8893> >> 900 Jefferson Ave >> Redwood City, CA 94063 >> > -- > > -- > Nimrod > -- Sahil Ganguly Senior Network Operations Engineer M: 303.250.8893 900 Jefferson Ave Redwood City, CA 94063 From amitchell at isipp.com Thu Aug 24 16:35:50 2017 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Thu, 24 Aug 2017 10:35:50 -0600 Subject: Contact at Charter Communications? In-Reply-To: References: Message-ID: <922F9E5F-ACC9-4162-BE47-A56E41FC7F87@isipp.com> Hi Chris! I've pinged our contact at Charter, will let you know if I come up with a contact for you. Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Attorney at Law / Legislative Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Author: The Email Deliverability Handbook Member, California Bar Cyberspace Law Committee Member, Colorado Cybersecurity Consortium Member, Board of Directors, Asilomar Microcomputer Workshop Member, Advisory Board, Cause for Awareness Member, Board of Directors, Greenwood Wildlife Rehabilitation Member, Elevations Credit Union Member Council Former Chair, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Available for consultations by special arrangement. amitchell at isipp.com | @AnnePMitchell Facebook/AnnePMitchell | LinkedIn/in/annemitchell From rod.beck at unitedcablecompany.com Thu Aug 24 17:00:23 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 24 Aug 2017 17:00:23 +0000 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: <1502827673.408249.1074473208.501C5274@webmail.messagingengine.com>, Message-ID: Unless I am mistaken, that is an old legacy route. I don't think it is a new build. I know at one time Hibernia was selling its undersea link from Halifax to Boston as a back up for that route. On the other hand, there have been some Canadian carrier builds recently so may be it's not legacy. Regards, Roderick ________________________________ From: NANOG on behalf of Fletcher Kittredge Sent: Wednesday, August 16, 2017 10:29 PM To: Clinton Work Cc: NANOG list Subject: Re: Last Week's Canadian Fiber Cut There is a third route from Halifax -> New Brunswick -> Portland, ME -> [Albany, Boston] On Tue, Aug 15, 2017 at 4:07 PM, Clinton Work wrote: > I can't speak for the Bell Aliant network, but I'm only aware of two > diverse fiber routes out of Halifax, Nova Scotia. Halifax -> New > Brunswick -> Quebec City is the Canadian route and Halifax -> Boston is > the diverse route. > > On Tue, Aug 15, 2017, at 01:52 PM, Jared Mauch wrote: > > Perhaps some transatlantic fallback? It looks like the only cable out > > there is the Greenland one.. guessing that’s not very competitive? It > > only gets you to Iceland it seems. > > > > -- Fletcher Kittredge GWI 207-602-1134 www.gwi.net GWI: Phone and High Speed Internet services for your Maine ... www.gwi.net GWI Home and Business Phone and High Speed Internet services in Maine. Business Wide Area Networks, Hosted PBX, cloud computing and data center services. From jfmezei_nanog at vaxination.ca Thu Aug 24 17:51:54 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 24 Aug 2017 13:51:54 -0400 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: Message-ID: <8a7d43f7-b87d-1cca-b23e-63a108523da6@vaxination.ca> On 2017-08-16 18:29, Christopher Morrell wrote: > Let’s not forget that all POTS and cell service was offline during the > outage - even for local and 911 service. It would be interesting to know how incumbent telco services within Aliant territory became dependent on a link to central Canada. Whenh on dials 911 in Moncton, does it require some database inquiry to some database in Toronto, failing which, the call can't go through? (Aliant, which used to be separate maritime telcos was bought lock stock and barrel by Bell Canada a couple years ago, so likely rationlized some services to save costs, so anything that became dependent on some Toronto server would stop working) The CRTC asked Bell for a report on what happened, but told media that report may not be made public. From nanog at ics-il.net Thu Aug 24 18:22:43 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 24 Aug 2017 13:22:43 -0500 (CDT) Subject: Cogent Chicago In-Reply-To: <295793127.4275.1503598752088.JavaMail.mhammett@ThunderFuck> Message-ID: <655739452.4281.1503598962425.JavaMail.mhammett@ThunderFuck> I'm looking for someone knowledgeable as to how some of their datacenter POPs interconnect. Trying to determine what level of diversity other than POP location there are between two datacenters. Cogent staff is fine, maybe even preferred. Unsurprisingly, the sales person I talked to wasn't incredibly useful. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From bill at herrin.us Thu Aug 24 19:54:21 2017 From: bill at herrin.us (William Herrin) Date: Thu, 24 Aug 2017 15:54:21 -0400 Subject: Creating a Circuit ID Format In-Reply-To: <1503386202.plhmfv5pqi.eising@mbp1-eising.nordu.net> References: <1503386202.plhmfv5pqi.eising@mbp1-eising.nordu.net> Message-ID: On Tue, Aug 22, 2017 at 3:36 AM, Allan Eising wrote: > it can be > troublesome to keep an incrementing number accurate, if you don't have a > good > central database to track it in. > That reminds me: You will buy out other organizations' assets with other organizations' identifiers. When you build your central database, make sure it can accept the arbitrary circuit ID formats applied to your new property. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From arshad.rad at gmail.com Wed Aug 2 16:37:27 2017 From: arshad.rad at gmail.com (Mehrdad Arshad Rad) Date: Wed, 02 Aug 2017 16:37:27 -0000 Subject: vFlow v0.4.1 :: IPFIX, sFlow and Netflow collector (open source) Message-ID: Hi All, Sorry for spamming, I just wanted to update you for vFlow v0.4.1 (High-performance, scalable and reliable IPFIX, sFlow and Netflow collector.) Now you can install it very easily through RPM or Debian package also the MS Windows binary is available (or you can compile it through a command) It's written with pure Golang and it works in production under heavy load! New features: Netflow v9 protocol, support NATS (message bus, nats.io), MS Windows support! You can download it at https://github.com/VerizonDigital/vflow/releases/tag/v0.4.1 All features: - IPFIX RFC7011 collector - sFLow v5 raw header packet collector - Netflow v9 collector - Decoding sFlow raw header L2/L3/L4 - Produce to Apache Kafka, NSQ, NATS - Replicate IPFIX to 3rd party collector - Supports IPv4 and IPv6 There are two quick start docs : - vFlow with NSQ: https://github.com/VerizonDigital/vflow/blob/master/docs/quick_start_nsq.md - vFlow with Kafka: https://github.com/VerizonDigital/vflow/blob/master/docs/quick_start_kafka.md All docs: https://github.com/VerizonDigital/vflow/tree/master/docs Please let me know if you have any questions/suggestions or open an issue at GitHub. https://github.com/verizonDigital/vflow Thanks, Mehrdad -- *M*ehrdad Arshad Rad *P*rincipal Software Engineer https://www.linkedin.com/in/mehrdadrad From fkittred at gwi.net Thu Aug 24 18:49:28 2017 From: fkittred at gwi.net (Fletcher Kittredge) Date: Thu, 24 Aug 2017 14:49:28 -0400 Subject: Last Week's Canadian Fiber Cut In-Reply-To: References: <1502827673.408249.1074473208.501C5274@webmail.messagingengine.com> Message-ID: On Thu, Aug 24, 2017 at 1:00 PM, Rod Beck wrote: > Unless I am mistaken, that is an old legacy route. I don't think it is a > new build. I know at one time Hibernia was selling its undersea link from > Halifax to Boston as a back up for that route. On the other hand, there > have been some Canadian carrier builds recently so may be it's not legacy. > No, this is not a legacy route. It was a new route constructed in 2012 as part of the Federal BTOP ARRA program. It is a 1,100 mile high strand count fiber ring around Maine with multiple border crossings. Dozens of carriers are using it. -- Fletcher Kittredge GWI From gabe at rtegroup.com Thu Aug 17 10:35:11 2017 From: gabe at rtegroup.com (Gabe Cole) Date: Thu, 17 Aug 2017 06:35:11 -0400 Subject: Telekom Malaysia Contact Message-ID: <48396247-E782-431E-B884-25B542285152@rtegroup.com> I am working on some subsea cables that need to transit in Malaysia and need a contact at Telekom Malaysia. Thanks in advance! Gabe Cole +1-617-303-8707 gabe at rtegroup.com @datacenterguru From marc.gimeno at adamo.es Wed Aug 23 15:26:54 2017 From: marc.gimeno at adamo.es (Marc Gimeno) Date: Wed, 23 Aug 2017 17:26:54 +0200 Subject: How can I obtain the abuse e-mail address for IPs from Japan? In-Reply-To: References: Message-ID: Maybe simple whois from debian machine. Then he looks to related Regional Internet address Registry, in this case, APNIC. I mark it in *bold*. hois 59.106.13.181 % [whois.apnic.net] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html % Information related to '59.106.0.0 - 59.106.255.255' % Abuse contact for '59.106.0.0 - 59.106.255.255' is 'hostmaster at nic.ad.jp' inetnum: 59.106.0.0 - 59.106.255.255 netname: SAKURA descr: SAKURA Internet Inc. descr: Grandfront Osaka Bldg. Tower-A 35F, 4-20, Ofukacho, Kita-ku, Osaka 530-0011 Japan country: JP admin-c: JNIC1-AP tech-c: JNIC1-AP status: ALLOCATED PORTABLE *remarks: Email address for spam or abuse complaints : support at sakura.ad.jp * mnt-by: MAINT-JPNIC mnt-irt: IRT-JPNIC-JP mnt-lower: MAINT-JPNIC changed: hm-changed at apnic.net 20041013 changed: ip-apnic at nic.ad.jp 20070523 changed: hm-changed at apnic.net 20151202 changed: ip-apnic at nic.ad.jp 20170703 source: APNIC irt: IRT-JPNIC-JP address: Urbannet-Kanda Bldg 4F, 3-6-2 Uchi-Kanda address: Chiyoda-ku, Tokyo 101-0047, Japan e-mail: hostmaster at nic.ad.jp abuse-mailbox: hostmaster at nic.ad.jp admin-c: JNIC1-AP tech-c: JNIC1-AP auth: # Filtered mnt-by: MAINT-JPNIC changed: abuse at apnic.net 20101108 changed: hm-changed at apnic.net 20101111 changed: ip-apnic at nic.ad.jp 20140702 source: APNIC *_____________________________* *Marc Gimeno* *NOC* *_____________________________* Adamo Telecom Iberia S.A.U. www.adamo.es On Wed, Aug 23, 2017 at 5:16 PM, Kurt Kraut wrote: > Hello Suresh, > > > It doesn't seem to help a lot: > > ktk at ktk:~$ whois -h whois.nic.ad.jp 59.106.13.181 > [ JPNIC database provides information regarding IP address and ASN. Its use > ] > [ is restricted to network administration purposes. For further > information, ] > [ use 'whois -h whois.nic.ad.jp help'. To only display English output, > ] > [ add '/e' at the end of command, e.g. 'whois -h whois.nic.ad.jp xxx/e'. > ] > > Network Information: > a. [Network Number] 59.106.12.0-59.106.27.255 > b. [Network Name] SAKURA-NET > g. [Organization] SAKURA Internet Inc. > m. [Administrative Contact] KT749JP > n. [Technical Contact] KW419JP > p. [Nameserver] ns1.dns.ne.jp > p. [Nameserver] ns2.dns.ne.jp > [Assigned Date] 2004/11/24 > [Return Date] > [Last Update] 2004/11/24 18:41:02(JST) > > Less Specific Info. > ---------- > SAKURA Internet Inc. > [Allocation] > 59.106.0.0/16 > > More Specific Info. > > > > No e-mail addresses of the abuse team or NOC or SOC. > > > Best regards, > > > Kurt Kraut > > 2017-08-23 11:55 GMT-03:00 Suresh Ramasubramanian : > > > whois -h whois.nic.ad.jp IP /e > > > > --srs > > > > > On 23-Aug-2017, at 7:38 PM, Kurt Kraut wrote: > > > > > > Hello, > > > > > > > > > I'm having a hard time to figure out the abuse e-mail address for IPs > > from > > > Japan. Any query I perform at the WHOIS, for any IP, from any > autonomoyus > > > system I get the same e-mail addresses: > > > > > > abuse at apnic.net > > > hm-changed at apnic.net > > > ip-apnic at nic.ad.jp > > > hostmaster at nic.ad.jp > > > > > > These e-mail addresses belong to JPNIC, not the autonomous system > itself. > > > So any messages sent to these e-mail addresses will not reach the > > offending > > > NOC/SOC so I can report vulnerabilities and DDoS attacks. > > > > > > What am I missing and how should I report security issues to autonomous > > > systems from this region? Has anyone here any experience on this? > > > > > > > > > Thanks in advance, > > > > > > > > > Kurt Kraut > > > From me at robbiet.us Thu Aug 24 02:43:17 2017 From: me at robbiet.us (Robbie Trencheny) Date: Wed, 23 Aug 2017 19:43:17 -0700 Subject: AWS internal networking team contact? Message-ID: Hey all, We are seeing major packet loss and high latency at a Level3 node just before the hop into AWS us-west-2. We had a go live planned for today which has now been scrapped because T-Mobile customers (a significant chunk of our customer base) nationwide are unable to login to our app. AWS Support is dragging their feet waiting to hear back from their internal networking team and didn't even believe they peered with Level3 at us-west-2 and we just don't have the time. CEO is talking about pulling the plug entirely on us-west-2 if not all of AWS and re-deploying to us-east-X or GCP. If someone from AWS could reach out off list to help expedite my ticket and get in contact with Level3 to fix their Seattle nodes i'd really appreciate it. It's already 740 on the west coast and I don't think i'm going home anytime soon. :( For those interested, failing nodes i'm seeing are ae-1-51.ear2.Seattle1.Level3.net and ae-2-52.ear2.Seattle1.Level3.net . Confirmed that T-Mobile is routing through those nodes from both SF and NYC. Apple also rejected our app during review this morning because of network failures while on wifi which I have to assume are the same ones we've been seeing for the last 96 hours. Thanks From steve at stevelerner.com Wed Aug 23 12:15:04 2017 From: steve at stevelerner.com (Steve Lerner) Date: Wed, 23 Aug 2017 08:15:04 -0400 Subject: unsubscribe Message-ID: On Wed, Aug 23, 2017 at 8:00 AM, wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Creating a Circuit ID Format (Tassos Chatzithomaoglou) > 2. Re: Creating a Circuit ID Format (Jared Mauch) > 3. 2017 NANOG Elections General Information (Dave Temkin) > 4. Re: Creating a Circuit ID Format (Justin M. Streiner) > 5. Re: Creating a Circuit ID Format (Nick Hilliard) > 6. Spectrum web cache engineer (Andrew Kirch) > 7. RE: Creating a Circuit ID Format (Timothy Creswick) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 Aug 2017 19:01:56 +0300 > From: Tassos Chatzithomaoglou > To: NANOG > Subject: Re: Creating a Circuit ID Format > Message-ID: <6b76d308-1a55-af42-c7cd-195d77147a3b at forthnet.gr> > Content-Type: text/plain; charset=UTF-8 > > I don't know if it has any relation to your issue, but we use Circuit-ID > to uniquely identify the access node plus the customer's access loop > logical port on the access node. > Access node can be either a DSLAM, a switch, an OLT, etc. > > You may have a look at BBF's TR-101 (section 3.9.3) or TR-156 (section > 5.7) for syntax guide . > > -- > Tassos > > Colton Conor wrote on 21/8/17 23:26: > > We are building a new fiber network, and need help creating a circuit ID > > format to for new fiber circuits. Is there a guide or standard for fiber > > circuit formats? Does the circuit ID change when say a customer upgrades > > for 100Mbps to 1Gbps port? > > > > What do the larger carriers do? Any advice on creating a circuit ID > format > > for a brand new fiber network? > > > > > > Originally we ran a CLEC using a LECs copper, and our circuit ID was > > historically a telephone number for DSL circuits. The ILEC had a complex > > method for assigning circuit IDs. > > > > I am sure anything will work as long as you keep track of it, but any > > advice would be great! > > > > > > ------------------------------ > > Message: 2 > Date: Tue, 22 Aug 2017 12:37:08 -0400 > From: Jared Mauch > To: Tassos Chatzithomaoglou > Cc: NANOG > Subject: Re: Creating a Circuit ID Format > Message-ID: <2AF810AB-E963-4CD4-867C-3D96B73A4C8C at puck.nether.net> > Content-Type: text/plain; charset=us-ascii > > > > On Aug 22, 2017, at 12:01 PM, Tassos Chatzithomaoglou < > achatz at forthnet.gr> wrote: > > > > I don't know if it has any relation to your issue, but we use Circuit-ID > to uniquely identify the access node plus the customer's access loop > logical port on the access node. > > Access node can be either a DSLAM, a switch, an OLT, etc. > > > > You may have a look at BBF's TR-101 (section 3.9.3) or TR-156 (section > 5.7) for syntax guide . > > > My favorite circuit-ids were those from MFS where it had the service type > (2 chars i think) + a pop-code + z pop-code + service count number. > > We could then tell what pop/facility everything was handed off at easily > enough. I think my house even got a MFS pop code at one time due to the T1 > which was there. > > - Jared > > ------------------------------ > > Message: 3 > Date: Tue, 22 Aug 2017 10:21:32 -0700 > From: Dave Temkin > To: "North American Network Operators' Group" > Subject: 2017 NANOG Elections General Information > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hello NANOGers! > > We are once again approaching the annual NANOG election > and appointment time. Board > candidate nominations open August 7th and the complete Election timeline > can be found here . We encourage > those in the community who are not currently NANOG members to consider > becoming members of NANOG and to consider standing for a position in our > leadership. Through membership and voting, you will be an active > participant in directing all NANOG activities. > > Only NANOG members are eligible to nominate, be a candidate, vote, and > serve in the NANOG Board of Directors and Committees. Click here > to become a member today! **If you are > not a member and wish to vote in this election, your membership must be > received by 9:00 a.m. Pacific Time on Wednesday, October 4, 2017.** > > Why? > > NANOG is at its strongest and best when there is an engaged group of > members. If you care about NANOG and would like to take a turn at > volunteering your time, please consider becoming part of the team by taking > part in the nomination and election process. If you know someone else that > you believe would be interested in serving on the Board of Directors, > nominate them by completing the Online Process > beginning August 7, 2017. Any > questions should be submitted to elections at nanog.org. > > As I spoke about during my opening at NANOG 70, diversity is key to the > viability of the NANOG community. Personally, it concerns me that our only > non-white, non-male elected member of the Board is leaving the board this > year, having served the maximum allowable number of terms. While everyone > is welcome, it is important that we represent our community well at all > levels and so if you or someone you know could help improve that > representation, please consider the nomination process. > > As NANOG continues to evolve, our Board of Directors and Committees will > continue to play an increasingly important role in our success. By joining > now, you can be an integral part of the process. > > For more information about the role of a Board of Director or any Committee > Member, or to find out more about what's involved in serving, please > consult the current NANOG Bylaws > October2016.pdf> > or follow the links to the Board and Committee pages from the General 2017 > NANOG Elections Page . > > > Best regards, > > Dave Temkin > On behalf of the NANOG Board of Directors > > > ------------------------------ > > Message: 4 > Date: Tue, 22 Aug 2017 16:50:40 -0400 (EDT) > From: "Justin M. Streiner" > To: James Bensley > Cc: NANOG > Subject: Re: Creating a Circuit ID Format > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Tue, 22 Aug 2017, James Bensley wrote: > > > In my opinion the circuit ID should be an abitrary (but unique) value > > and nothing more. As Nick suggested start at 1 and go up. If your > > company is called ABC Ltd then maybe have your first circuit ID as > > ABC00000001 and count up from there, it's as simple as that. > > > > For me, all the circuit ID should be is a record number/ID of a > > database entry and nothing more (or a search string). Some people like > > to have circuit IDs which include circuit types, or circuit speeds, or > > interface type, but as you asked, do you then change the circuit ID if > > the circuit speed changes, or the interface types changes, or the > > medium etc? > > Agreed. I designed something similar at a previous employer, and it just > used a date-coded ID with sequence number (ex: UOP 20170822.0001), and > then all of the cross-connect details were recorded in a place that was > better suited to capturing that sort of information. That would also > allow us to re-use fiber paths when we upgraded 1G links to 10G, etc. > > This also included IDs that could reference other circuit IDs - including > circuit IDs from other providers - so we could tie non-dark elements > together, such as waves through DWDM gear end up riding on separate dark > fiber paths on either side of the mux. > > The biggest obstacle was getting people to label fiber jumpers in the > field, but that obstacle went away as people get a better understanding of > it and having all of the cross-connects documented saved lots of time and > frustration when having to search through a large patch field at 3 AM... > > jms > > > ------------------------------ > > Message: 5 > Date: Tue, 22 Aug 2017 22:20:20 +0100 > From: Nick Hilliard > To: James Bensley > Cc: NANOG > Subject: Re: Creating a Circuit ID Format > Message-ID: <599CA014.5020704 at foobar.org> > Content-Type: text/plain; charset=UTF-8 > > James Bensley wrote: > > In my opinion the circuit ID should be an abitrary (but unique) value > > and nothing more. As Nick suggested start at 1 and go up. If your > > company is called ABC Ltd then maybe have your first circuit ID as > > ABC00000001 and count up from there, it's as simple as that. > > there are a lot of ways of handling this, which broadly speaking break > down into whether you want to encode data in your circuit ID or whether > you want it to act as nothing more than an index on a database table. > > Regardless of what way you go about things, there are some parallel > issues, including whether you want inline checksumming, whether you want > random value increases or +1 increases, and whether you want an > alphanumeric or strictly numeric ID. Alphanumeric can allow unique > prefixes or suffixes to help identify who owns a circuit ID or what type > it is, at the complexity of adding identifiers which can be > misinterpreted over the phone. > > There are differing opinions on whether other information such as > service type, node location, speed, etc should be encoded in the service > name. > > Things that most people generally agree on include: > > - carefully splitting out service types. E.g. a fibre cable to a > location is one ID; a wavelength on that service is another ID of > another type; an IP transit service on that wave is a third ID, etc. > > - don't reuse IDs, ever. There are plenty of numbers out there. > > - don't change from one ID mechanism to another, if possible. > > Otherwise, for every well-reasoned suggestion to use a specific format, > there are other well-reasoned arguments to do things in a different way. > Choose one and stick with it. > > Nick > > > ------------------------------ > > Message: 6 > Date: Tue, 22 Aug 2017 21:44:24 -0400 > From: Andrew Kirch > To: NANOG list > Subject: Spectrum web cache engineer > Message-ID: > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Would a Spectrum engineer please contact me off list? It appears you're > caching an expired certificate for https://www.icei.org. > > The issue is tested/working everywhere else. > > Thanks! > > Andrew > > > ------------------------------ > > Message: 7 > Date: Wed, 23 Aug 2017 08:18:52 +0000 > From: Timothy Creswick > To: NANOG > Subject: RE: Creating a Circuit ID Format > Message-ID: > eurprd05.prod.outlook.com> > > Content-Type: text/plain; charset="utf-8" > > > Things that most people generally agree on include: > > > > - carefully splitting out service types. E.g. a fibre cable to a > > location is one ID; a wavelength on that service is another ID of > > another type; an IP transit service on that wave is a third ID, etc. > > Definitely. We have one digit in our circuit ID which denotes the type to > aid with quick identification. > > We also use a luhn-10 checksum digit at the end, which is optional on > re-entry. This is really helpful when getting references over the phone. > When written, it's with a hyphen so that it's clear that it's able to be > dropped. > > A few things we also decided on: > > - Circuit references are purely numerical (although we prefix them with > letters when written, those letters are not part of what makes the numbers > unique in our business). The main reason for this is that they can easily > be entered in a variety of *compact* barcode formats. Most label printers > support this, and it saves loads of time in the datacentre when you can > just scan the label on a circuit on a handheld PC. > > - Circuit references are always the same length. This way, if the checksum > digit is being dropped (e.g. because it's coming from a non-human source > like a barcode), we know that the checksum digit is missing. > > - The first digit is never a zero, to avoid silly mistakes if you're > sorting them in Excel etc. > > - The first four digits are a simple date code of YYMM that the ID was > generated. This is surprisingly handy when you're looking for a specific > circuit reference in a list, and it sort of helps to spread the dataset out > a bit. This is what ensures that it's a non-zero first digit for the next > 80 years or so. The date code isn't a *requirement* of our format, however. > Should we need more than 10,000 circuits per month, we'll just abandon the > date coding. > > For those interested, our system looks like this: > > VCI-150600019-7 > > Any non [0-9] characters (including symbols) can be omitted. > > VCI : denotes that this circuit identifier corresponds to our business > 1506 : date code > 0001 : sequence number, incremented per circuit, per month > 9 : circuit type > 7 : checksum (optional) > > T > > > End of NANOG Digest, Vol 115, Issue 21 > ************************************** > -- -Steve Lerner (m) 212-495-9212 From lguillory at reservetele.com Thu Aug 24 22:30:09 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Thu, 24 Aug 2017 22:30:09 +0000 Subject: Comparing Backbone providers from support POV In-Reply-To: <131777996.73187322.1501146533310.JavaMail.zimbra@noor.net> References: <813307713.73178382.1501145672883.JavaMail.zimbra@noor.net>, <131777996.73187322.1501146533310.JavaMail.zimbra@noor.net> Message-ID: <41056DDE-B0FD-4BDE-ACAF-7A111427CB5A@reservetele.com> Check this thread out. https://mailman.nanog.org/pipermail/nanog/2017-August/091852.html Sent from my iPhone On Aug 24, 2017, at 5:18 PM, Bassem Fawzi > wrote: Hello All, This is Bassem and this is my first participation in nanog. We are planning to get a new 10G circuit and we are comparing the IPT service of three backbone providers that met our technical and financial requirements, Now to take all aspects into consideration we need to compare them from the support point of view. The three providers are NTT,GTT and Telia so if any one have dealt with them before and can help us rate their support it would be Great. Many thanks. -- Best regards, Bassem Fawzy Network engineer – Core Team City Stars Capital 5 A4 Omar Ibn El Khattab St. Heliopolis, Cairo, Egypt Mobile GSM: +2 01006580139 Land Line: +2 02 16700 EXT:139 FAX: +2 02 37482816 Email: bfawzi at noor.net Luke Guillory Vice President – Technology and Innovation [cid:imagee3fe68.JPG at 4f232b39.4682af08] 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 benno at NLnetLabs.nl Fri Aug 25 15:30:06 2017 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Fri, 25 Aug 2017 17:30:06 +0200 Subject: Last call for presentations and Draft programme for RIPE 75 Message-ID: <210f8ed7-511d-ed4c-efb9-308d1acaf17d@NLnetLabs.nl> Colleagues, A list of currently accepted RIPE 75 presentations is now published at: https://ripe75.ripe.net/programme/meeting-plan/draft-programme/ There are still plenary, BoF, tutorial and workshop slots remaining for the final RIPE 75 programme and RIPE Programme Committee will accept new proposals until *6 September 2017*. This is our last call for you to submit your proposals. You can find the CFP for RIPE 75 below or at https://ripe75.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Update to UAE DTCM requirments: It is now confirmed that a photocopy of speakers' passports is *not* required. Non-UAE/international speakers need only to provide: * Passport number * Date of birth * A short biography (at least 60 words) Residents of the UAE are required to upload a copy of their Emirates ID (in jpeg format). More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Kind regards, Benno Overeinder RIPE PC Chair https://ripe75.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 75 will take place from 22-26 October in Dubai, UAE. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 75. See the full descriptions of the different presentation formats, https://ripe75.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *6 September 2017*. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Speakers Due to UAE law, confirmed Non-UAE/international speakers need to provide: * Passport number * Date of birth * A short biography (at least 60 words) Residents of the UAE are required to upload a copy of their Emirates ID (in jpeg format). More details are available here: https://ripe75.ripe.net/attend/dctm-requirements Please also note that speakers do not receive any discount or funding towards the meeting fee at RIPE Meetings. Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe75.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe75.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From cscora at apnic.net Fri Aug 25 18:02:42 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 26 Aug 2017 04:02:42 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20170825180242.A27DDC44AD@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, SANOG, PacNOG, SAFNOG MENOG, BJNOG, SDNOG, CMNOG, IRNOG 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 26 Aug, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 659134 Prefixes after maximum aggregation (per Origin AS): 256684 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 319064 Total ASes present in the Internet Routing Table: 58198 Prefixes per ASN: 11.33 Origin-only ASes present in the Internet Routing Table: 50314 Origin ASes announcing only one prefix: 22185 Transit ASes present in the Internet Routing Table: 7884 Transit-only ASes present in the Internet Routing Table: 228 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 56 Max AS path prepend of ASN ( 55644) 51 Prefixes from unregistered ASNs in the Routing Table: 62 Number of instances of unregistered ASNs: 65 Number of 32-bit ASNs allocated by the RIRs: 19815 Number of 32-bit ASNs visible in the Routing Table: 15573 Prefixes from 32-bit ASNs in the Routing Table: 63688 Number of bogon 32-bit ASNs visible in the Routing Table: 24 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 328 Number of addresses announced to Internet: 2851451744 Equivalent to 169 /8s, 245 /16s and 179 /24s Percentage of available address space announced: 77.0 Percentage of allocated address space announced: 77.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 219440 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 179395 Total APNIC prefixes after maximum aggregation: 51805 APNIC Deaggregation factor: 3.46 Prefixes being announced from the APNIC address blocks: 178370 Unique aggregates announced from the APNIC address blocks: 74369 APNIC Region origin ASes present in the Internet Routing Table: 8295 APNIC Prefixes per ASN: 21.50 APNIC Region origin ASes announcing only one prefix: 2304 APNIC Region transit ASes present in the Internet Routing Table: 1176 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 56 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3154 Number of APNIC addresses announced to Internet: 764692960 Equivalent to 45 /8s, 148 /16s and 73 /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: 201001 Total ARIN prefixes after maximum aggregation: 95586 ARIN Deaggregation factor: 2.10 Prefixes being announced from the ARIN address blocks: 202791 Unique aggregates announced from the ARIN address blocks: 93664 ARIN Region origin ASes present in the Internet Routing Table: 17961 ARIN Prefixes per ASN: 11.29 ARIN Region origin ASes announcing only one prefix: 6638 ARIN Region transit ASes present in the Internet Routing Table: 1776 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: 2161 Number of ARIN addresses announced to Internet: 1108661024 Equivalent to 66 /8s, 20 /16s and 211 /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: 176705 Total RIPE prefixes after maximum aggregation: 86571 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 172575 Unique aggregates announced from the RIPE address blocks: 104278 RIPE Region origin ASes present in the Internet Routing Table: 24326 RIPE Prefixes per ASN: 7.09 RIPE Region origin ASes announcing only one prefix: 11177 RIPE Region transit ASes present in the Internet Routing Table: 3456 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 32 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6118 Number of RIPE addresses announced to Internet: 713008256 Equivalent to 42 /8s, 127 /16s and 164 /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: 84765 Total LACNIC prefixes after maximum aggregation: 18849 LACNIC Deaggregation factor: 4.50 Prefixes being announced from the LACNIC address blocks: 86023 Unique aggregates announced from the LACNIC address blocks: 39482 LACNIC Region origin ASes present in the Internet Routing Table: 6288 LACNIC Prefixes per ASN: 13.68 LACNIC Region origin ASes announcing only one prefix: 1726 LACNIC Region transit ASes present in the Internet Routing Table: 1161 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 36 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 3801 Number of LACNIC addresses announced to Internet: 171152864 Equivalent to 10 /8s, 51 /16s and 149 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 17204 Total AfriNIC prefixes after maximum aggregation: 3818 AfriNIC Deaggregation factor: 4.51 Prefixes being announced from the AfriNIC address blocks: 19047 Unique aggregates announced from the AfriNIC address blocks: 7005 AfriNIC Region origin ASes present in the Internet Routing Table: 1068 AfriNIC Prefixes per ASN: 17.83 AfriNIC Region origin ASes announcing only one prefix: 339 AfriNIC Region transit ASes present in the Internet Routing Table: 210 Average AfriNIC Region AS path length visible: 4.8 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 339 Number of AfriNIC addresses announced to Internet: 93467136 Equivalent to 5 /8s, 146 /16s and 50 /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 5412 4192 87 ERX-CERNET-BKB China Education and Rese 7545 3980 407 393 TPG-INTERNET-AP TPG Telecom Limited, AU 17974 2962 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2839 11126 752 KIXS-AS-KR Korea Telecom, KR 9829 2754 1498 549 BSNL-NIB National Internet Backbone, IN 9808 2353 8699 32 CMNET-GD Guangdong Mobile Communication 45899 2292 1465 114 VNPT-AS-VN VNPT Corp, VN 4755 2099 423 221 TATACOMM-AS TATA Communications formerl 7552 1706 1105 70 VIETEL-AS-AP Viettel Corporation, VN 9498 1623 361 144 BBIL-AP BHARTI Airtel Ltd., IN 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 3808 2952 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 6327 3468 1341 87 SHAW - Shaw Communications Inc., CA 18566 2205 405 109 MEGAPATH5-US - MegaPath Corporation, US 6389 2047 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 20115 2030 2233 429 CHARTER-NET-HKY-NC - Charter Communicat 209 1887 5066 642 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1828 329 279 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 16509 1822 3927 529 AMAZON-02 - Amazon.com, Inc., US 701 1715 10557 629 UUNET - MCI Communications Services, In 6983 1694 854 229 ITCDELTA - Earthlink, 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 3387 186 23 ALJAWWALSTC-AS, SA 20940 2969 959 2134 AKAMAI-ASN1, US 8551 2540 377 41 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2058 332 424 TELLCOM-AS, TR 9121 1811 1691 17 TTNET, TR 12389 1695 1604 670 ROSTELECOM-AS, RU 12479 1652 1048 59 UNI2-AS, ES 13188 1602 100 55 TRIOLAN, UA 6849 1225 355 21 UKRTELNET, UA 8402 1159 544 15 CORBINA-AS OJSC "Vimpelcom", 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 3549 542 217 Telmex Colombia S.A., CO 8151 2982 3424 581 Uninet S.A. de C.V., MX 11830 2109 370 65 Instituto Costarricense de Electricidad 6503 1606 437 53 Axtel, S.A.B. de C.V., MX 7303 1561 1019 245 Telecom Argentina S.A., AR 6147 1218 377 27 Telefonica del Peru S.A.A., PE 3816 1026 504 95 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 954 2279 185 CLARO S.A., BR 11172 917 126 86 Alestra, S. de R.L. de C.V., MX 18881 898 1052 23 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 1185 398 48 LINKdotNET-AS, EG 37611 750 91 8 Afrihost, ZA 36903 711 357 130 MT-MPLS, MA 36992 657 1383 29 ETISALAT-MISR, EG 24835 499 850 15 RAYA-AS, EG 29571 421 36 10 CITelecom-AS, CI 37492 409 353 76 ORANGE-, TN 15399 361 35 7 WANANCHI-, KE 2018 304 327 74 TENET-1, ZA 23889 283 103 14 MauritiusTelecom, MU 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 5412 4192 87 ERX-CERNET-BKB China Education and Rese 7545 3980 407 393 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3808 2952 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3549 542 217 Telmex Colombia S.A., CO 6327 3468 1341 87 SHAW - Shaw Communications Inc., CA 39891 3387 186 23 ALJAWWALSTC-AS, SA 8151 2982 3424 581 Uninet S.A. de C.V., MX 20940 2969 959 2134 AKAMAI-ASN1, US 17974 2962 902 73 TELKOMNET-AS2-AP PT Telekomunikasi Indo 4766 2839 11126 752 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 3808 3650 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7545 3980 3587 TPG-INTERNET-AP TPG Telecom Limited, AU 6327 3468 3381 SHAW - Shaw Communications Inc., CA 39891 3387 3364 ALJAWWALSTC-AS, SA 10620 3549 3332 Telmex Colombia S.A., CO 17974 2962 2889 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8551 2540 2499 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 8151 2982 2401 Uninet S.A. de C.V., MX 9808 2353 2321 CMNET-GD Guangdong Mobile Communication Co.Ltd. 9829 2754 2205 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 290012147 UNALLOCATED 63.65.43.0/24 7046 RFC2270-UUNET-CUSTOMER - MCI C 65538 DOCUMENT 64.27.253.0/24 1273 CW Vodafone Group PLC, GB 65346 PRIVATE 94.50.36.0/22 31094 TTKNET Tyumen, Russia, RU Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 23.226.112.0/20 62788 UNKNOWN 27.100.7.0/24 56096 UNKNOWN 41.76.232.0/21 62878 XLITT - Xlitt, US 41.77.248.0/21 62878 XLITT - Xlitt, US 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.79.12.0/22 37306 -Reserved AS-, ZZ 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:15 /9:13 /10:36 /11:104 /12:284 /13:553 /14:1052 /15:1847 /16:13417 /17:7668 /18:13406 /19:24731 /20:38877 /21:41696 /22:78797 /23:65148 /24:369251 /25:850 /26:633 /27:650 /28:37 /29:23 /30:17 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3265 3468 SHAW - Shaw Communications Inc., CA 22773 2996 3808 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 39891 2946 3387 ALJAWWALSTC-AS, SA 18566 2089 2205 MEGAPATH5-US - MegaPath Corporation, US 8551 2005 2540 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1610 1828 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11830 1499 2109 Instituto Costarricense de Electricidad y Telec 10620 1495 3549 Telmex Colombia S.A., CO 11492 1411 1591 CABLEONE - CABLE ONE, INC., US 6389 1358 2047 BELLSOUTH-NET-BLK - BellSouth.net Inc., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1558 2:827 4:18 5:2447 6:31 7:1 8:1052 12:1855 13:142 14:1703 15:28 16:2 17:193 18:90 20:61 23:2438 24:1920 25:2 27:2378 29:1 31:1926 32:84 33:18 35:21 36:390 37:2354 38:1353 39:68 40:98 41:2957 42:464 43:1961 44:78 45:3021 46:2797 47:163 49:1257 50:989 51:19 52:815 54:364 55:6 56:4 57:44 58:1559 59:1009 60:325 61:1923 62:1702 63:1903 64:4647 65:2210 66:4567 67:2279 68:1231 69:3380 70:1179 71:616 72:2219 74:2712 75:388 76:428 77:1497 78:1443 79:1940 80:1406 81:1395 82:1001 83:728 84:964 85:1830 86:465 87:1198 88:763 89:2179 90:166 91:6205 92:1008 93:2399 94:2345 95:2663 96:655 97:354 98:1066 99:98 100:153 101:1469 102:1 103:15666 104:3026 105:187 106:550 107:1767 108:822 109:2910 110:1466 111:1748 112:1241 113:1247 114:1078 115:1585 116:1671 117:1768 118:2155 119:1658 120:734 121:1060 122:2330 123:1819 124:1480 125:1785 128:883 129:665 130:441 131:1472 132:572 133:190 134:682 135:218 136:452 137:480 138:1924 139:521 140:409 141:651 142:773 143:894 144:810 145:184 146:1097 147:705 148:1500 149:584 150:731 151:987 152:731 153:298 154:871 155:755 156:667 157:665 158:481 159:1559 160:750 161:747 162:2521 163:500 164:960 165:1404 166:381 167:1295 168:2987 169:843 170:3515 171:369 172:996 173:1994 174:813 175:749 176:1894 177:3947 178:2553 179:1145 180:2198 181:1978 182:2430 183:769 184:878 185:10588 186:3317 187:2187 188:2579 189:1809 190:8361 191:1329 192:9579 193:5823 194:4727 195:3924 196:2107 197:1360 198:5532 199:5890 200:7600 201:4347 202:10361 203:9990 204:4549 205:2840 206:3069 207:3157 208:3957 209:3996 210:3956 211:2056 212:2883 213:2524 214:853 215:66 216:5877 217:2132 218:899 219:601 220:1685 221:909 222:749 223:1196 End of report From sean at donelan.com Sun Aug 27 03:18:22 2017 From: sean at donelan.com (Sean Donelan) Date: Sat, 26 Aug 2017 23:18:22 -0400 (EDT) Subject: Hurrican Harvey - Network Status (FCC) Message-ID: Hurrican Harvey DIRS report 5 radio stations out of service (WKNC, KKTX, KUNO, KKWV, and KAYK) 149,909 cable and wireline subscribers out of service (5 switching centers out of service, and 38 switching centers on backup power) 4% of cell sites out of service (Aransas, Reugio and San Patricio, TX have more than 50% of cell sites out of service) 9 PSAPs out of service or calls re-routed to another PSAP Aransas, TX is very rural, with only 19 cell sites, 18 out of service. https://apps.fcc.gov/edocs_public/attachmatch/DOC-346368A1.pdf From faisal at snappytelecom.net Sun Aug 27 18:13:42 2017 From: faisal at snappytelecom.net (Faisal Imtiaz) Date: Sun, 27 Aug 2017 18:13:42 +0000 (GMT) Subject: Comparing Backbone providers from support POV In-Reply-To: <131777996.73187322.1501146533310.JavaMail.zimbra@noor.net> References: <131777996.73187322.1501146533310.JavaMail.zimbra@noor.net> Message-ID: <469896183.2961211.1503857622521.JavaMail.zimbra@snappytelecom.net> Hi Bassem, All three of them are excellent Networks with Extensive Resource and excellent Technical Staff Behind them. I am not sure if you are going to be able to find enough of a difference in their Support to make a decision based on it. Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net ----- Original Message ----- > From: "Bassem Fawzi" > To: "nanog list" > Cc: "core" > Sent: Thursday, July 27, 2017 5:08:53 AM > Subject: Comparing Backbone providers from support POV > Hello All, > > This is Bassem and this is my first participation in nanog. > > We are planning to get a new 10G circuit and we are comparing the IPT service of > three backbone providers that met our technical and financial requirements, Now > to take all aspects into consideration we need to compare them from the support > point of view. > > The three providers are NTT,GTT and Telia so if any one have dealt with them > before and can help us rate their support it would be Great. > > Many thanks. > > -- > Best regards, > > Bassem Fawzy > Network engineer – Core Team > City Stars Capital 5 A4 > Omar Ibn El Khattab St. > Heliopolis, Cairo, Egypt > Mobile GSM: +2 01006580139 > Land Line: +2 02 16700 EXT:139 > FAX: +2 02 37482816 > Email: bfawzi at noor.net From sean at donelan.com Sun Aug 27 21:24:34 2017 From: sean at donelan.com (Sean Donelan) Date: Sun, 27 Aug 2017 17:24:34 -0400 (EDT) Subject: Hurricane Harvey - Network Status (FCC) In-Reply-To: References: Message-ID: Hurricane Harvey DIRS report August 27, 2017: 17 PSAPs impacted, 1 out of service, 16 with partial service or re-routed to another PSAP At least 148,565 cable and wireline subscribers out of service (11 switching centers out of service, and 21 switching centers on backup power) 4.1% of cell sites out of service (Aransas, Calhoun, Refugio, and San Patricio in TX have more than 50% of cell sites out of service) 9 radio stations out of service (KJOJ-FM, KKTX, KUNO, KPRC, KKWV, KAYK, KZFM, KKBA and KEYS) News reports also say 1 TV station (KHOU) out of service, but not reported in the DIRS status. https://www.fcc.gov/file/12806/download From jackson.tim at gmail.com Mon Aug 28 00:58:38 2017 From: jackson.tim at gmail.com (Tim Jackson) Date: Sun, 27 Aug 2017 19:58:38 -0500 Subject: Hurricane Harvey - Network Status (FCC) In-Reply-To: References: Message-ID: KHOU's local transmitter (Missouri City I think is where it's at) seems to be back on the air, but with all production from WFAA out of Dallas. -- Tim On Sun, Aug 27, 2017 at 4:24 PM, Sean Donelan wrote: > Hurricane Harvey DIRS report August 27, 2017: > > 17 PSAPs impacted, 1 out of service, 16 with partial service or re-routed > to another PSAP > At least 148,565 cable and wireline subscribers out of service (11 > switching centers out of service, and 21 switching centers on backup power) > 4.1% of cell sites out of service (Aransas, Calhoun, Refugio, and San > Patricio in TX have more than 50% of cell sites out of service) > 9 radio stations out of service (KJOJ-FM, KKTX, KUNO, KPRC, KKWV, KAYK, > KZFM, KKBA and KEYS) > > News reports also say 1 TV station (KHOU) out of service, but not reported > in the DIRS status. > > https://www.fcc.gov/file/12806/download > From adofou at gmail.com Fri Aug 25 10:50:11 2017 From: adofou at gmail.com (Johann) Date: Fri, 25 Aug 2017 12:50:11 +0200 Subject: AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these schmucks? In-Reply-To: References: <15340.1502740194@segfault.tristatelogic.com> <970945E55BFD8C4EA4CAD74B647A9DC0DE623E91@USIDCWVEMBX08.corp.global.level3.com> Message-ID: Hello, AS29073 seem be visible (for anyone?) on AMS-IX routeserver. I think that can explain why many ASN peer with this network. So, thanks for this thread. I have filtered this ASN on AMS-IX RS (99 =>98). Johann 2017-08-17 5:51 GMT+02:00 Troy Mursch : > This discussion is not pertaining to a customer of a network service > provider. Ecatel / Quasi Networks (AS29073) has an established track > record of ignoring abuse requests for years. So much so they are now in > legal trouble, per court documents published on August 14: > https://uitspraken.rechtspraak.nl/inziendocument? > id=ECLI:NL:RBDHA:2017:9026 > > > (Use Google Translate if you can’t read Dutch) > > > Setting aside the child porn, phishing sites, route hijacking, copyright > infringement, and large-scale outbound hacking activities - why would > anyone peer with another AS who deliberately ignores abuse requests? > > > Yesterday I spoke with BREIN, the organization leading case against > AS29073, they advised, "Our effort is aimed at outing the actual people > behind it so they can be held responsible." > > If anyone has information regarding AS29073 and would like to share it with > BREIN you can submit it via this web form: > https://stichtingbrein.nl/contact.php > > __ > > *Troy Mursch* > > Bad Packets Report > > (702) 509-1248 > > On Mon, Aug 14, 2017 at 1:17 PM, Siegel, David > wrote: > > > If you believe that a customer of a network service provider is in > > violation of that service providers AUP, you should email > > abuse at serviceprovider.net. Most large networks have a security team > that > > monitors that email address regularly and will cooperate with you to > > address the problem. > > > > Dave > > > > > > > > > > -----Original Message----- > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ronald F. > > Guilmette > > Sent: Monday, August 14, 2017 1:50 PM > > To: nanog at nanog.org > > Subject: AS29073, 196.16.0.0/14, Level3: Why does anyone peer with these > > schmucks? > > > > > > Sorry for the re-post, but it has been brought to my attention that my > > inclusion, in my prior posting, of various unsavory FQDNs resolving to > > various IPv4 addresses on AS29073 has triggered some people's spam > > filters. (Can't imagine why. :-) So I am re-posting this message now, > > with just a link to where those shady FQDNs and their current forward > > resolutions may be found. (I also took the opportunity to clean up some > > minor typos.) > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > > I think that this is primarily Level3's problem to fix. But you be the > > judge. Please, read on. > > > > +_+_+_+_+_+_+_+_ > > > > Over the weekend, I stumbled upon an interesting blog calld "Bad > Packets", > > where a fellow named Troy has written about various unsavory goings on > > involving various newtorks. One network that he called out in particular > > was AS29073, formerly called "Ecatel". on his blog, this fellow Troy has > > noted at length some break-in attempts originating from AS29073 and his > > inability to get anyone, in particular RIPE NCC, to give a damn. > > > > https://badpackets.net/the-master-needler-80-82-65-66/ > > https://badpackets.net/a-conversation-with-ripe-ncc-regardin > > g-quasi-networks-ltd/ > > https://badpackets.net/quasi-networks-responds-as-we-witness > > -the-death-of-the-master-needler-80-82-65-66-for-now/ > > > > The fact that RIPE NCC declined to accept the role of The Internet Police > > didn't surprise me at all... they never have and probably never will. > > But I decided to have a quick look at what this newtork was routing, at > > present, which can be easily see here: > > > > http://bgp.he.net/AS29073#_prefixes > > > > So I was looking through the announced routes for AS29073, and it all > > looked pretty normal... a /24 block, check, a /24 block, check, a /21 > block > > check... another /24 block, and then ... WAIT A SECOND! HOLY MOTHER OF > > GOD! WHAT'S THIS??? 196.16.0.0/14 !!! > > > > So how does a little two-bit network with a rather dubious reputation and > > a grand total of only about a /19 to its name suddenly come to be routing > > an entire /14 block?? > > > > And of course, its a legacy (abandoned) Afrinic block. > > > > And of course, there's no reverse DNS for any of it, because there is no > > valid delegation for the reverse DNS for any of it... usually a good sign > > that whoever is routing the block right now -does not- have legit rights > to > > do so. (If they did, then they would have presented their LOAs or > whatever > > to Afrinic and thus gotten the reverse DNS properly delegated to their > own > > name servers.) > > > > I've seen this movie before. You all have. This gives every indication > > of being just another sad chapter in the ongoing mass pillaging of unused > > Afrinic legacy IPv4 space, by various actors with evil intent. > > I've already documented this hightly unfortunate fad right here on > > multiple occasions: > > > > https://mailman.nanog.org/pipermail/nanog/2016-November/089232.html > > https://mailman.nanog.org/pipermail/nanog/2017-August/091821.html > > > > This incident is a bit different from the others however, in that it > -does > > not- appear that the 196.16.0.0/14 block has been filed to the brim with > > snowshoe spammers. Well, not yet anyway. > > > > But if in fact the stories are correct, and if AS29073 does indeed have a > > history of hosting outbound hacking activities, then the mind reels when > > thinking about how much mischief such bad actors could get into if given > an > > entire /14 to play with. (And by the way, this is a new world's record I > > think, for largest single-route deliberate hijack. > > I've seen plenty of /16s go walkabout before, and even a whole /15. > > But an entire /14?!?! That is uniquely brazen.) > > > > In addition to the above, and the points raised within the Bad Packets > > blog (see links above) I found, via passive DNS, a number of other causes > > for concern about AS29073, to wit: > > > > Shady FQDNs (incl possible child porn ones) on AS29073 moved here: > > https://pastebin.com/raw/f4M09UKL > > > > (In addition to the above, I've also found plenty more domain names > > associated with AS29073 which incorporate the names "Apple" "AirBnB", > > "Facebook", and "Groupon", as well as dozens of other legitimate > companies > > and organizations.) > > > > I confess that I have not had the time to look at any of the web sites > > that may or may not be associated with any of the above FQDNs, but the > > domain names themselves are certainly strongly suggestive of (a) the > > possible hosting of child porn and also and separately (b) the possible > > hosting of phishing sites. > > > > So, given the history of this network (as is well documented on the Bad > > Packets blog) and given all of the above, and given what would appear to > be > > the unauthorized "liberation" of the entire 196.16.0.0/14 block by > > AS29073, one cannot help but wonder: Why does anybody still even peer > with > > these jerks? > > > > The always helpful and informative web site bgp.he.net indicates that > > very nearly 50% of the connectivity currently enjoyed by AS29073 is being > > provided to them by Level3. I would thus like to ask Level3 to > reconsider > > that peering arrangement in light of the above facts, and especially in > > light of what would appear to be the unauthorized routing of the > > 196.16.0.0/14 block by AS29073. > > > > Surprisingly, given its history, AS29073 apparently has a total of 99 > > different peers, at present, and I would likewise ask all of them to > > reconsider their current peering arrangements with this network. I am > > listing all 99 peers below. > > > > Before I get to that however, I'd like to also note that there currently > > exists, within the RIPE Routing Registry, the following route object: > > > > route: 196.16.0.0/14 > > origin: AS29073 > > mnt-by: QUASINETWORKS-MNT > > mnt-by: EC42500-MNT > > mnt-routes: EC42500-MNT > > mnt-routes: M247-EU-MNT > > created: 2017-03-28T21:47:03Z > > last-modified: 2017-08-11T19:58:39Z > > source: RIPE > > > > I confess that I am not 100% sure of the exact semantics of the > > "mnt-routes" > > tag, but it would appear from the above that the UK's M247 network > > (AS9009)... > > which itself is not even peering with AS29073... appears to have, in > > effect countersigned the above RIPE route object, vouching for its > > correctness and authenticity as they did so. Why they would have done > > that, especially given that they themselves are not even peering with > > AS29073, is, I confess, beyond me. But I would love to have them explain > > it, or even try to explain it. > > It's enigmatic, to say the least. > > > > Anyway, the "created" date in the above record seems to be consistant > with > > that actual start of the announcement of 196.16.0.0/14 by AS29073, which > > the RIPE Routing History tool says occured sometime in March of this > year. > > > > One additional (and rather bizzare) footnote to this whole story about > the > > 196.16.0.0/14 block has to do with the entity that allegedly -is- the > > current rightful owner of the block (as far as Afrinic is concerned). > > That entity is designated by the Afrinic handle ORG-IA41-AFRINIC and that > > in turn has an admin-c and tech-c of NAIT1-AFRINIC. The record for that > > handle is as follows: > > > > ------------------------------------------------------- > > person: Network and Information Technology Administrator > > address: Unit 117, Orion Mall, Palm Street > > address: Victoria, Mahe > > address: Seychelles (SC) > > phone: +972-54-2203545 > > e-mail: info at networkandinformationtechnology.com > > nic-hdl: NAIT1-AFRINIC > > mnt-by: MNT-NETWORKANDINFORMATIONTECHNOLOGY > > changed: info at networkandinformationtechnology.com 20150725 > > source: AFRINIC > > ------------------------------------------------------- > > > > Upon fetching the current WHOIS record for networkandinformationtechnolog > > y.com > > I found it more than passing strange that all of the contact details > > therein are associated *not* with anything in Africa, nor even anything > in > > the home country of AS29073 (Netherlands) but rather, the address and > phone > > numbers therein all appear to be ones associated with a relatively well > > known Internet attorney in Santa Monica, Califiornia by the name of > Bennet > > Kelly. > > > > As it happens, in the distant past (about 10 years ago) I personally > > crossed swords with this particular fellow. He may be a lot of things, > but > > it never seemed to me that stupid was one of them. And indeed the domain > > name networkandinformationtechnology.com and all of its connections to > > the 196.16.0.0/14 block appear to date from 2015... > > long before AS29073 started routing this block (which only started in > > March of this year). > > > > So, my best guess about this whole confusing mess is that the -original- > > legitimate owners of the 196.16.0.0/14 block most probably sold it on, > in > > a legitimate transaction, to some other party in 2015, where that other > > party was/is represented by Mr. Bennet Kelly, Esq. And my guess is that > > neither he nor the new owners, who he represents, even know that their > > expensive /14 has gone walkabout, as of March of this year. > > I will be trying to make contact with Mr. Kelley today to discuss this > > with him and will post a follow-up if any new and interesting information > > arises from that conversation. > > > > > > Regards, > > rfg > > > > > > Peers of AS29073: > > ============================================================ > > ==================== > > 1 Level 3 Communications, Inc. > > United States > > AS3356 > > 2 REBA Communications BV > > Netherlands > > AS56611 > > 3 Hurricane Electric, Inc. > > United States > > AS6939 > > 4 Core-Backbone GmbH > > Germany > > AS33891 > > 5 Init7 (Switzerland) Ltd. > > Switzerland > > AS13030 > > 6 RETN Limited > > Ukraine > > AS9002 > > 7 COLT Technology Services Group Limited > > United Kingdom > > AS8220 > > 8 State Institute of Information Technologies and > Telecommunications > > (SIIT&T "Informika") > > Russian Federation > > AS3267 > > 9 GlobeNet Cabos Submarinos Colombia, S.A.S. > > Colombia > > AS52320 > > 10 Digital Telecommunication Services S.r.l. > > Italy > > AS49605 > > 11 IT.Gate S.p.A. > > Italy > > AS12779 > > 12 green.ch AG > > Switzerland > > AS1836 > > 13 UNIDATA S.p.A. > > Italy > > AS5394 > > 14 GEANT Limited > > European Union > > AS20965 > > 15 IP-Max SA > > Switzerland > > AS25091 > > 16 Lost Oasis SARL > > France > > AS29075 > > 17 nexellent ag > > Switzerland > > AS31424 > > 18 SEACOM Limited > > Mauritius > > AS37100 > > 19 Angola Cables > > Angola > > AS37468 > > 20 ENTANET International Limited > > United Kingdom > > AS8468 > > 21 Blix Solutions AS > > Norway > > AS50304 > > 22 POST Luxembourg > > Luxembourg > > AS6661 > > 23 Zayo France SAS > > France > > AS8218 > > 24 Wind Telecomunicazioni SpA > > Italy > > AS1267 > > 25 Swisscom (Switzerland) Ltd > > Switzerland > > AS3303 > > 26 Pacnet Global Ltd > > Hong Kong > > AS10026 > > 27 SURFnet bv > > Netherlands > > AS1103 > > 28 SEEWEB s.r.l. > > Italy > > AS12637 > > 29 BIT BV > > Netherlands > > AS12859 > > 30 euNetworks Managed Services GmbH > > Germany > > AS13237 > > 31 CAIW Diensten B.V. > > Netherlands > > AS15435 > > 32 netplus.ch SA > > Switzerland > > AS15547 > > 33 DOKOM Gesellschaft fuer Telekommunikation mbH > > Germany > > AS15763 > > 34 ADISTA SAS > > France > > AS16347 > > 35 Viewqwest Pte Ltd > > Singapore > > AS18106 > > 36 Digital Ocean, Inc. > > European Union > > AS200130 > > 37 Digital Ocean, Inc. > > Netherlands > > AS202018 > > 38 Open Peering B.V. > > Netherlands > > AS20562 > > 39 Services Industriels de Geneve > > Switzerland > > AS20932 > > 40 Cemig Telecomunicaes SA > > Brazil > > AS23106 > > 41 SG.GS > > Singapore > > AS24482 > > 42 Vorboss Limited > > United Kingdom > > AS25160 > > 43 equada network GmbH > > Germany > > AS25220 > > 44 Avantel, Close Joint Stock Company > > Russian Federation > > AS25227 > > 45 Gyron Internet Ltd > > United Kingdom > > AS29017 > > 46 IPROUTE SRL > > Italy > > AS49289 > > 47 LLC "TRC FIORD" > > Russian Federation > > AS28917 > > 48 Hostserver GmbH > > Germany > > AS29140 > > 49 Telekommunikation Mittleres Ruhrgebiet GmbH > > Germany > > AS12329 > > 50 Internet Systems Consortium, Inc. > > United States > > AS30132 > > 51 Liquid Telecommunications Ltd > > United Kingdom > > AS30844 > > 52 Paulus M. Hoogsteder trading as Meanie > > Netherlands > > AS31019 > > 53 Digiweb ltd > > Ireland > > AS31122 > > 54 Fiberax Networking&Cloud Ltd. > > United Kingdom > > AS3252 > > 55 Hivane > > France > > AS34019 > > 56 CELESTE SAS > > France > > AS34177 > > 57 Kantonsschule Zug > > Switzerland > > AS34288 > > 58 Citycable > > Switzerland > > AS34781 > > 59 SoftLayer Technologies Inc. > > United States > > AS36351 > > 60 Network Platforms (PTY) LTD > > South Africa > > AS37497 > > 61 Micron21 Datacentre Pty Ltd > > Australia > > AS38880 > > 62 Convergenze S.p.A. > > Italy > > AS39120 > > 63 Fiberby ApS > > Denmark > > AS42541 > > 64 IP ServerOne Solutions Sdn Bhd, > > Malaysia > > AS45352 > > 65 Easynet Global Services > > European Union > > AS4589 > > 66 IP-Only Networks AB > > Sweden > > AS12552 > > 67 Tango S.A. > > Luxembourg > > AS48526 > > 68 Les Nouveaux Constructeurs SA > > France > > AS49463 > > 69 CustodianDC Limited > > United Kingdom > > AS50300 > > 70 MCKAYCOM LTD > > United Kingdom > > AS50763 > > 71 Daisy Communications Ltd > > United Kingdom > > AS5413 > > 72 MC-IX Matrix Internet Exchange RS-1 > > Indonesia > > AS55818 > > 73 NetIX Communications Ltd. > > Bulgaria > > AS57463 > > 74 Anycast Global Backbone > > Australia > > AS58511 > > 75 LUXNETWORK S.A. > > Luxembourg > > AS29467 > > 76 oja.at GmbH > > Austria > > AS39912 > > 77 Elisa Oyj > > Finland > > AS6667 > > 78 A1 Telekom Austria AG > > Austria > > AS8447 > > 79 Fusix Networks B.V. > > Netherlands > > AS57866 > > 80 ClaraNET LTD > > United Kingdom > > AS8426 > > 81 "OBIT" Ltd. > > Russian Federation > > AS8492 > > 82 Console Network Solutions Ltd > > United Kingdom > > AS43531 > > 83 NetCologne GmbH > > Germany > > AS8422 > > 84 Tesonet Ltd > > Lithuania > > AS201341 > > 85 Linx Telecommunications B.V. > > Estonia > > AS3327 > > 86 Strato AG > > Germany > > AS6724 > > 87 CJSC RASCOM > > Russian Federation > > AS20764 > > 88 Sunrise Communications AG > > Switzerland > > AS6730 > > 89 KPN B.V. > > Netherlands > > AS1136 > > 90 MTN SA > > South Africa > > AS16637 > > 91 Portlane AB > > Sweden > > AS42708 > > 92 TM Net, Internet Service Provider > > Malaysia > > AS4788 > > 93 Network Dedicated SAS > > Switzerland > > AS62355 > > 94 Next Layer Telekommunikationsdienstleistungs- und Beratungs GmbH > > Austria > > AS1764 > > 95 Telkom SA Ltd. > > South Africa > > AS5713 > > 96 ShockSRV Internet Services Private Limited > > Netherlands > > AS60115 > > 97 JUPITER 25 LIMITED > > Netherlands > > AS64484 > > 98 M-net Telekommunikations GmbH > > Germany > > AS8767 > > 99 Neterra Ltd. > > Bulgaria > > AS34224 > > > From ando at kk.iij4u.or.jp Fri Aug 25 04:06:06 2017 From: ando at kk.iij4u.or.jp (Kazunori ANDO) Date: Fri, 25 Aug 2017 13:06:06 +0900 Subject: How can I obtain the abuse e-mail address for IPs from Japan? In-Reply-To: References: Message-ID: <35b1acda-7f0b-aa20-49b6-a6ba271d5e00@kk.iij4u.or.jp> one more command. whois -h whois.nic.ad.jp KW419JP -- Kazunori ANDO / ando at kk.iij4u.or.jp On 2017/08/24 0:16, Kurt Kraut wrote: > Hello Suresh, > > > It doesn't seem to help a lot: > > ktk at ktk:~$ whois -h whois.nic.ad.jp 59.106.13.181 > [ JPNIC database provides information regarding IP address and ASN. Its use > ] > [ is restricted to network administration purposes. For further > information, ] > [ use 'whois -h whois.nic.ad.jp help'. To only display English output, > ] > [ add '/e' at the end of command, e.g. 'whois -h whois.nic.ad.jp xxx/e'. > ] > > Network Information: > a. [Network Number] 59.106.12.0-59.106.27.255 > b. [Network Name] SAKURA-NET > g. [Organization] SAKURA Internet Inc. > m. [Administrative Contact] KT749JP > n. [Technical Contact] KW419JP > p. [Nameserver] ns1.dns.ne.jp > p. [Nameserver] ns2.dns.ne.jp > [Assigned Date] 2004/11/24 > [Return Date] > [Last Update] 2004/11/24 18:41:02(JST) > > Less Specific Info. > ---------- > SAKURA Internet Inc. > [Allocation] > 59.106.0.0/16 > > More Specific Info. > > > > No e-mail addresses of the abuse team or NOC or SOC. > > > Best regards, > > > Kurt Kraut > > 2017-08-23 11:55 GMT-03:00 Suresh Ramasubramanian : > >> whois -h whois.nic.ad.jp IP /e >> >> --srs >> >>> On 23-Aug-2017, at 7:38 PM, Kurt Kraut wrote: >>> >>> Hello, >>> >>> >>> I'm having a hard time to figure out the abuse e-mail address for IPs >> from >>> Japan. Any query I perform at the WHOIS, for any IP, from any autonomoyus >>> system I get the same e-mail addresses: >>> >>> abuse at apnic.net >>> hm-changed at apnic.net >>> ip-apnic at nic.ad.jp >>> hostmaster at nic.ad.jp >>> >>> These e-mail addresses belong to JPNIC, not the autonomous system itself. >>> So any messages sent to these e-mail addresses will not reach the >> offending >>> NOC/SOC so I can report vulnerabilities and DDoS attacks. >>> >>> What am I missing and how should I report security issues to autonomous >>> systems from this region? Has anyone here any experience on this? >>> >>> >>> Thanks in advance, >>> >>> >>> Kurt Kraut >> > From mjosephson at inap.com Fri Aug 25 06:58:47 2017 From: mjosephson at inap.com (Marcus Josephson) Date: Fri, 25 Aug 2017 06:58:47 +0000 Subject: Verizon 701 Route leak? Message-ID: Anyone from Verizon want to comment on a possible route leak on the 25th 10:30 PM EDT? Saw route table jump up to 737629 routes last night from 701. Marcus Josephson mjosephson at inap.com * www.inap.com INAP (r) connectivity | colocation | managed hosting | cloud One Ravinia Drive * Suite 1300 * Atlanta * GA * 30346 From benoit.donnet at ulg.ac.be Mon Aug 28 09:49:08 2017 From: benoit.donnet at ulg.ac.be (Benoit Donnet) Date: Mon, 28 Aug 2017 11:49:08 +0200 Subject: MPLS Usage Survey Message-ID: <8588AF4A-6459-41BF-B924-D14A49154094@ulg.ac.be> Dear all, At the Université de Liège (Belgium) and Université de Strasbourg (France), we are heavily working on measuring MPLS networks for a few years now (you can have a look at all our contributions here: http://montefiore.ulg.ac.be/~bdonnet/mpls/) In order to validate our techniques and get a better vision on how MPLS is actually used and deployed by operators, we have created a little survey. The answers to questions are straightforward (mostly binary answers and multiple choices) and completing the whole survey should take, roughly, 3 minutes. We would be very happy if you, guys, could take 3 minutes to complete the survey. The link towards the survey is the following: https://goo.gl/forms/9CUDnksbfLBbiltz2 Please, note that we do not ask you to validate our dataset (this might come later — that’s why the last question is about the contact email address), we are now interested in the big picture (do you deploy MPLS? MPLS usage? Labelling protocol? etc.). We will, obviously, post process the survey result but answers will always be anonymous when publishing the results (in scientific papers) If you need further information and/or would like to discuss our work, do not hesitate to contact one of us (see the contact page on the 1st link above or the CCs of this email) Thanks in advance Keep on Rockin’ Benoit — Prof. Benoit Donnet Université de Liège (ULg) Bât. B28 Algorithmique des Grands Systèmes Quartier Polytech 1 Allée de la Découverte 10 4000 Liège Phone: +32 4 3662279 From bengelly at gmail.com Mon Aug 28 15:47:05 2017 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Mon, 28 Aug 2017 17:47:05 +0200 Subject: Verizon 701 Route leak? In-Reply-To: References: Message-ID: <0899B986-59B1-4E79-AE86-D5A053B8D50F@gmail.com> Hello, Do you mean this one ? https://dyn.com/blog/large-bgp-leak-by-google-disrupts-internet-in-japan/ https://bgpmon.net/bgp-leak-causing-internet-outages-in-japan-and-beyond/ https://mobile.twitter.com/bgpmon/status/901565301048803329 Best regards. > Le 25 août 2017 à 08:58, Marcus Josephson a écrit : > > Anyone from Verizon want to comment on a possible route leak on the 25th 10:30 PM EDT? Saw route table jump up to 737629 routes last night from 701. > > > Marcus Josephson > > mjosephson at inap.com * www.inap.com > > INAP (r) > connectivity | colocation | managed hosting | cloud > > One Ravinia Drive * Suite 1300 * Atlanta * GA * 30346 > From mjosephson at inap.com Mon Aug 28 15:48:44 2017 From: mjosephson at inap.com (Marcus Josephson) Date: Mon, 28 Aug 2017 15:48:44 +0000 Subject: Verizon 701 Route leak? In-Reply-To: <0899B986-59B1-4E79-AE86-D5A053B8D50F@gmail.com> References: <0899B986-59B1-4E79-AE86-D5A053B8D50F@gmail.com> Message-ID: Damn you Google.. yup. Thanks for links. -Marcus From: Youssef Bengelloun-Zahr [mailto:bengelly at gmail.com] Sent: Monday, August 28, 2017 11:47 AM To: Marcus Josephson Cc: nanog at nanog.org Subject: Re: Verizon 701 Route leak? Hello, Do you mean this one ? https://dyn.com/blog/large-bgp-leak-by-google-disrupts-internet-in-japan/ https://bgpmon.net/bgp-leak-causing-internet-outages-in-japan-and-beyond/ https://mobile.twitter.com/bgpmon/status/901565301048803329 Best regards. Le 25 août 2017 à 08:58, Marcus Josephson > a écrit : Anyone from Verizon want to comment on a possible route leak on the 25th 10:30 PM EDT? Saw route table jump up to 737629 routes last night from 701. Marcus Josephson mjosephson at inap.com * www.inap.com INAP (r) connectivity | colocation | managed hosting | cloud One Ravinia Drive * Suite 1300 * Atlanta * GA * 30346 From jfmezei_nanog at vaxination.ca Mon Aug 28 16:51:23 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 28 Aug 2017 12:51:23 -0400 Subject: Hurricane Harvey - Network Status (FCC) In-Reply-To: References: Message-ID: On 2017-08-27 20:58, Tim Jackson wrote: > KHOU's local transmitter (Missouri City I think is where it's at) seems to > be back on the air, but with all production from WFAA out of Dallas. KHOU had a tweet with video showing the water flooding into their offices/studios and staff having to leave. https://twitter.com/sallykhou11/status/901805513905668096 I guess this is where disaster tolerance/recovery plans really kick in. From job at ntt.net Mon Aug 28 17:34:14 2017 From: job at ntt.net (Job Snijders) Date: Mon, 28 Aug 2017 19:34:14 +0200 Subject: Verizon 701 Route leak? In-Reply-To: References: <0899B986-59B1-4E79-AE86-D5A053B8D50F@gmail.com> Message-ID: <20170828173414.GM915@Vurt.local> On Mon, Aug 28, 2017 at 03:48:44PM +0000, someone wrote: > Damn you Google.. yup. I am not sure it is fair to say "damn you Google", because accidents happen (be it through human error or software defects). All of us have entered commands at some point and subsequently https://media.giphy.com/media/bI5BEfwbdVPcA/giphy.gif Software defects are a real risk as well: Major BGP implementations have had bugs which caused NO_EXPORT functionality to malfunction, or bugs where random pieces of your configuration are ignored (for instance the part of the configuration which contains a prefix-filter). Allegedly the famous AS 7007 incident was also caused by a software defect. The key concept here is that, since we know accidents an happen, we ought to look out for each other and impose multiple layers of protection for our mutual benefit. Mechanisms that come to mind are maximum prefix limits and coarse as-path filters. At NANOG67 I described a few of these tricks https://www.youtube.com/watch?v=CSLpWBrHy10 / https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pdf To further reduce the risk surface, it may be good to ask your BGP vendor for specific behaviour applicable to EBGP sessions: ask for RFC 8212 support. RFC 8212 defines that when you configure an EBGP session without any routing policy associated with that neighbor, no routes will be exchanged until it is explicitly instructed to do so. Finally, it may be worthwhile exploring if we can standardize and promote maximum prefix limits applied on the the _sending_ side. This way you protect your neighbor (and the Internet at large) by self-destructing when you inadvertently announce more than what you'd expect to announce. BIRD has this functionality http://bird.network.cz/?get_doc&f=bird-3.html#proto-export-limit however I am not aware of other implementations. Feedback welcome! Kind regards, Job From rjacobs at pslightwave.com Mon Aug 28 17:47:33 2017 From: rjacobs at pslightwave.com (Robert Jacobs) Date: Mon, 28 Aug 2017 17:47:33 +0000 Subject: Hurricane Harvey - Network Status (FCC) In-Reply-To: References: Message-ID: Large network provider in the middle of this... This event will re-write all of our DR plans... Telecom and communication systems are holding up extremely well with high water and multi-county power outages caused by high-water... I commend all those out in this responding to immediate needs of their fellow citizens directly and the countless other setting at home in front of their PC monitoring things and making sure systems and emergences are being dealt with. Proud to see everyone working together.. That is the way it should be. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois Mezei Sent: Monday, August 28, 2017 11:51 AM To: nanog at nanog.org Subject: Re: Hurricane Harvey - Network Status (FCC) On 2017-08-27 20:58, Tim Jackson wrote: > KHOU's local transmitter (Missouri City I think is where it's at) > seems to be back on the air, but with all production from WFAA out of Dallas. KHOU had a tweet with video showing the water flooding into their offices/studios and staff having to leave. https://twitter.com/sallykhou11/status/901805513905668096 I guess this is where disaster tolerance/recovery plans really kick in. From web at typo.org Mon Aug 28 17:51:02 2017 From: web at typo.org (Wayne Bouchard) Date: Mon, 28 Aug 2017 10:51:02 -0700 Subject: Hurricane Harvey - Network Status (FCC) In-Reply-To: References: Message-ID: <20170828175102.GA15944@spider.typo.org> These held up well in previous examples as well.... until their batteries ran down. So we'll have to see if they continue to be operational as the water drains away. On Mon, Aug 28, 2017 at 05:47:33PM +0000, Robert Jacobs wrote: > Large network provider in the middle of this... This event will re-write all of our DR plans... Telecom and communication systems are holding up extremely well with high water and multi-county power outages caused by high-water... I commend all those out in this responding to immediate needs of their fellow citizens directly and the countless other setting at home in front of their PC monitoring things and making sure systems and emergences are being dealt with. Proud to see everyone working together.. That is the way it should be. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois Mezei > Sent: Monday, August 28, 2017 11:51 AM > To: nanog at nanog.org > Subject: Re: Hurricane Harvey - Network Status (FCC) > > On 2017-08-27 20:58, Tim Jackson wrote: > > KHOU's local transmitter (Missouri City I think is where it's at) > > seems to be back on the air, but with all production from WFAA out of Dallas. > > > KHOU had a tweet with video showing the water flooding into their offices/studios and staff having to leave. > > https://twitter.com/sallykhou11/status/901805513905668096 > > I guess this is where disaster tolerance/recovery plans really kick in. --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From rfg at tristatelogic.com Mon Aug 28 19:06:26 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 28 Aug 2017 12:06:26 -0700 Subject: Hijack Factories: AS203418, AS205944, and AS203040 Message-ID: <16403.1503947186@segfault.tristatelogic.com> Executive Summary: AS203418 (Marketigames, LLC), together with its one and only immediate IPv4 upstream, AS203040 (Mint Company, LLC), and its sister network, AS205944 (MediaClick, LLC) either are currently hijacking or have recently hijacked multiple abandoned /16 IPv4 address blocks, apparently with the intent of leasing out this hijacked IPv4 space to snowshoe spammers, in particular, to Clickjet Media (clickjetmedia.com). Readers who may be peering with AS203040, in particular, are encouraged to cease doing so. +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ I believe that this listing of 13 separate /16 routes makes it self-evident what is going on here: https://bgp.he.net/AS203418#_prefixes (Please note that a screenshot of the above page has been archived here for posterity: http://i.imgur.com/Ws2aKkz.png) The hijacks currently being perpetrated by this ASN (AS203418 - Marketigames, LLC) are, in my opinion, both brazen and audacious. I wouldn't mind, but other evidence indicates persuasively that at least one of these hijacked /16 blocks (140.167.0.0/16) has already been put into use as a snowshoe spamming source. The following file contains a listing of numerous domain names that currently have associated SPF TXT records permitting these domains to send outbound emails from various parts of the (hijacked) 140.167.0.0/16 block: https://pastebin.com/raw/0EjThpR8 It is also interesting that a great many of the domain names listed in the above file in fact resolve to the IPv4 address 216.128.69.220, which is within a /24 block (216.128.69.0/24) which is ostensibly registered to an entity calling itself "Big Hosting Plus" (aka bighostingplus.com) allegedly of Albuquerque, New Mexico. A brief perusal of the WHOIS record associated with the contact domain name for that IPv4 block (bighostingplus.com) shows however the identity of the party that is actually pulling the strings here, i.e. a company called Clickjet Media of Glendale, California, aka clickjetmedia.com: https://pastebin.com/raw/h9cuGSdK I should note that the ARIN sub-SWIP for the 216.128.69.0/24 block is not the only instance in which Clickjet Media has followed this exact same playbook. I have previously identified the following four additional fradulent ARIN sub-SWIPs where ClickJet Media is, evidently, the real entity behind the deliberately fictitious ARIN sub-SWIPs: High Point Host ARB-69-1-227-0 (NET-69-1-227-0-1) 69.1.227.0 - 69.1.227.255 Pleasant Hosting ARB-69-1-228-0 (NET-69-1-228-0-1) 69.1.228.0 - 69.1.228.255 Quasi Hosting ARB-69-1-254-0 (NET-69-1-254-0-1) 69.1.254.0 - 69.1.254.255 Green River Hosting ARB-69-1-255-0 (NET-69-1-255-0-1) 69.1.255.0 - 69.1.255.255 Here is the archived evidence supporting my contentions as they relate to the above four ARIN sub-SWIPs: ARIN sub-SWIP records: https://pastebin.com/raw/UDBQKDiC https://pastebin.com/raw/hpDUqLFF https://pastebin.com/raw/7zdZLw01 https://pastebin.com/raw/gvXNwbJW Associated domain WHOIS records: https://pastebin.com/raw/pHLGRJux (highpointhost.com) https://pastebin.com/raw/V91DTsX1 (pleasanthosting.com) https://pastebin.com/raw/SxqzQy2v (quasihosting.com) https://pastebin.com/raw/2qv5xDsE (greenriverhosting.com) I should note for the sake of completeness that the listing of the 13 hijacked /16 blocks linked to above, as currently presented on the bgp.he.net web site, is in fact a somewhat stale listing. All of those thirteen /16 blocks were in fact hijacked by AS203418 as of yesterday, however as of this writing, it would appear that only the following nine /16 blocks are still hijacked at this moment (although this is hardly a cause for celebration): 116.79.0.0/16 116.144.0.0/16 116.152.0.0/16 116.166.0.0/16 116.181.0.0/16 128.13.0.0/16 134.22.0.0/16 140.167.0.0/16 148.154.0.0/16 Naturally, readers will ask "Who or what is AS203418?" It is registered using the name Marketigames, LLC, which is apparently a properly registered Delaware LLC. Beyond that it is difficult to find any other definitive info. The main web site for this entity (http://marketigames.biz/) is mostly devoid of any information that would allow us to know who is really behind this entity. Contact information is provided on the web site however, as follows: MarketiGames LLC, 4283 Express Lane,Suite 315-592, Sarasota, FL 34238 Phone : 217-717-9384 Googling the street address indicates that it is most often associated with fradulent activity on the Internet (e.g. frudulent attempts to order products). The area code 217 is associated with the Chicago area, not Florida and not Delaware. Although this entity (MarketiGames) does have its own ASN, it also appears to have a number of valid ARIN IP block allocations which are not currently routed by its own ASN: 104.218.224.0/22 (NET-104-218-224-0-1) 104.244.88.0/21 (NET-104-244-88-0-1) 104.245.40.0/21 (NET-104-245-40-0-1) 104.245.248.0/21 (NET-104-245-248-0-1) 173.234.197.0/24 (NET-173-234-197-0-1) 2620:125:C000::/40 (NET6-2620-125-C000-1) Historical passive DNS data appears to indicate that some or all of the above blocks have historically also been used to support snowshoe spamming. Data available from the interactive RIPE Routing History web service indicates clearly that it is not only AS203418 (Marketigames, LLC) that has been involved in the hijacking of abandoned /16 blocks, but also and likewise its immediate upstream AS203040 (Mint Company, LLC), and its sister network, AS205944 (MediaClick, LLC). RIPE Routing History shows that all three of these ASNs have, at various times, hijacked the 116.79.0.0/16 block, for example. The implication seems clear. All three of these ASNs have been working together to hijack abandoned /16 blocks for purposes of hosting snowshoe spamming operations. Because both AS203418 and AS205944 only peer with AS203040 (Mint Company, LLC) it is evident that the real problem here is Mint Company, LLC and the peering its ASN (AS203040) currently enjoys. Data provided by bgp.he.net indicates that the top three peers of AS203040 are currently as follows: AS24785 Open Peering B.V. AS20562 Open Peering B.V. AS6939 Hurricane Electric, Inc. I will be contacting these companies and asking them to de-peer from AS203040. I make the same request, here and now, to all other networks that may be peering with AS203040. Please stop that peering. Regards, rfg From nanog at studio442.com.au Mon Aug 28 21:41:05 2017 From: nanog at studio442.com.au (Julien Goodwin) Date: Mon, 28 Aug 2017 22:41:05 +0100 Subject: Verizon 701 Route leak? In-Reply-To: <20170828173414.GM915@Vurt.local> References: <0899B986-59B1-4E79-AE86-D5A053B8D50F@gmail.com> <20170828173414.GM915@Vurt.local> Message-ID: <2626812e-6fd6-6c53-0cb6-f0c2140ceadc@studio442.com.au> On 28/08/17 18:34, Job Snijders wrote: > Finally, it may be worthwhile exploring if we can standardize and > promote maximum prefix limits applied on the the _sending_ side. This > way you protect your neighbor (and the Internet at large) by > self-destructing when you inadvertently announce more than what you'd > expect to announce. BIRD has this functionality > http://bird.network.cz/?get_doc&f=bird-3.html#proto-export-limit > however I am not aware of other implementations. Feedback welcome! Having just dug up the reference for some strange reason... Back at NANOG38 (2006) Tom Scholl mentioned in a talk on max prefix: "Perhaps maximum-prefix outbound? (Suggested by Eric Bell years ago)" https://www.nanog.org/meetings/nanog38/presentations/scholl-maxpfx.pdf Notably Juniper does now have prefix-export-limit, but only for readvertisement into IS-IS or OSPF: https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/prefix-export-limit-edit-protocols-isis.html From sean at donelan.com Tue Aug 29 00:29:36 2017 From: sean at donelan.com (Sean Donelan) Date: Mon, 28 Aug 2017 20:29:36 -0400 (EDT) Subject: Hurricane Harvey - Network Status (FCC) In-Reply-To: References: Message-ID: Tropical Storm Harvey FCC DIRS and FEMA Operations report August 28, 2017: Emergency Alert System and Wireless Emergency Alerts between August 25-28 issued by NWS Houston (and surrounding metro area) 154 tornado warnings 149 flood warnings 67 flash flood warnings 27 reported tornados 5 civil emergency messages (at request of local authorities) 268,000 customers without electric power 1,828 people in shelters 16 PSAPs impacted, 1 out of service, 16 with partial service or re-routed to another PSAP (six PSAPs back in service, and five others added) At least 189,487 cable and wireline subscribers out of service (19 switching centers out of service, and 22 switching centers on backup power) 4.7% of cell sites out of service (Aransas, Calhoun, and Refugio in TX have more than 50% of cell sites out of service) 9 radio stations out of service (KKTX, KUNO, KPRC, KKWV, KAYK, KMKS, KZFM, KKBA and KEYS) 1 TV station previously out of service, back in service (KHOU now broadcasting from University of Houston, with assistance from remote news staff in Dallas and San Antonio) https://www.fcc.gov/file/12809/download From rblayzor.bulk at inoc.net Tue Aug 29 00:38:53 2017 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Mon, 28 Aug 2017 20:38:53 -0400 Subject: Cogent BCP-38 In-Reply-To: References: <496940670.3866.1502969745768.JavaMail.mhammett@ThunderFuck> Message-ID: > On Aug 17, 2017, at 9:11 AM, William Herrin wrote: > > Doesn't loose mode URPF allow packets from anything that exists in the > routing table regardless of source? Seems just about worthless. You're > allowing the site to spoof anything in the routing table which is NOT > BCP38. Well not completely useless. BCP will still drop BOGONs at the edge before they leak into your network. -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://inoc.net/~rblayzor/ From rfg at tristatelogic.com Tue Aug 29 05:24:47 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 28 Aug 2017 22:24:47 -0700 Subject: Hijack Factories: AS203418, AS205944, and AS203040 In-Reply-To: <16403.1503947186@segfault.tristatelogic.com> Message-ID: <18912.1503984287@segfault.tristatelogic.com> Sorry to follow-up on myself, but I just now realized that I made a small omission in my earlier post. I indicated that AS205944 (MediaClick, LLC) had previously hijacked the 116.79.0.0/16 block. That is true, but it may perhaps have led some people to incorrectly conclude that AS205944 was not -currently- hijacking anything. Unfortunately, nothing could be further from the truth. As shown here https://bgp.he.net/AS205944#_prefixes and as archived here: http://i.imgur.com/gkW6LUh.png AS205944 is currently announcing 13 IPv4 routes, all of which, except for the five that are for blocks legitimately allocated to either Marketigames, LLC or to Mint Company, LLP appear to be hijacked sub-parts of various legacy ARIN blocks. So, to set the record straight, AS205944 is *currently* engaged in a whole lotta hijacking, as we speak. I should also mention that MediaClick, LLC is actually a defunct Wyoming LLC. It has been struck off the rolls of active Wyoming companies for having failed to pay even its (minimal) Wyoming corporate taxes. RIPE NCC, in its infinite wisdom, will no doubt allow it to continue to exist, and to hold various number resources, indefinitely, but as far as the law is concerned it no longer exists. (The contact phone number for this ASN, as shown in the RIPE WHOIS record for AS205944 is also D.O.A. and probably has been for some time now. Perhaps forever. It may perhaps -never- have worked. RIPE NCC can't be bothered to ever actually check such things.) The good news is that corporate documents archived on the Wyoming Secretary of State's web site indicate clearly and persuasively the identity of the guy behind MediaClick, LLC. That is apparently a frenchman by the name of Mathieu Jean Guillaume, , who is also, apparently the proprietor of a couple of other French companies, i.e. ClicMe, SARL and also something called "YAQ Production" (yaqproduction.com) which appears to have one of these perpetual "under construction" web sites. (Apparently, Mathieu Jean Guillaume fancies himself as a budding film producer. Maybe he could be that, someday, if he ever decides to stop being a lame-ass low-life spammer and hijacker.) Sadly, this schmuck is probably a distant relative of mine. I may perhaps email him and ask why he was unable or unwilling to find some honest way of making a living, and why he turned to Internet crime instead. In the meantime, I repeat my suggestion that everyone who can do so should immediately de-peer from AS203040, which appears to be the roots of all this evil. Regards, rfg From saku at ytti.fi Tue Aug 29 09:44:24 2017 From: saku at ytti.fi (Saku Ytti) Date: Tue, 29 Aug 2017 12:44:24 +0300 Subject: Cogent BCP-38 In-Reply-To: References: <496940670.3866.1502969745768.JavaMail.mhammett@ThunderFuck> Message-ID: On 29 August 2017 at 03:38, Robert Blayzor wrote: > Well not completely useless. BCP will still drop BOGONs at the edge before they leak into your network. Assuming you don't use them in your own infra. And cost of RPF is lot higher than cost of ACL. Them being entirely static entities they should be in your edgeACL. The only real justification for loose RPF is source based blackholing. -- ++ytti From rblayzor.bulk at inoc.net Tue Aug 29 12:41:12 2017 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Tue, 29 Aug 2017 08:41:12 -0400 Subject: Cogent BCP-38 In-Reply-To: References: <496940670.3866.1502969745768.JavaMail.mhammett@ThunderFuck> Message-ID: <806F1F4A-5FB8-45E2-8AAE-D01CC8B33B54@inoc.net> > On 29 August 2017 at 03:38, Robert Blayzor wrote: > >> Well not completely useless. BCP will still drop BOGONs at the edge before they leak into your network. > > Assuming you don't use them in your own infra. And cost of RPF is lot > higher than cost of ACL. Them being entirely static entities they > should be in your edgeACL. The only real justification for loose RPF > is source based blackholing. > > -- > ++ytti Well, if you are using public IP addresses for infra you are violating your RIR’s policy more than likely. And if you’re using RFC1918 space in your global routing table, then thats another fiasco you’ll have to deal with. Managing ACL’s for customer routes has far more overhead (and cost, ie: time, human error, etc) than to just use RPF on an edge port. I believe the OP was talking about multi-homed, in that case if run a tight ship in your network RPF loose is probably a good choice. It at least gives you an easy way to not accept total trash at the edge. -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://inoc.net/~rblayzor/ From job at ntt.net Tue Aug 29 13:30:58 2017 From: job at ntt.net (Job Snijders) Date: Tue, 29 Aug 2017 15:30:58 +0200 Subject: Cogent BCP-38 In-Reply-To: <806F1F4A-5FB8-45E2-8AAE-D01CC8B33B54@inoc.net> References: <496940670.3866.1502969745768.JavaMail.mhammett@ThunderFuck> <806F1F4A-5FB8-45E2-8AAE-D01CC8B33B54@inoc.net> Message-ID: <20170829133058.GW915@Vurt.local> On Tue, Aug 29, 2017 at 08:41:12AM -0400, Robert Blayzor wrote: > > On 29 August 2017 at 03:38, Robert Blayzor wrote: > > > >> Well not completely useless. BCP will still drop BOGONs at the edge > >> before they leak into your network. > > > > Assuming you don't use them in your own infra. And cost of RPF is lot > > higher than cost of ACL. Them being entirely static entities they > > should be in your edgeACL. The only real justification for loose RPF > > is source based blackholing. > > Well, if you are using public IP addresses for infra you are violating > your RIR’s policy more than likely. There may be some miscommunication here or confusion on terminology used. But for instance using public, globally unique addresses for your router's loopback addresses, or router-to-router linknets is fine and not a violation. > And if you’re using RFC1918 space in your global routing table, then > thats another fiasco you’ll have to deal with. Then don't do that! :) > Managing ACL’s for customer routes has far more overhead (and cost, > ie: time, human error, etc) than to just use RPF on an edge port. I > believe the OP was talking about multi-homed, in that case if run a > tight ship in your network RPF loose is probably a good choice. It at > least gives you an easy way to not accept total trash at the edge. I am not sure what "RPF loose" offers that can't be done with a static general purpose edge ACL can't offer to protect your infrastructure and deny obvious bogons. Kind regards, Job From swmike at swm.pp.se Tue Aug 29 14:37:31 2017 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 29 Aug 2017 16:37:31 +0200 (CEST) Subject: Verizon 701 Route leak? In-Reply-To: References: <0899B986-59B1-4E79-AE86-D5A053B8D50F@gmail.com> Message-ID: On Mon, 28 Aug 2017, Marcus Josephson wrote: > Damn you Google.. yup. Thanks for links. A public post-mortem would be highly appreciated (from all parties). -- Mikael Abrahamsson email: swmike at swm.pp.se From internetplumber at gmail.com Tue Aug 29 13:29:17 2017 From: internetplumber at gmail.com (Rob Evans) Date: Tue, 29 Aug 2017 14:29:17 +0100 Subject: Cogent BCP-38 In-Reply-To: <806F1F4A-5FB8-45E2-8AAE-D01CC8B33B54@inoc.net> References: <496940670.3866.1502969745768.JavaMail.mhammett@ThunderFuck> <806F1F4A-5FB8-45E2-8AAE-D01CC8B33B54@inoc.net> Message-ID: > Well, if you are using public IP addresses for infra you are violating your RIR’s policy more than likely. [Citation needed.] :) Rob From stillwaxin at gmail.com Tue Aug 29 18:41:53 2017 From: stillwaxin at gmail.com (Michael Still) Date: Tue, 29 Aug 2017 14:41:53 -0400 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? Message-ID: I agree a max-prefix outbound could potentially be useful and would hopefully not be too terribly difficult to implement for most vendors. Perhaps RFC4486 would need to be updated to reflect this as a possibility as well? On Mon, Aug 28, 2017 at 5:41 PM, Julien Goodwin wrote: > On 28/08/17 18:34, Job Snijders wrote: >> Finally, it may be worthwhile exploring if we can standardize and >> promote maximum prefix limits applied on the the _sending_ side. This >> way you protect your neighbor (and the Internet at large) by >> self-destructing when you inadvertently announce more than what you'd >> expect to announce. BIRD has this functionality >> http://bird.network.cz/?get_doc&f=bird-3.html#proto-export-limit >> however I am not aware of other implementations. Feedback welcome! > > Having just dug up the reference for some strange reason... > > Back at NANOG38 (2006) Tom Scholl mentioned in a talk on max prefix: > "Perhaps maximum-prefix outbound? > (Suggested by Eric Bell years ago)" > https://www.nanog.org/meetings/nanog38/presentations/scholl-maxpfx.pdf > > Notably Juniper does now have prefix-export-limit, but only for > readvertisement into IS-IS or OSPF: > https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/prefix-export-limit-edit-protocols-isis.html -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ From tsesow at osstorage.com Tue Aug 29 22:08:41 2017 From: tsesow at osstorage.com (Timothy Sesow) Date: Tue, 29 Aug 2017 16:08:41 -0600 Subject: Hurricane Harvey - Network Status (FCC) In-Reply-To: References: Message-ID: <1760649e-6acb-893a-a655-bee360844a5b@osstorage.com> Tegna, ownership group of KHOU, had a news report that the news studio for KHOU was setup at a "PBS station in Dallas", with satellite uplink to KUSA (Denver). Master Control is running at KUSA Denver for KHOU service area, with satellite back to the transmitter for KHOU. According to the FCC filing, the transmitter is located SW of Houston near Fresno, TX at 29deg 33min 40secN 95deg 30min 4sec W Google Maps does show a tower there. On 08/28/2017 10:51 AM, Jean-Francois Mezei wrote: > On 2017-08-27 20:58, Tim Jackson wrote: >> KHOU's local transmitter (Missouri City I think is where it's at) seems to >> be back on the air, but with all production from WFAA out of Dallas. > > KHOU had a tweet with video showing the water flooding into their > offices/studios and staff having to leave. > > https://twitter.com/sallykhou11/status/901805513905668096 > > I guess this is where disaster tolerance/recovery plans really kick in. -- --- Timothy Sesow tsesow at osstorage.com Cell: 303-803-3506 Main Support Number 800-570-3624 Open Source Storage, Inc. 7950 S. Lincoln Street Unit B104 Littleton, Colorado 80122 From randy at psg.com Wed Aug 30 01:44:51 2017 From: randy at psg.com (Randy Bush) Date: Wed, 30 Aug 2017 10:44:51 +0900 Subject: Verizon 701 Route leak? In-Reply-To: References: <0899B986-59B1-4E79-AE86-D5A053B8D50F@gmail.com> Message-ID: >> Damn you Google.. yup. Thanks for links. > A public post-mortem would be highly appreciated (from all parties). there has been more press hysteria on this than actual packet droppage. goog fat fingered or otherwise misannounced a numer of large consumer isp's prefixes. the leak was for aybe 20 minutes. almost no one over here noticed. but the press, isoc, ... said "japan knocked off the internet." take that as a calibration of the press, isoc, ... randy From randy at psg.com Wed Aug 30 04:20:16 2017 From: randy at psg.com (Randy Bush) Date: Wed, 30 Aug 2017 13:20:16 +0900 Subject: Verizon 701 Route leak? In-Reply-To: <98EBD357-9D31-4E00-AA9A-118F05BE4716@cisco.com> References: <0899B986-59B1-4E79-AE86-D5A053B8D50F@gmail.com> <98EBD357-9D31-4E00-AA9A-118F05BE4716@cisco.com> Message-ID: > Good use-case for > https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out and > snapshot auditing before and after changes. Leak didn't last long but > it could have been caught within milliseconds verses minutes via oh > sh** alarms. [ i happen to like bmp, but ... ] if the sender did not have the automation or the mops to not leak in the first place, how well will they apply post hoc detection and repair? if the receiver did not filter, and an tier-1 as-path filter would have sufficed in this case, how well do you think they will be at applying post hoc detection and repair? this was an easily preventable ops failure. but what we will do is go to idr and grow and invent 42 more hacks, kinda like ipv6 transition mechanisms. randy From sander at steffann.nl Wed Aug 30 10:38:20 2017 From: sander at steffann.nl (Sander Steffann) Date: Wed, 30 Aug 2017 12:38:20 +0200 Subject: Cogent BCP-38 In-Reply-To: References: <496940670.3866.1502969745768.JavaMail.mhammett@ThunderFuck> <806F1F4A-5FB8-45E2-8AAE-D01CC8B33B54@inoc.net> Message-ID: <6EAF4CD6-4B2B-4C66-A2A0-3450733F211A@steffann.nl> Hi, > Op 29 aug. 2017, om 15:29 heeft Rob Evans het volgende geschreven: > >> Well, if you are using public IP addresses for infra you are violating your RIR’s policy more than likely. > > [Citation needed.] :) I am pretty confident that I know those policies well enough to say that you won't find any ;) Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP URL: From rod.beck at unitedcablecompany.com Wed Aug 30 13:42:54 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Wed, 30 Aug 2017 13:42:54 +0000 Subject: Hurricane Harvey - Network Status (FCC) In-Reply-To: <1760649e-6acb-893a-a655-bee360844a5b@osstorage.com> References: , <1760649e-6acb-893a-a655-bee360844a5b@osstorage.com> Message-ID: How badly was terrestrial telecom infrastructure affected? - R. ________________________________ From: NANOG on behalf of Timothy Sesow Sent: Wednesday, August 30, 2017 12:08 AM To: nanog at nanog.org Subject: Re: Hurricane Harvey - Network Status (FCC) Tegna, ownership group of KHOU, had a news report that the news studio for KHOU was setup at a "PBS station in Dallas", with satellite uplink to KUSA (Denver). Master Control is running at KUSA Denver for KHOU service area, with satellite back to the transmitter for KHOU. According to the FCC filing, the transmitter is located SW of Houston near Fresno, TX at 29deg 33min 40secN 95deg 30min 4sec W Google Maps does show a tower there. On 08/28/2017 10:51 AM, Jean-Francois Mezei wrote: > On 2017-08-27 20:58, Tim Jackson wrote: >> KHOU's local transmitter (Missouri City I think is where it's at) seems to >> be back on the air, but with all production from WFAA out of Dallas. > > KHOU had a tweet with video showing the water flooding into their > offices/studios and staff having to leave. > > https://twitter.com/sallykhou11/status/901805513905668096 [https://www.bing.com/th?id=OVF.PGK%2fiRjE1qEhJtqmND7dSQ&pid=Api] Sally Ramirez on Twitter twitter.com “#khou11 evacuation #hurricaneharvey @BrooksKHOU https://t.co/K4LLKdxFcP” > > I guess this is where disaster tolerance/recovery plans really kick in. -- --- Timothy Sesow tsesow at osstorage.com Cell: 303-803-3506 Main Support Number 800-570-3624 Open Source Storage, Inc. 7950 S. Lincoln Street Unit B104 Littleton, Colorado 80122 From rjacobs at pslightwave.com Wed Aug 30 14:21:03 2017 From: rjacobs at pslightwave.com (Robert Jacobs) Date: Wed, 30 Aug 2017 14:21:03 +0000 Subject: Hurricane Harvey - Network Status (FCC) In-Reply-To: References: , <1760649e-6acb-893a-a655-bee360844a5b@osstorage.com> Message-ID: High Water and loss of power has been biggest issue. Fiber is water proof just need to power to light it up. To many roads are blocked to even try and get generators dispatched. Link to power grid and link to flood gauges http://gis.centerpointenergy.com/outagetracker/ https://www.harriscountyfws.org Robert Jacobs | Network Architect & Director Direct: 832-615-7742   Main:    832-615-8000 Fax:     713-510-1650 5959 Corporate Dr. Suite 3300; Houston, TX 77036 A Certified Woman-Owned Business 24x7x365 Customer  Support: 832-615-8000 | support at pslightwave.com This electronic message contains information from PS Lightwave which may be privileged and confidential. The information is intended to be for the use of individual(s) or entity named above. If you are not the intended recipient, 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 me by telephone or e-mail immediately. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Rod Beck Sent: Wednesday, August 30, 2017 8:43 AM To: Timothy Sesow ; nanog at nanog.org Subject: Re: Hurricane Harvey - Network Status (FCC) How badly was terrestrial telecom infrastructure affected? - R. ________________________________ From: NANOG on behalf of Timothy Sesow Sent: Wednesday, August 30, 2017 12:08 AM To: nanog at nanog.org Subject: Re: Hurricane Harvey - Network Status (FCC) Tegna, ownership group of KHOU, had a news report that the news studio for KHOU was setup at a "PBS station in Dallas", with satellite uplink to KUSA (Denver). Master Control is running at KUSA Denver for KHOU service area, with satellite back to the transmitter for KHOU. According to the FCC filing, the transmitter is located SW of Houston near Fresno, TX at 29deg 33min 40secN 95deg 30min 4sec W Google Maps does show a tower there. On 08/28/2017 10:51 AM, Jean-Francois Mezei wrote: > On 2017-08-27 20:58, Tim Jackson wrote: >> KHOU's local transmitter (Missouri City I think is where it's at) >> seems to be back on the air, but with all production from WFAA out of Dallas. > > KHOU had a tweet with video showing the water flooding into their > offices/studios and staff having to leave. > > https://twitter.com/sallykhou11/status/901805513905668096 [https://www.bing.com/th?id=OVF.PGK%2fiRjE1qEhJtqmND7dSQ&pid=Api] Sally Ramirez on Twitter twitter.com "#khou11 evacuation #hurricaneharvey @BrooksKHOU https://t.co/K4LLKdxFcP" > > I guess this is where disaster tolerance/recovery plans really kick in. -- --- Timothy Sesow tsesow at osstorage.com Cell: 303-803-3506 Main Support Number 800-570-3624 Open Source Storage, Inc. 7950 S. Lincoln Street Unit B104 Littleton, Colorado 80122 From tievens at cisco.com Wed Aug 30 03:14:11 2017 From: tievens at cisco.com (Tim Evens (tievens)) Date: Wed, 30 Aug 2017 03:14:11 +0000 Subject: Verizon 701 Route leak? In-Reply-To: References: <0899B986-59B1-4E79-AE86-D5A053B8D50F@gmail.com> Message-ID: <98EBD357-9D31-4E00-AA9A-118F05BE4716@cisco.com> Good use-case for https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out and snapshot auditing before and after changes. Leak didn't last long but it could have been caught within milliseconds verses minutes via oh sh** alarms. --Tim On 8/29/17, 6:46 PM, "NANOG on behalf of Randy Bush" wrote: >> Damn you Google.. yup. Thanks for links. > A public post-mortem would be highly appreciated (from all parties). there has been more press hysteria on this than actual packet droppage. goog fat fingered or otherwise misannounced a numer of large consumer isp's prefixes. the leak was for aybe 20 minutes. almost no one over here noticed. but the press, isoc, ... said "japan knocked off the internet." take that as a calibration of the press, isoc, ... randy From nanog at ics-il.net Thu Aug 31 03:37:40 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 30 Aug 2017 22:37:40 -0500 (CDT) Subject: I-65 Alabama In-Reply-To: <1854064760.5247.1504150582092.JavaMail.mhammett@ThunderFuck> Message-ID: <2056963195.5256.1504150659145.JavaMail.mhammett@ThunderFuck> Is anyone aware of any non-AT&T, non-Charter fiber routes going up I-65 in Alabama? Most that even go close to there seem to be over on 231. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From alejandroacostaalamo at gmail.com Thu Aug 31 05:01:25 2017 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Thu, 31 Aug 2017 00:01:25 -0500 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: References: Message-ID: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> What a terrific idea..., simple & useful El 29/8/17 a las 1:41 p.m., Michael Still escribió: > I agree a max-prefix outbound could potentially be useful and would > hopefully not be too terribly difficult to implement for most vendors. > > Perhaps RFC4486 would need to be updated to reflect this as a > possibility as well? > > > > On Mon, Aug 28, 2017 at 5:41 PM, Julien Goodwin wrote: >> On 28/08/17 18:34, Job Snijders wrote: >>> Finally, it may be worthwhile exploring if we can standardize and >>> promote maximum prefix limits applied on the the _sending_ side. This >>> way you protect your neighbor (and the Internet at large) by >>> self-destructing when you inadvertently announce more than what you'd >>> expect to announce. BIRD has this functionality >>> http://bird.network.cz/?get_doc&f=bird-3.html#proto-export-limit >>> however I am not aware of other implementations. Feedback welcome! >> Having just dug up the reference for some strange reason... >> >> Back at NANOG38 (2006) Tom Scholl mentioned in a talk on max prefix: >> "Perhaps maximum-prefix outbound? >> (Suggested by Eric Bell years ago)" >> https://www.nanog.org/meetings/nanog38/presentations/scholl-maxpfx.pdf >> >> Notably Juniper does now have prefix-export-limit, but only for >> readvertisement into IS-IS or OSPF: >> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/prefix-export-limit-edit-protocols-isis.html > > From hardaker at isi.edu Wed Aug 30 19:58:56 2017 From: hardaker at isi.edu (Wes Hardaker) Date: Wed, 30 Aug 2017 12:58:56 -0700 Subject: B-Root to be renumbered in October Message-ID: FYI, To help support anycast with more resilient routing, the IPv4 address for b.root-servers.net will be renumbered to 199.9.14.201, effective 2017-10-24. The old IPv4 address (192.228.79.201) will continue to answer queries for at least 6 months. -- Wes Hardaker B-Root Operations USC/ISI From mark.tinka at seacom.mu Thu Aug 31 08:38:10 2017 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 31 Aug 2017 10:38:10 +0200 Subject: SAFNOG-3: Agenda Finalized Message-ID: <2b5d785b-6be7-432a-03fa-cb3e2d9ca877@seacom.mu> Hello all. Pleased to inform you that the SAFNOG-3 agenda is now full! You can view the agenda here: http://safnog.org/ We have a very detailed and exciting line-up, sure to appeal to different parts of our community, such as: - Data Centres. - Peering. - IPv4 Address exhaustion. - SDN/NFV. - FTTH. - Cloud Computing. - IPv6. - Internet Security. - DNS. - BGP. - e.t.c. We also have two very powerful keynote speakers delivering critical and vital information at this year's meeting: - Our opening keynote will be presented by Mr. Pascal Hoba, CEO of UbuntuNet Alliance. - Our closing keynote will be presented by Mr. Alan Barrett, CEO of AFRINIC. Bio information about all of this year's speakers will be available in the coming days. Please check the web site regularly for these updates. Please register your attendance for SAFNOG-3, if you have not yet done so. We look forward to seeing you all in Durban, next week! Cheers, Mark Tinka On Behalf of the SAFNOG Management Committee From marcel.duregards at yahoo.fr Thu Aug 31 10:06:12 2017 From: marcel.duregards at yahoo.fr (marcel.duregards at yahoo.fr) Date: Thu, 31 Aug 2017 12:06:12 +0200 Subject: BGP AS# migration from IOS to IOS-XR Message-ID: <59A7DF94.2000108@yahoo.fr> Dear All, Does anybody had to migrate a entire BGP transit AS# from Cisco IOS to IOS-XR ? Our main concern is BGP, especially conversion from route-map, communities, conditional advertisement, template, peer-group up to RPL. Cisco offer a doc how to migrate from IOS to XR of about 40pages, but it's quite old (XR 3.2) and not so interesting. There are also a lot of documentation about XR/RPL, but I was not able to find a good doc about RPL, and how to translate complex IOS config to XR. Any experience on BGP best pratice with XR, af-group, session-group, neighbor-group, communities implementation from existing IOS config ? And how to you manage RPL editing? I mean with IOS you have some completion on TAB keystroke, but as RPL has to be edited within a text editor, you loose this kind of 'help'. Maybe we have to re-think our config from scrash :-). Thank in advance, Best regards, Marcel From nick at foobar.org Thu Aug 31 10:39:33 2017 From: nick at foobar.org (Nick Hilliard) Date: Thu, 31 Aug 2017 11:39:33 +0100 Subject: BGP AS# migration from IOS to IOS-XR In-Reply-To: <59A7DF94.2000108@yahoo.fr> References: <59A7DF94.2000108@yahoo.fr> Message-ID: <59A7E765.50201@foobar.org> marcel.duregards--- via NANOG wrote: > Cisco offer a doc how to migrate from IOS to XR of about 40pages, but > it's quite old (XR 3.2) and not so interesting. that doc is still relevant. > And how to you manage RPL editing? I mean with IOS you have some > completion on TAB keystroke, but as RPL has to be edited within a text > editor, you loose this kind of 'help'. You can edit RPL from the command-line too, with tab completion and inline help. > Maybe we have to re-think our config from scrash that is a good option in this situation. RPL is significantly more flexible than what's available on vanilla IOS, and you would benefit from learning RPL, then standing back and looking carefully at what you're doing with route routing policy to see how it can be abstracted into well-structured RPL. There are a number of major new features: RPL functions can call other RPL functions, which you can't really do with route-maps (leading to lots of duplication for similar configuration), and passing variables into RPL functions. You can use these features to build up structured RPL configuration mechanisms which give a lot of flexibility and power. Also, XR is better from the point of view of automation. If it makes sense to build automation into your network, this would provide a good opportunity. Nick From jk at ip-clear.de Thu Aug 31 10:50:58 2017 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Thu, 31 Aug 2017 12:50:58 +0200 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> Message-ID: <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> Hi, but isn't peer A prefix-out a synonym for peer B prefix-in, that will lead to the same result, e.g. a BGP teardown? I just feel that this will add another factor, that people will not use or abuse: neigh $x max-out infinite What about adding an option to the BGP session that A & B do agree on a fixed number of prefixes in both directions, so Bs prefix-in could be As prefix-out automatically? Jörg On 31 Aug 2017, at 7:01, Alejandro Acosta wrote: > What a terrific idea..., simple & useful > > > El 29/8/17 a las 1:41 p.m., Michael Still escribió: >> I agree a max-prefix outbound could potentially be useful and would >> hopefully not be too terribly difficult to implement for most >> vendors. >> >> Perhaps RFC4486 would need to be updated to reflect this as a >> possibility as well? >> >> From job at ntt.net Thu Aug 31 11:06:58 2017 From: job at ntt.net (Job Snijders) Date: Thu, 31 Aug 2017 13:06:58 +0200 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> Message-ID: <20170831110658.GH29058@Vurt.local> Dear Jörg, On Thu, Aug 31, 2017 at 12:50:58PM +0200, Jörg Kost wrote: > but isn't peer A prefix-out a synonym for peer B prefix-in, that will > lead to the same result, e.g. a BGP teardown? > > I just feel that this will add another factor, that people will not > use or abuse: neigh $x max-out infinite I feel you may be overlooking a key aspect here: Currently all of us rely on our peer's 'inbound maximum prefix limit', and obviously these are not always set correctly. An 'outbound maximum prefix limit' offers networks that care about the rest of the world the option to 'self-destruct' the EBGP session in order to protect others. An 'outbound maximum prefix limit' is a 'permissionless' feature in that you do not require cooperation or support from your peering partner at the other end of the sessio in order to deploy the 'self-destruct to protect' mechanism. If you don't want to use it, then don't. If people configure "neighbor $x max-out infinite" that is fine by me, at least they made a conscience choice, it is no worse than today, and it is clearly documented in the running-configuration what the ramifications of the EBGP session could be. > What about adding an option to the BGP session that A & B do agree on > a fixed number of prefixes in both directions, so Bs prefix-in could > be As prefix-out automatically? I prefer unilateral permissionless mechanisms. Adding new negotiable options to BGP sessions is a lot of work and requires both parties to run software that supports the new feature, whatever it is. Anything that can be done without requiring your peer's cooperation will be more robust. Kind regards, Job From uwcableguy at gmail.com Thu Aug 31 11:20:34 2017 From: uwcableguy at gmail.com (Ben Bartsch) Date: Thu, 31 Aug 2017 06:20:34 -0500 Subject: BGP AS# migration from IOS to IOS-XR In-Reply-To: <59A7E765.50201@foobar.org> References: <59A7DF94.2000108@yahoo.fr> <59A7E765.50201@foobar.org> Message-ID: Get in touch with your Cisco SE or partner. Cisco SE's have access to a conversion tool that takes in an IOS config and spits out an XR config. It's usually about 80-95% correct. It even shows you sections that are not in use and can be removed. On Thu, Aug 31, 2017 at 5:39 AM, Nick Hilliard wrote: > marcel.duregards--- via NANOG wrote: > > Cisco offer a doc how to migrate from IOS to XR of about 40pages, but > > it's quite old (XR 3.2) and not so interesting. > > that doc is still relevant. > > > And how to you manage RPL editing? I mean with IOS you have some > > completion on TAB keystroke, but as RPL has to be edited within a text > > editor, you loose this kind of 'help'. > > You can edit RPL from the command-line too, with tab completion and > inline help. > > > Maybe we have to re-think our config from scrash > > that is a good option in this situation. RPL is significantly more > flexible than what's available on vanilla IOS, and you would benefit > from learning RPL, then standing back and looking carefully at what > you're doing with route routing policy to see how it can be abstracted > into well-structured RPL. > > There are a number of major new features: RPL functions can call other > RPL functions, which you can't really do with route-maps (leading to > lots of duplication for similar configuration), and passing variables > into RPL functions. You can use these features to build up structured > RPL configuration mechanisms which give a lot of flexibility and power. > > Also, XR is better from the point of view of automation. If it makes > sense to build automation into your network, this would provide a good > opportunity. > > Nick > From marcel.duregards at yahoo.fr Thu Aug 31 12:13:41 2017 From: marcel.duregards at yahoo.fr (marcel.duregards at yahoo.fr) Date: Thu, 31 Aug 2017 14:13:41 +0200 Subject: Cogent BCP-38 In-Reply-To: References: Message-ID: <59A7FD75.5070403@yahoo.fr> Really surprised that AS174 put in place any anti-spoofing. We are bgp-transit customer of CGNT and received traffic originated from RFC1918 on our public p2p link with them On 15.08.2017 17:36, Ben Russell wrote: > Could someone from Cogent contact me off-list? We are having an issue with one of our downstream customers who is multi-homed to another carrier. The end customer is advertising their prefix to both us and the other carrier. Both us and the other carrier peer with 174. However, if the prefix is preferred through us and the outbound traffic flows over the other carrier it is dropped. We suspect uRPF-strict on the other carriers Cogent link. We are working together with the other carrier and have a ticket open the help desk seem to be confused. Any help would be appreciated. Thanks > > > Ben Russell > Senior Network Engineer > Stratus Networks > (309)370-3174 > [logo] From jk at ip-clear.de Thu Aug 31 13:21:44 2017 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Thu, 31 Aug 2017 15:21:44 +0200 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: <20170831110658.GH29058@Vurt.local> References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> <20170831110658.GH29058@Vurt.local> Message-ID: Hi, but in reality you will factorise and summarize outbound and inbound numbers, create spare room for sessions and failover scenarios and therefore leaks and especially partial leaks can still occur. In another example scenario the BGP process may not only shutdown the session to B, that has run into an outbound warning, but all other sessions to prevent "leaks". Last-resort the router will only judge by the number of the prefixes and therefore could shutdown himself by accident, especially if this router was not the origin. That could be a global headache ;-) Jörg On 31 Aug 2017, at 13:06, Job Snijders wrote: > Dear Jörg, > > On Thu, Aug 31, 2017 at 12:50:58PM +0200, Jörg Kost wrote: >> but isn't peer A prefix-out a synonym for peer B prefix-in, that will >> lead to the same result, e.g. a BGP teardown? >> >> I just feel that this will add another factor, that people will not >> use or abuse: neigh $x max-out infinite > > I feel you may be overlooking a key aspect here: Currently all of us > rely on our peer's 'inbound maximum prefix limit', and obviously these > are not always set correctly. An 'outbound maximum prefix limit' > offers > networks that care about the rest of the world the option to > 'self-destruct' the EBGP session in order to protect others. > From stillwaxin at gmail.com Thu Aug 31 14:02:44 2017 From: stillwaxin at gmail.com (Michael Still) Date: Thu, 31 Aug 2017 10:02:44 -0400 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> <20170831110658.GH29058@Vurt.local> Message-ID: I think what this is is just a new (potentially) knob that can be turned. If you don't want to turn it that's your deal, you run your network how you want. There's been no suggestion that there be some explicit default value or even that its turned on by default so behavior won't change unless configured and if you configure it, you are on the hook for knowing how that might affect the behavior of your network. I would expect BGP speakers (router vendors / software devs) to implement this in a way such that it would syslog or otherwise trigger when the number of outbound prefixes reaches a specific percentage (of configured limit) or hard number so that either an engineer could respond or automation take place to do something in response. On Thu, Aug 31, 2017 at 9:21 AM, Jörg Kost wrote: > Hi, > > but in reality you will factorise and summarize outbound and inbound > numbers, create spare room for sessions and failover scenarios and therefore > leaks and especially partial leaks can still occur. > > In another example scenario the BGP process may not only shutdown the > session to B, that has run into an outbound warning, but all other sessions > to prevent "leaks". Last-resort the router will only judge by the number of > the prefixes and therefore could shutdown himself by accident, especially if > this router was not the origin. That could be a global headache ;-) > > Jörg > > > On 31 Aug 2017, at 13:06, Job Snijders wrote: > >> Dear Jörg, >> >> On Thu, Aug 31, 2017 at 12:50:58PM +0200, Jörg Kost wrote: >>> >>> but isn't peer A prefix-out a synonym for peer B prefix-in, that will >>> lead to the same result, e.g. a BGP teardown? >>> >>> I just feel that this will add another factor, that people will not >>> use or abuse: neigh $x max-out infinite >> >> >> I feel you may be overlooking a key aspect here: Currently all of us >> rely on our peer's 'inbound maximum prefix limit', and obviously these >> are not always set correctly. An 'outbound maximum prefix limit' offers >> networks that care about the rest of the world the option to >> 'self-destruct' the EBGP session in order to protect others. >> > -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ From bicknell at ufp.org Thu Aug 31 15:24:30 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 31 Aug 2017 08:24:30 -0700 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> Message-ID: <20170831152430.GA31292@ussenterprise.ufp.org> In a message written on Thu, Aug 31, 2017 at 12:50:58PM +0200, J??rg Kost wrote: > What about adding an option to the BGP session that A & B do agree on a > fixed number of prefixes in both directions, so Bs prefix-in could be As > prefix-out automatically? As others have pointed out, that's harder to do, but there's a different reason it may not be desireable. If a peer sets a limit to tear down the session with no automatic reset, forcing a call to their NOC to get a human to reset it then it may be advantageous to set your side to tear down at N-1 prefixes. That way you can insure restoration at the speed of your NOC, and not at the speed of your peer's. -- 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 morrowc.lists at gmail.com Thu Aug 31 15:57:19 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 31 Aug 2017 11:57:19 -0400 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: <20170831152430.GA31292@ussenterprise.ufp.org> References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> <20170831152430.GA31292@ussenterprise.ufp.org> Message-ID: On Thu, Aug 31, 2017 at 11:24 AM, Leo Bicknell wrote: > In a message written on Thu, Aug 31, 2017 at 12:50:58PM +0200, J??rg Kost > wrote: > > What about adding an option to the BGP session that A & B do agree on a > > fixed number of prefixes in both directions, so Bs prefix-in could be As > > prefix-out automatically? > > As others have pointed out, that's harder to do, but there's a > different reason it may not be desireable. > > If a peer sets a limit to tear down the session with no automatic > reset, forcing a call to their NOC to get a human to reset it then > it may be advantageous to set your side to tear down at N-1 prefixes. > That way you can insure restoration at the speed of your NOC, and > not at the speed of your peer's. > Generally controlling your own destiny is preferred, I agree with that. I think also being able to say: "I shouldn't ever send more than 477 routes, let's round up for ops reasons to 1k max" seems like a great way to make your network safer for the rest of the network. Yes, people (as job and others noted) could set 'too high' limits... ok, that's their decision to make. Yes, maybe in the 523 prefixes that leak in my example there could be some affected party... I think it's pretty unlikely that there will be widescale damage from a small number of routes leaking, there are certainly plenty of documented cases of wide scale problems from full table leaks though :) Yes, your sessions might bounce or stay-down... it's probably better to go down on a some peers and have control to get back up on your side, than to cause widescale outages due to a full table leak. i'd be in favor of a output max prefix limit knob. From andy.litzinger.lists at gmail.com Thu Aug 31 14:01:24 2017 From: andy.litzinger.lists at gmail.com (Andy Litzinger) Date: Thu, 31 Aug 2017 07:01:24 -0700 Subject: Validating possible BGP MITM attack Message-ID: Hello, we use BGPMon.net to monitor our BGP announcements. This morning we received two possible BGP MITM alerts for two of our prefixes detected by a single BGPMon probe located in China. I've reached out to BGPMon to see how much credence I should give to an alert from a single probe location, but I'm interested in community feedback as well. The alert detailed that one of our /23 prefixes has been broken into /24 specifics and the AS Path shows a peering relationship with us that does not exist: 131477(Shanghai Huajan) 38478(Sunny Vision LTD) 3491(PCCW Global) 14042 (me) We do not peer directly with PCCW Global. I'm going to reach out to them directly to see if they may have done anything by accident, but presuming they haven't and the path is spoofed, can I prove that? How can I detect if traffic is indeed swinging through that hijacked path? How worried should I be and what are my options for resolving the situation? thanks! -andy From job at instituut.net Thu Aug 31 17:01:36 2017 From: job at instituut.net (Job Snijders) Date: Thu, 31 Aug 2017 17:01:36 +0000 Subject: Validating possible BGP MITM attack In-Reply-To: References: Message-ID: Hi Andy, It smells like someone in 38478 or 131477 is using Noction or some other BGP "optimizer" that injects hijacks for the purpose of traffic engineering. :-( Kind regards, Job On Thu, 31 Aug 2017 at 19:38, Andy Litzinger wrote: > Hello, > we use BGPMon.net to monitor our BGP announcements. This morning we > received two possible BGP MITM alerts for two of our prefixes detected by a > single BGPMon probe located in China. I've reached out to BGPMon to see > how much credence I should give to an alert from a single probe location, > but I'm interested in community feedback as well. > > The alert detailed that one of our /23 prefixes has been broken into /24 > specifics and the AS Path shows a peering relationship with us that does > not exist: > 131477(Shanghai Huajan) 38478(Sunny Vision LTD) 3491(PCCW Global) 14042 > (me) > > We do not peer directly with PCCW Global. I'm going to reach out to them > directly to see if they may have done anything by accident, but presuming > they haven't and the path is spoofed, can I prove that? How can I detect > if traffic is indeed swinging through that hijacked path? How worried > should I be and what are my options for resolving the situation? > > thanks! > -andy > From achatz at forthnet.gr Thu Aug 31 17:20:41 2017 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Thu, 31 Aug 2017 20:20:41 +0300 Subject: Max Prefix Out, was Re: Verizon 701 Route leak? In-Reply-To: <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> References: <8ba013d1-232b-1d60-50c2-6c3dd4a8c90f@gmail.com> <3C632718-E45B-4D41-93D5-30EC8B09AFEB@ip-clear.de> Message-ID: <6291cfa3-7143-54df-1ab5-8a41c646b4e0@forthnet.gr> I guess you're looking into something similar to https://tools.ietf.org/html/draft-keyur-idr-bgp-prefix-limit-orf. -- Tassos Jörg Kost wrote on 31/8/17 13:50: > > > What about adding an option to the BGP session that A & B do agree on a fixed number of prefixes in both directions, so Bs prefix-in could be As prefix-out automatically? > > Jörg > From feldman at twincreeks.net Thu Aug 31 17:23:04 2017 From: feldman at twincreeks.net (Steve Feldman) Date: Thu, 31 Aug 2017 10:23:04 -0700 Subject: Validating possible BGP MITM attack In-Reply-To: References: Message-ID: Interesting. We also got similar BGPMon alerts about disaggregated portions of couple of our prefixes. I didn't see any of the bad prefixes in route-views, though. The AS paths in the alerts started with "131477 38478 ..." and looked valid after that. Job's suggestion would explain that. Steve > On Aug 31, 2017, at 10:01 AM, Job Snijders wrote: > > Hi Andy, > > It smells like someone in 38478 or 131477 is using Noction or some other > BGP "optimizer" that injects hijacks for the purpose of traffic > engineering. :-( > > Kind regards, > > Job > > On Thu, 31 Aug 2017 at 19:38, Andy Litzinger > wrote: > >> Hello, >> we use BGPMon.net to monitor our BGP announcements. This morning we >> received two possible BGP MITM alerts for two of our prefixes detected by a >> single BGPMon probe located in China. I've reached out to BGPMon to see >> how much credence I should give to an alert from a single probe location, >> but I'm interested in community feedback as well. >> >> The alert detailed that one of our /23 prefixes has been broken into /24 >> specifics and the AS Path shows a peering relationship with us that does >> not exist: >> 131477(Shanghai Huajan) 38478(Sunny Vision LTD) 3491(PCCW Global) 14042 >> (me) >> >> We do not peer directly with PCCW Global. I'm going to reach out to them >> directly to see if they may have done anything by accident, but presuming >> they haven't and the path is spoofed, can I prove that? How can I detect >> if traffic is indeed swinging through that hijacked path? How worried >> should I be and what are my options for resolving the situation? >> >> thanks! >> -andy >> > From morrowc.lists at gmail.com Thu Aug 31 17:47:09 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 31 Aug 2017 13:47:09 -0400 Subject: Validating possible BGP MITM attack In-Reply-To: References: Message-ID: On Thu, Aug 31, 2017 at 1:23 PM, Steve Feldman wrote: > Interesting. We also got similar BGPMon alerts about disaggregated > portions of couple of our prefixes. I didn't see any of the bad prefixes in > route-views, though. > > The AS paths in the alerts started with "131477 38478 ..." and looked > valid after that. Job's suggestion would explain that. > > Looking back at a bunch of historical route leak incidents... they often seem to be this sort of thing :( I think I normally term them; "internap box problems" I think internap doesn't even really sell that product anymore though :( so now I'll call them 'noction problems' instead I guess. lack of outbound route filtering can be painful yo! > Steve > > > On Aug 31, 2017, at 10:01 AM, Job Snijders wrote: > > > > Hi Andy, > > > > It smells like someone in 38478 or 131477 is using Noction or some other > > BGP "optimizer" that injects hijacks for the purpose of traffic > > engineering. :-( > > > > Kind regards, > > > > Job > > > > On Thu, 31 Aug 2017 at 19:38, Andy Litzinger < > andy.litzinger.lists at gmail.com> > > wrote: > > > >> Hello, > >> we use BGPMon.net to monitor our BGP announcements. This morning we > >> received two possible BGP MITM alerts for two of our prefixes detected > by a > >> single BGPMon probe located in China. I've reached out to BGPMon to see > >> how much credence I should give to an alert from a single probe > location, > >> but I'm interested in community feedback as well. > >> > >> The alert detailed that one of our /23 prefixes has been broken into /24 > >> specifics and the AS Path shows a peering relationship with us that does > >> not exist: > >> 131477(Shanghai Huajan) 38478(Sunny Vision LTD) 3491(PCCW Global) 14042 > >> (me) > >> > >> We do not peer directly with PCCW Global. I'm going to reach out to > them > >> directly to see if they may have done anything by accident, but > presuming > >> they haven't and the path is spoofed, can I prove that? How can I > detect > >> if traffic is indeed swinging through that hijacked path? How worried > >> should I be and what are my options for resolving the situation? > >> > >> thanks! > >> -andy > >> > > > > From andy.litzinger.lists at gmail.com Thu Aug 31 18:13:18 2017 From: andy.litzinger.lists at gmail.com (Andy Litzinger) Date: Thu, 31 Aug 2017 11:13:18 -0700 Subject: Validating possible BGP MITM attack In-Reply-To: References: Message-ID: Hi Steve and Job, Same here- I didn't actually see my prefixes leaked anywhere I could check, but I couldn't check near China where BGPmon's probe was complaining. So I was glad it didn't seem to be spreading, but still concerned that there may have been a large area (China) where my traffic was getting hijacked. The alert did clear after around 18 minutes. Presuming it was a route optimizer and the issue was ongoing, what would be the suggested course of action? reach out to those 2 AS owners and see if they could stop it? Or is it something I just have to live with as a traffic engineering solution they are using and mark the alerts as false positives? thanks! -andy On Thu, Aug 31, 2017 at 10:23 AM, Steve Feldman wrote: > Interesting. We also got similar BGPMon alerts about disaggregated > portions of couple of our prefixes. I didn't see any of the bad prefixes > in route-views, though. > > The AS paths in the alerts started with "131477 38478 ..." and looked > valid after that. Job's suggestion would explain that. > > Steve > > On Aug 31, 2017, at 10:01 AM, Job Snijders wrote: > > Hi Andy, > > It smells like someone in 38478 or 131477 is using Noction or some other > BGP "optimizer" that injects hijacks for the purpose of traffic > engineering. :-( > > Kind regards, > > Job > > On Thu, 31 Aug 2017 at 19:38, Andy Litzinger com> > wrote: > > Hello, > we use BGPMon.net to monitor our BGP announcements. This morning we > received two possible BGP MITM alerts for two of our prefixes detected by a > single BGPMon probe located in China. I've reached out to BGPMon to see > how much credence I should give to an alert from a single probe location, > but I'm interested in community feedback as well. > > The alert detailed that one of our /23 prefixes has been broken into /24 > specifics and the AS Path shows a peering relationship with us that does > not exist: > 131477(Shanghai Huajan) 38478(Sunny Vision LTD) 3491(PCCW Global) 14042 > (me) > > We do not peer directly with PCCW Global. I'm going to reach out to them > directly to see if they may have done anything by accident, but presuming > they haven't and the path is spoofed, can I prove that? How can I detect > if traffic is indeed swinging through that hijacked path? How worried > should I be and what are my options for resolving the situation? > > thanks! > -andy > > > > From andy.litzinger.lists at gmail.com Thu Aug 31 18:34:52 2017 From: andy.litzinger.lists at gmail.com (Andy Litzinger) Date: Thu, 31 Aug 2017 11:34:52 -0700 Subject: Validating possible BGP MITM attack In-Reply-To: References: Message-ID: FYI - I did get a response back from BGPMon- they concur with Job: "Hi Andy, unfortunately we had a peer sending us a polluted BGP views. Most likely using a BGP optimizer that is making up new paths. We've reached out to 131477 and dropped the session with them. This was most likely 131477 making up the paths. And not seen wider on the Internet. We'll work on making sure that cases like this will not cause bgpmon alerts going forward, by detecting these false alerts better." -andy On Thu, Aug 31, 2017 at 7:01 AM, Andy Litzinger < andy.litzinger.lists at gmail.com> wrote: > Hello, > we use BGPMon.net to monitor our BGP announcements. This morning we > received two possible BGP MITM alerts for two of our prefixes detected by a > single BGPMon probe located in China. I've reached out to BGPMon to see > how much credence I should give to an alert from a single probe location, > but I'm interested in community feedback as well. > > The alert detailed that one of our /23 prefixes has been broken into /24 > specifics and the AS Path shows a peering relationship with us that does > not exist: > 131477(Shanghai Huajan) 38478(Sunny Vision LTD) 3491(PCCW Global) 14042 > (me) > > We do not peer directly with PCCW Global. I'm going to reach out to them > directly to see if they may have done anything by accident, but presuming > they haven't and the path is spoofed, can I prove that? How can I detect > if traffic is indeed swinging through that hijacked path? How worried > should I be and what are my options for resolving the situation? > > thanks! > -andy > From job at ntt.net Thu Aug 31 20:06:49 2017 From: job at ntt.net (Job Snijders) Date: Thu, 31 Aug 2017 22:06:49 +0200 Subject: BGP Optimizers (Was: Validating possible BGP MITM attack) Message-ID: <20170831200649.GP29058@Vurt.local> Dear all, disclaimer: [ The following is targetted at the context where a BGP optimizer generates BGP announcement that are ordinarily not seen in the Default-Free Zone. The OP indicated they announce a /23, and were unpleasantly surprised to see two unauthorized announcements for /24 more-specifics pop up in their alerting system. No permission was granted to create and announce these more-specifics. The AS_PATH for those /24 announcements was entirely fabricated. Original thread https://mailman.nanog.org/pipermail/nanog/2017-August/092124.html ] On Thu, Aug 31, 2017 at 11:13:18AM -0700, Andy Litzinger wrote: > Presuming it was a route optimizer and the issue was ongoing, what > would be the suggested course of action? I strongly recommend to turn off those BGP optimizers, glue the ports shut, burn the hardware, and salt the grounds on which the BGP optimizer sales people walked. It is extremely irresponsible behavior to use software that generates _fake_ BGP more-specifics for the purpose of traffic engineering. You simply cannot expect that those more-specifics will never escape into the global DFZ! Relying on NO_EXPORT is not sufficient: we regularly see software bugs related to NO_EXPORT, and community-squashing configuration mistakes happen all the time. Consider the following: if you leak your own internal more-specifics, at least you are the legitimate destination. (You may suffer from suboptimal routing, but it isn't guaranteed downtime.) However if you generate fake more-specifics for prefixes belonging to OTHER organisations, you essentially are complicit in BGP hijacking. If those fake more-specifics accidentally leak into the DFZ, you are bringing down the actual owner of such prefixes, and depriving people from access to the Internet. Example case: https://mailman.nanog.org/pipermail/nanog/2013-January/054846.html > reach out to those 2 AS owners and see if they could stop it? Yes, absolutely! And if everyone of the affected parties of this localized hijack leak (or should we say 'victims') reaches out to the wrongdoers, they contribute peer pressure to rectify the situation. Just make sure you assign blame to the correct party. :) > Or is it something I just have to live with as a traffic engineering > solution they are using and mark the alerts as false positives? No, this is not something we should just accept. The Default-Free Zone is a shared resource. Anyone using "BGP optimizers" is not only risking their own online presence, but also everyone else's. Using a BGP optimizer is essentially trading a degree of risk to society for the purpose of saving a few bucks or milliseconds. It is basically saying: "The optimizer helps me, but may hurt others, and I am fine with that". An analogy: We don't want transporters of radioactive material to cut corners by using non-existant roads to bring the spent nuclear fuels from A to B faster, nor do we want them to rely on non-robust shielding that works "most of the time". We share the BGP DFZ environment, 'BGP optimizers' are downright pollution contributors. Kind regards, Job ps. If you want to do BGP optimization: don't have the BGP optimizer generate fake BGP announcements, but focus only on manipulating non-transitive attributes (like LOCAL_PREF) on real announcements you actually received from others. Or Perhaps BGP optimizers shouldn't even talk BGP but rather push freshly generated TE-optimized routing-policy to your edge boxes. Or perhaps the 'BGP optimizer' vendors should come to IETF to figure out a safe way (maybe a new AFI/SAFI to manipulate real announcements)... there are ways to do this, without risk to others! p.s. providing a publicly available BGP looking glasses will contribute to proving your innocence in cases like these. Since in many cases the AS_PATH is a complete fabrication, we need to manually check every AS in the AS_PATH to see whether the AS carries the fake more-specific. A public looking glass speeds up this fault-finding process. If you don't want to host a webinterface yourself, please consider sending a BGP feed to the Route Views Project or RIPE RIS, or for something queryable in a real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/ From rfg at tristatelogic.com Thu Aug 31 20:29:35 2017 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 31 Aug 2017 13:29:35 -0700 Subject: Hijacks: AS12506, AS327814, AS44582, AS62135 Message-ID: <45188.1504211375@segfault.tristatelogic.com> The following set of interrelated networks appear to be engaged in hijacking various IPv4 address blocks at the present time: AS12506 Inspiring Networks, B.V. (Netherlands) AS44582 Inspiring Networks, B.V. (Netherlands) AS62135 Inspiring Networks, B.V. (Netherlands) AS327814 Echoband, Ltd. (Ghana) The specific routes that are unambiguously being hijacked by each of these networks are as follows: AS12506: 152.108.0.0/16 155.159.0.0/16 196.15.64.0/18 AS327814: 163.198.0.0/18 164.88.0.0/16 168.80.0.0/17 168.80.128.0/17 AS44582: 175.53.0.0/17 175.53.128.0/17 175.54.0.0/17 175.54.128.0/17 AS62135: 160.116.32.0/20 160.116.128.0/20 160.116.240.0/20 160.122.144.0/20 Screenshots of the bgp.he.net prefixes reports for the above networks are archived here: http://i.imgur.com/5HuDRYX.png (AS12506) http://i.imgur.com/YishDCK.png (AS44582) http://i.imgur.com/lgiAKWz.png (AS62135) http://i.imgur.com/IM9Wf5h.png (AS327814) (Note that the set of routes announced by the four networks in question has changed slightly since the last bgp.he.net update -- 30 Aug 2017 14:48 PST. The route for 163.198.0.0/18 has been dropped and the routes for 160.116.128.0/20 and 160.122.144.0/20 have been added.) As seen in previous hijackings, and as is consistant with the general nature of such hijackings, no individual IP addresses within any of the above listed routes have any functioning reverse DNS delegation. Note that AS44582 (Inspiring Networks) and AS62135 (Inspiring Networks) really only have a single upstream connection to the Internet, at least as far as public BGP is concerned, and that is AS12506 (Inspiring Networks). Meanwhile, AS12506 (Inspiring Networks) has only a single BGP upstream, which is AS49544 i3D.net B.V (Netherlands). Therefore, the majority of this hijacking activity is only made possible via the generous help and assistance of AS49544, i3D.net B.V. Inspiring Networks is apparently run by one Maikel Jozef Gerardus Uerlings, : https://labs.ripe.net/Members/maikel_uerlings https://nl.linkedin.com/in/maikel-uerlings-072aaa65 https://twitter.com/maikeluerlings (recently disappeared) https://www.facebook.com/maikel.uerlings http://uerlings.nl/ On February 24, 2013, over four years ago, Mr. Uerlings apparently promised his Facebook friends and fans that his new corporate web site would be "launched soon". As of today however, Mr. Uerlings' corporate web site for Inspiring Networks stil contains only generic/boilerplate "Lorem ipsum" type filler text: https://inspiringnetworks.com/ It would thus appear that Mr. Uerlings has other ways of attracting customers, other than his minimalist placeholder corporate web site. In any case, Mr. Uerlings has apparently gotten some bad press on a couple of occasions, for example the following blog post by some anonymous spammer who felt that Mr. Uerlings didn't actually deliver on his promises of "fresh IPs for mailing": http://maikel-uerlings-inspiring-networks.blogspot.com/ Mr. Uerlings' name also came up in the context of a 2013 attempt by Microsoft to take down a certain botnet: Microsoft v. Botnet United States Court for the Western District of Texas Case: A-13-CV-1014SS http://botnetlegalnotice.com/zeroaccess/files/Summons_Does_1-8.pdf (... Care of: Maikel Uerlings, cust597 at serverius.com ...) Other folks also have, or had, a rather unfavorable opinion of Mr. Uerlings also, it would seem: https://www.mywot.com/en/scorecard/uerlings.nl https://www.scamwarners.com/forum/viewtopic.php?p=123180 https://unapprovedpharmacy.com/category/counterfeit-drugs-alert/page/12/ As usual, I wouldn't even mind about any of this hijacking activity if it were not for the fact that at least some porgtion of the hijacked IPv4 space appears to have been populated with snowshoe spammer domains: https://pastebin.com/raw/As9nVCMV I cannot help but wonder if there is something in the water supply in the Netherlands that may be causing so much hijacking activity to originate from that country. I do understand that Netherlands has what I gather is the best connectivity in all of Europe, but even that does not fully explain, I think, the Netherland's disproportionate share of these sorts of events and incidents, in this case involving Inspiring Networks, B.V. and clearly supported by AS49544, i3D.net B.V, also of the Netherlands. Regards, rfg P.s. Don't be fooled by hijackings of IP blocks that were historically allocated by AFRINIC to various corporate entities in the Seychelles Islands. Many of those corporate entities have long since died, and their associated IPv4 blocks have thus been abandoned. Unfortunately, due to the unique and very strict corporate secrecy laws in the Seychelles, it is not possible for any outsider to find out even if these entiries still exist or not, let alone who their corporate officers are or might have been. Thus, literally anybody can come along, after the fact (even lawyers) and claim to be representing the rightful owers of these blocks. And there is apparently no way, either verify or to disprove any such claims. Thus, hijacking the IP blocks of any defunct Seychelles Islands company is very nearly "The Perfect Crime". The only catch is that AFRINIC has, in its archives, the names of the actual corporate officers who originally requested (and were granted) the IP block allocations originally. And thus, they at least cannot be so easily fooled by any usurpers who are mearly pretending to be the rightful owners of these blocks. So it is actually pretty easy to tell which IPv4 blocks registered to Seychelles Islands companies have been hijacked. If they are hijacked by persons who are not actually acting on behalf of the true rightful owners of these blocks, then the thieves in question will not have been able to snooker AFRINIC into delegating reverse DNS authority for the blocks to them. So this is the simple acid test. If a given IP address block is allocated, from AFRINIC, to some corporate entity in the Seychelles Islands, and if that block has no working reverse DNS, then there's probably a very good reason for that, i.e. it's hijacked. And the hijacking has taken place without any knowledge of this event whatssoever on the part of AFRINIC. From martijnschmidt at i3d.net Thu Aug 31 22:05:34 2017 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Fri, 1 Sep 2017 00:05:34 +0200 Subject: Hijacks: AS12506, AS327814, AS44582, AS62135 In-Reply-To: <45188.1504211375@segfault.tristatelogic.com> References: <45188.1504211375@segfault.tristatelogic.com> Message-ID: Dear Ronald, Thanks for the investigative work, we will look into your report and take the appropriate action. Kind regards, Martijn Schmidt i3D.net / AS49544 PS: if anyone suspects that any of our customers are misbehaving, we would very much appreciate hearing about it directly via abuse at i3d.net as opposed to seeing the information for the first time on a public mailing list. All abuse reports are handled on a case-by-case basis by our own support staff in our headquarters in the Netherlands.