April 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

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

[FYI] Call for Presentations European Peering Forum 14 (EPF14) // NANOG
by Arnold Nipper 10 Jul '19

10 Jul '19

Dear Community This is the Call for Presentations European Peering Forum 14 (EPF14) AMS-IX, DE-CIX, LINX and Netnod are happy to host the 14th European Peering Forum (EPF) in Tallinn, Estonia from the 16th - 18th September 2019. The event will welcome up to 300 peering managers and coordinators from networks connected to the host Internet exchanges. Besides an interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and lightning talks related to peering and technical topics of interconnection. Your presentation should address * Interconnection Automation * Regional Peering * Interconnection / Peering Internet Governance and Regulatory Topics * Economic and Product Trends * Peering / Interconnection strategies * Interesting findings about Peering / Interconnection * 400GE and beyond Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee <epf-pc(a)peering-forum.eu>. Please include: * Author's name and e-mail address * Presentation title * Abstract * Slides (if available) * Time requested (max. 30 minutes incl. Q&A) Deadlines ========= Presentation Abstract Deadline 15/07/2019 12:00 UTC Final Selection of Speakers 26/07/2019 Presentation Slides Submission Deadline 02/09/2019 12:00 UTC More information about the event and other activities around EPF14 may be found at * https://peering-forum.eu/ * https://www.facebook.com/groups/1486607564933665/ Best regards Arnold -- Arnold Nipper email: arnold(a)nipper.de mobile: +49 172 2650958

1 1

Cellular backup connections
by Dovid Bender 24 Jun '19

24 Jun '19

Hi All, I finally got around to setting up a cellular backup device in our new POP. I am currently testing with T-Mobile where the cell signal strength is at 80%. The connection is 4G. When SSH'ing in remotely the connection seems rather slow. Ping times seem to be all over the place (for instance now I am seeing: rtt min/avg/max/mdev = 174.142/336.792/555.574/99.599 ms) . Is that just cellular or is that more related to the provider and the location where I am? I could in theory test with VZ and ATT as well. With Verizon they charge $500.00 just to get a public IP and I want to avoid that if possible. Thanks and sorry in advance if this is off topic.

15 19

Re: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?
by Montgomery, Douglas (Fed) 16 May '19

16 May '19

Our effort to get our new monitor transitioned to a public facing system ran into a wall for ~35 days. Unfortunately during that time, the visa of a visiting researcher leading that effort expired. We have almost recovered from all of that. Unfortunately, we have a bit of a bureaucracy to deploying public facing systems. So I would guess it will take ~end of March to get it on-line. Thanks DougM -- Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST Date: Thu, 14 Feb 2019 21:39:00 +0000 From: nusenu <nusenu-lists(a)riseup.net> To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram(a)nist.gov> Cc: rpki-monitor <rpki-monitor(a)nist.gov>, "nanog(a)nanog.org" <nanog(a)nanog.org>, "Montgomery, Douglas (Fed)" <dougm(a)nist.gov> Subject: Re: [proj-bgp] adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor? Message-ID: <2b8f9b07-27a7-08ba-ac51-afd39b30f769(a)riseup.net> Content-Type: text/plain; charset="utf-8" Sriram, Kotikalapudi (Fed) (2018-09-18):> I also found your analysis very interesting and useful. Thanks for that. > >> What do you think about adding graphs that show the amount of actually >> unreachable prefixes and IP space? (prefix where no alternative valid/unknown announcement exists) > > I am also part of the NIST BGP team. > Doug has already responded with information that we will soon have a new version of the NIST Monitor > which will provide the kind of graphs that you requested. Can you share an estimate for when you plan to publish the new version of the NIST Monitor? thanks, nusenu

2 2

AT&T contact
by Mehmet Akcin 01 May '19

01 May '19

Peering email is broken, looking for an AT&T contact. Please contact me off list. The original message was received at Tue, 30 Apr 2019 16:11:17 -0400 from m0053301.ppops.net [127.0.0.1] ----- The following addresses had permanent fatal errors ----- <peering(a)att.com> (reason: 550 5.1.1 <peering(a)att.com>... User unknown) ----- Transcript of session follows ----- ... while talking to [144.160.112.16]: >>> DATA <<< 550 5.1.1 <peering(a)att.com>... User unknown 550 5.1.1 <peering(a)att.com>... User unknown <<< 503 5.0.0 Need RCP -- Mehmet +1-424-298-1903

3 4

