- NANOG - lists.nanog.org

Re: What are folks using for serial consoles these days?
by Mel Beckman 18 Dec '25

18 Dec '25

We use the AirConsole line extensively: <https://www.get-console.com/shop/en/27-airconsole> Airconsole - the only Serial Adaptor you'll ever need - Get Console Shop<https://www.get-console.com/shop/en/27-airconsole> get-console.com<https://www.get-console.com/shop/en/27-airconsole> [get-console-shop-logo-1429842958.jpg]<https://www.get-console.com/shop/en/27-airconsole> Tiny little brickey things that you can link together using daisychain cables and physical sliding interlocks. All the connections are RS45, so you do need various kinds of adapters, but those are available. Natively it speaks Cisco, but we have cables for HP and Juniper that interoperate as well. Internally, it’s basically a linux box. You get SSH pass-through to virtual serial ports with, so just SSH to a pre-configured TCP port number to connect to a given serial port in an AirCosole stack. A web GUI is nice for configuration. Plus it supports Wi-Fi connectivity, so they are super handy for portable use with tablets and smart phones too. Very well thought-out features such as unattended buffering, and dozens of knobs and dials. Airconsole Enterprise Server (previously "Private Server") is a VM appliance designed to provide NOC operators with remote “NASA Screen” infrastructure, creating a simple aggregation point for remote serial console access. I’ve used that in SCADA deployments for direct control outside of WonderWare. We are constantly finding new tricks these things can do. -mel beckman On Dec 17, 2025, at 4:52 PM, Dan Mahoney via NANOG <nanog(a)lists.nanog.org> wrote: Hey there folks. Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device. As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender). It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance". If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system. Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it? -Dan (You may have also seen my note earlier about the Cisco ASR920, which has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe) _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5VV3B6C…

2 1

The NANOG 96 CFP is open through 05-January-2026
by NANOG Program 18 Dec '25

18 Dec '25

NANOG Community at large, With the holidays coming, we know that submitting proposals won’t necessarily be at the top of your mind, so we wanted to send one more reminder before our collective brains check out for the rest of the year. We are accepting proposals through Monday, 05 January 2026, for in-person or live remote presentations at all sessions of NANOG 96 taking place in San Francisco, CA on 02-04 February 2026. Our spotlight topic for NANOG 96 is “AI and network infrastructure”, but we accept presentations on all relevant topics. The work you do and the ideas you have are interesting and important, and we’d love to hear more about it! Perhaps you’re having trouble figuring out what the NANOG audience would like to see. During every NANOG Conference, we ask everyone to answer the surveys and tell us what they want to hear about at a future conference. Some of the most recent answers are below. If you have a presentation on any of these general or specific topic areas, your community would love to hear from you! AI / Automation Topics - AI vs “traditional” datacenter networks - Automation approaches - Designing networks for AI traffic - Details on how to define and build AI agents - Network automation technologies - Early-career Professional Development topics - Basic hands-on tutorial track - More career development topics - Emerging technologies topics - More on net infra evolution and the drivers around it - New protocols, technologies, IETF work, etc. - Enterprise Networking Topics - Enterprises interacting with ISPs and the Internet - Overlays - Performance - Open source/freely available tools to move data quickly and efficiently - More information about how to measure and improve network performance from hosts. - Routing / BGP Topics - BGP Route Maps - Integrating IPv6 - Interplanetary networking - More on BGP in data centers like the "lightweight traffic engineering" talk - RPKI, Routing - Peering - Residential Broadband - Segment routing - Researcher / Student Topics - Opportunity for students to network - Researcher / operator BoF / forum - Security Topics - AI-driven botnets and residential proxies - DDoS mitigation topics - Security and IOT - Soft skills - Attracting software developers to network development/engineering - Career development - Computing and internet history - Intro to NANOG mailing list and other operational communities - Risk-based financial decision making - Transitioning from technical roles to management - Troubleshooting and best practices - Layer 2 ethernet best practices - Network architecture or on-prem troubleshooting - Provisioning, troubleshooting - Workshops and How-Tos - More in-depth how-tos / more in-depth seminars - Physical hands on labs - Other - Edge computing - Hardware topics such as ASIC or specific software oriented network engineering - How to start an ISP from scratch - More cloud network specific topics - Starlink - - Submit your presentation proposal and abstract via the Program Committee Tool at: https://www.nanog.org/meetings/submit-presentation/ - Sign in with your Profile Account - Select the type of talk you propose to present, and complete the form Timeline for submission and proposal review: NANOG 96 Calendar of Events Date Event/Deadline December 15, 2025 Topics List Published <https://nanog.org/events/nanog-96/agenda/> January 05, 2026 DRAFT Presentation Slides Due January 12, 2026 Meeting Agenda Published January 26, 2026 FINAL Slides Due February 01, 2026 On-Site Lightning Talk Submissions Open If you have any questions, please email the PC (nanogpc(a)nanog.org) and a representative will respond to you in a timely manner. Otherwise, submit your talk, tutorial, track, or panel proposal to the Program Committee Tool at your earliest convenience. We look forward to reviewing your submission! Sincerely, Adair Thaxton Program Committee Chair Sent on behalf of the NANOG PC

