- NANOG - lists.nanog.org

ARIN Online update to provide auto-managed IRR objects for RPKI ROAs (Fwd: [arin-announce] New Features Added to ARIN Online)
by John Curran 13 Jan '25

13 Jan '25

NANOGers - For those using RPKI, there is now optional functionality in ARIN Online that allows for automatic syncing of IRR route objects to ROAs - see additional information below. FYI, /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN <info(a)arin.net> Subject: [arin-announce] New Features Added to ARIN Online Date: January 13, 2025 at 11:01:00 AM PST To: "arin-announce(a)arin.net" <arin-announce(a)arin.net> ARIN is pleased to present the latest version of ARIN Online, including improvements, new features, and updates. Full release notes are included at the end of this message. Our work on this release has been completed, and all ARIN systems are operating normally. We thank you for your patience. If you have additional questions, comments, or issues, please submit an Ask ARIN ticket using your ARIN Online account or contact the Registration Services Help Desk by phone Monday through Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660. Regards, Mark Kosters Chief Technology Officer American Registry for Internet Numbers (ARIN) Release Notes • ARIN has completed work on the IRR Auto-Manager in ARIN Online, by introducing the option to selectively create auto-managed IRR route objects based on the Org’s existing ROAs in ARIN’s RPKI repository. Full details regarding this change can be found in a previous announcement https://www.arin.net/announcements/20241004-irrintegration/, and additional details and instructions can be found https://www.arin.net/resources/manage/rpki/irrautomanager/. • Minor improvements and bug fixes were made to improve the customer experience. _______________________________________________ ARIN-Announce

2 1

HBO / MAX Geolocation Contact
by Esteban Hernandez 13 Jan '25

13 Jan '25

Hello, Does anyone have contact information for HBO / MAX? Our residential customers cannot access the service and I suspect that the Geolocation has not been updated with HBO / MAX Thank you ESTEBAN HERNANDEZ | GERENTE IT https://lixer.mx/

4 4

400G link L2 flakiness over DWDM
by Oliver Garraux 13 Jan '25

13 Jan '25

