January 2026 - NANOG - lists.nanog.org

Weird routing pattern - Atlanta device hitting Argentine ISP + unknown EU endpoint
by Intergalactic Auditor 18 Jan '26

18 Jan '26

Hey NANOG, Seeing some odd routing from an Atlanta device that seems to lack logic to say the least. Thought I'd shed some light on it.... Expected: Apple infrastructure (17.x.x.x) Actual destinations: - 109.1.2.1 (SFR France, INFRA-SBT, abuse(a)gaoland.net) - 200.3.10.2 (INTERWEB-DAIREAUX Argentina, 200.3.10.0/23) - 67.1.2.1 (CenturyLink) - 184.0.0.13 (CenturyLink) - 136.3.5.1 (AWS) Pattern: TLS 1.3, 02:00-03:30 local, multiple clients Geographic spread makes no sense (EU + small Argentine ISP from US). Possible C2/exfil. Worth checking your flows for 109.1.0.0/17 and 200.3.10.0/23 from non-EU/LACNIC sources. - Joseph II

2 3

ISP Operators AISURU/Kimwolf botnet
by Corey Smith 18 Jan '26

18 Jan '26

I would appreciate if any ISP Operators could help some of the smaller ISP like us in stopping the traffic from these new Malware infected customers that have devices with Aisiura/Kimwolf botnet, These are Residential Proxies for the most part, but hard to stop. Any help would be greatly appreciated.

15 28

Converting IPFIX flows to columnar format with all IEs - tool recommendations?
by Jonas Muecke 17 Jan '26

17 Jan '26

Hi, I'm looking for recommendations on conversion and long-term storage of raw IPFIX flow data. Specifically, I need to convert IPFIX flows stored in pcap files into a columnar format like Parquet to enable easy and detailed historic analysis that isn't possible with aggregated data. Requirements: - Parse IPFIX from pcap files (including templates) - Preserve ALL information elements, including custom IEs with enterprise PENs - Output enterprise number + IE ID + data (detailed interpretation of the data not needed) - Handle IP fragment reassembly or large IP packets nfdump [1] gets close, but it skips custom IEs. Other tools require replaying the pcaps which risks overflowing buffers, so reading directly from pcap files would be preferred. Has anyone had similar requirements and found a solution? I'm open to multi-step conversions (e.g., via JSON). Long-term I'll capture directly to a better format, but need to process existing pcap archives first. Thanks, Jonas [1] https://github.com/phaag/nfdump -- Jonas Muecke Phd Student, TU Dresden

3 3

Re: ISP Operators AISURU/Kimwolf botnet
by Tom Beecher 17 Jan '26

17 Jan '26

