- Test - lists.nanog.org

Re: Hawaii exchange and connection to mainland pops
by Scott Weeks 29 Jan '20

29 Jan '20

--- a.matamalas(a)gmail.com wrote: From: Antoni Matamalas <a.matamalas(a)gmail.com> I'm trying to figure out how is the connectivity in the Hawaiian Islands for a project I have. I'm based in Europe and my knowledge of the details of the communications in the islands is still limited. The project is based in the O'ahu island but I'm trying to understand how things are working in the whole Hawaiian islands (pure professional curiosity). I'm focusing on two aspects: * Content delivery and connection to content providers (Google, Apple, Netflix,...) * Availability of providers that can supply wavelength between Hawaiian Islands and the continent (LA, Seattle or other locations) -------------------------------------------------- I'm assuming you're talking Commercial only? DoD is a different animal as is UH. I work for the ILEC and can fill you in on that to a certain degree. We have the normal Google/Netflix/Akamai/etc caches. The population in the state of Hawaii is small. https://census.hawaii.gov/whats-new-releases/2019-state-population-estimates On July 1, 2019, the resident population for the State of Hawaii was 1,415,872. And of those about 1 million live on one island: Oahu. There're 5 other islands. We have a lot of trans-pacific fiber landing here, but it mostly just transits the island. Not much gets peeled off to service the state due to its size. The ILEC owns part of SEA-US: https://www.submarinenetworks.com/systems/trans-pacific/sea-us and we get service on Hawaiki for South Pacific connectivity. https://www.submarinenetworks.com/en/systems/australia-usa/hawaiki-cable Most of the inter-island fiber is owned by the ILEC, which was bought by Cincinatti Bell, which will be bought by either Brookfield Infrastructure or another company whose name isn't public yet. (Anyone been bought by BI? email me, please) As mentioned in another email HIX is the internet exchange managed by UH and DR Fortress connects to that. We do as well: http://www.hawaii.edu/hix/Hawaii_Internet_Exchange/Home.html https://www.drfortress.com/about/company-overview/ https://www.drfortress.com/services/internet-exchange/overview/ https://www.drfortress.com/services/internet-exchange/drfxchange/ https://www.drfortress.com/services/internet-exchange/peering-and-connectiv… scott

1 0

AFRINIC: The Saga Continues
by Ronald F. Guilmette 29 Jan '20

29 Jan '20

For the benefit of those of you who may have been living in caves for the past two months, I would like to share the following links regarding a massive fraud that appears to have been perpetrated by at least one AFRINIC insider. (It has still not been definitively determined if he had help or not.) https://mybroadband.co.za/news/internet/330379-how-internet-resources-worth… https://krebsonsecurity.com/2019/12/the-great-50m-african-ip-address-heist/ https://www.theregister.co.uk/2019/12/17/another_afrinic_scandal/ https://mybroadband.co.za/news/security/335226-here-are-the-police-charges-… I hate to say that I told you so, but I told you so. I reported right here on the NANOG list, in both 2016 and 2017, that there was quite a lot of funny business going on down in Africa. Nobody listened and there was no meaningful investigation whatsoever by anybody until I took it upon myself, starting in July of last year, to finally get to the bottom of this colossal mess. Here are links to my old public posts relating to this: November, 2016: https://mailman.nanog.org/pipermail/nanog/2016-November/089164.html https://mailman.nanog.org/pipermail/nanog/2016-November/089232.html https://lists.afrinic.net/pipermail/rpd/2016/006129.html August, 2017: https://mailman.nanog.org/pipermail/nanog/2017-August/091821.html https://mailman.nanog.org/pipermail/nanog/2017-August/091954.html https://mailman.nanog.org/pipermail/nanog/2017-August/092092.html AFRINIC supposedly began an investigation of these matters as early as last April (2019), but here's the funny thing: Not a single person from AFRINIC, or from any other part of what passes for "Internet governance" ever contacted me or asked a single question of me about any of this. I can only infer from this that nobody involved in this so-called investigation had any real or burning interest in gathering all of the relevant facts. In light of the facts that have now come out in the press, AFRINIC is still, allegedly, "investigating" and now, even nearly two months after the story broke in the press, AFRINIC has still not even reclaimed 100% of the valuable IPv4 space that was provably stolen from their own free pool. (Various online criminal enterprises are continuing to use that IPv4 space aqs we speak.) Worse yet, AFRINIC has done nothing whatsoever to address the problem of the large number of AFRINIC legacy /16 blocks that got stolen via some clever internal manipulation of AFRINIC's own WHOIS record. Those manipulations, and the benefits from them have flowed to various parties who are now all too well known, including one who previosuly made a brief guest apperance right here on this mailing list. In fact, that party has just recently found a brand new helpful and compliant small-time hosting provider in India to route for him the stolen 165.25.0.0/16 block, which is and has been "liberated" from its rightful owners, i.e. the City of Cape Town, South Africa. https://bgp.he.net/AS393960#_prefixes https://bgp.he.net/net/165.25.8.0/22#_whois Note that whereas AS393960 claims to be located in my own state of California, is is not incorporated here. It -is- incorporated in the state of Wyoming, but the owner and CEO, by his own admission, is actually located in Pune, India: https://in.linkedin.com/in/kushalraha (That small detail did not, of course, prevent ARIN, in its infinite wisdom, from giving the the proprietor of this place his own AS, two IPv4 /22 blocks and one IPv4 /24 block, all apparently on the basis of his tissue-thin Wyoming shell company. But I digress.) Anyway, I just wanted you all to be aware of all of these fun facts. Like I always say, just another day in paradise. Regards, rfg

