- Test - lists.nanog.org

ASE - 100 Gig Wave
by Rod Beck 18 Mar '21

18 Mar '21

This cable is tapped out and I need a 100 gig wave from Hong Kong to Singapore. 3 year term. Roderick Beck Global Network Capacity Procurement United Cable Company www.unitedcablecompany.com<http://www.unitedcablecompany.com> https://unitedcablecompany.com/video/ New York City & Budapest rod.beck(a)unitedcablecompany.com Budapest: 36-70-605-5144 NJ: 908-452-8183 [1467221477350_image005.png]

3 2

Saudi Arabia
by Rod Beck 18 Mar '21

18 Mar '21

Hi, I've received a request to put a circuit into a Riyadh financial exchange. Any thoughts on how to get back haul from the AAE1 cable landing station would be appreciated. Off-list is best. 🙂 Roderick Beck Global Network Capacity Procurement United Cable Company www.unitedcablecompany.com<http://www.unitedcablecompany.com> https://unitedcablecompany.com/video/ New York City & Budapest rod.beck(a)unitedcablecompany.com Budapest: 36-70-605-5144 NJ: 908-452-8183 [1467221477350_image005.png]

4 5

Re: ASE - 100 Gig Wave
by sronan＠ronan-online.com 18 Mar '21

18 Mar '21

Please review the Mailing List policies which specifically prohibit commercial discussions on the list. I would ask the list moderators to chime in here please Shane > On Mar 18, 2021, at 11:14 AM, Rod Beck <rod.beck(a)unitedcablecompany.com> wrote: > > > People post requests all the time. You are free to block me. And I know the majority of uses disagree with you. > > From: Shane Ronan <shane(a)ronan-online.com> > Sent: Thursday, March 18, 2021 4:11 PM > To: Rod Beck <rod.beck(a)unitedcablecompany.com> > Cc: nanog(a)nanog.org <nanog(a)nanog.org> > Subject: Re: ASE - 100 Gig Wave > > NANOG is not a service for receiving details on cable paths for commercial purposes. Please find somewhere else to collect this information. > > On Thu, Mar 18, 2021 at 10:54 AM Rod Beck <rod.beck(a)unitedcablecompany.com> wrote: > This cable is tapped out and I need a 100 gig wave from Hong Kong to Singapore. 3 year term. > > Roderick Beck > Global Network Capacity Procurement > United Cable Company > www.unitedcablecompany.com > https://unitedcablecompany.com/video/ > New York City & Budapest > rod.beck(a)unitedcablecompany.com > Budapest: 36-70-605-5144 > NJ: 908-452-8183 > > >

7 10

an IP hijacking attempt
by Brian Turnbow 17 Mar '21

17 Mar '21

Hello everyone, We received a strange request that I wanted to share. An email was sent to us asking to confirm a LOA from a diligent ISP. The Loa was a request to open bgp for an AS , that is not ours, to announce a /23 prefix that is ours. So basically this entity sent to their upstream a request to announce a prefix from one our allocated ranges. We have the allocation correctly registered and ROAs in place , but it is worrisome that someone would attempt this. Obviously we have informed the ISP that the LOA is not valid and are trying to contact the originating party. Aside from RIRs for the offending AS and our IPs, Is there anywhere to report this type of activity? We have dealt with hijacking technically speaking in the past but this is the first time, to my knowledge, of someone forging a LOA with our IPs. Thanks in advance for any advice Brian P.S. a big thanks to Chris for checking the boxes before activating the filter if you are on the list!

5 6

IPv6 filtering at network edge?
by Pete Ashdown 17 Mar '21

17 Mar '21

I'm tightening up some network-edge filters, and in the process of testing filtering with IPv6, I found that there is a lot of ICMP link-local (fe80::) to ff02:: activity at an IX. Is any of this necessary? I am wary of over-filtering that cuts down functionality and doesn't increase security. What of the IANA-reserved IPv6 addresses can be safely blocked on ingress/egress at the network edge?

4 3

SFI/SBI/Transit - Dumping
by Douglas Fischer 16 Mar '21

16 Mar '21