Mike- Should we hold the consumers responsible for their lack of tech knowhow > when corporations with actual ITSEC departments get owned all the time or > is that a total abrogation of responsibility from the people who are taking > the money to provide the service or hardware? So your position here is : Since corporate security folks can't catch everything, end users shouldn't be held responsible for doing anything themselves, and their ISPs should do it? ( Except isn't the ISP the corporate security folks you just said can't catch everything? ) On Sat, Jan 17, 2026 at 12:09 PM Mike Simpson <mikie.simpson(a)gmail.com> wrote: > So where are they getting the malware from if not from their ISP? > > Should we hold the consumers responsible for their lack of tech knowhow > when corporations with actual ITSEC departments get owned all the time or > is that a total abrogation of responsibility from the people who are taking > the money to provide the service or hardware? > > I think the “we aren’t responsible for anything that comes down the pipe > to the end users because doing otherwise will cost $$$ and impact our > revenue” is a stance that shouldn’t hold true anymore. > > I wonder how clearly you advertise the fact in your sales literature that > a user needs to have more technical security knowhow or needs to care more > than fortinet to safely connect to your network. > > That combined with all the reasons why having your users being infested is > bad for you should make you want to do more about it. Being a diseased > network spewing infection is surely seen as bad practice and “it’s the > fault of the users and there is nothing we are willing to do to change > that” shouldn’t be adequate. > > > > On 17 Jan 2026, at 16:26, Tom Beecher <beecher(a)beecher.cc> wrote: > > > >> If you didn’t want your customers being infected then don’t serve them >> malware and then blame them for getting owned and it impacting on your >> network or your upstreams. > > > ISPs aren't 'serving customers malware'. Come on. > > There is a shared responsibility here. ISPs need to take reasonable > precautions to block bad, while also ensuring that users can use the access > they provide in the ways they chose to do so. End users need to have a > basic level of understanding that the 'naked' internet is a nasty place, > and many network enabled devices are poorly designed, so having some level > of network security is important. > > > > On Sat, Jan 17, 2026 at 9:23 AM Mike Simpson via NANOG < > nanog(a)lists.nanog.org> wrote: > >> Again tho. >> What does it matter to the customer. It’s not impacting on their bottom >> line. They are used to fairly rubbish service for a huge multitude of >> reasons so their bandwidth being a bit slashdotted doesn’t matter to them. >> That’s why it’s a ddos. >> >> The only reason they got infected wasn’t their fault. It’s the fault of >> every company that believes that a eula is the end of their liability. >> >> If you didn’t want your customers being infected then don’t serve them >> malware and then blame them for getting owned and it impacting on your >> network or your upstreams. >> >> This is something that should have been sorted out after nimda but that >> wouldn’t have boosted shareholder value apparently. >> >> Your users aren’t aware that it’s not safe to plug stuff into the network >> you provide in the same way that they would expect a firewall not to get >> them owned or that a VPN device would be safe to use. >> >> -this is our fault, our failing, and we need to stop our knee jerk victim >> shaming and do better. >> >> > On 17 Jan 2026, at 12:49, Mel Beckman <mel(a)beckman.org> wrote: >> > >> > Mike, >> > >> > I agree with you where ISPs choose insecure CPE and force their >> customers to use it. But in the case of AISURU, It’s not the CPE causing >> the problem, it’s the customer’s buggy android-based IoT. >> > >> > -mel >> > >> >> On Jan 17, 2026, at 4:16 AM, Mike Simpson <mikie.simpson(a)gmail.com> >> wrote: >> >> >> >> “immediately recognize any they own, which will drive home the point >> that this is their problem” >> >> >> >> That’s some grade A victim blaming bs there. >> >> >> >> “The rubbish CPE that we forced you to have is now owned and it’s >> upsetting our eyeballs only peering arrangements so you need to sort it out” >> >> >> >> ISPs are only not accountable legally for the content of the packets >> they transport. That doesn’t mean they are not responsible for the terrible >> routers they give out. >> >> >> >> Your customers in the main don’t care as they are used to flaky >> internet service. It’s the problem of the ISP as it only really impacts on >> them in an aggregated form so as that’s where the pain is, that’s who is >> “it” for solving it. >> >> >> >> -don’t hand out cheap pos un-updatable CPE or do (shareholder value/ >> enshittification) and accept the consequences with good grace. >> >> >> >> >> >> >> >>>> On 17 Jan 2026, at 02:10, Mel Beckman via NANOG < >> nanog(a)lists.nanog.org> wrote: >> >>> >> >>> immediately recognize any they own, which will drive home the point >> that this is their problem >> _______________________________________________ >> NANOG mailing list >> >> https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SAEZI4V… > >

1 0

Re: ISP Operators AISURU/Kimwolf botnet
by Mel Beckman 17 Jan '26

17 Jan '26

