September 2019 - Test - lists.nanog.org

Issue with Geolocation in Virginia US
by Raja Sekhar Gullapalli 04 Jan '24

04 Jan '24

Team, We are having issues in our Virginia US office & it shows geolocation in all browsers as Canada instead of US region when we access news.google.com in our PC. Our public ip is 129.46.232.65. This issue is being observed for more than 2 month. Can you help to whom we can contact to resolve the issue. Regards, Raja

8 13

FW: softlayer.com
by Travis Garrison 23 Sep '23

23 Sep '23

Traceroute from here if it helps Tracing route to 138-43-128-1.reserved.highland.net [138.43.128.1] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms [REDACTED] 2 <1 ms <1 ms <1 ms [REDACTED] 3 1 ms 1 ms <1 ms [REDACTED] 4 1 ms <1 ms <1 ms [REDACTED] 5 6 ms 6 ms 6 ms v313.core1.mci3.he.net [216.218.213.141] 6 16 ms 16 ms 16 ms 100ge10-2.core1.dal1.he.net [184.105.81.206] 7 26 ms 26 ms 26 ms xo-as15-as2828.10gigabitethernet6-7.core1.dal1.he.net [184.105.255.78] 8 40 ms 39 ms 40 ms 207.88.14.198.ptr.us.xo.net [207.88.14.198] 9 40 ms 39 ms 40 ms 207.88.12.178.ptr.us.xo.net [207.88.12.178] 10 39 ms 39 ms 39 ms 216.156.16.239.ptr.us.xo.net [216.156.16.239] 11 48 ms 48 ms 48 ms ip65-46-198-198.z198-46-65.customer.algx.net [65.46.198.198] 12 41 ms 41 ms 41 ms occm-6.dhcp.grp1-rng1.tncsvl.blomand.net.57.131.192.in-addr.arpa [192.131.57.6] 13 * * * Request timed out. Thanks Travis From: NANOG <nanog-bounces(a)nanog.org<mailto:nanog-bounces@nanog.org>> On Behalf Of Siyuan Miao Sent: Friday, March 22, 2019 9:22 AM To: Nikolas Geyer <nik(a)neko.id.au<mailto:nik@neko.id.au>> Cc: nanog(a)nanog.org<mailto:nanog@nanog.org> Subject: Re: softlayer.com Perhaps it won't work because their customer support will ask you for bi-directional traceroute and refused to forward to backbone team. Then they'll say it's not their fault and you can see the packet is dropped outside our network. Here's a sample traceroute from SoftLayer Washington, San Jose and Seattle in case someone needs it: aveline@iad02-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 17:20:42 2019 HOST: iad02-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 1.4 1.5 0.8 3.7 1.0 2.|-- ae13.dar02.wdc01.networklayer.com<http://ae13.dar02.wdc01.networklayer.com> 0.0% 10 0.5 3.3 0.4 28.6 8.8 3.|-- ae9.bbr01.eq01.wdc02.networklayer.com<http://ae9.bbr01.eq01.wdc02.networklayer.com> 0.0% 10 0.8 0.8 0.7 1.0 0.0 4.|-- eqix-dc5.intellifiber.com<http://eqix-dc5.intellifiber.com> 0.0% 10 0.8 1.2 0.8 2.2 0.3 5.|-- ae13-0.cr02.asbn01-va.us.windstream.net<http://ae13-0.cr02.asbn01-va.us.windstream.net> 0.0% 10 0.9 0.9 0.9 1.0 0.0 6.|-- ae11-0.cr01.atln02-ga.us.windstream.net<http://ae11-0.cr01.atln02-ga.us.windstream.net> 0.0% 10 15.6 16.1 15.6 17.4 0.5 7.|-- ae0-0.pe06.atln02-ga.us.windstream.net<http://ae0-0.pe06.atln02-ga.us.windstream.net> 0.0% 10 17.4 16.1 15.9 17.4 0.3 8.|-- h43.88.198.64.static.ip.windstream.net<http://h43.88.198.64.static.ip.windstream.net> 0.0% 10 24.7 24.8 24.6 24.9 0.0 9.|-- east.tndodge-21.static.tncsvl.blomand.net<http://east.tndodge-21.static.tncsvl.blomand.net> 0.0% 10 22.6 22.8 22.5 23.8 0.0 10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 aveline@sjc03-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 16:21:04 2019 HOST: sjc03-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 2.4 2.0 0.3 14.3 4.3 2.|-- ae0.dar02.sjc01.networklayer.com<http://ae0.dar02.sjc01.networklayer.com> 0.0% 10 1.0 0.5 0.3 1.3 0.0 3.|-- ae9.bbr01.eq01.sjc02.networklayer.com<http://ae9.bbr01.eq01.sjc02.networklayer.com> 0.0% 10 0.8 0.8 0.7 0.9 0.0 4.|-- eqix-sv1.windstream.com<http://eqix-sv1.windstream.com> 0.0% 10 0.9 0.9 0.8 1.1 0.0 5.|-- ae6-0.cr02.lsaj01-ca.us.windstream.net<http://ae6-0.cr02.lsaj01-ca.us.windstream.net> 0.0% 10 11.6 11.5 11.5 11.6 0.0 6.|-- ae-11-0.cr01.dlls01-tx.us.windstream.net<http://ae-11-0.cr01.dlls01-tx.us.windstream.net> 0.0% 10 42.6 42.7 42.5 43.4 0.0 7.|-- ae7-0.cr02.atln02-ga.us.windstream.net<http://ae7-0.cr02.atln02-ga.us.windstream.net> 0.0% 10 64.0 65.6 63.9 74.2 3.4 8.|-- ae1-0.pe06.atln02-ga.us.windstream.net<http://ae1-0.pe06.atln02-ga.us.windstream.net> 0.0% 10 62.3 62.7 62.2 66.9 1.5 9.|-- h43.88.198.64.static.ip.windstream.net<http://h43.88.198.64.static.ip.windstream.net> 0.0% 10 71.9 72.0 71.9 72.2 0.0 10.|-- east.tndodge-21.static.tncsvl.blomand.net<http://east.tndodge-21.static.tncsvl.blomand.net> 0.0% 10 69.9 68.8 68.6 69.9 0.3 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 aveline@sea04-sl01:~$ mtr 138.43.128.1 --report-wide Start: Fri Mar 22 08:19:09 2019 HOST: sea04-sl01 Loss% Snt Last Avg Best Wrst StDev 1.|-- [REDACTED] 0.0% 10 0.7 1.2 0.7 1.8 0.0 2.|-- ae12.dar02.sr01.sea01.networklayer.com<http://ae12.dar02.sr01.sea01.networklayer.com> 0.0% 10 0.6 0.7 0.5 1.3 0.0 3.|-- ae9.bbr01.wb01.sea02.networklayer.com<http://ae9.bbr01.wb01.sea02.networklayer.com> 0.0% 10 1.2 1.0 0.7 1.5 0.0 4.|-- six.seattle-wa.us.windstream.net<http://six.seattle-wa.us.windstream.net> 0.0% 10 1.5 1.0 0.7 1.7 0.0 5.|-- ae12-0.cr01.chcg01-il.us.windstream.net<http://ae12-0.cr01.chcg01-il.us.windstream.net> 0.0% 10 41.1 41.2 41.0 41.6 0.0 6.|-- ae17-0.cr02.chcg01-il.us.windstream.net<http://ae17-0.cr02.chcg01-il.us.windstream.net> 0.0% 10 41.1 41.4 41.1 42.0 0.0 7.|-- ae10-0.cr01.atln02-ga.us.windstream.net<http://ae10-0.cr01.atln02-ga.us.windstream.net> 0.0% 10 63.8 64.4 63.5 71.1 2.3 8.|-- ae0-0.pe06.atln02-ga.us.windstream.net<http://ae0-0.pe06.atln02-ga.us.windstream.net> 0.0% 10 63.7 63.7 63.5 64.0 0.0 9.|-- h43.88.198.64.static.ip.windstream.net<http://h43.88.198.64.static.ip.windstream.net> 0.0% 10 71.6 71.8 71.5 72.8 0.0 10.|-- east.tndodge-21.static.tncsvl.blomand.net<http://east.tndodge-21.static.tncsvl.blomand.net> 0.0% 10 71.8 70.8 70.2 71.8 0.3 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 Regards, Siyuan Miao On Fri, Mar 22, 2019 at 10:10 PM Nikolas Geyer <nik(a)neko.id.au<mailto:nik@neko.id.au>> wrote: This is the best approach. Have run into this problem a few times and had zero success getting the filters removed without having SL customers log tickets with support. Verbiage needs to be “this prefix is blocked, please escalate to your backbone team”. Sent from my iPhone On Mar 22, 2019, at 9:56 AM, Forrest Christian (List Account) <lists(a)packetflux.com<mailto:lists@packetflux.com>> wrote: Another idea... Have you tried reaching out to some of the blocked sites? They likely have better contact information than is available publicly, especially a larger one like indeed. On Thu, Mar 21, 2019, 3:41 PM John Alcock <john(a)alcock.org<mailto:john@alcock.org>> wrote: Still looking for anyone from softlayer.com<http://softlayer.com> It has been a challenge. Anything hosted by softlayer.com<http://softlayer.com> is being blocked. Here is a small list so far windowbook.tpondemand.com<http://windowbook.tpondemand.com> ahainstructornetwork.americanheart.org<http://ahainstructornetwork.americanheart.org> clover.com<http://clover.com> Cebroker.com<http://Cebroker.com> Softlayer.com<http://Softlayer.com> indeed.com<http://indeed.com> & Enforce Staffing It is growing every day. John On Wed, Mar 20, 2019 at 12:35 PM John Alcock <john(a)alcock.org<mailto:john@alcock.org>> wrote: Afternoon, Thought I would start a new thread. After researching, traceroutes, etc, I think I found my problem. 9 out of the 10 sites that subscribers on my new block is being hosted by softlayer. Anyone on the list have contacts with softlayer. Right now I have an email to abuse. The support line will not help me out. John

