- NANOG - lists.nanog.org

Microsoft contact - emails being blocked from our app to our users
by Erik Levinson 21 Jan '26

21 Jan '26

Hello, does anyone have a Microsoft contact that could help with an email deliverability issue that started approximately two days ago? We (LeapAP) are seeing a large and increasing volume of mail errors from Microsoft, such as the below (XXXX is our dedicated IP at our ESP) and are unable to deliver mail to our users with the following destination domains (so it seems like the hosted Office 365 domains aren't impacted, but only the free/Outlook.com ones): hotmail.com hotmail.ca live.ca msn.com outlook.com live.com 4.7.650 The mail server [XXXX] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https://aka.ms/postmaster (S775) SNDS shows nothing abnormal for the IP address during the involved time period or earlier, but I can only see up to yesterday @ 18:00 PT there. We submitted the Microsoft form at https://olcsupport.office.com/ and have a ticket number as a result, which I can share as well. Appreciate the help as we're quite impacted and getting a lot of support tickets. Thanks Erik Levinson LeapAP

1 0

Apply Today for the ARIN 57 Fellowship Program
by John Sweeting 21 Jan '26

21 Jan '26

Hello NANOG, Please see the announcement below referencing ARIN's Fellowship Program. ________________________________ From: ARIN-announce <arin-announce-bounces(a)arin.net> on behalf of ARIN <info(a)arin.net> Sent: Thursday, January 8, 2026 10:26 AM To: arin-announce(a)arin.net Subject: Apply Today for the ARIN 57 Fellowship Program Interested in Internet governance, number resource policy, and getting involved in the ARIN community? Become an ARIN Fellow! Applications for the ARIN 57 Fellowship Program are now open, and we encourage you to apply for this specialized, interactive learning opportunity. https://www.arin.net/beafellow Applications are now being accepted through 26 January 2026.  What to Expect Selected Fellows will participate in virtual sessions before and after the ARIN 57 Public Policy and Members Meeting held 19-22 April 2026 in Louisville, Kentucky, and online. Fellows may attend ARIN 57 either in person or virtually, as determined by the Fellowship Selection Committee. With the personal support from experienced ARIN community Mentors, Fellows will have the opportunity to: - Ask questions and receive feedback, - Gain the knowledge and confidence to join in community discussions and contribute new ideas, and - Become part of the future of Internet governance and policy in the ARIN region.  Who Should Apply Individuals who are 18 years of age or older and reside in the ARIN region (https://www.arin.net/about/welcome/region/) are eligible to apply if they have a demonstrated interest in the ARIN community and its Policy Development Process for the management of Internet number resources.   Applicants should understand the importance of ARIN’s mission and be familiar with ARIN services, the Internet number resources it manages, and the processes reflected in the Number Resource Policy Manual (NRPM) (https://www.arin.net/participate/policy/nrpm/)   To learn more about ARIN’s Fellowship Program, the selection process, and the Terms and Conditions, please visit ARIN’s Fellowship Program portal (https://www.arin.net/fellowships) Applicants can email fellowships(a)arin.net<mailto:fellowships@arin.net> for more information or to request a customizable letter to their employer that highlights the benefits of taking part in ARIN’s Fellowship Program.  ARIN looks forward to receiving your application soon!  Regards,  Amanda Gauldin Senior Project Manager American Registry for Internet Numbers (ARIN)

1 0

pingability of 2600::
by Marco Moock 20 Jan '26

20 Jan '26

Hello! Cogent operates a machine on 2600::. IIRC there was also a route to sprint for that net, but that seems to be gone. I can ping that via my ISP (AS8820) that uses Cogent as its current default uplink. Although, I cannot ping that from various other ISPs, e.g. HE AS6939 or DTAG 3320 (no route). Some other people reported issues years ago: https://www.reddit.com/r/ipv6/comments/1bzfqzn/2600_is_no_longer_pingable/ Do some people know more about that case? -- kind regards Marco Send unsolicited bulk mail to 1768504259muell(a)stinkedores.dorfdsl.de

5 8

New c-nsp, j-nsp, a-nsp, etc mailing lists
by Drew Weaver 20 Jan '26

20 Jan '26

I was a big fan of the *-nsp(a)puck.nether.net<mailto:*-nsp@puck.nether.net> mailing lists that now seem to be completely gone without any indication of whether or when they might return. I've been considering just setting up new ones. Please email me off-list if you think this might be useful. Thanks, -Drew

15 25

TORNOG 1 -- Call for Proposals
by Mark Prosser 20 Jan '26

20 Jan '26

Hello NANOG community, Our little community NOG, here in Toronto, is growing. This year we are hosting our first ever full day conference on April 13th, 2026. We would like to welcome folks from far & wide to submit proposals and bring content to operators within our region. The Proposal window opened today. It will be open until EOD (23:59:59 EDT) on March 6th, 2026. We are looking for technical or "meta" talks on networking, automation, and observability. Yet, we also welcome our infrastructure peers to discuss their perspectives on the network. Talks can be 10 minutes, 30 minutes, or 45 minutes in length (technical tutorial / deep dives). Please provide your abstract, speaker bio (optional), and preferred talk length. Slides are not required but appreciated. The theme of TORNOG 1 is: "Stories from Regional Operators" Talks that will be regional to the Toronto / Ontario area will be highly considered. But we would also consider other regional stories from across Canada, and beyond, that consider their story useful to operators in the Toronto area. However, this is just a theme. Talks on any subject, that are not marketing focused, will be considered. Some topics to consider: - Network Automation - Observability & Telemetry - Network Security - Cloud Networking - Career Development in Networking - Diversity & Inclusion in Tech - Emerging Technologies in Networking - Segment Routing / Traffic Engineering - AI & Machine Learning in Networking - Case Studies / Postmortems Please sends you talks to talks(a)tornog.ca or follow the link at: https://tornog.ca/events/tornog-1/proposals/ I wish you all a wonderful 2026, full of peace & prosperity. We are also looking for Sponsors for TORNOG 1. Please reach out to us at sponsors(a)tornog.ca to receive details on our propspectus. We would also appreciate proposals from organizations willing to collaborate with us on workshops -- free with base ticket purchase -- on April 14th, 2026. We hope this would add value for operators traveling into Toronto or clearing their calendar to participate in our community. Some of the TORNOG team will be at NANOG96, if you'd like to learn more over a beer or an in-N-out burger. In solidarity, Mark Prosser Designated TORNOG Lead & Network Operator Advocate /* P.S. -- I have used my BDFL powers to price our tickets at a level I believe is accessible to operators from many walks of life; however, if you feel you the price is out of reach for you, please do not hesitate to reach out & I will do my best to make an accommodation for you. */

1 0

Optimizing Singapore peering?
by Landy Bible 19 Jan '26

19 Jan '26

Hey NANOG, I realize this is "NA" NOG list, but I assume I'm not the only one here who is operating a global network. Context: we have a dozen or so PoPs around the world to serve our load balancer product. We're using continent-specific prefixes to run anycast for this. We are on at least one IX at each location, and use Cogent as our primary transit provider. We'd like to add a real Tier 1 provider at each pop in the future, but In general, this all works ok right now. However, Singapore is a problem. We're on SGIX, but we're seeing a rather high percentage of traffic that originates in Singapore entering our Tokyo PoP instead. Google Cloud in particular is REALLY bad, with application latency testing approaching nearly 1 second, when our typical global latency is under 100ms on an end to end test. Other SG clouds are bad, but not THAT bad. My question to the list here is... for those of you who also operate in Singapore... what would you suggest we do to improve things here? We're looking at adding Arelion or NTT transit in APAC, but we're also trying to get PNIs (or even full IP transit) to the big Singapore networks like SingTel, SingNet, and StarHub, but we haven't had any luck yet. Perhaps we just don't know the right people. From a business perspective our primary concern is latency for our big customers who are hosted on the clouds in the area, but I don't want to just ignore our other customers who aren't in the cloud. Based on my research thus far, my gut says getting transit from Arelion is probably my best "bang for buck" move, but I'm wondering if any of you have any insights or wisdom to share about Singapore or APAC in general. Thanks All, Landy AS62902

6 5

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