We have a number of new 400G provider waves with odd flakiness that we can't seem to sort out. These links appear good - light levels are fine, links will be up with working LLDP. But if we admin down / up the link on the IP side, many of them won't come back up on their own. Our provider sees "loss of alignment" alarms on the optical equipment, and we can eventually get the links back up if they bounce them a few times on the DWDM side. We're using Juniper PTX's, with Juniper 400G FR4 and 400G LR4 optics. Same issue on different circuits/devices/paths with this provider, but no issues with other transport providers using the same optics on our end. Believe our provider is using Ciena optical equipment. Has anyone seen issues like this before? Our provider has been looking into this for months without much progress. One tantalizing clue was another customer using Cisco Nexus had better results after they enabled "link transmit reset-skip" (https://quickview.cloudapps.cisco.com/quickview/bug/CSCvi45168) Not clear exactly what that option does, and there doesn't seem to be an obviously equivalent config knob in Junos. Thanks, Oliver

5 8

Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
by Mel Beckman 13 Jan '25

13 Jan '25

I noticed that Level3 open DNS 4.2.2.1 and 4.2.2.2 stopped responding to ping today. They are responding to DNS queries however. Does anyone know if this filtering is going to be permanent? -mel beckman

6 7

Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work
by nanog＠fleish.org 13 Jan '25

13 Jan '25

I’m seeing some of the resolver IPs being filtering from various locations while responding from others, no doubt due to their use of anycast. I rarely ping test 4.2.2.2 anymore, having switched to 8.8.8.8 some time ago which I have a window up running 24x7 as a quick way to detect if my laptop is having connectivity issues from wherever it currently resides. It’s usually reliable, but I understand such traffic is the first to get filtered/dropped when needed so it’s just an initial indicator for me from which further testing can be performed when needed. I will also mention it’s possible to detect which NS server/pool/location you are reaching on Level3’s network via the below dig query. This has been an invaluable tool over the years as IME they tend to break DNS sub-delegation at least once or twice a year and the more data you can provide to them about where the breakage is the faster you can get them to engage the DNS team to actually fix it vs. arguing with you that it’s not broken because it "works for them” (facepalm). And at least once I found they broke resolution on their authoritative name servers (ns1.l3.net <http://ns1.l3.net/> or ns2.l3.net <http://ns2.l3.net/>) and again they first told me it wasn’t a problem because DNS again the broken one(s) would timeout and then get the answer from another, working server (double-facepalm). dig +short @4.2.2.2 hostname.bind CH TXT I’ve also been provided this query to derive the same for Cloudflare’s NS servers: dig CHAOS TXT id.server @1.1.1.1 +nsid And the following for Cleanbrowsing NS servers (these power content filtering on Unifi networks): nslookup -type=txt iptest.whois.dnscontest.cleanbrowsing.org <http://iptest.whois.dnscontest.cleanbrowsing.org/> Below are the results I got for Level3 from various locations (pardon the wall of text). It looks like they’re making some changes to serve DNS queries off their NTP servers From Level3 WDC1/McLean: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.987/0.987/0.987/0.000 ms "pubntp1.wdc12" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.926/0.926/0.926/0.000 ms "cns4.sjo1" PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.799/0.799/0.799/0.000 ms "pubntp1.wdc12" PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.855/0.855/0.855/0.000 ms "pubntp2.wdc12" PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.897/0.897/0.897/0.000 ms "cns4.sjo1" PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.973/0.973/0.973/0.000 ms "pubntp1.wdc12” From Level3 SFO1/Sunnyvale: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms "cns3.sjo1" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns2.sjo1" PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns1.sjo1" PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns2.sjo1" PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.275/0.275/0.275/0.000 ms "cns3.sjo1" PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns3.sjo1” From Comcast Atlanta: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns2.atl2" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 13.442/13.442/13.442/0.000 ms "cns4.atl2" PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 13.431/13.431/13.431/0.000 ms "cns2.atl2" PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 13.632/13.632/13.632/0.000 ms "cns2.atl2" PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 12.656/12.656/12.656/0.000 ms "cns3.atl2" PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 12.041/12.041/12.041/0.000 ms "cns4.atl2” From AT&T Atlanta: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns2.atl2" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "pubntp1.atl2" PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns3.atl2" PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 15.430/15.430/15.430/0.000 ms "pubntp1.atl2" PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns3.atl2" PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 16.103/16.103/16.103/0.000 ms "cns4.atl2” From AT&T SF Bay Area Peninsula: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 7.880/7.880/7.880/0.000 ms "cns3.sjo1" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns2.sjo1" PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 6.888/6.888/6.888/0.000 ms "cns3.sjo1" PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1000ms "cns4.sjo1" PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 7.173/7.173/7.173/0.000 ms "cns1.sjo1" PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns2.sjo1” From DRFortress Honolulu: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns3.sjo1" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns3.sjo1" PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 54.233/54.233/54.233/0.000 ms "cns3.sjo1" PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns3.sjo1" PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 54.195/54.195/54.195/0.000 ms "cns3.sjo1" PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms "cns4.sjo1” From Hawaiian Telecom Honolulu (oddly from here I get no response to the hostname.bind dig queries): PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 54.727/54.727/54.727/0.000 ms PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 56.765/56.765/56.765/0.000 ms PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms From Unitas Seacacus: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.062/2.062/2.062/0.000 ms "cns2.nyc6" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.012/2.012/2.012/0.000 ms "cns2.nyc6" PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.651/1.651/1.651/0.000 ms "cns3.nyc6" PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.055/2.055/2.055/0.000 ms "cns2.nyc6" PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 2.102/2.102/2.102/0.000 ms "cns3.nyc6" PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.626/1.626/1.626/0.000 ms "cns3.nyc6” From Verizon FIOS New York (oddly from here I get no response to the hostname.bind dig queries): PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 4.355/4.355/4.355/0.000 ms PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 3.764/3.764/3.764/0.000 ms PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 4.053/4.053/4.053/0.000 ms PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 3.394/3.394/3.394/0.000 ms PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 3.442/3.442/3.442/0.000 ms PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 4.944/4.944/4.944/0.000 ms From Allied Telecom in Washington DC: PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data. --- 4.2.2.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.683/1.683/1.683/0.000 ms "pubntp1.wdc12" PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data. --- 4.2.2.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.592/1.592/1.592/0.000 ms "pubntp2.wdc12" PING 4.2.2.3 (4.2.2.3) 56(84) bytes of data. --- 4.2.2.3 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.776/1.776/1.776/0.000 ms "cns1.wdc12" PING 4.2.2.4 (4.2.2.4) 56(84) bytes of data. --- 4.2.2.4 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.810/1.810/1.810/0.000 ms "pubntp2.wdc12" PING 4.2.2.5 (4.2.2.5) 56(84) bytes of data. --- 4.2.2.5 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.729/1.729/1.729/0.000 ms "cns1.wdc12" PING 4.2.2.6 (4.2.2.6) 56(84) bytes of data. --- 4.2.2.6 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.432/1.432/1.432/0.000 ms "cns4.sjo1” -T > On Jan 13, 2025, at 07:00, nanog-request(a)nanog.org wrote: > > Message: 6 > Date: Mon, 13 Jan 2025 04:24:50 +0000 > From: Mel Beckman <mel(a)beckman.org <mailto:mel@beckman.org>> > To: Daniel Sterling <sterling.daniel(a)gmail.com <mailto:sterling.daniel@gmail.com>> > Cc: Jerry Cloe <jerry(a)jtcloe.net <mailto:jerry@jtcloe.net>>, "nanog(a)nanog.org <mailto:nanog@nanog.org>" <nanog(a)nanog.org <mailto:nanog@nanog.org>> > Subject: Re: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS > queries work > Message-ID: <1E72A509-881F-453A-B5D4-7AF8FDB44C4E(a)beckman.org <mailto:1E72A509-881F-453A-B5D4-7AF8FDB44C4E@beckman.org>> > Content-Type: text/plain; charset="utf-8" > > Dan, > > Thanks! I had never read that before. But that makes sense. > > -mel > > On Jan 12, 2025, at 8:22?PM, Daniel Sterling <sterling.daniel(a)gmail.com <mailto:sterling.daniel@gmail.com>> wrote: > > ? > Seems like these IPs not responding to ping is not unusual, as per https://www.reddit.com/r/sysadmin/comments/11syv2e/google_dns_8888_dropping… > > "Google has stated multiple times before as has Level3/CenturyLink/Lumen that 4.2.2.1 and 8.8.8.8 should not be used for ping checks and they will drop packets when under load or if they notice too much activity from a single IP" > > -- Dan > > On Sun, Jan 12, 2025 at 11:03?PM Mel Beckman <mel(a)beckman.org <mailto:mel@beckman.org><mailto:mel@beckman.org>> wrote: > Still not pinging from Frontier, Lumen, AT&T, or Verizon networks > > > -mel > > On Jan 12, 2025, at 4:13?PM, Jerry Cloe <jerry(a)jtcloe.net <mailto:jerry@jtcloe.net><mailto:jerry@jtcloe.net>> wrote: > > ? > O:\>ping 4.2.2.1 > > Pinging 4.2.2.1 with 32 bytes of data: > Reply from 4.2.2.1<http://4.2.2.1 <http://4.2.2.1/>>: bytes=32 time=36ms TTL=56 > Reply from 4.2.2.1<http://4.2.2.1 <http://4.2.2.1/>>: bytes=32 time=44ms TTL=56 > Reply from 4.2.2.1<http://4.2.2.1 <http://4.2.2.1/>>: bytes=32 time=36ms TTL=56 > Reply from 4.2.2.1<http://4.2.2.1 <http://4.2.2.1/>>: bytes=32 time=38ms TTL=56 > > Ping statistics for 4.2.2.1<http://4.2.2.1 <http://4.2.2.1/>>: > Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), > Approximate round trip times in milli-seconds: > Minimum = 36ms, Maximum = 44ms, Average = 38ms > > Same for 4.2.2.2 > > > > -----Original message----- > From: Mel Beckman <mel(a)beckman.org <mailto:mel@beckman.org><mailto:mel@beckman.org>> > Sent: Sun 01-12-2025 06:07 pm > Subject: Level3 4.2.2.1 and 4.2.2.2 not responding to pings, DNS queries work > To: nanog(a)nanog.org <mailto:nanog@nanog.org><mailto:nanog@nanog.org>; > I noticed that Level3 open DNS 4.2.2.1 and 4.2.2.2 stopped responding to ping today. They are responding to DNS queries however. > > Does anyone know if this filtering is going to be permanent? > > -mel beckman >

4 4

Apply Today for the ARIN 55 Fellowship Program
by John Sweeting 13 Jan '25

13 Jan '25

Hello NANOG, Please see the announcement below referencing ARIN's Fellowship Program. Thanks, John S. ________________________________ From: ARIN-announce <arin-announce-bounces(a)arin.net<mailto:arin-announce-bounces@arin.net>> on behalf of ARIN <info(a)arin.net<mailto:info@arin.net>> Sent: Thursday, January 9, 2025 10:56 AM To: arin-announce(a)arin.net<mailto:arin-announce@arin.net> <arin-announce(a)arin.net<mailto:arin-announce@arin.net>> Subject: [arin-announce] Apply Today for the ARIN 55 Fellowship Program Learn more about Internet governance, number resource policy, and the ARIN community by becoming an ARIN Fellow. Applications for the ARIN 55 Fellowship Program are now open, and we encourage you to apply for this specialized, interactive learning opportunity. APPLY NOW: https://arin.net/beafellow Applications are now being accepted through 27 January 2025.  Fellows will attend virtual sessions before and after the ARIN 55 Public Policy and Members Meeting on 27-30 April 2025 in Charlotte, North Carolina, and may attend ARIN 55 either in person or virtually at the discretion of the Fellowship Selection Committee. With the personal support of ARIN community member Mentors, Fellows will have the opportunity to ask questions, get feedback, and gain the knowledge and confidence to join in community discussions, propose new ideas, and become part of the future of Internet governance and policy in the ARIN region.  Individuals who are 18 years of age or older and reside in the ARIN region are eligible to apply if they have a demonstrated interest in the ARIN community and its Policy Development Process for the management of Internet number resources.   Applicants should understand the importance of ARIN’s mission and be familiar with ARIN services, the Internet number resources it manages, and the processes reflected in the Number Resource Policy Manual (NRPM).   To learn more about ARIN’s Fellowship Program, the selection process, and the Terms and Conditions, please visit: https://www.arin.net/fellowship. Applicants can email fellowships(a)arin.net<mailto:fellowships@arin.net> for more information or to request a customizable letter to their employer that highlights the benefits of taking part in ARIN’s Fellowship Program.  ARIN looks forward to receiving your application soon!  Regards,  Amanda Gauldin Project Manager American Registry for Internet Numbers (ARIN)

1 1

Comcast looking glass router
by razor＠meganet.net 13 Jan '25

13 Jan '25

Hi, hoping someone here from Comcast can help me. I need to be able to login Comcast Looking Glass router in NY to check on some route advertising but the username and password that was previously working for the LG no longer seems to work. Host: route-server.newyork.ny.ibone.comcast.net Username: rviewsxr Password: rviews and I also tried rviewsxr If anyone knows the current login info I would appreciate it. P

4 6

Google Geo IP contact
by Lou Devictoria 13 Jan '25

13 Jan '25

Hi Nanog Is there anyone from Google who can help me correcting GeoIP information for my sites . Please contact me

2 1

BFD vs network brownouts
by David Zimmerman 12 Jan '25

12 Jan '25

Hi, all. BFD is well known for what it brings to the table for improving link failure detection; however, even at a reasonably athletic 300ms Control rate, you're not going to catch a significant percentage of brownout situations where you have packet loss but not a full outage. I'm trying to: 1. find any formal or semi-formal writing about quantification of BFD's effectiveness. For example, my mental picture is a 3D graph where, for a given Control rate and corresponding Detection Time, the X axis is percentage of packet loss, the Y axis is the Control/Detection timer tuple, and the Z axis is the likelihood that BFD will fully engage (i.e., missing all three Control packets). Beyond what I believe is a visualization complexity needing some single malt scotch nearby, letting even a single Control packet through resets your Detection timer. 2. ask if folks in the Real World use BFD towards this end, or have other mechanisms as a data plane loss instrumentation vehicle. For example, in my wanderings, I've found an environment that offloads the diagnostic load to adjacent compute nodes, but they reach out to orchestration to trigger further router actions in a full-circle cycle measured in minutes. Short of that, really aggressive timers (solving through brute force) on BFD quickly hit platform limits for scale unless perhaps you can offboard the BFD to something inline (e.g. the Ciena 5170 can be dialed down to a 3.3ms Control timer). Any thoughts appreciated. I'm also pursuing ways of having my internal "customer" signal me upon their own packet loss observation (e.g. 1% loss for most folks is a TCP retransmission, but 1% loss for them are crying eyeballs and an escalation). -dp

6 10

ZANOG25: Call for Papers
by Amreesh Phokeer 11 Jan '25

11 Jan '25

Hello all. The ZANOG25 Programme Committee is now seeking contributions for presentations for the ZANOG 2025 Conference, which will be held on 23-24 April 2025 in Durban, South Africa. Details about the Call for Papers, how you can submit a proposal for the conference, and the submission deadlines, can be found at the link below: https://events.nog.net.za/event/58/abstracts/ We look forward to receiving your papers and seeing you in Durban. Many thanks! ZANOG25 Programme Committee -- Amreesh Phokeer

1 0