3 2

Cogent sales reps who actually respond
by noc＠as37662.com noc＠as37662.com 17 Jun '20

17 Jun '20

Hi fellow network operators, Do any orgs here have experience with a good Cogent rep? The rep we got via Cogent's website is unresponsive to even basic questions. It feels like we are dealing with a bot and copy-pasted replies. Thanks Ruldu

66 146

DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users
by Jeroen Massar 12 Mar '20

12 Mar '20

Hi Folks, While in the US soon all Firefox users will *NOT* use your DNS Recursives configured using DHCP anymore (NXDOMAIN use-application-dns.net to avoid that[1]). Next to that, it seems some of the root operators are now creating instances in the same networks that offer these kind of services for globally figuring out what queries are being made. For those that thus either opt-out or otherwise want to use their own system resolvers, I suggest that all that run DNS Recursive setups enable "QNAME minimization" as defined in (experimental) RFC7816 [2] For pdns "qname-minimization=yes" [6] For unbound "qname-minimisation: yes" [5] For BIND "qname-minimization" option [3] and [4] Of course, do also provider your users with the option of using DoT or even DoH on your recursors... Noting that DoH operators are supposed to enable RFC7816 also [7], guess they do not want others to see all the details they get... Some more details in DNS Privacy Wiki [8]... Discuss! :) Greets, Jeroen [1] https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-… [2] https://tools.ietf.org/html/rfc7816 [3] https://www.isc.org/blogs/qname-minimization-and-privacy/ [4] https://gitlab.isc.org/isc-projects/bind9/issues/16 [5] https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf [6] https://github.com/PowerDNS/pdns/issues/2311 [7] https://wiki.mozilla.org/Security/DOH-resolver-policy [8] https://dnsprivacy.org/wiki/

