Getting Started with Ansible and Arista

Getting Started with Ansible and Arista

This post is part of an ongoing series on Ansible, and you can find all the other posts in the series here.

I'm writing this post as part of my Ansible for Network Engineers series. But if you've just stumbled across this post without reading the previous parts, you should still be able to follow along. I won't go into detail on everything we've already covered, such as inventory, variables, loops, and handlers, but I'll point you to the relevant parts where it helps.

Earlier in the series, we built the OSPF topology below using Cisco routers, and we've also looked at configuring OSPF on Juniper. Now it's Arista's turn. The reason I keep coming back to this OSPF topology is that it's a great way to cover a lot of topics in one go. With six routers and three OSPF areas, we get to work with interfaces, IP addressing, OSPF areas, passive interfaces, and router IDs, and it gives us a good excuse to use a range of different modules and config commands along the way. It also makes it really easy to compare how each vendor does things differently, since the network itself stays exactly the same.

Getting Started with Ansible and Arista
arista Continue reading

Choosing QuePaxa, an unusual consensus algorithm

Cloudflare recently announced Meerkat, an experimental distributed consensus service designed to manage our internal global control plane. It is powered by a new consensus algorithm published by researchers Tennage & Băsescu et al. called QuePaxa (2023).

QuePaxa is an unusual choice; most consensus systems use well-established consensus algorithms like Raft, (Multi-)Paxos or Viewstamped Replication. These algorithms are well understood, have mature implementations, and usually work well.

Unfortunately, common consensus algorithms often suffer in wide-area networks with volatile network connectivity and latency, i.e., networks like the Internet, which is where Meerkat runs. These algorithms rely on a single leader process being available and having predictable latency. If the leader goes down, experiences higher latency than usual, or is disconnected, the entire consensus system slows down or becomes unavailable until the leader is replaced. This is unacceptable for Meerkat.

Meerkat’s global deployment environment led us to a newer consensus algorithm, QuePaxa, which promises better stability despite volatility, in large part by not relying on a leader to make progress. In this post we’ll explain why we chose QuePaxa and how the QuePaxa algorithm works.

What we’re building and why it’s unique

Meerkat is a distributed system in which replicas agree upon Continue reading

New Tool – BGP Prefix-List and Policy Generator (with a Policy Tester)

New on the Network Tools page: a BGP Prefix-List and Policy Generator. You describe a BGP import or export policy once, get the configuration for Junos, Cisco IOS / IOS-XE or Cisco IOS-XR, and then test it against a list of routes before it goes anywhere near a router.

What it builds

  • Prefix sets with ranges: exact, orlonger, longer, le, ge, ge N le M, prefix-length-range. Length checks are just ranges: “too specific” is 0.0.0.0/0 ge 25, “too short” is 0.0.0.0/0 le 7 (which also catches the default route). IPv6 works the same way.
  • Ordered terms. Each term matches on a prefix set, an AS-path condition (originated by, learned from neighbor AS, passes through, locally originated, contains a private ASN) and communities. Then it can set local-preference and MED, add, replace, delete or clear communities, prepend your AS, and accept, reject or continue to the next term.
  • Real platform output. Junos gets route-filter-list and policy-statement terms. IOS gets prefix-lists, AS-path ACLs, community lists and a route-map with one sequence per term. IOS-XR gets prefix-sets, as-path-sets, community-sets and a route-policy that ends in an explicit done or drop.
  • Continue reading

AI agents belong on your Kubernetes platform

In Kubernetes, pods get a new IP every time they restart, so an IP can’t tell you which workload it is. Platform teams learned to identify workloads by labels and identity instead. AI agents are now teaching them a second lesson: an agent’s code can’t tell you what it will do.

I believe AI agents belong on the Kubernetes platform. Not beside it, not around it, and not left to each team to secure alone. On it: identified, governed and contained like every other production workload.

I’ve spent the last decade working with the platform teams behind some of the largest Kubernetes environments in the world: banks, telecom carriers, SaaS companies and insurers. I watched them take containers from a side experiment to the default way their companies ship software. The best of them did it without slowing anyone down, and without giving up control.

This year I’m watching the same story start again with a new workload. AI agents are arriving on those platforms faster than anyone can govern them. In an April 2026 Cloud Security Alliance survey of 418 IT and security professionals, 82% said they had found at least one AI agent or autonomous workflow in the Continue reading

Performance evolution of route lookup on Linux

In previous articles, I explained how the Linux kernel implements IPv4 and IPv6 routing tables, and I showed the performance improvement of route lookups from Linux 2.6.32 to 4.16 for IPv4—including the impact of the Meltdown and Spectre mitigations—as well as from Linux 2.6.39 to 4.18 for IPv6. This article updates the numbers through Linux 7.3 and investigates the perpetrator responsible for the performance regressions! 🕵️‍♂️

