• Human Infrastructure
  • Posts
  • Human Infrastructure 445: Rail-Optimized Networks, No IT Shortcuts, MCP and Identity, and More

Human Infrastructure 445: Rail-Optimized Networks, No IT Shortcuts, MCP and Identity, and More

AuthorAuthor

Drew Conry-Murray & Ethan Banks
April 23, 2026

THIS WEEK’S MUST-READ BLOGS 🤓

Phil Gervasi explains that a rail-optimized network is about putting GPU-to-GPU communications on as direct of a path to each other as possible in the context of leaf-spine. Put another way, if leaf-spine has been about providing a general purpose fabric that works pretty well for any short-lived, bursty traffic flows spread across a whole lot of hosts, rail-optimized is about a leaf-spine fabric where long-lived elephant flows are mapped to specific network paths to optimize the performance of host-to-host workloads that are intolerant of packet loss or delay.

So, what’s a rail, exactly? Phil explains (emphasis mine), “A rail isn’t a separate topology or a bypass of the leaf-spine fabric. Instead, it’s a consistent mapping of endpoints to a specific network plane within a shared Clos-based fabric.

Most real implementations are multi-plane Clos fabrics in which each plane operates independently (its own failure and congestion domain) and endpoints are deterministically assigned to planes. So while traffic can still travel leaf-to-spine-to-leaf, it does it within a constrained and predictable subset of the fabric.

And most important to keep in mind is that we’re aligning application communication to network forwarding.”

If, like me, you’ve designed a lot of networks to be pretty good at just about everything but not ideal for any one thing, rail-optimized goes in a different direction. Plugging in hosts so that their traffic flows between each other on a conceptual rail is something we only used to do in specific situations—like creating a special network just for backups or just for vMotion. Conversely, rail-optimized is all about that specificity. - Ethan

Larry Peterson waxes philosophical about what a router is vs. what a switch is, and when “router” or “switch” should be used when referring to a particular device. Lots of back and forth and even some Venn diagrams in Larry’s thought exercise…but no firm conclusion. Larry ultimately points out that which term is appropriate is more about context as opposed to which device is forwarding frames vs. packets.

Holly and I took a stab at this topic on N Is For Networking Ep.16 Routers Are Not Switches…Are They?. It is a somewhat diabolical issue to nail down. As experienced engineers, we instinctively know which is which, but explaining why we picked a given term when we consider what’s actually going on in the silicon is hard. - Ethan

Dustin Demers makes several great observations about what it takes to land a job in information technology. “There’s always talk about magic resumes, perfect cert stacks, or some weird trick to land interviews, but none of that really holds up in reality. Breaking into IT isn’t about one big move. It’s about stacking signals over time: your skills, your curiosity, your consistency, and proof that you can do the work.”

Allow me to highlight one point Dustin makes. “Networking matters too but not in the “cold message everyone asking for a job” kind of way. don’t do that by the way. Engage with people, ask questions, and share what you’re learning. Opportunities often come from being visible and involved, not just from submitting applications.”

I point this out because I’m seeing this bad behavior in our community Slack lately. Someone joins the group and their first post to #general is a fancy version of, “Hi, I want a networking job pls. kthxbai.” Folks, that ain’t gonna work in our Slack or anywhere else. We don’t know you. We don’t know your skills. In the age of AI, we don’t even know if you’re human. Low effort spam is gonna get you ignored if not banned or blocked.

The rest of Dustin’s post makes many other great points about earning your way to that first IT job. If you’re trying to hack your way into IT, read Dustin’s post and see what changes in your strategy are indicated. - Ethan

Suresh Vina made a CLI version of his resume/CV. You can run various commands to see different aspects of his career. It’s an ongoing project and Suresh is open to feedback and ideas if you want to go play with it and drop him a suggestion. - Drew 

If organizations are going to have AI agents interact with tools, services, and data, they need a robust mechanism to identify and authorize these agents. Karim’s post shares details on how to use an identity provider and OAuth to provide authorization for AI agents to take actions on behalf of human users in an MCP environment.