1 0

Seeking operator feedback on low-footprint network metadata probe with the goal of open-sourcing
by Fanch FRANCIS 18 Dec '25

18 Dec '25

Hi all, I’m part of a small team that’s been working on network visibility and security for some time now and we ended up developping a software network probe from scratch that we are considering to open-source. Our ask is not really should we, more how much of it? Would any of you use that and how? Now, for a bit of context. For years we have used the usual stack: Zeek plus homegrown glue for databases, dashboards, and so on. That works well enough in many environments (I mean, that’s what META uses for it’s own DC, so it does work alright), but in our own environment… we repeatedly hit limits in a few places: small edge boxes, noisy OT/telco environments, MSP-style multi-tenant deployments, and links where bandwidth drops are painful. At some point we stopped trying to patch more on top of Zeek and started building our own internal network probe instead 6 years ago (time flies by when you code fun stuff). We are now trying to decide how much of it (if any) should be open-sourced, and I’d like to sanity-check that with people who run similar tooling in production. What the probe does (high level) This is NANOG, so a network probe (DPI-based), shouldn’t be strange for a lot of you ;-) For those who are not familiar, it’s a tool that captures packets and turns them into enriched metadata / DB-ready records (flows, protocols, selected network metadata, assets, etc.). Some operational characteristics: * At around 1 Gbit/s sustained line rate, we are currently in the ballpark of: These numbers are still being tuned, but that’s the order of magnitude. * 2 CPU cores and 8GB of RAM * ~10 Mbit/s of metadata sent to the database * ~1 Mbit/s stored on disk after compression That's for the lean part, now for the carrier-grade: * Internal testing, plus commercial test gear (we had it certified by Spirent Communication), shows no false detections at full ine-rate 100 Gbit/s (145.000.000 pps, for around 10 to 12.000.000 news sessions per second) for 135+ network protocols (L2–L7) and nearly 4000+ applications, on simple commodity hardware (no FPGA/ASIC; just good old CPU and RAM). We are not using DPDK. For higher-speed use cases we ended up writing our own NIC drivers in Rust, too. For small links at full line rate with full protocol analysis, resource usage is roughly an order of magnitude lower than what we observed with Zeek or Suricata in equivalent scenarios (happy to share benchmark details if useful). What were our Design goals, in brief: * Low footprint: able to run “where Zeek/Suricata hurt”: on-prem systems, VMs, small Kubernetes worker nodes, cloud workloads, on both small x86 or ARM edge boxes (thanks to Rust), etc. * Simple deployment: a single static Rust binary with no dynamic dependencies. Drop it on a recent Linux host, point it at an interface, and it starts capturing. There is an installer with a CLI mode for use with Ansible/other automation. Optionally, a dockerized DB pipeline for ClickHouse/Postgres. * Fleet-oriented: usable at the scale of hundreds or thousands of probes in an MSP / distributed environment. * Outputs: JSON over HTTP / REST API, plus structured schemas for ClickHouse/Postgres so operators can plug in their own analytics, detections, or reporting. * Implementation: full Rust codebase, with a focus on predictability and safety rather than ad-hoc packet tricks that reduce visibility or telemetry quality. Why we didn’t just stick with Zeek This is not “Zeek bad, our code good”. We simply had a different set of constraints. The main drivers were: * Resource footprint when deploying probes directly on Kubernetes worker nodes, small cloud instances, or ARM edge devices. We also wanted to reuse the same probe design when monitoring much higher-speed links on commodity hardware. * Fleet and multi-tenant operation: the need to deploy, manage, and upgrade a large number of probes in an MSP / MSSP context, with clear separation between tenants. * Tighter control over metadata shape and volume: so that DB / storage does not explode in noisy environments. Our past Zeek deployments filled an Elastic cluster in a couple of days and often forced us to rebuild that instance; we wanted more predictable volume control. The result is a probe that overlaps with Zeek/Suricata functionally, but with different trade-offs. Open source, open core, or something else? Internally we are debating what would actually be useful to open-source for the operator community, versus what (if anything) should remain “product”. The rough options we see: * Open-source the probe engine and protocol parsers, so operators can run and extend it themselves and build their own services / UX on top. * Open-source primarily the DB schemas, ingestion pipeline, and operational tooling, while keeping the probe itself closed. * Keep the entire stack closed and offer it only as a self-hosted / appliance / cloud solution. Before we spend months going down any of these routes, I would really value operator feedback. Specific questions for the readers courageous enough to have reached this point in the post ;-) 1. Does this actually fill a gap for you, or is your current setup “good enough”? If you have deployed Zeek / Suricata / nProbe / NTOP / similar in anger, would you even look at something like this? 2. If some part of it were open-sourced, what would be most useful to you in practice? * Core probe and parsers? * Schemas / ingestion pipeline / deployment tooling? * SDKs / libraries to embed in your own systems? * Something else entirely? 3. Licensing / model concerns: Are there licenses that are an immediate “no” (e.g. AGPL)? Would “core open-source with additional commercial features” be acceptable, or is that a non-starter in your environment? 4. How you would realistically consume it: In your networks, would you be more likely to: * run it as a self-hosted binary on your own infrastructure, * deploy it as some kind of appliance, * or consume it as a managed service that delivers metadata or alerts? 5. What would make you discard it immediately? Examples: excessive resource usage, awkward integration model, unclear security story, problematic license, unclear long-term maintenance, etc. This is not a product announcement, beta signup, or marketing exercise. There are no links in this message. I am trying to avoid spending time open-sourcing the wrong components, or doing it in a way that doesn’t match how operators would actually use such a tool. If you have fought with network telemetry in production, I would appreciate hearing “this would be useful if X/Y/Z” or “we wouldn’t bother, because…”. I am happy to answer technical questions and take blunt feedback, on- or off-list, if this is of interest. Best regards, Fanch Fanch FRANCIS, PhD CEO +33 6 14 60 05 47 https://calendly.com/fanch-nanocorp/visio https://www.nanocorp.ai/<https://141-nanocorp.trakqit.com/?u=https:%2F%2Fwww.nanocorp.ai%2F&e=d4d55a…> [signature_2808701025] [https://141-nanocorp.trakqit.com/img/d4d55ac50f741f8ca2a25dfe80934e92]

