June 2020 - 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

DoD IP Space
by Chris Knipe 27 Apr '21

27 Apr '21

Hi Guys, Except for the email on ARIN's details, does anyone else have a contact for the DoD? We are experiencing a situation with a 3rd party (direct peer), wanting to advertise DoD address space to us, and we need to confirm whether they are allowed to do so or not. Range in question is the 22.0.0.0/8 network, which according to ARIN is actively assigned to the DoD (US). -- Regards, Chris Knipe

60 178

Oracle Certification Exams...
by Michael Bullut 02 Jul '20

02 Jul '20

Greetings Team, Are there any Oracle Certified Professionals in the group? Currently, I am undertaking several Oracle certifications during this month and would to inquire which materials did you use to prepare for the aforementioned? Warm regards, Michael Bullut. --- *Cell:* *+254 723 393 114.**Skype Name:* *Michael Bullut.* *Blog: http://www.kipsang.com/ <http://www.kipsang.com/>* *E-mail:* *main(a)kipsang.com <main(a)kipsang.com>* *---*

2 1

Re: Microsoft SNDS contact with a clue?
by Brian Rak 01 Jul '20

01 Jul '20

Unfortunately, that's the generic SNDS support email I have been talking to. They don't appear to be able to actually fix anything. On 6/25/2020 3:03 PM, Udeme Ukutt wrote: > Brian, try msn-snds(a)microsoft.com <mailto:msn-snds@microsoft.com>. > It's been awhile I've had to use it, but it's worth a shot. > > Udeme > Postmaster at LinkedIn > > On Thu, Jun 25, 2020 at 12:00 PM Brian Rak via NANOG <nanog(a)nanog.org > <mailto:nanog@nanog.org>> wrote: > > Is there anyone around from Microsoft that can help me with a SNDS > verification issue? > > I'm having problems where the verification system is trying to use > the > wrong WHOIS server, and the responses I'm getting from support don't > really indicate they understand the issue. > > I also have a different problem where I have a /17 and support keeps > telling me I need to go and verify all the /23's within it... > which is > going to take quite awhile. > >

2 1

Devil's Advocate - Segment Routing, Why?
by Mark Tinka 01 Jul '20

01 Jul '20

Hi all. When the whole SR concept was being first dreamed up, I was mildly excited about it. But then real life happened and global deployment (be it basic SR-MPLS or SRv6) is what it is, and I became less excited. This was back in 2015. All the talk about LDPv6 this and last week has had me reflecting a great deal on where we are, as an industry, in why we are having to think about SR and all its incarnations. So, let me be the one that stirs up the hornets' nest... Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+? I've heard a lot about "network programmability", e.t.c., but can anyone point me toward a solution that actually does this in the way that it has been touted for years? A true flow that shows the implementation of "network programming" over any incarnation of SR? Perhaps one a customer can go to the shop and grab off the shelf? A lot of kit does not currently support SR, be it in hardware or software. So are operators expected to dispose of boxes that are happily moving MPLS frames along with no complaints, and replace them with some newfangled creations that will support SR in code and silicon? At whose cost? Not just money, but time, people and working the day-to-day kinks out? I've heard about "end-to-end service chaining" as a use-case for SR. To service-chain what? Classic telco's don't offer complex over-the-top services that operate at a such a scale that "service chaining" in SR would make lives easier. More than half of the traffic we are carrying is coming in over the public Internet, and not some private VPN. And if "service chaining" makes sense to the cloud and content operators who run humongous data centres where the servers significantly outnumber the routing/switching/transport gear, I'd naively posit that they have built a myriad of custom, in-house solutions, systems, tools and controllers to do all the "service chaining" they could ever need, and have been at it for more than 10 years, if not more, all to manage an MPLS/DWDM backbone. So what off-the-shelf "service chaining" controller are they going to walk into the shop and pay money for? If I had to think of the number of network, content and cloud operators who have either said they've deployed some kind of SR, or intend to, you're looking at probably 10% - 15% of a market. What about the other 85% - 90% of the operators whose requirements are so simple, thinking about dumping existing boxes, systems, tools and solutions that work very well in order to join the SR club doesn't seem feasible. What problems are 90% of the operators running MPLS having that SR will truly fix, given that they don't operate large, distributed data centres or have a 5G license? What's even more wild, is that there are equally a number of networks that are stalling IPv6 deployment, for some reason or other, meaning it will probably take us another 1 to 2 decades to see worldwide adoption of IPv6. If SRv6 or SRv6+ is "where the market is dying to go", and a bunch of operators don't have IPv6 in their plans, what gives? To be clear, I'm not against SR; what has to come will come. What I am less enthused about is being forced into an all-or-nothing scenario for the going concern of my network. For those that are keen on SR, give them SR. But for those who would prefer to keep things simple in networks that are not about to fall over and die, let's have LDPv6 and let's implement RFC 7439. Then let the operators choose. On a personal note, it's a pity Juniper gave in to the SRv6 fight, despite all the initial resistance. If they'd gone a different direction and simply implemented RFC 7439 (they have LDPv6 already), not only would that have put Cisco under serious pressure, but it would have solved the problems of many network operators that are desperately looking to go IPv6-only, and still maintain the rich MPLS services they and their customers have grown to like. Mark.