Hello all! I'm going a bit deeper into the study of Peering Relationships... And one of the possibilities that I'm trying to understand better on the Peering Relationships on the Internet been considered dumping(economy). The matter here is more on the economic and commercial aspects than on the technical side. On the scope of Internet Peering Interconnections(Transit, Settlement Free, Settlement Based.): - There are any public papers, or even judicial processes, about situations that the possibility of Dumping(economic) was supposed? Independently if de dumping argument was accepted or not. - Does any colleague could remember some memorable case about that? - How does it affect the Big-Traffic-Guys (OTTs, Hosting/Colo/Cloud Datacenters, CDNs) and their routing policy on PNI/MPLA, SFI/SBI? -- Douglas Fernando Fischer Engº de Controle e Automação

7 9

ARIN-NONAUTH IRR final retirement set for 31 March 2022 (was: ARIN-NONAUTH data ARIN-NONAUTH dataFwd: [ARIN-consult] ACSP Consultation 2021.1: Future of ARIN’s Unauthenticated IRR is now Closed)
by John Curran 16 Mar '21

16 Mar '21

NANOGers - FYI - Outcome of the community consultation on the Future of ARIN’s Unauthenticated IRR. /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [ARIN-consult] ACSP Consultation 2021.1: Future of ARIN’s Unauthenticated IRR is now Closed Date: 15 March 2021 at 4:27:04 PM EDT To: <arin-consult(a)arin.net<mailto:arin-consult@arin.net>> I would like to thank everyone who provided valuable feedback during this consultation on the future of ARIN’s unauthenticated IRR. Input provided by the community is a vital part of our planning processes at ARIN, and after reviewing responses to the consultation, we are making a few significant adjustments in our path forward. One concern raised during the consultation was that six months was not enough time for organizations that currently depend on data in ARIN’s unauthenticated IRR to make changes to their systems. As a result, we will be extending the availability of ARIN’s non-authenticated IRR for an additional six months with final retirement set for 31 March 2022. The second major suggestion was that ARIN conduct proactive engagement to notifying customers who currently use our unauthenticated IRR. We have already initiated this outreach, and for the next twelve months, we will continue this direct outreach to customers who have records in ARIN’s non-authenticated IRR to inform them of their options and provide necessary assistance. We will also provide regular reminders and updates to our community and organizations making use of the outdated and non-authenticated IRR data stream so they can be ready for when we cease publishing the ARIN-NONAUTH data stream. These reminders leading up to the retirement of ARIN’s non-authenticated IRR will include statistics on the number of records remaining in that system and related routing coverage. Thank you again to those who provided valuable feedback on this consultation. Regards, John Curran President and CEO American Registry for Internet Numbers _______________________________________________ ARIN-Consult You are receiving this message because you are subscribed to the ARIN Consult Mailing List (ARIN-consult(a)arin.net<mailto:ARIN-consult@arin.net>). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services Help Desk at info(a)arin.net<mailto:info@arin.net> if you experience any issues.

3 4

Starlink terminal data acquisition for network engineers
by Eric Kuhnke 16 Mar '21

16 Mar '21

