November 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

Providing geofeed info to Google
by Hugo Slabbert 18 Sep '23

18 Sep '23

Google folks: I see historical reference to needing to use the Google Peering Portal ( http://peering.google.com) if you need to provide Google with geofeed info for GeoIP info on network blocks, ref https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html. Is that still the case? Are there any avenues to provide Google with geofeed info if you're *not* currently peering with 15169? Or to get access to just the geofeed update portion of the Peering Portal? -- Hugo Slabbert

6 8

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

afrinic rpki issue
by Randy Bush 14 Jun '23

14 Jun '23

From: PacketVis <notifications(a)packetvis.com> Date: Sun, 20 Nov 2022 04:30:44 +0000 Possible TA malfunction or incomplete VRP file: 73.95% of the ROAs disappeared from afrinic See more details about the event: https://packetvis.com/#/bgp/event/905ec8b7d37e89a2d7b547bca99fd57e-372b0bf3…

5 9

Re: Upstream bandwidth usage
by Mel Beckman 27 Feb '23

27 Feb '23

Adam, Your point on asymmetrical technologies is excellent. But you may not be aware that residential optical fiber is also asymmetrical. For example, GPON, the latest ITU specified PON standard, and the most widely deployed, calls for a 2.4 Gbps downstream and a 1.25 Gbps upstream optical line rate. -mel > On Jun 9, 2022, at 3:08 PM, Adam Thompson <athompson(a)merlin.mb.ca> wrote: > However, if you're talking about fiber service, it's pretty much pure marketing-dept-driven BS, combined with some vague justification of not letting TOR nodes or copyright-ignoring seeders/Warez-providers/etc. overwhelm the network in unexpected ways.

18 25

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

Experiences with commercial NOS vendors in white box space
by Graham Johnston 07 Dec '22

07 Dec '22

Good day. I'm curious to hear from those with direct, hopefully in-production, experience in using a commercial network operating system vendor along with white box switches. I'm specifically looking for operators in the service provider space, rather than data center or enterprise. I'm largely focused on Jericho2/Qumran2 based devices, with what would likely be modest feature requirements. We currently use MPLS with RSVP to build automatic paths, but don't do anything specific for traffic engineering. Segment routing isn't a requirement for today. Currently use more traditional forms of MPLS services for customer L2 and L3 VPNs, but are investigating a transition to EVPN. Automation is very much important to us, as are routing security features. Based on research, and use of vertically integrated Jericho-based switches, we aren't concerned about QoS as our needs aren't super complex. I guess I'm largely saying that we don't expect the ASIC to be the weak point in our use case, but rather the NOS or the nature of support from the vendor. I'm aware of IPInfusion and their OcNOS product, but the CLI and config syntax feels dated. I feel like I've been ruined by Cisco RPL, Juniper policy-statements, and Arista RCF and expect I would find wanting more than what route-map syntax has to offer. Can I accomplish the same complex routing policies via route-maps that I can with more modern solutions, and I'm just assuming it's limiting? Is it fair to say that even if I can achieve the same functionality, that route-maps are the poorer choice when it comes to the human interaction aspect? I know of Arrcus, but don't know much more than I can see on their website. Edge-core has an interesting reference in its Open Networking Solution Guide on their website in which they position Arrcus for core applications and IPInfusion for access and aggregation. All of which could be meaningless based on the varied definitions and expectations of what a core network is and does. Is it feature rich or just a set of fast LSR P-routers? The Edge-Cor guide also identifies Exaware and Capgemini, both of whom I know little about. Are there viable SP focused NOS vendors that I haven't touched on? Thanks in advance for any reply, be it on-list or off-list. Regards, Graham

3 2

the ipv4 vs ipv6 growth debate
by Dave Taht 06 Dec '22

06 Dec '22

I use a web plugin tool called ipvfoo to track my actual ipv4 vis ipv6 usage. I wish it worked over time. With very few exceptions I am still regularly calling ipv4 addresses in most webpages. Has anyone done a more organized study of say, the top 1 million, and how many still require at least some ipv4 to exist, and those trends over time? -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656… Dave Täht CEO, TekLibre, LLC

5 8

ipv4/25s and above
by Dave Taht 05 Dec '22

05 Dec '22

I am kind of curious as to the distribution of connections to smaller companies and other entities that need more than one ipv4 address, but don't run BGP. So, for as an ISP or infrastructure provider, what is the typical percentage nowadays of /32s /31s /30s... /25s of stuff that gets run "elsewhere"? Is there any correlation between the number of IPs a customer gets and the amount of bandwidth they buy? Obviously "retail", home use is /32s and there's an increasing amount of CGNAT, but I can't help but imagine there are thousands of folk running /27s and /29s for every /24 or /22 out there. I've been paying 15/month for a /29 for forever, but barely use it. -- This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656… Dave Täht CEO, TekLibre, LLC

26 91