- NANOG - lists.nanog.org

Re: What do you consider acceptable packet / session modification for a network operator?
by Andrew 25 Dec '25

25 Dec '25

Glad everyone agrees ISPs should not be doing this! Most of these things are currently being done by a US national wireless ISP to their ~100M customers. I’m sure you can guess who it is, there are only 3 choices. I spent an afternoon hand-crafting packets on their network to a remote cloud VPS to try to understand wtf their network is doing. I did all of this over IPv6 to avoid CGNAT. The first clue to me is that a ‘what is my IP’ website does not report the same IPv6 as the device. Obviously we should never be using NAT in IPv6, so clearly this ISP is doing something suspicious, and the ‘what is my IP’ IPv6 ends in ::8 which is also suspiciously manually generated. I eventually concluded that all traffic with a TCP or UDP destination port of 443 was being NATed via this ::8 address, while a random high numbered destination port was coming from the device’s IPv6 as expected. I drilled down into the behavior of this port 443 proxy and concluded: - The proxy responds to all TCP SYNs with a SYN ACK and establishes a connection - After the connection is established, it will then dial the remote side, so if I never send the ACK it will never dial the remote side - If the remote side rejects the connection, the proxy will ‘eat’ all of the bytes which have already been sent and then close the connection without any error on the client side - The proxy will still pass arbitrary bytes after the connection is established, even if they are not TLS traffic, it also does not appear to impact TLS traffic in any way that I could detect - The proxy re-negotiates all of the TCP options, so setting MSS manually on either side does not get passed through. Congestion control will also be impacted by this. The proxy seems to choose 1370 as its preferred MSS on both sides. I cannot understand a legitimate use case for an ISP to run such a proxy on port 443, and the resources required to proxy essentially all of the TLS traffic for 100M customers must be enormous. I then tried to scan all ports with TCP SYNs to see if any proxy responded with a SYN ACK, but hit some sort of rate limit on new connections and got unreliable responses (this could have been in my handset, which is acting as a hotspot). I limited my search to the first 1024 ports and found similar behavior on ports 21, 80, 443, and 554. All four proxies each have their own public IP, and it is different for each (so ‘what is my ip’ on port 80 is different than on 443). Digging in to the port 80 proxy, when connecting over HTTP to any destiatnation on port 80, the proxy adds a ‘Via:’ header to the HTTP request. This includes a seemingly random but never changing ID which is formatted as a DNS name, although the specific subdomain does not exist. I suspect this is a unique identifier which identifies me as a subscriber uniquely for advertising purposes. It's also found that sending a valid HTTP response with an invalid HTTP status code number will cause the proxy to return an HTML page which says 503 Service Unavailable. I was not able to detect any modification of data, but again I have no idea if it may be modifying only certain sites / … Again, this is not my network, I am trying to understand why a network operator would interfere with their users in this way. Andrew

2 1

What are folks using for serial consoles these days?
by Dan Mahoney 25 Dec '25

25 Dec '25

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)

26 46

Re: What do you consider acceptable packet / session modification for a network operator?
by Andrew 25 Dec '25

25 Dec '25

I’m talking about consumer ISPs, who are providing service to their paid customers. Not ‘managed’ business / edu / shared housing networks Andrew

1 0

Testing Out Of Band Management Tooling
by Andrew Latham 23 Dec '25

23 Dec '25

All Related to the Serial console topic I wanted to do a quick test. I hit a hiccup in my documentation and addressed it. Questions: A: How often should one do dry run testing on OOBM? B: How often should one call and confirm emergency numbers for remote vendor sites? C: How could Out Of Band Management equipment be monitored better in 2025? If you have other thoughts about questions, pop them in starting at D -- - Andrew "lathama" Latham -

5 4

NTP at NIST Boulder has lost power
by Anne Johnson 20 Dec '25

20 Dec '25