12 38

Europe IP Transit Provider Ideas ?
by James Braunegg 30 Jun '20

30 Jun '20

Dear Nanog For those running a AS with multiply POP locations around the world who would you recommend as a strong tier 1 transit provider in Europe (good routes to Africa would be a bonus) We currently take full table feeds from Telia, GTT, Cogent, Retn, tisparkle (Seabone) we are also looking at adding NTT in the USA and maybe also in Europe but any other recommendations ? Happy to be contacted by transit providers off list, thanks in advance Kindest Regards James Braunegg [cid:image001.png@01D280A4.01865B60] 1300 769 972<tel:1300%20769%20972> / 0488 997 207<tel:1300%20769%20972> james(a)micron21.com<mailto:james@micron21.com> www.micron21.com/<http://www.micron21.com/> [cid:image002.png@01D280A4.01865B60]<http://www.micron21.com/> [cid:image003.png@01D280A4.01865B60]<https://www.facebook.com/micron21/> [cid:image004.png@01D280A4.01865B60]<https://twitter.com/micron21> Follow us on Twitter<https://twitter.com/micron21> for important service and system updates. This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.

7 7

RE: Devil's Advocate - Segment Routing, Why?
by adamv0025＠netconsultings.com 30 Jun '20

30 Jun '20

> From: NANOG <nanog-bounces(a)nanog.org> On Behalf Of Mark Tinka > Sent: Wednesday, June 17, 2020 6:07 PM > > > I've heard a lot about "network programmability", e.t.c., First of all the "SR = network programmability" is BS, SR = MPLS, any programmability we've had for MPLS since ever works the same way for SR. > but can anyone > point me toward a solution that actually does this in the way that it has been > touted for years? A true flow that shows the implementation of "network > programming" over any incarnation of SR? Perhaps one a customer can go to > the shop and grab off the shelf? > Yes anything that works for RSVP-TE (i.e. PCEP), if you want to play there's this free app on top of ODL(acting as PCEP+BGP-LS) to program LSPs (can't recall the name). > I've heard about "end-to-end service chaining" as a use-case for SR. "service chaining" = traffic-engineering, you can do that with or without SR just fine. > To > service-chain what? To service-chain DC or as hipsters call it "cloud" stuff. To TE path from VM to FW to ...whatever, or to TE mice flows around elephant flows. > Classic telco's don't offer complex over-the-top services They do via telco cloud. > What problems are 90% of the > operators running MPLS having that SR will truly fix, > None, The same point I was trying to get across in our LDPv6 (or any v6 in control-plane or management plane for that matter) discussion, there's no problem to solve. Personally I'll be doing SR only in brand new greenfield deployments or if I start running out of RSVP-TE scale on existing deployments. adam

3 2

Layer 3 Switches
by Nathaniel Wingard 30 Jun '20

30 Jun '20

I'm looking to replace some access switches (Cisco Catalyst 3750 and 3560G). I really just need L2 features (stacking, PoE+, VLAN). I've found a 2960X that I like, but Cisco is pushing their 9200 series. The only downside I see is that the 9200s look to all have Layer 3 features. I've always shied away from L3 switches when I don't need the L3 features, but I don't have any solid reason not to just use the switches and turn off the L3 features I don't need. I'm looking for thoughts on this approach. Thanks, Nathaniel

7 8

netflix proxy/unblocker false detection
by Denys Fedoryshchenko 30 Jun '20

30 Jun '20

Did anybody noticed that Netflix just became useless due to tons of proxy/unblocker false detection on CGNAT ranges? Even my home network is dual stack, i am absolutely sure there is no proxy/vpn/whatsoever (but ipv4 part is over CGNAT) - and i got "proxy/unblocker" message on my personal TV. And many other ISP sysadmins told me that recently this is a massive problem, and netflix support is frankly inadequate and does not want to solve the problem. I will not be surprised that they will begin to actively lose users due to such a shameful silly screwed up algorithm. Who in sober mind blocks all legit users due probably one or two suspicious users behind same IP range?

16 40