4 5

RIP: Bill Manning
by Brett Watson 28 Jan '20

28 Jan '20

I was saddened to see this yesterday, that Bill Manning had passed. I was surprised this morning that it hadn’t hit NANOG yet but thought I’d post something because I have a ton of respect for Bill as I’m sure many here do. I met Bill as a very young, thought-I-knew-everything network engineer around ’92 when I was starting my internet life at a small ISP in Houston. Bill was visiting Stan Barber @ Sesquinet, which was my upstream provider at the time via T1, if I remember it all correctly. I was young, fresh out of college with a CS degree, and learning this “internet thing.” I met with Bill on campus at Rice University to discuss networking/routing, and Bill taught me CIDR, which I had no f-ing idea at that time what it was. Bill was always gracious and willing to share/teach. We always chatted and stayed in touch at NANOG and IETF conferences and through his relationship with Los Nettos over the years. Most notable, to me, was 2007 when my youngest daughter was diagnosed with cancer, and I believe Bill’s wife had (or previously battled) cancer as well. I hadn’t seen Bill for a few years, but he immediately reached out, shared his positive thoughts/prayers, and kept in touch during the battle we went through. Bill cared about people, and as noted below, he was smart as hell, and always had a crazy idea for how to solve a problem. Also as noted in Rod’s note below, Bill had a wealth of music knowledge and could always recommend something new and interesting to listen to. I’ll definitely miss Bill, and his passing makes me feel the years, and the mileage, but in a good way. -b >> This morning I talked to Julie Manning, Bill's wife. Bill died early >> Saturday morning, at home in Oregon. Most of you know Bill was >> waiting for a new heart. He would perhaps have gotten one next >> month. I guess the old one just wouldn't hold out long enough. >> >> I first met Bill in about 1995, when I returned to ISI after my first >> stint in Japan. He had taken a position in the Los Nettos project at >> ISI, a regional network project in the days when Internet service and >> operations work was still heavily shared between business and >> academia. Bill brought an operator's eye to the project, often seeing >> things differently from the researchers in the group. >> >> Bill kept the most erratic hours of any non-student I've ever met. He >> might be in the office at 2am or at 2pm, either was equally likely. >> I'd ask, "Bill, what time did you come in?" He'd reply, "10am." "I >> was here before that, and you were already here, it must have been >> earlier." "Greenwich Mean Time." >> >> And in one phase of life, "Bill, where do you live?" "Seat 4A." He >> would speculate about his average altitude and speed over the previous >> month. >> >> And, like any good geek, Bill had a spectacular collection of tie-dye >> t-shirts. He came by the look honestly: growing up in the Bay Area, >> he had actually snuck into Grateful Dead rehearsals held in a barn, >> and had traveled as a deadhead for a while. >> >> At ISI, we called Bill "the bad idea fairy". He always brought a >> slightly-off-kilter view of technical problems, which triggered >> endless discussions of fascinating, if usually implausible, >> alternatives. >> >> He had the most broad-ranging musical tastes of anyone I knew, and >> would eat almost anything (though, like me, he didn't drink alcohol). >> I was often envious of his eating and musical experiences. He >> certainly lived life to its fullest. >> >> On one occasion, I recall, we were eating lunch in a Thai restaurant >> for the first time. Bill called for the food "the way you'd make it >> in Thailand". The waiter went back into the kitchen and came out with >> a few raw Thai chiles. Bill ate one whole, without even breaking a >> sweat. The owner of the restaurant immediately came out to see who >> was eating them. Pam became a friend to our group. >> >> On other occasions, when the waiter asked for his order, Bill would >> point to another person at the table, and say, "I'll have what she's >> having." "Well, what is she having?" "I don't know, I haven't heard >> her say." Once in a while, he would point to someone else in the >> restaurant and say, "I'll have what they are having." It was funny >> and sometimes disconcerting, which was very Bill, and it was also his >> way of making sure he himself was eating (and thinking and doing) as >> broadly as possible, without getting stale. >> >> Bill worked in a bakery before joining Texas Instruments and >> accidentally falling into computer networking. (When we first met, he >> was commuting between Houston and L.A.; Julie and the kids were still >> in Houston.) I believe he attended a series of colleges but never >> finished his bachelor's degree. Just a few years ago, however, Jun >> Murai convinced him to get a Ph.D.; this took clearing administrative >> hoops to demonstrate that Bill's life experience matched that of a >> bachelor's degree, which it certainly did. I was honored to be on his >> Ph.D. committee. I literally created a "trouble ticket" accounting >> scheme to track change requests for his thesis. >> >> Bill was a valued member of the WIDE Project here in Japan. He worked >> with the DNS root operations group here, and participated in as many >> WIDE meetings as he could. He also came to Keio University's Shonan >> Fujisawa Campus when he was in Japan, and one of the best things about >> Bill was how seriously he took the students and their work, treating >> them like adult colleagues. >> >> Bill had friends on all seven continents, and for all I know on the >> International Space Station, as well. He was loved by us all. >> >> Julie does not plan to have a funeral immediately, so there is no need >> for flowers or the like. The family may do a memorial service in Utah >> in the spring. >> >> He was a unique and wonderful human being. And a good friend. >> Rest in peace, Bill. >> >> —Rod >

8 7

Major issues with Cloudflare DNS (specifically DNS-over-HTTPS)
by John Von Essen 28 Jan '20

28 Jan '20

Can someone from Cloudflare contact me off-list? I work for a major search engine (not Google) and starting yesterday, we are getting reports from around the world about a DNS issue. They are either not resolving our site, or they are getting incorrect resolution (i.e. the wrong IP). The issues appears to be centered around Firefox users who have DNS-over-HTTPS enabled, with Cloudflare as the provider. Thanks John

1 0

Call for Presentations: 33rd DNS-OARC Workshop, Paris, France, May 09 - 10th 2020
by Joe Abley 28 Jan '20

28 Jan '20

The 33rd DNS-OARC Workshop will take place at the Marriott Rive Gauche Hotel & Conference Center in Paris, France on May 9th and 10th 2020. It is co-located with and will take place right after the ICANN GDD (May 3rd to 6th), Registrations Operations Workshop (May 6th) and ICANN DNS Symposium (May 7th and 8th). The Workshop's Program Committee is requesting proposals for presentations. All DNS-related subjects are welcome. A time slot will also be available for lightning talks (5-10 minutes each) on day two of the workshop, for which submissions will be accepted just before the start of the workshop and until the start of the morning break on day two. Poster submissions are also welcome. There will be an OARC Business session during the workshop, which will be for OARC Members only. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. Workshop Milestones: 10 Jan 2020 - Submissions open via Indico 05 Mar 2020 - Deadline for submission (midnight CEST) 19 Mar 2020 - Initial Contribution list published 02 Apr 2020 - Full agenda published 02 May 2020 - Deadline for slideset submission 09 May 2020 - Workshop begins Details for presentation submission are published here: <https://indico.dns-oarc.net/event/34/call-for-abstracts/> The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> Joe Abley, for Dave Knight, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.)

1 0

DHCP Snooping Issue on Cisco N3K SW
by Md. abdullah Al naser 28 Jan '20

28 Jan '20

Hi everyone, I hope all you are fine. I'm very new to this mailing list and looking for a solution if anyone could help me. I am a network operation engineer and working for an ISP in Bangladesh. We are serving internet, data connectivity, IPTSP, IPTV and other services to corporate and retail clients. Retail clients are basically home users and small offices. To connect their CPE devices to our access network we are using DHCP. For example, we are using 192.168.0.1/24 IP in our BRAS interface and rest of all IPs are in DHCP pool to be allocated to the end users. By this time we had some bad experience with rouge DHCP server while clients connect the WAN link to the LAN port of CPE devices. To overcome that we recently deployed DHCP-snooping on our distribution switches which is in between the DHCP server and clients. But we are facing new problem after deploying that. Sometime our switch got stuck and clients don't get any IP via DHCP and all the allocations on valid DHCP server are stuck in "OFFERED" state. If we disable and then again enable the DHCP snooping feature in switch then problem is resolved for temporary. But few hours later the same problem happens repeatedly. For your information we are using Cisco Nexus 3000 switch and around 3k to 4k clients are there under that switch. We have a different location/POP where not more than 500 users are there and we don't have this kind of problem at all. So we assume that our Nexus 3000 switch is not performing well to handle DHCP snooping for large number of customers!!! For better understanding please check the network topology diagram (attached) SW Details: Hardware cisco Nexus3000 C3064PQ Chassis Software BIOS: version 3.8.0 NXOS: version 7.0(3)I4(3) NXOS image file is: bootflash:///nxos.7.0.3.I4.3.bin Just seeking expert opinion on above mention issue. Thanks & Regards, Naser

1 0

Wifi implementators
by Mehmet Akcin 27 Jan '20

27 Jan '20

Hi there I am looking for companies who can implement wifi to a 20,000 sq ft space in Virginia (near Virginia Beach area) and offer services that are turn key including upgrades/expansion/maintenance and such. Please contact me offlist if you can provide enterprise grade turn key wifi solutions Mehmet -- Mehmet +1-424-298-1903

2 1

Rogue objects in routing databases
by Florian Brandstetter 27 Jan '20

27 Jan '20

It appears that there is currently an influx of rogue route objects created within the NTTCOM and RaDB IRR databases, in connection to Quadranet (AS8100) and China Mobile International (CMI). Examples of affected networks are: 193.30.32.0/23 45.129.92.0/23 45.129.94.0/24 Networks, which have seemingly no affiliation with Quadranet, nor China Mobile International (CMI), which merely appears to be an upstream of Quadranet and hence creates the route objects in an automated manner. Another person has already reached out to Quadranet to find out the root cause of the creation of these objects. Their support gave an ETA of 24-72 hours. The route objects are all identical: route: 193.30.32.0/23 descr: CMI (Customer Route) origin: AS8100 mnt-by: MAINT-AS58453 changed: qas_support(a)cmi.chinamobile.com 20200117 source: RADB There appears to be a correlation with the affected networks, a fair share of them is part of AS-SBAG, which in turn is part of AS-VMHAUS, which in turn is part of AS- QUADRANET and could yield the importing of these prefixes. AS-VMHAUS appears to be a customer of Quadranet, listed within AS-QUADRANET-CUSTOMER-ASSET. These networks do however have no direct connection to Quadranet, and are not affiliated with Quadranet, nor are currently connected to Quadranet, which, entirely ignoring that the `origin` points to Quadranet, makes the route object illicit. Basically this has given AS8100, whether that be legitimately Quadranet, or somebody impersonating/spinning up a rogue AS8100, theoretical control over a massive amount of prefixes, as these can be advertised without restrictions and very likely reach a fairly high percentage of global visibility. -- Florian Brandstetter President & Founder SquareFlow Network LTD.

4 5

Comcast DNS Admin
by Childs, Aaron 26 Jan '20

26 Jan '20

Good Afternoon, If theres a Comcast DNS admin on this list, could you respond off list? Thanks, Aaron Sent from my Sprint Samsung Galaxy S10.

1 0

Data on latency and loss-rates during congestion DDoS attacks
by Amir Herzberg 26 Jan '20

26 Jan '20

Dear NANOG, One of my ongoing research works is about a transport protocol that ensures (critical) communication in spite of DDoS congestion attack (which cannot be circumvented), by (careful) use of Forward Error Correction. Yes, obviously, this has to be done and used carefully since the FEC clearly increases traffic rather than the typical congestion-control approach of reducing it, I'm well aware of it; but some applications are critical (and often low-bandwidth) so such tool is important. I am looking for data on loss rate and congestion of DDoS attacks to make sure we use right parameters. Any chance you have such data and can share? Many thanks! -- Amir Herzberg Comcast chair of security innovation, University of Connecticut Foundations of cybersecurity <https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Se…>, part I (see also part II and presentations): https://www.researchgate.net/publication/323243320_Introduction_to_Cyber-Se… <https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber…>

4 9