I ran the following benchmarks on an AMD EPYC 8024P, a Zen 4c CPU, rented from Scaleway, running at 2.4 GHz with CPU boost disabled. I compiled the kernels with GCC 10.2: this version can compile older kernels as well as the current ones.

IPv6

Performance evolution of IPv6 route lookups from Linux 4.14 to 7.3
Performance evolution of IPv6 route lookups. Versions with an asterisk have SRSO mitigation disabled.

I tested four scenarios:

  • a recent full view with about 260,000 prefixes,
  • a full view from 2017 with about 40,000 prefixes,
  • a set of 40,000 /48 prefixes, such that 2 lookups out of 3 match, and
  • a set of 40,000 random /128 prefixes, such that 1 lookup out of 400 matches.

In Linux 4.15, Wei Wang improved the lookup performance Continue reading

Securing AI Agents Requires More Than a Gateway

Over the past year, I’ve spent a lot of time talking with engineering and platform teams about how they’re deploying AI agents. The conversations are changing. Six months ago, most were focused on getting agents into production. Now, increasingly, the question is how to secure them once they’re there.

It’s a familiar transition. We’ve seen it with containers, Kubernetes, microservices, and cloud infrastructure. New technology gets adopted, architectures evolve, and security has to catch up with how systems actually operate.

AI agents introduce some interesting challenges, though. Unlike traditional applications, agents make decisions about what to do next. They interact with models, invoke tools, communicate with other agents, access data, and execute code. A single user request can trigger a sequence of actions across multiple systems, sometimes with very little human involvement.

That changes the security problem.

An agent can be properly authenticated, operate within its assigned permissions, and still be led into doing something nobody intended.

It’s one of the reasons I believe securing agentic AI requires a defense-in-depth architecture, with controls operating at both the application and runtime layers.

The gateway is an important part of the architecture

AI gateways have become a natural place to introduce security Continue reading

Calico on Red Hat OpenShift 5: One Network and Security Model for Containers, VMs and AI

We’re pleased to announce that Calico is supported on Red Hat OpenShift 5, the latest version of the industry’s leading hybrid cloud application platform powered by Kubernetes. Tested and validated to run on Red Hat OpenShift 5, Calico delivers high-performance networking and zero-trust network policy for containers, virtual machines on Red Hat OpenShift Virtualization, and AI workloads, with one consistent policy model across the cluster.

Built on a long-standing collaboration

Calico has been a supported networking option for Red Hat OpenShift since OpenShift 4, and the Tigera Operator is listed in the Red Hat Ecosystem Catalog. Red Hat OpenShift customers can install Calico through the Tigera Operator on a new cluster, or move existing clusters from OVN-Kubernetes to Calico using Tigera’s documented migration path.

What Calico brings to Red Hat OpenShift 5

  • High-performance networking, your choice of data plane. Calico runs on eBPF, iptables or nftables, so teams can match performance and operational needs cluster by cluster.
  • Zero-trust network policy. Calico enforces Kubernetes NetworkPolicy and extends it with Calico’s own policy model, including cluster-wide rules, so default-deny and microsegmentation apply consistently.
  • Policy you can test before you enforce it. Staged policies show the effect of a rule on live traffic Continue reading

Protect-RE Filter Generator Update – Mist, TACACS+, DHCP and Custom Rules

The Juniper Protect-RE Filter Generator on the Network Tools page picked up a round of additions. The trigger was simple: we compared it against the protect_re filter a Mist-managed EX4400 actually carries, and found a handful of things a real-world filter needs that the generator didn’t cover yet.

What’s new

  • Mist-Managed Device. A Mist switch opens its connections outward, so the filter only has to accept the return traffic. Three optional terms cover it: outbound SSH (TCP source-port 2200), the Mist cloud over HTTPS (443), and NAC RadSec (2083). Each is TCP with tcp-established, so a fresh inbound SYN doesn’t match.
  • TACACS+. Return traffic from your TACACS+ servers (TCP source-port 49, tcp-established), with the server list pulled live from system tacplus-server using the same apply-path trick the BGP, NTP and RADIUS terms use. It’s TCP-only on purpose: TACACS+ doesn’t run over UDP, and tcp-established can’t match UDP anyway, so a combined TCP/UDP term can only ever match TCP.
  • DHCP and DHCPv6. A client option for routers that get their management address by DHCP, and a server/relay option for routers that hand them out. The server/relay term is placed ahead of anti-spoof, because a client’s first packet comes from Continue reading

Launching the Vite Ecosystem Fund

Cloudflare is distributing the first $301,300 of the Vite Ecosystem Fund to 44 projects and maintainers across the Vite ecosystem.

When VoidZero joined Cloudflare, we committed $1 million to strengthen the open source ecosystem around Vite. This round is just the start.

