Archive

Category Archives for "Networking"

Do You Need IS-IS Areas?

TL&DR: Most probably not, but if you do, you’d better not rely on random blogs for professional advice #justSaying 😜

Here’s an interesting question I got from a reader in the midst of an OSPF-to-IS-IS migration:

Why should one bother with different [IS-IS] areas when the routing hierarchy is induced by the two levels and the appropriate IS-IS circuit types on the links between the routers?

Well, if you think you need a routing hierarchy, you’re bound to use IS-IS areas because that’s how the routing hierarchy is implemented in IS-IS. However…

What came first: the CNAME or the A record?

On January 8, 2026, a routine update to 1.1.1.1 aimed at reducing memory usage accidentally triggered a wave of DNS resolution failures for users across the Internet. The root cause wasn't an attack or an outage, but a subtle shift in the order of records within our DNS responses.

While most modern software treats the order of records in DNS responses as irrelevant, we discovered that some implementations expect CNAME records to appear before everything else. When that order changed, resolution started failing. This post explores the code change that caused the shift, why it broke specific DNS clients, and the 40-year-old protocol ambiguity that makes the "correct" order of a DNS response difficult to define.

Timeline

All timestamps referenced are in Coordinated Universal Time (UTC).

Time

Description

2025-12-02

The record reordering is introduced to the 1.1.1.1 codebase

2025-12-10

The change is released to our testing environment

2026-01-07 23:48

A global release containing the change starts

2026-01-08 17:40

The release reaches 90% of servers

2026-01-08 18:19

Incident is declared

2026-01-08 18:27

The release is reverted

2026-01-08 19:55

Revert is completed. Impact ends

What happened?

While making some improvements to lower the memory usage of Continue reading

By Decade’s End, AI Will Drive More Than Half Of All Chip Sales

As the year came to an end, we tore apart IDC’s assessments for server spending, including the huge jump in accelerated supercomputers for running GenAI and more traditional machine learning workloads and as this year got started, we did forensic analysis and modeling based on the company’s reckoning of Ethernet switching and routing revenues.

By Decade’s End, AI Will Drive More Than Half Of All Chip Sales was written by Timothy Prickett Morgan at The Next Platform.

From IPVS to NFTables: A Migration Guide for Kubernetes v1.35

Kubernetes Networking Is Changing

Kubernetes v1.35 marks an important turning point for cluster networking. The IPVS backend for kube-proxy has been officially deprecated, and future Kubernetes releases will remove it entirely. If your clusters still rely on IPVS, the clock is now very much ticking.

Staying on IPVS is not just a matter of running older technology. As upstream support winds down, IPVS receives less testing, fewer fixes, and less attention overall. Over time, this increases the risk of subtle breakage, makes troubleshooting harder, and limits compatibility with newer Kubernetes networking features. Eventually, upgrading Kubernetes will force a migration anyway, often at the worst possible time.

Migrating sooner gives you control over the timing, space to test properly, and a chance to avoid turning a routine upgrade into an emergency networking change.

Calico and the Path Forward

Project Calico’s unique design with a pluggable data plane architecture is what makes this transition possible without redesigning cluster networking from scratch. Calico supports a wide range of technologies, including eBPF, iptables, IPVS, Windows HNS, VPP, and nftables, allowing clusters to choose the most appropriate backend for their environment. This flexibility enables clusters to evolve alongside Kubernetes rather than being Continue reading

Exporting events to Loki

Grafana Loki is an open source log aggregation system inspired by Prometheus. While it is possible to use Loki with Grafana Alloy, a simpler approach is to send logs directly using the Loki HTTP API.

The following example modifies the ddos-protect application to use sFlow-RT's httpAsync() function to send events to Loki's HTTP API.

var lokiPort = getSystemProperty("ddos_protect.loki.port") || '3100';
var lokiPush = getSystemProperty("ddos_protect.loki.push") || '/loki/api/v1/push';
var lokiHost = getSystemProperty("ddos_protect.loki.host");

function sendEvent(action,attack,target,group,protocol) {
  if(lokiHost) {
    var url = 'http://'+lokiHost+':'+lokiPort+lokiPush;
    lokiEvent = {
      streams: [
        {
          stream: {
            service_name: 'ddos-protect'
          },
          values: [[
            Date.now()+'000000',
            action+" "+attack+" "+target+" "+group+" "+protocol,
            {
              detected_level: action == 'release' ? 'INFO' : 'WARN',
              action: action,
              attack: attack,
              ip: target,
              group: group,
              protocol: protocol
            }
          ]]
        }
      ]
    };
    httpAsync({
      url: url,
      headers: {'Content-Type':'application/json'},
      operation: 'POST',
      body: JSON.stringify(lokiEvent),
      success: (response) => { 
        if (200 != response.status) {
          logWarning("DDoS Loki status " + response.status);
        }
      },
      error: (error) => {
        logWarning("DDoS Loki error " + error);
      }
    });
  }

  if(syslogHosts.length === 0) return;

  var msg = {app:'ddos-protect',action:action,attack:attack,ip:target,group:group,protocol:protocol};
  syslogHosts.forEach(function(host) {
    try {
      syslog(host,syslogPort,syslogFacility,syslogSeverity,msg);
    } catch(e) {
      logWarning('DDoS cannot send syslog to ' + host);
    }
  });
}
Continue reading

PP092: News Roundup–Old Gear Faces New Attacks, Cyber Trust Mark’s Trust Issues, Alarms Howl for Kimwolf Botnet

