0

Datacenter Systems Spending To Go Through The Roof In 2027

0

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

0

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

0

Google Rejiggers TPU Accelerators For Broader AI Inference Work

0

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

0

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

0

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.

0

Fakt: 65 % umgehen Zugriffsregeln, um arbeiten zu können

Lernen Sie, wie Sie Ihren gesamten Identitätsbereich schützen, ohne die tägliche Produktivität einzuschränken.

0

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.

0

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.

0

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

0

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

0

Getting Started with Ansible and Juniper Junos

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

So far in this Ansible series, we've worked with Cisco and Arista devices. In this part, we're adding a third vendor, Juniper. We'll build a small lab with two Juniper routers, and use Ansible to configure their interfaces, IP addresses, and OSPF from scratch.

Juniper works quite differently from Cisco and Arista in a few areas, and that's really what this part is about. Instead of connecting over SSH and sending CLI commands, Ansible talks to Juniper devices using NETCONF. Every change goes into a candidate config and only takes effect once it's committed. And thanks to the way Junos compares configs, Ansible can show us exactly what it's going to change, in the same format as show | compare on the CLI.

This part is part of a series on Ansible for network engineers, so I won't go into every detail of things we've already covered, such as inventory, host_vars, loops, and check mode. If any of those are new to you, I recommend going through the earlier parts first. The OSPF example in this Continue reading

0

Revitalisasi Pasar Tradisional Lewat Sistem Digital Lokal

Pasar tradisional selama ini menjadi pusat ekonomi rakyat yang sulit tergantikan. Di sana, interaksi sosial, tawar-menawar, dan perputaran uang berlangsung setiap hari. Namun, di tengah perubahan pola belanja masyarakat, pasar tradisional menghadapi tantangan baru: persaingan dengan minimarket, marketplace daring, dan kebiasaan konsumen yang semakin mengutamakan kecepatan.

Untuk menjawab tantangan itu, banyak daerah mulai melirik revitalisasi pasar tradisional melalui sistem digital lokal. Tujuannya bukan mengubah pasar menjadi serba modern sampai kehilangan jati dirinya, melainkan membantu pedagang beradaptasi dengan kebiasaan belanja masa kini. Digitalisasi bisa menjadi jembatan antara tradisi dan kebutuhan zaman.

Mengapa Pasar Tradisional Perlu Beradaptasi?

Pasar tradisional punya kekuatan besar: kedekatan dengan warga, harga yang fleksibel, dan ragam produk segar. Tetapi, kekuatan itu tidak cukup jika fasilitas kurang nyaman, kebersihan kurang terjaga, atau layanan pembelian masih sangat bergantung pada cara lama. Konsumen masa kini ingin transaksi cepat, informasi harga yang jelas, dan kemudahan pembayaran.

Di banyak kota, pasar yang tidak beradaptasi mulai ditinggalkan pembeli muda. Mereka lebih memilih tempat yang rapi, punya akses digital, dan menyediakan pembayaran non-tunai. Jika tidak ada perubahan, pasar tradisional berisiko kalah bersaing meski sebenarnya memiliki potensi besar untuk tumbuh.

Revitalisasi digital hadir untuk menjawab masalah itu secara bertahap. Dengan pendekatan yang tepat, pasar bisa tetap Continue reading

0

IBM, AMD, And Oak Ridge Unveil Quantum Error Correction Platform

0

Hedge 324: NOSTR

Social media services have largely become a marketplace designed to capture and hold your attention, rather than places where people share information and talk to one another. A large part of this is because they are hosted on large-scale platforms that must be paid for by large, centralized companies. NOSTR is taking a different direction, creating a protocol and system that can be hosted by anyone, anywhere, to build a social network. Wouter Constant joins Tom and Russ to explain what NOSTR is, and how it’s different.
 
You can learn more about NOSTR here.
 

 
download

0

The post-quantum future of web privacy

The highest priorities for the transition to post-quantum cryptography are the basic building blocks of authenticated key-agreement protocols such as TLS. Without these building blocks in place, secure communication on the Internet will not be possible once cryptographically relevant quantum computers come online. However, today we rely on quantum-vulnerable cryptography for much more than TLS.

Privacy Pass is a protocol used by site operators like Cloudflare to help protect applications from abuse. One way we do this is by rate limiting individual clients so that no one client consumes too many of the site's resources. Normally this involves some combination of friction or loss of privacy for users: CAPTCHAs or other challenges to moderate traffic, along with accounts and fingerprinting to identify traffic.Privacy Pass was designed to avoid this tradeoff between friction and privacy. The basic idea is that a client gets issued a number of tokens, which they can redeem in exchange for access to the site. Crucially, each token is unlinkable to the client it was issued to, ensuring the client can use the site as they always had without sacrificing privacy.

With 10 years of deployment experience under our belts — using Privacy Pass for applications Continue reading

0

Scriptable GeoDNS: leaving AWS for Bunny

0

Meet NFA v26.04, featuring sharding & replication capability, host resource monitoring, and more

0

ClickHouse Sharding and Replication in NFA