“Where did I get the bad tacos from if not the cab driver?” You are being willfully ignorant now. Have a good day. -mel via cell On Jan 17, 2026, at 9:09 AM, Mike Simpson <mikie.simpson(a)gmail.com> wrote: So where are they getting the malware from if not from their ISP? Should we hold the consumers responsible for their lack of tech knowhow when corporations with actual ITSEC departments get owned all the time or is that a total abrogation of responsibility from the people who are taking the money to provide the service or hardware? I think the “we aren’t responsible for anything that comes down the pipe to the end users because doing otherwise will cost $$$ and impact our revenue” is a stance that shouldn’t hold true anymore. I wonder how clearly you advertise the fact in your sales literature that a user needs to have more technical security knowhow or needs to care more than fortinet to safely connect to your network. That combined with all the reasons why having your users being infested is bad for you should make you want to do more about it. Being a diseased network spewing infection is surely seen as bad practice and “it’s the fault of the users and there is nothing we are willing to do to change that” shouldn’t be adequate. On 17 Jan 2026, at 16:26, Tom Beecher <beecher(a)beecher.cc> wrote: If you didn’t want your customers being infected then don’t serve them malware and then blame them for getting owned and it impacting on your network or your upstreams. ISPs aren't 'serving customers malware'. Come on. There is a shared responsibility here. ISPs need to take reasonable precautions to block bad, while also ensuring that users can use the access they provide in the ways they chose to do so. End users need to have a basic level of understanding that the 'naked' internet is a nasty place, and many network enabled devices are poorly designed, so having some level of network security is important. On Sat, Jan 17, 2026 at 9:23 AM Mike Simpson via NANOG <nanog(a)lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: Again tho. What does it matter to the customer. It’s not impacting on their bottom line. They are used to fairly rubbish service for a huge multitude of reasons so their bandwidth being a bit slashdotted doesn’t matter to them. That’s why it’s a ddos. The only reason they got infected wasn’t their fault. It’s the fault of every company that believes that a eula is the end of their liability. If you didn’t want your customers being infected then don’t serve them malware and then blame them for getting owned and it impacting on your network or your upstreams. This is something that should have been sorted out after nimda but that wouldn’t have boosted shareholder value apparently. Your users aren’t aware that it’s not safe to plug stuff into the network you provide in the same way that they would expect a firewall not to get them owned or that a VPN device would be safe to use. -this is our fault, our failing, and we need to stop our knee jerk victim shaming and do better. > On 17 Jan 2026, at 12:49, Mel Beckman <mel(a)beckman.org<mailto:mel@beckman.org>> wrote: > > Mike, > > I agree with you where ISPs choose insecure CPE and force their customers to use it. But in the case of AISURU, It’s not the CPE causing the problem, it’s the customer’s buggy android-based IoT. > > -mel > >> On Jan 17, 2026, at 4:16 AM, Mike Simpson <mikie.simpson(a)gmail.com<mailto:mikie.simpson@gmail.com>> wrote: >> >> “immediately recognize any they own, which will drive home the point that this is their problem” >> >> That’s some grade A victim blaming bs there. >> >> “The rubbish CPE that we forced you to have is now owned and it’s upsetting our eyeballs only peering arrangements so you need to sort it out” >> >> ISPs are only not accountable legally for the content of the packets they transport. That doesn’t mean they are not responsible for the terrible routers they give out. >> >> Your customers in the main don’t care as they are used to flaky internet service. It’s the problem of the ISP as it only really impacts on them in an aggregated form so as that’s where the pain is, that’s who is “it” for solving it. >> >> -don’t hand out cheap pos un-updatable CPE or do (shareholder value/ enshittification) and accept the consequences with good grace. >> >> >> >>>> On 17 Jan 2026, at 02:10, Mel Beckman via NANOG <nanog(a)lists.nanog.org<mailto:nanog@lists.nanog.org>> wrote: >>> >>> immediately recognize any they own, which will drive home the point that this is their problem _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SAEZI4V…

1 0

Snapdragon X65 baseband buffer overflow - potential for mass device DoS
by Intergalactic Auditor 17 Jan '26

17 Jan '26

Disclosing for the NOCs at war everyday. Buffer overflow in Qualcomm X65 baseband Issue: SDM state transition → unchecked array index → baseband deadlock → forced reboot Timeline: 9ms to error, 2.3s to crash Trigger: Potentially via 5G/satellite signal Observed events: 2026-01-10, 01-11, 01-14 ~06:00 EST Monitor for: - Clustered device crash reports in narrow time window - "No Service" complaints with normal network metrics - Baseband watchdog resets (rst wdog) Technical: https://github.com/0verdu/X65_BufferOverflow Contact: Keybase: justthemessenger

1 1

Agenda is Published! ** [Video] Experience a NANOG Conference + Q+A with Meta's Omar Baldonado
by Nanog News 16 Jan '26

