April 2022 - 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

SentryPeer: A distributed peer to peer list of bad IP addresses and phone numbers collected via a SIP Honeypot
by Gavin Henry 04 Jul '23

04 Jul '23

Hi all, I hope you don't mind the post, but thought this might be of use and in the spirit of release early, release often I've done an alpha release: https://github.com/SentryPeer/SentryPeer There's a presentation too if you'd like to watch/read where I hope to go with this: https://blog.tadsummit.com/2021/11/17/sentrypeer/ Working on the API and web UI next, then the p2p part of it. Feel free to submit any feature requests or have a play :-) Thanks for reading and any feedback is welcome! -- Kind Regards, Gavin Henry.

3 7

202203071610.AYC Re: Making Use of 240/4 NetBlock
by Abraham Y. Chen 16 Jan '23

16 Jan '23

Dear Colleagues: 0) I was made aware of a recent discussion on this Forum that cited our work on the 240/4 NetBlock, nicknamed EzIP (Phonetic for Easy IPv4). (Please see, at the end of this MSG, the URL to the discussion and the highlighted text where the citation was made.) 1) As the lead investigator of the EzIP Project, I would like to formally introduce our solution by bringing your attention to an overview whitepaper: https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf In a nutshell, EzIP proposes to disable the program codes in current routers that have been disabling the use of the 240/4 NetBlock. The cost of this software engineering should be minimal. The EzIP deployment architecture is the same as that of the existing CG-NAT (Carrier Grade Network Address Translation). Consequently, there is no need to modify any hardware equipment. There is an online setup description (Reference II), called RAN (Regional Area Network), that demonstrates the feasibility of this approach. 2) There are additional consequential benefits by deploying EzIP, such as those mentioned by our comment to Reference III in the above whitepaper. I look forward to addressing your thoughts. Regards, Abe (2022-03-07 17:14 EST) VP Engineering Avinta Communications, Inc. Milpitas, CA 95035 USA +1(408)942-1485 Skype: Abraham.Y.Chen eMail: AYChen(a)Avinta.com WebSite: www.Avinta.com *********************** https://mailman.nanog.org/pipermail/nanog/2021-November/216766.html Class D addresses? was: Redploying most of 127/8 as unicast public *Greg Skinner* gregskinner0 at icloud.com <mailto:nanog%40nanog.org?Subject=Re%3A%20Class%20D%20addresses%3F%20was%3A%20Redploying%20most%20of%20127/8%20as%20unicast%20public&In-Reply-To=%3CFEDBF677-BC75-47F3-A92D-2611F43283BA%40icloud.com%3E> /Mon Nov 29 18:47:14 UTC 2021/ * Previous message (by thread): Class D addresses? was: Redploying most of 127/8 as unicast public <https://mailman.nanog.org/pipermail/nanog/2021-November/216640.html> * Next message (by thread): Class E addresses? 240/4 history <https://mailman.nanog.org/pipermail/nanog/2021-November/216602.html> * *Messages sorted by:* [ date ] <https://mailman.nanog.org/pipermail/nanog/2021-November/date.html#216766> [ thread ] <https://mailman.nanog.org/pipermail/nanog/2021-November/thread.html#216766> [ subject ] <https://mailman.nanog.org/pipermail/nanog/2021-November/subject.html#216766> [ author ] <https://mailman.nanog.org/pipermail/nanog/2021-November/author.html#216766> ------------------------------------------------------------------------ >/On Nov 24, 2021, at 5:08 PM, William Herrin <bill at herrin.us <https://mailman.nanog.org/mailman/listinfo/nanog>> wrote: />//>/On Wed, Nov 24, 2021 at 4:36 PM David Conrad <drc at virtualized.org <https://mailman.nanog.org/mailman/listinfo/nanog>> wrote: />>>/I like research but what would the RIRs study? The percentage of the />>//>>/Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC />>/and they said similar things when 1.1.1.0/24 was stood up as an />>/experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular. />//>/Hi David, />//>/I don't recall there being any equipment or software compatibility />/concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. As />/I recall it, there were concerns with prior local use and potential />/trash traffic. It seemed likely those concerns could be addressed with />/experiments, and the experiments in fact addressed them. />//>/The prior local use worry reared its head again with 240/4 but given />/the prior experience with 1.0.0.0/8 I don't personally believe we need />/to re-run that experiment just because the numbers are part of a />/different block. />//>//>>/Seems to me that a number of folks on this list and during this />>/discussion would disagree with a blanket assertion that 240/4 />>/is “dysfunctional on the 2021 Internet” - some of them even />>/wrote a draft discussing the possibility. />//>/Line them up. Show of hands. Who really thinks that if we assign />/240.0.0.1 to a customer tomorrow without waiting for anyone to clean />/up their software and hardware, you won't get enough complaints about />/things not working that you have to take it back and assign a />/different address instead? />//>//>>/1. Move 240/4 from "reserved" to "unallocated unicast" />>//>>/OK, but this seems like a quibble. The status for 240/4 is “ />>/RESERVED: designated by the IETF for specific non-global-unicast />>/purposes as noted.” The “as noted” part is “Future Use”. />//>/It's not a quibble. Some vendors take the current status to mean />/"treat it like unicast until we're told otherwise." Others take the />/status to mean, "packets with these addresses are bogons without a />/defined routing behavior until we're told otherwise." The result is />/incompatible behavior between vendors. Changing that direction to />/"treat it like unicast" without ambiguity is not a quibble. />//>/Regards, />/Bill Herrin />//>/-- />/William Herrin />/bill at herrin.us <https://mailman.nanog.org/mailman/listinfo/nanog> />/https://bill.herrin.us/ / For what it’s worth, I’ve been tracking this issue on other netops mailing lists. There is a recent post on the LACNOG list from Leandro Bertholdo <https://mail.lacnic.net/pipermail/lacnog/2021-November/008895.html> referencing https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/ <https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/>, a draft proposing another way to make additional IPv4 address space available I haven’t had time to read the draft closely, but I noticed that it involves the use of 240/4. Subsequent googling about the draft turned up a presentation <https://www.avinta.com/phoenix-1/home/RegionalAreaNetworkArchitecture.pdf> describing how the techniques described could be deployed. I noticed that the presentation made reference to OpenWRT, so perhaps the authors are aware of the work that the authors of the IPv4 Unicast Extensions Project have done in that area. The adaptive-ipv4 draft will expire sometime next month, so anyone interested in seeing it move forward should contact the authors. —gregbo ******************* -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