reposting from the Internet time service list jeff.s...(a)nist.gov <jeff.sherman(a)nist.gov>: Dec 19 05:18PM -0800 Dear colleagues, In short, the atomic ensemble time scale at our Boulder campus has failed due to a prolonged utility power outage. One impact is that the Boulder Internet Time Services no longer have an accurate time reference. At time of writing the Boulder servers are still available due a standby power generator, but I will attempt to disable them to avoid disseminating incorrect time. The affected servers are: time-a-b.nist.gov time-b-b.nist.gov time-c-b.nist.gov time-d-b.nist.gov time-e-b.nist.gov ntp-b.nist.gov (authenticated NTP) No time to repair estimate is available until we regain staff access and power. Efforts are currently focused on obtaining an alternate source of power so the hydrogen maser clocks survive beyond their battery backups. More details follow. Due to prolonged high wind gusts there have been a combination of utility power line damage and preemptive utility shutdowns (in the interest of wildfire prevention) in the Boulder, CO area. NIST's campus lost utility power Wednesday (Dec. 17 2025) around 22:23 UTC. At time of writing utility power is still off to the campus. Facility operators anticipated needing to shutdown the heat-exchange infrastructure providing air cooling to many parts of the building, including some internal networking closets. As a result, many of these too were preemptively shutdown with the result that our group lacks much of the monitoring and control capabilities we ordinarily have. Also, the site has been closed to all but emergency personnel Thursday and Friday, and at time of writing remains closed. At initial power loss, there was no immediate impact to the NIST atomic time scale or distribution services because the projects are afforded standby power generators. However, we now have strong evidence one of the crucial generators has failed. In the downstream path is the primary signal distribution chain, including to the Boulder Internet Time Service. Another campus building houses additional clocks backed up by a different power generator; if these survive it will allow us to re-align the primary time scale when site stability returns without making use of external clocks or reference signals. Best wishes, -Jeff Sherman project email: internet-time-service(a)nist.gov AnneJ (watching from Edinburgh, UK)

1 0

Meet our Second N96 Keynote + More!
by Nanog News 19 Dec '25

19 Dec '25

*** NANOG Announces Second Keynote with Omar Baldonado, Meta* ------------------------------------------------------------ *AI Data Center Networking: Lessons from Meta's Evolution* Meta has evolved its networking architectures to meet the growing demands of AI workloads. This Keynote explores the journey through successive AI network deployments, sharing lessons learned from production at scale. Attendees will gain insights into how AI frameworks, xPU behavior, and NIC capabilities influence network design, and how decisions at each layer impact the overall stack. The talk also covers practical experiences with network automation, infrastructure density, telemetry for AI workloads, and strategies for managing rapid technology transitions while keeping production stable. *REGISTER NOW* (https://nanog.org/events/nanog-96/register/) *** Last Call for Content for NANOG 96* ------------------------------------------------------------ *Transform Your BIG Idea into a NANOG Talk* N96 is accepting all topics but will focus on AI and Network Infrastructure. ***Deadline approaching: Please submit a presentation proposal including draft slides no later than Monday, Jan. 5, 2026. *MORE INFO* (https://nanog.org/program/call-presentations/) *** Video of the Year: Check out our Most Viewed Talk from 2025* ------------------------------------------------------------ *Tutorial: Everything You Always Wanted to Know About Optical Networking – But Were Afraid to Ask w/ Richard Steenbergen, Petabit Scale* At nearly 24,000 views and counting 👀 Our most viewed NANOG talk of 2025 dives into optical networking fundamentals, fiber, optics, DWDM, dispersion, and myth-busting. Presented by Richard Steenbergen, Petabit Scale. If you touch fiber, this is required viewing. *WATCH NOW* (https://youtu.be/Y-MfLsnqluM?si=Aq9CIcrhFT0Rjs_b) *** Happy Holidays from NANOG! 🎄✨* ------------------------------------------------------------ May your latency be low, your uptime high, and your out-of-office respected. Thanks for making this community one of the best networks around. *** Stay Connected* ------------------------------------------------------------ http://www.facebook.com http://www.instagram.com/nanog_org/ http://www.linkedin.com/company/nanog/ https://www.twitter.com/nanog/ http://nanog.org