He describes how the On-Behalf-Of (OBO) workflow integrates with the Client ID Metadata Document (CIMD), an IETF draft, to support dynamic authorization without the need to pre-register every agent. This post takes you step-by-step through the process with a lot of helpful illustrations. - Drew  

MORE BLOGS

Build a data foundation your automation can grow on
When you start a network automation project, it's tempting to grab popular tools and go. You’ll land some quick wins. But 18 months from now, you’ll either be scaling smoothly…or bumping up against painful gaps and constraints.

The future you face comes down to the data foundation you pick at the start.

Infrahub from OpsMill is a data management platform purpose-built to power network automation and AIOps. A fully extensible schema manages anything you want. Version control and change management are core features, not plugins.

When you build on that data foundation, the possibilities open up fast: scalable provisioning, self-service catalogs, durable lifecycle management, context-enriched agentic workflows.

Try the live Infrahub sandbox or grab the open-source version on GitHub. Your future self will thank you.

TECH NEWS 📣

No, the new user isn’t you. It’s agentic AI—AI agents working through a series of inferencing operations to generate a result for whatever series of tasks they’ve been asked to perform. This is interesting because the Internet wasn’t designed for this.

“A traditional crawler fetches a page and leaves. An agent doesn’t. It maintains state. It authenticates. It calls multiple services in sequence. It retries. It executes. From the network’s perspective, the traffic can look like a human session—but it runs at machine speed, at machine scale, 24 hours a day.

The network currently has no way to tell the difference. That matters because latency is starting to play a different role.”

A little later, the piece suggests, “BGP path selection wasn’t designed for this environment. That’s not a crisis today. But it is a serious design question and one the networking community should be asking before someone else answers it for them.”

In a number of podcast conversations, we’ve talked with folks building AI data centers about what makes AI compute workloads different. But as this article points out, it’s not just data center network infrastructure that’s having to be re-thought because of AI. The fabric of the Internet itself is also being impacted. - Ethan

IPv4 scarcity in the face of steady demand has created a market worth watching, whether you’ve got v4 you don’t need or v4 you really, really want. Based on data from a March 2026 report published by IPv4.Global, CircleID summarizes as follows.

“The accompanying pricing data illustrate a clear downward trajectory across all block sizes from April 2025 through early 2026, with larger blocks (/16+) falling from roughly $22 per address to below $10 at the beginning of the year. Mid-sized blocks (/17–/19 and /20–/21) followed similar patterns, while smaller allocations (/22–/24) proved comparatively resilient, declining more gradually from just above $30 to the low-$20 range. Notably, March data show a slight recovery across most categories, particularly among larger and mid-sized blocks, interrupting what had been a consistent softening trend.”

In other news, IPv6 adoption continues. 😅 - Ethan

Doug Dawson observes, “The FCC voted in its recent open meeting to expand the use of 900 MHz spectrum. The order opens up the full 10 MHz available in the 900 MHz spectrum bands 896–901 and 935–940 MHz, for licensed broadband services. 900 MHz is an attractive band for users since the signals carry a long way and are good at penetrating buildings.

The licensed portion of the spectrum is not of interest to WISPs due to the small size of the channels, which won’t deliver the kinds of speeds expected by home broadband users. But the spectrum can easily support smartphone applications and is of interest to those wishing to deploy private 5G network.”

Doug suggests the use cases will be for utilities who want to use the spectrum for meter reading. Click through for more details about the FCC change, channel widths, and other impacts. - Ethan

A surveillance startup called Sauron? I used to wonder if companies that borrowed the names of sinister characters from fiction were just  misreading those texts. Now I’m pretty sure they didn’t misread. They’re telling us who they side with and what their ambitions are. So just stop with the pretense and call your company “Stasi” or “Gestapo” like you want to and spare us your little wink. - Drew  