70 306

Getting Fiber to My Town by Jared Mauch
by Jared Brown 11 Aug '22

11 Aug '22

I believe this belongs here: Getting Fiber to My Town by Jared Mauch https://www.youtube.com/watch?v=ASXJgvy3mEg (YouTube video of NLnog presentation) https://nlnog.net/static/live/nlnog_live_sep_2020_jared.pdf (slides for presentation) https://news.ycombinator.com/item?id=24424910#24430901 (discussion on Hacker News with Jared participating) https://washftth.com/ (project homepage) I find this an interesting description of how to apply skills that we normally only use at work to solve connectivity issues at home. Quite timely too, as home connectivity is needed more than ever. Highlights: - location: just outside of Ann Arbor - no fixed broadband since 2002 -> build own network - pre-wire neighbors with fiber drops and feed them off WISP first - lots of work to sign up customers, having to resort to snailmail to reach all - 70% of homes passed signed up - Have ASN, get IPv6 and IPv4 allocation, multihome and connect to local IXP - purchase equipment: fusion splicer, OTDR, materials, directional drill(!) - hire contractors, deal with all manner of problems, theft, stop work orders, unbudgeted costs, unmarked/badly marked utilities, hitting (own) utilities - build own fiber blower(!) for blowing in fiber in ducts - splice, OTDR, resplice, schedule installs ... which don't always go to plan - Upstream very helpful, offered a Cisco 6500 as CPE, however respectfuly declined and went with Arista - Link up! Network is now live with 17 subscribers hooked up. More waiting to be connected - Mixed Active Ethernet and GPON - latency drops from 30 ms to 8 ms, bandwidth from 20-30M to 730M, total commit 1.5G on 10G port, plans from 50M to 500M - SPAM! IPv4 brokers and the usual unsolicited contacts from bottom of the baller IP transit providers - Costs: $126k in 2020, $95k contractors, $32k materials and equipment. Total outlay ~$150k + years of sweat equity. Important to spread out costs over longer period of time to be able to afford. Offset costs by using pre-pay model (Can pay $5,000 up-front and receive $50 credit for 100 months) All in all it was an excellent presentation. I only wish Jared had spent some more time on how he had to become a telco and how this got him better access to the public right of way. Of course, some more details on his directional boring and some nice video of him running the drill would have been a cherry on top :) I'd like to congratulate Jared on lighting up his network and wish him success in running it. I did a similar build almost twenty years ago and regret I didn't have the forethought to document the effort better then. Not that there was a YouTube to put it all on then :) You can find the other presentations from NLnog live September 2020 at https://www.youtube.com/channel/UCVz78FbsOJ6v6xb6S2GpvWQ Jared, not the Mauch one

