Harga $8, Kritik Berlipat: McDonald’s Hadapi Badai Online di Tengah Krisis Harga

Raksasa makanan cepat saji McDonald’s mencoba menawarkan nilai. Namun, promosi terbarunya justru memicu badai. Perusahaan mempromosikan paket McNugget seharga $8. Tetapi, konsumen merasa harga itu tidak masuk akal. Insiden ini menunjukkan adanya masalah yang lebih dalam. Perusahaan berjuang mempertahankan citra keterjangkauannya. Akibatnya, kritik online menggema dengan sangat keras.

Promosi $8 yang Memicu Amarah Online

Awal bulan ini, McDonald’s mengumumkan promosi terbatas. Promosi itu berisi 10 potong McNugget, kentang, dan minuman. Perusahaan memposisikannya sebagai penawaran nilai yang bagus. Namun, respons di media sosial sangat negatif. Banyak orang mengeluh di bawah postingan perusahaan. Mereka menyuarakan ketidakpuasan mereka secara terbuka.

Sebagai contoh, satu komentar menanyakan nilai dari promosi tersebut. “Sejak kapan $8 adalah harga yang bagus untuk nugget?” tulis seorang komentator. Keluhan lain berfokus pada kualitas dan layanan. Waktu tunggu di drive-thru juga menjadi sorotan. Akibatnya, postingan itu dipenuhi ratusan ulasan negatif.

Perusahaan mencoba merespons keluhan tersebut. Mereka meminta pengguna untuk mengirim informasi kontak mereka. Tujuannya adalah untuk menyelesaikan masalah secara privat. Namun, usaha itu tidak meredakan amarah publik. Badai kritik online terus berlanjut tanpa henti. Situasi ini menunjukkan jarak antara persepsi Continue reading

KubeCon NA 2025: Three Core Kubernetes Trends and a Calico Feature You Should Use Now

The Tigera team recently returned from KubeCon + CloudNativeCon North America and CalicoCon 2025 in Atlanta, Georgia. It was great, as always, to attend these events, feel the energy of our community, and hold in-depth discussions at the booth and in our dedicated sessions that revealed specific, critical shifts shaping the future of cloud-native platforms.
We pulled together observations from our Tigera engineers and product experts in attendance to identify three key trends that are directly influencing how organizations manage Kubernetes today.

🤖 Trend 1: Kubernetes is Central to AI Workload Orchestration

A frequent and significant topic of conversation was the role of Kubernetes in supporting Artificial Intelligence and Machine Learning (AI/ML) infrastructure.
The consensus is clear: Kubernetes is becoming the standard orchestration layer for these specialized workloads. This requires careful consideration of networking and security policies tailored to high-demand environments. Observations from the Tigera team indicated a consistent focus on positioning Kubernetes as the essential orchestration layer for AI workloads. This trend underscores the need for robust, high-performance CNI solutions designed for the future of specialized computing.

🌐 Trend 2: Growth in Edge Deployments Increases Complexity

Conversations pointed to a growing and tangible expansion of Kubernetes beyond central data centers and Continue reading

Lab: IS-IS Route Redistribution

Route redistribution into IS-IS seems even easier than its OSPFv2/OSPFv3 counterparts. There are no additional LSAs/LSPs; the redistributed prefixes are included in the router LSP. Things get much more interesting once you start looking into the gory details and exploring how different implementations use (or do not) the various metric bits and TLVs.

You’ll find more details (and the opportunity to explore the LSP database contents in a safe environment) in the IS-IS Route Redistribution lab exercise.

Click here to start the lab in your browser using GitHub Codespaces (or set up your own lab infrastructure). After starting the lab environment, change the directory to feature/7-redistribute and execute netlab up.

NANOG 95

NANOG held its 95th meeting in Arlington, Texas in October of 2025. Here's my take on a few presentations that caught my attention through this three-day meeting.

UET Relative Addressing and Its Similarities to VXLAN

 Relative Addressing