11 13

Time and Timing Servers
by Mike Hammett 16 Feb '20

16 Feb '20

There were a lot of NTP threads several weeks ago, but I didn't get an answer to my question amongst all of the other chatter. I'm looking for a device that can receive GPS inside a building without the assistance of an external antenna (Frontier says they no longer allow external antenna), will provide traditional NTP services, and will provide a timing signal that my Metaswitch can work with. I know that MicroSemi via Symmetricom makes these kinds of devices, but I'm hoping to look at multiple manufacturers and compare. Thanks. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP

13 21

Spectrum technical contact
by Josh Luthman 23 Jan '20

23 Jan '20

We have had a DOS attack for over 12 hours. I simply want them to null route or black hole an address. The traffic is filling one of our circus with them. The farthest I got was them telling me they can't do route changes because we're not public safety. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373

9 19

Internap (AS 12178) Contact
by Alex Lembesis 13 Dec '19

13 Dec '19

Wondering if anyone knows of a contact @ Internap that can reach out to me off-list. We're only receiving a default route from them now, when we should be receiving the full table. Any help is much appreciated. Thanks! This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you.

2 3

MX10003 rack size
by Sander Steffann 24 Oct '19

24 Oct '19

Hi, Has anyone ever managed to fit a Juniper MX10003 in a 90cm deep rack? Without applying power tools to either the rack or the router ;) Cheers, Sander