looking for hostname router identifier validation
by Matthew Luckie 01 May '19

01 May '19

Hi NANOG, To support Internet topology analysis efforts, I have been working on an algorithm to automatically detect router names inside hostnames (PTR records) for router interfaces, and build regular expressions (regexes) to extract them. By "router name" inside the hostname, I mean a substring, or set of non-contiguous substrings, that is common among interfaces on a router. For example, suppose we had the following three routers in the savvis.net domain suffix, each with two interfaces: das1-v3005.nj2.savvis.net das1-v3006.nj2.savvis.net das1-v3005.oc2.savvis.net das1-v3007.oc2.savvis.net das2-v3009.nj2.savvis.net das2-v3012.nj2.savvis.net We might infer the router names are das1|nj2, das1|oc2, and das2|nj2, respectively, and captured by the regex: ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$ After much refinement based on smaller sets of ground truth, I'm asking for broader feedback from operators. I've placed a webpage at https://www.caida.org/~mjl/rnc/ that shows the inferences my algorithm made for 2523 domains. If you operate one of the domains in that list, I would appreciate it if you could comment (private is probably better but public is fine with me) on whether the regex my algorithm inferred represents your naming intent. In the first instance, I am most interested in feedback for the suffix / date combinations for suffixes that are colored green, i.e. appear to be reasonable. Each suffix / date combination links to a page that contains the naming convention and corresponding inferences. The colored part of each hostname is the inferred router name. The green hostnames appear to be correct, at least as far as the algorithm determined. Some suffixes have errors due to either stale hostnames or incorrect training data, and those hostnames are colored red or orange. If anyone is interested in sets of hostnames the algorithm may have inferred as 'stale' for their network, because for some operators it was an oversight and they were grateful to learn about it, I can provide that information. Thanks, Matthew

10 16

Help needed to validate results of topology discovery research
by Bahador Yeganeh 30 Apr '19

30 Apr '19

Hi Nanog members, I am senior PhD student with the Oregon Network Research Group ( https://onrg.gitlab.io) at the University of Oregon, and sending this email to seek your help for validating the research results for one of our network measurement projects. We have conducted a large scale measurement study to infer the private (both physical and virtual) and public interconnections between Amazon/AWS network and all other ASes across the Internet along with their metro area where they are located. More information about this project can be found at https://ix.cs.uoregon.edu/~byeganeh/cloudx/. We are interested in validating at least part of our results against ground truth. If you are managing an AS that has one or more direct peerings with any of Amazon's networks (AS7224, AS16509, AS19047, AS14618, AS38895, AS39111, AS8987, and AS9059) and aware of their IPs and locations, it would be extremely valuable if you could validate our inferred peering between your AS and Amazon at the *aggregate level *(i.e. just indicating what fraction of our inferred interconnections for your network is correct). We will report this aggregate result in our study without revealing the identity of your network. If you have any questions or need more information about this project, please feel free to contact me. I appreciate your prompt response as we are trying to submit this study to a conference in a few weeks. Regards, Bahador Yeganeh

1 0

Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation (fwd)
by Carlos Friaças 30 Apr '19

30 Apr '19

Hi, Just to let everybody know that a petition was started in order to try to enable a policy discussion about "BGP Hijacking is an ARIN Policy Violation". If you would like to read the proposal, it is available at: https://www.arin.net/participate/policy/proposals/2019/ARIN_prop_266_v2/ Discussions are already ongoing at RIPE and LACNIC. Best Regards, Carlos (sorry for the duplicates, if you also receive arin-ppml(a)arin.net) ---------- Forwarded message ---------- Date: Fri, 26 Apr 2019 17:13:12 From: ARIN <info(a)arin.net> To: arin-ppml(a)arin.net Subject: [arin-ppml] Open Petition for ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation A petition has been initiated for the following: ARIN-prop-266: BGP Hijacking is an ARIN Policy Violation This proposal was rejected due to scope at the 10 April meeting of the Advisory Council. Anyone may take part in this petition. Per the Policy Development Process (PDP), a successful petition against a rejected Proposal requires the support of ten individuals from ten organizations. To support this petition, simply send a response to the Public Policy Mailing list stating your support, name, and organization. This petition window will remain open for five days, closing 1 May. If successful, the petition will result in the Board of Trustees considering the Proposal's scope at their next meeting. For more information on the PDP, visit: https://www.arin.net/participate/policy/pdp/ Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML(a)arin.net) Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact info(a)arin.net if you experience any issues.

11 27