How to Connect Nested KubeVirt Clusters with Calico and BGP Peering
Running Kubernetes inside Kubernetes isn’t just a fun experiment anymore – it’s becoming a key pattern for delivering multi-environment platforms at scale. With KubeVirt, a virtualization add-on for Kubernetes that uses QEMU (an open-source machine emulator and virtualizer), you can run full-featured Kubernetes clusters as virtual machines (VMs) inside a parent Kubernetes cluster. This nested architecture makes it possible to unify containerized and virtualized workloads, and opens the door to new platform engineering use cases.
But here’s the challenge: how can you ensure that these nested clusters, and the workloads within, can reach, and be reached by, your physical network and are treated the same way as any other cluster?
That’s where Calico’s Advanced BGP (Border Gateway Protocol) peering with workloads comes into play. By enabling BGP route exchange between the parent cluster and nested KubeVirt VMs, Calico extends dynamic routing directly to virtualized workloads. This allows nested clusters to participate in the broader network topology and advertise their pod and service IPs just like any other node. Thus eliminating the need for tunnels or overlays to achieve true layer 3 connectivity.
In this blog, we’ll walk through the big picture, prerequisites, and step-by-step configuration for setting up BGP Continue reading
HN799: Multi-Homing IPv6 to Your Home Lab
If you’ve got an Autonomous System Number (ASN) and an IPv6 block, you too can multi-home IPv6 to your home lab! Sounds easy, right? Well, maybe…but today we’re going to discuss why you’d want to and how you can do that with guest Anton Lönnerbro. Anton is a solutions architect at a managed service provider... Read more »Hedge 282: Future of Operations
On this episode of the Hedge, Anil Varanasi joins Russ to talk about the complexities of network operations and what Meter is doing in this space.
note: even though this is a more product-heavy episode of the Hedge than usual, it is not sponsored
download
Using BIRD BGP Daemon as a BGP Route Reflector
In this challenge lab, you’ll configure a BIRD daemon running in a container as a BGP route reflector in a transit autonomous system. You should be familiar with the configuration concepts if you completed the IBGP lab exercises, but will probably struggle with BIRD configuration if you’re not familiar with it.
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 challenge/01-bird-rr, build the BIRD container with netlab clab build bird if needed, and execute netlab up.
Containerlab – The Anti-Pattern
An intellectual is a man who says a simple thing in a difficult way; an artist is a man who says a difficult thing in a simple way. Charles Bukowski - Notes of a Dirty Old Man, 1969 In a world where technology seems to be working against us and seemingly simple things require far READ MORE
The post Containerlab – The Anti-Pattern appeared first on The Gratuitous Arp.
LIU001: Growing Pains
Starting any new endeavor is hard. That’s particularly true for a career in tech. And that’s the reason Alexis Bertholf and Kevin Nanns are launching the Life In Uptime podcast. In each episode they’ll sit down with engineers, leaders, and builders in tech to uncover the stories behind their careers to help you see how... Read more »netlab: Applying Simple Configuration Changes
For years, netlab has had custom configuration templates that can be used to deploy custom configurations onto lab devices. The custom configuration templates can be Jinja2 templates, and you can create different templates (for the same functionality) for different platforms. However, using that functionality if you need an extra command or two makes approximately as much sense as using a Kubernetes cluster to deploy a BusyBox container.
netlab release 25.09 solves that problem with the files plugin and the inline config functionality.
Ultra Ethernet: Address Vector (AV)
Address Vector (AV)
The Address Vector (AV) is a provider-managed mapping that connects remote fabric addresses to compact integer handles (fi_addr_t) used in communication operations. Unlike a routing table, the AV does not store IP (device mappings). Instead, it converts an opaque Fabric Address (FA)—which may contain IP, port, and transport-specific identifiers—into a simple handle that endpoints can use for sending and receiving messages. The application never needs to reference the raw IP addresses directly.
Phase 1: Application – Request & Definition
The application begins by requesting an Address Vector (AV) through the fi_av_open() call. To do this, it first defines the desired AV properties in a fi_av_attr structure:
int fi_av_open(struct fid_domain *domain, struct fi_av_attr *attr, struct fid_av **av, void *context);
struct fi_av_attr av_attr = {
.type = FI_AV_TABLE,
.count = 16,
.rx_ctx_bits = 0,
.ep_per_node = 1,
.name = "my_av",
.map_addr = NULL,
.flags = 0
};
Example 4-1: structure Continue reading
From Classroom to Community 2 – ROT13 and Math Quizzer
I am so happy the first post about sharing my Python scripts got such a […]
The post From Classroom to Community 2 - ROT13 and Math Quizzer first appeared on Brezular's Blog.
TCG059: From Source of Truth to Knowledge Graph – Rethinking Network Data
Network automation has a data problem. Traditional tools may hit limitations when managing complex infrastructure relationships. We explore how OpsMill’s InfraHub uses graph databases and temporal versioning to create what our guest calls “the knowledge graph of infrastructure” – enabling true version control at the database level while maintaining the flexibility to model anything from... Read more »NAN102: Practical Applications for AI in Network Automation
As AI becomes more integrated into the IT landscape, developers, engineers, and operators are looking for practical ways to use these new tools. Joining us today is Ryan Booth; he’s built a career around network automation, giving him a unique perspective on how network engineering, operations, software development, and AI intersect. We explore the practical... Read more »EVPN Designs: Multi-Pod Fabrics
In the EVPN Designs: Layer-3 Inter-AS Option A, I described the simplest multi-site design in which the WAN edge routers exchange IP routes in individual VRFs, resulting in two isolated layer-2 fabrics connected with a layer-3 link.
Today, let’s explore a design that will excite the True Believers in end-to-end layer-2 networks: two EVPN fabrics connected with an EBGP session to form a unified, larger EVPN fabric. We’ll use the same “physical” topology as the previous example; the only modification is that the WA-WB link is now part of the underlay IP network.
PP080: The State of OT Risks in 2025 (and What to Do About Them)
What does the risk environment for Operational Technology (OT) look like in 2025? JJ and Drew review four recent reports on the state of OT security from Dragos, Fortinet, and others. We discuss ransomware impacts, ongoing risks of RDP traffic, directly exposed OT devices, and overall attack trends and the tools and processes that organizations... Read more »Payload on Workers: a full-fledged CMS, running entirely on Cloudflare’s stack
Tucked behind the administrator login screen of countless websites is one of the Internet’s unsung heroes: the Content Management System (CMS). This seemingly basic piece of software is used to draft and publish blog posts, organize media assets, manage user profiles, and perform countless other tasks across a dizzying array of use cases. One standout in this category is a vibrant open-source project called Payload, which has over 35,000 stars on GitHub and has generated so much community excitement that it was recently acquired by Figma.
Today we’re excited to showcase a new template from the Payload team, which makes it possible to deploy a full-fledged CMS to Cloudflare’s platform in a single click: just click the Deploy to Cloudflare button to generate a fully-configured Payload instance, complete with bindings to Cloudflare D1 and R2. Below we’ll dig into the technical work that enables this, some of the opportunities it unlocks, and how we’re using Payload to help power Cloudflare TV. But first, a look at why hosting a CMS on Workers is such a game changer.
Behind the scenes: Cloudflare TV’s Payload instance
Most CMSs are designed to be hosted on a conventional server that runs Continue reading
HS113: Bad Tech Romance: Five Signs You’re In an Abusive IT Relationship
Sure, some days you hate your job. But how do you know when an IT position has gone from being run-of-the-mill annoying to truly toxic? And what do you do about it? Johna Johnson and John Burke are joined by Sandy Miller, a pseudonym for a CIO at a major global company who talks about... Read more »
Ultra Ethernet: Completion Queue
Completion Queue Creation (fi_cq_open)
Phase 1: Application – Request & Definition
The purpose of this phase is to define the queue where operation completions will be reported. Completion queues are used to report the completion of operations submitted to endpoints, such as data transfers, RMA accesses, or remote write requests. By preparing a struct fi_cq_attr, the application describes exactly what it needs, so the provider can allocate a CQ that meets its requirements.
Example API Call:
struct fi_cq_attr cq_attr = {
.size = 2048,
.format = FI_CQ_FORMAT_DATA,
.wait_obj = FI_WAIT_FD,
.flags = FI_WRITE | FI_REMOTE_WRITE | FI_RMA,
.data_size = 64
};
struct fid_cq *cq;
int ret = fi_cq_open(domain, &cq_attr, &cq, NULL);
Explanation of fields:
.size = 2048: The CQ can hold up to 2048 completions. This determines how many completed operations can be buffered before the application consumes them.
.format = FI_CQ_FORMAT_DATA: This setting determines the level of detail included in each completion entry. With FI_CQ_FORMAT_DATA, the CQ entries contain information about the operation, such as the buffer pointer, the length of data, and optional completion data. If the application uses tagged messaging, choosing FI_CQ_FORMAT_TAGGED expands the entries to Continue reading
Nationwide Internet shutdown in Afghanistan extends localized disruptions
Just after 11:30 UTC (16:00 local time) on Monday, September 29, 2025, subscribers of wired Internet providers in Afghanistan experienced a brief service interruption, lasting until just before 12:00 UTC (16:30 local time). Cloudflare traffic data for AS38472 (Afghan Wireless) and AS131284 (Etisalat) shows that traffic from these mobile providers remained available during that period.
However, just after 12:30 UTC (17:00 local time), the Internet was completely shut down, with Afghani news outlet TOLOnews initially reporting in a post on X that “Sources have confirmed to TOLOnews that today (Monday), afternoon, fiber-optic Internet will be shut down across the country.” This shutdown is likely an extension of the regional shutdowns of fiber optic connections that took place earlier in September, and it will reportedly remain in force “until further notice”. (The earlier regional shutdowns are discussed in more detail below.)
While Monday’s first shutdown was only partial, with mobile connectivity apparently remaining available, the graphs below show that the second event took the country completely offline, with web and DNS traffic dropping to zero at a national level, as seen in the graphs below.
While the shutdown will impact subscribers to fixed and mobile Internet Continue reading
Ultra Ethernet: Event Queue
Event Queue Creation (fi_eq_open)
Phase 1: Application – Request & Definition
The purpose of this phase is to specify the type, size, and capabilities of the Event Queue (EQ) your application needs. Event queues are used to report events associated with control operations. They can be linked to memory registration, address vectors, connection management, and fabric- or domain-level events. Reported events are either associated with a requested operation or affiliated with a call that registers for specific types of events, such as listening for connection requests. By preparing a struct fi_eq_attr, the application describes exactly what it needs so the provider can allocate the EQ properly.
In addition to basic properties like .size (number of events the queue can hold) and .wait_obj (how the application waits for events), the .flags field can request specific EQ capabilities. Common flags include:
- FI_WRITE: Requests support for user-inserted events via fi_eq_write(). If this flag is set, the provider must allow the application to invoke fi_eq_write().
- FI_REMOTE_WRITE: Requests support for remote write completions being reported to this EQ.
- FI_RMA: Requests support for Remote Memory Access events (e.g., RMA completions) to be delivered to this EQ.
Flags are encoded as a bitmask, so multiple Continue reading
Changing the Layout of netlab Topology Graphs
After I published the updated netlab topology graphs article, Samuel K. Lam quickly made a comment along the lines of now we know how the graph representing the following topology was made, adding a nice ASCII art that illustrated the point I was trying to make much better than my graphs:
ASCII art representing the BGP leak lab
Let’s see how close we can get to that ideal topology diagram with GraphViz and D2 graphs.