Everything old is new again in this Packet Protector news roundup, from end-of-life D-Link routers facing active exploits (and no patch coming) to a five-year-old Fortinet vulnerability being freshly targeted by threat actors (despite a patch having been available for five years). We also dig into a clever, multi-stage attack against hotel operators that could... Read more »

HS122: Insider Threats in the Age of AI

Leaders may shy away from thinking about insider threats because it means assuming the worst about colleagues and friends. But technology executives do need to confront this problem because insider attacks are prevalent—a recent study claims that in 2024, 83% of organizations experienced at least one—and on the rise. Moreover, AI and deepfakes vastly enhance... Read more »

Ultra Ethernet: Congestion Control Context

 Ultra Ethernet Transport (UET) uses a vendor-neutral, sender-specific congestion window–based congestion control mechanism together with flow-based, adjustable entropy-value (EV) load balancing to manage incast, outcast, local, link, and network congestion events. Congestion control in UET is implemented through coordinated sender-side and receiver-side functions to enforce end-to-end congestion control behavior.

On the sender side, UET relies on the Network-Signaled Congestion Control (NSCC) algorithm. Its main purpose is to regulate how quickly packets are transmitted by a Packet Delivery Context (PDC). The sender adapts its transmission window based on round-trip time (RTT) measurements and Explicit Congestion Notification (ECN) Congestion Experienced (CE) feedback conveyed through acknowledgments from the receiver.

On the receiver side, Receiver Credit-based Congestion Control (RCCC) limits incast pressure by issuing credits to senders. These credits define how much data a sender is permitted to transmit toward the receiver. The receiver also observes ECN-CE markings in incoming packets to detect path congestion. When congestion is detected, the receiver can instruct the sender to change the entropy value, allowing traffic to be steered away from congested paths.

Both sender-side and receiver-side mechanisms ultimately control congestion by limiting the amount of in-flight data, meaning data that has been sent but not yet acknowledged. Continue reading

netlab 26.01: EVPN for VXLAN-over-IPv6, Netscaler

I completely rewrote netlab’s device configuration file generation during the New Year break. netlab Release 26.01 no longer uses Ansible Jinja2 functionality and works with Ansible releases 12/13, which are used solely for configuration deployment. I had to break a few eggs to get there; if you encounter any problems, please open an issue.

Other new features include:

You’ll find more details (and goodies) in the release notes.

What we know about Iran’s Internet shutdown

In late December 2025, wide-scale protests erupted across multiple cities in Iran. While these protests were initially fueled by frustration over inflation, food prices, and currency depreciation, they have grown into demonstrations demanding a change in the country’s leadership regime. 

In the last few days, Internet traffic from Iran has effectively dropped to zero. This is evident in the data available in Cloudflare Radar, as we’ll describe in this post. 

Background

The Iranian government has a history of cutting off Internet connectivity when such protests take place. In November 2019, protests erupted following the announcement of a significant increase in fuel prices. In response, the Iranian government implemented an Internet shutdown for more than five days. In September 2022, protests and demonstrations erupted across Iran in response to the death in police custody of Mahsa/Zhina Amini, a 22-year-old woman from the Kurdistan Province of Iran. Internet services were disrupted across multiple network providers in the following days.

Amid the current protests, lower traffic volumes were already observed at the start of the year, indicating potential connectivity issues leading into the more dramatic shutdown that has followed. 

Internet connectivity in Iran plummeted on January 8

Some traffic anomalies Continue reading

Wi-Fi 8 Already?

A picture of the ASUS ROG Wi-Fi 8 AP

The ASUS ROG Wi-Fi 8 AP

Did you see the big news from CES? Wi-Fi 8 is here! Broadcom was talking about it. ASUS rolled out a d20 Wi-Fi 8 AP. MediaTek made sure they had one too. I guess I should probably take down all these Wi-FI 7 APs and just install the new stuff, right?

Nuts and Bolts

Before my favorite people start jumping out there to talk about how the newest iPhone and Samsung Galaxy phones are trash because they don’t support Wi-Fi 8, we need to make sure we’re all on the same page here. The standard behind the Wi-Fi 8 marketing term, 802.11bn, is a proposed working standard. It’s not finalized yet. It’s still in the draft phases, with final standards approval not expected until September 2028.

The focus of 802.11bn is not speed. It’s reliability. When you look at the way that vendors have been pushing more and more throughput for the past several revisions you might ask yourself how much faster things could get. For the eighth release of the Wi-Fi standard the answer is “not any faster.” Wi-Fi 8 is keeping the same speed numbers that Wi-Fi 7 Continue reading

Installing Cisco Nexus Dashboard on Proxmox

Important disclaimerThis guide is intended strictly for lab, testing, and learning purposes. Cisco does not officially support running Nexus Dashboard (ND) on Proxmox.For production deployments, always use Cisco-supported platforms such as VMware ESXi or bare-metal / supported KVM environments. VM Creation on Proxmox Create a new VM in Proxmox with the following characteristics: One critical […]

<p>The post Installing Cisco Nexus Dashboard on Proxmox first appeared on IPNET.</p>

HN809: EVPN All the Things!

It’s been over a decade since the first Packet Pushers podcast on EVPN. Now, guest Jeff McAdams can legitimately suggest that we “EVPN all the things.” Hosts Ethan Banks and Drew Conry-Murray dig into Jeff’s stance on EVPN/VXLAN. They look at how VXLAN and EVPN work; talk about use cases in the data center, the... Read more »