Sponsoring open source has always mattered, but now AI has made funding urgent.

AI is changing open source

AI has made open source more valuable while triggering more maintainer burnout. Previously, contributing to a project through either an issue or pull request meant you cared about it. In return, maintainers would review and provide feedback. AI changed the social contract of open source. Anyone can now create and submit AI-authored pull requests.

The most visible result is the influx of pull requests. As the number of PRs has gone up, the number of maintainers reviewing them has stayed constant. So each maintainer’s workload has grown.

During reviews, maintainers often find themselves speaking with an agent and not a person like they used to. If that’s the case, then why not cut out the middleman? Maintainers now have their own agents they can prompt to produce better results since they have more knowledge of the codebase.

AI has raised Continue reading

Worth Reading: BGP Multi-Homed with Two ISPs and Two Routers

I was reading the nice BGP Multi-Homed with Two ISPs and Two Routers scenario by Suresh Vinasiththamby - Packetswitch and thought wouldn’t it be nice if he were using netlab to build the lab, as that would give you the opportunity to build the same lab with zero hassle using non-Cisco devices. Guess what – Suresh already did just that. I was so glad to see someone using netlab in just the way I imagined it to be used.

Read more …

The DO’s and Don’ts of Post-Quantum DNSSEC

There has been a lot of interest in recent months on the topic of post-Quantum cryptography (PQC) and DNSSEC. It appears likely that the day will come when our current suite of cryptographic algorithms could not resist efforts to break them using appropriately powerful quantum computers. Some folk say this day is decades away, while others are predicting we have just a small number of years. We have suitably strong quantum-resistant algorithms that we can use. The only problem is that these post-quantum digital signatures are up to 40 times as large as the signatures we use today. And this has some serious implications for the operation of DDNSSEC.

Worth Reading 110726


The transition from IPv4 to IPv6 is usually presented as a protocol upgrade. In a lab, that’s roughly true. You enable the address family, you advertise a prefix, you ping something, you move on.

 


Most of us have never heard of longtermism, the view that we should consider the interests of those who will live in the far future more than those of current humans.

 


In this episode of PING, APNIC Chief Scientist Geoff Huston reflects on the economic consequences of the surge in artificial intelligence (AI) investment and the associated data centre build-out.

 


The Public Suffix List (PSL) is a security liability limping along as a vestigial artifact from a bygone age. Downstream consumers such as browsers, certificate authorities and RFC7489 DMARC receivers, to name a few, all read from this nearly 20-year-old text file for calculating domain boundaries.

 


No matter how much money anyone throws at it, the GenAI boom can only continue to grow as fast as datacenters are built and powered up to accept machinery.

AI Distributed Job Initialization

 

Job Orchestration and Resource Allocation

When a distributed training job is launched, the cluster scheduler or orchestration layer (such as SLURM or Kubernetes) allocates the required compute nodes and provides job-specific information to the job launcher. This information includes the JobID, the allocated nodes, and the resources assigned to the job.

The launcher provides the configuration required by the Torchrun agents, such as the number of nodes, the number of local workers, and the rendezvous configuration. Torchrun uses this configuration and the rendezvous mechanism to establish the worker-group membership and determine the distributed identities of the worker processes. These include the global rank (RANK), local rank (LOCAL_RANK), total number of workers (WORLD_SIZE), and number of local workers (LOCAL_WORLD_SIZE).

In a typical multi-node PyTorch deployment, one Torchrun agent runs on each allocated node. The agent is a host-side process responsible for launching and managing the local worker group. It starts the configured number of worker processes, typically one per GPU. Each worker is an independent operating-system process that executes the training application and uses its assigned GPU for computation.

The Torchrun agent monitors the worker processes and manages their lifecycle, including restarting the worker group if a failure occurs and Continue reading

Going Further with Ansible and Juniper

Going Further with Ansible and Juniper

This post is part of an ongoing series on Ansible, and you can find all the other posts in the series here.

In the previous part, we backed up the config of our Junos routers in two different ways. First, we used the junos_config module, which saved the config as set commands. Then, to get a copy in the curly bracket format, we ran show configuration with the junos_command module and saved the output to a file. In this section, I'll show you a more direct way to do it, using a module called juniper.device.config, which can retrieve the config and save it in whichever format we like.

Installing the Extra Packages

juniper.device.config is built on Juniper's PyEZ library, and it needs two extra Python packages, on top of the ones we installed in the previous part.

uv add junos-eznc jxmlease
  • junos-eznc - Juniper's PyEZ library, which the module uses to connect to the router.
  • jxmlease - Another library for working with XML, which PyEZ relies on.

The Playbook

The module doesn't create the directory for the backups, so let's create it first.

mkdir -p backups_native

Next, create a new playbook called backup_native.yml.

 Continue reading
1 2 3 … 3,920