10 13

Any sign of supply chain returning to normal?
by Drew Weaver 20 May '22

20 May '22

I'm not sure if this is the right place for this discussion but I can't think of anywhere better to ask. Has anyone seen any progress whatsoever on supply chain issues with networking hardware? I've noticed that primary market lead times have been increasing and at the same time secondary market pricing has also been going higher at the same time, still. What have you seen?

22 29

Ready to compromise? was RE: V6 still not supported
by Pascal Thubert (pthubert) 05 May '22

05 May '22

Dear all Following advice from thus list, I updated the YADA I-Draft (latest is https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html, more to come soon if feedback is heard) and proposed it to the v6ops WG at the IETF. For memory, the main goal here is to find a compromise as opposed to yet another transition solution, though it can be used as a side effect to move along the ladder. The compromise does not change IPv4 or IPv6, tries not to take side for one or the other, and add features to both sides which, if implemented, reduce the chasm that leads to dual stack and CG-NATs. There's value for the movers, lots more public address space for the IPv4-only stack/networks and free prefixes per node and new deployment opportunities for the IPv6-only ones. One major update from the original text accounts for Dave's comment in this list on BCP 38 enforcement, I believe it's solved now. I also added format layouts to Abe Chen's question, and text on the naïve version vs. all the elasticity that exists there and in IP in general to allow real world deployments. Comments welcome, here and/or at v6ops for those who participate there. Many thanks in advance; Pascal

2 4

Could people with experience with ARIN's IRR API contact me off-list?
by Dan Mahoney (Gushi) 02 May '22

02 May '22

All, Dayjob uses RADB mainly but would like for authority purposes to put some things in ARIN. I've had an ARIN help desk ticket in for a couple days, and would like to move to letting our IPAM files be the source of truth and push everything in via the API, but I'm finding a few things about the API just obtuse. I could post that laundry list here, but I'd prefer to get confirmations from people who've written tools against it what tools you found useful, and if the broken things I'm seeing are actually as broken as I think they are. ARIN people who implemented this, I'd love to hear from you as well. Best, -Dan --

3 2

Disney+ Issues
by Norman Jester 02 May '22

02 May '22

Anyone from Disney+ here? If you can reply off-list I'd appreciate it. I have emailed every place I can think of to solve a geoip problem affecting hundreds of customers, no reply in weeks. Would appreciate some help thanks in advance. -- Norman JellyDigital

12 14

how networking happens in Hawaii
by scott 01 May '22

01 May '22

I thought I'd put a smile on your faces for Friday. This is how networking happens in Hawaii... https://www.civilbeat.org/2022/04/thousands-of-hawaiians-could-lose-phone-a… ---------------------------------------------------------------------- "State regulators have opened an emergency investigation of Sandwich Isles Communications..." "The investigation comes as Sandwich Isles is apparently blocking access to its telecom infrastructure to another provider, Hawaiian Telcom, alleging trespass, filing police reports and putting customer phone and internet service at risk." "Sandwich Isles Communications is an Oahu-based telephone company founded in 1995 with a mission to provide communication services to Native Hawaiians living on homesteads" "In 2015, founder Albert Hee was convicted of criminal tax fraud...Hee was sentenced in 2016 to 46 months in prison." "With federal backing, the company built the Paniolo Network, a web of undersea and terrestrial fiber optic cables." "...a bankruptcy trustee ordered the sale of the Paniolo Network to Hawaiian Telcom." "Hawaiian Telcom says Sandwich Isles has removed, destroyed or tampered with Hawaiian Telcom locks on perimeter fences surrounding buildings purchased by Hawaiian Telcom. And that Sandwich Isles has installed its own locks and devices on buildings and premises owned by Hawaiian Telcom, as well as welding shut access gates. The company also says Sandwich Isles has made multiple false police reports alleging Hawaiian Telcom is trespassing on its property." "Al Hee was requesting that Hawaiian Telcom’s lock on its Paniolo Building at Laiopua on the Big Island be replaced. Otherwise, Hee said he would call the police." "In a Sept. 11 letter to customers, Sandwich Isles blamed the situation on Hawaiian Telcom." ---------------------------------------------------------------------- When your brother is very connected politically I guess one feels invincible... "...welding shut access gates..." hahaha! Insanity! There're other 'outages' that didn't make the article. Repeated fiber damaged off shore, etc. scott

6 8