1 1

Accidental ARIN Reallocation
by Chase 17 Dec '25

17 Dec '25

Hey NANOG, After receiving a BGPAlerter notification that one of our subnets (23.150.164.0/24) had been hijacked, I checked and noticed the prefix in question was missing RPKI. Assuming I had fat fingered something and butchered the ROA, I logged into ARIN and found that the prefix was missing from our resource list entirely, and had been reallocated to another organization and announced from their network. I created a ticket in ARIN and called immediately. They confirmed that our subnet had been accidentally reallocated to another customer, and that they are currently working on returning it to us. After a couple hours, they told us the other organization will stop announcing the prefix, and WHOIS will be returned shortly. I’m guessing there’s no way to prevent this kind of thing on our side if the RPKI ROA itself is removed along with the allocation? I’m planning on adding checks to look for missing ROAs (in addition to invalid/expiring ones), which I'm guessing would've caught this earlier. Have any of you had anything like this happen with ARIN or another RIR? I’m especially curious what might have happened if we’d only noticed and reached out a few weeks later instead of within a few minutes. Best, Chase Lauer GalaxyGate, AS397031 https://galaxygate.net

21 29

US Impact - October 29 2025
by Victor Kuarsingh 17 Dec '25

17 Dec '25

All, Anyone know what caused the large impact in the US at around noon ET today? regards, Vector K

9 11

Re: gstatic.com down?
by Jamie Null 17 Dec '25

17 Dec '25