1 0

Weekly Global IPv4 Routing Table Report
by Routing Table Analysis Role Account 19 Dec '25

19 Dec '25

This is an automated weekly mailing describing the state of the Global IPv4 Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG UKNOF, TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats(a)lists.apnic.net. For historical data, please see https://thyme.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. IPv4 Routing Table Report 04:00 +10GMT Sat 20 Dec, 2025 IPv4 BGP Table (Global) as seen at Japan. Report Website: https://thyme.apnic.net Detailed Analysis: https://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 1023110 Prefixes after maximum aggregation (per Origin AS): 394691 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 505765 Number of IPv4 prefixes with a valid ROA: 601968 Number of IPv4 prefixes with an invalid ROA: 1551 Number of IPv4 prefixes with no ROA: 419591 Total ASes present in the Internet Routing Table: 77698 Prefixes per ASN: 13.17 Origin-only ASes present in the Internet Routing Table: 66762 Origin ASes announcing only one prefix: 27136 Transit ASes present in the Internet Routing Table: 10936 Transit-only ASes present in the Internet Routing Table: 551 Average AS path length visible in the Internet Routing Table: 4.7 Max AS path length visible: 69 Max AS path prepend of ASN (269326) 61 Prefixes from unregistered ASNs in the Routing Table: 970 Number of instances of unregistered ASNs: 1009 Number of 32-bit ASNs allocated by the RIRs: 48255 Number of 32-bit ASNs visible in the Routing Table: 39531 Prefixes from 32-bit ASNs in the Routing Table: 219511 Number of bogon 32-bit ASNs visible in the Routing Table: 109 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 720 Number of addresses announced to Internet: 3105876864 Equivalent to 185 /8s, 31 /16s and 235 /24s Percentage of available address space announced: 83.9 Percentage of allocated address space announced: 83.9 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.6 Total number of prefixes smaller than registry allocations: 334335 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 277340 Total APNIC prefixes after maximum aggregation: 81410 APNIC Deaggregation factor: 3.41 Prefixes being announced from the APNIC address blocks: 264169 Unique aggregates announced from the APNIC address blocks: 106558 APNIC Region origin ASes present in the Internet Routing Table: 14971 APNIC Prefixes per ASN: 17.65 APNIC Region origin ASes announcing only one prefix: 4590 APNIC Region transit ASes present in the Internet Routing Table: 1982 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 34 Number of APNIC region 32-bit ASNs visible in the Routing Table: 10524 Number of APNIC addresses announced to Internet: 753819648 Equivalent to 44 /8s, 238 /16s and 96 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-155961 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 299822 Total ARIN prefixes after maximum aggregation: 134992 ARIN Deaggregation factor: 2.22 Prefixes being announced from the ARIN address blocks: 300245 Unique aggregates announced from the ARIN address blocks: 145685 ARIN Region origin ASes present in the Internet Routing Table: 19383 ARIN Prefixes per ASN: 15.49 ARIN Region origin ASes announcing only one prefix: 7063 ARIN Region transit ASes present in the Internet Routing Table: 1941 Average ARIN Region AS path length visible: 4.3 Max ARIN Region AS path length visible: 28 Number of ARIN region 32-bit ASNs visible in the Routing Table: 5423 Number of ARIN addresses announced to Internet: 1342849280 Equivalent to 80 /8s, 10 /16s and 65 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-402332 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 282840 Total RIPE prefixes after maximum aggregation: 140007 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 283565 Unique aggregates announced from the RIPE address blocks: 183891 RIPE Region origin ASes present in the Internet Routing Table: 29141 RIPE Prefixes per ASN: 9.73 RIPE Region origin ASes announcing only one prefix: 12084 RIPE Region transit ASes present in the Internet Routing Table: 3938 Average RIPE Region AS path length visible: 4.8 Max RIPE Region AS path length visible: 31 Number of RIPE region 32-bit ASNs visible in the Routing Table: 12896 Number of RIPE addresses announced to Internet: 735156608 Equivalent to 43 /8s, 209 /16s and 153 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-216475 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 53/8, 57/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 126106 Total LACNIC prefixes after maximum aggregation: 30624 LACNIC Deaggregation factor: 4.12 Prefixes being announced from the LACNIC address blocks: 121900 Unique aggregates announced from the LACNIC address blocks: 49722 LACNIC Region origin ASes present in the Internet Routing Table: 11324 LACNIC Prefixes per ASN: 10.76 LACNIC Region origin ASes announcing only one prefix: 2666 LACNIC Region transit ASes present in the Internet Routing Table: 2526 Average LACNIC Region AS path length visible: 5.3 Max LACNIC Region AS path length visible: 69 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 9325 Number of LACNIC addresses announced to Internet: 170518784 Equivalent to 10 /8s, 41 /16s and 233 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-274844 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 36032 Total AfriNIC prefixes after maximum aggregation: 6996 AfriNIC Deaggregation factor: 5.15 Prefixes being announced from the AfriNIC address blocks: 52511 Unique aggregates announced from the AfriNIC address blocks: 19317 AfriNIC Region origin ASes present in the Internet Routing Table: 1999 AfriNIC Prefixes per ASN: 26.27 AfriNIC Region origin ASes announcing only one prefix: 733 AfriNIC Region transit ASes present in the Internet Routing Table: 386 Average AfriNIC Region AS path length visible: 5.3 Max AfriNIC Region AS path length visible: 47 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 1363 Number of AfriNIC addresses announced to Internet: 103175936 Equivalent to 6 /8s, 38 /16s and 87 /24s AfriNIC AS Blocks 36864-37887, 327680-329727 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 9808 13405 8760 123 CHINAMOBILE-CN China Mobile Communication 7545 6040 834 583 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 5027 4193 77 ERX-CERNET-BKB China Education and Resear 9498 4631 542 336 BBIL-AP BHARTI Airtel Ltd., IN 7552 4025 1332 28 VIETEL-AS-AP Viettel Group, VN 7713 3730 1044 65 TELKOMNET-AS-AP PT Telekomunikasi Indones 56046 3375 831 184 CMNET-JIANGSU-AP China Mobile communicati 45899 3330 1869 99 VNPT-AS-VN VNPT Corp, VN 24560 2960 865 503 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., 17561 2840 179 617 LCS-AS-AP LARUS Limited, HK Complete listing at https://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 16509 14052 38461 5450 AMAZON-02, US 22773 4779 3118 370 ASN-CXA-ALL-CCI-22773-RDC, US 11492 4687 311 949 CABLEONE, US 7155 3861 286 85 VIASAT-SP-BACKBONE, US 6327 3691 1320 83 SHAW, CA 396982 3316 4867 490 GOOGLE-CLOUD-PLATFORM, US 749 3142 54729 2393 DNIC-AS-00749, US 16625 2857 1223 2141 AKAMAI-AS, US 36352 2821 229 904 AS-COLOCROSSING, US 174 2721 8769 865 COGENT-174, US Complete listing at https://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 7295 1711 149 UNI2-AS, ES 39891 4833 298 66 ALJAWWALSTC-AS, SA 9009 3953 369 2262 M247, RO 20940 3835 3394 122 AKAMAI-ASN1, NL 12389 3175 2317 871 ROSTELECOM-AS PJSC Rostelecom. Technical 212238 2557 182 1857 CDNEXT, GB 34984 2420 363 574 TELLCOM-AS, TR 8452 1688 1852 14 TE-AS TE-AS, EG 203020 1617 242 783 HOSTROYALE, IN 13188 1607 100 27 TRIOLAN, UA Complete listing at https://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 12687 3285 587 UNINET, MX 10620 3433 457 1107 Telmex Colombia S.A., CO 13999 2493 507 353 Mega Cable, S.A. de C.V., MX 11830 1992 369 65 Instituto Costarricense de Electricidad y 11664 1369 278 33 Techtel LMDS Comunicaciones Interactivas 28573 1369 2429 273 Claro NXT Telecomunicacoes Ltda, BR 3816 1339 770 213 COLOMBIA TELECOMUNICACIONES S.A. ESP BIC, 6147 1263 371 22 Telefonica del Peru S.A.A., PE 22884 1057 67 359 TOTAL PLAY TELECOMUNICACIONES SA DE CV, M 26615 1025 2486 56 TIM SA, BR Complete listing at https://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24835 1944 482 23 RAYA-AS, EG 36992 1824 1531 424 ETISALAT-MISR, EG 24863 1263 389 16 LINKdotNET-AS, EG 36903 1250 554 97 MT-MPLS, MA 37069 1084 1096 13 MOBINIL, EG 29571 1072 94 22 ORANGE-COTE-IVOIRE, CI 36935 1047 520 32 Vodafone-, EG 20011 580 154 212 NTT-DATA-Inc, ZA 36914 557 82 3 KENET-AS, KE 15399 541 56 53 WANANCHI-, KE Complete listing at https://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 16509 14052 38461 5450 AMAZON-02, US 9808 13405 8760 123 CHINAMOBILE-CN China Mobile Communication 8151 12687 3285 587 UNINET, MX 12479 7295 1711 149 UNI2-AS, ES 7545 6040 834 583 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 5027 4193 77 ERX-CERNET-BKB China Education and Resear 39891 4833 298 66 ALJAWWALSTC-AS, SA 22773 4779 3118 370 ASN-CXA-ALL-CCI-22773-RDC, US 11492 4687 311 949 CABLEONE, US 9498 4631 542 336 BBIL-AP BHARTI Airtel Ltd., IN Complete listing at https://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 9808 13405 13282 CHINAMOBILE-CN China Mobile Communications Grou 8151 12687 12100 UNINET, MX 12479 7295 7146 UNI2-AS, ES 7545 6040 5457 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 5027 4950 ERX-CERNET-BKB China Education and Research Net 39891 4833 4767 ALJAWWALSTC-AS, SA 22773 4779 4409 ASN-CXA-ALL-CCI-22773-RDC, US 9498 4631 4295 BBIL-AP BHARTI Airtel Ltd., IN 7552 4025 3997 VIETEL-AS-AP Viettel Group, VN 7155 3861 3776 VIASAT-SP-BACKBONE, US Complete listing at https://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Net Originated Transit AS Transit AS Name 393266 UNALLOCATED 8.23.52.0/24 46887 CROWNCASTLE-AS46887, US 396894 UNALLOCATED 8.28.201.0/24 3356 LEVEL3, US 394936 UNALLOCATED 8.33.224.0/24 22442 HOU-PHONOSCOPE, US 395195 UNALLOCATED 8.38.115.0/24 3356 LEVEL3, US 1782 UNALLOCATED 8.42.19.0/24 3356 LEVEL3, US 54739 UNALLOCATED 8.44.198.0/23 13335 CLOUDFLARENET, US 13342 UNALLOCATED 12.17.5.0/24 174 COGENT-174, US 26345 UNALLOCATED 12.21.93.0/24 40264 TWC-40264-WI-MN-UPPERMI 396831 UNALLOCATED 12.23.198.0/24 7018 ATT-INTERNET4, US 21861 UNALLOCATED 12.37.59.0/24 7018 ATT-INTERNET4, US Complete listing at https://thyme.apnic.net/current/data-badAS Prefixes from the Special Purpose Address Registry (Global) ----------------------------------------------------------- Prefix Origin AS Description 192.88.99.0/24 6939 HURRICANE, US Complete listing at https://thyme.apnic.net/current/data-spar Advertised Unallocated Addresses -------------------------------- Unassigned Network ASN Information AS Name 23.137.48.0/24 Origin: 16904 ARVIG-16904, US 23.137.48.0/24 Transit: 3257 GTT-BACKBONE GTT, US 23.137.200.0/24 Origin: 16276 OVH, FR 23.137.200.0/24 Transit: 2516 KDDI KDDI CORPORATION, JP 23.140.180.0/24 Origin: 401371 DEEP-TO-ONE-INC, US 23.140.180.0/24 Transit: 154309 INTELLIGENT1-AS-AP Intelligent Cloud Lim 23.140.216.0/24 Origin: 27176 DATAWAGON, US 23.140.216.0/24 Transit: 20278 NEXEON, US 23.141.0.0/24 Origin: 395350 RESERVED, ZZ 23.141.0.0/24 Transit: 11426 TWC-11426-CAROLINAS, US Complete listing at https://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:16 /9:14 /10:41 /11:93 /12:299 /13:579 /14:1199 /15:2096 /16:13704 /17:8294 /18:13584 /19:25046 /20:45643 /21:52666 /22:113548 /23:105849 /24:639742 /25:697 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 8151 6881 12687 UNINET, MX 12479 6226 7295 UNI2-AS, ES 11492 3532 4687 CABLEONE, US 39891 3521 4833 ALJAWWALSTC-AS, SA 6327 3478 3691 SHAW, CA 22773 3048 4779 ASN-CXA-ALL-CCI-22773-RDC, US 7155 2820 3861 VIASAT-SP-BACKBONE, US 16509 2455 14052 AMAZON-02, US 30036 2321 2664 MEDIACOM-ENTERPRISE-BUSINESS, US 10620 2213 3433 Telmex Colombia S.A., CO Complete listing at https://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1809 2:1525 3:978 4:10 5:4912 6:187 7:6 8:1522 9:10 11:172 12:1229 13:608 14:2651 15:416 16:290 17:387 18:912 20:587 21:4 22:188 23:8094 24:2561 25:2 27:2751 29:19 31:3393 32:32 33:1 34:81 35:290 36:4615 37:4532 38:10006 39:1209 40:440 41:4511 42:962 43:2839 44:413 45:19591 46:5094 47:396 49:2156 50:2057 51:598 52:1311 54:228 55:1105 56:11 57:305 58:2220 59:1398 60:1171 61:3063 62:3104 63:1741 64:5994 65:2124 66:5929 67:3235 68:1507 69:4191 70:1029 71:620 72:3077 74:2931 75:1506 76:600 77:2763 78:1921 79:1791 80:2313 81:2089 82:3894 83:1474 84:2022 85:3644 86:1101 87:2350 88:1360 89:4621 90:835 91:8435 92:2837 93:3017 94:4279 95:4561 96:1434 97:313 98:952 99:782 100:68 101:1268 102:4299 103:32247 104:5499 105:756 106:919 107:2815 108:1222 109:4242 110:2307 111:4040 112:2817 113:1676 114:2095 115:2243 116:2165 117:3151 118:2483 119:2095 120:2439 121:1562 122:2953 123:2288 124:1669 125:2948 126:125 128:1589 129:963 130:1543 131:2269 132:770 133:462 134:1639 135:538 136:1503 137:1281 138:3011 139:1595 140:1827 141:1567 142:2431 143:2127 144:1358 145:625 146:2191 147:2136 148:2780 149:2941 150:1315 151:2598 152:2263 153:798 154:9362 155:2274 156:4552 157:2236 158:1476 159:2730 160:3662 161:1995 162:3991 163:2332 164:1962 165:2623 166:1314 167:2193 168:3936 169:820 170:5442 171:1117 172:4529 173:3433 174:903 175:1344 176:3773 177:4742 178:4294 179:2291 180:2847 181:4350 182:3857 183:2434 184:2039 185:21675 186:5508 187:4771 188:4453 189:4489 190:9686 191:1538 192:11451 193:9520 194:7868 195:5638 196:3265 197:3193 198:6226 199:6113 200:8230 201:6404 202:10682 203:10498 204:4656 205:3760 206:4422 207:3959 208:4345 209:5521 210:4979 211:2777 212:4911 213:4040 214:1063 215:54 216:7110 217:3453 218:1659 219:581 220:2192 221:1291 222:916 223:3247 End of report

1 0

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