I thought about posting this to only NANOG, but since a great concentration of beta testers of a technical/network engineering inclination are located in the Pacific NW, decided to also include the SIX chat list. You may have seen the Starlink android or ios consumer-friendly app, which displays network traffic, uptime/downtime, and other link stats. I believe this to be polled directly from the antenna unit itself over grpc. The beta antennas are always 192.168.100.1. If you are using your own router with the starlink beta system, in addition to its WAN interface being an ordinary DHCP client in cgnat IP space, you'll need to manually give it an address in that /24 and set up routing to reach the .1 IP as needed. reference: https://github.com/sparky8512/starlink-grpc-tools reference: https://github.com/fullstorydev/grpcui you'll need a fairly normal Linux or BSD box with: git go python3 pip use pip to install grpcio and grpcio-tools install grpcurl: https://github.com/fullstorydev/grpcurl do a git clone of the starlink-grpc-tools url above, also take a look at its readme info get the dish's protoset file and write it to new file dish.protoset , this is an index of all data that can be polled cd /home/eric/starlink-grpc-tools /home/eric/go/bin/grpcurl -plaintext \ -protoset-out dish.protoset \ 192.168.100.1:9200 \ describe SpaceX.API.Device.Device /home/eric/go/bin/grpcurl \ -plaintext \ -d {\"get_history\":{}} \ 192.168.100.1:9200 \ SpaceX.API.Device.Device/Handle | python parseJsonHistory.py output of the above looks like this: 2021-02-06T08:15:56,3600,19.92034332,14,2,0.3125,0,0,0.0,0 full CSV header for the above: datetimestamp_utc,samples,total_ping_drop,count_full_ping_drop,count_obstructed,total_obstructed_ping_drop,count_full_obstructed_ping_drop,count_unscheduled,total_unscheduled_ping_drop,count_full_unscheduled_ping_drop since we are able to acquire the above in a comma-delimited csv format, it's fairly easy to write a script storing the integers from any one of those particular columns into a mariadb db, sqlite, influxdb, or whatever. the following will output about 3.8MB of text for the full history (I believe this to be the full copy of the ring buffer stored in RAM for the terminal's statistics) , pipe it into a text file if you want to manually look at it. /home/eric/go/bin/grpcurl -plaintext -d {\"get_history\":{}} 192.168.100.1:9200 SpaceX.API.Device.Device/Handle same as the above but human readable output /home/eric/go/bin/grpcurl \ -plaintext \ -d {\"get_history\":{}} \ 192.168.100.1:9200 \ SpaceX.API.Device.Device/Handle | python parseJsonHistory.py -v current counter: 299673 All samples: 43200 Valid samples: 43200 Parsed samples: 3600 Total ping drop: 20.03700998 Count of drop == 1: 14 Obstructed: 2 Obstructed ping drop: 0.3125 Obstructed drop == 1: 0 Unscheduled: 0 Unscheduled ping drop: 0.0 Unscheduled drop == 1: 0 see the get_history_notes.txt file for more info SOME EXAMPLE QUERIES these should match with what the json query is in the grpc GUI # get status /home/eric/go/bin/grpcurl \ -plaintext \ -d {\"getStatus\":{}} \ 192.168.100.1:9200 \ SpaceX.API.Device.Device/Handle # get device info /home/eric/go/bin/grpcurl \ -plaintext \ -d {\"getDeviceInfo\":{}} \ 192.168.100.1:9200 \ SpaceX.API.Device.Device/Handle # get history, this outputs a huge amount of data /home/eric/go/bin/grpcurl \ -plaintext \ -d {\"getHistory\":{}} \ 192.168.100.1:9200 \ SpaceX.API.Device.Device/Handle The following is copied/pasted from my notes file on things we can acquire, and then use a tiny shell script with awk, sed, regex, whatever as needed to trim out just the numbers, and put them somewhere else for polling by snmp extend /home/eric/go/bin/grpcurl \ -plaintext \ -d {\"getStatus\":{}} \ 192.168.100.1:9200 \ SpaceX.API.Device.Device/Handle notes on what's what: figures we care about to parse out and turn into just the integers snr can never be higher than 9 fractionobstructed appears to be the percentage of the time that the view is obstructed, as long as the view remains unobstructed, this number appears to slowly decrement over time validS is valid seconds? i think the S is almost likely always Seconds of time "uptimeS": "304439" "snr": 9, "fractionObstructed": 0.0013524292, "validS": 61815.74, "last24hObstructedS": 53 "downlinkThroughputBps": 47915.73, "uplinkThroughputBps": 34980.496, "popPingLatencyMs": 29.266666 example of running the command above twice, the second time a few minutes after the first, to see that fractionObstructed does decrement itself over time first run: 0.0013524292 second run: 0.0013467998

12 12

Letters of Authorization still aren't worth the paper they aren't printed
by Sean Donelan 15 Mar '21

15 Mar '21

Its amazing the telecommunications industry still uses or relies on "Letter of Authorization". Its less secure than faxing a piece of paper on "letterhead." I've said this before, check the archives. https://www.vice.com/en/article/y3g8wb/hacker-got-my-texts-16-dollars-sakar… While adding a number, Sakari provides the Letter of Authorization for the user to sign. Sakari's LOA says that the user should not conduct any unlawful, harassing, or inappropriate behaviour with the text messaging service and phone number. But as Lucky225 showed, a user can just sign up with someone else's number and receive their text messages instead.

2 1

OVH datacenter SBG2 in Strasbourg on fire 🔥
by Fredy Kuenzler 13 Mar '21

13 Mar '21

Very sad day for our colleagues at OVH AS16276 as they lost their datacenter SBG-2 in Strasbourg/France completly („everything is destroyed“) in a fire 🔥 and the neighboring SBG1/SBG3/SBG4 at least temporary. https://www.dna.fr/amp/faits-divers-justice/2021/03/10/strasbourg-important… -- Fredy Künzler Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur https://www.init7.net/

31 49