As described in the previous section, applications use endpoint objects as their communication interfaces for data transfer. To write data from local memory to a target memory region on a remote GPU, the initiator must authorize the local UE-NIC to fetch data from local memory and describe where that data should be written on the remote side.

To route the packet to the correct Fabric Endpoint (FEP), the application and the UET provider must supply the FEP’s IP address (its Fabric Address, FA). To determine where in the remote process’s memory the received data belongs, the UE-NIC must also know:

  • Which job the communication belongs to
  • Which process within that job owns the target memory
  • Which Resource Index (RI) table should be used
  • Which entry in that table describes the exact memory location

This indirection model is called relative addressing.

How Relative Addressing Works

Figure 5-6 illustrates the concept. Two GPUs participate in distributed training. A process on GPU 0 with global rank 0 (PID 0) receives data from GPU 1 with global rank 1 (PID 1). The UE-NIC determines the target Fabric Endpoint (FEP) based on the destination IP address (FA = 10.0.1.11). This Continue reading

How to Turbocharge Your Kubernetes Networking With eBPF

When your Kubernetes cluster handles thousands of workloads, every millisecond counts. And that pressure is no longer the exception; it is the norm. According to a recent CNCF survey, 93% of organizations are using, piloting, or evaluating Kubernetes, revealing just how pervasive it has become.

Kubernetes has grown from a promising orchestration tool into the backbone of modern infrastructure. As adoption climbs, so does pressure to keep performance high, networking efficient, and security airtight.

However, widespread adoption brings a difficult reality. As organizations scale thousands of interconnected workloads, traditional networking and security layers begin to strain. Keeping clusters fast, observable, and protected becomes increasingly challenging.

Innovation at the lowest level of the operating system—the kernel—can provide faster networking, deeper system visibility, and stronger security. But developing programs at this level is complex and risky. Teams running large Kubernetes environments need a way to extend the Linux kernel safely and efficiently, without compromising system stability.

Why eBPF Matters for Kubernetes Networking

Enter eBPF (extended Berkeley Packet Filter), a powerful technology that allows small, verified programs to run safely inside the kernel. It gives Kubernetes platforms a way to move critical logic closer to where packets actually flow, providing sharper visibility Continue reading

Testing IP Multicast with netlab

Aleksandr Albin built a large (almost 20-router) lab topology (based on an example from Jeff Doyle’s Routing TCP/IP Volume 2) that he uses to practice inter-AS IP multicast. He also published the topology file (and additional configuration templates) on GitHub and documented his experience in a LinkedIn post.

Lab topology, copied with permission by Aleksandr Albin

Lab topology, copied with permission by Aleksandr Albin

It’s so nice to see engineers using your tool in real-life scenarios. Thanks a million, Aleksandr, for sharing it.

PP088: How Fortinet Delivers Web App Security in the AI Era (Sponsored)

Web applications have always been tricky to protect. They’re meant to be accessible over the Internet, which exposes them to malicious actors, they’re designed to take end-user inputs, which can be manipulated for malicious purposes, and they often handle sensitive data. Then the rise of public cloud and microservices architectures added new layers of complexity... Read more »

HS118: Bricking the Company – Discussing Existential Threats with Leadership

AI and other technologies are increasingly capable of delivering company-ending events. How do you  have “the conversation” with senior leadership–the one about the existential risks your organization faces, and the steps needed for remediation–in a way that ensures that your company is maximally protected, and that you get the resources you need? AdSpot Sponsor: Meter ... Read more »

A Second Look at Geolocation and Starlink

Civil unrest can often cloud measurement data. Some measurement systems, including the one we use at APNIC Labs, make relatively sweeping assumptions about the stability of both end user behaviour and network service behaviours, and assume that the changes that occur from day-to-day are minor. During times of civil unrest those assumptions are pretty dubious, and this applies to our measurements of ISP market share in Yeman and Myanmar.

Multi-Pod EVPN Troubleshooting (Route Targets)