MORE NEWS

FOR THE LULZ 🤣

Marie Kondo will get you to tidy up that basement the easy way or the hard way. Shared on Bluesky by @mimismartypants.bsky.social

RESEARCH & RESOURCES 📒

This was posted in the Packet Pushers community Slack group, and it’s an interesting doc.

“The following list of features and protocols are planned for eventual removal from Cisco products. The list indicates which features are currently supported by each operating system. The expected release numbers for warnings and feature restrictions are outlined in the feature deprecation and removal strategy. Final feature removal dates will be updated in this document when the release number becomes available.

Some features will not transition through a restriction phase and will go directly from warnings to removal. For these features, you will see a release number for the warning phase, but N/A for the restriction.”

On the list are several of what I’ll describe as “old favorites”. Yeah, they’re insecure and we’ve known that for a long time. But they still might be hanging around because engineering them out of the network has been too difficult. For example, migrating from SNMP v2c to v3 can be annoyingly hard. 😬 - Ethan

Network Device Hardening Guides - Various

Cisco’s post above made me think about device hardening guides. Here are a few to get you started.

Even if you have no plans to implement device hardening, read through a couple of these to understand how to think about this network engineering challenge. It’s worth pondering the different angles of attack a bad actor might use to hurt your network. There’s a LOT more to hardening than setting up robust authentication and some access control lists. - Ethan

A group within the Network Automation Forum (which runs the AutoCon conference) has been working on a framework to describe the components involved in network automation. A first draft of that framework is now available.

The framework doesn’t tell you what products to buy or how to implement network automation. Instead, it models the core elements of network automation, and offers some guidance on how each part of the stack fits with the others.

I sat in on some of the early Zoom calls that attempted to put the framework together. There were lots of ideas, and lots of smart, passionate people with strong points of view. It was, sometimes, a bit of a struggle to even define basic terms. 

This current framework tries to balance strict definitions against the fluidity of industry terms, and I think it does a nice job. The framework borrows from the IETF model with the use of “must” and “should”, which lets you nail down core concepts while still allowing for a bit of wiggle room. 

In any case, if you’re looking for a mental model to help you get a big-picture view of what a network automation strategy or project might encompass, check this out and see if it helps. And cheers to the folks who put it together: Christian Adell, Ryan Shaw, Dinesh Dutt, Claudia de Luna, Damien Garros, and Wim Henderickx.  - Drew 

If you’ve wanted to try your hand at building an AI agent to help you with network ops tasks, this online workshop, which takes place May 9th, might be of interest. The instructor, Sif Baksh, is a member of the Packet Pushers Community Slack. This is from the description of the workshop:

“This hands-on workshop is built for network engineers who are done waiting for a tool that fits. You will build a working AI agent from scratch, connected to real Arista cEOS devices, and leave with production-ready code you can take back to your environment and adapt immediately. No mock demos. No stopping short of deployment.”

You have to pay to attend the workshop, but if you use the link above, it comes with a 30% discount. - Drew 

MORE RESOURCES

The AutoCon5 agenda from Network Automation Forum is OFFICIAL!

We say this every time - because it's true every time - that there were many excellent proposals and we could not fit in every great talk. The choices for AutoCon5 have definitely been the hardest. Thank you to the NAF Advisory Board for all your work here.

The good news for you is that you're going to see the best set of talks on what people are really doing in network automation. What's working, what's not, what's happening with the NAF framework perspective, what's happening in network automation leadership, and more.

Join us in Munich! Conference and workshop tickets and hotel rooms are still available - grab your tickets and room NOW: https://networkautomation.forum/autocon5#register

UPCOMING LIVE EVENTS 🍕🍻

A curated list of near-future meatspace events of interest to network engineers. Sometimes a Packet Pusher or two will be there (noted below).

Subscribe to events.packetpushers.net in your calendar software.

APRIL 2026

Wi-Co Frankfurt
29 April | Frankfurt, Germany