4 4

BGP Enabled transit in Chicago (River North) and equipment recommendation
by ADNS NetBSD List Subscriber 17 Oct '19

17 Oct '19

I have a need for a BGP enabled connection in the River North section of Chicago. We have a small number of IP blocks that we want to use. Currently, we have some equipment at 350 E. Cermak (Steadfast Networks) and are looking at downsizing and bringing stuff in-house. Our bandwidth requirements are miniscule (10MB/Sec is fine). I know RCN offers business cable-modem service but probably not BGP. Also, we’d like to ditch our 3640 router in favor of a smaller “desktop” size router, but none of them seem to do BGP (not surprising). Any recommendations on hardware would be welcome as well

8 10

Cogent & FDCServers: Knowingly aiding and abetting fraud and theft?
by Vivek Nigam 12 Oct '19

12 Oct '19

Hi Ronald, APNIC has contacted the custodians of 139.44.0.0/16 and 168.198.0.0/16 and brought this matter to their attention. Regards, Vivek Member Services Manager, APNIC From: Ronald F. Guilmette <rfg(a)tristatelogic.com> Date: Fri, Sep 6, 2019 at 6:30 PM Subject: Cogent & FDCServers: Knowingly aiding and abetting fraud and theft? To: <nanog(a)nanog.org> Few of you here probably know about this, but nearly a week ago now an article appeared in South Africa's largest and most popular online tech publication, MyBroadband.co.za. It detailed many, but certainly not all of the results of my multi-month investigation of a massive and ongoing fraud involving the theft of large numbers of large (generally /16 or larger) abandoned legacy blocks, taken from the AFRINIC region and beyond: https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-add… For various editorial reasons, the article that was published actually downplayed the magnitude of the of the thefts quite dramatically. The totality of the IPv4 space that has been stolen or squatted, primarily but not exclusively, from South African companies and South African national goverment agencies and departments is actually at least 5x bigger than what was reported in the MyBroadband.co.za article. The overwhelming majority of this stolen and squatted IPv4 space has been helpfully routed by Cogent (AS174), to their customer, FDCServers of Chicago, and then on to the prefered destinations of a certain Mr. Elad Cohen of Israel, and his company Netstyle Atarim, Ltd. (I have saved traceroutes up the wazoo that prove the involvement of FDCServers, in particular, in all of this.) Mr. Cohen has been exceptionally prolific in his IPv4 theft and squatting activities, basically grabbing everything that wasn't nailed down, both within the AFRINIC region and also within the APNIC region. In order to try to legitimize all of these thefts and squats, Mr. Cohen created quite a sizable number of fradulent route: objects within the Merit/RADB data base which, as most here should already know, has essentially zero authentication of any kind before it allows J. Random Luser to add pretty much any any route: object he wants to the RADB. Here's a full listing of all of Mr. Cohen's RADB route: objects as they existed as recently as August 17th: https://pastebin.com/raw/ZNgNuvtt And here is the short summary version showing just all of the prefixes/CIDRs that Mr. Cohen was effectively claiming rights and/or title to as of that same date: https://pastebin.com/raw/4LTaCg5R Plese do note the numerous blocks of size /16 or greater. The bottom line is that this one tiny little Israeli company was effectively claiming rights to a total of no fewer than 1,015,808 IPv4 addresses as of August 17th, 2019. (Not too shabby for one lone guy who teaches programming classes as a side job!) Vitrually all of the space is "legacy" IPv4 space, and generally consists of blocks having sizes of /16 or larger. Some of Mr. Cohen claims in his RADB entries are as humorous as they are pathetically fradulent. For example, Mr. Cohen has effectively claimed rights to 139.44.0.0/16 which unambiguously belongs to the Port Authority of the City of Melbourne, Australia. But hell! That's merely city property! Mr. Cohen's limitless appetite for other people's IPv4 space is more vividly on display in his claims to ownerhip over the 168.198.0.0/16 block, which actually belongs to the Department of Finance of the Australian national government. And I haven't even mentioned yet another of Mr. Cohen volumous IPv4 acqusitions, the 165.25.0.0/16 block, which he did not see fit to create an RADB entry for, but which he's been squatting on for for quite some time now, quite clearly with the aid and assistance of both Cogent and FDCServers. That one belongs to th City of Cape Town, South Africa. That city's engineers have been struggling to regain control of their block back from Cogent, from FDCServers, and from Mr. Cohen for some time now. I know because I've personally spoken to them about it. Cogent, in its infinite wisdom, is continuing to fight the city for control over property that clearly and righfully belongs to the City of Cape Town, even as we speak: https://drive.google.com/file/d/1ytRj1CtuVhDa0eGu4BT-oEz593y5EwJa/view When asked for LOAs attesting to his legitimate authority to route at least a few of these blocks, Mr. Cohen has produced blatantly forged documents, many of which appeared in the MyBroadband.co.za story. And when I say "blatant" that's a gross understatement. Any half-way decent forger would consider these documents an embarrasment. The documents all bear identical signatures, and identical and vaguely official looking stamps, and purport to actually be sales reciepts attesting to the alleged purchases, by Mr. Cohen's offshore Seychelles Islands shell company, Afri Holdings, Ltd., of various /16 blocks from a mysterious company called Afrivestment, Ltd., which may actually exist in some faraway galaxy, or in Mr. Cohen's active imagination, but which both Google and OpenCorporates.com seem to agree exists exactly noplace on this planet. Here are the manufactured LOAs supplied by Mr. Cohen: https://drive.google.com/file/d/1hVjmR6u0ANltuXtZ-Kng8io-EGFyevTR/view https://drive.google.com/file/d/1x_44_H5hkcFLhEwpkwfFoR5PJUyXHzxJ/view https://drive.google.com/file/d/1yQyqn4q_f3bt-wDVoN1FzbXf1k58DXtK/view Recently, Cohen started to move some, but not all, of his stolen and squatted IPv4 blocks off of Cogent/FDCServers and onto a friendly little bullet-proof hosting company in the Netherlands named IP Volume, Inc. (AS202425) and/or to its several sister networks, e.g. AS204655 - Novogara Ltd., all of which, coincidently, just happen to be owned by the exact same pair of Dutch gentlemen who previously owned the notorious Ecatel, follwed by the notorious Quasi Networks. (IP Volume, Inc. appears to have intherited all or nearly all of its legitimately assigned IP space from its predecessor entities, Ecatel and Quasi Networks.) Despite these relocations, many of Mr. Cohen's stolen and squatted blocks are still helpfully being routed to Mr. Cohen's preferred desitnations by his good friends at Cogent and FDCServers, even as we speak. The current set of such routes that Cogent is maintaining, at the moment, apparently on behalf of their customer, Mr. Cohen, consists of the prefixes listed here: https://pastebin.com/raw/EA3xJVLF When I noticed two days ago that all of these routes were still up I was deeply confused. Did both Cogent and FDCServrs not get the memo?? Do they not know yet that Cohen is stealing stuff, left, right, and sideways? Did nobody even tell them about the MyBroadband.co.za article which was published this past Sunday? I decided that it was incumbant upon me to find out. Thus, more that 48 hours ago now I sent the following polite but firm inquiry to Cogent, and a separate nearly identical one directly to the CEO of FDCServers, Mr. Petr Kral (petr(at)fdcservers.net) https://pastebin.com/raw/ztipqE96 A full forty eight hours later, I have received no reply whatsoever from either Cogent or FDCServers, not even a "Go pound sand" type of response. More importantly, most of the stolen IPv4 space that I called out, very specifically, to both Cogent and FDCservers two+ days ago now is still being routed by Cogent/FDCservers to their fun-loving and, I'm sure, promptly paying customer, Mr. Cohen. If neither Cogent nor FDCServers still do not know now that Mr. Cohen is a crook, and that he has glommed onto quite a lot of stolen and squatted IPv4 space... which they have been helpfully routing for him, no doubt in exchange for some handsome payments... then I am foreced to say that it appears to be a reasonable conclusion that it must be because neither Cogent nor FDCServers really wants to know what sort of a character Cohen is, or what he has been up to, specifically with their ongoing and material assistance. But you all be the judges. What does it look like to you? Regards, rfg

7 11