On 17/12/2025 00:11, Jamie Null wrote: > On 16/12/2025 23:52, Hank Nussbacher via NANOG wrote: >> Is gstatic.com down? >> >> Thanks, >> >> Hank >> >> _______________________________________________ >> NANOG mailing list https://lists.nanog.org/archives/list/ >> nanog(a)lists.nanog.org/message/QOVGOUL7JAQTABKZNWUBPAHVPCTJ47R7/ > > Down for me - Getting a 404. > > Regards, > Jamie Sorry - I forgot gstatic is supposed to return a 404 on root. It looks like it works for me when I try to load content though. -- Jamie Null (They/Them) E: Lav(a)lavender.earth "A person cannot be made to suffer a grossly disproportionate punishment simply to send a message to discourage others from offending." — R. v. Nur, 2015 SCC 15, [2015] 1 SCR 773, per McLachlin CJ, at para 45

1 0

Simple node SID TE with either SRv6 or SR-MPLS
by David Zimmerman 17 Dec '25

17 Dec '25

Hi, folks. I’m activating the NANOG brain trust here because I’ve exhausted (and am exhausted from) efforts so far to seal the deal on what is probably simple stuff to y’all. TL;DR: I think I’m missing some specific glue to make my backbone data plane forward CE IPv4 traffic into a simple PE-to-PE node SID path. I’ve tried both SRv6 steering IPv4 encap in IPv6 GRE (due to lack of End.DX4 or End.DT4) and SR-MPLS. Anonymized and scrubbed topologies and configurations attached — Plan E for SRv6, Plan F* for SR-MPLS. Using Junos 23.4R2-S5.6, looking for the magic “you forgot this part” for either way (though SRv6 + IPv6 GRE preferred). Details: I have a video partner with CEs at two sites on my internal WAN using SMPTE 2022-7 to generate two identical video streams. I receive those on physically diverse links from his CEs to my PEs, then ideally carry them over diverse paths, which I need TE to do. A path of node SIDs satisfies (for now) proof that I can do this (adjacency SIDs later). Everything I’m doing passes Junos CLI syntax checking and “commit check” semantics, but when the change is complete, neither I nor my partner sees this work doing ... anything. I should see his video test patterns having a significant bump in the “blue” path transcontinental end-to-end latency because I’m heading towards Canada then heading towards Mexico on my way between coasts. The “red” path is almost a straight shot. My PEs do not run BGP, so I need to do all of this entirely within IS-IS. I believe my use of “color” in these configurations is a distraction that sounds like it should work but is misguided being a BGP knob. I believe I’ve identified that IPv6 GRE on Junos will only use inet6.0 and will not get steered by the SID path in other tables despite my trying mechanisms like resolution-ribs. I prefer to have this work with SRv6 because I’m greenfield and it’s kind of a moonshot. But at this point I’ll defer to something more tried-and-true like SR-MPLS just to get things working. Direct responses are great, public responses are cool if there are helpful learnings for others where my self-esteem in this space is fragile but sacrificial :-) -dp * Yes, “F” now stands for what you think it does

1 1

AT&T/Lumen interconnection disruption in ATL
by nanog＠fleish.org 16 Dec '25

16 Dec '25

I lost access to the Lumen network from AT&T in Atlanta for 27 minutes (12-16-2025 15:50 to 12-16-2025 16:17 - times UTC) and wanted to check if anyone else saw this from other networks/locations? It restored on it's own and from the traceroutes I was able to perform while it was down vs. now it seemed to be stuck making the jump between AT&T and Lumen @ 76.239.207.188 (AT&T per ARIN whois). Once things restored it progressed onto 4.68.62.225 (ae8.edge4.atl2.sp.lumen.tech) and then to the final destination. There was one instance where there was another hop in between those 2 @ 32.130.89.13 (AT&T per ARIN whois), but it is no longer showing up on retries.

2 2

RAM prices will hit us.
by Tom Mitchell 16 Dec '25

16 Dec '25

The current RAM situation will affect all networking hardware. Dell has reduced our quote leadtimes to 14 days. https://www.tomshardware.com/laptops/dell-preps-massive-price-hikes-up-to-3… <https://www.netelastic.com> *Tom Mitchell* tmitchell(a)netelastic.com M: +1 408-476-6104

1 0

Low Cost 400G??
by Mike Hammett 15 Dec '25

15 Dec '25

Is it paradoxical to wonder what low-cost full table (or close to it) 400G options there are? An earlier thread looks like the Arista 7280QR-C36 is "almost" there for 100G at a reasonable $3k, but a quick look at 400G-capable goes up, well, 4x in price, though one does get fully into DFZ capable devices then. It seems like anything with more than low 6 digit route capability goes into full-scale multi-million capability, which is great technically, but not so great financially. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

6 8