MAY 2026

Extreme Connect | Extreme Networks
4 - 7 May | Orlando, FL (Packet Pushers attending)

NLNAM Meetup 2 | NL Network Automation Meetup
13 May | Alphen aan den Rijn, Netherlands

Wi-Co Brussels
21 May | Brussels, Belgium

(NH)NUG | New Hampshire Networking User Group (USNUA)
27 May | TBD, NH (Ethan co-organizing)

Wi-Co Memphis
29 May | Memphis, TN

Cisco Live US
31 May - 4 June | Las Vegas, NV (Packet Pushers likely)

JUNE 2026

Wi-Co Oslo
3 June | Oslo, Norway

AUTOCON5 | Network Automation Forum
8 - 12 June | Munich, Germany (Packet Pushers attending)

Wi-Co North Carolina
11 June | Jamestown, NC

HPE Discover
14 - 19 June | Las Vegas, NV (Packet Pushers possible)

INDUSTRY BLOGS & VENDOR ANNOUNCEMENTS 💬 

José Mª Rivadeneyra opens this piece as follows. Emphasis mine. “It is widely believed that all BGP routers within an Autonomous System (AS) must be connected in a full iBGP mesh, or, when this becomes impractical, that route reflectors or confederations must be used. However, a full mesh is not always necessary, and in some scenarios it may even be undesirable.

In this article, I will explain why the belief that iBGP full mesh is mandatory has become so widespread, and clarify when it is actually necessary to interconnect all BGP routers within an AS - and when it is better not to do so.”

Well, that caught my attention. As I read through the piece, I found one of those situations in networking where pedantry from the “well actually” guy matters. The first two statements in José’s concluding points gets to the heart of what his examples illustrated.

  • iBGP full mesh is not a protocol requirement, but a route visibility requirement.

  • It is only necessary among routers that must have full visibility of all external routes.

I’m still thinking about this, because it challenges consistent training I received on this back in the day. I never ran large BGP environments, so I never ran into any reasons to question the prevailing sentiments about full iBGP meshes. - Ethan

John Capobianco lays out a perspective on at least two things in this piece.

  1. The advantages of using a natural language interface instead of domain-specific CLIs.

  2. How training AI agents to do scut work improves our usefulness to the business.

Perhaps you value your expertise with command line syntax and therefore resist using natural language interfaces (NLIs) to prompt a model. My take is that to get the results you want from a model, you have to both feed it good data and know how to ask questions well. There’s still skill and expertise involved, but we’ve abstracted arcane syntax away. In the long run, I believe NLIs will become the standard way we interact with the holistic network. Interacting with one device at a time using the CLI (while there will still be reasons to do so) will be widely understood as slow, error-prone, and adding to MTTR.

If the thing that puts you off about agentic AI is trustworthiness, John doesn’t minimize those concerns. Instead, he points out that just like we wouldn’t let a new junior network engineer run wild, we won’t let AI run wild either. Start with small, low-risk tasks. Train. Improve. Then move on to larger tasks with a bit more risk. - Ethan

Security researchers at Expel describe how North Korean threat actors are targeting software developers with fake job offers. If the target responds, they are asked to undergo a “skills assessment” via a takehome coding assignment. That assignment is laced with malware, which the attackers then use to look for and steal crypto assets. The report also describes how the researchers identified the attackers’ use of AI (including OpenAI and Cursor) to develop the malware and other hacking tools. - Drew

MORE INDUSTRY NOISES

DYSTOPIA IRL 🐙

TOO MANY LINKS WOULD NEVER BE ENOUGH 🐳

  1. What it's Like to be a Network Engineer... (classic humor from 2017) - Ron Buchalski via LinkedIn

  2. NCSC Unveils SilentGlass, a Plug-In Device to Protect Monitors from Cyber-Attacks - InfoSecurity Magazine   

LAST LAUGH 😆

Shared in the Packet Pushers Community Slack by Danilo.