16 Jan '26

*** NANOG 96 Agenda is Published!* ------------------------------------------------------------ *Sync Your Calendars Now and Never Miss a Talk!* The full NANOG 96 agenda is live. Explore speakers and session abstracts, then view, download, or sync it straight to your calendar. *LEARN MORE* (https://nanog.org/events/nanog-96/agenda/) *** [Video] Experience a NANOG Conference* ------------------------------------------------------------ *See What all the Fuss is About: Watch Highlights, Hear from Attendees + More* You might see yourself in this video! Watch moments from NANOG 95: the Women in Tech “Superstar” event, the NANOG Social at Six Flags Over Texas, and real hallway conversations. Hear it straight from attendees and see what sets NANOG apart. Feeling the FOMO? Register Now for N96! ( https://nanog.org/events/nanog-96/register/) Same unscripted conversations, real breakthroughs, and technical depth you can’t fake or sell. *Trying to explain NANOG to a friend?* Send them this video. ( https://www.youtube.com/watch?v=Xh9Vfdv7N7Q&list=PLO8DR5ZGla8hP_Yyt5cz9o7xP… ) *WATCH NOW* (https://nanog.org/stories/nanog-tv/nanog-95-recap/) *** Inside a N96 Keynote: Q+A with Meta's Omar Baldonado* ------------------------------------------------------------ *When AI Hits the Network: What Meta Learned the Hard Way* NANOG recently caught up with Baldonado for a closer look at his upcoming Keynote “AI Data Center Networking: Lessons from Meta’s Evolution.” Attendees can expect a candid look at Meta’s evolution, from early design assumptions that turned out to be the most wrong, to the cultural shifts required when “everything that isn't a GPU-local error appears to be a network error.” Check out the interview and then show up ready with your own questions. *LEARN MORE *( https://nanog.org/stories/articles/when-ai-hits-the-network-what-meta-learn… ) *** Don’t Miss the Community IXP BoF (Birds of a Feather) at N96!* ------------------------------------------------------------ If You Run a Community Internet Exchange Point (IXP) or Curious About Starting One —You Need to be Here! We’ll swap stories, share lessons learned, and talk about what’s working (and what we wish we’d known) in building successful IXPs. Commercial IXPs are welcome to join the BoF, but the focus will be on building up community-based IXPs. Have a great BoF idea for a future meeting? Submit it below. *SUBMIT NOW* (https://nanog.org/program/call-presentations/) *** 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 16 Jan '26

16 Jan '26

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 17 Jan, 2026 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: 1027408 Prefixes after maximum aggregation (per Origin AS): 395533 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 507103 Number of IPv4 prefixes with a valid ROA: 606326 Number of IPv4 prefixes with an invalid ROA: 1620 Number of IPv4 prefixes with no ROA: 419462 Total ASes present in the Internet Routing Table: 77778 Prefixes per ASN: 13.21 Origin-only ASes present in the Internet Routing Table: 66853 Origin ASes announcing only one prefix: 27183 Transit ASes present in the Internet Routing Table: 10925 Transit-only ASes present in the Internet Routing Table: 554 Average AS path length visible in the Internet Routing Table: 4.7 Max AS path length visible: 209 Max AS path prepend of ASN (214570) 200 Prefixes from unregistered ASNs in the Routing Table: 1008 Number of instances of unregistered ASNs: 1048 Number of 32-bit ASNs allocated by the RIRs: 48411 Number of 32-bit ASNs visible in the Routing Table: 39655 Prefixes from 32-bit ASNs in the Routing Table: 220359 Number of bogon 32-bit ASNs visible in the Routing Table: 111 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 480 Number of addresses announced to Internet: 3106815104 Equivalent to 185 /8s, 46 /16s and 60 /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: 335174 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 280325 Total APNIC prefixes after maximum aggregation: 82184 APNIC Deaggregation factor: 3.41 Prefixes being announced from the APNIC address blocks: 266966 Unique aggregates announced from the APNIC address blocks: 106793 APNIC Region origin ASes present in the Internet Routing Table: 15015 APNIC Prefixes per ASN: 17.78 APNIC Region origin ASes announcing only one prefix: 4597 APNIC Region transit ASes present in the Internet Routing Table: 1981 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 35 Number of APNIC region 32-bit ASNs visible in the Routing Table: 10568 Number of APNIC addresses announced to Internet: 754743808 Equivalent to 44 /8s, 252 /16s and 122 /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: 301293 Total ARIN prefixes after maximum aggregation: 135129 ARIN Deaggregation factor: 2.23 Prefixes being announced from the ARIN address blocks: 301255 Unique aggregates announced from the ARIN address blocks: 146080 ARIN Region origin ASes present in the Internet Routing Table: 19393 ARIN Prefixes per ASN: 15.53 ARIN Region origin ASes announcing only one prefix: 7066 ARIN Region transit ASes present in the Internet Routing Table: 1923 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: 5446 Number of ARIN addresses announced to Internet: 1344401664 Equivalent to 80 /8s, 33 /16s and 241 /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: 282507 Total RIPE prefixes after maximum aggregation: 139963 RIPE Deaggregation factor: 2.02 Prefixes being announced from the RIPE address blocks: 284173 Unique aggregates announced from the RIPE address blocks: 184586 RIPE Region origin ASes present in the Internet Routing Table: 29121 RIPE Prefixes per ASN: 9.76 RIPE Region origin ASes announcing only one prefix: 12096 RIPE Region transit ASes present in the Internet Routing Table: 3951 Average RIPE Region AS path length visible: 4.8 Max RIPE Region AS path length visible: 209 Number of RIPE region 32-bit ASNs visible in the Routing Table: 12920 Number of RIPE addresses announced to Internet: 733572480 Equivalent to 43 /8s, 185 /16s and 109 /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: 125985 Total LACNIC prefixes after maximum aggregation: 30632 LACNIC Deaggregation factor: 4.11 Prefixes being announced from the LACNIC address blocks: 121805 Unique aggregates announced from the LACNIC address blocks: 49768 LACNIC Region origin ASes present in the Internet Routing Table: 11346 LACNIC Prefixes per ASN: 10.74 LACNIC Region origin ASes announcing only one prefix: 2678 LACNIC Region transit ASes present in the Internet Routing Table: 2517 Average LACNIC Region AS path length visible: 5.4 Max LACNIC Region AS path length visible: 69 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 9344 Number of LACNIC addresses announced to Internet: 170560768 Equivalent to 10 /8s, 42 /16s and 141 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-275868 + 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: 36290 Total AfriNIC prefixes after maximum aggregation: 6936 AfriNIC Deaggregation factor: 5.23 Prefixes being announced from the AfriNIC address blocks: 52729 Unique aggregates announced from the AfriNIC address blocks: 19471 AfriNIC Region origin ASes present in the Internet Routing Table: 2011 AfriNIC Prefixes per ASN: 26.22 AfriNIC Region origin ASes announcing only one prefix: 746 AfriNIC Region transit ASes present in the Internet Routing Table: 383 Average AfriNIC Region AS path length visible: 5.3 Max AfriNIC Region AS path length visible: 42 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 1377 Number of AfriNIC addresses announced to Internet: 103249408 Equivalent to 6 /8s, 39 /16s and 118 /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 13584 8945 102 CHINAMOBILE-CN China Mobile Communication 7545 6029 833 575 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 5024 4193 77 ERX-CERNET-BKB China Education and Resear 9498 4695 543 340 BBIL-AP BHARTI Airtel Ltd., IN 7552 4052 1332 29 VIETEL-AS-AP Viettel Group, VN 7713 3731 1044 65 TELKOMNET-AS-AP PT Telekomunikasi Indones 56046 3417 831 184 CMNET-JIANGSU-AP China Mobile communicati 45899 3332 1868 98 VNPT-AS-VN VNPT Corp, VN 24560 2965 865 502 AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., 17561 2804 176 556 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 14148 38738 5435 AMAZON-02, US 22773 4779 3116 367 ASN-CXA-ALL-CCI-22773-RDC, US 11492 4635 308 1031 CABLEONE, US 7155 3861 286 85 VIASAT-SP-BACKBONE, US 6327 3698 1321 70 SHAW, CA 396982 3324 4867 495 GOOGLE-CLOUD-PLATFORM, US 174 3213 8768 839 COGENT-174, US 749 3144 54729 2395 DNIC-AS-00749, US 16625 2820 1209 2120 AKAMAI-AS, US 36352 2703 222 889 AS-COLOCROSSING, 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 7242 1711 149 UNI2-AS, ES 39891 4969 306 72 ALJAWWALSTC-AS, SA 9009 3907 365 2233 M247, RO 20940 3832 3393 111 AKAMAI-ASN1, NL 12389 3175 2317 871 ROSTELECOM-AS PJSC Rostelecom. Technical 212238 2567 182 1864 CDNEXT, GB 34984 2425 372 577 TELLCOM-AS, TR 8452 1713 1852 14 TE-AS TE-AS, EG 203020 1625 243 800 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 12669 3300 603 UNINET, MX 10620 3433 457 1107 Telmex Colombia S.A., CO 13999 2486 508 350 Mega Cable, S.A. de C.V., MX 11830 1991 369 65 Instituto Costarricense de Electricidad y 28573 1380 2432 268 Claro NXT Telecomunicacoes Ltda, BR 11664 1357 278 33 Techtel LMDS Comunicaciones Interactivas 3816 1339 770 213 COLOMBIA TELECOMUNICACIONES S.A. ESP BIC, 6147 1256 371 22 Telefonica del Peru S.A.A., PE 22884 1057 67 358 TOTAL PLAY TELECOMUNICACIONES SA DE CV, M 26615 1012 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 1982 638 33 RAYA-AS, EG 36992 1850 1534 342 ETISALAT-MISR, EG 24863 1279 389 16 LINKdotNET-AS, EG 36903 1232 555 98 MT-MPLS, MA 36935 1146 524 47 Vodafone-, EG 37069 1101 1096 13 MOBINIL, EG 29571 1070 78 20 ORANGE-COTE-IVOIRE, CI 20011 580 154 212 NTT-DATA-Inc, ZA 36914 576 82 3 KENET-AS, KE 328608 572 49 166 Africa-on-Cloud-AS, ZA 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 14148 38738 5435 AMAZON-02, US 9808 13584 8945 102 CHINAMOBILE-CN China Mobile Communication 8151 12669 3300 603 UNINET, MX 12479 7242 1711 149 UNI2-AS, ES 7545 6029 833 575 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 5024 4193 77 ERX-CERNET-BKB China Education and Resear 39891 4969 306 72 ALJAWWALSTC-AS, SA 22773 4779 3116 367 ASN-CXA-ALL-CCI-22773-RDC, US 9498 4695 543 340 BBIL-AP BHARTI Airtel Ltd., IN 11492 4635 308 1031 CABLEONE, US Complete listing at https://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 9808 13584 13482 CHINAMOBILE-CN China Mobile Communications Grou 8151 12669 12066 UNINET, MX 12479 7242 7093 UNI2-AS, ES 7545 6029 5454 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 5024 4947 ERX-CERNET-BKB China Education and Research Net 39891 4969 4897 ALJAWWALSTC-AS, SA 22773 4779 4412 ASN-CXA-ALL-CCI-22773-RDC, US 9498 4695 4355 BBIL-AP BHARTI Airtel Ltd., IN 7552 4052 4023 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 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 395476 UNALLOCATED 12.36.194.0/24 7018 ATT-INTERNET4, US 395476 UNALLOCATED 12.36.195.0/24 3356 LEVEL3, 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.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 23.142.24.0/24 Origin: 62164 HEYMMAN-2, CA 23.142.24.0/24 Transit: 64236 UNREAL-SERVERS, 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:40 /11:93 /12:302 /13:580 /14:1199 /15:2091 /16:13723 /17:8314 /18:13577 /19:25083 /20:45600 /21:52658 /22:113780 /23:106304 /24:643339 /25:695 /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 6850 12669 UNINET, MX 12479 6173 7242 UNI2-AS, ES 39891 3655 4969 ALJAWWALSTC-AS, SA 11492 3497 4635 CABLEONE, US 6327 3479 3698 SHAW, CA 22773 3050 4779 ASN-CXA-ALL-CCI-22773-RDC, US 7155 2820 3861 VIASAT-SP-BACKBONE, US 16509 2496 14148 AMAZON-02, US 30036 2318 2660 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:1829 2:1497 3:978 4:9 5:4967 6:185 7:6 8:1521 9:14 11:172 12:1226 13:625 14:2677 15:419 16:275 17:390 18:917 20:595 21:4 22:188 23:8146 24:2626 25:2 27:2751 29:19 31:3413 32:32 34:81 35:293 36:4629 37:4523 38:9891 39:1248 40:439 41:4511 42:957 43:2921 44:414 45:19655 46:4934 47:397 49:2158 50:2059 51:599 52:1254 54:235 55:1115 56:11 57:311 58:2225 59:1424 60:1172 61:3098 62:3112 63:1771 64:6168 65:2141 66:6008 67:3259 68:1494 69:4218 70:1031 71:619 72:3066 74:2949 75:1514 76:609 77:2756 78:1938 79:1796 80:2307 81:2088 82:4014 83:1479 84:2025 85:3677 86:1096 87:2356 88:1355 89:4621 90:827 91:8408 92:2862 93:3010 94:4279 95:4527 96:1444 97:314 98:956 99:783 100:69 101:1510 102:4348 103:32368 104:5438 105:768 106:909 107:2824 108:1229 109:4229 110:2310 111:4115 112:3083 113:1698 114:2171 115:2238 116:2166 117:3285 118:2482 119:2110 120:2611 121:1571 122:2974 123:2305 124:1679 125:2978 126:125 128:1590 129:965 130:1558 131:2287 132:762 133:461 134:1629 135:534 136:1628 137:1291 138:2989 139:1600 140:1821 141:1562 142:2472 143:2138 144:1543 145:631 146:2201 147:2272 148:2816 149:2911 150:1314 151:2599 152:2256 153:846 154:9538 155:2270 156:4443 157:2235 158:1493 159:2744 160:3647 161:1998 162:4000 163:2329 164:1969 165:2641 166:1308 167:2193 168:3937 169:847 170:5444 171:1117 172:4548 173:3435 174:895 175:1346 176:3773 177:4731 178:4254 179:2294 180:2988 181:4359 182:3887 183:2532 184:2036 185:21686 186:5520 187:4816 188:4606 189:4488 190:9663 191:1534 192:11468 193:9497 194:7847 195:5696 196:3257 197:3205 198:6257 199:6129 200:8202 201:6381 202:10821 203:10541 204:4700 205:3759 206:4414 207:3973 208:4375 209:5502 210:4999 211:2782 212:4973 213:4046 214:1068 215:54 216:7141 217:3463 218:1675 219:591 220:2191 221:1311 222:1018 223:3276 End of report

1 0

frr mailing list
by Randy Bush 16 Jan '26

16 Jan '26

anyone know wazzuo with the frr ops' mailing list, frog(a)lists.frrouting.org? sending, i get Remote-MTA: dns; lists.frrouting.org Diagnostic-Code: smtp; 550 unknown user and the archive, has nothing in it since novemmber randy

7 10

Exploring EVPL / NNI redundancy options
by Mark Blackford 16 Jan '26

16 Jan '26

Does anyone have experience implementing redundancy on their EVPL services within the same carrier? For instance, I have many point-to-point scenarios using EVPL providers to connect sites to Dallas. I’m looking to add a new pop in Atlanta this year for expansion and redundancy. It seems possible to have a “Site A” with a current drop off NNI in Dallas added to the new POP on Atlanta within the same carrier network for data center redundancy, but I am not sure how practical that is in terms of cost and implementation. Latency would vary of course, and I am assuming they give you a different VLAN (but maybe not?). I welcome any comments like if this is a good idea or not, what carriers I should consider, and experience with cost. Thanks in advance! Mark Blackford

3 4