Last week, we fixed the incorrect BGP next hops in our sample multi-pod EVPN fabric. With that fixed, every PE device should see every other PE device as a remote VTEP for ingress replication purposes. However, that’s not the case; let’s see why and fix it.

Note: This is the fourth blog post in the Multi-Pod EVPN series. If you stumbled upon it, start with the design overview and troubleshooting overview posts. More importantly, familiarize yourself with the topology we’ll be using; it’s described in the Multi-Pod EVPN Troubleshooting: Fixing Next Hops.

Ready? Let’s go. Here’s our network topology:

Read more …

Partnering with Black Forest Labs to bring FLUX.2 [dev] to Workers AI

In recent months, we’ve seen a leap forward for closed-source image generation models with the rise of Google’s Nano Banana and OpenAI image generation models. Today, we’re happy to share that a new open-weight contender is back with the launch of Black Forest Lab’s FLUX.2 [dev] and available to run on Cloudflare’s inference platform, Workers AI. You can read more about this new model in detail on BFL’s blog post about their new model launch here.

We have been huge fans of Black Forest Lab’s FLUX image models since their earliest versions. Our hosted version of FLUX.1 [schnell] is one of the most popular models in our catalog for its photorealistic outputs and high-fidelity generations. When the time came to host the licensed version of their new model, we jumped at the opportunity. The FLUX.2 model takes all the best features of FLUX.1 and amps it up, generating even more realistic, grounded images with added customization support like JSON prompting.

Our Workers AI hosted version of FLUX.2 has some specific patterns, like using multipart form data to support input images (up to 4 512x512 images), and output images up to 4 megapixels. The multipart form Continue reading

5 Reasons to Switch to the Calico Ingress Gateway (and How to Migrate Smoothly)

The End of Ingress NGINX Controller is Coming: What Comes Next?

The Ingress NGINX Controller is approaching retirement, which has pushed many teams to evaluate their long-term ingress strategy. The familiar Ingress resource has served well, but it comes with clear limits: annotations that differ by vendor, limited extensibility, and few options for separating operator and developer responsibilities.

The Gateway API addresses these challenges with a more expressive, standardized, and portable model for service networking. For organizations migrating off Ingress NGINX, the Calico Ingress Gateway, a production-hardened, 100% upstream distribution of Envoy Gateway, provides the most seamless and secure path forward.

If you’re evaluating your options, here are the five biggest reasons teams are switching now followed by a step-by-step migration guide to help you make the move with confidence.

Reason 1: The Future Is Gateway API and Ingress Is Being Left Behind

Ingress NGINX is entering retirement. Maintaining it will become increasingly difficult as ecosystem support slows. The Gateway API is the replacement for Ingress and provides:

  • A portable and standardized configuration model
  • Consistent behaviour across vendors
  • Cleaner separation of roles
  • More expressive routing
  • Support for multiple protocols

Calico implements the Gateway API directly and gives you an Continue reading

UET Data Transfer Operation: Work Request Entity and Semantic Sublayer

Work Request Entity (WRE) 

[SES part updated 7-Decembr 2025: text and figure] 

The UET provider constructs a Work Request Entity (WRE) from a fi_write RMA operation that has been validated and passed by the libfabric core. The WRE is a software-level representation of the requested transfer and semantically describes both the source memory (local buffer) and the target memory (remote buffer) for the operation. Using the WRE, the UET provider constructs the Semantic Sublayer (SES) header and the Packet Delivery Context (PDC) header.

From the local memory perspective, the WRE specifies the address of the data in registered local memory, the length of the data, and the local memory key (lkey). This information allows the NIC to fetch the data directly from local memory when performing the transmission.

From the target memory perspective, the WRE describes the Resource Index (RI) table, which contains information about the destination memory region, including its base address and the offset within that region where the data should be written. The RI table also defines the allowed operations on the region. Because an RI table may contain multiple entries, the actual memory region is selected using the rkey, which is also included in the WRE. Continue reading

1 … 6 7 8 9 10 … 3,835